[OSM-dev] Problems with editor diversity (was: 0.6 API)

[Frederik Ramm]

Hi,

I wrote:
>> We have enough trouble as it is with the small number of editors we
>> have. I'm all for diversity and user choice but I'm prepared to  
>> accept
>> limits to diversity where it seems sensible to me, and this is a  
>> point
>> where it seems sensible.

Bart wrote:
>
> What difficulty specifically are you thinking off?

Before I start, let me reiterate that in general I like diversity. So  
this is not a plea to go back to having the one true editor.

But one big problem I see is relations. We currently have support for  
simple relations in our editors. Or better, "simple support for  
relations". Many more complex relations are being discussed and are  
in fact starting to appear. A big issue that we will soon have to  
give some attention is turn restrictions, so let me use that as an  
example.

A turn restriction relation is encumbered in a lot of logic.  
Generally (from the API viewpoint) a relation could have any number  
of members, in any roles. Only a tiny subset of possible relations  
are actually valid turn restriction relations: They must contain two  
ways in certain roles and one node, and that node must be an and  
point to both of the ways. (Or something like that.) Interestingly,  
it is possible to break the integrity of a turn restriction relation  
without changing the relation object and without violating  
referential integrity.

But there's more, there are also processing rules: When a way is  
split and it is part of a turn restriction relation, then the half of  
the way that connects to the junction node must continue to be part  
of the relation, and the other part must be removed from (or not  
included in) the relation. (This is wholly different from, say, a  
route relation where *both* parts must be included.)

All this has to be coded in every single editor, and it is very  
likely that some will do things differently. There is of course some  
degree of freedom in how you let the user interact with such a  
relation, but there is no freedom in how to deal with splitting a way  
that's part of a turn restriction relation - there is only "one true  
way" to do it.

And this is one example where I would, if I could, limit diversity  
and make sure every editor produces the same kinds of relations with  
the same restrictions. (They may produce any kind of relation they  
want, but if they produce a turn restriction, I'd wish they'd all  
adhere to the same logic in dealing with it.)

It is not unsolvable of course; we (editor developers) could agree on  
some kind of XML control file that we read from a wiki page and that  
dictates how we deal with relations.

But I believe as OSM and the data contained become more complex,  
we'll see a lot of "rules" like what I described above, where it  
really only makes sense to do it in one specific way, and if  
different editors do it differently then (worst case) data created by  
users of editor A is poorly visible/editable for users of editor B  
and vice versa, leading people to break other people's work and  
creating tensions within the community.

I think that the topic of rollbacks and changesets offers similar  
potential for editors to do things differently not in a "diversity is  
good" way but in a "what the hell has this guy done" way, and thus  
would like to limit options on the API. Maybe I'm too pessimistic or  
too much of a control freak. I am not normally ;-)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"