OpenStreetMap
calculate ways instead of drawing or: a look at "average tracks"
Posted by malenki on 30 October 2012 in English. Last updated on 1 December 2012.Since I was at it I checked again Average tracks mentioned yesterday.
In the valley of Trenta there is a nice highway with a lot of logs uploaded but it isn’t drawn really nice so far. I downloaded all the GPS data using JOSM, converted it to a data layer and cleaned it so that only good traces remained. Saving the data as gpx again, the resulting file contained nearly fifty tracksegments. I split that file into single gpx files each containing one of the segments. These I converted into csv format since the script wants this format.
A first run on all segments I cancelled after short time remembering the runtime of osm-makeroads.
I randomly selected some segments but since some covered only a part of that highway the result was unusable.
So I selected nine segments which covered the same part of the road with a length of 19 kilometres. The duration of the calculation with some seconds was satisfying short. The result itself is not to my liking. Though it is in most parts quite usable I will draw a better way by hand.
Conclusion: Most likely won’t use this script in the future. It is not much advantage from drawing some kilometers of a way to checking and fixing a calculated one over its complete length before uploading.
Used scripts:
gpxsplt *cough*
2csv
2gpx
(Sorry for the big screenshots, but all for the best visualisation :) The yellow line is the averaged track.)
“faulty” length: about 500m
“faulty” length: about 1200m
Discussion
Comment from z-dude on 30 October 2012 at 22:04
It looks like averaging tracks based on what your eyes see is likely a better solution. When I average tracks by hand, I tend to go with the points where two tracks intersect.
Looking at your graphs, the algorithm needs some work.
Comment from malenki on 30 October 2012 at 23:21
I posted only screenshots of the two really bad parts of the averaged way. The rest of it is acceptable. The data is linked above that everybody can have a look on his own :)
Comment from malenki on 30 October 2012 at 23:38
PS: I added the length of the complete way (19 km), the length of the faulty parts total 1700m) and a link.
Comment from Baloo Uriza on 2 November 2012 at 00:46
This could make an interesting JOSM plugin
Comment from Mappo on 6 November 2012 at 13:52
Surely there must be a bug causing this? It shouldn’t really be possible for an “average” to wander outside the values like shown in these diagrams.
Or even multiple bugs,
e.g. sometimes the average seems to “cut” the corners, with two widely spaced points, even though there seems to be multiple points between them that describe a smooth curve.
Okay, I don’t speak R, but after a glance at the github source I’d guess the reason for there being occasional problems like this is that one of the original tracks is chosen as the master track, based on which one has the most points. But those points are not equally spaced so the accuracy of the results varies with that single GPX track’s point spacing.
It doesn’t explain the offset seen in the second image, but it seems much more likely for that to be a silly bug too, rather than a fundamental problem with the idea of averaging tracks together.
Comment from malenki on 6 November 2012 at 15:54
@ Mappo: I don’t speak R neither. I just blogged this as addition the the previous entry and to give people a look a the results without having to set up that stuff on their own. Of course I am a little disappointed after having had the work I can’t use the result.