Featurewunsch: Glopus und Karten im geotiff format

    Hallo Peter,


    da es jetzt verschiedene Programme zur Konvertierung der TOPxx Karten ins geotiff Format gibt (mpr2gtiff, mpr2geotiff) würde ich mir wünschen, dass Glopus auch Karten im geotiff Format direkt nutzen kann.
    Dies könnte die Konvertierung der TOPxx Karten noch etwas einfacher machen als mit GMM und böte die Chance, noch weitere Kartenquellen leichter zu nutzen.


    Viele Grüße,


    Helmut

    Zitat

    Original von huirad
    würde ich mir wünschen, dass Glopus auch Karten im geotiff Format direkt nutzen kann.
    Helmut


    Ich denke wegen der Kachelorientierten Arbeitsweise von Glopus geht das nicht direkt (die Bildkachel muss im PDA-Speicher gehalten werden).


    Zumindest kann man die Kalibrierung in eine KAL-Datei übertragen und die Bitmap in Kacheln aufsplitten. Mit geodetic und UTM GeoTIFF-Karten habe ich das schon gemacht, siehe geotiff2kal* :
    http://forum.pocketnavigation.de/tid1053510-sid.htm


    Die DHDN - Gauss Krüger - Karten der Top50-Serie gehen nicht, aber ich denke die Scripts könnten entsprechend angepasst werden. GeoTIFF an sich bietet ja sehr viele Möglichkeiten der Projektion/Kalibrierung, die man nicht so einfach umfassend berücksichtigen kann.

    So, jetzt geht es mit der Generalkarte (im Geogrid-Viewer, wie die Top50-Karten). Das GeoTIFF-Format von mpr2geotiff war etwas anders als meine bisherigen. Daher hatte das "geotiff2kal"-Script nicht funktioniert. Diese veränderte Fassung im Anhang geht aber, zumindest mit dieser Karte. Man kann z.B. eine KAL-Datei für die Gesamtkarte generieren. Allerdings ist die Bitmap (nach tif2bmp-Konvertierung) dann zu groß für den GlopusMapManager, der damit Abstürzt. Auch tif2bmp braucht viel Speicher, was nur unter Linux funktioniert hatte.


    Was aber unter Windows funktioniert, ist das geotiffsplit-Script. Die GeoTIFF-Karte wird dann direkt in GeoTIFF-Kacheln zerstückelt. Anschliessend dann für jede Kachel eine KAL Kalibrierung generiert und nach PNG umgeschrieben. Folgende Kommando-Folge hatte ich benutzt:


    Code
    geotiffsplit karte.tif 1000 1000
