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 <[EMAIL PROTECTED]> wrote: > On Fri, Jul 25, 2008 at 12:19 AM, Germán Buela <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/newbies > _______________________________________________ newbies mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/newbies
