Konzeption eines optimierten Datenmodells zur ... · PDF fileDownloaddiensten (INSPIRE...

GWT-TUD GMBH

Gesellschaft für Wissens- und Technologietransfer der TU Dresden mbH

Konzeption eines optimierten Datenmodells zur Bereitstellung von Visualisierungsdiensten

Abschlussbericht zum Projekt, Mai 2014

Inhaltsverzeichnis

I

INHALTSVERZEICHNIS

Inhaltsverzeichnis ..................................................................................................................................... I

Abbildungsverzeichnis ............................................................................................................................ III

Tabellenverzeichnis ................................................................................................................................ IV

Zusammenfassung .................................................................................................................................. V

1 Projektziele ...................................................................................................................................... 1

1.1 Aufgabenstellung, Erwartungshaltung ..................................................................................... 1

2 Projektorganisation und Projektstruktur .......................................................................................... 2

2.1 Zeitraum .................................................................................................................................. 2

2.2 Projektbeteiligte ....................................................................................................................... 2

2.3 Relevante Vorschriften und Festlegungen .............................................................................. 2

3 Ausgangssituation ........................................................................................................................... 4

3.1 Datenbasis ............................................................................................................................... 4

3.2 Softwareprodukte .................................................................................................................... 7

4 Entscheidungspunkte zur Erstellung des kartographischen Darstellungsdienstes ......................... 8

4.1 Allgemeine Capabilities des kartographischen Darstellungsdienstes ..................................... 8

4.1.1 INSPIRE-konformer WMS oder allgemeiner WMS ............................................................. 9

4.1.2 Basic WMS oder Queryable WMS ...................................................................................... 9

4.1.3 Vordefinierte oder nutzerdefinierte Stile .............................................................................. 9

4.1.4 Verknüpfung mit Datensatzmetadaten .............................................................................. 10

4.1.5 Verknüpfung mit Downloaddiensten .................................................................................. 10

4.1.6 Zugriffseinschränkungen ................................................................................................... 10

4.1.7 Ansprechpartner ................................................................................................................ 11

4.1.8 Unterstützung von Mehrsprachigkeit ................................................................................. 11

4.1.9 Verwendung von Sonderzeichen ...................................................................................... 11

4.1.10 Name des Dienstes ....................................................................................................... 12

4.2 Kartenlayer ............................................................................................................................ 12

4.2.1 Strukturierung der Layer .................................................................................................... 13

4.2.2 Layer-Name ....................................................................................................................... 15

4.2.3 Layer-Titel .......................................................................................................................... 17

4.2.4 Layer-Abstract ................................................................................................................... 18

4.2.5 Zusammenfassung ............................................................................................................ 18

4.3 Abfrage von Objektinformationen (FeatureInfo) .................................................................... 18

4.4 Koordinatensysteme .............................................................................................................. 20

4.5 Stile und Legenden ................................................................................................................ 22

5 Erstellung eines optimierten Datenmodells für Web Map Services .............................................. 26

5.1 Anforderungen an ein weboptimiertes Datenmodell ............................................................. 26

5.2 Multirepräsentationsdatenbanken ......................................................................................... 27

Inhaltsverzeichnis

II

5.3 Übernahme von Daten der GhS ............................................................................................ 29

6 Erstellung eines weboptimierten Datenmodells am Beispiel der TOP Sachsen ........................... 34

6.1 Zusammenfassung der Entscheidungspunkte ...................................................................... 34

6.2 Eigenschaften der weboptimierten Datenbank für die TOP Sachsen ................................... 35

6.3 Erstellung der Übernahmedatenbank .................................................................................... 38

6.4 Erzeugung der weboptimierten Datenbank ........................................................................... 40

6.4.1 Objektfilterung nach Produkten ......................................................................................... 41

6.4.2 Reduktion der Attributinformation ...................................................................................... 41

6.4.3 Reduktion der Geometrieinformation ................................................................................ 42

6.4.4 Musterprojekt für die TOP Sachsen in ArcGIS .................................................................. 43

6.5 Qualitätskontrolle der Datenbasis ......................................................................................... 45

6.5.1 Vollständigkeit und Richtigkeit der thematischen Attribute ............................................... 46

6.5.2 Qualitätsprüfung und Optimierung der Objektgeometrien ................................................. 46

6.5.3 Diskussion zum ATKIS-Objektartenmodell ....................................................................... 51

7 Empfehlungen für das weitere Vorgehen ...................................................................................... 54

Anhang A Anpassung des Styling der GetFeatureInfo-Response ..................................................... 56

A 1 Beispiel angepasstes XSL für GetFeatureInfo ...................................................................... 56

Anhang B Workbenches zur Änderungsdetektion ............................................................................. 58

B 1 Änderungsdetektion für Datenschemata ............................................................................... 58

B 2 Änderungsdetektion für Features .......................................................................................... 59

Anhang C Datenbankschema TOP Sachsen: Feingranulare Schemavariante für die weboptimierte

Datenbank ..................................................................................................................................... 62

Anhang D Stile und Legenden ............................................................................................................ 74

D 1 Algorithmen zur Graustufendarstellung ................................................................................. 74

D 2 Definition von Feature Styles mit SLD ................................................................................... 75

Abbildungsverzeichnis

III

ABBILDUNGSVERZEICHNIS

Abbildung 1: Das ArcMap-Projekt “TOP Sachsen” ................................................................................. 4

Abbildung 2: Attributtabelle für die Feature Class Gebäude ................................................................... 6

Abbildung 3: Publikationsdialog ArcGIS Server WMS - Layer-Name ................................................... 17

Abbildung 4: Vordefinierte Stile nach AdV-WMS-Profil ......................................................................... 23

Abbildung 5: Publizieren eines WMS mit zusätzlichen Stilen via SLD .................................................. 25

Abbildung 6: Strukturierung einer MRDB nach AdV-Produkten ............................................................ 28

Abbildung 7: Transparenter Zugriff auf vorgeneralisierte Daten ........................................................... 29

Abbildung 8: Allgemeines Vorgehen zur Erzeugung der weboptimierten Datenbank aus vorhandenen

Datenbeständen der GhS .............................................................................................................. 30

Abbildung 9: Validierungsprozess zur Übernahme neuer Daten .......................................................... 32

Abbildung 10: Validierungsprozess zur Nachführung der Übernahmedatenbank ................................ 33

Abbildung 11: Ausschnitt aus dem Prozess zum Erstellen der Übernahmedatenbank in Form eines

FME Workflow ............................................................................................................................... 39

Abbildung 12: Abbildung der Attribute für den Sonderfall verschiedener Attributlängen des gleichen

Attributs in Form eines FME Workflow .......................................................................................... 40

Abbildung 13: Prozess zur Reduktion von thematischen Attributen und zum Mapping verschiedener

Attributwerte auf den zur Darstellung benötigten Bezeichner (BEZ) am Beispiel der

Objektartenklassen 2100 bis 2400 für die TOP Sachsen in Form eines FME-Workflow .............. 42

Abbildung 14: Ausschnitt aus dem Musterprojekt TOP Sachsen in ArcGIS ......................................... 44

Abbildung 15: FME Workflow zur Aufbereitung der Gewässerlinien .................................................... 48

Abbildung 16: Zerstückelung einzelner Flussobjekte - Beispiel: Vereinigte Weißeritz in Freital .......... 49

Abbildung 17: Segmentierung von Straßen- und Gewässerobjekten durch die Landesgrenze ........... 50

Abbildung 18: Offensichtliche Geometriefehler am Beispiel der Feature Class Grenzen im

Grenzverlauf mit “Stacheln” und Inseln ......................................................................................... 51

Abbildung 19: Prozess zum Vergleich von Schemata einer bestehenden und aktualisierten

Geodatenbank in Form eines FME Workflow ............................................................................... 59

Abbildung 20: Prozess zur Änderungsdetektion in thematischen Attributen und Speicherung als

Shape- und CSV-Datei mittels Transformer ChangeDetector in Form eines FME Workflow am

Beispiel der TOP Sachsen Feature Class Siedlungsfreiflächen (sie03_f) .................................... 60

Abbildung 21: Prozess zur Änderungsdetektion in Geometrieobjekten und Speicherung als Shape-

und CSV-Datei mittels Transformer ChangeDetector in Form eines FME Workflow am Beispiel

der TOP Sachsen Feature Class Siedlungsfreiflächen (sie03_f) .................................................. 60

Abbildung 22: Variation des Prozesses zur Änderungsdetektion in thematischen Attributen sowie

Geometrieobjekten und Speicherung als Shape-Dateien mittels CRC-Berechnung in Form eines

FME Workflow am Beispiel der TOP Sachsen Feature Class Siedlungsfreiflächen (sie03_f) ..... 61

Abbildung 23: Umwandlung eines RGB-Bild in Graustufen durch verschiedene Algorithmen (links

oben Original ©AdV, rechts oben Helligkeit, links unten Durchschnitt, rechts unten Lichtstärke) 75

Tabellenverzeichnis

IV

Abbildung 24: Beispielergebnis für eine SLD-definierte Punktebene ................................................... 76

TABELLENVERZEICHNIS

Tabelle 1: Beteiligte Personen des Projektes ......................................................................................... 2

Tabelle 2: Layerstruktur “TOP Sachsen” (Ausgangssituation) ................................................................ 5

Tabelle 3: Sonderzeichen und entsprechende Escape-Sequenzen ..................................................... 12

Tabelle 4: Strukturierung der kartenebenen in einem ALKIS-WMS ...................................................... 14

Tabelle 5: Von kartographischen Darstellungsdiensten zu unterstützende Koordinatensysteme ........ 20

Tabelle 6: Zusammenfassung der Entscheidungspunkte ..................................................................... 34

Tabelle 7: Maßstäbe einer MRDB ......................................................................................................... 35

Tabelle 8: Attribute für ein weboptimiertes Datenmodell ...................................................................... 36

Tabelle 9: Zielschema für die weboptimierte Datenbank ...................................................................... 37

Tabelle 10: Anzahl Features in Quelldaten ........................................................................................... 44

Tabelle 11: Anzahl Features optimierter Datensatz .............................................................................. 45

Tabelle 12: Ergebnisse der Objektverknüpfungen ................................................................................ 50

Zusammenfassung

V

ZUSAMMENFASSUNG

Im Rahmen des Projekts wurden Handlungsempfehlungen zur Erstellung eines

weboptimierten Datenmodells entwickelt. Das Datenmodell soll die Bereitstellung von

Darstellungsdiensten über das Internet erleichtern und die geographischen Daten in einer

nutzergerechten Detailtiefe enthalten. Der bereitzustellende Visualisierungsdienst soll auf

dem WMS-Standard des Open Geospatial Consortium (OGC) aufbauen und eine möglichst

gleichbleibende Performanz über alle Maßstäbe und Raumausschnitte liefern.

Die Konzeption eines WMS-konformen Webdienstes, des weboptimierten Datenmodells,

sowie Aussagen zur Datenqualität und Datennachführung bilden die Themenschwerpunkte

des Konzepts, dessen Umsetzbarkeit am Beispiel der TOP Sachsen mit den

Softwareprodukten FME, ArcGIS Desktop sowie ArcGIS Server überprüft wurde.

Die Eigenschaften eines spezifischen weboptimierten Datenmodells können mit der

Zielstellung des bereitzustellenden Visualisierungsdienstes variieren. Zur Bestimmung der

charakteristischen Merkmale dieses Datenmodells werden Entscheidungspunkte entwickelt,

die sowohl behördliche Richtlinien als auch softwaretechnische Standards für

Darstellungsdienste berücksichtigen. In den Entscheidungspunkten werden zunächst

grundlegende Fähigkeiten und Eigenschaften (allgemeine Capabilities) von Diensten

diskutiert. Weiterhin werden Möglichkeiten zur übersichtlichen und handhabbaren

Strukturierung, Benennung und Beschreibung der Karten-Layer aufgezeigt. In den

Entscheidungspunkten zu Koordinatensystemen, Stilen und Legenden werden fachliche und

technische Optionen zur Darstellung der Informationen sowie deren Realisierungsaufwand

beschrieben. Die interaktive Abfrage von Objektinformationen (FeatureInfo) wird separat

skizziert, da die Anpassung der FeatureInfo ebenso wie die der Capabilities ein (teils

ausgeprägtes) technisches Wissen voraussetzt und zugleich mit einem hohen

Nachführungsaufwand verbunden ist. Im Gegensatz dazu ist für die Zusammenstellung der

Layer, der Koordinatensysteme und der Stile überwiegend konzeptionelles Fachwissen, z.B.

über Benennungsvorschriften wie die des AdV, sowie Kenntnis über den Inhalt der

bereitzustellenden Daten erforderlich.

Zusätzliche Annahmen und Anforderungen zur Nutzerfreundlichkeit und der notwendigen

Informationstiefe im weboptimierten Datenmodell können sich an den Bedürfnissen der

Bürger oder Fachnutzer orientieren und sind bei den jeweiligen Entscheidungen zu

berücksichtigen.

Zusammenfassung

VI

Aufbauend auf dem weboptimierten Datenmodell ist ein Workflow erarbeitet worden, der als

Hilfsmittel zur Datenaufbereitung genutzt werden kann und Aspekte der Datenpflege und -

aktualisierung sowie der Bereitstellung konsistenter Daten über verschiedene

Generalisierungsstufen beinhaltet. Es werden beispielhaft Qualitätsprobleme in der

Datenbasis herausgearbeitet und klassifiziert. Entsprechende Lösungsmöglichkeiten sind

sowohl konzeptionell als auch in Form von FME Workflows beschrieben.

Auf Basis der genannten Entscheidungspunkte kann ein weboptimiertes Datenmodell

entwickelt werden. Dafür werden allgemeine Kernanforderungen an die zugrundeliegende

Datenbank des Darstellungsdienstes beschrieben und begründet. Diese beinhalten die

Optimierung für Lesezugriffe, die räumliche Indizierung, die Optimierung für unterschiedliche

Detailstufen und Maßstäbe sowie das Caching. Darauf aufbauend wird das Konzept der

Multirepräsentationsdatenbanken (MRDB) vorgestellt, welches neben der Vorberechnung

von Kartenausschnitten (Tiles, Kacheln) ein geeignetes Instrument zur performanten,

maßstabsabhängigen Darstellung digitaler Karten ist. Statt Daten lediglich in ihrer originären

Form vorzuhalten, speichern MRDB die gleichen Daten maßstabsabhängig in verschiedenen

Repräsentationen. Unter anderem ist damit die Speicherung vorgeneralisierter Daten für

unterschiedliche Maßstabsbereiche möglich.

Für das Erstellen einer weboptimierten Datenbank wird ein Prozessmodell zur Überführung

der Daten entwickelt. Darin ist definiert, wie Daten über einen Importprozess in eine

Übernahmedatenbank übertragen und zuvor validiert werden können. Filter-,

Generalisierungs- und Objektbildungsprozesse auf den Daten der Übernahmedatenbank

erzeugen anschließend die weboptimierte Ziel-MRDB.

Abschließend werden Prozesse zur Nachführung von Daten bzw. zur Qualitätssicherung

diskutiert. Diese erfordern jedoch umfangreichere konzeptionelle und einheitliche

Festlegungen bzw. anwendungsfallspezifische Detailanalysen.

Projektziele

1

1 PROJEKTZIELE

1.1 AUFGABENSTELLUNG, ERWARTUNGSHALTUNG

Im Rahmen des Projekts sollen Handlungsempfehlungen zur Erstellung eines

weboptimierten Datenmodells entwickelt werden, welches die Bereitstellung von

Darstellungsdiensten für topographische Karten über das Internet erleichtert und die

geographischen Daten in einer nutzergerechten Detailtiefe enthält. Der bereitzustellende

Visualisierungsdienst soll auf dem WMS-Standard aufbauen aufbauen und eine möglichst

gleichbleibende Performanz über alle Maßstäbe und Raumausschnitte liefern. Der WMS-

Standard wurde im Jahr 2006 in der Version 1.3 vom Open Geospatial Consortium (OGC)

verabschiedet und dient der Bereitstellung beliebiger digitaler Karten über das Internet. Die

Konzeption eines WMS-konformen Webdienstes, des weboptimierten Datenmodells, sowie

Aussagen zur Datenqualität und Datennachführung bilden die Themenschwerpunkte des

Projekts. Die entwickelten Konzepte und Arbeitsabläufe sollen am Beispiel der TOP Sachsen

mit den Softwareprodukten FME, ArcGIS Desktop sowie ArcGIS Server auf ihre

Umsetzbarkeit überprüft werden.

Die Eigenschaften eines weboptimierten Datenmodells sind zunächst zu konkretisieren. Die

Berücksichtigung relevanter Dokumente von Bund und Land sowie der Europäischen Union

soll zum einen die grundsätzliche Kompatibilität zu übergeordneten Vorschriften und

Festlegungen sicherstellen. Zum anderen sichert dieses Vorgehen die Interoperabilität mit

bestehenden und künftig verfügbaren Diensten des Landes, des Bundes und der

Europäischen Nachbarn. Weitere Annahmen und Anforderungen zur Nutzerfreundlichkeit

und der notwendigen Informationstiefe im weboptimierten Datenmodell können sich sowohl

an den Bedarfen des Bürgers als auch an den Bedürfnissen eines Fachnutzers orientieren.

Aufbauend auf dem weboptimierten Datenmodell ist ein Workflow zu erarbeiten, der die

geodatenhaltenden Stellen (GhS), inklusive des Staatsbetriebes Geobasisinformation und

Vermessung Sachsen (GeoSN), bei der Aufbereitung ihrer Daten unterstützt. Wichtige

Aspekte sind hier die Datenpflege und -aktualisierung sowie die Bereitstellung konsistenter

Daten über verschiedene Generalisierungsstufen. Für ausgewählte Fälle sollen Probleme in

der Datenqualität herausgearbeitet und Lösungsmöglichkeiten aufgezeigt werden.

Projektorganisation und Projektstruktur

2

2 PROJEKTORGANISATION UND PROJEKTSTRUKTUR

2.1 ZEITRAUM

Das Projekt wurde in der Zeit von November 2013 bis April 2014 durchgeführt.

2.2 PROJEKTBEARBEITER Tabelle 1: Beteiligte Personen des Projektes

Name Mail

Christin Henzen [email protected]

Daniel Kadner [email protected]

Stephan Mäs [email protected]

Matthias Müller [email protected]

2.3 RELEVANTE VORSCHRIFTEN UND FESTLEGUNGEN

Im folgenden Abschnitt werden relevante Richtlinien und Vorschriften benannt, die zur

Erstellung eines weboptimierten Datenmodells berücksichtigt werden sollten. Festlegungen,

die im Rahmen des Aufbaus der sächsischen Geodateninfrastruktur erstellt wurden, dienen

dafür als Grundlage. Weiterhin werden Vorschriften und Richtlinien der Koordinierungsstelle

der Geodateninfrastruktur Deutschland (GDI-DE), der Arbeitsgemeinschaft der

Vermessungsverwaltung der Länder der Bundesrepublik Deutschland (AdV) sowie von der

INfrastructure for SPatial InfoRmation in Europe (INSPIRE) ausgewertet.

Internationale Standards und Richtlinien

INSPIRE Durchführungsbestimmung und aktuelle Guidance-Dokumente zu

o INSPIRE Datenthemen

o INSPIRE View Services

http://inspire.ec.europa.eu/index.cfm/pageid/5

OpenGIS® Web Map Server Implementation Specification, Version 1.3.0

http://portal.opengeospatial.org/files/?artifact_id=14416

Projektorganisation und Projektstruktur

3

Dokumente der Geodateninfrastruktur Deutschland (GDI-DE)

Architektur der Geodateninfrastruktur Deutschland, Architektur der GDI-DE - Technik,

30.09.2013

Bereitstellung von Geodaten für INSPIRE, Handlungsempfehlung für GDI-

Koordinierungsstellen und geodatenhaltende Stellen; Version 1.1., 01.10.2013

Handlungsempfehlungen für die Bereitstellung von INSPIRE konformen

Darstellungsdiensten (INSPIRE View Services), 19.12.2011

Handlungsempfehlungen für die Bereitstellung von INSPIRE konformen

Downloaddiensten (INSPIRE Download Services), Version 1.1, 21.10.13

GDI-DE Profil WMS-DE_1.0 Applikationsprofil für Web Map Services innerhalb der

Geodateninfrastruktur Deutschland, Version 10.0, 17.10.2006

http://www.geoportal.de/DE/GDI-DE/Media-

Center/Dokumente/dokumente.html?lang=de

Dokumente der Arbeitsgemeinschaft der Vermessungsverwaltung der Länder der

Bundesrepublik Deutschland (AdV)

AdV-Festlegungen zu den INSPIRE Technical Guidance View Services Version 3.1

(AdV-WMS-Profil 3.0), Version 3.0, Stand: 02.05.2012

Dokumentation zur Modellierung der Geoinformationen des amtlichen

Vermessungswesens (GeoInfoDok), Hauptdokument, Version 6.0.1, Stand:

01.07.2009

ATKIS-Signaturenkatalog für die Digitale Topographische Karte

http://www.adv-online.de/Veroeffentlichungen

Festlegungen und Richtlinien der sächsischen Geodateninfrastruktur

Leistungskatalog des GDI-Servicezentrums (GSZ), Version 1.1

https://geoportal.sachsen.de/download/Leistungskatalog.pdf

Sax4INSPIRE – Abschlussbericht zum Pilotprojekt Geodatenaufbereitung für das

INSPIRE-Thema Schutzgebiete

Ausgangssituation

4

3 AUSGANGSSITUATION

Zur beispielhaften Realisierung eines weboptimierten Datenmodells für kartographische

Visualisierungsdienste wurde vom GeoSN das ArcMap-Projekt “TOP Sachsen”, inklusive

Datenbank, zur Verfügung gestellt. Der Datensatz deckt den kompletten Freistaat Sachsen

ab und enthält sowohl Elemente aus ALK und TK (Abbildung 1, Tabelle 2). Mit Ausnahme

des Gliederungspunktes “Übersicht” sind die thematischen Ebenen weitestgehend am

ATKIS-Objektartenkatalog ausgerichtet. Die Grenzmaßstäbe für die maßstabsabhängigen

Darstellungen sind uneinheitlich gewählt; die stärkste Differenzierung gibt es bei den

Straßen.

3.1 DATENBASIS

Die Diskussion konkreter Fragestellungen und Probleme erfolgt anhand des

Beispielprojektes “TOP Sachsen” des GeoSN und umfasst eine File Geodatabase sowie das

dazugehörige ArcMap-Projekt (Abbildung 1). Das Projekt enthält eine Vielzahl

topographischer Daten, welche über einen WMS mit diversen thematischen Kartenebenen

angeboten werden sollen.

Abbildung 1: Das ArcMap-Projekt “TOP Sachsen”

Ausgangssituation

5

Tabelle 2: Layerstruktur “TOP Sachsen” (Ausgangssituation)

1. Ebene 2. Ebene 3. Ebene max Maßstab min Maßstab

Übersicht

Kreisstadt 75.000

Gemeinden 75.000 250.000

Autobahnen 75.000 3.000.000

Bundestrasse 75.000 500.000

Kreisstrassen 75.000 200.000

Staatsstrassen 75.000 200.000

Gewaesser 75.000

Schutzgebiete 75.000 200.000

Grenzen 75.000

Wald 75.000

Siedlung 75.000

Verkehr

Hubschrauberlandeplatz 30.000

Leitungen 50.000

Masten 30.000

Brücken Tunnel Durchlässe 75.000

Schienenverkehr 75.000

Straßen

Straßen ‐ 1:1.500 1.500

Straßen ‐ 1501:3000 1.500 3.000

Straßen ‐ 3001:20000 3.000 20.000

Straßen ‐ 20001:75000 75.000

Straßen ‐ im Bau 75.000

Verkehrswege ‐ Linien ‐ 20k:30k 20.000 30.000

Verkehrswege ‐ Linien ‐ 1:20k 20.000

Flugverkehrseinrichtungen 75.000

Schienenverkehrseinrichtungen 75.000

Gewässer

Besondere Objekte in Gewässern 75.000

Einrichtungen & Bauwerka an Gewässern 75.000

Schiffsverkehr 75.000

flächenhafte Gewässer 75.000

linienhafte Gewässer 75.000

Siedlung

Bauwerke & sonstige Einrichtungen 15.000

Gebäude 75.000

Sperrgebiete 75.000

Ausgangssituation

6

Schutzgebiete 75.000

Bauwerke und sonstige Einrichtungen 75.000

Siedlungsfreiflächen_Ueberlagerung 75.000

Baulich geprägte Flächen Überlagerung 75.000

Siedlungsfreiflächen 75.000

Baulich geprägte Flächen 75.000

WPL‐Name 30.000

Ortsname 75.000

Strassenverkehr_und_Rollfelder 75.000

Grenzen 75.000

Schutzgebiete 75.000

Vegetation

Felsen ‐ Punkte 15.000

Büsche & Bäume 30.000

Sumpf, Nasser Boden 75.000

Brachland 75.000

Schneisen 25.000

Wald 75.000

Grünland 75.000

Ackerland 75.000

Felsen Flächen 30.000

Abbildung 2: Attributtabelle für die Feature Class Gebäude

Ausgangssituation

7

Die Ausgangsdatenbasis umfasst eine Vielzahl von Attributinformationen, die zum Teil nicht

genutzt und/oder nicht gefüllt sind. Exemplarisch dafür wird in Abbildung 2 auszugsweise die

Attributtabelle für die Feature Class Gebäude dargestellt.

3.2 SOFTWAREPRODUKTE

Zur Realisierung des weboptimierten Datenmodells und des WMS für die TOP Sachsen ist

folgende Software einzusetzen:

ArcGIS Desktop 10.1 / 10.2

ArcGIS Server 10.1 / 10.2

FME Workbench 2013, SP1

Entscheidungspunkte zur Erstellung des kartographischen Darstellungsdienstes

8

4 ENTSCHEIDUNGSPUNKTE ZUR ERSTELLUNG DES KARTOGRAPHISCHEN DARSTELLUNGSDIENSTES

Im Folgenden werden Entscheidungspunkte definiert, die bei der Konzeption und

Bereitstellung des kartographischen Darstellungsdienstes zu klären sind. Für jeden

Entscheidungspunkt werden Vorgaben aus relevanten Vorschriften und Festlegungen sowie

technische Einschränkungen der zur Verfügung stehenden Produkte zusammengestellt. Im

Anschluss werden daraus die möglichen Handlungsoptionen entwickelt.

Der Publikationsprozess für Geodaten ist bereits in verschiedenen Dokumenten des GeoSN

beschrieben. Im Vorkonzept für den Aufbau der zentralen Komponenten der GDI Sachsen ist

der Prozess aus Sicht des GSZ-Geodaten-Pfleger grob granular in den Anwendungsfällen

“Geodaten aufbereiten” und “Darstellungsregeln erstellen” zusammengefasst. Die

Aufbereitung der Geodaten beinhaltet demzufolge die Transformation der Daten in ein

bestimmtes Koordinatenreferenzsystem, das Erstellen und Anwenden von Mapping-Regeln

für die Transformation ins Zielschema sowie das Sichern bzw. zur Verfügung stellen des

aufbereiteten Datensatzes. Das Erstellen der Darstellungsregeln ist laut Vorkonzept durch

das Übersetzen von Visualisierungsvorgaben in SLD und das Setzen des Hintergrunds auf

transparent zu realisieren.

Außerdem wird im Leistungskatalog des GDI-Servicezentrums am Beispiel der Leistung

“Aufbereitung von Geodaten für INSPIRE” definiert, dass Entscheidungskompetenz (und

damit einhergehendes Fachwissen) über den Aufbau der Daten (Datenschema),

Aktualisierungszyklus sowie rechtliche Verbindlichkeiten seitens der geodatenhaltenden

Stelle vorhanden sein muss. Dieses Vorgehen kann ebenfalls als Grundlage für die

Bereitstellung nicht INSPIRE-relevanter Geodaten, wie im vorliegenden Fall, angewendet

werden.

4.1 ALLGEMEINE CAPABILITIES DES KARTOGRAPHISCHEN DARSTELLUNGSDIENSTES

Die Capabilities bezeichnen grundlegende Fähigkeiten und Eigenschaften des

Darstellungsdienstes. Sie umfassen sowohl Dienstoperationen, die zur Client-Server-

Kommunikation vorgesehen sind, als auch Informationselemente, die ergänzende

Informationen zum Dienst oder Karteninhalt enthalten.


9

Die Capabilities sind zwar keine Bestandteile eines weboptimierten Datenmodells, sie

definieren jedoch zusätzliche Anforderungen an dieses. Im Folgenden werden die

Entscheidungspunkte zu den Capabilities kurz beschrieben.

4.1.1 INSPIRE-konformer WMS oder allgemeiner WMS

Die INSPIRE Technical Guidances stellen Implementierungsvarianten für

Darstellungsdienste auf Basis der WMS Spezifikation vor. Falls der zu publizierende Dienst

unter die INSPIRE-Richtlinie fällt, sind die Mindestanforderungen an einen INSPIRE View

Service einzuhalten und die INSPIRE-Empfehlungen zu berücksichtigen. Fällt der Dienst

nicht unter die INSPIRE-Richtlinie, kann es trotzdem sinnvoll sein, den INSPIRE-

Konventionen für View Services so weit wie möglich zu folgen, um den Dienst nahtlos in eine

INSPIRE-konforme Architektur zu integrieren. In diesem Fall sind Aufwand und Nutzen

abzuwägen.

Aus technischer Sicht ist die Bereitstellung INSPIRE-konformer Darstellungsdienste mit der

Basisversion von ArcGIS-Server (derzeit) äußerst aufwendig. Unter anderem sind manuelle

Anpassungen von Konfigurationsdateien nötig. Dieser Prozess ist fehleranfällig und

verursacht bei Aktualisierungen von Daten und Software erheblichen Wartungsaufwand. Aus

diesem Grund wird von ESRI die Erweiterung ArcGIS4INSPIRE zur Verfügung gestellt, die

im Rahmen des Projektes SAX4INSPIRE eingesetzt wird. Es ist grundsätzlich zu prüfen, ob

diese Erweiterung auch für andere Dienste des GeoSN bzw. anderer GhS sinnvoll eingesetzt

werden kann.

4.1.2 Basic WMS oder Queryable WMS

Ein WMS kann sowohl zur einfachen Ausgabe von Karten (Basic WMS) dienen als auch

zusätzlich ortsbezogene Informationen zu Objekten in der Karte (Queryable WMS) liefern.

Die Entscheidung für eine der beiden Varianten hängt letztlich vom Einsatzzweck des

Dienstes ab. Stellt ein Dienst lediglich Hintergrundkarten bereit, so ist ein Basic WMS

ausreichend. Bietet der Dienst jedoch Fachinformationen mit detaillierten

Objektinformationen an, ist in der Regel ein Queryable WMS notwendig.

4.1.3 Vordefinierte oder nutzerdefinierte Stile

Die meisten amtlichen Darstellungsdienste bieten dem Nutzer eine oder mehrere

vordefinierte Stile bzw. Legenden an. Über die SLD-Erweiterung kann ein WMS jedoch auch

nutzerdefinierte Stile zur Visualisierung verwenden. Grundsätzlich ist zu entscheiden, ob der

Dienst ausschließlich vordefinierte Legenden anbieten, oder zusätzlich vom Nutzer definierte


10

Legenden akzeptieren soll. Detaillierte Aussagen zu diesem Punkt finden sich in Kapitel 4.5.

Die Unterstützung nutzerdefinierter Stile ist in der Regel sehr aufwendig - sowohl auf Client-

als auch auf Serverseite.

4.1.4 Verknüpfung mit Datensatzmetadaten

Datensatzmetadaten liefern detaillierte Aussagen zu Thematik, Qualität und Herkunft der

dargestellten Daten. Es ist zu entscheiden, ob der Dienst Verknüpfungen zu

Datensatzmetadaten enthalten soll. Stellt ein Dienst lediglich Hintergrundkarten bereit, so

sind diese Informationen für den Nutzer selten von Bedeutung. Bietet der Dienst

Fachinformationen an, können diese Informationen essenziell sein. In diesem Fall sollten die

diesbezüglichen Festlegungen für gekoppelte Ressourcen in INSPIRE View Services zur

Anwendung kommen. Im AdV-WMS-Profil wird ausgeführt, dass die Nutzung einer

Metadaten-URL derzeit nur begrenzt sinnvoll ist. Solche Metadaten können von Clients

bisher nicht ausgewertet werden (Stand: 5/2012). Da Datensatzmetadaten ohnehin auch in

externen Katalogen abgelegt werden müssen, ist die Verknüpfung innerhalb des WMS-

Layers nicht zwingend erforderlich und wird auch nicht durch den Veröffentlichungsdialog

des ArcGIS Server ermöglicht.

4.1.5 Verknüpfung mit Downloaddiensten

Downloaddienste bieten direkten Zugriff auf die dargestellten Daten - der Nutzer soll damit in

die Lage versetzt werden, die Daten ohne zusätzliche Umwege herunterzuladen. Es ist zu

entscheiden, ob der Visualisierungsdienst Download-Links zu den dargestellten Daten

enthalten soll.

Stellt ein Dienst lediglich Hintergrundkarten bereit, so ist eine Downloadmöglichkeit meist

nicht vorgesehen. Bietet der Dienst Fachinformationen an, ist eine Downloadmöglichkeit

möglicherweise von Interesse. Derzeitige WMS-Clients haben jedoch nur selten die

technischen Fähigkeiten, diese Information auszuwerten und einen direkten Download

anzubieten, sodass die Nutzung einer Download-URL derzeit wenig sinnvoll ist. Da

Downloaddienste auch über Katalogdienste recherchiert werden können ist die Verknüpfung

mit einem WMS nicht zwingend erforderlich und wird auch nicht durch den

Veröffentlichungsdialog des ArcGIS Server ermöglicht.

4.1.6 Zugriffseinschränkungen

Der GeoSN und andere GhS erstellen in einigen Fällen Daten, die nur für einen

beschränkten Nutzerkreis zu Verfügung stehen sollen. In diesem Fall sind geeignete


11

Zugriffseinschränkungen für den Dienst zu definieren und in der Dienstschnittstelle

bekanntzugeben. Wenn keine Zugriffseinschränkungen vorliegen, ist das Element

AccessConstraints mit “None” zu belegen. Der Veröffentlichungsdialog des ArcGIS Server

erlaubt die Definition des Elements AccessConstraints. Eine technische Umsetzung der

Zugriffseinschränkungen muss durch Softwarelösungen von Dritten realisiert werden (bspw.

durch eine Firewall) da dies im ArcGIS Server nicht möglich ist. Im Rahmen der sächsischen

Geobasiskomponenten (GeoBAK) wird zur Absicherung die Teilkomponente

Geodienstesecurity eingesetzt. Informationen zur technischen Absicherung zentraler

Darstellungsdienste sind im Leistungskatalog des GDI Servicezentrums (Abschnitt 4.4.5

Geodienstesecurity) beschrieben. Detaillierte Hinweise zur Definition der

Nutzungsbedingungen sind im WMS-Profil der AdV zu finden.

4.1.7 Ansprechpartner

Der Ansprechpartner für einen Dienst ist für den Dienstnutzer die erste Anlaufstelle bei

Fragen und Problemen. Es ist ein Ansprechpartner für den Dienst zu definieren und in der

Dienstschnittstelle zu hinterlegen.

4.1.8 Unterstützung von Mehrsprachigkeit

Mehrsprachige Dienste sind beispielsweise für die grenzüberschreitende Nutzung von

Geodaten von Bedeutung. Generell ist festzulegen, ob Mehrsprachigkeit für einen

bestimmten Dienst sinnvoll ist. Aktuelle Client- und Serverprodukte sind derzeit aber kaum in

der Lage, mit mehrsprachigen Diensten korrekt umzugehen. Auch ArcGIS-Produkte

(ArcMap, ArcGIS Server) bieten in der Standardversion keinerlei Unterstützung für das

Publizieren und Einbinden mehrsprachiger Dienste. Auf den Aspekt Mehrsprachigkeit wird

daher bei der Konzeption des Datenmodells verzichtet.

4.1.9 Verwendung von Sonderzeichen

Die Capabilities eines WMS werden in der Beschreibungssprache XML kodiert. Es ist daher

nicht möglich die folgenden Sonderzeichen zu nutzen:

&, <, >, “, ‘

Auch ArcGIS verbietet die Verwendung dieser Zeichen. Sollte die Verwendung dieser

Sonderzeichen unumgänglich sein, so besteht die Möglichkeit, sie durch die entsprechenden

Escape-Sequenzen zu ersetzen. Ein zeitgemäßer Client sollte in der Lage sein, diese

Sequenzen zu erkennen und zu dekodieren:


12

Tabelle 3: Sonderzeichen und entsprechende Escape-Sequenzen

Sonderzeichen Escape-Sequenz

& &

< <

> >

“ "

‘ '

Für die Verwendung von Umlauten ist die Situation ähnlich: Aktuelle Software sollte in der

Lage sein, Umlaute korrekt darzustellen, praktisch treten allerdings immer noch häufig

Dekodierungsfehler auf.

Die korrekte Darstellung von Sonderzeichen im Geoportal Sachsen sowie in bekannten

Clients ist zu testen.

4.1.10 Name des Dienstes

Es ist ein geeigneter Name für den Dienst zu vergeben. INSPIRE macht in dieser Hinsicht

keine Vorgaben. Für AdV-Produkte ist im AdV-WMS-Profil folgende Namenskonvention

festgelegt:

<SERVICE>_LÄNDERCODE[_<Produkt>]

Beispiel: WMS_SN_DTK

Auch für Nicht-AdV-Produkte kann diese Konvention sinnvoll sein, da es sich hier um eine

allgemeine Vorschrift zur Benennung produktorientierter Dienste handelt.

4.2 KARTENLAYER

Die bereitgestellten Inhalte von Kartendiensten wie beispielsweise WMS sind durch

Kartenebenen (Layer) strukturiert. Beim Einbinden eines solchen Dienstes kommt der Nutzer

bei der Auswahl der gewünschten Karteninhalte als erstes mit dieser Struktur in Kontakt. Es

ist daher wichtig, die dargebotenen Informationen aus Nutzersicht verständlich, plausibel,

übersichtlich und handhabbar zu strukturieren. Hierfür existieren eine Reihe von Vorgaben

und Empfehlungen auf die im Folgenden näher eingegangen wird.


13

4.2.1 Strukturierung der Layer

Für Datensätze die unter die INSPIRE-Richtlinie fallen, ergeben sich Aussagen zur

Strukturierung der Layer in der Regel aus den Darstellungsregeln für die einzelnen

Datenthemen. Fällt ein bereitgestellter Datensatz unter die INSPIRE-Richtlinie, so sind die

entsprechenden Vorschriften zu beachten. In diesem Fall sind harmonisierte Layernamen

und -stile zu verwenden. Entsprechende Angaben sind in den jeweiligen Kapiteln zu finden.

Für alle übrigen Karten und Produkte sind geeignete Strukturierungsansätze zu finden. Für

die Strukturierung und Benennung der Kartenebenen sind vom GeoSN folgende

Anforderungen in den Dokumenten Checkliste Qualitätssicherung Geodienste - Technische

Sicht bzw. Nutzersicht spezifiziert:

Sortierung bzw. Reihenfolge der Kartenebenen ist korrekt

Kartenebenen sind, sofern sinnvoll, zu Kartenebenengruppen zusammengefasst

Namen von Kartenebenen und Kartenebenengruppen sind interpretierbar und

enthalten keine spezifischen Abkürzungen, Identifikatoren oder Zahlenschlüssel

Performanz wird bei der Strukturierung der Kartenebenen berücksichtigt

Anzahl der Kartenebenen ist gering zu halten

In der ALKIS-WMS Spezifikation des AdV werden konkrete Angaben zur Strukturierung von

Kartenebenen gemacht. Danach enthält ein ALKIS-WMS die folgenden Ebenen zur

Unterscheidung:


14

Tabelle 4: Strukturierung der kartenebenen in einem ALKIS-WMS

Objektartengruppe Siedlung (2000) Objektartengruppe Verkehr (3000)

Wohnbaufläche (2111) Industrie- und Gewerbefläche (2112) Halde (2302) Bergbaubetrieb (2121) Tagebau, Grube, Steinbruch (2301) Fläche gemischter Nutzung (2113) Fläche besonderer funktionaler Prägung (2114) Sport-, Freizeit- und Erholungsfläche 1 Friedhof (2213)

Straßenverkehr (3100) Weg (3102) Platz (3103) Bahnverkehr [Schienenverkehr] (3200) Flugverkehr (3300) Schiffsverkehr (3400)

Objektartengruppe Vegetation (4000) Objektartengruppe Gewässer (5000)

Landwirtschaft 1 Wald (4107) Gehölz (4108) Heide (4104) Moor (4105) Sumpf (4106) Unland und vegetationslose Fläche 1

Fließgewässer 1 Hafenbecken (3402) Stehendes Gewässer 1 Meer (5111)

1 nicht unmittelbar auf eine ATKIS-Objektart abbildbar

Eine ähnliche Strukturierung ergibt sich für andere AdV-Produkte aus der

Normalisierungsvorschrift für Layernamen (siehe Abschnitt 4.2.2).

Technische Einschränkungen

Bei der Verwendung von ArcGIS (ArcMap und ArcGIS Server) ist eine zusätzliche

Einschränkung zu beachten: Innerhalb eines Layers (ausgenommen sind Gruppenlayer)

muss ein homogener Geometrietyp (entweder Punkt oder Linie oder Fläche) verwendet

werden. Innerhalb einer ATKIS-Objektart sind jedoch oft mehrere Geometrietypen zulässig.

Soll eine solche Objektart über ArcGIS verfügbar gemacht werden, bleibt in der

Standardausführung nur die Möglichkeit, separate Sub-Layer für die jeweiligen

Geometrietypen zu erstellen (z.B. “Gewaesser_Linien”, “Gewaesser_Flaechen”).

Aus Nutzersicht ist diese Einschränkung ein gravierender Mangel, da für das Betrachten

einer Karte der Geometrietyp der zugrundeliegenden Daten eigentlich keine Rolle spielen

sollte.


15

Es ist künftig zu prüfen, ob neue ArcGIS-Versionen oder -Erweiterungen diese

Einschränkung aufheben1. Darüber hinaus ist zu prüfen, ob die Erweiterung

ArcGIS4INSPIRE hier eine bessere Lösung ermöglicht.

Nachfolgend werden die einzelnen Elemente der Ebenenstruktur im Detail diskutiert.

4.2.2 Layer-Name

Kartenebenen sind in Darstellungsdiensten über ihre Namen adressierbar. Obwohl der

Name primär in der Client-Server-Interaktion auf Protokollebene verwendet wird, stellen ihn

viele Clients für Kartendienste auch als Klartext für den Nutzer dar. Der Name eines Layers

ist damit das zentrale Strukturierungselement für Kartenebenen.

Die primäre Einschränkung für Layer-Namen ergibt sich aus der WMS-Spezifikation selbst:

Der Name eines Layers muss innerhalb des Dienstes eindeutig sein. Das bedeutet, das

insbesondere Sub-Layer nicht den gleichen Namen tragen dürfen.

Die INSPIRE-Direktive definiert Konventionen für Layernamen für INSPIRE-Datenthemen.

Fällt ein bereitgestellter Datensatz unter die INSPIRE-Richtlinie, so sind die entsprechenden

Vorschriften zu beachten. Für das Beispiel Transportnetze sind die zu verwendenden Layer-

Namen im entsprechenden Dokument2, Kap. 11.1 “Layer Types” festgelegt. Danach werden

die dort definierten Objekte in äußerst feingranularen Layern gesammelt (z.B.

TN.RailTransportNetwork.RailwayStationArea). Für komplexe kartographische Produkte wie

die TOP Sachsen ist dieses Vorgehen weder nötig noch sinnvoll.

Auch die Festlegungen für Produkte der AdV verweisen für die Vergabe von Layer-Namen

auf die INSPIRE-Vorschriften. Für Fälle, in denen INSPIRE keine Namenskonventionen

definiert, muss der Layer-Name laut AdV nach dem folgenden Muster aufgebaut sein:

<Land>_<Produkt>[_<Ebene>]

Beispiel: SN_TOP1000_Gewaesser_Flaechen, SN_TOP1000_Verkehr

<land> entspricht dem Subcode des Länderkürzels nach ISO 3166-2. Bundesbehörden

stellen den Ebenen jeweils ein 'de' voran.

1 Das Produkt Geoserver bietet hierfür sogenannte „Group Layer“ 2 D2.8.I.7 INSPIRE Data Specification on Transport Networks – Guidelines


16

<produkt> trägt eine Bezeichnung, die den fachlichen Inhalt der Ebene oder des Dienstes

(wenn nur 1 Ebene vorhanden ist) kennzeichnet. Für das Produkt sind die einheitlichen

Bezeichner für Kartenprodukte des amtlichen deutschen Vermessungswesens zu

verwenden.

<ebene> dient der weiteren detaillierten Spezifikation des dargestellten Inhalts und ist nur

anzugeben, wenn innerhalb einer Ebene mindestens zwei weitere Unterebenen (wie bspw.

'gewaesser', 'hoehenlinien', 'symbole' etc.) existieren.

Als Sonderzeichen für die Trennung der Namenselemente wird der Unterstrich (_)

vorgeschrieben. Die AdV-Vorschrift beschränkt den Zeichenvorrat für Layernamen auf den

Bereich ['a-z', '0-9', '_'] - und zwar ohne Umlaute. Der Bezeichner “Gewässer” muss danach

als “Gewaesser” geführt werden.


Seit der Einführung von ArcGIS 10.1 können Layernamen sowohl automatisch als auch

nutzerdefiniert vergeben werden. Bei der automatischen Vergabe werden die WMS Layer

durchnummeriert; in diesem Fall können die Layertitel (s. nächster Abschnitt) frei gewählt

werden. Die Nummerierung der Layer widerspricht jeder guten Praxis und den o.g.

Festlegungen und kann daher nicht empfohlen werden.

Ab ArcGIS 10.1 können Kartenebenen auch mit nutzerdefinierten Klarnamen auf einem

WMS publiziert werden. In diesem Fall wird der Ebenenname im ArcMap-Projekt als

Layername und als Layertitel verwendet. Daher müssen in dieser Variante alle

Ebenennamen der Eindeutigkeitsforderung aus der WMS-Spezifikation genügen. Außerdem

dürfen folgende Zeichen nicht im Layer-Namen auftauchen3:

& < > " ' ? @ = $ ~ ^ ` # % * ( )

Zufriedenstellend ist weder die automatische noch die nutzerdefinierte Vergabe von

Layernamen. Es ist daher zu prüfen ob ArcGIS4INSPIRE bessere Möglichkeiten zur

unabhängigen Vergabe von Titeln und Namen bietet. In Abwägung der Vor- und Nachteile

beider Lösungen wird die Verwendung von nutzerdefinierten Layernamen (“Use Layer

Names from the map document”, Abbildung 3) empfohlen, da dieses Vorgehen mit den

Vorgaben der AdV konsistent ist.

3 http://resources.arcgis.com/en/help/main/10.1/index.html#//00sq00000095000000


17

Abbildung 3: Publikationsdialog ArcGIS Server WMS - Layer-Name

4.2.3 Layer-Titel

Für alle WMS-Layer sind aussagekräftige Titel zu wählen. Für alle Produkte, die unter die

INSPIRE-Richtlinie fallen oder AdV-Produkte sind, müssen außerdem die entsprechenden

Richtlinien berücksichtigt werden.


In ArcGIS kann bei der Vergabe nutzerdefinierter Layernamen der jeweilige Layertitel nicht

mehr frei gewählt werden. Die Titel erscheinen dann relativ sperrig und werden mit

zunehmender Schachtelungstiefe sehr lang. In der Standardversion von ArcGIS kann

lediglich eine angepasste XML-Datei mit den WMS-Capabilities bereitgestellt werden. Dieser

Eingriff muss jedoch händisch erfolgen und die separaten XML-Dateien müssen bei Dienst-

und Softwareaktualisierungen nachgeführt werden.


18

Es sollte ferner geprüft werden, ob die Erweiterung ArcGIS4INSPIRE hier eine bessere

Lösung ermöglicht.

4.2.4 Layer-Abstract

Der Layer-Abstract enthält eine kurze Beschreibung der dargestellten Informationen. Für

Daten und Produkte, die unter die INSPIRE-Richtlinie fallen, müssen die entsprechenden

Vorgaben berücksichtigt werden. Für AdV-Produkte ist der Layer-Abstract frei wählbar.


ArcGIS selbst stellt keine Funktion zur Verfügung, die ein sinnvolles Ausfüllen des Layer-

Abstracts ermöglicht. Der Abstract entspricht immer dem jeweiligen Ebenennamen im

ArcMap-Dokument. Die Anpassung des Abstracts erfordert zusätzliche Anpassungen der

Capabilities-XML-Dateien. Dieser Eingriff muss händisch erfolgen und die manipulierten

Dateien müssen bei Dienst- und Softwareaktualisierungen nachgeführt werden.

Es sollte ferner geprüft werden, ob die Erweiterung ArcGIS4INSPIRE hier eine bessere

Lösung ermöglicht.

4.2.5 Zusammenfassung

Die gravierendsten technischen Einschränkungen sind die Beschränkungen bei der Vergabe

von Layertitel und -Abstract, welche nur mit hohem Aufwand auf den jeweiligen Layer

angepasst werden können. Die Unterstützung von nur einem Geometrietyp pro Layer führt

außerdem zu einer stärkeren, weniger nutzerfreundlichen Gliederung des Ebenenbaumes.

4.3 ABFRAGE VON OBJEKTINFORMATIONEN (FEATUREINFO)

Die Informationselemente für Objektinformationen sind derzeit nicht standardisiert. Die

WMS-Spezifikation lässt zudem offen, in welchem Format die Objektinformationen

zurückgeliefert werden sollen. Die Verwendung von XML, HTML und Klartext ist gängig;

GML (für vollständige Geoobjekte) wird eher selten verwendet. Das AdV-WMS-Profil fordert

für den Fall, dass ein WMS die Operation GetFeatureInfo unterstützt, mindestens HTML

(Mimetype: text/html) als zu unterstützendes Rückgabeformat. Dessen Inhalt ist zwar nicht

standardisiert, kann aber von vielen Clientprodukten dargestellt werden und bietet vielfältige

Formatierungsmöglichkeiten.

Zunächst bleibt jedoch zu klären, ob die Abfrage von Objektinformationen sinnvoll ist oder

nicht, und welchen Inhalt die Informationselemente bereitstellen sollen.


19

a) Für eine reine “Hintergrundkarte” ist die Funktion überflüssig, da sie ungenutzt bliebe; für

