Meines Wissens die openmtbmap. Hab es aber noch nicht ausprobiert, bei meinem Etrex
funktioniert die Adresssuche ja auch ohne die MDR Index Datei.
Grüße
Chris
Felix, von openmtbmap meinete das dies evtl. aber der nächsten Verion möglich sei…
Ich freu mich schon drauf, dann könnte man die Garmin.Karten von OSM auch auf dem richtigen Navi einsetzen…
Also, in Mapsource funktioniert die Suche mit der openmtb schon ganz gut.
Auf dem Nüvi kommt weiterhin die ominöse Abfrage nach State/Provinz und dann gehts nicht weiter.
Chris
Nochmal zum eigentlichen Thema Hausnummern-Mapping-Aufruf:
Hier die aktuellen Daten:
Germany: Informations based on the Germany excerpt from the 2009-11-12 06:37
addr:housenumber: 473915
addr:interpolation: even (11201), odd (11045), all (3294)
Vergleich:
Germany: Informations based on the Germany excerpt from the 26-Oct-2009 05:36
addr:housenumber: 449037
addr:interpolation: even (10870), odd (10816), all (3053)
Knapp 24000 Hausnummern sind in 2 1/2 Wochen dazugekommen. Nicht schlecht !
Viele Grüsee
Teddy73
Schon gesehen? Der neue Namefinder nominatim kann nun auch hausnummerngenau suchen.
Allerdings muss man weiterhin erst die Straße und dann die Stadt ins Suchfeld eingeben.
http://wiki.openstreetmap.org/wiki/Nominatim
Scheint allerdings nicht mit allen Hausnummern zu funktionieren, nach erstem Test.
Update: Adress-Interpolation funktioniert auch damit. Die Search DB wird ca. alle
2 Tage aktualisiert.
Chris
Ich hab mal die Leute von Openrouteservice angeschrieben:
Hi Thomas,
…Die Interpolation Line werden bereits ausgewertet, ein OSM Daten Updates des Service liegt allerdings leider schon etwas zurück. Ich war die vergangene Zeit im Urlaub und…
grüße
xxxx
Mal ne dumme Frage: könnte man, sofern eindeutig
addr:postcode
addr:city
addr:country
nicht einer umgebenden Fläche zuweisen des typs
landuse residential
mit der Vereinbarung, alles was darin ist, hat bei Bedarf auch o.g. tags ?
(Schlieslich wird addr:street doch auch automatisch aus der nächstliegenden Straße zugewiesen - sofern ich richtig verstanden habe)
Und wozu soll das gut sein? Um die Redundanz zu vermindern?
Die Adress-Interpolation bietet doch schon eine elegante Möglichkeit Hausnummern
datensparend einzugeben.
Chris
Damit ich schlicht und einfach nur noch
addr:housenumber
und evtl.
addr:street
einzugeben habe, und der Rest eben automatisch mitvergeben ist.
Ich kann mich dann voll auf die verschiedenen Feinheiten von addr:housenumber stürzen und brauch mir um die Richtigkeit der übrigen tags keinen Kopf mehr zu zerbrechen. Klar, bei größeren Städten mit mehreren PLZs müßte addr:postcode weiterhin an jedes Objekt gehängt werden.
Ach ja, ich muß es leider gestehen: Ich habe das Karlsruhe-Schema leider falsch verstanden
und bisher die erstgenannten tags nicht vergeben, da ich dachte, diese könnten zentral für den ganzen Ort definiert werden.
Mit dem Anhängen an landuse residential könnte ich meine tags auf einfache Art und Weise auf Vordermann bringen.
Hi Gibuld,
die Josm Vorlage vergibt doch automatisch die Werte, die auch beim letzen mal drin waren, oder du selektierst am Ende alles und vergibts die PLZ und so allen auf einmal.
Oder nimmst du Potlatch?
Gruß
zorque
Genau, ich nehme Potlatch, und da gibt es eben ein Problem.
Ich kann zwar tags kopieren, aber dann sind die bestehenden auch überschrieben.
Achso 
nimm Josm, da is ganz einfach g
Noch einfacher ist, an Richard einen Request zu schreiben, er soll einen Kopiermodus in Potlatch einführen, wo nur fehlende tags kopiert werden, bestehende aber nicht verändert werden. Dieses Problem hatte ich schon öfters.
Dennoch, meine Frage hatte ich nicht nur wegen meiner eigenen Probleme gestellt, sondern halte sie nach wie vor ganz allgemein für sinnvoll.
Also die neue Suche Nominatim zeigt eigentlich recht schoen, das man auf addr:city und addr:country und zum teil sogar addr:street recht gut verzichten kann und die information von polygonen wie die admin_boundries berechnen kann. Wie man auf http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview nachlesen kann funktioniert der Suchalgorithmus, indem er jedes addr:housenumber Objekt nach dem folgenden Schema Strassen zuordnet. Wenn die Hausnummer teil einer assosiateStreet Relation ist, dann ist die Sache eindeutig, ansonsten wenn addr:street vorhanden ist wird per name die Strasse gesucht und zugeordnet. Ansonsten wird die naechst gelegene Strasse genommen. Um die Strasse dann der Stadt, Land zuzuweisen, werden alle boundary Polygone genommen die die Strasse einschliessen. Desweiteren wird noch eine nearest neighbour suche nach place= nodes durchgefuehert um auch die Orte zu bekommen, die bislang noch nicht als boundary Polygon definiert wurden zu finden. Das wird aber hoffentlich irgendwann ueberfluessig sein, und man braucht nur noch die genauere Polygon Zuordnung.
Also aus meiner Sicht, waere es sinnvoller anstelle an jedes addr:housenumber Objekt die addr:city, addr:country, … tags zu duplizieren, die boundary polygone der Orte auf vorderman zu bringen.
Natuerlich ist diese tagging weise fuer die Software wesentlich aufwendiger, ich halte es aber trotzdem fuer die bessere und fuer den Mapper einfacher Loesung
Ich verstehe das Problem nicht ganz. Ich mappe im Moment auch Hausnummern mit Potlatch.
Meine Vorgehensweise ist:
- Node setzen
- einen nahegelegenen Hausnummern-Node anklicken (nur notwendig, wenn man zwischenzeitlich etwas anderes slektiert hatte oder wenn man die Attribute eines ganz bestimmten Hausnummer-Nodes übernehmen möchte)
- dann nochmal den neuen Node anklicken
- auf “Attribute übernehmen” klicken (der runde Pfeil rechte unten)
- Hausnummer ändern (und nötigenfalls auch die Strasse, falls das die erste Hausnummer einer Strasse ist, ansonsten übernimmt man natürlich sinnvollerweise die Attribute eines Hausnummern-Nodes der gleichen Strasse)
Das ist im Ablauf noch viel einfacher als die Beschreibung.
Kann natürlich sein, dass es etwas umständlicher wird, wenn man Attribute von Einzel-Nodes auf Interpolationen übernehmen will. Das Problem habe ich hier nicht, weil ich hier alle Hausnummern einzeln als Nodes setzte.
Detlef
Nachtrag:
Sorry, jetzt habe ich das Problem erst verstanden! Du musst vorhandene Hausnummern-Nodes ergänzen. Was ich hier beschrieben habe, gilt natürlich nur für das Neuanlegen von Nodes.
Das Verhalten von Potlatch bei der Übernahme von Attributen ist eigentlich schon logisch. Es wäre schlimm, wenn vorhandene Attribute grundsätzlich immer erhalten blieben. Die Übernahme von Attributen unter Beibehaltung bereits vorhandener Attribute könnte eine zusätzlich Option sein. Das widerspräche aber dem Prinzip der einfachen Bedienung von Potlatch (die Bedienung verkompliziert sich für jeden, obwohl die Funktion nur wenige brauchen → siehen JOSM oder Microsoft-Produkte ;-)).
Daher würde ich in diesem Fall auch eher zu JOSM greifen, als Potlatch durch zustätzliche Funktione zuverkomplizieren. 
Hallo amm,
Danke für deinen wertvollen Beitrag. Damit scheint die Frage wohl ziemlich geklärt. Nur eines noch: Ich bin nicht vertraut mit der Kartenerstellung. Wie ich’s verstehe muß zur Adresssuche ein Index erstellt werden und dies kann seit kurzem mit mkgmap erreicht werden, wobei unsere addr: tags zusammengeführt werden. In deinem Link wird hinsichtlich Nominatim folgendes aufgeführt:
*Nominatim comprises of:
osm2psql output routine
postgresql module
set of plpgsql functions
php management / interface
*
Ich lese da jetzt nichts von mkgmap. Läuft das trotzdem wie erhofft ?
@dgdg
Wieso wäre Potlatch verkompliziert, wenn es ausser R und Shift-R z.B. noch einen Alt-R Kopiermodus gäbe ?
Wer’s nicht braucht, merkt nichts davon, wer’s braucht kann danach suchen und ist glücklich es zu finden.
Hallo Gibuld,
mkgmap macht ja nur Karten für Garmin-Geräte. Mit diesem Index hat Nominatim nichts zutun. Nominatim sucht die Adressen für Onlinekarten.
Wie mkgmap allerdings die Adressen Koordinaten zuordnet weiß ich nicht.
Was ist denn die nächst gelegene Strasse? Da kann ich mir viele Situationen vorstellen, wo das schiefgeht, z. B. an den Kreuzungen (Eckhäuser) und bei sehr eng parallel verlaufenden Strassen. Auf so ein Routing möchte ich mich nicht unbedingt verlassen.
Also ich denke ein addr:street sollte doch auf jeden Fall vorhanden sein, sonst sind die Ergebnisse beim Routing unvorhersehbar. Alles übergeordnete könnte man über Boundaries abdecken.
Aber wie oben schon geschrieben, ist das Setzen der Nodes inkl. alles Tags mit Potlatch überhaupt kein zusätzlicher Aufwand. Aufwändig wird’s erst dann, wenn man großflächig ändern möchte.
Detlef
Volle Zustimmung. Das Ziel sollte sein, dass Straße + Hausnummer eindeutig ableitbar sind. Die geratene Straße ist in meinen Augen nicht besser als garkeine Straßen. Wenn ich die Adresse A-Straße 1 suche, suche ich doch nicht bei der kreuzenden B-Straße, ob er die Adresse dort gespeichert hat.
Hallo Henning,
Ich frag mich jetzt, stehen wir nun mitten im Urwald, oder auf einer Lichtung, wie ich erhofft hatte. Eine Regel sollte doch für alle Verfahren gelten, nach welchen OSM-Karten erstellt werden. Gerade die Garmin-Karten werden doch für Navigation verwendet, wo die Adresssuche von besonderem Interesse ist.
Übrigens: Eines habe ich bei der Priorisierung von Nominatim nicht verstanden: Je näher an einem Objekt ein tag definiert ist, desto niedriger die Priorität. Dies widerspricht meinen ganzen Erfahrungen mit Programmiersprachen: Lokale Variable haben dort immer Vorrang vor globalen.
Zum Thema addr:street
Klar, überall wo es überhaupt fraglich ist, welche Straße gemeint sein könnte, ist dieses tag unbedingt zu setzen. Es gibt aber viele Fälle, wo auch ein Blinder mit Krückstock (politisch unkorrekt!) nur eine einzige Straße finden könnte die zu dem Objekt passt. Warum sollte man da nicht die Freiheit zum Verzicht ausüben ?
Gruß,
Gibuld