Polygon zu Adresse kann in Nominatim nicht gefunden werden

Nehmen wir eine Adresse in einem Häuserblock mit mehreren Eingängen (entrances). Z.B. berlin trusetaler str 82

Dieser Knoten ist eine Adresse, kein Gebäude, was ja erst Mal sinnvoll ist, da diese Adresse eben nur ein Eingang von mehreren zu einem Gebäude ist.

Es existiert aber auch ein Polygon zu diesem Gebäude.

Dieses kann ich aber in Nominatim nicht finden (ich habe auch den viewport search parameter versucht, aber ohne Erfolg).

Mit Glück seht ihr diesen Knoten hier:

https://www.openstreetmap.org/edit?editor=id#map=18/52.560336/13.562375

Dieses Polygon hat keinen Namen, keine Relation zu den Adressen und auch nicht zur Straße.

Jetzt habe ich praktisch zwei Fragen:

a) gibt es einen Weg, das Polygon dennoch in Nominatim zu finden?

b) ist das Polygon nicht letztlich sinnlos, weil es nicht gefunden werden kann (auch auf OSM nicht), wäre es nicht sinnvoll, es mit den Adressen zu verknüpfen?

Hintergrund hier: Addresses - OpenStreetMap Wiki

Da das Gebäude mehrere Adressen/Eingänge besitzt macht es natürlich Sinn es so zu Mappen.

Erlaubt wäre es, addr:housenumber=82,84,86 an dem Umriss zu mappen aber das wäre dann eine unschöne Doppelung.

Also das durch nominatim zu finden ist glaube ich - ohne Sarah vorzugreifen keine option. Denn Nominatim findet Objekte die du auch suchst. Du willst aber hier ein objekt was in einer Beziehung zu einem gesuchten Objekt steht haben. Also müsstest du dein nominatim ergebnis z.b. mit overpass ergänzen.

D.h. eigentlich suchst du die Addresse, die ist auf einem node, und zufällig ist der node bestandteil eines ways, dieser hat ein building tag.

Jede option addressen zu taggen hat ihre vor und nachteile. Die variante von chris mit X,Y,Z finde ich extrem unschön - damit wird hier die geographische lage der einzelgebäude/eingänge verwischt. Man könnte das Gebäude mit building:part aufteilen und die Addressen auf die building:part packen. Dazu sind “,” oder “;” in Addressen IMHO eher kaputt. Das geht in der einen oder anderen App - aber nicht flächig. hausnummern sind strings ohne bedeutung - Ob in 5-7b auch eine 5a oder 7a drin ist ist eben nicht eindeutig - Etc etc etc.

Auch das taggen des Gebäudes mit addr: tags hat riesen Nachteile vor allem wenn die Gebäude groß werden. In dem übergang von der Geokodierung zur Navigation wird da der Gebäudemittelpunkt genommen, der ist routingtechnisch vielleicht nicht das was optimal zu erreichen ist.

Flo

wenn allerdings das Objekt z.B. die Flurstücke 5, 5a, 5b, 7, 7a und 7b umfasst, dann könnte man so den String validieren (die Flurstücke müssten gemappt sein und der POI als Fläche eingetragen).

Diesen Absatz verstehe ich kaum:

  • wer ist Sarah?
  • ich suche ja ein Polygon zur Adresse, aber mein Punkt war, dass dieser Knoten (das Polygon) meines Wissens überhaupt nicht in Nominatim gefunden werden kann, mit keiner Query. Irre ich mich da?
  • Was ist overpass?

Das Gebäudepolygon zu verändern (Namen vergeben, Tags etc.) gab Ärger mit der Community. Offenbar ist es (in Dtl.) Usus, das Gebäudepolygon in solchen Fällen (nutzlos) zu isolieren.

Gibt es einen Grund, warum keine Relationen zu den Adressen hergestellt werden? (Würde mir das im Falle von Nominatim-Abfragen überhaupt helfen?)

Tags an das Polygon zu hängen kam nicht gut an, tatsächlich auch wegen der doppelten Information zu den Hausnummern.

