Fragen zu GeoTiff/ Tif mit Worldfile

Na dann wollen wir mal....

Also GeoTiff Karten Animationen gibt es nicht. Aber die von Dir schon erwähnten Übersichtsebenen. Das GDAL Kommando dazu heißt gdaladdo. Eine Dokumentation dazu findet man hier: http://www.gdal.org/gdaladdo.html

Für den DACH Raum gibt es keine wirklich freien Rasterkarten. Entweder man kauft die Karten aus offizieller Quelle und hackt das Format. Oder man bedient sich schamlos bei den zur Verfügung stehenden Kartenservern für TMS, WMS und WTMS Karten.

Zum World File: Deine Beobachtungen sind richtig. Ohne die Projektion zu kennen ist das witzlos. Deswegen wird der Kram auch nicht von QLGT unterstützt. Aber auch hier hilft GDAL. Den genauen Syntax habe ich jetzt nicht im Kopf. Aber ich würde mal gdal_translate mit dem -s_srs Parameter versuchen. Also in etwa so:

gdal_translate -s_srs "+proj=...." -co tiled=yes -co compress=LZW <input> <output>

Wobei input die tif oder twf Datei sein sollte. Beide Dateien müssenden den selben Namen haben. output ist eine Datei mit *tif als Endung. Wenn ich mehrere Dateien habe benütze ich gerne Python zur Automatisierung.

QLGT für Windows bringt seine eigen GDAL Installation mit. Im Startmenü von Windows wird auch eine Ikone angeboten, mit der sich eine Konsole öffnen lässt. In der Konsole sind alle Umgebungsvariablen richtig gesetzt.

Generell halte ich es für eine gute Idee wenn man hier im Forum vielleicht mal einen GDAL Thread pint und pflegt. Ich steure gerne mit Wissen bei. Die Pflege will ich nicht übernehmen. Ich habe mit QLGT schon genügend Dinge zu pflegen.

Zitat von MiLeo

Habe mir schon fast gedacht das ich um dieses Programm nicht drum rum komme. Bisher bin ich damit nicht so richtig klar gekommen. Hoffe, mit der Anleitung kann ich jetzt dann mehr damit anfangen. Kommandozeile ist halt für einen GUI-verwöhnten "Mausschubser" wieder etwas gewöhnungsbedürftig.

Das ist sicherlich richtig. Nur kann ein GUI nie und nimmer die selbe Flexibilität bieten. Und wenn man bei GM mit Automatisierung anfängt, ja das geht, wird es sehr schnell seltsam. Dann doch lieber eine gescheite Skriptsprache und kleine Kommandozeilenprogramme.

Zitat von MiLeo

Bin mir da immer noch nicht sicher was ich bei "+proj=...." eingeben muss. Will GDAL damit die Originalprojektion der (input)Karte wissen oder kann ich dadurch bestimmen welche Projektion meine Output-Karte haben soll?
Muss ich noch was beachten wenn das Worldfile ein Rotation beinhaltet (2. und 3. Zeile ungleich Null) oder erkennt das GDAL selber?

Folgendes als Faustregel aus http://www.gdal.org/gdal_utilities.html:

gdal_translate wandelt Dateien von einem Format in ein anderes.
gdalwarp reprojiziert Karten.

-s_srs ist die Projektion der Quelle (source, s_)
-t_srs ist die Projektion des Ziels (target, t_)

Projektionen inklusive dem geographischen Datum kann man am besten per EPSG Code angeben. Google hilft den richtigen zu finden. Dann schreibt man z.B.:

-s_srs "+init=epsg:4623"

Die echten Männer schreiben:

-s_srs "+proj=longlat +a=6378137.0000 +b=6356752.3142 +towgs84=0,0,0,0,0,0,0,0 +units=m  +no_defs"

Anhand der Projektion kann GDAL die in der tfw Datei abgelegte Transformationsmatrix als lineares Gleichungssystem interpretieren. Also auch mit einer Rotation. Aber Vorsicht! QLGT kann das nicht. Dieses Detail ist mir in den Anfängen entgangen. Und es jetzt noch zu ändern ein ganz schöner Aufwand. Deswegen funktionieren Projektionen wie Lambert nicht. Aber alles was Merkator oder Transversal Merkator ähnlich ist geht.

Zitat von MiLeo

