Neue Version Atlas Creator

@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

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...