[OSM-newbies] How to map routes

Dave Stubbs osm.list at randomjunk.co.uk
Fri Jul 25 09:19:42 BST 2008


On Fri, Jul 25, 2008 at 12:19 AM, Germán Buela <gbuela at gmail.com> wrote:
> OK guys... I suppose routes were not seriously considered in the
> original design and now we have these different approaches. I was
> looking for a platform on which we could save bus routes from users
> knowledge, solving once and forever the problems of inaccurate or
> outdated guides and websites that are painful to use (that's the case
> of my hometown which has a complex bus network). A mashup with OSM
> sounds like a good idea. But I find the official approach a bit
> disappointing. It feels totally wrong to have to split physical
> entities (like streets, roads...) into arbitrary segments to
> accomodate for routes, and then we can't make sure the segments keep
> the same tags because they're independent entities. Given the current
> model, there is an approach that feels to me far more natural for
> routes, not mentioned at least in this thread: why not make them a
> relation of NODES (usually intersections)? From A to B, B to C, C to
> D... no need for overlapping ways, no need to split ways. And it
> should be possible for an application to "describe" the route in terms
> of ways, because the line A-B most likely goes along one particular
> way. Could this work? Am I missing something important?
> Sorry to bring this up here, I'm a newbie after all :) and I would
> like read what you think about it.


I wouldn't do that, mostly because what you've described there is
basically a way -- you might as well use ways to achieve the same
thing.

Nothing was really considered in the original design because I think
the original design had nodes, and then segments a bit later, and then
ways, and then dropped segments and included relations... I'm sure you
see how this is going. OSM has been designed to be the simplest thing
that works, and only add extensions when they become needed.
There's not really any such thing as an "official" approach -- there's
just a general consensus about how things are being added. The
consensus on routes seems to be to split ways. I think this has come
about for various reasons...
1) editor support for overlapping ways has been really bad (lots of
modifier keys and then hidden ways you never realised were there).
2) describing routes becomes harder as you have to piece together ways
& nodes and build reverse lookup tables to do it (ie: what ways is
node X a part of). Also this becomes much harder if you already have
two ways overlapping, for instance, consider a double-deck bridge with
a cycle route, which deck is the route for? I'm sure there are other
marginal cases too.
3) it seems more logical to say that if a route goes down road XYZ,
then road XYZ should be part of the route. It also facilitates queries
such as "what routes go down road XYZ?".
4) splitting things really isn't so much of a problem as you might
think, as long as things aren't being hidden in the editor (by
overlapping ways etc). We already have to split for bridges, surface
changes, number of lanes changes, and many other variables. If some
property needs altering then the editors make it fairly obvious that
you haven't selected the whole thing, and let you investigate what's
going on.

The most important aspect of the way splitting method to take into
account is that it is already being used very successfully. The
database already has thousands of kilometres of cycle routes and bus
routes entered using this method, and loads of walking routes going in
as well.

Dave


More information about the newbies mailing list