Ausserdem ist mir immer noch nicht ganz klar: Ist ein .tif mit .tfw-Worldfile wirklich ein GeoTiff oder wird das nur manchmal der Einfachheit halber so bezeichnet?

Es wird leider auch als GeoTiff bezeichnet. Der Name "Krankheit" war anderweitig vergeben. Für mich hat ein echtes GeoTiff immer alle Information intern in den Tags.

Zitat von MiLeo

Dann müsste es doch eigentlich auch GeoPNGs oder GeoJPGs geben? Da fällt mir ein das mir auch schon mal ein GeoPDF begegnet ist.

Geht, gibt es, hat technisch keine wirkliche Bedeutung. PNG und TIF sind sich in der Codierung sehr ähnlich. Und GeoTiff kann die Daten auch JPEG codiert speichern. Wie übrigens fast alle anderen Formate auch die Kompression von anderen Formaten beherrschen. Die ursprünglichen Namen sind oft nur noch historischer Schall und Rauch. Ganz besonders deutlich wird dies beim Windows BMP. Von 32Bit Pixel unkomprimiert, über 8 Bit Farbtabelle, bis hin zu Lauflängen, Jpeg oder Wavelet Kompressionen kann da alles drinnen sein. Ein Jpeg mit 100% Qualität entspricht quasi einem PNG.

Zitat von MiLeo

Bin mir da immer noch nicht sicher was ich bei "+proj=...." eingeben muss. Will GDAL damit die Originalprojektion der (input)Karte wissen...

ja, entweder als Datei (Möglichkeiten siehe hier), EPSG-Code oder als vollständigen Parametersatz diskret angegeben. Für die mittlere deutsche Gauß-Krüger-Zone 3 sähe das z.B. so aus:

+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs

Zitat von MiLeo

oder kann ich dadurch bestimmen welche Projektion meine Output-Karte haben soll?

nein. Dazu ist ein zweiter Schritt mit gdalwarp nötig.

Zitat von MiLeo

Muss ich noch was beachten wenn das Worldfile ein Rotation beinhaltet (2. und 3. Zeile ungleich Null)

nein.

Zitat von MiLeo

Ausserdem ist mir immer noch nicht ganz klar: Ist ein .tif mit .tfw-Worldfile wirklich ein GeoTiff

im Sinne der Spezifikation nicht.

Zitat von MiLeo

oder wird das nur manchmal der Einfachheit halber so bezeichnet?

fälschlicherweise ja.

Zitat von MiLeo

Dann müsste es doch eigentlich auch GeoPNGs oder GeoJPGs geben? Da fällt mir ein das mir auch schon mal ein GeoPDF begegnet ist.

Prinzipiell läßt sich für jedes Bildformat, das Platz für Metadaten hat, ein GeoBildformat definieren. Es gab ein paar Anläufe, hat sich bisher aber nicht durchgesetzt. PDF ist ein Containerformat, da kann man so ziemlich alles reinpacken.

Wenn du als langjähriger Mausschubser mit der Kommandozeile nicht zurechtkommen solltest, sieh dir mal QGIS an. Das bietet u.a. ein grafisches Frontend für GDAL inkl. Stapelverarbeitung, die Bedienung ist allerdings alles andere als intuitiv (dafür gibt's aber eine Doku) und setzt einiges an Verständnis für die Materie voraus. Willkommen in der GIS-Welt!

Auf den Seiten von GDAL gibt es einige interessante PDFs. Und für den Anfang sollte man sich die Wikipedia Artikel zu Merkator/Transversal Merkator und zum geographischen Datum lesen und verstehen.

Zitat von MiLeo

So richtig verstanden habe ich es bisher aber nur bruchstückhaft.

Wird auch noch etwas dauern, je nachdem, wie weit du gehen willst. Oliver hat dich auch in eine auf zwei bestimmte Projektionen spezialisierte Richtung losgeschickt, fang mal etwas allgemeiner an:

http://de.wikipedia.org/wiki/Kartennetzentwurf
http://www.boehmwanderkarten.de/kartographie/is_netze.html
http://de.wikipedia.org/wiki/Geod%C3%A4tisches_Datum

Wenn Du ein konkretes Bespiel hast, können wir auch gerne Schritt für Schritt durchgehen.

Zu den Farben:
Es gibt viele Farbmodelle. Ich bin in all den Jahren mit RGB, RGBA und 8 Bit Farbtabellen prima ausgekommen.

RGB(A) bedeutet Rot Grün Blau(Alpha) und entspricht der üblichen bekannten Farbmischung. Der Wert im Alphakanal gibt an, in wie weit ein Pixel deckend ist. 0 ist durchsichtig, die Werte in RGB sind egal. 255 ist komplett deckend. manchmal werden die RGBA Werte auch von 0..1.0, also als 3(4) Kommazahlen angegeben.

Die üblichen Bildbearbeitungsprogramme laden normalerweise das ganze Bild in den Speicher. Bei Karten kommt man hier schnell an die Grenzen. QGis macht das auch, weil es versucht die ganze Karte im Bildschirm anzuzeigen. Also mit einem starken Zoom anfängt, als nur einen Ausschnitt 1:1.

Meine üblichen, grundlegende Vorgehensweise, wenn ich die Datei vom Scannen zurückbekomme ist wie folgt:

1) Öffnen der Datei mit Gimp.
2) Umwandeln in den RGBA Farbraum.
3) Mit dem Lasso Tool den Rand freistellen.
4) Als TIF mit RGBA Farbraum speichern.
5) Mit gdal_translate und "-co tiled=yes -co compress=LZW" die interne Struktur der Daten in Kacheln umwandeln
6) Mit gdaladdo Übersichtsebenen hinzufügen.

