This object is in archive! 

Don't display a gradient point in chart for track that has a gap - often displayed as spike

Andrew Heard shared this problem 8 years ago
Solved

At present when I merge two tracks and retain the gap (the default) the elevation of the last point in the first track, and the elevation of the first point in the second track may have no relation to each other, but are still used to calculate the gradient at that point, often resulting in a great spike in the gradient chart. For example chart:

5dc9c416a54bc7640664f74c4fff551a

And corresponding data from GPS track editor:

87f685ca3ea27730e391ae4631d64802

24bcb7fc8e7797d65c1c87b90ef6ab95

In this example the tracks had a gap of 15 minutes (a lunch break) and although the position remained the same, the inaccuracy of altitude measurement had 189m and 230m for the same point.

I suggest that no gradient point be calculated at any track discontinuity. It makes no sense. This can ruin the auto-scaling. In a more extreme (general/ better?) example the tracks may be completely unrelated to each other.

Replies (6)

photo
1

Good day Andrew,


issue should be fixed in next Locus version.

photo
1

I notice this bug has crept back in or wasn't fixed properly. In each of the two screen caps below two tracks have been merged resulting in large gradient spike at the end of first <trkseg>. Have attached corresponding GPX files. I also note related topic here.

c28ed3da6e9b8502d66bfdc7cbe89ed1

2d44ef70966162bf6eee7e05a94863d5

photo
1

Hello Andrew,


I'm checking your file 20160723.gpx, and from my point of view, all is fine.


Check lines 4231 and below. First point before break has elevation 164, first after break has 23, second 91, third 158 ... so chart is correct based on values in GPX file.

photo
1

Surely from "real life" user point of view, all is clearly wrong?


Isn't is really strange the elevation data each side of a <trkseg> break are invalid? These are only 2 examples of many. Often a spike very close to the track recording pause or merge of stop/restart. And because the user has no control over Y axis scaling it means that the real gradient data is squeezed down towards the 0 axis.


There is no point using track > More > Fill elevation - replacing actual recording data with SRTM data.


Comparison below (red=actual green="filtered" SRTM):

68419b35a6dd7d284ba197732fad1e1a

When I manually deleted one <trkpt> before the </trkseg> and two <trkpt> after, the spike was removed.


It appears the few elevation values as GPS is enabled/ disabled are very inaccurate. Some calculation error or filter settling/ stabilization time. Unless the GPS is enabled/disabled while track recording the user would not normally notice this error. So could the first/last few track point elevation values be ignored?

photo
1

Menion have you considered the effects that GPS altitude filtering could have at the start and end of a track gradient? My phone doesn't have a hardware barometer but I have found by detailed comparison with a Garmin GPS that has a barometer (and I therefore guess is more accurate when calibrated) that "heavy" altitude filtering gives the best approximation. With this filter enabled shouldn't the first few (or more) elevation points be discarded while the filter stabilizes? May this explain the inaccurate elevation values I am observing when I pause track recording and manually disable then later re-enable the GPS?


A related question: is the dashboard "elevation (uphill)" derived from the filtered or unfiltered altitude? I ask this because before saving a track recording I notice the "elevation (uphill)" value always seems significantly higher than when I later view track statistics after the track is saved. This is what led me to writing this topic.

photo
1

Good day Andrew,

I'm thinking about this problem. I think that original issue is solved. Problem was that in merged track was not a correctly visible gap and gradient was computed from point before gap and after gap. This is already solved.


What happen to you is anyway not a problem in computed gradient. Problem here is a fact, that Locus recorded trackpoint with really invalid elevation value. So problem is in source/recorded data, not in displayed chart as you already wrote in last post.


...


Oki, I did a one workaround. Locus will counts number of received locations since location source change. In this case, if you enable GPS in Locus, every received location increase counter by one. And recording service will now throw away first two points right after you enable GPS. So first recorded point will be "location no. 3".


In case, GPS will be already running, this will have no impact. In case, Locus turn on GPS right because of start of track recording/un-pause, this cause 2 seconds delay in start of recording. Hope this will be minimal tax for this.

photo
1

Good solution. I can't see any disadvantage of this. It sounds to me that an elevation filter is still stabilizing after starting (Android or Locus). You didn't comment on whether with "heavy | ultra" filter setting needs more time to stabilize after GPS is re-enabled? Will the workaround be in the next beta? I will test with current & new beta & let you know how they compare. Thank you.

photo
1

Hi Andrew, this new feature is already implemented in yesterday published Beta version 3.18.6.5 , so You may try it.


About filter ... it do not need some extra time. Elevation filter is based just on filtered value from previous measure. With created workaround it should work quite fine.

Replies have been locked on this page!