So, ein paar Adressen sind zur Wikiseite laut Thema-Start hinzu gekommen … schon interessant, dass verschiedene Navis bei der gleichen Adresse patzen. Woran mag das jeweils liegen?
Erstmal Korrektur: Neue Suche via Menütaste sucht anscheinend nicht nach Hausnummer, sondern nur nach Straße.
Hausnummernsuche über OldMenü:
Aktionen->Ort : Luedinghausen (ue oder ü geht beides)
Straßen : Münsterstraße
Hausnummer: 1
hast recht, es erscheinen auch andere Straßen dieser Hausnummer. 
Habe die Testfälle mal mit Mapfactor Navigator 11 free durchgespielt … fast immer ein Erfolg!!!
Nur der Ort Dahlenburg wird auch nicht gefunden, dort fehlt in den OSM-Daten offensichtlich die Boundary=administrative und/oder ein Node für den Ortsmittelpunkt, oder?
EDIT: habe für Dahlenburg in Niedersachsen eine Grenzrelation erstellt, unter Kopie der PLZ-Relation erstellt, sowie einen Punkt mit place=village erstellt … mal schauen wann in welchen Navi-Programmen der Ort wählbar wird.
Es scheint nach einiger Recherche so zu sein, dass eine relativ zuverlässige Zuordnung von Straßen zu einem Ort nur über die Methode “alle Wege innerhalb eines Polygons” zu realisieren ist.
Zumindest verfolgen wohl Mapfactor Navigator, OsmAnd und Monav dieses Ansatz. Für Orte ohne Begrenzung wird offensichtlich dann eine Umkreis-Suche benutzt, um die dazugehörigen Straßen abzuschätzen. (in welchen Gegenden fehlen noch die Ortsgrenzen?)
Nach allem, was man derzeit über diese Zuordnung bei Navit lesen kann, wird die Ortsgrenzen-Methode dort nicht angewandt.
Wenn man es den Navit-Autoren schmackhaft machen wollte, wie man solche Daten (Liste aller suchbaren Orte sowie Liste aller Straßen zu einem Ort) für ein Navigationsprogramm aus den OSM-Daten aufbereiten kann, welche schematischen Ansätze wären dafür nötig?
(Ähnliche Mechanismen werden doch bestimmt auch in der gerade neu aufgebauten Straßenlisten-Auswertung verwendet, oder?)
wenn ich mir die navit-svns so angucke scheinen die daran zu arbeiten. z.b. http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=3253
Hmmm, warum nehmen die nicht einfach die addr: -Nodes, da steht doch alles drin (Straße, Hausnummer, Stadt) ?
weil die für viele straßen noch nicht existent sind?
Das ist doch genau die Crux mit der bisherigen Navit-Methode, dass die zugehörigkeit JEDER Straße mit dem umstrittenen is_in-Schlüssel geregelt werden sollte.
Das is aber in Anbetracht der zum Großteil (zumindest für Deutschland) vorhandene Grenzpolygone für Gemeinden und/oder Postleitzahlen meiner Meinung nach Overkill.
Dass eine Zuordnung von Straße zu Ort auch mittels Polygone gut klappen kann, zeigen die im Vergleich zu Navit recht benutzerfreundlichen Programme Mapfactor Navigator oder OsmAnd (läuft bei mir übrigens via virtualbox mit android-x86 und dem apk von osmand.net auch auf WinXP) .
Wie sähe es denn nochmal mit ein paar adressen aus, welche irgendein Naviprogramm NICHT finden kann, wer hätte da was aus seiner Umgebung? Oder klappt bei euch jegliche Adressuche perfekt? 
Stephan meinst du die Adresssuche in der AIO in den Garmingeräten?
Gruß Jürgen
Ich denke schon. Zwar kenne ich mit Garmin-Geräten und den Prinzipien der dortigen Adress- und POI-Datenbanken nicht so aus, aber die Fragestellung dieses Threads und der genannten Sammlung auf der Seite im Wiki zielt auf JEDE Möglichkeit (hm … außer Online-Suche per Nominatim) wo ein Benutzer in einem Programm oder auf einem mobilen Gerät eine (postalische) Adresse eingeben kann, um den Zielpunkt sich anzeigen lassen zu können, z.B. zwecks Navigation.
(Der Abschnitt auf der “Wikiseite zur Adresseingabe” zu Garmin-Karten ist ja noch leer … wie funktionert denn dort die “Liste aller Orte” und “alle Straßen zu einem Ort”?)
Stephan,
es gibt da schon ein Thema Adressen finden…
http://forum.openstreetmap.org/viewtopic.php?id=10310
dort nimmt sich Martin @ railrun dem Problem auch schon an.
Er hat auch schon Verbesserungen vorgenommen. Er rendert eine Karte mit Adress Indexsuche.
Eventuell liest du den Thread mal schräg.
Vielleicht bekommen wir das zusammen ja hin.
Gruß Jürgen
edit Schreibfehler
das is_in wird meines Wissens nicht ausgewertet bei Navit, zumindest bei meinem Test wurde es das nicht.
Mit Ortsnamen gebe ich dir recht. Wenn ich jedoch mit Postleitzahlen suche, werden nach meiner Erfahrung nur PLZ angezeigt, die über ein boundary=postal_code erfasst sind.
… und das soll doch auch so sein, oder?
Wie man auf der PLZ-Seite des OSM-Inspectors von geofabrik.de sehen kann (http://tools.geofabrik.de/osmi/debug.html?view=plz&lon=10.39958&lat=53.16690&zoom=8), fehlen für Deutschland nur noch wenige Gebiete, in denen die Grenzen aus dem damaligen “Import” nachgetragen werden müssten.
Eine genauere Zuordnung von PLZ zu Ort kann man doch gar nicht realisieren … oder was fehlt dir da jetzt?
Ich spreche aus Erfahrungen hier im Umland. Such im Navigator free z.B. mal 779??-PLZ, und du wirst nur drei in Offenburg (7795*) finden, die eine boundary=postal_code haben. Z.B.:
http://www.openstreetmap.org/browse/relation/1250905
Im Umland hängt die PLZ am administrative, was nach meinem Wissen Wiki-gerecht ist.
Beispiel:
http://www.openstreetmap.org/browse/relation/452990
Die wertet Mapfactor offensichtlich nicht aus.
Edit: Wiki>
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010
@Michael:
Jaaaaaaa [frohlock!!] … genau DIESE Problematik habe ich vor kurzem in diesem Thread beleuchtet:
http://forum.openstreetmap.org/viewtopic.php?id=12726
Meine Konsequenz aus diesem Thread: ich erfasse derzeit ZWEI Relationen, auch wenn die PLZ- und Gemeindegrenze identisch ist.
Im Detail: wenn mapfactor Navigator die PLZ nicht findet, was macht denn z.B. OsmAnd aus den PLZ? (… jeder mit einem Windows- oder Linux-PC kann Osmand und andere Android-Apps testen, mittels VirtualBox o.ä. und android-x86.org)
Aber wir mappen doch nicht für…
Die Alternative wäre doch, dass die Auswertungsroutinen auch über die administrative gehen. Zwei Relationen über identische ways/nodes sind nachträglich umständlich zu bearbeiten und fehleranfällig.
Auf landuse=residential hängt oft auch noch ein PLZ-tag…
Neuigkeiten:
Bei einigen Adressen, welche OsmAnd nicht finden kann, habe ich eine Vermutung woran das liegt.
Dafür brauche ich aber mal eure Hilfe:
Wer kann mir aus den OSM-Rohdaten für ganz Deutschland (oder zur Not nur Norddeutschland oder Niedersachsen) eine Liste erstellen mit allen Relationen, die das Merkmal “de:amtlicher_gemeindeschluessel” gesetzt haben?
Kann jemand mir diese Daten (wahrscheinlich aus einer Datenbank?) exportieren in Form einer Datei für Tabellenkalkulation mit mindestens folgenden Spalten:
OSM-ID der Relation
Name=
de:amtlicher_gemeindeschluessel=
boundary=
admin_level=
Denn ich vermute, dass etliche Grenzpolygone für Ortschaften statt den “üblichen” admin-level=8 eher den Wert 7 gesetzt haben.
Dies wertet Osmand dann NICHT aus.
Frage in Bezug auf http://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dadministrative :
Gibt es anhand der hoffentlich generierbaren Liste laut oben Gemeinden, wo admin_level=7 falsch ist, stattdessen müsste 8 hin?
Oder sollte OsmAnd neben admin_level=8 auch die 7 mit auswerten?
Es gibt Bundesländer wie BaWü, die Verbandsgemeinden (admin_level=7) haben und ander, die das nicht haben. Das ist ähnlich wie mit den Regierungsbezirken (admin_level=4), die auch nur wenige Bundesländer haben/brauchen.
Also sollte jedes Programm, das nach Adressen suchen will, auch die admin_level=7 auswerten.
JM2C
Edbert (EvanE)
Wenn ich mich recht entsinne gab es dieses/ähnliches Problem auch bei http://wiki.maposmatic.org/doku.php?id=faq#what_should_i_do_when_the_administrative_boundary_of_the_city_i_m_looking_for_is_missing