On Mon, Mar 17, 2008 at 6:34 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote: > Hi, > > > > Surely one of the unwritten guiding principles of OSM is "don't make > > things complicated just to cater for a few edge cases"? > > Allowing an order in relations would not make things more complicated > for the user, only for the writers of editors ;-) > > There will always be certain advanced features that are so difficult > to support in Potlatch's easy "dear user you don't have to care be > cause we do it for you" interface. Which is perfectly ok. Potlatch > doesn't *have* to support everything. But "it's difficult to build > into Potlatch" must not become a reason against a new development... >
No, but the argument is actually that if it's too complicated for potlatch then it's too complicated full-stop. If only experts end up being able to do something then in general it won't get done. That might be OK for the bits where there are experts, but most areas on our map have never had an expert anywhere near them. We want cyclists, walkers, business owners etc mapping, not computer geeks, and frankly JOSM has very low usability these days if you don't know exactly what you're trying to do already and have enough spare fingers handy. Ofcourse making relations ordered arguably isn't really that complicated, and in itself it isn't, except that relations are already extremely complicated for the average user. The more levels of indirection and rules we add the worse it gets and the steeper the learning curve becomes. And having a mixed set of editors, ones that support ordering, and ones that don't, are likely to cause more confusion. I think the fact that some relations would then be considered to be order important, and others not would also cause confusion. So then the question becomes: is the alternative actually /more/ complicated, but I'll leave that as an exercise for the reader ;-) Dave _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
