Spaß mit Typefiles

Garmin fenix 7X und epix Gen 2 im Test

Der Schwerpunkt dieses Tests und Vergleichs der Garmin Fenix 7X Solar und Garmin Epix Gen 2 liegt auf den Sensoren wie Höhenmesser, Positionsbestimmung und Herzfrequenz. Was unterscheidet die beiden GPS-Outdoor-Smartwatches? Und wie gut ist die Taschenlampe der Fenix 7X für den Outdoorbereich? Hier geht es zum Test der Outdoor-Smartwatches ...

    Hallo Leute,


    beim Versuch, ein transparentes IMG mit Höhenlinien per Typfile aufzuhübschen, bin ich auf ein paar Merkwürdigkeiten gestoßen. Vielleicht hat ja jemand eine Idee, woran das liegen mag.
    Aber der Reihe nach. Es geht, wie gesagt, um ein transparentes IMG ("Transparent=Y") mit Höhenlinien (Typen 0x20, 0x21 und 0x22). Erzeugt habe ich es mit cGPSmapper.
    (Ja - nicht ganz aktuell, aber funktioniert eigentlich - zumal ich eine "Personal"-Version mit Routing aufgehoben habe. MapTk steht auf der Liste, für demnächst.)
    Das Ergebnis auf einem GPSMap 64st, über eine OSM-Karte von openstreetmap.nl gelegt, sieht schon ganz passabel aus (Bild 1).


    Allerdings hätte ich gerne die Linien etwas dezenter. Ein Fall für Typfiles. Wir versuchen es mal mit Grau, RGB #737373.

    1. Versuch: Typfile (109CF.TYP) erzeugt mit cgpsmapper, Definition für alle 3 Linientypen:[INDENT]LineWidth=1
    BorderWidth=0
    xpm="0 0 1 0"
    "1 c #737373"
    [/INDENT]Das Ergebnis ist in Bild 2 zu sehen. Auf dem GPSMap 64st erscheinen die Linien mit Grundfarbe #686868 (?). Für 1-Pixel-Linien erscheinen sie recht breit. Das kann am Antialiasing liegen. Ich hätte schon fast aufgegeben. Aber das Thema ist offenbar komplexer.

    2. Versuch: Typefile geladen von http://www.aukadia.net/gps/13100131.TYP , mit TYPWiz Farben geändert in #737373 (test1.typ).


    Ergebnis in Bild 3. Grundfarbe der Linien im GPSMap64 ist #707070 (??).
    Das sieht schon ganz gut aus, die Linien erscheinen schmaler. Aber es wird noch spannender.


    3. Versuch: Das muss doch auch mit Typfile-Compiler gehen. Typfile von 2. decompiliert mit MapTk. Definition für alle 3 Typen:[INDENT] LineWidth=1
    Color=0,0x737373
    [/INDENT]Nicht wirklich etwas neues. Das ganze dann mit MapTk wieder compiliert (M00135.typ). Ergebnis in Bild 4. Grundfarbe der Linien im GPSMap64 ist wieder #707070. Die Linien erscheinen deutlich breiter als in Variante 2. Das Antialiasing funktioniert anders. Warum ??? Jedenfalls ist das Ergebnis mit MapTk abgesehen von der anderen Grundfarbe vergleichbar mit dem von cGPSmapper.


    Bild 5 schließlich ist meine Typdefinition der Wahl (dem.typ), entstanden aus Variante 2., mit dem Unterschied, dass Typ 0x20 als Punktlinie definiert wurde (mit TYPWiz). Damit ist das ursprüngliche Problem eigentlich gelöst. Es bleiben aber Fragen:


    - Worin bestehen die Unterschiede in den TYP-Dateien? Weder TYPWiz noch MapTk finden signifikante Unterschiede.
    - Wie wurde 13100131.TYP erzeugt?
    - Wie kann ich dasselbe aus Quellen per Typ-Compiler nachvollziehen?
    - Warum kann MapTk nach Decompilieren / Compilieren eines Typfiles nicht das Ergebnis reproduzieren?
    - Warum sind die Farben bei gleicher Definition mit cGPSmapper und MapTk unterschiedlich?

    Die gmapsupp.img für die Tests habe ich übrigens, auch altmodischerweise, mit sendmap20 erzeugt. Ich hätte lieber gmt -j verwendet, aber das hat nicht funktioniert (die Typfiles waren nicht wirksam). Warum, ist eine weitere offene Frage.


    Weiß jemand Antworten auf die Fragen?



    Danke und Gruß,
    Erik

    ziemlich altmodisch sind die verwendeten Tools.Ist Dein Anliegen, ein passendes Typfile zu erzeugen oder willst du tiefer in die Geheimnisse der verwendeten Programmiersprachen/Compiler eintauchen ? Nur dann kannst Du nachvollziehen, falls unterschiedliche Ergebnisse rauskommen. Der Normaluser sucht lediglich einTool, welches einfach zu bedienen ist und mit minimaler Einarbeitung reproduzierbare Ergebnisse liefert. ich nehme dazu Typviewer Version 4.5.43. Damit muß man nicht extra compilieren, sondern kann den Quelltext direkt im Typ-Format speichern.

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...

    Danke für den Tip mit Typviewer. Ich werde es probieren und dann berichten. Du hast Recht, mit den Tools bin ich nicht auf dem neuesten Stand, da ich mich lange nicht mit dem Selberbasteln von Garmin-Karten befasst habe (außer jnx).
    Ich habe auch nicht den Anspruch, alles zu verstehen, sondern suche, wie Du sagst, Tools für reproduzierbare und vorhersagbare Ergebnisse. Einfache Bedienung muss nicht sein.


    Insofern fand ich es irritierend, dass verschiedene Tools bei scheinbar gleichen Eingangsdaten auf dem Gerät unterschiedliche Ergebnisse liefern.
    Am liebsten wäre mir ja, ich könnte die Aufgabe ausgehend von einer extern erzeugten MP-Datei komplett in MapTk erledigen. Gibt es einen Grund, warum das nicht gehen sollte?


    Und was wäre heutzutage das Tool der Wahl, um ein gmapsup.img zu erzeugen?


    Danke und Gruß,
    Erik

    Zitat von erik_heinz

    ...Am liebsten wäre mir ja, ich könnte die Aufgabe ausgehend von einer extern erzeugten MP-Datei komplett in MapTk erledigen. Gibt es einen Grund, warum das nicht gehen sollte?


    Und was wäre heutzutage das Tool der Wahl, um ein gmapsup.img zu erzeugen?


    Ich habe fast die gesamte Entwicklung der Garminkartenerstellung selbst mitgemacht. Meine ersten Karten waren mit GPSMapedit als .mp erzeugt und cgpsmapper compiliert. Mit den zu cgpsmapper gehörenden sendmap kann man auch gmappsupp erzeugen. Dann habe ich mit selbst geschriebenen Programmen Daten, die in anderen Formaten vorlagen(DXF usw...), in mp gewandelt. Auch Maptk kurz probiert. Ist alles Schnee von gestern. Vor allem weil die OSM -Datenbasis mittlerweile in Europa mindesten genauso gut ist, wie z.B. die Datenbasis der CRT- von Italien ( Carta Regionale technica 1:5000 ) , die man auch jetzt noch von den italienischen Server ziehen kann. Ich arbeite nur noch mit OSM- Daten und den Höhendaten von Austria (10 m), Copernicus (25m ), NASA(30) und de Ferranti. (in dieser Reihenfolge) Höhenlinien-Kacheln als mp-mit GlobalMapper aus den HGT erzeugt, werden mit mkgmap rasend schnell compiliert. Nur mkgmap kann auch die Schattierungen erzeugen. Es kann nicht nur diverse osm-formate sondern auch mp-lesen und daraus jede gewünschte Installation und gmapsupp machen. Nur den ebenfalls eingebauten Typcompiler benutze ich nicht, weil ich mich auf Typviewer eingeschossen habe. Hardwareseitig brauchst aber einen 64 bit PC und sehr viel RAM. Für Europa reichen 10GB RAM. Konkret hängt es vom Stylefile ab, welche Objekt in die Karte kommen und damit der benötigte RAM. Für Strassenkarten reicht auch weniger. Mp-Höhenlinien werden mit mkgmap rasend schnell compiliert mit sehr wenig RAM(1GB)
    Bis man alle Möglickeiten vom mkgmap erlernt hat dauert es. Aber wenn die Toolchain steht und alles mit Bat-file gemacht wird, geht es dann auch schnell.

    So.


    Mit TYPViewer habe ich das Rätsel mehr oder weniger lösen können. Das Problem besteht offenbar darin, dass sowohl cGPSmapper als auch MapTk aus der Definition:[INDENT]xpm="0 0 1 0"
    [/INDENT][INDENT] "1 c #737373"
    [/INDENT]im TYP-File sinnbemäß das Folgende produzieren:[INDENT] Xpm="0 0 2 0"
    [/INDENT][INDENT] "1 c #737373"
    [/INDENT][INDENT] "2 c #000000"
    [/INDENT]Nach geltender Lesart der Garmin-Versteher sollte das keinen Unterschied machen. Zumindest das GPSMAP64st macht aber offenbar doch einen: da, wo die Linien nicht exakt senkrecht oder waagerecht verlaufen, werden sie breiter bzw. verschmiert. Das ganze ist nachvollziehbar.
    TYPViewer macht das richtig. Allerdings bin ich auch mit TYPViewer nicht zu 100% zufrieden. Der hat nämlich Probleme mit "FontStyle=NoLabel". Er kann das zwar im TYP-File korrekt erkennen, aber nicht umgekehrt aus dem TXT.File korrekt ins TYP-File schreiben. Der Punkt geht also klar an das Programm TYPWiz5, denn damit funktioniert auch das.


    Was die gesamte Toolchain betrifft, so habe ich bisher nicht vor, selber aus OSM Garmin-Karten zu produzieren. Das machen inzwischen ausreichend viele Leute ausreichend gut. Ich verwende freizeitkarte-osm.de oder garmin.openstreetmap.nl und war bisher damit immer zufrieden. Höhenlinien oder DEM-Einbindung ist ein anderes Thema, schon wegen der Lizenzen. Für kleinere Projekte wie dieses möchte ich aber trotzdem eine aktuelle Toolchain haben. Mkgmap scheint mir hier der richtige Weg zu sein. Ich werde mir das mal anschauen.

    Vielen Dank nochmal für die Hinweise, und viele Grüße,
    Erik

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...