[WIP PATCH] Median of gps tracks

[biff21@…]

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.

[biff21@…]

example of gps median and time limit

[skyper]

#7020 requests the same for osm data ways

[stoecker]

Ticket #7020 has been marked as a duplicate of this ticket.

[stoecker]

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

[bastiK]

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.

[pabs]

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.

[skyper]

Ticket #7035 has been marked as a duplicate of this ticket.

[malenki]

Here is a helpful script regarding this issue:
​http://www.openstreetmap.org/user/Guttorm%20Flatabø/diary/14964

[Bjoeni]

Ticket #9004 has been marked as a duplicate of this ticket.

[Bjoeni]

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.

[stoecker]

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?

[Bjoeni]

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.

[stoecker]

What's the advantage of manually selecting a track compared to the heatmap?

[Bjoeni]

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.

[archiewheeler@…]

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.

[simon04]

@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.

[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)

[archiewheeler@…]

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:

[Bjoeni]

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.