Automatisch Address-Nodes in Gebäude mergen

JOSM:
Plugin utilsplugin2 und dann geht das mit STRG-SHIFT-G, wenn ich mich nicht täusche.
Wenn man das Plugin building_tool benutzt und ein Gebäude über ein Adressnode zeichnet scheint JOSM das auch direkt zu vereinen.

Was anderes wüsste ich auf anhieb auch nicht. Und, Adresse ist als Node und auf dem Gebäude OK. Man sollte aber nicht hingehen und systematisch alles umtaggen, vor allem, wenn die Adressnode sonst vollkommen korrekt ist. Imho.

Und wenn der Node auf dem Eingang liegt sollte man das natürlich auch nicht machen (Informationsverlust).

Wie wäre es mit einer Overpass-Abfrage, die alle "addr:housenumber" nodes innerhalb eines Gebäudes ausgibt? Mein Prototyp funktioniert aber leider nicht:

way[building=yes]({{bbox}});(node(around:0)["addr:housenumber"~"."];node(w););out␣meta;

Das geht mit Overpass in diesem Fall prinzipiell nicht. (Super-Kurzversion einer längeren Antwort...)

@mmd: Kommt die längere Antwort noch? Das würde mich mal interessieren ...

Ok, ganz kurz umrissen: alles was in die Richtung "liegt in" geht, wird in Overpass über ein "(area)" als Filter gelöst. So eine Area ist aber kein natives OSM-Objekt, sondern wird regelmässig auf dem Overpass Server berechnet, wofür es bestimmte Regeln gibt. Dummerweise ist es nun so, dass diese Regeln z.B. voraussetzen, dass ein Way bzw. Relation ein "name" Tag hat, oder bestimmte andere Tags (Details findest du hier). Für building=* gibt es also ganz überwiegend keine Area, so dass ein "liegt in" nicht tut.

Eine ad hoc Area Erzeugung gibts noch nicht, ebenso wie der folgende Ansatz: https://github.com/drolbr/Overpass-API/issues/77

@mmd Hast du http://dev.overpass-api.de/api_mmd/ noch irgendwo laufen? Habe ich das richtig verstanden, dass die von mir vorgeschlagene Abfrage (prinzipiell) auf deinem branch funktionieren würde?

Es hätte wahrscheinlich irgendwie funktioniert, allerdings war das halt nur ein Prototyp mit ein paar mehr oder weniger großen Macken. Inzwischen läuft er aber nicht mehr.

Sachen gibts: hier hat jemand deine Query gefunden und fragt auf help osm nach, warum das nicht tut.

https://help.openstreetmap.org/question … -buildings

Lilla Elna wrote:

Eine Debatte über die Sinnhaftigkeit möchte ich hier nicht anfangen.

Auch wenn es nicht verboten ist: Ich halte das fast für -ähm- sehr fragwürdig. Mir sind oft genug schon Adresspunkte in falschen Gebäuden aufgefallen - und so was soll jetzt Quasi automatisch an Gebäude "veredelt" werden?? Zudem kenne ich ebenfalls genügend Gebäude, die mehrere Adressen haben, aber nur eine davon erfasst wurde. Dann wäre das Übertragen ebenfalls schlicht und ergreifend falsch.

Lilla Elna wrote:

Kann man automatisch Address-Nodes, die innerhalb eines Gebäudes liegen, mit dem Gebäude-way mergen? Beispielsweise in JOSM?

Eine Debatte über die Sinnhaftigkeit möchte ich hier nicht anfangen. In machen Ländern wie z.B. Holland (NL) soll man das nicht, überall sonst auf der Welt ist es aber zumindest nicht verboten.

Nur, wieso sollte man das machen? Auch wenn es "nicht verboten ist" (mal abgesehen davon, dass die Sachlage deutlich komplizierter ist als das und man häufig gar nicht beurteilen kann ob dabei Informationen verloren gehen oder nicht). muss jeder Datenkonsument so oder so die üblichen Fälle verarbeiten können, und Ändern um des Änderns willens ist auch sinnlos.

Simon

Also ein JOSM fügt das "building_tool" unter 'Daten' > 'Adresspunkte vereinen' eine Möglichkeit ein große Mengen an Adresspunkten zu vereinigen. Ich gestehe das auch schon mal gemacht zu haben. Allerdings würde ich das heute nicht mehr tun. S. o. Es wäre meiner meinung nach höchstens dann sinnvoll, wenn dadurch die Struktur einer Stadt vereinheitlicht werden kann.

Wenn du das Gebäude erst zeichnest gibt dir gleiches Plugin die Möglichkeit (>Einstellungen) Adressnodes unter dem Gebäude zu übertragen.

SimonPoole wrote:

Nur, wieso sollte man das machen? Auch wenn es "nicht verboten ist", muss jeder Datenkonsument so oder so die üblichen Fälle verarbeiten können, und Ändern um des Änderns willens ist auch sinnlos.

Zu spät, ich habe schon 1 Million buildings gemerget.

Ich als Datenkonsument würde Adress-Nodes generell weglassen, da in den USA und Kanada viel zu viel Bullshit importiert wurde (Hausnummern für noch zu bauende Häuser).

Lilla Elna wrote:

(Hausnummern für noch zu bauende Häuser).

Gibt's auch in Berlin. Ich verstehe auch nicht, was das bei uns zu suchen hat.

Bei 1 Millionen Gebäuden sind wir aber im Bereich "mechanical edit". Das geht nicht einfach so.

Wow, das geht fix. Würde mich nicht wundern, wenn da in kürze ein Revert statt findet.

Und zwecks Hausnummern für noch oder nicht mehr existente Gebäude - was spricht dagegen? Wenn man die Info hat, spricht mM nichts dagegen. Zumindest in Österreich ist die Hausnummer am Grundstück, nicht am Gebäude, am Gebäude wird nur deswegen getagged, weil wir selten bis nie die genauen Grundstückabmessungen kennen. Am Luftbild ist das Haus einfach eindeutig.
Wenn nun ein Haus abgerissen ist, spricht auch nix dagegen, die Adresse als POI dort zu lassen.
EDIT: Für Baufirmen wärs auch ned unpraktisch, aber da könnte man auch sagen, die sollen sich selbst darum kümmern, wenn sie bauen anfangen *schulter zuck*

Lilla Elna wrote:

Zu spät, ich habe schon 1 Million buildings gemerget.

mit deinem Account oder einer Socke?

http://hdyc.neis-one.org/?Lilla%20Elna

Wieder was, was kein Spaß macht... 🙁

Dürfte wohl https://www.openstreetmap.org/user/TheSolarGuy sein, dann machen wir das doch alles wieder rückgängig.

SimonPoole wrote:

dann machen wir das doch alles wieder rückgängig.

+1 und vielen herzlichen Dank!

Lilla Elna wrote:

Ich als Datenkonsument würde Adress-Nodes generell weglassen, da in den USA und Kanada viel zu viel Bullshit importiert wurde

So ein Käse. "Würde weglassen" und im Gegenzug unbesehen auf das nächstbeste building übertragen widerspricht sich massiv :-(
Und ein Datenkonsument, der mit so einer flachen Begründung einfach alle Adressen in den Niederlanden und Italien wegschmeißt (weil nodes), sollte sich eine andere Quelle suchen...

pyram wrote:

SimonPoole wrote:

dann machen wir das doch alles wieder rückgängig.

+1 und vielen herzlichen Dank!

+1

Danke.

@OP: beim nächsten Mal bitte beachten:
https://wiki.openstreetmap.org/wiki/Aut … of_conduct

Ich werds im Laufe des Tages machen, hab noch ein CS Kommentar gemacht.

Der Witz ist ja noch, dass in SD (ich war da schon öfter irl) die Adressen aus einem (in der Zwischenzeit alten) Datensatz des "Bezirkes" San Diego sind und es generell relativ wenig Gebäude hat, die (fast) alle von Hand eingetragen sind. Sprich man müsste, die Gebäude einzeln anschauen ob sie überhaupt zur Nummerierung passen, ob die Gebäude sich geändert haben usw. Zusätzlich wurde der source Tag 1 zu 1 beim Mergen übernommen, was eh falsch ist.

Simon

PS: Hab den Revert in der Zwischenzeit gemacht.

mmd wrote:

Ok, ganz kurz umrissen: alles was in die Richtung "liegt in" geht, wird in Overpass über ein "(area)" als Filter gelöst. So eine Area ist aber kein natives OSM-Objekt, sondern wird regelmässig auf dem Overpass Server berechnet, wofür es bestimmte Regeln gibt. Dummerweise ist es nun so, dass diese Regeln z.B. voraussetzen, dass ein Way bzw. Relation ein "name" Tag hat, oder bestimmte andere Tags (Details findest du hier). Für building=* gibt es also ganz überwiegend keine Area, so dass ein "liegt in" nicht tut.

Eine ad hoc Area Erzeugung gibts noch nicht, ebenso wie der folgende Ansatz: https://github.com/drolbr/Overpass-API/issues/77

Ich hab mal testweise eine Ad-hoc Area Erzeugung eingebaut. Damit lassen sich nun auch Knoten mit addr:housenumber ermitteln, die in einem Haus liegen. Sonderlich schnell ist das nicht, aber für ein paar Stunden basteln schon mal ganz nett 😎

http://overpass-turbo.eu/s/Fbk