Hausnummer als node mit relation zur Straße

Hallo RideR6,

was du dort siehst ist eine associatedStreet Relation. So hat man “früher” gerne Adressen erfasst, es ist “heute” aber nur noch eine umstrittene Version von vielen möglichen.

Am häufigsten wird wohl die Adresse an den Gebäuden erfasst. Genauso sind aber auch Adressnodes in Verwendung, im speziellen auch gerne an Hauseingängen (z.B. bei mehreren Hausnummern pro Gebäude). Über Vor- und Nachteile lässt sich streiten, meistens ist es Geschmackssache.

Falls du es umtaggen möchtest, solltest du dann natürlich auch die Relation löschen. Da ein umtaggen kaum Nutzen haben und ggf. keine Veresserung mit sich bringt, würde ich alles so lassen wie es ist. Wieso sich Arbeit machen?

Gruß

Genau wie du vorgeschlagen hast.

Besser die Eingänge als node in den Hausumriss mit Adresse. Dann lässt sich zu dem POI routen wo man klingeln muss um rein zu dürfen.

Und etwas machen und dann vielleicht noch einmal um Kontrolle bitten.

PS: Natürlich noch Willkommen und viel Spaß mit OSM.

Stimme geri-oc zu. Bitte vorher checken, welcher Straßenname denn der richtige ist:

“addr:street” = “An Rebberg” (wie in der Relation angegeben) oder “Am Rebberg”

Danke schonmal für die Antworten! Aber ist nicht meistens die Lage eines Gebäudes ausreichend fürs routen? Wo genau die Haustür ist, kann man ja nicht immer wissen, sieht man aber vor Ort. (Ich weiß, eig sollte man vor dem mappen vor Ort schauen, aber bspw. fehlende Hausnummern würde ich ja auch nachtragen, auch wenn ich nicht extra hinfahre, um zu sehen, wo der Eingang ist.) Bei großen Objekten verstehe ich den Sinn des Adressnodes, “damit man auch weiß wo der Briefkasten hängt”. Bei Einfamilienhäusern entlang einer Wohnstraße erschließt sich mir der Sinn eines Adressnodes nicht ganz :expressionless:

Hallo RideR6,

willkommen bei OSM und im Forum! :slight_smile:

Falls die Relation entfernt werden sollte, müssen unbedingt alle betroffenen Hausnr.-Nodes mit der restlichen Adresse ergänzt werden, da diese sonst unvollständig sind - aktuell ist nur die Hausnr. in den Adress-Nodes.
Wenn dort keine Fehler in der Relation sind, würde ich die Relation allerdings so bestehen lassen.
Bei Problemen mit der Relation kannst du auch den Mapper q_un_go anschreiben, denn er hat diese erstellt und scheint in der Region sehr aktiv zu sein.

+1

Du musst neue / fehlende Adressen allerdings nicht mit Relation mappen, aber mindestens mit Straßenname und Hausnr…
Ich würde dann aber noch PLZ und Ort ergänzen, damit die Adresse vollständig ist, aber hierbei werden mir sicherlich einige Mapper widersprechen, wegen Redundanz. Ich freue mich immer, wenn der gesuchte POI eine vollständige Adresse hat und ich mir diese nicht erst woanders suchen muss.

