Benutzer:Thoroe/Making of Thüringer Wald

Im Jahr 2016 habe ich begonnen, eine Serie von topografischen Karten aller großen deutschen Mittelgebirge für die Wikipedia anzufertigen. Da ich mehrfach gefragt wurde, wie diese Karten entstanden sind, gibt es hier ein Making-Of am Beispiel der Karte des Thüringer Waldes. Meine Arbeitsweise mag nicht für jedermann als Vorbild taugen, aber vielleicht kann der eine oder andere etwas Brauchbares für sich herausziehen.

Wer will gute Karten machen, der muss haben sieben Sachen – mindestens…

Bitte Zeit mitbringen – sowohl für die Kartenerstellung als auch für die Lektüre dieses Making-Of

Glücklicherweise sind wir heutzutage in der Lage, auf zahlreiche frei verfügbare, teils kostenlose Werkzeuge und Ressourcen zur Kartenerstellung zurückzugreifen. Die einzigen kostspieligen und raren Ressourcen sind eigentlich die eigene Zeit, Geduld und Ausdauer. Die muss jeder bitte selbst mitbringen.

Darüber hinaus zum Einsatz kamen ein Texteditor (auf jedem Rechner vorhanden), GMT (kostenlos), SRTM-Daten (kostenlos), OpenStreetMap (kostenlos), Affinity Designer und Affinity Photo (nicht kostenlos, aber günstig, und es funktioniert sicher auch mit Inkscape/GIMP), Liberation Regular und Liberation Narrow (beides kostenlos), Microsoft Excel (OpenOffice/LibreOffice oder ein Taschenrechner tun’s auch), FileOptimizer (kostenlos) sowie ein Browser mit Internetverbindung (das setze ich mal voraus).

Eine Anmerkung zu den Grafikprogrammen: Die Karte des Thüringer Waldes war die erste, bei der ich die Affinity-Produkte eingesetzt habe. Bei den vorangegangenen Karten hatte ich ältere Versionen von Adobe Illustrator und Photoshop genutzt, die aber nur noch mehr schlecht als recht auf meinem aktuellen Windows laufen. Alles in allem ließ sich mit Affinity wesentlich angenehmer arbeiten – wobei ich sicher bin, dass das mit aktuellen Adobe-Versionen genauso gewesen wäre, aber Preise und Geschäftsmodell sind da nicht jedermanns Sache. Da Affinity relativ junge Software ist, ist der Funktionsumfang allerdings noch nicht gänzlich mit dem der Adobe-Produkte zu vergleichen. So gibt es derzeit (Version 1.10.4) beispielsweise noch keine Vektorschraffuren, was für die Kartenerstellung problematisch sein kann. In meinen Mittelgebirgskarten kommen glücklicherweise so gut wie keine Schraffuren zum Einsatz; lediglich bei Grenzen zwischen Staaten habe ich davon Gebrauch gemacht, aber seinerzeit noch mit Illustrator. Beim Thüringer Wald spielte das keine Rolle, weil da dank Wiedervereinigung keine Staatsgrenze verläuft.

Serie A: Gleiches Recht, äh… Relief für alle

Nein, das hat nichts mit Fußball zu tun. Einfache Erklärung: Ich hatte von Beginn an eine Kartenserie geplant, und um die Zusammengehörigkeit der Karten deutlich zu machen, habe ich der Serie einfach den nichtssagenden Titel „Serie A“ verpasst – um Raum zu lassen für eine noch schönere Serie B (Freiwillige vor!).

Alle Karten der Serie sollten eine einheitliche Gestaltung erhalten. Dazu gehörte auch, eine deutschlandweite Höhenskala für die Reliefdarstellung zu definieren, die auf alle Karten angewendet werden konnte (ob diese Entscheidung sinnvoll war, lasse ich mal dahingestellt). Bevor ich mich also an die erste Karte gemacht habe und lange bevor die Thüringer-Wald-Karte an der Reihe war, habe ich testweise jede Menge Gebirgsreliefs berechnen lassen – mit unterschiedlichen Höhenstufen und Farbskalen. Am Ende habe ich mich dann für eine Skala entschieden, von der ich der Meinung war, dass mit ihr alle Reliefs ein gefälliges Aussehen hatten und die Oberflächenformen gut erkennbar waren.

Wo geht’s denn hier zum Wald?

Zunächst galt es, den Arbeitsbereich zu verorten, also einen Ausschnitt der Erdoberfläche (anhand von Längen- und Breitengraden) festzulegen, den ich darstellen wollte. Da steht am Anfang ganz einfach die Frage: Wo endet der Thüringer Wald, wo fängt er an? Und wie viel des umliegenden Gebietes sollte auf meiner Karte noch mit abgebildet werden, welche nahegelegenen Städte/Orte? Eine erste gute Quelle dafür war… Wikipedia: Im Artikel Thüringer Wald wird die Ausdehnung des Gebirges schon mal grob beschrieben, und generell ist es immer eine gute Idee, sich etwas ins Thema einzulesen. Speziell beim Thüringer Wald gibt es Abweichungen bei der Begrifflichkeit. Was landläufig als „Thüringer Wald“ bezeichnet wird, umfasst oft auch das Thüringer Schiefergebirge, das geologisch aber davon abzugrenzen ist. Letzteres geht fast nahtlos in den Frankenwald über, den man aber nicht mehr als Teil des Thüringer Waldes bezeichnen würde. Meine Karte sollte also den Thüringer Wald (im engeren Sinne) und das Thüringer Schiefergebirge umfassen und dabei den Namen „Thüringer Wald“ tragen.

Weitere Quellen sind immer die Geoviewer und sonstigen offiziellen Informationsangebote der Bundesländer sowie die Karten zur Naturräumlichen Gliederung Deutschlands (für weite Teile Deutschlands, leider nicht für den Thüringer Wald). Und ein Blick in den alten Schulatlas schadet auch nie. All diese Referenzen lassen sich nicht nur für die Ermittlung der Ausdehnung eines Gebirges, sondern natürlich später auch für weitere Karteninhalte heranziehen. Sie sind in meinen Dateibeschreibungen nicht als Quellen aufgelistet, weil ich dort nichts Spezifisches entnommen, sondern mir nur anhand dieser Karten einen Überblick über allgemeingültige Gegebenheiten verschafft habe.

Die Abmessungen meines Arbeitsbereichs wähle ich immer etwas großzügiger. Erst im Grafikprogramm wird später der tatsächliche Kartenrand festgelegt. Sollte sich dann irgendwann zeigen, dass die Karte doch noch etwas weiter reichen sollte als ursprünglich vorgesehen, kann man sie leicht erweitern, ohne gleich das Relief neu berechnen zu müssen. Außerdem überlege ich mir bereits bei der Wahl des Ausschnitts, wo die Kartenlegende noch Platz findet, da diese bei meinen Mittelgebirgskarten immer in einer Ecke auf der Karte liegt, aber natürlich nichts Wichtiges verdecken darf.

Für die Ermittlung der begrenzenden Längen- und Breitengrade habe ich auf OpenStreetMap zurückgegriffen. Öffnet man dort die Export-Funktion, lässt sich ein Ausschnitt mit exakten Längen- und Breitengradangaben anzeigen. Tatsächlich exportiert habe ich da nichts (dafür wäre der Ausschnitt auch zu groß gewesen), aber das Rechteck ist eine gute visuelle Hilfe, um passende Werte zu ermitteln.

Für die folgenden Abmessungen habe ich mich entschieden, d. h. mein Arbeitsbereich und damit mein Relief sollte genau diesen Bereich abdecken:

W: 9.75° O
S: 50° N
O: 12° O
N: 51.2° N

Übrigens: Bei einigen meiner Karten habe ich den Arbeitsbereich so gewählt, dass ich gebirgsübergreifende Reliefs generiert habe. So wurden beispielsweise die Eifel- und die Hunsrückkarte auf Basis desselben großen Reliefs erstellt.

Relieferstellung: Das Fundament ist die Grundlage jeder guten Basis

Generic Mapping Tools (GMT)

Die Reliefgenerierung erfolgte mit den frei verfügbaren Generic Mapping Tools in (ist schon etwas her) Version 6.1.1. Dabei handelt es sich um eine Sammlung von Programmen, die per Kommandozeile bedient werden, also nicht eben intuitiv zu benutzen sind. Die für meine Reliefs benötigten Kommandos habe ich im Wesentlichen anhand dieser Hilfeseite und mit Infos aus der offiziellen GMT-Dokumentation zusammengestellt.

Achtung: Die verlinkte Wikipedia-Hilfeseite bezieht sich auf GMT 4 und ist daher nicht wirklich aktuell. Einige der Parameter können bei neueren GMT-Versionen abweichen. Außerdem gibt es bei GMT mittlerweile neben dem „Classic Mode“ wohl einen „Modern Mode“, bei dem sich die Parameter unterscheiden. Damit habe ich mich aber nicht beschäftigt und kann daher auch nichts dazu sagen. Ich habe einfach die Vorgehensweise beibehalten, die von meiner ersten Karte an funktioniert hat. If it ain’t broke, don’t fix it!

Höhendaten

Die Software zur Reliefgenerierung ist das eine, aber ohne Höhendaten des betreffenden Gebiets kommt man natürlich nicht weit. Die von der NASA produzierten SRTM-Daten sind frei verfügbar, können in Kacheln von 1×1° heruntergeladen und dann von GMT verarbeitet werden.

