Garmin Speicher voll

Du verwechselt wohl Roß und Reiter. Garmin baut seine Geräte für die Anzeige von Garminkarten. Und wenn Fremdkarten, weil nicht den Garminkonventionen entsprechend, oder klar gesagt: 'falsch' compiliert sind, Geräteprobleme verursachen, dann ist die nicht bestimmungsgemäße Nutzung dran Schuld und nicht Garmin. Was Dein Eingangssatz aber suggeriert. Oder nimmst Du die Verlustleistung einer Glühbirne zum Wasserkochen ?. Theoretisch, aber nur theoretisch, könnte man die Verlustleistung zum Erwärmen nutzen. Dass die Glühbirne bei dieser Zweckentfremdung platzt, ist eine andere Frage. Ob nun nur Felix oder generell mkgmap dran Schuld ist, weiss wohl keiner so genau. Für die kostenlose Nutzung dieser Karten muss man halt Kollateralschäden in Kauf nehmen. Und wenn ich es richtig in Erinnerung habe, lehnen die mir bekannten OSM-Compilierer ausdrücklich jede Haftung für die Nutzung Ihrer kostenlosen Karten aus guten Gründen ab.

morgen1

Zitat von uwelix

Nun, dieser Fehler scheint sich irgendwann in den letzten Wochen und Monaten eingeschlichen zu haben, und zwar entweder bei Garmin oder bei den OSM-Karten.

Eine Problemlösung betreffs der Etrex30 ist wohl mit der Firmware 2,72 erfolgt. Die Ursache wird wie folgt erklärt : Zitat:".....Bei Tests mit den US-Karten gab es da wohl auch keine Probleme und da die Routine sich in den alten eTrex-Geräten ja schon bewährt hatte und sich eigentlich nichts an den OSM-Datenformaten geändert hatte, wurde hier nie ein Fehler vermutet. Was aber nicht berücksichtigt wurde war, dass natürlich nun nicht eine (gepackte) Karte, sondern mehrere geladen werden konnten und dass in Europa (insbesondere Deutschland) die OSM-Karten laufend an Datendichte zugelegt hatten. Die OSM-Karten der USA, die z. B. für Nevada heruntergeladen werden, haben naturgemäß nur in den Städten viele Daten, ansonsten ergeben sich aber für eine gegebene Fläche recht wenig Informationen. Somit wurde offensichtlich der Speicher überlastet, was schließlich zu den Abstürzen führte. Dass manche keine Probleme mit OSM-Karten hatten lag evtl. daran, dass nur kleinere Bereiche (z. B. Bundesländer) ausgewählt wurden, oder dass einige auch eine Installation ohne Adress-Layer vorgenommen haben."

ist jetzt Spekulation von mir: Bei Garminfirmware gibt es den Trend, generell mehrere gmapsupp zu unterstützen. Z.B. gilt das mit der neuesten Firmware auch für mein Nüvi. Bei neueren Outdoor ja schon geraume Zeit. Die haben wohl die Nebenwirkungen dieser an sich wünschenswerten Erweiterung unterschätzt. Hinzu kommt bei OSM wegen immer noch nicht funktionierendem kachelübergreifenden Routing die große Kachelgröße. Garmin hat im allgemeinen kleinere Kacheln. Könnte mit gut vorstellen, das diese Faktoren zusammen zum Fehler führten.

Moin,

das Problem ist bei Garmin angekommen und betrifft die Firmware. Im Garmin Forum gibt es dazu gute Informationen eines Users:
https://forum.garmin.de/showthread.php?p=98174#post98174

Hmm, interessantes Thema. Da werfen aber einige Sachverhalte weitere Fragen auf:

(1) Was ist so anders an OSM Karten? OSM selbst ist ja keine Karte, sondern eine Vektordatenbank, aus der Garminkarten gemacht werden. Entspricht das Endprodukt nicht den MPC Specs? Wo liegen die Unterschiede?

(2) Eine Topo D hat sicher auch eine sehr hohe Datendichte, die an OSM rankommt. Daher müsste das Problem auch bei Topo D, und nicht nur bei OSM auftreten.

lg, Paul

Tja, die Ursache für das Problem wüsste ich auch gerne.

Habe sowohl auf dem Oregon 550 als auch auf dem eTrex 30 die Computerteddy von Europa als Nord- und Südteil aus der Worldmap drauf, zusammen 5 GB. Dazu die eine oder andere OSM-Karte zusätzlich, allerdings keine openmtb. Und noch nie "Speicher voll" gehabt.

Hmm, gut ich bin nicht der Experte fürs Garmin Map Format, aber die im Garminforum gepostete Erklärung seitens Garmin befriedigt mich auch nicht.

Nunja, es kann schon was damit zu tun haben, dass man jetzt x-beliebig viele IMG Container auf das GPS geben kann. Früher war ja ein Container mit max. 2024 Tiles zulässig. In jedem Tile (= Einzel-IMG) gibts verschiedenen Layer, wobei jeder Layer nicht mehr als 65535 TRE Regions haben durfte. Und jede TRE Region hat ihrerseits ein bezüglich Grösse und Inhalt. Ich nehme an, dass das auch der Grund ist/war, für die Beschränkung eines Gesamtcontainers.

Da diese Beschränkung jetzt obsolet ist, kann ich mir vorstellen, das in bestimmten Bereichen (MapRegions?) die Renderengine mal was nicht mehr darstellen kann. Aber das ist jetzt nur Spekulation.

Nebenbei sollte man wissen, worauf sich das "Speicher voll" konkret bezieht.

Was das Argument mit dem Index angeht, da müsste man mal testen, wie sich ALLE geladenen Karten verhalten, wenn diese OHNE Index am Gerät sind. Quasi eine Karten-Garnitur mit Index und die gleiche ohne Index.

lg, Paul

Zitat von Speichennippel

(Topo vor der CN erzeugt, macht die Adresssuche kaputt)

was heißt hier "erzeugt" ? Mapsource? Mapinstall? Oder wie?
Kannst du eine "Anleitung" geben a) zum erzeugen b) zum vermeiden dieses Fehlers?

Meine Erfahrung zu diesem Problem:

Karten auf das GPSr laden, z.B. mit Mapsource. Es bildet sich eine gmapsupp.img Datei. Falls es sich um die Topo handelt, umbenennen in z.B. Topo_d.img. Nächste Karte laden, umbenennen in z.B. Topo_I usw.
Eine dieser Karten ist auch die CN die die Routing-Info enthält. Wenn alle Karten geladen sind und jede ihren eigenen Namen hat, die CN wieder umbenennen in gmapsupp.img. Ganz egal zu welchem Zeitpunkt diese Karte geladen wurde, nach dem Umbenennen funktioniert alles wie gewünscht.

Wenn eine zusätzliche Karte geladen werden soll, erst die gmapsupp.img umbenennen in z.B. CN.img, die neue Karte laden, diese umbenennen in wasauchimmer.img und dann die CN.img wieder in gmapsupp.img umbenennen.

Hat bisher bei mir immer einwandfrei geklappt.

Gruß, MB