Is there a way to recalculate a track's statistics?

Taras D shared this question 12 months ago
Answered

Currently, I have Altitude Manager's SRTM Data set to "Replace GPS values" and Altitude Filter is set to "Light filter".


If I change "Light filter" to "No filtration", an existing track's statistics remain unchanged; there's no change to the values for Downhill/Uphill Elevation.

Is there a way to force Locus Map to recalculate the track's statistics using the new setting for Altitude Filter?

Comments (11)

photo
1

Good day Taras,

not sure what you expect in this case. You change filter for elevations and expect that elevation of existing tracks will be affected by this and change??

This won't happen, sorry. Whole "Altitude manager" change only elevation that is currently processes during enabled GPS system. It has absolutely no effect on already stored tracks.

Btw. statistics for tracks are automatically recalculated when something change, there is no need to take care of it manually.

Was my answer useful?

photo
1

In a competitor's product, "Noise Reduction" is applied after all the data has been recorded (post-processing). "Elevations Gain/Loss" is automatically recalculated if "Noise Reduction" is changed from "Medium (default)" to another value. I think it triggers the recalculation only when an existing track's details are displayed (i.e. if you change Noise Reduction it does not recalculate all existing tracks in one bulk operation, just the one you are viewing).


I know Locus Map does not work this way so I thought there was a way to manually trigger the recalculation. I performed the following experiments:


Experiment #1

  • SRTM Data = No usage
  • Altitude Filter = Light filter
  • Imported a track. Elevation Downhill = -1888 m.
  • Deleted several trackpoints. Distance was reduced and Elevation was virtually the same (decreased by 1 meter).
  • Deleted the track.

Experiment #2

  • SRTM Data = No usage
  • Altitude Filter = Ultra heavy filter
  • Imported the same track. Elevation Downhill = -1888 m. Same as with "Light filter".
  • Deleted several trackpoints. Distance was reduced and Elevation was the virtually the same.
  • Deleted the track.

Experiment #3

  • SRTM Data = Replace GPS values
  • Altitude Filter = Light filter
  • Imported the same track (no elevation fill). Elevation Downhill = -1888 m. Same as previously.
  • Deleted several trackpoints. Distance was reduced and Elevation was the virtually the same.
  • Deleted the track.


I also performed other experiments where I imported the track, then changed Altitude Filter, deleted a trackpoint, and the Elevation remained the same.

Based on what you said, and my experiments, modifying an existing track can cause its Distance to be recalculated but not its Elevation Downhill/Uphill. That's because Altitude Filter applies exclusively during the recording process. It is never used to recalculate Elevation after the track has been saved (i.e. there is no post-processing of Elevation). Is this correct?


If I'm not mistaken, this means that Altitude Filter has no effect on Elevation Downhill/Uphill when SRTM Data is set to "Replace GPS values". Is that right?

photo
1

In my understanding, altitude filter is supposed to filter GPS altitudes. If they are replaced by SRTM altitudes, it lost its job.

SRTM altitudes are smoother and generally more accurate then GPS altitudes,

GPS altitudes may be more accurate then SRTM altitudes where there are strong slopes or edges, like in mountains or "urban canyons". For such scenarios may be useful another There is another SRTM related option - ideal for such a case - Optimize GPS altitudes(or similar name). GPS altitudes are not generally replaced, only some outliers.

photo
1

It was my misconception that Altitude Filter was also used to post-process the elevation data. In other words, SRTM+Light Filtering would produce a different result from SRTM+Heavy Filtering. However, experiments show that is not true. It appears that Altitude Filter has no influence on elevation calculated from SRTM. My perception of how it worked was wrong.


In addition, when using GPS altitudes (not SRTM), the Altitude Filter only applies while the track is being recorded. After the track is saved, the total Elevation remains a fixed value and subsequent changes to Altitude Filter do not alter it. Altitude Filter is used exclusively during recording and never to post-process an existing track.

photo
1

This is correct, in case of "Replace by SRTM", altitude filter has no effect ( should be probably disabled in UI).

Whole elevation filter has really effect only on new fresh GPS data, it is never applied later on any stored tracks.

You wrote about non-changing elevation after removing few trackpoints. This is really weird ... can't this be caused just because you removed a few trackpoints on really flat area?

photo
1

Or rather on a slope, where trackpoint altitudes may form monotonics serie easier then on flats.


As stronger noise is needed on slopes to break the monotonousness, compared to flats.

photo
1

@Menion @Libor


I only removed a few trackpoints (< 5), some on flats and some on slopes, and in places where the trackpoint's removal made the track straighter (in other words, I removed a few "zig-zags").


It was enough to reduce the Distance by tens of meters but not enough to noticeably affect Elevation. It only decreased by a meter. It now makes sense to me because Altitude Filter has no effect when using SRTM altitude values.


If you can disable the Altitude Filter in the UI (when SRTM replace values is enabled), that would be very helpful to communicate that one doesn't use the other.

photo
1

Hi guys,

interesting. I was sure that it works how I wrote before.

But during check I found out that "replace by SRTM" is first step, but filtering is not stopped after this and continue to next step > pressure sensor > and in the end also > filter.

So generally option "SRTM data" only modify received GPS value, but all following steps are same. On one side, it gives some extra flexibility ( like you may wants to apply srtm-replace and also strong filter ), on second side, it complicates logic of whole altitude manager, because it brings another possible combination.

Hmm anyway, now you probably know all necessary info for this topic. if something won't be clear, feel free to ask.

photo
1

>>"SRTM data" only modify received GPS value, but all following steps are same. ... it gives some extra flexibility ( like you may wants to apply srtm-replace and also strong filter )

Now I'm confused! :( You are saying filtering is used even with SRTM data?

In my experiments, I switched from "Light filter" to "Ultra heavy filter", deleted a few trackpoints to trigger a recalculation, and the Elevation remained virtually unchanged. I would expect a noticeable difference between "Light" and "Ultra heavy" filtering but there was none. It behaved like filtering was not used.

photo
1

Taras, everything in "Altitude manager" is NOT applied on already stored data only on FRESH data received from GPS.

Altitude of once recorded and saved track cannot be modified ( except one-time "Fill elevation" option ). Ok?

photo
1

Ah! Thanks! I think the process is clear to me now!

Filtering is applied, even on SRTM values, but only for the initial, freshly recorded data (i.e. the first time the data is saved as a track). After that, filtering is never used on the saved track. If the track is modified (delete/add trackpoints) the statistics are recalculated but without filtering.


PS


I suggest adding a brief description of this process to the Altitude Manager's documentation. It offers many controls for recording and calculating Elevation. Each control is explained but how they all interact with each other is not clear in the documentation.

photo