Probleme mit .img und .typ

Mal eine hinterhältige Frage: Funktioniert das denn mit dem Bearbeiten als Textfile ?

Für Stadtflächen nehme ich die Farbe ffecff.
Das kann man auf dem Oregon gerade noch so als hellrot wahrnehmen, stört aber nicht die rosafarbene Navi-Linie. (Die kann man farblich nicht ändern)
Auf dem PC sieht es auch OK aus.

File -> Edit Text File benutze ich für die Änderung.

Man darf das Polygon nur nicht wieder über Edit -> Polygon öffnen, da die Farbe dann auf ffffff gesetzt wird.

@Speichernippel: Machen wir mal ein kleines Experiment. Was steht denn in der TYP-Datei bei der Farbe 0xffecff ( Typ -> TYP analysis ) ?
Die Farbpalette stammt aus alter Zeit. Ob das heute noch notwendig ist, oder überhaupt notwendig ist, weiß ich nicht. Alternativen kann ich nur mit Outdoor-Geräten ab GPSMAP60 testen, nicht mit den eTrex, Nüvi und dem Rest. Anders ausgedrückt: Ich traue mich nicht. Mir reicht die Palette eigentlich, auch wenn die Farben insgesamt heller und bunter sein könnten. Für Hilfswillige könnte ich eine Beta mit einer anderen Palette bereitstellen ( auch 239 Farben + 16 mal grau + transparent ). Das ist nur wenig Aufwand.

@Celtus: Mettwurst ist schon ok. Ich fische hier nicht nach Komplimenten. Zur Erklärung: MapTk habe ich eigentlich für mich geschrieben ( -> Süditrol-Karte ). Wenn andere damit etwas anfangen können, so ist mir das recht. Kleine Wünsche sind auch drin. Große Umbauten oder Erweiterungen, die mir nichts bringen: Nein.
Echte Fehlermeldungen sind hoch willkommen. Es kommt nur leider fast nichts ( 4 - 5 mal / Jahr und dann meist aus Spanien ). Was im Releasereport steht habe ich zu 98% selbst entdeckt.

Typ -> Analysis -> prj Datei geöffnet
File -> Edit Text File

Das steht drin:

# Polygons

[Polygon]
Type=0x02
DrawOrder=2
String=2,Stadt
TextSize=2
Color=0,0xffecff
[END]

Wenn man über Edit das Polygon mit ändert, wird die Farbe auf ffffff gesetzt.

Das war es, was ich mit dem Experiment zeigen wollte. Neben dem Editor stattfindende Änderungen können lästige Effekte haben und sollten lieber vermieden werden.

Zu den 256 Farben: Ich habe trotz des schönen Wetters mit Farben über den ganzen Farbraum experimentiert und die möglichen Farben immer wieder auf eine Karte übertragen. Die Unterschiede müssen schon recht groß sein um in der Karte Wirkung zu zeigen. Am Beispiel 0xffffff und 0xffecff ist das schön zu sehen: Am PC sind die Farben im direkten Vergleich ( rosa Linie auf weißem Grund ) noch unterscheidbar. Auf einem Garmin-Display im Freien wird davon zu wenig oder nichts übrig bleiben.

Für einen Moment sollte man mal überlegen wofür die Farben stehen. Eine Landkarte ( egal ob Papier oder Elektronik ) ist nicht die Abbildung der Welt. Dafür gibt es Satelliten- und Luftbilder. Vielmehr ist es eine abstrakte. auf das Wesentlich beschränkte symbolische Darstellung. Farben und Symbole müssen ohne Mühe unterscheidbar sein, möglichst auf den ersten Blick. Also Symbole in der richtigen Größe und ohne Schnörkel. Sie sollen nicht schön sein, so wie ein Foto oder mit Farbverläufen, sondern mir klar zeigen wo z.B. das nächste Gasthaus ist. Das gilt auch für für Linien und Flächen. Nicht nur zur Planung ist es interessant, wie der Weg beschaffen ist, ob mit Autos zu rechnen ist, geht es durch den Wald oder übers Feld, ... Auch hier sind angemessene Symbolgrößen und Farbkontraste erforderlich. Auf die Farbe selbst kommt es nur wenig an, sie ist nur ein Symbol. Wichtig ist, dass ich mich draußen und bei schlechter Beleuchtung mühelos auf der Karte orientieren kann. Im Auto gilt das sogar bei hervorragenden Beleuchtungsverhältnissen.

