Historische Karten und GLOPUS

Wenn man das so versteht wäre es durchaus exakt. Dann wäre die
WGS84-Referenz nicht auf die Pixelmitte bezogen. Bei
Interpolationsproblemen nehme ich sonst immer die Samplemitte als
Ankerpunkt. Es gibt technische Anwendungen wo die Lage der Indizes
durchaus eine Rolle spielt. Aber hier würde es wohl kaum auffallen.

Approximation meinte ich auch nicht, sondern mehr Interpolation als exakte Rekonstruktion. Solange die Nyquist-Bedingung eingehalten wird kann man theoretisch exakt mit Subpixelpositionen umgehen. Im Subpixelbereich sind Berechnungen oft einfacher wenn eine mittige Lage angenommen wird, gerade bei digitalen Filtern oder Korrelatoren. Praktische Beispiele für Subpixelverarbeitung sind das Antialiasing oder Motion Estimation in übertakteten TV-Geräten. Neuere Literatur ist voll von Schlagwörten wie "sparse sampling", "compressed sampling" oder super-resolution. Sehr interessant, aber natürlich bei der Glopus-Kartenkalibrierung wenig relevant ...

Hallo,

mal ein kurzer Zwischenstand: Bislang habe ich etwas über 10GB und knapp 100.000 Kacheln geladen (natürlich nur die "unterste Ebene", wobei es sich da um zwei Zoomstufen handelt, da auch die vorletzte in KMLs referenziert wird, die auf keine weiteren KMZs verweisen. Einige Kacheln sind übrigens auch im jpeg, statt png-Format).

Diese Datenmenge touchiert bislang die heutige Bundesrepublik nur knapp - das meiste ist Frankreich, Schweiz,...

Ich habe mein Progrämmchen so erweitert, dass ich selektiv einen rechteckigen Kartenausschnitt laden kann und habe heute erstmal meinen Landkreis geladen, um zu schauen, ob die Qualität den Aufwand überhaupt lohnt. Vor dem "Neu Berechnen" auf 1000x1000 Kacheln (Ergebnis dann BMP!) und anschließender Konvertierung nach JPG mit dem MapManager graut mir jetzt schon, zumal Windows (oder NTFS?) ja nun gar nicht gut auf Verzeichnisse mit extrem vielen Dateien zu sprechen ist...

Die Bildqualität ist sehr gut, die Kalibrierung haut auch recht gut hin: Nord-Süd-Straßen liegen oft genau auf den heutigen Verläufen, West-Ost-Straßen haben häufig einen Versatz bis max. 60m. Da kann man vielleicht noch was optimieren, falls der Fehler nicht schon in den Originaldaten liegt.

MfG

Oh ja, interessant. Ich dachte in Google Earth wäre das nur die Umsetzung der 2.6 GB Jpeg2000-Karte. Aber dort ist es tatsächlich schärfer dargestellt. Jpeg selbst ist ja schon i.d.R. größer als Jpeg2000 und wenn dann noch mehr Details drin sind ... Man kann aber auch Jpeg noch gut optimieren. Meist ist Default 80% Qualität eingestellt. Bei Kartenbildmaterial reicht auch oft schon 40% für eine ansehnliche Karte. Bei Irfanview gibt es eine praktische Batch-Bildkonvertierung für solche Aufgaben.

"Neu berechnen" wird vermutlich nicht nötig sein. Glopus kommt relativ gut mit Riesenkarten zurecht, wenn man das GMF-Format benutzt. Der MapManager ist nicht nötig. Wenn er die ganzen Kacheln im Memory halten müsste wäre das in der Tat problematisch. Einfaches Einpacken der Bilder+KAL geht aber auch so per Commandline. Dann spielt es fast keine Rolle wie viele es sind.

Den Kartenoffset könnte man leicht beseitigen solange er konstant auf der gleichen Kartenfläche vorhanden ist. Dazu müsste man nur auf den KAL-Kalibrierdaten einen kleinen Offset addieren. Aus dem metrischen Offset lässt sich ein Long/Lat-Offset berechnen (natürlich nicht für die ganze Weltkugel einheitlich, aber für den Landkreis wird der Approximierungsfehler klein bleiben).