Höhenmodelle (lokale Höhe) oder Straßenkarten (Straße, Hausnummer) kann eine

Objektinformation durchaus sinnvoll sein.

b) Experten haben andere Anforderungen als Bürger. Während Experten durchaus in der

Lage sind, aus einer Fülle von Attributen eine sinnvolle Auswahl zu treffen und auch mit

möglicherweise fehlerhaften Attributwerten umzugehen, werden Nicht-Experten eher

überfordert oder in die Irre geführt. In letztem Fall ist eine maximal mögliche Reduktion der

Objektinformation angebracht.

c) Die Datengrundlage muss die gewünschten Objektinformationen auch tatsächlich

enthalten. Wenn die Punkte a) und b) geklärt sind, ist zu prüfen, ob die Datengrundlage des

Dienstes die erforderlichen oder gewünschten Informationen in ausreichender Qualität

bereitstellen kann. Ist dies nicht der Fall, so sind Wünsche und Möglichkeiten abzuwägen.

Nach erfolgter Prüfung sind also drei Ergebnisse möglich. Die Datenqualität ist:

1) Hinreichend. Die Darstellung von Objektinformationen kann erfolgen.

2) Unzureichend. Auf die Darstellung von Objektinformationen muss verzichtet werden.

3) Unzureichend, aber essentiell. Die Datengrundlage muss vor der Publikation

