Entzerren von Kartenscans

Kann QGIS das nicht so wie Du das brauchst? http://www.geoportal.rlp.de/mediawiki/i … renzierung

Ab Photoshop 7 nach oben gibt es eine Entzerrfunktion:
Einfach mit Photoshop aufmachen, Häckchen "Perspektivisch" anklicken. Dann zeichnest du ein Auswahlviereck über die Kartenkanten. Enter.
Anschließend die Größe überprüfen und ggf korrigieren mit Alt+Stg+I : gewünschte Werte eingeben, enter, sichern.

Wenn du kein Photoshop hast, kann man auch die Hugin (mit den Panoramatools) (ein Freeware Programm, mit dem man Panaramafotos zusammenfügen kann) missbrauchen. Ist aber leider sehr viel Zeit nötig, um sich einzuarbeiten und gute Ergebnisse zu bekommen. Lohnt sich praktisch nur, wenn du es schon kennst.

Nahmd,

MasiMaster wrote:

Wenn du kein Photoshop hast, kann man auch die Hugin (mit den Panoramatools) (ein Freeware Programm, mit dem man Panaramafotos zusammenfügen kann) missbrauchen. Ist aber leider sehr viel Zeit nötig, um sich einzuarbeiten und gute Ergebnisse zu bekommen. Lohnt sich praktisch nur, wenn du es schon kennst.

Wenn die Karten überlappen, kann man die damit auch wunderbar zusammenkleben.
Aber in der Tat lohnt die Einarbeitung für einmalige Anwendung nicht.

Gruß Wolf

Dieses Problem kenne ich aus eigener Erfahrung in der Vergangenheit.
Man wird da auch nicht so recht glücklich mit dem hauseigenen A4-Flachbett-Scanner.
Nachträgliche Entzerrung o.ä. bringt da auch kaum Erfolge.

Das Problem beginnt beim Scanner; wählt man den gesamten A4-Bereich so kommt es zu den Rändern hin zu Verzerrungen.
Wählt man einen kleineren Bereich (etwa 2/3 Bildausschnitt), so lassen die Verzerrungen stark nach und man erzielt relativ brauchbare Ergebnisse.

Die beste Lösung ist, wenn man mit der Karte einen Copy-Shop aufsucht.
Die Jungs haben ganz andere Hardware und scannen dir die Karte für wenig Geld verzerrungslos ein.

mfG Michael

tiototo wrote:

Kann QGIS das nicht so wie Du das brauchst? http://www.geoportal.rlp.de/mediawiki/i … renzierung

Zur Georeferenzierung von Orthofotos, und anderen schon entzerrten Karten habe ich schon ein Tool (Glopus Map Manager).
Es geht um den Bearbeitungsschritt vorher.
Und die Kartenblätter überlappen nicht.
Es geht um Karten wie diese: http://greif.uni-greifswald.de/geogreif … oblenz.jpg also durchaus nicht um home-scans. Auf den ersten Blick sind sie durchaus rechteckig, aber eben nicht wirklich genau.

Hallo,

ich mach das so: Ich scanne die Karte überlappend. Danach verwende ich Photoshop Elements (ist ein semiprofessionelles Programm, was nicht allzu viel kostet). Danach setze ich die einzelnen "Schnippel" mit der "Panoramafunktion" zusammen. Dabei bleiben in den äußeren Randbereichen (Kartenrand) natürlich noch kleinere Ungenauigkeiten übrig, die ich nicht für sonderlich wichtig erachte. Man kann die Karte danach an den Rändern auch entsprechend zuschneiden, um diese zu egalisieren. Vermutlich gibt es auch noch andere Programme als "freeware" mit denen du ähnliche Ergebnisse erzielen könntest. Schau einfach mal nach.
Gruß, Burkhard (harzguide)

Ich nehme mal an du willst das so haben:
http://img191.imageshack.us/img191/4203/161coblenz2.jpg

