[OSM-newbies] How to map routes
Germán Buela
gbuela at gmail.com
Sat Jul 26 17:56:40 BST 2008
Dave, thanks for the long reply.
I will start working once the localisation problem is solved, to see
how it goes.
On 25/07/2008, Dave Stubbs <osm.list at randomjunk.co.uk> wrote:
> 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
> _______________________________________________
> newbies mailing list
> newbies at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/newbies
>
More information about the newbies
mailing list