verbessert werden.

d) Den technischen Möglichkeiten auf der Serverseite müssen äquivalente Fähigkeiten in der

Clientsoftware gegenüber stehen. Viele Clients können inzwischen mit HTML-formatierten

Objektinformationen umgehen. Die Darstellung in XML oder Text funktioniert in einigen

Fällen auch, ist aber nur im Expertenumfeld oder für Spezialanwendungen sinnvoll

anwendbar. Die Auslieferung kompletter Geoobjekte ist derzeit nur in Ausnahmefällen

sinnvoll und in der Regel nur in eng gekoppelten und abgestimmten Client-Server-

Umgebungen zu finden. In jedem Fall ist die korrekte Darstellung der Objektinformationen im

Geoportal und in häufig genutzten Clients zu überprüfen.

Der GeoSN trifft interne Festlegungen zur Qualitätssicherung mit ähnlichen Aussagen. Es

sind folgende Anforderungen aufgeführt:

FeatureInfo ist vorhanden und korrekt, sofern sinnvoll bei Datenbasis

FeatureInfo enthält keine spezifischen Abkürzungen, Identifikatoren oder

Zahlenschlüssel

Spaltenanzahl der FeatureInfo ist größtmöglich reduziert

Spalten der FeatureInfo enthalten ausschließlich benötigte Attribute


20


ArcGIS bietet verschiedene Möglichkeiten eine FeatureInfo individuell zu konfigurieren. Eine

Reduktion der Attributanzahl kann bereits beim Veröffentlichen erfolgen, wenn im

Kontextmenü (“Layer Properties”) zum jeweiligen Layer nur diese entsprechenden “Fields”

aktiviert werden, die auch in der resultierenden FeatureInfo angezeigt werden sollen. Eine

weitere Möglichkeit bietet der Einsatz von Extensible Stylesheet Language Transformations

(XSLT), einer Sprache zur Transformation von XML-Daten. Jenseits dieser Möglichkeiten ist