Es ist doch wenig sinnvoll die Adressen nur zur Straße zu mappen, d.h. keine Verbindung zum Gebäude zuzulassen, oder?

Die Adressen sind an den Hauseingängen erfasst und die Eingänge sind mit dem Gebäude verbunden. Von daher ist die Zuordnung Adresse - Gebäude vorhanden.

Es gibt auch die Variante, dass die Adressen als eigenständige Punkte innerhalb des Gebäudeumrisses erfasst werden. Dann ist die Zuordnung über die Fläche auch gegeben.

Die Hauptentwicklerin von Nominatim. @lonvia

Overpass ist ein Tool zur Abfrage von OSM-Daten mit einer spezialisierten recht mächtigen Abfragesyntax. https://overpass-turbo.eu/

Bei dem was du erreichen willst ist vermutlich Nominatim schlicht nicht das richtige Tool oder zumindest alleinstehend nicht das richtige Tool.
Overpass hat Möglichkeiten Nominatim in die Abfrage mit einzubeziehen, bspw. über Festlegung des Bereichs in dem die Abfrage gelten soll über “nominatimArea

Siehe die Geschichte von DE:Relation:associatedStreet - OpenStreetMap Wiki (speziell in Deutschland).

Siehe bitte DE:Overpass API - OpenStreetMap Wiki und teste mal https://overpass-turbo.eu/

Der Punkt war eine antwort auf das “Dann trag es halt als a,b,c ein”

“Irgendwas in addr:housenumber” reinzuinterpretieren ausser “Es ist ein string” geht irgendwann schief. Also sowas wie aufzählungen mit “,” oder “;” sind “prone to fail” - Das mag in Deutschland und aktuell gehen - Aber woanders geht es kaputt.

Aktuell gibts das Thema das die Katasterbehörden Hausnummer “0” abererkennen. Es gibt davon durchaus ein paar - Ich vermute da da hat jemand software geschrieben die aus “0” “null” macht - und dann in der datenbank da ein “nix” bei raus kommt.

So ist das wenn man dinge “besonders” behandelt - Hausnummern sind ein “string” - Versuche nicht sie zu parsen oder du fällst auf die Nase. “93 4k15” oder “5 3/5h” sind durchaus valide Hausnummern.

Du suchst nicht das polygon zur Adresse - Das ist der Punkt.

Du suchst ein polygon in dessen Aussenring ein node ist der die Addresse trägt.

Nominatim liefert dir (Stark vereinfacht) objekte (node, way, polygon) die eine Addresse haben. Dein Polygon hat keine Addresse sondern der node mit dem Eingang hat die Adresse. Den bekommst du.

Aufgabe von Nominatim ist es nicht dir objekte zu liefern die in irgendeiner Beziehung zu dem gesuchten Objekt stehen. Das musst du dann selber lösen. Deshalb die aussage das du um das zu lösen ggfs Overpass nutzen kannst was stark vereinfach eine Query Language ist die eben in der Lage ist beziehungen von OSM Objekten zueinander auszuwerten.

Flo

PS: Sarah ist die Entwicklerin und Betreiberin von Nominatim

Ich entnehme deiner Antwort und auch der von @flohoff , dass Nominatim mir nicht weiter helfen wird. Also werden wir andere Lösungen entwickeln müssen.

Aber gibt es überhaupt die Möglichkeit, das Polygon des Gesamtgebäudes in Nominatim zu finden, abseits von Relationen (die Nominatim meines Wissens ohnehin nicht ausspuckt)?

Ich habe es mit viewboxprobiert, bin aber gescheitert.

Meine letzte Frage wäre: wozu gibt es diese Gebäudepolygone überhaupt in der Datenbank, wenn sie gar nicht genutzt werden sollen (weil sie in keiner Relation stehen und nur globale Tags tragen)? Und einen Eingang (entrance) nicht zu einem Gebäude zu mappen macht für mich als Greenhorn überhaupt keinen Sinn - es sind Eingänge zu gar nichts? Aber ich muss zugeben, dass der Eintrag zu diesem Key auch nicht mehr hergibt:

The entrance=* key describes the point where you can go into a building or enclosed area (such as a zoo, theme park, cemetery grounds etc).

weil sie existieren.

Nominatim ist das falsche Werkzeug dafür. Es gibt andere, zum Beispiel Overpass - schon mehrfach erwähnt.

Aber zurück zum Anfang: Was ist Dein Ziel?

Eingänge werden selbstverständlich zu einem building gemappt. Zugänge zu Grundstücken haben andere tags (barrier). Bei POIs wird teilweise entrance gemappt ohne dass es sich auf ein Bauwerk bezieht

Das “nicht sollen” verstehe ich grundsätzlich nicht. Ansonsten:
Die werden schon einmal - ganz rudimentär - für die Darstellung von Gebäuden genutzt. Das kann man doch ganz leicht auf den meisten Karten sehen!?
Mit ein paar Zusatztags sogar in 3D.

Wenn du den ersten Link in deinem ersten Beitrag…

… nochmal anschaust, und auf der linken Seite genau hinschaust…


…siehst du, dass der Knoten mit der Adresse und dem Eingangstagging auch Teil eines Weges ist. Dieser Weg ist dein gesuchtes Gebäude. Also sind die Informationen direkt verknüpft.

Was aber nicht heißt, dass das immer so ist. Adressen können auch an “freien” Knoten getaggt sein, dann muss man mit einer spatialen Abfrage nach umschließenden Gebäude-Polygonen suchen (z.B. mittels Overpass).

Ähm, hast du mal auf irgend eine Karte geschaut? :wink:

Nominatim ist nur ein TEIL deiner Problemlösung. Nominatim kann die Addressen finden. Danach musst du dich zwangsweise mit dem Datenmodell von OSM Beschäftigen wenn du IMMER das Gebäudeoutline willst denn es gibt viele dinge auf denen Adressen sein könnnen.

  • Wenn diese direkt auf dem Gebäudeoutline liegen → Fertig.
  • Wenn es ein node ist
    • Overpass - umgreifendes Gebäude oder way suchen in dem der node bestandteil ist

Und wir vernachlässigen hier mal das es für POIs auch sein kann das deine Addresse auf einem outline eines Golfplatzes sein kann.

Es geht ja nicht nur um DEIN problem. Es geht darum eine Karte zu machen und da will man schon Gebäudeoutlines. Und ein node der in einem Gebäudeoutline ist mit entrance=yes/main definiert das hier ein Eingang zu diesem Gebäude ist. Es kann aber mehrere geben. Mit unterschiedlichen Addressen.

Jetzt muss man sich damit beschäftigen woher Gebäudeoutlines kommen. Im ALKIS sind diese ggfs nach Baugenehmigung und Flurstücken getrennt. D.h. Blocks die gemeinsam gebaut worden sind und einem Eigentümer gehören sind mitunter EIN Gebäudeoutline, haben aber mehrere Eingänge. Das überträgt OSM dann in EIN Gebäudeoutline und mehrere Addressnodes. Dafür gibt es dann mehrere optionen wo diese Addressen sind. Auf dem Eingang (entrance=*) oder einfach nur als node mitten im Gebäude.

Dein “Ich will das Gebäudeoutlines für diese Addresse” ist eben in dem Datenmodell von OSM keine kleine Aufgabe die dir ein tool wie Nominatim abnimmt.

Du wirst dich wohl oder übel mit dem Datenmodell und komplexität von OSM und der Realität beschäftigen müssen
Flo

es gibt ja auch viele Adressen ohne Gebäude, der Bezug von Adressen und Gebäude ist bei kleineren Gebäuden in Deutschland zwar meist 1:1, aber das ist keineswegs allgemeingültig oder immer so.

Das hatte mich am Anfang bei OSM auch überrascht. Ich dachte erst, eine Adresse würde automatisch zu einem Gebäude führen. In der Praxis gibt es aber Mehrfamilienhäuser mit mehreren Eingängen oder Adressen ohne direkt zugeordnetes Gebäude. Da muss man oft selbst noch etwas Logik einbauen, statt sich nur auf einen Geocoder zu verlassen.