editgpx not working/documentation defective

[pert]

Apart from the bug already reported concerning the inability to save files,
I am unable to fathom how editgpx is intended to work. The wiki is of minimal help.

By experiment I was able to copy a gpx track onto the editgpx layer. I discovered by
trial and error that dragging a box around a portion of the track deleted all the points
inside said box. I found no way to undo that in case of mistakes. Nor indeed any other
functionality at all.

I experimented with every combination of keys and mouse buttons all to no avail.

On a previous occasion, I somehow managed to get the editgpx context menu to offer to save
the edited track (that then resulted in a type cast bug). But today I was quite unable
to get that version of the context menu. Instead I was just instructed to select objects to edit, although I had finished all the deletions that I required. Also the other LHS icon/buttons did not react: I could not leave this editgpx mode. I do not know if that is another new bug, or just my failure to understand what was required.

editgpx looks very promising and is very fast, but unless I am especially dense, the documentation is completely inadequate. So inadequate that I do not know whether I hit some sort of deadlock bug, or just didn't know how to change mode. I can't offer to improve the documentation since I have no idea how it is supposed to be driven.

josm ver 1607. editgpx ver 14247

[leoss]

I extended the documentation at ​http://wiki.openstreetmap.org/wiki/JOSM/Plugins/EditGpx
It should be clear now.

[pert]

Yes, much better now.

I haven't used the time cleaning option, but I wonder whether there might be an intermediate setting
which retains direction information: perhaps with each interval set to 1 second or whatever?

Reason: I usually take a forward and a reverse track of a way to check accuracy and consistency. Knowing the direction (on roads at least) carries information about which side or lane was mapped. The two tracks crossing, or not matching the direction normally indicates poor satellite signals received. Retaining the time order while removing the absolute speeds and times keeps the information available for general use.

[leoss]

Replying to pert:

Yes, much better now.

I haven't used the time cleaning option, but I wonder whether there might be an intermediate setting
which retains direction information: perhaps with each interval set to 1 second or whatever?

Reason: I usually take a forward and a reverse track of a way to check accuracy and consistency. Knowing the direction (on roads at least) carries information about which side or lane was mapped. The two tracks crossing, or not matching the direction normally indicates poor satellite signals received. Retaining the time order while removing the absolute speeds and times keeps the information available for general use.

I set the timestamp of all points to one defined timestamp 1970-01-01 00:00 because the people recognize this is no real timestamp. Why is this important? If maybe in the future the speed limit for roads will be calculated from the uploaded GPX tracks, manipulated tracks can harm the calculation. The timestamp I use is obviously wrong so it will be ignored. It's a simple rule. I don't want to complicate this with other rules like - track is also wrong if time between two points is one second - or something like this.