besser hab ich es auf die schnelle leider nicht hinbekommen...
und die "Erdoberflächen-Krümmung" hab ich auch nicht rausgerechnet. Aber die dürfte bei dem Maßstab ohnehin sehr gering sein.

Nein das ist es nicht. Georeferenzierung ist keine Drehung; sie ist wiederum eine Verzerrung entsprechend der Eckkoordnination. Dazu verzerrt man nicht die Grafikdatei; die bleibt wie sie ist. Zunächst muss das Bild aber *entzerrt* werden, damit die Ränder rechtwinklig sind und exakt abgeschnitten werden können und das Nachbarbild georeferenziert dranpasst. Die ungleichen Ränder sind kein "Fehler" beim Scannen oder so etwas; sie sind schon so im Original durch die Polyederprojektion. Ungenauigkeiten im Druck oder im Scan verschlimmern die Sache noch...

Taunide wrote:

Nein das ist es nicht. Georeferenzierung ist keine Drehung; sie ist wiederum eine Verzerrung entsprechend der Eckkoordnination. Dazu verzerrt man nicht die Grafikdatei; die bleibt wie sie ist. Zunächst muss das Bild aber *entzerrt* werden, damit die Ränder rechtwinklig sind und exakt abgeschnitten werden können und das Nachbarbild georeferenziert dranpasst. Die ungleichen Ränder sind kein "Fehler" beim Scannen oder so etwas; sie sind schon so im Original durch die Mercatorprojektion.

g**gle ist da anderer Meinung 😉
g**gle sagt, die Reymannschen Karten sind konisch, also Kegelschnittprojektion und nicht mercatorisch (Zylinderprojektion).
MasiMaster hat das schon ganz gut hinbekommen, durch den großen Maßstab schaut dies "nur" wie eine Drehung aus.
Im thread http://forum.openstreetmap.org/viewtopic.php?pid=216232 wird das bedingt durch den viel kleineren Maßstab für
Süd-Südamerika (ONC T-18) viel deutlicher: LCC (Blattausschnitt rechteckig, Koordinatenkreuz konisch) vs. EPSG:4326 (Bild konisch, Koordinaten rechtwinklig)

Ich sehe da gar keine Probleme!

Die Reymannschen Karte ist doch rechteckig!!

Also auschneiden das der Rand weg ist und kalibrieren fertig (Natürlich mit der Richtigen Projektion und Kartendatum).

Das die Karte Bündig an die Nächste passt erledigen doch die entspechenden Programme wie OziExplorer, Glopus usw.

Eines würd ich gerne auch noch haben das so kalibrierte Karten in das füe OSM übliche Tile-Format schneidet!!!

quasilotte wrote:

Die Reymannschen Karte ist doch rechteckig!!

Die Karte ist (streng genommen) nicht ganz rechteckig, da man den Rand (der bemalten Karte)
(zur Gradeinteilung hin) offensichtlich per Hand und nicht mit dem Lineal gezeichnet hat und
daher kleine "Wellen" aufweist.

Taunide schreibt immer von "Entzerrung": Ich interpretiere dass so, dass er meint,
dass die "15'-Marke" am oberen Rand etwas weiter vom linken Blattrand entfernt ist
als die die untere "15'-Marke". Dies ist, wie ich oben schon geschrieben
habe, ein Folge der LCC-Projektion.

Moin,

Taunide wrote:

Auf den ersten Blick sind sie durchaus rechteckig, aber eben nicht wirklich genau.

Die Meridiane auf der Karte laufen definitiv nach unten auseinander; die Teilstriche auf der unteren Skala sind etwa 0.7% bis 0.8% breiter als die der oberen Skala. Das ist aber keine Fehler oder eine "Verzerrung", sondern ein Ausdruck der Präzision der Karte: im Rahmen der Messgenauigkeit ist die auf Breitenkreisen und Meridianen entfernungstreu. Nehmen wir mal unten 50°25' und oben 50°45' an, so sollte die Vergrößerung cos(50.42°)/cos(50.75) = 1.007 ~ 0.7% sein. Passt.

