Adressen finden in OSM mit Garmin

Dann hat hier jemand was lustiges Eingetragen.

das ist ein place=hamlet mit is_in: Klein Bennebek,Schleswig-Flensburg,Schleswig-Holstein,Bundesrepublik Deutschland,Europe

Der sollte meiner Meinung nach nicht im Index auftauchen, da es administrativ in Klein Bennebek ist

@Henning
was macht man eigentlich mit MS/BC. Ich hatte es mal, habe aber nicht verstanden wofür man das brauchen könnte. (ernst gemeinte Frage)

@Martin
mir gefällt Dein Projekt und Dein Kartenstyle. Darf man wissen wie lange die Generierung der DE Karte in etwa dauert?

In MS/BC kann man die Karte auf dem Bildschirm anschauen und dann Strecken planen. Dazu steht einem entweder ein Track zur Verfügung oder eine Route. Track dürfte klar sein, was es ist. Routen egtl. auch, diese werden allerdings bei den neueren Geräten auf dem Gerät immer neu berechnet. Auf den älteren konnte man dass AFAIK unterbinden. Dürfte aber für KFZ-Navigation nicht wirklich interessant sein.

Wie lange Martin fürs berechnen braucht, kann ich dir nicht sagen :wink: Bei mir dauert eine Aktualisierung vom planet rund 1h, dann zweimal rund 30min splitten, weil es für einen Durchlauf bei meinen vielen Karten zu viele Tiles sind. Deutschland zu berechnen dauert dann nochmal 25-30min.
Das alles auf einer SSD, 6Kern-CPU mit 3,6GHz und 8GB RAM.

achso, also für Leute, die sich viel bewegen und ihre Touren am PC planen. Nichts für mich :wink:

Letztendlich für alle, die mehr Einfluss auf die Route haben wollen, weil ihnen nicht unbedingt egal ist, wo sie lang laufen oder radeln.

Durch den LocationHook dauert es rund 2h. Das wird aber auch schneller werden, da es noch in den Kinderschuhen steckt.
Das wird auch der Grund sein, warum dieses “falsche” Potsdam im Index auftaucht. Es ist ja nicht 100% klar, wie die Straßensuche im Garmin funktioniert.

Die Generierung der ganzen DE Karte dauert wirklich nur 2h? Ohne zSeries und ohne SSD? Hintergrund meiner Frage ist, ob ich Dir helfen kann die Karte vielleicht wöchentlich und evtl auch für ganz Europa anzubieten. Webspace habe ich noch bei odbl.de und Rechenzeit auch, aber nicht unbegrenzt. Aber 2h pro Woche wären da Peanuts.

Für Europa müsstest du aber Einschränkungen bei den Datails machen, ansonsten durchbricht man die 4GB-Grenze des FAT-Formats.

Ich geb ihm knapp 1.7 gb RAM von meinem MacBook Pro (2.2 GHz, Intel Core 2 Duo). Aber ich werde gleich noch einmal das ganze anwerfen und die Zeit messen. Danach wissen wir mehr. Der Wert bezieht sich natürlich auf die reine Laufzeit von mkgmap.

Darüber habe ich schon mal nachgedacht…aber nicht intensiv, da es mich bisher nicht betroffen hat. Ich habe halt kaum Karten gemacht. Was mir als erstes kam, waren Buildings. Das müsste eine Menge ausmachen und die sehen eh krumm und schief auf den Garmins aus. Man müsste halt nur schauen, dass amenity etc drin bleibt. Das könnte ein sehr sehr langer osmosis Befehl werden

Sprichst Du fliessend Linux? Als Zeit meine ich von Anfang bis Ende. Die Daten wären vorhanden, also ohne runterladen

Wieso osmosis? Das geht alles in den Style-Files von mkgmap. Was meinst du mit fliessend Linux sprechen? Das Erstellen der Karten läuft komplett über java. Allerdings kommt dann keine fertige gmapsupp raus, die die Adresssuche beherrscht. Dafür braucht man derezit noch MapSource oder BaseCamp, was aber wohl auch unter Linux laufen soll.

