display timestamp of individual GPX trackpoints

[Polarbear-j]

It would be helpful to be able to show the timestamp of a particular GPX trackpoint.

This would help e.g. to align a note taken at a particular time if the logger cannot set waypoints.

To avoid clutter in editing mode, this could require selecting the GPX layer as the active one, and a mouse-over the trackpoint shows its time, maybe also the full XML data set of this trackpoint.

[akks]

Implemented in InfoMode plugin (now experimental).

[Polarbear-j]

Thanks! I tested it today, it works fine with one exception:

When I use a local GPX file only, it does not display the name of the file in the info box.

Once I download the traces for the area, and get info about a point in them, I get the trace URL.

Now, even if I delete the download-gpx layer, and look at a point of my local files again, it shows the stale URL of the downloaded one.

It appears also that some timestamps are not displayed, although the trace's website says it is identifiable with timestamps (but maybe this is a side effect of the stale URL).

[akks]

Thank you!

I have fixed the bug with URL and also added scanning of all layers if non-gpx layer is selected.
If timestamps are missing now (at least sometimes), please let me know.

I did not find source file information in gpx track class (and GpxLayer, except its name). If we really need displaying link to it, kernel could be changed.

You can close the ticket yourself, if all works OK.

[Polarbear-j]

akks, thanks the bogus URL issue has been fixed, and the function becomes very useful now.

I just wonder if the source of the trace could be displayed in general, so as the URL is displayed for downloaded traces now, that could be the filename for local ones.

Also I find some downloaded traces that do not display any source URL at all, they then also show no timestamps. However 'hide this and older' seems to work so it still has some implicit time stamp? Is there a way to UnDo the hiding in case a wrong point has been selected?

For testing, ​http://www.openstreetmap.org/browse/way/32889207 is a new roundabout that has plenty traces from the old road behind.

[akks]

Displaying source for local file needs support in core (while opening file, its name should be remembered in GpxTrack class). A can make a patch later.

Traces without source url and no timestamps are non-identifiable tracks. They are all merget together and sent to client (see Info panel in layer context menu). Their timestamp is formally 0 (or year 1970), so they hide every time user choose 'hide this and older'.

I am thinking about way to undo hiding the tracks. Currently, they are simply deleted from the data. I am afraid, the is no good solution for filtering without serious modification of the core (some hiddenTracks set, of isHidden attrbute for every track).

[Polarbear-j]

Ok I understand. Maybe the 'non-identifiable' issue and the zero-timestamp could be indicated ("No timestamp [=0]" in the info box so the user knows what he does when hiding them. Probably the button "Hide this" should be named "Hide this age".

The term to 'hide' them implied they were just switched invisible. I understand that as they are deleted, undoing is trickier. Maybe we just label the buttons differently to avoid wrong expectation (Remove this age, Remove this age&older). Would be easy enough to re-load them from the server.

The name for the local file would be good, still.

Maybe get the info box a bit closer to the red dot, if there is another tracepoint in between it is hard to move the mouse into the box.

[akks]

OK, i'll rename the buttons and change some messages. I'll also post a patch to save tracks file name some time later.

About moving info panel - I tried, but in this case it is hard to switch trackpoints for certain directions of the track. Buit you can hold Shift button and info panel moved as you wish together with highlighting the track :)

[Polarbear-j]

With the implementation of the ability to select which traces to show for each GPX Layer in [4332/josm], see #5661, the plugin should be harmonised with the visibility of the traces. Maybe you could use the same mechanism to make them invisible, instead of deleting them.

Also, the plugin now shows trace points that are set invisible, which can be confusing...

[akks]

Yes, some rework is needed. But the problem is that the is no interface for trackVisibility[] array and plugin can not access or modify it!

So, the kernel need to be patched once more. I do not know the plan of further GpxLayer development, but my opinion is we need:

1) Introduce hideTracks() , showTracks() methods (for individual tracks and timestamp-filtering)

2) Provide convenient (and fast) way to find visible tracks or check if track is visible (essential for plugins!)

3) Include basic filtering methods in context menu instead of plugin (hide older then ...). Plugin can have function "hide older than this" and "hide this".

I have no time to write good patch right now. Maybe more GpxLayer upgrades by Xeen will follow?