Methoden zur Verarbeitung historischer und topographischer...

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


TK25 - 1919


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

Anhang

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


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


2011


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,


1852, 1872, 1895


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,


1852, 1872, 1895


vorschrift


KircheDigitale Topographische Karte 1:25000

2011

Kirche groß/

Kirche klein


2011

Große Kirche mit Turm/

Kirche mit Turm


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,


1852, 1872, 1895


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


2011

Hauptstraße/ Fern-

und Regionalverkehr


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,


1852, 1872, 1895


vorschrift


LandstraßeDigitale Topographische Karte 1:25000

2011

Landstraße mit/ ohne Fahrbahntrennung


2011

Hauptstraße/ Fern-

und Regionalverkehr


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,


1852, 1872, 1895


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)

Methoden zur Verarbeitung historischer und topographischer...

Documents

Transcript of Methoden zur Verarbeitung historischer und topographischer...