Ich starte hier mal einen neuen Thread, da diese überlangen Threads unübersichtlich sind und teilweise mittlerweile überholte Informationen enthalten.
Ich habe jetzt mal versucht eine Garminkarte mit funktionierender Adresssuche zu bauen. Dabei folgte ich den Anweisungen von [1]. Das hat auch schon mal einige Ergebnisse gebracht. Aber ich kann nur relativ wenige Adressen finden. Daher nun ein paar Fragen zum Verständnis:
Wenn man die bounds selbst berechnet [2], gibt es dafür eine maximale Größe der Datei? Könnte man also einen ganzen Planet so bearbeiten? Schließlich müssen die Grenzpolygone ja ohne Lücken sein.
Welches Adress-Schema wird ausgewertet, bzw. welche Tags und Polygone liefern, welche Informationen?
Umlaute scheinen auch nicht zu funktionieren. Ist das normal?
Also, ich vermute der ganze Kram funktioniert hier nicht, weil die downloadbaren Bounds wohl nicht die Grenzen enthalten, die als type=multipolygon erfasst sind. Bei uns hat das jemand mal alles umgestellt.
Wie müßte der Osmosis- oder osmconvert-Aufruf lauten, um beide Grenztypen zu erwischen?
Wenn ich dann doch mal eine Straße gefunden habe, taucht diese gleich mehrfach (für jedes Teilstück einmal) auf. Das ist für längere Straßen ungünstig, da diese teilweise ja auch in anderen Stadtteilen liegen, und eigentlich soll das Garmin mir ja verraten, wo die entsprechende Hausnummer ist.
Wie sieht es mit den Straßennamen aus, wenn diese über eine ‘type=associatedStreet’-Relation eingebunden sind? Hat nämlich hier auch jemand mal verwendet. Kann mkgmap damit umgehen?
Nutzt mkgmap denn immer die Orts-Daten, die aus den Grenzen ermittelt? Wenn also Ort A zur Gemeinde B (‘admin_level=7’) gehört, und die einzelnen Adressen in Ort A auch mit 'addr:city=A-Dorf" getaggt sind, findet man diese dann unter A-Dorf oder Gemeinde B? Könnte man sonst im Stylefile eine entsprechende Regel voransetzen, daß A-Dorf genomen wird, sofern vorhanden?
Was mir im Stylefile auch nicht klar ist, ist der dreistellige Ländercode “DEU”. In ‘addr:country’ verwenden wir doch ‘DE’. Irgendwie habe ich auch geschafft, daß das Gamrin zwischendurch sowohl Deutschland als auch Germany als Land angeboten hat.
Ich finde das Ganze schwer zu verstehen, wenn man nicht genau weiß, wie mkgmap die Tags mkgmap:country, mkgmap:city etc. automatisch füllt. Da hilft mir weder das default-Stylefile noch die Ausgabe von ‘mkgmap --help=options’ so richtig weiter.
Railrun (Martin) might know something about this. You can also try one of my maps on www.navmaps.eu to see if you find more streets. There you can find more info on city/street search in the developers section. Ideally a country is covered with the right residential boundaries in one admin_level. Not a single European country matches that yet. My country, The Netherlands, is doing its best with a nice cover of admin_level 10 for small villages and for cities like Amsterdam and Rotterdam.
Setting I use for the German part of the style files lines, point and polygons:
mkgmap:country!=* & mkgmap:admin_level2=* { set mkgmap:country=‘${mkgmap:admin_level2}’ }
mkgmap:country=DEU & mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region=‘${mkgmap:admin_level4}’ }
mkgmap:country=DEU & mkgmap:region!=* { set mkgmap:region=‘${mkgmap:admin_level2}’ }
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city=‘${mkgmap:admin_level8}’ }
The trick is using boundaries (in my case only for level 8), then the nearest option in case mkgmap can’t find the level 8 boundary. Big problem in the admin_levels used in Germany: sometimes level 8 is perfect (Beilstein, Cochem), sometimes level 8 is not good enough (Edewecht, one level 8 boundary, several villages inside this single boundary). The standard style-file setting uses various levels for Germany. In theory a good idea, in practice not good enough: how to find these different villages in Edewecht, like Friedrichsfehn?
geht mir genauso. Zumal die Grenzrelationen z. B. die deutsche #51477 (Link überflüssig, da Ladefehler, zu groß…) kein Tag den Wert “DEU” enthält. Also müsste dieser Code “irgendwo”, also entweder bei der Erstellung der Bounds, oder in mkgmap hartverdrahtet sein. Kann ich mir aber, ehrlich gesagt, nicht vorstellen. “de” könnte ich mir noch vorstellen, das könnte aus dem dem ISO3166-1 tag hervorgehen. Aber DEU???
Daher versuche ich, auf meiner serseite die Infos erstmal kompakt in einer Tabelle zusammenzufassen.
Das Problem ist, dass ich die Regeln nicht wirklich selbst kenne, sondern auf langwierigen Tests und Annahmen beruhen. Das Wissen möchte ich gerne weitergeben.
Aha. Die Info würde ich gerne auf meine Wikiseite übernehmen. Ist das irgendwo dokumentiert, bzw.
welcher Ländercode wird verwendet? Könnte bzw. müsste der Alpha-3 Code nach http://de.wikipedia.org/wiki/ISO-3166-1-Kodierliste sein. Ich möchte eigentlich keinen Test starten müssen, um reverse-engineering an einer reverse-engineerten Software durchzuführen
Die Datei mkgmap/resources/LocatorConfig.xml enthält die Daten, um aus den ziemlich inkonsistenten OSM Daten etwas konsistentes für die Karte zu machen.
Warum man sich da aber für DEU entschieden hat? Ich denke man wollte einheitlich 3-Letter Codes wie sie auch die UN verwendet: http://www.worldatlas.com/aatlas/ctycodes.htm
die in mkgmap integrierte LocatorConfig.xml ist aus den Daten der Wikipedia erstellt worden. Es wird wie vermutet der Alpha-3 Code verwendet.
Warum ist auch mir unbekannt. Soweit ich weiß, kann man auch jeden anderen Code verwenden.
Falls Ihr Vorschläge für eine bessere Codierung habt, bitte auf der mkgmap Developerliste posten. Wenn es Zustimmung findet, kann ich das gerne ändern.
Änderungen halte ich nicht für nötig. Die Zuordnungen sind eindeutig und vollständig definiert, und einige Styles bauen auf die bisherigen Codes auf. Nur, finde ich es leider nicht dokumentiert. Das kann ich gerne ins Wiki übernehmen, falls ok. Wäre sehr nett wenn da noch ein paar Augen drüberschauen: http://wiki.openstreetmap.org/wiki/User:Yggdrasil/WikiChanges
Es werden die folgenden Tags (nicht nur :country, :region und :city):
mkgmap:country
mkgmap:region
mkgmap:city
mkgmap:postal_code
mkgmap:street
mkgmap:housenumber
mkgmap:phone
(mkgmap:is_in - used by location-autofill=is_in)
Das könnte da noch ganz gut als Ergänzung hinpassen.
Die admin_levels gehen von 2 bis 11 und nicht 1 bis 10.
Der Kommentar zu 3 ist nicht ganz richtig. Die admin_level Tags werden nur über die precompiled bounds gesetzt (location-autofill=bounds).
Für alle Items, bei denen nach Durchlaufen der Style Files noch keine Werte für :country, :region oder :city gesetzt sind, kann man dann noch location-autofill=is_in,neareast hinzufügen. Dort wird zum einen der is_in Tag etwas intelligenter ausgewertet und zum anderen die nächstliegenden place=* Nodes herangezogen. Dieses zweigeteilte Vorgehen ist sicherlich etwas gewöhnungsbedürftig, hat aber teilweise historische und technische Gründe.
Da es ein Wiki ist, dass davon lebt Sachen einzutragen und zu verändern, würde ich empfehlen, es einfach einzutragen. Super wäre, wenn Du die Beschreibung auch von passenden Stellen aus verlinkst.
soweit, so gut - aber eine kleine Frage hätte ich noch. Weiß jemand, wie sich das mit den mkgmap-Optionen
–country-name, --country-abbr, --region-name, --region-abbr verhält? Werden damit nicht die Felder mkgmap:country und mkgmap:region initialisiert?
Bei einem Test mit meinem Nüvi werden leider alle Punkte außerhalb Deutschlands als in Deutschland gelegen angezeigt - es bietet keine anderen Länder zur Auswahl an, obwohl ich mkgmap:country explizit per
set mkgmap:country=mkgmap:admin_level2
setze. Scheint irgendwie so, als ob sich mkgmap:country nicht überschreiben lässt. Aber das kann ich mir irgendwie nicht vorstellen
Die konfigurierten Werte werden für alle Elemente verwendet, die nach dem Abarbeiten der gesamten Locator-Logik das entsprechende Feld noch nicht gesetzt haben.
