Benutzer:Franzpaul/Baustelle2

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Projekt: Historische Karten im SVG-Format

[Bearbeiten | Quelltext bearbeiten]

Es hat mehrere Vorteile, Karten – wenn es sich nicht gerade um topografische Karten mit detaillierten Flussläufen, Höhenlinien oder gar Schummerung handelt – als Vektorgrafik (SVG) zu erzeugen.

  • Skalierbarkeit. Dieser systemimmanente Vorteil kommt bei Karten nicht so stark zum Tragen wie etwa bei Wappen oder sonstigen Cliparts. Anstatt eines SVG könnte man auch eine Pixelkarte hoher Auflösung (Seitenlänge > 3000px) produzieren; bei Skalierung auf bildschirmfüllend oder gar thumb wäre kein Unterschied zu erkennen (und in jedem Fall die Beschriftung nicht mehr lesbar). Dem SVG-Format fehlt die kontextabhängige Skalierung.
  • Nachträgliche Änderungen. SVG erlaubt, die Grafik so anzulegen, dass sie jeder – mit nur elementaren SVG-Kenntnissen, ohne Spezialwerkzeuge – ändern kann, z.B. Flächen anders einfärben, Texte hinzufügen/weglassen/ändern, zusätzliche Informationen einzeichnen. (Wer schon mal durch Antialiasing verschönerte Pixelkarten nachbearbeiten musste, weiß dies zu schätzen.) Die Betonung liegt hier auf SVG erlaubt; leider unterstützen Zeichenprogramme und Viewer diese Möglichkeiten nur beschränkt. Stichworte: CSS, symbol/use, transform.
  • Georeferenzierung/Koordinaten. Wenn eine vorhandene Karte durch zusätzliche Informationen ergänzt werden soll, stellt sich die Frage nach der korrekten Platzierung. Über den naiven Ansatz der Art hier müsste es ungefähr liegen sollten wir mittlerweile hinaus sein. SVG erlaubt entsprechende Metadaten (siehe SVG Spec 7.12), was aber nur theoretisch weiterhilft, weil diese Daten nur von spezieller GIS-Software verstanden werden und damit eine neue Nutzerbarriere errichten. Man kann aber die SVG-Pfade direkt in Koordinaten definieren und den Rest von einer Transformation erledigen lassen. Da SVG ausschließlich affine Trafo beherrscht, kommen als Koordinatensystem keine geografischen, sondern nur kartesische (vulgo Vermessungs-) KS in Frage, etwa Gauß-Krüger oder UTM, was (wegen der Verzerrungen) die Größe des darzustellenden Gebiets begrenzt. (Innerhalb eines UTM-Streifens sollte ok sein.)

Grundsätzliche Probleme

[Bearbeiten | Quelltext bearbeiten]
  • Erzeugen des SVG aus den Rohdaten. Man könnte die Generic Mapping Tools verwenden. Ein etwas altbackenes Programm, das nur über Umwege SVG produziert... Dann doch lieber in Eigenarbeit.
  • Balance zwischen Lagegenauigkeit (Zahl der Polygonpunkte, Dezimalstellen) und Dateigröße.
  • Unterschiedliche Orientierung der Koordinatenachsen: Bei SVG zeigt die y-Achse nach unten, hingegen bei Vermessungskoordinaten der Hochwert nach oben. Das bedeutet: Wenn die SVG-Pfade in Vermessungskoordinaten definiert werden sollen, müssen entweder alle Hochwerte mit Minuszeichen versehen werden oder man spiegelt die ganze Karte mit scale(1,-1). Letzteres wäre auch keine Katastrophe, müsste aber beim Einbinden sonstiger Informationen (Texte, Symbole) beachtet werden.

Arbeitsanleitung in Stichworten

[Bearbeiten | Quelltext bearbeiten]
  1. Alte Karte besorgen. Nach Möglichkeit mit den Originalquellen arbeiten, nicht mit XYs Historischem Weltatlas. Vereinfachungen und Fehler kann man bei Bedarf selber einbauen ;-)
  2. Relevanten Inhalt (z.B. Grenzlinien) digitalisieren. Ergebnis: Polygonzüge mit Koordinaten in Zentimetern oder Pixeln.
  3. Umrechnen auf das der Karte zugrunde liegende KS. Dies ist trivial, wenn die Karte einen achsenparallelen Ausschnitt aus einem kartesischen KS darstellt. Ansonsten mit den Koordinaten der Blattecken eine projektive Abbildung aufstellen.
  4. Umrechnen auf GK oder UTM.
  5. Rohes SVG erzeugen. Zwecks späterer Arbeitserleichterung mit Pfad-Definitionen und CSS arbeiten! Leider kennt SVG (im Gegensatz zu Metafont) keine Pfad-Verkettung. Bei Karten mit verschieden gefärbten Flächen werden die Dateien deshalb doppelt so groß, wie sie sein müssten.
  6. SVG nachbearbeiten, entweder mit (XML-)Editor oder mit Zeichenprogramm, z.B. Inkscape. Der (bei SVG lediglich nominelle) Maßstab kann abschließend durch Definition der Attribute width und height festgelegt werden.

Vorschlag für Dateinamen

[Bearbeiten | Quelltext bearbeiten]

Dateinamen setzt sich zusammen aus

  • Art der Karte. Dies lehnt sich an die bei gedruckten Karten geläufigen Bezeichnungen an, TK für Topografische Karte, GK für Geologische Karte usw. Vorläufiges Repertoire:
    • tk = topografische Karte
    • gk = geologische Karte
    • vk = Verwaltungskarte (z.B. Kreis- und Gemeindegrenzen)
    • rk = Regionalplanung (z.B. Mittelbereiche, Zentralität, Entwicklungsachsen)
    • mk = Gemarkungskarte (als Grundkarte für vk und hk)
    • hk = historische Territorien
    • xk = thematische Karten, die nicht in eine der vorigen Gruppen fallen
  • Dargestellter Raum. Für den Staat das Kürzel nach ISO 3166 verwenden. Untereinheiten mit Bindestrich anhängen. Baden-Württemberg wäre gemäß ISO 3166-2 als DE-BW anzusprechen, oder aber – besser, weil konsistent auf noch kleinere Einheiten übertragbar – wie beim Gemeindeschlüssel als DE-08. Bei historischen Territorien schlage ich Kürzel der Art DE-pr für Preußen, DE-by für Bayern usw. vor. (Kleinschreibung, um Verwechslungen mit ISO zu vermeiden.)
  • Stichwort bei xk, Stichjahr bei hk.

Konkrete Umsetzung

[Bearbeiten | Quelltext bearbeiten]

Am Beispiel Württemberg soll das dargelegte Arbeitsprogramm ausgeführt werden. Ziel sind zwei Karten für jedes Oberamt:

  • mk nach dem Stand von ca. 1850 (Landesvermessung)
  • hk nach dem Stand von 1801 (vor RDHS)

Die Einzelkarten können dann „zusammengeklebt“ werden, um ganz Württemberg abzudecken.