[Talk-de] Hierachien

Frederik Ramm frederik at remote.org
Di Aug 7 16:34:01 UTC 2007


Hallo,

> Haben wir in OSM eine gute Möglichkeit, Daten hierarchisch zu ordnen?

Nein.

> Und zwar würde ich gerne eine Ordnung wie diese haben (am Beispiel
> Deutschland):
> - Ich habe eine Straße, die ist in einem Ort
> - Dieser Ort gehört zu einem Landkreis
> - Der Landkreis liegt in einem Bundesland
> - Das Bundesland gehört zu einem Land
> - Dieses Land liegt auf einem Kontinent

Hierzu muessten erst einmal Objekte erzeugt werden, die den  
Kontinent, das Land usw. repraesentieren. Dann waere wieder fraglich,  
welche Hierarchie-Ebenen man einbezieht; da hat ja auch jeder seine  
unterschiedlichen Vorstellungen - beispielsweise finde ich es immer  
wieder aufs neue bescheuert, wenn Programme amerikanischen Ursprungs  
bei der Adresseingabe nach meinem Bundesland fragen, das ist hier bei  
uns einfach unueblich.

> Denn in Navigationssystemen (oder Web-Routenplaner), welche OSM-Daten
> nutzen sollen, muss der Benutzer die Zieladresse genau angeben können:
> Also wählt er zuerst ein Land, dann einen Ort und dann die gewünschte
> Straße.

Diese Daten muessen allerdings nicht unbedingt in OpenStreetMap  
vorliegen. Es waere auch denkbar, einen externen Ort-Suchdienst (wie  
geonames.org oder so) einzubinden, der einem am Schluss einfach lat/ 
lon ausspuckt, und man routet dann so nah wie moeglich da hin,

> Ich weiß, dass es das "is_in"-Tag gibt, aber dort ist man sich  
> anscheinend
> nicht einaml über die Reihenfolge der Begriffe einig
> (http://wiki.openstreetmap.org/index.php/Placename_hierachies). Ein
> weiteres Problem sehe ich darin, dass es beim "is_in"-Tag keine
> Möglichkeit gibt, verschiedene Sprachvarianten zu berücksichtigen.  
> Wenn,
> wie im Beispiel auf der Wiki-Seite, "Denmark" mit
> "is_in=Europe,Scandinavia" finde ich es nicht, wenn ich nach z.b.
> "Skandinavien" suche.

Ausserdem waere die Information, dass sich Skandinavien in Europa  
befindet, auf diese Weise tausendfach redundant in der Datenbank.  
Wollen wir das?

> Optimal wäre meiner Meinung nach eine eindeutige Adressierung (am  
> Beispiel
> der Stadt Ettlingen):
> eu.de.bw.karlsruhe.ettlingen

OSM ist inhaerent strukturfeindlich. Eine solche Adressierung  
funktioniert nur, wenn sie zentral vorgegeben wird und sich alle dran  
halten. Das wird nicht passieren.

> Und mit einem passenden "parent"-tag könnte man diese Struktur elegant
> aufbauen:

Typische Programmierer-Kontrollfreak-Haltung - ich will alles  
organisieren, fuer alles Regeln aufstellen, damit ich das nachher mit  
meinen Programmen gut auslesen kann. Das geht allein schon deshalb  
nicht, weil es ein nicht zu bewaeltigender Aufwand waere, solche  
Strukturen jetzt gleich fuer die ganze Welt bereitzustellen, und wenn  
man es nicht tut, dann gibt es Salat.

> Die "Rheinstraße" in Ettlingen wird dann mit
> "parent=eu.de.bw.karlsruhe.ettlingen" getaggt

Was ist mit Stadtteilen?

> die Stadt selbst mit
> "parent=eu.de.bw.karlsruhe", der Landkreis Karlsruhe sowie die Stadt
> Karlsruhe mit "parent=eu.de.bw"

Was is mit dem Regierungsbezirk?

Und wieso ueberhaupt brauchst Du ein parent-Tag, wenn doch an allem  
die Geo-Koordinaten dranhaengen? Wenn ich weiss, welchen Umriss  
Deutschland hat, kann ich doch programmatisch entscheiden, ob ein  
Punkt drin liegt oder nicht.

Also meiner Meinung nach ist das is_in-Tag voellig ungeeignet, um  
eine Struktur abzubilden; es taugt hoechstens fuer "Hints", die man  
bei mehreren gleichnamigen Staedten vergeben kann. Aber Dein  
Vorschlag ist auch keine Loesung, weil Du niemals eine konsistente  
Struktur hinbekommst, weder entworfen noch eingehalten, und weil die  
Formulierung der richtigen parent-Tags ein Haufen Arbeit waere, und  
weil Du Dir auch nicht ueberlegt hast, wie Du denn Objekte wie z.B.  
den Landkreis Karlsruhe abbilden willst.

Ich denke, im Augenblick ist es am besten, das Problem ungeloest zu  
lassen, und fuer Routing-Applikationen usw. auf Such-Anwendungen  
Dritter zurueckzugreifen. Es muss ja auch nicht unbedingt ALLES in  
OpenStreetMap drin sein. Dafuer, abstrakte Dinge wie Laender und ihre  
verschiedenen administrativen Gliederungsebenen sinnvoll zu speichern  
und benutzerfreundlich zu editieren, sind unsere Programme nicht  
geeignet.

Bye
Frederik

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






Mehr Informationen über die Mailingliste Talk-de