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?
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.
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).
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?)
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.
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”
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).
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.
…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).
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.