p.s. wer nachträglich noch einen Ausschnitt aus der Karte produzieren will: dafür habe ich das "gmf-selection"-Programm geschrieben. Man definiert in Google Earth oder Geogrid Viewer einen Polygonausschnitt und gmf-selection erzeugt ein neues GMF mit Kacheln aus dem entsprechenden Ausschnitt. Großer Vorteil gegeüber man anderen Tools: der Ausschnitt muss nicht rechteckig sein sondern schön sauber genau das was man auch braucht, ohne unnötig Platz für uninteressante Gebiete zu verschwenden.

Zitat von frank334

"Neu berechnen" wird vermutlich nicht nötig sein. Glopus kommt relativ gut mit Riesenkarten zurecht, wenn man das GMF-Format benutzt.

Die Kacheln sind 256x256 Pixel groß. Ich meine, die Empfehlung war, sowas auf 1000x1000 umzusetzen, damit Glopus flüssiger läuft.

Zitat von frank334

Den Kartenoffset könnte man leicht beseitigen solange er konstant auf der gleichen Kartenfläche vorhanden ist. Dazu müsste man nur auf den KAL-Kalibrierdaten einen kleinen Offset addieren. Aus dem metrischen Offset lässt sich ein Long/Lat-Offset berechnen (natürlich nicht für die ganze Weltkugel einheitlich, aber für den Landkreis wird der Approximierungsfehler klein bleiben).

Schick mir doch einfach 'mal eine PM, welcher handliche Kartausschnitt Dich interessieren würde. Dann lasse ich Dir den irgendwie zukommen, damit Du mal fachmännisch drüberschauen kannst, ob da ein korrigierbarer Fehler vorliegt.

MfG

Ja ich weiss, 1000'er Kacheln sind die Empfehlung. Aber 256'er werden sicher auch gut laufen. Wenn es nur ein paar Prozent Performanceunterschied sind würde ich den Aufwand der Konvertierung nicht machen. Vor allem geht es ja auch nicht, wenn die ganze Riesenkarte im RAM liegen muss. Es sei denn der MapManager würde das im Batchbetrieb machen. Meist verliert man ja auch Qualität bei der verlustbehafteten Jpeg-Komprimierung. Ich denke mit dem GMF-Format wird der Nachteil der kleinen Kacheln nicht so groß sein. Kann man ja mal testen ....

Stimmt, den Offset konnte ich nachvollziehen. Ca. 50-60m Ost-Drift. Ich kann dir mal meine Umrechnungsformeln zur Lon/Lat zu Metrisch geben:

// long/lat Grade [°] in Länge [m] umrechnen
double len_x(double delta_x, double y) { return(111325.0*cos(2.0/360.0*Pi*y)*delta_x); }
double len_y(double delta_y) { return(111325.0*delta_y); }

Ich hab's selbst nicht nachgerechnet, aber es hat bei mir immer gut gepasst. Es kann sein, dass die Koeffizienten ortsabhängig sind, aber nicht so stark. x geht Richtung Ost und y Richtung Nord. Breitengrad y ist ein Absolutwert, der Rest sind Deltas. Zur Lon/Lat-Korrektur kehrt man die Formeln um:
delta_x = len_x/111325.0*cos(2.0/360.0*Pi*y)
delta_y = len_y/111325.0

Um delta_x wären also bei Ostverschiebung die Längengrade in den KAL-Dateien zu korrigieren.

Ich habe nun einen Weg gefunden, auch relativ große Ausschnitte der Reichskarte auf Glopus zu übertragen. Sehr praktisch ist dann auch die Überlagerung der OSM/IMG-Vektorkarte (Darstellung: Punkte und Linien/Wege aktivieren, Flächen deaktivieren) auf die alte Rasterkarte. Mit dieser Kombikarte auf dem Rad durch die Historie zu fahren gibt einem gleich einen neuen Eindruck von der Siedlungslandschaft.

Für diesen Weg werden folgende Tools benötigt:

LizardTech GeoViewer
http://www.lizardtech.com/down…ction=geoviewer#geoviewer

MapTiler
http://www.maptiler.org/

Mobile Atlas Creator
http://mobac.sourceforge.net/

Im GeoViewer kann man größere Ausschnitte markieren und als GeoTIFF exportieren (Full Resolution aktivieren).

