Entzerren von Kartenscans

@MasiMaster

Das Problem ist nich die Vingettierung und Chromatische Aberation…
Da sollte bei guten Cameras (Spiegelreflex) ein Programm beiliegen das dies ausgleicht.
Auch das Drehen wenn es etwas schief aufgenoimmen ist ist hier nicht das Thema

@ Beitag von Kellerma
Bis Punkt “F” ist das so in Ordnung (= nee gedrehte und gezerrte Karte)
Das Problem und da will ja evtl. der Themenstarter hin ist das MercatorTiler.jar immer nur eine Karte bearbeitet - es währe purer Zufall wenn die Kartengrenze zufällig mit einer Tilegrenze zusammenfallen würde(= irgendwo müssen in einem Tile 2 Kartenteile rein).

Im prinzip muß aus den überlappenden/angrenzenden [wenn die unten aneinandergrenzen müssen sich diese oben überlappen] Karten (mindestens 2) eine gemacht werden.
Ich kenne eigentlich nur ein Programm das etwas ähnliches macht wenn auch eigentlich in die andere Richtung ( 1 bis mehrere große Karten viele kleine Karten). Für hinweise für Programme die sowas machen können hät ich nichts dagegen.

Ich danke für Euer Feedback.

Ich werd am Wochenende mal versuchen Deine Beschreibung, Kellerma, nachzuvollziehen - bis “A” war es mir schon mal nicht neu :slight_smile: - soweit mir das als Commandline Dummi gelingt. Ich muss zuvor einige der Karten neu abfotografieren die mir noch zu unsauber sind (die Probleme gehen noch weiter: die Karten enthalten Knicke, die das Bild wölben, sie sind auf schlechtem Papier gedruckt und kontrastschwach… und und und)

Ich hab den Eindruck dass der Glopus Map Manager, den hier keiner zu kennen scheint, mir die Ausrichtung der Karten anhand des Mittelmeridians des Kartenwerks abnimmt, und auch die Umprojektion der Rohkarten überflüssig machen müsste, weil Glopus die Karten nicht bloss oben links sondern an 4 beliebigen Punkten der Grafikdatei, sinnvollerweise Kartenecken, georeferenziert und man die Art der Projektion einstellen/auswählen kann. World-files benötige ich am Ende nicht; Glopus hat da eine eigenen Kalibrierungsstandard, der sich mit ein paar Hilfsprogrammen aber in gängige Formate umrechnen lässt, sicher auch world-files. Soweit bin ich noch nie durchgestiegen denn ich verwende weder Google Earth noch erstelle ich (bisher) meine eigenen Karten. Obwohl ich das, was Netzwolf an historischen Karten gezeigt hat schon sehr nett finde.

Was leider fehlt beim Glopus Map Manager, ist die Funktionalität des Abtrennens der Papierränder einer Rohkarte, sozusagen alles abzuschneiden was außerhalb der Eck-Referenzpunkte der Rohkarten liegt, und erst hinterher zu tilen. Das macht zwar keine Schwierigkeiten mit der Kalibrierung, aber bewirkt eben dass auf den berechneten Tiles diese Ränder die Inhalte der benachbarten Tile verdecken, auch wenn es nur 7mm sind. Und das sieht halt hässlich aus und es “fehlt was”. Vielleicht hab ich die Frage auch im falschen Forum gestellt und jemand anders der Glopus benutzt kennt den Trick.

Für mich ist die Beschäftigung mit dem Thema noch recht neu, weil es mir erstmals überhaupt gelungen ist die hier genannten Karten in befriedigender Qualität zu digitalisieren. Das ist sicher erst der Einstieg. Ich hab, seit fast 20 Jahren, noch eine Sammlung von A4-Handscans von KDR Karten (1:100.000) aus der Zeit 1875-1945 in befriedigender Qualität, die stehen dann hinterher an. Diese Karten haben mir in der Altstraßenforschung schon gute Dienste geleistet und sind verglichen mit den PGK und Reymann topographisch sehr präzise; aber um etwas von ihnen zu haben müssen diese Probleme gelöst sein…

Das mit dem Glopus Map Manager dürfte einigen schon bekannt sein.
Nur habe ich es noch nicht damit geschaft die Projektion zu ändern.
Normalerweise stört das nicht (bei kleinen Zoomstufen) weil mach aus großen Karten viele Kleine und durch die 4-Punktkalibierung ist der Fehler normalerweise unter 1 Pixel.

Deshalb erstmal wie von Kellerma umprojektieren und dann mit Glopus Map Manager (alle Karten auf einmal) Neu Berechnen lassen und als 4000*4000 Pixel-Karten ausgeben. Diese kann man ja weil GEODETIC in einem Graphikprogramm zusammenstitchen.