Jetzt habe ich eine Rohdatei, mit der ich was anfangen kann, weil sie nicht die Grenzen meines PCs sprengt.

Zu den schwarzen Keilen:
Der Übergang von Merkator nach Transversal Merkator (und anders herum) macht aus einem Rechteck ein Trapez [1], welches leicht gedreht ist. Natürlich muss dieses Trapez wieder als Rechteck gespeichert werden. Deswegen entstehen die Keile.

Dem kann man entgegenwirken, indem man die Projektion der Karte nicht ändert. Oder indem man einen Alphakanal hat. Also alle Pixel die nicht zur Karte gehören transparent setzt. Da bei gescannten Karten immer ein Rand entsteht, weil diese ja nie perfekt gerade sind, bevorzuge ich die Lösung mit dem Alphakanal.

Farbtabellen vs. RGBA:
Eine Karte mit normalisierten Farbraum, also eine wo eine grüne Fläche nur ein Grün hat und nicht Schattierungen von Grün, lässt sich sehr effizient als TIF mit Farbtabelle speichern. Wird solch eine Karte aber skaliert oder gedreht, entstehen Treppenstufen. Warum? Die Farbtabelle hat nur 255 Farben. Es gibt so gut wie keine Zwischenstufen. Um aber z.B. eine waagrechte Linie zu drehen und danach wieder als glatte Linie darzustellen, müssen Pixel mit einer Mischfarbe aus der Linienfarbe und der Umgebungsfarbe verwendet werden. Mit einer Farbtabelle unmöglich. Genauso beim Skalieren (Interpolation). Hier kann man sich nur für die eine oder andere Farbe entscheiden.

Deswegen arbeite ich zuerst mit RGBA. Zum Schluss wenn die Karte fertig ist, lasse ich eine optimierte Farbtabelle berechnen. Wenn man mehrere gescannte Karten zusammensetzen will, muss man die Tabelle über alle Dateien berechnen. Dann kann man die Kartendateien in einem finalen Schritt zu einer Karte vereinen.

Zum Referenzieren:
Man sollte diesen Vorgang mal in Gedanken genau durchspielen und sich überlegen welche Projektionen vorkommen. Nehmen wir z.B. mal die Tabacco Karten. Diese sind in der Merktor Projektion gezeichnet. Haben aber ein UTM Gitter. Das merkt man daran, dass das Gitter leicht verdreht zur Karte liegt. Nimmt man die Gitterpunkte muss man die natürlich richtig interpretieren. Folglich muss man bei Referenzpunkten auch immer die richtige Projektion mit angeben. Und die muss nicht zwangsläufig die der Karte sein.

Wenn man sich darüber im Klaren ist, dann kann man auch den Dialog zum Referenzieren in QLGT verstehen.

[1] Eigentlich nicht, weil die Seiten auch noch gebogen werden. Zum Verstehen reicht Trapez.

Den Url bekomme ich nicht geladen. Der Server scheint nicht zu funktionieren. Aber ich vermute mal das sind die gleichen Daten wie hier:

http://www.ordnancesurvey.co.u…products/os-opendata.html

