Adressen finden in OSM mit Garmin

Communities Deutschland (Germany)
121

@Railrun:

Leider habe ich eben festgestellt, dass die Suche doch nicht funktioniert. Ich habe mein oben genanntes Skript mit Deinen Optionen im mkgmap-Aufruf und Deinen Stylefiles und Deinem Typfile verwendet:


echo off

set drive=%cd:~0,3%
set tilesdir=%drive%map\OSM_Tiles
set centraleuropepath=%drive%map\Centraleurope.osm
set templateargspath=%tilesdir%\template.args
set mkgmapoutputdir=%drive%map\Output
set boundspath=%drive%map\Boundaries

set osmosispath=%drive%map\Osmosis-0.39
set splitterpath=%drive%map\Splitter-r174
set mkgmappath=%drive%map\mkgmap-locator-r1969
echo.
echo.

cd %drive%map
echo on

wget http://download.geofabrik.de/osm/europe.osm.bz2

7za e -y europe.osm.bz2

java -Xmx1100m -cp "%osmosispath%\lib\default\plexus-classworlds-2.2.2.jar" -Dapp.home="%osmosispath%" -Dclassworlds.conf="%osmosispath%\config\plexus.conf" org.codehaus.classworlds.Launcher --read-xml file="europe.osm" --bounding-box idTrackerType=BitSet top=60 left=4 bottom=47 right=16 --write-xml file=%centraleuropepath%

cd %splitterpath%
java -Xmx1100m -jar splitter.jar --cache==%drive%map\temp --max-areas=70 --max-nodes=900000 --output-dir=%tilesdir% %Centraleuropepath%

cd %mkgmappath%
java -Xmx1100m -jar mkgmap-locator-r1969.jar --boundsdirectory=%boundspath%  --latin1 --series-name=Germany --family-name=Germany --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines --location-autofill=0 --country-name=Deutschland --country-abbr=DEU --area-name=DEU --output-dir=%mkgmapoutputdir% --style-file=%drive%map\Railrun_Style -c %templateargspath% %drive%map\Railrun_Style\basemap.TYP
pause

Wenn ich z. B. die Friedrichstrasse in Berlin suche, dann schlägt mein eTrex Vista Hcx beim Eintippen der Straße bereits “Friedrichstrasse” vor. Wenn ich dann auf OK klicke, erscheint nur “nichts gefunden”. Wenn ich bei der Adress-Suche mit “Hamburg” beginne, findet er nicht mal diese, d. h. alle Adressen in Hamburg sind unauffindbar.

Jetzt habe ich mal testweise per MapInstall nur die Kachel mit dem Zentrum von Berlin auf die SD-Karte gespielt. Dann funktioniert auch die Suche nach der Friedrichstraße. In der von Dir berechneten gmapsupp geht es, obwohl dort viele Kacheln drauf sind. Wenn ich jetzt mit dem Ergebnis obigen Skripts ca. alle Kacheln von Deutschland (bzw. etwas mehr) auf die SD-Karte übertrage, geht es wieder nicht.

Der Unterschied zu Deiner Karte scheint mir hauptsächlich die Zahl und Größe Deiner Kacheln, bzw. die mkgmap-locator-Version zu sein. Oder gibt es noch andere Unterschiede?

Kannst Du mal den Rest Deines Skripts posten (Splitter-Aufruf, etc.)?

122

Hallo wind,

wo fängt man an?!
Erst einmal etwas optimierung :slight_smile:
Warum verwendest du nicht pbf-Dateien. Bei Europa macht das 2.5 gb weniger Traffic. Weiterhin reduziert sich die Verbarbeitungszeit um ca. 25-30 %.
Osmosis (pbf-Ein-&Ausgabe), Splitter(z. Zt. nur pbf-Eingabe, Ausgabe als .gz-Datei oder mittels gepatchter Version auch pbf-Ausgabe). Damit der Locator-Branch pbf verarbeiten kann, muss die locator.jar-Datei in das Standardverzeichnis von mkgmap-kopiert werden (da wo osmprotobuf.jar und protobuf.jar liegen).