Für alle meine bisherigen Mittelgebirgskarten inkl. der Thüringer-Wald-Karte habe ich die Höhendaten im HGT-Format von einer sehr praktischen Download-Seite des USGS geladen. Diese ist leider seit kurzem nicht mehr verfügbar. Beim USGS ist jetzt eine Registrierung erforderlich, und dann erhält man auch andere Dateiformate als die, mit denen ich bisher gearbeitet habe. Daher erläutere ich zwei unterschiedliche Methoden, wie man an die Daten kommt und diese verarbeiten kann – mit qualitativ leicht unterschiedlichen Endergebnissen.

1. Möglichkeit: SRTM3-Daten im HGT-Format

Auf dieser Seite kann man Pakete mit Höhendaten im HGT-Format herunterladen. Einfach auf der Weltkarte das entsprechende Kästchen anklicken. Für die Karte des Thüringer Waldes wird das Paket M32.zip benötigt. Die Dateinamen der darin enthaltenen .hgt-Dateien beschreiben die Koordinate der linken unteren Ecke der Kachel, d. h. die Datei N50E009.hgt enthält die Daten des Bereichs von 50° bis 51° N in Süd-Nord-Richtung und von 9° bis 10° O in West-Ost-Richtung. Für das Relief des Thüringer Waldes wurden die sechs folgenden Dateien benötigt, mit denen der Bereich von 50° bis 52° N und von 9° bis 12° O abgedeckt wird, der also das zuvor definierte Gebiet komplett enthält:

N50E009.hgt
N50E010.hgt
N50E011.hgt
N51E009.hgt
N51E010.hgt
N51E011.hgt

Das sind die Dateien, mit denen ich beim Erstellen meiner Karte auch gearbeitet habe.

2. Möglichkeit: SRTM1-Daten im geoTIFF-Format

Alternativ kann man sich die Mühe machen, sich auf der Seite des USGS zu registrieren. Leider geht das nur unter Angabe der Personalien (Name, Adresse, Telefonnummer) und mit Beantwortung von Fragen zur Nutzung der Daten. Kosten tut es aber außer Überwindung nichts. Wenn man diesen Weg geht, kann man im EarthExplorer SRTM1-Daten herunterladen, die noch etwas höher aufgelöst sind als die SRTM3-Daten. Bevor ich jetzt beschreibe, wie das Auswählen und Herunterladen genau funktioniert, schaut euch einfach dieses Video hier an.

Die Daten solltet ihr als geoTIFF herunterladen. Die Dateinamen folgen demselben Muster wie bei den .hgt-Dateien, d. h. ihr braucht die folgenden Dateien:

n50_e009_1arc_v3.tif
n50_e010_1arc_v3.tif
n50_e011_1arc_v3.tif
n51_e009_1arc_v3.tif
n51_e010_1arc_v3.tif
n51_e011_1arc_v3.tif

Arbeitet man mit diesen Daten, erhöht sich die Auflösung des Reliefs im Vergleich zu meiner Karte sogar noch einmal etwas.

Farbtabelle(n)

Die oben erwähnte, nach mehreren Testläufen definierte Farbskala, die für alle Karten der Serie gilt, wurde in einer Textdatei mit Dateierweterung .cpt gespeichert (der Dateiname ist frei wählbar, hier: col_dm.cpt). Zum Aufbau der Datei siehe auch die GMT-Hilfeseite.

Im Grunde ist es sehr simpel. Die erste Zeile bedeutet: Bei einer Geländehöhe von 50 m nutze die Farbe 148/191/139 (das ist der RGB-Farbwert), bei 200 m den Farbwert 189/204/150. Alle Werte dazwischen werden interpoliert, d. h ein Punkt mit der Höhe von 100 m erhält einen Farbwert, der zwischen den beiden angegebenen liegt. Die zweite Zeile legt dann die nächste Höhenstufe ab 200 m aufwärts fest. Auf diese Weise ergibt sich ein kontinuierlicher Farbverlauf von 50 m bis 1400 m – sofern man keine Lücken lässt und der zweite Farbwert einer Zeile immer dem ersten der Folgezeile entspricht. Alles, was unter 50 m liegt, erhält den Farbwert, der für B definiert ist (bei mir der dunkelste Grün-Ton), alles über 1400 m den F-Wert (entspricht dem 1400-m-Wert). Den für N definierten Farbwert erhalten alle Fehlerpunkte. Das sollte in unserem Fall aber nicht auftreten, weil wir die vorher rausrechnen werden.

Würde man in einer Zeile für die Start- und Endhöhe jeweils denselben Farbwert definieren, erhielte man kein Farbkontinuum, sondern treppenartige Höhenstufen wie z B bei dieser Karte (wobei das dort auf andere Weise hergestellte Vektoren sind, aber nur mal so zum grundsätzlichen Vergleich).

# col_dm.cpt
50   148 191 139   200  189 204 150
200  189 204 150   350  231 223 177
350  231 223 177   500  211 202 157
500  211 202 157   650  202 185 130
650  202 185 130   800  195 167 107
800  195 167 107   950  179 147 87
950  179 147 87    1100 158 129 77
1100 158 129 77    1250 138 112 66
1250 138 112 66    1400 122 99  58
B    126 173 128
F    122 99  58
N    255 255 255

Zusätzlich habe ich noch eine Weiß-Tabelle verwendet. Wozu, erläutere ich weiter unten. Der tatsächliche Nutzen geht gegen null, auch dazu mehr weiter unten. Also nicht nachmachen.

# col_sw.cpt
0 255 255 255   100 255 255 255
B 255 255 255
F 255 255 255
N 255 255 255

GMT-Code

Wie gesagt, hat GMT keine Benutzeroberfläche, sondern funktioniert über Kommandozeilenbefehle. Man könnte jeden Befehl einzeln in die Konsole tippen und ausführen, aber das wäre sehr umständlich. Einfacher ist es, alle Befehle in eine Batch-Datei zu schreiben und diese am Ende auszuführen. Unter Windows ist das eine einfache Textdatei mit Dateierweiterung .bat (auf anderen Betriebssystemen sollte es Vergleichbares geben).

1. Umwandeln

Der erste Schritt ist die Umwandlung der heruntergeladenen .hgt bzw. .tif-Dateien in .grd-Dateien, die GMT dann weiterverarbeiten kann. Im ersten Fall sind dabei jeweils die Grenzen der Datenkacheln (in der Reihenfolge W/O/S/N) anzugeben.

xyz2grd N50E009.hgt -R09/10/50/51 -I3c -N-32768 -ZTLhw -GN50E009.grd
xyz2grd N50E010.hgt -R10/11/50/51 -I3c -N-32768 -ZTLhw -GN50E010.grd
xyz2grd N50E011.hgt -R11/12/50/51 -I3c -N-32768 -ZTLhw -GN50E011.grd
xyz2grd N51E009.hgt -R09/10/51/52 -I3c -N-32768 -ZTLhw -GN51E009.grd
xyz2grd N51E010.hgt -R10/11/51/52 -I3c -N-32768 -ZTLhw -GN51E010.grd
xyz2grd N51E011.hgt -R11/12/51/52 -I3c -N-32768 -ZTLhw -GN51E011.grd

bzw.

gdal_translate -of GMT n50_e009_1arc_v3.tif N50E009.grd
gdal_translate -of GMT n50_e010_1arc_v3.tif N50E010.grd
gdal_translate -of GMT n50_e011_1arc_v3.tif N50E011.grd
gdal_translate -of GMT n51_e009_1arc_v3.tif N51E009.grd
gdal_translate -of GMT n51_e010_1arc_v3.tif N51E010.grd
gdal_translate -of GMT n51_e011_1arc_v3.tif N51E011.grd

2. Zusammenkleben

Die einzelnen Kacheln müssen dann zu einer großen „Fläche“ zusammengefügt werden. Es lassen sich immer zwei Dateien „zusammenkleben“, so dass im Fall der Thüringer-Wald-Karte fünf Klebevorgänge nötig waren. Die Namen der generierten Dateien können übrigens immer frei gewählt werden.

grdpaste N50E009.grd N50E010.grd -GN50E009_010.grd
grdpaste N50E009_010.grd N50E011.grd -GN50E009_011.grd
grdpaste N51E009.grd N51E010.grd -GN51E009_010.grd
grdpaste N51E009_010.grd N51E011.grd -GN51E009_011.grd
grdpaste N50E009_011.grd N51E009_011.grd -GN50_51E009_011.grd

3. Fehler ausbessern

Die originalen Höhendaten können Fehler enthalten, die im fertigen Relief als Pixelfehler erscheinen. Um das zu verhindern, werden eventuelle Lücken durch Interpolation geschlossen. Dieser Berechnungsschritt dauert immer ein wenig länger, aber da direkt die endgültigen Grenzen (in der Reihenfolge W/S/O/N) angegeben werden können, spart man sich zumindest die Berechnung von Bereichen, die später ohnehin nicht benötigt werden.

grd2xyz N50_51E009_011.grd >N50_51E009_011.txt
surface N50_51E009_011.txt -R9.75/50/12/51.2r -I1s -T0.35 -GN50_51E009_011n.grd

4. Schattenwurf berechnen

Aus der in Schritt 3 erstellten .grd-Datei kann dann der Schattenwurf berechnet werden, der über die Höhenstufen gelegt wird. Das macht das Relief erst plastisch. Der Parameter -A315 bestimmt den Winkel des Lichteinfalls (hier: von links oben), der Wert -Ne0.15 die Stärke des Schattens.

Der Wert 0.15 ist relativ gering; normalerweise würde ich einen etwa doppelt so hohen Wert empfehlen. Allerdings hatte ich bei meinen anfänglichen Relief-Tests den Eindruck gewonnen, dass das Endergebnis noch etwas besser aussieht, wenn man zwei Reliefdateien rechnen lässt und diese anschließend in einem Bildbearbeitungsprogramm kombiniert. Mehr dazu im nächsten Schritt.