Ich habe mir von "OS VectorMap™ District (Raster)" das Teilgebiet TL herunter geladen und entpackt. Da entstehen mehrere Verzeichnisse. In einem liegen die ganzen Tif Dateien und im anderen die Referenzinformation. Entweder als tfw oder als tab. Da tab die komplette Information enthält, ist es vorzuziehen. Dazu kopiert man alle *tab Dateien rüber in den Ordner mit den *tif Dateien. Für GDAL reicht das schon. Das kann man auf der Konsole wie folgt testen:

gdalinfo gdalinfo TL99.tif

ergibt:

Driver: GTiff/GeoTIFF
Files: TL99.tif
       TL99.TAB
Size is 4000, 4000
Coordinate System is:
PROJCS['unnamed',
    GEOGCS['unnamed',
        DATUM['OSGB_1936',
            SPHEROID['Airy 1930',6377563.396,299.3249646],
            TOWGS84[375,-111,431,-0,-0,-0,0]],
        PRIMEM['Greenwich',0],
        UNIT['degree',0.0174532925199433]],
    PROJECTION['Transverse_Mercator'],
    PARAMETER['latitude_of_origin',49],
    PARAMETER['central_meridian',-2],
    PARAMETER['scale_factor',0.9996012717],
    PARAMETER['false_easting',400000],
    PARAMETER['false_northing',-100000],
    UNIT['Meter',1]]
