[Openstreetmap-dev] Streets in GPX

SteveC steve at asklater.com
Sun Sep 25 00:09:54 BST 2005


* @ 23/09/05 12:36:35 PM immanuel.scholz at gmx.de wrote:
> > The other thing is that segments can belong to multiple streets. So
> > multiple segments can belong to 'baker street' but they can also belong
> > to 'Bus number 13's route'.
> 
> They can't in GPX. You have to repeat the data of a track segment, if
> listed in two different tracks. You may give it the same id, but to get
> legal gpx data, you have still to repeat the data :-(

Sure, I'm happy repeating the data.

gpx is just a convenient representation for some things. For others, as
we can see, it's pretty useless.

> > If it's XML, I don't care how it's represented. It's easy enough to
> > tranform it or modify all the code to use some other schema.
> 
> If it's only syntactic sugar, of course.
> But as you can see in my example above, conversion of data can be
> restricted by time consuming algorithms.
> 
> And you don't want a server which has to do a O(n^2) or even O(n*log(n)) -
> Operation of all nodes on every request!
> 
> 
> 
> >> in my opinion the current representation for nodes in data transfers
> >> might give some problems with floating point comparisons
> >> (the old XMLRPC interface gives every node a unique nodeid,
> >> while the GPX interface represents nodes as float LAT/LON)
> >
> > No it doesn't, the nodeid is in there.
> 
> Nope. Not in the track segments. Numbers only possible for tracks (without
> extensions).

Oh.. you mean in the gpx spec, rather than what the OSM server is
currently spitting out?

* @ 23/09/05 03:09:02 PM nick at hogweed.org wrote:
> > Before I dive in, my take on streets:
> >
> > Street segments connect two nodes, and have an implicit direction in
> > which node is first and which is last.
> >
> > By making streets a list of segments you can do cool things like have
> > non-connected streets. I'm desperately trying to think of an example
> > where this is useful, but I'm sure that there must be one.
> >
> > The other thing is that segments can belong to multiple streets. So
> > multiple segments can belong to 'baker street' but they can also belong
> > to 'Bus number 13's route'.
> 
> I see what you mean about this. However, could this also be done by 
> representing bus routes (or routes calculated by route-planners) as a list of 
> streets and nodes? e.g.
> 
> Bus 219 route
> StreetID     Startnode Endnode
> 286            50             63
> 287            1               3
> 90281       12             1
> 2131          54             42
> etc?
> 
> If the streets were edited, the node numbers would have to be updated, but 
> that would presumably also be the case if segments were edited too?

I don't quite get what you're driving at here?

> I tend to agree with Imi that streets are best represented as n-node segments; 
> maybe space doesn't matter too much (gzip the GPX) but parsing would be 
> rather more awkward; I find it more elegant to describe bus routes according 
> to the scheme above.

Yeah... but I wasn't thinking of giving anything much different when you
call the API... a street is a list of segments which have nodes, as
you've shown.

Am I missing something?

* @ 23/09/05 02:34:28 PM immanuel.scholz at gmx.de wrote:
> Note anyway, that I would prefer Steve's idea of a segment only connecting
> two nodes and composing of a street as a list of 2-node-segments. This
> implies to me, that we don't use GPX as primary transfer mechanism or at
> least, that the GPX-export from the server will be a strange GPX with
> every track segment consisting of only 2 nodes (and the list of these
> segments are unordered).

Yes, GPX is starting to look a bit silly.

> Even the "streets with gaps" scenario does not necessitate the two-point 
> segments; for example (as I said in another message) the A34 has a gap 
> between Oxford and Birmingham; it could be treated as two segments each of 
> many points.

segments of two nodes and then streets of multiple segments is just the
simplest way to program and think about the things, I think. The SQL for
arbitraryly long multi-point lines is horrible - when thinking about all
this, remember that you have to put some effort in to make sure you get
the most recent data as nothing is deleted from the database, it just
gets old because we're wiking things.


have fun,

SteveC steve at asklater.com http://www.asklater.com/steve/




More information about the dev mailing list