Wenn auf der Karte die Breitenkreise durchgezogen wären vom linken zum rechten Rand, würde man sehen, dass die gebogen sind: Kegelprojektion. Die Umprojektion von Kegel (Meridiane→Geraden, Breitenkreise→Kreisbögen) nach Zylinder (Meridiane und Breitenkreise →Geraden) ist keine normal Bildbearbeitungsfunktion. Mit Photoshop kann man da immer was frickeln, man ruiniert aber die Präzision der Karte.

Also entweder Du nutzt ein zur Kartenumprojektion geeignetes Tool, oder Du verlierst Genauigkeit.

Ganz allgemein zum Vorgehen: ich würde zuerst die Einzelblätter zusammenkleben und dann die Umprojektion durchführen. Da ich die Parameter nicht als Zahlen habe, sondern aus Pixelpositionen von Breiten und Längenlinien bestimmen lassen muss, ist der Fehler umso kleiner, je weiter die "Passpunkte" voneinander entfernt sind.

Mache ich die Umprojektion für jedes Kartenblatt einzeln, so werde sehr wahrscheinlich unterschiedliche Parameter benutzt, wodurch die Ergebnisse nicht mehr sauber zusammenpassen.

Gruß Wolf

Nahmd,

quasilotte wrote:

Eines würd ich gerne auch noch haben das so kalibrierte Karten in das füe OSM übliche Tile-Format schneidet!!!

Vielleicht kannst Du damit was anfangen?

Gruß Wolf

Edit: Link entfernt (an Qualitätskontrolle gescheitert)

Netzwolf wrote:

quasilotte wrote:

Eines würd ich gerne auch noch haben das so kalibrierte Karten in das füe OSM übliche Tile-Format schneidet!!!

Vielleicht kannst Du damit was anfangen?

Nein,
$ java -jar MercatorTiler.jar --image ../../data/greif.uni-greifswald.de/161Coblenz.jpg --bounds 7.6,50.33,8,50.66
Exception in thread "main" java.lang.NullPointerException
at info.netzwolf.cartography.MercatorTiler.main(MercatorTiler.java:310)

Oder doch 😉
$ java -jar MercatorTiler.jar --image ../../data/greif.uni-greifswald.de/161Coblenz.jpg --bounds 7.6,50.33,8,50.66 --tiledir blub
$

Nahmd,

Netzwolf wrote:

quasilotte wrote:

Eines würd ich gerne auch noch haben das so kalibrierte Karten in das füe OSM übliche Tile-Format schneidet!!!

Vielleicht kannst Du damit was anfangen?

Meine Antwort bezog sich auf die Frage von quasilotte nach so kalibrierte Karten in das übliche Tile-Format schneiden und nicht auf die Reprojektion der Reymannschen Karte. Für letzteres gibt es fertige Lösungen.

kellerma wrote:

Nein,
$ java -jar MercatorTiler.jar --image ../../data/greif.uni-greifswald.de/161Coblenz.jpg --bounds 7.6,50.33,8,50.66
Exception in thread "main" java.lang.NullPointerException
at info.netzwolf.cartography.MercatorTiler.main(MercatorTiler.java:310)

Oder doch 😉
$ java -jar MercatorTiler.jar --image ../../data/greif.uni-greifswald.de/161Coblenz.jpg --bounds 7.6,50.33,8,50.66 --tiledir blub
$

Der will halt wissen, wohin mit den Kacheln.
Doch auch wenn er das weiss: ohne vorherige Umprojektion werden diese Kacheln wenig hilfreich sein 🙂

Gruß Wolf

Netzwolf wrote:

Nahmd,

Netzwolf wrote:

quasilotte wrote:

Eines würd ich gerne auch noch haben das so kalibrierte Karten in das füe OSM übliche Tile-Format schneidet!!!

Vielleicht kannst Du damit was anfangen?

Meine Antwort bezog sich auf die Frage von quasilotte nach so kalibrierte Karten in das übliche Tile-Format schneiden und nicht auf die Reprojektion der Reymannschen Karte. Für letzteres gibt es fertige Lösungen.

Gruß Wolf

Mein post hatte 2 Absichten:
1) den Leuten zu zeigen, wie man das Teil aufruft. Denn mit einem so "dahingeworfenem" jar-file kann nicht jeder sofort damit was anfangen.
2) Dich ermuntern, die Fehlermeldung zu erweitern , denn fehlt das Bild beim Aufruf, kommt
eine ordenliche Fehlermeldung und kein Absemmeln 😉

Alles klar?

Danke !

MercatorTiler.jar funktionier wunderprächtig!

Somit kann ich im Mobile Atlas Creator die Scan's in das Format bringen welches ich möchte!

bzw.

Ist jetzt ein direktes Überlagern mit einem anderen Layern nur noch ein Kinderspiel!

Netzwolf wrote:

Edit: Link entfernt (an Qualitätskontrolle gescheitert)

Sei ein Wolf,
komm aus Deiner Schmoll-Höhle,
spring über Deinen eigenen Schatten
und reich die Pfote!

Nahmd,

kellerma wrote:

komm aus Deiner Schmoll-Höhle,

Schmollhöhle? Schön wärs ja. Eishöhle!
Hab heute morgen beim überstürzten Aufbruch verpennt, das Fenster zu schließen. 🤔

Wegen des Tilers: die Kritik war berechtigt. Das Teil ausgehfein zu machen braucht aber was Zeit.

Gruß Wolf

Netzwolf wrote:

Das Teil ausgehfein zu machen braucht aber was Zeit.

Windows-Nutzer können bis dahin vielleicht mit maptiler was anfangen.

Ich würde wohl auch sagen, dass ein Copyshop zunächst mal die erste Anlaufstelle wäre, wie r-michael schon gesagt hat, die machen mal den ersten Schritt professionell. Danach würde ich auch versuchen mit Photoshop oder Gimp (da weiß ich aber nicht wie die Funktionen genau heißen, finde das Programm etwas verwirrend) alles nach zu bearbeiten. Da kann man ja viel machen!

Papierverzug ist nicht ganz was für Laien, die Hardware ist nicht allein entscheidend,
hier ist gemäß http://de.wikipedia.org/wiki/Papierverzug eine Berechnung und die Einrichtung diverser Passpunkte erforderlich. Mit der geeigneten GIS-Software lassen sich dann erstaunlich genaue digitale Karten erzeugen.
Mit Photoshop ist es sicher möglich aber ein Glücksfall, wenn es klappt.

Fragt mal beim nächsten Vermessungsamt nach, manche sind erstaunlich hilfreich.

Kartenscans entzerren kann man auch mit der Freeware Shift-N. Die wird üblicherweise von "Pedanten" benutzt um stürzende Linien auf Kirchturmfotos u.ä. zu beseitigen, wodurch die Perspektive hinterher oft völlig unnatürlich wirkt. Für den Hausgebrauch taugt die auch zum Rechteckigmachen von Kartenscans. Wie gesagt, das muss man nur machen muss wenn man mehrere, nicht überlappende Kartenblätter eines größeren Werks zusammensetzen will. Korrekt georeferenzieren kann man auch ein nichtreckiges Bild, nur wird es in der Darstellung in der Kartenansicht dann umso verzogener und unschärfer wirken je nichtrechteckiger es war.

EDIT:: BESSER MIT GIMP! (Werkzeuge -> Transformation -> Perspektive)

Bei schon im Original welligen, evtl. ohne Lineal gezeichneten Kartenrändern braucht man aber ein echtes Grafikmanipulationsprogramm zum "Beulen entfernen". Ohne die scheitert auch jede mathematisch noch so korrekte Rückprojektion von Mercator, Kegel oder wasweissich.

