Große gescannte Mercator-Papierkarte automatisch kalibriert in Kacheln aufteilen

Es geht darum, eine große Mercatorprojezierte Papierkarte in Glopus verwenden zu können. Z.b. aus einem A0-Scan (Copyshop) einer Papierkarte. Die meisten topografischen Karten sind transversal Mercator projeziert. Aktuell geht das nicht gut, da Glopus nur die Projektionsart Platte-Carrée (= lat/long Äquidistant) beherrscht. Eine Möglichkeit ist jedoch, die Karte in sehr viele kleine Kacheln aufzuteilen, die zwar weiter Mercatorprojeziert sind, jedoch mit jeweils korrekt umgerechneten Kalibrierpunkten an den Kachelecken. So kann der Projektionsfehler auf ein minimales unbedeutendes Mass reduziert werden. Ausserdem kommt es der Arbeitsweise von Glopus entgegen, das Kacheln erwartet, die in den Hauptspeicher passen.

Früher ist hier von ReRo im Forum für eine Weltkarte folgende Reprojektion mit den GDAL-Tools (http://www.gdal.org/) vorgeschlagen worden:

gdal_translate -a_srs "+proj=merc +datum=WGS84" -gcp 433 1012 -18924313 11028513 -gcp 7403 1012 18924313 11028513 -gcp 7403 4308 18924313 -6413524 -gcp 433 4308 -18924313 -6413524 welt.gif welt.tif

gdalwarp -t_srs EPSG:32662 welt.tif welt-neu.tif

gdal_translate fürgt GCP Kalibrierpunkte hinzu und speichert als GeoTiff. gdalwarp ver-/entzerrt die Karte von Mercator in die Platte-Carrée-Projektion (EPSG-Code 32662). Durch die Verzerrung ist die Karte nicht mehr so schön.

Nun habe ich gelesen, die GDAL Tools könnten auch grosse Bitmaps in Kacheln aufteilen und die Projektion dazu umrechnen. Aber so ganz habe ich es noch nicht verstanden welche Kommandos und Optionen hier relevant sind. Folgende sind mir aufgefallen:

gdal_translate: Optionen -srcwin -projwin -co "TILED=YES" ?
gdalwarp: Optionen -te -tr ?

Ich weiss aber nicht, ob die Kachelung automatisch läuft, oder ob noch eine Schleife im Skript geschrieben werden muss. Die Source-Beispiele im Netz waren nicht so gut dokumentiert. Meine eigenen Versuche haben nicht auf Anhieb funktioniert. Das einfachste wäre sicher, im Pixelkoordinatenraum eine lineare quadratische Kachelaufteilung zu machen (im long/lat-System etwas krumm) und dann die GeoTiff-Kalibrierung in KAL umschreiben.

Kennt sich damit jemand aus? Es wäre schön, wenn das klappen würde. Ein Vorteil: die Tools arbeiten dateibasiert und müssen nicht unbedingt die Gesamtbitmap im Speicher halten, d.h. es gibt wenig Größenlimits (TIFF auf 4 GB, andere Bitmaps sind unlimitiert). Mit so großen Dateien haben viele andere Windowsprogramme Probleme.

In den FWTools gibt es auch eine Version der GDAL für die Windows-Commandline compiliert:
http://fwtools.maptools.org/

Eine Projektionsfrage an Peter:
macht Glopus intern folgende Projektion von Long/Lat-Koordinate auf Pixelkoordinate?
y = A x + y0
Ich meine nicht die Bildpunkte selbst, sondern nur die Koordinatenzuordnung. Diese Gleichung mit der 2x2 Matrix A und Offset y0 hat nur 6 Unbekannte, d.h. mathematisch würden 3 Kalibrierpunkte zur vollständigen Bestimmung reichen. Der 4. Punkt würde da im Prinzip nur Fehler ausmitteln. Oder ist der 4. Punkt mathematisch relevant, wenn andere Projektionen gemacht werden (Trapezform)?

Zitat

Original von frank334
Oder ist der 4. Punkt mathematisch relevant, wenn andere Projektionen gemacht werden (Trapezform)?

So ist es. Übrigens auch irgendwo auf der Glopus Seite beschrieben. :gap

glopus.de:
Mit der Definition des 1. Punktes wird die Karte "verschoben", beim 2. Punkt wird die Karte "skaliert", der 3.Punkt veranlasst eine Kartendrehung und über den 4. Punkt wird ggf. eine trapezförmige Zuordnung definiert.

Ist mir jetzt aber immer noch unklar. Heisst dein "ggf.", dass momentan "nur" obige Gleichung benutzt wird, aber momentan noch keine trapezförmige Verzerrung? Diese Frage hat mich bei der Programmierung des GoogleEarth-Overlays beschäftigt, da dort keine Trapezform möglich ist. Ich bin nur neugierig Auswirkungen hat das wahrscheinlich nur minimale. Der Hauptanteil ist die Rotation, wie man visuell an den eingezeichneten Kartenecken erkennt. Auch die GoogleEarth-Overlaykacheln passen gut zusammen, obwohl "nur" rotiert wird. Die Rotation ist dagegen schon sehr wichtig und wohl der Hauptgrund, warum ich damals bei der manuellen 2.Punkt-Kalibrierung der Topo-Karten nie zufrieden war.

"Ggf.", weil man ja nicht unbedingt 4 Punkte kalibrieren braucht. Die Berechnung ist exakt (Kannst man auch nachprüfen). Wird aber eher selten richtig notwendig sein.

Was heisst schon exakt, wenn eine Kugel auf eine Fläche plattgedrückt wird? Es gibt natürlich eine exakte Long/Lat-Abbildung auf eine Mercatorkarten-Koordinate. Diese Transformation machst du aber nicht, sondern eine gute lineare(?) Approximation, oder? Denn sonst müsste man den Zentralmeridian kennen. Ich frag mich nur, ob du die lineare y=Ax+y0 - Form oder eine Art trapezförmige Abbildung machst, d.h. dazu den 4. Kali-Punkt benutzt. Ansonsten wäre er mathematisch überflüssig. Die o.g. Formel kann nur ein Parallelogramm machen, aber kein Trapez.

p.s. beim GoogleEarth-Superoverlay habe ich sogar noch einen Variable weniger, denn die Kacheln können nur drehen, aber nicht scheren. So gesehen wäre das mit 3 Kalibrierpunkten sogar noch überbestimmt. Meine Winkelberechnung ist anscheinend auch nicht ganz exakt. Bei Top200-Kacheln merkt man schon kleine Sprünge.

Exakt heißt, wenn du 4 Punkte kalibrierst und diese Koordinaten z.B. in die GoTo Seite eingibst, dann werden die Positionen wieder exakt an den Kalibrierungspunkten eingezeichnet. Also die 4 Punkte sind exakt, aber es wird nichts über die anderen Bildpunkte oder Projektionsarten ausgesagt. Bitte verlange nicht, dass ich die Rechnung hier poste.

Hmm, eine Abbildung mit 2x4=8 Parametern, dann also doch keine Lineare Form. Gut, musst du nicht sagen, aber schlimm wäre das auch nicht. Bei einer Topo-Karte bin ich auch immer froh über Angaben wie UTM-Projeziert etc. Dann kann sich die nachgelagerte Bildverarbeitung daran orientieren.

Aber zurück zu der ursprünglichen Frage: hat denn keiner Erfahrung mit den GDAL-Tools? Wäre doch toll, man könnte die großen gescannten Mercatorkarten gut kalibriert für Glopus aufbereiten.

Sehr große Bitmaps wird GMM in naher Zukunft noch nicht bearbeiten können, Mercator wohl schon.
Noch mal zur Kalibrierung, schau dir mal an wie man bei OpenGL o.ä. arbeitet. Die perspektivische Darstellung in Glopus macht ja auch nichts anderes als Karten drehen und trapezförmig verzerren. In Glopus ist allerdings keine fertige OpenGL o.ä. lib verdrahtet. Ich habe da selber eine funktionsorientierte Mathe eingebaut, damit das möglichst schnell rechnet.

Ok, werde ich mir mal anschauen. Computergrafik mit OpenGL hatte ich noch nicht gemacht.

Ja, das mit Mercator in GMM ist sicher gut. Von der Bitmapgröße würde ich mir eine große Papierkarte vorstellen, die so im Copyshop gescannt wird dass alle Details noch zu sehen sind. Weiss nicht, wie gross das am Ende wird, wohl im Gigabyte-Bereich. Neben GMM ist aber sicher auch eine Commandline-Lösung mit den GDAL-Tools interessant, weil es dort kein Größenlimit gibt und die Tools an spezielle Anforderungen angepasst werden können. Ich dachte z.B. die Kalibrierpunkte aus Ozi-Karten automatisch dort übertragen zu lassen und so große Mercator/Lambert-Ozi-Karten in Glopus-Kacheln zu zerstückeln. Nur müsste mir dann erstmal jemand erklären wie man gdalwarp oder gdal_translate zu dieser Kachelung bewegt. Bei mir kam nur eine einzige blaue Fläche heraus, ohne Inhalt.