On Mon, Mar 17, 2008 at 11:02 AM, Richard Fairhurst <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev > _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