es natürlich sinnvoll, unnötige Attribute aus der Datenbasis zu entfernen und so zusätzlich

Ressourcen zu sparen. Im Falle einer erheblichen Datenreduktion kann so letztendlich auch

die Leistungsfähigkeit des Kartendienstes verbessert werden.

In der Standardkonfiguration von ArcGIS Server wird ein XSL Stylesheet genutzt, um aus

Geoobjekten eine HTML-Tabelle mit Attributinformationen zu generieren. Das existierende

Stylesheet kann angepasst werden und ist standardmäßig unter folgendem Pfad zu finden:

<Pfad_zur_ArcGIS_Server_Installation>/Styles/WMS/featureinfo_text_html.xsl

Eine Beispielkonfiguration ist in Anhang A zu finden. Eine Anpassung der FeatureInfo über

die Änderung dieser Datei erfolgt global für alle Dienste die auf diesem ArcGIS Server

veröffentlicht sind. Eine individuelle Veränderung einzelner Dienste ist hierüber nur

umständlich umsetzbar.

4.4 KOORDINATENSYSTEME

Die Überlagerung der sächsischen Kartendienste mit Kartendiensten benachbarter Länder,

des Bundes sowie Diensten mit europaweiter Gebietsabdeckung ist nur dann möglich, wenn

eine Mindestmenge von Erdkoordinatensystemen unterstützt wird. Entsprechende

Empfehlungen und Vorgaben aus Bundes- und Europaebene wurden bereits in der GeoBAK

2.0 realisiert. Danach sind folgende Koordinatensysteme von allen kartographischen

Darstellungsdiensten zu unterstützen:

Tabelle 5: Von kartographischen Darstellungsdiensten zu unterstützende Koordinatensysteme

Koordinatensystem Code

WGS84 geographic EPSG:4326

ETRS89 geographic EPSG:4258

ETRS89/LCC Germany EPSG:4839


21

ETRS89, UTM Zone 32N EPSG: 25832

ETRS89, UTM Zone 33N EPSG: 25833

ETRS89/TM32 EPSG:3044

ETRS89/TM33 EPSG:3045

DHDN, Gauß-Krüger Zone 2 EPSG:31466

DHDN, Gauß-Krüger Zone 3 EPSG:31467

DHDN, Gauß-Krüger Zone 4 EPSG: 31468

DHDN, Gauß-Krüger Zone 5 EPSG: 31469

ETRS89, ETRS-LCC EPSG:3034

ETRS89, ETRS-LAEA EPSG:3035

“Web”-Mercator EPSG:3857

RD83, Gauß-Krüger Zone 4 EPSG:3398

RD83, Gauß-Krüger Zone 5 EPSG:3399


Die Darstellung in den geforderten Koordinatensystemen ist mit ArcGIS Server

uneingeschränkt möglich. ArcGIS stellt einen WMS immer im nativen Koordinatensystem

der Datenbasis bereit. Außerdem ist die Definition zusätzlicher Koordinatensysteme während

des Publikationsprozesses möglich; in diesem Fall werden die Daten ad hoc aus dem

Koordinatensystem der Datenbasis in das zusätzlich unterstützte Koordinatensystem

transformiert. Dieser Transformationsschritt ist einerseits rechenintensiv, sodass die

Bereitstellung der Karten in einem der zusätzlichen Koordinatensysteme zu höherer

Serverlast und ggf. zu höheren Latenzen bei der Bereitstellung von Karten führt.

Andererseits entstehen durch den Transformationsschritt ggf. Lagefehler, die zu

Ungenauigkeiten in den ausgelieferten Karten führen. Dieser Fehler ist nicht pauschal zu

quantifizieren.

Für die Konzeption eines weboptimierten Datenmodells für einen bestimmten Datensatz ist

außerdem ein geeignetes Standardkoordinatensystem zu definieren. Idealerweise sollte das

Koordinatensystem so gewählt werden, dass für die Mehrzahl der Anfragen eine zusätzliche

Koordinatentransformation vermieden.


22

4.5 STILE UND LEGENDEN

Die Definition von Stilen (Styles) ermöglicht die Verwendung unterschiedlicher

kartographischer Darstellungen für einen WMS-Layer. In diesem Sinne definieren Styles

kartographische Signaturen und Symbole. Stile für WMS können in unterschiedlicher Art und

Weise definiert werden. Grundsätzlich ist zwischen vordefiniertem und dynamischem Styling

zu unterscheiden (siehe Abschnitt 4.5). Vordefinierte Styles werden serverseitig deklariert

und können von einem WMS Client in der GetMap-Anfrage ausgewählt werden. Zusätzlich

erlaubt der WMS-Standard die Definition mehrerer serverseitiger Stile für einen Layer.

Dynamische Styles werden dagegen nutzerseitig in Form von Styled Layer Descriptors

(SLD) definiert und in einer GetMap-Anfrage an den Dienst übertragen. Bis auf wenige

Ausnahmen kommen in der Praxis nur serverdefinierte Stile zum Einsatz.

Der GeoSN trifft Festlegungen bezüglich der Darstellung in Form von Anforderungen aus

nutzerspezifischer und technischer Sicht. Für die kartographische Darstellung und Legenden

sind folgende Anforderungen spezifiziert:

Durchgängig korrekte und einheitliche Darstellung einzelner Ebenen sowie der

ganzen Karte

Interpretierbare bzw. nachvollziehbare Farbgebung, Symbolisierung und Beschriftung

Ästhetische Kartendarstellung, z.B. durch abgestimmte Farben, sofern möglich

Interpretierbarkeit bei Überlagerung mit anderen Karten gegeben

Lesbarkeit bei Überlagerung mit anderen Karten ist gegeben

Freistellungen von Beschriftungen sind in hellgrau/hellgelb vorzunehmen um die

Lesbarkeit zu erhöhen

Interpretierbarkeit von Legendeninformationen bzw. -texten ist gegeben

Korrekt dargestellte und aussagekräftige Legende ist vorhanden

Das AdV-WMS-Profil4 sieht für einen WMS-Layer drei verschiedene (serverdefinierte) Styles

vor, die je nach Einsatzzweck vom Client verwendet werden können. Neben einer farbigen

und einer Graustufenumsetzung ist ebenso eine Gelbdarstellung (lediglich die Konturen der

Flächen werden hier gelb dargestellt) vorgesehen. Diese drei Varianten sollen durch die

Nutzung des styles-Attributes umgesetzt werden (Abbildung 4):

4 http://www.adv-online.de/AdV-Produkte/Liegenschaftskataster/Download/binarywriterservlet?imgUid=1c3475aa-b4fc-3315-4cdd-0f772e13d633&uBasVariant=11111111-1111-1111-1111-111111111111&isDownload=true


23

Style „default“ – Ausgabe der Farbdarstellung „palette_rgb“ (Standardausgabe)

Style „palette_grau“ – Ausgabe der Graustufendarstellung (Standard 256 Stufen)

Style „gelb“ – Ausgabe der Gelbdarstellung (vorrangig bei der Anwendung auf ALKIS-

Daten, zur Überlagerung mit Luftbildern)

Die Grau- und Gelbdarstellungen eigenen sich besonders für die Überlagerungen mit

anderen thematischen Ebenen.

Abbildung 4: Vordefinierte Stile nach AdV-WMS-Profil

Genauere Informationen über die farbliche Zusammenstellung sowie Kodierung der

verschiedenen Symbole sind aus den ADV-Signaturenkatalogen zu den verschiedenen

Maßstabsbereichen zu entnehmen5. Festlegungen bezüglich einer entsprechenden

Graustufendarstellung werden in diesen Dokumenten jedoch nicht getroffen. Eine kurze

Darstellung gängiger Umwandlungsverfahren von RGB in Graustufen ist in Anhang D 1 zu

finden.

Neben der Definition zur Darstellung existieren nur wenige Informationen über die Definition

von Legenden auf Basis der Signaturen. Eine optische Einteilung in die Hauptthemengebiete

Siedlung, Verkehr, Gewässer, Relief und Grenzen (siehe 4.2.1) wird empfohlen. Die

jeweiligen Bezeichnungen sollen dabei aussagekräftig sein und es besteht die Möglichkeit

auf Grund der Vielzahl an vorhandenen Signaturen und dem meist wenig vorhandenen Platz

mehrere Signaturen nebeneinander abzubilden.

5 http://www.adv-online.de/AdV-Produkte/Geotopographie/Download/


24

Styled Layer Descriptors (SLD)

Die SLD-Spezifikation ist ein Standard zur Formalisierung von Darstellungsstilen. Ein SLD-

Dokument ist ein meist externes XML-Dokument, welches gemäß des genutzten SLD-

Schemas für einzelne Features oder Featuregruppen mit gemeinsamen Attributen einen Stil

zur Darstellung definieren kann. Ein Beispiel für ein solches SLD-Dokument ist in Anhang D

2 dargestellt.6

Die Nutzung von SLD reduziert den Aufwand für die mehrmalige Verwendung des gleichen

Stils in verschiedenen WMS-Diensten. Hierfür muss nur einmalig eine solche SLD-Definition

erstellt werden und kann dann für verschiedene Dienste eingebunden werden. Ein Vorteil bei

der Nutzung externer SLD-Dokumente ist die einfachere Wartbarkeit bei Änderungen in der

Darstellung durch die Trennung von Daten und Darstellungsanweisungen. Komplexere Stile

sind i.d.R. auf ein Datenschema (und dessen Attributwerte) zugeschnitten. Weichen die zu

publizierenden Daten von diesem Schema ab, so muss entweder das Datenschema

angepasst oder ein entsprechend zugeschnittenes SLD-Dokument entwickelt werden.


Beim Einsatz von ArcGIS Server wird der Standardstil für einen WMS-Layer direkt in ArcMap

über die Symbolisierung festgelegt. Mehr als ein Stil pro Layer kann in ArcMap nicht definiert

werden. Der Name des Stils wird automatisch vergeben (“default”) und ist nicht veränderbar.

Die entsprechende Legende (LegendURL) wird automatisch erzeugt. Die Anpassung dieser

Legende erfordert zusätzliche Anpassungen der Capabilities-XML-Dateien. Dieser Eingriff

muss händisch erfolgen und die manipulierten Dateien müssen bei Dienst- und

Softwareaktualisierungen nachgeführt werden.

Seit der Version 10.1 besteht die Option, zusätzliche Stile über ein SLD-Dokument zu

definieren. Diese Stile gelten dann für alle Layer des Dienstes. Beim Publizieren des

Dienstes via ArcMap/ArcCatalog wird dafür ein entsprechendes SLD-Dokument im

Veröffentlichungsprozess angegeben (siehe folgende Abbildung 5). Für die Erstellung des

SLD-Dokuments bietet ArcGIS keinerlei Hilfestellung. Daher ist die Verwendung zusätzlicher

externer Werkzeuge notwendig (z.B. die AAA-Suite zur Erzeugung von Stilen aus den AdV-

6 Beispiel angelehnt an SLD Kochbuch @ http://docs.geoserver.org/latest/en/user/styling/sld-

cookbook/


25

Dokumenten). Ob der ArcGIS Server jegliche SLD-Dokumente korrekt verarbeiten kann war

nicht gesichert zu ermitteln. Alle durchgeführten Tests mit einfachen (!)

Visualisierungsvorschriften waren erfolgreich. Der Nutzen einer zentralen Datenbank für

SLD-Dokumente in Kombination mit einem ArcGIS Server ist jedoch gering, da der

Standard-Stil immer noch in ArcMap manuell nachgebildet werden muss. Derzeit besteht der

einzige Nutzen von SLD in der Möglichkeit, mehrere Stile pro Layer zu definieren.

Abbildung 5: Publizieren eines WMS mit zusätzlichen Stilen via SLD

Erstellung eines optimierten Datenmodells für Web Map Services

26

5 ERSTELLUNG EINES OPTIMIERTEN DATENMODELLS FÜR WEB MAP SERVICES

Die Bereitstellung der Geodaten in optimierter Form ist entscheidend für eine gute

Performanz des Kartendienstes. Aus den bekannten Interaktionsmustern zwischen WMS-

Clients und -Servern werden nachfolgend Anforderungen an das Datenmodell definiert.

Anschließend wird mit Multi-Repräsentationsdatenbanken ein Datenbankmodell vorgestellt,

das diesen Anforderungen Rechnung trägt.

5.1 ANFORDERUNGEN AN EIN WEBOPTIMIERTES DATENMODELL

Die Architektur eines leistungsfähigen, auf Kartendarstellung ausgelegten Datenmodells hat

sich an den typischen Abfragemustern für Kartenausschnitte zu orientieren. Primäre

Interaktionsmuster mit Kartendiensten sind das Hinein- und Herauszoomen sowie das

Verschieben von Kartenausschnitten, das Abfragen von Objektinformationen ist sekundär.

Die Darstellung von Kartenausschnitten geschieht wahlfrei.

Daraus ergeben sich folgende Anforderungen an die Datenbank:

1. Bei allen Zugriffen handelt es sich um reine Lesezugriffe; die Datenbank ist daher auf

reine Lesezugriffe zu optimieren.

2. Anfragen an die Datenbank werden immer für einen bestimmten Raumausschnitt

durchgeführt. Eine räumliche Indizierung der Daten ist unbedingt erforderlich.

3. Anfragen über große Raumausschnitte auf hoch aufgelösten Datenbeständen führen

zu hoher Serverlast und großen Datenströmen zwischen Datenbank und Renderer. In

der Client-Server-Kommunikation kommt es folglich zu hohen Latenzzeiten

(Sekunden pro Request) und schlechtem Datendurchsatz (Byte pro Sekunde);

insbesondere das Abrufen kleinmaßstäbiger Karten ist extrem ressourcenintensiv.

Das Datenmodell hat diesem Fakt Rechnung zu tragen und sollte auf Anfragen in

unterschiedlichen Detailstufen bzw. Maßstäben optimiert sein.

4. Bei wahlfreiem Zugriff auf die Datenbasis ist ein Caching der Anfragen kaum sinnvoll.

Wenn bestimmte Clientprodukte vorrangig auf den Dienst zugreifen kann es dennoch

zu häufig wiederkehrenden Anfragemustern kommen (z.B. durch fest vorgegebene


27

Zoomstufen). In diesem Fall ist zu prüfen, ob mittels HTTP-Caching7 die

Antwortzeiten des Dienstes beschleunigt oder die Serverlast effektiv reduziert. Diese

zusätzliche Optimierung erfolgt unabhängig vom Datenmodell.

5.2 MULTIREPRÄSENTATIONSDATENBANKEN

Neben der Vorberechnung von Kartenausschnitten (Tiles, Kacheln) sind

Multirepräsentationsdatenbanken (MRDB) ein geeignetes Instrument zur performanten,

maßstabsabhängigen Darstellung digitaler Karten. Statt die Daten lediglich in ihrer originären

Form vorzuhalten, speichern MRDB die gleichen Daten in verschiedenen Repräsentationen.

Unter anderem ist damit die Speicherung vorgeneralisierter Daten für unterschiedliche

Maßstabsbereiche möglich. Ähnlich wie bei der Verwendung von Bildpyramiden für

Rasterdaten müssen für die Visualisierung großer Raumausschnitte im Maßstab 1:100.000

nicht mehr großflächig Detaildaten geladen werden. Stattdessen wird auf vorgeneralisierte

Repräsentationen zurückgegriffen, die vereinfachte Geometrie- und Attributinformationen

enthalten. Damit reduziert sich die Komplexität der Datenbankabfrage, das zurückgelieferte

Datenvolumen und folglich die von der Rendering Engine benötigte Rechenzeit für das

Erzeugen der kartographischen Darstellung. Die Verwendung maßstabsabhängiger

Geometrietypen (Fläche - Linie, Fläche - Punkt) für große und kleine Kartenmaßstäbe ist mit

einer MRDB vorgesehen. Die flächenmäßige Aggregation von Einzelobjekten (z.B.

Gebäude) zu größeren Objekten (bebaute Flächen) ist ebenfalls möglich.

Für die Erstellung einer weboptimierten MRDB liegt es nahe, bekannte Produkte der

Vermessungsämter als Ausgangspunkt zu wählen. In Kapitel 4.2 wurde schon die

Strukturierung der Kartenlayer nach AdV-Produkten motiviert. Dieser Ansatz lässt sich auch

auf die Konzeption einer MRDB übertragen. Die unterschiedlichen Repräsentationen der

Daten entsprechen den AdV-Produkten (Abbildung 6). Hinweise zur erforderlichen

thematischen und geometrischen Auflösung sowie den zu verwendenden Geometrietypen

lassen sich aus den entsprechenden AdV-Spezifikationen entnehmen.

7 Im Gegensatz zu einem Tile Cache oder Tiling WMS werden in einem allgemeinen HTTP Cache häufige (oder alle) Serverantworten zwischengespeichert. Dieser Mechanismus ist zum einen im HTTP Standard beschrieben (http://www.ietf.org/rfc/rfc2616.txt) und in gängigen Serverprodukten implementiert. Zum anderen existieren Proxy-Server-Produkte, die ein adaptives Caching durchführen, indem sie die Antworten häufiger Anfragen zwischenspeichern (http://www.squid-cache.org/, http://trafficserver.apache.org/).


28

Abbildung 6: Strukturierung einer MRDB nach AdV-Produkten

Der Einsatz einer produktgetriebenen MRDB in Verbindung mit einer produktgetriebenen

Kartenstruktur im WMS ergibt den in Abbildung 6 dargestellten Datenfluss: Jede Zoomstufe

im Kartenclient kann über den jeweiligen Maßstab eindeutig einem AdV-Produkt auf

Dienstseite zugeordnet werden. Für das Rendern der Karten bezieht der WMS-Server die

notwendigen Daten aus genau einer Repräsentationsschicht in der Datenbank.

Damit erfüllt eine MRDB die in Kapitel 5.1 definierten Anforderungen in folgender Weise:

zu 1): Das Datenmodell ist leseoptimiert, Transaktionen im regulären Betrieb sind nicht

vorgesehen. Daten und Indizes werden einmalig geschrieben, danach wird nur noch lesend

zugegriffen.

