Modify

Opened 10 years ago

Last modified 6 years ago

#5662 reopened enhancement

display timestamp of individual GPX trackpoints

Reported by: Polarbear-j Owned by: team
Priority: normal Milestone:
Component: Core Version:
Keywords: GPX, timestamp Cc:

Description (last modified by akks)

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.

Attachments (0)

Change History (15)

comment:1 Changed 9 years ago by akks

Implemented in InfoMode plugin (now experimental).

comment:2 Changed 9 years ago by akks

Resolution: fixed
Status: newclosed

comment:3 Changed 9 years ago by 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).

comment:4 Changed 9 years ago by Polarbear-j

Resolution: fixed
Status: closedreopened

comment:5 Changed 9 years ago by 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.

Last edited 9 years ago by akks (previous) (diff)

comment:6 Changed 9 years ago by 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.

comment:7 Changed 9 years ago by 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).

comment:8 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by 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 :)

comment:10 Changed 9 years ago by 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...

comment:11 Changed 9 years ago by 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?

Last edited 9 years ago by akks (previous) (diff)

comment:12 Changed 6 years ago by akks

Description: modified (diff)

I am refactoring GPXLayer now, then will try to do something with this and #5105, #8761, #10136 and maybe integrate InfoMode functionality (its existing code is rather bad, I admit).

comment:13 Changed 6 years ago by akks

In 7319/josm:

Add colorbar for active GPX layer, big GpxLayer class refactoring, see #5662
new classes GpxDrawHelper and ColorScale responsible for GPX drawing and coloring
move data-related methods to GpxData
remove WayPoint.customColoringTransparent from memory, calculate it at paint-time

comment:14 Changed 6 years ago by akks

@team: this version of GpxLayer should be more maintainable.
I hope I can fix any bugs in it before Tested.

I would also like to get rid of tracksVisibility array (there is no fast way to find a track number in his array), but do not know the best place to add visible field or property... (extra method to GpxTrack as an interface, maybe? or leave the array untouched?) We have display-related properties in WayPoint class.

comment:15 Changed 6 years ago by Polarbear-j

Works fine in general. In the filter, 'select by date' allows the sliders to be moved in a position where the From date is later than the To date. If possible, it would be good if both sliders are moved simultaneously once the same date is hit.

When I select the GPX layer, the legend of the velocity colour coding is shown, nice, don't know if that was there before.

Infomode is still a plugin, the time is shown in ISO format in my linux box, still in AM/PM format on my MacOS.
Do we know the time zone of the GPX points?

When traces are dense it is hard to move the mouse pointer into the popup box (for the buttons or the URL). Question is if we need the Delete buttons at all. If we drop them, clicking on the GPX point directly could open the URL.

Last edited 6 years ago by Polarbear-j (previous) (diff)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as reopened The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to Polarbear-j
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.