**OT: **
Das kaputte Wohngebiet-Multipolygon (MP, https://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon ), ganz in der Nähe, sollte aber zumindest repariert werden:
https://www.openstreetmap.org/relation/3206351
Wenn ich das richtig sehe, hast du das mit https://www.openstreetmap.org/way/237939806 “kaputt gemacht”, deshalb wird es nicht mehr gerendert.
Dabei hilft dir sicherlich ein erfahrener Mapper hier oder du fragt den Erstersteller q_un_go .
So etwas passiert eben, wenn man Wege als MP-Außenlinien verwendet. Ein neuer Mapper kommt mit ID vorbei, aktualisiert etwas und dann ist es schon passiert, ohne das er etwas merkt.
Das ist kein Vorwurf an dich RideR6.
Dieses Problem wäre, in diesem Fall, gar nicht entstanden, wenn q_un_go eine einfache Fläche, anstatt eines MP, verwendet und diese nicht an Wege geheftet hätte.
Wozu auch ein MP, wenn es innerhalb keine Inseln gibt(?)

Gruß Peter

Kurz zur Info, weil ich deinen OSM-Wissensstand nicht weiß: Der Stil wird dir öfters begegnen, Flächen generell als Multipolygon zu erfassen, indem bestehende Linien passend aufgeteilt und an Flächengrenzen, wo außer der Grenze nichts ist, tag-lose Ways für die outer-Ringe eingezeichnet werden. Wer das nicht mag, nennt es Multipolygonitis. Es hat einige Vorteile – es geht wirklich schnell, jede Linie ist nur einmal da, nichts liegt aufeinander, auch das Rendering ist in jedem Zoomlevel lückenlos und wirkt professionell-elegant. Und wenn man einmal damit angefangen hat, werden angrenzende Flächen auch so dargestellt. Hier in Bild 3 siehst du den gedanklichen Ansatz. Nachteile: es ist extrem wartungs- und weiterführungsfeindlich, ein Fremdmapper muss sich da immer erst reindenken, und kein Teil-Way darf einfach so verlängert werden. Konsens ist eher, dass man nicht so vorgehen sollte, aber es gibt einige Hartgesottene, die immer wieder mal neue MP-Teppiche anlegen (oder, schlimmer, bestehendes Mapping löschen und durch ihren MP-Teppich ersetzen, weil sie das für besser halten).

Edit: Hier (und Umgebung) ist noch eine Multipolygonitis von mir, aus meiner sündigen OSM-Jugendzeit. Ich schäme mich auch, ganz bestimmt!

–ks

Der ist sicherlich ausbaufähig.

großartiges Wort :laughing:

ja, ganz bestimmt … :wink:

Push! Da ich noch neu bin, werden meine Beiträge erst nach Durchsicht gepostet…

Nochmal dazu: Ist es nicht sinnvoller wenige Objekte mit vielen Tags zu haben als viele Objekte, die iwie zusammengehören zu haben. Hat irgendein Renderer/Routenplaner/whatever Probleme mit Adressen als tag im building?

Zum Thema Multipolygone: Das Wohngebiet, das ich zerstört habe, schaue ich mir noch an! Habs nur auf die Schnelle in ID nicht kapiert :smiley: Im Gegensatz zum Adressnode erschließt sich mir der Sinn von Multipolygonen sogar :smiley: Theoretisch wäre so vieles als Multipolygon die sauberere Variante. Beispielsweise an Linien, die Gemeinde-, Landkreis-, Landes-, Bundes-,whatever -Grenze gleichzeitig sind…

Grüße RideR6

“Die Kette ist so stark wie das schwächste Glied”

Warum “kompliziert mit Relationen” mappen wenn man auch “einfach” mappen kann?

Bei Grenzen wird das gemacht. Aber bitte keine Straßenabschnitte o.ä. in MP-Ringe einbauen, das ist null fehlertolerant, und Straßen werden einfach zu häufig bearbeitet (Wowereit).

–ks

Nö. Hat er aber auch nicht an einem node.
Bei einem node muss er aber nicht erst einen Punkt errechnen, damit er zum Gebäudeschwerpunkt routen kann :slight_smile:
Einfach mal https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=49.41394%2C11.12977%3B49.46169%2C11.11913#map=19/49.41392/11.13025 ansehen - und verstehen, dass es schön ist, wenn man an der richtigen Seite ankommt…
Ändern, nur damit es anders ist? Schlechter Stil. Ob der Adressnode jetzt im Gebäude liegt oder am Umring hängt, ist einem Auswerteprogramm völlig schnurz, weil man sich immer um alle Varianten kümmern muss.

Bei Grenzen sind Multipolygone hier gewollt und akzeptiert, weil sich da entsprechende “Spezialisten” darum kümmern. Bei den Dingen für “Alltagsobjekte” wird der Pflegeaufwand immens und wahlweise OSM-Anfänger abgeschreckt oder die Multipolygone ständig kaputtgemacht.
Ich bin jetzt kein Anfänger mehr, aber in meinem Umfeld gibt es ein paar ausgeprägte Gebiete mit “Multipolygonitis”, die praktisch niemand (ist auch mir zu aufwendig) mehr pflegt…

kommt halt immer auf die Realität an. In Deutschland, wo die Nummern meistens Grundstücke oder Häuser bezeichnen, ist es m.E. am besten, die Nummern dort zu taggen, wo sie gelten. Da wir Grundstücke meistens nicht erfasst haben, macht es in diesem Fall oft mehr Sinn, einfach “das” Haus mit der Nummer zu versehen (sofern vorhanden), bzw. einen node mit der Nummer am Eingang zu machen, sofern man den Umriss nicht zeichnen will.

Dort, wo die Nummern tatsächlich einen Eingang bezeichnen, ist es am besten diesen Eingang mit der Nummer so zu mappen.

Wie die Nummern vergeben werden, entscheidet glaube ich die Gemeinde, evtl. auch das Land oder der Kreis(?). Für Baden-Württemberg habe ich auf die Schnelle nichts eindeutiges gefunden. Die Nummern werden wohl nach Erfordernis kreiert, d.h. z.B. wenn man einen Bauantrag einreicht.

Das wäre sicherlich einen eigenen Thread wert. Hierzu möchte ich trotzdem kurz anmerken, dass das Problem nicht Multipolygone an sich sind, sondern komplizierte / große Multipoligone mit vielen membern, die man noch dazu eigentlich kaum braucht, und die auch nichts spezielles beschreiben, was man anders nicht beschreiben könnte. Kleine, saubere Multipolygone sind auf Mapperseite kein Problem, sind es aber vielleicht wenn in großer Menge verwendet, beim Datenmodell und für die Tools (weil sie immer rekursiv durchlaufen werden müssen, erst die ways finden, dann die nodes).

Da ist das Land zuständig. In Bayern ist festgelegt, dass die Hausnummern auf der Linken Seite ungerade und rechts gerade sind, beim zählen wird immer von der Ortsmitte nach außen gezählt. Hamburg zählt auf der einen Seite die Häuser 1,2,3,4,…durch und auf der anderen Seite die umgekehrte Richtung weiter, somit kann da die Nummer 200 gegenüber der Nummer 1 sein. In Bayern regelt dies das BayStrWG. Die Gemeinden können das Aussehen der Hausnummernschilder vorschreiben.

Von welchem Hamburg sprichst du?

In dem gezeigten Fall sehe ich das vollkommen ein, dass ist die Lage des Gebäudeeingangs entscheidend.

Das habe ich mir eben auch gedacht. Habe auch nochmal in der Wiki recherchiert und folgendes gefunden:

https://wiki.openstreetmap.org/wiki/DE:Key:addr

Demnach ist für Einfamilienhäuser die Adresse am building die erwünschte Art zu mappen.
Außerdem entspricht das ja auch der One feature, one OSM element Philosophie denke ich mal…

Und hier steht, dass das mit der Relation sehr umstritten ist…
https://wiki.openstreetmap.org/wiki/DE:Relation:associatedStreet

Der Punkt ist, dass fast im gesamten Rest des Dorfes die Adressen an den buildings getaggt sind. Ich würde es gerne in diesem Dorf vereinheitlichen. (und die Relations löschen) Teilweise sind auch 95% Prozent der Häuser einer Straße “normal” getaggt, aber ganze 2 Häuser via Adressnodes und relation. Das muss ja nicht sein…

die “erwünschte“ Art etwas zu mappen ist, den Objekten einen tag zu geben, die das repräsentieren, was der tag beschreibt.
Die One Feature one OSM Element Regel sagt, dass man nicht dasselbe mehrmals mappen soll, wenn es nur einmal da ist, z.B. nicht als node und als polygon, das hilft aber nur bedingt, weil die Features erst dadurch zu Features werden, dass man ihnen einen tag gibt, und was die tags bedeuten wird festgelegt, ein place=city auf einem Polygon könnte z.B. als expliziter Umriss einer Stadt interpretiert werden während die Stadt bei demselben tag auf einem node nur implizit enthalten wäre (über das Zentrum), ähnlich wie bei Brücken, wo bridge=yes auf einem highway kein Brückenobjekt ist, trotzdem weiß man, dass dort eine Brücke ist. Bei Adressen ist es auch ein Sonderfall: addr: tags sind beides, Hausnummern und Adressinformationen. Dieselbe Adresse mehrmals ist kein so ungewöhnlicher Fall. Wenn man das über ein Polygon lösen kann, dann ist es überlegenswert (Risiko sind hier z.B. Probleme durch versehentliches teilweises Verschieben, der poi liegt danach im anderen building)), aber in manchen Gegenden geht das auch nicht, weil die Hausnummer einen Punkt (Eingang oder gate) beschreibt, und keine Fläche, da ist es am einfachsten, neben dem Mappen des Hausnummerobjekts auch noch die Adressen jeweils an die POIs zu machen.

Ersetze “festgelegt” mit “üblich”.

Auch in Bayern sind die Gemeinden originär für die Vergabe der Adressen zuständig. Der Freistaat legt da gar nichts fest. Auf dem flachen Land kann es aber sein, dass das jeweilige “Staatliche Vermessungsamt” bei Neubaugebieten neue Adressen “vorschlägt” (weil das einfacher und kostengünstiger ist, als später dann nochmal einen Veränderungsnachweis zu machen) und die Gemeinden das dann einfach akzeptieren.

Da gibt es leider mal wieder eine Abweichung zwischen deutscher und englischer Originalversion:

https://wiki.openstreetmap.org/wiki/Key:addr

Auch das sehe ich ein und befürworte ich! Dafür sollte der Punkt dann aber auch mit entrance=* getaggt sein.

Auf mein eingangs gepostetes Beispiel lässt sich allerdings nicht anwenden, dort sind die von mir kritisierten Adressnodes irgendwo auf der Grundfläche des Hauses angesetzt.