GMM 1.0.22 - Bug / Features GMM 1.0.2.3

Zitat

Original von Holger Issle
Und jetzt gibt es (noch als unstable) eine Version die weitere Kartendatümer erkennt

Und ich habe noch nicht mal die letzte Version als GMM Beta zur Verfügung gestellt.

Zitat

Original von edgri

So - ich hoffe, das sagt jemandem was - mir leider nur eingeschränkt...

Die Niedersachsenkarte mit dem gleichen Kartenausschnitt stimmt im übrigen recht genau! (auch mit Capture TOP 50 (3) erstellt - da steht aber prinzipiell das selbe drin lt. libmpr wie in der Hessenkarte - oder nicht?

Kann das ein Umrechenproblem sein ?

In der einen Karte ist der Referenzpunkt als Dezimal Koordinate und in der anderen als anderes Format (verschobener Punkt) angegeben ?

Vielleicht dabei auch nur ein diverses Rundungsproblem?

Gruß
Silver

Ja, dass sieht eigentlich ganz normal aus. Daher wundert mich das auch, dass hier ein Datums-Sprung reinkommt. Der GMM nutzt die Funktionen der Lib zum Umrechnen und offensichtlich hat es bisher keine Probleme gegeben. Wenn ich es schafft, kann ich heute Abend ja mal die nächste Version der Lib in den GMM einbinden - vielleicht ändert es was. Ansonsten wäre es hilfreich einen kleinen vom richtigen Viewer exportierten Ausschnitt zu haben.
Edit: Gerade Silvers Kommentar gelesen. Rundungsfehler sollten keine solche Abweichung nach sich ziehen, aber eine Ursache könnte das Format schon sein.

Zitat

Original von Peter Kirst
Ja, dass sieht eigentlich ganz normal aus. Daher wundert mich das auch, dass hier ein Datums-Sprung reinkommt. Der GMM nutzt die Funktionen der Lib zum Umrechnen und offensichtlich hat es bisher keine Probleme gegeben. Wenn ich es schafft, kann ich heute Abend ja mal die nächste Version der Lib in den GMM einbinden - vielleicht ändert es was. Ansonsten wäre es hilfreich einen kleinen vom richtigen Viewer exportierten Ausschnitt zu haben.
Edit: Gerade Silvers Kommentar gelesen. Rundungsfehler sollten keine solche Abweichung nach sich ziehen, aber eine Ursache könnte das Format schon sein.

wundert mich gar nicht. Schon mal in die Release Notes 0.2 geschaut?
"Several changes allowing more accurate georeferencing: 7-parameter datum transformations, better computation of the pixel size in meters ..."

Das könnte es sein. Ich hatte auch überlegt die Karten neu zu machen. Es spart evtl. Platz durch Wegfall der Kachel-Überlappungsbereiche, oder? Aber es dauert schon ne Weile (ca. 1 Tag für ein Bundesland), mit pngout die PNG-Kompression um 20% zu verbessern. Auf meinen knappen SD-Resourcen lohnt sich das. Auch das Löschen der weißen Kacheln im Randbereich ist sinnvoll. Sonst könnten die evtl. gar Nachbarkarten bei ferneren Ausflügen überlagern.

Na ja, die Bemerkungen der Release Notes gehen nach meinem Geschmack eher in eine andere Richtung. 40m klingt eher nach ganz weggelassener Transformation.
Übrigens, versucht GMM bei der neuen Kachelung die weißen Flecken auf ein Minimum zu reduzieren. Daher kommen am Rand auch kleinere Kacheln zustande, denn wenn zuviel Weiß rauskommt, packt GMM nicht mehrere Originalkacheln zusammen.
Das Packen der Pngs sollte für 16 Farben auch etwas besser sein. Wenn die Originalkarten nur 16 Farben hat, lohnt ein nachträgliches runterrechnen in GMM übrigens nichts. Für externe Tools gilt das natürlich nicht.

Ich hatte noch eine neue Version zum Test versprochen. Momentan mit der libmpr 0.2 gelinkt. Die dll braucht man nicht mehr. Mehr Neuerungen gibt es noch nicht.
http://www.glopus.de/history/GlopusMapManager1.0.0.25.zip

Edit: Habe die Version noch mal ausgetauscht!!!

Zitat

Original von Peter Kirst
Das Packen der Pngs sollte für 16 Farben auch etwas besser sein. Wenn die Originalkarten nur 16 Farben hat, lohnt ein nachträgliches runterrechnen in GMM übrigens nichts. Für externe Tools gilt das natürlich nicht.

Die angegebenen 20% Platzersparnis beim hatte ich rein verlustlos, ohne Farbreduktion. Einfach indem die PNG-Kompressionstabelle mit "pngout" optimiert wurde. Der Rechenaufwand ist enorm hoch, fällt aber nur bei der Kompression an, nicht bei der Dekompression bzw. in Glopus. 20% von 1 GB sind immerhin 200 MB, für die SD-Karte durchaus eine attraktive Ersparnis. Mit Lauflängenkompression bekomme ich typische A4-Dokumentscans 50% besser komprimiert. Leider ist das nur im TIFF definiert (G4 Fax RLE), nicht im PNG.

Die 16 Farben würde ich auch nicht antasten. Das sind die elementaren Kartenfarben der Top50. Reduktion bedeutet Verlust von kartographischen Merkmalen.

Zitat

Original von Peter Kirst
Na ja, die Bemerkungen der Release Notes gehen nach meinem Geschmack eher in eine andere Richtung. 40m klingt eher nach ganz weggelassener

Die Größenordnung war aber auch mein Fehler, als ich bei der MagicMaps-PTH PROJ mit falschen Bessel-Ellipsoidparametern gefüttert hatte. Die Projektionsverzerrung bei falscher Annahme Geodetic auf Mercator-Material ist wesentlich größer. Hatte in in Glopus mit einem Mercator-Deutschland-GIF probiert: da kannst du locker den Chiemsee nach München verlegen.

Zitat

Original von hips
Hallo, langsam komme ich nicht mehr mit.

Mit GMM .23 dauerte Niedersachsen ca. 10 min. das Ganze waren gut 2800 Karten und hatte ca. 260 MB.

Mit GMM .25 dauert das jetzt ca. 30 Min, es sind fast 40.000 Kacheln, und hat über 500 MB.

Ein GMF hat mein Rechner dann daraus nicht mehr machen wollen, zumindest habe ich nichts gemerkt.

Habe ich was falsch gemacht?

P.S. worin liegt eigentlich der Vorteil eines GMF gegenüber png?

Gruß hips

Alles anzeigen

Kann ich auch bestätigen !

Es werden nur noch 256*256 Pixel karten erstellt!

Geteste mit Top50-Hessen.

Gruß
Silver