This object is in archive! 

(New) Track Editor: Moving track changes time

Ingo Rau shared this problem 6 years ago
Solved

I can't say if it's a new problem with the new editor, but I never noticed this and I edit tracks quite often:

It's simple to describe: When I move a point, its timestamp changes. That shouldn't be the case, moving a point is only to correct its position.

Furthermore, inserting a point sometimes leads to incorrect order, i.e. a new point gets a timestamp before the point it actually comes after. This is something I experienced before, but it seems to have gotten a bigger problem. It can't be reproduced 100%, but when doing insert/edit and then several move and insert, and then check the timestamps, it should happen pretty easily.

Replies (9)

photo
1

Update about the changing timestamp on moving a point:

I have this on my Note 4 (Android 5.1.1), doesn't happen with all points, but with most. Now I tried it on my TabS2 (Android 7 something), and there it doesn't happen. Can't really imagine it's Android-related, but don't know what else could be the difference. When I find the time, I will take an identical track and do the same edit on both devices at the same time, see if it's really device-related or some other coincidence.


About the messed up chronological order:

This is also hard to exactly reproduce, but what I usually do is the following: I have a not very straight track along a rather straight road. What I do is, i "Cut inner part" several times for intermediate points. Then I "Insert/Edit trackpoints", moving some of the remaining points and, when the road wasn't completely straight, adding additional points with the red dots to make the track look nicer. The result looks better and needs less space (as I usually record with very short time between new points).

As I said, I can't give you a track and say "Do this, this and this, and bamm!", but doing what I described above, for me a wrong (out-of-order) timestamp appears roughly 1 out of 3 times. I can't really imagine I'm the only one having this problem - unless not many people do it like I do.

photo
1

Ok, I finally found an example to reproduce this. Take the attached GPX. Now go to point 27 (on Oktogon, if you knew a little bit of Budapest):

9c8065fb1d9a32f3b9d99e5c6738469aTime is 9:54:03

Now modify track, select that point and move it with Insert/Edit trackpoint:1ec620524bc8ee9a2a2b132764074419

So it looks like this:

8c95720e1bf0f420f783fa0e2d1a0c96

Tapping on the point reveals 9:33:37:

d472ad97de4db778ffeeacb041b47f77

This probably has to do with the fact that there's a very long break befor, point 26 has timestamp 9:32:25:

8a941c49588202afdabee559db920df2


Things get even worse if you start to add points using the red dots (only in this case I get points with wrong order, but for that I still don't have a 100% reproduction - but I'm sure if you play around with this example, it will happen).

I assume it has to do with the fact then Insert/Edit makes +/- 10 points editable and when finished, distributes differences over all points, no matter what was actually edited. Perhaps this is a side effect of when you switched to having +/-10 instead of +/-1 point editable (which, I admit, you did after my nagging...). Perhaps the old algorithm now has a problem here.

If that is so and cannot be easily corrected, I would rather you go back to +/-1 points for edit, because changing timestamps when simply moving points, even without adding anything, is really bad, I'd say...

photo
1

Hello Ingo,

thanks for a precise description of this problem.

I made system for editing quite a long time before and I remember, I was quite satisfied with it :). And thanks to your sample file, I've discovered quite serious issue in the middle of algorithm, so this problem will be solved in next version.

Anyway highlighted points won't preserve it's time and other parameters, but will be always interpolated from point before and point after this one. This is how it's currently made. As you wrote, this system was made for editing of 3 or 5 trackpoints, where this worked fine. Now, with a higher number, it should be improved.

Anyway this serious issue should be fixed now, thanks!

photo
1

Hi Menion!

First of all: thx! I'm also happy that I finally found a way to reproduce this, because this was bothering me for a long time, but not always, so I couldn't get my finger on.

But do I understand you correctly that moving a point will still change this point's timestamp? If so, shouldn't it be possible to have an option to move points only in position, not changing their timestamp? I'm pretty sure that's most users' expectation: You edit a track, see a point that is somewhere wrong, probably due to GPS inaccuracy, you move it - but of course the time was correct, so you don't want that to change.

photo
1

Hello,

current system does not change only timestamp, it completely generate all values based on points before and after.

In case of fluent track recording, let's say every 5 seconds, current system should cause no big problem. In your case, where time between points was around 20 minutes, it generates different time then expected, agree. But I cannot simply change one parameter to allow this. Take it or don't use it ;).

photo
1

Ok, understand - just wanted this clarified.

Sure, in most cases with more or less linear recording it poses no problem. But I'm pretty confident that many share my intuition, so I'll add it as idea - let's see what the others think.

photo
1

Have to reopen this. As mentioned in http://help.locusmap.eu/topic/track-editor-move-points-without-changing-timestamp, there is still something wrong.

It can be replicated with the same track as above. Performing the same steps as above, the moved point has a much more "sensible" timestamp of 9:46:29 which is roughly in between the surrounding points (not gonna argue about that here, that's for the other topic).

763a5d15ef0628aab361befc469cf67b

Now select Point 26 again, choose "Insert/edit trackpoints" and move the two previous points as shown here:

4765817d5f1a007fb2e650510aee3ff2 => 45fd80a089b04aa638be8121dfa7c9ec

Now, Point 26, which wasn't moved at all, has timestamp 9:49:15 (or something the like) which is after Point 27!

6d938b8f1ae3d2d50c0ef3ab6058b9c7

First, I'm really convinced that a point that wasn't touched shouldn't change timestamp (regardless of our discussion about a point that is actually being moved). And, certainly, the result may not be a track with jumbled up order of points. That even shows in the chart:

d436610a65a8d9b01c00e694ec7d4453

photo
1

Hello Ingo,

firstly thanks for detailed report. I agree that untouched point should not change it's time, this is something I need to improve. Well as I see, I'll really need to rewrite it completely, hmm ...

photo
1

Hi Menion, did you already change something here in 3.27.2? I have the feeling the above steps lead to slightly different results, but still "untouched" points get their timestamps changed...

photo
1

I mean 3.27.1, of course

photo
1

Good day Ingo,

there should be no change for now. I have partially prepared new function that should replace current solution, but it not yet works and not affect current system.

photo
1

Hello Ingo,

believe that based on discussion in second thread, we may close this.

In case of any problem, feel free to open discussion again. Thanks!

Replies have been locked on this page!