zu 2): Bei der Verwendung von ArcGIS erhalten die Datenbanken automatisch räumliche

Indizes.

zu 3): Die produktorientierte Sicht auf den Datenbestand berücksichtigt unterschiedliche

Detailstufen und Objektauflösungen. Je nach Zielmaßstab ist die Datendichte dadurch fein

steuerbar. Insbesondere für kleine Maßstäbe können Geometrien aggregiert oder in

einfachere Typen überführt werden. Die Zahl der Stützpunkte kann je nach Zielauflösung in

den kleinmaßstäbigen Repräsentationsstufen deutlich reduziert werden. Die

produktorientierte Sichtweise umfasst außerdem die Bildung nutzerorientierter

kartographischer Objekte auf dem Datenbestand (z.B. das Zusammenfassen von

Flusssegmenten oder benachbarter Teilflächen gleicher Objektart).

zu 4): Es besteht die Möglichkeit, den Kartendienst mit einem vorgelagerten HTTP-Cache zu

versehen. Der Einsatz eines Tiling Service ist ebenfalls möglich, wurde in der

Aufgabenstellung jedoch explizit ausgeschlossen.


29

Mit diesem Aufbau lässt sich der Datenstrom zwischen Datenbank und Kartenserver bzw.

Renderer sehr feingranular steuern. Bei der Fortschreibung der Basisdaten ist die MRDB im

Allgemeinen jedoch komplett zu aktualisieren. Für einen nachhaltigen Betrieb in einer

operationellen Infrastruktur ist es daher sinnvoll, den Erstellungsprozess der MRDB aus den

vorhandenen Basisdaten weitestgehend zu automatisieren.

Einige Serverprodukte (wie z.B. Geoserver) ermöglichen zusätzlich einen transparenten

Zugriff auf vorgeneralisierte Daten. Abbildung 7 zeigt eine Konfiguration, in der im

Hintergrund eine MRDB arbeitet, der WMS-Server jedoch nur einen Layer mit gleitendem

Maßstab über einen sehr großen Bereich (1:1 - 1:10.000.000) bereitstellt. Das Umschalten

zwischen verschiedenen Produkten geschieht in diesem Fall vollautomatisch im Hintergrund

und ohne Einwirken des Nutzers. Wie bereits in Kapitel 4.2 ausgeführt ist eine solche

Architektur aus Nutzersicht oftmals gewünscht, wird allerdings von ArcGIS bisher nicht

unterstützt.

Abbildung 7: Transparenter Zugriff auf vorgeneralisierte Daten

5.3 ÜBERNAHME VON DATEN DER GHS

Im vorigen Abschnitt wurde die Rolle der weboptimierten Datenbank aus der Sicht des

Kartendienstes beschrieben. Für die Erstellung der Datenbank ist jedoch auch die Kenntnis

der vorgelagerten Prozesse wichtig. Zu diesem Zweck wird nachfolgend ein allgemeines

Prozessmodell für die Überführung von Datenbeständen in ein weboptimiertes Datenmodell

beschrieben.

Aufgabe der Datenbank ist die Bereitstellung korrekter, qualitätsgesicherter und zur

Veröffentlichung bestimmter Daten. Die von der GhS gelieferten Daten sind jedoch teilweise

nicht qualitätsgeprüft und können durchaus Unstimmigkeiten, Lücken, strukturelle Fehler

oder unplausible Geometrien enthalten. Eine Validierung der Daten sollte daher immer


30

erfolgen und entsprechende Qualitätskriterien sind im Voraus für jeden Datensatz zu

definieren. In jedem Fall sind solche Fehler zu eliminieren, die später die Erzeugung der

weboptimierten Datenbank behindern können.

Die möglichen Fehler in den Ausgangsdaten lassen sich wie folgt kategorisieren:

Daten liegen im falschen Schema vor

Daten haben fehlerhafte/unvollständige thematische Attribute

Daten haben fehlerhafte/unvollständige Geometrien

Datensätze sind untereinander inkonsistent

Die ersten drei Fehlerkategorien haben unmittelbare Auswirkungen auf die Erstellung der

weboptimierten Datenbank und müssen im Vorfeld zwingend beseitigt werden.

Konsistenzfehler (wie z.B. Topologie- oder Lagefehler) sind aus technischer Sicht

unproblematisch, führen jedoch zu unkorrekten Karten.

Abbildung 8: Allgemeines Vorgehen zur Erzeugung der weboptimierten Datenbank aus vorhandenen Datenbeständen der GhS

Der schematische Ablauf zur Erzeugung der weboptimierten Datenbank ist in Abbildung 8

dargestellt. Ein oder mehrere Ausgangsdatensätze werden von der GhS übergeben.

Anschließend werden diese Daten in eine Übernahmedatenbank importiert. Im Zuge dieses

Importvorgangs werden Schema, Attribute und Geometrien der Daten validiert. Nach

erfolgter Erstellung der Übernahmedatenbank kann zusätzlich eine Konsistenzprüfung der

übernommenen Daten durchgeführt werden. Die Optimierung des qualitätsgeprüften

Datenbestandes erfolgt im letzten Schritt. Die Prozesse zur Ableitung der verschiedenen

Repräsentationsschichten der MRDB sind im Idealfall als Skripte oder computergesteuerte

Workflows implementiert und können automatisch ausgeführt werden.


31

Ein allgemeiner Importprozess für das Erstellen einer neuen Übernahmedatenbank ist in

Abbildung 9 dargestellt.8 Im Zuge der Übernahme sind zunächst drei Validierungsschritte zu

Schema, Objektattributen und -geometrien durchzuführen. Am Ende des Prozesses sind die

übernommenen Daten strukturell und syntaktisch valide und können von nachgelagerten

QS-Prozessen auf Konsistenz geprüft und ggf. korrigiert und ergänzt werden.

Die Schemaprüfung detektiert fehlende, überzählige oder inkorrekt benannte Attribute

sowie Attribute falschen Datentyps. Die nachfolgende Prüfung der thematischen Attribute

bezieht sich auf die Validierung der nicht-geometrischen Attribute. Insbesondere sind hier die

Wertebereiche von Attributen zu prüfen, die von den Generalisierungs- und Filterprozessen

zur Erzeugung der weboptimierten Datenbank verwendet werden oder bereits darzustellende

Objektinformationen beinhalten. Anschließend erfolgt die Geometrieprüfung . Dieser Schritt

behandelt zum einen reine Geometriefehler. Zum anderen kann zusätzlich eine Validierung

gegen die thematischen Attribute stattfinden (z.B. um den Geometrietyp gegen die Objektart

zu validieren). Wie strikt (oder fehlertolerant) die Teilprozesse implementiert werden sollen,

muss im Einzelfall entschieden werden. Einfache Fehler in den Daten können u.U.

automatisch erkannt und korrigiert werden.

8 Eine nach Änderungsarten strukturierte Übersicht ist im Sax4INSPIRE Abschlussbericht (Abschnitt 4.6 enthalten)


32

Abbildung 9: Validierungsprozess zur Übernahme neuer Daten

Für die beispielhafte Realisierung einer weboptimierten Datenbank für die TOP Sachsen ist

die Verwendung eines einfachen Importprozesses ausreichend. Ist darüber hinaus auch eine

kontinuierliche Nachführung der Übernahmedatenbank nötig, muss der Prozess modifiziert

werden (Abbildung 10). Da der GeoSN bisher keine Richtlinie zur Nachführung von

Datensätzen erlassen hat, ist im Einzelfall zu entscheiden, ob eine kontinuierliche

Nachführung der Übernahmedatenbank notwendig ist. Die Alternative zur kontinuierlichen

Nachführung ist das vollständige Neuerzeugen der Übernahmedatenbank.

Ein Importprozess mit integrierter Nachführung der Übernahmedatenbank enthält einen

zusätzlichen Schritt zur Veränderungsdetektion (Abbildung 10, V). Dieser Schritt isoliert

unveränderte, zusätzliche, modifizierte und gelöschte Datensätze (V a-d), die danach

fallweise behandelt werden. Um eine solche Veränderungsdetektion durchzuführen, muss

die GhS in den übergebenen Daten eindeutige Identifikatoren für jeden Datensatz (d.h. für

jedes Feature) einführen und pflegen. Diese Identifikatoren sind notwendig um veränderte

oder gelöschte Features von neu hinzugekommen Features sicher zu unterscheiden. Die

Implementierung eines Nachführungsprozesses ist aufwendig, kann daher nicht allein auf


33

Seiten des Dienstanbieters implementiert werden. Eine enge Abstimmung mit den beteiligten

GhS ist erforderlich.

Abbildung 10: Validierungsprozess zur Nachführung der Übernahmedatenbank

Erstellung eines weboptimierten Datenmodells am Beispiel der TOP Sachsen

34

6 ERSTELLUNG EINES WEBOPTIMIERTEN DATENMODELLS AM BEISPIEL DER TOP SACHSEN

Anhand des ArcGIS-Projektes “TOP Sachsen” ist nachfolgend der Aufbau einer

weboptimierten Datenbank beispielhaft beschrieben. Im Vorfeld werden die notwendigen

Entscheidungen zur WMS-Schnittstelle gemäß Kapitel 4 getroffen. Darauf aufbauend werden

ein entsprechendes Datenbankschema und ein geeigneter Übernahmeprozess entworfen. In

diesem Zuge wird auch kurz auf das Problem der Nachführung und Fortschreibung der

Datenbank eingegangen.

Um den Übernahmeprozess zu illustrieren, werden die in Kapitel 3.1 vorgestellten Daten

reimportiert. Eine vollständige Prüfung der Daten ist im Rahmen des Projektes nicht

vorgesehen. Stattdessen werden typische Qualitätsprobleme im Datensatz angesprochen

und passende Lösungsansätze entwickelt.

6.1 ZUSAMMENFASSUNG DER ENTSCHEIDUNGSPUNKTE

Allgemeine Entscheidungspunkte zum Funktionsumfang der Dienstschnittstelle wurden in

Kapitel 4.1 aufgestellt. Für die Optimierung des Beispielprojektes “TOP Sachsen” sind die

getroffenen Entscheidungen nachfolgend aufgeführt.

Tabelle 6: Zusammenfassung der Entscheidungspunkte

Entscheidungspunkt Entscheidung

4.1.1 – INSPIRE-konformer WMS oder allgemeiner WMS

allgemeiner WMS

4.1.2 - Basic WMS oder Queryable WMS

queryable WMS

4.1.3 - Vordefinierte oder nutzerdefinierte Stile

vordefinierte Legenden

4.1.4 - Verknüpfung mit Datensatzmetadaten

keine Verknüpfung mit Datensatzmetadaten

4.1.5 - Verknüpfung mit Downloaddiensten

keine Verknüpfung mit Downloaddiensten

4.1.6 - Zugriffseinschränkungen keine Zugriffseinschränkungen

4.1.7 - Ansprechpartner Ansprechpartner: Andreas Leiteritz

4.1.8 - Unterstützung von keine Mehrsprachigkeit; deutsche Sprache


35

Mehrsprachigkeit

4.1.9 - Verwendung von Sonderzeichen

keine Sonderzeichen, keine Umlaute

4.1.10 - Name des Dienstes Dienstname: WMS_SN_TOPSN

4.2.1 - Strukturierung der Layer Hierarchische Strukturierung der Layer anhand von Objektarten (grob granular) und Geometrietypen (techn. Einschränkung)

4.2.2 - Layer-Name Benennung nach AdV-WMS-Profil

4.2.3 - Layer-Titel Verwendung des Layernamens (aufgrund techn. Einschränkungen)

4.2.4 - Layer-Abstract Verwendung des Layernamens (aufgrund techn. Einschränkungen)

4.3 - Abfrage von Objektinformationen (FeatureInfo)

Formatierung in HTML, angepasste Attributtabelle

4.4 - Koordinatensysteme Unterstützung aller aufgeführten Koordinatensysteme

4.5 - Stile und Legenden Ein Stil pro Layer, kein SLD. Ähnliche Symbolisierung wie im Beispielprojekt (Kapitel 3.1).

6.2 EIGENSCHAFTEN DER WEBOPTIMIERTEN DATENBANK FÜR DIE TOP SACHSEN

Die weboptimierte Datenbank für die TOP Sachsen soll alle notwendigen (bzw.

vorhandenen) Datensätze für die Maßstäbe 1:1000 bis 1:1.000.000 enthalten. Die Daten

werden in einer MRDB in folgenden Maßstäben aufbereitet:

Tabelle 7: Maßstäbe einer MRDB

Produkt von 1 : ... bis 1 : ...

(ALK) 1 3.000

TK10 3.001 10.500

TK25 10.501 25.000

TK50 25.001 50.000

TK100 50.000 100.000

TK250 100.001 250.000

TK1000 250.001 ∞


36

Als räumliches Koordinatensystem für die Geodatenbank wird das Bezugssystem ETRS89,

UTM Zone 33N (EPSG:25833) verwendet.

Folgende Attribute sind im weboptimierten Datenmodell für die Erzeugung von

Objektinformationen idealerweise vorzuhalten, alle anderen Attribute sind zu entfernen bzw.

auszublenden.

Tabelle 8: Attribute für ein weboptimiertes Datenmodell

Attribut Erläuterung

Name Name des Objekts (z.B. Ortsname, Straßenname, Flurname, ...)

(Länge) Länge eines Straßenabschnitts (nur für linienhafte Geometrien)

(Fläche) Fläche des Objektes (nur für Polygone und Gebiete)

Die Angabe von Längen und Flächen für linienhafte Geoobjekte bzw. Gebiete ist

grundsätzlich wünschenswert. Vorarbeiten am Datensatz haben jedoch gezeigt, dass diese

Informationen in einer für den Nutzer sinnvollen Qualität aus den Geometrien nicht abgeleitet

werden können (z.B. die Länge von Flüssen). Flächen und Längeninformationen können

daher nur für wenige ausgewählte Objekte dargestellt werden.

Ein sehr feingranulares Datenbankschema ist in Anhang C dargestellt: Für jede

Produktkategorie (z.B. TK10, TK 20) sind entsprechende Unterebenen für ATKIS-

Objektarten zu- und abschaltbar. Aus Nutzersicht ist diese feine Unterteilung nicht unbedingt

zweckmäßig, da der Betrachter Objekte auch gut anhand der kartographischen Signatur

bzw. der Legende unterscheiden kann. Eine Grobstrukturierung anhand der Produkte und

1000er Objektarten erscheint daher zweckmäßiger.

Sowohl in der fein- als auch der grobgranularen Strukturierung treten allerdings

Mischgeometrien auf (typischerweise sowohl linien- als auch flächenhafte Objektgeometrien

in einer Strukturierungsebene). Aufgrund technischer Einschränkungen muss daher sowohl

datenbankseitig als auch im ArcMap-Projekt für den WMS nach Geometrietypen

unterschieden werden. Das Schema in Tabelle 9 dient sowohl als Grundlage für die

Strukturierung des WMS als auch für die weboptimierte Datenbank. Die zulässige Toleranz

zur Entfernung unnötiger Stützpunkte wurde für eine Lagegenauigkeit von ±1mm in der Karte

ermittelt:

Toleranz=1*10-3m/Maßstab.


37

Tabelle 9: Zielschema für die weboptimierte Datenbank

TK XX

ADV Layer (Objektkategorie)

Punkt

Linie

Fläche Zugehöriger WMS‐Layer

(Name)* Zu übernehmende Attribute

Sichtbare Attribute GetFeatureInfo

Generalisierungs‐ toleranz [m]

TK1000 SN_TOP1000

1000

Siedlung X SN_TOP1000_Siedlung OBJART Name

Verkehr X X SN_TOP1000_Verkehr OBJART, WDM Name

Gewässer X X SN_TOP1000_Wasser OBJART Name

Grenzen X SN_TOP1000_Grenzen OBJART, APG Name, Fläche

TK250 SN_TOP250

250

Siedlung X X SN_TOP250_Siedlung OBJART, GFK, FKT Name

Verkehr X X X SN_TOP250_Verkehr

OBJART, WDM, FKT, BKT

Name

Vegetation X X SN_TOP250_Vegetation OBJART Name

Gewässer X X X SN_TOP250_Wasser OBJART Name


TK100 SN_TOP100

100

Siedlung X X X SN_TOP100_Siedlung OBJART, GFK, FKT Name



Name

Vegetation X SN_TOP100_Vegetation OBJART Name



TK50 SN_TOP50

50

Siedlung X X X SN_TOP50_Siedlung

OBJART, GFK, FKT, KON

Name



Name

Vegetation X SN_TOP50_Vegetation OBJART Name



TK25 SN_TOP25

25



Name



Name

Vegetation X SN_TOP25_Vegetation OBJART, VEG Name, Fläche




38

TK10 SN_TOP10

10



Name



Name

Vegetation X SN_TOP10_Vegetation OBJART, VEG Name, Fläche



* Bei multiplen Geometrietypen müssen zusätzliche Sub‐Layer mit den Suffixen _Punkte | _Linien | _Flaechen erzeugt werden

6.3 ERSTELLUNG DER ÜBERNAHMEDATENBANK

Der Prozess zur Erstellung der Übernahmedatenbank orientiert sich am allgemeinen

Prozessmodell in Abbildung 8. Da für die Ausgangsdaten weder eine verbindliche

Schemadefinition vorliegt, noch eine Validierungsvorschrift für thematische Attribute und

Geometriedaten existiert, findet eine echte Schemavalidierung nicht statt.

Der Übernahmeprozess wurde in FME implementiert und ist auszugsweise in Abbildung 11

dargestellt. Die Ausgangsdaten werden zunächst eingelesen und nach Objektgeometrien

gefiltert. Die resultierenden punkt-, linien- und flächenhaften Objekte werden anschließend

nach ATKIS-Objektarten sortiert und in die Übernahmedatenbank geschrieben. Aufgrund der

großen Anzahl an Einzelobjekten werden die Klassen anhand der Objektgruppe

(repräsentiert durch die ersten beiden Stellen im Objektartenschlüssel) zusammengefasst.

Feinere Kategorien würden die Datenbank unübersichtlicher machen; gröbere Kategorien

führen - besonders beim Schreiben - zu schlechterer Datenbankperformanz.


