Keine Ahnung, ob das schon irgendwo andiskutiert wird, ich hab’s jedenfalls nirgends gefunden:
Wäre es nicht sinnvoll, für jede Ortschaft eine Relation zu erstellen, in die alles innerhalb der Ortschaft zusammengefasst ist (Straßen, Adressen, POIs, Grenzen, …)?
Die Vorteile, die ich sehe:
Ist eine Zuordnung von Straßen zur Ortschaft im Moment nur bedingt möglich. Bei nahe aneinanderliegenden Ortschaften werden manchmal die Straßen zum falschen Ort gezählt (Beispiel: routingfähige Karten von computerteddy, hier gehören ein paar Straßen in Heilbronn angeblich zu Flein). Ich nehme an da wird einfach geschaut, welcher Orts-Knoten am nächsten liegt. Mit einer Relation wäre das nicht passiert.
Beim Routing zu einer Stadt, also ohne Straßenangabe, führen die Router im Moment an den Punkt, an dem der Ortsname getaggt ist. Das kann an einem beliebigen Punkt innerhalb der Ortschaft sein. Schöner wäre es, wenn die Router einen, so wie es auch kommerzielle Router machen, an den Ortsanfang führen würden. Mit einer Relation könnte diese recht einfach abgefragt werden (Nach dem Motto: “Route mich zum ersten Punkt der Relation xy auf einer Hauptstraße” oder so ähnlich)
Nachteile fallen mir grade keine ein, aber deshalb frag ich ja
Irgendeinen Grund muss es ja geben, wieso das nicht so gemacht wird.
Denkbar wäre doch auch addr:city dafür weiter zu benutzen.
Aber als Relation fände ich das auch gut, weil man
sich das im Gegensatz zu addr:city im Analyzer anzeigen lassen kann.
Klar, addr:city wäre auch eine Idee. Aber das muss dann jeder einzelner Node/Track zugewiesen werden. Und gerade für Attribute, die viele Nodes/Tracks gemeinsam haben, gibt es ja die Relations.
Wenn man die Geschichte weiterspinnt, müsste man dann auch jeder Node/Track einen is_in-Rattenschwanz mitgeben. Auch das könnte man in der Relation vereinheitlichen.
Sorry, wenn ich so dumm frag, aber in wiefern ist das einfacher? Eine Stadt- oder Gemarkungsgrenze ist nicht so einfach zu erfassen, es sein denn, man hat Zugriff auf die öffentlichen Daten, was in den wenigsten Fällen der Fall sein dürfte.
Klar, Grenzen müssen sein, da hast Du vollkommen recht. Aber für die auswertende Software wäre doch eine klare objektorientierte Struktur wesentlich einfacher auszuwerten.
Wenn man einfach die Stadtgrenze erfasst und die Auswerte-Software (ich schreibe bewusst nicht Renderer, weil da gibt’s noch mehr) dann aufgrund von Koordinaten mehr oder weniger raten muss, ob z.B. ein Wald jetzt inner- oder außerhalb dieser Grenzen liegt, wäre es doch einfacher, wenn die Software nur auf die Relation schauen muss.
Ich programmier halt seit über 10 Jahren objektorientiert und da denkt man halt irgendwann in Objekten und Klassen. Und eine Relation ist da das entsprechende Pendant dazu.
Prinzipiell fände ich eine konsequente Anwendung von Relationen auch sinnvoll und dadurch ließen sich viele Dinge vereinheitlichen. Momentan (soweit ich das bisher realisiert habe) scheint es kein einheitliches System zu geben. Und das betrifft nicht nur die Zuordnung von Objekten zu Ortschaften.
Ich bevorzuge (solang es keine Alternative gibt) ein area mit place=city o.ä. mit name-Tag und source=estimated. Ich schätze auf Grund meiner Ortskenntnisse die Ortsgrenze und damit sollten auch die darin befindlichen Objekte korrekt zugeordnet werden. So hoffe ich jedenfalls.
Schätzen ? Na ich weis nicht. Lasst und lieber zu Grenzgängen aufrufen, dass bringt die Leute an die Luft und jede Menge Spaß
Ne, im Ernst ich denke es wird nicht so einfach werden die Gemarkungsgrenzen zu bekommen. Der Vorschlag an sich ist mir jedoch sehr symphatisch.
Georg
Wäre nicht sinnvoll, da das
a) jede Grenze von maximalen Anzahlen an Elementen in einer Relation sprengt
b) diese gigantischen Relationen keiner runterladen kann
c) das ganze auch keiner pflegen kann und wird.
zu a) Ok, das wusste ich nicht, dass es Obergrenzen gibt. Wo liegen denn die?
zu b) Ob ich jetzt 10000 Einzelelemente runterlade, oder eine Relation mit 10000 Elementen, wo ist da der Unterschied? Und außerdem: Ich MUSS ja nicht zwingend über die Relation auf ein Element zugreifen.
zu c) In wiefern ist der Pflegeaufwand größer als ohne Relation? Gut, es ist ein Tag mehr, der gesetzt werden muss. Aber sonst?
Und wie ist es z.B. mit Aussiedlerhöfen? Bei uns gibt es z.B. einen Aussiedlerhof, der ist näher am Nachbarort. Hier muss zwingend eine Zugehörigkeit getaggt werden (is_in oder eben Relation).
Nicht an jeder Einfahrtsstraße ist ein Ortseingangsschild.
Wäre schlecht, wenn’s nicht so wäre. Aber in welcher Form kommt dieses Wissen in die Datenbank? Das ist doch die große Frage.
Nochmals zur Verdeutlichung:
Ich will hier nicht meine ach so tolle Idee durchdrücken. Ich möchte einfach nur mal das Für und Wider abwägen können. Aus dem Alter, in dem ich mit dem Kopf durch die Wand gerannt bin, bin ich mittlerweile raus.
Ich habe offen gestanden auch keine Ahnung, wie die OSM-Datenbank aufgebaut ist. Vielleicht spricht ja auch schon das gesamte Konzept, so wie Du sagst, gegen dieses Vorgehen. Aber dann erlaube ich mir die Frage, ob das DB-Konzept das richtige ist.
Die technische Obergrenze an Membern in einer Relation liegt bei 2000. Das reicht bei detailreichem Mapping bis maximal großes Dorf oder kleine Kleinstadt.
Der Erfassungsaufwand hat keinerlei Vorteil. Ob ich nun alles im Ort selektiere und in einem rutsch addr zuordne oder alles selektiere und in eine Relation mit mit addr packe. Das ist plus minus null. Genau wie der Pflegeaufwand. Es ist genauso schwierig Objekte ausfindig zu machen wo addr vergessen wurde, wie Objekte die nicht in in die Relation aufgenommen wurde. Eines ist aber sicher. Eine relation wird schneller fehlerhaft, als das es vorkommt, dass großflächig addr an allen Objekten verschwindet. Und da haben wir noch ein Problem. Die ganzen aufkeinemenden Relationsideen werden von keinem Programm ausgewertet. Tags allerdings schon.
Ich vergebe jede einzelene Adresse mit einem vollem Satz nach Karlsruher Schema. Jeder der bei mir nach einer konktreten Adresse sucht, wird so auch eindeutig fündig.
Na, das nenne ich doch mal eine fachmännische Auskunft!
Vielen Dank, Mirko, für die Klärung.
Wegen der Gemarkungsgrenzen hab ich übrigens mal ne nette Mail an unseren Herrn Bürgermeister geschrieben und gleichzeitig ein bisschen Webung für OSM gemacht. Mal schauen, ob was zurückkommt…
Genau das wäre eigtl. der Vorteil, denn so schnell wie sowas Fehlerhaft werden kann, kann der fehler auch wieder behoben werden. Wogegen eine falsche PLZ in einem von 10000 Häusern wohl kaum bemerkt wird und das Haus demnach wahrscheinlich auch nicht gefunden wird wenn man sich auf die dortigen Angaben verlässt.
Zeitlich habe ich da nichts gewonnen. Man kann nicht festellen was fehlt oder im Eimer ist. Relationen sind dafür zu dumm. Bleibt wieder nur regelmäßig alles selektieren und übernehmen und hoffen das man alles drin hat.
Relationen können derzeich nur eines. ZUsammenfassen und sortieren, das wars. Vererben, Logik, Selbstdiagnose. Alles Wunschträume und weit weg von einer Umsetzung.
Eine Fehlerhafte PLZ findet sich genauso schnell. Wenn ich alles selektiere muss mir der bei addr:postcode immer die entsprechende PLZ stehen. Steht dort , ist ein Fehler drin. Das zu beheben ist dann auch kein Akt. Einfach bei wieder die PLZ eintragen, speichern und hochladen. So hast du in 5 Sekunden alles mit einer PLZ. Das geht ebenfalls bei für das Gebiet globalen Werten wie addr:country und adrr:city.
Andere Fehler wie falsch geschriebene Straße oder Nummer muss man bei egal welcher Umsetzung händisch suchen. Es gibt keine Möglichkeit eine art Makro für die Fehlersuche einzubauen. Hier hilft nur die Überwachung des eigenen Gebietes. Nach jeder Änderung müssen aktuell geänderte und fehleranfällige Objekte gesichtet werden.
Um das etwas abzufangen und die manuelle Fehlersuche auf Nummern zu beschränken und die Memberanzahl klein zu halten, müsste man Relationen verschachteln. Eine Relation für jede Straße. Die zusammengefasst in einer Relation für den Stadt- oder Ortsteil, welche wiederum von einer Ortsrelation zusammengefasst sind. Bleibt aber ein altes Problem. Im Gegensatz zu den Tags, werden solche Konstrukte von keiner Anwendung ausgewertet, also schlicht nicht gefunden.
Ich bin auch der Meinung, dass man die Sache durch Grenz-Flächen ganz gut in den Griff bekommt. Selbst wenn die Gemeindegrenzen nicht exakt bekannt sind, so weiss man doch, ob ein bestimmter Weg in die eine oder die andere Gemeinde / Stadt gehört. [EDIT: Ohne dieses Wissen könnte man auch keine entsprechende Relation erstellen. Und die Grenz-Umrandung hat den Vorteil, dass alle Wege, die innerhalb neu gemacht werden automatisch drin sind.]
Klar gibt es hier und da mal Exklaven, die könnte man dann aber als Multipolygon einbeziehen.
Interessanter Artikel, den kannte ich noch nicht.
Das bringt mich zu einem Thema, was ich noch nicht ganz verstanden habe: Wieso wird z.B für jede Autobahn eine Relation erstellt, wenn doch überall schon ein “ref” drinsteht?
Ouh, jetzt wird’s off-topic