geotiff2kal_2-all *.tif
map-tif2png
rm karte-*.tif
gmfmake karte.gmf


    Auf Google-Earth überprüfen
    kal2index2 (Umrisse)
    kal2index5 (mit Kartenanzeige)


    Auch in Glopus hat das GMF funktioniert (Test auf Glopus PC-Version).


    Die Konfiguration ist nicht gerade anfängertauglich, aber auch nicht überaus kompliziert: benötigt wird eine Cygwin-Installation, die geotools-Scripts, dazu die Freeware GDAL und Proj. So wie in der PDF-Anleitung beschrieben. Wenn man bei der Cygwin-Installation alle Pakete ausgewählt hatte (auf oberster Paketebene "default" auf "install" ändern) ist Proj schon dabei. GDAL hatte ich selbst kompiliert, aber es gibt auch eine vorkompilierte Sammlung namens FWTOOLS mit GDAL inklusive. Dann noch die Scripts aus dem Attachment nach /usr/local/bin verschieben und dann kann's losgehen ...


    Insgesamt ist diese direkte Umwandlung natürlich wahnsinnig viel schneller als das Bildschirm-Abfotografieren der alten Methode. Auch die Probleme, dass GMM am Rand der Karte stockt gibt es so nicht mehr.


    Vielen Dank an den Programmierer von mpr2geotiff !!!


    Übrigens kann das große GeoTIFF auch von QGIS zum selber Kartenzeichen verarbeitet werden:
    http://qgis.org/


    update:
    korrigiertes Script

    Die Installation der Tools ist jetzt vereinfacht:
    http://forum.pocketnavigation.de/tid1053510-sid.htm
    siehe install.txt
    Mit ein paar Mausklicks sollte es nun erledigt sein.
    Die Bedienung erfolgt weiterhin über die Kommandozeile
    (Start mit rechter Maustaste im Karten-Ordner)


    Einfach mal testen. Bei mir ist ja schon alles drauf.
    Daher kann ich nicht sagen, ob es so auf jeder Maschine funktioniert.

    Vielen Dank für die geotools und die super Anleitung :tup
    Klappt mit den Top-Karten wunderbar :)


    Ich hab allerdings 2 Probleme:


    1. Die Anzeige im Glopus stimmt nicht. Es wird die falsche Karte ausgewählt und angezeigt, ich befinde mich laut Glopus-Kartenanzeige etwa 10km Luftlinie neben meiner eigentlichen Position.
    Ich kann mir nicht erklären woran es liegt.


    Ich hab zum Testen die *.kal nach *.map konvertiert und die Karten so in den Cachewolf importiert - dort wird alles an korrekter Position angezeigt.
    Die Karten und die Koordinaten in den *.kal Dateien stimmen also.
    (Globus ist Version 1.20.6 falls das wichtig ist)


    2. ich würde gerne bestimmte Teile der Karte auswählen und zu einem neuen GMF zusammenstellen. Dafür gibt es ja gmf-selection.
    Habe einen Polygonzug erstellt und starte gmf-selection mit der Karte und dem Polygonzug.


    Der Polygonzug wird korrekt erkannt und auch die richtigen Tiles ausgewählt, wie gmf-selection-stat und gmf-selection-index bestätigen:

    Code
    $ gmf-selection-stat poly.ovl bw100.gmf
tiles in selection: 15
size of all bitmaps: 2040885




$ gmf-selection-index poly.ovl bw100.gmf > selection.kml
extracted 15 map tiles ...

    Die Anzeige der Tiles (bzw. deren Umrisse) in GoogleEearth stimmt.


    Allerdings kommt es bei gmf-selection zu einer Fehlermeldung und die neue gmf-Datei ist fehlerhaft:

    Code
    $ gmf-selection poly.ovl bw100.gmf bw100-neu.gmf
