[OSM-dev] Boundary data
roland.olbricht at gmx.de
Fri Oct 31 07:31:22 GMT 2008
> > 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.
More information about the dev