39

Abbildung 11: Ausschnitt aus dem Prozess zum Erstellen der Übernahmedatenbank in Form eines FME Workflow

Das Arbeiten mit dynamischen Schemas in FME führte in zwei Fällen zu Problemen:

1. Mehrere Feature Classes in den Ausgangsdaten, die in einer gemeinsamen Feature Class

in der Datenbank zusammengeführt werden sollen, haben unterschiedliche Attributspalten.

Im Datensatz zur TOP Sachsen tritt dieser Fall bei den Feature Classes Gebäude (sie07_f),

Siedlungsfreiflächen als Überlagerung (sie06_f) und Bauwerke & Sonstige Einrichtungen

(sie04_f) auf, die zu einer Feature Class 2300-2300_pg zusammengefasst werden sollen.

Mit dem Verarbeiten von sie04_f als erste Feature Class wird in FME bei eingestelltem

dynamischem Zielschema auch das Schema der Feature Class als Zielschema

übernommen. Dadurch wird das für die Visualisierung benötigte Attribut GFK der Feature

Class sie07_f nicht in die Ziel-Feature Class 2300-2300_pg übernommen. In diesem und

ähnlichen Fällen wurde das Zielschema explizit manuell angegeben.

2. Die zu importierenden Feature Classes belegen gleichnamige Attributspalten mit

unterschiedlichen Datentypen. Dieser Fall tritt bei den Feature Classes Gebäude (sie07_f)

und Bauwerke & Sonstige Einrichtungen (sie04_f) bei den Attributen GN und KN auf, die

beide in der Übernahmedatenbank in die Feature Class 2300_2399_pg gespeichert werden

sollen:


40

sie04_f.KN: String[19] sie04_f.GN: String[77]

sie07_f.KN: String[25] sie07_f.GN: String[84]

Die FME-Routine behandelt zuerst die Feature Class Bauwerke & Sonstige Einrichtungen

und erstellt daraus dynamisch das Zielschema für die neue Feature Class. Danach wird

versucht die Feature Class Gebäude hinzuzufügen. Die angelegte Datenbanktabelle enthält

bereits die Attribute KN und GN vom Typ String mit 19 bzw. 77 Zeichen. Dadurch resultiert

das Schreiben der Attribute des Gebäude-Feature Class (welches längere Strings für die

Attribute KN und GN definiert) in einer Fehlermeldung (Geodatabase Error (-2147219115):

The row contains a bad value. FileGDB Writer: A feature could not be written.).

Um dieses Problem zu beseitigen wurden die Attributlängen in diesen Fällen manuell

definiert. Dazu ist ein neues User Attribute mit dem gleichen Namen im Datenbank-Writer mit

entsprechender Attributlänge zu definieren und die Verknüpfung der Filter-Output-Attribute

zu dem neu erstellten Attribut herzustellen (siehe Abbildung 12).

Abbildung 12: Abbildung der Attribute für den Sonderfall verschiedener Attributlängen des gleichen Attributs in Form eines FME Workflow

6.4 ERZEUGUNG DER WEBOPTIMIERTEN DATENBANK

Die Optimierung der Daten gliedert sich in drei verschiedene Schritte. Zunächst werden für

alle Maßstabsebenen bzw. Produkte nur die darzustellenden Objekte aus der

Übernahmedatenbank herausgefiltert. Im nächsten Schritt erfolgt dann eine Reduzierung der

Attributinformation auf die zur Darstellung sowie zur Abfrage von Objektinformationen

benötigten Attribute. Schließlich werden im Zielmaßstab nicht mehr unterscheidbare Objekte

geometrisch aggregiert und wenn möglich anhand der Mindestdarstellungsdimension im

Zielmaßstab generalisiert. Der Aufbau der weboptimierten Datenbank entspricht


41

weitestgehend der in Kapitel 6.2 festgelegten Struktur nach Maßstabsbereichen und

Geometrietypen. Als Koordinatensystem für Geometriedaten wurde einheitlich ETRS89 /

UTM-33N verwendet.

6.4.1 Objektfilterung nach Produkten

Die Objektfilterung nach Produkten erfolgt gemäß der Attributübersicht in Anhang B. Für alle

Objekte wurde ein Bezeichner definiert und die zur Objektunterscheidung relevanten

Attribute sowie die Objektart mitgeführt.

6.4.2 Reduktion der Attributinformation

Im Ausgangsdatensatz sind zu viele und vor allem ungenutzte Attributinformationen

vorhanden. Die Reduktion der thematischen Attribute erfolgt auf Grundlage des in Abschnitt

6.2 beschriebenen Zielschemas für das weboptimierte Datenmodell. Zusammengefasst sieht

dies die Reduktion auf die Attribute Bezeichner (BEZ) und Länge bzw. Fläche sowie

benötigte Attribute zur Visualisierung vor.

Mittels FME können die Prozesse zur Attributreduktion und zum Mapping auf den

Bezeichner mit Hilfe der Transformer AttributeFilter, AttributeCreator und AttributeCopier

durchgeführt werden.

Die Verknüpfung der verschiedenen Transformer hängt stark von den Ausgangsdaten und

dem gewünschten Zielschema ab. Für die Feature Classes der Objektarten 2100 bis 2400

der TOP Sachsen ist der Reduktions- und Mappingprozess in Abbildung 13 dargestellt.


42

Abbildung 13: Prozess zur Reduktion von thematischen Attributen und zum Mapping verschiedener Attributwerte auf den zur Darstellung benötigten Bezeichner (BEZ) am Beispiel der Objektartenklassen 2100 bis 2400 für die TOP Sachsen in Form eines FME-Workflow

Allein durch Attributreduktion konnte die Größe der Datenbank von 1277 MB auf 736 MB

reduziert werden. Weitere Optimierungen wie die Änderung des Datentyps von Attributen

(z.B. von String auf Integer für Objektarten) können zusätzlichen Speicherplatz sparen und

die Zugriffe auf Objektattribute beschleunigen.

6.4.3 Reduktion der Geometrieinformation

Kleinteilige Geometrieobjekte nehmen einen großen Teil des Speicherplatzes der Daten ein

und führen zu einer immensen Menge an Features in der Datenbank (über 4 Mio. Features

in der Ausgangsdatenbank). Eine Reduktion der Geometriedaten durch das

Zusammenführen von Liniensegmenten und Teilflächen sowie eine maßstabsabhängige

Generalisierung kann das Datenvolumen und die Anzahl der Features in den verschiedenen


43

Repräsentationsebenen deutlich reduzieren. Datenbankabfragen laufen dadurch deutlich

schneller und beanspruchen weniger Arbeitsspeicher.

Für das Zusammenfassen flächenhafter Objekte lassen sich die FME Transformer Dissolver

und Amalgamator verwenden. Während der Dissolver lediglich benachbarte Geometrien

zusammenführt, füllt der Amalgamator zusätzlich Lücken und enge Kavitäten. Die dabei

erreichbare Datenreduktion kann erheblich sein. In den durchgeführten Tests führte der

Einsatz des Amalgamators erwartungsgemäß zu weniger Datenbankobjekten und damit zu

einem geringeren Datenvolumen als die Anwendung des Dissolvers. Die

Ergebnisgeometrien waren allerdings deutlich komplexer als beim Dissolver (stark

durchlöchert und auf sehr große Gebiete ausgedehnt), was sich generell nachteilig auf die

Renderingleistung bei der Datenvisualisierung auswirkt. Da die Anwendung des

Amalgamators zudem äußerst ressourcenintensiv ist (Arbeitsspeicherbedarf bis zu 6GB im

Beispieldatensatz), wurde letztendlich der Dissolver eingesetzt.

Das Zusammenfassen von Linienobjekten erfolgte analog mit dem LineJoiner. Dessen

Funktionsweise und Anwendung ist in Kapitel 6.5.2 zur Objektoptimierung detailliert

beschrieben. Eine Zusammenfassung fragmentierter Objektgeometrien führt auch zu einer

Verbesserung der Darstellungsqualität. Durch die Zusammenfassung der Grenzsegmente

konnte so die ursprüngliche Strich-Punkt-Signatur der sächsischen Landesgrenze wieder

erkennbar gemacht werden.

Im Anschluss an die Aggregation können die Objektgeometrien noch weiter generalisiert

werden. Ein sehr einfaches Verfahren ist die Filterung von Objekten anhand ihrer Größe. So

können z.B. Seen und Teiche, die eine Mindestgröße unterschreiten und im Zielmaßstab

daher ohnehin nicht sichtbar wären von Vornherein aus dem Datenbestand entfernt werden.

Eine weitere Möglichkeit ist die Generalisierung von Objektgeometrien durch Entfernen

überflüssiger Stützpunkte. Als konservative Schätzung für die Generalisierungstoleranz

können die in Tabelle 9 definierten Toleranzwerte verwendet werden.

6.4.4 Musterprojekt für die TOP Sachsen in ArcGIS

Gemäß den getroffenen Entscheidungen wurde ein Musterprojekt für die TOP Sachsen in

ArcGIS erstellt. Die folgende Abbildung 14 zeigt dabei nur einen Teilausschnitt

(SN_TOP1000) aus dem vollständigen Aufbau des Projektes.


44

Abbildung 14: Ausschnitt aus dem Musterprojekt TOP Sachsen in ArcGIS

Durch die Anwendung der verschiedenen zuvor beschriebenen Verfahren zur Objektfilterung

sowie zur Attribut- und Geometriereduktion konnte die ursprüngliche Datenmenge stark

reduziert werden. Die Anzahl der Kartenobjekte wurde von über zwei Millionen (Tabelle 10)

auf etwa 35.000 reduziert (Tabelle 11). Das Datenvolumen der optimierten Daten im Bereich

der TOP1000 beträgt nur noch ca. 10 MB.

Tabelle 10: Anzahl Features in Quelldaten

Feature Class Anzahl der Features

_2100_2199_pg 243.279

_2200_2299_pg 23.646

_3100_3199_pl 1.755.098

_3200_3299_pl 35.170

_3300_3399_pt 117

_3400_3499_pl 32


45

_5100_5199_pg 18.510

_5100_5199_pl 240.108

_7200_7299_pl 36.376

Summe 2.352.336

Tabelle 11: Anzahl Features optimierter Datensatz

Feature Class Anzahl der Features

tk1000_gewaesser_flaechen 15

tk1000_gewaesser_linien 254

tk1000_grenzen_linien 17

tk1000_siedlung_flaechen 26.135

tk1000_verkehr_linien 8563

tk1000_verkehr_punkte 117

Summe 35.101

6.5 QUALITÄTSKONTROLLE DER DATENBASIS

Prozesse zur Qualitätskontrolle und -sicherung sowie zur Pflege und Aktualisierung

vorhandener Dienste sind wichtige Bausteine einer operationellen Infrastruktur zur

Bereitstellung amtlicher Daten. Allgemeine Aussagen zum QS-Prozess wurden bereits in

Kapitel 5.3 getroffen. Eine vollständige Implementierung umfangreicher QS-Prozesse ist im

Rahmen des Projektes nicht vorgesehen. Basierend auf den Erfahrungen mit dem Datensatz

TOP Sachsen werden in diesem Kapitel exemplarische Fälle zu den aufgetretenen

Qualitätsproblemen diskutiert. Die nachfolgenden Betrachtungen können als Grundlage für

die Konzeption und Implementierung von Validierungs- und Korrekturinstrumenten dienen.

Dabei beginnt die Analyse, wie bereits in Kapitel 5.3 beschrieben, für die relevanten

thematischen Attribute und Objektgeometrien. Im Anschluss erfolgt eine kurze Diskussion

einiger Schwächen des ATKIS-Objektartenmodells für die Verwendung als Basis für ein

weboptimiertes Datenmodell.


46

6.5.1 Vollständigkeit und Richtigkeit der thematischen Attribute

Die vorhandenen thematischen Attribute sollten korrekt und nach Möglichkeit vollständig

befüllt sein. Ob bestimmte Attributfelder auch leer oder unvollständig bleiben dürfen, ist

fallweise zu entscheiden.

Im vorliegenden Datensatz wird die Vollständigkeitsanforderung häufig durch die Eingabe

von Leerzeichen umgangen (z.B. beim Attribut GN der linienhaften Gewässer). Bei den

Autobahnen fehlt bei den meisten Streckensegmenten die Kennung (z.B. “A4”). Vereinzelte

fehlerhafte Attribute wie z.B. das linienhafte Gewässer mit dem Namen “e” (Attribut GN, in

der Karte als offensichtlicher Teil des Langhennersdorfer Bachs erkennbar) sind bei der

stichprobenartigen Prüfung der Daten aufgefallen. Eine umfangreiche Prüfung der Daten war

hier aber nicht möglich.

Eine Prüfung, ob die festgelegten thematischen Attribute vollständig befüllt sind, lässt sich

mit FME einfach mit Hilfe des Transformers AttributeFilter prüfen. Für die automatische

Erfassung der fehlenden Attributinformationen bzw. die Prüfung der Richtigkeit der Attribute

wird ein entsprechender Referenzdatensatz zum Vergleich benötigt. In der Regel liegt jedoch

ein solcher, im Idealfall separat erfasster und inhaltlich überlappender, Datensatz nicht vor.

Eine manuelle Prüfung ist meist mit großem Aufwand verbunden.

6.5.2 Qualitätsprüfung und Optimierung der Objektgeometrien

Linien und flächenhafte Objekte sind in den Ausgangsdaten häufig zu stark segmentiert (z.B.

Gewässer / Flächenhafte Gewässer; Gewässer / Linienhafte Gewässer in der TopSachsen).

Die Anzahl der Einzelobjekte im Datenbestand ist dadurch unnötig hoch. Außerdem ist dies

besonders für GetFeatureInfo-Abfragen problematisch, weil zum einen nicht die kompletten

Objekte selektiert werden können (z.B. die Hervorhebung der kompletten Elbe in Sachsen).

Zum anderen lassen sich aus den segmentierten Geometrien nicht die korrekten Werte für

Flächeninhalt und Länge ableiten.

Die Segmentierung lässt sich mit den entsprechenden Operatoren in FME oder ArcGIS leicht

beheben, wenn die zusammengehörigen Segmente z.B. über einen gemeinsamen

Objektnamen oder einen anderen eindeutigen Identifikator gekennzeichnet sind.

Für allgemeine Fehler einzelner Geometrien bietet FME vorgefertigte Transformer

(GeometryValidator) zur Qualitätssicherung, die teilweise auch die erkannten Fehler

beseitigen können. Für digitalisierte Daten bieten sich außerdem Transformer wie


47

SpikeRemover und SliverRemover an (Beseitigung kleiner Linienüberstände bei Polygonen

bzw. Korrektur minimal nicht geschlossener Polygone).

Segmentierung im Gewässernetz

Im Layer “Gewässer - Schiffsverkehr - ver04_l” beinhaltet der Datensatz TOP Sachsen

linienhafte Gewässerachsen, welche vermutlich aus den flächenhaften Gewässern abgeleitet

wurden (gestrichelte Linien innerhalb der Gewässerflächen in Abbildung 16). Da diese

Gewässerachsen in Kombination mit den linienhaften Gewässern das Gewässernetz

augenscheinlich vollständig abbilden, wurden sie als Eingangsdaten für die Erstellung der

optimierten linienhaften Gewässerdaten genutzt (Abbildung 15). In einem ersten Schritt ([1]

in Abbildung 15) wird die Verknüpfung sich berührender Gewässersegmente mit gleichem

Namen die Objektanzahl von 250.000 auf 70.600 reduziert. Einfache Linestrings reichen für

die Abbildung des Gewässernetzes nicht aus, weil damit Flussläufe um Inseln und

Flussgabelungen, wie an Altarmen oder Häfen, nicht abgebildet werden können. Aus diesem

Grund müssen die bisherigen Linestrings in einem weiteren Schritt zu Multilinestrings

zusammengefasst werden. Eine einfache Aggregation aller Flussobjekte mit gleichem

Namen ist hierbei nicht möglich, da die Flussnamen nicht eindeutig sind und Namen wie z.B.

“Erlbach” oder “Mühlbach” relativ häufig vorkommen. Ein anderer Identifikator ist jedoch nicht

vorhanden. Aus diesem Grund werden zunächst die namenlosen Objekte herausgefiltert ([2]

in Abbildung 15). Von den verbleibenden Objekten werden diejenigen selektiert, welche ein

anderes Gewässersegment mit gleichem Namen berühren (Transformator SpatialFilter, [3] in

Abbildung 15), und dann aggregiert ([4] in Abbildung 15). Das Ergebnis beinhaltet 70.300

Gewässerobjekte mit einer korrekten Längenangabe. Davon sind 66.500 Objekte namenlos

und deshalb nicht klar identifizierbar. Die Segmente von Gewässern, welche die

Landesgrenze überschreiten und an anderer Stelle zurückfließen (wie z.B. die Elbe an

mehreren Stellen in der Nähe von Brandenburg) sind durch mehrere Objekte abgebildet

(Abbildung 17). Durch die räumlich getrennten Geometrien und das Nichtvorhandensein

eines eindeutigen Identifikators für die Zugehörigkeit ist dies nicht automatisch zu beheben

(und evtl. gewünscht). Die berechnete Länge der Gewässerobjekte bezieht sich immer nur

auf das jeweilige Segment.


48

Abbildung 15: FME Workflow zur Aufbereitung der Gewässerlinien

Der Datensatz enthält außerdem Fälle von extremer Segmentierung, die automatisiert kaum

zu beheben sind. Abbildung 16 zeigt die flächenhaften Abschnitte der vereinigten Weißeritz

auf der Höhe von Freital. Dazwischenliegend sind linienhafte Flussabschnitte, welche

wiederum durch die flächenhaften Abschnitte unterbrochen sind. In diesem Fall ist die

Aggregation der Liniensegmente nicht möglich, weil die Flächen- und Linienobjekte in

unterschiedlichen Feature Classes liegen und prinzipiell nicht gemeinsam gespeichert

werden können. Dieser Zustand lässt sich wahrscheinlich durch die Erfassungsanweisungen

begründen (Schwellwerte der Gewässerbreite für den Übergang von flächen- zu lininenhafter

Darstellung), ist aber sicher in diesem Ausmaß wenig sinnvoll.