grdgradient N50_51E009_011n.grd -A315 -Ne0.15 -GN50_51E009_011_shdw.grd

5. Relief erstellen

Aus den beiden Dateien aus Schritt 3 und 4 kann im letzten Schritt das fertige Relief mit Höhenstufen und Schattenwurf errechnet werden. Eigentlich braucht es dafür nur einen Befehl, aber wie eben angedeutet, hatte ich noch eine (sehr minimale) Optimierung vorgenommen und mit zwei Dateien gearbeitet:

Der erste Befehl erstellt eine Reliefdatei mit den farbigen Höhenstufen und leichtem Schattenwurf.
Der zweite Befehl erstellt eine weiße Datei (mit der weißen Farbtabelle von oben), in der nur der leichte Schattenwurf enthalten ist.

Im Zuge der Abfassung dieses Making-Of habe ich noch einmal ein paar Vergleichs-Renderings gemacht und muss sagen, dass die Unterschiede zu einer direkten Berechnung mit stärkerem Schatten quasi gegen null gehen, so dass sich der zusätzliche Aufwand vermutlich nicht lohnt. Aber natürlich habe ich diese Vorgehensweise für alle Karten der Serie beibehalten, nachdem ich einmal damit angefangen hatte. Wer selbst ein ähnliches Relief rechnen möchte, dem empfehle ich in Schritt 4 die Schattenstärke auf -Ne0.3 zu setzen und den zweiten grdimage-Befehl (s. u.) wegzulassen. Die Datei dm_thuer_comp.ps ist dann das fertige Ergebnis. Auf die weiße Farbtabelle kann in diesem Fall natürlich auch verzichtet werden.

Der Parameter -JM10.875/50.6/18c bestimmt die Kartenprojektion. Ich habe die Mercator-Projektion (M) gewählt, um später die OpenStreetMap-Karte deckungsgleich unter das Relief legen zu können. Die Werte 10.875 und 50.6 sind der Mittelmeridian und der zentrale Breitengrad der Projektion. Diese Werte setze ich immer auf die Mitte meines Gebietes.

Hinweis: OpenStreetMap nutzt nicht die klassische Mercator-Projektion, sondern eine vereinfachte Variante für Webanwendungen (en), aber die Abweichungen waren bei meinen Karten vernachlässigbar.

grdimage N50_51E009_011n.grd -IN50_51E009_011_shdw.grd -Ccol_dm.cpt -JM10.875/50.6/18c -R9.75/50/12/51.2r -P >dm_thuer_comp.ps
grdimage N50_51E009_011n.grd -IN50_51E009_011_shdw.grd -Ccol_sw.cpt -JM10.875/50.6/18c -R9.75/50/12/51.2r -P >dm_thuer_shdw.ps

Vollständige Datei dm_thueringer-wald.bat (bei Nutzung von .hgt-Dateien)

REM # GMT 6
REM # dm_thueringer-wald.bat
REM # ---------------------------------------------------------------------
REM # Deutsche Mittelgebirge
REM # Thüringer Wald
REM # ---------------------------------------------------------------------
REM # Höhendaten: HGT

REM # Umwandeln
xyz2grd N50E009.hgt -R09/10/50/51 -I3c -N-32768 -ZTLhw -GN50E009.grd
xyz2grd N50E010.hgt -R10/11/50/51 -I3c -N-32768 -ZTLhw -GN50E010.grd
xyz2grd N50E011.hgt -R11/12/50/51 -I3c -N-32768 -ZTLhw -GN50E011.grd
xyz2grd N51E009.hgt -R09/10/51/52 -I3c -N-32768 -ZTLhw -GN51E009.grd
xyz2grd N51E010.hgt -R10/11/51/52 -I3c -N-32768 -ZTLhw -GN51E010.grd
xyz2grd N51E011.hgt -R11/12/51/52 -I3c -N-32768 -ZTLhw -GN51E011.grd

REM # Zusammenkleben
grdpaste N50E009.grd N50E010.grd -GN50E009_010.grd
grdpaste N50E009_010.grd N50E011.grd -GN50E009_011.grd
grdpaste N51E009.grd N51E010.grd -GN51E009_010.grd
grdpaste N51E009_010.grd N51E011.grd -GN51E009_011.grd
grdpaste N50E009_011.grd N51E009_011.grd -GN50_51E009_011.grd

REM # Fehler ausbessern
grd2xyz N50_51E009_011.grd >N50_51E009_011.txt
surface N50_51E009_011.txt -R9.75/50/12/51.2r -I1s -T0.35 -GN50_51E009_011n.grd

REM # Schattenwurf berechnen
grdgradient N50_51E009_011n.grd -A315 -Ne0.15 -GN50_51E009_011_shdw.grd

REM # Relief erstellen (einmal Höhenstufen mit Schatten und einmal nur Schatten in Schwarz-Weiß)
grdimage N50_51E009_011n.grd -IN50_51E009_011_shdw.grd -Ccol_dm.cpt -JM10.875/50.6/18c -R9.75/50/12/51.2r -P >dm_thuer_comp.ps
grdimage N50_51E009_011n.grd -IN50_51E009_011_shdw.grd -Ccol_sw.cpt -JM10.875/50.6/18c -R9.75/50/12/51.2r -P >dm_thuer_shdw.ps

Vollständige Datei dm_thueringer-wald.bat (bei Nutzung von .tif-Dateien)

REM # GMT 6
REM # dm_thueringer-wald.bat
REM # ---------------------------------------------------------------------
REM # Deutsche Mittelgebirge
REM # Thüringer Wald
REM # ---------------------------------------------------------------------
REM # Höhendaten: geoTIFF

REM # Umwandeln
gdal_translate -of GMT n50_e009_1arc_v3.tif N50E009.grd
gdal_translate -of GMT n50_e010_1arc_v3.tif N50E010.grd
gdal_translate -of GMT n50_e011_1arc_v3.tif N50E011.grd
gdal_translate -of GMT n51_e009_1arc_v3.tif N51E009.grd
gdal_translate -of GMT n51_e010_1arc_v3.tif N51E010.grd
gdal_translate -of GMT n51_e011_1arc_v3.tif N51E011.grd

REM # Zusammenkleben
grdpaste N50E009.grd N50E010.grd -GN50E009_010.grd
grdpaste N50E009_010.grd N50E011.grd -GN50E009_011.grd
grdpaste N51E009.grd N51E010.grd -GN51E009_010.grd
grdpaste N51E009_010.grd N51E011.grd -GN51E009_011.grd
grdpaste N50E009_011.grd N51E009_011.grd -GN50_51E009_011.grd

REM # Fehler ausbessern
grd2xyz N50_51E009_011.grd >N50_51E009_011.txt
surface N50_51E009_011.txt -R9.75/50/12/51.2r -I1s -T0.35 -GN50_51E009_011n.grd

REM # Schattenwurf berechnen
grdgradient N50_51E009_011n.grd -A315 -Ne0.15 -GN50_51E009_011_shdw.grd

REM # Relief erstellen (einmal Höhenstufen mit Schatten und einmal nur Schatten in Schwarz-Weiß)
grdimage N50_51E009_011n.grd -IN50_51E009_011_shdw.grd -Ccol_dm.cpt -JM10.875/50.6/18c -R9.75/50/12/51.2r -P >dm_thuer_comp.ps
grdimage N50_51E009_011n.grd -IN50_51E009_011_shdw.grd -Ccol_sw.cpt -JM10.875/50.6/18c -R9.75/50/12/51.2r -P >dm_thuer_shdw.ps

Reliefdatei(en) berechnen und weiterverarbeiten

Alle Dateien, also die sechs Höhendaten-Dateien, col_dm.cpt, col_sw.cpt und dm_thueringer-wald.bat, wurden in das bin-Verzeichnis der GMT-Installation verschoben, und dann konnte dm_thueringer-wald.bat ausgeführt werden (Doppelklick). Nach Ende der Berechnungen befanden sich im selben Ordner zwei neue .ps-Dateien (PostScript).

Die PostScript-Dateien, die GMT auswirft, haben (wenn man an den Einstellungen nichts ändert) DIN-A4-Format, und die enthaltenen Reliefgrafiken belegen nur einen Teil davon. Vermutlich könnte man sie einfach ins Vektorprogramm ziehen, in dem man die Karte anfertigt, aber ich habe es gerne ordentlich strukturiert und wollte die Reliefgrafiken als separate Bitmap-Dateien vorliegen haben, auch um den überschüssigen Weißraum loszuwerden. Außerdem weiß ich bei einer Bitmap-Grafik am Ende, wie viele Pixel ich tatsächlich zur Verfügung habe.

Darum habe ich die PostScript-Dateien in Affinity Photo geöffnet (inwieweit andere Bildbearbeiter in der Lage sind, PostScript-Dateien zu öffnen/rendern, vermag ich nicht zu sagen, aber zumindest mit dem alten Photoshop ging es auch irgendwie), die Reliefgrafiken darin auf 100% ihrer originalen Breite skaliert, die zweite Schattendatei mit der Füllmethode „Linear nachbelichten“ über das Höhenstufenrelief gelegt und das Ergebnis in das TIFF-Format exportiert. Wenn man – wie oben empfohlen – auf den Umweg mit der zweiten Schattendatei verzichtet, hat man ja nur die eine PostScript-Datei; hier muss dann vor dem Export nichts mehr übereinandergelegt werden.