Im Arbeitsablauf davon unterscheiden muss man das georeferenzieren/kalibieren - trivial bei diesen Karten mit "gängiger" Längen+ Breitenangabe - und das Tilen, also Zerstückeln der Großblätter von vielleicht 5000x3000 Pixel in "handliche" (wiederum georeferenzierte) Abschnitte. Hierfür verwende ich wie gesagt Glopus Map Manager, weil der entsprechend mächtig ist und Glopus mein PDA (bzw. PC) Kartenviewer.

Die wirklich alten Karten aus der zeit der ersten trigonometrischen Landesaufnahme sind durch das grobmaschige Aufnahmegitter sowieso alles andere als präzise (dafür aber durch den erst in Ansätzen erfolgten Kunststraßenbau umso wertvoller als Quelle). Ich habe jetzt zusätzlich zu Reymann die Preußischen Generalstabskarten/PGK 1:86.400 (Reduktion der Tranchot-Müfflingschen Karten 1:20.000) meiner Heimatgegend georeferenziert, mit anderem Blattschnitt, und (beim Wiederzusammenfügen/Graderichten) anderen Fehlerquellen. Und siehe da, Reymann hat Orte wie Naurod und Niedernhausen bei Wiesbaden etwa nicht selber so "phantasievoll" eingezeichnet, es ist auch nicht Fehlerquelle meiner Scans, sondern er hat einfach die Lage aus der PGK abgekupfert, wo die Ungenauigkeit (etwa 800-1000m; 100m und darunter ist bei diesen Karten genau) wegen des kleineren Maßstabs natürlich viel stärker ins Gewicht fällt.

Taunide wrote:

Bei schon im Original welligen, evtl. ohne Lineal gezeichneten Kartenrändern braucht man aber ein echtes Grafikmanipulationsprogramm zum "Beulen entfernen". Ohne die scheitert auch jede mathematisch noch so korrekte Rückprojektion von Mercator, Kegel oder wasweissich.

Nein, diese "Beulen" dürfen entfernt, da schon im Original vorhanden.
Ein "Entzerrung" würde hier eine Verfälschung einführen!

Ich hatte das Gefühl, dass Dir nicht ganz klar ist, dass die Karte bereits in einer Projektion vorliegt, hier lcc.
Die will man aber auch nicht "entzerren". Was man ggf. will, ist eine Trafo von lcc nach latlon.

Wir haben hier eine Karte mit Maßstab 1:1 Mio, "100 m" sind hier "gar nichts".

die Preußischen Generalstabskarten/PGK 1:86.400 (Reduktion der Tranchot-Müfflingschen Karten 1:20.000)

gibt es die online auch zum Anschauen?

Danke.

kellerma wrote:

die Preußischen Generalstabskarten/PGK 1:86.400 (Reduktion der Tranchot-Müfflingschen Karten 1:20.000)

gibt es die online auch zum Anschauen?

Hier z.B.:
http://www.lgn.niedersachsen.de/portal/ … _psmand=35
http://www.kammertoens.genealogieonline … index.html

Gruß,
ajoessen

Mir wäre schon viel weitergeholfen wenn gewisse Experten sich etwas klarer ausdrücken könnten anstatt nur Brocken hinzuwerfen.
So sind diese Empfehlungen nicht wertvoller als die, Photoshop zu kaufen oder GIMP zu lernen (was man sowieso hin und wieder muss)