Origin = (590000.000000000000000,300000.000000000000000)
Pixel Size = (2.500000000000000,-2.500000000000000)
Metadata:
  TIFFTAG_ARTIST=Ordnance Survey
  TIFFTAG_COPYRIGHT=Ordnance Survey. © Crown copyright and database right 2011.
  TIFFTAG_DATETIME=2011:03:08 02:29:04
  TIFFTAG_IMAGEDESCRIPTION=beta
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  TIFFTAG_SOFTWARE=Adobe Photoshop CS5 Windows
  TIFFTAG_XRESOLUTION=254
  TIFFTAG_YRESOLUTION=254
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  590000.000,  300000.000) (  0d48'12.88"E, 52d33'51.26"N)
Lower Left  (  590000.000,  290000.000) (  0d47'52.31"E, 52d28'27.98"N)
Upper Right (  600000.000,  300000.000) (  0d57' 3.34"E, 52d33'38.36"N)
Lower Right (  600000.000,  290000.000) (  0d56'41.69"E, 52d28'15.12"N)
Center      (  595000.000,  295000.000) (  0d52'27.56"E, 52d31' 3.26"N)
Band 1 Block=4000x65 Type=Byte, ColorInterp=Palette
  Color Table (RGB with 256 entries)
    0: 250,249,247,255
    1: 239,231,215,255
    2: 252,252,253,255
...

Das sieht doch gut aus! Aber Du willst ja unbedingt wissen was man mit den tfw Dateien machen kann. Also alle *tab löschen und die *tfw kopieren. gdalinfo sieht jetzt nicht ganz so toll aus. Also flugs nach dem EPSG Code für Ordonance Survey National Grid gesucht. Ok das ist jetzt einfach Erfahrung

http://en.wikipedia.org/wiki/Ordnance_Survey_National_Grid

Und in gdal_translate einsetzen:

gdal_translate -a_srs "+init=epsg:27700" -co tiled=yes -co compress=LZW TL99.tif TL99_ref.tif

Man beachte es ist -a_srs und nicht -s_srs. Da bin ich weiter oben durcheinander gekommen. Mit gdalinfo die Datein TL99_ref.tif überprüfen. Sieht gut aus. Mit QLGT laden und einen Wegpunkt an eine markante Straßenkreuzung setzen. OSM Karte laden und überprüfen.

Jetzt sind das aber 100 Dateien. Ich würde ja empfehlen Cygwin zu installieren. Das ist eine UNIX Shell für Windows. Dort gibt es das Kommando "find", mit dem man die Sache automatisieren kann:

find ./ -name "*.tif" -exec gdal_translate -a_srs "+init=epsg:27700" -co tiled=yes -co compress=LZW {} {}.tif \;

Und mit

gdalwarp -co tiled=yes -co compress=LZW *.tif.tif TL.tif

wird aus den einzelnen Dateien eine Große gemacht.

Das mag jetzt dem gemeinen Mausschubser ewig kompliziert vorkommen, aber sich in ein GUI reinfuchsen und dort eine Automatisierung hinzubekommen ist vielleicht gewohnter, aber bestimmt nicht einfacher. Es hilft zu wissen wie man Zeilen aus der Konsole kopiert und wieder einfügt. Das geht auch unter Windows. Ich weiß es nur nicht auswendig. In Cygwin kann man auch die Tab Taste verwenden, um Wörter zu vervollständigen oder sich mögliche Befehle anzeigen zu lassen. Wenn man sich mal auf die Konsole eingelassen hat, will man sie nicht mehr missen und empfindet GUIs, die versuchen das Selbe abzubilden, als zu starr und kompliziert.

Zitat von MiLeo

Der Server funktioniert schon. Ich probiere es mal als Code:

Code

http://parlvid.mysociety.org:81/os/

Anscheinend macht mir die Forumssoftware aus dem "Doppelpunkt8" einen "Daumen nach oben"-Smiley.
Scheinen aber schon die gleichen Daten zu sein wie aus deinem Link.

Mein Fehler. Ich vergesse immer dass ich hier im Büro die Firewall sehr konservativ aufgesetzt habe. Port 81 für HTTP geht da gar nicht.

Zitat von MiLeo

Ich beschreibe zuerstmal was ich am Wochenende ausprobiert habe wie ich halbwegs zum Ziel gekommen bin. Mal schauen an welcher Stelle du die Hände über dem Kopf zusammenschlägst:
...
Macht also in einem Rutsch aus den ganzen Tifs lauter GeoTiffs.

Prima. Soweit alles gut

Zitat von MiLeo

Hätte ich an dieser Stelle schon den gdaladdo drüberlaufen lassen sollen?

gdaladdo macht immer nur Sinn, wenn du eine Datei auch wirklich anzeigen willst. Mit jedem neuen Arbeitsschritt wird die Information wieder entfernt. D.h. die Übersichten werden nicht von einer in die andere Datei übernommen.

Es macht aber aus meiner Sicht keinen Sinn gdaladdo auf die ganzen Einzeldateien los zulassen. Ich würde die erst zu einer großen Kachel zusammensetzen und dann die Übersichten drüber lassen. Wie du ja schon bemerkt hast entstehen bei der Anzeige von Kacheln, die pixelgenau an einander passen Rundungsfehler, die sich in einer weißen Pixelreihe äußern.

Die blauen Koordinatenlinien sind ein typische Aliasingproblem bei der Interpolation von Karten mit Farbtabellen. Das wird mit gdaladdo ein wenig besser.

Dass das Zoom mit den Übersichtsebenen besser geht hast Du ja schon selber herausgefunden.

Ja , die Bearbeitungszeit. Ich habe die Karte ja schon mal komplett umgewandelt. Das hat auf einem Prozessor Core zwei Wochen gedauert. Das Endergebnis ist ~16GB groß. Das Problem liegt wohl an gdalwarp. Da gdalwarp die Projektion ändern kann, verarbeitet es die Daten sehr umständlich. Und das ist natürlich nicht sehr effizient.

Aber, inzwischen weiß ich mehr, und es geht besser. Ich habe es gerade ausprobiert. 30 Sekunden für die 100 Kacheln. Ist das besser? Geht wie folgt. Zuerst erstellt man einen "virtual table". Das ist sowas wie eine qmap Datei.

gdalbuildvrt tl.vrt *.tif

Das sucht im aktuelle Pfad nach allen *.tif Dateien und erstellt eine Datei tl.vrt. Und jetzt:

gdal_translate -co tiled=yes -co compress=LZW tl.vrt  tl.tif

Und zum Schluss:

gdaladdo tl.tif 2 4 8 16

Hätte mir auch gleich einfallen können

Rasterkarten sind übrigens immer furchtbar groß. Und ein Land wie England braucht etwas Platz. Immerhin haben die jetzt einen neuen Monarchenspross. Der brauch auch Platz Deswegen muss auch immer eine Kompression angegeben werden. Ohne -co compress=... werden die rohen Daten geschrieben. Das ist dann groß. Wobei es fast egal ist ob man LZW oder DEFLATE nimmt. Das hat mehr historische Gründe, weil LZW patentverseucht war. Früher kam es zudem mit LZW in GDAL öfters zu Abstürzen. Deswegen benutze ich QLGT oft noch DEFLATE.

Ob man nun tfw oder tab Dateien bekommt, hängt wirklich von der Quelle ab. Ich finde beide Formate einen Schmarrn. Aber einem geschenkten Gaul schaut man nicht ins Maul.

Damit GDAL unter Windows auf der Kommandozeile richtig funktioniert, müssen einige Systemvariablen gesetzt sein. Die GDAL Konsole die mit QLGT angeboten wird sollte das richtig machen. Wenn nicht -> melden. Das Gleiche gilt für Cygwin. Und da liegt der Haken. Die 0815 Cygwin Konsole weiß davon nichts. Ich frag mal den Windows Maintainer ob man da was machen kann.

Das mit den 2x gdalinfo ist natürlich ein falscher Fehler. Zittrige Finger vorm ersten Kaffee.

Wenn man auf der Konsole einen GDAL Befehl ohne alles eingibt, kommt eine kurze Anleitung. Mehr Doku findet man im Internet auf den bekannten Seiten. Einfach ein wenig einlesen.

+proj/+init: Man kann die Projektion auf 2 Arten definieren. Entweder als "well known projection" über +init=epsg:.... Oder als Projektions String mit allen Parametern einzeln. Für die "well known" Projektionen ist der EPSG Code bedeutend einfacher.

So ich hoffe, das hat die größten Wirren beseitigt. Das mit der Konsole unter Windows, werde ich mal selber testen. Das sollte alles unabhängig vom Pfad funktionieren.

Edit: Falscher Dateiname beim gdal_translate Befehl

Zitat von MiLeo

Die Syntax von Cygwin ist auch etwas gewöhnungsbedürftig. Das Programm beschwert sich jedenfalls immer über meine "DOS-mäßige" Ausdrucksweise.

Ist halt Bash Style. Du kannst aber auch in der .bashrc oder .profile sogenannte Aliase setzen. Dann wird "dir" nach "ls -l" übersetzt usw.

Zitat von MiLeo

Und noch dazu sind die Dateien viel kleiner. Brauchen blos mehr geschätzt 1/10 auf der Festplatte im Vergleich zu den bisherigen Karten.
Jetzt kann Kate von mir aus auch Zwillinge bekommen.

Naja, schlecht ist ihr ja schon mal für zwei

Die *vrt Dateien habe ich auch erst diesen Sommer entdeckt, als ich einen großen Stapel Tabacco Karten zu einer Gesamtkarte umwandeln wollte. Da das Endprodukt eine gemeinsame Farbtabelle haben sollte, musste ich die nötigen Befehle zugleich auf alle Dateien loslassen. Dass man damit Karten über gdal_translate wesentlich effizienter zusammenfügen kann als mit gdalwarp, ist mir aber erst jetzt gekommen.

Das ist halt das Problem mit GDAL. Lauter kleine Primitiven. So ein System ist zwar sehr flexibel und damit jeder Aufgabe gewachsen. Leider gibt es auch immer mehrere Lösungen, die mehr oder weniger elegant sind.

Ich sehe auch gerade, dass es ein Python Skript gdal_merge.py gibt. Das benütz auch QGis.

python gdal_merge.py -o tl.tif -co tiled=yes -co compress=LZW *.tif

Geht auch recht flott und man spart sich den Zwischenschritt mit der *vrt Datei. Jetzt haben wir schon 3 Wege nach Rom - oder besser nach London.

Normal Tiff Dateien können 4GB groß sein. Es gibt auch die BigTiff Erweiterung, dann geht ewig viel. Wenn das Dateisystem mit macht gdaladdo räumt leider beim Abbruch nicht auf. Deswegen auch die weißen Ebenen.

Ich habe die Englandkarte wie folgt gezähmt. Die original Projektion habe ich beibehalten. Jede Großkachel, also die mit dem Buchstabenpaar, wird zu einer Datei zusammengesetzt. Und diese Dateien über eine qmap Datei zu einer Karte. Zusätzlich habe ich mir die Übersichtskarten gezogen und als weitere Ebenen eingetragen. Damit habe ich in QLGT eine schöne Karte, die sich flüssig zoomen lässt.

Auf meinen Geräten habe ich in der Regel immer nur Ausschnitte von Karten. QLGT schneidet aus mehreren Kartendateien die nötigen Bereiche aus und vereint diese. Erst danach wird auf die nötige Projektion reprojiziert.