Don't display a gradient point in chart for track that has a gap - often displayed as spike
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:
And corresponding data from GPS track editor:
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.
The same problem 
Good day Andrew,
issue should be fixed in next Locus version.
Good day Andrew,
issue should be fixed in next Locus version.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!