Im Wesentlichen ist das Framework aktuell ein Script mit Verzeichnisstruktur, geschrieben in Tcl (8.5). Es benötigt das Tcl Paket “tDom”, sowie ImageMagick (convert und identify) und iconv. Und natürlich auch mkgmap…
Zunächst ein paar Bemerkungen zu TYP Textdateien:
So eine TYP Textdatei enthält nichts anderes als hinterienander geschriebene XPM Grafiken. Auf meinem Linux finden sich aber auch binäre XPMs - und auch welche mit einem SVG-Vectorformat. Dazu kommt, dass das XPM Format für mkgmap nicht nur das gewöhnliche ASCII Format sein muss, sondern Farbnamen wie “gray100” tabu sind (und wer nun tapfer einfach “suchen&ersetzen” spielt, wird mit “gray10” und “gray100” Probleme bekommen, bzw. auch wenn die Pixel selbst zufällig mit dieser Zeichenfolge codiert wurden). Korrekte XPMs zu erstellen ist etwas komplizierter als man zunächst annimmt.
Auch jene Linien, die man mit Border + Farbwert usw. definiert, lassen sich problemlos mit 2farbigen Grafiken abbilden (was hinter den Kulissen m.E. ohnehin geschieht). Hier kann man also die Definition der Elemente vereinfachen bzw. vereinheitlichen.
Haken an dieser TYP Textdatei ist, dass sie sehr unschön zu bearbeiten ist - und gerne die 100kB übersteigt. Und da kam mein Gedanke, die Grafiken auszulagern - und im XPM-Format mag ich die ohnehin nicht um sie später mal wieder weiter zu bearbeiten. Genauer: Das Grafikformat ist eigentlich völlig egal, denn konvertieren kann man ja automatisiert mit ImageMagick. Es dürfen also auch TIFFs, JPEGs, GIFs und was auch immer sein 
Die Definition, welcher Garmin-Code zu welcher Grafik gehört, sehe ich in einer XML Datei gut aufgehoben. Für die Bearbeitung einer solchen XML Datei kann man später ja immer noch eine GUI basteln… (oder einen Viewer in PHP für den Webbrowser). Aktuell sieht eine XML TYP Datei so aus:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<typ>
<header>
<family_id>2807</family_id>
<product_id>1</product_id>
<codepage>1252</codepage>
</header>
<polygons>
<level>
<element type="0x02"><color>#e3e3e3</color></element>
<element type="0x16">
<img>wald_hell_nadel.png</img>
<txt lang="en">Forest</txt>
<txt lang="de">Wald</txt>
</element>
</level>
<level>
<element type="0x10">
<img>fels_und_geroell.png</img>
<txt lang="en">Scree / Rocks</txt>
<txt lang="de">Felsen / Geröll</txt>
</element>
</level>
</polygons>
<lines>
<element type="0x00"><img>highway_road.png</img></element>
<element type="0x10f0c">
<img>barrier_hecke.png</img>
<txt lang="en">Hedge</txt>
<txt lang="de">Hecke</txt>
<font>hidden</font>
</element>
</lines>
<points>
<element type="0x04">
<img>punkt.png</img>
<font>big</font>
</element>
<element type="0x51">
<img>telefon.png</img>
<txt lang="en">Phone</txt>
<txt lang="de">Telefon</txt>
</element>
</points>
</typ>
Die Grafiken liegen in den Verzeichnissen “lines”, “points” und “polygons”. Das obige Beispiel hätte bei den Polygonen lediglich 2 Level. Die Konvertierung der Farbnahmen in RGB-Hex-Codes geschieht mittels der offiziellen Tabelle aus “/usr/share/X11/rgb.txt” (die nutzt “convert” wohl auch umgekehrt). Starte ich mein Script “mkgtyp.tcl”, so wird die Datei “2807.txt” und “2807.TYP” erstellt (“2807” entsprechend family_id). Die Texte (Sonderzeichen/Umlaute) sind in auch CP1252 (auch wenn diese Umwandlung noch hart codiert ist). ImageMagicks “convert” bekommt den Parameter “-colors” mit einem Wert den “identify” zuvor ermittelt - sonst hat man sehr viel Datenmüll, da “convert” jedem Pixel einen neuen Farbidentifikator zuweist sofern das ebenfalls gesetzte Limit von 8bit Farbtiefe noch nicht verbraucht wurde… usw.
Aktuell erhält man nur TYP Dateien mit einfacher Transparenz - die “Semi-Alphakanal-Auswertung” habe ich noch nicht umgesetzt (und nutze sie auch nicht). Ich habe aber nicht vor das als neues Softwareprojekt öffentlich anzubieten - um so ein Projekt muss man sich auch kümmern, und dafür habe ich keine Resourcen frei (da würde es wohl mehr Sinn machen, mein ganzes Environment zum Garminkartenbastelt endusertauglich anzubieten). Zumal es nicht sooo viele sein dürften, die so etwas überhaupt einsetzen würden. Falls wer sich daran probieren möchte und auch keine Probleme hat wenns nicht out of the box zum eigenen Rechner passt, der darf sich gerne melden.