Track-Distances uphill and downhill not helpful at the moment.
When I look at a trail`s data, the values for the distances uphill and downhill typically make up for the whole length of the track because the distance "flat" is never much more than zero.
Look at this screenshot of a walk around a lake with very few parts of the trail that were not completely flat:
By looking at the last four rows in the distance-column, the casual viewer might think I had been hiking in the mountains ("only 115 meters flat - must have been hard!").
I would like to see a customizing option where I can specify which gradients I consider uphill or downhill.
Something like
"Parts of tracks to be considered uphill when their gradient is at least" x%
"Parts of tracks to be considered downhill when their gradient is at least" y%
where I can fill in values for x and y (at the moment, it seems to me that internally, x=y=0%).
In the example of the screenshot above, values then would be something like this, better showing me the character of the trail:
Distance for...
Downhill 90
Uphill 110
Flat 23543
I like this idea 
Good day Christian,
I`m checking source of function that compute these values. Before more then eight months, value used to decide if gradient is still flat or not, was 2%.
But before these eight months, I changed it to 0.01%. This change was anyway done, because I created a smoothing mechanism, that optimise altitude values during storing to database.
What you see on screenshot, is already stored track or just still actively recording?
I can anyway add these two parameters to configuration file, but better should be to find optimal middle values, that will be best for 90% of cases ...
If you want, you may share exported GPX file. I`ll do some tests also in other applications, and optimize parameter to some better value.
Good day Christian,
I`m checking source of function that compute these values. Before more then eight months, value used to decide if gradient is still flat or not, was 2%.
But before these eight months, I changed it to 0.01%. This change was anyway done, because I created a smoothing mechanism, that optimise altitude values during storing to database.
What you see on screenshot, is already stored track or just still actively recording?
I can anyway add these two parameters to configuration file, but better should be to find optimal middle values, that will be best for 90% of cases ...
If you want, you may share exported GPX file. I`ll do some tests also in other applications, and optimize parameter to some better value.
Hi Menion,
thanks for the quick answer.
The screenshot is from a track that has already been stored. You can find the gpx-file here:
https://dl.dropboxusercontent.com/u/4...
I`d really like to get two parameters (you could set them to 0,01 initially so that nobody would get unexpected distances uphill/downhill with the new Version). But ultimately, that`s your choice, of course.
Hi Menion,
thanks for the quick answer.
The screenshot is from a track that has already been stored. You can find the gpx-file here:
https://dl.dropboxusercontent.com/u/4...
I`d really like to get two parameters (you could set them to 0,01 initially so that nobody would get unexpected distances uphill/downhill with the new Version). But ultimately, that`s your choice, of course.
I`ve tested three PC programs and two web generators and only this site http://utrack.crempa.net/index_en.php show also distance for uphill and downhill.
Mentioned site show around 4,6 km for both values, which is equal to 2% grade limit. So I set this value for counting distances also to Locus. For elevatiou values, in all cases, Locus show little bit less value. Other programs usually show around 290 m, but it`s OK here I think. Question is, how precise it will be in mountains ...
I understand you want to define these two parameters, but I still think, that we should find some universal value, that satisfy in most cases all people.
I`ve tested three PC programs and two web generators and only this site http://utrack.crempa.net/index_en.php show also distance for uphill and downhill.
Mentioned site show around 4,6 km for both values, which is equal to 2% grade limit. So I set this value for counting distances also to Locus. For elevatiou values, in all cases, Locus show little bit less value. Other programs usually show around 290 m, but it`s OK here I think. Question is, how precise it will be in mountains ...
I understand you want to define these two parameters, but I still think, that we should find some universal value, that satisfy in most cases all people.
Another option might be to take fixed parameters of "2%-5%" for uphill/downhill and to add two more lines for "steep up" and "steep down" who take into account anything that is steeper than 5%.
Another option might be to take fixed parameters of "2%-5%" for uphill/downhill and to add two more lines for "steep up" and "steep down" who take into account anything that is steeper than 5%.
Could this be already have been implemented? Even for trips in hilly regions like the Black Forest in Germany, Locus classifies roughly 1/5 to 1/2 of the distance as flat, for example 1/3 of http://www.openstreetmap.org/relation/5963743 (elevation profile and GPX download e.g. at https://www.xctrails.org/map.html?zoom=15&lat=47.86908&lon=8.11099&layers=B00000TFFTTTTTTTTTTFTTT).
Could this be already have been implemented? Even for trips in hilly regions like the Black Forest in Germany, Locus classifies roughly 1/5 to 1/2 of the distance as flat, for example 1/3 of http://www.openstreetmap.org/relation/5963743 (elevation profile and GPX download e.g. at https://www.xctrails.org/map.html?zoom=15&lat=47.86908&lon=8.11099&layers=B00000TFFTTTTTTTTTTFTTT).
Replies have been locked on this page!