Anmerkung (sieht aus wie ein Werbeblock, aber ich bekomme kein Geld dafür): Was ich in Affinity Photo gemacht habe, hätte man auch in Affinity Designer machen können. Die Programme sind in vielerlei Hinsicht zu denselben Dingen fähig, nicht zuletzt, weil sie sich das Dateiformat teilen. Jede Designer-Datei kann in Photo geöffnet, bearbeitet und gespeichert werden (und umgekehrt). Es geht nichts kaputt oder verloren. Praktisch.

Maßstab und Gradnetz: Ein GMT-Nachklapp

GMT ist mehr als nur ein Programm zur Relieferstellung. Man kann damit komplette Karten (siehe nebenstehendes Beispiel) anfertigen. Um auf diesem Weg etwas Brauchbares zustande zu bringen, das auch grafisch überzeugen kann, ist aber sicher viel Hirnschmalz nötig. Ich habe es nie versucht. Stattdessen nutze ich – wie vermutlich die meisten Kartografen – ein Grafikprogramm, um damit all die Signaturen, Schriften und sonstigen Kartenbestandteile auf das Relief zu legen.

Allerdings gab es zwei Dinge, für die ich die Hilfe von GMT noch einmal in Anspruch genommen habe, nämlich das Gradnetz und den Maßstabsbalken. Beides kann mit GMT generiert werden, und wenn man dabei dieselben Kartengrenzen und dieselben Projektionsparameter angibt wie bei der Relieferstellung, dann passt das auch perfekt zusammen. Ich habe dazu den GMT-Befehl pscoast verwendet, der in erster Linie dazu dient, Küstenlinien, Grenzen, Flüsse und ähnliche Linien zu zeichnen, aber eben auch die genannten Kartenelemente. Das genaue Aussehen war dabei nebensächlich, weil mir das Ergebnis später nur als Vorlage für meine eigenen Grafiken diente.

Die Parameter -N, -I und -D steuern die Anzeige von Grenzen und Flüssen. Für meine Zwecke uninteressant, aber wenn man das alles weglässt, funktioniert der Befehl nicht mehr. Also hinnehmen und ignorieren.
-Lx13.3c/1.7c/50.6/20 definiert den Maßstabsbalken: Die ersten beiden Werte stehen für die Positionierung auf der Karte – „irgendwo“ hat mir hier ausgereicht, die krummen Werte sind ein altes Copy-and-Paste-Überbleibsel. 50.6 ist der Breitengrad, an dem sich die Längenangabe des Maßstabsbalkens orientiert. Die Mercator-Projektion ist ja nicht längentreu, d. h. am Nordrand der Karte ist ein Kilometer „länger“ als am Südrand (auf der Südhalbkugel umgekehrt); ich setze hier immer die Mitte meines Reliefs als Referenzbreite, auch wenn das am Ende nicht die Mitte meiner Karte ist, aber wer ist schon perfekt. Die 20 steht für 20 Kilometer, die der Balken lang sein soll.
-Ba0.5g0.5 bestimmt die Darstellung von Kartenrahmen und Gradnetz. In meinem Fall wird jedes halbe Grad eine Linie gezogen.

pscoast -JM10.875/50.6/18c -R9.75/50/12/51.2r -Na -Ia/0.25p,39/170/234 -Dh -Lx13.3c/1.7c/50.6/20 -Ba0.5g0.5 -P -K >dm_thuer_lines.ps

Natürlich kann man diese eine Zeile GMT-Code oben noch mit in die Datei dm_thueringer-wald.bat schreiben und die Darstellung in einem Rutsch mitberechnen lassen. Aus didaktischen Gründen habe ich das hier in einem eigenen Absatz abgehandelt, weil es ja nicht direkt etwas mit dem Relief zu tun hat.

Zur Erstellung einer guten Karte nehme man… eine andere gute Karte

Wie bereits angedeutet, habe ich OpenStreetMap (OSM) als Grundlage für all die geografischen Objekte (Orte, Flüsse, Straßen etc.), die auf der Karte erscheinen sollten, verwendet und das Relief bereits in der passenden Projektion erstellt. Man hätte nun versuchen können, die OSM-Daten über einen SVG- oder PDF-Export tatsächlich als Vektoren zu extrahieren, aber ich hatte mich von Anfang an entschieden, alle Elemente selbst neu zu zeichnen und die gerenderte OSM-Karte lediglich als Vorlage zu verwenden. Das hatte mehrere Gründe, u. a.:

OSM-Exporte enthalten in der Regel eine Vielzahl von Objekten, die ich in meinen Karten nicht brauche; man müsste also erstmal die Objekte herausfiltern, die von Interesse sind bzw. den „Schrott“ aus der Vektordatei löschen.
OSM-Linien kennen keine Kurven, sondern bestehen ausschließlich aus geraden Teilstücken, die noch dazu nicht alle zusammenhängen, sondern immer wieder unterbrochen sind: beides kann der Qualität der Darstellung abträglich sein.
OSM-Daten liegen maßstabsunabhängig vor, d. h. ein stark mäandrierender Fluss könnte in meinem Kartenmaßstab mit der entsprechenden Strichstärke zu einem Pixelmatsch werden, der dann doch wieder manuelle Generalisierung erforderlich macht.

Alles Gründe, die mich dazu bewogen haben, nicht direkt mit OSM-Objekten zu arbeiten.

Suche nach einem geeigneten OSM-Export

Ich brauchte also einen Ausschnitt aus der OSM-Karte, der exakt denselben Bereich abdeckte wie das zuvor erstellte Relief. Bei Ermittlung der Kartengrenzen hatte ich bereits die Export-Funktion von OSM genutzt, aber eben nicht tatsächlich zum Export (s. o.), denn für das vergleichsweise große Gebiet ist nur ein Export in niedriger Zoomstufe mit entsprechend wenigen Details möglich.

Die OSM-Karte (und damit meine ich die Standard-Karte auf osm.org) besteht eigentlich aus 19 unterschiedlichen Karten, nämlich einer pro verfügbarer Zoomstufe. Und jede dieser 19 Karten besteht wiederum aus einzelnen PNG-Kacheln. Ich hätte also theoretisch die entsprechenden Kacheln in einer geeigneten Zoomstufe herunterladen und in einem Grafikprogramm zu einer großen Karte zusammenfügen können. Zu dieser Sisyphusarbeit hatte ich aber wenig Lust und habe stattdessen nach einem geeigneten Tool gesucht, das diese Aufgabe (zumindest in Teilen) für mich erledigt – und es mit der BigMap auch gefunden. Hier kann eine große, zusammenhängende OSM-Karte eines definierten Gebiets in einer frei wählbaren Zoomstufe erstellt werden. Also genau das, was ich brauchte.

Zum Zwecke der Einheitlichkeit meiner Mittelgebirgskarten habe ich auch die jeweiligen OSM-Vorlagen alle in derselben Zoomstufe erstellen lassen, nämlich in Stufe 11. Die Kartengrenzen der BigMap orientieren sich an den OSM-Kacheln, d. h. ich konnte nicht direkt die benötigten Grenzen eingeben, sondern habe die kleinstmögliche Karte erstellt, die mein Gebiet abdeckte. Das lässt sich ganz gut über die „Expand“-, „Shrink“- und „Zoom“-Befehle der BigMap bewerkstelligen.

Zusammenfügen der OSM-Kacheln zu einer Karte

Wer den vorstehenden Link angeklickt hat, wird sehen, dass auch BigMap nicht direkt eine große Kartendatei erstellt, sondern zunächst einmal nur die entsprechenden Kacheln anzeigt, in diesem Falle 168 an der Zahl. Es wird ein Perl-Skript zum Download bereitgestellt (in der untersten Zeile der Datenbox), mit dem man aus den Kacheln selbst eine Gesamtdatei erstellen kann, wenn man einen Webserver zur Hand hat. Bei meinen ersten Karten habe ich das tatsächlich auch so gemacht, aber spätestens mit Anschaffung eines neuen PCs und Umstellung auf Windows 10 funktionierte das bei mir dann nicht mehr – was wohl eher an meinen limitierten Perl-Kenntnissen lag als an dem Skript an sich.

Aber warum kompliziert, wenn es auch einfach geht: lassen wir den Browser einfach einen Screenshot der kompletten Seite machen. Dazu sollte man zunächst die BigMap-Datenbox ausblenden (praktischerweise gibt es dazu einen Link „hide this“ unten rechts in der Box). Und dann:

Firefox: Über F12 die Entwicklerwerkzeuge einblenden und in deren Fenster oben rechts auf den Fotoapparat klicken (Bildschirmfoto der gesamten Seite aufnehmen). Die PNG-Datei landet dann im Download-Ordner. Es gibt in Firefox auch irgendwo den Befehl „Bildschirmfoto aufnehmen“, aber da wird nur eine unschön komprimierte JPG-Version gespeichert.
Chrome: Über F12 die Entwicklerwerkzeuge einblenden und dort rechts auf die drei Punkte klicken und „Befehl ausführen“ (Run command) auswählen. In der Liste nach „Screenshot in voller Größe aufnehmen“ (Capture full size screenshot) suchen und anklicken. Das Ergebnis landet als PNG-Datei im Download-Ordner.

Zurechtschneiden der OSM-Karte

In der Regel weist die erstellte Screenshot-Datei einen dünnen weißen Rand auf, den man penibelst abschneiden sollte, damit man eine Datei erhält, die exakt den Dimensionen entspricht, die in der BigMap-Datenbox angegeben sind, in unserem Fall 3584×3072 Pixel. Für Fortgeschrittene: man kann den weißen Rand vermeiden, wenn man vor Aufnehmen des Screenshots über die Entwicklerwerkzeuge dem <body> der Seite die Eigenschaft margin:0 zuweist.