49

Abbildung 16: Zerstückelung einzelner Flussobjekte - Beispiel: Vereinigte Weißeritz in Freital

Segmentierung im Straßennetz

Der Layer Autobahn beinhaltet stark segmentierte linienhafte Geometrien der

Autobahnfahrbahnen, Autobahnkreuze und der Auf- und Abfahrten. Wie bereits beschrieben

fehlt bei den Autobahnsegmenten zum großen Teil die Kennung (z.B. A4), so dass eine

Verknüpfung zu Multiline-Features auf Basis der Autobahnnummerierung (ähnlich wie bei

den linienhaften Gewässern) nicht möglich ist. Die zahlreichen Auffahrten sind aber

entsprechend bezeichnet. Nach der ersten Verknüpfung der Autobahnsegmente mit dem

LineJoiner Transformer ist es mit geringem manuellen Aufwand möglich die Kennzeichner

für die Hauptstrecken nachzuführen und dann durch den Aggregator Transformer

entsprechend zu Multiline-Features zu aggregieren.

Tabelle 12 zeigt die Ergebnisse der Objektverknüpfung für die verschiedenen Objektklassen

mit den FME Transformern LineJoiner für linienhafte und Dissolver für flächenhafte Objekte.

Die FME Workspaces sind in der Anlage zum Dokument mitgeliefert.


50

Abbildung 17: Segmentierung von Straßen- und Gewässerobjekten durch die Landesgrenze

Tabelle 12: Ergebnisse der Objektverknüpfungen

Objektklasse Beschreibung Geometrietyp Anzahl der Objekte im Ursprungs-datensatz

Objektanzahl nach der Verknüpfung

Grenze Verlauf der Landesgrenze, detailliert

linienförmig 4.216 15

UE_Grenze Verlauf der Landesgrenze, generalisiert


geb02_l Grenzen, allgemein

linienförmig 36.376 1.279

ver11_l Verkehrswege linienförmig 486.106 295.540

Autobahnen Autobahnen incl. Auffahrten


gew01_f Flächenhafte Gewässer

flächenhaft 18.510 15.571


51

Inkonsistente Geometrien

Der Verlauf von Polygonen oder Liniengeometrien sollte auch immer konsistent zur Semantik

der jeweiligen Objektklasse sein. Zum Beispiel sollten Landes oder Kreisgrenzen (Feature

Classes: Grenze, UE_Grenze, geb02_l) immer einen geschlossenen Grenzverlauf ohne

Lücken ergeben. Außerdem ist ein Grenzverlauf mit Inseln und “Stacheln” wie in Abbildung

18 bei diesen Objektklassen nicht sinnvoll.

Abbildung 18: Offensichtliche Geometriefehler am Beispiel der Feature Class Grenzen im Grenzverlauf mit “Stacheln” und Inseln

Derartige Fehler zeigen sich nach der Verknüpfung der Objektsegmente, wenn die

resultierenden Objekte nicht die vollständigen Objekte abbilden. Auch die FME Transformer

LineJoiner bzw. Dissolver schaffen hier keine Abhilfe.

6.5.3 Diskussion zum ATKIS-Objektartenmodell

Der Beispieldatensatz ist nach den ATKIS-Objektarten strukturiert. Aus kartographischer

Sicht ist dieses Datenmodell sicherlich sinnvoll; für den Aufbau einer konsistenten

Datenbasis hat der Beispieldatensatz allerdings einige Schwächen die im Folgenden

diskutiert werden.


52

Missverständliche Objektklassenbenennung

Die Namen der Objektklassen und deren hierarchische Gliederung sollten so angelegt sein,

dass sie vom Nutzer unmissverständlich interpretierbar sind. Im vorliegenden Datensatz sind

beispielsweise die Grenzen (ObjektArt 7299) linienhaft erfasst, gehören aber zum

Objektbereich Gebiete (7000). Auch wenn das so in ATKIS vorgegeben ist würde man als

Nutzer in diesem Objektbereich eher flächenhafte Objekte erwarten.

Missverständliche Attributbenennung

Die Namen der thematischen Attribute sollten so vergeben werden, dass sie vom Nutzer

unmissverständlich interpretierbar sind. Im vorliegenden Datensatz wird z.B. das

thematische Attribut Obj_Name verwendet (durch die AdV vorgegeben). Das Attribut

beinhaltet aber nicht den Namen des jeweiligen Geoobjektes (z.B. Elbe) sondern den Namen

der Objektart (z.B. Gewässerachse).

Inhomogene Objektgeometrien

Innerhalb der gleichen Objektart sind in ATKIS unterschiedliche Geometrietypen zulässig.

Diese Praxis ist durch das ISO-Featuremodell und durch langjährige Erfahrungen im

Umgang mit kartographischen Daten entstanden. Die verbreiteten Systeme zur

Geodatenverarbeitung und -speicherung bieten dagegen nur geringe Unterstützung zur

Behandlung von Mischgeometrien. Die meisten Werkzeuge in ArcGIS und FME sind auf die

Verwendung homogener Geometrietypen ausgelegt. Validierungs-, Korrektur- und

Aggregationsprozesse für Mischgeometrien sind viel komplexer als vergleichbare Prozesse

für homogene Geometrien. In einigen Fällen (vgl. Kapitel 6.5.3) können sie gar nicht

implementiert werden.

Uneinheitliche Semantik der Objekte eines Kartenlayers

Die einzelnen Kartenlayer sollten jeweils nur Objekte mit einer vergleichbaren Semantik

beinhalten. D.h. Objekte mit unterschiedlicher Semantik sollten sich auch in

unterschiedlichen Layern befinden. Im Beispieldatensatz beinhaltet der Layer Gewässer -

Schiffsverkehr - ver04_l zwei Arten von Objekten die sich hinsichtlich ihrer Semantik

unterscheiden und eigentlich in verschiedene Layer gehören (Obj_Name entweder

Gewässerachse oder Schifffahrtslinie). Die Schifffahrtslinien beinhalten ausschließlich

Fährverbindungen (i.d.R. senkrecht zu den Gewässerachsen), das heißt die Strecken der

Elbedampfer sind beispielsweise nicht enthalten. Die Gewässerachsen beinhalten auch nicht

schiffbare Flüsse wie z.B. die Weißeritz und weitere kleine Flüsse; sie sind also nicht

geeignet um den Schiffsverkehr darzustellen.


53

Aus Sicht der Qualitätssicherung ist der Aufbau eines robusteren, leichter validierbaren

Schemas für die Datenhaltung wünschenswert. (In diesem Fall ist sicherzustellen, dass sich

aus dem neuen Schema die von ATKIS geforderten Objektarten und Attributinformationen

ableiten lassen.)

Empfehlungen für das weitere Vorgehen

54

7 EMPFEHLUNGEN FÜR DAS WEITERE VORGEHEN

Im folgenden Abschnitt werden potenzielle Anknüpfungspunkte für die Fortführung des

vorgestellten Konzepts für ein weboptimiertes Datenmodell zusammengefasst. Außerdem

wird der Einfluss dieses Konzepts auf weitere Arbeiten des GeoSN bzw. der GhS betrachtet.

1) Das im Bericht vorgestellte Vorgehen zur Konzeption neuer Visualisierungsdienste sollte

vom GeoSN künftig für weitere Datensätze angewendet und anschließend dokumentiert

werden. Die so gewonnen Fallbeispiele können diesen Bericht ergänzen und in einem Best-

Practice-Dokument gebündelt werden. Dieses Dokument sollte in erster Linie GhS

adressieren und diesen als Handlungs- und Entscheidungsgrundlage bei der Bereitstellung

eigener Dienste dienen.

2) Aussagen zu technischen Möglichkeiten und Einschränkungen sind in angemessenen

Zeitabständen zu überprüfen. Der Bericht stellt den Stand der Technik zum Januar 2014 mit

den gegebenen Softwareprodukten (vgl. Kapitel 3.2) dar. Bei Einführung neuer Software

bzw. aktuellerer Versionen sind die Aussagen zu überprüfen und ggf. fortzuschreiben.

Um technische Defizite im ArcGIS Server auszugleichen (siehe Kapitel 4), sollten die

Möglichkeiten der im GeoSN vorhandenen Erweiterung ArcGIS4INSPIRE ausgelotet

werden.

3) Um auch bei einfachen WMS (ungekachelten Diensten) mit Leistungsengpässen die

Performanz zu steigern, bieten sich grundsätzlich Proxyserver für das Caching an (siehe

Kapitel 5.2). Die Effektivität dieser Lösung ist anhand gängiger Nutzungsszenarien vorher zu

prüfen.

4) Die Nachführung bestehender Daten erzeugt einen erheblichen Aufwand bei der

Bereitstellung und Pflege von Webdiensten. Das ist insbesondere dann der Fall, wenn der

GeoSN diese Dienstleistung für eine GhS übernimmt und die Daten in regelmäßigen

Abständen aktualisiert werden. Die Anwendung von Verfahren zur Änderungsdetektion, wie

sie in diesem Bericht vorgestellt wurden, sind nur ein erster Schritt zur Konzeption eines

vollständigen Änderungsmanagements. Eine zusätzliche Konsistenzprüfung der Daten stellt

zusätzliche Anforderungen an die Datenbasis. Die dafür notwendigen Datenmodelle müssten

künftig entwickelt werden.

5) Der Aufwand zur Erstellung und Pflege einer MRDB lässt sich durch automatisierte

Generalisierungsverfahren reduzieren, die kleinere Maßstäbe aus höher aufgelösten Daten

ableiten. Entsprechende Ansätze und Verfahren wurden im Bericht vorgestellt und für

Empfehlungen für das weitere Vorgehen

55

ausgewählte Beispiele in FME umgesetzt. Das eher auf die kartographische Darstellung

ausgerichtete ATKIS-Objektartenmodell verbietet jedoch einen höheren

Automatisierungsgrad. Inkonsistente und unvollständige Datensätze stellen ebenfalls

Hindernisse dar. Effizienzsteigerungen beim Aufbau der MRDB sind – ähnlich wie im Falle

der Nachführung – nur mit verbesserten Datenmodellen zu realisieren.

Anpassung des Styling der GetFeatureInfo-Response

56

ANHANG A ANPASSUNG DES STYLING DER GETFEATUREINFO-RESPONSE

A 1 BEISPIEL ANGEPASSTES XSL FÜR GETFEATUREINFO

Im folgenden Beispiel wird die XSL-Datei

<Pfad_zur_AGS_Installation>/Styles/WMS/featureinfo_text_html.xsl

des ArcGIS Server so modifiziert, dass die Darstellung einer FeatureInfo verändert wird. Eine

URL in der FeatureInfo wird durch die Modifizierung als anklickbarer Link (<a> - Element in

HTML-Syntax) dargestellt, wie z.B. der folgende Link zum Geoportal Sachsen:

<a href=”http://geoportal.sachsen.de” target=”_blank”>Geoportal Sachsen</a>

Der relevante Bestandteil der XSL-Datei beschreibt ein Element mit dem Namen “td” dessen

Inhalt mit dem Wert des XML-Elements “esri_wms:FieldValue” gefüllt wird.

1 <td>

2 <xsl:value-of select="esri_wms:FieldValue"/>

3 </td>

Der folgende Code ersetzt den vorhergehenden und bewirkt, dass zunächst eine

Entscheidung gefällt wird, ob der Wert des Attributs mit “http” oder “www” beginnt oder nicht.

Sollte dies der Fall sein wird innerhalb des “td”-Elements ein Link “a” definiert welcher als

Parameter “href” (setzt einen Verweise auf den Wert) und “target” (_blank bewirkt dass der

Link ein einer neuen Seite geöffnet wird). Wenn dies nicht der Fall ist (<otherwise>), dann

wird wie im vorherigen Beispiel kein Link erzeugt.

1 <xsl:choose>

2 <xsl:when test="starts-with(esri_wms:FieldValue,'http')">

3 <td>

4 <a>

5 <xsl:attribute name="href">


7 </xsl:attribute>

8 <xsl:attribute name="target">_blank</xsl:attribute>


10 </a>

11 </td>

12 </xsl:when>

Anpassung des Styling der GetFeatureInfo-Response

57

13 <xsl:when test="starts-with(esri_wms:FieldValue, 'www')">

14 <td>

15 <a>

16 <xsl:attribute name="href">

17 http://<xsl:value-of select="esri_wms:FieldValue"/>

18 </xsl:attribute>

19 <xsl:attribute name="target">_blank</xsl:attribute>


21 </a>

22 </td>

23 </xsl:when>

24 <xsl:otherwise>

25 <td>


27 </td>

28 </xsl:otherwise>

29 </xsl:choose>

Workbenches zur Änderungsdetektion

58

ANHANG B WORKBENCHES ZUR ÄNDERUNGSDETEKTION

B 1 ÄNDERUNGSDETEKTION FÜR DATENSCHEMATA

Im Rahmen der Bereitstellung eines Visualisierungsdienstes kann es zur Aktualisierung der

zugrundeliegenden Geodaten kommen. Die Aktualisierung kann dabei mit einer

Veränderung des zugrundeliegenden Schemas einhergehen und die Überprüfung des neuen

Schemas erfordern. Das bedeutet, dass veränderte sowie neu hinzu gekommene

Attributinformationen im Rahmen der Qualitätssicherung durch den Geodatenpfleger geprüft

werden müssen. Durch Unterstützung mittels Änderungserkennungsprozess kann die

Prüfung des neuen Schemas stark vereinfacht werden, so dass der Geodatenpfleger nicht

alle Attributinformationen sondern nur neue bzw. veränderte Werte überprüfen muss.

Die nachfolgend abgebildete FME Routine ermittelt diese veränderten und neu

hinzugefügten Attribute und stellt dem Geodatenpfleger eine Übersicht über die zu prüfenden

Attribute bereit. Die Abbildung zeigt zwei FME Reader (links im Bild), die auf das bestehende

bzw. aktualisierte Schema zeigen. Aus den eingelesenen Schemainformationen werden mit

Hilfe zweier ListExploder Transformer (Bildmitte) die beinhalteten Attributlisten der Schemata

aufgetrennt und für einen Vergleich vorbereitet. Dieser Vergleich wird in FME durch einen

ChangeDetector (Attributvergleich) realisiert. Die Ergebnisse werden in einer Log-Datei

festgeschrieben und können zusätzlich zu den Daten gespeichert werden, um Änderungen

über mehrere Updatezyklen hinaus nachvollziehbar zu dokumentieren.


59

Abbildung 19: Prozess zum Vergleich von Schemata einer bestehenden und aktualisierten Geodatenbank in Form eines FME Workflow

B 2 ÄNDERUNGSDETEKTION FÜR FEATURES

Eine Änderungserkennung auf Basis einer ESRI Geodatabase kann in FME auf

verschiedene Weise realisiert werden. Eine Möglichkeit bietet der Transformer

ChangeDetector, mit dessen Hilfe zwei Datenbasen verglichen werden können. Dieser

Transformer liefert als Ergebnis die neu hinzugefügten, gelöschten und unveränderten

Features. Erneuerte Features werden indirekt sowohl als neue als auch als gelöschte

Features ausgewiesen. Um diese Erneuerungen zu ermitteln können wie in Abbildung 21

beschrieben zusätzlich Transformer vom Typ FeatureMerger angewendet werden.

Eine für die Qualitätssicherung wichtige Unterscheidung zwischen Veränderung von

Geometrieobjekten oder thematischen Attributen ist durch entsprechende Konfiguration

(MatchGeometry: None/2D) des ChangeDetector Transformer regelbar (siehe Abbildung 20).

Abbildung 20 zeigt die FME Routine für die Änderungsdetektion von thematischen Attributen

am Beispiel der Feature Class Siedlungsfreiflächen der TOP Sachsen.


60

Abbildung 20: Prozess zur Änderungsdetektion in thematischen Attributen und Speicherung als Shape- und CSV-Datei mittels Transformer ChangeDetector in Form eines FME Workflow am Beispiel der TOP Sachsen Feature Class Siedlungsfreiflächen (sie03_f)

Abbildung 21: Prozess zur Änderungsdetektion in Geometrieobjekten und Speicherung als Shape- und CSV-Datei mittels Transformer ChangeDetector in Form eines FME Workflow am Beispiel der TOP Sachsen Feature Class Siedlungsfreiflächen (sie03_f)

Eine Variation zum oben beschriebenen Prozess der Änderungsdetektion ist die CRC-

Vergleichsmethode (siehe Abbildung 22). Mit Hilfe des Transformers CRCCalculator werden

in FME eindeutige Schlüssel aus allen definierten Attributwerten für jedes Feature erzeugt.

Ein Vergleich dieser Schlüssel von Features der Ausgangsdatenbasis bzw. modifizierten

Datenbasis liefert veränderte bzw. unveränderte Features. Die Ergebnisse dieses

Änderungsdetektionsprozesses werden in Form von vier Shape-Dateien gespeichert, welche

veränderte, unveränderte, neu hinzugefügte oder gelöschte Feature enthalten. Alternativ ist


61

es auch möglich, die Liste der veränderten Features in Form einer CSV (wie in Abbildung

21gezeigt) abzuspeichern.

Abbildung 22: Variation des Prozesses zur Änderungsdetektion in thematischen Attributen sowie Geometrieobjekten und Speicherung als Shape-Dateien mittels CRC-Berechnung in Form eines FME Workflow am Beispiel der TOP Sachsen Feature Class Siedlungsfreiflächen (sie03_f)

Datenbankschema TOP Sachsen: Feingranulare Schemavariante für die weboptimierte Datenbank

62

ANHANG C DATENBANKSCHEMA TOP SACHSEN: FEINGRANULARE SCHEMAVARIANTE FÜR DIE WEBOPTIMIERTE DATENBANK

TK XXX

ADV Layer Kate‐gorie

...hat folgende ADV‐SubLayer

...beinhaltet folgende ADV Signaturen

…entspricht OBJART aus Übernahme‐DB

Attribut aus Übernahme‐DB zur Unterscheidung

Geo‐metrie‐typ

Name des Layer im WMS

TK1000 SN_TOP1000

