[OSM-talk] Track2osm?

Jon Burgess jburgess777 at googlemail.com
Mon Mar 26 23:35:18 BST 2007

On Sun, 2007-03-25 at 06:56 +0200, Joerg wrote:
> Am Samstag, 24. März 2007 00:28 schrieb Jon Burgess:
> > On Fri, 2007-03-23 at 23:23 +0000, Jon Burgess wrote:
> > > On Fri, 2007-03-23 at 23:54 +0100, Andreas Volz wrote:
> > > > Hello,
> > > >
> > > > does someone know Tack2osm? I found many broken ways that are created
> > > > by Track2osm. I'm very frustrated to repair these ways.
> > >
> > > svn.openstreetmap.org/utils/perl/Geo/OSM/Tracks2OSM.pm
> >
> > utils/osmfilter/osmfilter.pl uses this library to upload tracks so it is
> > likely this is the program generating this data. If you could point out
> > some examples on the map (URL + ID) and what problem it has then someone
> > may be able to improve the script.
> Yes it is ( one of ) the scripts using it. And please do point out where there 
> are problems. Maybe you do have a suggestion on how to improve it in these 
> parts too.

The main issue i've found in the script is that {dist} is measured in
metres whereas a number of comments in the file hint that this should be
in km's. Adding a few *1000 & /1000 in a few places fixes that. It looks
like maybe you changed interface from km to m at some point and didn't
update all the {dist} references to use m. For me this change makes it
output reasonable looking ways for some test gpx files.

I had a look through the script and I can not see anything in it which
would mangle a single track into lots of different directions as seen by
the example posted in an earlier email in this thread. Perhaps the
original track data was not in a nice sequential order. I guess the only
way to know would be to locate the original uploader and his track file
(perhaps this issue is inherent in some input formats other than GPX).

The only other thing which looks a bit wrong is that a single GPX
covering one road twice causes that road to be output twice in the OSM.
The filtering against OSM data only applies to the loaded OSM data, IMO
when adding new nodes and segments it should consider the previous track
nodes and segments too (right now it only looks for a precise lat/lon
match in previous track points).


More information about the talk mailing list