Letzter Schritt der OSM-Vorlagenerstellung war das Zuschneiden der großen OSM-Karte auf die Grenzen des Reliefs, damit man beides ohne großes Herumprobieren direkt übereinander legen konnte. Da mir BigMap die Grenzen meiner OSM-Karte exakt angegeben hat (9.667969, 49.951220, 12.128906, 51.289406), konnte ich berechnen, wie viele Pixel ich auf jeder Seite entfernen musste, um auf den Ausschnitt des Reliefs (9.75, 50, 12, 51.2) zu kommen. Ich hatte mir dazu eine wiederverwendbare Excel-Datei erstellt, da ich dieselben Berechnungen ja für alle meine Karten brauchen würde. Beim Thüringer Wald waren oben 205, links 119, rechts 188 und unten 112 Pixel zu entfernen, so dass die OSM-Karte am Ende eine Größe von 3277×2755 Pixeln hatte. Ihr könnt das ja mal nachrechnen…

P.S. Wenn jemand einen einfacheren Weg kennt, einen zum Relief passenden OSM-Ausschnitt zu erstellen, freue ich mich, dazuzulernen.

Es wird Zeit, dass wir mal anfangen, unsere Karte zu erstellen

Ich fasse zusammen: Zu diesem Zeitpunkt lagen mir drei Dateien vor, nämlich eine Reliefgrafik, die den Hintergrund meiner Karte abgeben würde (5155×4321 Pixel), ein Ausschnitt der OpenStreetMap-Karte (3277×2755 Pixel) als Vorlage für meine Kartenzeichnung und eine PostScript-Datei mit einem Kartenrahmen und ein paar Linien. Da alle drei Dateien exakt dasselbe Gebiet abdeckten, waren ihre Seitenverhältnisse identisch und ließen sich also (entsprechend skaliert) deckungsgleich übereinander legen. Zumindest theoretisch. Tatsächlich sind meine OSM-Ausschnitte immer ein paar Pixel zu hoch – eventuell liegt das an den leicht voneinander abweichenden Mercator-Projektionen. Aber was nicht passt, wird passend gemacht (s. u.).

Wenn ich im Folgenden meine Arbeit an der eigentlichen Karte beschreibe, beziehe ich mich immer auf Affinity Designer, ohne dass ich jedes Mal darauf hinweisen werde. Wer mit Illustrator, Inkscape, CorelDraw o. ä. arbeitet, wird die einzelnen Schritte leicht auf seine Software übertragen können.

Vektordatei einrichten

Alle Karten meiner Serie haben denselben Maßstab, den ich seinerzeit bei meiner ersten Karte festgelegt hatte, nämlich 20 Pixel/km. Wie es zu dieser Festlegung kam, weiß ich nicht mehr, aber ich denke, sie hat sich für das Thema „Deutsche Mittelgebirge“ als brauchbar erwiesen.

Ich habe also eine neue Vektordatei im RGB-Farbmodus und in einer beliebigen Größe (größer als das Endprodukt) angelegt und die Liniendatei dm_thuer_lines.ps reingezogen. Die wurde dann unter Beibehaltung des Seitenverhältnisses so skaliert, dass der 20-km-Maßstabsbalken, der sich darin befand, eine Länge von 400 Pixeln hatte. Entweder rechnet man per Dreisatz aus, wie groß der Kartenrahmen werden muss, oder man zieht so lange an der Datei herum, bis es passt. Anschließend konnte ich die Reliefdatei einfügen und in den inneren Rand des Kartenrahmens einpassen, ebenso die OSM-Karte, die – das hatte ich ja schon angedeutet – nicht ganz passte, aber einfach ein bisschen verzerrt wurde. Die Abweichungen über die gesamte Karte waren vernachlässigbar, zumal es sich ja nur um eine Zeichenvorlage handelte. Abschließend habe ich die Größe des Affinity-Dokuments an die Maße des Reliefs angepasst, und der Aufbau sah dann aus wie im nebenstehenden Screenshot. Die beiden großen Bitmap-Dateien habe ich übrigens nicht in die Vektordatei eingebettet, sondern lediglich mit dieser verknüpft, um die Dateigröße klein zu halten (Ansicht > Ressourcen verwalten).

Ebenenstruktur

Natürlich habe ich im Grafikprogramm mit Ebenen gearbeitet. Der Screenshot im nächsten Abschnitt zeigt die Struktur, die ich angelegt habe. Ganz unten liegen die beiden Bitmap-Grafiken, von denen die unterste nur eine Hilfsebene beim Zeichnen war, das Relief wurde dann bei Bedarf ein- und ausgeblendet. Die Ebene [[GMT]] war ebenfalls nur eine Hilfsebene, anhand derer ich das Gradnetz nachgezeichnet habe. Die wurde ausgeblendet und dann nicht mehr gebraucht. Die weiteren Ebenen sind selbsterklärend beschriftet. Ihre Reihenfolge ergab sich teils automatisch aus den Inhalten: so führen Gewässer (in aller Regel) nicht über Autobahnen, die flächige Darstellung einer Stadt muss unter den Liniensignaturen liegen etc. Man hätte mehr Ebenen einrichten können (so liegen bei mir alle Ortssignaturen, Orts- und Geländenamen mit Ausnahme von Gebirgen, Bergen und Gewässern in derselben Ebene) oder auch weniger (so könnten mehr Schriften in einer Ebene zusammengefasst werden). Ich bin mit meiner Struktur gut klar gekommen, aber das soll jeder so machen, wie es für ihn/sie am besten passt.

Kartenrahmen und Legende

Nachdem ich mich bisher schon ausgiebig mit diversen Auschnitten und Zuschnitten beschäftigt hatte, war jetzt der Moment gekommen, den endgültigen Rahmen meiner Karte festzulegen. Wie dem nebenstehenden Screenshot zu entnehmen ist, belegt die Karte flächenmäßig noch nicht einmal die Hälfte des Reliefs; es ist also eine Menge Spielraum für spätere Erweiterungen vorhanden. Es wäre auch nicht das erste Mal, dass ich während der Arbeit an der Karte den Ausschnitt noch mal erweitern müsste. Oder später, wenn die Rückmeldungen in der Kartenwerkstatt eingehen.

Wie dem einen oder anderen vielleicht schon aufgefallen ist, wähle ich für meine Karten immer „runde“ Zahlen für die Abmessungen, also mindestens ganze 50er-Pixelwerte. Hier waren es letztlich 2200×1850 Pixel. Muss man nicht machen, ist eigentlich völlig egal, aber ich mag’s. Außerdem achte ich darauf, dass der Rahmen pixelgenau im Dokument liegt, d. h. die X- und Y-Werte der Position sind immer ganze Pixelwerte. Dadurch ist gewährleistet, dass die Randpixel beim Export auch zu 100% schwarz sind. Auch das sicher ein Detail, das von einem gewissen Hang zum Perfektionismus zeugt, aber es ist ja nicht wirklich zusätzlicher Aufwand.

Was die Gestaltung von Rahmen und Legende betrifft, so ist das sicherlich Geschmackssache. Manch einer mag keinen dicken schwarzen Rand um seine Karten, hat es evtl. lieber komplett randlos; das ist teils auch vom Motiv abhängig, und ich habe das bei anderen Karten auch gemacht (bei fremder Leute Karten einfach den Rand abzuschnippeln, ist allerdings nichts, womit man sich Freunde macht). In meiner Mittelgebirgsserie hatte ich mich für einen deutlichen Rand entschieden: schwarze Linie plus weiße Linie mit 85 % Deckkraft, passend zum Hintergrund der Legende, der ebenfalls zu 85 % deckend ist. Derart halbtransparente Überlagerungen mögen nicht den Gepflogenheiten der klassischen Kartografie entsprechen, aber wie gesagt: Geschmackssache. Und es hat sich auch noch niemand darüber beschwert.

Die Legende konnte ich natürlich aus früheren Karten übernehmen, weil die immer gleich ist. Einzige Anpassung neben dem Kartentitel war das rote Rechteck auf der Deutschlandkarte. Das skaliere und platziere ich immer Pi mal Daumen und orientiere mich dabei an den Bundesländer-Grenzen. Da die Projektion der kleinen Karte aller Wahrscheinlichkeit nach nicht der Projektion der großen Karte entspricht, dürfte das Rechteck genau genommen vermutlich nicht mal ein Rechteck sein. Aber da hört dann mein Perfektionismus auch schon wieder auf. Ich denke, dass bei der Darstellungsgröße ein Rechteck eine gute Näherung darstellt.

Jetzt aber Butter bei die Fische

Ein paar Worte zur Generalisierung

Jetzt konnte die eigentliche Arbeit beginnen: das Einzeichnen und Platzieren von Orten, Gewässern, Bergen, Straßen, Grenzen und Beschriftungen aller Art. Bei dieser Arbeit kommt man nicht umhin, sich der Regeln der Generalisierung zu bedienen, denn der Platz auf einer Karte ist begrenzt.