GMF write error
selected 15 map tiles ...

    Die bw100-neu.gmf ist nur 142559 Bytes groß, statt der vorhergesagten etwa 2 MB.
    Was mache ich falsch ?(


    Verwende die geotools-2008-02-17 und linux/debian.


    Bin für jegliche Hilfe dankbar :sonne
    ...dolor sit amet.

    Hab noch einen Hinweis, vllt. eine Idee, woran es liegen könnte:


    Evtl. wird durch gmf-generate die GMF-Datei nicht korrekt erstellt?


    Das gmf-generate listet korrekt alle PNG-Dateien auf, die es integriert:

    (noch etwa 700 andere...)


    ABER: eine Anzeige der Namen in der generierten GMF-Datei ergibt seltsame Dinge:


    So geht das immer weiter...


    Ich kenne das GMF-Format nicht genau und weiß nicht, ob das "normal" ist. Aber das erscheint mir schon seltsam ?(


    Zumindest wäre das eine Erklärung, warum die Karte (also die GMF) in Glopus nicht funktionieren, die PNG&KALs aber sehr wohl korrekt sind (wie man an der korrekten Darstellung im Cachewolf sieht).

    Zitat

    Original von Lorem ipsum


    Evtl. wird durch gmf-generate die GMF-Datei nicht korrekt erstellt?


    Das könnte passieren, speziell in der von mir nicht durchgetesteten Linux-Variante. Zum Test bzw. Gegencheck könntest du einmal mit dem GlopusMapFile.Exe-Programm von Peter probieren (sollte auch mit WINE unter Linux laufen).


    Ich verwende keinen Microsoft-Compiler, sondern den freien GCC. Glopus wird mit Microsoft kompiliert. Normalerweise gibt es keine Probleme, aber die binär kodierten Wide-Chars (2-Byte Zeichen) sind nicht so ganz kompatibel. Das Problem hatte ich hier schonmal :


    Formatdefinition GMF-Dateien


    Zitat: "Bei der native Linux-Version kommt noch ein anderes Problem ins Spiel, da in Unix wide-chars als Unicode UTF-32 angenommen werden, in Windows und GMF aber als UTF-16. Mit der GCC-Option -fshort-wchar lässt sich das 16-Bit-Verhalten erzwingen, aber trotzdem produziert gmf-generate in der Linuxversion Stringfehler. Ich benutze "mbstowcs(mapfilename_unicode,mapfilename,STRSIZE);" zur Umwandlung der Dateinamen von KAL-Files nach GMF. Hat jemand eine bessere Idee?"

    Hallo Frank,


    danke für den Hinweis. Das war der Fehler.
    Mit gmf-generate.exe und wine funktioniert es :tup
    Zwar langsamer als nativ, aber Hauptsache es geht :gap



    Ich mußte heute natürlich gleich mal testen :D und hab dabei unterwegs festgestellt, daß zumindest die TOP25-Karten nach der Konvertierung alle ganz leicht verschoben sind.


    Also nicht mehr der Fehler, den ich oben beschrieb, sondern man ist überall etwa 100-150 Meter "neben" der Strecke.
    Das ganze sowohl mit Glopus & GMF-File als auch den "reinen" PNG + Cachewolf.


    Man sieht den Fehler sogar sehr schön, wenn man die Overlays für GoogleEarth erstellt, diese leicht transparent macht und dann reinzoomt. Überall steckt der gleiche "Verschieber" nach links drin.


    Hab zuerst gedacht vielleicht liegt es an der Geotiff-Erstellung des Konverters mpr2geotiff.
    Also die TIff in qgis geöffnet, einen Log-Track von heute drüber gelegt und ins gleiche Koordinatensystem transferiert (dummer Gauß-Krüger-Mist - warum kann die Erde keine Scheibe sein :ugly).
    Dort lag der Track dann aber ziemlich korrekt, ohne Verschiebung.


    Also geschaut, wo in den geotools die Umrechnung GK => WGS erfolgt, und dann in der geotiff2kal_2 fündig geworden (zum Glück keine Exe ;))


    Dort hattest du eigentlich schon die Lösung für mein Problem drin -- lediglich auskommentiert. Ich weiß nicht, warum du von der tmerc-Projektion mit epsg-Initwert wieder abgekommen bist. Ich hab diese Projektion wieder einkommentiert, benutze allerdings als Koordinaten die "großen" Werte im Geotiff.
    Es gibt ja immer 2 Einträge:

    Code
    Upper Left  ( 3246463.412, 6128177.272) (  5d 0'53.39"E, 55d13'6.92"N)...


    Hab nun überall auf das linke Paar umgestellt, und damit klappt es wie gesagt wunderbar, ganz ohne Verschiebung.
    Vielleicht liegt es an der anderen Projektion mit cs2cs, oder auch an den anderen Koordinaten (evtl. sind die rechten "menschenlesbar" und darum schon etwas gerundet?) - ich weiß es nicht genau.


    Hab mal meine Version der geotiff2kal_2 angehängt, hoffe das ist OK sonst entferne ich es wieder.


    Danke, prima dass jemand mitdenkt :) Das Problem könnte vielleicht sein, dass die rechten Werte nicht auf das WGS84 bezogen sind, sondern einfach nur Gradzahlen im DHDN sind. Bin kein Kartograph um das beurteilen zu können.


    Ja, die Lösung mit den linken Koordinaten hatte ich vorher auch schon, im alten "geotiff2kal"-Script. Nur gibt es im Geotiff sehr viele Systeme, z.B. ED50-Datum und Lambert-Projektion für die Generalkarte. Ich hab's nicht geschafft, aus den vielen GeoTiff-Projektionsangaben auf sichere Weise die richtige Angabe zur Projektionsangabe herauszufischen (es gibt dort viele EPSG-Nummern). Ein paar meiner Versuche sind im Script drin, auskommentiert. Oder kennst du eine Methode?


    Solange muss man eben für jeden Projektionstyp ein eigenes Script machen.


    Zu den geotools, muss man von der gmf-generate Linux-Variante abraten, solange das UTF16/32 Widechar-Problem nicht gelöst ist. Ich hoffe die anderen Funktionen sind davon nicht betroffen. In gmf-select wird der Widecar-Name einfach nur weiterkopiert.

    Hallo Frank,


    Zitat

    Original von frank334
    Ja, die Lösung mit den linken Koordinaten hatte ich vorher auch schon, im alten "geotiff2kal"-Script. Nur gibt es im Geotiff sehr viele Systeme, z.B. ED50-Datum und Lambert-Projektion für die Generalkarte. Ich hab's nicht geschafft, aus den vielen GeoTiff-Projektionsangaben auf sichere Weise die richtige Angabe zur Projektionsangabe herauszufischen (es gibt dort viele EPSG-Nummern). Ein paar meiner Versuche sind im Script drin, auskommentiert. Oder kennst du eine Methode?


    Das hatte ich mir schon gedacht. Hab nämlich auch gesehen, daß im Geotiff zig verschiedene EPSG-Angaben sind. Der letzte (31467) war dann in meinem Fall der richtige.


    Du filterst im Script ja nach "AUTHORITY", allerdings mit einem TAB-Char davor. Damit wurde die letzte EPSG-Angabe in meinen Tiffs nicht gefunden (bei deinem "original" Script war der verwendete EPSG-Wert 9001.


    Hier mal die entsprechende Stelle aus dem Tiff der Dtl-Übersichtskarte mit gdalinfo:


    Leider hab ich absolut keine Ahnung, welcher EPSG-Wert nun korrekt ist bzw. verwendet werden sollte. Der letzte Wert (31467) wurde bei dir jedenfalls nicht berücksichtigt, da dort davor kein Tab, sondern nur 4 Leerzeichen sind.
    Interessant ist auch, daß in den Angaben auch die eigentlichen Parameter stehen (false_easting...). Aber ob die immer korrekt und gültig sind weiß ich auch nicht.


    Ich kann mir mal zumindest für meine TOP25-SüdBW alle vorhandenen Karten anschauen, und kontrollieren, ob dort immer das gleiche System Verwendung findet. Falls dir das irgendwie hilft?


    Oder ich schaue mir mal den Code von QGIS genauer an. Dort wird ja das TIF auch eingelesen und - mit EPSG 31467 - verwendet. Vielleicht finde ich in dessen Code eine Möglichkeit, wie man sich auf einen der vielen EPSG-Wert festlegen kann.




    Zitat

    Zu den geotools, muss man von der gmf-generate Linux-Variante abraten, solange das UTF16/32 Widechar-Problem nicht gelöst ist. Ich hoffe die anderen Funktionen sind davon nicht betroffen. In gmf-select wird der Widecar-Name einfach nur weiterkopiert.


    Ich hab mir die von gmf-generate (also der Linux-Version) erzeugten GMFs angeschaut. Dort stehen die Namen der PNGs mit 4 Byte-Widechar statt 2-Byte drin. Es sind nur die Namen nicht korrekt, ansonsten stimmt alles. Dadurch kommen dann natürlich alle weiteren Tools durcheinander, die irgendwie die Namen weiterverarbeiten.


    Evtl. könnte iconv hier helfen? Dies ist ein universeller "Char-Converter", der so ziemlich alle gängigen Formate beherrscht. iconv kann man als iconv.h einbinden (ist in der libc zmd. unter Unix mittlerweile per Standard enthalten). Mit iconv_open(...) wird ein Konverter (struct) generiert, auf den man sich später bezieht und der die eigentliche Konvertierung mittels iconv(...) vornimmt.
    Hab es jetzt nicht ausprobiert, aber ich könnte mir vorstellen, daß etwas hilft wie in der Art:
    iconv_open ("UTF16", "WINDOWS-1252");


    Denn UTF-16 ist unter Linux 4-Byte-Wertig - also genau das, was auch wchar_t unter Unix ist. "WINDOWS-1252" ist hingegen (auch unter Unix) als 2-Byte-Wert definiert. Deine wchar_t - Chars (mit 4 Bytes) können durch das iconv in WINDOWS-1252 char* umgewandelt werden. Du erhälst hast dann also in deinem char-array nach der Konvertierung den Namen aus dem wchar_t - Array, allerdings korrekt mit 2 Byte breite.
    Vielleicht hilft es dir ja.



    Übrigens das -fshort-wchar als Compileroption ist wohl nur eine Art "Hack" - viele Compiler verstehen es nicht korrekt, und auch die WCHAR-Funktionen werden davon nur teilweise beeinflußt. Z.B. liefert wohl bei den meisten auch mit aktiviertem -fshort-wchar sizeof(wchar_t) 4 statt 2.
    Hab es aber jetzt auch nicht selbst ausprobiert, nur kurz gesucht...


    Bei der Generalkarte war der letzte Wert die 9001, eine Maßeinheit, keine Projektion. Ich denke auf die Reihenfolge im gdalinfo-dump kann man sich nicht verlassen. Mit der Geotiff-Lib könnte man das ganze wohl vernünftig parsen. Aber ich habe jetzt keine Zeit mich in die APIs einzuarbeiten. Zudem würde das wohl nicht einfach per RegEx im Script gehen, sondern nur via C-Programm. Also, für's erste würde ich es einfach manuell im Script einstellen, solange es keine bessere Detektionsmöglichkeit gibt.


    f-short-wchar ist schon Ok für den GCC 4.x. Andere Compiler nutze ich sowieso nicht. Das Problem dabei ist aber, dass alle Libraries, auch die C-Lib, damit kompiliert werden müssen, sonst geht printf %ls etc. nicht. Ich möchte auch nicht den Code umschreiben. Die Windows-Variante ist ja Ok und läuft per wine auch unter Linux. Von der Performance ist das nicht kritisch. Zeit wird nur in den GDAL-Libs bei der Bildverarbeitung verbraten.

    Zitat

    Original von frank334
    Bei der Generalkarte war der letzte Wert die 9001, eine Maßeinheit, keine Projektion. Ich denke auf die Reihenfolge im gdalinfo-dump kann man sich nicht verlassen. Mit der Geotiff-Lib könnte man das ganze wohl vernünftig parsen. Aber ich habe jetzt keine Zeit mich in die APIs einzuarbeiten. Zudem würde das wohl nicht einfach per RegEx im Script gehen, sondern nur via C-Programm. Also, für's erste würde ich es einfach manuell im Script einstellen, solange es keine bessere Detektionsmöglichkeit gibt.


    Ja das stimmt wohl.
    Habe mir jetzt meine verfügbaren Karten angeschaut. Dort sind alle Detailkarten in DHDN mit letzter EPSG=31467 und alle Übersichtskarten in WSG84 mit EPSG=4326. Aber du hast vollkommen Recht - das mag bei anderen Karten wieder komplett anders ausschauen. Von daher ist die Script-Lösung im Moment die beste und flexibelste.


    Zitat

    f-short-wchar ist schon Ok für den GCC 4.x. Andere Compiler nutze ich sowieso nicht. Das Problem dabei ist aber, dass alle Libraries, auch die C-Lib, damit kompiliert werden müssen, sonst geht printf %ls etc. nicht.


    Achso dann kann das bei mir ja garnicht gehen, solange das gmf-generate nicht statisch übersetzt ist. ;) Du kannst nicht zufällig mal stati.. ach nee ist auch nicht so wichtig :]


    Zitat

    Zeit wird nur in den GDAL-Libs bei der Bildverarbeitung verbraten.


    Apropos - ich habe bei mir in tif2png1 die Kombination tifftopnm & pnmtopng ersetzt durch ImageMagicks convert:


    Code
    #tifftopnm "$image" | pnmtopng -compression 9 > "$base.png"
