[OSM-talk] A proposal to improve relation handling

Nathan Edgars II neroute2 at gmail.com
Tue Aug 23 05:53:21 BST 2011


I and some other mappers have noticed that relations are more prone to 
breaking than equivalent tags on ways.
(For a simple example, imagine two people simultaneously editing 
different parts of a route and each splitting a way, e.g. to add a 
maxspeed to a portion. If the route is stored as a relation, the second 
one to upload will get a conflict, and relation member conflicts are 
rather difficult to resolve. On the other hand, if the route is stored 
as ref tags on the ways, no conflict will result.)

Another problem is that relations are harder for new mappers to work 
with than tags. If you want to say that a way is part of Vermont Route 9 
with tags, you simply add ref=VT 9. But if you want to use a relation, 
you first need to find the relation ID or a way that already has it, 
then add the way to it.

I am going to propose improvements to the API and to editing software 
that will make relations easier to work with and less prone to breakage. 
(Note that I am not a coder and the rather rude response to 'write a 
patch' will get you nowhere.)

;API changes
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). 
Similarly, if one person only changes the tags and the other the 
members, do not throw a conflict. (This sort of thing could also help 
minimize conflicts on ways.)
2. Treat relation membership as a characteristic of the members. Each 
revision of each member includes a separate field that stores what 
relations it is a part of. When an object is downloaded, the list of 
relation IDs it is a part of is included (and perhaps so is the type of 
relation - route, multipolygon, etc. - this needs more thought). On 
uploading a change in membership, the editor will send this field (if 
nothing else is changed, the other tags do not need to be uploaded) and 
a conflict can occur on this field. Perhaps, for backwards 
compatibility, a relation change can be uploaded without this field, but 
it will always 'lose' a conflict even if saved before a change that 
contains the field.

;Editor changes
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. 
Perhaps use the field from API change 2 to improve the process.
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, and with three columns instead of two (e.g. network, 
ref, role). Make the process of adding an object to a relation 
essentially the same as that of adding a tag. For example, the following 
could be the method in which a way is added to the relation for Vermont 
Route 9 with role east (the relation will have tags network=US:VT and 
ref=9):
*Select the way.
*Click the same button or press the same key as when adding a normal tag.
*Fill in the first field as US:VT. (Perhaps the editor realizes that 
this is a relation network, but more likely a box will have to be 
checked that a relation is being used, absent a regional plugin that 
will recognize certain networks.)
*Fill in the second field as 9.
*A third field will appear; fill in east.
*Now the editor finds a relation with network=US:VT ref=9. If none is 
loaded, a new type of API call will be made to find it. If none is 
found, a new one will be created.
It's possible that this will need regional presets to work properly.
3. Change uploading to comply with API change 2.

Editor change 2 is most important for making relations easier to work 
with. The other changes are important for making conflicts less frequent 
and easier to handle when they do appear.

Any comments?



More information about the talk mailing list