Und ich habe den Eindruck, einige bringen das Entzerren, verzeihung Umprojizieren mit dem Georeferenzieren und Tilen durcheinander.
Was darf man mit den Beulen machen, oder nicht?
Ja, es ist mir klar, dass es sich um eine Projektion handelt. Die Karten sind ja nicht gewölbt.
Es geht darum, die trapez- oder kegelförmige Projektion in ein perfektes Rechteck zu verwandeln, dessen Ränder man abschneiden kann, damit sie, wenn in tiles verwandelt, randlos an das Nachbarblatt passen. Der von Dir eingestellte Grafiklink war ebensowenig ein Rechteck wie das Original wie Geogreif. Dieser Schritt ist unnötig beim Georeferenzieren bloss einer einzigen Karte, wo hinter den Rändern "Ende" ist... Das Georeferenzieren oder Kalibrieren kommt als Zwischenschritt nach der Entzerrung, verzeihung Umprojektion, und vor der Umwandlung in tiles.

Nein, es geht um 1:86.400 bzw. 1:200.000, nicht um 1:1.000.000, und wie schon beschrieben, um mehrere Blätter, ohne Überlappung.

Im Moment fotografiere ich diese Karten ab, weil sie nicht sonderlich scantauglich sind (mit einem Makroobjektiv mit 43° Bildwinkel). Mir ist schon klar dass alleine damit eine Verzerrung gegeben ist, und jede Karten an den (georeferenzierten) Ecken genauer sein müsste als in der Mitte, die ja näher zum Objektiv ist. Das ist bei Reprojobs im Copyshop aber genauso. Immerhin ist es kein Laienobjektiv wo einem die spherischen Fehler bei solchen Reprojobs schon ins Auge springen. Inwieweit diese Ungenauigkeit praktische Relevanz hat, genau wie meine laienhafte "Rechteckigmachung" mit einem unbekannten, möglicherweise nicht exakten Algorythmus, zwecks Randentfernung, muss sich zeigen. Da aber die Karten, wie schon festgestellt wurde, eh "fast" reckeckig sind (Abweichung von unter 1%) schätze ich den Fehler auf max. 300m. Das ist "im Feld" nicht schlimm, addiert sich aber zu den anderen Fehlern hinzu und macht es unmöglich sie zuzuordnen, es sei denn man hat eine Vergleichskarte aus einem anderen Blattschnitt, wo der Fehler möglicherweise identisch ist.

Mea culpa, natürlich 1:200000, hatte noch die ONC vom anderen thread im Kopf 😉

So, hier eine Kurzanleitung:
A)
Wir schauen uns die obere linke Ecke an und bestimmen deren Koordinate:
Recht grob: 50 Grad 45,2 Minuten nördlicher Breite, 25 Grad 12,2 Minuten östlicher Länge.
Ein Blick in osm auf das heute Koblenz: Da kann doch was nicht stimmen? 😉
Damals (so 1850) hat man nicht Greenwich sondern Ferro benutzt und so müssen noch 17 Grad 40 Minuten "abgezogen" werden:
25° 12,2' ö. L. - 17° 40' Ferro-Offset = 7° 32,2' ö. L.

B)
Nun berechnen wir diesen Punkt - ausgehend von longlat - in den Koordinaten des lcc-Systems mit dem CommandLineTool "cs2cs":

$ cs2cs +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs +to +proj=lcc +ellps=bessel +datum=potsdam +lon_0=12d20 +lat_0=0 +lat_1=47d16 +lat_2=54d54 +no_defs
7d32.2 50d45.2
-337409.31 6348684.69 -1.81

Note:
lon_0=12d20 ergibt sich aus 30° - 17°40', da Reymann den 30° (nach Ferro) als Mittelmeridian verwendet haben soll.
lat_1 Lat. des südl. Punkt Deutschland
lat_2 Lat. des nördl. Punkt Deutschland

C)
Mit einem Graphikprogramm wird die Karte ohne Rand ausgeschnippelt. Alsbald erstellen wir ein sog. World-File namens 161.wld mit den eben ermittelten Koordinaten sowie den - nach einigem rumspielen - "Streckungsfaktor" 25:
25
0
0
-25
-337409.31
6348684.69

