Formatdefinition GMF-Dateien

    Zitat

    Original von frank334
    Und, Hakan, hat's funktioniert?


    Wenn du [Kalibrierung] einfügst, müssten ja auch die alten Linuxprogramme funtionieren. Hab momentan keinen Nerv, meine alte Linuxbox wieder anzufahren. Demnächst kommt sowieso ein Update auf OpenSuse 10.3, dann werd ich da wieder rangehen.


    Das mit [Kalibrierung] hat zwar mein Problem mit dem SegFault beseitigt, dafür erzeuge ich im Augenblick kaputte Koordinaten in meinem .kal ; zumindest kommt auch Glopus nicht mehr mit den Dingern zurecht. :-D)


    Kannst du dir bitte die angehängten .kals anschauen? Ich scheine im Augenblick an Blindheit zu leiden. Die Kalibrierungspunkte sollten eigentlich (N,W), (S,W), (S,E) und (N,E) sein, also im Kreis gegen Uhrzeigersinn... Die dazugehörigen .png's sind auch angehängt.



    'Tschüß,
    Hakan

    Bei mir geht es teils, in Glopus wird eine Kachel angezeigt (KAL & GMF), aber nicht 2 nebeneinander (?). Die KAL-Dateien sehen korrekt aus, da ist nichts zu erkennen. Geb mal eine präzise Fehlerbeschreibung.

    Zitat

    Original von frank334
    Bei mir geht es teils, in Glopus wird eine Kachel angezeigt (KAL & GMF), aber nicht 2 nebeneinander (?). Die KAL-Dateien sehen korrekt aus, da ist nichts zu erkennen. Geb mal eine präzise Fehlerbeschreibung.


    Hi Hakan,
    korrektur: die Koordinaten waren wirklich falsch:
    du hast die y-Achse der Pixelkoordinate falsch herum (geht nach Norden!).


    GPS.Joe: wenn du etwas konkreter wirst, könnte ich evtl. helfen.

    Zitat

    Original von frank334
    Hi Hakan,
    korrektur: die Koordinaten waren wirklich falsch:
    du hast die y-Achse der Pixelkoordinate falsch herum (geht nach Norden!).


    Danke für den Tip, jetzt habe ich *.kal-files, die 4 Kalibrierungspunkte so anlegen, daß die erzeugte Karte auch paßt. Das heißt, wenn ich "Verfolge aktuelle Position" wähle wird das GPS-Kreuz an der richtigen Stelle hingemalt.


    Das mit dem gmf-File klappt aber immer noch nicht, jetzt sag mir Glopus beim Laden des gmfs immer "Error while loading <filename>: 11". Zwei der dazugehörigen kals und pngs habe ich angehängt. Hast du hier noch eine Idee?


    Das mit gmf-index erzeugte KML-File sieht eigentlich auch korrekt aus, es zeigt mir alle Kacheln da wo sie auch sein sollten.



    'Tschüß,
    Hakan


    Hi Hakan,


    ich habe deine Beispiele geprüft. Das GMF ist kaputt. Die PNG/KAL's sind in Ordnung (sorry, y-Achse soll nach Süden zeigen, aber bei deinem 1. Beispiel war's einmal richtigherum einmal falschherum). gmf-index nehme ich auch immer zur Kontrolle, allerdings musst du aufpassen, weil darin nur die long/lat-Koordinaten angezeigt werden, selbst wenn die Bildpixelkoordinaten widersprüchlich sind.


    Womit hast du das GMF erzeugt? Mit Peter's GlopusMapfile.exe und auch mit meinem (aktuellen Windows-) gmf-generate kommt mit den Beipiel-KAL/PNG ein korrektes GMF heraus.


    p.s.
    du kannst auch "gmf2index2" aus den geotools zur Kontrolle nehmen. Dann werden nicht nur die Kachelumrisse gezeigt, sondern das Kachelbild selbst auf die GoogleEarth-Oberfläche eingeblendet.

    Einmal editiert, zuletzt von frank334 ()

    Zitat

    Original von frank334
    Hi Hakan,


    Womit hast du das GMF erzeugt? Mit Peter's GlopusMapfile.exe und auch mit meinem (aktuellen Windows-) gmf-generate kommt mit den Beipiel-KAL/PNG ein korrektes GMF heraus.


    p.s.
    du kannst auch "gmf2index2" aus den geotools zur Kontrolle nehmen. Dann werden nicht nur die Kachelumrisse gezeigt, sondern das Kachelbild selbst auf die GoogleEarth-Oberfläche eingeblendet.


    Ich habe das GMF mit deinen gmf-create aus den geotools-2007-04-14.zip (das letzte, das hier veröffentlicht worden ist) erzeugt.


    Ich werde gleich nochmal testhalber das selbe GMF einmal mit deinen Windows-Binaries und danach nochmal mit dem "offiziellen" GlopusMapFile erzeugen. Lieber wären mir aber trotzdem Linux-Binaries ;)



    'Tschüß,
    Hakan

    Zitat

    Original von frank334


    Womit hast du das GMF erzeugt? Mit Peter's GlopusMapfile.exe und auch mit meinem (aktuellen Windows-) gmf-generate kommt mit den Beipiel-KAL/PNG ein korrektes GMF heraus.


    p.s.
    du kannst auch "gmf2index2" aus den geotools zur Kontrolle nehmen. Dann werden nicht nur die Kachelumrisse gezeigt, sondern das Kachelbild selbst auf die GoogleEarth-Oberfläche eingeblendet.


    Hallo,


    Ich habe gerade eben mit GlopusMapFile und deinen geotools-dev-2007-11-11 experimentiert. Die erzeugten gmf-files funktionieren mit Glopus 1.20.0. :respekt


    Die GMF-Files habe ich, falls jemand interesse daran findet, angehängt.


    Jetzt braucht das OpenStreetMap-Projekt nur noch Linux-binaries von deinem aktuellen Tools ;D



    'Tschüß,
    Hakan

    Ok, die letzten GMF's funktionieren beide. Was war denn mit dem kaputten full.gmf.zip, wie ist das entstanden ?


    Du hast doch das alte Linux-binary für gmf-generate. Das müsste doch funktionieren, wenn die KAL-Dateien mit [Kalibrierung] anfangen, oder? Das Problem mit 2 Kalibrierpunkten bestand bei den alten Tools nur in den Verarbeitungsfunktionen gmf-selection, gmf-index etc. Andererseits sollten aber auch die Windows-binaries mit wine laufen "cat *.kal | wine gmf-generate.exe mapdirectory map.gmf". Probier einfach mal aus. Meine Linux-Kiste läuft momentan nicht, wird erst in den nächsten Wochen mit neuer Hardware & neuer Distribution wiederbelebt.


    p.s. bei Fehlersuche auch immer an der CR/LF ASCII-Problematik denken, die zwischen Unix und Windows auftritt. Bei Windoze kommt nach LF immer noch der alte Schreibmaschinen-Wagenrücklauf CR dran. Ist zwar blöd, aber stört u.U. einige ASCII-Programme. Notfalls per unix2dos / dos2unix umwandeln. Das Problem hatte ich mal mit POI-Dateien. Glopus hatte POI-Dateien ohne CR falsch verarbeitet.

    Einmal editiert, zuletzt von frank334 ()

    Zitat

    Original von frank334
    Ok, die letzten GMF's funktionieren beide. Was war denn mit dem kaputten full.gmf.zip, wie ist das entstanden ?


    Du hast doch das alte Linux-binary für gmf-generate. Das müsste doch funktionieren, wenn die KAL-Dateien mit [Kalibrierung] anfangen, oder? Das Problem mit 2 Kalibrierpunkten bestand bei den alten Tools nur in den Verarbeitungsfunktionen gmf-selection, gmf-index etc. Andererseits sollten aber auch die Windows-binaries mit wine laufen "cat *.kal | wine gmf-generate.exe mapdirectory map.gmf". Probier einfach mal aus. Meine Linux-Kiste läuft momentan nicht, wird erst in den nächsten Wochen mit neuer Hardware & neuer Distribution wiederbelebt.


    p.s. bei Fehlersuche auch immer an der CR/LF ASCII-Problematik denken, die zwischen Unix und Windows auftritt. Bei Windoze kommt nach LF immer noch der alte Schreibmaschinen-Wagenrücklauf CR dran. Ist zwar blöd, aber stört u.U. einige ASCII-Programme. Notfalls per unix2dos / dos2unix umwandeln. Das Problem hatte ich mal mit POI-Dateien. Glopus hatte POI-Dateien ohne CR falsch verarbeitet.


    Das defekte full.gmf.zip entsteht mit den alten Linux-binaries.


    Ich kann auf die jetzigen .kal's die alten binaries loslassen -> defektes gmf


    auf die selben .kal's GlopusMapFile oder die neuen binaries -> korrekt


    Ich hoffe nur, daß es kein compilierproblem ist. Ich würde gerne auf "echte" Linux-binaries warten, im Augenblick (und für den Urlaub) reicht es, wenn ich die mingw-Binaries unter Windows ausführe. Den Test mit Wine (und auch mit den CR/LF in dek .kal's) mache ich aber irgendwann diese Woche noch.



    'Tschüß,
    Hakan

    Verstehe ich nicht. Der Sourcecode der Win/Lin-Edition ist vollkommen identisch, und gerade die gmf-generate-Funktion habe ich nicht geändert. Das Problem mit 2 Punkten gab es nur dort, wo 4 Punkte auf die Kartenecken verwschoben wurden.


    Bist du dir sicher, dass die KAL's für full.gmf korrekt waren, vielleicht doch noch ein paar defekte darunter? Da war mehr drin als im letzten funktionierenden Beispiel. Ausserdem war die Zahl der Kalibrierpunkte nicht 2 oder 4 (nur das wird vom gmf-superoverlay derzeit verarbeitet). Probier nur mal mit den 2 Beispielkacheln.

    Zitat

    Original von frank334
    Verstehe ich nicht. Der Sourcecode der Win/Lin-Edition ist vollkommen identisch, und gerade die gmf-generate-Funktion habe ich nicht geändert. Das Problem mit 2 Punkten gab es nur dort, wo 4 Punkte auf die Kartenecken verwschoben wurden.


    Bist du dir sicher, dass die KAL's für full.gmf korrekt waren, vielleicht doch noch ein paar defekte darunter? Da war mehr drin als im letzten funktionierenden Beispiel. Ausserdem war die Zahl der Kalibrierpunkte nicht 2 oder 4 (nur das wird vom gmf-superoverlay derzeit verarbeitet). Probier nur mal mit den 2 Beispielkacheln.


    Ich habe die "funktionierenden" gmf's mit dem neuen migw-compilierten gmf-extract ausgepackt, verifiziert, daß die .kal's meine vierpunkt-Teile sind und daß die Koordinaten stimmen, und die .kal's und .png's wieder mit dem "alten" Linux-Binary von gmf-create eingepackt. Glopus kann das neue gmf nicht öffnen, ich bekomme ein "Error while loading <dateiname>:2" :(


    Das erzeugte gmf ist angehängt. Ich habe auch einen binary diff versucht, das war aber für mich (ich kenne nun das genaue Dateiformat nicht) nicht wirklich aufschlußreich.


    Das alte Linuxbinary von gmf-extract kann übrigens die "funktionierenden" gmf's nicht auspacken, ich bekomme "number of calibration points should be [2..4] ..."

    Das GMF Format ist in geotools/doc-txt/gmf-extract.txt erklärt, wenn du wissen willst, was im Binärfile nicht Ok ist. Habe leider momentan keine Zeit für's Debugging. Ich hab den aktuellen Code mal auf einer Fremdmaschine compiliert, siehe Anhang.


    Dein Problem konnte ich bestätigen. Und zwar sowohl in den alten Linux-binaries als auch in den neuen. Auf Anhieb fällt mir nichts auf. Der Code Linux/Windows ist identisch. Ob's am KAL-Parser liegt, oder in der GMF-Library ??? Wenn du Zeit hast, kannst du mit den Linux-binaries spielen und mir sagen, welche davon sonst noch fehlerhaft sind (gmf-correct auch?). Dann kann man evtl. schon vermuten, wo es hakt. Ich werd es auf jeden Fall in einigen Wochen nochmals untersuchen.


    Was aber sofort hilft: die Windows-EXE's unter Linux mit wine starten.
    cat *.kal | wine gmf-generate.exe ./ map.gmf
    Das hat bei mir funktioniert.

    Zitat

    Original von frank334
    Wenn du Zeit hast, kannst du mit den Linux-binaries spielen und mir sagen, welche davon sonst noch fehlerhaft sind (gmf-correct auch?). Dann kann man evtl. schon vermuten, wo es hakt. Ich werd es auf jeden Fall in einigen Wochen nochmals untersuchen.


    So, jetzt habe ich die Zeit gefunden, wenigstens mal den Header der GMF-Files genauer anzuschauen.


    In dem angehängten Archiv sind zwei PNGs, zwei dazu passenden .kal's mit 4 Kalibrierungspunkten, die jeweils generierten GMF's und der decoder-output von meinem Perl-Skript (das auch 'dranhängt).


    Geotools-Linux-0414:
    GMF defekt (Glopus kann es nicht laden).
    DWORD Länge Kartenname ist 116 (viel zu lang), jedes wchar wird von drei nullbytes gefolgt.


    Geotools-1111 unter Windows:
    GMF funktioniert
    DWORD Länge Kartenname ist 58 (0-bytes mitgezählt?)


    Geotools-1111 mit Wine unter Linux:
    GMF funktioniert
    DWORD Länge Kartenname ist 58, im read-buffer steht nach dem Dateinamen Datenschrott


    GlopusMapFile unter Windows
    GMF funktioniert
    DWORD Länge Kartenname ist 29


    GlopusMapFile habe ich ehrlich gesagt nicht ausprobiert.


    Die Startadressen für die PNGs unterscheiden sich zwischen den Geotools-GMF's und dem GlopusMapFile-PNG um 116 bytes, interessanterweise hat die wine-Version die PNG's in genau der umgekehrten Reihenfolge eingepackt wie die Windows-Version...


    Naja, und die bytedarstellung der Lon/Lat als doubles unterscheiden sich zwischen Windows und Linux ein klein wenig...


    Was mich etwas irritiert: An den Startadressen der PNG's habe ich nicht die typischen Anfangsbytes gesehen. Liegen die Daten irgendwie verschoben im GMF?



    'Tschüß,
    Hakan