Mein Fazit: Ähnliche Überlegungen wird man sich bei Garmin schon vor vielen Jahren gemacht haben. Die Farben von Garmin sind nicht schlecht für eine Karte, sowohl die Anzahl als auch die Farben selbst. Linien und Flächen haben max. 2 Farben. Symbole eben ! Mehr und andere Farben muss es nicht geben. Damit erübrigt sich auch die Frage nach der Kompatibilität.

Das Oregon hat ein sehr schlechtes Display. Versucht man mit einer Garmin-Topo Karte Fahrrad zu fahren, kann man schlicht nichts erkennen. Das liegt daran, dass die Landpolygone viel zu dunkel sind. Es ist so gut wie kein Kontrast zu Straßen oder dem Navibalken vorhanden.
Der City-Navigator ist da viel besser. Damit kann man ganz gut die Straßen erkennen.
Der CN hat keine Landpolygone. Selbst die grauen Stadtflächen, die man auf dem PC sehen kann, fehlen auf dem Oregon.

Meine Idee war es daher, eine Karte mit ganz hellen Landpolygonen zu machen. z.B. ist Wald bei mir weiß mit einigen wenigen hellgrünen Baumsymbolen.

Auf dem PC sind die Polygone gut erkennbar, was für die Planung von Radstrecken wichtig ist.
Beim Navigieren mit dem GPS sind diese Infos zweitrangig, da kommt es nur drauf an, die Straßen zu erkennen bzw. den rosa Navibalken. Beim Radfahren bewegt man sich eh meist zwischen 50 und 200 Meter zoom, da braucht man keine Polygone auf dem Gerät, die sieht man im Real-Live viel besser.
Plant man mit dem GPS eine Strecke, kann man, wenn man genau hinschaut, die Polygone trotzdem voneinander unterscheiden.

Ich habe viel mit den Farben herumexperimentiert. Die Ablesbarkeit des Oregon ist durch die Farbwahl um mind. 100% gestiegen. Ich kann das Gerät tagsüber ohne Hintergrundbeleuchtung benutzen.

Wäre schön, wenn man die Farben mit dem Editor direkt wählen könnte. Aber, wie gesagt, so wichtig ist es auch nicht, da man das ja auch über den Texteditor ändern kann.

Ich hab mich erbarmt.

Das beste Ergebnis meiner Experimente habe ich mal in MapTk 3.2 als alternative Palette eingebaut. Die Palette ist lose gebunden an das Projekt. In 'Header' gibt es eine Checkbox dafür. Das soll ungewollten Farbveränderungen durch unachtsames Speichern etwas vorbeugen. Ein Wechsel ist jederzeit möglich. Vorsichtige belassen es für ein Projekt bei einer der beiden Paletten. Soll eine TYP-Datei auch mit alten Geräten verwendbar sein, empfehle ich die Garmin-Palette - zumindest bis sicher ist, dass andere Farben verwendet werden dürfen.

Super, danke dir!

MapTk passt auf seinen Benutzer auf.

Der nutzbare Bereich für Polylines geht von 0x01 bis 0x3f ! Das Bit 6 ( 0x40 ) ist die Richtungsangabe, Bit 7 ist der Indikator für 2-Byte-Bitstream-Length. 0x47 & Co kann damit in der IMG-Datei nicht dargestellt werden, ist also illegal.

Von MapTk akzeptiert aber nicht unbedingt problemlos: 0x00 ist möglich, sollte aber vermieden werden wegen ggf. interner Anwendung für Markierungen. 0x2C bis 0x2f brauchen eine TYP-Datei. 0x30 bis 0x3f kann von (manchen ?) Geräten zwar angezeigt werden, wird von BaseCamp oder MapSource ignoriert. Der vernünftige Bereich reicht damit von 0x01 bis 0x2b.

