In der aktuellen Karte von mir werden die jetzt auch angezeigt.
Auf meinem GPSMap 66s konnte ich das bisher nicht reproduzieren, da gehen die Suchen bisher immer schnell.
Auf meinem alten GPSMap 62s hatte ich das Problem auch ständig. Backup des Profiles erstellen, ein Reset des Gerätes durchführen, Backup des Profiles wieder einspielen. Danach ging es dann wieder sehr flott. Meine Vermutung ist, das Garmin da Karteninformationen cached, aber den Fall von Karten-Updates oder wechsel nicht richtig hinbekommt und dabei den internen Cache nicht löscht.
Ich glaube, ich habe die entsprechende *.img Datei noch, sprich, ich sollte es immer noch reproduzieren können. Ich habe keinen Grund gefunden, warum es nicht funktioniert, ich vermute immer noch einen Firmware-Fehler im Oregon 600. Soll ich die beiden Karten mal irgendwo hochladen?
Kannst Du machen, dann kann ich es auf dem GPSMap 66 testen. Dessen Firmware verhält sich ja nun definitiv völlig anders als die vom Oregon 600.
Ich habe es jetzt noch mal mit der aktuellen TK-Europe-Bicycling.img ausprobiert. Gleiches Problem.
Ich habe mal testweise eine Karte von einem kleinen Bereich in Bremen erzeugt:
java -jar d:\mkgmap\dist\mkgmap.jar --family-id=4455 --mapname=44556677 --description=SearchTest --gmapsupp --index --bounds=f:\dwnload\temp\bounds-latest.zip --route c:\temp\searchtest.osm
Das Kommando erzeugt eine gmapsupp.img mit gerade mal 266.752 Bytes (1).
Ohne TK-Europe-Bicycling.img zeigt eine Suche nach Restaurants innerhalb von einer Sekunde eine lange Liste. Mit TK-Europe-Bicycling.img dauert es sehr viel länger, aber irgendwann kommt tatsächlich das Ergebnis. Normalerweise verwende ich gmapsupp.img mit deutlich mehr als 500MB, ich vermute mal, da dauert die Suche dann so lange, dass ich - auf Tour - schon ein paar Kilometer von der Stelle entfernt wäre, wo ich die Suche gestartet habe. Ich habs nie abgewartet.
Mein Oregon 600 läuft mit Firmware 5.60, das Problem gab es aber schon mit älterer Firmware, meine erste TK-Europe-Bicycling.img ist vom 7. April 2018.
(1) http://files.mkgmap.org.uk/download/466/gmapsupp.img
Edit: Die family-id und description habe ich noch nie benutzt. Ich habe auch mal versuchsweise die TK-Europe-Bicycling.img mit gmt zerlegt und dann mit mkgmap mit --index eine neue erzeugt:
gmt -S TK-Europe-Bicycling.img
del 7112_srt.img
java -Xmx4G -jar d:\mkgmap\dist\mkgmap.jar --gmapsupp --index 7112*.img
ren gmapsupp.img layer1.img
Leider ohne Effekt.
Edit2: Den Test habe ich in Wildeshausen, ca. 30km entfernt von Bremen durchgeführt. Es geht dabei immer um die Suche “Alle Restaurants in der Nähe”, also nicht nach Name.
Vielen Dank! D.h. bei regionalen Radwegen werden die Name-Tags für eine Darstellung nicht mehr benötigt?
Gibt es für die solche Radwege denn allgemeingültige Namenskonventionen?
Hallo,
Ich habe jetzt mal mit meinem GPSMap 66s ausprobiert (jeweils den POI Bremen gesucht und dann alle Restaurants aller Kategorien in der Nähe auflisten lassen):
- Nur Deine gmapsupp.img: Liste ist sofort da
- Deine gmapsupp.img mit meiner TK-DACH-Bicycling: ca 2 Sekunden
- Nur meine TK-DACH-Basemap: ca 1 Sekunde
- Meine TK-DACH-Basemap mit Bicycling: ca 3-4. Sekunden
Also man erkennt sehr schön: Germin durchsucht alle images und benutzt nicht mehr den Index, was natürlich bei mehreren größeren Karten sehr lange dauern kann.
Bei meinem alten GPSMap 62s war es jedenfalls so, das es sich wohl einen internen Index aufgebaut hat und nicht immer mitbekommen hat, wenn die Karte upgedated wurde. Die Suchzeiten dauerten dann auch ewig. Da half es dann, einen Reset des Gerätes durchzuführen.
Lieber kukuk,
wäre es möglich, neben dem bicycle layer auch einen MTB layer anzubieten? Also alle Relations mit route = mtb?
Das wäre echt top!
Gruß
Matthias