Und da der MercatorTiler.jar auch mit großen BMP’s umgehen diese dann als Tile ausgeben.

Ja Noch: Bei dem Kartenrand sollte doch einfach ein Abschneiden der Ränder des Orginalfotos reichen oder sehe ich da was falsch?

Nahmd,

Das aber kann doch jede Bildverarbeitung? Polygon aus 4 Punkten setzen, clippen (Fläche außerhalb wird transparent), speichern, done.

Wir haben hier (Köln) einen kalibrierten A3-Überformat Heidenhein-Scanner stehen. Damit ist die AV von 1885 gescannt. In vernünftigem Umfang können wir da auch Deine schweren Fälle drauflegen. Das Gute ist die große Fläche, da braucht man die alten Karten nicht zu quälen. Und ich glaube, die Kiste weiß noch nicht einmal, wie man “Verzeichnung” schreibt.

Glücklicher!
Ich bin immer noch auf der Suche nach antiquarischen AV-Karten; die werden aber oft nur zur horrenden Preisen angeboten. :frowning:

Gruß Wolf

“Nachdem” sie im GMM kalibriert ist, meine ich. Sozusagen in der (rechteckigen) Bildschirmansicht…

Die einseitige 0,7% Verzerrung habe ich jetzt mit GIMP rausgekriegt (Perspektive korrigieren) und konnte die Ränder grade abschneiden. Das mit den “Beulen” beschäftigt mich noch.

Der wäre für die alten KDR-Karten mit ihren ungeheuer feinen Details wohl genau richtig, die haben annähernd A3. Die PGK hat denselben Blattschnitt und ist leider etwas über A3. Meine PGK-Drucke sind allerdings wellig, total vergilbt, ein paar haben Knicke (weil ich sie mal versucht habe stückweise einzuscannen) und das Papier ist faserig und billig, der “antiken” Wirkung wegen. Ich muss sie wohl eh neu anschaffen (LV Hessen); sie sind nicht teuer.

Wenn Du Karten der Alpen suchst, hast Du’s schon mal an der nächsten Unibibliothek probiert? (wobei, wenn Du aus Köln bist…)

Zum Erzeugen von Tiles aus mehreren Kartenteilen hatte ich mal gdal2tiles zusammen mit dem GDAL VRT Meta-Format verwendet. gdal2tiles wird auch in dem bereits erwähnten MapTiler verwendet.

Beispiel für zwei Kartenteile (karte-1-0.png und karte-1-1.png):

  1. Kartenteile georeferenzieren (hier über Eckpunkt-Koordinaten), vrt XML Datei enthält Referenz auf png Datei

gdal_translate -of VRT -a_srs EPSG:4326 ^
-a_ullr 9.33164083610756 47.7346276156722 9.38562491608134 47.7159923753746 ^
karte-1-0.png karte-1-0.vrt

gdal_translate -of VRT -a_srs EPSG:4326 ^
-a_ullr 9.33189174563309 47.7175022162899 9.38585813297247 47.6988579268 ^
karte-1-1.png karte-1-1.vrt

  1. vrt Dateien der Kartenteile zu einer Datei (karten.vrt) mergen (nur virtuell im XML, pngs weiterhin separat)

gdalbuildvrt karten.vrt karte-1-0.vrt karte-1-1.vrt

  1. gemeinsame Tiles für alle Kartenteile erstellen

gdal2tiles -z 8-16 karten.vrt tiles

Die Tile-Nummerierung erfolgt allerdings nach dem TMS Schema mit umgekehrtem y-Ursprung. Das kann man aber per Script umbenennen.

Bei rechteckigen Teilen mit leichter Überlappung hat die Methode gut geklappt, wie gut das in diesem Fall funktionieren würde, kann ich aber nicht sagen. Die gdal_translate aus obigem Beispiel müssten im Schritt F) der Anleitung von kellerma vermutlich in etwa so aussehen (nicht getestet):


gdal_translate longlat.tif -of VRT longlat.vrt

Gruß,
Norbert (ikonor)

Hi ikonor,

dass mit VRT und gdal2tile.py ist ein guter Hinweis!
Vgl. auch http://code.google.com/p/tilers-tools/

Oh, dann ist isse ja gar kein “+proj=lcc +lat_1=47d16 +lat_2=54d54”,
sondern ein “+proj=eqdc +lat_1=50 +lat_2=50”
oder so ähnlich :wink:

Die gute Nachricht: Es geht!
Die schlechte: Anders als erwartet :wink:

