[OSM-dev] Boundary data

[Roland Olbricht]

> > In detail, there are
> > a) the "left:country" and "right:country" attributes in the boundary
> > ways. b) the nodes with tag k="place" v="country" which contain more
> > information on a country.
>
> I don't see problems with both issues above. Everything in our db is
> sensitive to typos, so why is this more of a problem here? If the info
> is only partially present, it should be extended.

The situation is quite similar to the situation with road numbering. First, a 
very common query would be to get the boundary of an entire country, city or 
whatever. If this information is encoded in a relation, this is a 
straightforward query and directly supported by the API. If this information 
is coded as tags in the respective ways, you have to either query every way 
in the database for the particular attribute or you have to keep a 
specialised index. Note that the latter would contain exactly the same 
information as the respective relation does. Anyway, the API doesn't support 
a query for it.

Furthermore, if you accidentally try to delete a way which is part of the 
border of something, the database will protect the way if it is part of a 
relation - you have to deliberately also delete its entry in the relation. 
There is no protection without the relation - you could just silently leave a 
gap in the border.

The same thing with a new way: if you add it to a relation, there will be 
exactly one relation per country - no ambiguity, you safely choose the right 
one. If you have it as an attribute, the database can't check whether you 
leave a typo or not. Below country level, it is not even assured that the key 
is written in an uniform way, one country might denote its next 
level "region", another might call it "land".

Or just from a generic point of view: its a n:n-relation between ways and 
geographical units, not a feature of a particular way, so it should be 
visible as a linked data structure in OSM.

Cheers,
Roland