[OSM-dev] Proposal: Make relations ordered
gravitystorm at gmail.com
Mon Mar 17 11:32:20 GMT 2008
On Mon, Mar 17, 2008 at 11:02 AM, Richard Fairhurst
<richard at systemed.net> wrote:
> Jo wrote:
> > OK, fair enough. I hope JOSM and Potlatch get around to implementing it
> > sooner rather than later then. It's rather annoying to carefully define
> > a route relation, knowing that it can be blown apart by people who
> > remerge the parts or split them in other ways. I tested this and it
> > gives undesired results at the moment.
> To be honest the thought of relations getting ordering fills me with
> dread. Potlatch is only just about to get relations support (thanks
> entirely to Dave Stubbs) in 0.8; the thought of having to redesign it
> and add a load of crap to handle splitting/merging/whatever doesn't
> exactly fill me with joy.
> Plus there's a more general worry that with this, and with layers, and
> whatnot, we're moving away from "simple is good" to "let's have a
> super complex data model that covers all eventualities".
Hear, hear. We haven't even scratched the surface of what is possible
with relations as-are. And I too worry that one of the major reasons
that OSM took off was that it was simple, even if some thought it
crude. I got completely frustrated when I used JOSM for the first time
in a long time last weekend (and I'm not exactly a newbie :-) ) so I
worry that the stuff we do to make our ultra-mappers' lives easier may
be having a poor impact on the learning curve for newbies.
> AIUI the problem you mention above is nothing at all to do with
> ordering. It's because the editors don't make it sufficiently explicit
> what is part of a route relation, and what isn't. If the editor
> highlights such routes in a different colour (as Dave's excellent code
> for Potlatch does) then users will _see_ when they split or merge
> wrongly, and modify their behaviour accordingly.
Looking forward to this when it happens (I have, of course, been party
to sneak previews) but I think again it'll show how few parts of our
toolchain handle relations. Or at least, how many of them use only one
tool in the relations Swiss-Army knife (e.g. multipolygons) but not
others (e.g. routes, or street-relations).
> Similarly I don't see why Frederik's initial ribbon-like loop
> needs to be solved by ordering. One of the most frequently cited use
> cases for relations is turn restrictions. Surely this is nothing more
> than a non-mandatory turn restriction?
I don't understand what problem it's trying to solve, but maybe that's
because I'm missing something to do with routing. I would have thought
that there's plenty of scope within relations (and even nested
relations) without putting constraints on the ordering of the members.
Take this route relation:
There's no roles defined for any of the members, so 1,2,3,4 could be
added to a section which needs explicit ordering.
PS Is it bad XML-foo to assume the child nodes are ordered? I wouldn't
expect an implicit ordering myself, but I'm no XML expert.
> dev mailing list
> dev at openstreetmap.org
More information about the dev