[OSM-talk] is_in

[Frederik Ramm]

Hi,

> is_in has the potential to be a very useful source of relationship  
> data.

Let's put it that way: Relationship data would be very useful ;-)

The "isin" you propose is the best that can be done inside the OSM  
database at the moment, but of course it is just a meek imitation of  
what real object relationships could give us.

What you really want is to create a relationship between the object  
representing (say) a suburb and the object representing (say) a town.  
What you do with "isin" is creating relationships between names of  
objects. If someone has a typo somewhere (or uses different names -  
you pointed out the language problem), then your whole hierarchy  
breaks. The name of a town is duplicated in each of the isin tags of  
its suburb, and changing the name of the town breaks the  
relationships. Unlikely, but still ugly.

Also, your relationships are not unique because names are not unique.  
A suburb carrying "isin=city:Perth" can be in Scotland or in New  
South Wales, and nobody will want to name one city "Perth (Scotland)"  
and the other "Perth (NSW)".

What's more, the larger your "parent" objects get the less likely it  
is to see them in OSM because we do not have the option of creating  
location-less objects - and where to put the node for "nation=England"?


Honestly I don't really see what is gained by having this data *in*  
OSM at all. In other situations I have said that I want data in OSM  
because it is then editable; but in this case, it is very difficult  
to extract the actual structure tree (you cannot click a town in your  
editor and see the suburb nodes highlighted... well... it *could* be  
done but would only ever work for smaller areas), and modifying the  
whole structure tree is even more complex. You can modify the "isin"  
of a suburb here and there, but to systematically find anything else  
in order to change it would be a challenge suitable only for planet  
file hackers.

Also, such "structure trees" are availble in good quality from free  
sources already (e.g. geonames - who have been criticised on the  
grounds of using Google to derive co-ordinates but we wouldn't have  
to use co-ordinates for what we want to do).

Is it wise to re-invent the wheel here?

I think I'd opt for having this kind of data in a text file, or web  
service or so. Can't see how having it in the planet file helps.


And a much less fundamental ciritcism:
> isin:city=Cambridge  // applied to suburbs, for example
> isin:district=South Cambridgeshire
> isin:county=Cambridgeshire
> isin:nation=England
> isin:country=Deutschland
> isin:state=Texas

Some of these elements are probably universal (suburbs and cities).  
But the whole sub-country layer - states, counties, districts,  
nations - is quite different among countries, and trying to bring  
e.g. the German, French or US structures in one line is going to be  
very difficult and error-prone (as there is no official 1:1 relation,  
everybody will do as he/she sees fit, and you'll have the same entity  
named a county here and a district there). You would really have to  
qualify your entities, saying which structuring system you intend to  
use:

is_in:uk_county
is_in:de_regierungsbezirk
is_in:fr_departement

or so.

(Geonames.org has solved this by speaking only of "administrative  
divisions" of a certain order.)

> Languages are solved too by using isin only in local language

I am no expert on this but does each place have exactly one  
undisputed local language, or are there "OSM edit wars" looming?


Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'