Verläuft beispielsweise eine Straße parallel zu einem Fluss, der gleichzeitig die Grenze zum Nachbarland bildet, dann ist es nicht möglich, alle drei Liniensignaturen lagetreu, also an ihrer tatsächlichen Position einzuzeichnen, weil der Kartenmaßstab das nicht hergibt. So hätte eine vierspurige Autobahn mit einer realen Breite von 30 m in meinem Kartenmaßstab rein rechnerisch noch eine Breite von 0,6 Pixeln, wird aber mit 7 Pixeln Breite gezeichnet (was schon sehr dünn erscheint). Da kommt es also zwangsläufig zu Kollisionen, und man muss entscheiden, welche Linien man wohin verschiebt, damit man sie nebeneinander darstellen kann. Ähnlich verhält es sich mit sehr kurvigen Linienobjekten wie zum Beispiel einem stark mäandrierenden Fluss, Serpentinen oder einem Grenzverlauf mit vielen kleinen „Nasen“. Würde man diese Verläufe exakt nachzeichnen, würden enge Kurven miteinander „verschmelzen“, und die Form des Objektes wäre nicht mehr zu erkennen. In beiden Fällen muss man generalisierende Entscheidungen treffen, also die Darstellung anpassen, ohne dass dabei der Charakter der Objekte oder ihre Lagebeziehungen verloren gehen. Aber auch die Darstellung von Orten durch Punktsignaturen und die Entscheidung, welche Objekte man überhaupt darstellt und welche man weglässt, was für die Karte wichtig und was unwichtig ist, fallen unter das Stichwort „Generalisierung“. Es gibt keine Karte, die nicht generalisiert.

Welche generellen Entscheidungen habe ich also diesbezüglich bei meiner Kartenserie getroffen? – Es handelt sich um physische Karten, also um eine Darstellung der Formen der Erdoberfläche. Dementsprechend dürfte es nicht überraschen, dass Gebirge, Berge, Flüsse und Seen eingezeichnet werden, was bei einer politischen Karte größtenteils verzichtbar wäre. Auch Städte und größere Orte stelle ich dar (zur Auswahl schreibe ich weiter unten noch etwas). Auf Straßen hingegen habe ich weitgehend verzichtet; lediglich Autobahnen sind zur Orientierung eingezeichnet. Das hätte man sicher auch anders entscheiden können. Ebenso verhält es sich mit Bahnstrecken, die bei mir gar nicht vorkommen. Staats- und Bundesländergrenzen sind ebenfalls mit dabei, Grenzen von Landkreisen oder Gemeinden hingegen nicht.

Grenzen und Autobahnen – Ich fange immer mit den falschen Sachen an

Was machen wir nun mit den drei (fiktiven, aber realistischen) parallelen Liniensignaturen, die alle an den selben Ort gehören? Welche hat Vorrang und welche muss verschoben werden? Da wir ein Relief als Grundlage haben, ist in der Regel den Gewässern der Vorzug zu geben, denn die folgen den Oberflächenformen, und wenn man einen Fluss aus seiner eigentlichen Lage verschiebt, kann es passieren, dass er plötzlich einen Berg überquert, was den Betrachter der Karte zurecht stutzig machen würde. Es wäre also logisch, mit der Zeichnung der Gewässer zu beginnen.

Aber wie der Überschrift und dem Screenshot zu entnehmen ist, habe ich das nicht gemacht. Die Gewässer habe ich mir immer bis zum Schluss „aufgehoben“, weil es einfach die meiste Arbeit ist. Das bringt dann mit sich, dass man am Ende unter Umständen bereits eingezeichnete Signaturen wieder verschieben muss, weil dann doch ein Fluss an einer Stelle wichtiger ist. Kein effizienter Workflow – aber ihr könnt es ja anders machen.

Trotzdem habe ich also mit den Ländergrenzen begonnen, die auf der unterliegenden OSM-Karte gut zu erkennen waren und nachgezeichnet werden konnten (3,5 pt Linienbreite, gestrichelt). Dazu habe ich das Bleistift-Werkzeug mit aktiviertem Modelliermodus verwendet. Ich darf mittlerweile ein Grafiktablett (mit eingebautem Bildschirm) mein eigen nennen, was eine erhebliche Erleichterung darstellt; bei früheren Karten habe ich noch alles mit der Maus gemacht – das geht natürlich auch. Ein Tipp: Man sollte immer denselben Zoomfaktor einstellen, wenn man die Linien zeichnet (bei mir waren es 300 %). Bei den Grenzen mag das noch nicht so entscheidend sein, aber bei den Flüssen trägt es zu einer einheitlichen Darstellung bei. Denn je weiter man in die Karte hineinzoomt, um so kleinere Kurven lässt der Bleistift zu, und idealerweise sollte der Detailgrad über die ganze Karte (bzw. in meinem Fall die ganze Kartenserie) hinweg gleich bleiben. Das ist gleichzeitig schon ein Beitrag zur Generalisierung des Kurvenverlaufs. Und natürlich ist darauf zu achten, dass die Kurvenradien nicht zu klein werden, damit eine Linie nicht mit sich selbst verschmilzt. Am besten direkt in der endgültigen Strichstärke zeichnen.

Die Autobahnen habe ich nicht mit dem Bleistift nachgezogen, sondern ich habe die Bézierkurven mit dem Zeichenstift-Werkzeug konstruiert. Im Gegensatz zu Grenzen und Flüssen haben Autobahnen große Kurvenradien, und diese teils langen Schwünge lassen sich durch bewusste Platzierung von Punkten störungsfreier abbilden. Das Netz aus schwarzen Linien (7 pt) wurde dupliziert, die Kopie gelb eingefärbt und mit 6 pt Strichstärke darübergelegt. Wo immer Autobahnen und Grenzen sich zu nahe kamen oder gar berührten, wurde eines von beiden etwas verschoben.

Beschriftung

Ebenfalls ist im obigen Screenshot zu sehen, dass ich zu Beginn schon ein paar großräumige Landschaften beschriftet habe. Diese Textobjekte bleiben in den seltensten Fällen bis zum Schluss an genau diesen Positionen und in dieser Ausrichtung stehen. Aber gerade die sehr großen Schriften blocke ich gerne frühzeitig rein, um mir vor Augen zu führen, dass die am Ende da irgendwo hinpassen müssen.

Schriftart

Ich habe in meinen Karten durchgehend die Schriftart Liberation Sans verwendet. Es gibt ja mittlerweile zahlreiche Schriften unter freier Lizenz, aber meine Wahl fiel seinerzeit auf diese, weil sie nicht so breit ist wie beispielsweise Vera/DejaVu und es außerdem noch eine schmale Variante (Liberation Sans Narrow) gibt.

Freistellung

Allen Beschriftungen ist gleich, dass ich sie generell freistelle, d. h. mit einer dünnen Kontur in der Hintergrundfarbe versehe, die hinter die Textfüllung gelegt wird. Insbesondere wenn ein Textobjekt auf einer Liniensignatur zu liegen kommt, verbessert das die Lesbarkeit deutlich. Schaut man sich meine älteren Mittelgebirgskarten an (also alle vor dem Thüringer Wald), wird man sehen, dass die Wahl der Konturfarbe oft ein nicht immer befriedigender Kompromiss war, denn je länger ein Text ist, um so größer ist die Wahrscheinlichkeit, dass er über viele unterschiedliche Farben des Reliefs läuft. Einem Textobjekt ließ sich in (meinem alten) Illustrator aber nur eine einzige Konturfarbe zuweisen. In Affinity Designer geht das buchstabenweise, so dass bei Schriftzügen, die gleichzeitig auf grünem und braunem, auf hellem und dunklem Hintergrund liegen, die Kontur besser angepasst werden konnte. Diese Optimierung habe ich aber natürlich erst ganz am Ende vorgenommen, als alle Schriften positioniert waren, daher sind die Konturen auf den Screenshots der Zwischenstände oft noch unpassend.

Schriftgrößen und Schriftschnitte

Was die Schriftgrößen angeht, tu ich mich schwer damit, meine Wahl nachvollziehbar zu begründen. Gleiche Dinge sollten gleich beschriftet werden, das ist soweit noch klar. Aber wie groß? – Da Platz immer der limitierende Faktor ist, ist es verlockend, alle Schriften einfach sehr klein zu machen. Eine gute Karte kommt dabei aber vermutlich nicht heraus.

Namen der Staaten und Bundesländer (lila) haben eine Größe von 50 pt (fett/kursiv/Versalien) bzw. 40 pt (fett)
Ortsnamen (schwarz) sind je nach Größenkategorie in 32 pt, 38 pt, 44 pt (fett) und 50 pt (fett/Versalien) gesetzt; Landeshauptstädte werden zudem unterstrichen
Namen von Flüssen und Seen (blau) haben 28 pt und sind kursiv
Bei Bergen (braun) sind es 26 pt, und ich habe die schmale Schriftvariante (Narrow) in fett gewählt, um die Beschriftungen optisch von den Ortsnamen abzusetzen
Gebirge beschrifte ich immer in Schwarz, alle anderen Landschaften in Grün (fett). Die Trennung zwischen beiden ist aber teils unscharf, und dann folge ich eher meinem Gefühl als rein objektiven Kriterien. Auch die Schriftgrößen handhabe ich variabel – aber nicht beliebig, denn wenn man anfängt, immer irgendeine Schriftgröße zu wählen, die gerade zum verfügbaren Platz passt, endet das schnell in einem unübersichtlichen und unharmonischen Durcheinander. Also nicht zu viele verschiedene Größen einsetzen und für gleiche Dinge nach Möglichkeit die gleiche Größe nutzen. Der Hauptschriftzug des Gebirges steht meist in 80 pt, Teilgebiete in 60 pt oder 45 pt, benachbarte Gebirge und Landschaften in 45 pt, 35 pt oder 30 pt (das ist das Minimum). Das kann sich auch zwischen einzelnen Karten der Serie unterscheiden, sollte innerhalb einer Karte aber irgendwie… ja, eben harmonisch sein. Wie gesagt: schwer zu begründen, oft eine intuitive Entscheidung.

Schriftplatzierung

Zur Platzierung von Schrift auf Karten habe ich vor einiger Zeit das nebenstehende Merkblatt verfasst, das auf der Hilfe-Seite der Kartenwerkstatt zu finden ist. Das fasst viele Grundsätze ganz gut zusammen; man sollte sich aber klarmachen, dass man nicht alle immer sklavisch wird befolgen können, vor allem auf einer Karte, die sehr voll ist.

