This object is in archive!
(New) Track Editor: Moving track changes time
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.
The same problem 
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.
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.
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):
Now modify track, select that point and move it with Insert/Edit trackpoint:
So it looks like this:
Tapping on the point reveals 9:33:37:
This probably has to do with the fact that there's a very long break befor, point 26 has timestamp 9:32:25:
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...
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):
Now modify track, select that point and move it with Insert/Edit trackpoint:
So it looks like this:
Tapping on the point reveals 9:33:37:
This probably has to do with the fact that there's a very long break befor, point 26 has timestamp 9:32:25:
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...
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!
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!
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.
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.
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 ;).
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 ;).
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.
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.
Added idea: http://help.locusmap.eu/topic/track-editor-move-points-without-changing-timestamp
Added idea: http://help.locusmap.eu/topic/track-editor-move-points-without-changing-timestamp
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).
Now select Point 26 again, choose "Insert/edit trackpoints" and move the two previous points as shown here:
Now, Point 26, which wasn't moved at all, has timestamp 9:49:15 (or something the like) which is after Point 27!
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:
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).
Now select Point 26 again, choose "Insert/edit trackpoints" and move the two previous points as shown here:
Now, Point 26, which wasn't moved at all, has timestamp 9:49:15 (or something the like) which is after Point 27!
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:
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!
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!