Bin gestartet mit “141 Cöln” und “161 Coblenz”.
Nota bene: Die beiden Karten stoßen “diagonal” zusammen, d. h.
lower right lr(141) = upper left ul(161)
A) + B) wie gehabt.
Statt wld-File mit “-a_ullr” georeferenziert, erspart das mühsame “Skalierungsfaktor rumgerechne”.
dann gdal_translate nach vrt mit ikinor-Methode, anschließen ge-warp-t.
Zum Anglotzen zurück ins jpg: Soweit so gut.

Jetzt “160 Andernach” mit ins Boot geholt, ergibt quasi “Karten-Dreieck” und
nun ist letzteres nicht mehr “tight” an den anderen beiden anliegend,
da ur(160) js nicht verwendet wird bei der 2-Punkte-Kalibrierung (nur ul(160) sowie lr(160).
Versucht via “gdal_translate -gcp” einen 3. Kalibrierungspunkt “reinzumogeln” (nämllich ur(160) was ja = lr(141) = ul(161) ist), aber nun steigt gdalbuildvrt beim mergen der 3 Teilkarten aus :frowning:

Zu guter letzt in qgis “3-Punkte-Kalibrierung” am 160er vorgenommen, und nun stoßen die 3 zusammen.
Bei 4er-Kalibrierung an jeder Teilkarte mit lr(n)= ll(n+1), ur(n) = ul(n+1), etc. und darunter/darüber entsprechend:
Alles wird gut ™

Zum Thema HISTORISCHE KARTEN ein gigantischer Link:

http://www.davidrumsey.com/blog/2011/4/10/karte-des-deutschen-reiches-1893

Diese Karten können für Glopus auf einfachste Weise kalibriert werden.
Die Auflösung dieser scans ist für “normale Kartenzwecke”, um es nicht übertrieben zu formulieren, mehr als hinreichend.

Muss ich zur KDR (Karte des Deutschen Reiches) etwas sagen? Ich denke, in einem so speziellen Forum sollte jedes Lob dieses Kartenwerks überflüssig sein weil jeder seine Bedeutung und sagenhafte Qualität kennt oder zumindest kennen sollte. :slight_smile:

Naja, die Hauptarbeit (Entzerrung) wurde bereits von Cartography Associates geleistet, so dass diese Bilderchen schon “googletauglich” sind :wink:

…und das Entzerren ist noch die kleinste Arbeit, oder Quelle möglicher Ungenauigkeit, weil diese Karten nahezu rechteckig sind. Die Vorlagen sind aber noch dazu wellig, in Schnippeln auf Leinwand aufgezogen… GIMP-Dilletanten wie ich würden sich daran totarbeiten… :slight_smile:

Was die Genauigkeit der Reymann’schen Karte angeht: die kann man mangels angegebener Eck-Koordinaten eh’ nur nach ungefähren Eck-Ortschaften u.dergl. kalibrieren. Nimmt man dann den Fuß, das Kreuz oder die Mitte des Dorfsymbols dafür her? Was oft schiefgeht in Verbindung mit den Nachbarkarten. Die Ortschaften liegen nämlich manchmal 1km weiter weg wo sie sein sollten, was in der Karte nur 0,5cm ausmacht aber in der Vergrößerung auf dem Bildschirm vielleicht 100 Pixel. Was aber auffällig ist: die Reymnannkarten übernehmen die Lagefehler der Preußischen Generalstabskarte, nach der sie offenbar (zumindest in meiner Region) gezeichnet ist. 1km bei 1:86.400 ist dann aber schon mehr wie 1cm. Mal liegt der Ort links davon wo er liegen sollte und mal rechts. Aber immer sind die Fehler gleichartig (obwohl die Karten von mir auf unterschiedliche Art entzerrt und georeferenziert sind). Von dieser Art groben Schnitzern ist die KDR echt frei. Wenn da etwas schief liegt, liegt es an der Generalisierung, Aufnahmefehlern, oder man selber hat die Kalibrierung irgendwie verbockt.

Ungeachtet der Warnung könntest Du doch die Eckkoordinaten benutzen und nach Post #39 vorgehen, denn
dann brauchst Du nur noch lim(n->unendl.) ((n+1)(n+1))/(nn) = 1 Kalibrierungspunkt pro (Teil-)Karte :wink:

Man kann das Ganze ja auch mal ein JP2-File runterladen. Hat nur schlappe 2,5 GB. Kann man da irgendwas mit anfangen? Kann man wieder automatisch kacheln und z.B. als WMS in JOSM laden?

Christian

Ich hab mich jetzt auch ein wenig mit dem selbertilen beschäftigt:
http://wiki.openstreetmap.org/wiki/User:Ajoessen/eigene_Tiles

Gruß,
ajoessen

Diese Karten sind allerdings in Polyeder-Projektion, und lassen sich nicht ohne weiteres “zusammenkleben”:

http://www.posselt-landkarten.de/geschichte_der_kdr.htm
http://www.geog.fu-berlin.de/2bik/Kap4/kap4_1-05.php3
http://www.informatik.uni-leipzig.de/~sosna/karten/polyeder.html

Gruß,
ajoessen

Doch, das geht mit GMM problemlos.

Hier ein noch gigantischerer Link für die API-lose Zeit:
http://lib.byu.edu/digital/germanmaps/

Was Geogreif nur in niedriger Auflösung bietet, hier 13MB je Messtischblatt.
Originale im Vorkriegszustand, teilweise nach US-Luftaufnahmen von 1944 überarbeitet.

Referenzierungsdateien werden zwar auch angeboten, sollen aber nicht unbedingt hochwertig sein.

Gruß,
ajoessen

Gute Quelle, kannte den Link schon, habe aber erst jetzt den “download” button für die Karten entdeckt.
Wobei die Scans leider im Unterschied zu Geogreif teilweise üble Verzeichnung haben und auch wellig sind.
Kein Wunder dass sie in diesem Zustand nicht sonderlich genau zu kalibrieren sind.

GIMP bietet in der Funktion “Verbiegen” (Korrektur von Verzeichung), die hierfür zu grob ist, eine zusätzliche Option Kontrollkurven/Ausrichtungskurven hochzuladen, genannt POINTFILE_CURVE_BEND. Mit dessen Syntax komme ich aber irgendwie nicht klar; ein Tool eine solche Kurve zu erstellen hab ich nicht gefunden, dokumentiert ist dieser Teil anscheinend nicht. Optimal wäre natürlich eine Art Funktion die Karte mit allen Unregelmässigkeiten wie mit der GIMP Schere entlang ihrer Ränder auszuschneiden und dann rechteckig zu machen. Ein entsprechender Algorythmus muss dieser Funktion ja irgendwie zugrundeliegen.

ajoessen’s “Referenzierungsdateien werden zwar auch angeboten, sollen aber nicht unbedingt hochwertig sein” bezieht sich wahrscheinlich auf den Aussagen aus dem QuoVadis (TTQV)-Forum,
siehe auch http://forum.openstreetmap.org/viewtopic.php?pid=232346#p232346

Ich selbst hab’ mir mal eine angeschaut, und wirklich, bei den Angaben:
northlimit=… eastlimit=… southlimit=… westlimit = …
ergab sich eine Abweichung von ca. 300 m :frowning:
Dies wird wohl auch auf die mitgelieferten kml- bzw. tfwx-Daten zutreffen.

Dann habe ich die Karte selbst ausgeschnitten und georeferenziert und es passte,
(soweit ich das anhand der tiles - die api steht momentan ja nicht zur Verfügung - beurteilen konnte).
Der “wellige Rand” hingegend ist so gesehen noch das kleinere Übel …

+1
Yep, sowas fände ich auch schön: Da man nicht ausgehen kann, dass selbst beim vorsichtigen Scannen
der Kartenrand pixelgenau parallell zum äußeren Rand der Karte wird und man so stets ein (bestenfalls) Viereck bekommt,
geschweigedenn ein Trapez oder gar Rechteck.

Trapez ist nicht schlimm, da man ungleichmässige Ecken mit dem Entzerren im GIMP in WISIWYG Ansicht wegbekommt. Aber nur immer **eine **pro Seite. Keine Verzeichnung.

Was die Kalibrierung angeht, kamen die Amis wohl mit den geographischen Daten nach Potsdam/Rauenberg nicht zurecht und haben es wohl falsch korrigiert. Das ergibt genau 300m Abweichung. Der Blattschnitt entspricht genau den Vorkriegsblättern (wie auch bei Geogreif; man kann die Kalibierungsdaten von diesen verwenden, wenn man PDT berücksichtigt mit den “graden” Gradangaben, allerdings nur bei den Blättern mit Vorkriegsursprung). In diesem Dokument findet sich auf Seite 4 eine Grafik die die Auswirkkungen eines “falschen” Datums anzeigen.

Der Bestand der Blätter ist sehr unterschiedlich; es sind einige sehr billige Lichtpausen dabei, aber auch einige wunderschöne sechsfarbige in Kupfer- oder Stahlstich mit unglaublichem Detaillierungsgrad. Solche Blätter gab es in unserer Region bis 1973, danach wurden sie immer mehr vereinfacht und Informationen weggelassen. Eine Hauptmotivation für mich bei OSM mitzuarbeiten ist, einmal wieder solch gute Karten zu haben… (wobei sich die Landschaft ja leider stellenweise ebenso “vereinfacht” hat) :roll_eyes: