User Longbow4u hat zu dem Thema ein abgespecktes How-To geschrieben, wen es interessiert. siehe hier
Georg
So unverständlich finde ich die Fehlermeldung nun wieder nicht. Was sollte den sonst dort stehen?
Die Meldung kommt übrigens auch bei einer Kombination von Zahlen/Buchstaben. (z.B. 14D)
Eine weitere Meldung die häufig bei Interpolationen zu finden ist: “needless”
Dieser Fehler meint nicht benötigte Interpolationsways.
Im Beispiel wird kein addr:interpolation-Way zwischen den Nummern 44-46 und 45-47 (Kauderstr. / Marburggasse) benötigt.
Ropino
Vielen Dank Tordanik und Ropino für die Hinweis. Nun sind die Daten korrigiert (Endpunkte eingeben und needless Verbindungen entfernt) und die interpolierten Adressen werden bereits angezeigt.
Ich hoffe, dass Mapnik irgendwann einmal ebenfalls statt einer punktierten Linie die interpolierten Zahlen anzeigen kann.
In der All-in-one-Garmin Map werden Adressen ja leider überhaupt noch nicht direkt als Zahl angezeigt (weder interpolierte, noch einzelne).
Walter
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.