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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
