Track editor: Move points without changing timestamp

Ingo Rau shared this idea 1 month ago
Completed

As discussed in http://help.locusmap.eu/topic/new-track-editor-moving-track-changes-time, the "Insert/edit trackpoint" function in the track editor works like this:

It doesn't matter whether a point is moved (moving green dot) or added (tapping red dot), Locus always creates a new trackpoint at the new position with a timestamp interpolated from the points before and after.

Now for a more or less linear recording, this doesn't matter. However, the intuition is different: A new point's timestamp (red dot) must be interpolated, sure - but for an existing point I expect only the position to change. After all, the GPS may be (way) off, but the phone's time will always be correct (if it was correct at the start).

Comments (19)

photo
1

Example:

Imagine pausing the track recording for a stop, then when you restart it, the GPS is first way off. After your trip, you edit the track to correct this. You know where you stopped, so you can move the recorded points to the roughly correct position - but you expect the time to be kept, as that is when you actually started. Right now, this would happen:

Point 1 (before pause, correct position): 9:00:00

Point 2 (after pause, wrong position): 9:09:00

Point 3 (after pause, correct position again): 9:10:00

Now you modify track, choose insert/edit on point 2 and move it to the correct position. After that, point 2 has the timestamp 9:05:00.*

Your track (and diagram, statistics) will now look more like you moved very slowly suddenly, instead of obviously pausing for 9min.


* NB: Right now, there's a bug in the algorithm (that's what http://help.locusmap.eu/topic/new-track-editor-moving-track-changes-time is about), so you can't recreate this example exactly, but this is more or less how it should work, according to Menion.

photo
1

I agree with you. If you move an existing point, it's time-stamp should not be changed. Only new points should get an interpolated time.


That's almost how it works in Garmin's Basecamp. Basecamp retains a moved point's time-stamp but does not create a time-stamp for new points.

photo
1

Thx. "No timestamp" for new point would be OK for me, if that doesn't confuse calculations and the diagram display. That keeps the track as close to what was recorded as possible. However, I also find the interpolation sensible, that's why I'd like to ignore this aspect here. Only existing points matter for this idea.

photo
photo
1

Hello guys,

try to look on this problem from different perspective. You are basic user that really really don't care about something like trackpoint. He just recorded a track and GPS was bad today in forest and point is on completely wrong place.

So he open track editor, find a function that allows to move with point and simply move problematic point on a place, where he this it should be. But, he do not know exact place where he was in the moment in forest! He only think it was somewhere between these two places!!

So from technical point of view: you are playing here with exact timestamp, but you do not know exact real place! What Locus currently do, is that it don't care about timestamp, but takes average values from points before and after and based on distance to them, compute necessary parameters. Because these values is what user expect to see ... values that are right in the middle of before/after points (based on distances to them).

EDIT: I've just imagined that my algorithm still should be better. But it's on longer time (time when I start rewriting Track editor to support undo/redo).

photo
1

Here's how I see the situation:


The point's location may be wrong because it was miscalculated (bad satellite geometry, signal attenuation, etc). However, the point's time is unlikely to be wrong (unless the clock is offset).

  • Location -> Incorrect
  • Time -> Correct

When moving the point, I think it is preferable to preserve whatever is correct (its original time-stamp).

It just seems natural to me to preserve whatever is correct. For example, if I moved a named waypoint, I would expect it to retain its name and time. Only its location should change. If both the time and name changed, I'd question why it works that way.

photo
photo
1

Compromise proposal:

Outside of the track editor, it's possible to open "Point details", but there the editing of the location is not allowed (tapping on the coordinates gives a red message). Would it be possible to activate this? It's not as "user-friendly", but for these special situations like my example it would at least be a reasonable workaround. Additionally, the Point Detail could also be made available in the track editor?

Anyway, nice to hear you're planning Undo/Redo in Track Editor :)

photo
1

3.27.0: Result is better than before, in above example the moved point is now more in the middle of the other points (even though I still think that's not intuitive).

But I still managed to get a point with timestamp after the point that comes after it. Will try to reproduce and then post the steps here.

photo
1

I posted a step-by-step guide to reproduce the problem in the original Problem topic: http://help.locusmap.eu/topic/new-track-editor-moving-track-changes-time

photo
3

Hello guys,

I've just finished completely new system for editing trackpoints.

It should work in different way then before (on background) and result will be hopefully closer to more logical (and expected) values.

Show info:

  • when you move single point, it's parameters except coordinates, won't change
  • when you move more then single point, it's parameters will be interpolated with little complicated algorithm from closest existing trackpoints (based on distances before and now). Also a times will change.
  • unchanged editable points (green dots) won't be modified at all!

Hope this will be closer to your needs. Because system is little complicated and it's not tested on 100% by me, I'll really appreciate if some from You, who plan to use this function, invest few minutes and test it. In case on problems, detailed step by step to simulate issue will be needed.

Thanks and have a nice evening (feature in next Beta).

photo
1

Looking forward to testing that out. Made me finally subscribe to the Beta testing channel (was too lazy for that so far...).

photo
1

Just tried out 3.27.1.2:

First of all, the point time is not displayed in the flyout anymore, neither in edit mode nor in normal view. I had to go back to regular version to see the new timestamp.

Apart from that, I fear it doesn't work as intended. I just moved one single point, but the timestamp still changed. Tried it twice. I just just my test track from http://help.locusmap.eu/topic/new-track-editor-moving-track-changes-time.

Furthermore, after finishing Insert/Edit Track Point, the view zooms out again to show all of the track - didn't do that before, and of course that's a major hassle.

photo
1

Good day Ingo,

thanks for a testing. Indeed, few more remaining bugs clearly visible on your example track ...

- invisible times: please check menu > maps > points & tracks > track popup content > and check first option with "Recorded time" value

- still incorrect time of moved points: thanks, I've got it (hope)

- moved map to whole track after edit: fixed


So again ... next version.

photo
1

Yeah, of course - Beta version = Free = separate settings. Thx, changed.

And looking forward to trying out the next beta! :)

photo
1

Beta 3.27.1.4:

Sorry to say, but still not working as described. Moving a single point changed its timestamp to the timestamp of the following point. After that timestamp remains unchanged when moving the point again. Wrong indexing perhaps?

photo
1

This really happens? And I was sure, I tested it well ... hmm, thanks.

photo
photo
1

3.27.1.5 (I think, my "About app/Support" doesn't work...):

Much better now!

  • Moving single point: No change in timestamp, check!
  • Only inserting new points (with red dots): Doesn't change timestamp of surrounding points, check!
  • Moving several points, optionally combined with new points: Recalculation, check!I'm still not convinced that just moving (several) points should be allowed to change their timestamp, but that's ok. And if there's a special situation (like my example with very big time gap between two points), I can always do a "move-single-point-only" for that one point.

I could only play around a few minutes for now, so will have a more thorough testing later one - but this is very promising and a big step forward. Thx!

photo
1

OK, I tested it a little more, seems to work fine now. :)

Two minor things:

photo
1

Thanks for a tests! Seems it's finally compute as expected, perfect!

Two issues ... first problem, fixed. Second .. it happen to me as well few times, but I always excused it by incorrect tap on arrow button.

I'll be watching it.

So task completed, perfect :).

photo
1

Mmmh, incorrect tap is of course also possible. However, I remember this already happened with the old editing function, where the < and > were in the bottom button bar. And those buttons were much wider, and even if I missed the buttons there it would most likely have been to the left or right and then activated some other action. So I still think it's more likely there's some tiny bug to squash ;)

photo