Meine Verabeitung sieht recht einfach aus. Die pbf-Datei lade ich mir mit Firefox&DownThemAll direkt von der Geofabrik runter.
Danach:


java -Xmx1500M -jar splitter-r175/splitter.jar --mapid=63240345 --split-file=./tiles_germany_patch/areas.list --pbf --output-dir=tiles_germany_patch ./germany.osm.pbf
java -Xmx1500M -jar ./mkgmap-r1962/mkgmap-locator-r1969.jar --boundsdirectory=bounds --latin1 --series-name=Germany --family-name=Germany --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines --location-autofill=0 --country-name=Deutschland --country-abbr=DEU --area-name=DEU --family-id=4 --product-id=45 --style-file=./master/basemap_style/ ./tiles_germany_patch/*.osm.pbf basemap.TYP

Areas.List-Datei
Folgende Hinweise dazu: Ich verwende wie oben beschrieben die pbf-Variante. Entweder du lädst dir die o. g. Splitterversion runter oder du änderst die Zeile.
Mehr Hexerei ist nicht dabei :slight_smile:
Wegen Hamburg:
Dort gibt es kein Admin-Level 6 sondern nur 4. Ich bin mir nicht sicher, welches amdin-level für Hamburg richtig wäre. Es ist ja mit Berlin gleichgestellt. Bei Berlin verläuft aber noch ein Admin-Level 6 drum herum.
Man könnte über folgende Zeile in den Style-Dateien probieren das Problem zu umgehen:


mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level4=* { set mkgmap:city='${mkgmap:admin_level4}' }

Diese Zeile kommt ganz ans Ende des “mkgmap:country=DEU & mkgmap:city!” Abschnittes.
Wenn es funktioniert, sag bitte bescheid.

P.S.: Benutze nicht die “mkgmap-locator-r1977.jar”-Version. Die liefert eine fehlerhafte Index-Datei. Ist der mkgmap-Dev-Liste schon bekannt. Gleiches gilt auch für die mkgmap-Version von r1970 bis r1973.

123

So, es gibt mal wieder ein Update.

Direkt für Garmin-Geräte (nur entpacken&kopieren):
MD5-Summen:


MD5 (20110712gmapsupp.img.zip) = 67f65c1c455db7bcd5d3b752d5bf21d4
MD5 (SRTM.zip) = 0870ab05aec9cb6c2a913826fcc4ebc7

SRTM-Layer (Höhenprofil) als eigenständige Karte => geht nur bei neueren Garmin-Geräten

Was ist neu:

  • Locator&City-Region-Branch wurde verwendet

  • dadurch sind jetzt Städte mit gleichen Namen in unterschiedlichen Regionen findbar, z. B. Neustadt in Schleswig-Holstein und Sachsen

  • durch Änderung an der Styledatei ist auch Hamburg durchsuchbar (fehlendes Admin-Level=6 um Hamburg)

Ich bastel gerade viel am Style rum, da ich es für mein Nüvi optimiere. Durch einen Fehler erscheinen einige Straßen recht spät/gar nicht. In der nächsten Karte tauchen diese dann wieder auf.
Außerdem gibt’s bei Stuttgart das Problem, dass es in -Ost/-Nord/-West/-Süd/-Mitte unterteilt ist. Das lag an falschen Admin-Levels in Stuttgart. Die benötigten Boundaries werden aber nur selten aktualisiert, deswegen weiß ich nicht, wann das Problem behoben ist.

124

Woran liegts? Daran, dass Nominatim steht? Oder woher bekommt ihr die Grenzen? Ich verfolge Deine Posts hier mit sehr großem Interesse…auch wenn ich nichts schreibe. Andere vermutlich auch. Vielleicht können wir helfen?

125

Nein… die Grenzen werden aus einem Extrakt gewonnen…das dauert aber immer recht lange. Außerdem sind gerade die Grenzen von Luxemburg kaputt (oder evtl. schon wieder ganz).

126

Hallo SunCobalt,

danke für die angebotene Hilfe. Die Grenzen werden mittels Osmosis aus den Europa-Datensatz extrahiert und zusammengeführt. WanMil hat da ein mehrzeiliges Skript dafür.
Danach werden die Grenzen “aufgearbeitet”.
Ich frage mal WanMil nach dem genauen Befehlen. Wenn jemand einen leistungsstarken Rechner hat, wäre das Prima.

127

kann man da helfen? Leistungsstark ist relativ, aber Rechenzeit habe ich noch. Um wieviel gehts?

128

http://wiki.openstreetmap.org/wiki/Mkgmap/help/usage#Addressindex_with_locator-branch
Hier gibt’s die Anleitung :slight_smile:
Wenn jemand helfen kann, wäre super.

129

nur eine letzte Frage noch. Wie lange dauert das, wieviele Kerne brauchts dazu, wieviel Upload und wie oft? Eventuell gebe ich Dir gleich ne Shell.

130

Also mit Osmosis hat es auf meinem MBP DualCore für Deutschland schon ziemlich lange gedauert (ca. 6 h).
Mit osmconvert geht es wohl deutlich schneller. Eigentlich ändert sich an den Grenzen nicht viel (sollte man denken), deswegen wäre es eher so etwas “nach Bedarf”. Die meisten Fehler kommen jetzt auch erst zum Vorschein, wenn man ganze Städte nicht findet.
Als upload benötigt man die gesamte Europa-Datei, was aktuell 6 gb sind. Danach könnte man ja mit Diffs arbeiten. Vielleicht liegt auf dem Rechner ja auch eine aktuelles Spiegelbild der europa-Datei?!

131

Thomas, mit osmconvert und o5mfilter geht es deutlich schneller. Ich bin damals daran gescheitert, dass er sich bei dem Europa-Extrakt immer verabschiedet hat. Der Entwickler konnte das Problem aber nicht reproduzieren. Evtl. klappt es bei dir ja auch.

Das sollte dann in etwa so aussehen:

osmconvert.exe --drop-author D:\dump\europe.osm.pbf > data\europe.o5m

o5mfilter.exe data\europe.o5m --keep-ways-relations=“boundary=administrative =postalcode” > data\boundary.osm

132

Martin: die Größe stimmt nicht… man Filtert aus europa ja nur die Grenzen raus…da sind ungefähr 300-400mb

133

europe.osm.pbf wäre der Download. Ich frage mich, wie groß das Resultat wäre. Aber vermutlich nicht so groß. Wenn es mit osmconvert schneller als 6 Stunden geht, dann ist es kein Problem das einmal die Woche zu berechnen und der Allgemeinheit zur Verfügung zu stellen.
Schicke mir mal bitte eine Mail in OSM wegen der Zugangsdaten. osmconvert ist bei mir noch nicht drauf, osmfilter und osmfilter64 schon. Aber das kriegen wir hin. Die Daten für Europe habe ich eh alle zwei Wochen, dann holen wie sie eben wöchentlich. Ich hoffe Du kennst Dich mit Linux aus.
Ich schicke Dir dann morgen früh die Login Daten

134

wieviele Leute brauchen denn sowas, also so ausgeschnittene Grenzen? Ich kenne mich damit nicht aus. Sind es 2 oder 20 oder 200?

135

Hallo Thomas,
wenn du sowas rechnen würdest, dann wäre es sinnvoll Schritt 4 auch noch zu rechnen und das Verzeichnis dann als zip oder ähnlichem anzubieten. Wie viele das laden kann ich dir nicht sagen. Derzeit ist das ja eher weniger populär in der Masse, sodass wohl nur die Experten damit rumprobieren. Letzlich wird es jeder laden, der Karten mit Adresssuche erstellen will. Das kann dann in naher Zukunft schon einiges an Traffic sein.

Aber das könnte man dann evtl. auch bei der gwdg spiegeln. Die haben noch Traffic frei, man muss sich nur bei dem Admin melden. Kontaktdaten könnte ich dir per Nachricht geben.

136

also ich kann das nicht machen. Naja vielleicht schon, aber es waere einfacher, wenn es jemand mit Linux Kenntnissen automatisieren wuerde. Ich habe kein Problem das einmal die Woche zu rechnen und auf meinen eigenen Webspace (irgendeine subdomain von osm4people.org) zu schieben. Ich mag aber keine anderen Leute um irgendwas etwas bitten.
Also ich rechne es woechentlich hier und hoste es, aber es muss jemand einrichten.

137

Man kann das ganze vermutlich auch auf dem OSM dev server machen. Einmal die Woche 6 Stunden, sollte dort nicht so das Problem sein. Auch traffic duerfte da kein Problem sein. So populaer sind die Grenzen dann doch nicht, auch wenn ich vermute das es den ein oder anderen schon interessiert (auch ausserhalb von mkgmap).

138

also das müsste gemacht werden, oder? Bei Schritt 4 bin ich mir nicht sicher. Sorry, Ich habe noch nie was mit mkgmap gemacht. Und von Interesse ist die europe-boundaries.osm und/oder(?) europe-boundaries.osm.pbf

  1. osmconvert64 europe.osm.pbf --out-o5m >europe.o5m

  2. osmfilter64 europe.o5m --keep-nodes= --keep-ways-relations=“boundary=administrative” >europe-boundaries.osm

  3. [gzip europe-boundaries.osm]

  4. java -jar mkgmap.jar --createboundsfile=europe-boundaries.osm.pbf europe-boundaries.osm

139

Du musst eine mkgmap-Verison aus dem locator-branch nehmen. Die findest du hier: http://www.mkgmap.org.uk/snapshots/

java -jar mkgmap-locator-r1994.jar --max-jobs=<Anzahl der Kerne, die du nutzen möchtest> --createboundsfile=europe-boundaries.osm

Kann aber sein, dass der Prozess ohnehin nur auf einem Kern läuft.

140

solche Meldungen sind normal?


SCHWERWIEGEND (BoundaryElementSaver): Relation is not processed due to missing tags: 4551 [openGeoDB:name=Weggis,openGeoDB:population=3616,openGeoDB:version=
0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/,openGeoDB:auto_update=population,place,name,is_in,openGeoDB:is_in=Amt Luzern,Luzern,Sc
hweiz,Europe,openGeoDB:postal_codes=6353,place=village,openGeoDB:location=political_structure,name=Weggis,population=3616,created_by=opengeodb2osm0.5.2,openG
eoDB:loc_id=31331,openGeoDB:type=Gemeinde,openGeoDB:community_identification_number=G1069,openGeoDB:is_in_loc_id=78556,openGeoDB:sort_name=WEGGIS,is_in=Amt L
uzern,Luzern,Schweiz,Europe,openGeoDB:layer=6]
SCHWERWIEGEND (BoundaryElementSaver): r16567: Relation is not processed due to missing tags: 17511 [name:de=Deutschland - Österreich,name:ru=Германия - Австр
ия,admin_level=2,name:en=Germany - Austria,boundary=administrative,name=Deutschland - Österreich,name:fr=Allemagne - Autriche,type=boundary_segment]
SCHWERWIEGEND (BoundaryElementSaver): r18510: Relation is not processed due to missing tags: 20099 [boundary=administrative,name=Landkreis Diepholz,admin_lev
el=6,type=county]
SCHWERWIEGEND (BoundaryElementSaver): r27811: Relation is not processed due to missing tags: 27894 [postal_code=6022,type=place,name=Grosswangen,created_by=P
otlatch 0.10b,place=village]
SCHWERWIEGEND (BoundaryElementSaver): r27811: Relation is not processed due to missing tags: 27895 [type=place,name=Amt Willisau,place=county]
SCHWERWIEGEND (BoundaryElementSaver): r27811: Relation is not processed due to missing tags: 27897 [type=place,name=Dagmersellen,place=village]
SCHWERWIEGEND (BoundaryElementSaver): r27811: Relation is not processed due to missing tags: 27898 [type=place,name=Ettiswil,place=village]
SCHWERWIEGEND (BoundaryElementSaver): r27811: Relation is not processed due to missing tags: 27899 [type=place,name=Reiden,place=village]