D)
Dem Ergebnis wird obiges lcc-System verpasst (georeferenzieren 😉 :
$ gdal_translate 161.jpg lcc.tif -a_srs "+proj=lcc +ellps=bessel +datum=potsdam +lon_0=12d20 +lat_0=0 +lat_1=47d16 +lat_2=54d54 +no_defs"

E)
Nun transformieren wir unser Bildchen von lcc nach longlat:
$ gdalwarp lcc.tif longlat.tif -t_srs "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs"

F)
Last but not least wird noch getilet:
$ gdal_translate longlat.tif a.jpg -of JPEG ; java -jar MercatorTiler.jar --image a.jpg --bounds 7.5,50.3,8.5,50.8 --tiledir Coblenz

Wichtig:
Das Endergebnis ist nicht rechteckig (darfs gar nicht sein), da aber die anderen, z. B. "160 Andernach" auch diese Form bekommen, passt das "Puzzle" wieder 🙂

EDIT:
Als Reymann seine Karte 1806 angefangen hat, gab's weder "bessel" noch "potsdam", dies und die wahren lat_1/lat_2 überlass ich den Experten.

Nahmd,

Taunide wrote:

Mir wäre schon viel weitergeholfen wenn gewisse Experten sich etwas klarer ausdrücken könnten anstatt nur Brocken hinzuwerfen. So sind diese Empfehlungen nicht wertvoller als die, Photoshop zu kaufen oder GIMP zu lernen. Und ich habe den Eindruck, einige bringen das Entzerren, verzeihung Umprojizieren mit dem Georeferenzieren und Tilen durcheinander.

"Ich höre euch zwar nicht zu und weiß sowieso alles besser, aber macht mir mein Problem weg"

Taunide wrote:

Und ich habe den Eindruck, einige bringen das Entzerren, verzeihung Umprojizieren mit dem Georeferenzieren und Tilen durcheinander.

Taunide wrote:

Das Georeferenzieren oder Kalibrieren kommt als Zwischenschritt nach der Entzerrung, verzeihung Umprojektion, und vor der Umwandlung in tiles.

Die korrekten Begriffe zu benutzen hilft beim Verstehen des hier notwendigen Ablaufes. Du gehst immer noch davon aus, dass die Karten irgendwie verzogen sind und irgendwie verrechteckt werden müssen.

Dieser Ansatz ist falsch.

Was Du bei der Einzelkarte noch nicht siehst: die Blattschnitte oberhalb der hier vorliegenden Teilkarte decken in der Breite mehr Längengrade ab, und die darunterliegenden Teilkarten weniger.

Desweiteren musst Du, wenn Du auf eine Projektion mit waagrecht verlaufenden Breitenkreisen wechselst, die Karten gegenüber dem Scan verdrehen. Je weiter von dem von kellerma angesprochenen Mittelmeridian entfernt, umso mehr.

Weiterhin: Du sagst, dass die Blätter keinen Überlapp haben. Dann kannst Du die nur im Original zusammenkleben (was ich auch empfehle). Wenn Du Rechtecke kleben willst.

Wenn Du eine einzelne Karte umprojizierst (mit Deinen Worten: entzerrst), so dass die Meridiane aufgerichtet werden, so wird die Karte als ganzes trapezförmig (genauer: ein Trapez mit Kreisbögen (sehr) großer Radien als Seiten). Außerdem werden die Einzelblätter dabei unterschiedlich gedreht. Du kannst natürlich diese Trapeze zusammenkleben. Die passen genau so gut wie die Original-Rechtecke. 🙂