kann gut sein…dachte, man filtert das vorher wegen der Geschwindigkeit.

Verstehe ich nicht. Man kann keine fertige *img erstellen, wie bspw mit dem MapComposer ohne MS/BC? Ich wollte langsam dahin, dass evtl auf einem headless system zu automatisieren. Aber wenn man dazu MS/BC braucht, hat sich das erledigt.

Nein, mkgamp kann derzeit keine gmapsupp.img erstellen, sodass du damit auf dem Gerät nach den Straßen suchen könntest. Eine gmapsupp.img, mit der du nicht suchen kannst, kannst du damit erstellen. Für eine gmapsupp.img mit Straßensuche braucht es derezit MS/BC.

Danke für die Info. Ich kenne mich nicht so im Kartenerstellerumfeld aus …bin schon froh mit MapComposer klar zukommen… Wann versteht Garmin mal, dass sie durch OSM mehr Geräte verkaufen und legen den Code offen. Naja, vielleicht rechnen die auch ganz genau nach, was der OSM Vorteil gegenüber der Marge von den verkauften (teilweise umgelabelten) Fremdkarten ausmacht.

So…
Ich hab jetzt noch einmal eine germany.osm.pbf runtergeladen.
Splitten hat 23 Minuten gedauert.
Die Karte zu generieren hat 176 Minuten gedauert… Hatte sich das letzte Mal “schneller angefühlt”.
Du könntest, wenn Möglich, ein Paket anbieten, wo nsi, tdb etc enthalten. Dann kann sich jeder die Karte selber in MS/BC installieren.

Leider verdienen die ihr Geld mit den Karten und nicht mit den Geräten…

Chris

Hallo Chris, Thomas

Das wird klar wenn man bedenkt, dass ein Gerät produziert werden muss, während Software+Karten einfach nur kopiert werden können. Die Produktion von Geräten erfolgt in großen Stückzahlen, damit überhaupt zu einem günstigen Preis angeboten werden kann. Dabei entstehen dann Logistikkosten für die Lagerung, da der Abverkauf ja eher kontinuierlich erfolgt.

In Summe bleibt ab einer gewissen Stückzahl deutlich mehr Spanne bei Software/Karten als bei Hardware. Von daher gibt es wenig Neigung der Gerätehersteller ihr jeweiliges internes Format für OSM (und schlimmer auch allen anderen) offen zu legen.

Edbert (EvanE)

Da ich sowieso eine neue Karte erstellen musste, hab ich sie auch gleich hochgeladen.
Direkt für Garmin-Geräte (nur entpacken&kopieren):
Zum Installieren in Mapsource/Basecamp (inklusive Typ-File):
MD5-Summen:


MD5 (gmapsupp.img) = ffe729ca89877d1661cd8defbe04a6cd
MD5 (gmapsupp.img.zip) = 35e4faef95b65b2b6e7cc77d7a2e3026
MD5 (All.zip) = 8ff8f864cabc7dbd3bb03905e349b168

Zum installieren in Mapsource benötigt man Nullsoft Scriptable Install System. Ich hab es einmal auf dem Rechner meiner Freundin ausprobiert, kann also wenig dazu sagen. Damals hat es ohne Probleme funktioniert. :wink:
Für Mac OS benötigt man gmapi-builder.py
Aufruf mittels:


python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s basemap.TYP -i osmmap.mdx -m osmmap_mdr.img osmmap.img 63240*.img osmmap_mdr.img

Herrenberg in BaWü ist auch nicht suchbar. Liegt vermutlich an einem suburb=Herrenberg in Erfurt, denn es wird Herrenberg(Thüringen) angezeigt. Da es vermutlich sehr viele doppelte Namen geben wird, ist das schon ein Problem.