Das GeoTiff wiederum kann der "MapTiler" in eine OSM/GoogleMaps-kompatible Kachelsammlung zerstückeln. MapTiler selbst basiert wiederum auf GDAL, im Grunde ein ähnlicher Weg wie "geotiffsplit" in meiner geotools-Sammlung. Der große Vorteil nun: kachelkompatibel zum mobac.

Der Mobile Atlas Creator kann schließlich die Kachelsammlung als Quelle nutzen und verschiedene Atlas-Exportformate generieren, z.B. für Glopus oder auch Smartphone GPS-Programme (Oruxmaps SQL, OsmAnd SQL).

Als Beispiel hänge ich mal eine Hybridquellen-Definition für mobac an, die gröbere Zoomlevels aus OSM ergänzt (wo man auf der Reichskarte nichts mehr erkennen kann). Ansonsten reicht auch nur der <localTileFiles> Eintrag, wenn man auf den OSM-Layer verzichten will. Das hat jetzt nichts mit dem OSM/IMG-Vektoroverlay in Glopus zu tun, den man separat aktivieren kann, um das heutige Wegenetz erkennen zu können.

frank334
Danke für den Hinweis.
Ich kenne diese Internetseite zwar seit langem, hatte aber die Möglichkeit des Downloads der gesamten Karte von 1938 bislang übersehen.
Äußerst sehenswert und interessant.
Gestern am späten Nachmittag schnell herunter geladen und den ganzen Abend und die halbe Nacht studiert und gestaunt.
Danke!

Zitat von Wunibald

Hallo Frank,
ich bin auch ganz begeistert von dieser Karte, aber schaffe die Integration in MOBAC nicht.
Könntest Du die einzelnen Schritte genauer beschreiben, besonders auch die Kartenquellendefinition.
Ich bekomme diese Fehlermeldung.

Die obige Methode ist eigentlich sehr einfach und intuitiv (ohne commandline :-).

Die Fehlermeldung besagt, dass dein mobac den Tag "backgroundColor" nicht versteht.
Hast du auch die aktuelle Version?
Weiterhin muss natürlich der Dateipfad <sourceFolder> zu den lokalen Tile-Quellen in der XML-Datei angepasst werden.

Wie es genau mit den ext. Kartenquellen in mobac funktioniert steht in der mobac-Anleitung. Die hier Multi-Layer-Methode war für die <localTileFiles> zwar nicht dokumentiert, geht aber trotzdem.

Interessant wäre es vielleicht noch, das OSM-Wegenetz zu überlagern (transparente Layer), wie es Glopus mit den Vektordaten macht (also ohne die Füllflächen). Gibt es dazu OSM-Tile-Quellen online? Das sollte natürlich nicht den Kontrast der Rasterkarte beeinflussen. Für Glopus ist das zwar wegen der IMG-Vektorkarten nicht nötig, aber auf Smartphones habe ich so eine schöne Raster-Vektor-Überlagerung noch nicht gesehen, bzw. nur durch Mischen der Layers und resultierender Kontrastminderung. Auch die offiziellen (numerierten) Rad-/Wanderwegenetze wären sehr schön für eine Überlagerung.

Wie gesagt, deine mobac-Version ist vermutlich veraltet (1.9 final) und kennt das <backgroundColor>-Feld noch nicht. Aktuell ist die Version 1.9.8. Entweder du machst einen Update oder versuchst es mit einer Anpassung des XML.

p.s.
Man kann auch mehrere mobac-Versionen in versch. Verzeichnissen parallel installieren, falls man seine Alte behalten will. Die Kachelverzeichnisse würde ich sowieso auf eine große Datenpartition auslagern. Anpassung der Pfade in "settings.xml" so

<directories>
<atlasOutputDirectory>d:\download\karte-mobac</atlasOutputDirectory>
<tileStoreDirectory>d:\download\karte-mobac\tilestore</tileStoreDirectory>
</directories>

Ach was mir noch auffällt: das XML-Encoding ist UTF-8. Dein Editor muss das natürlich auch können. Ob der Windoof-Notepad das kann wage ich zu bezweifeln. Nimm einen Profieditor wie "Notepad++". Der kann UTF und auch XML-Syntaxhighlightning.