climb_factor_gem

Climb Factor

This is a Ruby gem adaptation of the software authored by Ben Crowell, the original source for which you can find here.

Description

This software estimates your energy expenditure from running or walking, based on a GPS track or a track generated by an application such as google maps or onthegomap.

The model used to calculate the results is described in this paper:

B. Crowell, "From treadmill to trails: predicting performance of runners," https://www.biorxiv.org/content/10.1101/2021.04.03.438339v2 , doi: 10.1101/2021.04.03.438339

The output from this software is most useful if you want to compare one run to another, e.g., if I want to know how a mountain run with lots of elevation gain compares with a flat run at a longer distance, or if I want to project whether doing a certain trail as a run is feasible for me.

Use through the web interface

The web interface is available here

Use

Add this to your Gemfile

gem 'climb_factor_gem'

To invoke it, you must provide an array of horizontal/vertical pairs (in meters!):

hv = [[0, 1], [1.1, 4], [3.4, 6], ...]
ClimbFactor.estimate(hv)

See climb_factor.rb for more details and additional options.

Filtering

The parameters filtering and xy_filtering both represent horizontal distances in units of meters. Their defaults values are 200 and 30, respectively. These are meant to get rid of bogus oscillations in the data. Any elevation (z) changes that occur over horizontal distances less than the value of "filtering" will tend to get filtered out, and likewise any horizontal motion that occurs over horizontal distances less than the value of "xy_filtering." To turn off filtering, set the relevant parameter to 0.

The choice of the vertical filtering parameter can have a huge effect on the total elevation gain, but the effect on the calorie expenditure is usually fairly small. There are several reasons why it may be a good idea to set a fairly large value of the vertical ("filtering") parameter:

1. If the resolution of the horizontal track is poor, then it may appear to go up and down steep hillsides, when in fact the real road or trail contours around them.

2. If elevations from GPS are being used (which is a bad idea), then random fluctuations in the GPS elevations can cause large errors.

3. If the elevations are being taken from a digital elevation model (DEM), which is generally a good idea, then there may still be certain types of errors. Trails and roads are intentionally constructed so as not to go up and down steep hills, but the DEM may not accurately reflect this. The most common situation seems to be one in which a trail or road takes a detour into a narrow gully in order to maintain a steady grade. The DEM currently used by this software has a horizontal resolution of 30 meters. If the gully is narrower than this, then the DEM doesn't know about the the gully, and the detour appears to be a steep excursion up and then back down the prevailing slope. I have found empirically that setting filtering=60 m is roughly the minimum that is required in order to eliminate this type of artifact, which makes sense because a detour into a 30 meter gully probably does involve about 60 meters of horizontal travel.

My rules of thumb for setting the filtering are as follows:

• For most runs with relatively short and not insanely steep hills, the default vertical filtering parameter of 60 m works well. Using a higher filtering value leads to wrong results, because the hills get smoothed out entirely.

• For very steep runs with a lot of elevation gain, in rugged terrain, it's necessary to use a larger filtering value of about 200 m. Otherwise the energy estimates are much too high. This is the software's default.

The mileage derived from a GPS track can vary quite a bit depending on the resolution of the GPS data. Higher resolution increases the mileage, because small wiggles get counted in. This has a big effect on the energy calculation, because the energy is mostly sensitive to mileage, not gain.