[OSM-dev] Proposal: Make relations ordered

[Andy Allan]

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
>  (http://lists.openstreetmap.org/pipermail/dev/2008-March/009389.html)
>  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:
http://www.openstreetmap.org/api/0.5/relation/2204
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.

Cheers,
Andy

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.

>  cheers
>  Richard
>
>
>
>
>  _______________________________________________
>  dev mailing list
>  dev at openstreetmap.org
>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>