Opened 14 years ago
Last modified 3 years ago
#7037 new enhancement
[WIP PATCH] Median of gps tracks
Reported by: | Owned by: | Bjoeni | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | |
Keywords: | Cc: | pabs |
Description
I suggest a function to show a medium of gps tracks. Sometimes there are so many tracks that it's hard to find a compromise between own gps records and those of other users. So it would nice to get a blured line or a single sharp line representing the sum of all gps tracks. Some options could help to make it more flexible: maximum date of gps tracks (to get rid of old and inaccurate lines), radius for median (way near by other way -> radius small) and so on...
See picture for better imagination.
Attachments (3)
Change History (23)
by , 14 years ago
Attachment: | Untitled-2 copy.jpg added |
---|
comment:3 by , 14 years ago
Copy from #7020:
There is some code (written in R) to do the averaging here:
https://github.com/dittaeva/Average-tracks/
There is more info about this code here:
http://wiki.openstreetmap.org/wiki/Average_tracks
There is some proprietary software plus a paper about a more advanced method for doing that here:
http://www.topofusion.com/network.php
http://www.topofusion.com/jcdl-04-trails.pdf
comment:4 by , 14 years ago
Cc: | added |
---|
comment:5 by , 14 years ago
When it comes to interpolation and pattern recognition, the human brain is far superior to any algorithm. IMHO, this feature has very limited use. Maybe for a wide region without aerial imagery, where it would be too cumbersome to trace the gps tracks by hand.
comment:6 by , 14 years ago
I guess you are assuming people only submit features to OpenStreetMap based on aerial imagery. I would challenge that assumption and state that I have found such data to be of low quality.
The only ways I submit to OpenStreetMap are from my GPS device. I traverse a way multiple times, usually at least once in each direction. Having this feature would enable me to upload more accurate ways and would be immensely useful. Especially for ways that are not roads or cannot be seen in aerial imagery, this is even more important.
comment:8 by , 14 years ago
Here is a helpful script regarding this issue:
http://www.openstreetmap.org/user/Guttorm%20Flatabø/diary/14964
comment:9 by , 12 years ago
Reporter: | changed from | to
---|
comment:11 by , 5 years ago
Owner: | changed from | to
---|---|
Summary: | Median of gps tracks → [WIP PATCH] Median of gps tracks |
Here's a WIP implementation for averaging OSM ways, inspired by the script by Michiel Faber and Guttorm Flatabø mentioned above (CC0), enhanced for efficiency. Still needs some work though.
by , 5 years ago
Attachment: | 7037v0.1.diff added |
---|
comment:12 by , 5 years ago
Hmm, you know that we have a heatmap feature in JOSM for GPX data? Is there anything to that ticket which is not covered by the heatmap?
comment:13 by , 5 years ago
That serves different purposes. This patch applies to manually selected OSM ways as suggested in #7020, not GPX layers in general. So you choose two or more ways and get one resulting averaged way.
In my opinion this feature is useful for regions with no usable aerial imagery, but multiple GPX tracks (doesn't matter if downloaded from OSM, your own track e.g. from going back the same way or a combination of both). Also we have regions in OSM where you can still add tens or possibly even hundreds of kilometers of tracks/paths without intersecting other paths.
follow-up: 20 comment:14 by , 5 years ago
What's the advantage of manually selecting a track compared to the heatmap?
comment:15 by , 5 years ago
The heatmap only gives you a visual representation, while this gives you an actual way usable for OSM.
See also the comments above:
bastiK
Maybe for a wide region without aerial imagery, where it would be too cumbersome to trace the gps tracks by hand.
pabs
The only ways I submit to OpenStreetMap are from my GPS device. I traverse a way multiple times, usually at least once in each direction. Having this feature would enable me to upload more accurate ways and would be immensely useful. Especially for ways that are not roads or cannot be seen in aerial imagery, this is even more important.
comment:16 by , 4 years ago
Hello, I'm currently developing a JOSM plugin for maintaining bus routes. One of its features is producing the average of a collection of GPX tracks, which might be what you're looking for. You can find the plugin here:
https://github.com/archwheeler/bus-route-maintenance/
If you collect all of your tracks as different segments within a single layer, you can produce an average track by going to Data > Average GPX tracks.
I hope this helps, any feedback would be greatly appreciated.
comment:17 by , 4 years ago
@archiewheeler, any reason to not add your plugin to PluginsSource? There's a bunch of plugins which are hosted on GitHub and included this way.
follow-up: 19 comment:18 by , 4 years ago
@archiwheeler, sorry for the late response and thanks for pointing that out. It works a bit different than the patch I proposed (mine works with already converted OSM ways, yours uses the whole segment). I assume you usually have one segment per bus ride from the tracker?
My idea was to basically allow the user to merge two OSM ways after converting and cutting them, as I usually have one long segment (e.g. when hiking in the middle of nowhere). So I guess both make sense, just different use cases.
Regarding your plugin:
- When the segments are in opposite directions, I get a StackOverflowError (see issue on github).
- The start points of the different segments must be nearly at the same position for your plugin, otherwise it looks like this:
(not sure if that's intended, since bus routes should always have the same start/stop, but I thought I'd mention it. That obviously would not work for my use case)
by , 4 years ago
Attachment: | merge-sample-uneven.png added |
---|
comment:19 by , 4 years ago
Replying to Bjoeni:
@archiwheeler, sorry for the late response and thanks for pointing that out. It works a bit different than the patch I proposed (mine works with already converted OSM ways, yours uses the whole segment). I assume you usually have one segment per bus ride from the tracker?
My idea was to basically allow the user to merge two OSM ways after converting and cutting them, as I usually have one long segment (e.g. when hiking in the middle of nowhere). So I guess both make sense, just different use cases.
Regarding your plugin:
- When the segments are in opposite directions, I get a StackOverflowError (see issue on github).
- The start points of the different segments must be nearly at the same position for your plugin, otherwise it looks like this:
(not sure if that's intended, since bus routes should always have the same start/stop, but I thought I'd mention it. That obviously would not work for my use case)
Thanks for the feedback! I've replied to your issue on GitHub. A new option has been added to the plug-in which produces a much more sensible average for your data:
comment:20 by , 3 years ago
Replying to stoecker:
What's the advantage of manually selecting a track compared to the heatmap?
@Dirk, what's your take on this ticket / the WIP patch from comment:11?
Because I won't pursue this any further if it doesn't have any chance of being merged anyways, but I personally think it makes a lot of sense.
- It provides more functionality than the heatmap (see comment:15) and
- it serves a different use case than the plugin mentioned by archiewheeler
- it makes editing much easier and more accurate in certain regions (that are currently not mapped well and/or have no imagery of usable quality)
Also there are three tickets requesting the same thing.
example of gps median and time limit