Siedlung Siedlungsfläche 21XX, 22XX (alle) PG SN_TOP1000_Siedlung

Verkehr SN_TOP1000_Verkehr

Straßenverkehr SN_TOP1000_Verkehr_Straße

Autobahn 3101, 3105, 3106

WDM: 1301 PL

Bundesstraße 3101, 3105, 3106

WDM: 1303 PL

Staatsstraße 3101, 3105, 3106

WDM: 1305 PL

Bahnverkehr SN_TOP1000_Verkehr_Bahn

Eisenbahn 3201 BKT: 1100 PL

Flugverkehr SN_TOP1000_Verkehr_Flug

Flughafen 3301, 3302 ‐ P

Schiffsverkehr SN_TOP1000_Verkehr_Schiff

Schifffahrtslinie 3403 ‐ PL

Gewässer SN_TOP1000_Wasser

Fließgewässer SN_TOP1000_Wasser_Fließend

Wasserlauf 5101 ‐ PL

Kanal 5102, 5103 ‐ PL

Stehendes Gewässer SN_TOP1000_Wasser_Stehend

Binnensee 5112 ‐ PG

Grenzen SN_TOP1000_Grenzen

Staat 7299 APG: 7101 PL

Bundesland 7299 APG: 7102 PL

TK250 SN_TOP250

Siedlung SN_TOP250_Siedlung

Wohnbaufläche Siedlungsfläche 2111 ‐ PG SN_TOP250_Siedlung_Wohnbau

Industrie‐ und Gewerbefläche


2112 ‐ PG SN_TOP250_Siedlung_IndustrieGewerbe

Bergbaubetrieb Bergbaubetrieb 2121 ‐ P SN_TOP250_Siedlung_Bergbau

sonstige Bebauung SN_TOP250_Siedlung_Sonstige


63

Burg 2315 GFK: 1138,1131 P

Kirche 2315 GFK: 1141, 1143, 1145

P

Turm 2316, 2317 FKT: 1301, 1302, 1303, 1304, 1305, 1307, 1308, 1309, 1310,1311,1312

P

Windrad 2317 FKT: 2810 P

Denkmal 2332 ‐ P



Autobahn 3101, 3105, 3106

WDM: 1301 PL


WDM: 1303 PL


WDM: 1305 PL

Gemeindestraße, Kreisstraße

3101, 3105, 3106

WDM: 1306, 1307 PL

Tunnel Straße 3513 ‐ PL

Weg Weg 3102 FKT: 1701 PL SN_TOP250_Verkehr_Wege


Eisenbahn 3201, 3202, 3205

BKT: 1100 PL

Museumsbahn 3201, 3202, 3205

BKT: 1400 PL

Standseilbahn 3201, 3202, 3205

BKT: 2300, 2400, 2500, 2600

PL

Tunnel Bahn ‐


Internationaler Flughafen

3301, 3302 ‐ PG

Rollbahn 3303 ‐ PL

Flughafensignatur 3301, 3302 ‐ P


Schifffahrtslinie 3403 ‐ PL

Vegetation SN_TOP250_Vegetation

Landwirtschaft Landwirtschaft 4101 ‐ PG SN_TOP250_Vegetation_Landwirtschaft

Wald Wald 4107, 4108 ‐ PG SN_TOP250_Vegetation_Wald

Heide Heide 4104 ‐ PG SN_TOP250_Vegetation_Heide

Moor Moor 4105 ‐ PG SN_TOP250_Vegetation_Moor

Sumpf Sumpf 4106 ‐ PG SN_TOP250_Vegetation_Sumpf

Unland und vegetationslose Fläche SN_TOP250_Vegetation_Vegetationslos

Felsen 6211 ‐ P

vegetationslos 4120 ‐ PG



Wasserlauf 5101 PL

Kanal Schifffahrt 5102, 5103 PL

Stehendes Gewässer SN_TOP250_Wasser_Stehend

Binnensee 5112 PG


64

Bebauung SN_TOP250_Wasser_Bebauung

Schleuse 5303 P

Sperrwerk 5302 P


Administrativ SN_TOP250_Grenzen_Administrativ

Staatengrenze 7299 APG: 7101 PL

Landesgrenze 7299 APG: 7102 PL

Regierungsbezirksgrenze 7299 APG: 7103 PL

Kreisgrenze 7299 APG: 7104 PL

Natur SN_TOP250_Grenzen_Natur

Nationalpark 7299 APG: 7301 PL

Naturschutzgebiet 7299 APG: 7302 PL

Truppenübungsplatz 7403 PL

TK100 SN_TOP100







Tagebau, Grube, Steinbruch

Tagebau 2301 ‐ PG SN_TOP100_Siedlung_Tagebau

Sport, Freizeit und Erholungsfläche


2202, 2201, 2227

‐ PG SN_TOP100_Siedlung_SportFreizeitErholung

Friedhof Friedhof 2213 PG SN_TOP100_Siedlung_Friedhof


Kraftwerk 2126 ‐ P

Kläranlage 2129 ‐ P

Sportplatz 2222 ‐ P

Campingplatz 2228 ‐ P

Hochhaus ‐ P

Schloss, Burg 2315 GFK: 1131, 1138 P

Kirche 2315 GFK: 1141, 1143, 1145

P

Treibhaus 2315 GFK: 2741 P

Wasserturm 2316 FKT: 1301 P

Leuchtturm 2316 FKT: 1306 P

Funkturm 2316 FKT: 1308 P

Kirchturm 2316 FKT: 1302 P

Kühlturm 2316 FKT: 1305 P


Archäologische Fundstätte

2331 ‐ P

Denkmal 2332 ‐ P

Leitungen 3531 ‐ PL

Mast 3541 ‐ P



Autobahn 3101, 3105, 3106

WDM: 1301 PL


WDM: 1303 PL


WDM: 1305 PL


65

Kreisstraße, Gemeindestraße

3101, 3105, 3106

WDM: 1306, 1307 PL

Tunnel 3513 ‐ PL

Raststätte 3502 ‐ P

Weg SN_TOP100_Verkehr_Weg

Hauptwirtschaftsweg 3102 FKT: 1701 PL

Wirtschaftsweg 3102 FKT: 1702 PL

Klettersteig ‐ PL

Platz Platz 3103 ‐ PG SN_TOP100_Verkehr_Platz


Eisenbahn 3201, 3202, 3205

BKT: 1100 PL


BKT: 2300, 2600 PL

Schwebebahn 3201, 3202, 3205

BKT: 2500 PL

Sessellift 3201, 3202, 3205

BKT: 2400 PL

Bahnhof 3204, 3501 ‐ P


Flughafen 3301, 3302 ‐ PG

Rollbahn 3303 ‐ PL

Vorfeld 3304 ‐ PG


Schiffsverkehr 3403 ‐ PL

Anleger ‐ ‐


Landwirtschaft SN_TOP100_Vegetation_Landwirtschaft

Ackerland 4101 ‐ PG

Sonderkultur 4109 ‐ PG

Dauergrünland 4102 ‐ PG

Gartenland 4103 ‐ PG


Gehölz Gehölz ??? Unterschied Wald Gehölz?

‐ PG


Moor Moor 4105 ‐ PG SN_TOP100_Vegetation_Moor



Vegetationslos 4120 ‐ PG

Felsen 6211 ‐ PG




Kanal 5102, 5103 ‐ PL

Hafenbecken Hafenbecken 3402 ‐ PG SN_TOP100_Wasser_Hafen

Stehendes Gewässer Stehendes Gewässer 5112 ‐ PG SN_TOP100_Wasser_stehend

Bebauung SN_TOP100_Wass


66

er_Bebauung

Staudamm ‐ ‐ P

Sperrwerk 5302 ‐ P

Schleuse 5303 ‐ P



Staatsgrenze 7299 APG: 7101 PL








TK50 SN_TOP50











2202, 2201, 2227





Umspannstation 2127 ‐ P

Pumpe 2325 ‐ P



Schießstand 2223 ‐ P


Hochhaus ‐ P


Kirche 2315 GFK: 1141, 1145 P

Kapelle 2315 GFK: 1143 P

Krankenhaus 2315 GFK: 1151 P

Windmühle 2315 GFK:1911 P

Wasserbehälter 2315 GFK: 2515 P

Treibhaus 2315 GFK: 2741 PG, P






Schornstein, Schlot, Esse 2317 ‐ P

Höhleneingang 2320 KON: 6003 P



2331 ‐ P

Denkmal 2332 ‐ P

Bildstock, Wegekreuz 2333 ‐ P


Pipelines 3532 ‐ PL

Mast 3541 ‐ P


67



Autobahn 3101, 3105, 3106

WDM: 1301 PL


WDM: 1303 PL


WDM: 1305 PL


3101, 3105, 3106

WDM: 1306, 1307 PL

Tunnel 3513 ‐ PL


Grenzübergang ‐




Fußweg 3102 FKT: 1703 PL

Klettersteig ‐ PL



Eisenbahn 3201, 3202, 3205

BKT: 1100 PL

Museumsbahn 3201, 3202, 3205

BKT: 1400 PL

Straßenbahn 3201, 3202, 3205

BKT: 1201 PL


BKT: 2300, 2600 PL

Schwebebahn 3201, 3202, 3205

BKT: 2500 PL

Materialseilbahn 3201, 3202, 3205

BKT: 2600 PL

Sessellift 3201, 3202, 3205

BKT: 2400 PL

Bahnhof 3204, 3501 ‐ P


Flughafen 3301 ‐ PG

Hubschrauberlandeplatz 3302 FKT: 2006 P

Rollbahn 3303 ‐ PG

Vorfeld 3304 ‐ PG



Anleger ‐ ‐ P









‐ PG


Moor Moor 4105 ‐ PG SN_TOP50_Vegeta


68

tion_Moor




Felsen 6211 ‐ PG




Kanal 5102, 5103 ‐ PL

Gewässerachse 3524 ‐ PL




Staudamm ‐ ‐ P


Schleuse 5303 ‐ P











TK25 SN_TOP25


Wohnbaufläche Wohnbaufläche 2111 ‐ PG SN_TOP25_Siedlung_Wohnbau









2202, 2201, 2227






Pumpe 2325 ‐ P


öffentliches Gebäude 2315 GFK: 1110, 1111, 1112, 1113, 1115, 1121, 1123, 1132, 1134 1135,

P




69


Hochhaus ‐ P


Kirche 2315 GFK: 1141, 1145 P









Förderturm 2316 FKT: 1310 P




Brunnen 2319 ‐ P


Schachtöffnung 2317 KON: 6004 P



2331 ‐ P

Denkmal 2332 ‐ P


Schwimmbecken 2345 ‐ PG



Mast 3541 ‐ P



Autobahn 3101, 3105, 3106

WDM: 1301 PL


WDM: 1303 PL


WDM: 1305 PL


3101, 3105, 3106

WDM: 1306, 1307 PL

Tunnel 3513 ‐ PL


Grenzübergang ‐





Klettersteig ‐ PL



Eisenbahn 3201, 3202, 3205

BKT: 1100 PL

Museumsbahn 3201, 3202, 3205

BKT: 1400 PL

Straßenbahn 3201, 3202, 3205

BKT: 1201 PL


BKT: 2300, 2600 PL

Schwebebahn 3201, 3202, 3205

BKT: 2500 PL


BKT: 2600 PL

Sessellift 3201, 3202, 3205

BKT: 2400 PL

Bahnhof 3204, 3501 ‐ P


70





Vorfeld 3304 ‐ PG



Anleger ‐ ‐ P







Wald ‐ PG SN_TOP25_Vegetation_Wald

Laubwald 4107 VEG: 1000 PG + Muster

Nadelwald 4107 VEG: 2000 PG + Muster

Mischwald 4107 VEG: 3000 PG + Muster


‐ PG

Heide Heide 4104 ‐ PG + Muster

SN_TOP25_Vegetation_Heide

Moor Moor 4105 ‐ PG + Muster

SN_TOP25_Vegetation_Moor

Sumpf Sumpf 4106 ‐ PG + Muster

SN_TOP25_Vegetation_Sumpf



Felsen 6211 ‐ PG




Kanal 5102, 5103 ‐ PL





Staudamm ‐ ‐ P


Schleuse 5303 ‐ P












71

TK10 SN_TOP10


Wohnbaufläche Wohnbaufläche 2111 ‐ PG SN_TOP10_Siedlung_Wohnbau









2202, 2201, 2227






Pumpe 2325 ‐ P


öffentliches Gebäude 2315 GFK: 1110, 1111, 1112, 1113, 1115, 1121, 1123, 1132, 1134 1135,

P




Hochhaus ‐ P


Kirche 2315 GFK: 1141, 1145 P



Polizeistation 2315 GFK: 1171 P

Feuerwehrstation 2315 GFK: 1172 P

Jugendherberge 2315 GFK: 1462 P

Parkhaus 2315 GFK: 2361 P

Tiefgarage 2315 GFK: 2368 P

Hallenbad 2315 GFK: 2821 P

Sanatorium 2315 GFK: 2842 P







Förderturm 2316 FKT: 1310 P




Brunnen 2319 ‐ P


Schachtöffnung 2320 KON: 6004 P

Stollenmundloch, Kellereingang

2320 KON: 6001, 6002 P

Kran 2324 ‐ P


Wasserrad 2316 GFK: 1912 P


2331 ‐ P

Denkmal 2332 ‐ P


Schwimmbecken 2345 ‐ PG



72


Mast 3541 ‐ P



Autobahn 3101, 3105, 3106

WDM: 1301 PL


WDM: 1303 PL


WDM: 1305 PL


3101, 3105, 3106

WDM: 1306, 1307 PL

Tunnel 3513 ‐ PL


Grenzübergang ‐

Parkplatz





Klettersteig ‐ PL



Eisenbahn 3201, 3202, 3205

BKT: 1100 PL

Museumsbahn 3201, 3202, 3205

BKT: 1400 PL

Straßenbahn 3201, 3202, 3205

BKT: 1201 PL


BKT: 2300, 2600 PL

Schwebebahn 3201, 3202, 3205

BKT: 2500 PL


BKT: 2600 PL

Sessellift 3201, 3202, 3205

BKT: 2400 PL

Bahnhof 3204, 3501 ‐ P

S‐Bahn Station

Straßenbahnhaltestelle





Vorfeld 3304 ‐ PG



Anleger ‐ ‐ P







Wald ‐ PG SN_TOP10_Vegetation_Wald

Laubwald 4107 VEG: 1000 PG + Muster

Nadelwald 4107 VEG: 2000 PG + Muster


73

Mischwald 4107 VEG: 3000 PG + Muster


‐ PG

Heide Heide 4104 ‐ PG + Muster

SN_TOP10_Vegetation_Heide

Moor Moor 4105 ‐ PG + Muster

SN_TOP10_Vegetation_Moor

Sumpf Sumpf 4106 ‐ PG + Muster

SN_TOP10_Vegetation_Sumpf



Felsen 6211 ‐ PG




Kanal 5102, 5103 ‐ PL





Staudamm ‐ ‐ P


Schleuse 5303 ‐ P











Stile und Legenden

74

ANHANG D STILE UND LEGENDEN

D 1 ALGORITHMEN ZUR GRAUSTUFENDARSTELLUNG

Es existieren verschiedene Algorithmen zur automatischen Umwandlung eines Rot-Grün-

Blau (RGB) Wertes in einen Graustufenwert. Als Beispiel können die folgenden Algorithmen

genutzt werden, wobei zu beachten ist das dies nur eine kleine Auswahl an möglichen

Verfahren ist:

Helligkeit: Grauwert = (max(R,G,B) + min(R,G,B)) / 2. (reduziert Einfluss der

markanten und weniger markanten Farbwerte)

Durchschnittswert: Grauwert = (R + G + B) / 3

Lichtstärke: Grauwert = 0.21 R + 0.71 G + 0.07 B (ähnlich zu Durchschnitt, aber

menschliche Auffassungsgabe wird beachtet)

Die folgenden Abbildungen (Abbildung 23) verdeutlichen die Auswirkungen der genutzten

Algorithmen zur Umwandlung eines RGB-Wertes in einen Graustufenwert.

Stile und Legenden

75

Abbildung 23: Umwandlung eines RGB-Bild in Graustufen durch verschiedene Algorithmen (links oben Original ©AdV, rechts oben Helligkeit, links unten Durchschnitt, rechts unten Lichtstärke)

D 2 DEFINITION VON FEATURE STYLES MIT SLD

Das folgende Beispiel illustriert die Verwendung von SLD zur Darstellung geographischer

Features.

1 <FeatureTypeStyle>

2 <Rule>

3 <PointSymbolizer>

4 <Graphic>

5 <Mark>

6 <WellKnownName>circle</WellKnownName>

7 <Fill>

8 <CssParameter name="fill">#FF0000</CssParameter>

9 </Fill>

Stile und Legenden

76

10 <Stroke>

11 <CssParameter name="stroke">#000000</CssParameter>

12 <CssParameter name="stroke-width">2</CssParameter>

13 </Stroke>

14 </Mark>

15 <Size>8</Size>

16 </Graphic>

17 </PointSymbolizer>

18 </Rule>

19 </FeatureTypeStyle>

In diesem Beispiel wird eine Regel (Zeile 2) für die Darstellung von Punktgeometrien (3)

definiert. Alle auftretenden Punkte sollen durch Kreise (6) mit einem Durchmesser von 8

Pixeln (15) dargestellt werden. Diese Kreise besitzen eine rote Füllung (7-9) und einen

schwarzen, 2 Pixel breiten Rand (10-13). Ein mögliches Visualisierungsergebnis wird in

Abbildung 24 dargestellt.

Abbildung 24: Beispielergebnis für eine SLD-definierte Punktebene

Herausgeber:

GWT-TUD GMBH Gesellschaft für Wissens- und Technologietransfer der TU Dresden mbH ABAKUS Business-Center Dresden Blasewitzer Straße 43 01307 Dresden Veröffentlichung:

Mai 2014

Konzeption eines optimierten Datenmodells zur ... · PDF fileDownloaddiensten (INSPIRE...

Documents

Transcript of Konzeption eines optimierten Datenmodells zur ... · PDF fileDownloaddiensten (INSPIRE...