MARTIN-LUTHER-UNIVERSITÄT
HALLE-WITTENBERG
Projektarbeitsbericht
Methoden zur Verarbeitung historischer
und topographischer Kartenwerke
für eine GIS-basierte multitemporale Analyse der
Flächennutzungsentwicklung am Beispiel
Teutschenthal-Bahnhof
vorgelegt von:
Philipp Bolz Helen Kollai (210 240 519)
Stephan Dreller Kristian Möller (210 237 924)
Sarah Engel (210 241 011) Martin Ostrowski
Henning Gerstmann (210 244 559) Steffen Rechner (207 220 762)
Sascha Heße (206 211 152) Sebastian Schenk
Maria Herbig (206 221 960)
Modul: GIS-Projektmanagement
Semester: Wintersemester 2011/2012
Leitung: Prof. Dr. Cornelia Gläßer, Dr. Detlef Thürkow
Halle (Saale), 20. Februar 2012
I
Inhaltsverzeichnis
1 Einleitung.......................................................................................................... 1
1.1 Zielstellung und Methodik (Dreller) ............................................................. 1
1.2 Grundlagen zum Untersuchungsgebiet (Dreller) ........................................ 1
2 Projektmanagement ........................................................................................ 4
2.1 Projektplanung (Schenk) ............................................................................ 4
2.2 Risikomanagement (Bolz)........................................................................... 5
3 Datengrundlage................................................................................................ 7
3.1 Topographische Karten des Gebiets Teutschenthal-Bahnhof (Kollai) ........ 7
3.2 Metadaten (Gerstmann).............................................................................. 8
4 Datenverarbeitung ........................................................................................ 10
4.1 Scannen analoger Karten (Gerstmann) .................................................... 10
4.2 Bildbearbeitung (Schenk, Bolz) ................................................................ 10
4.2.1 Analyse der verwendeten Filter (Bolz) ............................................. 11
4.3 Georeferenzierung (Möller)....................................................................... 15
5 Datenauswertung ........................................................................................... 19
5.1 Landschaftswandel in den Gebieten um Teutschenthal-Bahnhof (Engel) 19
5.2 Vergleich der Kartenlegenden (Herbig) .................................................... 21
6 Metadatenbank ............................................................................................... 23
6.1 Metadatenstandards (Rechner) ................................................................ 23
6.2 Datenbankenentwurf (Heße) .................................................................... 25
6.3 Administration der Datenbank (Ostrowski/Heße)...................................... 30
6.4 Umsetzung der Datenbank (Ostrowski) .................................................... 33
6.5 Verbindung mit Geo-Server (Heße) .......................................................... 37
7 WebGIS (Schenk) ............................................................................................ 38
7.1 OpenLayers .............................................................................................. 38
7.2 WMS-Server ............................................................................................. 38
7.3 GeoTiff...................................................................................................... 38
7.4 Webseiten-Layout..................................................................................... 39
7.5 Vergleich mit anderen Online-Kartensammlungen bzw.
Online-Geo-Diensten ................................................................................ 40
II
8 Schlussbetrachtung (Dreller) ........................................................................ 42
Quellenverzeichnis.............................................................................................. 44
Kartenverzeichnis ............................................................................................... 47
Anhang
(Formatierung: Sarah Engel, Helen Kollai)
III
Abbildungsverzeichnis
Abb. 1: Anwendung der Tonwertspreizung im RGB-Raum mit dem
vorgegeben Kartenmaterial; Original(links); Resultat (rechts) .............. 12
Abb. 2: Anwendung des Filters „Unschärfe maskieren“ im RGB-Raum mit
dem vorgegeben Kartenmaterial; Original (links); Resultat (rechts) ..... 13
Abb. 3: Entfernen der durch Scannen entstandenen Fehlinformationen
(blauer Strich);Original (links); Resultat (rechts)................................... 14
Abb. 4: Entfernen der durch Scannen entstandenen Fehlinformationen
(blauer Strich) in farbiger Karte; Original (links); Resultat (rechts) ....... 14
Abb. 5: Vergleich von Symboliken und sich ändernden Ausprägungen als
ungeeignete Passpunkte...................................................................... 15
Abb. 6: Beispiel einer Passpunktsetzung.......................................................... 16
Abb. 7: WebGIS................................................................................................ 17
Abb. 8: Kupferstich eines Schachts mit Förderkorb.......................................... 19
Abb. 9: Teutschenthaler Halde ......................................................................... 20
Abb. 10: ER-Modell für die Metadatenbank........................................................ 26
Abb. 11: Relationales Modell .............................................................................. 28
Abb. 12: SQL-Skript für die Erstellung der Tabelle Metadata_Keywords ........... 28
Abb. 13: SQL-Skript für die Erstellung der Tabelle Metadata ............................. 29
Abb. 14: Formular zum Einfügen neuer Datensätze........................................... 31
Abb. 15: Suchfunktion der Metadatenbank......................................................... 33
Abb. 16: Freischaltformular mit Eingabe des Geo-Server Layers....................... 33
Abb. 17: Web-GIS. ............................................................................................. 40
Abb. A1: Gantt-Diagramm - Arbeitsplanung GIS-Projektmanagement..................A
IV
Tabellenverzeichnis
Tab. 1: Übersicht über die 10 wichtigsten Risiken eines Softwareprojektes........ 5
Tab. 2: Karten und deren dazugehörigen Legenden......................................... 21
Tab. A1: Landschaftswandel anhand von Gewässer; Teutschenthal ....................B
Tab. A2: Landschaftswandel anhand von Feuchtwiesen, Teutschenthal ..............C
Tab. A3: Landschaftswandel anhand von Waldflächen, Teutschenthal.................D
Tab. A4: Signaturenvergleich für „Grube“ bzw. „Böschung“ ..................................E
Tab. A5: Signaturenvergleich für „Kirche“ .............................................................. F
Tab. A6: Signaturenvergleich für „Landstraße“ ..................................................... G
Tab. A7: Beschreibung der Metadatenfelder .........................................................H
1
1 Einleitung
Auf Grund der langen Tradition kartographischer Aufnahen in Deutschland, existiert eine
Vielzahl verschiedenster historischer Karten. Diese liegen jedoch häufig in analoger Form
vor und sind in unterschiedlichsten Institutionen archiviert. Diese Tatsache macht eine
Recherche und einen Bezug der Karten häufig umständlich. Durch eine Digitalisierung,
Aufbereitung und anschließende Einbindung in ein Web-GIS können solche historischen
Karten für bestimmte Fragestellungen neu in Wert gesetzt und mir aktuellen digitalen
Geodaten in Beziehung gesetzt werden. Als Beispiel einer Anwendungsmöglichkeit wurde
im vorliegenden Projekt eine multitemporale Analyse von ausgewählten
Flächennutzungsänderungen für die Beispielregion Teutschenthal-Bahnhof durchgeführt.
Die Methodik zur Bearbeitung und Nutzung historischer und topographischer Karten soll
in dieser Arbeit beschrieben werden.
1.1 Zielstellung und Methodik
Übergeordnetes Ziel des Projekts ist die Schaffung einer Geodateninfrastruktur (GDI) der
Daten der Untersuchungsregion und deren Visualisierung in einer Web-GIS-Anwendung.
Die Erstellung der Anwendung soll so angelegt werden, dass sie für eine Verwendung für
multitemporale Kartenvergleiche geeignet ist. Wichtiger theoretischer Hintergrund für die
erfolgreiche Bearbeitung der Zielstellung ist das Wissen über Geoinformationssysteme
und Web-GIS sowie theoretische Grundlagen der Planung und Umsetzung eines GIS-
Projekts. Konzeptuell basiert der Aufbau der einzelnen Projektphasen auf dem EVAP-
Modell (Erfassung, Verwaltung, Analyse und Präsentation).
Praktisch wurde das Projekt in vier Arbeitsgruppen bearbeitet. Konkret beinhaltete das
Projekt die Arbeitspakete Recherche, Datenverarbeitung der Geodaten,
Datenverarbeitung der Metadaten und GDI bzw. Geodatenviewer (s. Abschnitt 2.1). Den
einzelnen Arbeitspaketen stand ein Leiter zur Koordination der Teammitarbeiter vor. Zu
gleich wurden zu Beginn die Bearbeiter für die verschiedenen Aufgabenstellungen, die
Zielsetzung, die Voraussetzungen, die gewünschten Ergebnisse sowie die Meilensteine
festgelegt. Die Praxisrelevanz des Themas und der Zielstellung wurde in einer Exkursion
unter der Leitung von Daniel Schwefel deutlich.
1.2 Grundlagen zum Untersuchungsgebiet
Die zu untersuchende Region Teutschenthal-Bahnhof liegt 15 km westlich von Halle an
der Saale im südlichen Sachsen-Anhalt und im östlichen Harzvorland (vgl. SCHWEFEL
2010, S. 20). Die in KOCH / STOTTMEISTER / THOMAE (vgl. 2002, S.105) thematisierte
2
Kalisalzhalde mit der dazugehörigen Feuchtsenke in Teutschenthal ist 1 km westlich von
Teutschenthal-Bahnhof zu finden. Der nördliche Teil des Gebiets ist durch Vernässung
gekennzeichnet. Der südliche Teil ist vom Bergbau beeinflusst. Das Gebiet wird als
Röblinger Revier bezeichnet. Die Waldflächen die hier anzufinden sind, sind häufig
ehemalige Bergbauflächen. Für das Röblinger Revier ist hierbei die Salza der Vorfluter. In
Folge berg- und tagebaulicher Aktivitäten kam es im Verlauf der Jahrzehnte zu
Veränderungen der gesellschaftlichen und wirtschaftlichen Infrastrukturen zum Beispiel in
Form von Umsiedlungen. Ebenso traten bedeutenden Veränderungen des natürlichen
Landschaftsbildes auf. Hierzu zählen beispielsweise Versalzungen, Vernässungen und
die Anlage von Abraumhalden.
Klima und Wasserhaushalt
Die Region Teutschenthal-Bahnhof zählt zum subkontinentalen mitteldeutschen
Binnenklima. Das Jahresmittel der Temperatur liegt hier bei 8,8 °C. Der Wind kommt
vorwiegend aus West bis Südwest und damit befindet sich das Untersuchungsgebiet im
Regenschatten von Harz und Thüringer Wald. In der Folge treten nur geringe jährliche
Niederschläge von unter 500 mm auf. Der Niederschlag erreicht im Februar und im März
seinen Minimalwert und im Juli sein Maximum. Die Hauptvegetationsperiode erstreckt
sich von Mai bis Juli und wird im Wesentlichen durch den geringen Niederschlag begrenzt.
Durch die minimalen Niederschläge und die vergleichsweise hohe Verdunstung entsteht
ein geringer Abfluss (vgl. SCHWEFEL 2010, S. 32). Die Grundwasserspiegelhöhe im Gebiet
Teutschenthal-Bahnhof liegt auf Höhe des Geländeniveaus oder etwas höher (vgl. KOCH /
STOTTMEISTER / THOMAE 2002, S. 105). Das Grundwasser fließt vom Galgenhügel südlich
Teutschenthals gesehen in NNW-Richtung. Die Höhe des Grundwasserspiegels variiert
von 120 m NN in der Nähe des Galgenhügels bis 90 m NN im Gebiet zwischen
Teutschenthal-Bahnhof und Bundesstraße B80 (vgl. ebd. S. 107).
Boden und Vegetation
Ausgangspunkt der Bodenbildung ist der jungweichselzeitliche Löss auf mesozoischem
bzw. tertiärem Gestein. Vorwiegend sind darauf die ackerbaulich günstigen Schwarzerden
entstanden. Auf Grund von Bodenabtragungen und -herabsetzung haben sich zudem
Pararendzinen gebildet. Anthropogen wurde die Bodenbildung durch den Bergbau stark
beeinflusst. Beispielsweise wurde der Oberboden beseitigt oder mit anderem Material
überkippt. Die unter solchen Vorraussetzungen entstehenden Böden besitzen einen
schlechten Nährstoff- und Wasserhaushalt (vgl. SCHWEFEL, S. 36). Die aufgeschüttete
Kalirückstandshalde westlich von Teutschenthal-Bahnhof führte zur Versalzung und somit
Herabstufung des Bodens und des Oberflächenwassers in ihrer Umgebung, so dass sich
3
ein Habitat für halophile und halotolerante Pflanzen entwickelte. Die Weitzke-Niederung
kann damit als eine für die Pflanzenwelt bedeutsame Binnensalzstelle angesehen werden
(vgl. RICHTER 2001, S. 137). Die Vegetation ist gekennzeichnet durch Quellerfluren,
Salzbinsen, Salzrasen und Schilfröhrichte. Zudem existieren „halobionte
Laufkäfer“ (SCHWEFEL 2010, S.37). Der im Zuge der Vernässung und Versalzung ist ein
einzigartiger Charakter geschaffen, der nach KOCH / STOTTMEISTER / THOMAE (2002,
S.109) dieses Geotop hinsichtlich der Mineralisation mit keinem anderen in Sachsen-
Anhalt vergleichbar mach. In Folge dessen erhielt das Gebiet 1976 den Status eines
Flächennaturdenkmals.
4
2 Projektmagagement
2.1 Projektplanung
Für eine erfolgreiche Projektplanung ist die Verwendung von Ablaufplänen, die den
gesamten Projektumfang erfassen, ein wichtiger Schritt den Überblick zu behalten. Die
Gliederung in Projektphasen und Teilziele, sowie die Angabe von sinnvollen
Bearbeitungszeiten helfen dem Team die aktuelle Situation bis in die einzelnen
Arbeitsgruppen nachzuvollziehen. Die Vorgabe von Meilensteinen als Abschluss von
Teilzielen muss stets bindend erfolgen um Verwirrung im Team und Ressourcenverlust
bei bereits geplanten Aufgaben zu minimieren. Die Verschiebung von Meilensteinen ist
möglich und zeigt im Gantt-Diagramm den direkten Einfluss auf das Gesamtprojekt. Wird
ein Ziel nicht rechtzeitig erreicht und gibt es keine Zeitpuffer zu anderen Aufgaben,
verlängert sich das gesamte Projekt. Abhängigkeiten zwischen den einzelnen
Arbeitspakten können durch Verknüpfungspfeile im Diagramm selbst angegeben werden.
(vgl. dazu GABRISCH 2011) Die Arbeitsplanung für das vorliegende Projekt ist in Abbildung
A1 im Anhang dargestellt und soll im Folgenden kurz beschrieben werden.
Das Arbeitspaket “Recherche” setzte sich zusammen aus der Suche und Selektion
relevanter historischer und aktueller topographischen Karten und ihrer Legenden, dem
Sammeln der dazugehörigen Metadaten sowie der Bestimmung des anzuwendenden
Referenzsystems.
Das Projektteam “Datenverarbeitung der Geodaten” beschäftigte sich mit den
Arbeitschritten Scannen der analogen Karten, Qualitätsverbesserung der Karten durch
Bildbearbeitung, Georeferenzierung sowie deren Dokumentation und Qualitätskontrolle.
Neben der Strukturierung der Daten in einem Desktop-GIS und der multitemporalen
Untersuchung ausgewählter Geoobjekte, wurden die Zeichenvorschriften und Signaturen
der verschiedenen Kartenwerke verglichen.
In der Phase “Datenverarbeitung der Metadaten” wurde der anzuwendende
Metadatenstandard festgelegt, ein Datenbankmodell aufgestellt, ein
anwendungsorientierte Oberfläche zur späteren Recherche designt und ein Admintool zur
Verwaltung der Datenbank gewählt.
Im Rahmen des GDI und des Geodatenviewers standen zu Beginn die Fragen, auf
welche bestehenden Systeme kann aufgebaut werden und wie können diese an die
projektspezifischen Anforderungen angepasst werden. Die Geo- und Metadaten wurden
auf einer gemeinsamen Ebene miteinander verbunden. Speicherort und -prinzip wurden
5
festgelegt, Zugangsberechtigungen und Sicherungsbedingungen sind aufgestellt worden
und ein Geodatenviewer wurde eingerichtet.
2.2 Risikomanagement
Teil der Projektplanung herkömmlicher Softwareprojekte ist das Risikomanagement. Für
das durchgeführte Projekt gelten aber andere Bewertungen der Risiken, da eigentliche
Schwerpunkte wie Personal, Finanzierung oder Outsourcing von Komponenten nur
bedingt zutreffen. In der folgenden Tabelle werden die „Top Ten Risiken“ für
Softwareprojekte auf das Projekt projiziert (vgl. ZIMMERMANN 2011).
Risiken Bewertung für das Projekt / durchgeführte Maßnahmen
Personelle Defizite - ausschlaggebend für den Erfolg des Projekts
- Bewertung der einzelnen Studenten nach Vorkenntnissen
- Einteilung in Teams nach Qualifizierung und Interesse
- Terminplanung mittels Milestone-System
unrealistische Termine und
Kostenvorgaben
- keine bindende Zielstellung, sondern Anpassung des erwarteten
Ergebnis an zeitliche Verpflichtung und Möglichkeiten der
Studenten
- keine Kostenvorgaben die direkt mit dem Projekt
zusammenhängen fester Abschlusstermin am Ende des
Semesters
- Terminplanung mittels Milestone-System
Entwicklung von falschen
Funktionen und Eigenschaften
- Risiko wurde durch wöchentliche Präsentationen und
Zielvorgaben minimiert
Entwicklung der falschen
Benutzerschnittstelle
- klare mündliche Anforderungen an die Benutzerschnittstelle,
aber keine schriftliche Spezifikation (Pflichtenheft, Lastenheft,
etc.)
über das Ziel hinausschießen - nicht von Belang, da die damit verbundenen Mehrkosten nur die
Arbeitszeit betreffen
- Risiko wurde durch wöchentliche Präsentationen minimiert
kontinuierliche
Anforderungsänderungen
- Anforderung während des gesamten Projekts eher statisch
Defizite bei extern gelieferten
Komponenten
- Nutzung verifizierter bzw. bereits verwendeter Schnittstellen
und Software (SQL und OpenLayers)
(wird fortgesetzt)
Tab. 1: Übersicht über die 10 wichtigsten Risiken eines (Quelle: angepasst nach ZIMMERMANN 2011)
6
Defizite bei extern erledigten
Aufträgen
- keine externen Aufträge
Defizite in Echtzeitleistung - Tests / Simulationen der Echtzeitleistung nur im geringen Maße
möglich
- durch standardisiertes Vorgehen eher unwahrscheinlich
Überfordern der Softwaretechnik - Maßnahmen / Grenzen Softwaretechnik bei weitem nicht
ausgeschöpft
Tab. 2: Übersicht über die 10 wichtigsten Risiken eines (Quelle: angepasst nach ZIMMERMANN 2011)
(Fortsetzung)
7
3 Datengrundlage
Die Grundlage für eine raum-zeitliche Analyse und Präsentation von
Flächennutzungsentwicklungen des Arbeitsraumes Teutschenthal-Bahnhof bilden
topographische Karten. Für die Erfassung anthropogener und natürlicher
Landschaftsveränderungen sind Karten des Maßstabs 1:25000 oder größer geeignet.
Dementspechend wurde eine Auswahl topographischer Karten im Maßstab 1:10000 und
1:25000 recherchiert, welche von historischen Karten aus dem Jahr 1817 bis zur aktuellen
Auflage der Digitalen Topographischen Karte des Jahres 2011 reicht. Gleichzeitig wurden
notwendige Metadaten zusammengestellt. Neben dem landschaftlichen Wandel des
Untersuchungsraum Teutschenthal kann so durch die Präsentation der Karten im
WebGIS gleichzeitig ein Wandel der kartographisch-topographischen Landesaufnahmen
dargestellt werden.
3.1 Topographische Karten des Gebiets Teutschenthal-Bahnhof
Die ältesten verwendeten topographischen Karten sind zwei Blätter des Deckerschen
Kartenwerks aus dem Jahr 1817. Die Aufnahmen des Kartenwerks erfolgten unter der
Leitung von F. v. Rau und C. v. Decker und wurden in den Jahren 1816 bis 1821 gefertigt.
Die Landschaft wird im Maßstab 1:25000 abgebildet und wurde vor allem durch
militärisches Personal annähernd einheitlich nach von Decker 1816 veröffentlichten
Grundlagen zum topographischen Aufnehmen vermessen (vgl. DECKER 1816, ZÖGNER
1981). Mit den Musterblättern des Jahres 1818 schuf Decker einen Ausgangspunkt für die
zukünftig gleichmäßige Verwendung von Zeichenvorschriften für Darstellungen in
topographischen Karten. Im Punkt Genauigkeit standen jedoch die Karten des
Deckerschen Kartenwerks den späteren Aufnahmen mit dem Messtisch nach − ein
Umstand, der vor allem bei der Georeferenzierung der im Projekt verwendeten Karten
deutlich wurde (siehe Abschnitt 4.3).
Auf Basis der durch Decker geschaffenen Vorschriften begann ab dem Jahr 1822 eine
Weiterentwicklung der preußischen Landesaufnahme unter Major v. Müffling. Ein
wesentlicher Genauigkeitsgewinn wurde durch die Aufnahme per Messtisch erzielt. Der
Übergang von kartesischen Koordinaten zu geographischen Karten zog einen Wechsel
des Blattschnitts von den Quadratmeilenblättern zu den Gradabteilungskarten mit sich.
Diese Größe des Blattschnitts ist bis heute für deutsche Karten im Maßstab 1:25000
erhalten geblieben (vgl. KRÜGER & SCHNADT 2000) Ab 1846 wurde die Darstellung des
Reliefs durch Schraffen durch äquidistante Höhenlinien abgelöst, ab 1872 die Angabe von
Längen in preußischen Ruthen und Dezimalfuß durch Meter (vgl. ebd.) Für das Gebiet
8
Teutschenthal-Bahnhof wurde das Urmesstischblatt von 1852 mit seinen Neuauflagen
1872 und 1895 genutzt. Bei der Neuaufnahme der preußischen Gebiete ab 1875 wurde
1927 offiziell auf den Bessel-Ellipsoiden umgestellt und damit auch die zuvor verwendete
Preußische Polyederprojektion durch Gauß-Krüger-Koordinaten ersetzt. Gleichzeitig
verwendete man nun als Nullmeridian Greenwich anstelle von Ferro. Die Messtischblätter
der Neuaufnahme liegen für Teutschenthal in den Ausgaben von 1903, 1912, 1919 und
1931 vor. (vgl. zu diesem Absatz VERLAG DES REICHAMTS FÜR LANDESAUFNAHME 1931)
Mit Gründung der DDR wurden die topographischen Aufnahmen weitgehend an
sowjetische Vorschriften angepasst. Somit wurden Änderungen des Ellipsoidbezugs,
Höhenbezugssystems, Blattschnittes und der Nomenklatur wirksam. Eine Besonderheit
stellte die Produktion von topographischen Karten in zwei verschiedenen Ausführungen
dar. Es wurden Karten hoher inhaltlicher und räumlicher Genauigkeit in der „Ausgabe
Staat“ (AS) gefertigt, die jedoch der Geheimhaltung unterlagen. Zur Veröffentlichung
bestimmt waren hingegen Karten der „Ausgabe für die Volkswirtschaft“ (AV), die jedoch
gezielte geometrische, sowie semantische Änderungen enthielten (vgl. KOCH 2006). Für
die Analyse und Präsentation im Projekt wurden zwei Ausgaben der AS aus den Jahren
1954 und 1986, sowie zwei Ausgaben der AV der Jahre 1970 und 1980 verwendet.
Als Zeitschnitte für den Zeitraum nach der Wiedervereinigung wurden die topographische
Karte des Jahres 1994 und die aktuelle Auflage der Digitalen topographischen Karte im
Maßstab 1:10000 und 1:25000 ausgewählt. In diesen finden wieder die Blattschnitte und
geodätischen Grundlagen der Zeit vor der DDR Kartographie Anwendung. Mit dem
Aufbau des Amtlichen Topographisch-Kartographischen Informationssystems (ATKIS)
wurden länderübergreifend gültige Richtlinien zur einheitlichen Erstellung und Gestaltung
digitaler und analoger topographischer Karten geschaffen.
Es wird deutlich, dass eine Vielzahl der bis heute genutzten kartographischen und
geodätischen Grundlagen bereits im 19. Jahrhundert erstellt wurde. Dazu können auch
die Signaturen zur Darstellung der Landschaftselemente gezählt werden. Ein Vergleich
dieser wird im Abschnitt 5.2 für die verschiedenen Kartenwerke gegeben.
3.2 Metadaten
Als Metadaten werden Informationen bezeichnet, die ein bestimmtes Objekt beschreiben.
Der Begriff ist dabei nicht nur auf digitale Daten beschränkt, sondern auf jede Art von
Daten. Beispiele sind unter anderem in Literaturverzeichnissen zu finden, wobei Angaben
wie Autor, Publikationsjahr, Verlag etc. ebenfalls als Metadaten verstanden werden
können. Die Hinterlegung von Metadaten ist nötig, um das Urheberrecht zu wahren oder
9
eine indizierte Suche von Daten über verschiedene Kategorien zu ermöglichen. Um eine
einheitliche Hinterlegung zu ermöglichen, existieren oftmals so genannte
Metadatenstandards, die Vorschriften über Syntax oder Semantik enthalten (s. Abschnitt
6.1).
Besonders relevant sind die sorgfältige Hinterlegung von Metadaten bei digitalen Daten,
die im Internet für jeden einsehbar sind. Ein bekannter Metadatenstandard für Daten im
Internet ist der Dublin Core Standard. Für die Sammlung der Metadaten für das
Kartenrecherchesystem über die Halde Teutschenthal wurde nach diesem speziell für
Geodaten festgelegten Standard vorgegangen. Während Informationen wie der Kartentitel
oder der Maßstab der Karte relativ klar ersichtlich sind, gestaltete sich zum Beispiel die
Frage nach der Lizenz komplizierter. Nicht jedes Kartenwerk hatte dazu eine Angabe auf
dem Kartenblatt verzeichnet. Außerdem war zu beachten, dass eventuell das
Urheberrecht bereits erloschen sein könnte. Dieses erlischt für Karten, wenn der letzte
Mitautor der Karte, bereits mindestens 70 Jahre verstorben ist. Da dies nicht endgültig
festzustellen ist und das Karteninformationssystem vorerst ausschließlich für Lehrzwecke
zur Verfügung steht, wurde auf jeweiligen Bezugsquellen und deren Lizenzrechte
verwiesen.
Eine Exel-Tabelle mit allen nach dem Dublin Core Standard für Geodaten ermittelten
Metadaten ist dieser Arbeit auf CD begefügt. (siehe metadaten_teutschenthal.xls)
10
4 Datenverarbeitung
4.1 Scannen analoger Karten
Bis auf die beiden digitalen topographischen Karten (DTK10 und DTK25) lagen alle
anderen Karten nur analog, das heißt in gedruckter Form, vor. Um sie in das
Karterecherchesystem integrieren zu können, mussten sie also gescannt werden. Für den
Kartenscan wurde der Rollenscanner des Instituts für Geowissenschaften und
Geographie der Martin-Luther-Universität Halle-Wittenberg genutzt.
Für optimale Ergebnisse muss eine gewisse Vorwärmzeit des Scanners eingehalten
werden. Danach kann jede Karte einzeln gescannt werden, wobei die Auflösung der
Scans vom Nutzer festzulegen ist. Für die Karten für das Gebiet um die Halde
Teutschenthal wurde eine Auflösung von 400 dpi (Dots per inch bzw. Bildpunkte pro Zoll)
gewählt. Auch die Farbtiefe des Scans ist vom Nutzer zu definieren. Hier wurde sich für
eine Tiefe von 24 bit entschieden, um eine möglichst hochwertige graphische Darstellung
am Bildschirm zu ermöglichen.
Problematisch am Kartenscan stellte sich die Qualität der in Papierform vorliegenden
Karten dar. Einige Karten, speziell jene aus dem 19. Jahrhundert, waren durch die lange
Lagerung im Archiv verzerrt oder rissig geworden, was sich negativ auf das Scanergebnis
auswirkte. Auch lässt die Druckqualität der älteren Karten im Laufe der Zeit nach, sodass
trotz der sehr guten Auflösung und Farbtiefe eine Unschärfe im gescannten Bild nicht zu
vermeiden war. Für den Fall, dass die Qualität einzelner gescannter Karten als nicht
ausreichend beurteilt wurde, konnte zum Teil auf Scans der Staatsbibliothek Berlin
zurückgegriffen werden.
4.2 Bildbearbeitung
Zur Korrektur oben beschriebener Qualitätsminderungen wurden die Scans
nachbearbeitet. Dabei wurde angestrebt eine mangelhafte Bildschärfe und nicht optimale
Gradiationskurven (schlechter Kontrast) zu reduzieren. Wird beim Scan das Kartenblatt in
einem jeweils leicht veränderten Winkel zugeführt, müssen die Karten durch
entsprechende Korrekturdrehung neu ausgerichtet werden. Die Entzerrung der Karten
erfolgt während der Georeferenzierung. Für die Bildverarbeitung können Programme wie
GIMP oder Adobe Photoshop verwendet werden.
Die Bildschärfe kann durch verschieden Filteroperationen verbessert werden. Neben dem
bekannten Gauß-Filter, können auch Funktionen zur Hervorhebung von Kanten den
optischen Eindruck einer gesteigerten Bildschärfe zur Folge haben (vgl. TÖNNIES 2005).
11
Der Kontrast kann durch die Anpassung des Gammawerts und durch die Bearbeitung der
Gradiationskurven deutlich verbessert werden. Beschädigungen der Karten können, je
nach Grad des Schadens, durch Retuschieren und Stempeln entfernt werden.
Verschmutzungen können durch partielle Korrektur der Belichtung oder durch
Regulierung der Farbkanalintensitäten minimiert werden. Einige dieser
Bearbeitungsschritte lassen sich automatisch auf mehrere Bilder anwenden (Batch-
Bearbeitung). Aber gerade die aufwändigen manuellen Schritte müssen einzeln und
angepasst mit jedem Bild durchgeführt werden (vgl. BURGER & BURGE 2006). Im
Folgenden sollen daher die Grundlagen der angewendeten Filter der Kartenverarbeitung
dargestellt werden. Dabei wird neben der exemplarischen Darstellung des Ergebnisses
auch die zugrunde liegende Funktionsweise erläutert. Für die Bearbeitung der Bilder
wurde „Adobe Photoshop CS5“ verwendet.
4.2.1 Analyse der verwendeten Filter
Tonwertkorrektur der Karten
Mit der Tonwertkorrektur können die Sättigung und der Kontrast des Bildes manipuliert
werden. Der Filter arbeitet auf dem Histogramm des gegebenen Bildes. Das Histogramm
beschreibt die Farb- bzw. Intensitätsverteilung innerhalb des Bildes. Es stellt dar, wie oft
ein bestimmter Farbwert im Bild vorkommt, also wie viele Pixel diesen Farbwert besitzen.
Es gibt zwei Verfahren, um über die Tonwertkorrektur die Eigenschaften des Bildes
anzupassen. Zum einen kann über die Tonwertspreizung die Verteilung der Farbtöne,
innerhalb des Histogramms, gestreckt oder gestaucht werden. Zum anderen kann der
Tonwertumfang (Wertebereich des Histogramms) geändert werden. Beispielsweise
können durch eine Verringerung des Wertebereichs bestimmte Farben bzw. Farbtöne aus
der Darstellung entfernt werden.
Die Änderung des Tonwertumfangs ist für unsere Zwecke nicht notwendig. Die
Tonwertspreizung hat jedoch einen direkten Einfluss auf die Wahrnehmung von
Sättigung und Kontrast. Je gleichmäßiger die Farbwerte im Histogramm verteilt sind,
desto höher ist der globale Kontrast im Bild.
Das verfügbare Kartenmaterial liegt in Form von Rasterbildern im RGB-Format vor.
Histogrammbasierte Verfahren können, gemäß der Definition, nur mit Rasterbildern
verwendet werden. Die Auftrennung der Bilddaten in die drei Farbkanäle (rot, grün, blau)
des RGB-Bildes überträgt sich auch auf die Darstellung des Histogramms. Hierbei wird für
jeden einzelnen Kanal ein Histogramm erstellt. Zusätzlich kann aus den drei einzelnen
Kanälen ein einziges Histogramm erstellt werden. Der Wertebereich ist genauso groß wie
12
der eines der gegebenen Kanäle. Der Wert entspricht der Addition der
korrespondierenden Werte aus den drei Ausgangskanälen. Diese Umrechnung entspricht
auch der Interpretation des RGB-Modells. Umso größer die Summe der drei Kanäle ist,
desto heller wirkt die resultierende Farbe, unabhängig von den zugrunde liegenden
Anteilen der einzelnen Kanäle. Die Histogrammspreizung kann, analog zu
Grauwertbildern, für jeden Kanal einzeln durchgeführt werden. (vgl. dazu MÖLLER 2009)
Scharfzeichnen der Karten
Der Eindruck von Schärfe kann durch verschiedene Eigenschaften erzeugt werden. Vor
allem klare Kanten und Umrisse lassen ein Bild scharf erscheinen. Die Schärfe hängt
auch direkt mit dem Kontrast eines Bildes zusammen. Je höher der Kontrast, desto höher
ist auch der Schärfeeindruck. Die Anpassung des Kontrasts kann über die
Tonwertspreizung erzwungen werden. Das Abgrenzen der Kanten wird durch das
Verfahren „Unschärfe maskieren“ realisiert.
Kurioser Weise liegen die Wurzeln dieser Technik in der analogen Fotographie. Ein
unscharfes Negativ kann „geschärft“ werden, indem man eine noch unschärfere Version
des ursprünglichen Negativs (Maske) erstellt. Legt man bei der Entwicklung beide
Negative übereinander, entsteht ein Foto mit einem höheren Schärfeeindruck.
In der Verarbeitung digitaler Bilder wird dieses Verfahren adaptiert. Hierbei wird aus dem
Originalbild eine unschärfere Version erstellt. Nun wird vom Originalbild die unscharfe
Version abgezogen. Die entstehende Differenz wird wieder auf das Original addiert.
Dadurch nimmt der Kontrast vor allem an den Kanten deutlich zu.
Für Bilder im RGB-Format wird das Verfahren auf jeden Kanal einzeln angewendet. Zu
bemerken bleibt, dass der angewendete Filter nur den Eindruck vermittelt ein schärferes
bzw. kontrastreicheres Bild zu liefern. Ein unscharfes Bild kann nicht nachträglich
Abb. 1: Anwendung der Tonwertspreizung im RGB-Raum mit dem vorgegeben Kartenmaterial;
Original(links); Resultat (rechts). (Quelle: eigene Darstellung - Philipp Bolz, Grundlage:
TK25 - 1986)
13
geschärft werden, aber der Eindruck einer höheren Schärfe kann erweckt werden. (vgl.
ebd.)
Rauschunterdrückung
Die Rauschunterdrückung ist ein aufwendiges Verfahren. Es gibt zwar naive Ansätze,
welche aber fehlerbehaftete Ergebnisse liefern. Auf der anderen Seite gibt es effektive
Ansätze, die aber nicht intuitiv erfassbar sind.
Bei den naiven Verfahren wird eine kleine Maske, die ein eindeutiges Zentrum besitzt
(meist 3x3 oder 9x9), über jeden Pixel des Bildes geschoben. Das Zentrum der Maske
liegt auf dem aktuellen Pixel. Es gibt verschiedene Filter, die über solche Masken
realisiert werden.
- Mittelwertfilter: Alle Pixelwerte innerhalb der Maske werden addiert und durch die
Anzahl der Pixel geteilt. Der Filter berechnet den Mittelwert innerhalb der Maske.
Im RGB-Farbraum wird der Mittelwert für jeden der drei Kanäle einzeln bestimmt.
- Medianfilter: Alle Pixel innerhalb der Maske werden in einer Liste sortiert. Das
mittlere Element der Liste entspricht dem Ergebnis des Medianfilters. Für eine
Übertragung des Verfahrens in das RGB-Farbmodell werden die einzelnen
Farbwerte nach der euklidischen Distanz (entspricht der Entfernung zum
Koordinatenursprung) sortiert. Dies ist möglich, da das RGB-Farbmodell einen
dreidimensionalen Raum aufspannt.
- Minimum- und Maximumfilter: Analog zum Medianfilter werden die Pixelwerte
sortiert. Aus der Liste wird der minimale bzw. maximale Wert, als Ergebnis des
Filters, ausgewählt. Die Übertragung in den RGB-Farbraum ist analog zum
Medianfilter.
Abb. 2: Anwendung des Filters „Unschärfe maskieren“ im RGB-Raum mit dem vorgegeben
Kartenmaterial; Original (links); Resultat (rechts). (Quelle: eigene Darstellung - Philipp Bolz,
Grundlage: TK25 - 1986)
14
Dem aktuellen Pixel wird das Ergebnis des jeweiligen Filters zugeordnet. Die gefilterten
Bilder werden dabei entweder unscharf (Mittelwertfilter) oder das Bild wirkt mosaikartig,
da größere Bereiche mit dem gleichen Farbwert entstehen (Median-, Minimum- und
Maximumfilter). (vgl. dazu BRUDER 2002)
Manuelle Bildverarbeitung
Beim Einscannen des analogen Kartenmaterials, entstanden Fehlinformationen, die
nachträglich entfernt werden sollten. Dazu gehört der deutlich zu erkennende, blaue
Strich auf jeder der eingescannten Karten. Auf den schwarz-weißen Karten gestaltet sich
das Entfernen eher einfach (TK10 - 1970, TK25 - 1852). Dafür wird ein Referenzpixel
innerhalb des blauen Strichs gewählt. Das Programm berechnet nun automatisch über
eine festgelegte Toleranz die Auswahl (vgl. Abb. 3, links). Um das Ergebnis zu
verbessern, wird die Auswahl manuell auf einen kleinen Bereich um den blauen Strich
reduziert (vgl. Abb. 3, rechts). Abschließend wird die Auswahl mit weißen Pixeln gefüllt.
Abb. 3: Entfernen der durch Scannen entstandenen Fehlinformationen (blauer Strich); Original
(links); Resultat (rechts). (Quelle: eigene Darstellung - Philipp Bolz, Grundlage:TK10-1970)
Abb. 4: Automatisierte Auswahl über Referenzpixel (links); manuell verbesserte Auswahl (rechts).
(Quelle: eigene Darstellung - Philipp Bolz)
15
Für die farbigen Karten bzw. die Karten deren Hintergrund stark von weiß abweicht, ist die
Bearbeitung geringfügig aufwendiger (TK25 - 1912, TK25 - 1931, TK25 - 1954, TK10 -
1980, TK25 - 1986, TK10 - 1994). Das Vorgehen ist analog zu den schwarz-weißen
Karten, nur dass die Auswahl nicht mit weißen Pixeln gefüllt werden kann. Der Farbton
und die Sättigung innerhalb der Auswahl muss manuell angepasst werden. Das Ergebnis
ist deutlich schlechter, da immer noch ein blassblauer Strich zurückbleibt. Zusätzlich wirkt
sich die automatisierte Auswahl nicht auf Bereiche aus, deren Farbwerte nah am
gewählten Referenzpixel liegen (vgl. Abb. 5 rechts).
4.3 Georeferenzierung
Beim Georeferenzieren werden einem Datensatz raumbezogene Informationen
(Georeferenzen) zugewiesen. Dies kann auf drei verschiedene Varianten und für
unterschiedliche Zwecke erfolgen. Die erste Möglichkeit wäre eine Einpassung von Daten
in ein geodätisches Referenzsystem vorzunehmen. Diesen Schritt bezeichnet man als
Geokodierung. Desweiteren kann eine Rektifizierung erfolgen, bei der geometrische
Verzerrungen eliminiert werden. Als dritte Option ergibt sich die Transformation. Dazu
werden zwei ungleich skalierte Datensätze aneinander angepasst. Zudem müssen
verschiedene Arten der Geokodierung unterschieden werden:
• Adresskodierung � Zuweisung einer Postanschrift
• Geokodierung � Zuweisung einer Koordinate
• Kartenkalibrierung � Zuweisung einer Transformation
• Entzerrung � Anwendung einer Transformation.
Abb. 5 Entfernen der durch Scannen entstandenen Fehlinformationen (blauer Strich) in farbiger
Karte; Original (links); Resultat (rechts). (Quelle: eigene Darstellung - Philipp Bolz,
Grundlage: TK25 - 1986)
16
Es ist schwierig eine Systematik und genaue Definition für das Wort
„Georeferenzierung“ zu finden, da der Begriff uneinheitlich und teils widersprüchlich in der
Literatur verwendet wird (vgl. BILL 2012).
Im Projekt wurden zunächst alle zur Verfügung stehenden Karten objektbezogen auf die
DTK25 bzw. DTK10 aus dem Jahre 2011 georeferenziert. Diese lagen im Gauß-Krüger-
Koordinatensystem in der Zone 4 des Deutschen Hauptdreiecksnetzes (DHDN 3) vor.
Hierzu mussten auf jeder Karte Passpunkte gefunden werden, die mit der Karte von 2011
übereinstimmen. Bei der Auswahl von Passpunkten ist von Bedeutung, dass diese
eindeutig in ihrer Lage bestimmbar sind – sprich, eine hohe Lagegenauigkeit besitzen.
Deswegen eignen sich Symboliken (wie z.B. das Kreuz für Kirchen) als auch sich ständig
ändernde Ausprägungen (wie z.B. Randlinien von Gewässern) meist nicht für eine
Referenzierung (vgl. Abb. 6).
Bei Straßen, Wegen oder Bahnlinien ist darauf zu achten, dass die Mitte den exakten
Lagebezug darstellt, da sie in Karten häufiger bereiter als in der Realität dargestellt
werden. Dagegen eignen sich Höhenpunkte sehr gut für eine exakte Lagebestimmung.
Doch auch hier sind Grenzen gesetzt. Vor allem in älteren historischen Karten sind diese
entweder gar nicht oder mit inexakten Höhenangaben verzeichnet. Außerdem kann es
auch auftreten, dass Höhenpunkte über die Zeit eliminiert bzw. neue vermessen wurden.
So konnten bei jüngeren Karten relativ zügig Passpunkte ermittelt werden. Es eigneten
sich vorwiegend Höhenpunkte, Wegkreuzungen oder Zugtrassen. Bei den älteren,
historischen Karten, insbesondere dem Deckersche Kartenwerk und den Preußische
Urmesstischblättern, ergaben sich Schwierigkeiten für eine exakte Passpunktefindung.
Zum einen aus den im oberen Absatz geschilderten Problemen, zum anderen gab es
gerade größere Straßen und Bahnlinien zu dieser Zeit noch nicht. Desweiteren wurden
keine Höhepunkte eingetragen und die Aufnahmen, besonders im Deckerschen
Kartenwerk, waren eher skizzenhaft, was sich auf die Lagegenauigkeit auswirkte. Deshalb
konnten nur markante und seit Jahrhunderten bestehende Wegkreuzungen als
Passpunkte fixiert werden.
Abb. 6: Vergleich von Symboliken und sich ändernden Ausprägungen als ungeeignete
Passpunkte. (Quelle v.l.n.r.: TK25 - 1903, TK25 - 1954, TK25 - 1986, DTK10 - 2011)
17
Damit die zu referenzierende Karte nicht an bestimmten Stellen verzerrt und in anderen
Bereichen sehr genau ist, wurden die Passpunkte verteilt über die Gesamtkarte gesetzt,
sofern es die Ausgangskarte zuließ (vgl. Abb. 7).
Ein weiterer grundlegender Schritt im Rahmen der Georeferenzierung war die Wahl eines
geeigneten Referenzsystems. Nachdem alle historischen Karten auf die in “DHDN 3”
(EPSG:31468) vorliegende DTK25 - 2011 georeferenziert wurden, erfolgte die
Transformation aller Karten in des geographische Koordinatensystem „WGS84”
(EPSG:4326). Die Entscheidung für dieses Referenzsystem wurde aus mehreren
Gründen getroffen. Durch die geplante Einbindung der Karten in einen Kartenviewer
wurde dieses System gewählt, da die dort ebenfalls implementierten Geodatendienste
(z.B GoogleMaps, OpenStreetMap) mit WGS84 arbeiten, bzw. damit kompatibel sind.
Damit entspricht dieses Format auch dem aktuellen internationalen Quasi-Standard, der
u.a. bei der Arbeit mit GPS-Daten genutzt wird (vgl. NIMA 2000). Ebenso ist diese
Entscheidung in Hinblick auf die Kompatibilität mit bereits vorhandenen übergeordneten
Projektdaten getroffen wurden.
Abb. 7: Beispiel einer Passpunktsetzung (Quelle: eigene Darstellung - Kristian Möller, Grundlage:
TK10 - 1980 auf DTK10 - 2011)
18
Zusammenfassend ist für die Georeferenzierung festzuhalten, dass gerade ältere,
historische Karten, bis etwa Anfang des 20. Jahrhunderts, recht schwierig zu
referenzieren waren. Dies hat letztendlich Konsequenzen auf die Lagegenauigkeit dieser
Karten. Jüngere Werke ließen sich dagegen sehr gut referenzieren und erweisen eine
sehr hohe Deckungsgenauigkeit.
19
5 Datenauswertung
Neben schriftlichen Aufzeichnungen und mündlichen Überlieferungen stellen historische
Karten ein wertvolles Mittel dar, um sowohl natürliche, als auch sozioökonomische
Prozesse einer Region nachzuvollziehen. Die Karten dokumentieren hierbei für bestimmte
Zeitschnitte einen Landschaftsausschnitt. In den nachfolgenden beiden Abschnitten soll
der aufgezeichnete Landschaftswandel bei Teutschenthal-Bahnhof beschrieben, sowie
die Vergleichbarkeit der verschiedenen genutzten Kartenwerke abgeschätzt werden.
5.1 Landschaftswandel in den Gebieten um Teutschenthal-Bahnhof
Die Landschaft unterliegt einem ständigen Wandel, nicht zuletzt durch die Besiedlung
durch den Menschen. Schon in frühesten Zeiten strebten die Menschen nach
Sesshaftigkeit, welche mit einer Ausdehnung der Agrarflächen einherging. Vor allem mit
dem Beginn des Bergbaus im Mansfelder Land wurde das Areal um Teutschenthal bis
Eisleben langfristig beeinflusst. Neben dem Kupferschieferbergbau sind vor allem noch
der Braunkohlebergbau und die Gewinnung von Kalisalzen zu nennen. Die Lage der
Schächte und Gruben sind durch historische Karten nachvollziehbar.
Durch die Erfindung der Dampfmaschine wurden neben dem Bergbau auch das
Maschinenwesen, und der Transport über Eisenbahnen revolutioniert. Schienen wurden
verlegt und das Straßennetz erweitert. Die zunehmende Bevölkerung wanderte in große
Städte, von denen viele heute noch durch ihren Namen (z.B. –hall) von der enormen
Bedeutung des Bergbaus zeugen. Seen und Feuchtgebiete wurden trocken gelegt und
Abb. 8: Kupferstich eines Schachts mit Förderkorb.
(Quelle: http://www.mansfelder-seen.de/pict/Berg2.jpg)
20
Wälder gerodet, um Platz für neue Siedlungen und Ackerland zu schaffen. Das wohl
bekannteste Beispiel ist die Trockenlegung des Salzigen Sees. Nach Versiegen der
Rohstoffe Mitte bis Ende des 20.Jhs. wurden die Schächte geschlossen. Die Schutthalden
bilden heute, neben den Stadtnamen, die letzten Zeugen des damaligen Bergbaus.
Die Aufgabe bestand darin, anhand von historischen Karten den Landschafts- und
Strukturwandel über die Veränderung ausgewählter Landschaftselemente zu zeigen. Die
Auswahl wurde beschränkt auf Gewässer, Feuchtgebiete und Wälder. Der betrachtete
Zeitraum liegt zwischen 1817 und 2011. In diesem Abschnitt soll der Wandel nur anhand
von diesen 3 Beispielen erläutert werden. Die detaillierte Darstellung findet sich im
Anhang.
Anhand der Tabelle A1 im Anhang lässt sich die Veränderung der Größe und der Lage
der Gewässer nachvollziehen. Durch Kalibergbau wurden Dränagen gelegt, um das
Gebiet zu entwässern. Aufgrund dieser Eingriffe fand in der Seen- und Weiherlandschaft
ein massiver Wandel statt. Ob die Seen natürlichen Ursprungs sind lässt sich anhand der
historischen Karten nicht nachvollziehen. Jedoch wird vermutet, dass die vorhandenen
trockengelegt und teilweise durch neue kleinere, künstliche Gewässer abgelöst wurden.
Die Kartengrundlage bildet ein Luftbildaufnahme von GoogleMaps.
Die Veränderungen in der Ausbreitung der Feuchtwiesen bzw. Vernässungsflächen sind
ebenfalls im Wandel der Flächennutzung des Gebiets begründet (s. Tab. A2 im Anhang).
Vor allem anthropogene Eingriffe wie der Abbau von Rohstoffen im Tage- und Bergbau
(v.a. Braunkohle, Kalisalz, Ton) und der Bau der Bundesstraße B80 haben sich auf die
Entwässerung des Gebiets ausgewirkt. Teile der Feuchtflächen bildeten sich an
ehemaligen Tagebaurestlöchern, die sich zunehmend mit Wasser gefüllt haben. Die
größte Vernässungsfläche ist in der Weitzschke-Niederung zu finden. Sie wurde historisch
im Wesentlichen durch die Entwässerungsstollen und Drainagegräben des Bergbaus
Abb. 9: Teutschenthaler Halde. (Quelle: http://img.fotocommunity.com/
photos/17389482.jpg)
21
gespeist. Der hohe Salzgehalt des Wassers der Fläche zeigt, dass heute auch ein Eintrag
von Sickerwässern der Kalirückstandshalde erfolgt. Zwar wurde die Feuchtwiese durch
den Bau der B80 im Jahr 1980 durchschnitten, dennoch kam es zu einer weiteren
Ausbreitung der vernässten Flächen nördlich der Straße (vgl. SCHWEFEL 2010, S. 70).
Anhand der Tabelle A2 im Anhang ist der Wandel der Feuchtwiesen ersichtlich. Die
Kartengrundlage bildet die DTK10 von 2011.
Weiterhin lässt sich der Landschaftswandel an dem Rückgang der Wälder um
Teutschenthal belegen (s. Tab. A3 im Anhang). Zu Beginn des 19. Jh. erstreckten sich
weitgestreckte, zusammenhängende Laubwälder in unserem Gebiet. Schon Mitte des 19.
Jhs. wurden diese zum Großteil abgeholzt, vermutlich durch die Ausdehnung des
Bergbaus und Erschließung von neuer Acker- und Siedlungsfläche. Heute sind nur noch
wenige größere Waldflächen zu finden. Jedoch nimmt der Anteil an künstlich angelegten
Gehölzen zu, z.B. als Alleebäumen an Straßen. Hier wurde als Kartengrundlage die TK10
von 1994 gewählt.
5.2 Vergleich der Kartenlegenden
Die verwendeten Legenden reichen von analogen historischen Karten (aus dem Jahr
1817) bis hin zu digitalen topographischen Karten (von 2011). Anhand dessen können die
Signaturen der einzelnen Karten im Laufe der Zeit verglichen werden. Legenden sich
wichtig, um Karten interpretieren zu können. Somit war es erforderlich zu den einzelnen
Kartenblättern entsprechende Legenden herauszusuchen. Dabei war es schwer zu jeder
Karte die exakte Legende zu finden. Somit gibt es mehrere Karten, für die es eine
Legende gibt. Welche Legende für welche Karte existiert ist in der nachfolgenden Tabelle
2 dargestellt.
Karte Jahr dazugehörige Legende Karte Jahr dazugehörige Legende
TK25 1817 TK10 1970
TK25 1852
TK25 1872
TK25 1895
Musterblätter des Deckerschen Kartenwerks und der Urnesstischblätter
TK10 1980
Zeichenerklärung für Ausgabe Volkswirtschaft
TK25 1903 TK10 1994 Legende von TK10 1994
TK25 1912 DTK10 2011 Legende von DTK10 2011
TK25 1919 TK25 1931
Legende der Messtischblätter
TK25 1954
TK25 1986
Zeichenerklärung für Ausgabe Staat
DTK25 2011 Legende von DTK25 2011
Tab. 2: Karten und deren dazugehörigen Legenden (Quelle: eigene Darstellung - Maria Herbig)
22
Die Veränderungen der Legendenvorschriften soll an drei Beispielen veranschaulicht
werden. Die Zeichenvorschriften unterliegen der Entwicklung der Kartographie und
wurden somit häufigen Veränderungen unterzogen (vgl. KOHLSTOCK 2004). Die
Veränderung von Zeichenvorschriften und Landschaftswandel in historischen und
aktuellen Karten sollen an dem Beispiel für die Signatur “Grube” bzw. “Böschung” am
Beispiel der “Hölle” bei Teutschenthal-Bahnhof (vgl. Tab. A4 im Anhang), der Signatur
“Kirche” am Beispiel der Kirche in Köchstedt (vgl. Tab. A5 im Anhang) und der Signatur
“Landstraße” (vgl. Tab. A6 im Anhang) gezeigt werden. Anhand des Vergleiches der
Signaturen wird deutlich, dass die Legendensymbole vom Urmesstischblatt bis heute in
ähnlicher Form bestehen. Diese Karten wurden nach einem einheitlichen
Zeichenschlüssel des preußischen Generalstabes gezeichnet, allerdings führten
unterschiedliche Bearbeiter (Zeichner der Karte) zu unterschiedlichen Farbintensitäten
und Qualitäten der Karte. Diese eigene Note des Kartenzeichners verschwand dann mehr
und mehr aus der Kartographie, bis zu dem Zeitpunkt, wo es zum Einsatz von PC-
gestützten Zeichenprogrammen gekommen ist. Dadurch wurden die Karten immer
präziser, allerdings geht dabei der Charme und die persönliche Handschrift des
Bearbeiters verloren. Die Komplexität der Karten und damit Legenden hat in den letzten
Jahren stark zugenommen, was eine Zeichnung per Hand gar nicht mehr zulassen würde.
Beispielsweise wird bei den Straßen zwischen Autobahn, Bundesstraße mit Brücke,
Landstraße, Kreis- oder Gemeindestraße und Wege unterschieden. Zudem kommen noch
Informationen über die unterschiedlichen Breiten und Fahrbahnspuren. Im
Urmesstischblatt gab es auch eine Vielzahl an verschiedenen Verkehrswegarten, jedoch
gab es keine Unterscheidung der Breite. Die Differenzierung erfolgte vielmehr über die
Beschaffenheit, wie zum Beispiel Kies Chaussee, Stein Chaussee, Landstraße,
bleibender Verbindungsweg oder Feldweg, Veränderlicher Weg durch Heide, Holz und
Felder, oder Fussweg. Diese voranschreitende Komplexität ist anhand der Legenden zu
sehen, deshalb ist das Vorhandensein von ihnen auch wichtig, um Karten eindeutig lesen
zu können.
23
6 Metadatenbank
Wie bereits beschrieben, werden unter dem Begriff “Metadaten” im Allgemeinen Daten
verstanden, die Informationen über andere Daten vermitteln. Sie haben beschreibenden
bzw. erklärenden Charakter und geben Aufschluss über die Eigenschaften ihrer Zieldaten.
Im Kontext geografischer Informationssysteme spricht man in diesem Sinne auch von
raumbezogenen Metadaten, da diese Informationen über raumbezogene Objekte wie
Geodaten liefern. Im Falle von Geodaten haben Metadaten insbesondere die Aufgabe,
einen zeitlichen Bezug zu den räumlich gearteten Geodaten zu liefern und damit eine
zeitliche Einordnung zu liefern. Aber auch andere Informationen wie Inhalt, Autor oder
Veröffentlichungsdatum sind oft Bestandteil solcher Metadaten.
Zu Beginn des Projektes war es zunächst notwendig, sich darüber klar zu werden, welche
Metadaten zur Beschreibung der historischen Karten der Umgebung von Teutschenthal
gesammelt und gespeichert werden sollten. Natürlich gibt es eine Vielzahl an
Informationen und Daten, die für eine Beschreibung in Frage kämen, allerdings bedeutet
eine große Anzahl an Metadaten auch einen großen Rechercheaufwand. Ein erster
Schritt musste also die Festlegung eines einheitlichen Metadatenstandards sein. Als
Metadatenstandard bezeichnet man die Menge der Metadateninformationen zur
Beschreibung von Daten, die im Folgenden auch als Attribute bezeichnet werden.
6.1 Metadatenstandards
Um der Vielzahl unterschiedlicher Möglichkeiten zur Beschreibung von Geodaten zu
entgegnen und diese zu vereinheitlichen, wurden verschiedene Standards und Normen
geschaffen. Diese beschreiben die Art und Weise, wie Geodaten durch Metadaten
beschrieben werden und legen insbesondere fest, welche Informationen zur
Beschreibung genutzt werden. Überdies beschreiben Standards auch das Format der
Metadaten sowie die Art und Weise, wie einzelne Elemente miteinander in Verbindung
stehen. Je nach Standard kann sich die Anzahl dieser Attribute sehr stark unterscheiden.
Von diesen sollen im Folgenden einige, die für das Projekt in Frage kamen, näher
beschrieben werden.
ISO 19115
Einen Versuch zur internationalen Normierung von Geoinformation und Geodaten ist der
ISO 19115. Er beschreibt einen Standard zur einheitlichen Beschreibung geografischer
Informationen, mit der es möglich sein sollte, Geodaten anhand einer Reihe von
Metadatenattributen zu beschreiben. Teil der ISO 19115 sind 409 Metadatenfelder, die in
24
einem relationalen Verhältnis miteinander in Verbindung stehen. Es handelt sich also um
einen vergleichsweise komplexen Standard zur Beschreibung unterschiedlichster Arten
von Geodaten.
Die Vorteile dieses Standards liegen in seiner internationalen Verbreitung und der damit
verbundenen Kompatibilität zu anderen GIS. Weiterhin ist der ISO-Standard sehr
ausführlich und komplex, wodurch eine Reihe unterschiedlichster Geodaten beschrieben
werden könnten. Diese Komplexität wirkt sich jedoch auch nachteilig aus, da die
Recherche so vieler Informationen weit mehr Aufwand bedeutet und im Falle unseres
Projektes nicht zielführend ist. Aus Gründen der Einfachheit wurde beschlossen, den ISO
19115 Standard nicht zu verwenden.
GSDGM
Ein vorwiegend in den USA weit verbreiteter Standard ist der „Content Standard for Digital
Geospatial Metadata“, kurz GSDGM, des US-amerikanischen Federal Geographic Data
Committee. Dieser definiert neben einer Reihe von Attributen zur Beschreibung
raumbezogener Objekte auch den Aufbau der möglichen Werte dieser Attribute, wie etwa
das Format von Datums- oder Koordinatenangaben über das Konzept kontextfreier
Grammatiken.
Auch dieser Standard ist recht umfangreich und enthält eine große Menge optionaler und
verbindlicher Attribute, was die gleichen Nachteile mit sich bringt, wie zuvor bereits der
ISO 19115.
Zusätzlich dazu fehlt in diesem Standard eine konkrete Beschreibung des Datenformats,
wie etwa ein XML-Schema, was einen Austausch der Metadaten erschwert. Da der
GSDGM zudem nicht international verabschiedet wurde und größtenteils in den USA
benutzt wird, kam auch dieser Standard nicht für die Metadatenerfassung nicht in Frage.
DCLite4G
Der „Dublin Core Lightweight Profile for Geospatial“ Standard ist eine Ausprägung des
Dublin-Core Metadaten Standards speziell für Geodaten. Vorteilhaft an diesem Standard
ist sein sogenanntes "Minimal Information Model", welches aus gerade einmal 13
verpflichtenden und 4 optionalen Attribute besteht und damit den kleinsten gemeinsamen
Nenner aller Metadatenstandards darstellt. Zusätzlich dazu existiert im Dublin-Core
Standard die Möglichkeit, mit Hilfe sogenannter Namensräume (Namespaces) weitere
Attribute zur Beschreibung von Geodaten zu definieren.
Aufgrund der Einfachheit des Informationsmodells fiel die Entscheidung für dieses
Schema aus. Die Beschreibung der festgelegten 17 Felder befindet sich als Tabelle A7 im
25
Anhang. Die Namen der Felder sowie die Beschreibungen sind selbst getroffene
sinngemäße Übersetzungen und weichen daher möglicherweise von der
Standardbezeichnung ab.
Zusätzlich zu diesen Attributen ist die Möglichkeit zur Angabe von Legenden und deren
Textinhalt vorgesehen, um später eine Möglichkeit zum An- und Abschalten der Legenden
sowie einer Möglichkeit zur Suche im Legendentext zu haben.
Zu den 17 Attributen des DCLite4G kommen also nochmals zwei hinzu, wodurch die
Metadaten 19 Attribute umfassen. Die Tatsache, dass die resultierende Tabelle insgesamt
26 Spalten besitzt, liegt daran, dass diverse Zusatzinformationen gespeichert werden
müssen, die beispielsweise für das Zusammenspiel zwischen Metadatenbank und Geo-
Server benötigt werden.
Mit dem DCLite4G wurde ein Metadatenstandard gefunden, der mit seinen 17 Attributen
ein sehr schlanker und minimalistischer Standard ist und durch das Hinzufügen zweier
weiterer Attribute auf unsere Bedürfnisse angepasst ist. Die insgesamt 19 Attribute stellen
dabei eine solide Basis zur Beschreibung historischer Karten dar und erfordern
gleichzeitig eine beherrschbare Recherchearbeit.
6.2 Datenbankentwurf
Der Entwurf einer Datenbank setzt sich aus drei aufeinanderfolgenden Teilschritten
zusammen. Zunächst wird ein sogenanntes Entity-Relationship-Modell (ER-Modell)
erstellt. Dieses wird anschließend in das Relationale-Modell übersetzt, was wiederum die
Ausgangsposition für den letzten Schritt darstellt: Die Formulierung der Anweisungen zum
Anlegen der einzelnen Tabellen in der Datenbankanfragesprache SQL. Die so
formulierten Anweisungen können dann problemlos in ein bestehendes SQL-
Datenbanksystem eingegeben werden und die notwendigen Tabellen werden automatisch
erzeugt.
ER-Modell
Generell kann der Entwurf des ER-Modells durchaus als der anspruchsvollste Teil des
Datenbankentwurfs bezeichnet werden. Im Allgemeinen müssen Sachverhalte und
Informationen zunächst auf Objektgruppen bzw. Klassen (Entities) und deren
Beziehungen untereinander (Relationships) heruntergebrochen werden. Bei größeren
Projekten erfordert dieser Schritt ein gewisses Maß an Erfahrung.
26
Da die Metadatenbank für dieses Projekt jedoch von der Komplexität her vergleichsweise
überschaubar war, verlief der Entwurf des ER-Modells zügig und ohne Probleme. Die
folgende Abbildung zeigt das ER-Modell in der Notation des Oracle Designers.
Wie in Abbildung 10 dargestellt ist, sind für die Umsetzung dieses Projektes lediglich zwei
Klassen und eine Beziehung erforderlich. Die Objektklassen sind zum einen die
Metainformationen zu den Karten (Metadata) und zum anderen die Schlüsselwörter
(Keyword), die den Karten zugeordnet sind. Die Schlüsselwörter lassen sich dabei nicht
einfach mit den anderen Metainformationen zusammenfassen, da die resultierende
Datenbank nicht den Ansprüchen der Normalisierung gerecht werden würde. Ziel der
Normalisierung ist die Vermeidung von Datenredundanzen, welche spätestens während
des Betriebs der Datenbank ungewünschte Konsequenzen mit sich bringen würden. In
erster Linie ist das Risiko groß, dass redundant gespeicherte Informationen durch
Änderungen inkonsistent werden, was zu einem ungültigen Datenbankzustand führt. Bei
der Normalisierung gibt es mehrere sogenannte Normalformen, die eine Datenbank
erfüllen kann. Sie sind hierarchisch aufgebaut – erfüllt eine Datenbank also eine
Normalform höherer Ordnung, so erfüllt sie ebenfalls alle darunter liegenden
Normalformen. Würden im konkreten Fall also die Schlüsselwörter direkt in die Klasse der
Metadaten mit aufgenommen werden, so würde die Tabelle bereits die Anforderungen für
Abb. 10: ER-Modell der Metadatenbank. (Quelle: eigene Darstellung)
27
die erste Normalform nicht mehr erfüllen. Diese schreibt vor, dass sämtliche Attribute (die
Spalten der späteren Tabelle) atomar sein müssen. Weil zu einer Karte jedoch im
Regelfall mehrere Schlüsselwörter in der Datenbank hinterlegt werden, müssten diese
konsequenterweise als Menge in einem einzelnen Attribut gespeichert werden – etwa in
einer durch Komma getrennten Liste. Eine solche Liste ist jedoch offensichtlich nicht
atomar.
Aus diesem Grund müssen die Schlüsselwörter getrennt erfasst werden. Die beiden
Klassen Keyword und Metadata sind durch eine sogenannte Viele-zu-viele-Beziehung
miteinander verbunden. Genauer gesagt, stehen die Zeilen der Tabelle der
Schlüsselwörter mit den Zeilen der Tabelle der restlichen Metadaten in dieser Beziehung
zueinander. Im Detail bedeutet dies nichts weiter, als das jeder Karte (Zeile in der Tabelle
Metadata) mehrere Schlüsselwörter (Zeilen in der Tabelle Keywords) zugeordnet sein
können. Ebenso kann natürlich auch ein und dasselbe Schlüsselwort mehreren
verschiedenen Karten zugeordnet sein. Im ER-Modell ist dies an den Krähenfüßen auf
beiden Seiten der Relation erkennbar.
Im Inneren der beiden Klassen finden sich die Attribute wieder. Im Fall der Klasse
Metadata, sind das unter anderem die bekannten Attribute des gewählten
Metadatenstandards. Hinzu kommen einige Attribute, die für die spätere Zusammenarbeit
mit dem Geo-Server notwendig sind. Dabei lässt sich an der Notation bereits erkennen,
welche Attribute notwendig sind (*), welche optional sind (O) und welches Attribut später
den Schlüssel der Tabelle darstellt (#).
Relationales-Modell
Mit dem fertigen ER-Modell ist der erste Schritt des Datenbankentwurfs abgeschlossen.
Der zweite Schritt ist nun die Übersetzung des ER-Modells in das Relationale-Modell. In
diesem Schritt werden aus den Klassen und Beziehungen des ER-Modells Tabellen
erstellt, wie sie später auch in der Datenbank vorhanden sein werden. Dieser Schritt ist
notwendig, da eine Datenbank nur Tabellen kennt und keine Relationen.
Bei der Übersetzung ins Relationale-Modell bietet sich stets an, immer mit den Klassen
des ER-Modells anzufangen, da jede Klasse in der Regel einfach in eine Tabelle
übersetzt werden kann. Dabei bilden die Attribute der Klasse die Spalten der Tabelle.
Etwas mehr Arbeit erfordert die Übersetzung der Relationen. Hier gilt jedoch grundsätzlich,
dass für eine Viele-zu-viele-Beziehung wie sie hier vorliegt, immer eine sogenannte
Verknüpfungstabelle (Join-Table) angelegt werden muss. Diese Tabelle speichert also
explizit die Zuordnung der einzelnen Schlüsselwörter zu den Karten. Dies geschieht ganz
28
einfach durch die Verwendung eines sogenannten Fremdschlüssels. Ein Fremdschlüssel
ist ein Verweis auf den Schlüssel einer anderen Tabelle. Konkret bedeutet dies, dass in
der Verknüpfungstabelle eine Spalte existiert, in der nur Werte stehen dürfen, die auch in
der Spalte ID der Metadaten-Tabelle vorkommen. So wird garantiert, dass jedes
eingetragene Schlüsselwort einer Karte zugeordnet ist, die auch tatsächlich existiert. Die
dafür notwendigen Kontrollen werden vom Datenbanksystem automatisch durchgeführt.
Insgesamt verlief die Überführung des ER-Modells ins Relationale-Modell für dieses
Projekt ohne Probleme. Das Resultat lässt erkennen, dass lediglich zwei Tabellen
notwendig sind, um alle Informationen speichern zu können.
Die Notation des Relationalen-Modells ist schnell beschrieben und in Abbildung 11
dargestellt. Jeder Eintrag beschreibt eine Tabelle der Datenbank. Die einzelnen Einträge
beginnen mit dem Namen der Tabelle (fettgedruckt), gefolgt von den einzelnen Spalten.
Diese können vollständig unterstrichen sein, wenn es sich um Schlüsselfelder handelt
oder nur gestrichelt unterstrichen, wenn diese Spalte in der Tabelle nicht immer einen
Wert enthalten muss – also optional ist. Fremdschlüssel werden zusätzlich durch einen
Pfeil gekennzeichnet und einen Verweis auf die Tabelle, auf die sich der Fremdschlüssel
bezieht.
SQL-Skripte
Der letzte Schritt besteht nun daraus, das Relationale-Modell in SQL-Anweisungen zu
überführen. Diese können dann in das Datenbanksystem eingegeben werden, um die
entsprechenden Tabellen anzulegen.
CREATE TABLE metadata_keywords (
id integer NOT NULL,
keyword character varying(64) NOT NULL,
CONSTRAINT metadata_keywords_pkey PRIMARY KEY (id, keyword))
WITH (OIDS=FALSE);
Metadata_Keywords (ID Metadata, Keyword)
Metadata(ID, Abstract, Available, BB_East, BB_North, BB_South, BB_West, Format,
Img_Width, Img_Height, License, Originator, Projection, Publisher, Pub_Date, Rev_Date, Scale, Series, Title, URI, URI_Key, Key_Text, Colour_Depth, Resolution, Transparency)
Abb. 11: ER-Modell der Metadatenbank. (Quelle: eigene Darstellung)
Abb. 12: SQL-Skript für die Erstellung der Tabelle Metadata_Keywords.
(Quelle: eigene Darstellung)
29
CREATE TABLE metadata (
id serial NOT NULL,
abstract text NOT NULL,
format character varying(20) NOT NULL,
licence text NOT NULL,
originator text NOT NULL,
projection text NOT NULL,
publisher text NOT NULL,
pub_date date NOT NULL,
rev_date date NOT NULL,
series text NOT NULL,
title text NOT NULL,
uri text NOT NULL,
uri_key text NOT NULL,
key_text text NOT NULL,
bb_east double precision NOT NULL,
bb_north double precision NOT NULL,
bb_south double precision NOT NULL,
bb_west double precision NOT NULL,
scale integer NOT NULL,
colour_depth integer,
resolution character varying(20) DEFAULT NULL::character varying,
transparency integer,
img_width integer NOT NULL DEFAULT 0,
img_height integer NOT NULL DEFAULT 0,
available boolean NOT NULL DEFAULT false,
CONSTRAINT metadata_pkey PRIMARY KEY (id)
WITH (OIDS=FALSE);
Spätestens zu diesem Zeitpunkt müssen die Datentypen der einzelnen Spalten der
Tabellen bedacht werden. Hier unterscheiden sich die einzelnen Datenbanksysteme
teilweise voneinander. Da in diesem Projekt das Datenbanksystem PostgreSQL
verwendet wird, sind die SQL-Skripte selbstverständlich für dieses System ausgelegt (vgl.
Abb. 12 und 13).
Neben den Standarddatentypen wie Integer für ganze Zahlen, Double für
Gleitkommazahlen oder Date für Datumsangaben, die von allen Datenbanksystemen
unterstützt werden, wurde für die Textattribute der PostgreSQL-spezifische Datentyp Text
verwendet. Dieser ermöglicht ein Speichern beliebig langer Texte, was für eine
Datenbank eher ungewöhnlich ist, da Textspalten meist über eine maximale Länge
verfügen. Natürlich kann dieser Vorteil der unbegrenzten Länge nur auf Kosten der
Performance erreicht werden. Für die Metadatenbank sollte dieser Performanceverlust
jedoch sehr gering sein, und im Vergleich zur hinzugewonnenen Flexibilität kaum ins
Gewicht fallen. Eine weitere spezifische Eigenschaft von PostgreSQL wurde für das
Abb. 13: SQL-Skript für die Erstellung der Tabelle Metadata.
(Quelle: eigene Darstellung)
30
Schlüsselattribut der Metadatentabelle verwendet. Durch die Verwendung des Datentyps
serial übernimmt das Datenbanksystem automatisch die Generierung des
Schlüsselwertes beim Einfügen eines neuen Eintrags. So wird sichergestellt, dass jeder
Schlüssel auch wirklich nur einmal in der Datenbank vorkommt, ohne dass der
Administrator eingreifen muss. Natürlich befreit dieses Vorgehen den Administrator nicht
vor der Aufgabe, darauf zu achten, dass keine doppelten Einträge in der Datenbank
vorhanden sind.
6.3 Administration der Datenbank
Jede Datenbank benötigt selbstverständlich auch Personen, die sie verwalten und in Takt
halten. Auch für die Metadatenbank ist daher ein Administrator notwendig. Damit diese
Aufgaben leicht von der Hand gehen, müssen dem Administrator gewisse Werkzeuge zur
Verfügung gestellt werden, um die Einträge der Datenbank verwalten zu können. In erster
Linie ist dabei wichtig, ein gewisses Level an Bedienkomfort zu gewährleisten, so dass die
Administration auch ohne erweiterte Kenntnisse des Aufbaus und der inneren Struktur der
Datenbank ermöglicht wird. Aus diesem Grund war ein wichtiger Bestandteil dieses
Projekts, eine Weboberfläche für die Administration der Metadatenbank zu entwickeln.
Der Zugriff über eine Weboberfläche hat dabei diverse Vorteile. So ist für die Benutzung
außer einem herkömmlichen Webbrowser keine zusätzliche Software notwendig.
Außerdem ist der Aufwand der Entwicklung einer Webseite im Vergleich zur Entwicklung
einer eigenständigen Software im Regelfall vergleichsweise gering.
Anforderungen
Zunächst muss geklärt werden, welche Funktionalität die Administrationsoberfläche bieten
muss. Neben einer Übersicht aller Einträge, soll es natürlich auch möglich sein, neue
Karten in die Datenbank einzutragen. Zusätzlich sollen vorhandene Einträge nachträglich
bearbeitet und bei Bedarf auch komplett gelöscht werden können. Zu guter Letzt soll die
Administrationsoberfläche noch eine Suchfunktion bereitstellen, um gegebenenfalls
Karten schnell finden zu können. Besonders aufwendig war dabei der Entwurf des
Formulars zum Einfügen neuer Datensätze. Zum einen, weil eine Vielzahl an Daten
eingegeben werden müssen und zum anderen, weil dem Nutzer diverse Hinweise zur
korrekten Eingabe der Daten angezeigt werden müssen. Im Folgenden wird jede der
einzelnen Funktionen beschrieben. Dabei wird bewusst auf HTML oder PHP-Code
verzichtet, um eine bessere Übersichtlichkeit zu wahren.
31
Neuen Datenbankeintrag einfügen
Die erste Anforderung, die an das Frontend gestellt wurde, war das Einfügen von
Datenbankeinträgen. Aus diesem Grund ist in der oberen Menüleiste einen Link
geschaffen um einem Eintrag einzufügen. Auf der dahinter stehenden Seite werden
sowohl die Pflicht- als auch die optionalen Felder untereinander aufgelistet. Wobei der
Nutzer nicht allein gelassen wird, denn jedes Feld besitzt am rechten Rand eine kleine
Erklärung. So können auch Personen die Seite benutzen, die nicht Teil des Projektes
waren.
Um eine mühselige Überprüfung der Datumseingabe zu ersparen, wurde zuerst einen in
HTML 5 dafür vorgesehener input-Typ verwendet. Leider verstehen einige Browser HTML
5 nicht fehlerfrei. Aus diesem Grund haben wir uns dafür entschieden, einen in PHP und
JavaScript geschriebenen Open-Source Kalender zu verwenden (vgl. TRICONSOLE 2009).
Dieser ist frei konfigurierbar und besitzt genau die gewünschten Funktionen.
Der Karten- und Legendenupload war ebenso eine Herausforderung. Zuerst wurde
angenommen, die Karten seien schon auf dem Server hochgeladen. Somit bräuchte man
diese nur noch auf dem Server auswählen. Später stand aber fest, dass die Karten beim
Einfügen eines neuen Eintrags mit hochladen werden sollten. Dies hat aber das Problem,
dass man relativ große Karten (> 100 MB) per Webupload auf den Server laden sollte.
Somit würden bei mehreren Karten, die parallel hochgeladen werden, das Netzwerk
verstopfen. Dies ist ein Problem, welches nicht ohne weiteres gelöst werden kann, da die
Abb. 14: Formular zum Einfügen neuer Datensätze. (Quelle: eigene Darstellung)
32
Karten auf Grund der Qualitätsanforderungen eine gewisse Größe haben müssen und sie
durch den Nutzer auf den Server geladen werden sollen
Datenbankeintrag ändern
Grundsätzlich ist diese Seite ähnlich wie die Seite zum Einfügen in die Datenbank
aufgebaut. Dennoch gibt es mehrere kleinere Unterschiede.
So wird, während die Seite geladen wird eine Anfrage an die Datenbank gestellt. Als
Ergebnis dieser Anfrage bekommt man den zu ändernden Datenbankeintrag entgegen.
Daraufhin werden alle Eingabefelder der Seite mit den in der Datenbank befindlichen
Daten gefüllt.
Ein anderer Unterschied ist, dass das Hochladen der Karte und der Legende nicht
Bestandteil des Änderungsformulars ist. Darüber hinaus werden beim Absenden der
abschließenden SQL-Anfrage alle für die zu ändernden Karte bestehenden Einträge in
der Keywords-Tabelle gelöscht und dann alle geänderten bzw. neuen Schlüsselwörter
hinzufügt. Diese strenge Variante wurde gewählt, da sonst geprüft werden müsste,
welche Keywords sich geändert haben, welche noch dieselben und welche neu
hinzugekommen sind. Dies wäre auch sehr fehleranfällig, deshalb ist die einfachere
Variante umgesetzt wurden.
Datenbankeintrag entfernen
Falls der Nutzer einen falschen Eintrag getätigt haben sollte, sollte man neben dem
Ändern auch die Möglichkeit haben diesen Eintrag direkt zu löschen. Dafür ist bei der
Übersicht aller Datenbankeinträge hinter dem Ändern-Button einen Löschen-Button
hinzugefügt. Um sicherzustellen, dass dieser nicht aus Versehen gedrückt wird, erscheint
nach dem Drücken immer eine kleine Warnung. Erst wenn man diese Warnung bestätigt
wird der Eintrag zum Löschen vorgesehen.
Datenbank durchsuchen
Zu einer vollständigen Datenbank gehört selbstverständlich auch eine Suchfunktion.
Gerade wenn schnell Informationen zu einer bestimmten Karte nachschlagen werden
sollen, ist es effektiver direkt danach zu suchen, als erst in der Übersicht lange Scrollen
zu müssen. Neben einer einfachen Suche, die sämtliche Spalten der Tabelle
berücksichtigt, gibt es auch erweiterte Suchfunktionen, mit denen man beispielsweise
nach einem Jahr oder Zeitintervall suchen kann, nach Schlüsselwörtern oder sogar direkt
nach Koordinaten.
33
Änderung veröffentlichen
Am Ende wurde zusätzlich noch einen Überwachungsmechanismus eingebaut. Alle
neuen Einträge werden auf der Seite „Eintrag freischalten“ aufgelistet. Hier kann der
Administrator die neuen Einträge gegebenenfalls ändern, löschen und letztendlich auch
freigeben. Die Freigabe eines Eintrages bewirkt, dass dieser in der Datenbank als gültig
markiert wird. Nur als gültig markierte Einträge können später benutzt werden. Dieser
Mechanismus gibt zusätzlich mehr Sicherheit.
6.4 Umsetzung der Datenbank
Zum erfolgreichen und zeiteffizienten Erstellen des GIS-Metadaten-Frontends gehört das
Verwenden einer Arbeitsumgebung, die dem Programmierer in vielen Dingen zur Hand
geht und ihm kleinere Aufgaben abnimmt und ihn den Blick auf das eigentliche Ziel
ermöglicht. Des Weiteren ermöglicht eine voll funktionsfähige und auf die Bedürfnisse des
Programmierers eingerichtete Arbeitsumgebung eine Programmiereffizienz, die ohne
Abb. 15: Suchfunktion der Metadatenbank. (Quelle: eigene Darstellung)
Abb. 16: Freischaltformular mit Eingabe des Geo-Server Layers. (Quelle: eigene Darstellung)
34
diese Hilfsmittel unerreicht bliebe. Viel wichtiger noch als eine Arbeitsumgebung ist jedoch
die Software, auf der das Projekt aufbaut. Kein Projekt wird von Grund auf neu gebaut
sondern basiert auf bereits vorhandener und vielfach bewährter Software. Getreu der
Philosophie „Zwerge auf den Schultern von Riesen“ ist die Verwendung von bereits
funktionierenden Softwarekomponenten daher ein absolutes “Muss” für eine zielgerichtete
Projektarbeit. Im Folgenden soll daher eine kleine Übersicht über die verwendete
Software, die im Rahmen des GIS-Projekts Verwendung, fand vermittelt werden.
Grundlegende Software
Virtuelle Maschine – VirtualBox
Das erste Hindernis, dass es in einer teamorientieren Projektarbeit zu überwinden gilt, ist
die Schaffung einer homogenen Arbeitsumgebung, in der alle Teilnehmer die gleichen
Voraussetzungen haben. Da der Großteil der Projektarbeit auf privaten Laptops geschah,
die allesamt unterschiedliche Hard- und Softwarekonfigurationen aufwiesen, war dieser
Schritt besonders wichtig. Vielfach bewährt hat sich hierfür die Verwendung einer
sogenannten „Virtual Machine“, einem vollständig simulierten Betriebssystem, das
innerhalb eines Host-Umgebung ausgeführt wird und das im Allgemeinen gar nichts
davon weiß, dass es nur virtuell läuft. Eine weit verbreitete Lösung einer solchen
Maschine ist die „VirtualBox“. Einmal eingerichtet, kann diese von einem PC zum
nächsten kopiert und benutzt werden.
Als Betriebssystem, welches innerhalb der VirtualBox lief, wurde Ubuntu 10.04 LTS 32 Bit
Desktop-Edition verwendet, da es während des Informatikstudiums viele
Berührungspunkte gab und so die zuständige Arbeitsgruppe gut mit diesem System
vertraut ist. Als nächstes wurde auf diesem System ein Apache-Webserver installiert und
konfiguriert.
Webserver – Apache
Diese Serversoftware wird benötigt, um selbstgeschriebene Webseiten oder auch andere
beliebige Daten lokal abzuspeichern und innerhalb eines Netzes (z.B. Internet) zur
Verfügung zu stellen. Damit auf Seite des Webservers Code ausgeführt werden kann, um
z.B. Datenbankanfragen abzuschicken, musste zusätzlich auch noch PHP installiert
werden.
PHP
Bei PHP handelt sich um eine Skriptsprache, die auf Seite des Servers läuft. Mit ihr kann
man z.B. Datenbankanfragen abschicken und die Ergebnisse als Webseite an den Client
35
schicken. Die Installation von PHP auf dem System erfolgte recht unkompliziert, was nicht
zuletzt an der Tatsache liegt, dass PHP einerseits frei verfügbar ist und es andererseits
für fast alle Betriebssysteme eine Version gibt. Dies sind auch die Gründe warum PHP bei
einem Großteil der dynamischen Internetseiten verwendet wird. Neben PHP gibt es auch
noch ASP von Microsoft. Da bei den Mitgliederen der Arbeitsgruppe aber mit dieser
Sprache kaum Erfahrungen vorlagen, war es zu riskant auf diese Technik zu setzten.
Weiterhin musste eine Datenbank aufgesetzt werden, in der die Metadaten gespeichert
werden.
Datenbankmanagementsystem – MySQL und PostgreSQL
Die im GIS hinterlegten Metadaten werden in einer Datenbank gespeichert, die speziell
für diesen Zweck entworfen wurde (s. Abschnitt 6.2). Hier soll nur die technische
Einrichtung der Datenbank beschrieben werden.
Zu Beginn des Projektes sah es der Plan noch vor, eine MySQL-Datenbank aufzusetzen.
MySQL ist ein Datenbankmanagementsystem, welches den SQL-Standard implementiert
und unter Umständen mehrere unterschiedliche Datenbanken verwaltet. SQL ist eine
Sprache mit der man Anfragen an eine Datenbank schreiben kann. Als Antwort einer
solchen Anfrage bekommt man alle Datenbankeinträge, die zu der Anfrage „passen“. Die
Einrichtung dieser Datenbank geschieht zu großen Teilen vollautomatisch und ist
allgemein sehr benutzerfreundlich gehalten. Aus diesem Grund hatte das Team bereits in
anderen Projekten gute Erfahrungen mit diesem Datenbanksystem gemacht und konnte
bereits von Anfang an mit diesem System umgehen. Über das Administrationstool
„PHPMyAdmin“ konnten zudem leicht Test-Einträge eingefügt und Testanfragen gestellt
werden.
Leider kann MySQL als Datenbankmanagementsystem nicht verwendet werden, da der
Geo-Server nicht mit einer MySQL-Datenbank arbeiten kann. So waren wir gezwungen,
im letzten Drittel des Projekts, von MySQL zum Konkurrenzdatenbanksystem PostgreSQL
zu wechseln. Dies erforderte zunächst eine Einarbeitung in das für die Teammitglieder bis
dahin unbekannte Datenbanksystem. Da dieser Schritt zu einem Zeitpunkt geschah, zu
dem auch bereits große Teile des PHP-Codes fertiggestellt waren, zog dies leider
Anpassungen des Codes nach sich, was einen zusätzlichen, im Projektplan nicht
vorgesehenen, Arbeitsaufwand bedeutete.
Zusätzliche Software
Die bisher beschriebenen Softwarekomponenten stellen die Grundlage für ein
funktionierendes GIS dar. Für das Eintragen von Metainformationen ist jedoch eine
36
Benutzeroberfläche (Frontend) nötig, die komfortabel und benutzerfreundlich genug ist,
um auch projektfremden Personen das Einfügen und Verwalten von Metadaten zu
gestatten.
Von Anfang an stand bereits fest, dass diese Benutzeroberfläche durch eine PHP-
Webseite realisiert werden sollte, die über das Internet anzusprechen ist. Diese Seite
sollte den Funktionsumfang zum Einfügen, Ändern und Löschen von Metadatensätzen
liefern, sowie die Möglichkeit zu Hochladen des Kartenmaterials sowie den
Legendenobjekten und -texten bereitstellen. Dies könnte klassischerweise manuell in
PHP programmiert werden, was einen nicht unerheblichen Programmieraufwand von
etwa 1000 Zeilen Code bedeutet. Einen Versuch zur Vermeidung dieses Aufwandes
wurde durch die Verwendung sogenannter PHP-Codegeneratoren unternommen.
PHP-Codegeneratoren – SQLMaestro
Ein solcher Generator wird beispielsweise von der Firma SQLMaestro angeboten und
erstellt zu einer gegebenen Datenbank ein solches Frontend, welches anschließend noch
personalisiert und anderweitig an die Bedürfnisse des Projektes angepasst werden kann.
Für die MySQL Datenbank wurde dies erfolgreich unter dem verwendetem System
getestet. Als Resultat wurde eine voll funktionsfähige Benutzeroberfläche generiert,
welche wir auch im Rahmen der Veranstaltung vorgestellt haben.
Als aber bekannt wurde, dass PostgreSQL verwendet werden soll, kamen Probleme auf.
Zuerst hat das Team nach einem PHP-Generator für PostgreSQL-Datenbanken gesucht.
Zum Glück bietet auch hier die Firma SQLMaestro einen Generator an. Leider funktioniert
dieser Generator nur unter Windows und nicht unter Linux. Trotz einiger Tricks (WINE und
dll-Imports) konnte dieses Programm nicht zum Laufen gebracht werden. So blieb dieser
mögliche Lösungsweg leider verwehrt.
Eine andere Möglichkeit wäre es gewesen, das generierte MySQL-Frontend so
umzuschreiben, dass es mit einer PostgreSQL-Datenbank und nicht mit einer MySQL-
Datenbank kommuniziert. Leider waren die PHP-Codedateien sehr schlecht kommentiert,
was eine nachträgliche Manipulation natürlich schwierig machte. Darüber hinaus war
jegliche Datenbank-Kommunikation so stark gekapselt, dass es insgesamt aufwändiger
gewesen wäre den bestehenden Code zu modifizieren, als ihn einfach von Grund auf neu
zu schreiben.
Die Verwendung der PHP-Generatoren stellt also ein Kapitel des Projektes dar, was nicht
bis zum Ende hin erfolgreich durchgezogen wurde, welches allerdings als Versuch nicht
unerwähnt bleiben sollte.
37
6.5 Verbindung mit Geo-Server
Bereits von Vornherein war geplant, die Metadatenbank mit einem WebGIS zu verbinden,
um so die Karten auch zugänglich zu machen. Dieser Schritt erfordert das
Zusammenspiel von zwei getrennten Komponenten. Auf der einen Seite ist das
Datenbanksystem PostgreSQL mit der Metadatenbank und auf der anderen Seite der
Geo-Server, welcher die Grundlage für das WebGIS darstellt. Prinzipiell ist es kein
Problem, die für die Präsentation der Karten notwendigen Informationen aus der
Metadatenbank abzufragen. Allerdings müssen diese Informationen anfangs erst einmal
in die Metadatenbank gelangen. Konkret sind das die Bezeichnung des Kartenlayers wie
er im Geo-Server steht, die Auflösung der Karte in Pixeln (also Breite und Höhe) sowie die
Ausdehnung der Bounding-Box. Da kein automatischer Austausch zwischen Geo-Server
und Metadatenbank erfolgt, müssen die entsprechenden Daten jeweils vom Administrator
– nach dem Einrichten des entsprechenden Layers im Geo-Server – eingetragen werden.
Dieser Schritt geschieht beim Freischalten der Karten.
38
7 WebGIS
7.1 OpenLayers
Die OpenLayers-Bibliothek basiert auf JavaScript und ermöglicht es Geodaten im
Webbrowser anzuzeigen. Bei OpenLayers handelt es sich um eine
Programmierschnittstelle, die eine clientseitige Entwicklung unabhängig vom Server
zulässt. Dadurch können verschiedene Datenquellen als Grundlage für ein eigenes
Kartenobjekt dienen. (vgl. dazu OPENLAYERS 2012)
Die Verwendung von Online-Kartendiensten wie GoogleMaps, GoogleSatellit oder
OpenStreetMaps ist ebenso einfach möglich, wie die statische Einbindung von einzelnen
gescannten Bilddateien. Neben verschiedenen Tools innerhalb einer eigenen
Symbolleiste im Kartenfenster, können eventbasierte Interaktion von außerhalb (Button,
Mausklick, Eingabe) den Inhalt oder das Verhalten beeinflussen.
7.2 WMS-Server
Ein WebMapService (WMS) ist eine Schnittstelle zum Abrufen von Auszügen aus
Landkarten über das World Wide Web. Der WMS ist ein Spezialfall eines Web Services.
Ein WMS liefert auf Anfrage gekachelte Kartenteile aus Vektor- oder Rasterdatenquellen
und kann Feature-Informationen verarbeiten (im Projekt nicht vorhanden). (vgl. dazu
WIKIPEDIA 2012)
7.3 GeoTiff
Die Bezeichnung für das TIFF-Format für Bilder (Tagged-Image-File-Format) weist auf die
Besonderheit hin, neben den Informationen für z.B. Bildgröße, Farbtiefe und Kodierung,
auch weitere Tags innerhalb der Bilddatei verwenden zu können. Diese können unter
anderem Informationen zum Aufnahmegerät, Belichtung oder verwendetem
Bildbearbeitungsprogramm, aber auch Namen und Autor oder weitere
Quelleninformationen enthalten. (Bei JPEG-Dateien wird für diese Informationen oft der
sog. EXIF-Header verwendet.)
Seitdem Handys über gute Digitalkameras und GPS-Funktionalität verfügen, ist das sog.
Fotografieren mit Geotags, also die Aufnahme von Georeferenzierten Digitalbildern, auch
für Amateure möglich. Dies nutzt unter anderem die Anwendung GoogleEarth für die
Platzierung der von Benutzern aufgenommenen Bilder. Die bei der Aufnahme
entstehenden Geodaten werden im EXIF-Header oder als sog. GeoTiffs gespeichert. Die
Verwendung von GeoTiffs erlaubt eine Vielzahl von weiteren Meta-Tags und kann bei
Karten auch Projektion und geodätische Grundlage enthalten. Es gibt auch Entwicklungen
39
bei der Versucht wird standarisierte Meta-Geodaten z.B. im DublinCore als Meta-
Datenblock in GeoTiffs zu verwenden. Da diese Anstrengungen jedoch nicht von jedem
Entwickler getragen werden und properitäre Dateiformate von Adobe wie z.B. XMI als
XML-basiertes Pendent zum GeoTiff eigene Wege verfolgt, ist es schwierig die optimale
Lösung (zukunftsorientiert) derzeit zu finden. Der XMI-Standard scheint eine höhere
Kompatibilität zum PDF-Format zu haben. (vgl. dazu TRAC 2011, OMG 2012) Daher wirkt
die Entscheidung eine eigene Metadatenbank aufzubauen als solide Alternative zu den
derzeit angebotenen Dateiformaten. Die spätere Konvertierung des Inhalts der Datenbank
in neue Metadateiformate kann automatisiert erfolgen.
7.4 Webseiten-Layout
Die Webseite für die Darstellung des Kartenframes, soll Eingabefelder für den Filter der
Suchanfrage enthalten und das Ergebnis geeignet und übersichtlich präsentieren. Alle
gefundenen Karten können durch Mausklick aktiviert werden und im Kartenframe
angezeigt werden. Die Anordnung der Hauptelemente dieser Webseite entscheidet über
die Usability und sollt auch gestalterische Aspekte nicht außen vor lassen.
Die Hauptaufgabe der verantwortlichen Arbeitsgruppe besteht in der Einbindung der
Hauptfunktionselemente, der Verknüpfung von Suchergebnissen mit dem Kartenframe,
der Verknüpfung der Eingabefelder mit der Metadatenbank über SQL-Anfragen und der
Gestaltung der Webseite im Gesamten. Dazu ist es teilweise erforderlich eng mit der
Arbeitsgruppe III zusammen zu arbeiten, insbesondere bei Fragestellungen zur
Datenbankkommunikation und PHP-Anfragen, da diese bereits im Eingabe-Formular der
Metadatenbank vorhanden sind und ggf. wieder verwendet werden können. Das
Hauptaugenmerk besteht in der dynamischen Generierung von OpenLayer-Ebenen zur
Laufzeit. Dies ist notwendig um kontextsensitiv auf die Ergebnisse der Suche zu reagieren
und die Kartenauswahl auf nur vorhandene Elemente zu begrenzen.
Die Webseite des WebGIS (vgl. Abb. 17) orientiert sich an der bestehenden
CampusMaps-Seite der MLU. (vgl. CAMPUSMAPS 2012) Auf der linken Seite befindet sich
das Kartenfenster (OpenLayer-Objekt). Auf der rechten Seite ist die Suchmaske mit
Eingabeboxen platziert. Unter diesen Elementen werden die Suchergebnisse tabellarisch
aufgelistet. Die Eingabemaske enthält die Möglichkeit orts-, zeit- und themenbezogene
Suchanfragen zu stellen. Die Ergebnisse werden dann automatisch als Themenlayer im
Kartenfenster angezeigt und können per Mausklick aktiviert werden. Neben diesem
WebGIS-Portal besteht die Möglichkeit über einen vereinfachten Viewer direkt aus der
Meta-Datenbank ausgewählte Suchergebnisse anzeigen zu lassen. Damit ist es möglich
40
einfach und direkt auf den Inhalt des Geo-Servers zuzugreifen und die von ihm zur
Verfügung gestellten Karten anzuzeigen.
Für die Umsetzung der Webseite wurde für die Kartendarstellung bedingt durch die
Verwendung der OpenLayers-Bibliothek JavaScript verwendet und für die
Datenbankverbindung zur PostgreSQL-DB ein PHP-basierter Skriptteil für Anfrage und
Ergebnisverarbeitung eingesetzt. Die Schwierigkeit dabei, besteht in der Verbindung von
beiden Skriptsprachen und deren Interaktion miteinander.
7.5 Vergleich mit anderen Online-Kartensammlungen/-Archiven bzw.
Online-Geo-Diensten
Unter der Adresse „www.iegmaps.de“ findet sich eine Auswahl an historischen Karten,
geordnet in mehre Serien. Die gescannten Karten wurden statisch als Bilddatei
eingebunden. Daneben befinden sich die zugehörigen Metadaten. Es ist möglich einzeln
durch die Karten einer Serie zu navigieren oder eine Suchmaske zu verwenden. Diese
ermöglicht es dem Nutzer Stichworte einzugeben und thematische oder ortsbezogene
Suchbegriffe zu wählen. Die meisten Karten wurden zeitlich geordnet eingefügt. Deshalb
ist ein multitemporärer Vergleich ohne Probleme möglich. Es lässt sich jedoch nur eine
Karte pro Seite darstellen. (vgl. dazu KUNZ o.J.) Im Vergleich zum WebGIS der
Projektgruppe stellt die statische Einbindung als feste Bilddatei den größten Nachteil des
IEG-Maps dar. Im Gegensatz zu der Herangehensweise der Projektgruppe, welche eine
einzelne Webseite (Portal) als Ausgangspunkt für Suche und Ergebnisdarstellung
Abb. 17: Web-GIS. (Quelle: eigene Darstellung)
41
verwendet, wirkt die Webseite der IEG-Maps eher als Ansammlung einzelner
Kartenblätter die durch Verlinkung sortiert präsentiert werden sollen. Die Möglichkeit
mehrere Karten im Vergleich im selben Kartenfenster darzustellen, ist hierbei nicht
gegeben. Die Qualität der enthaltenen Karten ist eher mäßig.
Das Archiv „Digital Historical Maps (dhm)“ unter „www.dhm.uni-greifswald.de“ bietet einen
erheblichen größeren Umfang in Bezug auf den Inhalt des Portals, als auch auf die
zahlreichen Funktionen. Neben den verschiedenen Bildbetrachter-Plugins der Karten, der
interaktiven Legenden (Bild und Text für jede Signatur einzeln) und der
Qualitätsverbesserung der Rohdaten, gibt es ein interaktives Kartenauswahlmenü,
welches innerhalb einer grobschematischen Karte die vorhandenen Einträge der
Datenbank zeigt. Der Benutzer kann durch Auswahl der jeweiligen Region in der
Übersichtskarte selbst oder durch Auswahl des Ortsnamens aus einem Dropdown-Menü
die Metadaten anzeigen lassen. Die Karte selbst wird als sid-Datei zur Verfügung gestellt,
welche durch das Betrachter-Plugin dekomprimiert und angezeigt wird. (vgl. dazu
HARTLEIB 2003) Im Vergleich zum WebGIS der Projektgruppe, kann im dhm-Portal direkt
auf einer Übersichtskarte ausgewählt werden. Ein weiterer Vorteil sind die interaktiven
Legendeneinträge mit Erklärungen. Jedoch ist es auch beim dhm-Portal nur möglich
feste, statisch eingebundene Karten einzeln zu laden.
Das Projekt DHM wird durch das Projekt GeoGREIF fortgesetzt und ist unter „greif.uni-
greifswald.de/geogreif“ zu erreichen. Neben einer Übersicht über thematische Karten gibt
es auch eine alphabetisch geordnete Gesamtübersicht und die Möglichkeit über eine
Suchmaske gezielt nach bestimmten Metadatenfeldern zu suchen. Dadurch kann effizient
nach Stichworten, thematisch oder zeitlich gesucht werden. Die Ergebnisse werden in
einer Vorauswahl mit Minibildern und Kurzbeschreibung dargestellt und können vom
Benutzer im Detailmodus ausführlicher betrachtet werden. Neben verschiedenen
Metadatenformaten in XML kann dann die Karte als statisch eingebundene Bilddatei
angezeigt werden. Es fällt auf das innerhalb der Metadaten keine Hinweise auf
Georeferenzierung vorliegen. (vgl. dazu UNIVERSITÄT GREIFSWALD o.J.) Der Vorteil durch
die Vielzahl von historischen Karten von GeoGREIF wird nicht durch die fehlende
Interaktivität und dynamische Einbindung der Karten in einen Geokontext gemindert. Als
Datengrundlage für ein darauf aufbauendes WebGIS-Portal ist GeoGREIF hervorragend
geeignet. Die Interaktivität und die Verschmelzung mit bestehenden Online-Geodiensten
wie Bing, Google oder OSM sind nur im WebGIS dieser Projektgruppe enthalten. So kann
ein stets aktuelles Kartenwerk von verschiedenen Quellen garantiert werden und als eine
Basis für Kartenvergleiche mit historischen Daten dienen. Dieser Vorteil wird bisher nicht
von den verglichenen Online-Archiven erreicht.
42
8 Schlussbetrachtung
Ziel des Projekts war die Schaffung einer Geodateninfrastruktur (GDI) der Daten der
Untersuchungsregion und die Visualisierung der Geodaten zu deren späteren Nutzung in
Web-GIS. Dieses Ziel wurde erreicht durch die Zusammenarbeit von Studierenden
unterschiedlicher Fachrichtungen. Hierbei mussten die einzelnen Aufgabenbereiche
koordiniert und aufeinander abgestimmt werden, wobei es teilweise
Kommunikationsschwierigkeiten gab. Schwierigkeiten ergaben sich zudem durch das
auffinden der jeweiligen Legenden bzw. Metadaten, die sich jedoch durch gezielte
Recherche bewältigt werden konnten. Lediglich die Frage nach der Lizenz bzw. nach dem
Urheberrecht ließ sich bei den Metadaten nicht in allen Fällen eindeutig klären, was
aktuell eine Einschränkung auf ausschließlich institutsinterne Nutzung der
Webanwendung bedeutet. Analoge Karten wurden durch das Scannen digitalisiert und
durch die Bildbearbeitung vor verarbeitet, so dass sie in einem nächsten Schritt
georeferenziert werden konnten. Beim Scannen ergaben sich teils durch die
Papierqualität der analogen Karten Schwierigkeiten. Bei der anschließenden
Georeferenzierung bereitete zunächst die Zuweisung des geeigneten Referenzsystems
Probleme, die sich jedoch aufhoben und somit ein einheitliches Referenzsystem die
Grundlage für die unterschiedlichen Karten bildete. Zudem ließen sich die älteren Karten
schwer georeferenzieren, da gleiche Passpunkte gefunden werden mussten. Schließlich
wurde in diesem Abschnitt vektorisiert und Legendeninhalte wurden verschriftlicht, so
dass mittels der Suchfunktion später Karten mit den betreffenden Legendeninhalten
aufgefunden werden können. In der Folge wurde mit dem DCLite4G ein
Metadatenstandard festgelegt, der mit 17 Attributen einen auf das wesentliche
beschränkten Standard darstellt und durch die Einführung zweier weiterer Attribute die
projektrelevanten Anforderungen erfüllt. Die bestehenden 19 Attribute können die
historischen Karten ausreichend beschreiben und erleichtern die Recherchemöglichkeiten.
Auf die Festlegung des Metadatenstandards folgte der Entwurf einer Datenbank, der in
drei aufeinander aufbauenden Teilschritten erfolgt. Zuerst wird das Entity-Relationship-
Modell (ER-Modell) aufgestellt, welches darauf in ein Relationales-Modell transformiert
wird. In einem letzten Schritt werden Befehle zur Generierung von Tabellen in der
Datenbankanfragesprache SQL eingegeben. Diese Anweisungen sind ohne
Schwierigkeiten in eine existierende SQL-Datenbank integrierbar, so dass die nötigen
Tabellen automatisch generiert werden können. Die Schaffung eines ER-Modells ging
problemlos von statten, da die zu Grunde liegende Metadatenbank nicht zu umfangreich
war. Die Überführung in ein Relationales-Modell und die SQL-Skripte ergaben keine
Schwierigkeiten, bei den SQL-Anweisungen wurde das Datenbanksystem PostgreSQL
43
festgelegt. Die entstehende Datenbank muss letztlich durch einen Administrator verwaltet
werden, dem Administrator werden für die leichte Handhabung der Datenbank folgende
Funktionen zur Verfügung gestellt: neuen Datenbankeintrag einfügen, Datenbankeintrag
ändern, Datenbankeintrag ändern, Datenbankeintrag entfernen, Datenbank durchsuchen
und Änderung veröffentlichen. Gleichzeitig wurde mit der Erstellung der Webanwendung
eine Oberfläche geschaffen, die es dem Nutzer ermöglicht Karten mit dazugehörigen
Legenden zu recherchieren. Durch die Verknüpfung mit der Metadatenbank, sind für alle
integrierten Karten Metainformationen nach dem Dublin Core Standard abrufbar. Es
wurde die Möglichkeit geschaffen mehrere Karten gleichzeitig anzuzeigen. Durch die
Bestimmung einer Transparenz ist es so dem Nutzer möglich sowohl Unterschiede des
Karteninhalts, als auch der Kartengestaltung zu analysieren. Die Anwendung wurde so
gestaltet, dass auch zukünftig eine projektunabhängige Nutzung erfolgen kann, d. h.
weitere Karten bzw. Geodaten der Datenbank zugefügt und so recherchierbar und
visualisierbar gemacht werden können.
Die Metadatenbank und der Kartenviewer sind über die folgenden Webseiten abrufbar:
Metadatenbank: http://maps.uni-halle.de/gdi/index.php
WebGIS: http://maps.uni-halle.de/gdi/webgis.php .
44
Quellenverzeichnis
BILL, R. (2012): Geoinformatik-Service. In: http://www.geoinformatik.uni-
rostock.de/themen.asp?ThemID=4, Universität Rostock [Zugriff am: 01.02.2012]
BRUDER, R. (2002): Digitale Bildverarbeitung. Ausarbeitung zum Seminar. In: http://
www2.in.tu-clausthal.de/~reuter/ausarbeitung/Ralf_Bruder_-_Digitale_
Bildverarbeitung.pdf [Zugriff am: 16.01.2012]
BURGER, W. & BURGE, M. J. (2006): Digitale Bildverarbeitung. Eine Einführung mit
Java und ImageJ. Berlin.
CAMPUSMAPS (2012): CampusMaps Martin-Luther-Universität Halle-Wittenberg. In:
http://maps.uni-halle.de [Zugriff am: 02.02.2012]
DECKER, C. V. (1816): Das militärische Aufnehmen oder vollständiger Unterricht in der
Kunst, Gegenden, sowohl regelmäßig als nach dem Augenmaaße, aufzunehmen.
Mit besonderer Rücksicht auf die herrschenden militairischen Verhältnisse und auf
eigends dazu erfundene Instrumente genau bearbeitet. Berlin.
GABRISCH, W. (2011): Softwaretechnik in der Praxis. Projektmanagement. Skript
zur Lehrveranstaltung. Martin-Luther-Universität Halle-Wittenberg.
HARTLEIB, J. (Hg.) (2003): dhm. Digital Historical Maps. Greifswald. In:
http://www.dhm.uni-greifswald.de [Zugriff am: 02.02.2012]
KOCH, T. / STOTTMEISTER, B. / THOMAE, M. (2002): Ein junger Geotop bei Teutschenthal.
In: Hallesches Jahrb. Geowiss. Bd. 24, S. 105-111.
KOCH, W. G. (2006): Zur Problematik der topographischen Karten (Ausgabe für die
Volkswirtschaft) der DDR. In: Unverhaun, D. (Hg.): Kartenverfälschung als Folge
übergroßer Geheimhaltung? Eine Annäherung an das Thema Einflussnahme der
Staatssicherheit auf das Kartenwesen der DDR. 3. Auflage, Münster.
KOHLSTOCK, P. (2004): Kartographie. UTB-Verlag, Stuttgart.
KRÜGER, G. & SCHNADT, J. (2000): Die Entwicklung der geodätischen Grundlagen für die
Kartographie und die Kartenwerke 1810-1945. In: Scharfe, W. & Scheerschmidt, H.
(Hg.): Berlin-Brandenburg im Kartenbild. Ein Ausstellungsbericht der Ausstellung
vom 10. Oktober bis 18. November 2000. Berlin.
KUNZ, A. (Hg.) (o.J.): IEG-MAPS. Server für digitale historische Karten. Institut für
europäische Geschichte, Mainz. In: http://www.iegmaps.de [Zugriff am:
02.02.2012]
45
MÖLLER, B. (2009): Skript: Einführung in die Bildverarbeitung. Skript zur
Lehrveranstaltung. Martin-Luther-Universität Halle-Wittenberg.
NATIONAL IMAGERY AND MAPPING AGENCY (NIMA) (2000): DoD: World Geodetic System
1984. NIMA Report 8350.2.
OBJECT MANAGEMENT GROUP (OMG) (2012): XMI-Standard. In:http://www.omg.org/spec/
XMI [Zugriff am: 02.02.2012]
OPENLAYERS (2012): OpenLayers: Free Maps for the Web. In: http://openlayers.org
[Zugriff am: 2.2.2012]
RICHTER, W. (2001): Salzgewinnung und Umweltbelastung. In: Hallesches Jahrb.
Geowiss., Bd. 23, S. 137-153. Halle.
SCHARFE, W. & SCHEERSCHMIDT, H. (Hg.) (2000): Berlin-Brandenburg im Kartenbild. Ein
Ausstellungsbericht der Ausstellung vom 10. Oktober bis 18. November 2000.
Berlin.
SCHWEFEL, D. (2010): Räumliche und zeitliche Analyse von anthropogen induzierten
Landschaftsveränderungen im Bergbaufolgegebiet Teutschenthal-Bahnhof.
Diplomarbeit, Institut für Geowissenschaften der Martin-Luther-Universität Halle-
Wittenberg, Fachgebiet Geofernerkundung und Kartographie, Halle.
SCHWEFEL, D. (2011): Exkursion im Rahmen des Seminars GIS-Projektmanagement am
02.11.2011 nach Teutschenthal.
TÖNNIES, K.D. (2005): Grundlagen der Bildverarbeitung. Pearson Studium.
TRAC (2011): GeoTIFF. In: http://trac.osgeo.org/geotiff [Zugriff am: 02.02.2012]
TRICONSOLE (Hg.) (2009): PHP-Calendar, Datepicker Calendar. In: http://
www.triconsole.com/php/calendar_datepicker.php [Zugriff am: 10.01.2012]
UNIVERSITÄT GREIFSWALD (Hg.) (o.J.): GeoGREIF. Geographische Sammlungen. In:
http://greif.uni-greifswald.de/geogreif [Zugriff am: 02.02.2012]
UNVERHAUN, D. (Hg.) (2006): Kartenverfälschung als Folge übergroßer Geheimhaltung?
Eine Annäherung an das Thema Einflussnahme der Staatssicherheit auf das
Kartenwesen der DDR. 3. Auflage, Münster.
VERLAG DES REICHAMTS FÜR LANDESAUFNAHME (1931): Das Reichsamt für
Landesaufnahme und seine Kartenwerke. Berlin.
WIKIPEDIA (2012): Web Map Service. In: http://de.wikipedia.org/wiki/Web_Map_Service
[Zugriff am: 02.02.2012]
46
ZIMMERMANN, W. (2011): Skript: Softwaretechnik. Skript zur Lehrveranstaltung. Martin-
Luther-Universität Halle-Wittenberg.
ZÖGNER, L. (1981): Preußens amtliche Kartenwerke im 18. und 19. Jahrhundert.
Institut für angewandte Geodäsie. Berlin.
47
Kartenverzeichnis
Karte
verwendetes Kürzel
PREUßISCHER GENERALSTAB (Hg.) (1817a): Deckersches Kartenwerk, Blatt 623, Maßstab 1:25000,1817.
PREUßISCHER GENERALSTAB (Hg.) (1817b): Deckersches Kartenwerk, Blatt 624, Maßstab 1:25000, 1817.
TK25 - 1817
KÖNIGLICH PREUßISCHES MINISTERIUM FÜR HANDEL (Hg.) (1852): Urmesstischblatt, Bande V, Blatt 3, Maßstab 1:25000, 1852.
TK25 - 1852
KÖNIGLICH PREUßISCHES MINISTERIUM FÜR HANDEL (Hg.) (1872): Urmesstischblatt, Bande V, Blatt 3, Maßstab 1:25000, Original von 1852 mit Nachträgen von 1872.
TK25 - 1872
KÖNIGLICH PREUßISCHES MINISTERIUM FÜR HANDEL (Hg.) (1895): Urmesstischblatt, Bande V, Blatt 3, Maßstab 1:25000, Original von 1852 mit Nachträgen von 1895.
TK25 - 1895
PREUßISCHES REICHSAMT FÜR LANDESAUFNAHME: (Hg.) (1905): Messtischblatt, Blatt 2604 Schraplau, Maßstab 1:25000, 1903.
TK25 - 1903
PREUßISCHES REICHSAMT FÜR LANDESAUFNAHME: (Hg.) (1918): Messtischblatt, Blatt 2604 Schraplau, Maßstab 1:25000, Original von 1905 mit Nachträgen von 1912.
TK25 - 1912
PREUßISCHES REICHSAMT FÜR LANDESAUFNAHME: (Hg.) (1919): Messtischblatt, Blatt 2604 Schraplau, Maßstab 1:25000, Original von 1905 mit Nachträgen von 1919.
TK25 - 1919
PREUßISCHES REICHSAMT FÜR LANDESAUFNAHME: (Hg.) (1938): Messtischblatt, Blatt 2604 Schraplau, Maßstab 1:25000, Original von 1905 mit Nachträgen von 1931.
TK25 - 1931
MINISTERIUM FÜR NATIONALE VERTEIDIGUNG DER DDR (Hg.) (1956): Topographische Karte 1:25000 (Ausgabe Staat), Blatt M32-24-D-a Teutschenthal, 1954.
TK25 - 1954
MINISTERIUM DES INNEREN DER DDR (Hg.) (1972): Topographische Karte 1:10000 (Ausgabe Volkswirtschaft), Blatt 1105-411 Langenbogen, 1970.
TK10 - 1970
MINISTERIUM DES INNEREN DER DDR (Hg.) (1978): Topographische Karte 1:10000 (Ausgabe Volkswirtschaft), Blatt 1105-411 Langenbogen, 1980.
TK10 - 1980
48
MINISTERIUM FÜR NATIONALE VERTEIDIGUNG DER DDR (Hg.) (1988): Topographische Karte 1:25000 (Ausgabe Staat), Blatt M32-24-D-a Teutschenthal, 1986.
TK25 - 1986
LANDESAMT FÜR LANDESVERMESSUNG UND DATENVERARBEITUNG SACHSEN-ANHALT (Hg.) (1994):Topographische Karte 1:10000, Blatt M32-24-D-a-1 Langenbogen, 1994.
TK10 - 1994
LANDESAMT FÜR VERMESSUNG UND GEOINFORMATION SACHSEN-ANHALT (Hg.) (2011a): Digitale Topographische Karte 1:10000, Blatt 4536-NO Langenbogen, 2011.
DTK10 - 2011
LANDESAMT FÜR VERMESSUNG UND GEOINFORMATION SACHSEN-ANHALT (Hg.) (2011b): Digitale Topographische Karte 1:25000, Blatt 4536 Teutschenthal, 2011.
DTK25 - 2011
A
Abb. A1: Gantt-Diagramm - Arbeitsplanung GIS-Projektmanagement (Quelle: eigene Darstellung -
Sebastian Schenk)
B
Gewässer
1817 1852
1912 1994
Tab. A1: Landschaftswandel anhand der Gewässer. (Quelle: eigene Darstellung - Kristian Möller )
C
Feuchtwiesen
1872 1919
1980 2011
Tab. A2: Landschaftswandel anhand von Feuchtwiesen. (Quelle: eigene Darstellung - Helen Kollai )
D
1817
1872
1954
1994
Wald
Tab. A3: Landschaftswandel anhand von Waldflächen. (Quelle: eigene Darstellung - Sarah Engel)
E
Kartenbeispiel
Grube /BöschungDigitale Topographische Karte 1:25000
2011
Grube /BöschungDigitale Topographische Karte 1:10000
2011
Grube /BöschungTopographische Karte 1:10000
1994
Grube /BöschungTopographische Karte 1:10000 Ausgabe Volksw.
1970, 1980
Grube /BöschungTopographische Karte 1:25000 Ausgabe Staat
1954, 1986
GrubeMesstischblätter 1:25000
1903, 1912, 1919, 1931
GrubeDeckersches Kartenwerk
1817,
Preuß. Urmesstischblätter
1852, 1872, 1895
BeschreibungZeichen-
vorschrift
Kartenwerk Kartenbeispiel
Grube /BöschungDigitale Topographische Karte 1:25000
2011
Grube /BöschungDigitale Topographische Karte 1:10000
2011
Grube /BöschungTopographische Karte 1:10000
1994
Grube /BöschungTopographische Karte 1:10000 Ausgabe Volksw.
1970, 1980
Grube /BöschungTopographische Karte 1:25000 Ausgabe Staat
1954, 1986
GrubeMesstischblätter 1:25000
1903, 1912, 1919, 1931
GrubeDeckersches Kartenwerk
1817,
Preuß. Urmesstischblätter
1852, 1872, 1895
BeschreibungZeichen-
vorschrift
Kartenwerk
Tab. A4: Signaturenvergleich für „Grube“ bzw. „Böschung“. (Quelle: eigene Darstellung - Maria Herbig)
F
Kartenbeispiel
KircheDigitale Topographische Karte 1:25000
2011
Kirche groß/
Kirche klein
Digitale Topographische Karte 1:10000
2011
Große Kirche mit Turm/
Kirche mit Turm
Topographische Karte 1:10000
1994
KircheTopographische Karte 1:10000 Ausgabe Volksw.
1970, 1980
Kirche mit TurmTopographische Karte 1:25000 Ausgabe Staat
1954, 1986
KircheMesstischblätter 1:25000
1903, 1912, 1919, 1931
steinerne Kirche/
hölzerne Kirche
Deckersches Kartenwerk
1817,
Preuß. Urmesstischblätter
1852, 1872, 1895
BeschreibungZeichen-
vorschrift
Kartenwerk Kartenbeispiel
KircheDigitale Topographische Karte 1:25000
2011
Kirche groß/
Kirche klein
Digitale Topographische Karte 1:10000
2011
Große Kirche mit Turm/
Kirche mit Turm
Topographische Karte 1:10000
1994
KircheTopographische Karte 1:10000 Ausgabe Volksw.
1970, 1980
Kirche mit TurmTopographische Karte 1:25000 Ausgabe Staat
1954, 1986
KircheMesstischblätter 1:25000
1903, 1912, 1919, 1931
steinerne Kirche/
hölzerne Kirche
Deckersches Kartenwerk
1817,
Preuß. Urmesstischblätter
1852, 1872, 1895
BeschreibungZeichen-
vorschrift
Kartenwerk
Tab. A5: Signaturenvergleich für „Kirche“. (Quelle: eigene Darstellung - Maria Herbig)
G
Kartenbeispiel
LandstraßeDigitale Topographische Karte 1:25000
2011
Landstraße mit/ ohne Fahrbahntrennung
Digitale Topographische Karte 1:10000
2011
Hauptstraße/ Fern-
und Regionalverkehr
Topographische Karte 1:10000
1994
LandstraßeTopographische Karte 1:10000 Ausgabe Volksw.
1970, 1980
LandstraßeTopographische Karte 1:25000 Ausgabe Staat
1954, 1986
ReichsstraßeMesstischblätter 1:25000
1903, 1912, 1919, 1931
LandstraßeDeckersches Kartenwerk
1817,
Preuß. Urmesstischblätter
1852, 1872, 1895
BeschreibungZeichen-
vorschrift
Kartenwerk Kartenbeispiel
LandstraßeDigitale Topographische Karte 1:25000
2011
Landstraße mit/ ohne Fahrbahntrennung
Digitale Topographische Karte 1:10000
2011
Hauptstraße/ Fern-
und Regionalverkehr
Topographische Karte 1:10000
1994
LandstraßeTopographische Karte 1:10000 Ausgabe Volksw.
1970, 1980
LandstraßeTopographische Karte 1:25000 Ausgabe Staat
1954, 1986
ReichsstraßeMesstischblätter 1:25000
1903, 1912, 1919, 1931
LandstraßeDeckersches Kartenwerk
1817,
Preuß. Urmesstischblätter
1852, 1872, 1895
BeschreibungZeichen-
vorschrift
Kartenwerk
Tab. A6: Signaturenvergleich für „Landstraße“. (Quelle: eigene Darstellung - Maria Herbig)
H
Feldname Beschreibung
Kartenname - Der Titel, wie er auf der Karte angegeben ist.
Bezeichner
- Ein eindeutiger Bezeichner, der zur Zuordnung zur
Karte benutzt wird. Dieser wird diesem Fall von der
Datenbank automatisch generiert und muss daher
nicht manuell vergeben werden.
Kartenwerk
- Zu welchem Kartenwerk bzw. zu welcher
Kartensammlung oder Serie von Daten gehört die
Karte?
Beschreibung - Eine kurze Beschreibung der Karte und deren Inhalt.
Herausgeber - Person bzw. Einrichtung, die für die Veröffentlichung
der Karte zuständig ist.
Urheber - Person bzw. Einrichtung, die für die Ersterstellung der
Karte verantwortlich ist.
Veröffentlichung und
Überarbeitung (2 Attribute)
- Das Jahr, in dem die Karte Veröffentlicht wurde sowie
das Jahr, in dem die letzte Überarbeitung erfolgte,
sofern die Karte überarbeitet worden ist.
Lizenz - Angaben zum Urheberrecht der Karte sowie
zusätzliche Informationen zur Verwendung,
Vervielfältigung, Veröffentlichung etc. Alternativ kann
auch ein Link zu einer Webseite angegeben werden,
auf der die Angaben zum Urheberrecht der Karte zu
finden sind.
Format - Gibt an, in welchem Dateiformat die Karte vorliegt.
Referenzsystem - Eine eindeutige Bezeichnung des verwendeten
Referenzsystems.
Geografisches
Begrenzungsrechteck
- Angabe der geografischen Ausdehnung des
Kartengebietes. Grundlage ist ein achsenparalleles
Begrenzungsrechteck, welches durch die beiden
Breitengrade im Norden und Osten, sowie die
Längengrade im Osten und Westen angegeben wird.
Die Koordinatenangaben erfolgen in Dezimalgrad.
(wird fortgesetzt)
Tab. A7: Beschreibung der Metadatenfelder. (Quelle: eigene Darstellung)
I
Schlüsselwörter - Angabe von aussagekräftigen Schlüsselwörtern und
Bezeichnern, die die Karte am besten beschreiben.
Typischerweise sollte die Liste von Schlüsselwörtern
mindestens die Thematik der Karte, das
Untersuchungsgebiet (evtl. Ortsnamen) sowie
umgangssprachlich verwendete Wörter, Ausdrücke
oder formalisierte Fachbegriffe beinhalten, die den
Inhalt der Karte beschreiben.
Maßstab (optional) - Die räumliche Auflösung der Karte als Maßstabszahl.
Es wird nur der Nenner angegeben, also z.B. 2500 für
1:2500. Dieses Attribut ist im Dublin-Core Standard
optional, allerdings in unserem Falle verbindlich, da
ein Maßstab für alle Karten unbedingt notwendig ist.
Auflösung (optional) - Falls es sich bei der Karte um eine digitale Kopie einer
analogen Karte handelt, kann hier die beim Scannen
verwendete Auflösung in DPI angegeben werden,
insofern bekannt.
Transparenz (optional) - Falls die Karte transparent ist, kann hier der
Transparenzwert in Prozent angegeben werden.
Farbtiefe (optional) - Insofern bekannt, kann hier die Farbtiefe der
Kartengrafik in Bit angegeben werden.
Tab. A7: Beschreibung der Metadatenfelder. (Quelle: eigene Darstellung) (Fortsetzung)