Wenn Du allerdings die Trapeze auf rechteckig beschneiden willst (wohlgemerkt, das ist nach der "Entzerrung", die "Entzerrung besteht gerade darin, die Karte zu manipulieren), gehen Teile jedes Blattes vorloren. Und wenn die Blätter keinen Überlapp haben, ist das endgültig: Du hast Löcher in der Gesamtkarte.

Zusammengefasst: Du willst:

1. senkrechte Meridiane und waagrechte Breitenkreise (die brauchst Du, wenn Du die Karte als Overlay über OSM/Google/Bing/you name it-Slippymaps legen willst.
2. aus den Einzelblättern zusammenklebbare Rechtecke bekommen, und
3. keinen Verschnitt (weil Du keine Löcher in der Zielkarte haben willst)

Das sind ja gleich drei Wünsche auf einmal… doch Du bekommst nur zwei erfüllt. Ätsch! 😉

Doch warum soll es Dir besser ergehen als den Kartographen und Mathematikern der letzten Jahrhunderte?

Meine Empfehlung: klebe die Karten im Original zusammen – wenn nötig bei einem Graphiker mit entsprechend ausgestattetem Rechner. Der kann Dir auch optische Verzeichnungen "wegmachen". Aber er soll die Finger von Meridianen&Co lassen. Auf das Ergebnis wendest Du dann das von kellerma detailliertest beschriebene Verfahren an. Bingo.

Das Gesamtergebnis ist natürlich ein Trapez. Das aber kannst Du beliebig beschneiden – oder auch einfach trapezförmig lassen.

Gruß Wolf

Ich will mich gar nicht groß einmischen oder Verwirrung stiften, aber mit dem Programm "PTLens" kann man die Krümmung des Objektivs (bei einer Fotografie) herausrechnen lassen. Dazu braucht man allerdings die Kamera- und Objektivdaten.
http://epaperpress.com/ptlens/

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

Taunide wrote:

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.

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,

Taunide wrote:

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,

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

Taunide wrote:

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.

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.

Taunide wrote:

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

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

Gruß Wolf

Netzwolf wrote:

Taunide wrote:

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,

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

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

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.

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

quasilotte wrote:

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

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

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

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

www.lostart.de wrote:

Die Reymannsche Spezialkarte ist in einfacher normaler Kegelprojektion entworfen. Die Projektion ist weder winkel- noch flächentreu, sie ist längentreu im Mittelparallel und in den Meridianen. Die Karte ist keine Gradabteilungskarte, die Blätter sind rechteckig im Format 231,8 x 339,7 mm bzw. 46,4 x 67,9 km. Die Blattränder sind daher nicht nach geographisch Nord orientiert.

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 😉

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

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 🙁

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 (TM)

Zum Thema HISTORISCHE KARTEN ein gigantischer Link:

http://www.davidrumsey.com/blog/2011/4/ … iches-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. 🙂

Taunide wrote:

Diese Karten können für Glopus auf einfachste Weise kalibriert werden.

Naja, die Hauptarbeit (Entzerrung) wurde bereits von Cartography Associates geleistet, so dass diese Bilderchen schon "googletauglich" sind 😉

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

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.

Taunide wrote:

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.

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))/(n*n) = 1 Kalibrierungspunkt pro (Teil-)Karte 😉

Taunide wrote:

http://www.davidrumsey.com/blog/2011/4/ … iches-1893

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

quasilotte wrote:

Danke !

MercatorTiler.jar funktionier wunderprächtig!

Somit kann ich im Mobile Atlas Creator die Scan's in das Format bringen welches ich möchte!

bzw.

Ist jetzt ein direktes Überlagern mit einem anderen Layern nur noch ein Kinderspiel!

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

Gruß,
ajoessen

Taunide wrote:

Zum Thema HISTORISCHE KARTEN ein gigantischer Link:

http://www.davidrumsey.com/blog/2011/4/ … iches-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. 🙂

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/~s … yeder.html

Gruß,
ajoessen

Doch, das geht mit GMM problemlos.

Taunide wrote:

Zum Thema HISTORISCHE KARTEN ein gigantischer Link:

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.

Taunide wrote:

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.

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/viewtopi … 46#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 🙁
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 ...

Taunide wrote:

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.

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

kellerma wrote:

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) 🙄