Neue Version Atlas Creator

  • Hallo Glopus-Freunde.
    In diesem Thread wurde ja schon mal das geniale Program Atlas Creator begeistert diskutiert.
    Habe daraufhin mal im Trekbuddy-Forum nachgefragt, ob nicht auch als Ausgabe-Fomat .png & .kal für Glopus erzeugt werden kann.
    Und :] :] :] :] :]:
    der Programmierer hat sofort reagiert es gibt die Version 1.6RC1 mit Ausgabe für Glopus !!!!!
    Hier ist der link zum Downloaden. Erster Schnelltest lief bei mir erfolgreich !!
    Bitte um Rückmeldung, dann kann ich im Trekbuddy-Forum ggf. auftretende Probleme melden.
    Gruß
    W.

  • Hallo Wunibald,


    vielen Dank für Deine Anstrengung. Eventuell könnte man noch die "lästigen" BLANKS im Layernamen verändern. Ist jetz zum Umkalibrieren ja nicht mehr erfordelich, aber trotzdem lästig, oder?


    MfG
    Achim


    Ps.: Eventuell wären noch die Kartenquellen von http://www.gps-tracks.com unter Karten interessant...

  • womisa : Bei mir nimmt die RC1 Unterstriche statt Leerzeichen (zumindest bei der Glopus-Ausgabe).


    Was mir noch auffällt: in den KAL-Dateien werden für eine 1024x1024-Kachel die Punkte POINT(0,0) und POINT(1024,1024) referenziert. Ich habe zwar keine Ahnung vom KAL-Format, aber wenn Glopus bei 0 beginnt zu zählen, kann es den zweiten Punkt nicht geben, ansonsten den ersten nicht...


    Egal, was man unter Layer settings: custom tile processing/Tile format einstellt, werden die PNGs immer mit 24Bit Farbtiefe erzeugt. Für viele Karten reichen 8, für manche gar nur 4 Bit aus. Würde das funktionieren, sparte das jede Menge Platz auf der Speicherkarte bzw. einen Nachbearbeitungsschritt. Meine JAI-Bibliotheken sind einigermaßen aktuell.


    Bei der GoogleEarth Zoomstufe 0 erkennt Glopus die Kalibrierung nicht (schaltet in den Kalibrierungsmode), der GlopusMapManager kann die Karte nicht darstellen.


    MfG

  • Hallo womisa,


    im README.HTM steht


    Zitat

    Using this atlas output format the following features are ignored when creating atlases:


    * Recreate/adjust map tiles (custom tile size and image format)


    Im Satz davor steht zwar OziExlorer, das ist aber wohl ein copy&paste - Fehler.


    Gruß
    W.

  • Zitat

    Original von daRAMA
    Was mir noch auffällt: in den KAL-Dateien werden für eine 1024x1024-Kachel die Punkte POINT(0,0) und POINT(1024,1024) referenziert. Ich habe zwar keine Ahnung vom KAL-Format, aber wenn Glopus bei 0 beginnt zu zählen, kann es den zweiten Punkt nicht geben, ansonsten den ersten nicht...
    MfG


    Mir ist früher mal aufgefallen, daß Glopus/GMM beim Kachelteilen sogar weit ausserhalb der eigentlichen Bildfläche Kalibrierpunkte setzte. So etwas habe ich anfangs in meinen GMF-Tools als Fehlermeldung quittiert. Eigentlich spielt das aber keine Rolle, wenn man es bewußt zulässt und in den Kalibrierformeln entsprechend skaliert. Glopus zumindest hat es akzeptiert. Problematisch wird das, wenn die Kachel z.B. in Google-Earth eingebettet wird (superoverlay-script), oder in ein Kartenzeichenprogramm (GIS) übernommen wird.


    Relevant wird die Lage der Kalibrierpunkte auch für mein "gmf-selection"-Programm zur regionalen Beschneidung einer GMF-Karte. Da müssen die Punkte auf den 4 Kachelecken liegen. Falls das nicht der Fall ist, werden sie einfach dorthin zurückprojeziert.


    Separat kann man das auch mit dem "gmf-correct"-Programm erreichen, das die 4 Kalibrierpunkte auf die Ecken setzt, und bei der Gelegenheit auch problematische Sonderzeichen "=&" aus dem Dateinamen wirft (das akzeptiert GoogleEarth nicht als Kachelname).

  • Zitat

    Original von daRAMA
    Was mir noch auffällt: in den KAL-Dateien werden für eine 1024x1024-Kachel die Punkte POINT(0,0) und POINT(1024,1024) referenziert. Ich habe zwar keine Ahnung vom KAL-Format, aber wenn Glopus bei 0 beginnt zu zählen, kann es den zweiten Punkt nicht geben, ansonsten den ersten nicht...


    Die Diskrepanz ist mit auch schon aufgefallen.
    Beim GMM ist das mit den POINT(X,Y) gleich der Pixelzahl der Karte - allerdings dürfte bei 1024*1204 + POINT(0,0) es eigentlich nur POINT(1023,1023) ?


    Anerseits konnte ich aber auch kein Fehler/Unterschied in der Darstellung mit 1023 vs 1024 feststellen! Deshalb hab ich es als nicht korrekte Kalibrierung definiert ohne allerdings relavante Darstellungfehler zu generieren = zu vernachlässigen.


    Ich weis jetzt kommen wieder welche aus dem Keller - für mich aber zählt nur was bei der praktischen Nutzung (Tourplanung + Outdooreinsatz) relvant ist und da spielt 1 Pixel Abweichung durch nicht ganz korrekte Kalibrierung keine Rolle.


    Gruß
    Silver


    PS: Und ich find es auch schade das beim AC das PNG8Bit nicht funktioniert - irgendein Grund wird wohl der Programmierer von AC schon haben bzw. wird halt Ozi als vorlage genommen haben und einfach die map in ein kal klibrierung umgeschrieben...

    Regioausflug.de Wandertourenplaner für Odenwald, Rhön, Mittelrhein und Taunus!!!!


    Ein Stau ist nur hinten blöd - vorne gehts !!!!

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von Silver34 ()

  • Zitat

    Original von Silver34
    Die Diskrepanz ist mit auch schon aufgefallen.
    Beim GMM ist das mit den POINT(X,Y) gleich der Pixelzahl der Karte - allerdings dürfte bei 1024*1204 + POINT(0,0) es eigentlich nur POINT(1023,1023) ?


    Vielleicht liege ich falsch, aber wenn man z.B. von einem Bild der Breite 1 Pixel x 1 Pixel ausgeht, kämen -wenn man es analog zu (1023,1023) machen würde- für die beiden Eckpunkte ja nur Point(0,0) und Point(0,0) heraus... OK, das Beispiel hinkt, aber bei 1024*1024 bezieht sich die Koordinate eben auf den rechten unteren Rand des Pixels (1023,1023), was identisch mit der Koordinate des oberen linken Rands von Pixel (1024,1024) ist. So habe ich das jedenfalls verstanden, bitte korrigieren, falls das nicht stimmt...


    Grüße
    Helge

  • Hallo Wunibald,


    Zitat


    ..Du hattest doch mit dem Vorschlag zu Kalibrierung schon einen "großen" Erfolg ;D. Kannst Du nicht auch diese Kartenquellen zum Einbau als Kartensource dem Autor empfehlen ;D. Bitte, Du bist doch in dieser FAQ Mitglied ....


    MfG
    Achim