IDeine Aussage
ist nur dann richtig wenn auf dem Gerät Strassenkacheln vorhanden sind.
Du verwechselt was. Routing funktioniert mit allen routingfähigen Karten. Die bestimmungsmäßige Verwendung und damit die enthaltenen Kartenmerkmale und die Optik, ob Strasse oder Trecking (Topo) ist gleichgültig. Selbstredend macht es keinen Sinn, eine Strassenkarte im Walde zu verwenden, eine routingfähige Topo schon. Meine Topokarten sind alle routingfähig.
Natürlich kann das 60 er routen. Sowohl Autorouting als auch andere Arten (Fußgänger usw.) . Wenn ich mich recht erinnere, kann es aber nur 20 Routen gleichzeitig verwalten. Bin mir jetzt aber nicht sicher, ob ich die 20 mit einem meiner anderen GPS verwechsele...
Das GPSMAP 60CSx kann nur 1 Datei namens gmapsupp.img lesen. Andere Dateinamen gar nicht. Gehe mal auf meine website und lies dort das Grundwissen. Dort ist auch folgender Link :
Ich habe das 60 CSx bis vor kurzen und jahrelang genutzt. Jetzt aber durch das 65 abgelöst. Da Du nur eine weisen Hintergrund siehst, liegt es an der Karte. 'DIE' Osm -Karte gibt es nicht. Du schreibst nicht, welche konkret Du benutzt. Probiere einfach mal eine von hier : http://osm-karten.img2ms.de/ aus. Es gibt eine ganze Menge von Karteneigenschaften, welche von den jeweiligen Erstellern unterschiedlich gehandhabt werden. Eine davon ist die sogenannte Drawpriority, welche festlegt, welche Karte auf dem Display angezeigt wird, falls mehrere Karten installiert sind. Um was genaues sagen zu können, müßte man wissen, welche Karten insgesamt auf dem CSx installiert sind und deren Eigenschaften kennen. Die Drawpriority kannst Du z.B. mit meinem Tool img2ms auslesen und ändern für Karten die auf dem PC installiert sind. Diese sollte auf 30 eingestellt sein, damit die ganz oben liegt. Die anderen auf 25.
Ich kann klug schnacken ...
Wie man die Style-Datei aufbauen muss, dass das funzt weiß ich auch nicht
es gibt im STYLE- die Datei 'access'. Dort findet man diesen Code :
motorcar=destination | motorcar=delivery { set mkgmap:throughroute=no; set motorcar=yes }
access=destination | access=delivery { set mkgmap:throughroute=no; set access=yes }
Und set mkgmap:throughroute=no; muß man dann individuell auf die (hoffentlich ) in der OSM Datenbank hinterlegten Strassenbeschränkungen anpassen.
Selbst falls alle Verkehrsbeschränkungen, insbesondere die 'Anlieger frei', eingetragen sind, frage ich mich, wie ich dem Navi beibringen soll, ob ich zu den Anliegren gehöre oder nicht ? Will ich meine dort lebende Oma besuchen, bin ich Anlieger, fahre ich am Haus vorbei, bin ich keiner ?
Also, das ist alles eine sinnlose Diskussion. Nichts geht über den gesunden Menschenverstand und das Navi ist nur ein 'dummes', aber nützliches Hilfsmittel.
morgen1
würde eh nichts bringen - die Topo Active basiert wie die Freizeitkarte auf OSM und hätte dasselbe Problem
Nicht unbedingt. Ihr müßt 2 Einflußfaktoren auseinanderhalten : der 1. ist die OSM-Datenbank, da steht entweder die spezielle Info drin oder nicht. Und
2. der Kartenersteller verwendet für die Extraction aus der OSM Datenbank und die Umwandlung der OSM-Einträge in Garminkarten ein sogenanntes 'STYLE'-File. (nicht zu verwechseln mit den im Forum oft diskutierten Typ-Files). Allein der Kartenersteller entscheidet mit dem Inhalt seines 'STYLE' was in die Karte kommt oder nicht.
Fazit : wenn die Karte der Wirklichkeit entsprechen soll, muß zuerst die Datenbank korrekt sein und der Kartenersteller erstellt dann nach eigenem Gusto eine Karte. 'DIE' OSM Karte ' gibt es nicht. Damit ist auch klar, das Garmin seiner TopoActive ganz andere Kartenmerkmale zu Grunde legen kann.
morgen1
Dafür kann es 3 .Gründe geben :
1.in der OSM Datenbank ist der Rad/Fußweg nicht mit den erforderlichen Verkehrsbeschränkungen getaggt. Falls Du den Namen des betreffenden Fuß/Radweges und eine Koordinate dazu bekannt gibst, kann ich (und jeder andere) das in der Datenbank mal überprüfen und ggf. korrigieren. Dazu ist aber Ortskenntnis wünschenswert. Aus der Ferne solche Beschränkungen einzutragen ohne zuverlässiges Wissen ist kritisch.
2. Die Datenbank ist okay, aber der Kartenersteller hat an dieser Stelle gepfuscht. Dann wäre zu erwarten, dass alle gleichartigen so getaggten Strassen den selben Fehler produzieren. Aber falls kein Pfusch, dann
3. Dein Navi kann die in der Karte hinterlegten Infos nicht auswerten
Ergänzung zu 3. : Falls Du noch eine ander Karte auf dem etrex hast, mal die andere Karte diesen Weg routen lassen und sehen, ob da dieser Rad/Fußweg vermieden wird. City Navigator sollte das eigentlich können. Falls auch der CN durch routet, vermute ich das Problem eher beim etrex. Und dann noch einen Gegentest der OSM -Karte in Basecamp machen. Wird da der Rad/Fußweg vermieden ? Falls ja, liegt es nicht an der Karte.
Kommt schon mal zu Datenfehler gerade bei komprimierten Dateien da diese ja aus Summenblöcken bestehen.
Nochmal downloaden und entpacken.
Das ist äußerst unwahrscheinlich. Die Struktur der Datenübertragung im Internet basiert bekanntlich auf Datenpaketen. Und die Integrität jedes Datenpaketes wird bei der Weitergabe von Router zu Router überprüft. Unvollständige Datenpakete werden gar nicht weiter übertragen ,sondern erneut übertragen. Das ist auch der Grund, warum man bei niedriger Empfangsqualität gefühlt ein langsames Netz hat : weil eben beschädigte Pakete x-mal übertragen werden, bis die endlich unbeschädigt ankommen. Die Funkwellen sind nicht langsamer, sondern der Anteil beschädigter Pakete zu hoch, Es gelangen also prinzipiell nur unbeschädigte Pakete zum letzten Router. Der von Windows gemeldete Fehler ist tatsächlich kein Fehler, sondern eine falsche Interpretation auf Grund unangepasster Voreinstellungen. Den sogenannten 'Fehler' kann man schlicht und einfach ignorieren.
Die Philosphie von Garmin hat sich geändert. MapInstall und/oder Mapsource braucht man für Original Garminkarten nicht. Warum soll Garmin dann nur wegen fremder Karten sich die Mühe machen, bug's zu fixen ? Das händische Zusammenstellen braucht man auch nicht unbedingt für freie OSM-Karten. Zumindest bieten viele OSM-Anbieter auch fertige gmapsupp.img an. Ich selbst stelle meine Karten aber auch lieber selbst zusammen. Mit Mapsource gab es da nie eine Problem. Und wenn man den Installationsort des gmap-Ordners richtig wählt, wird die Karte sowieso von Basecamp und Mapsource erkannt. Also Null Zusatzaufwand.
Gibts grad ein Problem mit den Freizeitkarten ?
Nach dem entpacken kommt eine Fehlermeldung:
Die Datenträgerimage Datei ist beschädigt
Dein Problem ist, dass Du der Dateierweiterung .img noch keine Standard-Anwendung zugewiesen hast. Da denkt Windows, es sei ein Datenträgerimage, was es aber definitiv nicht ist. Geh mal davon aus, dass es für Basecamp nicht beschädigt ist.
Das Sichbarkeitsflag kann auch das Freewaretool 'Gmaptool' setzten. Das hat auch eine deutsche Oberfläche. Nur rettet das bei Platzmangel auch nichts . Siehe dazu RainerSurfer post #5
morgen1
hab ein Platzproblem
Mein Tipp : kaufe eine neue SSD mit der Nvme Technologie. Dann clone die alte Festplatte auf die neue. Zum Beispiel mit Software von o&o Diskimage. Das wirkt Wunder. Mein 8 Jahre altes Notebook mit W10 brauchte mit der alten HDD fast 3 Minuten zum Starten, Mit der NVMe -SSD 40 sekunden.
..... Dummy-SD mache, auf der dann nur die GarminDevice.xml vorhanden ist, legt mir GE dies so an. Scheint wohl dort dann hinterlegt zu sein. .....
Es könnte in der GarminDevice.xml ein falscher Pfad hinterlegt sein. Die xml ist eine reine Textdateu und mit jedem Editor lesbar. Die Einträge sind mit etwas Garminfeeling auch gut deutbar. Insbesondere kommen die Pfade zu den jeweiligen Dateitypen in Frage : Hier mal ein Beispiel, das muß man dann sinngemäß anwenden : Die Pfade sind natürlich relativ zu sehen.
<File>
<Specification>
<Identifier>IMG</Identifier>
</Specification>
<Location>
<Path>Map</Path>
<BaseName>gmapsupp</BaseName>
<FileExtension>img</FileExtension>
<Extensions>
<dtlx:DataTypeLocationExtension>
<dtlx:ExternalPath>Garmin/</dtlx:ExternalPath>
</dtlx:DataTypeLocationExtension>
</Extensions>
</Location>
<TransferDirection>InputOutput</TransferDirection>
</File>
Falls die GarminDevice.xml aber richtige Pfadeinträge hat, bleibt nur noch die Schlußfolgerung, dass GE die Pfade falsch ausliest oder etwa falsch hardcecodete Pfade nutzt. In obigen Beispiel (von einem DS65) könnte beim ZumoXT etwa stehen <Path>.system/Map</Path>. Das hängt wohl von der Firmwareversion ab, wo die entsprechenden .img stehen sollen. Und falls Garmin gepfuscht hat, dann könnten die Pfadangaben nicht konkruent zur Firmware sein.
Das ist meine Vermutung.
Zur Datei D8259030A.img ist keine gma vorhanden. Sehr wohl aber zur D8258030C.img.
Ev. liegt es bei Dir nur an der fehlenden gma ?
In diesem Thread Bug im MapInstall V.4.3.5? oder im Gerätesoftware? hat ein user ein sehr ähnliches Problem. Es liegt Nahe, dass die selbe Ursache zu Grunde liegen könnte. Um diese Vermutung zu analysieren, wäre es hilfreich, falls mir jemand die Datei Info.xml eines betroffenen Gerätes zukommen lassen könnte. Die Gerätenummern können gerne geschwärzt sein.
morgen1
Eine Vermutung hätte ich. Betreibe aber die von Dir genannten GPS'se nicht. Deshalb kann ich die Vermutung nicht selbst überprüfen. Bei Interesse könntest Du die Datei Info.xml eines betroffenen Gerätes entweder hier als zip reinstellen oder mir privat per Konversation oder über meine email-adresse, die in meiner Signatur zu finden ist, mir zukommen lassen.
morgen1
.......Leider ist das OSM Kartenthema etwas schwierig geworden nachdem raumbezug tot ist und http://garmin.openstreetmap.nl/ auch tot ist. .....
Dann schau mal hier vorbei : http://osm-karten.img2ms.de
Hallo Liebe Leute im Forum ich habe ein kleines Problem ich will eine Software schreiben um die Fläche eines Polygons zu berechnen mit GPS Koordinaten
Aber ich bekomme die Werte nicht in X,Y in Meter.
ich habe auch schon probiert mit z.B 52,9879°,8,3487678° mal 111,3.
ich kann die Strecke zwischen zwei Punkten berechnen mit einer Formel.
X, Y Koordinaten sind Argumente zur Berechnung einer ebenen rechtwinkligen Fläche. Die Erde ist aber keine ebene Fläche sondern näherungsweise eine abgeflachte Kugel. Deine Formeln müssen deshalb auf shärischer Geometrie beruhen. Nutze mal die Suchmaschine Deiner Wahl zu einer Recherche nach 'Karten Datum' und 'Kartenprojektion'. Lediglich für sehr kleine Gebiete mit wenigen Quadratkilometern könnte man für den Hausgebrauch die Formeln für ebene Flächen verwenden, wenn der trotzdem entstehende Fehler nicht von Belang ist. 111,3 km ist der Abstand eines Längengrades lediglich am Äquator. Am Pol ist der Abstand = 0. Auf 52,9879 ° Breite must Du 111,3 noch mit dem Cosinus multiplizieren.
morgen1
ich hatte gerade ein Update für DS 65 über GE aufgespielt. Mir ging es um die Firmware 9.4. GE zeigte aber weitere Updates inclusive Cyclops. ---> alle Installieren---> Meldung es ist ein Fehler aufgetreten. GE zeigte dann an, dass Cyclops verfügbar ist. Nochmals auf das Cyclops-Update geclickt und GE meldete Erfolg. Habe aber nicht nachkontrolliert, ob auf dem Gerät tasächlich das Cyclops ein neues Datum hat. Test steht ebenfalls noch aus.
