Interoperabilität in GIS - Institute of Geodesy and Photogrammetry

Transcrição

Interoperabilität für die
breite Nutzung von
Geoinformation
Weiterbildungstagung 17. und 18. März 2005
Herausgegeben von A. Carosio
Veranstalter
Institut für Geodäsie und Photogrammetrie, ETH Zürich
ETHZ
Laboratoire de Systèmes d'information géographique, ETH Lausanne
EPFL
Ecole d’ingénieurs du Canton de Vaud, Yverdon
EIVD
Fachhochschule beider Basel Nordwestschweiz
FHBB
Schweizerischer Verband für Geomatik und Landmanagement
geosuisse
Konferenz der Kantonalen Vermessungsämter
KKVA
Schweizerische Organisation für Geo-Information
SOGI
Bundesamt für Landestopographie
swisstopo
Koordination der Geoinformationen und der geographischen
Informationssysteme beim Bund
KOGIS
Schweizerischer Ingenieur- und Architektenverein
SIA
Bundesamt für Landwirtschaft
BLW
Deutsche Ausgabe :
Weiterbildungstagung 17. und 18. März 2005
IGP Bericht
Nr. 298 d
ISBN
3-906467-51-1
Interoperabilität für die breite Nutzung von Geoinformation
Herausgegeben von A. Carosio
Edition française :
Journées d‘étude des 17 et 18 mars 2005
IGP Rapport
Nr. 298 f
ISBN
3-906467-52-X
Interopérabilité pour l'utilisation généralisée de la Géoinformation
Textes rassemblés par A. Carosio
©2005
Institut für Geodäsie und Photogrammetrie, ETH Zürich
Alle Rechte vorbehalten
1 Vorwort
Die Verwirklichung der NGDI (Nationale Geodaten-Infrastrukturen) in Europa und
weltweit ist unlösbar mit der Problematik der Vernetzung der Geoinformationssysteme
verbunden. Geodaten gemeinsam nutzen ist eine dringende Notwendigkeit. Dafür
braucht man technische und organisatorische Lösungen. Das Zauberwort, das zum Ziel
führen soll, heisst: Interoperabilität!
In Fachgremien und in Gesprächen mit Fachleuten fällt aber oft auf, dass Fragen und
Lösungsansätze nur zum Teil bekannt sind.
Es schien daher angebracht, eine Weiterbildungstagung zu diesem Thema zu organisieren, um das verfügbare Wissen zu sammeln, darzustellen und zu präsentieren.
Wir glauben, dass es durch die Beteiligung der Organisationen, die heute an der Entwicklung von interoperablen Systemen arbeiten, gelungen ist, ein vielseitiges Programm
zusammenzustellen, das die unterschiedlichsten Probleme beleuchtet und beschreibt.
Den Autoren, die sich freiwillig zur Verfügung stellten, den Mitarbeitern der ETHZ und
EPFL, die bei der Redaktion der deutschen und französischen Versionen des Berichtes
mitwirkten sowie allen anderen Beteiligten möchten wir unseren herzlichen Dank aussprechen.
Alessandro Carosio
Zürich, 3. März 2005
Organisationskomitee
Alessandro Carosio, Prof. Dr.
IGP-ETH Zürich (Vorsitz)
Alain Buogo, dipl.Ing.
KOGIS
Thomas Glatthard, dipl.Ing.
SOGI, geosuisse
François Golay, Prof. Dr.
LaSIG-ETH Lausanne
Francis Grin, dipl.Ing.
EIVD Yverdon
Jens Ingensand, dipl.Ing.
LaSIG-ETH Lausanne
Peter Jordan, Dr.
SIA
Christian Just, dipl.Ing.
swisstopo
Jürg Kaufmann, dipl.Ing.
geosuisse
Andreas Morf, dipl.Ing.
IGP-ETH Zürich
Stephan Nebiker, Prof. Dr.
FHBB Abt. Vermessung und Geoinformation, Muttenz
Anton Stübi, dipl.Ing.
BA Landwirtschaft Abt. Strukturverbesserung
Pierre-Alain Trachsel, dipl.Ing.
KKVA
Inhaltsverzeichnis
1
Interoperabilität in GIS: Anforderungen, Strategien,
Lösungsansätze
Prof. Dr. Alessandro Carosio, IGP-ETH Zürich
Nationale und internationale Standards
2
Überblick
Urs Flückiger, SOGI Fachgruppe GISTechnologie
3
Informatik-Standards (UML, XML, SOAP)
Prof. Dr. Christine Giger, IGP ETH Zürich
4
Weltweite, europäische und schweizerische GeoNormen in
Wechselwirkung
Hans-Rudolf Gnägi, IGP-ETH Zürich, OSIG GT Normes
5
OpenGeospatial Consortium OGC (GML, WMS, WFS)
Adrian Annen, FHBB
Stand der Technik, Implementierungen I
6
OGC-Lösungen: Möglichkeiten und Grenzen
Dr. Andreas Donaubauer, TUM, Prof. Dr. Matthäus Schilcher,
Anette Huber, TUM
7
ISO-Standards für den Datentransfer: Stand der Realisierungen /
Werkzeuge
Claude Eisenhut, Eisenhut Informatik AG
Stand der Technik, Implementierungen II
Realisierungen im Rahmen der GDI
8
Interoperabilität von Geodaten: aktueller Stand und
Zukunftsperspektiven im Kanton Waadt
Marc Gilgen, DINF-VD
9
Die Komplexität der Interoperabilität: ein einfacher Praxisbericht
aus der Ostschweiz
Ueli Forrer, F+P Geoinfo AG
10
Modellbasierte und interoperable Bearbeitung der Basisdaten in
Wallonien
Jean-Claude Jasselette, MET Belgien
Nächste Schritte in der Interoperabilität
11
Modellstandardisierung vs. semantische Interoperabilität:
aktuelles aus der Forschung
Andreas Morf, IGP-ETH Zürich, Josef Dorfschmid, ADASYS AG
Semantische Interoperabilität – aktuelle Projekte
12
Datenmigration UIC
Dr. Théophil Engel, SBB
13
Integration der Daten der Landeskarte 1:25’000 (VECTOR25) ins
Datenmodell der Amtlichen Vermessung (DM.01 AV CH)
Robert Balanche, swisstopo
Organisatorische Folgen der Interoperabilität I
14
Nationale Geodaten-Infrastruktur (NGDI): Organisatorische Aspekte
der Interoperabilität beim Bund
Rolf Buser, KOGIS
15
Nationale Profile der internationalen Standards am Beispiel
Metadaten
Rudolf Schneeberger, ITV Geomatik AG
16
Interoperabilität – nicht nur eine Frage der Technologie
Willy Müller, Informatik Strategie Organ Bund
17
Interoperabilität auf strategischer und administrativer Ebene
Prof. Dr.François Golay, LaSIG-ETH Lausanne
Organisatorische Folgen der Interoperabilität II
18
Interoperabilität in der Praxis: Erfahrungen aus Projekten im In- und
Ausland
Dr. Ivo Leiss, Ernst Basler + Partner AG
19
Perspektiven für die Geomatik-Berufe
Christian Kaul, Kaul Beratungen GmbH
20
Tarifierung, Kostenfrage
Jürg Kaufmann, Kaufmann Consulting
Spezielle Aspekte der Interoperabilität in der Praxis
21
Georeferenzierung, Interoperabilität zwischen Vermessungsdaten
und darauf aufbauender Rauminformation, Datenhierarchie und
Nachführung der abhängigen Rauminformation
Dr. Horst Düster, AGI Solothurn
22
Der Mobilitäts-Graph: ein geographisches Rahmenwerk für die
Partner des Mobilitäts-Informationssystems der Region Genf
Pascal Oehrli, SIT Genf
1
Interoperabilität in GIS
Anforderungen, Strategien, Lösungsansätze
Alessandro Carosio, ETH Zürich
Alessandro Carosio, Prof. Dr.
Eidg. Technische Hochschule Zürich
Institut für Geodäsie und Photogrammetrie
ETH Hönggerberg
CH-8093 Zürich
Tel :
Fax :
E-Mail :
+41 1 633 30 52
+41 1 633 11 01
1 Interoperabilität und Datentransfer: Eine zentrale
Funktion jedes GIS
Das Entstehen und der erfolgreiche Einsatz von Geoinformationssystemen sind mit einer wirksamen Lösung des Problems der Interoperabilität und des Transfers der Geodaten untrennbar gekoppelt. Nur kleine Applikationen, die die Verarbeitung von kleinen
Datenmengen während kurzer Zeit erfordern (z.B. GIS-Übungen in der Ausbildung),
können ohne eine Lösung des Datentransferproblems auskommen.
Wir verfügen heute über eine immer grösser werdende Menge geographischer Daten in
digitaler Form und einer grossen Anzahl Organisationen, die mit Daten dieser Art arbeiten. Das Risiko, dass Doppelspurigkeiten und Widersprüche entstehen, ist gross.
Oft existieren die benötigten Daten bereits. Sie werden aber wieder erfasst, weil:
x
x
eine geeignete Dokumentation fehlt oder
sie eine inkompatible Struktur aufweisen.
Ein GIS ist nur erfolgreich, wenn es die Anforderungen möglichst vieler User erfüllt.
Abb. 1 : Die Kommunikation zwischen Geoinformationssystemen
Die Anforderungen und die Bedürfnisse sind allerdings sehr unterschiedlich. Dies ist
der Grund, warum es bis jetzt relativ schwierig war, eine alles umfassende Standardlösung zu finden.
Die wirtschaftlich entwickelten Länder realisieren zur Zeit geeignete nationale Geodateninfrastrukturen (NGDI), in welchen Private, Ämter, Lieferanten und Anwender integriert werden, damit sie gemeinsam Technologien und existierende Daten nutzen
können.
Voraussetzung für die Realisierung von Koordinationszentren (Clearinghouses), für den
Informationsaustausch und für die interoperable Nutzung der Geodaten ist die Lösung
der in Abbildung 2 beschriebenen organisatorischen und technischen Problemen.
Alle aufgezeigten Punkte sind sehr wichtig. Der vorliegende Beitrag befasst sich jedoch
nur mit der technischen Thematik der Interoperabilität und der Datenübertragung zwischen Systemen unterschiedlicher Hersteller.
Die erforderlichen Lösungsansätze für diese beiden Aufgaben sind besonders aktuell,
da man zurzeit sowohl auf nationaler Ebene als auch in internationalen Institutionen
(Europa, Welt) an der Entwicklung von technischen Normen arbeitet, die die Realisierung von interoperablen Systemen ermöglichen sollen.
Interoperabilität für die breite Nutzung von Geodaten
1.1
Einführung in die Thematik
Interoperabilität in GIS - Anforderungen, Strategien, Lösungsansätze
Abb. 2 : Organisatorische und technische Voraussetzungen für eine NGDI
2 Bedürfnisse, Lösungsansätze
GIS
GIS
Abb. 3 : Datenaustausch und Interoperabilität
2.1 Die Vielfalt der Anforderungen
Die Komplexität der Frage der Datenübertragung ist die direkte Folge der Vielfalt der
Anwendungen.
Ausgetauscht oder angefragt werden zum Beispiel:
x
x
x
x
x
x
Graphische Darstellungen (digitale Karten und Pläne)
Beschreibungen der GIS-Inhalte (Metadaten)
Resultate von Abfragen (Tabellen, Karten usw.)
Strukturierte Datenbankinhalte (z.B. Tabellen, Attribute) ohne Änderung der Datenstrukturen
Daten von einer Datenbank in eine andere Datenbank mit unterschiedlichen Datenstrukturen
Vollständige Objekte in einer objektorientierten Umgebung (inkl. Operationen)
Bereits diese kleine Auswahl von häufig auftretenden Datentransferwünschen gibt einen Eindruck über die Vielfalt der Bedürfnisse mit ihren sehr unterschiedlichen Komplexitäten.
1.2
2.2 Die Vielfalt der Lösungen
Interoperable GIS können auf unterschiedliche Arten realisiert werden:
x
x
Datentransfer
o Datenaustausch zwischen gleichen Systemen
o Datenaustausch mit Standardformaten
o Modellbasierte Datentransfermethoden
Interoperabilität
o Interoperabilität (nach OGC = Open Geospatial Consortium; früher Open
GIS Consortium)
3 Der eigentliche Datentransfer
3.1 Proprietäre Transferformate: ein Grundbedürfnis
Das Inbetriebsetzen einer GIS-Applikation, die Verkaufsvorführungen, die erste Schulung von neuen Anwendern und die Tests des Herstellers während der Softwareentwicklung erfordern die Übernahme von Demonstrationsdaten des gleichen GISHerstellers von einer Applikation zu einer anderen. So verfügen alle GIS über die Möglichkeit, die gespeicherten Daten in Standarddateien (in der Regel sequentielle Dateien)
auszugeben und aus den gleichen Dateien wieder zu übernehmen. Die verwendeten
Formate sind ausschliesslich geeignet für eine bestimmte GIS-Software (proprietäres
Format) und erfordern beim Sender und beim Empfänger die identische Datenstruktur
für die transferierten Daten.
GIS
GIS
Abb. 4 : Datentransfer mit proprietären Formaten
Andere proprietäre Formate, welche oft de facto Standard geworden sind, werden für
die Ausgabe von graphischen Darstellungen (z.B. Plottfiles), die aus der raumbezogenen
Information hergeleitet werden (Karten und Pläne), verwendet. Die GIS-Software beinhaltet normalerweise die Treiber für die erforderliche Steuerung und Generierung der
Datenformate.
3.2 Standard-Formate
Das Bedürfnis, Geoinformationen zwischen Systemen unterschiedlicher Hersteller auszutauschen war bereits in der Vergangenheit, besonders in grossen Organisationen (Telecom, Eisenbahngesellschaften, militärische Organisationen, usw.), stark spürbar.
Bei solchen Anwendungen hat man mit Geoinformationssystemen zu tun, in welchen
die zu verwaltenden Informationen für alle Systeme einheitlich festgelegt sind. Dies ist
vor allem in stark hierarchischen Organisationen der Fall (NATO, Staatsbetriebe usw.).
1.3
Wenn sowohl die geometrischen als auch die thematischen Inhalte feststehen, kann man
ein passendes Format definieren, das die Information aufnehmen kann und es ist möglich in jedem System die entsprechende Schnittstelle für das Lesen und Schreiben der
Transferdateien in das definierte Format einzubauen. So wurden zum Beispiel für die
NATO das Austauschformat DIGEST (Digitial Geographic Information Exchange Standard) und für den Ordnance Suvey (OS) in Grossbritannien das Format NTF (National
Transfer Format) definiert.
GIS
Abb. 5 : Datentransfer mit Standard-Formaten
Ein weiteres Bedürfnis, das sehr verbreitet ist, ist die Abgabe von Geoinformationen an
Partner, die sie nur graphisch auf ihren Computersystemen weiter verarbeiten werden.
Auf diese Art verwenden oft Architekten und Bauingenieure die erhaltenen Geodaten.
Sie werden in CAD-Systemen für die Projektierung eingesetzt. Der de facto Standard im
CAD-Bereich ist zurzeit DXF, ein Format, in welchem die Information in thematische
Ebenen (Layer) unterteilt wird.
Die meisten GIS-Hersteller sehen vor, Daten in DXF auszugeben und auch zu lesen. Dabei ist zu beachten, dass nur eine Teilmenge der Information (hauptsächlich die Graphik) in DXF abgebildet werden kann (ńInformationsverlust). Sehr vorteilhaft sind bei
dieser Form der Datenabgabe Vereinbarungen oder Normen, um die Layer-Zuordnung
und Nummerierung einheitlich zu gestalten.
Als das Projekt der Reform der Amtlichen Vermessung in der Schweiz realisiert wurde,
stellte man mit Besorgnis fest, dass die Festlegung von einheitlichen Datenstrukturen
für die Systeme der 26 Kantone unrealistisch war. Folglich war auch die Definition eines
gemeinsamen Datentransferformats ein unmögliches Bestreben.
Nicht anders geschah es ein paar Jahre später auf europäischer Ebene. Auf Anregung
von Frankreich wurde das TC 287 der europäischen Normungsorganisation CEN gegründet, um unter anderem auch Normen für den Transfer geographischer Daten in
Kraft zu setzen. Grossbritannien und Frankreich hatten sich vorgestellt, ihre Formate
NTF und EDIGéO (Echange de Données Informatisées GéOgraphiques) für Europa zu
erweitern (z.B. ETF). Die ersten Sitzungen zeigten aber, dass die Bedürfnisse und die
Systeminhalte sehr unterschiedlich und vor allem die Anwendungen extrem vielfältig
sind und daher die Festlegung von Standardformaten ein unmögliches Unterfangen ist.
Man brauchte andere Lösungsansätze. Wenn unterschiedliche Datenstrukturen erwartet
werden, sind modellbasierte Verfahren anstatt feste Formate der richtige Weg.
3.3 Modellbasierte Transferverfahren
Geoinformationen der heutigen Zeit bieten den Anwendern neben einer festgelegten
Datenstruktur für die geometrischen Daten die Möglichkeit, die thematischen Inhalte
frei zu definieren. Das System bildet dann aufgrund der Datenstrukturbeschreibung
1.4
(Eingabe des DB-Schemas) die erforderlichen Entitätsklassen (in der Regel relationale
DB-Tabellen). Somit passt sich die Datenverwaltung den Bedürfnissen an.
GIS
Abb. 6 : Modellbasierte Transferverfahren
Man kann diese Idee auch brauchen, um den Datentransfer flexibel zu gestalten: Die
Struktur der Daten, die man übertragen möchte, wird beschrieben und daraus kann ein
Format für diese Daten hergeleitet werden. Dafür benötigt man zwei Komponenten: erstens eine standardisierte Datenbeschreibungssprache, um die Struktur der Daten, die
man transferieren möchte, eindeutig und konsistent zu beschreiben, und zweitens ein
genormtes Verfahren, um aus der Datenstruktur ein Format herzuleiten.
FormatHerleitung
Abb. 7 : Komponente des modellbasierten Transferverfahrens
In der europäischen Normung wurde EXPRESS als Sprache festgelegt, da sie bereits eine gewisse Verbreitung hat (CAD, Automobilindustrie usw.). Applikationen im GeoBereich existieren allerdings noch nicht und ihre Komplexität ist für eine Implementierung nicht förderlich.
In der Schweiz wurde für die Amtliche Vermessung vor mehr als 10 Jahren die Sprache
INTERLIS definiert, welche die Beschreibung der Thematik in einem GIS nach einem
relationalen Modell und der Geometrie aufgrund von festgelegten Geometrieelementen
(Punkte, Geraden, Kreisbögen, Einzelflächen, Gebietseinteilungen) ermöglicht. Die
Sprache passt sehr gut zu den heutigen GIS. Sie verfügte von Anfang an über einen
Compiler für die automatische Herleitung der Transferformate und wird zunehmend
eingesetzt. Zurzeit kann weltweit keine andere Lösung als operationell betrachtet werden. Im Technischen Komitee der ISO (TC 211) konnte nur INTERLIS als in GIS implementierter modellbasierter Transfermechanismus für Geodaten vorgeführt werden.
ISO hat bisher folgendes beschlossen:
x
x
Die modellbasierten Transferverfahren sind als Standard erklärt.
UML wurde als graphischer Formalismus für die Beschreibung der Datenstrukturen festgelegt.
1.5
x
Eine textuelle Sprache, die automatisch gelesen und interpretiert werden kann,
ist vorgesehen, ihre Eigenschaften wurden beschrieben und festgelegt. Kein Entscheid wurde getroffen. Mögliche Lösung INTERLIS 2.
Die Schweiz hat die neue INTERLIS Version (INTERLIS 2) entwickelt, um die volle
Kompatibilität mit den ISO-Normen (Objektorientierung, Inkrementelle Nachführung,
usw.) zu erfüllen. In diesem Rahmen wurde auch die Schnittstelle zwischen UML und
INTERLIS realisiert, damit ein UML-Schema in INTERLIS automatisch übersetzt werden kann (und umgekehrt). Ebenfalls wurde das Transferformat im InformatikStandard XML definiert. Demnächst wird man auch ein Transferformat auf der Basis
von GML erzeugen können.
Die modellbasierten Technologien bieten auch für andere Bereiche Lösungsansätze.
Moderne GIS ermöglichen heute die Implementierung des Modells direkt aus dem konzeptionellen Schema (in UML oder in INTERLIS):
x
x
x
ArcGIS (ESRI) kann die Datenstruktur aus Schemata in UML (erzeugt mit Microsoft Visio) implementieren
GeosPro/GeoMedia (a/m/t, Intergraph) aus INTERLIS
Topobase (C-Plan) aus INTERLIS oder aus UML
4 Interoperabilität
Während die bisherigen Lösungen alle als Ziel haben, die Daten von einem System zu
einem anderen zu transferieren, sind Kommunikationsmöglichkeiten denkbar, die ohne
Verschiebung der Originalgeodaten auskommen. Diese Lösung ist besonders interessant, wenn nur einfache Auswertungen der Information benötigt werden (z.B. eine graphische Darstellung von einem Ausschnitt oder die Auflistung von bestimmten Objekten). In diesen Fällen ist es einfacher, die Auswertungsbefehle und -ergebnisse zu standardisieren und zu transferieren als die Grunddaten selbst.
Die Interoperabilität bedeutet die Parallelnutzung von verschiedenen GIS, indem die
Befehle (Anfragen) und die daraus entstehenden Ergebnisse (Antworten) ausgetauscht
werden (siehe Abb.8).
Die GIS-Industrie (Softwarehersteller) hat diesen Weg als für den Markt interessant angesehen und das Open Geospatial Consortium (OGC) gegründet, um diese Technik
möglichst weit zu entwickeln. Dank der Beteiligung der führenden weltweit tätigen
Firmen (ESRI, Intergraph, Siemens, Oracle, Microsoft usw.) und der Einbindung von
Universitäten und Forschungsinstitutionen hat OGC grosse Resonanz erhalten und entsprechend grosse Erwartungen geweckt.
1.6
Abb. 8 : Interoperabilität
Aus dem Konzept der Interoperabilität sieht man sofort die Vorteile:
x
x
x
das Datenverwaltungskonzept kann in den kommunizierenden Systemen sehr
unterschiedlich sein.
Das abfragende System muss nichts über die Datenorganisation des angefragten
Systems wissen.
Die Systeme geben nur Teile der Information weiter. Der volle Inhalt bleibt unter
der eigenen Kontrolle (Urheberrecht).
Ein Vorteil für die GIS-Hersteller:
x
die Kunden können nicht so leicht das System wechseln
Ebenfalls sichtbar sind die Grenzen: die Vielfalt der standardisierten Abfragen und der
Antwortformen darf nicht zu gross sein. Falls die gewünschten Interoperationen zu
komplex, zu vielfältig und anzahlmässig zu gross werden, ist der Austausch der Daten
einfacher und günstiger als die Standardisierung der Operationen. Selbstverständlich
müssen die Systeme vergleichbare Informationen enthalten. Zurzeit hat OGC nur Lösungen vorgesehen für Abfragen, die in den Bezeichnungen angeglichen wurde (syntaktische Interoperabilität).
Zusammenfassend kann man sagen, dass die Interoperabilität interessant ist, wenn:
x
x
einfache Auswertungen der Geoinformationen benötigt werden (z.B. graphische
Darstellungen, Listen von Objekten oder Attributen)
die Systeme, die angefragt werden, gleichzeitig in Betrieb sind
1.7
5 Metadaten
Die immer grössere Verbreitung der Geoinformationssysteme stellt uns vor neue Probleme: es fehlen oft Informationen über die verfügbaren Geoinformationssysteme und
ihre Daten. Um diese wichtigen Informationen zugänglich zu machen, entstehen Metainformationssysteme, welche Metadaten (Daten über die Daten) verwalten. Diese Systeme sind ihrerseits Geoinformationssysteme, in welchen ein Teil der Metainformationen raumbezogen ist (wo und über welches Gebiet findet man Daten). Zu den Metadaten gehören Informationen über die Qualität, die Verfügbarkeit, die Nutzungsbeschränkungen, die Kosten usw. Die Beschreibung der Datenstruktur in einer genormten Sprache (EXPRESS, INTERLIS, UML usw.) kann ebenfalls dazu gehören.
Ansätze für die Normung von Metadaten befinden sich im ISO-Normenwerk. In der
Nationalen Geodaten-Infrastruktur (NGDI) wird man aus den internationalen Normen
nationale Profile (Teilmengen) definieren, um eindeutige Interpretationen zu ermöglichen.
Zurzeit werden Metadaten zur visuellen Konsultation zur Verfügung gestellt. In Zukunft werden sie automatisch von interoperierenden Systemen bei der Datensuche genutzt werden.
6 Die Wünsche und das Erreichbare
6.1 Wünschbares
Die optimistischen Beschreibungen der unterschiedlichen Datentransfer-Konzepte
könnten den Eindruck entstehen lassen, dass - mit etwas Geduld und finanziellen Mitteln - das Problem des automatischen Austausches von Geoinformationen zwischen beliebigen Systemen ohne weiteres lösbar sei.
GIS
GIS
GIS
Abb. 9 : Interoperabilität zwischen beliebigen Systemen mit beliebigen Datenstrukturen sind
gewünscht.
Dies entspricht selbstverständlich dem, was man sich wünscht. Man möchte die wertvollen Informationen, die an verschiedenen Orten erfasst und verwaltet werden, gemeinsam nutzen.
6.2 Technische Grenzen
Eine voll automatische Datenübertragung oder die gemeinsame Nutzung der Daten in
beliebig konfigurierten Geoinformationssystemen ist nicht möglich. Die unüberwindbare Grenze liegt in der nicht standardisierten Semantik der Datenstrukturbeschreibungen.
1.8
Die folgenden Beispiele illustrieren häufig vorkommende Fälle.
Im Sendersystem wird eine thematische Klasse von Elementen mit dem Begriff „HÄUSER“ identifiziert, während der Empfänger dasselbe mit „GEBÄUDEN“ bezeichnet.
Selbstverständlich können Fremdsprachen und Abkürzungen weitere Hindernisse zu
einer automatischen Interpretation bieten. Es kommt auch die umgekehrte Situation vor.
Gleiche Begriffe bedeuten in den zwei kommunizierenden Systemen andere Objekte. In
einem System bedeutet der Begriff „WEGE“ die Menge aller Verkehrsverbindungen
(Strassen, Eisenbahnen, schiffbare Kanäle usw.), im anderen sind „WEGE“ kleine Strassen in einer Ortschaft (Schlossweg, Alpenweg usw.). Noch häufiger sind die Fälle dazwischen, in welchen die thematischen Elemente andere Bezeichnungen und auch eine
andere Unterteilung haben (Abb.10).
Abb. 10 : Im allgemeinen Fall kann die Zuordnung der einzelnen Attribute nicht automatisch
stattfinden.
Die Semantik der Datenbeschreibung kann in einem freien Umfeld nicht standardisiert
werden. Für die Zuordnung der Entitäten und der Attribute braucht man Zusatzinformationen. Es ist zu beachten, dass die Zuordnung von der Bedeutung der Objekte und
der Attribute abhängig ist. Sie ist daher auch von den Betriebsanweisungen und von
den Regeln der Datenakquisition beeinflusst. Weder Mensch noch Computer werden in
der Lage sein, ohne Zusatzauskünfte die Zuordnung der Entitäten und der Attribute
vorzunehmen. Man wird sich zuerst erkundigen müssen oder ausführliche Beschreibungen lesen, um aufgrund der eigenen Interpretationen und Zielsetzungen die Datenfelder in Beziehung zu bringen.
Diese Zuordnung muss das erste Mal aufgrund von:
x
x
x
Einer Analyse eines Experten
Anfragen bei den Verantwortlichen
Konsultationen von Metadaten erfolgen
Erst danach kann eine semantische Transformation automatisch ausgeführt werden.
Für die modellbasierten Transferverfahren haben Software-Hersteller Module entwickelt, die zwei Datenstrukturen (z.B. aus ihrer Beschreibung in INTERLIS) darstellen
1.9
und die Zuordnung der Entitätsklassen und Attribute auf Formatebene interaktiv am
Bildschirm erlauben. Weitere Entwicklungen in dieser Richtung aber auf konzeptueller
Ebene sind zu erwarten (semantische Transformationen, semantische Interoperabilität).
Ontologie
Agent
Agent
Abb. 11: Semantische Transformationen mit Hilfe von Ontologien
Zwischen föderierten Systemen (unter gemeinsamen Regeln organisiert) wird es in spezifischen Bereichen möglich sein, Ontologien zu entwickeln, welche die Semantik von
mehreren Systemen beschreiben und die Herstellung von automatischen Transformationsmodulen (Agenten) ermöglichen werden.
Die Ontologien sind Gegenstand der heutigen Forschung. Man wird allerdings nur die
Semantik in klar definierten und abgegrenzten Sektoren eindeutig beschreiben können.
Eine Ontologie entspricht einer Standardisierung der Begriffe, die man für die Modellbildung und für die Bezeichnung der Elemente der Datenstruktur im GIS verwendet
hat.
7 Entwicklungsstrategien
Jeder der bisher geschilderten Lösungsansätze ist, trotz der erwähnten technischen
Grenzen, eine optimale Antwort für einzelne Fälle mit ihren unterschiedlichen Anforderungen. Es ist daher nicht zu erwarten, dass sich ein einziger besonderer Lösungsansatz
als Weltstandard für den Transfer von Geoinformationen durchsetzen wird:
x
x
1.10
Proprietäre Formate werden zu jeder GIS-Software gehören. Sie sind die optimale Lösung für die Systemadministration. Sie übertragen die Daten eines bestimmten Systems vollständig (inkl. Konfigurationsparameter). Sie können auch
für den internen Datenaustausch in grossen Organisationen dienen, die mehrere
identische Systeme betreiben.
Standardformate sind einzusetzen, wenn die Inhalte der GIS zentral festgelegt
werden. Zur beschlossenen Datenstruktur kann ein Format definiert werden, mit
welchem die Daten sequentiell übertragen werden können. Standardformate
sind ebenfalls die geeignete Lösung für die Abgabe von GIS-Daten an CADSysteme. DXF ist im CAD-Bereich am meisten verbreitet. Wünschenswert ist dabei die Normung der Layer.
x
Modellbasierte Transferverfahren sind die Lösung für den Datenaustausch
zwischen Systemen, die eine eigene Datenstruktur besitzen. Die ankommenden
Daten beinhalten die Datenstrukturbeschreibung in einem genormten Formalismus (Datenbeschreibungssprache). Zur Sprache gehört auch das Verfahren, um
daraus die Formate herzuleiten. Wenn die Strukturen der erhaltenen Daten und
der Daten des Empfänger-Systems nicht identisch sind, kann eine voll automatische Übernahme nicht stattfinden. Die Zuordnung der Entitätsklassen und der
Attribute muss das erste Mal aufgrund menschlicher Interpretation geschehen.
Um diese interaktive Arbeit zu erleichtern, haben Software-Hersteller Module
entwickelt, die zwei Datenstrukturen vergleichen und am Bildschirm die Zuordnung der Tabellenfelder erlauben (z.B. INTERLIS-Studio von Leica).
Abb. 12 : Bei der ersten Datenübertragung muss die Beziehung zwischen den Attributen definiert
sein.
x
Interoperabilität ist die Alternative, mit welcher die Kommunikation zwischen
den GIS ohne Austausch der Geodaten stattfinden kann. Genormt werden die
Anfragen und die Formate für die Übermittlung der Antworten (Services Interfaces). Der tatsächliche Umfang der Möglichkeiten, die im Rahmen der OGCArbeiten entstehen werden, ist schwer vorherzusagen. Zurzeit sind einfache Anfragen (Visualisierungen, Selektionen) und der Zugriff auf einfache geographische Objekte spezifiziert.
Sicher werden einfache Anfragen (Visualisierungen, Selektionen) zur Verfügung
stehen. Ebenfalls spezifiziert ist bereits der Zugriff zu einer einfachen Koordinatengeometrie. Da in den Absichten des Open Geospatial Consortium (OGC)
nicht nur die Kommunikation zwischen den Systemen im Vordergrund steht,
sondern auch das Zusammensetzen von ganzen GIS aus selbstständigen Komponenten, werden die Schnittstellen zwischen den frei gewählten SoftwareModulen ebenfalls benötigt. Die erforderliche Zeit und die Erreichbarkeit der
Ziele sind nicht leicht vorsehbar.
1.11
8 Schlussfolgerung
Die Kommunikation zwischen Geoinformationssystemen ist eine vielseitige Aufgabe,
für welche eine Vielfalt von Lösungsansätzen zur Verfügung steht. Die Probleme, die
Anforderungen und die technischen Grenzen sind erst in neuster Zeit in ihrer ganzen
Breite wahrgenommen worden. Die heute eingesetzten Datentransferverfahren und die
Interoperabilität werden sich in den nächsten Jahren stark entwickeln. Mehrere Methoden werden sich als Standard durchsetzen. Die nächsten Schritte der Forschung sind im
Bereich der semantischen Interoperabilität und der semantischen Transformationen zu
erwarten.
Diese Arbeiten sind die Voraussetzung, damit Geoinformationssysteme ihre wertvollen
Daten ohne Verzögerung und Hindernisse der ganzen Gesellschaft zur Verfügung stellen können.
1.12
2
Überblick
Urs Flückiger, SOGI Fachgruppe GIS Technologie
Urs Flückiger
ESRI Geoinformatik AG
Beckenhofstr. 72
CH-8006 Zürich
Tel :
Fax :
E-Mail :
+41 1 360 24 60
+41 1 360 24 70
Dieser Beitrag soll dem Interessenten einen Überblick zum Thema nationale und internationale Standards im Gesamtkontext zu „Interoperabilität für die breite Nutzung von
Geodaten“ geben. Im Gegensatz zu den nachfolgenden Beiträgen kann dieser Einstieg
ins Thema nicht in die Details gehen. An der Tagung behandelte Themen finden sich als
Beispiele wieder.
Was ist Interoperabilität? – Interoperabilität ist, wenn ein System mit anderen Systemen
unterschiedlichen Ursprungs innerhalb vordefinierter Grenzen zusammenarbeiten kann
und darf. Durch Spezifikationen und Normen entsteht Interoperabilität. Interoperabilität findet auf verschiedenen technologischen Ebenen statt.
Leisten Normen einen Beitrag zur Interoperabilität? – Normen erleichtern das Leben in
einer vernetzten Welt. In den wenigsten Fällen werden Daten nur für einen kurzfristigen Moment erfasst und nur in einem System gehalten. Deshalb ist die Schaffung und
Durchsetzung von Normen eine bedeutende Aufgabe. Normen erleichtern die Vernetzung und bauen technologische Hindernisse zur Zusammenarbeit ab.
Gibt es einen Markt für Normen? – Verschiedene Gruppierungen befassen sich damit.
Der Nutzen ist unterschiedlich. Alle Beteiligten profitieren jedoch in irgendeiner Weise.
1 Normung
1.1 Definition von Normung
Normung heisst die planmässige, durch interessierte Kreise durchgeführte Vereinheitlichung von materiellen und immateriellen Gegenständen zum Nutzen der Allgemeinheit
(DIN). Das Ergebnis von Normung ist eine technische Vorschrift, die man Norm nennt
(englisch: standard). Eine „de jure Norm“ (oder kurz Norm) ist eine solche technische
Vorschrift, die von nationalen oder internationalen Normenverbänden festgelegt wird.
Eine „de facto Norm“ ist eine allgemein anerkannte und mehrheitlich genutzte technische Vorschrift, die sich aus der weiten Verbreitung eines Produktes ergibt, durch die
ausschliessliche Nutzung innerhalb eines Unternehmens (so genannter IndustrieStandard) oder durch nationale oder internationale Interessengemeinschaften oder Konsortien festgelegt wird. Sowohl Normen als auch de facto Normen sind nur dann verbindlich und müssen durch natürliche und juristische Personen angewendet werden,
wenn durch gesetzliche oder vertragliche Regelungen deren Einhaltung gefordert wird.
Typ
Betriebssysteme
Datenbanken
Norm (Gremium)
Unix, Linux (ANSI)
SQL-92 (ISO)
Datenformat
XML (W3C), ITF (SNV)
Programmiersprachen
C++ (ANSI)
Internet-Dienste
HTTP (ISO), SOAP, UDDI
GI-Standards
Verbandsspezifisch
ISO 19115 Metadaten (ISO)
De facto Norm (Gremium)
Windows 2000 (Microsoft)
DXF (AutoCAD), Shapefile
(ESRI)
Java (Sun), Visual Basic (Microsoft)
J2EE (SUN Microsystems),
WSDL (W3C)
WMS (OGC)
SIA-Norm 405 (SIA)
Tab. 1 : Beispiele von Normen und de facto Normen
Normen, insbesondere für die Dokumentation (Metadaten), die Modellierung (einheitliche Beschreibungssprache) sowie den Datenaustausch (Bezugsmechanismus und Datenformat) erhöhen die Flexibilität, die Funktionalität und die Produktivität eines Informationssystems.
2.1
Überblick
1.2 Normierungsorganisationen
1.2.1
De jure Normierungsorganisationen
Internationale Organisation für Standardisierung (ISO)
ISO ist die Internationale Organisation für Standardisierung für Business, Behörden und
Gesellschaft. Die Mitglieder-Organisationen können die Normen übernehmen.
Beispiele für ISO-Normen:
x
ISO 19103 Geographic Information – Conceptual Schema Language
x
ISO 19115 Geographic Information – Metadata
x
ISO 19119 Geographic Information – Services
x
ISO 19136 Geographic Information – Geography Markup Language
x
ISO 19139 Geographic Information – Metadata – Implementation Specification
TC211 ist das technische Komitee Nr. 211 der ISO, das sich mit Geografischen Informationen und Geomatik beschäftigt. Dieses Komitee bearbeitet die Normenserie ISO 19100,
welche verschiedenste Geodaten-Standards (Metadata, Spatial Schema, Spatial Reference, Application Schema, Conceptual Schema Language, Quality, Encoding, Catalog ...)
beinhaltet.
Die ISO TC211 und das Open Geospatial Consortium (OGC) arbeiten zusammen und
unterstützen sich gegenseitig. Eine Spezifikation bei OGC entspricht einer Ebene der
19100-er Normenserie bei ISO. Die mit dem Abkommen verfolgten Ziele sind:
x
OGC-konforme Produkte werden (fast) konform mit dem Standard aus ISO
TC211.
x
Verbesserung der Standards bei OGC und ISO TC211.
x
Schnellere Entwicklung und Austesten von Spezifikationen in Testumgebung und
Pilotprojekten.
x
Beachtung von Marktkonditionen.
Europäisches Komitee für Standardisierung (CEN)
CEN ist das Europäische Komitee für Standardisierung. CEN wird voraussichtlich beschliessen die Normenserie ISO 19100 weitgehend zu übernehmen. Die Mitglieder von
CEN haben sich verpflichtet die CEN-Normen zu ratifizieren.
Schweizerische Normenvereinigung (SNV)
Die SNV ist Mitglied von CEN und daher verpflichtet, die CEN-Normen und somit die
ISO-Normen zu übernehmen, falls diese zu CEN-Normen werden. Dies bedeutet, dass
allfällige Schweizer Normen, welche im Widerspruch mit CEN bzw. ISO-Normen stehen, voraussichtlich eliminiert werden müssten. Da die Schweizer Geonormen auf
Grund von praktischen Bedürfnissen entwickelt, implementiert und getestet wurden, ist
die Schweiz daran interessiert, dass auch die allfällig zu übernehmenden internationalen Normen im GI-Bereich den praktischen Bedürfnissen entsprechen und durch Implementierung auf ihre Brauchbarkeit geprüft werden. Dafür setzen sich die Schweizer
Vertreter in den entsprechenden Gremien mit zunehmendem Erfolg ein.
2.2
Überblick
Andererseits bemüht man sich in der Schweiz ebenfalls erfolgreich, die existierenden
und bewährten Normen den aktuellen Entwicklungen in der Informationstechnologie
und im GI-Normenbereich schrittweise anzupassen.
Beispiele für SNV-Normen:
x
SN 612 030 und SN 612 031: INTERLIS Modellierungssprache und Datentransfermethode
x
SN 612 040: Gebäudeadressen
x
SN 612 050: GM03 - Metadatenmodell
1.2.2
De facto Normierungsorganisationen
Open Geospatial Consortium (OGC)
Führende GIS-Hersteller, Datenproduzenten, Behörden, Organisationen und Forschungseinrichtungen haben sich 1994 im Open Geospatial Consortium (OGC) zusammengeschlossen. Ziel des Zusammenschlusses ist die Definition von herstellerübergreifenden, "offenen" Programmschnittstellen, die Standardisierung von GISTechniken sowie die Förderung der GIS-Technologie. Die angestrebten de facto Normen
sollen erreichen, dass die Dienste von Anbietern einem grossen Kreis von Nutzern auf
einfache Weise zugänglich gemacht werden können. Angestrebt werden ein breiter Einsatz interoperabler Software-Komponenten von der Stange (Components of the shelf),
die vollständige Integration der Geodatenverarbeitung mit der normalen Informationstechnologie und der Schritt von Geodaten zu Geoinformationsdiensten. Die OGCSpezifikationen sind meist pragmatische Ansätze, welche die Funktionstüchtigkeit als
Hauptziel haben.
Beispiele für OGC Spezifikationen sind:
x
„OpenGIS Simple Feature Specification (SF, approved)“
x
„OpenGIS Geography Markup Language (GML, approved)“
x
„OpenGIS Web Map Server Specification (WMS, approved)“
x
„OpenGIS Web Feature Server Specification (WFS, approved)“
x
Service Discovery
x
Service Description
W3C
Das World Wide Web Consortium wurde gegründet, um alle Möglichkeiten des Webs
zu erschließen. Dazu werden einheitliche Technologien (Spezifikationen, Richtlinien,
Software und Tools) entwickelt, die den Fortschritt des Webs fördern und seine Interoperabilität sicherstellen.
Hauptprodukte des W3C sind neue Empfehlungen, die als de facto Standards für Protokolle und Anwendungen von den Mitgliedern begutachtet und gebilligt werden müssen. Ziel dabei ist es, einen möglichst breiten Konsens zu finden, was dadurch erreicht
wird, dass jede Spezifikation ein bestimmtes Verfahren zu durchlaufen hat (sog. Recommendation Process).
Ziel des W3C ist es, das WWW zu seiner vollen Entfaltung zu führen: Als ein funktionierendes Computer zu Computer System, als ein wirkungsvolles Mensch zu Computer
Interface und als ein effizientes Mensch zu Mensch Kommunikationsmedium. Um die-
2.3
Überblick
ses Ziel zu erreichen, arbeitet das W3C-Expertenteam zusammen mit seinen Mitgliedern
in den folgenden fünf Bereichen:
x
Architecture Domain (DOM, Jigsaw, XML, XML Protocol, URI)
x
Document Formats Domain (HTML, Style Sheets, Math, Grafik, Internationalisierung, Amaya)
x
Interaction Domain (Device Independence, synchronisierte Multimediaanwendungen, Voice Browser)
x
Technology and Society Domain (Digitale Signaturen, Metadaten, elektronisches
Geld, Datenschutz und Datensicherheit)
x
Web Accessibility Initiative
2 Interoperabilität
Durch normierte Schnittstellen und Formate wird die systemunabhängige Kommunikation zwischen verschiedenen Informationssystemen ermöglicht, was als Interoperabilität
bezeichnet wird. Interoperabilität erlaubt den einfachen Zugang zu verschiedenen (auch
raumbezogenen) Daten- und Verarbeitungsressourcen innerhalb eines Arbeitsablaufs
bzw. die einfache Verknüpfung unterschiedlicher Systeme. Durch dieses einfache Zusammenspiel von Systemen und Daten wird es möglich, viele verschiedene Daten an
einem Ort zu nutzen und diese Information gegebenenfalls auch zu veröffentlichen.
Durch Spezifikationen und Normen entsteht Interoperabilität. Interoperabilität ist die
Grundlage von IT-Infrastrukturen, d.h. von verteilten Systemen für eine GesamtUnternehmungslösung.
Interoperabilität findet auf verschiedenen Ebenen statt.
Schicht
Präsentation
Services
Applikationslogik
Daten, Formate
Plattform
Charakteristik
Unterstützung von thin clients
und fat clients
Begriffe
J2ME
Interoperation und Offenheit:
Einsatz von Internet-, IT- und
GIS- Standards
HTTP, XML, SOAP, J2EE, UDDI;
OGC: WMS, WFS
Integration und IT-Konformität
(API)
Austausch und Investitionsschutz
.net, COM, Java SOAP, GML/XML,
C++, VB
DXF, DGN, SHP, OGC SF, INTERLIS, GML, DBMS OS, PNG, JPG
Plattformunabhängigkeit
Unix (SUN, IBM, HP), DOS, Windows, Mac, Linux; DBMS (Oracle,
SQL, DB2, Informix); WebServer
(IIS, Websphere, Apache)
3 Marktbetrachtung
Generell erleichtern Normen das Leben in einer vernetzen Welt. In den wenigsten Fällen
werden Daten nur für einen kurzfristigen Moment erfasst und nur in einem System
gehalten. Die Schaffung von Normen ist eine bedeutende Aufgabe. Wer befasst sich mit
Normung?
Ein Marktangebot soll sich an der Nachfrage orientieren. Denn nur diejenigen Normen
werden sich durchsetzen, welche einen klaren Nutzen für den Anwender haben. Wem
bringt Normung etwas?
2.4
Überblick
Die Antworten auf diese beiden Fragen sind nicht abschliessend:
Verschiedene Organisationen bzw. Gremien befassen sich mit Normung. Die einschlägigen Normierungsorganisationen wie ISO, CEN und SNV aber auch OGC wurden bereits erwähnt. Neben den technischen Kommissionen (z.B. TC211 oder TK151) befassen
sich auch weitere Gremien und Verbände (z.B. eCH, sia) mit Normung. Gerade Verbände sind gefordert, entstehende Normen für ihre Mitglieder auf ihre Praxistauglichkeit
zu prüfen.
EUROGI (European Umbrella Organisation for Geographic Information) will den
Gebrauch von geographischen Informationen zugunsten der Bürger, der Regierungen
und des Handels in Europa maximieren und die Sichtweise der GeographischenInformationen-Gemeinschaft darstellen. Dies wird erreicht durch Förderung, Anregung
und Unterstützung der Entwicklung und des Gebrauchs geographischer Informationen
und Technologien.
Das Schweizer Kontaktnetz e-geo.ch wurde initiiert, um den Aufbau einer NGDI zu
fördern wie auch die Partnerschaften zwischen der öffentlichen Hand, Organisationen
und der Privatwirtschaft zu verbessern. Beide Initiativen benötigt für die Umsetzung
die Interoperabilität. Für das Erreichen der Ziele sind praktikable und sinnvolle Normen
von Vorteil.
Hersteller sind angehalten, die vom Markt geforderten Normen zu implementieren.
Davon profitiert der Kunde wie der Hersteller, weil weitere Aufgaben bewältigt und
neue Marktsegmente erschlossen werden können.
Datenproduzenten wollen ihre Daten einem möglichst grossen Publikum zugänglich
machen. Die Bereitstellung in einem genormten Datenformat verringert den Aufwand
erheblich. Die Daten müssen nicht in verschiedenen proprietären Formaten von GISSystemlieferanten aufbereitet werden. Verschiedene Studien belegen, dass gut zugängliche Geobasisdaten für Privatwirtschaft wie für Verwaltung hohen volkswirtschaftlichen
Nutzen haben (vgl. NGDI des Bundes).
Der Anwender wird sich nicht im Detail damit befassen. Er wird sich informieren, damit er als Auftraggeber notwendige Standards fordern bzw. als Auftragnehmer geforderte Standards umsetzen kann. Schliesslich sollen Investitionen nachhaltig sein.
Die Schaffung und Durchsetzung von Normen ist eine bedeutende Aufgabe. Normen
erleichtern die Vernetzung und bauen technologische Hindernisse zur Zusammenarbeit
ab. Die SOGI FG GIS-Technologie hat den Nutzen der Ergebnisse der Arbeit von OGC,
ISO und SN für den GIS-Anwender in der Schweiz untersucht:
Beschreibung
Produktivitätssteigerung von Unternehmen und Behörden durch die
Nutzung genormter Programmschnittstellen.
Produktivitätssteigerung von Unternehmen und Behörden durch die
Nutzung genormter Austauschformate und Mechanismen.
Nutzen durch Software spezifischer Technologien ab der Stange.
Investitionsschutz (durch Plattformunabhängigkeit).
CH ist nicht mehr eine Normeninsel.
Bessere Kontrolle der Daten.
Klar definierte Richtlinien für Ausschreibungen durch die zwingende
Vorgabe des abzugebenden Datenformates, und damit Chancengleichheit für alle Anbieter.
Im Bereich länderübergreifender Projekte, kommen proprietäre nationale Normen (d.h. ohne Bezug zu internationalen Normen) nicht zum Ein-
OGC
ISO
SN
X
-
e
e
e
X
X
?
X
-
e
X
e
X
X
X
X
-
-
X
e
e
e
2.5
Überblick
satz. Dort ebnen internationale Normen den Weg für einen geregelten
Datenbezug bzw. Datenaustausch.
Normung wird auf einer systemneutralen Daten- und Modellierungsebene geführt.
Alle Beteiligten sprechen die gleiche „Sprache“.
?
X
X
-
?
X
Legende: X Nutzen realisiert, e Nutzen zu erwarten/versprochen, ? Nutzen unklar, - kein
Nutzen
In einem Bericht der swisstopo wurde versucht, die konkreten Einsparungen beim sinnvollen Einsatz von Schweizer Normen zu schätzen (Bericht 17, www.swisstopo.ch). Es
wird dort von einem Potential von einigen Millionen Schweizer Franken pro Jahr gerechnet. Ein anderer Bericht spricht von 3% Einsparung durch genormte Arbeitsabläufe
und Werkzeuge (www.cgey.com/gcicase); dieser Prozentsatz dürfte im GIS-Bereich
noch wesentlich höher liegen. Ebenso wichtig wie die Einsparungen ist jedoch der Zusatznutzen, der durch genormte Geoinformationsverarbeitung erzielt wird.
Im Gegensatz zu üblichen Märkten ist Wettbewerb weniger gefragt. Organisationen sollen in jenen Bereichen, in denen sie sich thematisch überschneiden, zusammenarbeiten
und ihre Normen angleichen. Dies passiert bereits. OGC-Standards wie WFS oder WMS
werden von ISO als Norm übernommen oder in entsprechenden Normen angepasst.
Dasselbe geschieht auch umgekehrt, indem z.B. OGC ISO-Normen als Standards übernimmt. Auch andere Organisationen wie FGDC arbeiten enger mit ISO und OGC zusammen. Dies bringt den Organisationen weniger Arbeit und mehr Durchsetzungskraft.
Für Entwickler, Hersteller und Anwender wird es einfacher.
4 Literaturangaben
x
SOGI FG GIS-Technologie (2003): Worin liegt der praktische Nutzen von Interoperabilität und Normung für den GIS-Anwender in der Schweiz?
x
SOGI FG GIS-Technologie (2005): Geo-Webdienst
URL
CEN, European Committee for Standardisation (www.cenorm.be)
INTERLIS (www.interlis.ch)
ISO (www.iso.org)
ISO TC/211 (www.isotc211.org)
KOGIS (www.kogis.ch, www.e-geo.ch)
OGC (www.opengis.org)
Online Glossar (www.integis.ch)
Schweizerischen Normen Vereinigung SNV (www.snv.ch)
SOGI (www.sogi.ch)
TC211 – OGC coordination group (www.opengis.org/iso)
2.6
3
Informatik-Standards
Für die Interoperabilität von GIS relevante
Standards
Christine Giger, ETH Zürich
Christine Giger, Prof. Dr.
ETH Hönggerberg
CH-8093 Zürich
Tel :
Fax :
E-Mail :
+41 1 633 30 51
+41 1 633 11 01
1 Einleitung
Die Entwicklung vernetzter, interoperabler
Informationstechnologien vier Aufgaben:
1.
2.
3.
4.
Systeme
betrifft
aus
Sicht
der
Festlegung der Architekturen und technischen Standards
Prozessmodellierung
Datenmodellierung
Entwicklung von Basiskomponenten
Alle vier Aufgaben sind im hohen Masse voneinander abhängig und müssen
aufeinander abgestimmt werden. In anderen Beiträgen dieser Tagung werden die
verschiedenen Schritte unter verschiedenen Aspekten beleuchtet. Hier soll vor allem auf
die erste Aufgabe eingegangen werden und dargestellt, welche allgemeinen,
informationstechnischen Standards existieren, die als Grundlage für die in anderen
Beiträgen behandelten Geoinformations- und Geomatik-Standards dienen. Dabei wird
mit dem Begriff „Standard“ im folgenden Text sowohl ein de facto-Standard (z.B.
Hersteller- oder Domänen-spezifische aber weit verbreitete Schnittstellen) als auch ein
de jure-Standard (entspricht einer von einem offiziellen Gremium definierten Norm)
bezeichnet.
Die Anzahl und Breite der informationstechnischen Standards ist sehr gross und kann
im Rahmen dieses Beitrags nicht umfassend und vollständig beschrieben werden. Um
eine sinnvolle Eingrenzung des Themas vornehmen zu können, gehen wir zunächst von
einer in Fachkreisen allgemein anerkannten Architektur für Geodateninfrastrukturen
aus.
Bild 1: Middleware-Architektur für Geodateninfrastrukturen gemäss INSPIRE [1]
3.1
Informatik-Standards: für die Interoperabilität von GIS relevante Standards
Die in Bild 1 gezeigte 3-Schichten Architektur wurde so vom Expertengremium der EUInitiative INSPIRE (Infrastructure for Spatial Information in Europe) [1] verabschiedet
und basiert unter anderem auf den für den Geoinformationsbereich so bedeutsamen
Gremien:
x
x
ISO/TC 211 – Geoinformation - Geomatics [5]
Open Geospatial Consortium (OGC) [8]
Auf der untersten Ebene befinden sich Daten- und Metadatenquellen. Dort ist darauf zu
achten, dass Daten und Metadaten maschinell gelesen, interpretiert und verarbeitet
werden können. Schnittstellen zu Clients aber vor allem zu zugreifenden Diensten
(darunter die wichtigen Katalog- und Suchdienste) müssen exakt spezifiziert und
eingehalten werden. Nur so sind die vorhandenen Geodaten breit nutzbar.
In der mittleren Schicht müssen Basis- und Mehrwertdienste angeboten werden. Diese
müssen unabhängig von bestimmten Datenquellen funktionieren und austauschbar
sowie miteinander koppelbar sein. D.h. es müssen letztlich Schnittstellen zu
Datenquellen wie auch zu Clients und anderen Diensten (Middleware-Komponenten)
spezifiziert und eingehalten werden.
In der obersten Schicht befinden sich die Endnutzer-Anwendungen, zu denen auch
Portale zählen. Weitere Beispiele sind einfache Web-Browser, spezialisierte Dienste (z.B.
Routenplanung, Immobilienbewertung) aber auch traditionelle GIS. Hier sind ebenfalls
vor allem die Schnittstellen zu den Diensten und Datenquellen aber auch zu
Suchdiensten relevant.
Fasst man nun die Software-Architektur in Bild 1 als zu erreichendes Ziel auf, bleibt zu
überlegen, wie die einzelnen dort aufgeführten Komponenten über standardisierte
Schnittstellen miteinander kommunizieren können. Idealerweise sollten zu diesem
Zweck Standards gewählt werden, die
x
x
x
x
x
x
leicht implementierbar sind,
die Freiheit bei der Implementierung der Komponenten möglichst nicht oder nur
schwach einschränken
die Kommunikation zwischen den Komponenten sicherstellen,
den Ersatz einzelner Komponenten durch andere/neue ermöglichen,
die Erweiterbarkeit des Gesamtsystems ermöglichen,
kompatibel zu allgemeinen IT-Standards sind.
Im Bild 2 sind die korrespondierenden Standards der Reihe ISO 19100 des ISO/TC 211
und die Standards des OGC an den entsprechenden Schnittstellen oder für die
entsprechenden Komponenten dargestellt.
3.2
Bild 2: Middleware-Architektur mit ISO/TC 211 und OGC Standards
Auf die Beschreibung der Standards, die in diesen beiden Gremien entwickelt werden,
wird in diesem Beitrag explizit verzichtet, da andere Beiträge sich diesen Themen
widmen.
Aus Sicht der Informatik sollte man die folgenden Normungsgremien betrachten, die
auch einen Grossteil der Basis für ISO/TC 211 und OGC liefern:
x
x
x
x
Object Management Group (OMG) [6]
World Wide Web Consortium (W3C) [10]
International Organization for Standardization (ISO) [4]
International Electrotechnical Commision (IEC) [3]
Es existieren natürlich noch weitere Gremien, deren Beschreibung jedoch den Rahmen
dieses Beitrags sprengen würde. Aus Platz-und Zeitgründen aber auch aus Gründen der
unmittelbaren Relevanz behandeltdieser Beitrag vor allem die GIS-relevanten Standards
von OMG und W3C
Um diese in ihrer Funktion und in Relation zu anderen Standards einordnen zu können,
illustriert das folgende Bild 3 die Aufgaben der einzelnen Standards im Zusammenhang
mit den funktionalen Anforderungen der Interoperabilität.
3.3
Bild 3: Standards und ihre Aufgaben für die Realisierung von interoperablen Systemen
Die Nennung der in der Spalte „Interoperabilitäts-Standards“ angegebenen Standards
erhebt keinerlei Anspruch auf Vollständigkeit. Im Rahmen dieses Beitrags wird auch
nur auf einen geringen Teil der dort genannten Standards eingegangen.
2 Object Management Group (OMG)
Die Object Management Group (OMG) wurde 1989 von 11 Firmen gegründet, darunter
3Com, American Airlines, Canon, Data General, HP, Philips, SUN und Unisys. Das
Industrie-Konsortium zählt heute mehr als 800 Mitglieder. Es standardisiert offene,
verteilte, objekt-orientierte Systeme auf Middleware-Basis.
Unter den zahlreichen von der OMG entwickelten Standards haben die folgenden die
grösste Bedeutung für interoperable GIS:
x
x
x
Common Object Request Broker Architecture (CORBA)
Model Driven Architecture (MDA)
Unified Modeling Language (UML)
Die Standards werden in den folgenden Kapiteln etwas näher erklärt.
2.1 Common Object Request Broker Architecture (CORBA)
CORBA basiert auf dem ISO/IEC 10746 Standard for Open Distributed Processing, einer
allgemeinen Architektur offener, verteilter komponentenbasierter Systeme. Das OGC
beruft sich mit seinen Entwicklungen ebenfalls auf dieses ISO/IEC Standard und auf die
Entwicklungen der OMG. Eine 1. Version von CORBA wurde 1991 veröffentlicht. Seit
2000 ist CORBA ebenfalls als Standard der ISO (ISO/IEC 19500-2) erhältlich. CORBA
definiert die Komponenten und Rollen der Komponenten von MiddlewareArchitekturen.
3.4
2.2 Model Driven Architecture (MDA)
Die MDA vereinheitlicht als modellbasierte Software-Architektur die Modellierungsund Middleware-Bereiche der OMG. Sie unterstützt Anwendungen über ihren
gesamten Lebenszyklus von Analyse und Entwurf über Implementierung und
Entwicklung bis hin zur Pflege und der Erweiterung von Softwaresystemen. Die MDA
basiert auf UML Modellen. Die Beschreibungssprache UML wird im nächsten Kapitel
noch etwas näher beschrieben.
Das folgende Bild 4 illustriert die Funktion der MDA aus Sicht der OMG.
Bild 4: Funktionen der Model Driven Architecture
Die MDA integriert Anwendungen innerhalb eines Unternehmens und über das
Unternehmen hinaus mit Anwendungen anderer Unternehmen. Sie wurde von den
OMG-Mitgliedern als Basis für alle OMG-Spezifikationen im September 2001
verabschiedet. Weitere Infos finden sich unter [7].
2.3 Unified Modeling Language (UML)
UML standardisiert die Repräsentation von objekt-orientierter Analyse und Entwurf. Es
handelt sich bei UML um eine graphische Sprache mit einem Dutzend Diagrammtypen
(Anwendungs- und Aktivitätsdiagramme zur Anforderungserfassung, Klassen- und
Objektdiagramme für den Systementwurf, Paket und Subsystemdiagramme für die
Entwicklung, usw.). Software-Architekten und -Analysten können Anwendungen
standardisiert visualisieren, spezifizieren, konstruieren und dokumentieren. Die OMG
entwickelte UML also vor allem zum Entwurf von komplexen, verteilten
Softwaresystemen.
Im GIS-Bereich wird zur Zeit allerdings nur ein sehr kleiner Aspekt von UML genutzt:
die Möglichkeit, mit UML Datenmodelle zu beschreiben. UML ist allerdings sehr
verbreitet für die Nutzung und wird beispielsweise auch für die Spezifikation der ISO
19100 [5] Normenreihe intensiv gebraucht.
Weitere Informationen zu UML, Beispiele sowie UML-Kurse finden sich unter [9].
3.5
3 World Wide Web Consortium (W3C)
Das World Wide Web wurde 1989 von Tim Berners-Lee während seiner Tätigkeit am
CERN in Genf erfunden. Berners-Lee und andere gründeten im Oktober 1994 das World
Wide Web Consortium (W3C) als Industriekonsortium. Berners-Lee ist seit dem
Direktor des W3C.
Viele Informationen inklusive einer vollständigen Liste aller Standards finden sich unter
[10]. Kurse zu den meisten Standards finden sich unter [11].
Ziel des W3C ist es, Industrie-weiten Konsens über Web-Technologien herbei zu führen.
Das W3C hat die Aufgabe, das Wide World Web zur Nutzung seiner vollen Kapazität
zu führen, indem die gemeinsamen Protokolle entwickelt werden, die seine
Weiterentwicklung fördern und seine Interoperabilität gewährleisten.
Eine der Aufgaben des W3C ist es, einen Beitrag zur Standardisierung der WebTechnologien zu leisten, indem “Recommendations” genannte Spezifikationen, welche die
Grundlagen des Web beschreiben, produziert werden. Die Ziele des W3C können in den
sieben folgenden Punkten zusammengefasst werden: Universal Access, Semantic Web,
Trust, Interoperability, Evolvability, Decentralization und Cooler Multimedia.
Um diese Ziele zu erreichen, wurden verschiedene Arbeitsgruppen gegründet, welche
in fünf Bereiche aufgeteilt werden können:
Architecture Domain: Sie entwickelt die Web-Technologien. Innerhalb dieser Domäne
befinden sich Arbeitsgruppen zum Thema XML (XML Core Working Group, XML
Linking Working Group, XML Query Working Group und XML Schema Working
Group), WebServices (XML Protocol Working Group und WebServices Descriptor
Working Group), Uniform Resource Identifiers, DOM und Jigsaw.
Document Formats Domain: arbeitet an den Formaten und Sprachen für die
Informationsdarstellung. Zum Beispiel an der Hypertext Markup Language (HTML),
Style Sheets, Math, Graphics (z.B. Formate PNG, SVG, usw.),
Interaction Domain: beschäftigt sich mit der Unterstützung des Benutzers in der
Interaktion mit dem Web. Die Aktivitätsbereiche sind: Device Independence,
Multimodal Interaction, Synchronized Multimedia (SMIL) und Voice Browser.
Technology and Society Domain: berücksichtigt gesetzliche und sozialpolitische
Aspekte in der Web-Entwicklung. Die Aktivitätsbereiche sind: Semantic Web (z. B.
Resource Description Framework, RDF oder Web Ontology Language, OWL), Platform
for Privacy Preferences (P3P), XML Signature (xmldsig), XML Encryption, XML Key
Management, Patent Policy and Standards.
Web Accessibility Initiative (WAI): führt die Arbeiten zur Förderung des Web-Zugriffs
anhand von fünf Arbeitsbereichen fort: technology, guidelines, tools, education and
outreach, und research and development.
Das folgende Bild 5 illustriert die Funktionen der W3C Standards im Hinblick auf die
Funktionen und die Weiterentwicklung des World Wide Web.
3.6
Bild 5: W3C-Standards und die Weiterentwicklung des World Wide Web [10]
Für die GI-Normung sind dabei vor allem die folgenden Standards wichtig:
x
x
x
x
x
x
x
Uniform Resource Locators (URL), Uniform Resource Identifiers (URI),
HyperText Transfer Protocol (HTTP), HyperText Markup Language (HTML)
o Diese sind dem Leser (hoffentlich) bekannt und werden im folgenden
nicht mehr näher erklärt
Extensible Markup Language (XML) und XML Schema
Scalable Vector Graphics (SVG)
Resource Description Framework (RDF)
Web Ontology Language (OWL)
Simple Object Access Protocol (SOAP)
Web Services Description Language (WSDL)
3.1 Extensible Markup Language (XML)
Bei XML handelt es sich um ein Textformat, das als Derivat der
Dokumentenbeschreibungssprache Standard Generalized Markup Language SGML (ISO
8879) entstand. XML nutzt zur Zeichenkodierung den ASCII-Standard. Es ist beschreibt
sequentiell die Struktur von Dokumenten (z.B. Titel, 1. Kapitel, Absatz, Absatz, 2.
Kapitel, usw.). XML war ursprünglich nur für die breite elektronische Publikation von
Dokumenten gedacht. Heute wird es zunehmend für den Austausch beliebiger Daten in
der Informatik und eben auch zum Austausch von Geodaten verwendet.
Beispiel:
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
3.7
XML und XML-Derivate sind sehr gut für die Beschreibung von Daten geeignet, die
automatisch von Rechnern weiterberabeitet werden sollen. Das Lesen von XML-Dateien
durch Menschen ist natürlich möglich, aber extrem mühsam, da Menschen gewöhnlich
eher objekt-orientiert als sequentiell denken, sofern es sich bei den Daten nicht um
Dokumente handelt. XML und XML-Derivate zur Modellierung beliebiger Daten (nicht
Dokumente) zu verwenden ist prinzipiell möglich aber ebenfalls unsinnig. UML zum
Beispiel liegt viel näher an menschlichen Denkweisen.
3.2 XML Schema
XML Schema beschreibt so genannte shared vocabularies und bietet damit Methoden zur
Definition der Strukturen, Inhalte und Semantik von XML-Dokumenten. XML Schema
erlaubt die Definition von Klassen von XML-Dokumenten. Eine deutsche Beschreibung
zu XML-Schema findet sich z.B. unter [1].
XML Schema ist auch die Basis für den OGC Standard GML [8].
3.3 Scalable Vector Graphics (SVG)
SVG beschreibt 2D Graphiken. Es besteht aus 2 Teilen: XML-basiertes Dateiformat und
Programmierschnittstele für graphische Anwendungen. Es enthält z.B. verschiedene
Formen, Text, und Rastergraphik. SVG unterstützt Scripts und Animationen. Es nutzt
JPEG und PNG als Bildformate.
SVG wird für interaktive Anwendungen im Web, auf mobilen Systemen, etc. benutzt. Es
handelt sich um einen systemunabhängigen, offenen Standard. Die Autoren kommen
von: Adobe, Agfa, Apple, Canon, Corel, Ericsson, HP, IBM, Kodak, Macromedia,
Microsoft, Nokia, Sharp und Sun Microsystems. SVG viewers gibt es für alle gängigen
Web-Browser
3.4 Resource Description Framework (RDF)
RDF bietet einen Rahmen zur Beschreibung und zum Austausch von Metadaten, die
Informationen im Internet betreffen, gemäss den folgenden Regeln:
1. Eine Resource ist irgendetwas, dass einen URI haben kann; dies beinhaltet alle
WWW-Seiten aber auch individuelle Teile eines XML-Dokuments.
2. Ein PropertyType ist eine Resource, die einen Namen hat und als Property
genutzt werden kann, z.B. Autor oder Titel. In vielen Fällen kümmern wir uns
dabei nur um den Namen; aber ein PropertyType muss eine Resource sein,
damit er eigenen Properties (Eigenschaften) haben kann.
3. Eine Property ist die Kombination einer Resource, eines PropertyType und eines
Werts.
Beispiel:
"The Author of http://www.textuality.com/RDF/Why.html is Tim Bray.“ Der
Wert kann nur ein String sein, z.B. "Tim Bray" oder eine andere Resource, z.B.
"The
Home-Page
of
http://www.textuality.com/RDF/Why.html
is
http://www.textuality.com“
4. Diese Eigenschaften können direkt im XML beschrieben werden
3.8
3.5 Web Ontology Language (OWL)
OWL basiert auf RDF und bietet zusätzlich mehr Vokabular für die Beschreibung von
Eigenschaften und Klassen an, z.B.:
x
x
x
x
x
x
untereinander
Relationen zwischen Klassen
Kardinalitäten
Gleichheit
Charakteristika von Eigenschaften (z.B. Symmetrien)
Enumerationen
RDF nutzt Description Logics zur Modellierung von Daten (z.B. Geoobjekten) und deren
Eigenschaften.
Bild 6 zeigt ein Beispiel für deskriptive Logik.
Bild 6: Deskriptive Logik
OWL ist (ähnlich wie
Beschreibungssprache.
zum
Beispiel
INTERLIS)
auch
eine
konzeptionelle
3.6 Simple Object Access Protocol (SOAP)
Um Anwedungsprogramme auf einem Rechner zu koppeln, würde man typischerweise
auf die Nutzung so genannter Remote Procedure Calls (RPC) zurückgreifen. Bei der
Kopplung von Anwendungen, die jedoch auf verschiedenen Rechnern laufen, die durch
das Internet verbunden sind, ist dies nicht möglich. Firewalls würden RPCs sofort
zurückweisen. Daher wurde SOAP entwickelt.
SOAP ist ein Kommunikationsprotokoll, das die Kommunikation zwischen
Applikationen, die auf verschiedenen Betriebssystemen mit verschiedenen
Technologien und Programmiersprachen laufen, erlaubt. Es ist ein Format zum Senden
von Nachrichten und wurde speziell für die Kommunikation via Internet entworfen. Es
ist Plattform-unabhängig und basiert auf XML. Es ist einfach und erweiterbar und
erlaubt die Umgehung von Firewalls.
3.7 Web Services Description Language (WSDL)
WSDL ist ein spezielles XML-Format zur Beschreibung von Netzwerkdiensten als
Menge von Endpunkten, die auf Nachrichten operieren, die entweder Dokumentorientierte oder Prozedur-orientierte Informationen enthalten. Operationen und
Nachrichten werden abstrakt beschrieben und dann an ein konkretes Netzprotokoll und
Nachrichtenformat gebunden, um einen Endpunkt zu definieren. In Beziehung
3.9
stehende konkrete
kombiniert.
Endpunkte
werden
zu
abstrakten
Endpunkten
(Diensten)
WSDL ist unabhängig von Nachrichtenformaten und Protokollen. Üblich sind aber zur
Zeit die Verwendung von SOAP 1.1, HTTP GET/POST, und MIME (Multipurpose
Internet Mail Extensions) für WSDL.
Insbesondere für Geodateninfrastrukturen, in denen man gerne Dienste suchen und
finden und dann auch miteinander verketten möchte, gewinnt WSDL eine zunehmende
Bedeutung.
4 Abschlussbemerkungen
Die vorgestellte Liste der Informatik-Standards ist keineswegs vollständig und skizziert
auch nur gewisse Aspekte der Standards und deren Bedeutung für die Nutzung von
Geoinformationen. Alle Standards sind in „Bewegung“, d.h. sie sind zum Teil noch
nicht als Standards verabschiedet und werden noch bearbeitet. GI-Standards, die auf
diesen Informatik-Standards beruhen, sind allenfalls auch von diesem Aspekt der
Instabilität betroffen. Dies gilt insbesondere auch für den OGC-Standard GML.
Modellbasierte Ansätze beherrschen die Informatik-Standards für verteilte interoperable
Systeme. Die schlägt sich allerdings auch in den Ansätzen von ISO/TC 211, CEN/TC
287, der EU-Initiative INSPIRE aber auch in der nationalen Normung einzelner Länder,
darunter auch Deutschland (AAA Modell) und die Schweiz (INTERLIS!) nieder.
Das Semantic Web hat grosse Zukunft und wird stark vorangetrieben (z.B. mit RDF und
OWL).
Referenzen
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
3.10
http://www.edition-w3c.de/TR/2001/REC-xmlschema-0-20010502/
http://inspire.jrc.it/home.html
http://www.iec.org/
http://www.iso.org/
http://www.isotc211.org/
http://www.omg.org/
http://www.omg.org/mda/
http://www.opengeospatial.org/
http://www.uml.org/
http://www.w3.org/
http://www.w3schools.com/
4
Weltweite, europäische und
schweizerische GeoNormen in
Wechselwirkung
Hans Rudolf Gnägi, ETH Zürich
Hans Rudolf Gnägi
ETH Hönggerberg
CH-8093 Zürich
Tel :
Fax :
E-Mail :
+41 1 633 30 60
+41 1 633 11 01
1 Einleitung
Wer an Normen denkt, dem fallen spontan Stichworte ein wie „Schraubengewinde“,
„DIN A4“ und „Spurweite der Eisenbahn“. Dabei geht es um stabile Dinge des täglichen Lebens, die schon mehr oder weniger lang existieren und sich bewährt haben und
wo es nur noch darum geht, einige Details einheitlich festzulegen, um einer noch uneingeschränkteren Verwendung dieser Dinge letzte Hindernisse aus dem Weg zu räumen.
Ganz anders ist die Situation im Geoinformationsbereich. Da ist sozusagen nichts stabil,
Technisch jagen sich die inkompatiblen Versionen von Geoinformationssystemen und
Geodiensten in einem atemraubenden Tempo, die Geodaten werden immer umfangreicher, waren schon immer und bleiben teuer in der Herstellung, die Vielfalt von Austauschformaten nimmt babylonische Ausmasse an.
Und trotzdem sollten in dieser hoffnungslos dynamischen Situation mittels Normen
stabile Pflöcke eingeschlagen werden. Schon immer war da der Bedarf, Geodaten auszutauschen über lokale, regionale und nationale Grenzen, auch über Systemgrenzen. Nationale, regionale und globale Geodateninfrastrukturen rufen heute nach vielseitiger
Nutzung einmal erhobener Geodaten. Aber was und wie soll normiert werden? Wo sind
die Schraubengewinde im Geobereich? Zur Dynamik der Technik gesellen sich zudem
handfeste Interessenkonflikte. Während beispielsweise die Geodatennutzer an möglichst frei und vollständig austauschbaren sowie offen beschriebenen Geodaten interessiert sind, möchte ein GIS-Hersteller tendenziell eher seine Kunden an sein System binden durch möglichst hohe Hürden, die Daten wohldokumentiert und vollständig in ein
Mitbewerber-System transferieren zu können.
Im Folgenden soll kurz gezeigt werden, ob und wie erfolgreich das weltweite (ISO/
TC211), das europäische (CEN/TC287) und das nationale Normengremium (SNV/INB
TK 151) den mehrdimensionalen Spagat zwischen Technikdynamik und Anforderungswidersprüchen meistern.
2 Normen, was ist das? Qualitätskriterien, Entstehung,
Beeinflussung
DIN normt auch den Begriff „Normung” und zwar mit folgender Definition: Normung
ist planmässige, durch die interessierten Kreise durchgeführte Vereinheitlichung von
materiellen und immateriellen Gegenständen zum Nutzen der Allgemeinheit (DIN 820
Teil 3). Eine „Norm” ist das Resultat solcher Normungstätigkeit.
Das Interesse am „Nutzen für die Allgemeinheit“ von „Vereinheitlichungen“ im Geobereich meldete sich in der Schweiz, wie in den meisten Ländern, zunächst auf nationaler
Ebene an. Bedeutung und Wert der umfangreichen Geodatensammlungen führten zu
einer ersten Schweizer Norm „Sicherheit und Schutz von Geodaten“ (SN612010). Um
den Datenaustausch zwischen amtlicher Vermessung einerseits und Architektur und
Bau andererseits zu entwirren wurde die Norm „Datenreferenzmodell DXF Geobau“
(SN612020) erarbeitet. Die modellbasierte Methode, in Stürmen praktischer Anwendung
gereift, wurde als Norm „INTERLIS Datenbeschreibungssprache und Transfermethode“
(SN612030) fixiert
Es folgten „INTERLIS 2“ (SN612031), „Gebäudeadressen“
(SN612040), „Metadaten“ (SN612050), diese sind aber bereits beeinflusst von der weltweiten Geo-Normung, wo seit 1994 die wesentlichen Entwicklungen stattfinden.
4.1
Weltweite, europäische und schweizerische Geonormen in Wechselwirkung
Die Erfahrungen mit der Entwicklung von Schweizer Normen zeigten, dass eine Norm
nur dann „zum Nutzen der Allgemeinheit“ dient, wenn sie den folgenden Qualitätskriterien genügt.
E
Exakte knappe Formulierung mit präzisen klar definierten Begriffen aber auch
mit anschaulichen Erläuterungen.
M
Minimum, das nötig ist wurde festzulegen: „Vollständig“ ist eine Norm, wenn
sie alles enthält, was nötig ist für ein Vereinheitlichung, nicht alles, was existiert.
P
Praxiserprobung war erfolgreich
B
Breit abgestützte Einflussnahme auf die Erarbeitung
„Planmässig“ bedeutet im Geobereich, dass organisatorisch primär auf weltweiter Ebene normiert wird (ISO/TC211), diese Normen in Europa nach Prüfung von Bedarf und
Eignung als Euronormen (EN) anerkannt werden (von CEN/TC287), und dass diese
Euronormen von den Mitgliedländern schliesslich ins nationale Normenwerk übernommen werden müssen (in der Schweiz durch die Schweizerisch Normenvereinigung
SNV). „Planmässig“ verläuft auch der Lebenszyklus einer Norm: Dieser startet damit,
dass eine Mitgliednation oder ein Liaison-Mitglied die Idee für eine neue Norm als
„New work
item proposal“ (NWIP) formuliert. Wird dieses vom TC angenommen,
beginnt ein Projektteam (PT) „Committee Drafts“ (CD) auszuarbeiten, die von den Mitgliedernationen beurteilt werden können. Änderungswünsche werden durch „Editing
Committee Meetings“ (ECM) eingearbeitet. Ist ein CD stabil, dann kommt er zur Abstimmung als „Draft International Standard“ (DIS) und schliesslich als „International
Standard“ (IS). Analog entstehen bei ISO „Technical Reports“ (TR): Vom NWIP über
den „Provisional Draft Technical Report“ (PDTR) zum DTR und zum TR.
Soweit das Prozedere zur Schaffung von sogenannten „de jure“ Normen über die offiziellen Normengremien. Daneben haben sich im Geo-Bereich wie in der Informationstechnologie allgemein auch „de facto“ Normen durchgesetzt durch weitverbreiteten
Gebrauch. Man denke etwa an das „Drawing eXchange File“ (DXF) zum Austausch von
Vektorgrafik. Mit dem „Open Geospatial Consortium“ (OGC) hat sich ein Gremium
konstituiert, mit dem Ziel, Interoperabilität von GIS zu realisieren, d.h. Funktionalität
und Daten von GIS wechselseitig nutzbar zu machen, insbesondere, wenn nicht umfangreicher Datenaustausch gefordert ist. OGC umfasst als strategisch entscheidende
„principle members“ vor allem die grossen GIS-Hersteller. Viele an GIS interessierte
Administrationen, Universitäten und kleinere Firmen können zu bescheideneren Jahresbeiträgen und mit weniger Entscheidungsbefugnis ihre Ideen einbringen. Der grosse
Vorteil der de facto Normen von OGC gegenüber den de jure Normen von ISO ist, dass
meist erst auf Grund von Implementierungen für eine Idee der Normungsprozess gestartet wird, dass also das oben erwähnte Qualitätskriterium 3 der Praxiserprobung automatisch erfüllt ist. Entsprechend dem Ziel Interoperabilität liegt das Hauptinteresse
der OGC-Normungsarbeit im Bereich Internet basierte Dienste.
Einzigartig und ausserordentlich positiv für die Normung im Geo-Bereich ist, dass ein
Zusammenarbeitsvertrag zustande kam zwischen OGC und ISO/TC211. Er ist zwar insofern einseitig, als damit nur OGC Normenvorschläge in den ISO-Prozess einbringen
kann und nicht auch umgekehrt ISO/TC 211 bei OGC die Implementierung und damit
praktische Überprüfung von durch ISO entwickelten Normen beantragen kann. Aber
schon, dass OGC-Realisierungen auch den ISO-Prozess durchlaufen und so mit breiten
kritischen Stellungnahmen und Verbesserungsideen konfrontiert werden, die mittels
4.2
ECMs berücksichtigt werden, hat wesentliche Qualitätsverbesserungen zur Folge (Qualitätskriterium 4!).
Noch ein Blick auf die Normungsexperten von ISO/TC211: Deren Zusammensetzung
ist nach wie vor von unglaublicher Heterogenität. Viele kennen GIS nur von ferne, theoretisch, viele sind fixiert auf das eine GIS, mit dem sie gelegentlich oder täglich arbeiten,
Das Verständnis für die Bedeutung systemunabhängiger Lösungen und für die modellbasierte Methode ist zwar zunehmend aber immer noch sehr nahe bei Null.
3 Geo-Normen, Übersicht
Gesamtübersicht und Stand der ISO Normenserie 19100 gibt Tabelle 1. Von den 47 insgesamt gestarteten Projektteams wurden 3 wieder gestrichen und die übrigen produzierten bis zum 16.2.2005 insgesamt 18 IS und TR, 11 DIS und DTR, 9 CD und PDTR
und 6 NWIP sind noch nicht bis zum CD vorgedrungen.
Die ganze Normenserie basiert auf der modellbasierten Methode. Das heisst, es wird
grundsätzlich auf system-unabhängiger konzeptioneller Ebene normiert. Die konzeptionellen Schemata (Datenmodelle) der normierten Datenstrukturen bzw. Strukturelemente müssen für die Implementierung in GIS oder Datenbanken auf das logische
Schema (Datenmodell) dieser Zielsysteme umgebaut werden, um von dort, meist automatisch, auf den physischen Level des Betriebssystems bzw. des Rechners übersetzt zu
werden. Für den Datentransfer kann aus einem konzeptionellen Schema automatisch
direkt die Beschreibung des Transferformats, also das physische oder Transferschema,
hergeleitet werden.
Als konzeptionelle Beschreibungssprache verwendet ISO19100 die Umified Modelling
Language (UML). Als Transferformat wurde der XML-Dialekt GML gewählt, als physische Beschreibungssprache des Transferschemas zunächst XML-DTD und jetzt XMLSchema. Viele Leser aber auch Hersteller der Normen haben grosse Schwierigkeit, diese
verschiedenen Beschreibungsstufen auseinander zu halten. Es besteht ein wesentlicher
Unterschied zwischen der Beschreibung der Datenstruktur auf konzeptioneller Ebene
(bei ISO 19100 durch UML) und der Beschreibung des Transferformats (bei ISO 19100
durch XML-Schema). Wer ein physisches Transferschema als konzeptionelles Datenmodell betrachtet und bezeichnet bereitet sich selber vor allem unnötige Schwierigkeiten
und stiftet in der Geowelt unnötig Verwirrung.
Die Normen der Serie ISO 19100 können gegliedert werden in die beiden Hauptbereiche
Grundlagen und Anwendungen. Bei den Grundlagen zeichnen sich vier Teilbereiche ab:
Basis – Integrierbarkeit/Transferierbarkeit – Interoperabilität. Bei den Anwendungen
kann zur Zeit unterschieden werden zwischen Qualität/Metadaten – Pixelbilder/Gitterdaten – LBS – Adressen – Bewegte Objekte. Details zu den beiden Hauptbereichen sowie der Versuch eines Zustandsvergleichs ISO-CEN-SNV für den Grundlagenbereich folgen im nächsten Abschnitt.
Tabelle 1 enthält in der dritten Kolonne eine grobe Beurteilung aller Normen. Dabei fällt
sehr unangenehm auf die grosse Zahl von Normen mit der Bemerkung „No“. Wegen
der sehr beschränkten personellen und finanziellen Kapazität der Schweiz im GeoNormenbereich konnten alle diese Dokumente überhaupt nicht bewertet werden
4.3
Nr
ISO
Sta
nd
6709
19101
19101-2
19102
19103
19104
19105
19106
19107
19108
19109
19110
19111
19112
19113
19114
19115
19115-2
19116
19117
19118
19119
19120
19120 A
19121
19122
19123
19124
19125-1
19125-2
19125-3
19126
19127
19128
19129
19130
19131
19132
19133
19134
19135
19136
19137
19138
19139
19140
19141
¬

¬
±

|

±

|

±
¬

|
¬
¬
|

¬

¬
¬
|
|
BeurTitel
Dokument Nr
teilung
?
Std, representation of lat., long., alti. for pt. loc.
N1733
j? GI – Reference Model
N1197, ISO19101
GI – Reference Model – Part 2: Imagery
N1455,N1489
GI – Overview
j? TR GI – Conceptual Schema Language
N1527
?
GI – Terminology
Spread sheets N1485, DIS 19104
No GI – Conformance and Testing
(2000) ISO 19105
No Gi – Profiles N1483,
(2004) ISO 19106
(2003) ISO 19107
! o GI – Spatial Schema (siehe 19137)
?
GI – Temporal Schema
FDIS N1225, ISO 19108
?
GI – Rules for Application Schema
N1538, DIS 19109
?
GI – Feature Cataloguing Methodology
N1567 (2005) IS
j! GI – Spatial Referencing by Coordinates
(2003) IS
!
GI – Spatial Referencing by Geo Identifiers
(2003) IS
No GI – Quality Principles
(2002) ISO 19113
No GI – Quality Evaluation Procedures
(2003) ISO 19114
j? GI – Metadata
(2003) ISO 19115
No GI – Metadata 2; Extensions for IGD
N1396, N1425
No GI – Positioning Services
N1547 (2004) ISO 19116
?
GI – Portrayal
N1578 (2002) DIS 19117
?
GI – Encoding
N1580 (2002) DIS 19118
No GI – Services
N1540 (2002) DIS 19119
No TR GI – Functional standards
(2001) ISO TR 19120
No TR GI – Functional standards amendmt 1
No TR GI – Imagery and gridded data IGD
(2000) ISO TR
j? TR GI – Qualif. and certif. of pers N1491
(2004) ISO TR
No GI – Schema for coverage geom. & funct
N1740 FDIS
No TR GI – Imagery and gridded data components
N1017
(2004) IS
! o GI – Simple feat. acc - P1 Comn arch N1563
(2004) IS
! o GI – Simple feat. acc - P2 SQL option N1565
GI
–
Simple
feature
access
–
P3:
COM/OLE
opt.
N997
!o
No GI – Profile – FACC data dictionary
N1561
j? TR GI – Geodetic codes and parameters
N1751 FDTR
No GI – Web map server interface
N1675, DIS
No TR GI – Imagery, gridded & coverage data frwk.
N1252
No GI – Sensor and data models for IGD
N1772
j? GI – Data product specification
N1688
No GI – Location based serv.- reference model
N1599
No GI – Location based serv tracking and navig. N1762,DIS
No GI – Multimodal LBS for routing and navigation
N1768
No GI – Procedures for registration of GI-items
N1605 DIS
j? GI – GML
N1576
j
GI – Core profile of spatial schema
N1670 DIS 19137
j
GI – Data quality measures
N1744, PDTS
?,! GI – Metadata – XML schema implem.
N1663, PDTS
j
GI – Technical amendment of ISO19100 series
N1346
No GI – Schema for moving features
N1757
CH Norm
SeiSN6120xx-y
ten
xx Nr.Teil
ISO
y Kap,Annex
31-2.9.4
48 31-1
Seiten
CH
1
13
71
19
26
38
184
55
83
60
44
30
38
79
150
31-2
31-L
50
22
31-2.8.11/12
31-H
Mod.Meth.G
Mod.Meth.G
31-J
40
10
4
50
59
47
117
74
31-2.16, -K
31-3
Checker,...
13
15
12
63
39
48
72
124
31-2.8.11/12
31-2.8.11/12
31-2.8.11/12
s.o.
s.o.
s.o.
39
31-J
s.o.
13
107
76
Mod.Meth.G
20
Tab. 1 : Stand der Geo-Normen-Serie 19100 von ISO/TC 211 (2005-02-16)
4.4
Legende zu Tabelle 1: Stand der Geo-Normen-Serie 19100 von ISO/TC 211 (2005-02-16)
Legende Stand der Normen
Legende Beurteilung Sicht CH
= IS International Standard (or TR Technical Report)
j = zweckmässiges Konzept
= DIS Draft International Standard (or DTR Draft Technical Report)
? = Unklarheiten, Probleme
¬ = CD Committee Draft (or PDTR Provisional Draft Technical Report)
! = Widerspruch zu anderen Normen
| = NWI New Work Item beschlossen
o= Folgearbeiten notwendig
u = aufgehoben
No = keine Beurteilung Sicht CH
Mod.Meth.G = Modellierungs Methode, INTERLIS Grundkurs
4 Für Integrierbarkeit und Interoperabilität wesentliche
Normen
Für Integrierbarkeit und Interoperabilität wesentlich sind ohne Ausnahme alle Normen
des Grundlagenbereichs. Tabelle 2 bringt eine vergleichende Übersicht dieser Grundlagennormen in thematischer Ordnung gemäss den oben beschriebenen Teilbereichen.
Für die ISO/CEN-Normen einerseits und für die entsprechenden SNV-Normen andererseits kommen die in Abschnitt 2 eingeführten Qualitätskriterien zur Anwendung.
Nr ISO
CEN
Basis
Name ISO CEN
E
N
E M P
B Nr SNV
Name CH Norm
E M P B
.
19103
Conceptual schema language
ï
s
19104
Terminology principles
ï
G s
G G 612031
19107
19123
19125
19137
19111
19127
Spatial schema
Schema for coverage..
Simple features
Minimal profile spa sch
Referencing by coord
Geodetic codes and par
9
ï
ï
ï
9
ï
s
ï
s
G
s
s
u
ï
G
G
s
s
u
ï
G
s
s
G
19108
Temporal schema
9
s
u u
s
19109
19110
Rules for applic schema
Feature cataloguing met
ï
ï
s
s
u u
u s
s
612031
G
19106
Profiles
ï
ï ï ï
ï 612031
19119
Services
ï
ï ï ï
ï 612031
Integrierbarkeit/Transferierbarkeit
19118
Encoding
19136
GML
ï
ï
u u u
s u s
.
G
612031
G
19117
ï
u u u
s
ï
ï
ï ï ï
ï ï ï
ï ï
ï ï
Portrayal
Interoperabilität
19128
WMS
NWIP
WFS
s
u
s
612031
u
ï
612031
s
G
G
612031
G
612031
612031
INTERLIS 2, Kapitel 2
Beschreibungssprache
INTERLIS 2, Anhang L
Glossar
INTERLIS 2, Abschnitt
2.8.7 Koordinaten, 2.8.11
Linienzüge,
2.8.12 Flächen, Gebiete
INTERLIS 2, Anhang J
Koordinaten(ref)system
INTERLIS 2 Anhang H
Zeit-Definitionen
INTERLIS 2, Kapitel 1,
Grundprinzipien, UsHB
2.4 Vererbung
1.8 Dienste, Werkzeuge
INTERLIS 2, Kapitel 3
sequentieller Transfer
2.16 Darstellungsbeschr
G s
G G
G G G G
G G G G
G G u G
G s
u G
G G G G
G G s
G
G u u G
G G G G
s
s
s
G
.
ï
ï
ï ï ï ï
ï ï ï ï
Tab. 2 : Stand der Geo-Normen-Serie 19100 von ISO/TC 211 (2005-02-16)
Legende: Kolonne EN: 9 = existiert als Euronorm, ï = existiert noch nicht als Euronorm.
Bewertungskolonnen E = Exakte knappe Formulierung. M = Minimum festgelegt,
P = Praxiserprobung war erfolgreich, B = Breit abgestützte Erarbeitung.
Bewertung: G = gut, s = genügend (sufficient), u = ungenügend, ï = nicht bewertet
Dass sich unter den Schweizer Normen bei INTERLIS 2 alle Themen der Basisnormen
und der Normen zur Integrierbarkeit/Transferierbarkeit von ISO vorfinden beruht auf
4.5
der Wechselwirkung, die zwischen diesen beiden Normengremien stattfand.
INTERLIS 1 wurde auch auf Grund der Anforderungen von ISO/TC211 an die für die
Normenserie ISO 19100 auszuwählende konzeptionelle Beschreibungssprache
entsprechend weiterentwickelt zu INTERLIS 2. Hauptforderung des Projektteams 3 von
ISO/TC211 war volle Objektorientierung. Auch war XML als Transferformat verlangt.
Die Wahl von ISO/TC211 erfolgte dann für die grafische Sprache UML. Als textuelle
CSL sind alle diejenigen zugelassen, deren Sprachelemente sich eindeutig auf die in ISO
19103 festgelegten Sprachelemente von UML abbilden lassen. Das ist für INTERLIS 2
der Fall.
5 Nächste Schritte
Die verschiedenen Lücken in Tabelle 2 zeigen deutlich den Verbesserungsbedarf vieler
bereits verabschiedeter ISO-Normen. Dafür hat ISO/TC211 mit dem Projekt 41 den
Amendment
Prozess
gestartet.
Über
diese
Schiene
sind
begründete
Verbesserungsanträge einzureichen.
Gewisse Normen sind eigentlich eher technische Reports über den aktuellen Stand der
Dinge. So etwa das ‚Spatial schema’ ISO 19107 und das ‚Temporal schema’ ISO 19108.
Beide haben deshalb in der Kolonne M „Minimum festgelegt“ ein u für „ungenügend“.
Damit zu diesen Themen eine minimale aber echte Integrierbarkeit / Interoperabilität
unterstützt wird, muss für beide Normen eine konsistente Teilmenge als sogenanntes
Profil definiert werden. Ein erster Schritt in dieser Richtung wurde bereits gemacht mit
dem minimalen Profil des ‚Spatial schema’ durch ISO 19137.
Eine Dauerfrage ist immer: Genügt eine graphische CSL auf konzeptioneller Ebene? Es
ist klar, dass etwa im Bereich der Datentypen eine Präzisierung nötig ist, um Transferformate (und andere Dienste) eindeutig generieren zu können. Diese Präzisierung sollte
nicht versteckt werden in XSLT-Skripts, sondern offengelegt werden mit einer normierten textueller konzeptionellen OO Beschreibungssprache.
Die Lücke bei den Schweizer Normen im Bereich Web-Services bedeutet nicht, dass es
keine INTERLIS basierten Web-Dienste gibt. Im Gegenteil. Es sind verschiedene grosse
Geo-Portale in Betrieb mit Hilfe von INTERLIS. Hingegen soll darüber hinaus versucht
werden, durch eine Kombination der modellbasierten Methode mit den OGC WebServices eine „best of“ Lösung des Typs Model Driven Web Feature Server (MDWFS) zu
bauen.
6 Zusammenfassung
Klar ist: Die modellbasierte Methode ist Basis der weltweiten und der europäischen
Geo-Normung.
Transferformate sollten eigentlich verschieden gewählt werden können entsprechend
verschiedenen Bedürfnissen und Ansprüchen (Binär / ASCII / tagged). Der modellbasierte Ansatz, aus einem system- und formatunabhängigem Datenmodell automatisch
verschiedene Formate herzuleiten gemäss definierten Regeln (und in Zukunft auch verschiedene Protokolle), ist auch in dieser Beziehung sehr viel versprechend.
Bleibt zum Schluss noch die Frage, ob die Geo-Normung den mehrdimensionalen Spagat zwischen Technikdynamik und Anforderungswidersprüchen erfolgreich meistert.
Wir müssen die Beantwortung der Zukunft überlassen. Aber mindestens ist mit dem
Entscheid für die modellbasierte Methode eine sehr tragfähige Voraussetzung für einen
Erfolg geschaffen.
4.6
5
Open Geospatial Consortium OGC
GML, WMS und WFS
Adrian Annen, Fachhochschule beider Basel
(FHBB), Abt. Vermessung und Geoinformation
Adrian Annen
Fachhochschule beider Basel
Abteilung Vermessung und Geoinformation
Gründenstrasse 40
CH-4132 Muttenz
Tel :
Fax :
E-Mail :
+41 61 467 44 68
+41 61 467 44 60
1 Kurzfassung
Mit dem Open Geospatial Consortium (OGC) existiert ein internationales Industriekonsortium mit dem Ziel, die Interoperabilität von Geodaten zu verbessern. Die Abkürzungen GML, WMS und WFS, welche im Zusammenhang mit dem OGC oft verwendet werden, sind Bezeichnungen für offene, systemunabhängige Mechanismen
zum Austausch von Geodaten. Bei der Geography Markup Language (GML) handelt
es sich um eine XML-basierte Applikation für die Modellierung und den Austausch
von Daten mit Raumbezug. GML wird unter anderem für verschiedene Webdienste
verwendet. Als Beispiel kann der Web Feature Service (WFS) genannt werden, welcher für den Austausch und die Manipulation von Daten über das Web verwendet
wird. Demgegenüber bietet der Web Map Service (WMS) einen Webdienst für gerenderte Karten an. Die WMS-Spezifikation ist die bisher am erfolgreichsten umgesetzte Spezifikation des OGC.
2 Einleitung
Im Zusammenhang mit dem Begriff der Interoperabilität im Geoinformationsbereich
werden oft Abkürzungen wie OGC, GML, WMS und WFS verwendet. Seit den frühen
neunziger Jahren hat sich in diesem Bereich eine breit abgestützte Organisation (Open
Geospatial Consortium) gebildet, welche bestrebt ist, offene, systemneutrale Schnittstellen zu schaffen, und so die Verfügbarkeit von Daten mit Raumbezug weltweit zu erhöhen. Dabei wird auf bestehende Standards der Informatik-Welt aufgebaut. Zum Beispiel
dient XML als Grundlage für praktisch alle Spezifikationen des OGC.
Eine bereits erfolgreich umgesetzte Spezifikation des OGC ist der Web Map Service
(WMS). Diese wurde von diversen kommerziellen Herstellern und von einigen OpenSource-Projekten erfolgreich implementiert.
Den wohl wichtigsten Standard des OGC stellt die Geography Markup Language
(GML) dar. GML stellt einen Mechanismus zur Modellierung und zum Austausch von
primär vektor-orientierten Geodaten zur Verfügung. Verschiedene Webdienste wiederum bauen auf GML auf. Ein Beispiel für solche Webdienste ist die Web Feature Service
(WFS)-Spezifikation.
In den folgenden Abschnitten werden das OGC selbst, sowie die oben genannten Spezifikationen näher vorgestellt. Zu beachten ist, dass damit nur ein kleiner Ausschnitt der
vielfältigen Arbeit des OGC beleuchtet werden kann. Für detailliertere Informationen
sei an dieser Stelle auf die Webseite www.opengeospatial.org verwiesen.
3 Open Geospatial Consortium (OGC)
3.1 Wer ist das OGC?
Das Open Geospatial Consortium (OGC) ist ein internationales Industriekonsortium,
bestehend aus über 270 Firmen, Behörden und Hochschulen, welches sich zum Ziel gesetzt hat, öffentlich verfügbare Schnittstellen-Spezifikationen im Konsensverfahren zu
entwickeln. OGC-Spezifikationen unterstützen interoperable Lösungen, welche das
Web, mobile Anwendungen, Location Based Services (LBS) und allgemeine Informatiklösungen um einen Raumbezug erweitern. Mit den OGC-Spezifikationen soll es Entwicklern möglich sein, komplexe Geoinformationen und darauf basierende Dienste einem breiten Spektrum von Nutzern und Anwendungen zugänglich zu machen.
5.1
Open Geospatial Consortium OGC (GML, WMS und WFS)
Das OGC finanziert sich primär über die Beiträge seiner Mitglieder. Zurzeit existieren
acht verschiedene Mitgliederkategorien. Diese unterscheiden sich im zu entrichtenden
Jahresbeitrag (zwischen 300$ bis >50'000$ pro Jahr) aber auch in den Rechten und Pflichten.
OpenGIS® ist eine geschützte Marke des Open Geospatial Consortium, Inc. und dient
gleichzeitig als Produktname für die Spezifikationen und Dokumente, welche vom OGC
erstellt und publiziert werden.
3.2 Geschichte
Die wichtigsten Ereignisse in der Geschichte des OGC können wie folgt zusammengefasst werden:
Jahr
80er Jahre
1994
1999
2004
Meilenstein
Diverse Aktivitäten rund um das Open Source Projekt GRASS
(Geographic Resource and Analysis Support System)
Gründung des Open GIS Consortium, Inc.
Mitgliederzahl Ende 1994: 20
Publikation der OpenGIS Web Map Server Interface Specification
und des Zusammenarbeitsvertrags zwischen ISO/TC 211 und OGC
Umbenennung in Open Geospatial Consortium, Inc.
Im Januar 2005 existierten 17 Abstract Specifications und 14 Implementation Specifications. Zusätzlich wurden unzählige Recommendation Papers und weitere Entwürfe öffentlich publiziert.
4 Geography Markup Language (GML)
4.1 Was ist GML?
Die Geography Markup Language (GML) ist eine XML-Applikation des Open Geospatial Consortiums (OGC) für die Modellierung, den Austausch und die Speicherung
von Informationen mit Raumbezug. Die wichtigsten Ziele von GML sind:
x
x
x
x
x
x
x
x
Unterstützung möglichst vieler Einsatzgebiete (auch nicht-räumliche Daten können abgebildet werden)
GML als Grundlage für Internet-GIS Anwendungen
Einfach zu verstehende Codierung räumlicher Daten und derer Beziehungen
Effiziente Codierung von Geometriedaten
Trennung der Daten von deren Präsentation
Einfache Integration bereits in XML vorhandener, nicht-räumlicher Daten
Möglichkeit der Verknüpfung verschiedener Datensätze
Bereitstellung eines Basissatzes geometrischer Objekte
Diese Ziele werden mit einer umfangreichen Spezifikation angepeilt. Die aktuelle Version (3.1) der GML-Spezifikation beinhaltet etwa 600 Seiten.
5.2
4.2 Einsatzspektrum
Eines der wichtigsten Ziele ist die universelle Verwendbarkeit von GML als Datenformat für beliebige Anwendungen mit räumlichem Bezug. Die hauptsächlichen
Einsatzgebiete von GML sind:
x
x
x
Austausch von Daten zwischen verschiedenen GIS-Systemen
Basis für Internet-GIS Anwendungen (Bsp. Web Feature Service, WFS)
Basis für Location Based Services (LBS)
4.3 Konzept
Das Konzept von GML beruht auf dem Feature-Modell des OGC. Ein 'Feature' gemäss
der OGC-Definition besteht aus einem Objekt mit einer Reihe von Eigenschaften ('Properties'). Jede dieser Eigenschaften ist charakterisiert durch ihren Namen, ihren Typ und
ihren Wert. Wenn der Typ zumindest einer Eigenschaft eines Features geometrisch ist,
spricht man von einem geographischen Feature. Mehrere Features können zu Feature
Collections zusammengefasst werden. Eine Feature Collection repräsentiert allerdings
wiederum ein Feature, so dass eine beliebig tiefe Schachtelung modelliert werden kann.
Abb. 1 : GML-Grundkonzept
GML 3 ist in ca. 30 XML-Schema-Dokumenten (Basisschemen) definiert. Für eine konkrete Anwendung von GML muss ein anwendungsspezifisches Schema abgeleitet werden, welches auf den in den Basisschemen definierten Klassen aufbaut. Im Applikationsschema können eigene Features mit anwendungsspezifischen Eigenschaften definiert werden. Dies kann über Erweiterung oder Einschränkung der vorhandenen Klassen erreicht werden.
4.4 Verbindung zu ISO
Das OGC ist bemüht, seine Konzepte denjenigen der ISO (International Organization for
Standardization) anzupassen. So ist vorgesehen, die OGC-Spezifikation GML (Version
3.x) mit der ISO Norm 19136 (Geography Markup Language GML) zu harmonisieren.
Gegenwärtig ist die ISO Norm 19136 in der 'Commitee Stage' (Stand Januar 2005). Das
bedeutet, dass sich das zuständige Technical Commitee (TC) der ISO mit der Spezifikation befasst. In diesem Fall ist das TC 211 der ISO zuständig. Für nähere Angaben wird
auf die Website der ISO (www.iso.org) verwiesen.
5.3
5 OGC Web Services
5.1 Zielsetzung
Vielerorts sind bereits grosse Mengen von Daten in proprietären Datenformaten vorhanden. Die Nutzung dieser Daten von fremden Systemen aus ist nur mühsam, oder
gar nicht möglich. Eine Lösung dafür bieten Webdienste an. Dabei wird über das Internet auf verteilte Datenquellen zugegriffen. Neben den grossen GIS-Herstellern, die solche Lösungen anbieten, sind auch Open Source Projekte verfügbar, die diese Funktionalität zur Verfügung stellen. Weiterhin ungelöst bleibt die Verknüpfung von unterschiedlichen Diensten (Insellösungen). Dies ist der Ansatzpunkt der OGC Web Services. Sie
definieren Methoden, eine Reihe von Parametern sowie Kommunikationsregeln, die einem beliebigen System den Zugriff auf verteilte Datenquellen ermöglichen, sofern beide
Komponenten über die identische Schnittstelle verfügen.
5.2 Grundprinzip
Die OGC definierte in der OWS (OGC Web Services) Common Implementation Specification die Gemeinsamkeiten ihrer verschiedenen Web Services. Der Ausdruck Web Service beschreibt die standardisierte Weise der Integration netzwerk-basierter Applikationen. Für die Definition und Beschreibung der Applikationen wird XML verwendet. Die
Kommunikation erfolgt auf der Basis von Internet-Protokollen. Durch den Einsatz von
XML sind Web Services nicht an ein bestimmtes Betriebssystem oder eine bestimmte
Programmiersprache gebunden.
Abb. 2 : Funktionsschema OGC Web Services
Das in Abb. 2 dargestellte Funktionsschema stellt folgende Funktionen dar:
1. Client kontaktiert Server und fordert Capabilities-Dokument an
2. Server liefert XML-formatierte Capabilities (Beschreibung der Funktionalität) des
gewünschten Services an den Client
3. Client fordert Daten vom Server an
4. Server liefert die angeforderten Daten im verlangten Format
Diese vier Schritte bilden die Grundfunktionalität eines Services nach OGC-Spezifikation. Je nach Service sind weitere Interaktionen zwischen Client und Server möglich,
beispielsweise das Abfragen weiterer Informationen über ein Feature, ein Kartenlayer
etc.
Web Services kommunizieren (gemäss ihrer Definition) mit Hilfe von beliebigen Internet-Protokollen miteinander. Die meisten OGC Web Services benutzen zurzeit das
HTTP-Protokoll. Das Hyper Text Transfer Protocol (HTTP) verfügt über ein sehr einfaches Interaktionsschema zwischen Client und Server, welches aus einem von einem
Client an einen Server gesendeten Request (Anfrage) und einer vom Server an den
Client geschickten Response (Antwort) besteht.
5.4
5.3 Web Map Service (WMS)
Die WMS-Spezifikation beschreibt eine Schnittstelle, über welche georeferenzierte Karten bereitgestellt werden können. Die Realisierung basiert auf drei Grundoperationen,
für die jeweils ein Parametersatz definiert ist:
x
x
x
Beschreibung der verfügbaren Daten (GetCapabilities)
Lieferung der angeforderten Daten (GetMap)
Abfragen weiterer Informationen (GetFeatureInfo)
Dabei sind die ersten beiden Operationen zwingend zu implementieren, die Funktion
zur Abfrage von Feature-Informationen ist optional.
Der Zugriff auf einen WMS kann mit Hilfe eines Standardbrowsers erfolgen, wobei die
Parameter in der URL übermittelt werden (GET Methode). Komfortabler sind natürlich
Programme mit einer graphischen Benutzeroberfläche (GUI), entweder als Browser- oder als Standalone-Applikation konzipiert. Mit der aktuellen WMS-Version (1.3) ist auch
die Übermittlung der Anfragen mit der POST Methode festgelegt.
Im Allgemeinen liefert ein WMS gerenderte Bilder in einem üblichen Bildformat wie
PNG (Portable Network Graphics), JPEG (Joint Pictures Expert Group) oder GIF (Graphics Interchange Format). Denkbar ist aber auch die Erzeugung von Karten im SVGFormat (Scalable Vector Graphics).
Abb. 3 : Schematische Darstellung verteilter WMS
WMS-Karten können von beliebigen, verschiedenen WMS angefordert werden. Das
heisst, die Spezifikation unterstützt den Aufbau eines Netzwerkes verteilter Map Server
von denen ein Client Daten anfordern kann (siehe Abb. 3). Da jeder WMS unabhängig ist,
muss jeder die Fähigkeit besitzen, seine Möglichkeiten und Ressourcen maschinenlesbar zu beschreiben.
In Abb. 3 ist zudem das Konzept eines kaskadierenden Map Servers (Cascading Map
Server) dargestellt. Dabei ist ein Map Server ein Client von anderen WMS und bildet
gegen aussen einen neuen Web Map Service (Zusammenfassen mehrerer WMS in einen
Service).
Die Spezifikation WMS 1.3 des OGC wird zurzeit als ISO/DIS Norm 19128 (Web Map
Server Interface) in die ISO-Normenserie integriert.
5.4 Web Feature Service (WFS)
Während mit dem WMS in der Regel gerenderte (Raster-)Daten geliefert werden, steht
bei der WFS-Spezifikation die Übertragung von geographischen Objekten im Vordergrund. Dabei stellt sich das Problem, dass Geodaten oft nicht nach einem einheitlichen
Datenschema modelliert sind. Deshalb ist es wichtig, dass das Datenschema mit den Daten mitgeliefert wird. Ein entsprechender Client muss somit mit diesem Datenschema
und den Daten umgehen können.
5.5
Als Grundlage für die WFS-Spezifikation dient der Datenaustauschmechanismus GML
(Geography Markup Language) des OGC. Damit können Geodaten und ihr zugehöriges
Schema in XML codiert und übertragen werden.
Im Unterschied zum WMS ist es auch möglich, diese Daten zu manipulieren und zu
verändern. Dazu wurden weiterführende Operationen wie 'Transaction' und 'LockFeature' definiert.
Die folgenden Operationen sind in der WFS-Spezifikation definiert:
x
x
x
x
x
GetCapabilities: Ein WFS muss in der Lage sein, seine Funktionalität zu beschreiben.
Im Speziellen muss er in der Lage sein, die unterstützen Feature-Typen und die
darauf anwendbaren Operationen anzugeben.
DescribeFeatureType: Auf Anfrage muss ein WFS in der Lage sein, die Struktur jedes
unterstützten Feature-Typen zu liefern (Datenschema). Konkret wird hier ein
GML-Applikationsschema übertragen.
GetFeature: Ein WFS muss in der Lage sein, Instanzen (Objekte) von Feature-Typen
zu liefern. Zusätzlich muss er erkennen, welche Eigenschaften (properties) er mitliefern soll, und er muss in der Lage sein, sowohl räumliche wie auch nichträumliche Selektionen zu unterstützen.
Transaction: Ein WFS kann in der Lage sein, Operationen an Objekten auszuführen.
Diese Operationen sind 'create', 'update' und 'delete' an geographischen Objekten.
LockFeature: Ein WFS kann einen Lock-Request auf eine oder mehrere Instanzen
während der Dauer einer Transaktion anwenden.
Dementsprechend kann zwischen verschiedenen Typen von Web Feature Services unterschieden werden:
x
x
Basic WFS: Ein Basis-WFS unterstützt die Operationen 'GetCapabilities', 'DescribeFeatureType' und 'GetFeature'. Dies entspricht einem 'Read-Only'-WFS.
Transaction WFS: Dieser unterstützt sämtliche Operationen des Basis-WFS, und
zusätzlich die Operationen 'Transaction' und 'LockFeature' (optional).
Ein WFS liefert mit dem GetFeature-Aufruf ein GML-Instanzdokument. In der aktuell
gültigen Version der WFS-Spezifikation (1.0) ist festgelegt, dass die GML-Version 2
verwendet werden soll. Gegenwärtig ist die WFS-Spezifikation in einer Überarbeitungsphase, in welcher unter anderem die Integration der Version 3 von GML diskutiert wird. Allerdings ist noch nicht klar, ob die vollständige GML 3 – Spezifikation
unterstützt werden soll. Auf Grund der Komplexität der aktuellen GML-Version wird
über eine Einschränkung mit einem Profil (Level 0) diskutiert.
6 Fazit
Mit dem OGC hat sich im Geoinformationssektor ein sehr aktives, internationales Industriekonsortium mit internationalem Standardisierungsanspruch etabliert. Durch die
Mitwirkung grosser Systemhersteller, nationaler und internationaler Behörden und vieler Hochschulen ist das Konsortium mittlerweile breit abgestützt. Mit seinen Aktivitäten
hat das OGC zu einer deutlichen Verlagerung bzw. Erweiterung des Fokus von den vielen nationalen Normen und Standards auf die internationale Standardisierung beigetragen. Erfreulich ist, dass dabei die OGC seit einigen Jahren ihre Aktivitäten mit denjenigen der ISO harmonisiert, was mittel- und langfristig zu einer breiteren Akzeptanz und
auch zu stabileren Standards führen dürfte.
Mit WMS, WFS und GML hat das OGC drei sehr nützliche Spezifikationen geschaffen.
Dabei hat sich am Beispiel des WMS gezeigt, dass sogar die Umsetzung eines relativ
5.6
einfachen Standards auf internationaler Basis mehrere Jahre in Anspruch nehmen kann.
Es ist daher anzunehmen, dass die Definition von Minimalprofilen im Falle von GML
und WFS eine erfolgreiche Umsetzung deutlich beschleunigen würde. Der für einen
breiten Einsatz der Standards dringende Übergang von formatbasierten auf modellbasierte Mechanismen wurde von OGC mittlerweile erkannt und eingeleitet. Das damit
verbundene Umdenken bei Systemherstellern und Anwendern sowie die konsequente
Umsetzung dürften aber noch viel Arbeit und Zeit erfordern.
7 Literatur
Nebiker S. und Annen A. , 2004
Vergleichsstudie INTERLIS 2 – GML 3
Verfügbar unter:
http://www.kogis.ch/docs/Vergleichsstudie_ILI_GML_revidiert.pdf
[Online 21. Jan. 05]
Nebiker, S., et al., 2004
Skript zum GIS/SIT-Workshop 2004: 'WMS, WFS, Simple Features und Co.'
[durchgeführt am 30. März 2004 in Bern]
Open Geospatial Consortium Inc. (OGC), 2004
Geography Markup Language (GML) Recommendation Paper 3.1
Verfügbar unter:
http://portal.opengeospatial.org/files/?artifact_id=4700 [Online 21. Jan. 05]
Web Map Service (WMS) Implementation Specification 1.3
Verfügbar unter:
http://portal.opengeospatial.org/files/?artifact_id=5316 [Online 21. Jan. 05]
Web Feature Service (WFS) Implementation Specification 1.0
Verfügbar unter:
https://portal.opengeospatial.org/files/?artifact_id=7176 [Online 21. Jan. 05]
International Organization for Standardization (ISO).
Informationen zu diversen Standards
Verfügbar unter:
http://www.iso.org [Online 21. Jan. 05]
5.7
6
OGC-Lösungen
Möglichkeiten und Grenzen
Andreas Donaubauer, Matthäus Schilcher,
Anette Huber, TU München
Andreas Donaubauer, Dr.-Ing. /
Matthäus Schilcher, Univ.-Prof. Dr.-Ing. /
Anette Huber
Technische Universität München
Fachgebiet Geoinformationssysteme
Arcisstraße 21
D-80290 München
Tel :
Fax :
E-Mail :
+49 89 289 22973
+49 89 289 22878
Vorwort
Der Beitrag gibt einen Überblick über den Stand der Technik zur Nutzung verteilter
Geodaten auf der Basis der Standards des Open Geospatial Consortium (OGC).
Anhand von Praxistests werden die Möglichkeiten und Grenzen von OGC-Standards
diskutiert. Im Ausblick wird ein neues Forschungsprojekt zwischen ETH Zürich und TU
München zum Aufbau einer grenzüberschreitenden Geodateninfrastruktur (GDI) vorgestellt, bei dem Synergien der beiden Lösungsansätze „modellbasierter Datentransfer“
und „OGC Web Services“ untersucht werden sollen.
1 Einführung und Begriffsbestimmung
Seit nun gut 20 Jahren werden an verschiedensten Stellen in Verwaltung und Wirtschaft
digitale Geodaten produziert. Dabei entstand im Laufe der Zeit eine große Anzahl an
verteilten Geodatenbeständen, deren effiziente und nachhaltige Nutzung über organisatorische Grenzen hinweg jedoch meist durch die derzeit existierenden heterogenen GISLandschaften behindert wird. Die Probleme liegen vor allem in der Heterogenität der
verschiedenen Systeme – deren proprietären Schnittstellen und Datenformaten – aber
auch in der Verwendung verschiedener Datenmodelle sowohl auf konzeptioneller, logischer und physikalischer Ebene begründet.
Zur Überwindung der derzeit bestehenden Probleme bei der kombinierten Nutzung
verteilter, heterogener Geodaten werden in Wirtschaft und Forschung momentan zwei
Lösungsansätze intensiv diskutiert und verfolgt, die auf internationalen Standards und
Normen basieren. Zum einen der modellbasierte Datentransfer zur Überwindung der
Heterogenität der Daten und deren zugrunde liegenden Modellen, wie er in der GeoNormenserie ISO19100 konzipiert ist und mit INTERLIS, einer Schweizer Norm ermöglicht wird, zum anderen die Verwendung von Geo Web Services des Open Geospatial
Consortiums OGC zur Herstellung von Interoperabilität zwischen verschiedenen GISystemen in Bezug auf deren proprietäre Zugriffsschnittstellen und Datenformate.
Dieser Beitrag beschreibt die Möglichkeiten und Grenzen des auf Interoperabilität
mittels OGC Web Services1 basierenden Lösungsansatzes und gibt einen Ausblick
auf eine zukünftige Kombination der beiden Lösungsansätze „Interoperabilität mittels OGC Web Services“ und „modellbasierter Datentransfer“ – im Folgenden mit
„Kombinierter Ansatz“ bezeichnet.
Tabelle 1 gibt einen Überblick über Methoden zur kombinierten Nutzung verteilter
Geodaten und erlaubt eine Einordnung der genannten Lösungsansätze.
Dieser Beitrag beschränkt sich auf das Web als Plattform für die Interoperabilität von GI-Systemen.
Das OGC erarbeitet neben den Spezifikationen auf Basis der Web-Technologie (OGC Web Services)
auch Standards für weitere Plattformen (z.B. SQL, CORBA, JAVA). Diese werden hier nicht betrachtet.
1
6.1
Beispiele für
Standards und
Normen
Datentransfer auf Dateiebene grafik-orientiert
„Datenintegration“
Interoperabilität (Internet als
Kommunikationsplattform
zw ischen den
Softwarekomponenten)
objektstrukturiert
modellbasiert
grafik-orientiert
objektstrukturiert
„W eb Services“
modellbasiert
„kombinierter Ansatz“
Beispiele für
herstellerspezifische /
proprietäre Formate /
Zugriffsschnittstellen
TIFF (ISO 12639), DBR
(SICAD)
DXF
SVG (W 3C)
(CAD)
G DF (ISO 14825)
Shape (ESRI), SQ D
INTERLIS
?
OGC W M S
W eb-ZugriffsSchnittstelle von
Autodesk MapGuide
OGC W FS
Zugriffsschnittstelle
eines
ESRI ArcIMS
Feature Service
OGC+INTERLIS
(noch nicht
verfügbar)
OGC W eb Services
Tab. 1 : Methoden zur kombinierten Nutzung verteilter Geodaten
Im Folgenden werden einige grundlegende Begriffe für den Lösungsansatz „Interoperabilität mittels OGC Web Services definiert.
Verteilte (Geo-)Daten: (Geo-)Daten, die physikalisch oder logisch getrennt von einander vorgehalten werden.
Interoperabilität: Fähigkeit zur Zusammenarbeit unabhängiger Systeme durch Anbieten bzw. Inanspruchnahme von Daten und Funktionalität über Softwareschnittstellen.
Dienst / Service: Abgeschlossene Funktionalität, die von einer Softwarekomponente
über eine Softwareschnittstelle angeboten wird. Komplexität und interne Strukturen der
Softwarekomponente bleiben vor dem Nutzer eines Dienstes verborgen.
Verkettung von Diensten / Service Chaining: Sequentieller oder paralleler Aufruf von
Diensten, so dass die Antwort eines Dienstes als Eingabe für den Aufruf eines weiteren
Dienstes in der Kette verwendet wird. Die Verkettung von Diensten ist grundlegend für
die Erstellung von Dienstebündeln.
Dienstebündel / Aggregate Service: Kombination einzelner Dienste zu einem höherwertigen Dienst. Ein Dienstebündel muss erstellt werden, wenn die Funktionalität oder
das Datenangebot eines einzelnen Dienstes nicht ausreicht, um die Fragestellung eines
Anwenders zu beantworten. Kern jedes Dienstebündels ist ein so genannter Aggregate
Service, der die Benutzereingaben entgegennimmt, für die Verkettung der Dienste verantwortlich ist und das Endergebnis an den Benutzer ausliefert. Ein Aggregate Service
tritt somit als Client für mehrere Dienste auf.
Web Service: Funktionalität, die von einer Softwarekomponente über eine WebSchnittstelle angeboten wird. Über die Web Schnittstelle können auch die Fähigkeiten
und weitere Informationen über den Web Service angefragt werden
Geo Web Service: Web Service mit der Funktionalität zur Nutzung von Geodaten
OGC Web Service: Geo Web Service mit einer vom Open Geospatial Consortium OGC
spezifizierten Schnittstelle.
6.2
2 Möglichkeiten von OGC Web Services
Die Anwendung „Leitungsauskunft aus verteilten GIS“, ist in einem praxisorientierten
Forschungsprojekt der Technischen Universität München und des Vereins Runder Tisch
GIS e.V. entstanden. Sie soll im Folgenden beispielhaft die Möglichkeiten und Vorteile
der einfachen Nutzung verteilter Geodaten mittels OGC Web Services aufzeigen.
2.1 Erfahrungen der TU München und des Vereins Runder Tisch GIS
e.V.
Das Fachgebiet Geoinformationssysteme der TU München und der Verein Runder Tisch
GIS e.V. konnten seit dem Jahr 2000 in mehreren Forschungsprojekten umfangreiche
Erfahrungen mit der Entwicklung, Nutzung und herstellerübergreifenden Kombination
von OGC Web Services sammeln.
2.1.1
Forschungsschwerpunkte
Schwerpunkte der Forschungsarbeiten der TU München und des Vereins Runder Tisch
GIS e.V. im Bereich der Nutzung verteilter Geodaten sind:
x
x
x
x
x
x
2.1.2
Einfacherer Zugang und effizientere Nutzung vorhandener Geodaten,
Nutzung verteilter Geodaten für eine neues Nutzerprofil (GIS-Laien),
Verkettung von Geo Web Services,
Möglichkeiten und Grenzen der Nutzung von OGC Web Services,
Herstellerübergreifende Interoperabilität auf Basis der Standards des OGC
Wirtschaftlichkeit und Geschäftsmodelle für die Nutzung verteilter Geodaten.
OGC Testplattform des Vereins Runder Tisch GIS e.V.
Im Rahmen der OGC-Testplattform, einer Testumgebung, in der Produkte aller führenden GIS-Hersteller sowie Open Source Software betrieben werden (siehe Abb. 1), wird
vom Runden Tisch GIS e.V. GIS-herstellerübergreifend die Umsetzung von OGC Spezifikationen untersucht. Wesentliche Ziele sind es, zu zeigen:
x
x
x
x
dass GIS unterschiedlicher Hersteller auf Basis der OGC Standards in gemeinsamen Anwendungen zusammenwirken können,
dass durch den Zugriff auf verteilte Daten von Behörden und aus der Wirtschaft
mittels OGC Web Services ein Nutzen für den Anwender generiert werden kann,
dass Praxis-Anwendungen auf der Basis des Zugriffs auf existierende, verteilte
Geodatenbestände mittels OGC Web Services entwickelt werden können,
dass der Ansatz im deutschen Umfeld und länderübergreifend erfolgreich eingesetzt werden kann.
6.3
Hersteller (Produkte)
•
•
•
•
•
•
•
•
•
AED-SICAD
(Internet Suite 6.0)
Autodesk
(MapGuide 6.5)
C-Plan
(TB Internet)
ESRI
(ESRI ArcIMS 9.0 SP1
mit WMS- und WFSConnector)
GE Energy (Smallworld
SIAS 2.1)
Intergraph (GeoMedia
WebMap 5.1b mit WMS
und WFS Adapter)
M.O.S.S.
(WEGA-MARS 4.2)
Terradata
University of
Minnesota (UMN Map
Server 4.3)
Anwendungsbeispiele
OGC-Spezifikationen
•
WMS (Web Map Service)
•
WFS (Web Feature Service)
•
WCTS (Web Coordinate
Transformation Service)
•
Aggregate Services:
implementieren mehrere
Spezifikationen als Client
•
Herstellerübergreifender
Interoperabilitätstest WMS
•
Immobilienbewertung
(länderübergreifend)
•
Leitungsauskunft aus
verteilten GIS
Universitäten
Testgebiete
(Datenanbieter)
•
•
•
Baden-Württemberg,
Stadt Horb am Neckar
Bayern:
Landkreis Fürstenfeldbruck,
Stadt Bad Wörishofen, Stadt
München, Stadt Nürnberg
Brandenburg:
Landkreis Barnim
•
Technische Universität
München
•
Universität der Bundeswehr
München
GIS-Dienstleistungsunternehmen
•
Geo-IT
•
RIWA
Abb. 1 : OGC-Testplattform des Vereins Runder Tisch GIS e.V. (Stand Januar 2005)
Weitere Merkmale der OGC-Testplattform sind:
x
x
x
x
x
x
x
herstellerneutral,
hersteller- und branchenübergreifend,
grenzüberschreitend,
Aufbau durch Zusammenarbeit zwischen Datenlieferanten, Systemherstellern,
Universitäten und GIS-Dienstleistungsunternehmen
Forschung anhand konkreter und praktisch verwertbarer Anwendungen,
Beitrag zum Aufbau von Geodateninfrastrukturen (GDI),
führend im Bereich der herstellerübergreifenden Nutzung von OGC Web Feature
Services und im Bereich der Verkettung von OGC Web Services (Service Chaining).
Auf der Fachmesse INTERGEO 2003 konnten mit dem hersteller- wie länderübergreifenden Anwendungsbeispiel „Immobilienbewertung“ demonstriert werden, dass die
OGC-Web-Map-Service-Spezifikation (WMS) eine tragfähige Basis für interoperable
Web-GIS-Auskunftslösungen ist. Im Vergleich zu früheren InteroperabilitätsUntersuchungen des Runden Tisch GIS e.V. konnte zudem gezeigt werden, dass die GISysteme der führenden Hersteller mittlerweile ausgereifte WMS-Schnittstellen besitzen.
Auf der INTERGEO 2004 wurde das Anwendungsbeispiel „Leitungsauskunft aus verteilten GIS“ präsentiert, das erstmals einen herstellerübergreifenden Interoperabilitätsnachweis auf Basis der Web Feature Service Spezifikation (WFS) lieferte.
2.2 Anwendungsbeispiel „Leitungsauskunft aus vereilten GIS“
2.2.1
Ausgangssituation
Betreiber von Leitungsnetzen (Energieversorgungs- und Telekommunikationsunternehmen, Kommunen etc.) sind gesetzlich dazu verpflichtet, Dritten Auskunft darüber
zu geben, ob ihre Leitungen von einer geplanten Baumaßnahme betroffen sind. Bei einem Energieversorger gehen je nach Größe des Unternehmens mehrere tausend solcher
6.4
Anfragen pro Jahr ein. Jährlich entstehen durch die Beeinträchtigungen Dritter große
Schadenssummen an den Leitungsnetzen. Daher ist es im Interesse jedes Leitungsbetreibers, der Auskunftspflicht genüge zu tun [KOPPERSCHMIDT 2004]. Aufgrund
der Vielzahl an Trassen und Sparten sowie der großen Anzahl potenzieller Anwender
birgt die Dienstleistung einer sparten- und unternehmensübergreifenden Leitungsauskunft ein großes Potenzial (siehe Abb. 2).
Kundenpotenzial
Leitungsbetreiber
GIS A
Gasversorger
GIS B
Stromversorger
. . .C
GIS
Telekom
Leitungsbetreiber
...
Fernwärmeerzeuger
...
...
Wasserversorger
...
Kanalbetreiber
...
...
Bürger
Kommunen
GIS
Dienstleister
Tiefbauämter
Amtliche Geobasisdaten
- Geocodierte Adressen
- ALK, DFK, Orthophotos
Grafik modifiziert nach: micus management consulting GmbH
Abb. 2 : Leitungsauskunft aus verteilten GIS als Dienstleistung
Um eine derartige Lösung anbieten zu können, muss ein GIS-Dienstleister Zugriff auf
die Geodaten der Leitungsbetreiber sowie auf amtliche Geobasisdaten haben.
Zwei Hindernisse stellen sich dem GIS-Dienstleister als potenziellem Betreiber einer
derartigen unternehmensübergreifenden Lösung entgegen: Zum einen ist dies die Heterogenität und Verteiltheit der Geodatenbestände der Leitungsbetreiber, zum anderen
sind letztere selten dazu bereit, ihre Geodaten an Dritte abzugeben.
2.2.2
Lösungsansätze
Aus Sicht eines GIS-Dienstleisters gibt es prinzipiell zwei technische Lösungsansätze
um die Verteiltheit und Heterogenität der Geodatenbestände der Leitungsbetreiber zu
überwinden:
x
x
Lösungsansatz A: Datenintegration (Aufbau eines GIS beim Dienstleister, das
Kopien der Daten aller Leitungsbetreiber sowie amtlicher Geobasisdaten enthält),
Lösungsansatz B: Stellen von Anfragen an verteilte GIS mittels OGC Web Services (Daten bleiben bei den Leitungsbetreibern, diese geben lediglich Auskunft
über Web Services Schnittstellen nach den Spezifikationen des Open Geospatial
Consortium OGC).
Im Fall einer unternehmensübergreifenden Leitungsauskunft erweist sich der Lösungsansatz A jedoch aus folgenden Gründen als problematisch:
x
x
Leitungsbetreiber müssen ihre vollständigen Leitungsdaten an den Dienstleister
abgeben.
Wegen der Heterogenität der Daten und Systeme der Leitungsbetreiber ist eine
Datenintegration teuer und zeitaufwändig.
6.5
x
Der Dienstleister ist für die Aktualität des integrierten Datenbestands verantwortlich, was einerseits auf Seiten des Dienstleisters weitere Kosten verursacht
und andererseits auch zu Haftungsproblemen bei Fehlinformationen aufgrund
veralterter Daten führen kann.
Aufgrund dieser Überlegungen beschloss der Verein Runder Tisch GIS im Jahr 2004 auf
Basis seiner OGC Testplattform eine Lösung nach dem Lösungsansatz B, dem Zugriff
auf verteilte GIS mittels OGC Web Services zu entwickeln. Mit diesem Projekt wurden
u.a. folgende Ziele verfolgt:
x
x
2.2.3
Hersteller- und länderübergreifende Nutzung von Auskunftsfunktionalität auf
Basis der OGC Web Feature Service Spezifikation
Aufzeigen des Potenzials von Geo Web Services mit standardisierten Schnittstellen am Beispiel einer innovativen Auskunftslösung.
Einsatz von OGC Web Services für die Leitungsauskunft aus verteilten GIS
Abbildung 3 zeigt die Systemarchitektur und insbesondere den Einsatz der OGC
Schnittstellen Web Map Service (WMS) und Web Feature Service (WFS).
Browser
Aggregate
Service
OGC Web
Map Service
OGC Web
Amtliche Geobasisdaten
Feature Service
- Geocodierte Adressen
WFS Bridge
- ALK, DFK, Orthophotos
GIS A
Gas
GIS B
Strom
. GIS
.. C
Wasser
GIS D
Abwasser
GIS E Beleuchtung
Internet-Verbindung
Abb. 3 : Systemarchitektur
Während die OGC Web Services den lesenden Zugriff auf die verteilten und über das
Internet vernetzten Systeme der Leitungsbetreiber und der Anbieter amtlicher Geobasisdaten dienen, erfüllt der anwendungsspezifische so genannte Aggregate Service folgende Aufgaben:
x
x
x
x
x
x
x
Benutzereingaben entgegennehmen und in Anfragen an OGC Web Services
(OWS) umformen,
Ergebnisse eines OGC Web Service in Anfragen an einen anderen OWS umformen,
Ergebnisse mehrerer OWS kombinieren,
abhängig vom Ergebnis eines OWS den Workflow regelbasiert verzweigen,
auf den Ausfall und auf Fehlermeldungen von OWS sowie auf Inkonsistenzen in
den Ergebnissen der beteiligten OWS reagieren,
dem Anwender Zwischenergebnisse bzw. ein Endergebnis präsentieren,
Verbergen der Komplexität des verteilten Systems vor dem Anwender.
Die folgenden Abbildungen geben den Ablauf einer Anfrage an das System „Leitungsauskunft aus verteilten GIS“ wieder.
6.6
Abb. 4 : Adresseingabe
Der Anwender erhält eine Eingabemaske für die Adresseingabe vom Aggregate Service
und gibt Strasse, Hausnummer, Postleitzahl, Ort der Schadensstelle bzw. der geplanten
Baumaßnahme ein.
Abb. 5 : Geokodierung
Die vom Anwender ausgewählte Adresse wird vom Aggregate Service an einen so genannten Geocoding Service (hier ein Web Feature Service, der den Zugriff auf geocodierte Adressdaten erlaubt) gesendet. Der Geocoding Service wandelt die Adresse in
Koordinaten um.
Abb. 6 : Laden der Liegenschaftskarte
6.7
Für den geographischen Ausschnitt der Adresse wird durch einen WMS-Client ein entsprechender Ausschnitt aus der amtlichen Liegenschaftskarte geladen.
Abb. 7 : Schadensstelle durch Polygon abgrenzen
Der Anwender markiert die Schadensstelle bzw. den Ort einer geplanten Baumaßnahme
durch Einzeichnen eines Polygons auf der Liegenschaftskarte
Abb. 8 : Leitungsanfrage an einzelne Leitungsbetreiber
Das Polygon wird vom Aggregate Service des GIS-Dienstleisters an die einzelnen Systeme (WFS-Bridges) der Leitungsbetreiber übermittelt. Die WFS-Bridges formulieren die
Anfragen an die Web Feature Services der Leitungsbetreiber (Operation „GetFeature“,
geometrischer Filter „Intersects“ mit Polygon als Argument des Filters), wandeln die
Antworten der WFS (GML-Dokumente) in Antworten der Form „Leitungsnetz betroffen“/“Leitungsnetz nicht betroffen“ um und senden diese an den Aggregate Service des
GIS-Dienstleisters zurück.
Der Aggregate Service des GIS-Dienstleisters fasst die einzelnen Ergebnisse der Anfragen an die Systeme der Leitungsbetreiber zusammen und sendet das Gesamtergebnis in
Form einer HTML-Seite an den Anwender zurück.
2.3 Zusammenfassung
Das vorgestellte Anwendungsbeispiel „Leitungsauskunft aus verteilten GIS“ zeigt deutlich das Prinzip, die Vorteile und die technische Machbarkeit von Lösungen auf der Basis von OGC Web Services zur losen Verknüpfung verteilter Systemkomponenten.
6.8
Das Prinzip:
x
x
x
Verteilte Datenhaltung: Die Daten bleiben verteilt auf die Systeme, mit denen sie
erfasst und gepflegt werden.
Dienstorientierte Architektur: Die Zusammenarbeit der Systeme funktioniert über den Aufruf entfernter Operationen, also über das Stellen von Anfragen. Vorrangiges Ziel der Anfragen ist es nicht, Geodaten zum Anwender zu transferieren,
damit dieser sie analysieren und weiterverarbeiten kann. Vielmehr soll der Anwender eine Antwort auf seine raumbezogene Fragestellung erhalten (z.B. „Liegt
das Flurstück X in einem Wasserschutzgebiet?“)
Standardisierte Dienstschnittstellen: Sowohl die Anfragen als auch die Ergebnisse der Anfragen sind standardisiert. Dank der standardisierten Zugriffsschnittstellen sind die Anfragen an Systeme unterschiedlicher GIS-Hersteller identisch aufgebaut. Möglicherweise komplexe interne Strukturen der Systeme sowie das konzeptionelle Datenmodell bleiben vor dem Anwender dank der relativ einfach aufgebauten Dienstschnittstellen verborgen.
Die Vorteile:
x
x
x
x
Einfache Clients: Beim Endanwender müssen weder Geodaten noch GISFunktionalität vorgehalten werden. Die Einstiegshürde zur Nutzung der GISTechnologie ist gering. Neue Nutzergruppen für vorhandene GeoinformationsRessourcen können so erschlossen werden.
Geringer Aufwand für Betreiber von Auskunftslösungen: Der Betreiber einer
Auskunftslösung spart Zeit und Kosten durch den Entfall der Arbeitsschritte Datenbeschaffung, Datentransfer, Formatkonvertierung, Datenaufbereitung und Datenpflege.
Datenaktualität: Der Web-Zugriff auf Geodaten des originären Datenanbieters hat
eine Qualitätssteigerung durch die Nutzung aktueller Daten zur Folge.
Wiederverwendbarkeit von Komponenten: Einmal im Web veröffentlichte Geo
Web Services sind mehrfach verwendbar. Durch die vielfältigen Kombinationsmöglichkeiten von Geo Web Services können einmal eingerichtete Geo Web Services in einer Vielzahl an Lösungen verwendet werden.
3 Grenzen von OGC Web Services
Die aktuellen Grenzen der Interoperabilität mittels OGC Web Services zur kombinierten
Nutzung verteilter Geodaten werden im Folgenden dargestellt.
3.1 Grenzen in der Praktikabilität
Bei der Lösung raumbezogener Fragestellungen aus der Praxis mittels verteilten Geodaten und OGC Web Services zeigten sich folgende, heute noch bestehende Mängel in der
Praktikabilität des Lösungsansatzes:
x
Aufwand bei der Kombination von OGC Web Services unterschiedlicher Typen: Sollen OGC Web Services unterschiedlicher Service-Typen (z.B. Gazetteer
Service und Map Service) in einer Service Kette miteinander verknüpft werden, so
kommt es auf die Konsistenz der OGC Standards untereinander an. Hier sind
noch einige Inkonsistenzen festzustellen, die bei der Kombination von OGC Web
Services unterschiedlicher Typen zu einem Mehraufwand aufgrund syntaktischer
Umformung bedeuten. Im oben beschriebenen Anwendungsbeispiel „Leitungs-
6.9
x
x
x
auskunft aus verteilten GIS“ werden diese Inkonsistenzen durch Programmieraufwand beim Aggregate Service kompensiert.
Betrachtet man die Konsistenz zwischen den Standards für Web Services der Informatik und der Geoinformatik, so stellt man fest, dass die momentan gültigen
Versionen der OGC Spezifikationen insbesondere den für Web Services gängigen
SOAP-Standard noch nicht unterstützen, was eine Integration der OGC Web Services in die allgemeine IT-Landschaft behindern könnte.
Übertragungsrate im Internet: Die Ergebnisse von Anfragen an OGC Web Services können ein großes Datenvolumen haben (z.B. hochaufgelöste Rasterbilder bei
WMS, GML-Daten bei WFS), so dass bei den heute möglichen Übertragungsraten
die verteilte Datenhaltung und verteilte Verarbeitung nicht immer praktikabel ist.
Grenzen der Verteiltheit und Modularität: Untersuchungen der TU München
[Donaubauer 2004a] haben gezeigt, dass zur Lösung einer raumbezogenen Fragestellung auf Basis verteilter Datenhaltung und OGC Web Services im Vergleich
mit dem Zugriff auf einen integrierten Datenbestand unter Umständen ein Vielfaches an Anfragen gestellt werden müssen.
3.2 Grenzen in der Akzeptanz
Die Akzeptanz des Lösungsansatzes in der Praxis, bei GIS-Herstellern wie bei den (potenziellen) Betreibern von OGC Web Services (z.B. Datenanbieter und Dienstleister) ist
grundlegend dafür, dass ein Nutzen für Anwender entsteht. Erst wenn viele Hersteller
ausgereifte OGC-Schnittstellen für ihre Systeme sowohl auf Server- als auch auf ClientSeite anbieten und erst wenn die Großkunden der GIS-Hersteller, z.B. die großen Datenproduzenten, diese Schnittstellen nachfragen und einsetzen, wird es interessant und
wirtschaftlich sinnvoll, den Lösungsansatz für Praxisanwendungen einzusetzen.
Ein Teil der Spezifikationen für OGC Web Services findet heute bereits eine breite Unterstützung in den Produkten der GIS-Hersteller. Herstellerübergreifende Interoperabilität wurde insbesondere für die am häufigsten implementierte, grafikorientierte Spezifikation WMS mehrfach getestet (vgl. z.B. KUNKEL/TEEGE 2003). Die Praxistauglichkeit WMS-basierter Lösungen konnte nachgewiesen werden (vgl. SCHILCHER et al.
2004 und WILLKOMM 2004). Die oben beschriebene OGC Testplattform des Runder
Tisch GIS e.V. zeigt, dass zwar auch die WFS-Spezifikation heute bereits von vielen
GIS-Herstellern unterstützt wird, jedoch nur sehr selten vollständig.
Die Umsetzung der OGC Spezifikationen beschränkt sich heute meist auf Auskunft
aus vorhandenen Geodatenbanken, also auf den lesenden Zugriff. Die Möglichkeit
des schreibenden Zugriffs, die ein Transactional WFS bietet, wurde nur in sehr wenigen
Fällen umgesetzt. Gründe hierfür sind einerseits in der Komplexität der Umsetzung eines standardisierten Schreibzugriffs (Transaktionsmanagement, Abbruch der Verbindung im Internet usw.) zu suchen, andererseits aber auch in der mangelnden Nachfrage
dieser Funktionalität seitens der potenziellen Betreiber von OGC Web Services.
Generell gibt es immer noch große Bedenken seitens der Datenanbieter als potenziellen
Betreibern von OGC Web Services, einen Zugriff auf ihre Systeme über das Internet zuzulassen. Dies könnte auch daran liegen, dass die OGC Spezifikation in den Bereichen
Sicherheit und Zugriffskontrolle (Digital Rights Management) noch Lücken aufweisen. Auch ein Standard für einen Web Service zur Abrechnung von Leistungen befindet
sich noch in der Entwurfsphase.
6.10
3.3 Grenzen in der Funktionalität
Auch wenn die Realisierung von Auskunftslösungen auf Basis von OGC Web Services heute kein Problem mehr darstellt, so decken die heute verfügbaren OGC Spezifikationen doch noch nicht alle wichtigen Analysemethoden für Geodatenbanken ab. So
fehlen metrische Anfragen (Fläche, Umfang etc. der geometrischen Eigenschaften von
Geoobjekten) sowie Analysemethoden, bei denen aus vorhandenen Mengen von
Geoobjekten neue Geoobjekte gebildet werden (z.B. analytische Flächenverschneidung2). Die vom OGC spezifizierte Sprache „Filter Encoding“ für die Selektion von
Geoobjekten ist in Ihrer Ausdrucksmächtigkeit verglichen beispielsweise mit SQL beschränkt.
Prinzip des Lösungsansatzes „Interoperabilität mittels OGC Web Services“ ist es, komplexe interne Strukturen von Systemen vor dem Anwender zu verbergen, indem ein
Zugriff auf die Systeme mittels der relativ einfach gehaltenen standardisierten Zugriffsschnittstellen ermöglicht wird (vgl. 2.3). Dies ist einerseits ein Vorteil, da der Zugriff auf
Geodaten vereinfacht wird. Andererseits verbergen OGC Web Services so auch das
konzeptionelle Modell, das hinter den Geodaten steckt, obwohl diese Informationen
in bestimmten Fällen nötig wäre, um Daten weiterverarbeiten zu können, die von einem
OGC Web Service geliefert werden. So muss zum Beispiel für komplexere Analysen die
Struktur der einzelnen Geoobjekte und deren Beziehungen untereinander ebenso bekannt sein, wie die Semantik der Daten – Informationen, die aus einer eindeutigen Beschreibung des konzeptionellen Modells abgeleitet werden könnten.
4 Fazit und Ausblick
Als Folge der aktuellen Möglichkeiten und Grenzen von OGC Web Services ergeben
sich folgende bevorzugte Einsatzbereiche:
x
x
x
x
OGC Web Services eignen sich für das Erstellen von Auskunftslösungen im stationären und mobilen Internet,
OGC Web Services sind immer dann zu bevorzugen, wenn Geodatenhaltung und
GIS-Kenntnisse beim Anwender nicht vorhanden sind,
Hohe Anforderungen an Datenaktualität gestellt werden,
Ad hoc Datenkombination, d.h. schnelle Zusammenführung von Informationen
aus unterschiedlichen Quellen, beispielsweise im Krisen- oder Katastrophenfall
benötigt wird.
Die beiden eingangs erwähnten Lösungsansatze zur Nutzung verteilter, heterogener
Geodaten, OGC Web Services und Modellbasierter Datentransfer, sind Forschungsschwerpunkte in der Geoinformatik an der TU München (Interoperabilität mittels OGC
Web Services) und an der ETH Zürich (Modellbasierter Datentransfer). Beide Hochschulen betreuen aktuell in Kooperation mit dem Bundesamt für Landestopographie,
Swisstopo und dem Landesvermessungsamt Baden – Württemberg ein Projekt zum
Thema: Aufbau eines grenzüberschreitenden GIS in der Bodenseeregion BadenWürttemberg – Schweiz auf der Basis internationaler Standards. Anhand des Anwendungsbeispiel grenzüberschreitende Regionalplanung wird deutlich, wie groß der Bedarf an der einfachen und schnellen Nutzung der Daten auch ‚jenseits der Grenze’ ist.
2
Die TU München hat einen „Web Spatial Analysis Service“ genannten Dienst in den Standardisierungsprozess des OGC eingebracht, der dazu beitragen soll, diese Lücke zu schließen (vgl.
DONAUBAUER 2004a).
6.11
Die beiden oben genannten Lösungsansätze sollen dabei auf Vorteile und Grenzen hin
untersucht werden. Darüber hinaus soll geklärt werden, wie eine Kombination der beiden Ansätze funktionieren könnte. Durch eine Verknüpfung dieser beiden Technologien würde eine, in dieser Ausprägung wohl erstmalige, neue Art von Web Service
entstehen, der die vorhandenen Einschränkungen bisheriger OGC Web Services in
Bezug auf modellbasierten Datentransfer aufheben würde. Auf Seiten von INTERLIS
läge der Mehrwert eines solchen Konzeptes in der Integration der OGC Web Service
Technologie.
Der Nutzen den man sich von einer Kombination der beiden Ansätze verspricht, ist
zum einen eine umfassende Erweiterung an Funktionalitäten, die effizientere Arbeitsabläufe ermöglichen, zum anderen lassen sich (intelligente, erweiterte) Web Services gut in
Portallösungen integrieren. Portallösungen wiederum bieten den Vorteil, dass damit
leichter nach geeigneten Web Services gesucht werden kann und diese einfacher zugänglich gemacht werden. Die angedachte Kombination verspricht darüber hinaus einen relevanten Beitrag zu regionalen, nationalen und internationalen Geodateninfrastrukturen zu leisten. Die Nachfrage nach Geodaten kann somit schnell und auf einfache
Weise bedient werden, neue Nutzergruppen für vorhandene Geodaten können so gewonnen werden.
5 Literatur
x
x
x
x
x
x
x
x
x
x
6.12
Annen, A.: Geostandards: OpenGeospatial Consortium OGC (GML, WFS, WMS). Vortrag im Rahmen von Interoperabilität für die breite Nutzung von Geoinformation,
Zürich, 2005.
Donaubauer, A.: Interoperable Nutzung verteilter Geodatenbanken mittels standardisierter Geo Web Services, Dissertation an der TU München, 2004, Internet:
http://tumb1.biblio.tu-muenchen.de/publ/diss/bv/2004/donaubauer.html
Donaubauer, A.; Fischer, F.; Huber, A.; Müller, S.; Plabst, S.; Straub, F.: Leitungsauskunft aus verteilten GIS. Projektbericht des Runder Tisch GIS e.V., München,
2004. Internet: http://www.rundertischgis.de
Gnägi, H. R.; Plabst, S.: Modellbasierter Datenaustausch und Geo Web Services im Internet. In: Schilcher, M. (Hrsg.). Tagungsband zum 9. Münchner Fortbildungsseminar Geoinformationssysteme, München, 2004.
Kopperschmidt, W.: Unternehmensprozesse optimieren durch Web-Services am Beispiel
digitaler Planauskunft. In: Schilcher, M. (Hrsg.). Tagungsband zum 9. Münchner
Fortbildungsseminar Geoinformationssysteme, München, 2004.
Kunkel, T.; Teege, G.; Seuß, R.: Projektbericht zu den Stufen IA und IB des Projektes
„Interoperabilität auf der Basis von OpenGIS Web Services – Länderübergreifende Datennutzung bei verteilten Geodatenbanken und unterschiedlichen Herstellersystemen für das
Anwendungsbeispiel Real Estate“. Runder Tisch GIS e.V., München, 2003.
Shi, W.: Zum modellbasierten Austausch von Geodaten auf Basis XML. Dissertation an
der Universität der Bundeswehr München, München, 2004
Schilcher, M. et al.: OGC Web Services zur interoperablen Nutzung verteilter Geodatenbanken für die Immobilienwirtschaft. In: Bernard, L., Fitzke, J. und R. Wagner (Hrsg.):
Geodateninfrastrukturen. Grundlagen und Anwendungen. Heidelberg, 2004.
Schilcher, M.; Aumann, G. et al.: Abschlussbericht Forschungsprojekt GeoPortal. München, 2004.
Willkomm, Ph: Interoperabilität auf der Basis von OpenGIS Web-Services Bericht aus
Forschung und Praxis. In: Schilcher, M. (Hrsg.). Tagungsband zum 9. Münchner
Fortbildungsseminar Geoinformationssysteme, München, 2004.
7
ISO-Standards für den Datentransfer
Stand der Realisierungen / Werkzeuge
Claude Eisenhut, Eisenhut Informatik AG
Claude Eisenhut
Eisenhut Informatik AG
Rosenweg 14
CH-3303 Jegenstorf
Tel :
Fax :
E-Mail :
+41 31 762 06 62
+41 31 762 06 64
1 Theorie
1.1 Was für eine Interoperabilität?
Interoperabilität ist die Zusammenarbeit von Anwendungen in einem offenen System.
Unabhängig von der verwendeten Hardware, den eingesetzten Betriebssystemen, der
verwendeten Netzwerktechnologie und der Realisierung einer Anwendung kann eine
Zusammenarbeit mit anderen Anwendungen erfolgen. Dazu ist in der Regel die Einhaltung gemeinsamer Standards notwendig, aber ohne dass dazu gesonderte Absprachen
zwischen den Anwendungen notwendig sind.
In einem Integrationsprojekt gibt es normalerweise einen Auftraggeber und (innerhalb
des Projektes) eine definierte Anzahl Anwendungen die zusammenarbeiten sollen. Trifft
man innerhalb des Projektes über den Standard hinausgehende Absprachen, hat das auf
die Zusammenarbeit keine negativen Auswirkungen. Die durch die Absprache betroffenen Anwendungen sind bekannt und im Einflussbereich des Projektes.
Beim Aufbau einer Daten-Infrastruktur sind die Anwendungen, die zusammenarbeiten
sollen, nicht bekannt und/oder ändern sich laufend. Eine über den Standard hinausgehende Absprache ist darum unmöglich!
Funktionierende, „ausführbare“ Standards, die keine zusätzlichen Absprachen erfordern, sind darum für Interoperabilität, wie sie eine Daten-Infrastruktur benötigt, eine
zwingende Voraussetzung!
7.1
ISO-Standards für den Datentransfer: Stand der Realisierungen / Werkzeuge
1.2 Welche ISO-Normen?
Norm
OMG
UML
Titel
Unified Modeling
Language
ISO 19103
Conceptual schema
language
ISO 19109
Rules for
applicationschema
DIS
ISO 19107
Spatial schema
IS
ISO 19108
ISO 19111
Temporal schema
Spatial referencing by
coordinates
Spatial referencing by
geographic identifiers
Schema for coverage
geometry and functions
Metadata
Encoding
IS
IS
XML
1.0 (selten 1.1)
XML-Schema
1.0
Beschreibungssprache für XMLDateien
Geography Markup
Language
CD (GML 3.2)
Gemeinsame Spezifikation von
OGC und ISO für den
Datentransfer.
ISO 19112
ISO 19123
ISO 19115
ISO 19118
W3C
XML
W3C
XMLSchema
ISO 19136
Stand
Diverse
Versionen. 191xxx
basiert auf UML
1.3
DTS
IS
DIS
IS
DIS
Beschreibung
Kästchendiagramme
Einschränkung von UML +
Basisdatentypen wie Text, Zahl,
usw.
Metamodell
(=Modellierungssprache).
Überflüssig, da UML+19103 die
Modellierungssprache definiert!
Geometrie-Datentypen (inkl.
Topologie)
Zeit-Datentypen (inkl. Topologie)
Datenmodell für
Koordinatenreferenzsysteme
Datenmodell für geographische
Namen
Coverage-Datentypen
Datenmodell für Metadaten
Definiert, wie man
Kodierungsregeln für den
Datenaustausch definiert. Muss für
Interoperabilität zuerst konkret
definiert werden!
Flexibles Textformat
WD: Working draft ; CD: Committee draft; DIS/DTS: Draft International Standard/Draft ;
Technical Specification ; FDIS: Final Draft International Standard ; IS: International Standard
7.2
Modellierungs
sprache
(UML+19103
(19109))
Applikationsmodell in
UML (z.B. Amtl.
Vermessung)
Vordefinierte
Datentypen und
Modelle
(19107, 19108,
19111, 19112,
19115, 19123)
Kodierung
(19118)
Kodierungsregeln
(müssen definiert
werden!)
Konkretes
Transferformat
GML (19136, XML, XML-Schema)
Zusammenhang zwischen den einzelnen ISO-Standards
Anwendung der ISO-Standards ohne GML
Man modelliert mit Hilfe von UML sein Datenmodell, berücksichtigt dabei die Einschränkungen von 19103 und verwendet die durch 19103, 19107 etc. definierten Basistypen. Zusätzlich definiert man allgemeine Kodierungsregeln, z.B. wie ein Objekt und
dessen Attributwerte kodiert werden. Dann wendet man die selbst definierten Kodierungsregeln auf das eigene Datenmodell an, um so das konkrete Transferformat zu erhalten.
Ohne ISO 19136 (GML) müssen für ein konkretes Transferformat zusätzliche Absprachen gemacht werden!
Anwendung der ISO-Standards mit GML
Man modelliert mit Hilfe von UML sein Datenmodell, berücksichtigt dabei die Einschränkungen von GML (beinhaltet auch diejenigen von 19103), und verwendet die
durch GML (beinhaltet 19103, 19107, etc.) definierten Basistypen. Dann wendet man die
durch GML definierten Kodierungsregeln auf das eigene Datenmodell an, um so das
konkrete Transferformat zu erhalten. Das Resultat ist ein XML-Schema das den Regeln
von GML entspricht. Für ein konkretes Transferformat sind keine zusätzlichen Absprachen erforderlich.
7.3
1.3 Verschiedene Modellierungsansätze
Mit dem Aufkommen von GML treffen die folgenden zwei Ansichten aufeinander:
x
x
UML-Modell als Visualisierungsmittel; GML-Schema als Norm
UML-Modell als Norm; GML-Schema als Transferformat
UML-Modell als Visualisierungsmittel; GML-Schema als Norm
Gemäss diesem Ansatz, ist das GML-Schema massgebend und das UML-Modell dient
nur zur Visualisierung der Datenstruktur und evtl. zur Entwicklung des GML-Schemas.
Vorteile dieses Ansatzes:
x
Es ist keine Übersetzung des UML-Modells erforderlich, das Schema beschreibt
direkt das Transferformat. Der Software-Entwickler muss vor allem das Transferformat während der Realisierung in Gedanken präsent haben.
Nachteile:
x
x
x
Die Inhaltsstruktur lässt sich nicht von Formattricks unterscheiden.
Ein anderes Transferformat (für dieselben Daten) lässt sich nicht ohne weiteres
herleiten.
Die in 19136 (Anhang F) definierten Abbildungsregeln von GML nach UML decken nicht alle möglichen GML-Schemas ab.
UML-Modell als Norm; GML-Schema als Transferformat
Gemäss diesem Ansatz ist das UML-Modell massgebend, und das automatisch hergeleitete GML-Schema dient nur zum Datentransfer.
Vorteil dieses Ansatzes:
x
x
Es lassen sich auch andere Transferformate herleiten.
Das UML-Modell beschreibt nur die Inhaltsstruktur, Formattricks fliessen durch
die Kodierungsregeln ein.
Nachteile:
x
x
Bestimmte Möglichkeiten von GML lassen sich nicht ausnützen, da die entsprechenden Abbildungsregeln von UML nach GML in 19136 (Anhang E) fehlen.
Für das konkrete Transferformat ist eine Übersetzung des UML-Modells notwendig. Für den Anwender ist das nur ein Knopfdruck, der Software-Entwickler
muss aber das UML-Modell, das Transferformat und die Übersetzungsregeln
während der Realisierung in Gedanken präsent haben.
1.4 Beurteilungskriterien
Bei der Auswahl eines Datentransferstandards, sind die folgenden Kriterien zu berücksichtigen. Je nach Kontext wird man den einen oder anderen Faktor höher gewichten.
x
x
x
x
x
7.4
Wie sichert man die Daten gegen Verlust wegen heute noch unbekannten technischen Entwicklungen?
Wie sichert man die Daten gegen Verlust wegen Personalwechsel?
Welche Auswirkungen haben Modelländerungen?
Genügt ein einziges Transferformat oder werden für dieselben Daten verschiedene Transferformate benötigt?
Wie prüft der Nutzer, dass er erhalten hat, was er bestellt hat?
x
x
x
x
x
x
x
x
x
x
x
x
x
Wie beweist der Produzent, dass er geliefert hat, was er versprochen hat?
Wie wird die Handhabung der Daten beim Nutzer vereinfacht?
Wie wird die Handhabung der Daten beim Produzenten vereinfacht?
Wie wird die Handhabung der Daten beim Daten-Pool/Portal vereinfacht?
Wie wird das Auslagern von Dienstleistungen rund um die Daten vereinfacht?
Wie einfach ist die Software-Entwicklung?
Funktionieren diese Standards mit grossen Datenmengen?
Wie wird Mehrsprachigkeit unterstützt?
Wie werden föderale Organisationsstrukturen unterstützt?
Sind diese Standards beeinflussbar?
Welche Anwender und Datennutzer brauchen diese Standards sonst noch?
Gibt es hier genügend Spezialisten?
Wie ist die Unterstützung durch Standard-Software?
2 Praxis/SW-Demo
x
x
x
x
x
x
x
Modellieren mit diversen Werkzeugen
Formatbeschreibung
Wie sehen die Daten aus?
Datenprüfung
Konvertierungswerkzeuge
Sind die Modellierungskonzepte in den GIS vorhanden?
Werkzeuge für die Softwareentwicklung
3 Beurteilung
Die ISO-Normen sind lesbar. Es ist aber aufwendig, einerseits wegen dem Umfang der
einzelnen Normen, andererseits weil sich die relevanten Konzepte über mehrere Normen verteilen.
Mit entsprechendem Aufwand sind die ISO-Normen realisierbar. Der Aufwand ergibt
sich dadurch, dass das jeweilige Thema, z.B. geometrische Datentypen, sehr umfassend
definiert wird.
Für Interoperabilität sind die ISO-Normen nur beschränkt tauglich. Es gibt zu viele Widersprüche zwischen den einzelnen Normen und zu oft werden abstrakte Ideen definiert, die sich nicht direkt realisieren lassen. Im Bereich des Datentransfers ist die Norm
19136 (GML) ein erster nützlicher Schritt.
Verbesserungsvorschlag
Statt seit drei Jahren im Projekt 19139 ein Transferformat für Metadaten zu entwickeln,
sollte das TC211 die Kodierungsregeln von 19136 (GML) auf das Metadatenmodell
(19115) anwenden. So hätte man direkt innerhalb des TC211 eine Rückmeldung zur Realisierbarkeit.
7.5
4 Ausblick
Der Kosten/Leistungsdruck bleibt auch in Zukunft bestehen!
Innovative Unternehmen suchen darum nach neuen Einteilungen der Prozessketten.
Interoperabilität reduziert die Schnittstellenkosten und ermöglich somit neue Einteilungen.
Datentransfer ist out! Die Zukunft gehört den (Web-)Diensten!
(Web-)Dienste sind nicht für menschliche Benutzer gedacht sondern für Anwendungen,
die automatisiert Daten austauschen und/oder Funktionen auf entfernten Rechnern
aufrufen.
Ohne funktionierenden Datentransfer geht bei Diensten aber gar nichts.
Jeder Funktionsaufruf selbst ist implizit ein Datentransfer. Der Funktionsname und die
aktuellen Funktionsargumente müssen von einem Rechner zum anderen transferiert
werden und das Resultat muss wieder zurück.
Braucht es noch INTERLIS?
Das INTERLIS-Transferformat bietet einige Möglichkeiten (inkrementellen Transfer,
mehrsprachige Tags), die GML nicht bietet. Benötigt man diese nicht, kann man ohne
weiteres GML für den Transfer einsetzen. Das Basis-Schema des INTERLISTransferformats ist jedoch wesentlich kleiner, und darum einfacher zu realisieren.
Die Möglichkeiten zur automatischen Datenprüfung sind mit UML/GML (gem. 19136)
verglichen mit INTERLIS armselig. Die Datenbeschreibungsmöglichkeiten sind mit INTERLIS substanziell besser, auf INTERLIS als Beschreibungssprache zu verzichten, wäre
darum ein Rückschritt.
7.6
8
Interoperabilität von Geodaten
Aktueller Stand und Zukunftsperspektiven im
Kanton Waadt
Marc Gilgen, État de Vaud
Service de l’information sur le territoire
In Zusammenarbeit mit
Sandrine Durler, État de Vaud
Lucien Imhof, État de Vaud
Bruno Magoni, ASIT-VD
Marc Gilgen
État de Vaud
Département des infrastructures
Service de l’information sur le territoire
Av. de l’Université 3
CH-1014 Lausanne
http://www.dinf.vd.ch/sit
Tel :
Fax :
E-Mail :
+41 21 316 34 83
+41 21 316 24 84
1 Einleitung
Seit mehr als 10 Jahren hat der Kanton Waadt an der Interoperabilität im Bereich der
Geodaten gearbeitet. Die Vereinigung für das Landinformationssystem des Kantons
Waadt (ASIT-VD1), mit ihrem Auftrag einer Plattform für den Datenaustausch, hat frühzeitig eine Metadatenbank mit einem Katalogisierungsdienst (dem so genannten Géocatalogue) und einem Online-Bestelldienst aufgebaut. Gleichzeitig hat die kantonale Verwaltung, wichtiges Mitglied der ASIT-VD, die notwendigen Mittel für ein Geoinformationssystem innerhalb der kantonalen Verwaltung2 aufgebracht. Diese Infrastruktur und
Organisation haben den Datenaustausch gefördert und weiterentwickelt. Gleichzeitig
sind auch Interoperabilitäten zwischen Informatik-Applikationen entstanden.
Dank des Geoportals der ASIT-VD ist der Kanton Waadt zur Zeit der Hauptlieferant
raumbezogener Daten. Er profitiert von den Diensten der ASIT-VD im Bereich der Katalogisierung und der Bestellung und er nutzt sie häufig. Eine Voraussetzung dazu ist eine zweckmässige technische und organisatorische Infrastruktur innerhalb der kantonalen Verwaltung. Aus dem technischen Standpunkt funktioniert das Informationssystem
des Kantons hauptsächlich durch das Prinzip des Datenpools (Datawarehouse), bestehend aus den spezifischen Datenbanken der verschiedenen Abteilungen. Dieser zentrale
Datenpool ermöglicht es, viele GIS-Applikationen innerhalb des Kantons anzubieten
und Interoperabilitäten im Bereich der Geodaten zu entwickeln.
2 Aktueller Stand der Realisierungen
2.1 Interoperabilitäten im Bereich der Geodaten
Die von der kantonalen Verwaltung und von der ASIT-VD bearbeiteten Interoperabilitäten im Bereich der Geodaten können einfach aus einem URL-Link aber auch aus viel
komplexeren Realisierungen bestehen. Untenstehend kommen wir auf die folgenden
Interoperabilitäten einzeln zu sprechen :
Abfrage von Geodaten in administrativen Applikationen
x
Abfrage von geographischen Ebenen für Baubewilligungen
x
Kartendienst für Internet-Applikationen
x
Online-Bestellung von Geodaten (geographische Objekte auswählen und extrahieren)
Abfrage von administrativen Daten in GIS-Applikationen
1
2
x
Abfrage von entfernten Datenbanken
x
Zugang zu den Metadaten
x
Verbindung mit dem Geographischen Datenkatalog der Schweiz
http://www.asit.vd.ch
http://www.dinf.vd.ch/sit
8.1
Interoperabilität von Geodaten : aktueller Stand und Zukunftsperspektiven im Kanton Waadt
2.2 Abfrage von geographischen Ebenen für Baubewilligungen
Die kantonale Abteilung, die die Baubewilligungen erteilt (Baubewilligungzentrale3)
verfügt über eine Internet-Applikation, die es ermöglicht, verschiedene geographische
Ebenen in der zentralen Datenbank abzufragen. Die Baubewilligung wird unter Berücksichtigung mehrerer Kriterien erteilt. Die geometrische Dimension in Verbindung mit
der geographischen Lage des zukünftigen Baus spielt in vielen von diesen Kriterien eine
wichtige Rolle. Zudem wird die vom Bau beeinflusste Ausdehnung in der Webapplikation erfasst, um das Ausmass des zukünftigen Baus möglichst gut zu berücksichtigen.
Die räumliche Abfrage wird auf der Grundlage eines geometrischen Schnitts zwischen
dem zum Ausmass des zukünftigen Baus proportionalen Kreis und den geographischen
Ebenen durchgeführt. Die Resultate werden dann der Internet-Applikation zurückgeschickt. Diese Interoperabilität ermöglicht verschiedene Verifikationen, die ohne einen
solchen automatischen Prozess sehr mühevoll wären.
Eine der Verifikationen betrifft den Namen der Gemeinde. Dieser wird nämlich wie die
geographischen Koordinaten des Baugesuchs manuell eingegeben. Dank der räumlichen Abfrage wird geprüft, ob die geographische Lage des Baugesuches innerhalb des
Umkreises der Gemeinde liegt.
Die Mehrheit der abgefragten Ebenen werden im Datawarehouse gespeichert. Einige
sind in Dateien gespeichert. Durch diesen Mechanismus können wir die Verträglichkeit
des Baus mit verschiedenen rechtskräftigen mit der Raumplanung verbundenen Einschränkungen prüfen, insbesondere mit der Bodennutzung, dem Grundwasserschutz,
den Kantons- und Bundesinventaren, den Schutzmassnahmen für die Gebäude (für ein
schon bestehendes Gebäude). Bei einem Interessenskonflikt zwischen einem Baugesuch
und einer Zone eines Inventars beispielsweise, wird der Mechanismus die Abteilungen
erwähnen, die befragt werden müssen, um eine Baubewilligung zu erteilen. Dieser automatisierte Prozess ermöglicht einer « nicht-geographischen » Applikation einen geographischen Server abzufragen.
2.3 Interoperabilitäten des kartografischen Internet-Schalters
Dank des kartografischen Internet-Schalters des Kantons Waadt (GéoPlaNet4) können
die von der kantonalen Verwaltung hergestellten und benutzten Geodaten auf dem Internet veröffentlicht werden. Dieser Internet-Schalter profitiert auch von der Integration
der Geodaten in einem einzigen Datenpool. Es gibt ausserdem viele Schnittstellen (unioder bidirektional) mit anderen Applikationen. Zum Beispiel können wir folgende erwähnen : Schnittstellen mit dem Grundbuch5 (Grundbuchauszüge), mit der Baubewilligungszentrale6 (Visualisierung der Akten), oder auch mit der wirtschaftlichen Förderung7 (Suche nach verfügbarem Gelände).
Die wichtigsten Interoperabilitäten, die mit dem kartografischen Internet-Schalter verbunden sind, werden nachfolgend beschrieben. Diese Interoperabilitäten zeigen schon
das Prinzip, das Interesse und das Potential eines universellen Portals, das die Dienstleistungen des Kantons durch ein einziges Portal anbietet.
3
http://www.camac.vd.ch
http://www.geoplanet.vd.ch
5 http://www.rf.vd.ch
6 http://www.camac.vd.ch
7 http://www.terrains.vd.ch
4
8.2
2.3.1
Kartendienst für Internet-Applikationen
Für die administrativen Applikationen des Kantons ist die Interoperabilität hauptsächlich beim Kartendienst von Interesse. Dieser von GéoPlaNet geleistete Dienst ermöglicht
Karten in eine andere Applikation dynamisch zu integrieren (einfacher Kartendienst)
oder zur Benutzungsoberfläche des kartografischen Internet-Schalters zu kommen
(Browserkartendienst). Die Lokalisierung wird mit Hilfe von Koordinaten oder mit Hilfe eines räumlichen Objekts (z.B. eine Parzelle in einer Gemeinde) gemacht. Die Parameter der Lokalisierung, des Massstabes und des Grösse der Karte, sowohl die Auswahl
der Datenebenen werden über die URL-Adresse übermittelt. Die Applikationen des
Grundbuchs, der Baubewilligungszentrale und der Wirtschaftsförderung benutzen diese Kartendienste.
2.3.2
Abfrage von entfernten Datenbanken
Umgekehrt ermöglicht der kartografische Internet-Schalter Informationen in entfernten
Datenbanken zu finden. Zum Beispiel derjenigen des Grundbuchs: mit GéoPlaNet kann
der Name des Besitzers einer Liegenschaft angezeigt werden. Diese Information wird
bald mit anderen Informationen aus dem Grundbuchauszug ergänzt werden (Beschreibung des Grundstückes, Eigentum, Grunddienstbarkeiten, usw.). Das zeigt den Vorteil
und die Rolle des kartografischen Internetschalters, um nicht-geografische Informationen zu erwerben. Dieser Zugang zur Information durch die geografische Dimension
und durch einen einzigen Eingangspunkt ist ein grosser Gewinn für den Benutzer.
2.3.3
Zugang zu den Metadaten
Was die Metadaten betrifft, bietet der kartografische Internet-Schalter einen direkten
Zugang zum Géocatalogue der ASIT-VD8 an, in dem alle Geodaten beschrieben werden.
Es handelt sich hier darum, dass die Koppelung der Daten mit den Metadaten innerhalb
des Visualisierungsdienstes für Geodaten (GéoPlaNet) gewährleistet wird.
2.4 Online-Bestellung von Geodaten
Dank des Portals Géocommande der ASIT-VD9 können Geodaten auf dem Gebiet des
Kantons Waadt online bestellt werden. Der Benutzer kann seine Daten via Géocatalogue
auswählen und ein Suchgebiet für die Extraktion (Text- oder räumliche Suche) definieren. Zusätzlich zum Visualisierungsdienst, der benutzt wird, um die Basiskarten darzustellen, bietet die geografische Auswahl eigentlich einen Auswahldienst durch ein Objekt an. Die geografischen Objekte, die ausgewählt werden können, sind die Bezirke, die
Gemeinden, die Umkreise der Katasterpläne und die Parzellen. Der Kartenserver ist
derselbe wie derjenige des kartografischen Schalters (MapServer). Diese Auswahl durch
ein Objekt wird durch eine Datenbank PostGIS gemacht.
Sobald das Bestellungsformular ausgefüllt ist, wird es den betroffenen Lieferanten geschickt. Für die Geodaten des Kantons Waadt wird die Abfrage automatisch verarbeitet:
die Geodaten werden vom Datawarehouse aus dem ausgewählten Umkreis herausgezogen, dann zum Benutzer durch FTP übermittelt. Die Rechnung wird auch automatisch gemacht.
8
9
http://www.asit.vd.ch/geoportal/geocatalog/public.asp
http://www.asit.vd.ch/geoportal/geodata/public.asp
8.3
Die Verarbeitungskette einer Online-Bestellung besteht aus vielen Interoperabilitäten
zwischen mehreren Applikationen: um den Bestellungsumkreis zu definieren (Auswahl
von geografischen Objekten) und um die Abfrage zu übermitteln und zu verarbeiten
(Herausziehen von geografischen Objekten).
2.5 Verbindung mit dem Geographischen Datenkatalog der Schweiz
Mit dem neuen Geographischen Datenkatalog der Schweiz10 arbeitet die ASIT-VD wie
ein Partner vom Typus C (der Partner vom Typus A gibt seine Metadaten direkt in die
zentrale Datenbank von geocat ein ; der Partner vom Typus B verfügt über seine eigene
Datenbank aber kopiert seine Metadaten in die zentrale Datenbank ; der Partner vom
Typus C erlaubt einen Zugang zu seiner Datenbank durch geocat ohne Duplizierung).
Die ASIT-VD verfügt nämlich über seine eigene Metadatenbank, die geocat abfragen
kann. Zu diesem Zweck wurde ein Abfrageprotokoll (Catalog Gateway Protocol) auf
Bundesebene entwickelt und in die Applikation von der ASIT-VD eingebaut. Auf dieser
Weise kann die ASIT-VD die Abfragen von geocat bekommen und verarbeiten, und
dann eine Antwort zurückschicken, die der Struktur und dem Format von geocat entspricht. Diese Interoperabilität ist die erste konkrete Realisierung in die Richtung eines
Schweizer Suchportals für Geodaten mit einem dezentralisierten Katalog.
Die Interoperabilität zwischen geocat und dem Géocatalogue der ASIT-VD zeigt die
Notwendigkeit, über gemeinsame Datenmodelle zu verfügen. Das Metadatenmodell
GM03Core muss mindestens in jedem Metadatensystem implementiert werden. Auf der
Basis von GM03Core werden die minimalen Metadaten ausgetauscht. Die ASIT-VD hat
deswegen den Géocatalogue angepasst, um mit dem Schweizer Metadatenmodell
GM03Core in Übereinstimmung zu sein. Alle obligatorische Metadaten von GM03Core
können im Géocatalogue gefunden und dank geocat visualisiert werden.
Die technischen Entwicklungen, die die Interoperabilität fördern, müssen von Bemühungen in anderen Bereichen begleitet werden. Hier müssen die Bemühungen erwähnt
werden, um standardisierte Datenmodelle und Vorgehen für Geodatenaustausch zwischen den Partnern anzunehmen oder auszuarbeiten. Zu diesem Zweck arbeiten die
kantonale Verwaltung und die ASIT-VD zusammen. Erste Schritte im Bereich der generellen Entwässerungspläne (GEP11) sind erfolgreich gewesen. Jetzt wird etwas im Bereich der Raumplanung unternommen, um den Austausch der Daten für die Bodennutzung zu vereinheitlichen.
3 Perspektive
3.1 Webdienst über Raumgliederungen
Demnächst wird der Kanton einen Webdienst über die Raumgliederungen aufstellen.
Zuerst werden der Kanton, die Bezirke, die Gemeinden, die Katasterpläne und die Parzellen betroffen sein. Dieser Dienst gibt die Möglichkeit, Informationen über die Einheiten der vorher genannten Raumgliederungen (z.B. Bundesnummer und Name der Gemeinden) und über die Zusammensetzung und die Zugehörigkeit der Einheiten einer
Raumgliederung in Beziehung mit den anderen Raumgliederungen (z.B. Nummer aller
10
11
http://www.geocat.ch
http://www.dse.vd.ch/eaux/assainissement/eaux/pgee.htm und
http://www.asit.vd.ch/documentation/command.asp
8.4
Parzellen und aller Katasterpläne, die einer Gemeinde gehören) in einer Standardform
und im Format XML zu übermitteln.
Dieser Dienst wird vor allem beim Bestellungs- und Vertriebsvorgehen der Geodaten
benutzt. Dieser Webdienst ist unabhängig von jeder Applikation und er wird dennoch
später für andere Bereiche benutzt werden können. Die Vorteile eines solchen Dienstes
sind klar: die Aktualisierung der Datenbanken ist automatisch bei Veränderungen, wie
z.B. bei den Fusionen von Gemeinden oder bei der Einführung von neuen Vermessungslosen. Im Vergleich brauchen die traditionellen Methoden der Aktualisierung viel
Zeit, in Anbetracht der vielen Applikationen, die diese Informationen benutzen.
Mit diesem Dienst wird auch die Aktualisierung der Postleitzahlen (PLZ) und der Orte
in jeder betroffenen Applikationen vorgesehen. Die PLZ wechseln regelmässig und
werden mehrmals im Jahr aktualisiert12.
3.2 Geschützter Kartendienst
Die ASIT-VD und der Kanton entwickeln und testen jetzt einen geschützten Kartendienst, der sich auf die OpenGIS Spezifikationen13 beruht. Im ersten Schritt wird die
Spezifikation Web Map Service (WMS) implementiert, damit die Karten in Bildform geliefert werden. Der Zugang wird mit einem Benutzernamen und einem Passwort geschützt.
Es gibt zwei Hauptziele:
x
Den Datenvertrieb mit einem direkten Zugang auf Daten durch den Standard
WMS ergänzen. Die Benutzung von WMS gibt jeder Applikation, die als WMSKlient funktioniert, die Möglichkeit, Abfragen zu schicken und die zurückgeschickten Karten direkt in die Benutzungsoberfläche des Klienten zu integrieren.
Die hier betroffenen Applikationen sind besonders die GIS- und die WebApplikationen. Folglich sind die betroffenen Benutzer Fachleute der Vermessung, der Umwelt, der Raumplanung (usw.) aber auch zum Beispiel die Gemeinden. Im Bereich vom GIS bieten immer mehr Softwareprodukte – sowohl
kommerzielle Produkte (z.B. MapInfo, ArcGIS) sowie "free" Programme (z.B.
JUMP) – WMS-Klientfunktionalitäten. Die Zugangskontrolle ermöglicht es, die
Identität des Benutzers zu erkennen und auch ein Rechnungssystem für diesen
Direktzugangdienst zu definieren.
x
Einen zentralen kartografischen Schalterdienst (waadtländisches Portal) anbieten. Er wird vor allem den öffentlichen Verwaltungen angeboten unter der Bedingung, dass der Geodatenlieferant über einen Server verfügt, der WMSAbfragen beantworten und Bilder, die diesem Standard entsprechen, liefern
kann. Der einzige kartografische Schalter, der von der ASIT-VD beherbergt und
unterhalten wird, wird als WMS-Klient funktionieren und wird die Visualisierung von Geodaten von mehreren Lieferanten ermöglichen. Wir haben als Ziel,
dass die Daten der kantonalen Verwaltung und die von den Gemeinden gegebenen Daten zusammen gelegt sind.
Dieser geschützte Dienst wird zuerst die Interoperabilität nur im Bereich der Geodaten
ermöglichen. Dann wollen wir die Entwicklungen in Richtung Interoperabilität der
12
13
http://www.poste.ch/yellowbox
http://www.opengeospatial.org
8.5
Funktionalitäten orientieren. Das heisst, dass der Zugang zu Funktionalitäten der Applikation des Lieferanten durch den zentralen Schalter und auch von irgendwelchen
Klienten möglich sein wird. Es ist klar, dass die Aufstellung einer solchen Interoperabilität nur möglich ist, wenn Funktionalitäten in Form von Webdiensten entwickelt werden.
Für die kantonale Verwaltung sind diese Perspektive nicht nur technische Ziele und
Herausforderungen, sondern auch strategische. Die Aufstellung von solchen Interoperabilitäten wird nämlich den Geodatenvertrieb, ihre Tarifgestaltung, ihre Verwaltung
und ihre Aktualisierung (verteilte Kosten, gemeinsame Infrastrukturen) beeinflussen.
4 Schlussfolgerungen
Die Interoperabilität im Bereich der Geodaten spielt eine wichtige Rolle. Im Kanton
Waadt können wir nach den realisierten Entwicklungen in diesem Bereich Folgendes
bemerken:
8.6
x
Die Interoperabilität bietet technische Lösungen für organisatorische Probleme
an (z.B. den Abfragedienst der geografischen Ebenen).
x
Dank der Interoperabilität wird Zeit und Geld gewonnen durch die Rationalisierung der Aufgaben, die mit der Erwerbung, der Verwaltung, der Aktualisierung,
der Veröffentlichung und dem Vertrieb der Geodaten verbunden sind (z.B. dank
eines Online-Bestellungsdienstes der Geodaten).
x
Die Interoperabilität unterstützt die Förderung und die Benutzung der Geodaten
in Bereichen, die an Geomatik wenig oder nicht gewohnt sind (z.B. dank des
Kartendienstes, der durch einen kartografischen Schalter verfügbar ist).
x
Die Interoperabilität erhöht die Zuverlässigkeit der Daten : wir vermeiden mehrfache Kopien, die Aktualisierung wird schneller gemacht, das Speichersystem
wird nicht mehr so viel belastet und die Bemühungen für die Verwaltung der
Geodaten sind nicht mehr so gross (z.B. dank des Informationsdienstes über die
Raumgliederungen).
9
Die Komplexität der Interoperabilität
Ein einfacher Praxisbericht aus der
Ostschweiz
Ueli Forrer, F+P GEOINFO AG
Ueli Forrer
F+P GEOINFO AG
Geoinformatik und Vermessung
Kasernenstrasse 69
CH-9100 Herisau
http://www.geoinfo.ch
Tel :
Fax :
E-Mail :
+41 71 353 53 53
+41 71 353 53 50
1 Einleitung
Interoperabilität ist für uns als GIS-Dienstleistungsunternehmen ein sehr aktuelles
Thema und langfristig betrachtet, wird Interoperabilität zu einer Überlebensfrage solcher Unternehmen werden. Wenn wir uns mit Definitionen von Interoperabilität auseinander setzen, geraten wir direkt zur Frage der Systemabgrenzung. In unserem System, einer regionalen Geodateninfrastruktur, können wir zur Zeit Interoperabilität in
diversen Teilsystemen finden.
1.1 Definitionen zur Interoperabilität
Interoperabilität wird in der Literatur unterschiedlich definiert. Wir beschränken uns in
der Folge auf zwei unterschiedliche, jedoch sinngleiche Definitionen1:
1. Als Interoperabilität bezeichnet man die Fähigkeit zur Zusammenarbeit von verschiedenen Systemen, Techniken oder Organisationen. Dazu ist in der Regel
die Einhaltung gemeinsamer Standards notwendig. Wenn zwei Systeme miteinander vereinbar sind, nennt man sie auch kompatibel.
2. Interoperabilität ist die Fähigkeit unabhängiger, heterogener Systeme möglichst
nahtlos zusammen zu arbeiten, um Informationen auf effiziente und verwertbare Art und Weise auszutauschen bzw. dem Benutzer zur Verfügung zu stellen,
ohne dass dazu gesonderte Absprachen zwischen den Systemen notwendig sind.
1.2 Systemabgrenzung
Wenn aus der ersten Definition Interoperabilität als die Fähigkeit zur Zusammenarbeit
von verschiedenen Systemen, Techniken oder Organisationen bezeichnet wird, dann
lässt sich daraus logischerweise ableiten, dass die Interoperabilität vor allem auch eine
Frage der Systemabgrenzung ist, egal ob es sich dabei um eine technische oder organisatorische Abgrenzung des Systems handelt.
2 Interoperabilität am Beispiel der IG GIS AG
In der Ostschweiz haben sich die Kantone Appenzell A.Rh., Appenzell I.Rh. und St. Gallen und sowie ca. 60 Gemeinden (Bezirke im Kanton AI) zu einer Interessengemeinschaft GIS, der IG GIS AG zusammengeschlossen. Das eigentliche Betreiben des GIS ist
in diesen Kantonen und Gemeinden teilweise bereits seit 1997 aus der Verwaltung ausgelagert und einem privaten Betreiber, der F+P GEOINFO AG übertragen worden. Die
IG GIS AG hat einen rein koordinativen Charakter und bündelt die Interessen der Aktionäre (Gemeinden, Bezirke und Kantone) gegenüber dem GIS-Betreiber. Die Geschäftsführung (50% Stelle) der IG GIS AG ist dem Dienst für Informatikplanung des Kantons
St. Gallen angegliedert.
2.1 Gesamtsystem
Wenn wir den heutigen Stand der Architektur des Gesamtsystems betrachten, dann
wird es relativ schwierig über Interoperabilität des Gesamtsystems zu berichten, weil
das System sehr gross ist. Das Rechenzentrum der IG GIS AG ist zudem einerseits in
das Rechenzentrum des Kantons St. Gallen (Abraxas Informatik AG) und andererseits
1
Quelle: http://de.wikipedia.org
9.1
Die Komplexität der Interoperabilität: ein einfacher Praxisbericht aus der Ostschweiz
komplett in die Informatikstrukturen der anderen Kantone und Gemeinden eingebettet.
Abbildung 1 zeigt die stark vereinfachte Architektur des RZ der IG GIS AG als Gesamtsystem:
Abbildung 1
Auf Grund der Grösse der IG GIS AG - drei Kantone und rund sechzig Gemeinden –
können wir von einer regionalen Geodateninfrastruktur (RGDI) sprechen. Suchen wir
in dieser Organisation Interoperabilität, dann finden wir diese in vielen, einzelnen Teilsystemen.
Betrachten
wir
die
„Aussenbeziehungen“
dieser
Organisation, nämlich die vielen Datenlieferanten, andere
RGDI’s,
die
künftige
NGDI
(Nationale
Geodateninfrastruktur) oder gar eine europäische
Organisation, welche eine Geodateninfrastruktur betreibt,
dann denke ich ganz intuitiv an den Turmbau zu Babel.
Gemäss der oben erwähnten Definition von Interoperabilität
müssen nun nämlich alle diese Organisationen „Informationen auf effiziente und verwertbare Art und Weise austauschen
bzw. dem Benutzer zur Verfügung stellen, ohne dass dazu
gesonderte Absprachen zwischen den Systemen notwendig sind.“
Dazu müssten diese nicht nur hunderte von technischen
Standards und Normen einhalten, sie müssten auch in ihren
betriebswirtschaftlichen Abläufen und Organisationsformen
interoperabel oder kompatibel werden. Davon sind wir noch weit entfernt. Und wie
beim Turmbau von Babel sind es die verschiedenen Sprachen die uns manchmal zur
Verzweiflung bringen: So spricht der Ingenieur, welcher Fachdaten für eine Gemeinde
Abbildung 2
9.2
erfasst, eine andere Sprache als der Informatiker, der eine regionale Geodateninfrastruktur betreibt.
Dieses Grundprinzip „der verschiedenen Sprachen“ in Bezug auf Interoperabilität lässt
sich sehr einfach nachprüfen: Sucht man im Internet nach dem Wort „Interoperabilität“,
zeigen viele Links auf Hilfsorganisationen. Auch dort treffen verschiedenste Organisationen, Sprachen, Techniken und Kulturen aufeinander.
Im Folgenden ziehe ich die Systemgrenzen enger und fokussiere auf das Gesamtsystem
IG GIS. Zwecks besserer Übersicht teile ich das Gesamtsystem in drei Teile auf:
x Daten
x Applikationslogik
x Präsentation der Daten
Weitere Teilsysteme wären noch:
x
x
x
x
Systemplattformen
Betriebssysteme
Netzwerke
Weitere Organisationsprozesse
2.2 Teilsystem „Daten“
2.2.1
Stand Heute
Betrachten wir das Teilsystem „Daten“, dann stechen in dieser Lösung die heterogenen
Strukturen der Ostschweiz sofort ins Auge. Kleinere Gemeinden (mit bis ca. 4500 Einwohner) mit bis zu 17
verschiedenen, eigenständigen
Korporationen
sind
keine
Seltenheit.
Dabei ist natürlich
jede Korporation ihr
eigener
Datenherr
und
bestimmt
autonom, wer auf ihre
Abbildung 3
Daten Zugriff hat.
Heute liefern 64 verschiedene Datenlieferanten, 178 Datenthemen (ein Thema ist z.B.
die amtliche Vermessung (AV), der Leitungskataster Abwasser, usw.), in 609 Arten von
Datensätzen (eine Datensatzart ist dabei z.B. die Ebene Liegenschaften in der AV), und
15 verschiedenen Datenformaten an. Davon sind gerade einmal 9 Datensätze in INTERLIS I beschrieben und durch die Kantone2, den SIA3 oder andere Fachverbände
normiert. Nur die Daten welche in INTERLIS I angeliefert werden, sind interoperabel.
Wenn wir die 609 Arten von Datensätzen auf die geografischen Gebiete, also z.B. die
einzelnen Gemeinden (AV-Liegenschaften der Gemeinde X, AV-Liegenschaften der
Gemeinde Y, usw.) aufteilen, dann sind es 10'606 einzelne Datensätze. Wir betreiben
und organisieren also eine ganze Menge Schnittstellen und wenden viel Zeit für Qualitätskontrollen auf. Und - es funktioniert sehr gut!
2
Im Kanton SG die Geodatenkonferenz und im Kanton AR der GIS-Ausschuss AR
Ingenieur- und Architektenverein
3 Schweizerischer
9.3
Im RZ der IG GIS halten wir sehr viele Daten auf einem RDMS4. Das sind Benutzerdaten, Benutzerrechte, Sichtendefinitionen usw. welche allerdings eher der Applikationslogik zugehören, ein klarer Trennungsstrich ist hier nicht möglich. Die grafischen Daten
liegen immer noch in einem proprietären Format. Dies ist bei unseren grossen Datenmengen – leider – immer noch eine Frage der Systemperformance.
Innerhalb des RZ des Kantons St. Gallen und über das Intranet der Kantone AR und AI,
haben wir unterschiedliche Direktzugriffe in die Datenbestände anderer RDBMS realisiert. Gesamthaft sind heute 22 weitere Datenbanken (Fremddatenbanken) direkt an
die Daten der IG GIS angebunden. Das heisst, dass der Nutzer direkt über sein GIS auf
diese Datenbanken zugreift. Diese Einbettung in die vorhandenen IT-Strukturen zeugt
wiederum von Interoperabilität.
Zu dieser Auslegeordnung im Teilsystem Daten gehören zudem weitere, sehr wesentliche Aspekte:
Die Darstellung der Daten, die dazu gehörenden Legenden, die rechtlichen Hinweise
und der Aktualitätsstand spielen bei den Nutzern eine nicht zu unterschätzende Rolle.
Wir führen über alle Datenbestände umfassende Metadaten, welche auf dem RDBMS
abgelegt und bereits heute in einer Form vorhanden sind, die einen interoperablen Austausch mit Fremdsystemen zulässt.
2.2.2
Aussichten
In der Datennormierung warten wir auf Standards der verschiedensten internationalen, nationalen und regionalen Gremien.
Im Teilsystem Daten sehen wir für die Zukunft eine zentrale Datenverwaltung auf der
Basis eines Geodatenservers mit einer RDBMS. Unsere Versuche, mit verschiedenen
Applikationen auf einen Geodatenserver zuzugreifen, zeigen, dass bereits die Interpretationen simpler geometrischer Datentypen Fragen aufwerfen. Erschwerend kommt die
produkteabhängige Darstellung der Daten dazu.
Beim Datenaustausch und der Darstellung der Daten setzen wir auf INTERLIS II, wobei die Marktakzeptanz bei unseren Datenlieferanten aus heutiger Sicht teilweise doch
sehr fraglich ist. In Frage kommt hier auch der internationale Standard, nämlich GML3.
4
Relationales Datenbank Managementsystem
9.4
2.3 Teilsystem „Applikationslogik“
2.3.1
Stand Heute
Wir betreiben einerseits verwaltungsintern Applikationen auf der Basis eines DesktopGIS und verschiedene Web-Applikationen im Intranet, andererseits öffentlich im Internet verschiedene Produkte wie z.B. das www.geoportal.ch. Der umfassende Teil unserer
Applikationslogik liegt immer
noch in den einzelnen Applikationen,
ein
kleiner
Teil
auf dem RDBMS. In diesem
Punkt ist Interoperabilität nicht
gegeben.
Abbildung 4
Wie im Teilsystem Daten bereits erwähnt, sehen wir im Bereich der Applikationslogik
folgende wesentlichen und erwähnenswerten Punkte:
x Wir betreiben eine sehr umfassende Benutzerverwaltung mit entsprechenden Vertragsregelungen und Zugriffsrechten. 907 registrierte Benutzer in 128 Benutzergruppen greifen verwaltungsintern geordnet auf unsere Datenbestände.
x Wir legen unsere umfassende Datenbestände in Strukturen ab, dabei wenden wir
folgende Ordnung an:
x Kategorien
x Bereiche
x Themen
x Datensätze
x Um den Nutzern die Arbeit zu erleichtern, stellen wir ihnen Daten in den gewohnten Karten zur Verfügung. Karten sind dabei vordefinierte Kombinationen
von Datensätzen oder definierte Sichten.
x Wir haben zunehmend Datensätze, welche auch über ein Regelwerk definiert sind
(z.B. Gewässernetze inkl. Kilometrierungen und Routenbildungen, Flächentopologien usw.).
2.3.2
Aussichten
In Bezug auf Interoperabilität innerhalb der Applikationslogik ist die Entwicklung aus
der Informatik bereits vorgezeichnet: .net, COM, GML/XML usw. werden die künftigen
Applikationen interoperabler gestalten.
In Bezug auf die Daten-Zugriffsrechte ist eine echte Interoperabilität vermutlich sehr
fraglich und nicht sinnvoll.
Datenstrukturen (in der Form der oben erwähnten Gliederungen), vordefinierte DatenSichten usw. sind heute bereits in einem RDBMS abgelegt und sind im technischen Sinne bereits interoperabel.
Mit INTERLIS II können wir künftig die Definition von Regeln zu den Daten interoperabel beschreiben. Die Regelwerke selber sind möglichst mit den Daten in einem
RDBMS abzulegen.
9.5
2.4 Teilsystem „Präsentation“
2.4.1
Stand Heute
Im Teilsystem Präsentation sind verschiedenste Standards und Normierungen schon
vorhanden. Z.B. verteilen wir verwaltungsintern in den Geoportalen für Betrachter
(6000 bis 7500 Arbeitssitzungen pro Monat) und öffentlich im Internet (10’000 bis
14’000 Arbeitssitzungen pro Monat) über http schon heute Daten auf verschiedenste
Betriebssysteme. Ebenso leben wir beim Betrieb der Geoportale für Anwender (230 registrierte Benutzer) über die Metaframe/Citrix-Umgebung eine spezielle Art von Interoperabilität über die Betriebsystemgrenzen hinweg.
Abbildung 5
Mit der heute verfügbaren Technik, insbesondere von WMS5 und WFS6, wäre eine weitere Interoperabilität (auch aus den proprietären Daten heraus) bereits möglich, wird
aber wegen der Zugriffsrechte noch nicht angewendet. Die Anwendung von WMS ist
deshalb zur Zeit nur für die öffentlichen Daten im Internet sinnvoll.
2.4.2
Aussichten
In diesem Teilsystem sehen wir die künftige Anwendung von diversen Web Servicen als
sinnvolle Möglichkeit für die frei verfügbaren Daten im Internet:
x
x
x
x
x
x
WMS (Web Map Service)
WFS (Web Feature Service)
WCS (Web Coverage Service)
WCAS (Web Catalog Service)
WCTS (Web Coordinate Transformation Service)
Weitere Web Services
Zur Zeit steht für unsere Anwendungen sicherlich der WMS (Web Map Service) im
Vordergrund, da „fremde“ Institutionen Daten betrachten und drucken aber nicht in
Vektorform beziehen können. Jedenfalls wäre das im Sinne vieler Datenherren, die insbesondere im Verwaltungsumfeld die Daten zum Betrachten und Drucken freigeben.
5
6
Web Map Service
Web Feature Service
9.6
3 Fazit
In einer Organisationsstruktur für regionale Geodaten, wie derjenigen der IG GIS AG
sind in verschiedensten Teilbereichen Ansätze zu einer Interoperabilität vorhanden.
Diese Ansätze sind heute noch sehr technisch, vielschichtig und betreffen sehr verschiedene, spezielle Fachbereiche aus der Informatik und der Geoinformationsbranche.
Von einer echten Interoperabilität, also einer Interoperabilität von Organisationen von
regionalen und nationalen Geodatenstrukturen sind wir unseres Erachtens noch weit
entfernt.
Je grösser wir die Systemabgrenzung ziehen, desto komplexer wird die Interoperabilität und umso mehr verlagert sich diese weg von Systemen und der Technik auf die
Organisationen und deren Prozesse.
4 Literatur
INSPIRE. 2003. Spatial Data Infrastructure in Europe. Spatial Application Division
K.U. Leuven, Research & Development
Ott, Mathias. Datenaustausch und Interoperabilität, Dienste für eine offene
Geodatenstruktur,
www.ikg.uni-bonn.de/Lehre/Geoinfo/is_iv_SS_04/Vorträge%5C04_05_27_Ott.ppt
Open GIS Consortium. OpenGIS Service Architecture
SOGI. 2003. Worin liegt der praktische Nutzen von Interoperabilität und Normung für den
GIS-Anwender in der Schweiz?” Schweizerische
Organisation für Geoinformation, Bericht der Fachgruppe GIS Technik
9.7
10
Modellbasierte und interoperable
Bearbeitung der Basisdaten in
Wallonien
Jean-Claude Jasselette, MET Belgien
Jean-Claude Jasselette
MET (D.432) Topographie et Cartographie
CAMET - Boulevard du Nord, 8
B-5000 Namur
Tel :
Fax :
E-Mail :
+32 817 733 51
+32 817 738 88
1 Einführung
1.1 Vorwort
Jean-Claude Jasselette ist Adjunkt der Topographie- und Kartographieabteilung des
Bau- und Verkehrsministeriums der Region Wallonien in Belgien. Er ist im Projekt
InfraSIG involviert und hat sich insbesondere an den Arbeiten der Modellierung der
topographischen Referenzdaten mit Hilfe von INTERLIS beteiligt.
Das Hauptziel des Referates besteht darin, die Arbeiten vorzustellen, die im Rahmen
der Einführung einer Infrastruktur für geographische Informationen in der Region Wallonien durchgeführt wurden. Im Referat wird versucht, die zugrunde liegenden Leitlinien und ihre Auswirkungen im Kontext der Interoperabilität für räumliche Daten aufzeigen.
1.2 Übersicht
Nach einer kurzen Beschreibung der Situation der belgischen Kartographie wird die
Problematik in ihren wallonischen regionalen Zusammenhang gestellt. Schritt für
Schritt werden die verfolgten Zielsetzungen, die eingesetzten Mittel und schließlich der
Stand der Arbeiten durchgegangen. Die Schlussfolgerungen werden sich auf die Vorteile des gewählten Vorgehens, auf die aufgetretenen Probleme sowie auf das daraus Gelernte beziehen.
2 Kontext und Problematik
2.1 Belgien, ein junger Bundesstaat
FLANDERN
13 522 km2
BRÜSSEL
162 km2
WALLONIEN
16 844 km2
10.1
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien
Bekanntlich setzt sich Belgien seit mehr als 20 Jahren für einen Regionalisierungsprozess
ein. Für Themen wie die Kartographie ist die öffentliche Hand einerseits unterteilt in
eine föderale Ebene und andererseits ein regionales Niveau, das die Region Wallonien
(16.844 km2), die Region Flandern (13.522 km2) und die Region der Hauptstadt Brüssel
(162 km2) umfasst.
2.2 Kartographie im Bundesstaat und in den Regionen
Wie die meisten europäische Staaten verfügt Belgien über ein eigenes nationales geographisches Institut (IGN). Diese föderale öffentliche Verwaltung wird mit allen Kartographie-, Geodäsie- und Fernerkundungsaufgaben beauftragt, die sich auf das gesamte
Staatsgebiet beziehen. Das belgische IGN ist Hersteller von qualitativ sehr hochstehenden Karten und topo-geographischen Daten in den Massstäben zwischen 1/300’000 und
1/10’000.
Abgesehen davon ist auf der föderalen Ebene das Katasteramt Hersteller von Grundstücksplänen mit sehr grossem Massstab. Momentan haben diese Pläne ausschliesslich
steuerpolitische Ziele und haben meistens keine Vermessungsqualität. Ein ehrgeiziges
Projekt zur Modernisierung des belgischen Katasteramtes ist in Vorbereitung.
Infolge der Regionalisierung im Bereich der umweltrelevanten Kompetenzen der Raumordnung, der öffentlichen Arbeiten und erst kürzlich der Landwirtschaft hat die regionale öffentliche Hand verschiedene kartographische Projekte geschaffen. Was die Referenzdaten betrifft, hat jede der drei Regionen ein digitales topographisches Kartographieprojekt in sehr grossem Massstab eingeführt. Es handelt sich um die Projekte Urbis
in der Region der Hauptstadt Brüssel, PICC in der Region Wallonien und GRB in der
Region Flandern. Diese drei Projekte entsprechen ungefähr denselben Genauigkeitskriterien und sind vergleichbar mit einer Karte des Typs "öffentliche Arbeiten" im Maßstab
von 1/1’000 oder besser. Sie werden im Allgemeinen durch numerische Orthophotoplan-Layer vervollständigt.
Mangels einer Koordinationsstelle auf föderalem oder interregionalem Niveau haben
die durch die drei Regionen eingeleiteten Projekte trotz allem deutlich verschiedene
technische Eigenschaften.
2.3 Kartographie in der Region Wallonien
2.3.1
Verschiedene Ansätze und Referenzen
Auch innerhalb einer Region ist die Homogenität nicht immer die Regel. Auf diese Art
haben in Wallonien verschiedene Hersteller von analogen und numerischen kartographischen Daten verschiedene Methoden und Referenzen verwendet oder verwenden sie
immer noch. Zum Beispiel ist es mangels gemeinsamer Referenz nicht selten so, dass
Geometer, die für verschiedene Verwaltungen der Region Wallonien arbeiten, die gesammelten Vermessungsdaten nicht austauschen können.
2.3.2
Die Vielfalt numerischer Daten
Seit einigen Jahren wird der Gehalt der numerischen geographischen Daten, die durch
die Verwaltungen der Region Wallonien produziert wurden, allerdings anerkannt. Daher bilden die Plans Photographiques Numériques Communaux (PPNC) einen numerischen
Orthophotoplan in Farbe mit Meter-Auflösung flächendeckend für die ganze Region.
Das Projet Informatique de Cartographie Continue (PICC) bietet eine numerische Kartographie im Massstab 1/1’000 über eine Fläche von mehr als 8’000 km2 an, die unter ande-
10.2
rem in einer geographischen Datenbank mehr als 55% der 1'500’000 Gebäude, die die
wallonische Region umfasst, enthält.
Angesichts der Qualität der bestehenden Daten und der Kosten, die ihre Produktion
dargestellt hat, begreift man, dass ihre Aufwertung ein wichtiger Einsatz ist, und dass
nicht zu beabsichtigen ist, ein neues Projekt derselben Spannweite anzusetzen.
2.3.3
Der Zukunftsvertrag und das Vorgehen eGov
Im Zeitalter der Computerisierung und Vernetzung der Datenbanken ist die Notwendigkeit, die Aktivitäten der verschiedenen für die Erstellung von räumlichen Daten verantwortlichen öffentlichen Hoheitsträgern zu koordinieren, ein entscheidender Einsatz
geworden.
Die Regierung der Region Wallonien ist sich dieses Einsatzes bewusst. In einer der vorrangigen Massnahmen ihres Contrat d’Avenir pour la Wallonie (CAW), Absichtserklärung
der Regionalpolitik, wird festgelegt, dass die Regierung "allen Beteiligten via Internet
die Gesamtheit der kartographischen Daten der Region Wallonien zur Verfügung stellt"
und das, indem sie "die verschiedenen Kartographieprojekte in ein offenes, zusammenhängendes und koordiniertes System integrieren werden, das den Informationsaustausch erlaubt und das sowohl Redundanz als auch Inkompatibilität verhindert."
Seit 2002 präzisiert das aktualisierte CAW, dass die "regionalen kartographischen Projekte der Öffentlichkeit im Rahmen des Projekts vom wallonischen e-Gouvernement übers Internet zur Verfügung gestellt werden." Man sieht also, dass der Zugang zu zusammenhängenden geographischen Daten und die Qualität durch die wallonische öffentliche Hand für prioritär eingeschätzt werden.
2.3.4
Das CTC und das Projekt InfraSIG
In diesem Rahmen ist das Comité Technique Cartographique (CTC) der Region Wallonien
im November 2000 ins Leben gerufen worden. Das CTC setzt sich aus Vertretern des mit
der Kartographie beauftragten Ministeriums und aus den verschiedenen Generaldirektionen der wallonischen Ministerien zusammen. Sein Hauptziel besteht darin, die Kohärenz zwischen den verschiedenen Kartographiediensten der Region Wallonien zu gewährleisten und damit den Zielsetzungen des aktualisierten CAW zu entsprechen.
Um der Regierung die Elemente einer Verwaltungs- und Verbreitungspolitik der öffentlichen geographischen Daten im Rahmen einer internetbasierten Infrastruktur vorschlagen zu können, hat das CTC im Jahre 2002 ein Projekt mit der Bezeichnung InfraSIG
lanciert. Dieses Projekt zielt darauf ab, eine Infrastruktur für die Verwaltung und die
Verbreitung der geographischen Daten der Region Wallonien zu definieren und zu verwirklichen, um den Anforderungen und den Bedürfnissen aller Benutzer zu entsprechen. Um dieses Projekt zu verwirklichen, profitiert das CTC von der technischen Hilfe
eines Konsortiums, das durch die Gesellschaft GFI gesteuert wird.
Das InfraSIG-Projekt entwickelt sich in vier Richtungen:
1. Eine organisatorische Achse, um das Projekt zu koordinieren, die Rolle und die Verantwortung der Beteiligten zu definieren, die Benutzer zu sensibilisieren und auszubilden und einen Führer der guten Praktiken aufzustellen.
2. Eine technische Achse, die zum Ziel hat, die Problematik zur Sprache zu bringen
x von der Infrastruktur der Verbreitung der Daten,
x der Metadaten,
10.3
vom Setzen in Kohärenz der Referenzdaten und der thematischen Daten durch
den Modellbau,
x mit diesen Angaben assoziierte Dienste,
x Aktualisierungsverfahren.
3. Eine Rechtsachse, die anvisiert,
x einerseits ein vereinheitlichtes Lizenzmodell für die Zurverfügungstellung geographischer Informationen durch die Region aufzustellen;
x andererseits die Auswirkung der Gesetzgebungen über den Zugang zur Information zu untersuchen.
4. Eine sozioökonomische Achse, die zum Ziel hat, die Kosten, den Markt und die Anwendungen zu analysieren, um der wallonischen Regierung die Bestandteile einer
Politik für die Verbreitung der geographischen Daten vorzuschlagen.
x
Jede dieser Achsen entspricht einer oder mehreren Arbeitsgruppen.
Minister M. DAERDEN
(Kartographische Angelegenheiten)
Ministerialkanzlei – “Carto”
versch. DG
Technisches Komitee Kartographie
Technische
Projektassistenz
Projektleitung INFRASIG
GT
Organisation
Koordination
Basisdaten
GT Technik
Thematische
Daten
Metadaten
Infrastruktur
Verteilung
GT Recht
GT
Preis
Permanenter Auftrag
Organisation
Technik
Recht
Preis
Punktuelle Aufträge
10.4
Schliesslich ist das CTC beauftragt, "die Zusammenarbeiten und die Kooperationsabkommen mit anderen regionalen und gemeinschaftlichen (OC Gis-Vlaanderen, CIRB...),
nationalen (IGN, Katasteramt...) und europäisch Instanzen (grenzüberschreitende Projekte, Initiative LEITEN...) zu koordinieren."
3 Verfolgte Ziele
Die wichtigsten Leitlinien, die bei der Einführung von der Infrastruktur der Verbreitung
der wallonischen geographischen Informationen verfolgt werden, können wie folgt zusammengefasst werden.
3.1 Datenverwendung
Zunächst muss die Infrastruktur die Weiterverwendung der Daten vereinfachen und
die Aufrechterhaltung des Qualitätsniveaus dieser Daten garantieren, was ihre Aktualisierung voraussetzt.
Um zu garantieren, dass geographische Informationen, die im Rahmen eines Einzelvorhabens produziert wurden, an anderen Zielen wieder verwendet werden und dass sie
durch die öffentliche Hand befragt oder in Mehrwertdienste durch die Privatwirtschaft
noch integriert werden, muss man ihnen zunächst eine bessere Sichtweite und eine adäquate Dokumentation gewährleisten. Man muss auch im Rahmen des Möglichen die
Faktoren identifizieren und reduzieren, die den Zugang zu den geographischen Daten
beschränken, wie die Trägheit, die mit der Verwaltung oder mit der Gesetzgebung zusammenhängt, die zu hohen Preise sowie eine Reihe von technischen Problemen.
3.2 Begriff der authentischen Quellen
Daher muss die Kohärenz verstärkt werden. Diese Zielsetzung deutet zum Beispiel an,
dass eine gemeinsame Referenz identifiziert oder dargestellt wird, und dass man eine
Verbreitung von Mehrfachkopien der Referenzdaten vermeidet. Diese letzte Sache lässt
in der Tat gewaltige Probleme bei der Aktualisierung dieser Daten entstehen.
Ein Ziel auf lange Sicht ist also die Konsolidierung des Begriffes der authentischen Quellen welche eine eindeutige und gut verfügbare Referenz erlaubt. Im Gegensatz dazu
werden heute die PICC-Daten in der Zwischenversion des wallonischen Geoportals
vierfach kopiert!
3.3 Interoperabilität auf dem Datenniveau
Die Online-Verbreitung der geographischen Daten setzt auch die Interoperabilität bei
den Daten voraus.
3.4 Berücksichtigung von Normen und internationalen Standards
Die Realisierung dieser Infrastruktur wird im Sinne der Integration und der Koordination mit der europäischen Initiative INSPIRE (Infrastructure for Spatial Information in
Europe) sowie unter Berücksichtigung der bestehenden Normen und internationalen
Standards, die bereits bestehen oder erst in Vorbereitung sind (ISO, CEN, NBN, OGC,
W3C...), geführt
10.5
3.5 Unabhängigkeit von Systemherstellern
Schliesslich sucht die wallonische Region eine grösstmögliche Unabhängigkeit gegenüber den Softwareherstellern. Bei gleicher Leistung werden die „Open Source“Lösungen gegenüber den proprietären Lösungen bevorzugt.
4 Mitteleinsatz
4.1 Projekt InfraSIG, öffentlich-private Interaktion
Das InfraSIG-Projekt funktioniert auf der Basis einer Wechselwirkung zwischen den
verschiedenen Verwaltungen und den privaten und universitären Partnern. Seit 2004 ist
die Eidgenössische Technische Hochschule in Zürich ebenfalls im Projekt involviert.
4.2 Methode INTERLIS 2
Diese Partnerschaft ist vor allem dadurch begründet – wie wir noch detaillierter sehen
werden – weil die modellbasierte Methode mit INTERLIS im Zusammenhang mit dem
Projekt InfraSIG übernommen wurde.
5 Fortschritt der Implementierung
5.1 Abgeschlossene Realisierungen
Die erste Phase des Projektes InfraSIG wird auf vier Jahre verteilt (Februar 2002-2006).
Die folgenden Teilziele wurden bis jetzt erreicht:
x
x
x
x
x
Die Realisierung eines kartographischen Zwischenportals, das ins eGouvernement-Projekt der Region Wallonien integriert wurde.
Die Realisierung eines Metadaten-Verwaltungssystems gemäss den ISO-Normen
19115 und 19139
Die Realisierung von Applikationen für den sicheren Zugriff auf prioritäre Referenzdaten, sowohl für die Visualisierungen als auch für das Laden der Daten über
das Internet.
Die Redaktion von Berichten über die rechtlichen und wirtschaftlichen Aspekte.
Das Modell der topographischen Referenzdaten Walloniens wurde mit INTERLIS
2 beschrieben und die entsprechenden technischen Anforderungen wurden in einem Pflichtenheft verfasst.
5.2 Das vorläufige Portal
5.2.1
Stand der Arbeit
Das kartographische Portal entspricht einem einzigen interaktiven Schalter für die
Verbreitung der geographischen Information der Region Wallonien für alle Anwender
wie Verwaltungen, Unternehmen und Bürger. Das heutige Portal ist eine Zwischenlösung, welche realisiert wurde, um schnell die Ziele der Abgabe der Referenzdaten erreichen zu können.
Das Portal dient als einziger Zugang, um:
x
10.6
allen Interessenten den Zugriff auf die geographischen Daten aufgrund der vorhandenen Metadaten und der standardisierten Lizenzverträge zu gewähren und
so die Geodaten zu verbreiten.
x
x
x
x
5.2.2
die Visualisierung und das sichere Herunterladen der prioritären Referenzgeodaten zu erlauben.
Allen via Internet-Verbindungen den Zugang zu den anderen heute verfügbaren
geographischen Ressourcen (geologische Karte, Atlanten, statistische Karten, dynamische Karten wie Trafiroute usw.) zu gewähren die auf den verschiedenen
Homepages der kartographischen Dienste der Region Wallonien verfügbar sind.
die Realisierung von Standards zu fördern, um den Austausch und die Dokumentation der Qualitätsdaten durch die Bekanntgabe der Resultate des Projektes
InfraSIG über den Führer der guten Praktiken und über Empfehlungen zu garantieren.
die Sensibilisierung der Benutzer zu gewährleisten, indem es die Grundkonzepte
der geographischen Information definiert und die Daten der Kolloquien, Konferenzen oder Fachmessen und der Web-Links, die sich auf die geographische Information beziehen, bekannt gibt.
Zukünftige Aktivitäten
Definitives Portal – angestrebte technische Architektur
Benutzer
Sicherheit / Authentifizierung
Register
Daten
Services
Zugriffsverwaltung /
Authentifizierung
Services
Datenkatalog
Servicekatalog
Web Services OGC & W3C
Kartographische Werkzeuge
INTERLISServices
FTP
Datenbank
10.7
Oracle spatial 10g
Alle Daten sind in einem einzigen Datenbankverwaltungssystem gespeichert. Für die
geographischen Daten hat die wallonische Region Oracle Spatial gewählt. Die Daten
vom PICC zum Beispiel werden vom proprietären Format des Herkunft-GIS zu Oracle
Spacial 10g übertragen.
5.3 MétaWal und die ISO-Normen
5.3.1
Stand der Arbeit
Die Fachleute sind sich einig, dass die Metadaten ein unentbehrliches Element der ganzen Raumdateninfrastruktur sind. Im Rahmen des Projektes InfraSIG wurden die Metadaten von allen öffentlichen Datensammlungen Walloniens gemäss den Normen ISO
19115 beschrieben. Die erste Phase dieser Arbeit bestand in der Auswahl und Übersetzung der Attribute, welche für die Beschreibung der wallonischen Daten nötig waren.
Diese Attribute wurden anhand der Anwenderbedürfnisse mit wallonischen Erweiterungen ergänzt. Nach der Festlegung des Metadatenkatalogs wurde das konzeptuelle
UML-Modell der ISO-Norm und der wallonischen Ergänzungen generiert. Das UMLModell der Metadaten wurde danach im Datenbankverwaltungssystem von Oracle implementiert.
Danach wurden Datenerfassungsschnittstellen Intranet – Extranet entwickelt, um die
Kodierung der Metadaten durch den Datenverwalter zu ermöglichen, welcher sowohl
für die Daten als auch für die Metadaten verantwortlich ist. Die Zutrittskontrollen an
diesen Schnittstellen werden mittels eines extern akquirierten elektronischen Systems
LDAP realisiert.
Ein Import-/Export-XML-Werkzeug für Metadaten wurde entwickelt, welches die Vornorm ISO 19139 Version 6 vollständig erfüllt. Es ermöglicht sowohl die Integration von
Metadaten aus anderen Quellen als auch den Austausch von Metadaten mit allen Partnern ausserhalb der Region Wallonien.
Zurzeit ist das auf den Namen MétaWal getaufte System operationell und die Grundlagen der Metadaten wurden erfasst. Eine grosse Vielfalt von flexiblen Suchprozeduren
wurde entwickelt um die Abfragen von verschiedenen Anwendern zu ermöglichen. Die
Verbindung mit dem Suchwerkzeug Mugire ermöglicht mehrsprachige Suchprozesse.
5.4 Die abgegebenen Daten – die dazugehörigen Dienste
5.4.1
Stand der Arbeiten
Die Daten, auf welche durch das provisorische Portal zuerst Zugang verschafft wird,
sind die Referenzdaten (PICC, PPNC, Strassenatlas, MNT Verlauf der Hauptgewässer).
Bis heute erlauben die auf diesen Daten entwickelten Dienste einerseits ihre Visualisierung mittels zweier mit der OGC-Norm WMS kompatiblen Schnittstellen und andererseits das Herunterladen der Datenfiles in zwei proprietären Formaten der GIS-Software.
Es ist zu beachten, dass diese Daten laufend mit anderen thematischen Daten nach und
nach (gem. Validierung) vervollständigt werden.
5.4.2
Das provisorische Portal verwaltet Dienste nach den Normen von OGC oder W3C. Diese Dienste verwenden kartographische Werkzeuge, welche Algorithmen und technische
10.8
Funktionen aktivieren, die in den dem Besucher zugänglichen Web-Services enthalten
sind.
Neben den Applikationsdiensten und den Visualisierung- und Datenzugriffdiensten
wird man weitere generische Dienste schrittweise den Anwendern und Entwicklern zur
Verfügung stellen. Darunter wird man Lokalisierungsdienste (verbunden mit einem
Gazetteer), Dienste für das Herunterladen und die INTERLIS-Dienste (Checker, semantische Transformation der Daten, Werkzeuge für die Formatumwandlung, Verwaltung
von eindeutigen Identifikatoren) finden. Diese Werkzeuge werden ermöglichen die Interoperabilität der Daten zu gewährleisten, die Anfragen der Anwender, welche mit
verschiedener GIS-Software arbeiten, zu beantworten und die Daten in den erforderlichen Formaten herunterzuladen.
Die Entwicklung des Dienstleistungsumfeldes sieht vor, Dienste zu integrieren, die elementareren Funktionen entsprechen. Es ist die Kombination solcher „atomaren“ Dienstleistungen, die erlauben wird, Applikationen auf einem den Bedürfnissen der Anwender entsprechenden Niveau zu realisieren.
Ausserdem muss die Verbreitungsinfrastruktur einen Katalog von Diensten enthalten,
welche wahrscheinlich der Norm OGC entsprechen. Mehrere auf dem Markt erhältliche
Kataloge werden zurzeit im Rahmen des Projektes InfraSIG evaluiert. Ein Bewertungskriterium ist ihr Niveau der Erfüllung der Norm ebXML
5.5 Rechtliche Aspekte
5.5.1
Stand des Fortschrittes
Für jede Anwenderkategorie wurde ein einheitliches Lizenzmodell verfasst und auf
dem kartographische Portal platziert, das für alle Daten, die durch die regionale Verwaltung verbreitet wurden, standardisiert ist.
Das Herunterladen von Daten ist nur möglich, wenn der Anwender den Lizenzvertrag
angenommen hat. Bei der Visualisierung der Daten erscheint ein rechtlicher Hinweis auf
dem Bildschirm.
Das hat die Prüfung der Gesetzgebungen zum geistigen Eigentum, über das Verwaltungsrecht, über die Daten von persönlichem Charakter und zur Respektierung des privaten Lebens, über den Verbraucherschutz, über die Verantwortung des Erzeugers und
des Benutzers und über die elektronische Unterschrift erfordert.
5.5.2
Zurzeit wird die Frage diskutiert, inwieweit das Geoportal zur Visualisierung von Geobasisdaten der Öffentlichkeit zugänglich gemacht werden kann. Es fehlt allerdings eine
hinreichende Rechtssprechung und es ist schwierig zu garantieren, dass die Veröffentlichung solcher Basisdaten nicht einer Verletzung der Bestimmungen über den Schutz der
Privatsphäre bedeutet. Besonders stellt sich diese Frage für die Veröffentlichung von
sehr detaillierten Orthophotoplänen, welche eine Visualisierung vom Innern privater
Liegenschaften erlauben.
10.9
5.6 Sozio-ökonomische Aspekte
5.6.1
Stand der Arbeit
Um die Regeln für die Abgaben der geographischen Daten definitiv festzulegen ist es
notwendig eine Preispolitik zu definieren. Für die Redaktion eines Vorschlages für die
wallonische Regierung wurden drei Aspekte verfolgt:
x
x
x
Einerseits wurde eine Studie über die Anwendungen der geographischen Daten
unternommen. Zu diesem Zweck wurde eine breite semantische Studie über eine
grosse Menge Dokumente unternommen
Andererseits wurde eine Studie verfasst über die allgemeinen Kriterien der Preisfestlegung und über die heutige Situation im Bereich der geographischen Daten in
Europa
Schliesslich wurde der Vorschlag gemacht, mit welchem eine Preispolitik beschrieben wird, die tiefe Preise bezweckt und in welcher man die Randkosten für
die Abgaben berücksichtigt.
Dieser Vorschlag entspricht den allgemeinen Zielen der Region Wallonien, welche eine
breite Verbreitung der geographischen Daten bezweckt und globale Einsparungen sowie eine regionale Förderung ermöglicht.
Der Vorschlag fusst auf den Charakteristika des Marktes geographischer Daten und liefert eine Matrix, welche es erlaubt, die Preise in Abhängigkeit von Dateneigenschaften,
Benutzertypus und vorgesehener Verwendung zu bilden. So ist es zum Beispiel denkbar, dass ein Unternehmer freien Zugang zu gewissen als essentiell beurteilten Daten
erhält, um für andere – zur kommerziellen Nutzung vorgesehene – Daten bezahlen
muss.
5.6.2
Wenn die wallonische Regierung die Vorschläge annimmt wird ein Abgabesystem entstehen in welchen die Geodaten für die öffentlichen Dienste und die Ausbildungsinstitutionen kostenlos im Rahmen ihres Auftrages abgegeben werden. Für die anderen Berufskreise wird man die Abgabe der Geodaten auf der Basis von Abonnements- oder
Partnerschaftsverträgen regeln. Ein Detailverkauf in besonderen Fällen soll ebenfalls
möglich sein.
5.7 Die Modellierung der topographischen Referenzobjekte
5.7.1
Stand der Arbeiten
Die Modellierung der Referenzdaten ist Bestandteil der existierenden Daten und insbesondere vom PICC. Daher wird der Objektkatalog stark von letztgenannten Daten beeinflusst. Ein indirekter Effekt der Modellierungsprozesse war die Erhöhung des Bekanntheitsgrades der Daten von PICC. Ebenfalls verbreitete sich die Diskussion über die
Referenzdaten auch auf andere Berufskreise und blieb nicht nur beschränkt auf den
Kreis der Geodaten-Produzenten. Diese Entwicklungen haben die Bedeutung des PICC
aufgewertet. Dadurch wird es möglich, das PICC von einer rein numerischtopographischen Planform hin zu einer echten Datenbasis zu entwickeln.
Das Konzept der Vererbung, typisch für die objektorientierten Technologien wurde eingesetzt um drei gekapselte Geodatenmodelle zu definieren. Das detaillierteste – innerste
– Modell, das Geometermodell, enthält alle im Gelände nach dem System Walcors aufgenommenen Objekte (wallonisches GPS-RTK-Permanentnetz mit 23 Stationen); das
10.10
mittlere Niveau ist das Modell PICC, welches ein Teil der Objekte des Geometermodells
übernimmt. Schliesslich das Modell der Region Wallonien, welches nur die topographischen Objekte beinhaltet die für eine grosse Anzahl Applikationen benötigt werden. In
der gleichen Art könnte ein Referenzmodell für das ganze Land oder für Europa aufgebaut werden.
Um die sehr unterschiedlichen Detaillierungsstufen zu harmonisieren und zu konzipieren, ist die modellbasierte Methode mit INTERLIS 2 angewendet worden.
Die Modellierung erlaubte einerseits die Datenstrukturen der Thematik unter Berücksichtigung der verschiedenen potenziellen Anwendungen zu verbessern. Andererseits
schien es sinnvoll bei der Modellierung die Ergänzung der bestehenden Daten mit neuen Konzepten wie derjenigen der Strassenplattformen.
5.7.2
Die Einführung der neuen Konzepte und der Einsatz der INTERLIS-Werkzeuge (insbesonders dem Checker) machte eine Menge Inkonsistenzen in den Daten sichtbar. Man
konnte feststellen, dass es nötig sein wird, ein Re-Engineering der Daten vorzunehmen.
In der Folge wird man die Prozesse für die Nachführung der Daten unter der Verwendung der Methoden und Werkzeuge von INTERLIS gestalten. Zu diesem Zweck wird
man eine immer stärkere Koordination der Anstrengungen anstreben. So sollte zum Beispiel nur eine einzige Feldaufnahme für die Nachführung der verschiedenen Datenebenen verwendet werden. Die Möglichkeit von INTERLIS 2 im Bereich der inkrementellen
Nachführung ist vertieft zu analysieren. Es wird notwendig sein, ein Verwaltungssystem für eindeutige Objektidentifikatoren einzuführen.
5.8 Gemeinsames Pflichtenheft für die topographischen Aufnahmen
5.8.1
Stand der Arbeit
Die technischen Spezifikationen wurden in einem gemeinsamen Pflichtenheft aufgrund
der konzeptuellen Datenmodellierung formuliert. Dieses Pflichtenheft könnte nach der
definitiven Validierung als verbindlich für diejenigen Geometer erklärt werden, welche
die Arbeiten für die wallonische öffentliche Hand ausführen. In dieser Art werden die
Ergebnisse ihrer Arbeiten kompatibel zueinander und man wird sie verwenden, um die
Daten des PICC sowie topografische Referenzobjekte auf einfache Weise zu aktualisieren.
5.8.2
Das Pflichtenheft muss noch in einer operationellen Umgebung getestet werden.
Im Übrigen wird demnächst ein Pilotprojekt gestartet, um den Informationsaustausch
zwischen den Feldequipen und der Verwaltung zu erleichtern. Dieser Pilot hat zum
Ziel, im Rahmen des kartographischen Portals einen Web-Dienst für den Datenaustausch mit Hilfe von INTERLIS 2-Werkzeugen zu implementieren. Dieses System wird
es den für die wallonische Verwaltung tätigen Geometern erlauben, nötige Dokumente
aus dem Internet zu beziehen:
das Pflichtenheft, seine Dokumentation, die Datenmodelle usw.
die Daten der Geländeaufnahmen der Verwaltung unter Verwendung der INTERLIS 2-Werkzeuge zu übergeben um die eigenen Daten nach Bedarf zu trans-
10.11
formieren und um ihre Kompatibilität mit den entsprechenden Modellen mit dem
INTERLIS-Checker zu überprüfen.
eine Validierung der eigenen Arbeit sobald die Verwaltung die Daten überprüft
hat.
Die organisatorischen und personellen Aspekte sind eine zentrale Frage des Projektes.
Das Projekt kann nur erfolgreich sein wenn gemeinsame Interessen erkannt werden und
wenn die Veränderungen breite Unterstützung finden.
5.9 Weitere zukünftige Vorhaben
5.9.1
Integration weiterer Partner
Das Vorhaben der Region Wallonien, eine gemeinsame Geodaten-Infrastruktur – basierend auf einem Objektkatalog – zu erstellen, welche mit weiteren thematischen Informationen erweitert werden kann, lässt bereits heute erkennen, dass ein Koordinationsbedarf mit anderen Fachleuten der Regionen Wallonien, Flandern und Brüssel sowie Bundesstellen (IGN und Kataster) unerlässlich ist. Diese Koordination ist unter anderem
notwendig, um die Anforderungen der europäischen Initiative INSPIRE zu erfüllen.
6 Überlegungen
6.1.1
Vorteile von INTERLIS
INTERLIS 2 bietet einerseits die Vorteile der Objektorientierung wie Vererbung und Polymorphismus. Andererseits können die Daten mit einem so genannten Checker auf
Modellkompatibilität überprüft werden. Ebenfalls sehr geschätzt ist in Belgien und insbesondere in der Region Wallonien die Mehrsprachigkeit der Lösung. Als Ergänzung
erleichtert INTERLIS die Nachführung, da sie sich mit inkrementellen Verfahren organisieren lässt.
Schliesslich ist die Unabhängigkeit der Methode von jeglichem Informatiksystem der
entscheidende Vorteil. Er gewährt die Interoperabilität, sobald man die konzeptionellen
Modelle mit INTERLIS beschrieben hat.
6.1.2
Aufgetretene Schwierigkeiten
Einige der erwähnten Vorteile gelten für die Version 2 von INTERLIS. Die Region Wallonien hat von Anfang an entschieden, diese Version zu implementieren, ohne die Version 1 einzusetzen. Dieser Entscheid stellt die wallonische Verwaltung in die Position
des Pioniers von INTERLIS 2, hat aber bereits einigen Zeitverlust verursacht und beinhaltet Risiken, die nicht so leicht abgeschätzt werden können.
Man musste zum Beispiel die Modellierungsarbeit „blind“ vornehmen, da während dieser Zeit die Werkzeuge nur für INTERLIS 1 existierten. Wir sind weiterhin mit dem
Problem konfrontiert, dass zu wenige Werkzeuge für die Modellierung der graphischen
Darstellung zur Verfügung stehen. Werden wir eine direkte Beziehung mit SLD von
OGC erleben?
Es gibt noch weitere offene technische Fragen: die Implementierung der OID und ihres
Transfers zu anderen Formaten mittels Transformationen, die naturgemäss nie neutral
sein können. Wie kann man die Arbeit standardisieren, um allen Datenproduzenten zu
ermöglichen, mit dem gleichen Konfigurationsskript für die Transformationswerkzeuge
zu operieren? Wie weit kann die inkrementelle Nachführung eingesetzt werden? Usw.
10.12
Aufgrund der bisherigen Erfahrungen plädieren wir für eine Vervollständigung der
Norm INTERLIS 2 mit Implementierungsregeln, um die erwähnten Probleme zu vermeiden.
Neben den technischen Schwierigkeiten zeigten sich ebenfalls organisatorische und
menschliche Probleme. Es ist zum Beispiel nicht leicht, alle Betroffenen in das Vorhaben
zu integrieren. Die Beteiligung der Datenanwender war wesentlich kleiner als diejenige
der Datenproduzenten, die bereits sensibilisiert sind auf die Bedürfnisse einer Datenmodellierung.
Man stellte ebenfalls fest, dass eine Vielfalt von Arbeitsmethoden, insbesondere für die
Feldaufnahmen, existiert. Dies ergibt sich aus der fehlenden Standardisierungstradition
im Kreis der wallonischen Datenproduzenten. Die Konsequenz daraus ist ein Bedarf
nach tief greifenden Änderungen, um garantieren zu können, dass die Daten modellkonform erfasst werden. Man kann erwarten, dass Widerstände entstehen, die durch
einen zwingenden rechtlichen Rahmen beseitigt werden können. Terminologische Probleme sind ebenfalls aufgetaucht.
Die bisherigen Erfahrungen in der Region Wallonien sind global betrachtet positiv. Die
INTERLIS-Lösungsansätze ermöglichten, ein konsistentes Vorgehen zu gestalten und
diesem zu folgen. Eine vertiefte Diskussion über die topographischen Referenzdaten
und über ihre langfristige Entwicklung wurde ebenfalls ausgelöst.
Die Wahl von INTERLIS 2 bedeutete trotzdem ein nicht zu vernachlässigendes Risiko.
Mehrere wichtige Fragen blieben bis jetzt unbeantwortet.
Die realisierten Lösungen stehen zurzeit noch am Anfang der Entwicklung. Die nächsten Schritte der Evolution betreffen die Beziehungen zwischen Referenz- und thematischen Daten. Diese Zielsetzung wird den Einbezug einer grösseren Anzahl Partner erfordern.
10.13
11
Modellstandardisierung vs.
semantische Interoperabilität
Aktuelles aus der Forschung
Andreas Morf, ETH Zürich
Josef Dorfschmid, ADASYS AG
Andreas Morf
ETH Hönggerberg
CH-8093 Zürich
Sepp Dorfschmid
ADASYS AG
Dörflistrasse 67
Postfach 5019
CH-8050 Zürich
Tel :
E-Mail :
+41 1 633 32 56 (Morf)
+41 1 363 19 39 (Dorfschmid)
1 Problemstellung / Zielsetzung
Immer wieder kommt es vor, dass Daten neu erfasst werden, obwohl sie an sich vorhanden wären. Sie liegen aber nicht in der gewünschten Form vor. Zum Teil müssten
anspruchsvolle Umformungen durchgeführt, zum Teil sogar verschiedene Datenbestände in geeigneter aber nicht offensichtlicher Art zusammengeführt werden.
Bislang wurde versucht, die Problematik durch möglichst abschliessende Standardisierung der Datenmodelle bzw. der Datenformate zu entschärfen. Wenn die Definition der
Bedürfnisse und Ansprüche an die entsprechenden Daten möglich ist und der zugehörige Anwenderkreis an den 'runden Tisch' gebracht werden kann ist ein solches Vorgehen durchaus Erfolg versprechend.
In vielen Fällen ist jedoch eine umfassende Festlegung und abschliessende Standardisierung der Modelle nicht möglich oder mit unverhältnismässig grossem Aufwand verbunden:
1.1 Möglichkeiten und Grenzen der Modell-Standardisierung
Mit der modellbasierten Methode (ISO/UML/INTERLIS) steht ein Werkzeug zur Verfügung, welches eine sehr flexible Datenmodellierung ermöglicht. Die Anwendung dieses Verfahren ist weitgehend etabliert und wurde in diversen Informationsgemeinschaften zur Definition ihrer Datenmodelle in der Form von Standards verwendet (SIA 405,
AVS, VSA-DSS).
Mit den objektorientierten Konzepten, wie sie zum Beispiel in INTERLIS 2 zur Verfügung stehen, ist es nun auch möglich, Basismodelle zu spezifizieren und dann mittels
Vererbung Modellerweiterungen für spezielle Bedürfnisse vorzunehmen (vergleichbar
mit den heute praktizierten kantonalen Erweiterungen zum Bundesmodell der amtlichen Vermessung).
Ist es nun aus administrativen oder rechtlichen Gründen nicht möglich, ein umfassendes und abschliessendes Datenmodell festzulegen ergeben sich offensichtlich zwei
grundsätzliche Probleme:
x
Verschiedene Teil-Informationsgemeinschaften (z.B. Kantone) erweitern ein Basismodell um Elemente, wobei die Erweiterungen wohl oftmals denselben Inhalt
beschreiben, diesen jedoch vielleicht auf verschiedene Arten modellieren (Namen
der Klassen/Tabellen/Attribute)
x
Übergeordnete und 'verwandte' Informationsgemeinschaften (Staat, EU-Raum)
streben die Nutzung der Daten an und wollen zu diesem Zweck Standardmodelle
erstellen. Die Koordination aller Bedürfnisse der Beteiligten verursacht einen sehr
grossen Aufwand und führt entweder zu Modellen, welche dem kleinsten gemeinsamen Nenner entsprechen und damit den wenigsten gerecht werden - oder
aber alle Eventualitäten werden berücksichtigt und es entstehen Modelle mit einer
Komplexität, welche in der Praxis kaum mehr handhabbar sind.
Der Einsatz von spezialisierten Softwaresystemen im Geoinformationsbereich im Zusammenhang mit normierten Standard-Datenmodellen ist oftmals mit einigen Hürden
verbunden und häufig werden auch an sich geeignete Software-Pakete zur Erfassung,
Bearbeitung und Auswertung von Daten nicht eingesetzt, weil sie die gewünschten Datenmodelle nicht unterstützen oder diese Unterstützung mit erheblichen Kosten verbunden wäre.
11.1
Modellstandardisierung vs. semantische Interoperabilität: Aktuelles aus der Forschung
1.2 Anforderungen an ein Lösungskonzept
Wo die Einführung von Standard-Datenmodellen aufgrund administrativer, politischer,
rechtlicher und allenfalls auch technischer Randbedingungen nicht oder nur mit sehr
grossem Aufwand möglich ist, sind Ansätze gefragt, welche die Interoperabilität auch
in den Fällen sicherstellen, bei welchen die Datenmodelle der Beteiligten und deren jeweiligen Systemen nicht (genau) dieselben sind:
x
Diese semantische Interoperabilität wird mittels einer Transformation sichergestellt. Die Formulierung der Transformationsregeln für konkrete Datenmodelle ist
ein Schritt, welcher nicht oder nur sehr beschränkt automatisierbar ist
x
Die Abbildungsfunktionen zwischen verschiedenen Modellen (welche jedoch einen ähnlichen oder gleichen Sachverhalt der Realwelt beschreiben) soll wie die
Datenmodelle selbst mit einem systemunabhängigen Formalismus beschrieben
werden (im Gegensatz zu einer Formatumwandlung, welche normalerweise mit
einer Programmier-/Skriptsprache realisiert wird)
x
Die Anwendung eines solchen Formalismus soll für den Anwender und Modellierer möglichst intuitiv sein, wobei eine Unterstützung durch grafische Hilfsmittel
(analog zur Datenmodellierung mit UML) anzustreben ist
x
Anbindung von Modellierverfahren und Datenformaten, welche verbreiteten Industriestandards entsprechen, muss möglich sein und spezifiziert werden (insbesondere ISO/OGC Interoperabilitäts-Standards)
Mit einem solchen Werkzeug zur Modellierung von semantischen Transformationen
sind folgende Vorteile und Beispielanwendungen denkbar:
x
Formale Spezifikation und Visualisierung von Zusammenhängen zwischen Modellen für beteilige und verantwortliche Personen
x
Automatische Ableitung der für die Datentransformation notwendigen Programme, Skripte und Instruktionen. Denkbar sind XSLT, SQL-3, iG-Skript und weitere
x
Datenportale, welche es dem Kunden ermöglichen eigene Zielmodelle und Transformationen zu deklarieren und somit die Portalmodelle/-daten automatisch entsprechend umwandeln und ausliefern
Es wäre also wünschenswert, wenn es Softwaremittel gäbe, dank denen anspruchsvolle
Umformungen von Daten auf einfache Art definiert und entsprechend zuverlässig ausgeführt werden könnten.
11.2
Bildlich wünscht man sich folgende Situation:
Modelle der
Inputdaten
Modell der semant.
Transformation
Min-2
Min-1
Maut
Mtrf
Din-2
Din-1
TransformationsEngine
Inputdaten
Modellierung
Transformationsdef.
Modell der
veredelten Daten
Dout
Veredelte Daten
Steuerung
Datenfluss
Man könnte auch formulieren:
Mout = f(Min-1, .., Min-i)
Die Struktur der Inputdaten Din-1 bis Din-i ist durch die Datenmodelle Min-1 bis Min-i beschrieben. Diejenige der Outputdaten Dout durch das Datenmodell Mout. Die Beschreibung erfolgt mittels INTERLIS 2 oder einem anderen äquivalenten Beschreibungsmittel.
Wie aber beschreibt man die Funktion f?
2 Grundsätzliche Möglichkeiten zur Definition der
Abbildungsfunktion
2.1 Imperative Definition
In vielen Fällen werden solche Datentransformationen mittels Programmiersprachen
definiert.
In einfachen Fällen kommen Skriptsprachen (z.B. PERL) zur Anwendung. Vielfach
kommen aber auch eigentliche Programmiersprachen zum Einsatz. Man schreibt ein
Programm welches die Aufgabe löst.
2.2 Deskriptive Definition
Oftmals möchte man die Erstellung eines Programms lieber vermeiden. Beschreibungen
wären angenehmer, weil man sich bei ihrer Erstellung nicht um all die Aspekte der Implementierung kümmern muss.
Einen interessanten Ansatz in diese Richtung bilden die Sichten (Views), wie sie auch in
INTERLIS 2 vorgesehen sind.
11.3
Gegenstand eines aktuellen Forschungsprojektes IGP/ETHZ ist die Abklärung der Eignung eines Formalismus zur Beschreibung der Abbildungsfunktion unter Zuhilfenahme
der Modellierungssprache UML (Unified Modeling Language). UML bietet neben Klassendiagrammen zur Modellierung von Geodaten auch Diagrammtypen zur Beschreibung von (dynamischen) Prozessen. Damit lassen sich die Instruktionen, welche für die
Abbildung von einer Datenstruktur auf eine andere notwendig sind, in grafischer und
für den Benutzer einfach verständlicher Form beschreiben.
2.3 Beispiele dazu
2.3.1
Grunddaten
In einer Gegend gibt es – wie überall – Menschen, also entweder Frauen oder Männer.
Das – etwas vereinfachte - Datenmodell dazu:
MODEL Menschen =
TOPIC Menschen =
CLASS Mensch (ABSTRACT) =
Vorname: TEXT*30;
Name: TEXT*100;
Geburtsjahr: 1900..3000;
WohnPos: CHKoord;
END Mensch;
CLASS Frau EXTENDS Mensch =
END Frau;
CLASS Mann EXTENDS Mensch =
END Mann;
END Menschen;
END Menschen.
Nun sollen mögliche Paare gebildet und diese als Daten ausgewiesen werden.
Für die Paare ergibt sich folgendes Modell:
MODEL Paare =
TOPIC Paare =
CLASS Paar =
VornameMann: TEXT*30;
NameMann: TEXT*100;
GeburtsjahrMann: 1900..3000;
VornameFrau: TEXT*30;
NameFrau: TEXT*100;
GeburtsjahrFrau: 1900..3000;
END Paar;
END Paare;
END Paare.
11.4
2.3.2
Full-Join (kartesisches Produkt)
Ist man an allen möglichen Paaren interessiert, müsste man folgende Transformation
definieren:
TRANSFORMATION MODEL AllePaare =
IMPORTS Menschen, Paare;
VIEW Paar
JOIN OF M ~ Menschen.Menschen.Mann,
F ~ Menschen.Menschen.Frau;
=
VornameMann: TEXT*30 := M->Vorname;
…
VornameFrau: TEXT*30 := F->Vorname;
END Paar;
MAP Paar TO Paare.Paare.Paar;
END AllePaare.
Eine vergleichbare imperative Definition hätte etwa folgendes Aussehen:
loop M := alle Menschen.Menschen.Mann
loop alle F := Menschen.Menschen.Frau
VornameMann := M->Vorname;
VornameFrau := F->Vorname;
Paare.Paare.Paar kreieren
Attribute darauf kopieren
end
end
Der Unterschied ist offensichtlich relativ klein.
2.3.3
Equi-Join
Ist man an allen Paaren interessiert, bei denen beide Partner im gleichen Jahr geboren
sind, müsste man die Transformation leicht ergänzen:
TRANSFORMATION MODEL GleichaltrigePaare =
VIEW Paar
WHERE M->Geburtsjahr == F->Geburtsjahr;
=
…
END Paar;
END GleichaltrigePaare.
11.5
Analog könnte man in der imperativen Definition schreiben:
loop alle F := Menschen.Menschen.Frau
if M->Geburtsjahr == M->Geburtsjahr then
end
end
end
Es ist aber offensichtlich, dass dies bei sehr grossen Datenmengen zu erheblichem Aufwand führt, auch wenn die Ergebnismenge (also die gefundenen Paare) relativ klein ist,
da nur die gleichaltrigen Menschen als Partner in Frage kommen. Bei jedem Mann werden alle Frauen angeschaut und dann auf Gleichaltrigkeit geprüft.
Dies führt zu M * F Vergleichsoperationen.
Würde man eine Hilfsstruktur aufbauen, dank der alle Frauen mit einem bestimmten
Geburtsjahr effizient gefunden werden können, könnte das Programm ungefähr so aussehen:
HF := ErzeugeHilfsstruktur (Menschen.Menschen.Frau,
Geburtsjahr)
loop alle F := HilfsstrukturAuswahl(HF, M->Geburtsjahr)
end
end
Der Laufzeitaufwand würde damit im Prinzip auf M * log(F) sinken und damit auch die
Bearbeitung grosser Datenmengen erlauben.
Eigentlich möchte man sich im Rahmen der Definition einer semantischen Datentransformation aber nicht um solche Aspekte der Implementierung kümmern. Die deskriptive Form ist darum vorteilhafter. Allerdings hat sie den Nachteil, dass man dem Transformationsverfahren einiges aufbürdet, wenn es auf Grund der WHERE-Bedingung erkennen muss, dass es Optimierungsmöglichkeiten gibt.
Das folgende Beispiel macht dies noch deutlicher.
11.6
2.3.4
'Near' - Join
Es besteht ein Interesse an allen Paaren, bei denen die Partner nicht weiter als einen Kilometer entfernt wohnen.
TRANSFORMATION MODEL UmkreisPaare =
FUNCTION Distanz(P1: CHKoord; P2: CHKoord): NUMERIC;
VIEW Paar
WHERE Distanz(M->WohnPos, F->WohnPos) < 1000.0;
=
…
END Paar;
END UmkreisPaare.
Wie soll das Transformationsprogramm hier eine Optimierungsmöglichkeit erkennen?
Würde man jedoch spezielle Definitionen einführen, bei welchen der Bezug zu den
Grundmengen erkennbar ist und die im Rahmen einer WHERE-Bedingung eingesetzt
werden können, wäre dies wieder einfach:
TRANSFORMATION MODEL UmkreisPaare =
FUNCTION InnerhalbDistanz
(Basis1: CLASS; P1Attr: ATRIBUTE;
Basis2: CLASS; P2Attr: ATTRIBUTE;
MaxDistanz: NUMERIC): BOOLEAN;
VIEW Paar
WHERE InnerhalbDistanz(M, WohnPos,
F, WohnPos, 1000.0);
=
…
END Paar;
END UmkreisPaare.
11.7
2.3.5
'Nearest' - Join
Ist man noch restriktiver bei der Paarbildung und bildet Paare nur zwischen der Frau,
die am nächsten bei einem Mann wohnt oder umgekehrt, bleibt die Transformationsbeschreibung sehr ähnlich.
TRANSFORMATION MODEL NachbarPaare =
FUNCTION KuerzesteDistanz
(Basis1: CLASS; P1Attr: ATRIBUTE;
Basis2: CLASS; P2Attr: ATTRIBUTE): BOOLEAN;
VIEW Paar
WHERE KuerzesteDistanz(M, WohnPos,
F, WohnPos);
=
…
END Paar;
END NachbarPaare.
Will man die Transformation imperativ beschreiben, ist es offensichtlich, dass die Lösung recht anspruchsvoll ist, wenn sie auch bei grossen Mengen zu vernünftigen Laufzeiten führen soll.
2.4 Forschungsprojekt 'Neue Ansätze zur konzeptionellen
Beschreibung semantischer Transformationen'
2.4.1
Ausgangslage
Vorgängig wurden die Grundlagen für den Einsatz von Views, welche die Abbildung
von einer Ausgangsdatenstruktur auf eine Zieldatenstruktur leistet, ausführlich eingeführt. Für einen Anwender, welchem dieses Verfahren nicht aus der Datenbank-Welt
vertraut ist, sind solche Abbildungsdefinitionen nicht ganz einfach zu verstehen und
nachzuvollziehen. Darüber hinaus ist eine intuitive grafische Darstellung, welche den
gleichen Sachverhalt der Transformation wiedergibt, schwierig zu erreichen.
2.4.2
Zielsetzung: grafische Notation und daran angelehnter Formalismus
Neben dem Diagrammtyp 'Klassendiagramm' stellt die grafische Modellierungssprache
UML auch weitere Diagrammtypen zur Verfügung, welche die Erstellung von Modellen
für Prozesse ermöglicht. Da jedoch mit diesen Mitteln die Transformation von Modellen
nicht vollständig ausgedrückt werden kann, muss das Repertoire von UML zu diesem
Zweck erweitert werden. Bei der OMG (Object Management Group), welche für die
Weiterentwicklung von UML zuständig ist, wurde bereits ein Vorschlag für entsprechende Modellierungselemente eingereicht (MOF Query/Views/Transformations;
UMLX)
11.8
Für die Darstellung der semantischen Transformation von Geodaten müssen die geeigneten Diagrammelemente evaluiert und um notwendige Erweiterungen ergänzt werden. Die Anpassung der UML-Symbolik für eine Anwendungsdomäne (Geoinformatik)
nennt man auch UML-Profil. Eine Modelltransformation könnte dann wie folgt dargestellt werden:
Da grafische Darstellungen wie UML nicht direkt maschinell verarbeitbar sind, muss in
Ergänzung dazu ein textueller Formalismus geschaffen werden. Die Realisierung kann
zum Beispiel als Erweiterung von INTERLIS 2 erfolgen. Für Transformationen, bei welchen der mengenorientierte Zugriff ausreicht, können die Abbildungsvorschriften auch
mittels Views repräsentiert werden.
2.4.3
Implementierung der Transformationsmodelle
Mit der Formulierung von Modellen und Transformationen auf konzeptioneller Ebene
erhalten wir den 'Werkzeugkasten', mit welchem wir die semantische Interoperabilität
erreichen können. Wir sind damit nicht an ein konkretes GIS-System bzw. Transformationssoftware mit eigener Programmier-/Skriptsprache gebunden.
Ebenso wie wir mit INTERLIS unabhängig vom Transferformat sind (XML, GML, ITF),
lassen sich die Transformationsvorschriften in eine konkrete Transformations- bzw.
Programmiersprache, welche für eine bestimmte Anwendung ideal geeignet ist, umsetzen. Denkbar wären z.B. SQL, XSLT, XQuery, iG-Skript, FME usw.
Ähnlich wie die Kommunikation der am Daten-Modellierungsprozess beteiligten Experten durch konzeptionelle und grafische Mittel wie UML stark verbessert wird, macht es
Sinn, die Zusammenhänge und Transformationen zwischen verschiedenen Datenmodellen (ähnlicher oder gleicher Themenbereiche) explizit zu formulieren. Dies kann mit
einer Programmiersprache allein nicht sinnvoll geleistet werden.
2.5 Folgerungen
Die deskriptive Definition einer semantischen Transformation hat zweifellos Vorteile,
denn sie trennt zwischen Definition und Implementierung.
Um die Ansprüche an die Transformationsprogramme nicht a priori hoch zu schrauben
oder das Risiko einzugehen, dass Optimierungsmöglichkeiten kaum genutzt werden,
macht es Sinn, die Formulierung spezieller Bedingungen durch spezielle Operationen
zu unterstützen. Für solche Operationen ist in den Transformationsprogrammen explizit
entsprechender Code vorzusehen. Es ist aber den Transformationsprogrammen überlassen, inwiefern sie die Optimierungen auch realisieren.
11.9
3 Ein Blick auf INTERLIS 2
Wer INTERLIS 2 präsent hat, hat festgestellt, dass die Sichten 'AllePaare' und 'GleichaltrigePaare' mit den heutigen INTERLIS 2 – Mitteln formulierbar sind.
Für die Sichten in den Modellen 'UmkreisPaare' und 'NachbarPaare' sowie für eine
durch den Transformator leicht erkennbare 'GleichaltrigePaare'-Sicht ist es nötig INTERLIS 2 um View-Operatoren zu ergänzen. Es kann dazu ein ähnlicher Ansatz verwendet werden wie bei den bereits vorhandenen INTERLIS-Funktionen.
Mit einem Zusatz muss dafür gesorgt werden können, dass aus einer Sicht Objekte gemäss einer Klasse eines Modells erzeugt werden können.
x
Mit einem bescheidenen Ausbau von INTERLIS 2 kann die semantische Datentransformation mittels INTERLIS 2 beschrieben werden.
Die genaue Definition ist noch Gegenstand eines gemeinsamen Projektes.
4 Hauptvorteile
4.1 Kommunikation zwischen Menschen
Mit INTERLIS wurde nebst dem eigentlichen Datentransfer eine gemeinsame Sprache
geschaffen, damit sich Menschen möglichst präzis über die Struktur von Daten unterhalten können.
Ähnlich könnte mit einem solchen Ansatz auch ein generelles Verständnis aufgebaut
werden, wie man Transformationen von Daten beschreibt.
Wie bei den Datenmodellen dürfte es auch bei den Datentransformationen teilweise anspruchsvoll sein, die besten geeignete Definition zu finden. Eine gemeinsame Sprache
leistet dabei aber wichtige Dienste.
4.2 Nutzen für Prozessoren
Andere Tools
UML-Editor
I2Modelle
Andere Quellen der
Definition von
Modellen und
Transformationen
I2-Compiler
Modelle
in XML
Inputdaten
11.10
Transformator
Outputdaten
Der Transformator ist abstrakt gehalten und hat folgende grundlegenden Fähigkeiten:
x
Ist in der Lage Daten zu verarbeiten, die INTERLIS 2 – Datenmodellen entsprechen und kann somit recht anspruchsvolle Datenmodelle unterstützen.
x
Ist in der Lage auf eingelesenen Daten mit INTERLIS 2 definierte Sichten aufzubauen und modellbasierte Datentransformationen auszuführen.
Dabei kann davon ausgegangen werden, dass einfache Datentransformationen direkt
mit einer leicht erweiterten INTERLIS 2 – Beschreibungen definiert und ausgeführt
werden können. Ähnlich zu den in INTERLIS 2 vorgesehenen Funktionen, wird man
jedoch für anspruchsvollere Abbildungen spezifische Operatoren zur Bildung von Sichten definieren und entsprechend im Transformator codieren.
Die INTERLIS 2 – Modelle (inkl. Transformation) können mit dem UML-Editor oder
anderen Werkzeugen erstellt werden und mit dem INTERLIS 2 – Compiler in ein noch
definitiv festzulegendes Format (z.B. in INTERLIS 2 oder XMI) gebracht werden. Alternativ ist es auch möglich, solche Modell- und Transformationsbeschreibungsdaten mit
anderen Werkzeugen (unabhängig von INTERLIS) direkt zu erzeugen. Diese Modellund Transformationsdefinitionen werden durch den Transformator gelesen. Damit ist
dem Transformator bekannt, wie die Inputdaten zu Outputdaten veredelt werden müssen.
Durch diese klare Trennung der einzelnen Komponenten besteht eine hohe Anpassungsfähigkeit an verschiedene Bedürfnisse, die sich aus konkreten Systemsituationen
ergeben.
11.11
12
Datenmigration UIC
Théophil Engel, UIC / SBB
Théo Engel, Dr.
SBB-Infrastruktur-Asset Management, Programmanager Fahrstrom
Schanzenstrasse 5
CH-3000 Bern 65
Tel :
Fax :
E-Mail :
+41 51 220 21 80
+41 51 220 39 19
1 Umfeld
1.1 Übersicht
1.1.1
Einstieg
Der Gleisbau stützt sich schon lange auf Koordinatentrassen. Seit den 90er Jahren sind diese
auch als Grundlage des systematischen Gleisunterhalts im Einsatz und bringen dort bedeutende
finanzielle, technische, allgemein anerkannte Vorteile. Numerische Gleiskoordinaten sind
auch die Basis einer erhöhten Interoperabilität aller Infrastrukturanlagen, sowie dank der, von
der europäischen Union postulierte Harmonisierung der Koordinatenreferenzen, landesgrenzenüberschreitend, eine Grundvoraussetzung ist für erfolgreiche, neue Anwendungsfelder wie z.B.
die satellitenbasierte Navigation der Züge.
1.1.2
Vierzehn Kernsätze
1 Koordinatenbasierte, absolute Gleisedefinition (CNTD) als Grundlage des modernen Gleisbaus
und Gleisunterhaltes //2 UIC-Projekt GEORAIL: Ein weiterer Konsolidationsschritt auf dem
Weg der Einführung absoluter Koordinaten bei der Eisenbahn //3 Definition Bahngeodäsie,
CNTD //4 Die wichtigsten Grundsätze im Umgang mit diesen Kerndaten der Infrastrukturanlagen //5 Wirtschaftliche und technischen Vorteile absoluter Koordinatentrassen //6 Bedeutung des
Optimierungspotentials dank absoluten Trassenkoordinaten auf der Prozessebene //7 Umfassende Lösung bedingt grenzüberschreitende Sicht //8 Fundierte Vertiefung zu Fragen der Koordinatenreferenz, Datenstandardisierung sowie Datenschnittstelle //9 Ansprechpartner von Georail
Phase 2: Gleisbaufirmen, Eurogeographics (Europäische Landesvermessungsämter), Forschung,
Gleisbauliteratur //10 UIC interne Absprache mit Projekt Track Machine Guidance //11 Dialog
UIC ņ Eurogeographics. Ansprechsstelle Eisenbahn für die Eurogeographics? //12 Folgearbeit
auf Steuerebene: UIC-Merkblatt mit Leitbildcharakter //13 Folgearbeit Technik: Nationale Bahnreglemente und dritte Auflage des Buches „Eisenbahnbau – Wichmann Verlag, 2006-7 //14 Weiterführung des Georail Gedankengutes durch UIC-Track-Expertengruppe?
1.1.3
Ziel von GEORAIL und Inhalt des Berichtes
Klärung der Grundsatzfragen zum Einsatz von absoluten Koordinaten für die Eisenbahn. Skizzierung erster Überlegungen, die im Umgang mit Koordinaten der Förderung
der Interoperabilität aller Objekte der Infrastruktur dienen.
Das erste Kapitel gibt Einblick in die Thematik Koordinaten bei der Eisenbahn mit
Schwergewicht Gleisanwendungen. Das zweite Kapitel reflektiert die wichtigsten Resultate, welche im Rahmen des UIC-Projektes bezüglich der Frage der semantischen Transformation. Das dritte Kapitel zeichnet die weiterführende Stossrichtung auf.
1.2 Historische Entwicklung
Die koordinatenbasiert, kontinuierlich-numerische Trassendefinition, CNTD (engl., continuous numeric track definition) hat sich in den 90er Jahren als Basis der Gleisarbeiten
durchgesetzt. Grosse Bahnnetze planen deren Einführung oder haben sie bereits hinter
sich. Die Gleismaschinenindustrie steuern damit Gleisbaumaschinen.
Die Schlüsselwörter wirtschaftlicher Gleisarbeiten sind: Einfache Nutzung, (bahn-)
netzweite Einheitlichkeit, operative Präzision und Zuverlässigkeit, keine Spezialtricks
bei der Anwendung. Daraus ergeben sich zwei geodätische Herausforderungen:
12.1
Datenmigration UIC
-
Die Harmonisierung der heute europaweit heterogenen, geodätischen
Grundlagen.
Die Abbildung des (globalen) räumlichen Gleisverlaufs auf die ebenen Pläne.
In der UIC (Union internationales des chemins de fer) sind Gleisarbeiten das Kerngeschäften des „Track Expert Group“. Klassisch kennen sie keine Koordinaten. Erste Beiträge für den Einsatz von Koordinaten in den Gleisarbeiten kommen von der Gruppe
6.4 „Track and utility lines“ der FIG (Fédération Internationale des Géomètres). FIG 6.4
postuliert den Kontakt zu den Bahnspezialisten: Die Führung gehört langfristig nicht
zur FIG, sondern zur UIC. Der Übergang erfolgt schrittweise:
1990 – Entscheid der FIG zum Einstieg in die Thematik Bahngeodäsie.
1996 – Die Präsidenten der FIG und der UIC erstellen einen ersten Kontakt.
2000 – Die „Track Expert Group“ der UIC übernimmt die Leitung des Koordinatenprojektes zur Steuerung der Gleisbaumaschinen unter der Führung der schwedischen Bahnen (BV).
2002 – Beginn des UIC Projektes Georail. Abschluss des FIG Engagements.
2004 – Erste „Open Rail Session“ unter dem Patronat der UIC.
Nebst den Bahnprojektpartnern sind folgende Bereiche in Georail involviert:
-
-
ExG-G (expertgroup geodesy, Arbeitsgruppe Geodäsie) von Eurogeographics als Vertreter der europäischen Landesvermessungsverwaltungen.
In Abstimmung mit der EU-Kommission, legen sie in den 90er Jahren
ETRS89 als europäische Koordinatenbasis fest.
ISO/TC211 und CEN/TC287 im Bereich der Datenstandardisierung.
Die Vertreter der Gleisbaumaschinenindustrie Plasser-Theurer und Müller
AG.
Die Forschung, vertreten durch das Institut für Geodäsie der ETH Zürich
Die Eisenbahnbauliteratur durch die Hauptverfasser des Buches „Eisenbahnbau“ (G. Müller, Wichmann Verlag, 2000) der Hochschule für Technik
und Wirtschaft in Dresden
1.3 Einige Grundbegriffe
CNTD oder Continuous, Numeric Track Definition ist der englische Begriff für absolute
Gleistrassierung auf der Basis von Koordinaten.
CNTD beschreibt die 3-dimensionale Gleisgeometrie mit mathematisch exakt definierten Elementen, die nahtlos aneinandergeknüpft, die Gleise an jedem beliebigen Punkt in
Lage, Höhe und Überhöhung beschreiben.
Nebst CNTD bilden folgende Elemente die Basis der Bahngeodäsie:
-
-
-
12.2
Die Ordnungsdaten als Schlüssel für die Datenabfrage und –
Strukturierung, in Form von eineindeutigen numerischen Streckentrassen.
Netzweit gruppiert, bilden diese, „KM-Achsen“ genannten Trassen, die Streckennetze der Eisenbahngesellschaften.
Die geodätischen Referenzpunkte. Über diese Punkte sind die Bahndaten
am absoluten Koordinatensystem angebunden. Diese Punkte beinhalten
auch die Funktionalität der Gleisvermarkung, was zu den, im folgenden Abschnitt beschrieben, Vorteilen führt.
Die Trassenpunkte und die kritischen Punkte des Lichtraums, welche der
Trassenrechnung zugrunde liegen.
Datenmigration UIC
Bahngeodäsie ist ein Teilfachgebiet der Ingenieurvermessung, das alle Geoinformationen für die topologische Datenstrukturierung, Verwaltung und interdisziplinäre Nutzung numerischer Gleistrassen liefert und die damit zusammenhängenden Verfahren
beinhaltet.
Die KM-Achsen bilden den Kern der hierarchisch strukturierten, koordinatengebundenen Daten der Infrastruktur (Abb. 1.1). Das zweite Niveau um den Kern, beinhaltet die
Gleisdaten. Sie werden von allen Fachdiensten benötigt. Die dritte Schicht umfasst die
wichtigsten Daten der Fachdienste welche auch von den anderen Bereichen benutzt
werden und das letzte Niveau beinhaltet die Daten, deren Interessen auf den Fachdienst
beschränkt sind.
Diese Strukturierungsart erlaubt es, den Datenzugriff mittels zwei Koordinatenwerten
durch eine eindimensionale Abfrage über einen KM-Wert zu ersetzen, was einer beträchtlichen Vereinfachung bezüglich der Organisation der Abfragealgorithmen gleichkommt.
Koordinatenreferenzierte Infrastrukturobjekte,
aufgebaut nach dem Schalenmodell:
Kern: Das Streckennetz mit Knoten (die Betriebspunkte) und Kanten (die Strecken)
Erste Schale:
Das Gleisnetz
Zweite Schale: Die Kern-Fachdienstdaten.
Dritte Schale: Fachdienstdaten mit limitiertem
Interesse
CNTD: Geodätische Referenzpunkte sowie die
Daten von Kern und erster Schale des Schalenmodells
Abb. 1.1 : Hierarchisches Schichtenmodell der koordinatenbasierten Daten der Infrastruktur
1.4 Technische Entwicklung
Die Entwicklung von CNTD ist das Resultat der engen Zusammenarbeit von Fachleuten
aus Vermessung, Bahndienst und Informatik. Die CNTD Entwicklung begann im operativen Tagesgeschäft der Eisenbahn nach dem „vom Benutzer für den Benutzer“ - Modus.
Drei Jahrzehnte charakterisieren die Entwicklung wie folgt:
-
80er Jahre: Verschiedene Einzelentwicklungen im Bottom-up Verfahren.
90er Jahre: Verschiedene Konsolidierungsphasen bei den Bahnen, aber ohne
grenzüberschreitende Koordination.
Ab 2000: Operative Reife der Systeme mit Erhöhung der Wirtschaftlichkeit
im Gleisbereich. Erste internationale Abstimmungsbestrebungen.
Die Optimierung auf Prozess- und Organisationsebene ist der nächste, wichtige Entwicklungsschritt.
CNTD setzt den Methoden der bisherigen, relativen Gleistrassierung ein Ende.
Diese alten Methoden beruhen alle auf dem Pfeilhöhenprinzip. Mit einer gespannten
Schnur zwischen zwei Bezugspunkten, misst man die Pfeilhöhe eines Kurvenabschnittes und vergleicht ihn mit einem theoretischen Wert. Ab 1940, beginnen die Bahnen, die
12.3
Datenmigration UIC
Kurven ihres Netzes auf diese Art zu unterhalten. Senkrecht, einen Meter neben den
Gleisen, alle 20m eingeschlagene Gleisstücke, sind die Bezugspunkte der Gleistrassierung, nachfolgenden Vermarkungspunkte genannt. Die zwischen den Kurven liegenden Geraden werden in der Regel nicht vermarkt.
Erste Impulse für den Wechsel kommen:
-
Von der Gleisbaumaschinenindustrie, welche im Bereich der Automatisierung der Maschinensteuerung entscheidende Fortschritte macht.
Von den Bahnen welche beginnen, koordinatenbasierte, numerische Gleistrassen zu rechnen.
Der Durchbruch erfolgt, durch das Zusammenlegen der Funktionalitäten „Vermarkungspunkt“ und „geodätischer Fixpunkt“. Die Gleismaschinen können, dank den
Fortschritten der automatischen Gleisbaumaschinensteuerung und den koordinatenmässig definierten Vermarkungspunkten, für jeden Gleispunkt in Echtzeit die IST-Lage
des Gleises bestimmen, sowie die Differenz zwischen der effektiven Gleislage und der
theoretischen Soll-Lage. Das Resultat dient als Steuerwert der Gleismaschinen, dessen
Ermittlung automatisch aus folgenden Grunddaten ermittelt wird:
-
Die koordinatenmässig definierten Vermarkungspunkte,
Die kontinuierlich gerechneten, theoretischen Koordinatentrassen,
Die netzweit homogenen, eineindeutigen Koordinatenreferenz,
Die automatisiert ermittelte IST-Lage der Gleise.
Die einführend aufgeführten Grundbedingungen für den automatisierten Einsatz der
Gleismaschinen für den systematischen Unterhalt sind somit vollständig erfüllt: Einfache Nutzung, bahnnetzweite Einheitlichkeit, operative Präzision und Zuverlässigkeit,
Keine Spezialtricks bei der Anwendung
Dieser Automatisierungsprozess funktioniert heute in der Praxis des Gleisunterhaltes
unterschiedlich.
-
-
Für Vermarkungspunkte die als geodätische Messpunkte materialisiert, auf
den Fahrleitungsmasten fixiert sind, ist die Methodik voll operativ und ausgereift.
Die Variante, wo nur noch mit Satellitenpositionierung gearbeitet wird, ist
heute erst im Aufbau. Anstelle einer Vermarkung entlang des Gleises gibt es
nur noch alle 2 km einen, mit GPS bestimmten, geodätischen Referenzpunkt
in Gleisnähe. Heute noch nicht gelöste Probleme sind:
¾ Keine GPS-Signale in den Schattenzonen (z.B. in Tunnels, bei abgedeckten Bereichen der Bahnhöfe, ...).
¾ Unzureichende Präzision für kritische Netzteile, z.B.: Komplexe Weichenverbindungen – häufig die Ein- und Ausfahrten grösserer Bahnhöfe
– feste Fahrbahn und vor allem alle Strecken wo Hochgeschwindigkeit
gefahren wird. Dort müssen repetitiv Absteckgenauigkeiten im mmBereich sichergestellt werden können, währenddem Werte in der Regel
±5mm betragen, um die Vorteile der absoluten Koordinatentrassen voll
nutzen zu können.
Die treibende Kraft zur Harmonisierung der Koordinatenreferenz kommt im Gleisbereich von den Bedürfnissen der Satellitenpositionierung, wo höchste Genauigkeiten nur
über völlig spannungsfreie Netze erreicht werden können.
12.4
Datenmigration UIC
1.5 Gewinnfaktoren
Erhöhung der Qualität der Gleislage
Erhöhung der Wirtschaftlichkeit
Datenhierarchie
Funktionale Optimierungen: Prozesssupport
Zusammenfassend: Katalysierender Effekt und Synergien dank Koordinaten
2 Semantische Transformation
Die im zweiten Kapitel beschriebenen Arbeiten, wurde von der ETH Zürich im Rahmen
der UIC-Projektes Georail erbracht.
2.1 Modellierung der Ordnungsdaten
Grundlage für die Modellierung der Ordnungsdaten bilden die Streckenübersichtsdaten
aus der Datenbank der festen Anlagen (DfA) sowie ergänzende Betriebspunktdaten.
Aus diesem relevanten Realitätsausschnitt wird mit der textuellen CSL INTERLIS ein
konzeptionelles Schema erstellt.
2.2 Standardisierung der Ordnungsdaten-Schnittstelle
Mit dem „Compiler“ wird das textuelle Schema geprüft. Sobald diese Konsistenzprüfung fehlerfrei abläuft, wird daraus die Beschreibung des Transferformats (physisches
Schema) erstellt. Im vorliegenden Beispiel wird das INTERLIS-Transferformat ITF verwendet. Analog kann jedoch auch das XTF- oder GML-Transferformat erzeugt werden.
Das physische Schema enthält die Information, welches wie die Transferdatei strukturiert sein muss.
Entsprechend diesem Standardformat werden die Ausgangsdaten nun umstrukturiert.
In den meisten Fällen genügt dazu eine einfache Programmier- oder Skriptsprache, zum
Beispiel awk. Awk ist eine einfache Skriptsprache auf Basis der Mustererkennung, mit
deren Hilfe ASCII-Dateien systematisch auf das Standardformat umgebaut werden
können.
2.3 Visualisierung der Strecken- und Stationsdaten mit Geo-Shop
Die SBB-Streckendaten liegen nun im systemunabhängigen INTERLIS-Transferformat
(ITF) vor. Sie können mit einer Software, welche INTERLIS unterstützt, visualisiert
werden. Im Folgenden wird dafür „GeoShop“ verwendet, eine Software, welche auf
systemneutralen Standards basiert (https, Java, INTERLIS). Sie ermöglicht die Bearbeitung von Geodaten unterschiedlicher Struktur (insbesondere die Visualisierung, die
Verbreitung sowie der Verkauf dieser Daten) über das Intra- oder Internet. Geoshop besteht aus 3 Modulen:
-
-
Geoshop Server: Dieser zentrale Teil des Programms verwaltet die Geodaten
sowie die Benutzerinformationen
Geoshop Client Tools: Sie ermöglichen die Visualisierung und Verbreitung
der Daten, wobei vom Kunden einzig ein Java-fähiger Webbrowser benötigt
wird.
Geoshop Administrator Tools: Sie steuern die Konfiguration des Servers, den
Status von Benutzern und Bestellungen sowie die Darstellung der Geodaten.
12.5
Datenmigration UIC
2.4 Modellierung der Fachdienst-Daten: FahrleitungAE
In einem nächsten Schritt geht es darum, den Inhalt von nicht verknüpften Datenbanktabellen mit Hilfe der modellbasierten Methode gemeinsam nutzbar zu machen, vorausgesetzt beide Tabellen enthalten mindestens ein gemeinsames Attribut. Als Beispiel
wird für die Fahrleitungsinformationen der SBB, welche zu den Fachdienst-Daten gehören, aus den Streckenübersichtsdaten die Geometrie hergeleitet.
Die Informationen zu den Fahrleitungen sind in einer Excel-Tabelle enthalten, wobei
jede Zeile einem Fahrleitungsabschnitt entspricht. Die Tabelle enthält für jeden Fahrleitungsabschnitt Attribute, beispielsweise das Erstelektrifizierungsjahr. Obwohl die Fahrleitungen einen eindeutigen Raumbezug aufweisen, sind in der Tabelle keine Koordinaten enthalten. Einzige räumliche Attribute bilden die Kilometrierungswerte (km von,
km bis), welche jeweils Anfang und Ende eines Fahrleitungsabschnittes repräsentieren.
Die Kilometer-Achsen der Streckenübersichtsdaten sind meist in mehrere Fahrleitungsabschnitte unterteilt, welche jeweils aus einer Vielzahl von minimalen Streckenabschnitten bestehen.
Baujahr Fahrleitung
BPK von
Linie von
Fil von
LinieKorr
km von
Lausanne 100
100
West
Lausanne
0.0000
St-Maurice 100
100
West
St-Maurice
51564.9400
Sion 100
100
West
St-Maurice
92432.0600
Brig 100
100
West
Brig
145548.5000
Brig Tunnel 109
109
West
Brig
147149.9000
Vevey Ouest (bif) 111
111
West
Lausanne
762.5000
BPK bis
Linie bis
LinieKorr
km bis
Jahr 1. El.
St-Maurice 100
100
St-Maurice
51564.9400
1924
Sion 100
100
St-Maurice
92432.0600
1923
Brig 100
100
Brig
145548.5000
1919
Iselle di Trasquera 100
100
Brig
167478.3100
1906
Iselle portail tunnel 109
109
Brig
166973.4000
1922
Puidoux-Chexbres 111
111
Lausanne
7829.0000
1940
Abb. 2.1 : Auszug aus der Exceldatei der Fahrleitungsdaten
Die Herleitung von Fahrleitungsdaten und ihrem Verlauf aus Fahrleitungsdaten, die
nur Anfangs- und End-Kilometrierungswerte enthalten, und aus Ordnungsdaten mit
geometrischem Verlauf, ist ein typisches Beispiel für eine semantische Transformation.
Zunächst ist die Ausgangsklasse der Fahrleitungsdaten mit UML und INTERLIS zu beschreiben. Das gibt eine UML-Klasse „FahrleitungAE“ und eine INTERLIS-Klasse
„Fahrleitung“.
12.6
Datenmigration UIC
2.4.1
Standardisierung der Fachdienst-Schnittstelle: FahrleitungAE
Aus dem INTERLIS-Modell kann automatisch die Formatbeschreibung für die Klasse
„FahrleitungAE“ bestimmt werden. Mit einem 1:1 Prozessor werden die Daten der Excel-Tabelle umgebaut auf das Standardformat ITF.
2.4.2
Modellierung der Fachdienst-Daten: Fahrleitung (mit Verlauf)
Als Zieldatei der semantischen Umformung wollen wir die einfache Klasse „Fahrleitung“ mit nur zwei Attributen definieren: Das Attribut „Erstelektrifizierung“, das aus
der Klasse „Fahrleitung “ übernommen wird, und das Attribut „Verlauf“ vom Typ POLYLINE, das neu berechnet wird aus den Attributen „km_von“ und „km_bis“ der Klasse „Fahrleitung“ und aus dem Attribut „Verlauf“ der Klasse „Achse“. Das UMLDiagramm dieser neuen Klasse „FahrleitungAE“ finden wir in Abb. 2.2, ihr INTERLISDatenmodell in Abb. 2.3.
Fahrleitung
Erstelektrifizierung
Abb. 2.2 : Graphisches Datenmodell neue Klasse „Fahrleitung“ (UML-Diagramm)
TABLE Fahrleitung =
Erstelektrifizierung: [1900 .. 2500];
Verlauf: POLYLINE WITH (STRAIGHTS, ARCS) VERTEX Koord2
WITHOUT OVERLAPS > 0.50000;
NO IDENT
END Fahrleitung;
Abb. 2.3 : Neue Klasse „Fahrleitung“ (mit Verlauf), INTERLIS-Modell
2.4.3
Semantische Transformation
Jetzt stehen zur Verfügung: Die Datenmodelle in INTERLIS der Ausgangsdateien „Achse“ (aus 2.4.1) und „FahrleitungAE“ (aus 2.4.2) sowie diejenigen der Zieldatei „Fahrleitung“ (aus 2.4.3) und ferner die Daten von „Achse“ und „Fahrleitung“ im Standardformat ITF von INTERLIS.
Es gibt Software-Werkzeuge, wie das INTERLIS-Conversion-System ICS, die es erlauben, auf konzeptioneller Ebene den Umbau von zwei (oder mehr) gegebenen Klassen in
eine neue Klasse (oder mehrere) zu definieren mit Hilfe der beteiligten Datenmodelle
und mit geeigneten Umbaufunktionen. Die Umbaufunktion die wir brauchen heisst:
Aus den Linien von Klasse „Achse“ Stücke ausschneiden vom Anfangspunkt „km_von“ bis zum
Endpunkt „km_bis“ eines Objektes aus der Klasse „FahrleitungAE“, und diesen Linienausschnitt zusammen mit dem Wert des Attributes „Jahr_erste_Elektrifizierung“ aus der Klasse
„FahrleitungAE“ abspeichern als neues Objekt der Klasse „Fahrleitung“.
12.7
Datenmigration UIC
[……]
TABL Fahrleitung
OBJE
0.0000.0100 1924
STPT 537875.40604 152041.99120
LIPT 537984.59908 152018.12626
ARCP 538041.11107 151980.47901
[..]
ARCP 566299.34338 118421.92351
LIPT 566299.35779 118418.30702
ELIN
[.....]
OBJE
1763.3040.7744
1925
STPT 681720.79964 248756.00813
LIPT 681721.16279 248758.52014
ARCP 681761.91402 248844.22701
[..]
LIPT 683823.44151 247149.25542
LIPT 683786.02309 247064.53648
0.000
-263.000
ELIN
ETAB
[……]
Abb. 2.4 : Auszug aus der ITF-Datei der neuen Klasse „Fahrleitung“ (mit Verlauf)
2.4.4
Visualisierung der Fahrleitungsdaten (mit Verlauf) im Geo-Shop
Diese ITF-Datei der neuen Klasse „Fahrleitung“ (mit Verlauf) kann als Input für den
„GeoShop“ verwenden. Bei der Visualisierung im „GeoShop“ werden die einzelnen Altersklassen der Fahrleitungsdaten unterschiedlich eingefärbt (Abb. 2.5).
12.8
Datenmigration UIC
Abb. 2.5 : Visualisierung der Fahrleitungen im Geoshop (mit Legende)
3 Zukunft
3.1 Wie weiter? Leitgedanken
3.1.1
Datenrichtigkeit
Voll nutzbar sind koordinatenbasierte Daten nur dann, wenn in allen Bereichen alles
stimmt: Koordinatenreferenz, Datenstruktur, Datenvollständigkeit, Datenrichtigkeit,
Datenkonsistenz, Datentopologie, Netzsicht 100%.
3.1.2
Harmonisierung der Datenstrukturen generell
Harmonisierung von Datenstrukturen als Grundelement des Zusammenpassens von
Daten ist das Fundament der Interoperabilität. Die Umsetzung dieser Aufgabe europa-
12.9
Datenmigration UIC
weit sicherzustellen ist eine Kernaufgabe der UIC. Ausgegangen muss immer von den
heutigen, EDV-mässig bereist im Einsatz stehende Datenstrukturen der einzelnen Bahngesellschaften. Langfristziel ist, eine, von der UIC verabschiedete und von den Bahnen
getragene, europaweite, harmonisierte Datenstruktur. Der Einsatz einer einheitlichen
Software ist ein erster konkreter Harmonisierungsschritt.
3.1.3
Harmonisierung der Datenstrukturen in angrenzenden, nicht abgestimmten
Zonen
In Grenzgebieten, wo unterschiedliche Netze zusammenkommen und die Bahnen nicht
über die nötigen Ressourcen verfügen, um eine Abstimmungen vorzunehmen, respektive die technischen Anpassungen zu gross wären, können die Datensätze unverändert so
stehen gelassen werden wie sie sind. Aus den Arbeiten zur Datenmodellierung geht
hervor, dass Daten später immer zusammengebracht werden können. Trotzdem wird
empfohlen, die Strukturen auf ihre Konsistenz hin zu prüfen und Unstimmigkeiten
möglichst früh zu bereinigen.
3.1.4
Übergang zwischen verschiedenen Koordinatensystemen
Damit die Daten in den angrenzenden, nicht harmonisierten Koordinaten zusammengebracht werden können, müssen entlang der Streckenabschnitte in den Übergangszonen, Fixpunkte in beiden Systemen gerechnet werden. Aus den zwei Koordinatenpaaren der identischen Punkte können die Transformationsparameter für den Übergang
vom einem ins andere Systeme gerechnet werden. Der Massstabsfaktor der Transformation muss immer 1 sein um vor allem bei Konstruktionsteilen wie Weichen, die Massangaben nicht zu verändern.
3.1.5
Abstimmung mit den Referenznetzen der amtlichen Vermessung
Die Abstimmung bedingt hier zwingend den Dialog zwischen Eisenbahn und amtlicher
Vermessung, um Doppelinvestionen bei der Festlegung des Fixpunktnetzes zu vermeiden. Es macht Sinn, wenn in den Übgangszonen, nebst den Koordinaten der beiden benachbarten Systeme als dritte Koordinatenangabe die ETRF89 Werte angebunden werden und daraus die Transformationswerte errechnet werden.
3.2 Wie weiter? Konkret
Klarheit und Einheitlichkeit bei der Einführung von CNTD, aufbauend auf den bahngeodätischen Grundlagen dieses Berichtes, soll von Anfang den europäischen Partnerbahnen der UIC ermöglichen, mit der neuen Koordinatentechnologie die bestmöglichen Resultate zu erzielen.
Ein Merkblatt soll zuerst für die Bereiche Gleisbau und dann für alle zukünftigen, darauf aufbauenden Nutzungen, die Stossrichtung vorgeben.
Dank
An alle Mitarbeiter der ETH, der UIC der DB, der SNCF, der SBB welche am Fortschritt
der Themen die in diesem Text erläutert sind gearbeitet haben.
12.10
13
Integration der Daten der Landeskarte
1:25’000 (VECTOR25) ins Datenmodell
der Amtlichen Vermessung
(DM.01-AV-CH)
Robert Balanche, Eidgenössische
Vermessungsdirektion/swisstopo
Robert Balanche
Seftigenstrasse 164
CH-3084 Wabern
Tel :
Fax :
E-Mail :
+41 31 963 21 11
+41 31 963 22 97
1 Einleitung
Die Daten der Amtlichen Vermessung (AV) sind insbesondere seit Beginn der Umsetzung des Projektes Reform der Amtlichen Vermessung (RAV) immer populärer geworden. Dies beruht nicht zuletzt auf der seinerseits gewählten Strategie des modellbasierten Konzeptes für die Verwaltung der numerischen Daten. Es handelte sich damals
noch um eine visionäre Lösung, von welcher wir heute die Früchte « Nutzen und Ertrag » ernten können.
Aufgrund unseres föderalistischen Systems und der dezentralen Organisationsstruktur
der Amtlichen Vermessung der Schweiz ist der Arbeitsfortschritt bei der Erstellung der
Daten der AV von Kanton zu Kanton und von Region zu Region verschieden. Auch
heute noch sind die Daten der AV nicht flächendeckend über die ganze Schweiz vorhanden. Diese Tatsache führt dazu, dass eine ansehnliche Anzahl von Kunden diese
sehr genauen und zuverlässigen Daten der AV nicht verwendet.
Um dieser fehlenden Flächendeckung begegnen zu können, hat das Departement für
Verteidigung, Bevölkerungsschutz und Sport (VBS) in der Strategie der Amtlichen Vermessung für die Jahre 2004-2007 mit einer Vision für die Folgejahre 1 im Kontext und im
Zusammenhang mit der Nationalen Geodaten-Infrastruktur (NGDI) folgendes festgelegt: Die Referenzdaten der NGDI und damit auch die Daten der AV müssen folgende
Voraussetzungen erfüllen:
a.
b.
c.
d.
e.
f.
ein Datenmodell ist vorhanden,
sie liegen flächendeckend vor,
es besteht ein öffentliches Interesse,
sie entsprechen einer definierten Qualität,
die Nachführung ist gesichert und
die Finanzierung ist gesichert.
Damit die Voraussetzung b. der Flächendeckung kurzfristig erreicht werden kann, ist es
nötig, einfache provisorische Ersatzprodukte (PEP) zu erstellen.
Provisorische Ersatzprodukte (PEP) sind digitale Vektordaten, welche im Datenmodell
der AV beschrieben und über die Amtliche Vermessungsschnittstelle (AVS) austauschbar sind. Deren Aktualität, Genauigkeit und Informationsgehalt erfüllen die Anforderungen der AV nicht. Sie dienen ausschliesslich für die Verwendung der AV als Referenzdaten für Landinformationssysteme und nicht für die Bedürfnisse des Grundbuchs.
Die PEP ergänzen die AV in Gebieten, in welchen noch keine AV-Daten oder nur graphische Grundbuchpläne existieren. Sie können auch die bestehenden Bestandteile der
digitalen AV-Daten mit fehlenden Informationsebenen oder Themen ergänzen.
Es ist vorgesehen, die PEP für die Informationsebenen „Bodenbedeckung“, „Einzelobjekte“ und „Nomenklatur“ aus bestehenden digitalen Produkten (z.B. VECTOR25 und
SwissNames von swisstopo) abzuleiten.
Die vorliegenden Ausführungen sind der Schnittstelle für die Überführung der Vektordaten der Landeskarte 1 : 25'000 (VECTOR25) ins Datenmodell der Amtlichen Vermessung (DM.01-AV-CH, Version 24) gewidmet.
1
http://www.swisstopo.ch/data/vd/Documents/Strategie_AV_04_07.pdf
13.1
Integration Vector25 / AV
2 Vergleich der VECTOR25-Daten mit denjenigen der AV
2.1 Die VECTOR25-Daten
VECTOR25 ist das digitale Landschaftsmodell der Schweiz, welches inhaltlich und geometrisch auf der Landeskarte 1 : 25’000 basiert. VECTOR25 gibt die natürlichen und
künstlichen Objekte der Landschaft im flexiblen Vektorformat wieder und eignet sich
speziell für den Einsatz in geografischen Informationssystemen (GIS). VECTOR25 beschreibt rund 8.5 Millionen Objekte mit Lage, Form und ihren Nachbarschaftsbeziehungen (Topologie) sowie der Objektart und weiteren Sachattributen. Sein Perimeter umfasst die ganze Schweiz und das angrenzende Ausland entsprechend dem Perimeter der
Landeskarte 1 : 25‘000. Die Daten von VECTOR25 werden blattschnittfrei verwaltet. Um
die Handhabbarkeit der Daten zu gewährleisten, werden extra grosse Objekte (z.B. ausgedehnte Waldgebiete) an geeigneten Stellen künstlich aufgetrennt.
2.1.1
Struktur von VECTOR25
VECTOR25 besteht aus 9 thematischen Ebenen:
Thematische Ebene
Strassennetz
Eisenbahnnetz
Übriger Verkehr
Gewässernetz
Primärflächen
Gebäude
Hecken und Bäume
Anlagen
Einzelobjekte
Beschreibung
Strassen- und Wegnetz
Eisenbahnnetz
Fähren, Seilbahnen usw.
Gewässerachsen und Uferlinien
Primäre Bodenbedeckung (Wald, See usw.)
Diverse Gebäudearten
Diverse Objektarten der Vegetation
Künstliche Areale und Anlagen
Diverse künstliche Objekte
Jede Ebene umfasst Topologietypen (z.B. Linien der Primärflächen). Pro Ebene und Topologietyp ist ein Attributsatz definiert, der mindestens aus den Standardattributen
(ObjectID, ObjectOrigin, ObjectVal bzw. Objektart, YearOfChange) besteht. VECTOR25
umfasst insgesamt rund 150 unterschiedliche Objektarten (z.B. 2-Klass-Strasse, Bach).
2.1.2
Qualität der VECTOR25-Daten
VECTOR25 zeichnet sich durch folgende Qualitätsmerkmale aus:
x
x
x
x
x
x
x
x
13.2
flächendeckend in homogener Qualität und Form
blattschnittfrei über den gesamten Perimeter
Lagegenauigkeit: 3-8m (entsprechend der Kartengenauigkeit)
Topologie ermöglicht Analysen und Simulationen
Objekte haben geometrische Minimal- und Maximaldimensionen (ń erleichterte
Handhabung)G
Koordinaten können ohne Topologieverlust auf Meter oder Dezimeter gerundet
werden
eindeutige und stabile Objektidentifikation (ń Voraussetzung für inkrementelle
Nachlieferungen)
Einfache Struktur (ń Transfer / Einsatz auf anderen GIS und CAD-Systemen
problemlos möglich).
2.2 Das Datenmodell der Amtlichen Vermessung
Aus dem Projekt « Reform der Amtlichen Vermessung (RAV) » zu Beginn der 90-erJahre ist das erste Datenmodell der Amtlichen Vermessung entstanden, das DM93. Dieses Datenmodell als Bestandteil der Technischen Verordnung über die Amtliche Vermessung (TVAV)2 legte die Minimalanforderungen fest, welche die Kantone bei der Datenerhebung bezüglich Inhalt und Organisation der Daten einzuhalten hatten. Die meisten Kantone haben dieses Modell mit kantonalen Anforderungen erweitert; daher basieren alle Vermessungen ab 1993 auf diesem Modell. Heute erkennt man die grossen Vorteile, welche schweizweit einheitlich organisierte und strukturierte Daten in einem gemeinsamen Datenmodell mit sich bringen
Ende der 90-er-Jahre zeigte es sich, dass das Datenmodell der AV überarbeitet und die
Kinderkrankheiten korrigiert werden mussten, damit es den neuen Anforderungen gerecht werden konnte. So wurde am 18. Dezember 2001 das neue Datenmodell der AV,
das DM.01-AV-CH publiziert. Unglücklicherweise enthielt dieses neue Datenmodell
noch das provisorisch ausformulierte Thema « Gebäudeadressen », da die entsprechende Schweizer Norm SN 612040 zum Zeitpunkt der Modellerstellung noch nicht vollständig vorlag. Im Juni 2003 endlich wurde die Schweizer Norm « Gebäudeadressen »
publiziert und zwei Wochen später wurde das Datenmodell DM.01-AV-CH, Version 24,
welches die Vorgaben aus der Norm übernommen hatte, amtlich herausgegeben.
2.2.1
Struktur von DM.01-AV-CH
Die Amtliche Vermessung umfasst die nachstehenden 8 Informationsebenen:
1.
2.
3.
4.
5.
6.
7.
Fixpunkte
Bodenbedeckung
Einzelobjekte
Höhen
Liegenschaften
Rohrleitungen
Administrative Einteilungen
Das Datenmodell der Amtlichen Vermessung gliedert sich in die nachstehenden 20
Themen:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
2
FixpunkteKategorie1
FixpunkteKategorie2
FixpunkteKategorie3
Bodenbedeckung
Einzelobjekte
Höhen
Nomenklatur
Liegenschaften
Rohrleitungen
Nummerierungsbereiche
Gemeindegrenzen
Bezirksgrenzen
Kantonsgrenzen
Landesgrenzen
http://www.admin.ch/ch/f/rs/c211_432_21.html
13.3
15.
16.
17.
18.
19.
20.
2.2.2
Planeinteilungen
TS-Einteilung
Rutschgebiete
PLZ, Ortschaft
Gebäudeadressen
Planrahmen
Qualität der Daten der AV
Die Qualitätsanforderungen der Daten der AV sind sehr hoch und werden festgelegt
mit den Informationen über die Genauigkeit und die Zuverlässigkeit. Die Qualitätsanforderungen richten sich nach der Einteilung in die 5 Toleranzstufen, welche in der
TVAV, Art. 3 wie folgt definiert wurden:
x
x
x
x
x
TS1: Stadtgebiete
TS2: Überbaute Gebiete und Bauzonen
TS3: Intensiv genutzte Landwirtschafts- und Forstwirtschaftsgebiete
TS4: Extensiv genutzte Landwirtschafts- und Forstwirtschaftsgebiete
TS5: Das Sömmerungsgebiet und unproduktive Gebiete
Die TVAV definiert in den Art. 28 ff die Genauigkeitsanforderungen je nach Informationsebene und Toleranzstufe. Man findet dort beispielsweise für die Ebenen « Liegenschaften » und « Rohrleitungen » die nachstehenden Genauigkeitsanforderungen:
Lagegenauigkeit (Standardabweichung in cm) für einen im Gelände exakt definierten
Punkt:
TS2
3.5
TS3
7
TS4
15
TS5
35
N.B. die TS1 (Stadtgebiete) müssen mindestens die Anforderungen der TS2 erfüllen.
Was die Zuverlässigkeit anbelangt, findet man in Art. 33 der TVAV:
"Die Zuverlässigkeit ist für alle Punkte der Informationsebenen « Fixpunkte », « Liegenschaften » und für die Hoheitsgrenzen der Informationsebene « Administrative Einteilungen » sowie für spezielle Einzelpunkte nachzuweisen…
3 Datentransfer von VECTOR25 ins DM.01-AV-CH
3.1 Unterschiede in den beiden Datensätzen
Gemäss der Beschreibung der Datenstruktur von VECTOR25 und den Daten im Datenmodell der AV gemäss Kapitel 2 erkennt man sofort, dass nicht nur die Objekte verschieden strukturiert sind, sondern dass auch die Definition der Informationen unterschiedlich ist. In der Tat, wenn man die Bodenbedeckung etwas genauer unter die Lupe
nimmt, erkennt man, dass die Modellierung derselben Realität unterschiedlich vorgenommen worden ist. Von Seiten VECTOR25 erhält man z.B. folgende Beschreibung:
Die Ebene „Primärflächen“ beschreibt die primäre topografische Bodenbedeckung. Die Flächenarten dieser Ebene schliessen sich gegenseitig aus (See und Wald) und bilden ein redundanzfreies,
lückenloses Flächennetz. Im Gegensatz zur Landeskarte sind in den Primärflächen interpretierte
Siedlungsgebiete enthalten. Einzelgebäude sind in der Ebene Gebäude verwaltet.
13.4
Die Informationsebene « Bodenbedeckung » ist in Art. 7, Ziff. b der TVAV wie folgt beschrieben:
1. Gebäude;
2. befestigte Flächen unterteilt in: Strasse/Weg, Trottoir, Verkehrsinsel, Bahn,
Flugplatz, Wasserbecken sowie übrige befestigte Flächen;
3. humusierte Flächen unterteilt in: Acker/Wiese/Weide, Intensivkulturen (weiter
unterteilt in Reben und übrige Intensivkulturen), Gartenanlage, Hoch/Flachmoor sowie übrige humusierte Flächen;
4. Gewässer unterteilt in: stehendes Gewässer, fliessendes Gewässer sowie Schilfgürtel;
5. bestockte Flächen unterteilt in: geschlossener Wald sowie übrige bestockte Flächen;
6. vegetationslose Flächen unterteilt in: Fels, Gletscher/Firn, Geröll/Sand, Abbau/Deponie sowie übrige vegetationslose Flächen.
Zwischen den Informationsebenen der beiden Datensätze erkennt man zwei grosse Unterschiede: Die Bodenbedeckung gemäss Datensatz von VECTOR25 enthält weder die
Gebäude noch die Strassen. Dies bedeutet, dass diesem Umstand beim Transfer der Daten von VECTOR25 ins Datenmodell der AV Rechnung getragen werden muss. Diese
Elemente müssen anders zusammengefasst und als Gebietseinteilung definiert werden.
Nachstehend ein Beispiel, für welches beim Transfer der Daten eine Lösung gefunden
werden muss.
VECTOR25
DM.01-AV-CH
Bodenbedeckung
(Gebietseinteilung)
Primärflächen
(Gebietseinteilung)
Gebäude
Strassen
(Polyline)
(Flächen)
Figur 1 : Unterschiede zwischen der Bodenbedeckung von VECTOR25 und dem DM.01-AV-CH
3.2 Übereinstimmung der Objekte
Bei der Vorbereitung eines derartigen Datenaustausches muss als einer der ersten
Schritte eine eindeutige Korrespondenztabelle für die Zielobjekte definiert werden. Dies
ist eine relativ schwierige Aufgabe, welche mit dem Kunden klar abgesprochen werden
muss Es kommt dabei vor, dass gewisse Objekte lediglich in einem Datensatz existieren.
Was kehrt man vor, wenn ein Objekt lediglich in den Ausgangsdaten existiert; Soll man
es ignorieren oder dennoch transferieren, um die Information nicht zu verlieren?
Die nachstehenden Tabellen zeigen für jedes Objekt jeder VECTOR25Informationsebene das zugeordnete Objekt im Datenmodell DM.01-AV-CH.
13.5
3.2.1
Strassennetz
Vector25.ObjectVal
Beschreibung
Target->DM01-AV-CH
Autobahn
Autob_Ri
Autostr
Autobahn
Autobahn richtungsgetrennt
Autostrasse
Ein-/Ausfahrt (Autobahn /
Strasse)
Autobahnzufahrt
1. Klass Strasse
2. Klass Strasse
3. Klass Strasse
4. Klass Strasse
5. Klass Strasse
6. Klass Strasse
Quartierstrasse
Historischer Weg / Strasse
Panzerpiste
Parkweg
Alleinstehende Brücke
Alleinstehende Brücke gedeckt
Alleinstehender Steg
Strasse_Weg
Strasse_Weg
Strasse_Weg
Ein_Ausf
A_Zufahrt
1_Klass
2_Klass
3_Klass
4_Klass
5_Klass
6_Klass
Q_Klass
HistWeg
PzPiste
Parkweg
BrueckLe
GedBruLe
StegLe
3.2.2
Strasse_Weg
Strasse_Weg
Strasse_Weg
Strasse_Weg
Strasse_Weg
Strasse_Weg
schmaler_Weg
schmaler_Weg
Strasse_Weg
schmaler_Weg
schmaler_Weg
schmaler_Weg
Tunnel_Unterfuehrung_Galerie
Eisenbahnnetz
Vector25.ObjectVal
Beschreibung
Target->DM01-AV-CH
Gt_Bahn
I_Geleis
MS_Bahn
NS_Bahn1
Güterbahn
Industriegeleise
Museumsbahn
Normalspurbahn eingleisig
Normalspurbahn
mehrgleisig
Schmalspurbahn eingleisig
Schmalspurbahn mehrgleisig
Strassenbahn
Streckenverknüpfung innerhalb des Bahnhofareals
Bahngeleise
Bahngeleise
Bahngeleise
Bahngeleise
NS_Bahn2
SS_Bahn1
SS_Bahn2
Str_Bahn
Str_Bhof
3.2.3
Bahngeleise
Bahngeleise
Bahngeleise
Bahngeleise
Bahngeleise
Übriger Verkehr
Vector25.ObjectVal
Beschreibung
Target->DM01-AV-CH
A_Faehre
LS_Bahn
Mat_Bahn
P_Faehre
Skilift
Autofähre
Luftseilbahn
Materialbahn
Personenfähre
Skilift
Faehre
Luftseilbahn
Luftseilbahn
Faehre
Skilift
13.6
3.2.4
Gewässernetz
Vector25.ObjectVal
Beschreibung
Target->DM01-AV-CH
Bach
Bachachs
Bach_U
Bisse
Druckl_1
Druckl_2
Drucksto
Fluss
Fluss_U
Bach
Bachachse
Bachverlauf unterirdisch
Bisse
Druckleitung einfach
Druckleitung mehrfach
Druckstollen
Flussachse
Flussverlauf unterirdisch
Bach ohne erkennbare /
eindeutige Fliessrichtung
Seeachse
Seeinsel
Seeufer
Rinnsal
eingedoltes_oeffentliches_Gewaesser
Rinnsal
Druckleitung
Druckleitung
Druckleitung
eingedoltes_oeffentliches_Gewaesser
Vector25.ObjectVal
Beschreibung
Target->DM01-AV-CH
Z_BaumS
Z_Fels
Z_Fluss
Z_Gebue
Z_GerGeb
Z_GerGle
Z_Geroel
Z_GerWa
Z_GerWaO
Z_Glet
Z_GsPist
Z_HaPist
Z_KiGrub
Z_LeGrub
Z_ObstAn
Z_Reben
Z_See
Z_Siedl
Z_StauDa
Z_StauMa
Z_SteBru
Z_SumGeb
Z_Sumpf
Z_SumWa
Z_SumWaO
Z_Uebrig
Z_Wald
Z_WaldOf
Baumschule
Fels
Fluss
Gebüsch
Geröll mit Gebüsch
Geröll auf Gletscher
Geröll
Geröll in Wald
Geröll in offenem Wald
Gletscher
Graspiste
Piste mit Hartbelag
Kiesgrube
Lehmgrube
Obstanlage
Reben
See
Siedlung
Staudamm*
Staumauer*
Steinbruch
Sumpf und Gebüsch
Sumpf
Sumpf in Wald
Sumpf in offenem Wald
Übriges Gebiet
Wald
Wald offen
geschlossener_Wald
Fels
fliessendes
uebrige_bestockte
Geroell_Sand
Geroell_Sand
Geroell_Sand
Geroell_Sand
uebrige_bestockte
Gletscher_Firn
Strasse_Weg
Strasse_Weg
Abbau_Deponie
uebrige_vegetationslose
uebrige_humusierte
Reben
stehendes
Fels
Abbau_Deponie
uebrige_humusierte
uebrige_humusierte
uebrige_bestockte
uebrige_humusierte
Acker_Wiese_Weide
geschlossener_Wald
uebrige_bestockte
Kanal
Seeachse
Seeinsel
See
3.2.5
Rinnsal
-
Primärflächen
13.7
3.2.6
Gebäude
Vector25.ObjectVal
Beschreibung
Target->DM01-AV-CH
Z_Gebaeude
Z_Innenhof
Z_Gasthof
Z_Huette
Z_Kirche
Z_Kuehlturm
Z_Lagertank
Z_Perron
Z_Schiessstand
Z_Schloss
Z_Station
Z_Treibhaus
Gebäude / Einzelhaus
Innenhof
Abgelegener Gasthof
Hütte
Kirche
Kühlturm
Lagertank
Perrondach
Schiessstand, Schützenhaus
Schloss, Burg
Station / ÖV Haltestelle
Treibhaus
Wasserbecken (Schwimmbäder, ARA)
Gebaeude
uebrige_befestigte
Gebaeude
Gebaeude
Gebaeude
Silo_Turm_Gasometer (EO)
Gebaeude
Bahnsteig (EO)
Gebaeude
Gebaeude
Unterstand
Unterstand
Z_WBecken
3.2.7
Wasserbecken
Hecken und Bäume
Vector25.ObjectVal
Beschreibung
Target->DM01-AV-CH
BauReihe
Hecke
OBReihe
EinBaum
ObstBaum
Baumreihe
Hecke
Obstbaumreihe
Einzelbaum
Obstbaum
schmale_bestockte_Flaeche
wichtiger_Einzelbaum
wichtiger_Einzelbaum
3.2.8
Anlagen
Die Ebene Anlagen umfasst die Objektarten Bahnhofareal, Flughafenareal und Flughafenbahnhof-areal. Da für diese Objekte keine entsprechenden Elemente im Datenmodell
DM.01-AV-CH existieren, werden sie nicht erfasst.
3.2.9
Einzelobjekte
Vector25.ObjectVal
Antenne
ARA
AusTurm
BiStock
Brunnen
Denkmal
Doline
Drehsch
ElWerk
Hoehle
Kamin
Kapelle
KiTurm
Quelle
Reserv
Schiffst
SendeAnl
13.8
Beschreibung
Target->DM01-AV-CH
Antenne
Mast_Antenne
Abwasserreinigungsanlage weitere
Aussichtsturm
Aussichtsturm
Bildstock_Kruzifix
Bildstock /Wegkreuz
Brunnen
Brunnen
Denkmal
Denkmal
weitere
Doline
Aussichtsturm
Drehscheibe
weitere
Elektrizitätswerk
Grotte_Hoehleneingang
Höhle / Grotte
Hochkamin
Hochkamin
Bildstock_Kruzifix
Kapelle
uebriger_Gebaeudeteil
Kirchturm
Quelle
Quelle
Reservoir
Reservoir
Landungssteg
Schiffstation
Mast_Antenne
Sendeanlage
Turm
W_Turm
WaFall
ZistOff
HSP_Ltg
Ruine
Sender
Turm
Wasserturm
Wasserfall
Zisterne offen
Hochspannungsleitung
Ruine
Radiosender
Aussichtsturm
Aussichtsturm
weitere
Reservoir
Hochspannungsfreileitung
Ruine_archaeologisches_Objekt
Mast_Antenne
3.3 Datentransfer
Wenn die Korrespondenztabellen ausgearbeitet worden sind, « genügt es », das Interface für den Transfer all dieser Objekte von VECTOR25 nach MD.01-AV-CH zu schreiben. Dazu benötigt man ein Werkzeug, mit welchem die Parameter so gesetzt werden
können, dass jedes Element aus VECTOR25 in die richtige Ebene von MD.01-AV-CH
transferiert wird. Die Erarbeitung eines solchen Interfaces kann nicht über StandardKonversions-Werkzeuge erfolgen. Es bleibt einem nichts anderes übrig, als sich mit dem
Quellcode auseinanderzusetzen und dieses Interface teilweise selbst zu programmieren.
Nachstehend ein Auszug des notwendigen Skripts für die Erstellung eines solchen Interfaces mittels des Werkzeuges « ilitools ».
Für dieses Interface, welches für die Modellierung in den Sprachen Französisch,
Deutsch und Italienisch vorgesehen ist, war es notwendig, eine « Namens- und AttributTabelle » zu erstellen, so dass das Skript lediglich einmal beschrieben werden musste.
Am Anfang des Programmes wird ein Konfigurationsfile gelesen, welches die Zuordnung des gewünschten Modells definiert.
Auszug aus der deutschsprachigen Namenstabelle der Primärflächen von VECTOR25 :
MAP PRI
LANG
=> D
TOPIC
=> Bodenbedeckung
TABLE
=> ProjBoFlaeche
TABLE_NACH
=> BBNachfuehrung
TABLE_SURFACE
=> ProjBoFlaeche_Geometrie
OTHER
=> PEP
Z_GERGEB_VAL
=> vegetationslos.Geroell_Sand
Z_GERGEB
=> Z_GerGeb_X-Z_GerGle_X-Z_Geroel_X-Z_GerWa_X
Z_FELS_VAL
=> vegetationslos.Fels
Z_FELS
=> Z_Fels_X-Z_StauMa_X
Z_FLUSS_VAL
=> Gewaesser.fliessendes
Z_FLUSS
=> Z_Fluss_X
Z_GEBUE_VAL
=> bestockt.uebrige_bestockte
Z_GEBUE
=> Z_Gebue_X-Z_GerWaO_X-Z_SumWa_X-Z_WaldOf_X
Z_GLET_VAL
=> vegetationslos.Gletscher_Firn
Z_GLET
=> Z_Glet_X
Z_KIGRUB_VAL
=> vegetationslos.Abbau_Deponie
Z_KIGRUB
=> Z_KiGrub_X-Z_SteBru_X
Z_SEE_VAL
=> Gewaesser.stehendes
Z_SEE
=> Z_See_X
Z_SUMPF_VAL
=> humusiert.uebrige_humusierte
Z_SUMPF
=> Z_Sumpf_X-Z_ObstAn_X-Z_SumGeb_X-Z_SumWaO_X
13.9
Z_WALD_VAL
=> bestockt.geschlossener_Wald
Z_WALD
=> Z_Wald_X-Z_BaumS_X
Z_SOLD_VAL
=> vegetationslos.uebrige_vegetationslose
Z_SOLD
=> Z_Siedl_X-Z_LeGrub_X-Z_StauDa_X
Z_UEBRIG_VAL
=> humusiert.Acker_Wiese_Weide
Z_UEBRIG
=> Z_Uebrig_X
Z_BEFESTIGT_VAL => befestigt.Strasse_Weg
Z_BEFESTIGT
=> Z_GsPist_X-Z_HaPist_X
Z_REBEN_VAL
=> humusiert.Intensivkultur.Reben
Z_REBEN
=> Z_Reben_X
TMP
=> 1.0
END_MAP !PRI
Auszug aus dem Skript:
Kategorienwahl:
! Here the Category who are inserted into Geroell_Sand (BB)
IF PRI.Z_GERGEB SHPIN_REC.objectval LOC IS_NOT_NULL THEN
PRI.Z_GERGEB_VAL => VAR.ART
PRI_SURFACE
END_IF
…
PROCEDURE PRI_SURFACE
!***********************************************************
! Write the Object and the geometry for the category PRI
!***********************************************************
IF PRI.LANG = 'F' THEN
VAR.ART
=> OUT.Genre
ELSE
VAR.ART
=> OUT.Art
END_IF
NEXT_OBJID
=> OUT.OBJID
ILOUT_WRITE_OBJECT
PRI.TABLE_SURFACE
ILOUT_WRITE_SURFACE
END_PROCEDURE !PRI_SURFACE
13.10
3.4 Festgestellte Probleme
3.4.1
Topologische Unterschiede
Bevor die Daten gemäss den obigen Tabellenzuordnungen transferiert werden können,
sind die topologischen Unterschiede zu untersuchen. In der Tat, wie bereits im Kapitel
3.1. angesprochen, unterscheiden sich die Primärflächen des Produktes VECTOR25 und
die Informationsebene Bodenbedeckung der AV.
Eine der Schwierigkeiten betrifft die Informationen des Strassennetzes von VECTOR25.
Diese sind in VECTOR25 als lineare Strassenachsen definiert, während die Strassen in
der AV als flächenartige Information im DM.01-AV-CH ausgeschieden werden. Die
Strassenbreiten sind a priori, ausgehend von der Information Strassenachse, nicht bekannt; man ist vielmehr gezwungen, diese Informationen der Zeichenerklärung zur
Landeskarte 1 : 25'000 von swisstopo zu entnehmen, wo für jede Strassenklassierung
eine bestimmte Mindestbreite vorgegeben wird. Durch diese zusätzliche attributive Information von VECTOR25 kann jedem Strassenelement eine bestimmte Breite zugeordnet werden und daraus können flächenhafte Objekte gebildet werden.
Gemäss Flyer « Zeichenerklärung » zu den Landeskarten sind die Strassenklassierungen
wie folgt definiert:
x
x
x
x
x
x
x
1- Kl.-Strasse, (mind. 6m breit)
2- Kl.-Strasse, (mind. 4m breit)
Quartierstrasse, (mind. 4m breit)
3-Kl.-Strasse, (mind. 2,8m breit)
4- Kl. Fahrweg (mind. 1,8m breit)
5-Kl. Feld-, Wald-, Veloweg
6- Kl.., Fussweg
Die 5-Kl. und 6-Kl.-Objekte werden als Wege mit linearer Geometrie in die Informationsebene « Einzelobjekte » transferiert
Die Strassenverbreiterungen, ausgehend von den linearen Objekten, und die Erstellung
von gebietseinteilenden Flächenobjekten erfolgt mit konventionellen GIS-StandardWerkzeugen.
13.11
0
25
50
75
100
1 2 5 M e te r
Figur 2 : Transformation des linearen Strassennetzes in « gebietseinteilende » Flächenelemente
3.4.2
Generalisierung der Daten
Die VECTOR25-Daten stammen aus der Digitalisierung der Landeskarten 1 : 25'000, einem kartographischen Produkt mit generalisierten Informationen. Es ist nicht möglich,
ausgehend von diesen generalisierten Informationen, die Bedürfnisse der AV oder der
provisorischen Ersatzprodukte (PEP) abdecken zu können. Es ist vielmehr nötig, dazu
auf weitere Grundlagedaten zurückzugreifen, z.B. durch die Verwendung der Informationen für das Strassennetz, welche mittels des Programmes ATOMI von swisstopo aus
den digitalen Orthofotos gewonnen werden.
ATOMI ist ein Programm für die automatische Extraktion dreidimensionaler Strassenachsen aus Orthofotos, dem digitalen Geländemodell sowie dem bereits vorhandenen
vektoriellen Strassennetz aus VECTOR25. Die nachstehende Figur 3 zeigt die Überlagerung der Informationen von VECTOR25 und ATOMI:
13.12
0
25
50
75
100
1 2 5 M e te r
Figur 3 : Überlagerung der VECTOR25-Daten mit denjenigen aus ATOMI
Diese Lösung verbessert die Qualität des Strassennetzes ganz erheblich, bringt jedoch
weitere Probleme. Dadurch, dass die Strassen nun « geometrisch richtig » erfasst sind,
stellt man fest wie die Gebäude diese Strassen zum Teil überlappen. Zur Lösung dieses
Konfliktes sind mehrere Varianten möglich:
x
x
x
Man belässt die Originaldaten aus VECTOR25 ohne Verwendung der StrassenInformationen aus ATOMI,
Man verwendet die Strassenauswertungen aus ATOMI und belässt die aus
VECTOR25 erfassten Gebäudeinformationen, auch wenn diese die Strassen
überlappen,
Man verwendet die Strassenauswertungen aus ATOMI und korrigiert die aus
VECTOR25 erfassten Gebäude so, dass man einen kohärenten und realistischen
Datensatz erhält. Der dafür notwendige Aufwand ist jedoch nicht zu vernachlässigen.
Man kann feststellen, dass die Verbesserung von Datensätzen unweigerlich andere
Probleme oder Diskrepanzen aufwerfen. Dabei wird man jedoch auch mit der KostenNutzen-Frage konfrontiert und man wird gezwungen, eine entsprechende Wahl zu treffen!
13.13
Der ganze Prozess kann wie folgt zusammengefasst werden:
VECTOR25
ATOMI
Vorbereitung
Vorbereitung
der Daten
der Daten
Interface
Behandlung
nein
nein
Resultat
manuell
Behandlung
manuell
ja
DM.01
Figur 4 : Integrationsprozess von verschiedenen Datenquellen
3.5 Schlusskontrollen
Nachdem man die Vorgehenswahl getroffen hat und die Daten transferiert worden
sind, ist die Integrität der daraus resultierenden Daten zu überprüfen. Die AV verlangt
eine hohe Qualität der Daten und exakt einzuhaltende Anforderungen, die mit entsprechenden Werkzeugen geprüft werden. Daher kann nach erfolgreich durchgeführtem
Datentransfer ein INTERLIS-file im Datenmodell DM.01-AV-CH generiert werden, welches mit einem entsprechenden Checker geprüft wird. Dabei stellt man fest, dass im so
neu erzeugten Datensatz noch viele Fehler und Ungereimtheiten existieren. Nachstehend einige Beispiele mit den von uns festgestellten Fehlern:
Figur 5 : Ein einziges Zentroïd für 2 verschiedene Flächen
13.14
Figur 6 : Resultierende Fläche sehr klein
Figur 7 : Fehlende Punkte: noch zu erzeugen
Figur 8 : No area found for
centroid
Figur 9 : Area with unknown
centroid
Figur 10 : Area with "n"
centroids
Figur 11 : duplicate line
Figur 12 : Intersection
Figur 13 : partial line overlap
Figur 14 : full line overlap
Für die Elimination obiger Fehler sind entweder weitere Routinen zu programmieren,
welche diese Unzulänglichkeiten erkennen und beheben, oder es bedarf manueller Korrektureingriffe zur Erstellung eines kohärenten Datensatzes, welcher die Anforderungen der AV erfüllt. Auch nach der Vornahme dieser weiteren Verbesserungen gilt es
abzuwägen, inwieweit das entstandene Endprodukt den Bedürfnissen des provisorischen Ersatzproduktes gerecht wird. Können die geringere Qualität und die noch
verbleibenden « Ungereimtheiten » akzeptiert werden?
13.15
Der Datentransfer von VECTOR25 ins Datenmodell DM.01-AV-CH zeigt, wie wichtig, ja
unerlässlich eine Datenbeschreibung ist. Wenn ein Datensatz weder über ein Datenmodell noch über eine klare Datenbeschreibung verfügt, ist es praktisch unmöglich, diese
Informationen für verschiedene andere Zwecke verwenden zu können. Sie sind nicht
mehr „interoperabel“!
Eine gute Datenbeschreibung reicht für die Interoperabilität jedoch noch nicht aus. Für
die Interoperabilität der Daten bedarf es auch einer exakten Analyse, nicht nur des Datenmodells aber auch der Semantik.
Man kann feststellen, dass die technische Interoperabilität weniger Probleme aufwirft
als die semantische Interoperabilität. In der Tat muss man festhalten, dass der ursprünglich erfasste Datensatz für ein bestimmtes, festgelegtes Bedürfnis angelegt worden ist.
Wenn man ihn nachher für andere als die ursprünglich vorgesehenen Zwecke verwendet will, riskiert man, dass die Anforderungen des ursprünglichen Datensatzes nicht
mehr denjenigen des zweiten entsprechen.
Die semantische Interoperabilität umfasst auch die sprachlichen Probleme. Wenn beispielsweise die beiden Datensätze in verschiedenen Sprachen festgelegt worden sind,
muss auch die Korrespondenz von Ausdrücken und Definitionen festgelegt werden. Ein
technisches Wörterbuch ist bei der Festlegung des Datensatzes in einer Fremdsprache
eine grosse Hilfe.
Die Interoperabilität von Daten ist eine Notwendigkeit und ein unerlässliches Werkzeug
für eine effiziente Nutzung von Informationen, insbesondere von geographischen Informationen.
Literatur
x
Strategie der Amtlichen Vermessung für die Jahre 2004 bis 2007 mit Vision für
die Folgejahre, Eidgenössisches Departement für Verteidigung, Bevölkerungsschutz und Sport, Bundesamt für Landestopografie, Eidgenössische Vermessungsdirektion.
x
VECTOR25. Das digitale Landschaftsmodell der Schweiz, Bundesamt für Landestopografie.
x
Transfert des données de VECTOR25 dans le MD.01, Semesterarbeit, A.
WILDBOLZ, EIVD 2004.
x
«Interlis Tools», Dokumentation der Firma Infogrips GmbH.
13.16
14
Nationale Geodaten-Infrastruktur
(NGDI)
Organisatorische Aspekte der
Interoperabilität beim Bund
Rolf Buser, Stv. Leiter KOGIS
Koordinationsstelle GI & GIS des Bundes
KOGIS
Rolf Buser, Dipl. Ing. ETH
Koordinationsstelle GI & GIS (KOGIS)
c/o Bundesamt für Landestopografie / swisstopo
Seftigenstrasse 264
CH-3084 Wabern
Tel :
Fax :
E-Mail :
+41 31 963 24 03
+41 31 963 23 25
Unter der Nationalen Geodaten-Infrastruktur (NGDI) wird gemäss der Strategie1 und
dem Umsetzungskonzept2 zur Strategie für Geoinformation beim Bund “… ein von allen
für die Bereitstellung von Geobasisdaten Verantwortlichen gemeinsam entwickeltes, genutztes
und fortgeführtes System von politischen, institutionellen und technologischen Massnahmen
verstanden. Dieses System stellt sicher, dass Verfahren, Daten, Technologien, Standards, rechtliche Grundlagen, finanzielle und personelle Ressourcen zur Gewinnung und Nutzung von Geoinformationen ziel- und bedarfsorientiert den beteiligten Verwaltungen, Organisationen und
Bürgern auf allen Entscheidungsebenen (lokal, regional und national) zur Verfügung gestellt
werden können.“
Diese Umschreibung der NGDI zeigt auf, dass hier eine Infrastruktur entwickelt werden
soll, welche hochgradig interoperabel sein muss. Interoperabel einerseits auf der politischen, organisatorischen und institutionellen Ebene, andererseits auf der technischen,
also der Daten- und Systemebene. Die technische Ebene bringt durch die schnelle Entwicklung der Internettechnologien immer bessere Lösungen. Auf dieser Ebene liegt jedoch auch beim Bund weniger das Problem. Technisch lässt sich schon vieles realisieren
und es stehen schon gute Lösungen bereit.
Auf der politischen, organisatorischen und institutionellen Ebene stehen wir hingegen
bezüglich Interoperabilität im Geoinformationsbereich am Anfang.
Nachfolgend werden einige organisatorische Aspekte beim Bund im Bereich der NGDI
bezüglich Interoperabilität kurz dargelegt.
Kontaktnetz
Auf dem Weg zu einer NGDI muss die politische, organisatorische und institutionelle
Interoperabilität der technischen vorausgehen. Eine gemeinsame Strategie, verbindliche
Verfahren, eindeutige Begriffe, sowie genau abgestimmte Forderungen und Erwartungen der beteiligten Partner und Institutionen sind nötig. Eine umfassende und stetige
„interpersonale“ Kommunikation und der Einbezug von Informationsgemeinschaften
sind unabdingbar. Mit der konstituierenden Sitzung für das Kontaktnetz e-geo.ch im
Januar 2005 ist ein erster Schritt in Richtung politischer, organisatorischer und institutioneller Interoperabilität getan. Das Kontaktnetz soll unter Berücksichtung oder gar
Stärkung föderaler Strukturen und heterogener Systeme umgesetzt werden und wird
durch ein Steuerorgan geleitet, in welchem sowohl alle Verwaltungsebenen als auch Institutionen und die Privatwirtschaft vertreten sind.
Die neu gebildete Geschäftsstelle des Kontaktnetzes, welche vorerst vom Bund finanziert wird, bildet das Sekretariat des Steuerungsorgans und betreut in erster Linie die
Aufgaben, welche ihr vom Steuerungsorgan anvertraut werden.
Geobasisdaten und Geobasisdienste
Mit höchster Priorität muss festgelegt werden, „WAS“ die Inhalte der NGDI Schweiz
sind. d.h. welche Daten und Dienste die NGDI bereitstellen muss. Hier werden die oben
erwähnten Informationsgemeinschaften eine entscheidende Rolle spielen. Innerhalb von
eindeutig definierten Tätigkeitsbereichen (z.B. Raumplanung) müssen gemeinsame Vorstellungen über Modelle von Geobasisdaten- und Geobasisdiensten entwickelt werden.
Nur dadurch kann die Interoperabilität auf der Datenebene und später bei angebotenen
1
2
Strategie für Geoinformation beim Bund, GKG-KOGIS 2001, www.kogis.ch
Umsetzungskonzept zur Strategie für Geoinformation beim Bund, GKG-KOGIS 2003, www.kogis.ch
14.1
Nationale Geodaten-Infrastruktur (NGDI): Organisatorische Aspekte der Interoperabilität beim Bund
Diensten erfolgreich sein. Mit der Erstellung des Geobasisdaten-Katalogs des Bundes ist
ein erster Schritt getan. Auf der Basis dieses Katalogs kann die Diskussion über Informationsgemeinschaften geführt werden.
Beim Bund geht es auf organisatorischer Ebene primär darum, vorhandene Informationsgemeinschaften für diese neuen Aufgaben zu motivieren oder den Aufbau von neuen Informationsgemeinschaften zu unterstützen. Weiter müssen die Entscheidungsträger für diese Bereiche sensibilisiert werden.
Der Bund will grundlegende Geodienste bereitstellen und vernetzen. KOGIS koordiniert die Umsetzung der bundesweiten Plattform, welche auf „produktiven“ Normen
basiert, wie jene, die aus den Arbeiten von SNV (Schweizerische Normen-Vereinigung)
und OGC (Open Geospatial Consortium) hervorgegangen sind.
Auf der organisatorischen Seite muss diskutiert werden, wie ein Register der Geobasisdienste aufgebaut werden kann, in welchem die Anbieter und deren Geobasisdienste
strukturiert beschrieben und kategorisiert sind. Weiter müssen die Geobasisdienste exakt beschrieben werden, und es wird festgelegt, wie darauf zugegriffen werden kann
und wie sie kommunizieren.
Standards / Normung
Der modellbasierte Ansatz ist entscheidend für die Interoperabilität und soll beim Bund
in Zukunft eine wichtige Rolle spielen.
Folgende Richtlinien und Standards werden auf Bundesebene festgelegt:

die Metadatenbeschreibung erfolgt über das auf der Basis von ISO 19115 entwickelte CH-Profil (im Minimum über das von ISO definierte Core-Profil),
die Geodatenmodellierung erfolgt mit der Modellierungssprache UML (Unified
Modeling Language) und INTERLIS auf der Basis eines Objektkatalogs,
der systemneutrale Austausch von Geobasisdaten und Metadaten erfolgt mindestens auf der Basis der Modellbeschreibung INTERLIS/XML unter Berücksichtigung der Kompatibilität mit internationalen Standards (z.B. mit GML).
die Vernetzung von grundlegenden Geodiensten erfolgt mindestens unter Berücksichtigung der Kompatibilität mit den internationalen Standards (wie W3C
(World Wide Web Consortium))
Die Bestrebungen im Sinne einer nationalen Plattform Geonormen (NGN) sollen weiter
gefördert und auch finanziell unterstützt werden. Die Entwicklung und Anwendung
von Geo-Normen und Datenmodellen forciert und koordiniert werden. Datenmodelle
und Normen sollen allen interessierten Nutzern zur Verfügung stehen und weiterentwickelt werden. Dazu sind in einem ersten Schritt vorhandene effiziente aber unkoordinierte und ad hoc finanzierte Initiativen und Aktivitäten zu koordinieren und auf eine
stabile finanzielle Basis zu stellen.
Ziel ist die rasche Verbreitung des Wissens über Nutzen und Anwendung der Datenmodelle und Normen sowie deren konsequente Anwendung. Die Aufgabenbereiche
Ausbildung, Technik, Datenmodelle, Support, Normen und Marketing bilden dabei die
Haupttätigkeiten.
14.2
15
Nationale Profile der internationalen
Standards am Beispiel Metadaten
Rudolf Schneeberger, ITV Geomatik AG
Rudolf Schneeberger
Dorfstrasse 53
CH-8105 Regensdorf
Tel :
Fax :
E-Mail :
+41 44 871 21 90
+41 44 871 21 99
1 Einleitung
1.1 Definition von Metadaten
Metadaten sind für viele Leute schwammig, undefinierbar und zu technisch, scheinen
unwichtig, da die Daten vorhanden sind, werden oft vernachlässigt behandelt, existieren nur auf Notizzetteln. Aus diesen Gründen werden Metadaten selten freiwillig erfasst und nachgeführt. Denn es ist heute dem Benutzer oft nicht ganz klar, wozu sie eigentlich dienen.
Laut Definition handelt es sich bei Metadaten um „Daten über Daten“, das heisst es sind
beschreibende Daten der effektiven Daten. Zwei weitere Definitionen werden noch etwas klarer:
x
Unter Metadaten versteht man strukturierte Daten, mit deren Hilfe eine Informationsressource beschrieben und dadurch besser auffindbar gemacht wird.
x
Metadaten sind maschinenlesbare Informationen über elektronische Ressourcen
oder andere Dinge.
Sehen wir uns einmal um, so stellen wir fest, dass wir jeden Tag Metadaten begegnen.
Man stelle sich ein Schokoladengestell in einem Einkaufsladen vor, in dem jede Schokolade weiss eingepackt ist und „Schokolade“ drauf steht. Welche kaufen Sie? Wahrscheinlich keine, weil nicht bekannt ist, um was für eine Schokolade es sich handelt. Der
Käufer will wissen, ob es eine Schokolade ist mit Nüssen oder ohne, wer sie hergestellt
hat, wie sie heisst, wie teuer sie ist, usw. Erst mit diesen Angaben werden die unterschiedlichen Schokoladen vergleichbar und er kann entscheiden, welches die Richtige
ist und bei welcher das Preis/Leistungs-Verhältnis stimmt.
Genau gleich verhält es sich mit Metadaten für Geodaten. Sie geben eine genaue Beschreibung des Geodatenbestandes. Erst wenn man den genauen Inhalt, die Genauigkeit, den Preis, das Modell, das Format und vieles mehr eines Geodatenbestandes kennt,
kann man entscheiden, ob er den Ansprüchen genügt. Die wichtigsten Fragen, welche
mit Metadaten beantwortet werden sind bei Geodaten:
15.1
Nationale Profile der internationalen Standards am Beispiel Metadaten
WER
WAS
bietet
und
- Institutionen
- Ansprechpartner
- Ersteller / Verteiler
- Zuständigkeit
- Anschrift
- Datenarten
- Inhalte
- Erfassungsdatum
- Name und Beschreibung
- Massstab
- Art
- Datenmenge
- Flächendeckung
WIEVIEL
- Status
- Objektarten
- räumlicher Bezug
- zeitlicher Bezug
- Thesaurus
- Fachgebiet
- Format
- Schnittstelle
- Analog / Digital
- Datenbank
- Zugangsberechtigung
- Zugangsadresse
WELCHEM Zusammenhang
und zu
- fachliche Bedeutung
- Aufgabenbeschreibung
- Eignungshinweis
- Nutzungsrestriktionen
WELCHEN Konditionen
- Preis
- Zugriffsrechte
- Nutzungsrechte
- Rechtsinhaber
- Vervielfältigungen
WORÜBER
WIE
in
1.2 Metainformation als Teil einer NGDI
Das Hauptziel einer Nationalen Geodaten-Infrastruktur (NGDI) besteht darin, über einen leichten Zugang ein optimales Angebot und eine breitere Nutzung von Geoinformation zu bewirken. In dieser NGDI sind Metainformationen ein wesentlicher Bestandteil.
15.2
2 ISO Normen
2.1 Inhalt von ISO von 19115:2003 - Metadata
Struktur für die Beschreibung von digitalen geographischen Daten in Form eines abstrakten Modells (konzeptionelles Metadatenmodell):
x
Einführung mit Abmachungen und Definitionen
x
Klassendiagramme als UML-Diagramme
x
Objektkatalog (Datadictionary)
x
weitere Anhänge
Die Norm sagt nichts über die Form der Umsetzung in einem GIS oder einer Datenbank
aus und ist kein "Kochrezept" für eine Implementierung.
2.2 Profile und Erweiterungen von ISO 19115:2003 - Metadata
Die ISO Norm 19115 geht vom Ansatz einer möglichst universellen Anwendung der
Norm aus, jedoch mit der Möglichkeit den Gesamtumfang mit Profilen wiederum einzuschränken. Die ISO Norm definiert mehr als 300 Metadatenelemente (Klassen, Attribute, Beziehungen), wobei die meisten davon optional verwendet werden können.
Profile
Profile erlauben es, Abbildungen aus dem umfassenden ISO-Metadatenmodell für spezifische Anwendungen zu erstellen. In jedem Profil muss das minimale ISOMetadatenmodell vollumfänglich integriert sein. Zudem kann das Bedürfnis bestehen,
ein Profil zu erweitern.
Erweiterungen
Ein Profil kann mit eigenen Metadatenelementen oder sonstigen Änderungen erweitert
werden. Die ISO Norm 19115 schreibt im Annex C genau vor, wie die vorgegebenen
Strukturen zu erweitern sind und welche Erweiterungen erlaubt sind.
Umfassendes
ISO Metadatenmodell
(ISO Comprehensive Metadata Profile)
Minimales
ISO Metadatenmodell
(ISO Core Metadata
components)
Erweiterung
Profil XY
15.3
Regeln für die Erstellung von Profilen
1. Vorhandene Elemente dürfen in eigenen Profilen nicht abgeändert werden.
2. Werden in einer neuen Entitätsmenge bereits bestehende Attribute verwendet,
dürfen deren Attribute nicht abgeändert werden.
3. In Erweiterungen ist es erlaubt, ...
... strengere Verbindungstypen festzulegen,
4. ... den Entitäten und Attributen Wertebereiche zu zuweisen,
5. ... bereits vorgegebene Wertebereiche zu kürzen,
6. ... oder zu erweitern.
7. Erweiterungen dürfen aber nicht erlauben, was der Standard verbietet.
3 Schweizer Norm für Metadaten
3.1 Warum braucht es eine Schweizer Norm?
Bestehende Metadateninventare sind entweder nur regional (Kantone), fachlich beschränkt (CDS, GeoMeta, Geostat) oder nicht Internet-tauglich betreffend Suche und
Erfassung von Metadaten. Bisherige Metadatenbanken sind nicht kompatibel untereinander und sind auch nicht kompatibel zu der ISO Norm 19115:2003.
KOGIS ist für die Geodatenkoordination in der Bundesverwaltung verantwortlich und
hatte darum auch bei Metadaten Handlungsbedarf. Da KOGIS nicht ein eigenes "Bundesmodell" entwickeln wollte, wurde in Zusammenarbeit mit einer Arbeitsgruppe aus
Kantonen, Hochschulen und Firmen ein Metadatenmodell definiert, das die minimalen
Anforderungen aller Beteiligten befriedigt, ISO kompatibel ist und welches vom SNV
als Schweizer Norm veröffentlicht wird.
3.2 Von der ISO-Norm zur Schweizer Norm
ISO
19115:2003
Pflichtenheft
geocat.ch
SIK - GIS
CDS
Stellungnahmen
zum Entwurf
Arbeitsgruppe
SNV - TK 151
SNV
Vernehmlassung
15.4
Schweizer Norm
SN 612050
Pilot
geocat.ch
GM03
Metadatenmodelle
Catalog Gateway
geocat.ch
INTERLIS
Beschreibung
Um die Anliegen der Beteiligten in der Schweiz zu berücksichtigen, wurden die bestehenden Metadatenbanken der Schweizerischen Informatik Konferenz GIS (SIK-GIS) und
des Bundesamtes für Wald und Landschaft (CDS) mit der ISO-Norm verglichen. Daraus
entstand ein erster Entwurf eines Schweizer Metadatenprofils, in dem bereits Teile der
ISO-Norm weggelassen wurden. Andere Teile wurden als Erweiterung neu modelliert.
Man war sich bewusst, dass mit dem Vergleich lediglich zweier bestehender Metadatenbanken noch nicht alle Bedürfnisse abgedeckt sein würden. Stellungnahmen von
Bundesämtern, Kantonen und weiteren interessierten Stellen ergaben zusätzliche Bedürfnisse. Das überarbeitete Metadatenmodell war Grundlage für den Schweizer
Normentwurf, der Ende 2003 in eine offizielle Vernehmlassung geschickt wurde. Die
Resultate dieser Vernehmlassung wurden in einer Arbeitsgruppe (SNV/TK151) besprochen. Diese Arbeitsgruppe, bestehend aus Vertretern aller interessierten Stellen,
entschied in jedem Fall darüber, ob eine Eingabe berücksichtigt wurde oder nicht. Daraus wurde ein definitives Modell erarbeitet, welches Grundlage für die Schweizer Norm
ist.
Parallel zur Erarbeitung der Schweizer Norm wurde das Portal und der Metadatenserver geocat.ch spezifiziert und entwickelt (siehe Kapitel 4).
3.3 Weshalb ISO als Grundlage?
x
ISO ist die internationale Organisation für weltweite Standards.
x
CEN ist das Europäische Pendant zu ISO und wird ISO 19115:2003 übernehmen.
x
Die Schweiz ist Mitglied von CEN und deshalb verpflichtet, deren Normen zu übernehmen, also auch ISO 19115:2003.
x
Nur auf der Basis des internationalen Standards ISO 19915:2003 wird ein Datenaustausch mit anderen Ländern möglich.
3.4 Unterschiede ISO Norm - CH Norm
Die Modell-Beschreibung in UML in der Norm ISO 19115:2003 ist zu allgemein gehalten
für eine konkrete Umsetzung. Aus diesem Grund wurde in der Schweiz das Modell detaillierter in INTERLIS 2, dem Schweizer Standard für Datenmodellierung und Datenaustausch, modelliert und mit UML-Notation dokumentiert. Dadurch wird der Konkretisierungsgrad erhöht und ein Datenaustausch ermöglicht. INTERLIS 2 beinhaltet Codierungsregeln zur automatisierten Generierung einer XML-Schema-Beschreibung, welche maschinenlesbar und zum Aufbau einer Datenbankstruktur und einer Applikation
verwendet werden kann. Mit diesen Regeln entfällt der Aufwand, neben einer UMLBeschreibung eine XML-Beschreibung in Handarbeit zu erstellen, wie es ISO mit der
Norm 19139 zurzeit macht.
Wie das Metadatenmodell der ISO kennt auch das Schweizer Metadatenmodell zwei
Profile, GM03Core und GM03Comprehensive, welche beide die ISO-Core Metadatenelemente enthalten. Es wurde jedoch ein anderer Ansatz der Modellierung gewählt (siehe Abbildung): ISO definiert ein möglichst umfassendes Metadatenmodell (Profil ISOComprehensive), schreibt vor, welche Elemente in jedem Profil enthalten sein müssen
(ISO-Core) und überlässt es dann jeder Anwendergruppe, daraus ein eigenes Profil zu
definieren. In der Schweiz dagegen, wird in die andere Richtung modelliert. Als minimaler Kern wird GM03Core definiert und durch Vererbung zu GM03Comprehensive
erweitert. Die Vorteile des Vorgehens in der Schweiz gegenüber der ISO ist die bei allen
15.5
Profilen identische Grundlage, GM03Core, und somit ein garantierter gemeinsamer
Nenner für den Austausch.
GM03Core
Metadatenmodell
Comprehensive
Metadatenmodell
Lokales
Metadatenmodell
Core
Metadatenmodell
Lokales
Metadatenmodell
GM03Comprehensive
Metadatenmodell
Lokales
Metadatenmodell
Lokales
Metadatenmodell
Lokales
Metadatenmodell
3.5 Grundsätze bei der Ausarbeitung der Schweizer Norm
Als Grundlage wurde ISO 19115:2003 Metadata gewählt:
x
Alle Metadatenelemente aus ISO-Core werden auch in GM03Core übernommen.
x
Es werden alle Metadatenelemente oder Klassen übernommen, die aus den Bedingungen und Vorgaben der Norm obligatorisch sind.
x
Es werden die Metadatenelemente definiert, welche notwendig sind, um die bestehenden Schweizer Datenkataloge abzudecken.
Die Kompatibilität zu ISO 19115:2003 wird soweit sinnvoll sichergestellt:
x
Erweiterungen sind nach den Regeln in Anhang C der ISO-Norm modelliert (z.B.
gesetzliche Informationen „Legislation Information“).
x
Die für die Schweiz notwendige Mehrsprachigkeit ist nach Anhang J der ISONorm umgesetzt.
In einzelnen Fällen musste von der ISO-Norm abgewichen werden, damit eine brauchbare Lösung gefunden werden konnte:
x
verantwortliche Stelle („Responsible Party“)
autorisierte Stelle („Authority“) und Identikator („Identifier“)
x
Wiederverwendung von Daten in mehreren Instanzen (z.B. „Responsible Party“,
Koordinatensystem, etc.) bedingt Abweichung bei der Modellierung der Beziehungen
3.6 GM03 Metadatenmodell
Um eine minimale Beschreibung von Geodaten zu garantieren, wird das minimale Metadatenmodell GM03Core definiert. Zu GM03Core gehören die Metadatenelemente, mit
welchen mindestens folgende Fragen beantwortet werden können:
15.6
x
Existiert ein Datenbestand zu einem bestimmten Thema? (WAS)
x
Gibt es den Datenbestand zu einem bestimmten Ort? (WO)
x
Bei wem erhalte ich diese Daten? (WER)
x
In welcher Form kann ich die Daten beziehen? (WIE)
x
Wann oder in welcher Periode wurde der Datenbestand erstellt oder zuletzt nachgeführt? (WANN)
Das Modell GM03Core umfasst nur die wichtigsten Elemente und deckt nicht alle Anforderungen ab. Deshalb wurde ein umfassenderes Modell GM03Comprehensive ausgearbeitet, das alle Elemente von ISO enthält und weitere Bedürfnisse der Beteiligten
abdeckt.
3.7 Anwendungsbereich der Schweizer Norm SN612050
Die Norm befasst sich mit Metadaten für Geodaten und gilt für Betriebe, die für die Erfassung, Verarbeitung, Verwaltung und Abgabe von Metadaten verantwortlich sind.
Die Norm bezieht sich zwar auf Geodaten, kann aber sinngemäss auch für andere Anwendungsbereiche eingesetzt werden.
Die Norm regelt, wie Metadaten konzeptionell strukturiert werden. Sie ermöglicht damit ein einheitliches Verständnis aller an Metadaten interessierten Personen und Stellen.
Sie regelt aber nicht, wie konkrete Einrichtungen (z.B. Datenbanken) aufgebaut sein sollen.
Die Norm entwickelt selbst keine Technik zur präzisen Beschreibung der Festlegungen.
Sie bedient sich dafür existierenden Techniken. Für die Beschreibung des
Datenmodells wird die Unified Modelling Language (UML) und die Datenbeschreibungssprache INTERLIS 2 verwendet.
Die Norm legt den Datenaustausch fest. Als gemeinsames Transferprotokoll wird XML
(Regeln nach INTERLIS 2) verwendet.
4 geocat.ch
4.1 Metadatenportal geocat.ch und Geodatenkatalog
Die Anforderungen an einen Geodatenkatalog lassen sich auf zwei wesentliche Punkte
reduzieren:
x
Der Geodatenkatalog muss über eine Such-Applikation verfügen, damit erfasste
Metadaten gesichtet werden können. Über ein heterogenes und dezentral organisiertes Metadatenportal wird dieser Geodatenkatalog abgefragt und die gewünschten Daten werden dem Benutzer zur Verfügung gestellt.
x
Der Geodatenkatalog muss über eine Administrations-Applikation verfügen, damit die Daten erfasst, verwaltet und aktuell gehalten werden können.
Das Metadatenportal geocat.ch erfüllt genau diese genannten Anforderungen an einen
Geodatenkatalog.
4.2 Konkrete Umsetzung
Das Hauptziel besteht darin, auf nationaler Ebene ein Portal für die Gesamtheit aller
geographischen Metadaten zu verwirklichen. Es wird die Einführung einer dezentralisierten Infrastruktur beabsichtigt, welche die dezentralisierte Verwaltung und den Zugang auf alle angeschlossenen Metadatenkataloge erlaubt.
15.7
Portal für die
Suche
Gateway
Metadatenkatalog mit
seinen Administrationsund Verwaltungstools
user
Benutzer
(Oberfläche)
user
Discov e ry
Service
1
Catalog
Management
Discovery Service
Partner
Catalog
Gate way
2
A
gateway
manager
Partner
Metadatenbank
Gatew ay and Client of
Metadatabas es
Se arch Server
Komponenten
der Infrastruktur
Metadata
Beziehung zwischen eine
Benutzer und einer
Komponente
Informationsfluss
Database and Tool
Adm inistration
Metadata
Managem e nt
Catalog
Managem ent
Im port / Export
Search Se rve r
3
Catalog
Server
Metadata
Metadatabase
MetaCH
general
administrator
KOGIS
metadata
contributor
Partner and
producer of
Geodata
catalog
administrat
or
A
catalog
administrat
or
metadata
contributor
Partner and
producer of
Geodata
Metadata
catalog
administrat
or
metadata
contributor
B
Partner and
producer of
Geoda ta
C
Es sind zwei Typen von Datenbanken verbunden:
x
Die zentrale geocat.ch-Datenbank, welche erreichbar ist über die Suchapplikation
geocat.ch.
x
Verteilte Datenbanken, die mittels Catalog Gateway mit der Suchapplikation geocat.ch verbunden sind.
Für Datenproduzenten von Metadaten sind drei Partnertypen möglich:
x
Datenmanagement direkt in der zentralen Datenbank.
x
Datenmanagement in eigener Datenbank. Mittels eines Import/Export-Tools werden diese Daten in der zentralen Datenbank für die Suchapplikation verfügbar
gemacht.
x
Datenmanagement in eigener Datenbank, welche durch die Suchapplikation über
den Catalog Gateway abgefragt werden kann.
4.3 Suchportal
Das Suchportal gibt dem Nutzer von Geodaten einen umfassenden und einheitlich
strukturierten Überblick und schnellen Zugriff zu notwendigen Informationen über
Geodaten, ganz gleich, welche Institution die Geodaten anbietet. Dieser Suchdienst wird
nicht zu einer zentralisierten Lösung für die Verwaltung und Verbreitung von geographischen Metadaten verwendet. Im Allgemeinen ist vorgesehen, dass die Metadaten
direkt bei den Geodaten produzierenden Partnern mit Hilfe der innerhalb ihrer Institution verfügbaren Infrastruktur verwaltet werden (Partner C).
15.8
Die Applikation unterstützt zwei Arten der Suche: die einfache Textsuche und die ausführliche Suche, bei der nach jedem Element gesucht werden kann. Beiden Such-Arten
gemeinsam ist die geographische Suche nach einer Gebietsbezeichnung (z.B. Kanton
Bern), innerhalb eines umhüllenden Rechtecks oder innerhalb eines frei definierbaren
Polygons.
Der Suchdienst muss deshalb einen koordinierten und transparenten Zugriff auf verschiedenartige Metadatenbanken ermöglichen. Die Funktionstüchtigkeit einer solchen
Lösung bedingt die Verwendung eines gemeinsamen Protokolls für Abfrage und Ergebnis. Dieses Protokoll, in SOAP (Simple Object Access Protocol) beschrieben, ist relativ kostengünstig implementierbar, sowohl für relationale Datenbanken als auch für
XML basierte Lösungen.
geocat.ch
Discovery Client
Geocat.ch
Portal
Gateway Protokoll
Gateway
Server(s)
Anfrage (HTML)
Anfrage(n)
Resultat(e) in XML
Konsolidierung
der Resultate
Präsentation der Resultate
Detaillierte Anfrage (HTML)
GM03 Anfrage(n)
GM03 Resultat(e) in XML
Präsentation der Resultate
aus GM03 (HTML)
Quellenangaben
x
Vermessung und Geoinformation - GM03 - Metadatenmodell, Ein Schweizer Metadatenmodell für Geodaten, SN 612050, Working Draft Version 1.4
x
ISO Norm 19115:2003, Geographic Information - Metadata
x
Aufbau eines Nationalen Metadaten-Portals als Teil einer Nationalen GeodatenInfrastruktur in der Schweiz, Referat von D. Angst (ITV Geomatik AG) und A.
Schneider (KOGIS), AGIT 2004 in Salzburg
x
Pflichtenheft geocat.ch Metadatenkatalog für Geodaten, August 2002
x
Catalog Gateway Protocol, Mai 2004, KOGIS, Version 0.99
15.9
16
Interoperabilität
Nicht nur eine Frage der Technologie
Willy Müller, Informatikstrategieorgan Bund
Willy Müller
Informatikstrategieorgan Bund
Friedheimweg 14
CH-3003 Bern
Tel :
Fax :
E-Mail :
+41 31 325 90 35
+41 31 322 45 66
Interoperabilität im Geoinformationsbereich ist das Thema dieser Tagung. Aber was ist
Interoperabilität? Nach der Definition in [IEEE 90] ist es, die Fähigkeit von zwei oder
mehreren Systemen oder Komponenten, Informationen auszutauschen und die Information, welche ausgetauscht wurde, zu nutzen. In unserem Kontext geht es primär um
die Möglichkeit, geografische Daten auszutauschen. Bis zu einem gewissen Grad ist Interoperabilität auf irgendeine Weise fast immer gegeben. So kann z.B. ein Vermessungsbüro einen Plan erstellen, ihn auf Papier ausdrucken und per Post an ein anderes Büro
versenden, das ihn manuell in sein System überträgt. Wenn wir damit zufrieden wären,
wären wir wohl nicht hier. Wir streben eine bessere Interoperabilität an. Das heisst, Interoperabilität kann besser oder schlechter sein. Die Güte der Interoperabilität hat dabei
zwei Dimensionen: die eine korreliert negativ mit dem Aufwand und den Kosten, die
nötig sind, um Daten elektronisch auszutauschen und weiter zu verwerten. Die andere
korreliert positiv mit der Menge der Systeme oder Komponenten, welche untereinander
Informationen austauschen und weiterverwenden können. Lassen sie uns daher für unseren Kontext die Definition von [IEEE 90] präzisieren: Interoperabilität ist die Fähigkeit
möglichst vieler Systeme oder Komponenten, Daten elektronisch auszutauschen und sie
mit möglichst wenig Aufwand, insbesondere ohne manuelle Bearbeitung, weiter zu
verwenden.
1 Der Bundesrates will eine reibungslose elektronische
Zusammenarbeit
Was hat der Staat zur Interoperabilität – insb. im Bereich der Geoinformationen - zu sagen? Soll er sich dazu überhaupt äussern, oder soll er besser die Finger davon lassen?
Der Schweizer Staat - und das gilt für Bund, Kantone und Gemeinden gleichermassen sieht sich in mehrerlei Hinsicht mit der auf den ersten Blick eher technischen Fragestellung konfrontiert:
1. Er hat die Aufgabe, für Einwohnerinnen und Einwohner wie auch die Wirtschaft
förderliche Rahmenbedingungen zu schaffen.
2. Als Produzent und wichtiger Konsument von Geoinformationen ist er direkt betroffen.
3. Er muss sich mit den Folgen verbesserter Interoperabilität auseinandersetzen.
Der Bundesrat erachtet die Förderung der Informationsgesellschaft in der Schweiz als
prioritär. Darüber hinaus will er seine Regierungs- und Verwaltungstätigkeit effizient,
flexibel und transparent gestalten. In seiner eGovernment-Strategie hat er dazu drei
Stossrichtungen definiert:
1. Voraussetzungen schaffen: Die organisatorischen, technologischen und sicherheitsspezifischen Voraussetzungen für eine reibungslose Zusammenarbeit innerhalb der Verwaltung sollen geschaffen werden.
2. Service excellence: Der Zugang zu den staatlichen Dienstleistungen – und dazu
gehört auch die Bereitstellung einer ganzen Menge von Geoinformationen - soll
für Privatwirtschaft, Bürgerinnen und Bürger leichter und transparenter werden.
3. Vernetzung: Angestrebt wird die ‚elektronische Integration’ zwischen den Verwaltungsstellen der verschiedenen Staatsebenen (Bund, Kantone und Gemeinden) sowie zwischen dem Staat und seinen Partnern (öffentliche Hand, Wirtschaft und Gesellschaft).
16.1
Interoperabilität: nicht nur eine Frage der Technologie
Die Arbeiten zur Förderung der elektronischen Zusammenarbeit im Bereich der Geoinformationen sind also zu sehen als Teil einer übergeordneten Strategie. Zu diesem
Zweck wurde u.a. KOGIS, die Koordinationsstelle für geografische Information und
geografische Informationssysteme, ins Leben gerufen (vgl. www.kogis.ch). Die Stossrichtungen ‚Voraussetzungen schaffen’ und ‚Vernetzung’ haben eine verbesserte Interoperabilität zum Ziel.
Um die Interoperabilität zu steigern, sind dabei Massnahmen auf unterschiedlichen Ebenen notwendig. In Anlehnung an das Modell, welches wir im Rahmen der EGovernment-Architektur der Schweiz entwickelt haben [eGovCH], sind insbesondere
zu unterscheiden:
Politische, rechtliche und
organisatorische Rahmenbedingungen
Daten-Services
Infrastruktur-Services
Technische Basis
Directory Services
Fach-Services
Abb. 1 : Bereiche, in denen zur Erreichung einer realen Interoperabilität, auf einander
abgestimmte Massnahmen nötig sind.
x
x
x
x
x
x
Technologische Infrastruktur: Rechner, Speicher und Netzwerke für die elektronische Verarbeitung und den Datenaustausch,
Infrastruktur-Services: Nicht fachspezifische Anwendungen, welche den sicheren
und zuverlässigen Datenaustausch ermöglichen,
Directory-Services: Elektronische, bei Bedarf maschinenlesbare Verzeichnisse über Kommunikationspartner und elektronisch zugängliche Dienstleistungen
Daten-Services: Definition der Syntax und Semantik, welche gewährleistet, dass
Partner ausgetauschte Daten ohne grössere Probleme weiterverwenden können,
Fach-Services: Fachanwendungen, welche so geschrieben sind, dass sie mit anderen Fachanwendungen zusammenarbeiten können,
Organisation, Prozesse und Recht: Organisatorische und rechtliche Rahmenbedingungen, welche Interoperabilität zulassen und die Spielregeln für die elektronische Zusammenarbeit festlegen.
Erst wenn auf allen Ebenen die geeigneten Voraussetzungen geschaffen sind, ist ein reibungsloses Zusammenspiel möglich. Nachfolgend wird exemplarisch auf einige kritische Themenkreise eingegangen. Zur Illustration wird in der Regel auf Beispiele im
Geoinformationsbereich Bezug genommen.
16.2
2 Erste Stossrichtung: Voraussetzungen schaffen
Damit Systeme ohne menschliche Intervention Daten austauschen können, müssen sie
sich verstehen. Das ist nur möglich, wenn sie die gleiche Sprache sprechen. Wir beginnen zu verstehen, wie derartige Sprachen optimalerweise aussehen sollten und wie sie
zu dokumentieren sind. Entsprechende Spezifikationen im Geoinformationsbereich sind
vorhanden und haben - zumindest teilweise - erste Praxistests bestanden (z.B. INTERLIS, GML). Darauf im Detail einzugehen, ist nicht die Aufgabe dieses Beitrags. Bei der
Auseinandersetzung mit der Spezifikation von Klassen, Konsistenzregeln und Tags vergisst man jedoch gerne, dass es letztlich um mehr geht, als die präzise Spezifikation. Auf
drei Aspekte soll im Folgenden speziell hingewiesen werden:
x
x
x
der Kampf um die richtige Sprache
die Vergabe von Namen und Identifikatoren
Verknüpfungen von Daten unterschiedlicher Domänen.
2.1 Der Kampf um die richtige Sprache
Unglücklicherweise gibt es keine Naturgesetze, welche sicherstellen, dass es nur eine
einzige Sprache gibt. Üblicherweise bilden sich daher mehr oder weniger unabhängig
voneinander verschiedene Sprachgemeinschaften mit je eigenen Konventionen. Das ist
bei den Geoinformationen nicht anders: Neben nationalen und internationalen Standardisierungsgremien setzen Softwareanbieter ihre eigenen Datenaustauschformate fest.
Solange Mitglieder einer Sprachgemeinschaft lediglich unter sich Daten austauschen
möchten, ist dies nicht weiter problematisch. Andernfalls stellen unterschiedliche Sprachen jedoch ein ernsthaftes Interoperabilitätsproblem dar.
Sprachen dienen leider nicht nur der Kommunikation, sondern genauso der Ausgrenzung. Der Entscheidung, wer an der Sprachgemeinschaft teilhaben soll, kommt daher
strategische Bedeutung zu. Der Bundesrat spricht sich explizit für eine Vernetzung innerhalb der Schweiz und darüber hinaus aus. Gelingt dies, wird sich dadurch allerdings
der Wettbewerb zwischen den betroffenen Software- und Datenanbietern verschärfen.
Nischen, die sich der eine oder andere geschaffen hat, gehen verloren.
2.2 Verknüpfungen
Die Abgrenzung, was als Geoinformation zu betrachten ist, fällt schwerer, als auf den
ersten Blick zu erwarten wäre. Im weiteren Sinn fällt darunter alles mit einem geografischen Bezug, d.h. alles, was in Beziehung zu einer Koordinate oder einem Areal stand,
steht oder stehen wird. Bei genauerem Hinsehen sind das potentiell alle Objekte, welche
eine räumliche Ausdehnung besitzen. Denn was eine räumliche Ausdehnung hat, befindet sich zwangsweise zu einem bestimmten Zeitpunkt an einem bestimmten Ort:
Golfclubs, Webcams, Mobilfunkantennen, Raucher, Rinder, Gletscherhahnenfüsse, Gasleitungen, Niederschläge. Aber damit nicht genug! Selbst alles was mit einem solchen
Objekt in Beziehung steht, kann zum Teil von Geoinformationen werden: Windgeschwindigkeiten, Kindersterblichkeit, Sexpraktiken oder Vorlieben für Rotwein.
Was bleibt noch übrig? – Nicht viel! Da liegt es nahe, einen zusätzlichen Begriff einzuführen: die Referenzdaten. Referenzdaten sind Geoinformationen, welche herangezogen
werden können, um weitere Informationen darauf zu projizieren. Die Idee ist einleuchtend, den Begriff präzise zu fassen, jedoch schwierig. Er wurde in den Entwurf des neuen Geoinformationsgesetzes aufgenommen, und hat in den vorberatenden Gremien zu
entsprechend heftigen Diskussionen geführt. Bei genauerem Hinsehen enthalten selbst
16.3
einfachste Geoinformationen Angaben zu 'Fremdobjekten', beispielsweise Länder, Kantone oder Gemeinden, Nationalstrassen, Hauptstrassen und Nebenstrassen, Haus- und
Parzellennummern. Und mit Sachinformationen kombinierte Geoinformationen - z.B.
eine mit geologischen Informationen angereicherte Karte - kann von anderen als Grundlage für weitere Arbeiten genutzt werden - beispielsweise die Planung von AtomEndlagern.
Wir möchten ein - möglichst weltumspannendes Interoperabilitätsnetz für Geoinformationen schaffen. Dazu sind Normen zur Abbildung von räumlichen Informationen notwendig, jedoch, wie diese Beispiele verdeutlichen, nicht hinreichend. Zusätzlich brauchen wir auch Normen zur Abbildung der Angaben, welche mit ihnen verknüpft werden sollen. Interoperabilität im Bereich der Geoinformationen kann und darf daher
nicht bei den Geoinformationen im engeren Sinn stehen bleiben, sonst ist sie nur von
begrenztem Nutzen.
2.3 Vergabe von Namen und Identifikatoren
Was wären Landeskarten ohne Ortsbezeichnungen oder Stadtpläne ohne Strassennamen? Im Gegensatz zur allgemeinen Syntax und Semantik ist es oft nicht, oder nur bedingt möglich, derartige Namen oder Identifikatoren in Normen oder Standards festzuhalten, dennoch sind sie für die Interoperabilität unabdingbar. Nur wenn zwei Kommunikationspartner demselben Objekt gleich sagen, wissen sie, dass sie vom Gleichen
sprechen. Neben Standardisierungsgremien, welche die notwendigen Normen erarbeiten, herausgeben und pflegen, brauchen wir Institutionen, welche Objekte, zu denen wir
Informationen austauschen möchten, identifizieren und die Listen der vergebenen Identifikatoren aktuell und für alle Betroffenen elektronisch zugänglich publizieren.
Idealerweise ist überschneidungsfrei definiert, wer für welche Namensräume zuständig
ist. Diese aus technischer Sicht einfach aufzustellende Forderung enthält jedoch im Einzelfall einigen Zündstoff. So ist sich die Staatengemeinschaft nicht einig, ob Taiwan ein
eigenständiger Staat ist oder lediglich eine – abtrünnige - Provinz Chinas. Die Anerkennung eines Staates ist ein politischer Akt, der im schlimmsten Fall zum Krieg führen
kann.
Vor dem Zeitalter der Vernetzung hat jede Anwendung notgedrungen die von ihr benötigten Daten selbst verwaltet und identifiziert. Möchte man sie austauschen, bringt das
Probleme. In unterschiedlichsten Fachgebieten sind Arbeiten im Gang, diese anzugehen.
Ein Beispiel sind die Bemühungen zur Einführung von Identifikatoren für juristische
und natürliche Personen.
Noch ist für viele Objekte nicht verbindlich geregelt, wer ihre Namen vergibt. Die Festlegung, wer wofür Namen vergibt, und das Akzeptieren dieser Definitionsgewalt durch
die Kommunikationsgemeinschaft sind primär organisatorische und politische Entscheide, und diese laufen selten ohne Auseinandersetzungen und Machtkämpfe ab.
Hier liegt noch einige Arbeit vor uns.
3 Zweite Stossrichtung: Service excellence
Interoperabilität ist kein Selbstzweck. Wir arbeiten daran, weil wir uns davon Vorteile
versprechen. Diese Vorteile nutzen wir jedoch erst, wenn die Systeme in Realität zusammenarbeiten. Der Bundesrat hat zum Ziel, dass die Behörden die Möglichkeiten der
Informationstechnologien nutzen, um der Privatwirtschaft, Bürgerinnen und Bürgern
16.4
den Zugang zu ihren Dienstleistungen erleichtern. Dabei ist sowohl die eingehende wie
die ausgehende Kommunikation betroffen:
Dazu müssen:
x
x
x
x
die Datenproduzenten die Daten elektronisch erstellen (was, z.B. in der amtlichen
Vermessung noch nicht überall der Fall ist)
die Daten in geeigneten Formaten und zu realistischen Konditionen elektronisch
zur Verfügung gestellt werden
eine geeignete Infrastruktur für den Datenaustausch bereitstehen
die Datenempfänger über die geeignete Infrastruktur verfügen, um die Daten einzulesen und zu verarbeiten.
Die aufgeführten Bedingungen mögen banal erscheinen. In der Praxis soweit zu kommen, dass z.B. die Pläne aller Grundstücke in der Schweiz tatsächlich elektronische erfasst sind und die Programme, welche sie verwalten, dazu in der Lage sind, sie elektronisch auszutauschen, ist alles andere als trivial. Dazu sind ist Überzeugungsarbeit bei
Amtlichen Vermessern, Gemeindepräsidenten und Politikern notwendig und sind teilweise grössere Investitionen unumgänglich. Selbstverständlich arbeitet auch der Bund
daran, seine Geoinformationsdaten einfach elektronisch zugänglich zu machen.
4 Dritte Stossrichtung: Vernetzung
Wir streben nach einer dichteren Vernetzung und besseren Interoperabilität. Systemtheoretisch betrachtet, modifizieren wir damit die Interaktionsregeln innerhalb eines dynamischen Systems. Dies muss unweigerlich Auswirkungen auf das Gesamtsystem haben: Es wird sich verändern. Ob wir wollen oder nicht, wir werden nicht darum herum
kommen, auf die Veränderungen zu reagieren. Wer strategisch denkt, wird sich nicht
damit zufrieden geben. Er wird die möglichen Veränderungen vorwegnehmen und, so
gut es geht, gestaltend darauf einwirken wollen.
Einige der Felder, in denen Veränderungen bevorstehen, sind die folgenden:
x
x
x
x
Tarifierung und Finanzierung
Authentizität und Urheberrecht
Datenschutz
Verantwortung der Datenanbieter
4.1 Die Tarifierungs- und Finanzierungsmodelle sind zu
überarbeiten.
Noch vor nicht allzu langer Zeit hatten Geoinformationen die Form von Karten oder
Plänen und konnten daher wie klassische Güter gehandelt werden. Werden sie in Form
von digitalen Datensätzen weitergegeben, ist das nur noch bedingt möglich. Denn digitale Informationen können in Sekundenbruchteilen kopiert, transportiert, neu zusammengestellt, verändert oder mit neuen Informationen verknüpft werden.
Die elektronische Weitergabe schafft jedoch ein neues Potential: Für Partner, Behörden
und auch Unternehmen, wird es leichter, Daten einzukaufen und sie zu neuen Produkten zu verarbeiten, welche sie dann ihrerseits weiterverkaufen.
So gesehen wird der Staat gewissermassen zum Rohstofflieferanten für die weiterverarbeitende Industrie. Für die nachgelagerten Informationsverarbeiter wird die Nutzung
der Rohdaten umso interessanter, je kostengünstiger er sie erwerben kann. Ist ihr Preis
zu hoch, werden seine eigenen Produkte zu teuer und dadurch weniger attraktiv.
16.5
Der Bundesrat verfolgt die Strategie, seine Geodaten den Nutzern zu möglichst günstigen Preisen zur Verfügung zu stellen und so für die Wirtschaft förderliche Bedingungen
zu schaffen. Er ist bemüht, die Kantone zu einer ähnlichen Strategie zu bewegen. Die
gleichzeitig verfolgten Sparanstrengungen auf Seiten des Staates erschweren allerdings
eine konsequente Umsetzung.
4.2 Urheberrecht und Authentizität
Daten, welche elektronisch weitergegeben werden, sieht man ohne spezielle Massnahmen den Urheber nicht mehr an, und sie können ohne sein Wissen und seine Zustimmung weiterbearbeitet, ja gar weiterverkauft werden. Ich kann ohne grössere Probleme
Video-Dateien vom Internet herunterladen, mit einfachen Programmen bearbeiten, zusammenkopieren und das Resultat unter meinem Namen weiterverbreiten. Dies ist bei
Geoinformationen nicht anders.
Die einfache Kopierbarkeit stellt ganze Geschäftsbereiche vor bisher ungelöste Probleme. Eingespielte Verrechnungsmechanismen werden ausgehöhlt. Die Durchsetzung des
Urheberrechts in der E-Welt ist ein noch nicht gelöstes Problem. Was tun wir z.B. wenn
das Kartenwerk der Landestopographie plötzlich in die Hände einer Gruppe gerät, welche es auf einem Server in Übersee ins Internet stellt?
Die einfache Kopierbarkeit und Modifizierbarkeit produziert noch ein weiteres Problem:
Woher weiss ich, ob ich eine autorisierte Version der Daten in den Händen habe? Wie
kann ich z.B. sicher sein, ob es sich beim Vermessungsplan, den ich am Bildschirm sehe,
um eine autorisierte Kopie handelt?
Zwar gibt es erste technologische Ansätze, die hier Abhilfe schaffen wollen wie z.B. die
des Digital Rights Management (DRM), doch diese eignen sich für den uns interessierenden Kontext nur bedingt, da sie für Objekte konzipiert sind, welche als Einheit auf
einem bestimmten Gerät abgespielt werden.
Die gesetzlichen Grundlagen in diesem Bereich sind erst rudimentär vorhanden, die nötigen technischen Lösungen noch ungenügend.
4.3 Datenschutz
Die einfache Zugänglichkeit und Verknüpfbarkeit von Geoinformationen bringt auch
neue Probleme mit sich. Eines besteht darin, dass es schwieriger wird, Informationen
geheim zu halten. Angaben über dasselbe Gebiet aus verschiedenen Quellen können mit
relativ geringem Aufwand verglichen und Unterschiede ausgewertet werden. So ist es
möglich, Satellitenaufnahmen mit von den lokalen Behörden herausgegebenen Karten
abzugleichen. Dabei können gerade Informationen, welche bewusst weggelassen wurden, Geheimdiensten interessante Aufschlüsse geben...
Oder Personendaten können mit Geoinformationen verknüpft werden. Bringt man Angaben im Telefonbuch, Gebäudeadressen und Kartenmaterial zusammen, kann auf
Knopfdruck sichtbar gemacht werden, wer wo wohnt. Trägt eine Person ein eingeschaltetes Handy bei sich, ist ihr Aufenthaltsort bekannt. Ohne grössere Probleme könnte auf
einer Web-Seite eine Karte aufgeschaltet werden, welche anzeigt, wo wer sich gerade
befindet. Derartige Informationen können in Katastrophensituationen helfen, Personen
aufzufinden. Die Polizei kann sie nutzen, um Verbrecher zu fassen. Sie sind jedoch genauso interessant für Privatdetektive, Geheimdienste und Terroristen.
Wenn wir die Interoperabilität verbessern, dürfen wir Massnahmen nicht vernachlässigen, welche sicherstellen, dass mit den Informationen kein Missbrauch getrieben wird.
16.6
Gegenwärtig tun sich Staat und Politik schwer bei der Festlegung, wie mit elektronischen Daten umgegangen werden, was erlaubt und was verboten sein soll. Manche gehen beispielsweise soweit, die elektronische Version der Schweizerkarte zu schützenswerten Personendaten zu erklären, da sie potentiell mit Personendaten verknüpft werden können.
4.4 Verantwortung der Datenanbieter
Interoperabilität ist kein abstrakter Wunsch. Geodaten sind mehr und mehr elektronisch
zugänglich, und der Markt beginnt die sich daraus ergebenden Möglichkeiten zu nutzen. Es ist absehbar, dass sich nach und nach ganze Wertschöpfungsketten aufbauen
werden. Ob gewollt oder ungewollt werden die Abnehmer von Daten sich mit steigenden Kundenwünschen konfrontiert sehen. Diese betreffen einerseits die Stabilität des
Angebots: Wer Daten eines anderen nutzt, um daraus eigene Produkte zu generieren,
zählt darauf, dass diese auch in Zukunft verfügbar sein werden. Der volkswirtschaftliche Nutzen wird dann am grössten sein, wenn die Datenanbieter ihre Produkte präzise
definieren und ihren Kunden garantieren können, dass ihr Angebot über längere Zeit
zur Verfügung stehen wird.
Andererseits wird nicht zu vermeiden sein, dass die Kunden auf den Geschmack kommen und neue Wünsche vorbringen werden, welche die Anbieter unter Druck setzen.
So ist beispielsweise vorhersehbar, dass die Forderungen nach höherer Aktualität der
Daten steigen werden.
5 Schlusswort
Ist Interoperabilität im Geoinformationsbereich Realität, entsteht logisch gesehen ein
riesiger Datenpool, zu dem unterschiedliche Parteien ihren Beitrag leisten. Die Beteiligten, dazu gehört der Staat genauso wie betroffene private Unternehmen, müssen sich
darauf einigen, wer welchen Beitrag zu diesem Datenpool leistet und wie damit umgegangen werden soll. Der Datenpool an sich stellt ein volkswirtschaftlich nicht zu unterschätzendes Kapital dar, dessen Wert mit der Menge der darin integrierten Informationen steigt. Wie dieses Kapital bewirtschaftet – oder nicht bewirtschaftet – wird, entscheidet darüber, wie gross die Wertschöpfung sein wird.
[eGovS 99]
Regieren in der Informationsgesellschaft. Die eGovernment-Strategie des Bundes. 13. Februar 2002.
http://www.isb.admin.ch/imperia/md/content/egoverment/egov_stra
tegie/de/egov_strat_bv_dt.pdf
[IEEE 90]
Institute of Electrical and Electronics Engineers. IEEE Standard Computer
Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York,
NY: 1990.
[IGES 98]
Strategie des Bundesrates für eine Informationsgesellschaft in der Schweiz vom
18. Februar 1998.
http://www.infosociety.ch/site/propos/references/details.asp?id_fiche
=2867#
[eGovCH 05] eGovCH - eGovernment Architektur Schweiz. Informatikstrategieorgan Bund
(in Vorbereitung).
16.7
17
Interoperabilität auf strategischer und
administrativer Ebene
François Golay, ETH Lausanne
François Golay, Prof. Dr.
Laboratoire de Systèmes d'information géographique
Ecole Polytechnique Fédérale de Lausanne
CH-1015 Lausanne
Tel :
Fax :
E-Mail :
+41 21 693 57 81
+41 21 693 57 90
1 Einleitung
Man kann die Interoperabilität vor allem als eine technologische Antwort auf das Bedürfnis, Geoinformationssysteme zu öffnen, betrachten. Die OGIS spielt weltweit eine zentrale Rolle für die normierte technologische Entwicklung und die damit verbundenen
Systemarchitekturen. Programmmodule, Webservices, etc – erlauben es, eine effiziente
Implementierung zu gewährleisten. Schliesslich erlauben die innerhalb der ISO besonders unternommenen Normungsarbeiten, diese Konzepte dauerhaft zu verankern.
Die vorangegangenen Präsentationen dieses Seminars haben bewiesen, dass das Datensharing nicht nur eine Übereinkunft über den Behälter – die Architekturen – aber
auch über den Inhalt des Datenaustausches erfordert. Welche Daten sind bei einem Austausch beteiligt? Worauf gründen sich Information über gemeinsame Prozesse? Diese
Fragen wurden von Morf und Dorfschmid in der Präsentation „Modellstandardisierung
oder semantische Interoperabilität“ [Morf 2005] behandelt. Die Erarbeitung und Normalisierung von gemeinsamen Modellen stellen eine Antwort auf diese Fragen dar, genauso
wie die Identifikation und die Definition von Referenzen, die interoperable Systeme
verknüpfen.
Die vorhergehenden Redner haben schliesslich betont, dass die Vielfalt der beteiligten
Personen und Institutionen, die im Sharing von Informationen [Buser 2005] und Diensten einbezogen wurden, eine adäquate Organisation erfordert, die die institutionelle
Verantwortung jedes einzelnen Beteiligten respektiert.
Wir stellen in diesem Beitrag fest, dass es kein wirksames Datensharing ohne Anerkennung und Berücksichtigung der Aufgaben und Strategien von jeder der beteiligten Institutionen, insbesondere von Gemeinden, Kantonen und dem Bund, geben wird. Wir postulieren, dass die technische und semantische Interoperabilität nur im Rahmen einer guten, strategischen und administrativen Interoperabilität der beteiligten Institutionen verwirklicht werden kann.
2 Föderalistische Organisation der Schweiz und Aufgaben
der beteiligten Institutionen
Im Rahmen der Vorstudie zum Projekt e-geo.ch: Organisatorische und technische Aspekte
[Moreni & al. 2003] wurde eine Verschachtelung der Entscheidungsebenen auf dem
Staatsgebiet am Beispiel der Schweiz vorgeschlagen (Figur 1). Man kann unterschiedliche Positionierungen der verschiedenen staatlichen, kantonalen und kommunalen Beteiligten feststellen.
Die Arbeitsbereiche der Akteure der verschiedenen Entscheidungsebenen können sich
jedoch, ihren Verantwortlichkeiten im Bodennutzungsmanagement entsprechend, erheblich unterscheiden.
17.1
Kanton
Stadt
Gem.
Kanton
Gem.
Kanton
Stadt
Gem.
Privatgesellschaften
Etat
Bund
Einrichtungen öffentlichen Rechtes, z. B. Elektrizitätswerke usw.)
LOKAL
REGIONAL
NATIONAL
Figur 1 : Verschachtelungen der Entscheidungsebenen auf dem Staatsgebiet
Somit:
17.2
x
Sind auf lokaler (kommunaler) Ebene die Grund- und Bodenangelegenheiten
vorherrschend. Es handelt sich zuallererst darum, die rechtliche und technische
Grund- und Bodenverordnung verlässlich zu dokumentieren und als Bezugseinheit ist die Parzelle ausschlaggebend. Die Lokalisierung von technischen Infrastrukturen, die Verwaltung des bebauten Kulturgutes, usw., sind typische Beispiele für diese Ebene.
x
Auf regionaler (kantonaler) Ebene ist die räumliche Information vor allem ein
Werkzeug für die Raumplanung. Die Erwartungen bestehen hauptsächlich im
Erhalt von korrekt aktualisierten, und zusammenhängenden Informationen zur
Bodennutzung und der Umwelt. Öffentliche Gelände, verseuchte Gebiete, Bodennutzungsstatistiken, Räume, die durch natürliche Gefahren bedroht werden,
sind einige Beispiele für Informationen auf diesem Niveau.
x
Auf nationaler (eidgenössischer) Ebene geht es vor allem darum, die Konzeption
und Planung von kohärenten Strategien durch zuständige Organisationen und
Einrichtungen möglich zu machen. Ein globaler und homogener Zugang zu den
Informationen, ohne „Grenzen zwischen den Regionen, stellt eine nötige Vorbedingung dar.
3 Datenintegration zwischen verschiedenen Entscheidungsebenen
Die Primärdaten, die für die Erfüllung der Aufgaben dieser verschiedenen strategischen
Niveaus notwendig sind, sind jedoch teilweise dieselben: Indikatoren, welche die Landschaftsnutzung im Kantonsmassstab angeben, können von den kommunalen Rahmennutzungsplänen abgeleitet werden. Bodennutzungsstatistiken auf nationaler Ebene
können anhand lokaler Bodennutzungsangaben erstellt werden, usw. Aus Effizienzgründen sollen die entsprechenden Daten nur ein einziges Mal erstellt und verwaltet werden,
und zwar auf der am besten geeigneten Ebene (Dieses Prinzip wird im [INSPIRE 2002]Bericht für geographische Infrastrukturen und Daten beschrieben)
Die oben aufgeführten, speziellen Bedürfnisse jeder Entscheidungsebene müssen unabhängig von der Einrichtung, die mit deren Realisierung beauftragt ist, bei der Datenerfassung und Verteilung berücksichtigt werden. Einige kürzlich aufgetretene Schwierigkeiten zeugen von den Schwierigkeiten, die auf diese Wechselbeziehung der Bedürfnisse zurückzuführen sind
x
Gemeinden, welche Katasterdaten besitzen, geben sich aus Furcht vor einer übermässigen Zentralisierung zurückhaltend, diese Daten der kantonalen Stelle
zu übergeben. Wie sollen kantonale Stellen eine umfassende Verwaltung des
Kantonsgebiets verwirklichen?
x
Hingegen haben Kantone, welche Daten in grossem Massstab besitzen, kein Interesse daran eine klar dokumentierte, systematische Qualität ihrer Daten zu fördern. Diese Daten sind folglich nicht brauchbar für Verwaltungsaufgaben auf lokaler Ebene.
x
Einige Kantone widersetzen sich der Harmonisierung von Datenstrukturen, welche vom Bund verlangt wird, um einen nahtlosen Datenzugang für die ganze
Schweiz zu ermöglichen.
Solche Probleme existieren auch zwischen öffentlichen Einrichtungen und Privaten Unternehmen. Wieso war es z.B. notwendig, das Strassennetz für die Bedürfnisse der automobilen Navigation nochmals zu erfassen?
4 Die Interoperabilität auf strategischer und administrativer
Ebene – eine entwicklungsbedürftige Ressource !
Die Wiederverwendung von Daten zwischen verschiedenen strategischen Ebenen setzt
jedoch voraus, dass jeder Beteiligte einer Entscheidungsebene die Bedürfnisse der anderen Entscheidungsebenen kennt (und anerkennt!), und dass er bereit ist, die Datenerfassung, für die er zuständig ist, gemäss der Bedürfnisse sämtlicher anderer Partner durchzuführen.
Dieser Anspruch betrifft nicht die technischen und organisatorischen Dimensionen der
Interoperabilität, sondern eine Art der Anerkennungsteilung und der Teilung von Zielsetzungen und Aufgaben. Es ist schwieriger die Interoperabilität auf strategischer und
administrativer Ebene durchzuführen, als auf der technischen Ebene, jedoch stellt die
Interoperabilität auf strategischer und administrativer Ebene eine Anforderung an
die technische, semantische und organisatorische Ebene. Diese Anforderung wird im
[INSPIRE 2002] – Bericht beschrieben: administrative interoperability should precede geospatial interoperability.
17.3
Die Berücksichtigung des Grundsatzes der strategischen und administrativen Interoperabilität müsste auch die Annahme und die Umsetzung durch alle Beteiligten erleichtern und eine gute Handhabung der Interoperabilität ermöglichen:
x
Man sollte versuchen, die Datenerfassung und -verwaltung von gemeinsamen
Interesse zu an eine einzige Instanz zu delegieren.
x
Um eine adäquate Qualität dieser Aufgaben zu garantieren, die den wesentlichen Bedürfnissen sämtlicher Partner entspricht, müssen die Normen auf dem
höchsten Entscheidungsniveau definiert werden (SNV/ASN – Normen für die
gesamte Schweiz).
Bibliographie
Buser, R., 2005, Conséquences organisationnelles de l’interopérabilité, Actes de la journée d’étude « Interopérabilité pour l’utilisation généralisée de la géoinformation », mars
2005, A. Carosio éd., ETH Zürich.
INSPIRE, 2002, INSPIRE Architecture and Standards Position Paper, JRC-Institute for Environment and Sustainability, Ispra.
Moreni, C. & al., 2003, Etude préliminaire au projet e-geo.ch: aspects organisationnels et
techniques, Rapport sur mandat de la COSIG, EPFL-LASIG et ETHZ-Geoinformation.
Morf, A. & Dorfschmied, J., 2005, Modèles standardizes ou interopérabilité sémantique,
Actes de la journée d’étude « Interopérabilité pour l’utilisation généralisée de la géoinformation », mars 2005, A. Carosio éd., ETH Zürich.
17.4
18
Interoperabilität in der Praxis
Erfahrungen aus Projekten im In- und
Ausland
Ivo A. Leiss, Ernst Basler + Partner AG
Ivo A. Leiss, Dr.
Zollikerstr. 65
CH-8702 Zollikon
Tel :
Fax :
E-Mail :
+41 44 395 12 80
+41 44 395 12 34
1 Einleitung
Die Interoperabilität bei der Nutzung von Geoinformation ist bei GIS-Projekten im Planungs- und Umweltbereich ein allgegenwärtiges Thema. In der Praxis trifft man auf
verschiedene Aspekte der Interoperabilität:
x
x
x
beim Austausch von Geodaten (z.B. mit Auftraggebern oder Partnerfirmen)
beim Austausch von Applikationen und Systemen (z.B. Businessapplikationen
ohne geografischen Bezug)
beim Austausch von Prozessen (z.B. Service zur Geocodierung von Adressen)
Der vorliegende Beitrag soll die Interoperabilität von Geoinformation am Beispiel von
ausgewählten Projekten der Firma Ernst Basler + Partner AG im In- und Ausland beleuchten. Typische Interoperabilitätsprobleme und deren Lösungsansätze werden aufgezeigt. Die Bedeutung der Interoperabilität für die Zukunft wird bewertet.
2 Beispielprojekte
2.1 Nationale Projekte: Drei kantonale Beispiele
Die Interoperabilität bei der Nutzung von Geoinformation in den Kantonen soll anhand
drei verschiedener GIS-Projekte beleuchtet werden (Tab. 1).
Projektname
(Laufzeit)
Strassenlärm
Zürich
(2000 – 2005)
Auftraggeber
Aufgaben
Projektpartner
Baudirektion des
Kantons Zürich,
Fachstelle Lärmschutz
Portierung des
Strassenlärmkatasters
(Emissionen), GISAnalyse
lärmbetroffener
Gebäude
(Immissionen)
Erstellen einer
Gefahrenhinweiskarte
für den
Naturgefahrenprozess
Hochwasser im Kanton
Luzern, Erstellen eines
Ereigniskatasters
Darstellung von
archäologischen
Informationen
(SPATZ) in einem
Intranet-Kartendienst,
Interaktion zwischen
dem Archäologischen
Informationssystem
und dem Kartendienst
(z.B. Editieren von
Punkten)
Norsonic Brechbühl
AG
F. Preisig AG
GIS-Zentrum Kt.
Zürich
Gefahrenhinweiskarte Hochwasser
Luzern
(2003 – 2005)
Bau-, Umwelt- und
Wirtschaftsdepartemen
t des Kantons Luzern,
Dienststelle Verkehr
und Infrastruktur
SPATZ
Mapserver
Graubünden
(2004 – 2005)
Archäologischer
Dienst, Kanton
Graubünden
Kost+Partner AG
ITECO
Geoinformation und
Vermessung Kt.
Luzern
GIS
Kompetenzzentrum Kt.
Graubünden
GWZ Informatik
Tab. 1 : Übersicht über drei kantonale Projekte. Sie dienen als Grundlage für die nachfolgenden
Überlegungen.
18.1
Interoperabilität in der Praxis: Erfahrungen aus Projekten im In- und Ausland
2.2 Internationale Projekte: Transnationales Internet KartenInformationssystem für Überschwemmungen (TIMIS flood)
Das Projekt TIMIS flood hat zum Ziel, für das internationale Einzugsgebiet der Mosel
und der Nahe ein transnationales Informationssystem für Überschwemmungen aufzubauen. Dabei kommen innovative GIS und IT-Technologien zum Einsatz. TIMIS flood
soll folgende Informationen bereitstellen:
x
x
x
harmonisierte und qualitativ hochstehende räumliche Daten,
Informationen über Gefahr und Risiko sowie
Informationen zur Vorhersage und Warnung.
Sämtliche resultierenden Informationsdienste sollen schliesslich unter einer Plattform
namens TIMIS flood Service kombiniert werden. Dieser Service wird den verschiedenen
Benutzern (Behörden, Wissenschaftler und Öffentlichkeit) im Jahr 2008 zugänglich sein.
Auftraggeber sind sieben verschiedene Behörden aus Luxemburg, Deutschland und
Frankreich. Die Firma Ernst Basler + Partner AG ist als Generalunternehmer für die Koordination des Projekts und die Realisierung des Informationssystems verantwortlich.
Sie wird unterstützt durch die Firma Hydrotec aus Aachen (Deutschland) sowie durch
zahlreiche Subunternehmer im Bereich der Datenerfassung. Weitere Informationen sind
unter http://www.timisflood.net erhältlich.
3 Aspekte der Interoperabilität
3.1 Austausch von Geodaten
Der Austausch der Geodaten bildet im Rahmen der Beispielprojekte die weitaus grösste
Herausforderung im Bereich der Interoperabilität. Zwischen folgenden Beteiligten müssen Daten ausgetauscht werden (Abbildung 1):
x
x
x
x
Ernst Basler + Partner als Auftragnehmer
Auftraggeber
Projektpartner (Partnerfirmen, Subunternehmer, andere Beteiligte)
Externe Geodatenlieferanten (z.B. Swisstopo, Vermessungsbüros)
Abb. 1 : Beteiligte beim Austausch von Geodaten.
Standardisierte Austauschformate werden zum heutigen Zeitpunkt kaum verwendet. In
der Regel wird im Vorfeld eines Datenaustauschs ein geeignetes Transferformat – in
Abhängigkeit der Möglichkeiten von Quell- und Zielsystem – festgelegt (Tabelle 2).
18.2
Austauschformate für Vektordaten
ESRI (Shape, Coverage, Personal Geodatabase, Exportdatei)
CAD (DXF, DGN)
Datenbanken und Tabellen (MS Access, MS Excel, dbf)
XML
sAndere (INTERLIS, ASCII)
Austauschformate für Rasterdaten
Tiff (World, Geo)
ESRI (Grid)
ASCII
Andere
Anteil (geschätzt)
60%
10%
10%
10%
10%
Anteil (geschätzt)
50%
20%
20%
10%
Tab. 2 : Verwendete Formate für den Austausch von Geodaten. Der Anteil bezieht sich auf die
Anzahl zu transferierenden Informationen in den Beispielprojekten und ist geschätzt.
Der hohe Anteil an ESRI-Formaten lässt sich damit begründen, dass die Firma Ernst
Basler + Partner AG auf ESRI spezialisiert ist und damit häufig Auftraggeber und Projektpartner hat, welche ebenfalls mit ESRI arbeiten.
Nur rund 20% aller Daten, welche uns von den Auftraggebern zur Verfügung gestellt
werden, beinhalten nutzbare Metainformationen. Aber auch hier hat sich noch kein interkantonaler, geschweige denn ein internationaler Standard durchgesetzt.
3.2 Austausch von Applikationen und Systemen
Die gemeinsame Nutzung von Applikationen hat in den letzten Jahren an Bedeutung
gewonnen. Grund dafür ist die generell zunehmende Vernetzung von Systemen.
In den Beispielprojekten kommt dieser Aspekt in den webbasierten Projekten "SPATZ
Mapserver" und "TIMIS flood" zum Tragen.
Beim archäologischen Informationssystem SPATZ handelt es sich um eine OracleDatenbank mit Benutzerschnittstelle für die Datenbewirtschaftung. Der lesende Zugriff
auf SPATZ erfolgt via OGR Virtual Format, einem Open Source Treiber, welcher einfache Geoobjekte aus einer ODBC-Datenbank anhand einer XML-Konfigurationsdatei
liest. Der schreibende Zugriff auf die Oracle-Datenbank wird durch eine Schnittstelle
der Firma GWZ Informatik (Vertreiber von SPATZ) sichergestellt. Die Parameter werden dabei mittels ASCII-Datei übergeben.
Da es sich beim SPATZ Mapserver um eine Intranet-Anwendung handelt, kommen zur
Zeit keine OGC-kompatiblen Austauschformate (WFS, WMS) zum Einsatz.
Im Projekt TIMIS flood werden die geografischen Informationsdienste zur Zeit basierend auf WFS und WMS konzipiert. Für das Internet-Portal (auf Basis von ESRI ArcIMS)
ist dies mittlerweile eine Standardfunktionalität. Zum heutigen Zeitpunkt ist jedoch
noch nicht sichergestellt, dass alle nationalen Server diese OGC-Formate unterstützen.
Wir gehen aber davon aus, dass sich diese OGC-Formate in den kommenden Jahren
durchsetzen werden.
3.3 Austausch von Prozessen
Die Interoperabilität von Prozessen ist zum heutigen Zeitpunkt noch am wenigsten
fortgeschritten. Im Zusammenhang mit Web-Services (z.B. für die Geocodierung von
Adressen) wird dieser Aspekt in Zukunft aber immer wichtiger.
Der Austausch von Prozessen ist unter den Beispielprojekten einzig im Projekt TIMIS
flood vorgesehen. Ab 2008 soll es möglich sein, die Hochwasservorhersage für einen
18.3
Standort an der deutschen Mosel (Rheinland-Pfalz) aus der Kombination verschiedener
Prozesse zu generieren: aus der Wettervorhersage des deutschen Wetterdienstes, aus
den aktuellen Pegelmessungen im Einzugsgebiet (Frankreich, Luxemburg und Deutschland), aus einer Abflussvorhersage aus Baden-Württemberg und aus einer hydraulischen Modellierung für den entsprechenden Standort in Rheinland-Pfalz. Als Resultat
erhält der Benutzer die Hochwasservorhersage in Karten- und Textform (ähnlich wie
bei der Wettervorhersage). Die gleichen Prozesse können auch für beliebige Orte in Luxemburg beansprucht werden.
Noch sind nicht alle Fragen gelöst. Die grössten Hürden liegen jedoch weniger in der
technischen Realisierbarkeit, sondern viel eher in der Akzeptanz der verschiedenen
(ausländischen) Prozesse und Verfahren. Für eine erfolgreiche Umsetzung sind hier
weniger Standards, sondern eher eine gute Kommunikation innerhalb und ausserhalb
des Projekts notwendig.
3.4 Interoperabilität und Projektplanung
Die oben erwähnten Aspekte kommen zum Tragen, wenn ein Projekt ausgelöst ist. Erfahrungen in der Praxis haben aber gezeigt, dass der Kosten-, Kommunikations- und
Zeitaufwand für die Interoperabilität im Allgemeinen unterschätzt wird. Bei der Planung eines Projekts sind folgende Informationen häufig nicht oder nur unzureichend
vorhanden:
x
Qualität der Geodaten oder der Systeme
Neben der grundsätzlich zu prüfenden Qualität der Datengrundlage kann es alleine aufgrund der genutzten Formate zu Qualitätsproblemen kommen: Ein
CAD-Format setzt andere Integritätsregeln auf einen geometrischen Datensatz
als ein GIS-Format. Selbst innerhalb verschiedener GIS-Formate bestehen unterschiedlich strenge Anforderungen an den Aufbau und die Konsistenz der Daten.
x
Erstellung oder Anpassung notwendiger Schnittstellen
Während der Bearbeitung eines Projektes kann es passieren, dass aus rein technischen Gründen neue Schnittstellen notwendig werden oder geplante Schnittstellen angepasst werden müssen.
x
Vollständige Dokumentationen
Bei der Planung werden Eigenschaften der zu nutzenden Daten oder Systeme
implizit angenommen, die nicht oder nur unzureichend dokumentiert oder in
Metadaten vorhanden sind.
Der Vollständigkeit halber soll auch erwähnt sein, dass Projektideen immer wieder
durch zu hohe Tarife für Geodaten wieder begraben werden.
4 Fazit
Aus den oben dargestellten Projekten lassen sich bezüglich Interoperabilität bei der
Nutzung von Geodaten folgende Folgerungen ableiten:
x
x
18.4
Bei GIS-Projekten im Planungs- und Umweltbereicht steht heute bezüglich Interoperabilität vor allem der Austausch von Daten im Vordergrund.
Beim Datenaustausch gelangen kaum Standards zum Einsatz. Am häufigsten
werden die Formate ESRI Shape und Tiff verwendet. Dies hängt aber in erster
Linie von den Möglichkeiten (der GIS-Software) der Parteien ab. INTERLIS wird
zur Zeit (zu) wenig eingesetzt.
x
x
XML als Austauschformat ist im Vormarsch, doch wird die Interoperabilität
durch die unzähligen Variationen (WFS, GML, ESRI XML, INTERLIS 2, etc.) reduziert.
Die OGC-Formate WFS und WMS werden sich etablieren und zumindest bei internationalen Projekten zum Standard werden. Andere Formate werden vom
Markt verschwinden oder ein Nischendasein führen.
Insgesamt ist festzuhalten: Die Anzahl Projekte, bei denen Daten oder Systeme zusammengeführt werden müssen, steigt stetig. Aus diesem Grund wird die Interoperabilität
von Applikationen und Prozessen in den kommenden Jahren zunehmen. Ob sich in Zukunft Standards einstellen oder nicht: wir als Dienstleister im Bereich der Geoinformatik
müssen uns ohnehin anpassen; an die Bedürfnisse der Auftraggeber und Projektpartner
oder an die vorgegebenen Standards.
Abkürzungen und Begriffe
Abkürzung/Begriff
ASCII
CAD
DXF
DGN
GIS
GML
Grid
INTERLIS
ODBC
OGC
OGR
Oracle
Shape
Tiff
TIMIS
SPATZ
WFS
WMS
XML
Definition
American Standard Code for Information Interchange; Codierung
von insgesamt 128 Zeichen (Buchstaben, Zahlen und Satz- und
Sonderzeichen)
Computer Aided Design
Vektorbasiertes Dateiformat der Firma Autodesk, speziell für
CAD-Lösungen entwickelt.
Vektorbasiertes Dateiformat der Firma Intergraph
Geographische Informationssysteme
Geography Markup Language; XML-basiertes Format für den Austausch von GIS-Daten
Rasterbasiertes Dateiformat der Firma ESRI
Datenbeschreibungs- und –modellierungssprache, basiert in der
Version 2 auf XML
Open Data Base Connectivity, Datenbanktreiber für anwendungsunabhängige Datenbankzugriffe
Open Geospatial Consortium
Softwarebibliothek für den Zugriff auf verschiedene GIS Vektorformate
Softwareanbieter für Datenbanken
Dateiformat für Vektordaten, entwickelt von der Firma ESRI
Dateiformat zur Speicherung von Rasterdaten
Transnational Internet Map Information System
Synergie Projekt Archäologie Thurgau und Zürich
Web Feature Service; Internet-Protokoll zum Lesen und Schreiben
von GIS-Daten im Vektorformat, basiert auf GML
Web Map Service, Internet-Protokoll zum Lesen und Schreiben
von digitalen Karten
Extensible Markup Language; Format zur Erstellung strukturierter
Dokumente
18.5
19
Christian Kaul, Kaul Beratungen GmbH
Kaul Beratungen GmbH
Christian Kaul
Flaachtalstrasse 8
CH-8412 Hünikon
Tel :
Fax :
E-Mail :
+41 52 343 79 01
+41 52 343 79 02
Perspektiven für die Geomatik-Berufe …
… oder was es braucht, damit das zarte Pflänzchen „Interoperabilität“ zum Blühen
kommt.
1 Einleitung
Die zentrale Aussage gleich vorweg: Die neuen technischen Möglichkeiten der Interoperabilität alleine sichern der Geomatik-Branche noch keine neuen Märkte!
Interoperabilität ist auch kein technisches Projekt, das nach Abschluss eine Firma interoperabel macht. Interoperabilität muss viel mehr zu einer grundlegenden Denkhaltung
in allen Geomatik-Berufen werden. Damit können auch die rasanten Entwicklungen der
Zukunft in diesem Bereich proaktiv genutzt werden.
Damit die Chancen und Möglichkeiten der Interoperabilität neue Perspektiven für die
Geomatik-Berufe eröffnen werden, ist das Zusammenspiel von verschiedenen Ebenen
und Facetten notwendig. Die technischen Herausforderungen sind dabei nur ein Blatt
einer weitgefächerten Blüte.
Technische
Fähigkeiten
Systemtechnisches Visionär
Arbeit in
denken
kooperativ Multidisziund
Generalist plinären
handeln
Projekten
Permanente
berufliche
Weiterentwicklung
19.1
2 In Zentrum - der Unternehmer
Im Zentrum steht die unternehmerische Persönlichkeit in Privatwirtschaft und Verwaltung. Das Thema Interoperabilität kann nicht passiv-reaktiv angegangen werden. Es
braucht den visionären Geist, der eine - vielleicht nur vage - Vorstellung davon hat, wohin die Reise gehen könnten. Ohne Visionen ist jede Organisation in dieser schnelllebigen Zeit früher oder später dem Untergang geweiht.
Inter-operability braucht Inter-working. Die Fähigkeit und der Wille zur Kooperation
mit anderen Organisationen muss von den Chefs vorgelebt und gefördert werden. Dabei darf ruhig anerkannt werden, dass andere auch etwas können – denn das ist die Basis der gemeinsamen künftigen Erfolge.
Mit der Interoperabilität der Geo-Daten geht eine massive Ausweitung der DatenInhalte einher, mit der eine Organisation konfrontiert wird. Damit rückt die alte Fähigkeit des Generalisten wieder mehr ins Zentrum des Interesses. Nach Prof. Dr. Hans Ulrich ist ein Generalist: "... jemand, der auch in seinem eigenen Wirkungsbereich lange
nicht alles weiss, der aber das Ganze versteht." Als integrierende Ergänzung der Spezialisten in den Unternehmen muss sich der Unternehmer stärker der Übersicht, dem Ganzen widmen.
3 Die Blütenblätter – das Unternehmen
Für die Mitarbeiter eines Unternehmens sind folgende vier Bereiche im Hinblick auf interoperables Arbeiten von Bedeutung:
Technische Fähigkeiten
Das Unternehmen muss die notwendigen Techniken für interoperables Arbeiten beherrschen. Dabei wird sich das Schwergewicht noch mehr auf die Informatik verlagern. Eine
Firma muss in der Lage sein, die sich immer schneller ändernden Bedürfnisse der Kunden zufrieden zu stellen und gleichzeitig die rasante technische Entwicklung aktiv zu
nutzen.
Inhaltlich werden die Web-Technologien sehr stark ins Zentrum des Interesses rücken.
Die datentechnischen Fähigkeiten müssen aber parallel dazu noch weiter ausgebaut
werden.
Arbeiten in multidisziplinären Projekten
Die Interoperabilität bietet die Chance in themenübergreifenden Projekten effizient zusammenzuarbeiten. Dies erfordert eine offene und interessierte Haltung aller Beteiligter
bezüglich anderer Themen und anderen Teams und ein Bewusstsein, dass dies nicht
von selber erfolgreich geschieht, sondern gelernt und geübt werden kann und muss.
Systemtechnisches Denken und Handeln
Die Anforderungen an die Produkte der Geomatik-Branche werden auch weiterhin stetig steigen. Die einfachen, klaren Antworten werden immer seltener werden. In einem
solchen Umfeld haben sich seit Jahren die Grundsätze und Methoden der Systemtechnik
bewährt. Diese Art des Denkens und Handelns kann nicht einigen Spezialisten überlassen werden, denn sie bildet die Grundlage für ein erfolgreiches interoperables Arbeiten
aller Geomatik-Berufe.
Permanente berufliche Weiterentwicklung
Die oben beschriebenen Anforderungen an die Mitarbeiter können nicht einfach neben
dem Alltagsgeschehen entwickelt werden. Es braucht eine aktive, gezielte und vor allem
19.2
permanente Weiterentwicklung aller Mitarbeiter. Mit kurzfristigen Feuerwehrübungen
können die notwendigen Fähigkeiten in einer Firma nicht nachhaltig erarbeitet und aufrechterhalten werden.
4 Die Kelchblätter – eine nachhaltige Basis
Die UNO definiert nachhaltige Entwicklung als: "... eine Entwicklung, die die Bedürfnisse der Gegenwart befriedigt, ohne zu riskieren, dass künftige Generationen ihre eigenen
Bedürfnisse nicht befriedigen können." Diese Definition ist weitherum anerkannt und
bildet die Basis der so genannten "Agenda21" der UNO.
Im Zusammenhang mit nachhaltiger Entwicklung werden oft die drei Zieldimensionen
Gesellschaft, Wirtschaft und Umwelt beleuchtet.
Gesellschaft
Durch ihren Hauptauftraggeber, die Öffentliche Hand, haben die Dienstleistungen der
Geomatik-Branche traditionell einen grossen Bezug zur Gesellschaft. Aktivitäten im Bereich der Interoperabilität sind zum Teil sehr stark vom Rahmen der Gesellschaft geprägt. Eine sehr grosse Bedeutung muss in diesem Zusammenhang dem Rechtssystem
beigemessen werden. Die rechtlichen Rahmenbedingungen sind immer höher einzustufen als die technischen. Deshalb bilden gute rechtliche Kenntnisse und eine sorgfältige
Analyse dieser Sachverhalte die Grundlage erfolgreicher Projekte und Produkte.
Einen weiteren massgebenden Faktor bildet die Normierung. Wie an dieser Tagung
aufgezeigt, sind zur Zeit sehr grosse Bestrebungen auf Stufe ISO und CEN im Gange.
Hier gilt es, aktiv die langjährige praktische Erfahrung der Schweiz in diese Normierungsarbeiten einzubringen.
Wirtschaft
Das heisst nichts anderes, als dass sich auch die Aktivitäten im Bereich der Interoperabilität schlussendlich positiv aufrechnen lassen. Das wird nur gelingen, wenn den Aufwändungen auch ein entsprechend nachgefragter Nutzen gegenübersteht. Demzufolge
definiert der Nutzer und Endkunde die Rahmenbedingungen für die Wirtschaftlichkeit
und nicht die eigenen Vorstellungen der Branchen-Insider. Das bedingt jedoch viel bessere und ehrlichere Kenntnis der echten Bedürfnisse der Kunden.
Diese Überlegungen gelten auch für die staatlich finanzierten Aktivitäten. Ein GeoDienst könnte vom Staat, durch Steuergelder finanziert, für den Nutzer unentgeltlich
angeboten werden. Doch auch hier muss dem Aufwand an Steuergeldern ein entsprechender Nutzen gegenüberstehen.
Umwelt
Diese Zieldimension beinhaltet den Umgang mit Ressourcen in einem umfassenden
Sinne, also die Aufforderung, die Aktivitäten im Bereich der Interoperabilität mit einem
Minimum an Aufwand von Energie, Material, Arbeit und Geld umzusetzen. Im Bereich
der Interoperabilität kann dies in erster Linie mit einer exzellenten Nachführbarkeit der
Lösungen und einem systemneutralen Investitionsschutz für die Daten erreicht werden.
Auch die genialste technische Lösung wird nie nachhaltig sein, wenn sie alle zwei Jahre
neu aufgesetzt werden muss. Der gesicherte Investitionsschutz und die konsequente
Nachführung der Daten sind eine grosse Verantwortung der Branche gegenüber kommenden Generationen.
19.3
5 Neue Perspektiven dank Interoperabilität
Auf der Basis der bisherigen Überlegungen kann gesagt werden:
x
es wird einfacher, grossflächige regionale oder überregionale Projekte zu bearbeiten
x
die Zusammenarbeit verschiedener interner und externer Teams wird effizienter
x
es können gemeinsam Produkte entwickelt und lanciert werden, die für eine
einzelne Firma nicht denkbar sind. Z.B. Portallösungen für Geodaten-Nutzung
x
die bewährte Zusammenarbeit von öffentlicher Hand und Privatwirtschaft (Public-Private-Partnership PPP) kann vertieft werden
x
durch die vermehrte Zusammenarbeit und das bessere gegenseitige Verständnis
werden sich neue Tätigkeitsfelder eröffnen
x
die gemeinsame Nutzung von Technologien, Know-how, Kapazitäten (von Mitarbeitern, HW, SW, etc.) , Datenleitungen, etc. wird attraktiver
x
bereits vorhandene Fähigkeiten können unter dem Titel "Interoperabilität" besser
kommuniziert werden
Weiterführende Informationen:
- Buch Systems Engineering, Methodik und Praxis, Hrsg: Daenzer / Huber, Verlag Industrielle Organisation, Zürich, ISBN 3-85743-998-X
- Zur Agenda 21: http://www.are.admin.ch/are/de/na
19.4
20
Tarifierung, Kostenfragen
Jürg Kaufmann, KAUFMANN Consulting / FIG
Jürg Kaufmann, dipl. Ing. ETH
KAUFMANN CONSULTING/FIG
Hauffeld 109
CH-8455 Rüdlingen
Tel :
Fax :
E-Mail :
+41 1 867 14 36
+41 1 867 34 89
1 Einleitung
Die folgenden Überlegungen sollen aufzeigen, wie sich die Interoperabilität auf die Kostengestaltung und die Festlegung von Tarifen auswirken.
Um diese Fragen zu klären seien zunächst einmal einige Begriffe definiert:
Interoperabilität:
Zusammenarbeit in einem offenen System (gemäß dem Client/Server--Modell). Unabhängig von
der verwendeten Hardware, den eingesetzten Betriebssystemen, der verwendeten Netzwerktechnologie und der Realisierung einer Anwendung kann eine Zusammenarbeit zwischen diesen
Anwendungen erfolgen.
Tarif:
1. verbindliches Verzeichnis der Preis- bzw. Gebührensätze für bestimmte Lieferungen, Leistungen, Steuern u. a.
2. durch Vertrag od. Verordnung festgelegte Höhe von Preisen, Löhnen, Gehältern u. a.
Tarifieren:
die Höhe einer Leistung durch Tarif bestimmen.
Der Begriff der Kosten darf wohl als bekannt vorausgesetzt werden.
Um die Folgen der Interoperabilität abschätzen zu können wird zunächst der traditionelle Ablauf der Leistungserbringung dargestellt. Der Vergleich mit dem Ablauf bei
Anwendung der Interoperabilität kann Hinweise auf die Veränderung der Kostenfaktoren geben.
Die Auswirkungen der Interoperabilität auf die Kostenstruktur sollen aufgezeigt werden. In einem weiteren Kapitel werden die Überlegungen zur Tarifierung dargestellt.
Schliesslich werden die Resultate der Groupe de Réflexion "Datenabgabe und Gebühren", sowie die Arbeiten der KOGIS im Bereich Tarifierung und in Bezug auf die Auswirkungen der Interoperabilität beleuchtet.
Einige Schlussfolgerungen sollen das zukünftige Verhalten der Informationsgesellschaft
skizzieren.
2 Auswirkungen der Interoperabilität auf den Ablauf der
Leistungserbringung
Das uns allen bestens bekannte Schema für den Bezug von Leistungen ist in Abbildung 1
dargestellt.
Bestellung
Anfrage bei Logistik
Empfangen der Lieferung
Bereitstellung der Lieferung
Bezahlung
Inkasso
Abb. 1 : Schema für den Bezug von Leistungen
Dieser Ablauf war seit Beginn der Handelsaktivitäten des Menschen immer derselbe
und er spielt auch heute noch eine dominierende Rolle. Gewisse Neuerungen führten zu
20.1
verkürzten Abläufen, beispielsweise bei der Selbstbedienung oder zu effizienteren Zahlungsverfahren, wie bei der Verwendung von Strichcodes. Auch das e-shopping läuft
nach demselben Schema ab. Die Verkäuferin wird durch ein Terminal und ihre Beratung durch Text und Bilder ersetzt. Nur für das Lächeln und die Ausstrahlung der Verkäuferin oder der Serviertochter kann diese Art der Leistungserbringung nicht überzeugend ersetzen.
Bei Anwendung der Interoperabilität wird genau dasselbe Schema durchlaufen. Aber
alle menschlichen Teilnehmer an der Leistungserbringung sind durch Maschinen ersetzt.
Angesichts der hohen Lohnkosten in der Schweiz, muss also die Leistungserbringung
grundsätzlich günstiger werden.
Da die Leistungen durch Automaten erbracht werden, ist es notwendig, die Abrechnung automatisch zu erfassen
3 Auswirkungen der Interoperabilität auf die Kosten
Die anwendbaren Kostenkomponenten für die Leistungserbringung sind normalerweise:
x
x
x
x
x
Die Kosten für die Bestellungsaufnahme
Die Kosten für die Bestellungsübermittlung
Die Kosten der Bereitstellung der Lieferung
Die Kosten für die Lieferung
Die Kosten für die Rechnungsstellung und das Inkasso.
Im Normalfall werden diese Kosten als Gemeinkostenanteil auf den Preis der gelieferten
Ware oder Dienstleistung geschlagen. Gegenüber dem Kunden wird diese Kostenkomponente nicht offen gelegt. Gemeinkostenanteile können ermittelt werden, wenn die Beteiligten an einem Prozess und ihre spezifischen Kosten bekannt sind.
Branchenübliche Festlegungen der Gemeinkostenzuschläge sind im traditionellen System die Regel.
Bei einer interoperablen Arbeitsweise ist aber nicht mehr à priori bekannt, welche Maschinen/Systeme/Automaten an der Ausführung einer Lieferung beteiligt sind. Die bestellte Ware wird dort abgeholt oder eingesehen, wo sie verfügbar ist.
Unabhängig davon, wie man einen Preis für die Ware oder die Dienstleistung festsetzt,
muss eine Lösung gefunden werden, welche ohne Gemeinkostenzuschlag auskommt.
Man muss die Kosten für die Leistungserbringung gesondert betrachten.
Da die Leistungserbringung durch Automaten erfolgt, muss die Erfassung der preisbildenden Faktoren automatisch erfolgen können, weil es im Umfeld der Interoperabilität
unmöglich wird, die Wege zu verfolgen und die nötigen Abrechnungsdaten manuell zu
erfassen.
Es ist zudem wenig sinnvoll jede Komponente, die bei der Leistungserbringung zum
Zuge kommt, individuell und mit eigenen Kostensätzen in ein Abrechnungssystem einzubringen, da die Preisgestaltung der einzelnen beteiligten Dienstleister wohl niemals
über einen Leist geschlagen werden können.
Deshalb ist es im Zeitalter der Interoperabilität zwingend, mit vereinbarten Tarifen zu
arbeiten.
20.2
4 Auswirkungen der Interoperabilität auf die Tarifierung
Eine vernünftige Tarifierung der Leistungserbringung ist also eine Notwendigkeit, damit die Vorteile der Interoperabilität schliesslich voll zum Tragen kommen.
Die Anforderungen an die Tarifierung wurden teilweise bereits bei den Kosten genannt:
x
x
x
Die preisbildenden Faktoren müssen automatisch ermittelt, festgehalten und abgerechnet werden können.
Die festgelegten Tarife müssen mit dem Aufwand für die Erbringung der Leistung in einem sinnvollen Verhältnis stehen.
Die Tarife müssen für den Besteller nachvollziehbar sein.
Über die Art der Preisgestaltung sind Lösungsansätze vorhanden, aber es hat sich bisher
keine einheitliche Lösung herauskristallisiert.
5 Resultate bisheriger Tarifierungsanstrengungen
In der Schweiz existieren zwei Arbeiten, die sich mit der Tarifierung beschäftigen. Einerseits hat eine von der V+D1 eingesetzte, paritätische Groupe de Réflexion sich mit den
Problemen der Datenabgabe und Gebühren befasst. Eine weitere Expertenarbeit über
Tarifierungsprobleme wurde im Auftrag von KOGIS erstellt. Die Arbeiten dieser Teams
wurden auf höchster Stufe koordiniert.
Beide Arbeiten kommen zum Schluss, dass für Geodaten eine Strategie der marginal cost
anzuwenden sei. Marginal cost umfassen ausschliesslich die Bearbeitungs- und Lieferkosten. Als Begründung für diese Empfehlung wird angeführt, dass Geodaten in der
Regel in Erfüllung eines gesetzlichen Auftrags beschafft werden. Dies trifft in der Tat
auf die meisten Geodaten zu. Im Entwurf des Geoinformationsgesetzes wird denn auch
von Geobasisdaten gesprochen, die von nationalem, kantonalem oder kommunalem Interesse liegen, je nachdem, welche Stufe den gesetzlichen Auftrag beschlossen hat. Damit sind die Investitionskosten, d.h. die Kosten für die Datenbeschaffung von der Allgemeinheit zu übernehmen. Um aber einen möglichst grossen Kostenrückfluss zu generieren, sollen die Daten möglichst günstig an die Interessenten abgegeben werden, damit deren Steuern möglichst hoch ausfallen, weil die Gewinne nicht durch Beschaffungskosten geschmälert und möglichst gross werden, wenn aus diesen Daten Produkte
mit Mehrwert generiert werden können.
Im Rahmen der Arbeiten der Groupe de Réflexion wurde nachgewiesen, dass die Investitionskostenbeiträge, wie sie durch den Bericht Buschor im Rahmen der Arbeiten zur Reform der Amtlichen Vermessung vorgeschlagen und in der Mehrzahl der Kantone eingeführt wurden, keinen signifikanten Beitrag zur Abschreibung der getätigten Investition in die Amtliche Vermessung zu liefern vermag. Bei hohen Preisen wird die Anzahl
Bezüge durch die Benützer minimiert indem das Abgaberegime unterlaufen wird. Bei
tiefen Preisen werden die Daten zwar häufiger bezogen, aber die eingenommenen Beiträge fallen zu klein aus, um zu einer sinnvollen Amortisationsdauer zu führen. Die
Groupe de Réflexion empfiehlt deshalb, zum Regime der marginal cost, das bis zur Einführung des Vorschlags Buschor Gültigkeit hatte, zurückzukehren.
Die Groupe de Réflexion hat sich ebenfalls über Tarifansätze Gedanken gemacht. Dabei
hat sie versucht, die Auswirkungen der Interoperabilität in ihre Betrachtungen einzubeziehen.
1
Anm. d. Red. : V+D :Eidgenössische Vermessungsdirektion
20.3
Sie hat folgende Kostenfaktoren gemäss Abbildung 2 vorgesehen:
Komponente
Administrative Bearbeitung eines Auftrages
Technische Bearbeitung eines Auftrages
Vertriebsaufwand für die Ablieferung des
Resultates
Ansatz
Pauschale pro Auftrag
vorgeschlagener Preis
CHF 50.-/Auftrag
CHF 50.-/Auftrag
CHF 20.-/Auftrag
Benützung der Infrastruktur für die
Erstellung des gewünschten Produktes
CHF/Megabyte
bezogener Daten
CHF 5.-/Megabyte
Vektordaten
(INTERLIS-Format)
Benützung der Internetinfrastruktur bei
Bezug der Daten über das Internet
Pro Anfrage
CHF 10.- pro Anfrage
Abb. 2 : Tarifierungsvorschlag der Groupe de Réflexion
Bei einer bediensten Abgabe kommen die ersten vier Komponenten zur Anwendung.
Wird das Internet oder eine andere interoperable Infrastruktur benützt, werden die grau
unterlegten Komponenten verrechnet.
Ein völlig neuer und transparenter Ansatz ist die Erfassung und Belastung der Menge
der tatsächlich bezogenen Daten, wobei bei den Vektordaten das wohldefinierte INTERLIS-Format, für Rasterdaten ein Äquivalent zur Anwendung kommt. Mit diesem
Ansatz soll die Bereitstellung der Lieferung entschädigt werden. Dem Bezüger wird
damit eine Rechnung gestellt, die den Daten, die er bezogen hat, objektiv entspricht. Er
kann damit seinen Bezugspreis beeinflussen.
Dieses Konstrukt sollte den Herausforderungen der Interoperabilität genügen können.
Allerdings sind die Tauglichkeit des Ansatzes und die Höhe der Tarife im praktischen
Einsatz zu testen.
Die Strategie der marginal cost wurde zwar in den Entwurf zum neuen Geoinformationsgesetz aufgenommen. Ob sie zur Anwendung kommt ist vorerst nicht klar. Es ist in
jedem Fall weise, die Bearbeitungs- und Lieferkosten separat festzusetzen und damit
vom traditionellen Muster des Gemeinkostenzuschlags wegzugehen.
Die Interoperabilität ändert die traditionellen Kostenfragen nicht grundsätzlich, verschiebt aber den Schwerpunkt auf hochautomatisierte Prozesse bei der Leistungserbringung. Es müssen einfache und transparente Tarife geschaffen werden, um interoperable
Lösungen auch kommerziell sinnvoll auszugestalten.
Erste Ansätze sind vorhanden. Diese müssen aber in der praktischen Anwendung ausprobiert und allenfalls den Erfahrungen angepasst werden.
Literatur
Groupe de Réflexion Datenabgabe und Gebühren [2003] 'Vorschlag für die zukünftige
Regelung der Datenabgabe und der Gebühren in der Amtlichen Vermessung, V+D,
Bern
Groupe de Réflexion diffusion des données et émoluments [2003] 'Proposition pour la
future réglementation de la diffusion des données et des émoluments dans la Mensuration Officielle', D+M, Berne
KOGISTarif [2002] Neue Tarifierungs- und Vertriebsstrategien von Geodaten des Bundes, INFRAS im Auftrage von KOGIS, 26. September 2002
20.4
21
Georeferenzierung, Interoperabilität
zwischen Vermessungsdaten und
darauf aufbauender Rauminformation,
Datenhierarchie und Nachführung der
abhängigen Rauminformation
Horst Düster,
Amt für Geoinformation Kanton Solothurn
Horst Düster, Dr.
Amt für Geoinformation Kanton Solothurn
Abteilung SO!GIS Koordination
Werkhofstr. 65
CH-4509 Solothurn
Tel :
Fax :
E-Mail :
+41 32 627 25 32
+41 32 627 22 14
1 Situation
Eine kantonale Verwaltung hat Ähnlichkeiten mit einer heterogenen Unternehmensstruktur. Die Verwaltungsorgane verfügen über eine vielfältige Aufgabenstruktur mit
gleichzeitiger räumlicher Trennung der Einheiten. Herausragend ist dabei der grosse
Informationsbedarf, besonders nach Geoinformationen.
Zur Befriedigung dieses Informationsbedarfes steht eine grosse Zahl unabhängig funktionierender Informationsquellen bereit. In der Regel weisen diese Quellen Redundanzen auf. So werden z.B. Grundbuchzugehörigkeiten, Flurnamen von verschiedenen Objekten in unterschiedlichen Datenhaltungssystemen redundant bereit gehalten. Eine
konsistente Pflege und Nachführung dieser eigentlich ungebundenen Informationen ist
in der Regel unmöglich.
Die Folge dieser Situation ist eine ineffiziente Ressourcennutzung, die insbesondere
durch Entscheidungsunsicherheit hervorgerufen wird.
Im Kanton Solothurn wurde ein GIS Leitbild entworfen, dessen Kernsätze sich auf die
Erhöhung der Produktivität, Verbesserung der Entscheidungssicherheit und damit die
Erhöhung des operationellen Nutzens sowie die Verbesserung des strategischen Nutzens mit dem Ziel die staatlichen Strukturen und Instrumente zu verbessern, beziehen.
2 Strategie
Die Vision zur strategischen Umsetzung des Leitbildes sieht eine Beschleunigung und
Verbesserung der grundlegenden Verwaltungs- und Entscheidungsprozesse durch konsistente digitale Geo- und Sachinformationen vor. Dazu müssen Raum- und Sachinformationen logisch und redundanzfrei normalisiert vereint werden können. Die Voraussetzung dazu ist technische Interoperabilität durch offene Schnittstellen. Um diese nutzen zu können wird konzeptionelle Interoperabilität durch offene Systeme vorausgesetzt.
Aufgrund des Regierungsziels 2005, "... 90% der Standard-Benutzer sowie der Anwendungen sind auf Terminalserver unter Linux migriert", wird durch die Abteilung
SO!GIS Koordination weitgehend freie und offene Software eingesetzt.
Open Source GIS bietet sich zur Umsetzung der Vision auf der Grundlage des Regierungsziels an. Da seitens dieser Software kein Interesse besteht, die Anwender an ein
herstellerabhängiges System/Produkt zu binden, werden ein grosse Zahl verschiedener
Datenformate unterstützt. Ausserdem wird eine breite Unterstützung offener Spezifikationen und Schnittstellen wie z.B. die vielfältigen OGC Spezifikationen gewährleistet.
Schliesslich sind die verwendeten Systemschnittstellen der Open Source GIS Software
offen dokumentiert und frei erhältlich.
3 Systemumgebung
Im Kanton Solothurn werden die folgenden Open Source GIS Komponenten im Rahmen
einer Multischicht-Architektur eingesetzt. Zur persistenten Datenhaltung wird in der
Datenschicht PostgreSQL verwendet. PostgreSQL folgt den Standards SQL92 und
SQL99. Mit der Erweiterung PostGIS wird PostgreSQL um den Funktionsumfang der
OGC Spezifikation SQL for simple features erweitert. Auf diese Weise steht eine vollständig GIS fähige Datenhaltungsschicht, mit der über standardisierte Schnittstellen, als
Grundlage zur technischen Interoperabilität, kommuniziert werden kann, zu Verfü-
21.1
Georeferenzierung, Interoperabilität zwischen Vermessungsdaten und darauf aufbauender
Rauminformation, Datenhierarchie und Nachführung der abhängigen Rauminformation
gung. Diese Umgebung bildet die Grundlage für die normalisierte Datenhaltung und
Informationsverarbeitung. Applikationsschichten bzw. Anwendungen müssen deshalb
nicht grundsätzlich über GIS-Funktionalität verfügen.
Die Applikationsschichten und Applikationen sind den Anforderungen entsprechend
vielfältig. Sowohl proprietäre Systeme auf Client-Server Basis über ODBC, JDBC,
GDAL/OGR oder nativen Schnittstellen, als auch echte Multischicht-Architekturen, in
der Regel Web basierend, werden eingesetzt.
Grundsätzlich ist dieser Ansatz unabhängig von den eingesetzten Betriebssystemen,
Programmiersprachen und Entwicklungsumgebungen, da die Kommunikation zwischen den einzelnen Komponenten standardisiert abläuft.
4 Beispiel Bodenprofil
Am Beispiel der Abfrage von Informationen zu einem Bodenprofil soll die Konzeption
und Systemumgebung in einem konkreten Fall, wie er in Solothurn umgesetzt ist, illustriert werden.
4.1 Problemstellung
Die Informationen zu einem Bodenprofil sollen redundanzfrei normalisiert abgelegt
und gepflegt werden können. Dazu wird eine persistente und normalisierte Datenhaltung aufgebaut, die in eine Multischicht-Architektur integriert ist. Die Vereinigung der
originären Information erfolgt über den Raum auf der Grundlage von SQL92 und dem
OGC Standard SQL for simple features. Die Applikationsschicht ist, in diesem Fall, mit
Web Technologien aufgebaut. Es werden technisch und konzeptionell offene und interoperable Schnittstellen verwendet.
Ein Abfrageergebnis soll der Bodentyp sowie die aktuelle Grundbuchnummer der Liegenschaft, den aktuellen Flurnamen und die aktuelle Höhe, in der das jeweilige Bodenprofil liegt, ermittelt werden.
4.2 Lösung
Aus der Sicht des Bodenprofils können die originären Informationen die Lage des Profils im Raum als Geometrie und der Bodentyp sein. Sie werden in einer
PostgreSQL/PostGIS Datenbank abgelegt und gepflegt. Zur Lösung der Problemstellung werden vom Bodenprofil keine weiteren Informationen benötigt. Abgeleitet sind
zur Lösung der Fragestellung, aus der Sicht des Bodenprofils, die Informationen aktuelle Parzellennummer, aktueller Flurname und aktuelle bekannte Höhe. Die abgeleiteten
Informationen stammen alle aus dem Datenstamm der amtlichen Vermessung und
werden dort unabhängig von den Bodeninformationen, in der PostgreSQL/PostGIS Datenbank gepflegt. Die Informationsebenen bilden somit eine flache Hierarchie, die a priori, ausser über den Raum, keine Beziehung zueinander aufweisen. Die Beziehungen
werden erst durch die Fragestellung generiert.
Wird nun eine Abfrage via SQL for simple features formuliert, an die Datenbank geschickt, erfolgt die im SQL Statement formulierte Verschneidung und das System kann
mit dem gewünschten Ergebnis antworten. So sieht die SQL Query für die Ermittlung
der Grundbuchnummer der Parzelle in der das Profil liegt folgendermassen aus:
21.2
select bodenprofil.bodentyp, parzellen.nummer
from bodenprofil, parzellen
where distance(bodenprofil.geometrie,parzellen.geometrie)=0;
Grundsätzlich kann diese Query von jeder beliebigen Applikationsschicht bzw. Applikation abgesetzt werden. Die Interoperabilität wird durch ODBC, JDBC, GDAL/OGR
oder native aber technisch offen dokumentierte Schnittstellen gewährleistet.
Abb. 1 : Systemarchitektur am Beispiel Bodenprofil
21.3
5 Fazit
Die vorgestellte Strategie der Multischicht-Systemumgebung in Verbindung mit einer
normalisierten Kommunikation zwischen den Komponenten ist sowohl unabhängig
von Betriebssystemen als auch von Programmiersprachen, unter der Voraussetzung,
dass die Kommunikationsstandards zur Interoperabilität eingehalten werden. So ergeben sich die folgenden Verbesserungen.
geringere Redundanzen
Die seit mehreren Jahren in Solothurn verfolgte Strategie der Normalisierung der
Grundlageninformationen führte zur erheblichen Reduktion der Redundanzen in der
Grundlagenhaltung, da Objektfremde abgeleitete Informationen nicht mehr mit den jeweiligen Objekten gemeinsam gespeichert werden.
effektiveres Datenmanagement
Das Datenmanagement ist vereinfacht und effektiver geworden. Die Nachführung der
Grundlagen erfolgt ausschliesslich auf den normalisierten Grundlageninformationen in
einer horizontalen Hierarchie.
verbindliche Daten
Die normalisierten Grundlageninformationen werden separat gepflegt und aktualisiert.
Da die gewünschte Information erst im Moment einer Abfrage generiert wird, konnte
die Qualität der Abfrageergebnisse erheblich verbessert und die Entscheidungssicherheit erhöht werden.
21.4
22
Der Mobilitäts-Graph
Ein geographisches Rahmenwerk für die
Partner des Mobilitäts-Informationssystems
der Region Genf
Pascal Oehrli, SSIG Genf
Pascal Oehrli
SSIG - Service des Systèmes d'Information et de Géomatique
DIAE - Département de l'Intérieur, de l'Agriculture et de l'Environnement
7, rue des Gazomètres
Case Postale 36
CH-1211 Genève 8
Tel :
Fax :
E-Mail :
+41 22 327 79 29
+41 22 327 50 70
Das Mobilitäts-Informationssystem der Region Genf (SI Mobilité) ist ein thematisches
Informationssystem aufgebaut im Rahmen des Système d’Information du Territoire Genevois (SITG). Die SI Mobilité ist eine Partnerschaft zwischen den verschiedenen Institutionen und Beteiligten, die mit Verkehr und deren Infrastrukturen zu tun haben (gilt für
alle Verkehrsmittel). Seine Ziele sind es die Daten und Produkte im Bezug auf die Mobilität in Genf zu sammeln, organisieren, verwerten, koordinieren und vertreiben.
Die Analyse der Situation hat gezeigt, dass die durch die verschiedenen Partner produzierten oder verwalteten Daten voneinander unabhängig, manchmal redundant und
direkt in einer Anwendung oder einem Modell insgesamt unbrauchbar waren. Trotz der
Existenz eines Routen-Graphs innerhalb der SITG sind von den Beteiligten entsprechend den berufsspezifischen Bedürfnissen andere Graphe entwickelt worden. Es existierten bis zu 5 oder 6 verschiedene Darstellungen der Geographie der Straßen.
Aufgrund dieser Tatsachen ist eine Vorgehensweise lanciert worden um einen gemeinsamen Routen-Graph auszuarbeiten, der die Besonderheiten von jedem der Partner maximal integriert. Es hat sich schnell gezeigt, wie wertvoll es ist, über ein einziges und auf
zentrale Art gehaltenes geographisches Bezugssystem verfügen zu können. Als Antwort
auf dieses Bedürfnis entstand der Mobilitäts-Graph. Er integriert die Geographie derverschiedenen der Fortbewegung dienenden Infrastrukturen (Straßen, Wege und Pfade,
Schiene und Wasserstraßen) sowie die Verbindungspunkte (Kreuzungen, Bahnsteige
und Anlegeplätze). Ein Paket so genannter Anschlussregeln erlaubt das logische Verbinden verschiedener Komponenten des Mobilitäts-Graphs.
Dieses allen Partnern von SI Mobilité zur Verfügung gestellte geographische Bezugssystem erlaubt es, die verschiedenen Daten, welche durch die Partner produziert und verwaltet werden, zu koordinieren. Diese Daten sind in einem Datenmodell organisiert
welches die folgenden Aspekte integriert: die Infrastruktur selbst, die dafür aufgestellten Einrichtungen, die Mobilität im Allgemeinen, die verschiedenen angewendeten Gesetzgebungen, die Mittel zur Umsetzung dieser Gesetzgebungen und die Aspekte der
Umwelt oder der Sicherheit. Diese vielfältigen Informationen unterschiedlicher Natur
können durch den Mobilitäts-Graphen auf verschiedene Arten wie die lineare Gliederung, die Netztopologie oder andere geographische oder nichtgeographische Beziehungsmittel koordiniert werden. Ausserdem bildet der Mobilitäts-Graph eine Basis für
die Netzanalyse und die Routenberechnung oder anderen zeitlichen oder geographischen Abfragen auf einem multimodalen Reisenetz.
22.1
Der Mobilitäts-Graph: ein geographisches Rahmenwerk für die Partner
des Mobilitäts-Informationssystems der Region Genf
Linien TC
Routen-Graph
Parkplatz
Halt TC
Kreuzungen
LangsamverkehrsGraph
ParkplatzzufahrtenGraph
Anschlüsse
Mobilitäts-Graph
Anlegestellen
Bahnsteig_Bahnhof
Flughäfen
WasserstrassenGraph
Fluglinien
Eisenbahn-Graph
Bahnhö-
Der Mobilitäts-Graph wird durch den mit der Amtlichen Vermessung beauftragten
Dienst verwaltet, auf den neusten Stand gebracht und allen Partnern von SITG frei zur
Verfügung gestellt.
Als Schlussfolgerung kann man sagen, dass die Existenz eines minimalen gemeinsamen
Bezugssystems eine wesentliche Basis für die Interoperabilität in einem Informationssystem darstellt, am Beispiel eines Koordinatensystems… oder eines für die linearen
Strukturen gemeinsamen Referenz-Graphen. Der gemeinschaftliche Genfer MobilitätsGraph, ebenso wie die Vorgehensweise, die zu einer Übereinkunft aller betroffenen Beteiligten geführt hat und die verschiedenen Modelle, die man durch dynamisches Segmentieren daran anknüpfen kann, scheinen ein gutes Beispiel für die Ausarbeitung eines gemeinsamen Bezugssystems zu sein.
22.2