Reicht das nicht, bleiben die 3-Byte-Codes wie z.B 0x10f0c für eine Hecke ( wie in Garmin-Topos ). Die brauchen ausnahmslos eine TYP-Datei.

Beispiel zum Download für ein Projekt: 'Sample.zip' zeigt ziemlich alle Variationen eines Kartensatzes, auch die 3-Byte-Codes.

JürgenD

Zitat von Cletus

.. Was läuft da schief?

Du hast Deiner Phantasie freien Lauf gelassen. Mir ist keine Original-Garmin Dokumentation bekannt, in der steht, welche Types Garmin rendert. Deshalb ist es gut, nur die Types zu nutzen, die zumindest indirekt dokumentiert sind. Und diese Typs findest du in der CGPSmapper-installation im File RGNTypes.txt. Da sind Deine Types unter Standard gar nicht drin und unter Erweitert mit 0x01 auch nicht.

Das Manual vom cGPSmapper orientiert sich sehr exakt an den MPC-Vorgaben. In den MPC Specs sind nur jene Typen zulässig, welche auf allen Garmin Applications und GPSr dargestellt werden können. Es gibt zwar noch andere Typen, welche dafür vorgesehen sind, nur auf speziellen GPSr zu laufen, aber die liegen ausserhalb der MPC Specs.

lg, Paul

MapTK 3.1.1

Beispiel:
Input

;testdaten für MPtoGPX export
[POI]
Type=0x2a0e
Label=KAP AM SUEDKAI (48M)
EndLevel=2
HouseNumber=1
StreetDesc=Bar Bistro im Rheinauhafen Blick auf den Rheim
CityIdx=1
ZipIdx=1
Phone=+49 221 123 456 789
Data0=(50.91918,6.96990)
[END]

Output
<wpt lat="50.91918" lon="6.9699">
<name>KAP AM SUEDKAI (48M)</name>
<cmt>Type=0x2a0e
Street=Bar Bistro im Rheinauhafen Blick auf den Rheim
Phone=+49 221 123 456 789
House=1</cmt>
<sym>Restaurant</sym>
</wpt>

Beim Konvertieren von Daten muss für jedes Datum in beiden Formaten ein Feld vorhanden sein. Fehlt ein Feld, geht der Inhalt des Feldes bei Import / Export verloren. Bei GPX ( zumindest in der von Garmin verwendeten Weise ) gibt es ein Feld '<cmt>.....</cmt>'. Dieses Feld kennt man im MP-Format so nicht. MapTk nutzt diese Feld um sich beim Export den Typ eines POI oder einer Linie zu merken. Ein neues Feld für MP-Dateien einzuführen ist an sich problemlos oder sinnlos: Es gibt keine Programme die damit ohne Klimmzüge etwas anfangen können. Für die Einbettung solcher Kommentare oder gar Bilder in eine 'normale' IMG-Datei sehe ich keine Möglichkeit. Wozu auch ? Um Informationen über einen Ort auf einem Gerät zu hinterlegen sind doch GPX-Dateien und georeferenzierte Bilder bestens geeignet ! Dazu noch unabhängig vom Kartenmaterial und ohne lizenzrechtliche Rücksicht verteilbar.

JürgenD

Es gibt kein Feld dafür in MP-Dateien. Ich vermute, dass GPSMapEdit als Konverter herhalten muss. Als Option kann man da alle Datenfelder in den Kommentar der MP-Datei übertragen. Das ist aber Kommentar zu einem Objekt der MP-Datei, beginnend mit einem Semikolon außerhalb der Definition eines Objektes ( alles zwischen [...] und [END] ). Für die Erzeugung von IMG-Datien sind diese Informationen irrelevant und werden von MapTk überlesen bzw. ignoriert. Eine Erweiterung in diese Richtung geht am Sinn von MapTk vorbei. Ein kleines Programm, dass dieses Format in in eine GPX-Datei verwandelt, ist dann auch nicht so schwierig zu schreiben. Viel Spaß dabei !