Orte

Orte werden üblicherweise ihrer Einwohnerzahl entsprechend dargestellt. Ihr seht in der Legende, dass ich Punktsignaturen für vier Größenkategorien vorgesehen habe. Bei den beiden oberen Kategorien wird zudem das Stadtgebiet durch eine halbtransparente Flächensignatur dargestellt (siehe hier Erfurt). Alle Städte/Gemeinden mit roten Signaturen wurden in die Karte aufgenommen (wobei es rund um den Thüringer Wald keine Stadt mit mehr als 500.000 Einwohnern gibt). Bei den Orten unter 20.000 Einwohnern musste ich abwägen, denn es konnte nicht jedes Dorf und jeder Weiler berücksichtigt werden. Städte (im rechtlichen Sinne) nehme ich in der Regel immer auf – die sind auch meist einwohnerstärker als Gemeinden mit Gemeindestatus. Ansonsten ist die Zahl 10.000 so eine Grenze, die ich üblicherweise ansetze. Orte mit mehr als 10.000 Einwohnern versuche ich immer aufzunehmen. Bei Orten, die darunter liegen, kommt es z. B. auf ihre Bedeutung an. Gerade in Bergregionen gibt es oft kleine Orte, die aber als touristische Ziele bekannt sind (auf dieser Karte z. B. Oberhof). Auch eine historische Bedeutung kann den Ausschlag geben. Und zuletzt spielt auch der verfügbare Platz in der Karte eine Rolle.

Die Orte hole ich mir aus dem unterliegenden OSM-Ausschnitt, der OSM-Internetkarte sowie den Wikipedia-Artikeln der einzelnen Landkreise bzw. Städte, wo dann auch die Einwohnerzahlen dabeistehen. Die Ortsnamen werden zunächst nur grob daneben gesetzt und im Laufe der weiteren Kartenerstellung passend verschoben.

Ein Problem, das ich rückblickend betrachtet auch wenig konsequent gehandhabt habe in meinen Mittelgebirgskarten, ist die Tatsache, dass die Einwohnerzahl einer Kommune nichts über die tatsächliche räumliche Verteilung der Einwohner aussagt. Besteht eine Stadt aus mehreren größeren Orten, dann wäre unter Umständen für jeden Ort eine eigene Signatur angebracht statt einer einzigen für die gesamte Stadt. Zudem gibt es Städte, die im Zuge von Gebietsreformen entstanden sind und denen ein Kunstbegriff als Name verpasst wurde, den keiner ihrer Orte trägt. Ein gutes Beispiel ist Erftstadt in Nordrhein-Westfalen. Die Stadt hat über 50.000 Einwohner, ihre beiden etwa gleich großen Hauptorte – von denen keiner den Namen „Erftstadt“ trägt – aber jeweils nur knapp über 10.000. Will man nun die tatsächliche Bevölkerungsverteilung darstellen und setzt zwei kleine Signaturen für die Orte Lechenich und Liblar? Oder setzt man „irgendwo“ in das Stadtgebiet eine große Signatur mit dem Namen Erftstadt, weil das administrativ nunmal eine recht große Stadt ist, auch wenn es an der Stelle der Signatur gar keine 50.000-Einwohner-Siedlung gibt und keine Ortslage, die Erftstadt heißt? Diese Widersprüche werden sich nie ganz auflösen lassen. Noch unbefriedigender wird es, wenn sich die Karte über mehrere Bundesländer erstreckt, in denen das Gemeindewesen sehr unterschiedlich organisiert ist. So wurden in NRW in den 1960er und 1970er Jahren durch Zusammenschlüsse größere Städte und Gemeinden geschaffen, während es in Rheinland-Pfalz das Konzept der Verbandsgemeinden gibt, wo die Gemeinden an sich aber klein geblieben sind (NRW hat knapp 400 Gemeinden, Rheinland-Pfalz 2.300, und das bei weniger als einem Viertel der Bevölkerung von NRW). Auf meiner Eifelkarte sieht man daher wesentlich mehr rote Signaturen in NRW als in Rheinland-Pfalz, was nicht ausschließlich auf unterschiedliche Bevölkerungsdichte zurückzuführen sein dürfte (auch wenn der Raum Köln/Bonn natürlich stärker bevölkert ist als die Eifel), sondern teils auch schlicht auf die unterschiedliche administrative Gliederung.

Gebirge und Berge

Die Namen von Gebirgszügen findet man nicht in OSM. Hier greife ich auf alle Quellen zurück, die sich so anbieten und die oben auch schon erwähnt wurden, also die Wikipedia, Geoviewer, Atlanten, Naturraumkarten etc. Diese Karte hier ist mir auch immer hilfreich.

Die Karten zur Naturräumlichen Gliederung Deutschlands, die ich oben ebenfalls bereits erwähnt hatte (die aber den Thüringer Wald nicht abdecken), sind bei meinen Mittelgebirgskarten immer eine wertvolle Hilfe, jedoch nur eine Quelle unter mehreren. Es war nie mein Ziel, Naturraumkarten auf Basis dieser Gliederungskarten anzufertigen, sondern allgemeine topographische Karten einer Region. Demzufolge stelle ich nie die komplette Gliederung dar, sondern beschrifte immer nur die größeren Einheiten und ausgewählte Untereinheiten bzw. Landschaften. Hinzu kommt, dass die Einteilung der Landschaft in einzelne Einheiten, die Abgrenzung dieser Einheiten voneinander und ihre Bezeichnungen nicht immer eindeutig sind, oftmals gibt es auch unterschiedliche Auffassungen darüber. So kann es vorkommen, dass ich mitunter eine „landläufige“ Bezeichnung einer „wissenschaftlichen“ vorziehe.

Ich habe oben schon etwas zur Auswahl der Schriftgrößen bei der Beschriftung von Gebirgen geschrieben. Was die Ausrichtung der Schrift betrifft, setze ich sie in aller Regel mithilfe von Pfadtext in einer leichten Kurve der größten Ausdehnung des Gebirges folgend.

Beim Einzeichnen von Bergen sieht meine Vorgehensweise so aus:

Im Wikipedia-Artikel zum jeweiligen Gebirge findet sich meist eine Liste seiner höchsten bzw. bedeutendsten Berge. Die arbeite ich von oben nach unten ab.
Jeden Berg der Liste lokalisiere ich auf der OSM-Karte, und dann kann ich ihn normalerweise auch leicht auf meinem unterliegenden OSM-Screenshot identifizieren (wo die Bergsignaturen meist zu erkennen sind, aber die Namen fehlen).
An die betreffenden Stellen setze ich meine Bergsignaturen, den Namen des jeweiligen Berges und seine Höhe. Dabei muss ich schon ein wenig aussortieren, weil aufgrund des Platzes nicht alle Berge übernommen werden können. Höhere Berge erachte ich allgemein als wichtiger als niedrigere, aber auch die Dominanz eines Berges ist zu berücksichtigen. Und wie bei den Orten kann es auch bei Bergen Exemplare geben, die vielleicht nicht zu den höchsten zählen, aber trotzdem eine gewisse Bedeutung haben und deshalb in die Karte aufgenommen werden sollten.
Bei allen benachbarten Gebirgen, die nicht Hauptthema meiner Karte, aber ganz oder teilweise abgebildet sind, ziehe ich den jeweils höchsten auf der Karte sichtbaren Berg heran und setze dort ebenfalls eine Signatur. Außerdem schaue ich, ob im Relief noch weitere markante Erhebungen zu erkennen sind, die bezeichnet werden sollten. Auf dieser Karte sind der Dolmar und die beiden Gleichberge südwestlich des Thüringer Waldes gute Beispiele dafür.
Im Laufe der weiteren Kartenerstellung, insbesondere wenn ich die Gewässer (und deren Namen) hinzufüge, fliegt der eine oder andere Berg aus Platzgründen auch schon mal wieder raus.
Wenn meine Karte fertig ist und ich sie in der Kartenwerkstatt präsentiere, nehme ich die Rückmeldung derer entgegen, die sich vor Ort wirklich auskennen. Das kann dann noch zu Änderungen führen, wenn ich einen Berg eingezeichnet habe, den keiner kennt, und/oder etwas Bekanntes vermisst wird. Das ist der angenehme Teil der Prozedur: andere arbeiten lassen …

Flüsse und Seen

Auch bei den Gewässern muss eine Auswahl getroffen werden. Für meine Mittelgebirgskarten habe ich im Laufe der Zeit die folgenden groben Regeln aufgestellt: Flüsse unter 10 km Länge werden nicht dargestellt, ab 15 km sind sie in der Regel drin, ab 20 km auf jeden Fall. Bei Seen liegt die Mindestgröße bei ca. 50 ha (500.000 m², 0,5 km²). Und wieder gilt: das sind keine in Beton gegossene Regeln, sondern lediglich Leitlinien. So habe ich auf meiner Eifelkarte auch die wesentlich kleineren Maare eingezeichnet, weil sie ein charakteristischer Landschaftsbestandteil sind.

Die Strichstärke bei Flüssen sind mindestens 3 pt. Bei größeren bzw. längeren Flüssen kann sich das auf bis zu 7 pt erhöhen – auch hier beginne ich an der Quelle mit 3 pt Breite (wenn die Quelle denn auf der Karte liegt), erhöhe dann aber im Verlauf immer mal wieder um 1 pt, meist an der Einmündung eines größeren Nebenflusses. Ich folge hier wieder meiner Intuition und recherchiere keine Abflussmengen o. ä.

