> Man koennte sowas auch mittelfristig fuer OSM entwickeln. Ich arbeite > gerade daran, dass wir im OSM-Datenmodell Beziehungen zwischen Objekten > abbilden koennen und auch "abstrakte" Dinge wie z.B. einen Landkreis > oder eine Behoerde. Aber die uebersichtliche Verwaltung solcher > Strukturinformationen sprengt den Rahmen dessen, was wir im Moment haben > - da will man ja dann auch huebsche Baumdarstellungen haben, Ebenen > einfuegen, aufklappen, kollabieren, und weiss der Teufel noch was. Eine > solche Struktur warten zu wollen, indem man Abermillionen von > "parent"-Tags ueber die existiernden Objekte ergiesst, halte ich fuer > Wahnsinn.
Ich muss dir im Bezug auf die Anzahl der erforderlichen "parent"-Tags und deren enthaltenen Redundanzen recht geben -- der Tag sollte auch nur ein Denkanstoß geben, sich mal über die Problematik gedanken zu machen. Ein Datensatz mit vielen Straßen, von denen ich aber nicht weiß, ob sich die "Hauptstraße" in Ort A oder dessen Nachbarort B befindet (und da kann es schon Probleme mit der von dir vorgeschlagenen Umkreissuche geben), ist in meinen Augen leider nur halb soviel wert. Dementsprechend halte ich es für falsch, das Problem zu ignorieren. Denn je mehr Datensätze hinzukommen, desto schwieriger wird die Situation. Ich halte deinen Vorschlag, dafür einen externen Dienst einzusetzen, für deutlich besser, als noch mehr Tags einzuführen. Aber auch hier sollte man sich Gedanken über eine brauchbare Verknüpfung der beiden Dienste machen. -- Wabba _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
