[OSM-dev] Proposal: Make relations ordered

Dave Stubbs osm.list at randomjunk.co.uk
Mon Mar 17 20:23:22 GMT 2008

On Mon, Mar 17, 2008 at 6:34 PM, Frederik Ramm <frederik at remote.org> 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

So then the question becomes: is the alternative actually /more/
complicated, but I'll leave that as an exercise for the reader ;-)


More information about the dev mailing list