addr:place bedeutet, dass die Hausnummer sich nicht auf eine Straße bezieht, addr:suburb ist dagegen die üblicherweise redundante Angabe eines Stadtteils bei einer herkömmlichen Adresse
Hier sind schon einige Annahmen drin, die problematisch sind.
A) Du hast gerade ein Schema definiert, dass nur auf Deutschland beschränkt ist. Das kann Nominatim natürlich nicht machen, der muss weltweit funktionieren. Das heisst Nominatim müsste die Schemata für jedes Land kennen. Das hat aber keiner je definiert oder dokumentiert. Da kommt man also nicht weiter. Es braucht etwas allgemeineres.
B) Du nimmst an, dass alle Addressen immer vollständig mit allen addr:-Tags versehen sind. Das ist nicht einmal in Deutschland der Fall, ausserhalb von Deutschland wird es noch dünner. Wie soll der Geocoder jetzt feststellen, dass Tags fehlen? Gegen die offizielle Liste vergleichen? Das bringt uns zurück zu Problem A.
C) Du nimmst an, dass alle Addressen in das von dir gewählte Schema passen. Ich denke, das haben wir in diesem Thread schon nachgewiesen, dass das nicht einmal in Deutschland funktioniert.
Es macht die Suche robuster. Dass addr:-Tags selten vollständig sind, hatte ich bereits erwähnt. Dann kann man aus den Strassen- und Boundary-Objekten noch zusätzliche Infos ziehen wie alternative Namen oder Namen in anderen Sprachen. Das wird besonders wichtig, wenn Orte mehrsprachig sind und man nicht überall die addr:-Tags in allen lokalen Sprachen anhängen will. Aber es hilft dir natürlich auch wenn du einen Ort im Ausland suchst. Und letztendlich ist eine postalische Adresse nicht immer das gleiche wie eine textuelle Ortsbeschreibung. Einfaches Beispiel: im deutschen Addressformat oben hast du das Bundesland weggelassen, was völlig korrekt ist. Die Suche sollte aber schon das richtige ergeben, je nachdem ob du “Hauptstr 3, Neustadt, Sachsen” oder “Hautpstr 3, Neustadt, Baden-Würtemberg” suchst.
Und dann gibt es noch einen implementierungstechnischen Grund. Nominatim indiziert zur Zeit ca. 150 Millionen Objekte auf Hausnummer-Niveau. Das macht mehr als die Hälfte der Datenbank aus. Wenn man für alle die vollständig Adresse speichern würde, würde das die Grösse der Datenbank mal eben verdoppeln. Sprich, aus 800GB werden 1.5TB. Das ist nicht wenig.
Das ist historisch gewachsen. Früher gab es nur das addr:housenumber Tag und die implizite Annahme war, dass es sich auf die nächste Strasse bezieht. Dann hat man festgestellt, dass es auch andere Arten von Hausnummern gibt. Man brauchte also eine explizite Kennzeichung, die sagt, dass sich die Nummer nicht auf eine Strasse bezieht. Natürlich hätte man auch ein anderes bestehendes addr:-Tag nehmen können, aber dann hätte man sich einigen müssen auf welches. addr:city, addr:suburb, addr:block, … Es gibt da einige Varianten, die je nach Land besser oder schlechter passen. Deshalb hat man ein neues Tag genommen, dass jetzt ausdrückt, dass es der ‘Anker’ zur Hausnummer ist unabhängig davon, wie das sonstige lokale Addressformat aussieht.
interessanterweise findet er das nicht (0 Treffer) weil 2 Tippfehler drin sind, korrigiert man die Straße wird es aber gefunden. Könnte man Nominatim evtl. etwas fehlertoleranter einstellen?
Nachtrag: sehe gerade dass es in manchen Sprachen Baden-Wurtemberg bzw Baden-Wuertemberg heißt (bzw so gemappt ist), evtl liegt es daran dass das erkannt wird.
Das ist das Problem - also das (richtig) korrigieren.
ich spreche die Sprachen nicht, kann da also nicht weiterhelfen
Sorry, aber das halte ich für ne Ausrede. Das Problem, das Nominatim sich für die Suchergebnisanzeige was zusammenreimt, was so einfach nicht stimmt, besteht doch auch mit richtig (als Nodes) getaggten suburbs.
Suche “badenia offenburg” > Suchergebnis No. 3 > Restaurant Badenia, 28, Hauptstraße, Bohlsbach, Offenburg, Verwaltungsgemeinschaft Offenburg, Ortenaukreis, Baden-Württemberg, 77652, Germany
Getaggt beim Restaurant (Node) ist keine Adresse.
Ok ist es wenn man die fehlenden Bestandteile eindeutig herleiten kann, das sind alle Bestandteile außer “Bohlsbach”, weil es dazu Boundaries gibt. Bohlsbach ist als place-Node erfasst und wird zugefügt, weil es zufälligerweise (!) der näheste place-Node ist. Hat mit der Badenia aber mal so garnix zu tun.
IMHO sollte Nominatim darauf verzichten, “zu raten”. Was nicht da ist und auch nicht eindeutig ergänzt werden kann, wird halt nicht angezeigt.
Und zum Problem “Außerhalb”, “Außenliegend”: Die Adressen sind eben so erfasst. Dann sollte man auch diese Angaben verwenden und nicht versuchen, das besser zu machen wie der Erfasser. Verzweigungen in der Art
wenn addr:street dann add:street sonst suche_strasse(koordinaten)
sollte das Problem deutlich entschärfen.
Aber ich jammere lieber.
Ich finde den Versuch, auch aus Nodes noch was herauszuraten, im Prinzip nicht schlecht, besser wäre aber in jedem Fall, place-Objekte auch als Flächen zu erfassen, weil bei place-Nodes fehlt grundsätzlich die wichtigste Information: worauf sich das bezieht außerhalb genau des getaggten Punktes.
Ich habe jetzt den Thread nochmal komplett gelesen, vor allen Dingen die qualifizierten Erklärungen von lonvia nebst dem … herausvordernden Video über die Hintergründe von Nomiatim (ich habe tatsächlich nicht alles in gänze verstanden).
Subsumierend scheine ich feststellen zu müssen, dass es derzeit keine Möglichkeit gibt, das Haus “Außenliegend 13” regelgerecht zu beschreiben UND dafür zu sorgen, das es durch Nomiatim durch normale Suchanfragen gefunden wird. (wie markiert man einen Thread eigentlich als “gelöst” bzw. “erledigt”?
es ist ja jetzt nicht erledigt, vielmehr sollte man überlegen ob man nicht speziell für solche Situationen, wo es per Konvention postalische Zusätze gibt, die keinem place oder admin-Objekt entsprechen, einen neuen tag einführen könnte.
Die einzige Alternativ ist die Adresse nach dem “place” Schema zu erfassen → addr:housenumber=13, addr:place=Hainburg
Straße “Außenliegend” kann man ja drann lassen. Dann kann man mal schauen wie sich das auf die Suche auswirkt… 
Dann hätte ich noch eine unorthodoxe Idee… : Eine Dummy-Straße “Außenliegend” vor das Haus zu plazieren → highway=service, name=Außenliegend. Länge vom Weg: 5cm
Und dann wieder schauen wie sich das auf die Suche auswirkt. Ich könnte mir sogar vorstellen, das das die eleganteste Lösung für das “Suchproblem” ist.
PS @therdt: Jeder der eine Diskussion startet vergibt mit dem initialen Beitrag einen Namen für die Diskussion. Den Beitrag inkl. Titel kann er jederzeit editieren…
es gibt vermutlich weltweit noch mehr solche Codewörter für Adressen, die weder eine Straße noch einen Ort beschreiben. Ein tag dafür würde sich lohnen
Nur um meine Gedanken dazu noch beizusteuern - Ich war ne Woche auf dem Rad deshalb jetzt verspätet.
Wenn es keine Straße mit dem namen “Außenliegend” gibt sollte das nicht in addr:street sein. Fertig. Wenn das in addr:street steht versucht nominatim das in die Hierarchie zu packen und die entsprechende Straße zu suchen.
Also bleibt nur das “Außenliegend” in “addr:place” zu packen. Problem damit ist das es möglicherweise keinen place mit Außenliegend gibt. Den kann man leider dann nur “hinfaken”.
Ich habe hier ein “ähnliches” Thema. Es gibt die Gebäudesammlung “Bosfeld” in “Rheda-Wiedenbrück”. Durch Bosfeld führt eine Straße namens “Bosfelder Weg”. Die Adressen sind aber “Bosfeld 60, 33378 Rheda-Wiedenbrück” und die Hausnummern dazu willkürlich (Nach errichtung) verteilt.
Da ist jeweils dann ein addr:place=Bosfeld dran und KEIN addr:street. Natürlich existiert hier dann auch ein “place=hamlet name=Bosfeld” entsprechend.
D.h. in deinem Fall - für das Beispiel:
addr:place=Außenliegend
addr:suburb=Hainstadt
addr:city=Hainburg
addr:housenumber=13
So jedenfalls würde ich das machen. Wenn jetzt alle “Außenliegend” in derselben Ecke liegen könnte man da einen place=locality oder so nehmen (Wertet nominatim den aus?)
Flo
sorry, aber wenn es keine locality namens Außenliegend gibt sollte man sie auch nicht hinfaken
Ich werde bei sowas echt mürrisch. Wenn ich sehe was alles für den renderer dabei gefaket wird und alle Ackselzuckend daneben stehen ist das dagegen echt ne Lappalie. Am Ende faken wir hier die Hierarchie der Adresse für Nominatim.
Ja - wenn es nicht existiert dann sollten wir es nicht mappen. Hier existiert aber was namens “Außenliegend”. Was das ist ist nen bisschen unklar - also generalisieren wir das halt zu einer locality.
Flo
ich denke es ist völlig klar was „außenliegend“ ist, nämlich ein Adresszusatz für den Postboten, dass es sich um eine laufende Nummer für Adressen außerhalb der Ortschaft handelt. Das ist nichts, was geographisch eine Entsprechung hat (abgesehen davon, dass es eben nicht innerhalb einer Ortschaft ist). Daher wird es in OpenStreetMap dafür auch kein place Objekt geben, und sollte es auch nicht.
Es ist nur ein Adresscode, sonst nichts.
@flohoff: place=locality ist auf jeden völlig falsch!
Völlig klar? Sicher? 
Ein Suche der Adresse bei der Post liefert “Außenliegend Klein-Krotzenburg” für das Feld Straße.
Es wird wie eine Straße behandelt obwohl es keine Straße mit dem Namen gibt.
An dieser Stelle hat Nominatim ein Problem weil auf real existierende Straßen mit diesem Namen geprüft wird und deshalb die Suche fehlschlägt. Und genau deshalb existiert überhaupt dieses Thema hier…
Und jetzt brauchen wir neue Tags? Für was denn? Für Nominatim? Für Fake-Straßen: addr:fake_street… ?
Die Adresse “Außenliegend 13” paßt vom Format her exakt auf Straße + Hausnummer. Punkt.
… und Post lieft das Ergebnis unter Straße.
Wozu einfach wenn es kompliziert geht?!
Ganz einfache Lösung: Es wird für Nominatim eine Dummy-Straße mit dem Namen vor das Haus gelegt. So kurz und klein, daß sie in keiner Karte angezeigt wird…
Suche funktioniert. Der Rest interessiert effektiv niemanden. Fertig.
ja, die deutsche Post hat das als Straße einsortiert, weil sie es nicht so genau nehmen, reicht für sie. Wir haben aber ein weltweites System. Falsche Straßen eintragen ist keine Option
Welche Option denn??? Neuer Tag und dann?
“Weltweites System”… Richtig! Und das heißt jetzt konkret für diesen Fall???
Vielleicht hast du ja einen konkreten Plan… Ich nicht. Sorry.
ist ja im Prinzip völlig egal, wie der tag heißt, irgendwas mit addr:
z.B. addr:addition=Außenliegend
oder addr:supplement=Außenliegend
oder addr:description=Außenliegend
jedenfalls ist es weder place noch street