Bei mir im Dörfchen trägt ein Mapper Häuser und Adressen in einer Relation ein. Dadurch neugierig geworden habe ich mal nachgesehen was das Wiki dazu sagt. Unter anderem: „Prinzipiell sind diese jedoch für Software leichter und weniger fehleranfällig auszuwerten.“ Was mir auch schlüssig erschien und habe daher selber eine Straße, nachträglich, in die Relation gepackt.
Etwas Später habe ich dann, an anderer Stelle gelesen: „ DE:Relation:associatedStreet - Relation zur Erfassung von Hausnummern. Auf die Relation sollte verzichtet werden und statt dessen die Nummern unmittelbar den Elementen hinzugefügt werden: Karlsruhe-Schema und addr “
Wie den nun? Entweder Relation oder nicht? Für mich sind diese beiden Aussagen ein Widerspruch.
Wie seht ihr das? Oder habe ich da grundsätzlich was nicht verstanden?
Da wirst du - wie so oft - mehrere Antworten bekommen. Meine:
associatedStreet ist tot und sollte nicht verwendet oder gar erweitert werden.
das “Karsruher Schema” ist “State of the Art”, also etabliert und sollte bevorzugt werden.
Zum Karsruher Schema ist noch zu bemerken, daß in gut “vergrenzten” Gebieten - also dort wo die Grenzen komplett und sauber sind, addr:country und addr:city nicht mehr unbedingt benötigt werden. addr:street steht derzeit “auf der Kippe” und addr:postcode wird langsam auch angezweifelt.
Auf addr:street wird man an Straßenkreuzungen wohl nie verzichten können, wenn man nicht aus Nachbarhausnummern extrapolieren will, was in Städten ziemlich verzwickt werden kann.
Bei addr:postcode bin ich bei der Überarbeitung der PLZ-Grenzen immer noch froh, wenn da wenigstens ein paar Einträge stehen. Gelegentlich gibt es nur ein, zwei “Irrläufer”, die auf kilometerlange falsche Zuordnung einer Straßenseite hinweisen.
Sehe ich auch so: Ich lasse teilweise die Strassenangabe (egal ob mit “addr:street”=* oder associatedStreet) weg, weil ich nicht sicher sagen kann zu welcher Strasse ein Haus gehört. Da dürfte die Fehlerquote auch bei besseren Implementierungen nicht so toll sein.
Ich halte associatedStreet für die schönere der beiden Lösungen (weil weniger Redundanz) und nutze daher das, wenn ich eine Strasse zu einem grossen Teil mit Hausnummern versehe.
Das ist kompletter Bullshit, für Software im Allgemeinen bringt das überhaupt nichts. Für manche Anwendungen ist es sogar praktischer, alle Informationen an einem Objekt zu haben (also eben gerade keine Relationen auswerten zu müssen).
Hat jemand überhaupt ein Beispiel für eine existierende Software, die von der Verwendung von associatedStreet statt addr:street profitiert?
Ganz kurz die Argumente:
Adr:tags einfach, übersichtlich aber redundant, besonders wennjemand immer noch Stand-Land-Fluss hinzu fügt. (Auf Adr:street kann man schon ob der Übersichtlichkeit nicht verzichten, da an Ecken oft gleiche Hausnummern liegen)
Relation, genial weil man allen Elementen leicht Werte zuordnet, leider wird da aber kaum gemacht, sodass die Relation nur das übliche Stadt-Land-Fluss- Schema ergänzt und damit macht diese sich überflüssig. Andererseits stören die Relationen auch nicht, und man kann durch diese gut den Verlauf der Straße nachvollziehen und erkennen, ob man eine Hausnummer vergessen hat.
Ich bin da zerissen. Generell finde ich Relationen gut: weniger Redundanz, weniger Fehler. Ohne guten Tool-Support für die Eingabe und Auswertung bringt das hier jedoch wenig. Aber wenn man z.B. im Editor beim Hinzufügen einer Adresse die umliegenden Straßen als Auswahlbox angezeigt bekommt, könnte automatisch das Tagging per Relation passieren. Entweder eine neue Relation oder Hinzufügen zu bestehender. Na ja, passiert wohl nicht so bald.
ich unterstütze in meiner OSM-Hausnummernauswertung zwar praktisch die associatedStreet Zuordnungen von Hausnummernobjekten. Aber diese Relationsart wird in der osm2pgsql, die fürs rendern optimiert ist, nicht berücksichtigt. Nur sehr umständlich und inperformant können diese trotzdem ausgewertet werden. Da kann gerne gesagt werden, eine andere DB-Struktur wäre besser, aber auch die haben ihre Nachteile.
Die associatedStreet Relation ist nicht erforderlich, weil es das Karlsruhe Schema gibt. Ich persönlich finde den Einsatz von Relationen dann sinnvoll, wenn andere Arten nicht oder nur sehr schwierig gehen, also z.B. bei Multipolygonen, Verkehrsrouten oder Abbiegebeschränkungen.
“addr:street” habe ich bisher noch nirgendwo infrage gestellt gesehen. Ich unterstütze ein Hausnummerobjekt ohne addr:street nicht. Das Argument, die nächstgelegene Straße zu ermitteln, zählt für mich nicht als Argument. Eine auswertende Software hat wirklich einiges zu tun, aber auch noch das zu verlangen, finde ich nicht ok. Vom Aufwand abgesehen, ist die Ermittlung auch ggfs. nicht eindeutig und eine eindeutige Aussage nach dem Motto, bitte immer addr:housenumber und addr:street zu setzen, ist einfacher für alle Mapper, als zu differenzieren, wann evtl. addr:street auch entfallen könnte.
Gestern oder heute erst gesehen: ein Gebäude, dreimal Hausnummer 1, aber drei unterschiedliche Straßen. Viel Glück, die alle richtig zuzuordnen. Mindestens zwei verschiedene Postleitzahlen waren’s auch noch, sonst wäre es mir nicht aufgefallen.
Wen ich für mich das hier geschriebene zusammenfasse, komme ich zu dem Ergebnis:
Ein Relation stört nicht, aber Mappen nach dem Karlsruher Schema ist die bessere Variante.
Hier dann möglichst nur
addr:housenumber
addr:street
addr:postcode
nutzen.
addr:city und country nicht mehr.
Aber warum city und country nicht mehr? Gibt es hierzu vll. etwas im Wiki (möglichst deutsch, englisch kann ich nicht ), oder einen Thread hier? Zur Info und damit das Thema (city/country) hier nicht noch mal durchgekaut werden muss bzw. wird.
Im Wiki steht sowieso nicht, dass man diese Infos taggen muss. Was jedoch sinnvoll/wünschenswert ist, darüber gehen die Meinungen auseinander.
Ein Argument ist: Land, Gemeinde und auch PLZ kann man in DE weitgehend aus den Relationen für die Grenzen durch eine räumliche Abfrage ableiten.
Außerdem sollte durch den Kontext der Verwendung mindestens das Land meistens klar sein.
Das Gegenargument: Nicht immer steht die Möglichkeit einer räumlichen Abfrage zur Verfügung bzw. bei lokalen Exktrakten fehlen die Relationsdaten evetuell.
Bei lokalen Extrakten sind Land und Gemeinde meistens aus dem Kontext gegeben. Die PLZ, insb. in Großstädten, vielleicht nicht.
Ich versuche es mal leicht verständlich zu erklären: Die Grenzen von Ländern und Gemeinden in Deutschland sind schon ziemlich genau erfasst. Hier z.B. die von Deutschland: https://www.openstreetmap.org/relation/51477 Achtung: das Laden dauert etwas länger.
Aus diesen Grenzen kann man relativ einfach berechnen, in welcher Stadt/Land eine Adresse liegt. Man braucht daher city/country nicht mehr erfassen, da dies eine redundante Information wäre.
Die PLZ-Grenzen sind auch schon einigermaßen genau erfasst (Ausnahme: größere Städte mit mehreren PLZ), also muss man diese auch nicht mehr unbedingt eingeben. Besser wäre es, die PLZ-Grenze zu korrigieren, falls diese nicht stimmen sollte.
Ich bin dafür an einen POI alle addr: zu setzen.*
Bei einer Suche wird es komplett angezeigt. Man sollte auch den “einfachen” Dingen ihren Bestand lassen!
Wird es auch ohne vollstädige addr:-Daten. Bei einer Suche nach „Bettinas Haarstudio, Erding“ ist das Resultat:
Präziser geht’s doch gar nicht. Die Darstellung des Nodes selbst ist dann doch eher Geschmacksfrage und momentan stehen eben nur die explizit vergebenen Tags dran, was nicht heißt, dass man’s nicht ändern könnte.
Entfernen würde ich addr:-Tags allerdings nur dann, wenn sie wirklich falsch sind, nicht, wenn ich sie für redundant halte.
), oder einen Thread hier? Zur Info und damit das Thema (city/country) hier nicht noch mal durchgekaut werden muss bzw. wird.