convert "$image" -quality 9 "$base.png"


    und hatte eine Geschwindigkeitssteigerung um das 8-10 fache bei der PNG-Generierung, dem wohl aufwendigsten Prozess bei der tiff->gmf Konvertierung überhaupt.
    Falls du irgendwann in der Zukunft da nochmal was dran ändern solltest, kannst dir das Imagemagick bei der Gelegenheit mal anschauen (gibts auch für Windows ;) )


    Grüße,
    ...dolor sit amet.

    Zitat

    Original von Lorem ipsum


    Habe mir jetzt meine verfügbaren Karten angeschaut. Dort sind alle Detailkarten in DHDN mit letzter EPSG=31467 und alle Übersichtskarten in WSG84 mit EPSG=4326. Aber du hast vollkommen Recht - das mag bei anderen Karten wieder komplett anders ausschauen. Von daher ist die Script-Lösung im Moment die beste und flexibelste.
    ...
    Achso dann kann das bei mir ja garnicht gehen, solange das gmf-generate nicht statisch übersetzt ist. ;) Du kannst nicht zufällig mal stati.. ach nee ist auch nicht so wichtig :]


    und hatte eine Geschwindigkeitssteigerung um das 8-10 fache bei der PNG-Generierung, dem wohl aufwendigsten Prozess bei der tiff->gmf Konvertierung überhaupt.
    ...dolor sit amet.


    Ja, convert/ImageMagick ist bekannt, und auch als Cygwin-Paket drauf. Ich hätte nur nicht gedacht, dass die Performance so unterschiedlich ist. Die PNM-Konverter haben aber eine besondere Eigenschaft, manche Dinge mit fast unlimitierter Dateigröße von Disk-zu-Disk auszuführen. Das ist relevant bei den Multigigabyte-Satkarten der NASA. Programme, die Bitmaps im Arbeitsspeicher halten müssen, bekommen bei großen Karten leicht die Krise. Die machen sogar schon bei den Top50-Geotiffkarten schlapp. Mit meiner Kombination konnte die Gesamtkarte konvertiert werden, ohne Kachelung.


    Viel Zeit wird aber auch beim geotiffsplit in GDAL verbraucht, da das TIFF für jede Kachel wieder neu geöffnet wird. Bei der Generalkarte ging das flott, aber bei der Top50 war's nicht so wahnsinnig schnell. Zumindest wird dann die Maschine nicht tagelang durch's Bildschirmfotografieren blockiert. Ausserdem hab es es noch nie geschafft, die Gesamtkarte ohne Probleme / Unterbrechnung am Kartenrand für Glopus aufzubereiten. Übrigens sollte man am Ende die PNG's nach Größe sortiert in der Voransicht im Explorer anschauen und die ganzen leeren weißen Kacheln löschen. Dann mit "kals-deletenobitmap" die zugehörigen KAL's rauswerfen.


    Also, du meinst die Topo-Karten sind alle DHDN? Ok, dann muss das Script nicht mehr ausgeweitet werden. Allerdings war die Generalkarte als ED50 mit Lambert-Projektion. Deswegen hatte ich das 2. Koordinatenpaar ausgewertet.


    Statische Übersetzung bringt nichts, weil ich überhaupt keine 16-Bit wchar C-Lib auf dem Linux-System habe. Das möchte ich auch nicht umfrisieren. Glopus-PC und GlopusMapManager laufen ja auch nur unter Windows (nicht in wine).

    Zitat

    Original von frank334
    Ja, convert/ImageMagick ist bekannt, und auch als Cygwin-Paket drauf. Ich hätte nur nicht gedacht, dass die Performance so unterschiedlich ist.


    Hätte ich auch nie gedacht. Da ich aber gesehen hab, daß die Tif->Png Konvertierung echt lange gedauert hat (v.a. für die komplette Topo-Karte :] ) und ich sowieso nochmals konvertieren mußte (wg. den anfänglich leicht verschobenen Daten) dacht ich mir:
    schauste mal nach, warum dat so lange dauert.. ;)


    Zitat

    die PNM-Konverter haben aber eine besondere Eigenschaft...


    Achso ok, kann natürlich sein, daß Imagemagick dann schlappmacht. Kann ich nicht sagen - müsst ich testen.



    Zitat

    Viel Zeit wird aber auch beim geotiffsplit in GDAL verbraucht


    Das geht bei mir komischerweise erstaunlich schnell. Vielleicht ist die Unix-Version des gdal_translate schneller.
    Btw. hast du gesehen, daß gdal_translate (angebtlich) direkt in PNG speichern kann?
    Zumindest steht es in der Anleitung:

    Zitat

    $ gdal_translate --help
    GDAL 1.5.0, released 2007/12/18
    ...
    The following format drivers are configured and support output:
    ...
    PNG: Portable Network Graphics


    Weitere sind übrigens JPEG oder bsw. Gif...



    Vielleicht würde es also gehen, die PNGs direkt von gdal_translate zu erzeugen, ganz ohne ppmtopng etc...?


    Zitat

    Also, du meinst die Topo-Karten sind alle DHDN?


    Ich habe nur die Top25-Karte Badenwürttemberg-Süd.
    Dort kann ich bestätigen, daß alle Top-Karten DHDN sind (sprich die Süd-BW-TOP25 & die BW-TOP100), und alle Übersichtskarten (Dtl., BW etc..) sind WSG84.


    Ich kann nicht sagen, wie das bei anderen Topo-Karten (andere Bundesländer, oder TOP50 .. ) aussieht.


    Ja, ich glaube der "wahnsinnig schnell" - Eindruck ist bei mir auch in Linux gekommen. Beim letzten Test mit der Top50 in Windoze war's langsam.


    Das splitten in PNG ist übrigens schon jetzt in geotools möglich:


    "geopngsplit map.tif 1000 1000"


    Nur kann PNG keine Kalibrierdaten speichern wie Geotiff. Dazu werden dann Worldfiles erzeugt.


    Konvertierung zu KAL mittels : wld2kal-all *.png


    Allerdings wird dabei das Koordinatensystem nicht transformiert, d.h. DHDN bleibt DHDN. Wenn du ein Korrekturscript dazu schreibst, wäre die direkte PNG-Wandlung eine Alternative. Mir reicht erstmal der Weg über TIFF.


    Für das Linux-Problem mit den GMF-Tools hab ich derzeit keinen Bedarf und keine Zeit. Aber du kannst natürlich ein paar C-Codezeilen zum Einbau in die GMF-Library spendieren. Wenn das so ein 2-Zeiler mit #ifdef Linuxerkennung ist, kein Problem. Ich möchte nur den Code nicht umstricken. Am besten würde ich bei dem systeminternen widechar-Format bleiben (16/32 Bit je nach Plattform) und nur für das Lesen/Schreiben ins GMF eine Zeichenkettenwandlung vornehmen. Hab momentan auch keine Linuxkiste zum austesten. Glopus verwendet das gewöhnliche Windows-Format (was das auch immer bedeuten soll, in verschiedenen Locales).