[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