Das Einzeichnen der Flüsse – das hatte ich schon angedeutet – ist die aufwändigste Arbeit in meinen Karten, eben weil ich alles neu zeichne. Das Gewässernetz im Bereich der Karte ist in aller Regel auf mehrere größere Flusssysteme verteilt, die sich leicht identifizieren lassen. Hier beim Thüringer Wald wird z. B. der nordwestliche Teil der Karte über die Werra entwässert (siehe auch die nebenstehende Karte). Diesen „Hauptabfluss“ habe ich also als einen der ersten eingezeichnet. Anschließend habe ich mir den Wikipedia-Artikel der Werra genommen, in dem eine Tabelle der wichtigsten Zuflüsse zu finden ist. Die bin ich nach und nach durchgegangen und habe die Flüsse eingezeichnet, die meinen Regeln der Mindestlänge entsprachen (zumindest für Deutschland sind die meisten Fluss-Artikel dahingehend recht gut ausgebaut und für diesen Zweck brauchbar). Natürlich kann auch ein Zufluss wiederum Zuflüsse haben, die eine entsprechende Länge aufweisen, um relevant zu sein – da arbeite ich mich dann nach und nach durch.

Je kleiner ein Fluss ist und je mehr man sich der Quelle nähert (ich fange meistens an der Mündung an zu zeichnen), um so wahrscheinlicher ist es, dass der Flusslauf nicht auf dem unterliegenden OSM-Screenshot zu sehen ist. Das ist natürlich zum Nachzeichnen ungünstig. Mein Einzeichnen ist daher immer eine Kombination aus Wikipedia-Informationen (Koordinaten von Quelle und Mündung sind in der Regel angegeben), der OSM-Internetkarte, meinem Screenshot als Zeichengrundlage und der Reliefdarstellung. In der Internetkarte identifiziere ich den Fluss (im Idealfall ist er in OSM in ganzer Länge als ein Relationsobjekt getaggt, dann kann man ihn leicht markieren und hervorheben) und zeichne ihn dann auf meinem OSM-Screenshot nach. Wenn er dort nicht zu sehen ist, lässt sich der Verlauf durch optischen Abgleich mit der Internet-Karte trotzdem ganz gut nachvollziehen (glücklich, wer einen Zweitmonitor sein eigen nennt). Sollte ein Fluss auch in OSM nicht vollständig dargestellt sein, schaue ich in den Geoviewer des Bundeslandes und hole mir da den fehlenden Rest. Am Ende blende ich das Relief ein und schaue, ob das fließtechnisch so auch alles Sinn ergibt. Und es ist auch schon vorgekommen, dass ich anhand des Reliefs einen „fehlenden Zufluss“ gefunden habe. Der war dann einfach nicht in der Wikipedia-Tabelle eingetragen und mir deshalb durchgerutscht. Zwei Fliegen mit einer Klappe: so konnte ich dann auch gleich den Wikipedia-Artikel ergänzen.

Außerdem achte ich beim Einzeichnen darauf, ob ein Fluss einen auf meiner Karte verzeichneten Ort durchquert oder möglicherweise knapp daran vorbeifließt. Gegebenenfalls verschiebe ich die zuvor gesetzte Ortssignatur dann mittig auf den Flusslauf oder eben bewusst rechts oder links daneben.

Nach Möglichkeit werden Flüsse beschriftet, längere Flüsse auch mehrmals (siehe z. B. die Werra). Wo es in der Karte sehr eng wird, müssen die Namen kürzerer Flüsse mitunter entfallen, die Flüsse selbst bleiben aber trotzdem drin. Ich verwende immer gebogenen Pfadtext, der dem Verlauf folgt, und versuche die Beschriftungen so zu setzen, dass auch bei Einmündungen von Nebenflüssen klar ist, welcher Abschnitt welchen Namen trägt. So ist beispielsweise im nebenstehenden Werra-Beispiel der Schriftzug „Nesse“ (ganz oben zwischen Hainich und Fahner Höhe) so gesetzt, dass deutlich wird, dass hier der Wilde Graben in die Nesse mündet, also der Fluss vor und nach der Einmündung Nesse heißt. Das ist aufgrund des Platzes aber nicht immer so gut möglich wie hier.

Und wenn man auf diese Weise ein Flusssystem abgearbeitet hat, folgen dann auf gleiche Weise die weiteren, bis die komplette Karte entwässert ist (hier Saale mit Ilm und Gera nach Osten und Norden sowie im Süden alles, was Richtung Main fließt: Fränkische Saale, Itz, Rodach etc.). Die Kartenlegende ignoriere ich übrigens beim Einzeichnen der Flüsse, d. h. dass ich auch die dahinter liegenden Flussläufe einzeichne. Da meine Legende leicht transparent ist, scheint das Relief etwas durch, da gehören dann die Flüsse dazu. Vor allem aber lade ich die Reliefs meiner Mittelgebirgskarten immer auch separat auf Commons hoch (einmal mit, einmal ohne Gewässer). Die kann man sich als Grundlage nehmen, wenn man eine eigene Karte des Gebiets erstellen möchte (ich weiß allerdings nicht, ob das schon mal jemand gemacht hat). Sämtliche Beschriftungen, Orts- und Bergsignaturen lege ich hingegen nicht hinter die Legende.

Finales Aufhübschen

Nachdem alles so weit eingezeichnet war, folgten die abschließenden Verfeinerungen: ein letztes Arrangieren der Beschriftungen und schließlich die Anpassung der Konturfarben zur Schriftfreistellung an den jeweiligen Hintergrund.

Alles muss raus

Export als PNG

Am Ende exportiere ich meine Karten im PNG-Format. Dazu markiere ich das Kartenrand-Rechteck und wähle im Exportdialog von Affinity Designer „Bereich der Auswahl“. Dann wird nur der Teil, der vom markierten Rechteck überdeckt wird, exportiert.

Aber warum erstelle ich ein PNG, warum keine SVG-Vektordatei, ist das nicht moderner und besser? – Jein. Sicher spricht bei Illustrationen und somit auch bei Karten einiges dafür, SVG als Dateiformat auszuwählen. Aus zwei Gründen tu ich das im Falle meiner Mittelgebirgskarten aber nicht.

Zum einen sind die Karten sehr detailliert und „eng“, d. h. die einzelnen Signaturen und Schriften müssen quasi pixelgenau platziert werden, um ein schönes Kartenbild zu erhalten. Bei einer SVG-Datei ist insbesondere das Rendern von Schrift problematisch: Kennt der Renderer die Schriftart nicht, nimmt der Browser irgendeine andere und zerschießt damit das Kartenbild. Viele Textobjekte sind außerdem als Pfadtext angelegt, und soweit ich weiß, hat SVG damit Probleme (macht Einzelbuchstaben daraus). Hinzu kommt das Hinterlegen eines Textobjektes mit einer farbigen Kontur zwecks Freistellung. Daraus werden in SVG zwei übereinanderliegende Objekte. Und nicht zuletzt ist der SVG-Renderer von Wikipedia (der aus dem SVG verkleinerte PNG-Dateien erstellt, die dann auf den Wikipedia-Seiten eingebunden werden) verbesserungswürdig. Zumindest war er das mal, vielleicht hat sich da ja mittlerweile auch was getan. Ein Beibehalten der Schriften als Textobjekte ist also eine heikle Sache, wenn der Kartograf darauf bedacht ist, dass die Karte exakt so aussieht, wie er sich das vorgestellt hat. Man könnte beim SVG-Export alle Schriften in Kurven umwandeln, aber das ist irgendwie auch immer eine Krücke, denn eine Änderung einer solchen SVG-Datei ist dann auch nicht mehr trivial.

Der zweite Punkt ist das Relief: das ist ja nun mal eine Bitmap-Datei. Der Vorteil von SVG-Vektorgrafiken ist die Skalierbarkeit, aber durch den (nicht beliebig skalierbaren) Hintergrund käme dieser Vorteil hier nur bedingt zum Tragen.

Zusammengefasst lässt sich sagen: Ich möchte, dass die Karte, die ich erstelle, stets so aussieht, wie ich das vorgesehen habe. Und da ist eine Bitmap-Datei noch immer die „sicherste“ Lösung. Und wer dieser Argumentation nicht folgen kann oder will, muss damit leben, dass ich dahingehend vielleicht altmodisch bin.

Datei-Optimierung

Die fertige PNG-Datei schicke ich vor dem Hochladen immer noch durch ein Optimierungsprogramm, das die Dateigröße etwas reduziert. Ich verwende dazu den eingangs verlinkten FileOptimizer. Einfach Datei reinschieben und das Optimieren starten. Bei den relativ großen und detailreichen PNG-Karten dauert der Vorgang ein paar Minuten (zumindest auf meinem PC), und das Einsparpotenzial ist auch nicht allzu groß, aber besser als nichts.

Produkt reift beim Kunden

Und das war es dann im Grunde auch schon. Wie bereits angemerkt, stelle ich meine Karten nach dem Hochladen in der Wikipedia-Kartenwerkstatt ein, um Rückmeldungen zu erhalten. Meist gehen daraufhin auch ein paar Änderungswünsche bzw. -vorschläge ein, die ich in der Regel aufgreife (oder auch freundlich ablehne, wenn ich anderer Meinung bin). Und dann erkläre ich das Ganze schließlich für FERTIG.

Arbeitsnachweis

Bayerischer Wald
Eifel
Harz
Hunsrück
Oberpfälzer Wald
Odenwald
Rhön
Rothaargebirge
Schwäbische Alb
Schwarzwald
Spessart
Taunus
Teutoburger Wald und Weserbergland
Thüringer Wald
Vogelsberg
Westerwald