Erst mal Danke an alle für prompte Antwort! Tobias Knerr schrieb: > Hallo, > > Relationen sind für so etwas nicht üblich. Wenn aufgrund der Situation > in der Realität eine namentliche Zugehörigkeit zur Kernstraße gegeben > ist (hier gibt es natürlich manchmal Interpretationsspielraum, ich kenne > den konkreten Fall nicht), dann einfach auch dort das entsprechende > name-Tag setzen. > OK, Name-Tag kann wohl nicht schaden, ich werde es wohl ein bisschen situationsabhängig gestalten (sprich von der Größe der Stichstraße und der erforderlichen Eindeutigkeit, so wie es Markus vorschlägt). >> 2. bei den Hausnummern habe ich natürlich mal versucht mir etwas in >> Karlsruhe abzukucken ... > > Man kann es machen - ob es sinnvoll ist, ist Ansichtssache. Notwendige > Information ist allein die Nummer, und aus praktischen Gründen > (eindeutige Zuordnung etwa von Eckhäusern) ist zusätzlich zur Nummer ein > Bezug zur Straße empfehlenswert, üblicherweise über addr:street. Das scheint mir sinnvoll. > > Orte und Postleitzahlen sind hingegen prinzipiell über Grenz-Polygone > ableitbar. Wenn man auf diese Weise auch an die Daten kommt, ist eine > Angabe am jeweiligen Haus nicht wirklich erforderlich. > Wie stelle ich denn fest, dass zu einem Grenz-Polygon eine Postleitzahl gesetzt wurde? Gibt es dazu eine systematische Vorgehensweise, oder andersrum gefragt: Ortsteile können selten von unser einem klar in ihren Grenzen erkannt werden (man kann vielleicht das Zentrum feststellen). Man hätte also schon 2 verschiedene Polygone für Ortsteil und Postleitzahl. Gibt es das überhaupt? Zumindest ist mir auf der Hardhöhe nichts dergleichen ins Gesicht gesprungen. >> 2. oder gibt es da eventuell einen hierarchischen Ansatz mit >> Relationen? > > Gerade hierarchische Relationen lassen sich mit den üblichen Editoren > schwierig bearbeiten, wohingegen Funktionen zum Kopieren von Tags und > zum Auswählen und Taggen aller Objekte mit bestimmten Eigenschaften in > Editoren recht etabliert sind. Dazu kommen noch weitere Probleme von > Relationen - namentlich Bearbeitungskonflikte -, die man sich mit Tags > oder Grenz-Polygonen erspart. Normalerweise wird in solchen Fällen > einfacher Handhabbarkeit der Vorzug gegeben. > Das was ich gerade zu diesem hierarchischen Ansatz mit Relationen im Wiki gesehen habe (basierend auf RFC 4119 Tags) erscheint mir zwar "formal" sehr reizvoll, aber wehe da wollen mehrere Leute gleichzeitig an solchen Beziehungen arbeiten, die id<->ref Beziehungen werden wohl recht schnell zerbrechen. Da kann man ja mal bei einem nächsten NEF Treffen drüber philosophieren. Da gibt es auch noch andere Dinge in den Tag-Formaten, die mir sehr abenteuerlich anmuten (was Zerbrechlichkeit angeht).
Danke für die ausführlichen Erläuterungen, bringt mich alles schon ein bisschen weiter, Georges _______________________________________________ Franken mailing list Franken@lists.openstreetmap.de http://lists.openstreetmap.de/mailman/listinfo/franken
