Wine und OpenBSD vertragen sich leider nicht. Es gab mal eine sehr alte Wine-Version die mit OpenBSD lief, aber dann wurden Änderungen an Wine vorgenommen, die inkompatibel zu OpenBSD waren und schließlich wurde Wine aus dem Portstree von OpenBSD rausgeworfen. Über kurz oder lang werde ich wohl doch mal wieder ein Windows kaufen müssen und eine extra Partition dafür abstellen müssen.
Gruß
unixasket
Map Composer ist eine GUI, die unter anderem ein Textfile für TYP Files schreibt. Allerdings nicht für mkgamp sondern für cgpsmapper als Compiler. Keine Ahnung ob das dasselbe Format ist oder ganz was anderes.
bye, Nop
Nimm doch eine VM mit z.B. Ubuntu und dann Wine
Gruß
Walter
Hab mal gestern in deren Forum geschaut. Es gibt da jemanden, der die Sache hosten würde und dieser versucht nun, vom Autor die Gui zu bekommen. Wär doch was, gell?
Gruss
walter
Der jemand war ich, werd ich aber wohl doch nicht machen da ich jetzt für mich eine Möglichkeit gefunden habe das halbwegs vernünftig direkt im Texteditor zu machen. Icons erstellt weiterhin Gimp und diese werden dann in die Textconfig einfach eingefügt. vim ist ein Prima Editor der auch Makros kennt etc. Ich schreibe mit vim übrigens sogar komplexe Websites inklusive ellenlanger CSS Definitionen etc. Meine ~/.vimrc ist ziemlich lang (und mein Nickname kommt nicht von ungefähr).
Gruß
unixasket
Emacs kann sogar vim emulieren. Und ich bearbeite damit auch OSM.
SCNR
Kann der Composer auch vorhandene Txt-Files importieren? Wäre es denkbar, den Teil mit den Teil mit den Kartenobjekten und dem schreiben und lesen von txt-Files als Eigenständiges Programm anzubieten?
Zwar wurde hier schon bemerkt, dass das geht - aber ohne binäre TYP Datei bereitet die Nutzung einer solchen Karte z.B. mit “QLandkarte GT” nicht so richtig Freude. Daher: Aus einer TYP Textdatei kann man eine anderswo nutzbare binäre machen, indem man diese einfach separat mkgmap zum Fraß vorwirft:
java -jar mkgmap.jar typdatei.txt
Heraus purzelt eine Datei “typdatei.typ”. Heißa, mein Framework um unter Unix aus einer Sammlung PNGs via XML Definition nun eine ordentliche TYP Datei zu erzeugen funktioniert nun (für den von mir benötigten Funktionsumfang)
Könntest du erklären, wie dein Framework funktioniert?
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.
An so eine XML-Geschichte zum Erzeugen von TYP files aus einer XML-Datei und diversen Grafikdateien hatte ich auch schon mal gedacht, daher wäre ich durchaus interessiert, mir dieses Framework mal anzuschauen. Bisher nutze ich eine Textdatei und mkgmap, aber da hat man doch ziemlich viele redundante Daten drin, die eine Wartung relativ schwierig machen.
Habe nun doch ein richtiges, kleines Paket geschnürt: http://getmap.gpxtour.com/mkgtyp.tar.gz Das Archiv enthält als Beispiel auch mein eigenes XML mit Grafiken.
Der Editor ist seit einiger Zeit leider nicht mehr erreichbar - die Schließung war also ernst. 
Mehr als nur eine Träne weine ich dem Online-Editor nach, denn damit klappte die Entwicklung auch von komplexeren Stilen einwandfrei.
Vermutlich muss ich mich jetzt in die scheußliche mkgmap-Implementierung reinfressen. Besonders das XPM-Format verursacht Unmut. GIMP kann wenigstens in dieses exportieren.
Nicht unbedingt. Es gibt auch die Möglichkeit, einen Stil Offline in Map Composer zu verwalten, der erzeugt den ganzen Input für den TYP-Compiler aus einer menschenlesbaren Liste mit Previews und PNGs.
Nachdem es schon lange keinen Grund gab am Kartenstilgenerator zu schrauben, kann ich mir vorstellen, daß er nicht alle Möglichkeiten modernster Geräte unterstützt. Aber das wäre mal ein Impuls weiterzubasteln.
bye, Nop
Kennt ihr MapTK?
Leider nur für Windows. Gab’s früher mal für Python, mittlerweile leider nicht mehr
Interessantes Tool, das glücklicherweise mit Wine auch auf Debian läuft. Wenn man nur den TYP-Editor benötigt, muss man sich erst etwas zurecht finden.
Für alle die etwas französisch können:
https://sites.google.com/site/sherco40/ bzw. https://sites.google.com/site/sherco40/TYPViewer4.5.7.zip?attredirects=0
Gruss mgbass
Und was möchtest du uns damit sagen? Der TYPviewer ist ein alter Bekannter, wurde auf der vorherigen Seite auch mehrfach genannt. Allerdings ist es nunmal eine Windows-Anwendung, die nicht so einfach auf anderen Systemen läuft.
Für Mac-User habe ich folgenden Tipp: Wine-Bottler laden unter http://winebottler.kronenberg.org/ und installieren.
Im Register “Advanced” kann man dann den “TYPViewer4.5.20” in der Windows-Version zum Laufen bringen. Wichtig dabei ist der eine Haken bei **“Winetricks” wsh57 **(Windows Scripting Host)!
Ganz elegant wird es, wann man mit einem weiteren Haken das Wine-Programm mit paketieren lässt. So bekommt man eine Mac-App mit der Windows-Version des TYPViewer. Dank Winetricks läuft er bei mir ohne Fehler. Ohne Winetricks bekommt man beim Speichern eine französische Fehlermeldung. Viel Erfolg.