[OSM-talk] A proposal to improve relation handling
Frederik Ramm
frederik at remote.org
Tue Aug 23 09:26:20 BST 2011
Hi,
On 08/23/11 06:53, Nathan Edgars II wrote:
> (Note that I am not a coder and the rather rude response to 'write a
> patch' will get you nowhere.)
If you cannot write code yourself, there's always the option of finding
someone else who does it for you ;)
> 1. Handle conflicts better. Treat the relation members as a
> comma-separated list, and apply each diff independently (this would
> probably need some checking that they are not too close to each other).
I believe Matt has some ideas about incrementally editing objects for
API 0.7. This would not be relation specific and certainly not about
"comma separated lists" but might go a little way in your direction.
> 2. Treat relation membership as a characteristic of the members.
I do not think this is a good idea. It seems conceptually wrong to me.
If the public transit authority creates a new bus route, does that
really change all the roads along which the bus runs? Is the road any
different on the ground the day after the bus route has been introduced?
> 1. Handle conflicts better. If a conflict still happens, make it easier
> to see what members are added or removed without caring about the order.
Handle conflicts better is always good ;) however it seems to me that
you should broaden your view a bit as to the different types of
relations that exist; there's much more than route relations which seem
to be the focus of your ideas.
> 2. Treat relation membership as a characteristic of the members. Put the
> relation among the other tags with only a minor notation that it is not
> a standard tag,
I think Potlatch2 goes in that direction. Have you tried it? I don't
think all editors should necessarily be the same - if Potlatch2 presents
things in a way that you like, there's no need to make all other editors
to do the same I'd say.
> *A third field will appear; fill in east.
I never quite understood this directional role business. Seems to be an
US specialism?
Bye
Frederik
More information about the talk
mailing list