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?
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
