Interoperabilität - Institute of Geodesy and Photogrammetry (IGP ...
Interoperabilität - Institute of Geodesy and Photogrammetry (IGP ... Interoperabilität - Institute of Geodesy and Photogrammetry (IGP ...
- Seite 3 und 4: Interoperabilität für die breite
- Seite 5 und 6: 1 Vorwort Die Verwirklichung der NG
- Seite 7 und 8: Inhaltsverzeichnis 1 Interoperabili
- Seite 9: Alessandro Carosio, Prof. Dr. Eidg.
- Seite 12 und 13: Einführung in die Thematik Interop
- Seite 14 und 15: Einführung in die Thematik Interop
- Seite 16 und 17: Einführung in die Thematik Interop
- Seite 18 und 19: Einführung in die Thematik Interop
- Seite 20 und 21: Einführung in die Thematik Interop
- Seite 22 und 23: Einführung in die Thematik Interop
- Seite 25 und 26: Dieser Beitrag soll dem Interessent
- Seite 27 und 28: Nationale und internationale Standa
- Seite 29 und 30: Nationale und internationale Standa
- Seite 31: Christine Giger, Prof. Dr. Eidg. Te
- Seite 34 und 35: Nationale und internationale Standa
- Seite 36 und 37: Nationale und internationale Standa
- Seite 38 und 39: Nationale und internationale Standa
- Seite 40 und 41: Nationale und internationale Standa
- Seite 42 und 43: Nationale und internationale Standa
- Seite 45 und 46: 1 Einleitung Wer an Normen denkt, d
- Seite 47 und 48: Nationale und internationale Standa
- Seite 49 und 50: Nationale und internationale Standa
- Seite 51: Adrian Annen Fachhochschule beider
<strong>Interoperabilität</strong> für die<br />
breite Nutzung von<br />
Geoinformation<br />
Weiterbildungstagung 17. und 18. März 2005<br />
Herausgegeben von A. Carosio<br />
Veranstalter<br />
Institut für Geodäsie und Photogrammetrie, ETH Zürich ETHZ<br />
Laboratoire de Systèmes d'information géographique, ETH Lausanne EPFL<br />
Ecole d’ingénieurs du Canton de Vaud, Yverdon EIVD<br />
Fachhochschule beider Basel Nordwestschweiz FHBB<br />
Schweizerischer Verb<strong>and</strong> für Geomatik und L<strong>and</strong>management geosuisse<br />
Konferenz der Kantonalen Vermessungsämter KKVA<br />
Schweizerische Organisation für Geo-Information SOGI<br />
Bundesamt für L<strong>and</strong>estopographie swisstopo<br />
Koordination der Geoinformationen und der geographischen<br />
Informationssysteme beim Bund KOGIS<br />
Schweizerischer Ingenieur- und Architektenverein SIA<br />
Bundesamt für L<strong>and</strong>wirtschaft BLW
Deutsche Ausgabe :<br />
Weiterbildungstagung 17. und 18. März 2005<br />
<strong>IGP</strong> Bericht Nr. 298 d<br />
ISBN 3-906467-51-1<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geoinformation<br />
Herausgegeben von A. Carosio<br />
Edition française :<br />
Journées d‘étude des 17 et 18 mars 2005<br />
<strong>IGP</strong> Rapport Nr. 298 f<br />
ISBN 3-906467-52-X<br />
Interopérabilité pour l'utilisation généralisée de la Géoinformation<br />
Textes rassemblés par A. Carosio<br />
©2005<br />
Institut für Geodäsie und Photogrammetrie, ETH Zürich<br />
Alle Rechte vorbehalten
1 Vorwort<br />
Die Verwirklichung der NGDI (Nationale Geodaten-Infrastrukturen) in Europa und<br />
weltweit ist unlösbar mit der Problematik der Vernetzung der Geoinformationssysteme<br />
verbunden. Geodaten gemeinsam nutzen ist eine dringende Notwendigkeit. Dafür<br />
braucht man technische und organisatorische Lösungen. Das Zauberwort, das zum Ziel<br />
führen soll, heisst: <strong>Interoperabilität</strong>!<br />
In Fachgremien und in Gesprächen mit Fachleuten fällt aber <strong>of</strong>t auf, dass Fragen und<br />
Lösungsansätze nur zum Teil bekannt sind.<br />
Es schien daher angebracht, eine Weiterbildungstagung zu diesem Thema zu organisieren,<br />
um das verfügbare Wissen zu sammeln, darzustellen und zu präsentieren.<br />
Wir glauben, dass es durch die Beteiligung der Organisationen, die heute an der Entwicklung<br />
von interoperablen Systemen arbeiten, gelungen ist, ein vielseitiges Programm<br />
zusammenzustellen, das die unterschiedlichsten Probleme beleuchtet und beschreibt.<br />
Den Autoren, die sich freiwillig zur Verfügung stellten, den Mitarbeitern der ETHZ und<br />
EPFL, die bei der Redaktion der deutschen und französischen Versionen des Berichtes<br />
mitwirkten sowie allen <strong>and</strong>eren Beteiligten möchten wir unseren herzlichen Dank aussprechen.<br />
Aless<strong>and</strong>ro Carosio<br />
Zürich, 3. März 2005
Organisationskomitee<br />
Aless<strong>and</strong>ro Carosio, Pr<strong>of</strong>. Dr. <strong>IGP</strong>-ETH Zürich (Vorsitz)<br />
Alain Buogo, dipl.Ing. KOGIS<br />
Thomas Glatthard, dipl.Ing. SOGI, geosuisse<br />
François Golay, Pr<strong>of</strong>. Dr. LaSIG-ETH Lausanne<br />
Francis Grin, dipl.Ing. EIVD Yverdon<br />
Jens Ingens<strong>and</strong>, dipl.Ing. LaSIG-ETH Lausanne<br />
Peter Jordan, Dr. SIA<br />
Christian Just, dipl.Ing. swisstopo<br />
Jürg Kaufmann, dipl.Ing. geosuisse<br />
Andreas Morf, dipl.Ing. <strong>IGP</strong>-ETH Zürich<br />
Stephan Nebiker, Pr<strong>of</strong>. Dr. FHBB Abt. Vermessung und Geoinformation, Muttenz<br />
Anton Stübi, dipl.Ing. BA L<strong>and</strong>wirtschaft Abt. Strukturverbesserung<br />
Pierre-Alain Trachsel, dipl.Ing. KKVA
Inhaltsverzeichnis<br />
1<br />
<strong>Interoperabilität</strong> in GIS: Anforderungen, Strategien,<br />
Lösungsansätze<br />
Pr<strong>of</strong>. Dr. Aless<strong>and</strong>ro Carosio, <strong>IGP</strong>-ETH Zürich<br />
Nationale und internationale St<strong>and</strong>ards<br />
2<br />
3<br />
4<br />
5<br />
Überblick<br />
Urs Flückiger, SOGI Fachgruppe GISTechnologie<br />
Informatik-St<strong>and</strong>ards (UML, XML, SOAP)<br />
Pr<strong>of</strong>. Dr. Christine Giger, <strong>IGP</strong> ETH Zürich<br />
Weltweite, europäische und schweizerische GeoNormen in<br />
Wechselwirkung<br />
Hans-Rudolf Gnägi, <strong>IGP</strong>-ETH Zürich, OSIG GT Normes<br />
OpenGeospatial Consortium OGC (GML, WMS, WFS)<br />
Adrian Annen, FHBB<br />
St<strong>and</strong> der Technik, Implementierungen I<br />
6<br />
7<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
Dr. Andreas Donaubauer, TUM, Pr<strong>of</strong>. Dr. Matthäus Schilcher,<br />
Anette Huber, TUM<br />
ISO-St<strong>and</strong>ards für den Datentransfer: St<strong>and</strong> der Realisierungen /<br />
Werkzeuge<br />
Claude Eisenhut, Eisenhut Informatik AG<br />
St<strong>and</strong> der Technik, Implementierungen II<br />
Realisierungen im Rahmen der GDI<br />
8<br />
9<br />
10<br />
<strong>Interoperabilität</strong> von Geodaten: aktueller St<strong>and</strong> und<br />
Zukunftsperspektiven im Kanton Waadt<br />
Marc Gilgen, DINF-VD<br />
Die Komplexität der <strong>Interoperabilität</strong>: ein einfacher Praxisbericht<br />
aus der Ostschweiz<br />
Ueli Forrer, F+P Geoinfo AG<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in<br />
Wallonien<br />
Jean-Claude Jasselette, MET Belgien
Nächste Schritte in der <strong>Interoperabilität</strong><br />
11<br />
Modellst<strong>and</strong>ardisierung vs. semantische <strong>Interoperabilität</strong>:<br />
aktuelles aus der Forschung<br />
Andreas Morf, <strong>IGP</strong>-ETH Zürich, Josef Dorfschmid, ADASYS AG<br />
Semantische <strong>Interoperabilität</strong> – aktuelle Projekte<br />
12<br />
13<br />
Datenmigration UIC<br />
Dr. Théophil Engel, SBB<br />
Integration der Daten der L<strong>and</strong>eskarte 1:25’000 (VECTOR25) ins<br />
Datenmodell der Amtlichen Vermessung (DM.01 AV CH)<br />
Robert Balanche, swisstopo<br />
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
14<br />
15<br />
16<br />
17<br />
Nationale Geodaten-Infrastruktur (NGDI): Organisatorische Aspekte<br />
der <strong>Interoperabilität</strong> beim Bund<br />
Rolf Buser, KOGIS<br />
Nationale Pr<strong>of</strong>ile der internationalen St<strong>and</strong>ards am Beispiel<br />
Metadaten<br />
Rudolf Schneeberger, ITV Geomatik AG<br />
<strong>Interoperabilität</strong> – nicht nur eine Frage der Technologie<br />
Willy Müller, Informatik Strategie Organ Bund<br />
<strong>Interoperabilität</strong> auf strategischer und administrativer Ebene<br />
Pr<strong>of</strong>. Dr.François Golay, LaSIG-ETH Lausanne<br />
Organisatorische Folgen der <strong>Interoperabilität</strong> II<br />
18<br />
19<br />
20<br />
<strong>Interoperabilität</strong> in der Praxis: Erfahrungen aus Projekten im In- und<br />
Ausl<strong>and</strong><br />
Dr. Ivo Leiss, Ernst Basler + Partner AG<br />
Perspektiven für die Geomatik-Berufe<br />
Christian Kaul, Kaul Beratungen GmbH<br />
Tarifierung, Kostenfrage<br />
Jürg Kaufmann, Kaufmann Consulting<br />
Spezielle Aspekte der <strong>Interoperabilität</strong> in der Praxis<br />
21<br />
22<br />
Georeferenzierung, <strong>Interoperabilität</strong> zwischen Vermessungsdaten<br />
und darauf aufbauender Rauminformation, Datenhierarchie und<br />
Nachführung der abhängigen Rauminformation<br />
Dr. Horst Düster, AGI Solothurn<br />
Der Mobilitäts-Graph: ein geographisches Rahmenwerk für die<br />
Partner des Mobilitäts-Informationssystems der Region Genf<br />
Pascal Oehrli, SIT Genf
Aless<strong>and</strong>ro Carosio, Pr<strong>of</strong>. Dr.<br />
Eidg. Technische Hochschule Zürich<br />
Institut für Geodäsie und Photogrammetrie<br />
ETH Hönggerberg<br />
CH-8093 Zürich<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 1 633 30 52<br />
+41 1 633 11 01<br />
1<br />
<strong>Interoperabilität</strong> in GIS<br />
Anforderungen, Strategien, Lösungsansätze<br />
Aless<strong>and</strong>ro Carosio, ETH Zürich
1 <strong>Interoperabilität</strong> und Datentransfer: Eine zentrale<br />
Funktion jedes GIS<br />
Das Entstehen und der erfolgreiche Einsatz von Geoinformationssystemen sind mit einer<br />
wirksamen Lösung des Problems der <strong>Interoperabilität</strong> und des Transfers der Geodaten<br />
untrennbar gekoppelt. Nur kleine Applikationen, die die Verarbeitung von kleinen<br />
Datenmengen während kurzer Zeit erfordern (z.B. GIS-Übungen in der Ausbildung),<br />
können ohne eine Lösung des Datentransferproblems auskommen.<br />
Wir verfügen heute über eine immer grösser werdende Menge geographischer Daten in<br />
digitaler Form und einer grossen Anzahl Organisationen, die mit Daten dieser Art arbeiten.<br />
Das Risiko, dass Doppelspurigkeiten und Widersprüche entstehen, ist gross.<br />
Oft existieren die benötigten Daten bereits. Sie werden aber wieder erfasst, weil:<br />
� eine geeignete Dokumentation fehlt oder<br />
� sie eine inkompatible Struktur aufweisen.<br />
Ein GIS ist nur erfolgreich, wenn es die Anforderungen möglichst vieler User erfüllt.<br />
Abb. 1 : Die Kommunikation zwischen Geoinformationssystemen<br />
Die Anforderungen und die Bedürfnisse sind allerdings sehr unterschiedlich. Dies ist<br />
der Grund, warum es bis jetzt relativ schwierig war, eine alles umfassende St<strong>and</strong>ardlösung<br />
zu finden.<br />
Die wirtschaftlich entwickelten Länder realisieren zur Zeit geeignete nationale Geodateninfrastrukturen<br />
(NGDI), in welchen Private, Ämter, Lieferanten und Anwender integriert<br />
werden, damit sie gemeinsam Technologien und existierende Daten nutzen<br />
können.<br />
Voraussetzung für die Realisierung von Koordinationszentren (Clearinghouses), für den<br />
Informationsaustausch und für die interoperable Nutzung der Geodaten ist die Lösung<br />
der in Abbildung 2 beschriebenen organisatorischen und technischen Problemen.<br />
Alle aufgezeigten Punkte sind sehr wichtig. Der vorliegende Beitrag befasst sich jedoch<br />
nur mit der technischen Thematik der <strong>Interoperabilität</strong> und der Datenübertragung zwischen<br />
Systemen unterschiedlicher Hersteller.<br />
Die erforderlichen Lösungsansätze für diese beiden Aufgaben sind besonders aktuell,<br />
da man zurzeit sowohl auf nationaler Ebene als auch in internationalen Institutionen<br />
(Europa, Welt) an der Entwicklung von technischen Normen arbeitet, die die Realisierung<br />
von interoperablen Systemen ermöglichen sollen.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 1.1
Einführung in die Thematik<br />
<strong>Interoperabilität</strong> in GIS - Anforderungen, Strategien, Lösungsansätze<br />
Abb. 2 : Organisatorische und technische Voraussetzungen für eine NGDI<br />
2 Bedürfnisse, Lösungsansätze<br />
GIS GIS<br />
Abb. 3 : Datenaustausch und <strong>Interoperabilität</strong><br />
2.1 Die Vielfalt der Anforderungen<br />
Die Komplexität der Frage der Datenübertragung ist die direkte Folge der Vielfalt der<br />
Anwendungen.<br />
Ausgetauscht oder angefragt werden zum Beispiel:<br />
� Graphische Darstellungen (digitale Karten und Pläne)<br />
� Beschreibungen der GIS-Inhalte (Metadaten)<br />
� Resultate von Abfragen (Tabellen, Karten usw.)<br />
� Strukturierte Datenbankinhalte (z.B. Tabellen, Attribute) ohne Änderung der Datenstrukturen<br />
� Daten von einer Datenbank in eine <strong>and</strong>ere Datenbank mit unterschiedlichen Datenstrukturen<br />
� Vollständige Objekte in einer objektorientierten Umgebung (inkl. Operationen)<br />
Bereits diese kleine Auswahl von häufig auftretenden Datentransferwünschen gibt einen<br />
Eindruck über die Vielfalt der Bedürfnisse mit ihren sehr unterschiedlichen Komplexitäten.<br />
1.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
2.2 Die Vielfalt der Lösungen<br />
Einführung in die Thematik<br />
<strong>Interoperabilität</strong> in GIS - Anforderungen, Strategien, Lösungsansätze<br />
Interoperable GIS können auf unterschiedliche Arten realisiert werden:<br />
� Datentransfer<br />
o Datenaustausch zwischen gleichen Systemen<br />
o Datenaustausch mit St<strong>and</strong>ardformaten<br />
o Modellbasierte Datentransfermethoden<br />
� <strong>Interoperabilität</strong><br />
o <strong>Interoperabilität</strong> (nach OGC = Open Geospatial Consortium; früher Open<br />
GIS Consortium)<br />
3 Der eigentliche Datentransfer<br />
3.1 Proprietäre Transferformate: ein Grundbedürfnis<br />
Das Inbetriebsetzen einer GIS-Applikation, die Verkaufsvorführungen, die erste Schulung<br />
von neuen Anwendern und die Tests des Herstellers während der S<strong>of</strong>twareentwicklung<br />
erfordern die Übernahme von Demonstrationsdaten des gleichen GIS-<br />
Herstellers von einer Applikation zu einer <strong>and</strong>eren. So verfügen alle GIS über die Möglichkeit,<br />
die gespeicherten Daten in St<strong>and</strong>arddateien (in der Regel sequentielle Dateien)<br />
auszugeben und aus den gleichen Dateien wieder zu übernehmen. Die verwendeten<br />
Formate sind ausschliesslich geeignet für eine bestimmte GIS-S<strong>of</strong>tware (proprietäres<br />
Format) und erfordern beim Sender und beim Empfänger die identische Datenstruktur<br />
für die transferierten Daten.<br />
GIS<br />
Abb. 4 : Datentransfer mit proprietären Formaten<br />
Andere proprietäre Formate, welche <strong>of</strong>t de facto St<strong>and</strong>ard geworden sind, werden für<br />
die Ausgabe von graphischen Darstellungen (z.B. Plottfiles), die aus der raumbezogenen<br />
Information hergeleitet werden (Karten und Pläne), verwendet. Die GIS-S<strong>of</strong>tware beinhaltet<br />
normalerweise die Treiber für die erforderliche Steuerung und Generierung der<br />
Datenformate.<br />
3.2 St<strong>and</strong>ard-Formate<br />
Das Bedürfnis, Geoinformationen zwischen Systemen unterschiedlicher Hersteller auszutauschen<br />
war bereits in der Vergangenheit, besonders in grossen Organisationen (Telecom,<br />
Eisenbahngesellschaften, militärische Organisationen, usw.), stark spürbar.<br />
Bei solchen Anwendungen hat man mit Geoinformationssystemen zu tun, in welchen<br />
die zu verwaltenden Informationen für alle Systeme einheitlich festgelegt sind. Dies ist<br />
vor allem in stark hierarchischen Organisationen der Fall (NATO, Staatsbetriebe usw.).<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 1.3<br />
GIS
Einführung in die Thematik<br />
<strong>Interoperabilität</strong> in GIS - Anforderungen, Strategien, Lösungsansätze<br />
Wenn sowohl die geometrischen als auch die thematischen Inhalte feststehen, kann man<br />
ein passendes Format definieren, das die Information aufnehmen kann und es ist möglich<br />
in jedem System die entsprechende Schnittstelle für das Lesen und Schreiben der<br />
Transferdateien in das definierte Format einzubauen. So wurden zum Beispiel für die<br />
NATO das Austauschformat DIGEST (Digitial Geographic Information Exchange St<strong>and</strong>ard)<br />
und für den Ordnance Suvey (OS) in Grossbritannien das Format NTF (National<br />
Transfer Format) definiert.<br />
GIS<br />
Abb. 5 : Datentransfer mit St<strong>and</strong>ard-Formaten<br />
Ein weiteres Bedürfnis, das sehr verbreitet ist, ist die Abgabe von Geoinformationen an<br />
Partner, die sie nur graphisch auf ihren Computersystemen weiter verarbeiten werden.<br />
Auf diese Art verwenden <strong>of</strong>t Architekten und Bauingenieure die erhaltenen Geodaten.<br />
Sie werden in CAD-Systemen für die Projektierung eingesetzt. Der de facto St<strong>and</strong>ard im<br />
CAD-Bereich ist zurzeit DXF, ein Format, in welchem die Information in thematische<br />
Ebenen (Layer) unterteilt wird.<br />
Die meisten GIS-Hersteller sehen vor, Daten in DXF auszugeben und auch zu lesen. Dabei<br />
ist zu beachten, dass nur eine Teilmenge der Information (hauptsächlich die Graphik)<br />
in DXF abgebildet werden kann (�Informationsverlust). Sehr vorteilhaft sind bei<br />
dieser Form der Datenabgabe Vereinbarungen oder Normen, um die Layer-Zuordnung<br />
und Nummerierung einheitlich zu gestalten.<br />
Als das Projekt der Reform der Amtlichen Vermessung in der Schweiz realisiert wurde,<br />
stellte man mit Besorgnis fest, dass die Festlegung von einheitlichen Datenstrukturen<br />
für die Systeme der 26 Kantone unrealistisch war. Folglich war auch die Definition eines<br />
gemeinsamen Datentransferformats ein unmögliches Bestreben.<br />
Nicht <strong>and</strong>ers geschah es ein paar Jahre später auf europäischer Ebene. Auf Anregung<br />
von Frankreich wurde das TC 287 der europäischen Normungsorganisation CEN gegründet,<br />
um unter <strong>and</strong>erem auch Normen für den Transfer geographischer Daten in<br />
Kraft zu setzen. Grossbritannien und Frankreich hatten sich vorgestellt, ihre Formate<br />
NTF und EDIGéO (Echange de Données Informatisées GéOgraphiques) für Europa zu<br />
erweitern (z.B. ETF). Die ersten Sitzungen zeigten aber, dass die Bedürfnisse und die<br />
Systeminhalte sehr unterschiedlich und vor allem die Anwendungen extrem vielfältig<br />
sind und daher die Festlegung von St<strong>and</strong>ardformaten ein unmögliches Unterfangen ist.<br />
Man brauchte <strong>and</strong>ere Lösungsansätze. Wenn unterschiedliche Datenstrukturen erwartet<br />
werden, sind modellbasierte Verfahren anstatt feste Formate der richtige Weg.<br />
3.3 Modellbasierte Transferverfahren<br />
Geoinformationen der heutigen Zeit bieten den Anwendern neben einer festgelegten<br />
Datenstruktur für die geometrischen Daten die Möglichkeit, die thematischen Inhalte<br />
frei zu definieren. Das System bildet dann aufgrund der Datenstrukturbeschreibung<br />
1.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Einführung in die Thematik<br />
<strong>Interoperabilität</strong> in GIS - Anforderungen, Strategien, Lösungsansätze<br />
(Eingabe des DB-Schemas) die erforderlichen Entitätsklassen (in der Regel relationale<br />
DB-Tabellen). Somit passt sich die Datenverwaltung den Bedürfnissen an.<br />
GIS<br />
Abb. 6 : Modellbasierte Transferverfahren<br />
Man kann diese Idee auch brauchen, um den Datentransfer flexibel zu gestalten: Die<br />
Struktur der Daten, die man übertragen möchte, wird beschrieben und daraus kann ein<br />
Format für diese Daten hergeleitet werden. Dafür benötigt man zwei Komponenten: erstens<br />
eine st<strong>and</strong>ardisierte Datenbeschreibungssprache, um die Struktur der Daten, die<br />
man transferieren möchte, eindeutig und konsistent zu beschreiben, und zweitens ein<br />
genormtes Verfahren, um aus der Datenstruktur ein Format herzuleiten.<br />
Format-<br />
Herleitung<br />
Abb. 7 : Komponente des modellbasierten Transferverfahrens<br />
In der europäischen Normung wurde EXPRESS als Sprache festgelegt, da sie bereits eine<br />
gewisse Verbreitung hat (CAD, Automobilindustrie usw.). Applikationen im Geo-<br />
Bereich existieren allerdings noch nicht und ihre Komplexität ist für eine Implementierung<br />
nicht förderlich.<br />
In der Schweiz wurde für die Amtliche Vermessung vor mehr als 10 Jahren die Sprache<br />
INTERLIS definiert, welche die Beschreibung der Thematik in einem GIS nach einem<br />
relationalen Modell und der Geometrie aufgrund von festgelegten Geometrieelementen<br />
(Punkte, Geraden, Kreisbögen, Einzelflächen, Gebietseinteilungen) ermöglicht. Die<br />
Sprache passt sehr gut zu den heutigen GIS. Sie verfügte von Anfang an über einen<br />
Compiler für die automatische Herleitung der Transferformate und wird zunehmend<br />
eingesetzt. Zurzeit kann weltweit keine <strong>and</strong>ere Lösung als operationell betrachtet werden.<br />
Im Technischen Komitee der ISO (TC 211) konnte nur INTERLIS als in GIS implementierter<br />
modellbasierter Transfermechanismus für Geodaten vorgeführt werden.<br />
ISO hat bisher folgendes beschlossen:<br />
� Die modellbasierten Transferverfahren sind als St<strong>and</strong>ard erklärt.<br />
� UML wurde als graphischer Formalismus für die Beschreibung der Datenstrukturen<br />
festgelegt.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 1.5
Einführung in die Thematik<br />
<strong>Interoperabilität</strong> in GIS - Anforderungen, Strategien, Lösungsansätze<br />
� Eine textuelle Sprache, die automatisch gelesen und interpretiert werden kann,<br />
ist vorgesehen, ihre Eigenschaften wurden beschrieben und festgelegt. Kein Entscheid<br />
wurde getr<strong>of</strong>fen. Mögliche Lösung INTERLIS 2.<br />
Die Schweiz hat die neue INTERLIS Version (INTERLIS 2) entwickelt, um die volle<br />
Kompatibilität mit den ISO-Normen (Objektorientierung, Inkrementelle Nachführung,<br />
usw.) zu erfüllen. In diesem Rahmen wurde auch die Schnittstelle zwischen UML und<br />
INTERLIS realisiert, damit ein UML-Schema in INTERLIS automatisch übersetzt werden<br />
kann (und umgekehrt). Ebenfalls wurde das Transferformat im Informatik-<br />
St<strong>and</strong>ard XML definiert. Demnächst wird man auch ein Transferformat auf der Basis<br />
von GML erzeugen können.<br />
Die modellbasierten Technologien bieten auch für <strong>and</strong>ere Bereiche Lösungsansätze.<br />
Moderne GIS ermöglichen heute die Implementierung des Modells direkt aus dem konzeptionellen<br />
Schema (in UML oder in INTERLIS):<br />
� ArcGIS (ESRI) kann die Datenstruktur aus Schemata in UML (erzeugt mit Micros<strong>of</strong>t<br />
Visio) implementieren<br />
� GeosPro/GeoMedia (a/m/t, Intergraph) aus INTERLIS<br />
� Topobase (C-Plan) aus INTERLIS oder aus UML<br />
4 <strong>Interoperabilität</strong><br />
Während die bisherigen Lösungen alle als Ziel haben, die Daten von einem System zu<br />
einem <strong>and</strong>eren zu transferieren, sind Kommunikationsmöglichkeiten denkbar, die ohne<br />
Verschiebung der Originalgeodaten auskommen. Diese Lösung ist besonders interessant,<br />
wenn nur einfache Auswertungen der Information benötigt werden (z.B. eine graphische<br />
Darstellung von einem Ausschnitt oder die Auflistung von bestimmten Objekten).<br />
In diesen Fällen ist es einfacher, die Auswertungsbefehle und -ergebnisse zu st<strong>and</strong>ardisieren<br />
und zu transferieren als die Grunddaten selbst.<br />
Die <strong>Interoperabilität</strong> bedeutet die Parallelnutzung von verschiedenen GIS, indem die<br />
Befehle (Anfragen) und die daraus entstehenden Ergebnisse (Antworten) ausgetauscht<br />
werden (siehe Abb.8).<br />
Die GIS-Industrie (S<strong>of</strong>twarehersteller) hat diesen Weg als für den Markt interessant angesehen<br />
und das Open Geospatial Consortium (OGC) gegründet, um diese Technik<br />
möglichst weit zu entwickeln. Dank der Beteiligung der führenden weltweit tätigen<br />
Firmen (ESRI, Intergraph, Siemens, Oracle, Micros<strong>of</strong>t usw.) und der Einbindung von<br />
Universitäten und Forschungsinstitutionen hat OGC grosse Resonanz erhalten und entsprechend<br />
grosse Erwartungen geweckt.<br />
1.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Einführung in die Thematik<br />
<strong>Interoperabilität</strong> in GIS - Anforderungen, Strategien, Lösungsansätze<br />
Abb. 8 : <strong>Interoperabilität</strong><br />
Aus dem Konzept der <strong>Interoperabilität</strong> sieht man s<strong>of</strong>ort die Vorteile:<br />
� das Datenverwaltungskonzept kann in den kommunizierenden Systemen sehr<br />
unterschiedlich sein.<br />
� Das abfragende System muss nichts über die Datenorganisation des angefragten<br />
Systems wissen.<br />
� Die Systeme geben nur Teile der Information weiter. Der volle Inhalt bleibt unter<br />
der eigenen Kontrolle (Urheberrecht).<br />
Ein Vorteil für die GIS-Hersteller:<br />
� die Kunden können nicht so leicht das System wechseln<br />
Ebenfalls sichtbar sind die Grenzen: die Vielfalt der st<strong>and</strong>ardisierten Abfragen und der<br />
Antwortformen darf nicht zu gross sein. Falls die gewünschten Interoperationen zu<br />
komplex, zu vielfältig und anzahlmässig zu gross werden, ist der Austausch der Daten<br />
einfacher und günstiger als die St<strong>and</strong>ardisierung der Operationen. Selbstverständlich<br />
müssen die Systeme vergleichbare Informationen enthalten. Zurzeit hat OGC nur Lösungen<br />
vorgesehen für Abfragen, die in den Bezeichnungen angeglichen wurde (syntaktische<br />
<strong>Interoperabilität</strong>).<br />
Zusammenfassend kann man sagen, dass die <strong>Interoperabilität</strong> interessant ist, wenn:<br />
� einfache Auswertungen der Geoinformationen benötigt werden (z.B. graphische<br />
Darstellungen, Listen von Objekten oder Attributen)<br />
� die Systeme, die angefragt werden, gleichzeitig in Betrieb sind<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 1.7
Einführung in die Thematik<br />
<strong>Interoperabilität</strong> in GIS - Anforderungen, Strategien, Lösungsansätze<br />
5 Metadaten<br />
Die immer grössere Verbreitung der Geoinformationssysteme stellt uns vor neue Probleme:<br />
es fehlen <strong>of</strong>t Informationen über die verfügbaren Geoinformationssysteme und<br />
ihre Daten. Um diese wichtigen Informationen zugänglich zu machen, entstehen Metainformationssysteme,<br />
welche Metadaten (Daten über die Daten) verwalten. Diese Systeme<br />
sind ihrerseits Geoinformationssysteme, in welchen ein Teil der Metainformationen<br />
raumbezogen ist (wo und über welches Gebiet findet man Daten). Zu den Metadaten<br />
gehören Informationen über die Qualität, die Verfügbarkeit, die Nutzungsbeschränkungen,<br />
die Kosten usw. Die Beschreibung der Datenstruktur in einer genormten Sprache<br />
(EXPRESS, INTERLIS, UML usw.) kann ebenfalls dazu gehören.<br />
Ansätze für die Normung von Metadaten befinden sich im ISO-Normenwerk. In der<br />
Nationalen Geodaten-Infrastruktur (NGDI) wird man aus den internationalen Normen<br />
nationale Pr<strong>of</strong>ile (Teilmengen) definieren, um eindeutige Interpretationen zu ermöglichen.<br />
Zurzeit werden Metadaten zur visuellen Konsultation zur Verfügung gestellt. In Zukunft<br />
werden sie automatisch von interoperierenden Systemen bei der Datensuche genutzt<br />
werden.<br />
6 Die Wünsche und das Erreichbare<br />
6.1 Wünschbares<br />
Die optimistischen Beschreibungen der unterschiedlichen Datentransfer-Konzepte<br />
könnten den Eindruck entstehen lassen, dass - mit etwas Geduld und finanziellen Mitteln<br />
- das Problem des automatischen Austausches von Geoinformationen zwischen beliebigen<br />
Systemen ohne weiteres lösbar sei.<br />
GIS GIS GIS<br />
Abb. 9 : <strong>Interoperabilität</strong> zwischen beliebigen Systemen mit beliebigen Datenstrukturen sind<br />
gewünscht.<br />
Dies entspricht selbstverständlich dem, was man sich wünscht. Man möchte die wertvollen<br />
Informationen, die an verschiedenen Orten erfasst und verwaltet werden, gemeinsam<br />
nutzen.<br />
6.2 Technische Grenzen<br />
Eine voll automatische Datenübertragung oder die gemeinsame Nutzung der Daten in<br />
beliebig konfigurierten Geoinformationssystemen ist nicht möglich. Die unüberwindbare<br />
Grenze liegt in der nicht st<strong>and</strong>ardisierten Semantik der Datenstrukturbeschreibungen.<br />
1.8 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Einführung in die Thematik<br />
<strong>Interoperabilität</strong> in GIS - Anforderungen, Strategien, Lösungsansätze<br />
Die folgenden Beispiele illustrieren häufig vorkommende Fälle.<br />
Im Sendersystem wird eine thematische Klasse von Elementen mit dem Begriff „HÄU-<br />
SER“ identifiziert, während der Empfänger dasselbe mit „GEBÄUDEN“ bezeichnet.<br />
Selbstverständlich können Fremdsprachen und Abkürzungen weitere Hindernisse zu<br />
einer automatischen Interpretation bieten. Es kommt auch die umgekehrte Situation vor.<br />
Gleiche Begriffe bedeuten in den zwei kommunizierenden Systemen <strong>and</strong>ere Objekte. In<br />
einem System bedeutet der Begriff „WEGE“ die Menge aller Verkehrsverbindungen<br />
(Strassen, Eisenbahnen, schiffbare Kanäle usw.), im <strong>and</strong>eren sind „WEGE“ kleine Strassen<br />
in einer Ortschaft (Schlossweg, Alpenweg usw.). Noch häufiger sind die Fälle dazwischen,<br />
in welchen die thematischen Elemente <strong>and</strong>ere Bezeichnungen und auch eine<br />
<strong>and</strong>ere Unterteilung haben (Abb.10).<br />
Abb. 10 : Im allgemeinen Fall kann die Zuordnung der einzelnen Attribute nicht automatisch<br />
stattfinden.<br />
Die Semantik der Datenbeschreibung kann in einem freien Umfeld nicht st<strong>and</strong>ardisiert<br />
werden. Für die Zuordnung der Entitäten und der Attribute braucht man Zusatzinformationen.<br />
Es ist zu beachten, dass die Zuordnung von der Bedeutung der Objekte und<br />
der Attribute abhängig ist. Sie ist daher auch von den Betriebsanweisungen und von<br />
den Regeln der Datenakquisition beeinflusst. Weder Mensch noch Computer werden in<br />
der Lage sein, ohne Zusatzauskünfte die Zuordnung der Entitäten und der Attribute<br />
vorzunehmen. Man wird sich zuerst erkundigen müssen oder ausführliche Beschreibungen<br />
lesen, um aufgrund der eigenen Interpretationen und Zielsetzungen die Datenfelder<br />
in Beziehung zu bringen.<br />
Diese Zuordnung muss das erste Mal aufgrund von:<br />
� Einer Analyse eines Experten<br />
� Anfragen bei den Verantwortlichen<br />
� Konsultationen von Metadaten erfolgen<br />
Erst danach kann eine semantische Transformation automatisch ausgeführt werden.<br />
Für die modellbasierten Transferverfahren haben S<strong>of</strong>tware-Hersteller Module entwickelt,<br />
die zwei Datenstrukturen (z.B. aus ihrer Beschreibung in INTERLIS) darstellen<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 1.9
Einführung in die Thematik<br />
<strong>Interoperabilität</strong> in GIS - Anforderungen, Strategien, Lösungsansätze<br />
und die Zuordnung der Entitätsklassen und Attribute auf Formatebene interaktiv am<br />
Bildschirm erlauben. Weitere Entwicklungen in dieser Richtung aber auf konzeptueller<br />
Ebene sind zu erwarten (semantische Transformationen, semantische <strong>Interoperabilität</strong>).<br />
Agent<br />
Abb. 11: Semantische Transformationen mit Hilfe von Ontologien<br />
Zwischen föderierten Systemen (unter gemeinsamen Regeln organisiert) wird es in spezifischen<br />
Bereichen möglich sein, Ontologien zu entwickeln, welche die Semantik von<br />
mehreren Systemen beschreiben und die Herstellung von automatischen Transformationsmodulen<br />
(Agenten) ermöglichen werden.<br />
Die Ontologien sind Gegenst<strong>and</strong> der heutigen Forschung. Man wird allerdings nur die<br />
Semantik in klar definierten und abgegrenzten Sektoren eindeutig beschreiben können.<br />
Eine Ontologie entspricht einer St<strong>and</strong>ardisierung der Begriffe, die man für die Modellbildung<br />
und für die Bezeichnung der Elemente der Datenstruktur im GIS verwendet<br />
hat.<br />
7 Entwicklungsstrategien<br />
Ontologie<br />
Agent<br />
Jeder der bisher geschilderten Lösungsansätze ist, trotz der erwähnten technischen<br />
Grenzen, eine optimale Antwort für einzelne Fälle mit ihren unterschiedlichen Anforderungen.<br />
Es ist daher nicht zu erwarten, dass sich ein einziger besonderer Lösungsansatz<br />
als Weltst<strong>and</strong>ard für den Transfer von Geoinformationen durchsetzen wird:<br />
� Proprietäre Formate werden zu jeder GIS-S<strong>of</strong>tware gehören. Sie sind die optimale<br />
Lösung für die Systemadministration. Sie übertragen die Daten eines bestimmten<br />
Systems vollständig (inkl. Konfigurationsparameter). Sie können auch<br />
für den internen Datenaustausch in grossen Organisationen dienen, die mehrere<br />
identische Systeme betreiben.<br />
� St<strong>and</strong>ardformate sind einzusetzen, wenn die Inhalte der GIS zentral festgelegt<br />
werden. Zur beschlossenen Datenstruktur kann ein Format definiert werden, mit<br />
welchem die Daten sequentiell übertragen werden können. St<strong>and</strong>ardformate<br />
sind ebenfalls die geeignete Lösung für die Abgabe von GIS-Daten an CAD-<br />
Systeme. DXF ist im CAD-Bereich am meisten verbreitet. Wünschenswert ist dabei<br />
die Normung der Layer.<br />
1.10 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Einführung in die Thematik<br />
<strong>Interoperabilität</strong> in GIS - Anforderungen, Strategien, Lösungsansätze<br />
� Modellbasierte Transferverfahren sind die Lösung für den Datenaustausch<br />
zwischen Systemen, die eine eigene Datenstruktur besitzen. Die ankommenden<br />
Daten beinhalten die Datenstrukturbeschreibung in einem genormten Formalismus<br />
(Datenbeschreibungssprache). Zur Sprache gehört auch das Verfahren, um<br />
daraus die Formate herzuleiten. Wenn die Strukturen der erhaltenen Daten und<br />
der Daten des Empfänger-Systems nicht identisch sind, kann eine voll automatische<br />
Übernahme nicht stattfinden. Die Zuordnung der Entitätsklassen und der<br />
Attribute muss das erste Mal aufgrund menschlicher Interpretation geschehen.<br />
Um diese interaktive Arbeit zu erleichtern, haben S<strong>of</strong>tware-Hersteller Module<br />
entwickelt, die zwei Datenstrukturen vergleichen und am Bildschirm die Zuordnung<br />
der Tabellenfelder erlauben (z.B. INTERLIS-Studio von Leica).<br />
Abb. 12 : Bei der ersten Datenübertragung muss die Beziehung zwischen den Attributen definiert<br />
sein.<br />
� <strong>Interoperabilität</strong> ist die Alternative, mit welcher die Kommunikation zwischen<br />
den GIS ohne Austausch der Geodaten stattfinden kann. Genormt werden die<br />
Anfragen und die Formate für die Übermittlung der Antworten (Services Interfaces).<br />
Der tatsächliche Umfang der Möglichkeiten, die im Rahmen der OGC-<br />
Arbeiten entstehen werden, ist schwer vorherzusagen. Zurzeit sind einfache Anfragen<br />
(Visualisierungen, Selektionen) und der Zugriff auf einfache geographische<br />
Objekte spezifiziert.<br />
Sicher werden einfache Anfragen (Visualisierungen, Selektionen) zur Verfügung<br />
stehen. Ebenfalls spezifiziert ist bereits der Zugriff zu einer einfachen Koordinatengeometrie.<br />
Da in den Absichten des Open Geospatial Consortium (OGC)<br />
nicht nur die Kommunikation zwischen den Systemen im Vordergrund steht,<br />
sondern auch das Zusammensetzen von ganzen GIS aus selbstständigen Komponenten,<br />
werden die Schnittstellen zwischen den frei gewählten S<strong>of</strong>tware-<br />
Modulen ebenfalls benötigt. Die erforderliche Zeit und die Erreichbarkeit der<br />
Ziele sind nicht leicht vorsehbar.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 1.11
Einführung in die Thematik<br />
<strong>Interoperabilität</strong> in GIS - Anforderungen, Strategien, Lösungsansätze<br />
8 Schlussfolgerung<br />
Die Kommunikation zwischen Geoinformationssystemen ist eine vielseitige Aufgabe,<br />
für welche eine Vielfalt von Lösungsansätzen zur Verfügung steht. Die Probleme, die<br />
Anforderungen und die technischen Grenzen sind erst in neuster Zeit in ihrer ganzen<br />
Breite wahrgenommen worden. Die heute eingesetzten Datentransferverfahren und die<br />
<strong>Interoperabilität</strong> werden sich in den nächsten Jahren stark entwickeln. Mehrere Methoden<br />
werden sich als St<strong>and</strong>ard durchsetzen. Die nächsten Schritte der Forschung sind im<br />
Bereich der semantischen <strong>Interoperabilität</strong> und der semantischen Transformationen zu<br />
erwarten.<br />
Diese Arbeiten sind die Voraussetzung, damit Geoinformationssysteme ihre wertvollen<br />
Daten ohne Verzögerung und Hindernisse der ganzen Gesellschaft zur Verfügung stellen<br />
können.<br />
1.12 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Urs Flückiger<br />
ESRI Geoinformatik AG<br />
Beckenh<strong>of</strong>str. 72<br />
CH-8006 Zürich<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 1 360 24 60<br />
+41 1 360 24 70<br />
2<br />
Überblick<br />
Urs Flückiger, SOGI Fachgruppe GIS Technologie
Dieser Beitrag soll dem Interessenten einen Überblick zum Thema nationale und internationale<br />
St<strong>and</strong>ards im Gesamtkontext zu „<strong>Interoperabilität</strong> für die breite Nutzung von<br />
Geodaten“ geben. Im Gegensatz zu den nachfolgenden Beiträgen kann dieser Einstieg<br />
ins Thema nicht in die Details gehen. An der Tagung beh<strong>and</strong>elte Themen finden sich als<br />
Beispiele wieder.<br />
Was ist <strong>Interoperabilität</strong>? – <strong>Interoperabilität</strong> ist, wenn ein System mit <strong>and</strong>eren Systemen<br />
unterschiedlichen Ursprungs innerhalb vordefinierter Grenzen zusammenarbeiten kann<br />
und darf. Durch Spezifikationen und Normen entsteht <strong>Interoperabilität</strong>. <strong>Interoperabilität</strong><br />
findet auf verschiedenen technologischen Ebenen statt.<br />
Leisten Normen einen Beitrag zur <strong>Interoperabilität</strong>? – Normen erleichtern das Leben in<br />
einer vernetzten Welt. In den wenigsten Fällen werden Daten nur für einen kurzfristigen<br />
Moment erfasst und nur in einem System gehalten. Deshalb ist die Schaffung und<br />
Durchsetzung von Normen eine bedeutende Aufgabe. Normen erleichtern die Vernetzung<br />
und bauen technologische Hindernisse zur Zusammenarbeit ab.<br />
Gibt es einen Markt für Normen? – Verschiedene Gruppierungen befassen sich damit.<br />
Der Nutzen ist unterschiedlich. Alle Beteiligten pr<strong>of</strong>itieren jedoch in irgendeiner Weise.<br />
1 Normung<br />
1.1 Definition von Normung<br />
Normung heisst die planmässige, durch interessierte Kreise durchgeführte Vereinheitlichung<br />
von materiellen und immateriellen Gegenständen zum Nutzen der Allgemeinheit<br />
(DIN). Das Ergebnis von Normung ist eine technische Vorschrift, die man Norm nennt<br />
(englisch: st<strong>and</strong>ard). Eine „de jure Norm“ (oder kurz Norm) ist eine solche technische<br />
Vorschrift, die von nationalen oder internationalen Normenverbänden festgelegt wird.<br />
Eine „de facto Norm“ ist eine allgemein anerkannte und mehrheitlich genutzte technische<br />
Vorschrift, die sich aus der weiten Verbreitung eines Produktes ergibt, durch die<br />
ausschliessliche Nutzung innerhalb eines Unternehmens (so genannter Industrie-<br />
St<strong>and</strong>ard) oder durch nationale oder internationale Interessengemeinschaften oder Konsortien<br />
festgelegt wird. Sowohl Normen als auch de facto Normen sind nur dann verbindlich<br />
und müssen durch natürliche und juristische Personen angewendet werden,<br />
wenn durch gesetzliche oder vertragliche Regelungen deren Einhaltung gefordert wird.<br />
Typ Norm (Gremium) De facto Norm (Gremium)<br />
Betriebssysteme Unix, Linux (ANSI) Windows 2000 (Micros<strong>of</strong>t)<br />
Datenbanken SQL-92 (ISO)<br />
DXF (AutoCAD), Shapefile<br />
Datenformat XML (W3C), ITF (SNV)<br />
(ESRI)<br />
Java (Sun), Visual Basic (Micro-<br />
Programmiersprachen C++ (ANSI)<br />
s<strong>of</strong>t)<br />
J2EE (SUN Microsystems),<br />
Internet-Dienste HTTP (ISO), SOAP, UDDI<br />
WSDL (W3C)<br />
GI-St<strong>and</strong>ards ISO 19115 Metadaten (ISO) WMS (OGC)<br />
Verb<strong>and</strong>sspezifisch SIA-Norm 405 (SIA)<br />
Tab. 1 : Beispiele von Normen und de facto Normen<br />
Normen, insbesondere für die Dokumentation (Metadaten), die Modellierung (einheitliche<br />
Beschreibungssprache) sowie den Datenaustausch (Bezugsmechanismus und Datenformat)<br />
erhöhen die Flexibilität, die Funktionalität und die Produktivität eines Informationssystems.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 2.1
Nationale und internationale St<strong>and</strong>ards<br />
Überblick<br />
1.2 Normierungsorganisationen<br />
1.2.1 De jure Normierungsorganisationen<br />
Internationale Organisation für St<strong>and</strong>ardisierung (ISO)<br />
ISO ist die Internationale Organisation für St<strong>and</strong>ardisierung für Business, Behörden und<br />
Gesellschaft. Die Mitglieder-Organisationen können die Normen übernehmen.<br />
Beispiele für ISO-Normen:<br />
� ISO 19103 Geographic Information – Conceptual Schema Language<br />
� ISO 19115 Geographic Information – Metadata<br />
� ISO 19119 Geographic Information – Services<br />
� ISO 19136 Geographic Information – Geography Markup Language<br />
� ISO 19139 Geographic Information – Metadata – Implementation Specification<br />
TC211 ist das technische Komitee Nr. 211 der ISO, das sich mit Geografischen Informationen<br />
und Geomatik beschäftigt. Dieses Komitee bearbeitet die Normenserie ISO 19100,<br />
welche verschiedenste Geodaten-St<strong>and</strong>ards (Metadata, Spatial Schema, Spatial Reference,<br />
Application Schema, Conceptual Schema Language, Quality, Encoding, Catalog ...)<br />
beinhaltet.<br />
Die ISO TC211 und das Open Geospatial Consortium (OGC) arbeiten zusammen und<br />
unterstützen sich gegenseitig. Eine Spezifikation bei OGC entspricht einer Ebene der<br />
19100-er Normenserie bei ISO. Die mit dem Abkommen verfolgten Ziele sind:<br />
� OGC-konforme Produkte werden (fast) konform mit dem St<strong>and</strong>ard aus ISO<br />
TC211.<br />
� Verbesserung der St<strong>and</strong>ards bei OGC und ISO TC211.<br />
� Schnellere Entwicklung und Austesten von Spezifikationen in Testumgebung und<br />
Pilotprojekten.<br />
� Beachtung von Marktkonditionen.<br />
Europäisches Komitee für St<strong>and</strong>ardisierung (CEN)<br />
CEN ist das Europäische Komitee für St<strong>and</strong>ardisierung. CEN wird voraussichtlich beschliessen<br />
die Normenserie ISO 19100 weitgehend zu übernehmen. Die Mitglieder von<br />
CEN haben sich verpflichtet die CEN-Normen zu ratifizieren.<br />
Schweizerische Normenvereinigung (SNV)<br />
Die SNV ist Mitglied von CEN und daher verpflichtet, die CEN-Normen und somit die<br />
ISO-Normen zu übernehmen, falls diese zu CEN-Normen werden. Dies bedeutet, dass<br />
allfällige Schweizer Normen, welche im Widerspruch mit CEN bzw. ISO-Normen stehen,<br />
voraussichtlich eliminiert werden müssten. Da die Schweizer Geonormen auf<br />
Grund von praktischen Bedürfnissen entwickelt, implementiert und getestet wurden, ist<br />
die Schweiz daran interessiert, dass auch die allfällig zu übernehmenden internationalen<br />
Normen im GI-Bereich den praktischen Bedürfnissen entsprechen und durch Implementierung<br />
auf ihre Brauchbarkeit geprüft werden. Dafür setzen sich die Schweizer<br />
Vertreter in den entsprechenden Gremien mit zunehmendem Erfolg ein.<br />
2.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nationale und internationale St<strong>and</strong>ards<br />
Überblick<br />
Andererseits bemüht man sich in der Schweiz ebenfalls erfolgreich, die existierenden<br />
und bewährten Normen den aktuellen Entwicklungen in der Informationstechnologie<br />
und im GI-Normenbereich schrittweise anzupassen.<br />
Beispiele für SNV-Normen:<br />
� SN 612 030 und SN 612 031: INTERLIS Modellierungssprache und Datentransfermethode<br />
� SN 612 040: Gebäudeadressen<br />
� SN 612 050: GM03 - Metadatenmodell<br />
1.2.2 De facto Normierungsorganisationen<br />
Open Geospatial Consortium (OGC)<br />
Führende GIS-Hersteller, Datenproduzenten, Behörden, Organisationen und Forschungseinrichtungen<br />
haben sich 1994 im Open Geospatial Consortium (OGC) zusammengeschlossen.<br />
Ziel des Zusammenschlusses ist die Definition von herstellerübergreifenden,<br />
"<strong>of</strong>fenen" Programmschnittstellen, die St<strong>and</strong>ardisierung von GIS-<br />
Techniken sowie die Förderung der GIS-Technologie. Die angestrebten de facto Normen<br />
sollen erreichen, dass die Dienste von Anbietern einem grossen Kreis von Nutzern auf<br />
einfache Weise zugänglich gemacht werden können. Angestrebt werden ein breiter Einsatz<br />
interoperabler S<strong>of</strong>tware-Komponenten von der Stange (Components <strong>of</strong> the shelf),<br />
die vollständige Integration der Geodatenverarbeitung mit der normalen Informationstechnologie<br />
und der Schritt von Geodaten zu Geoinformationsdiensten. Die OGC-<br />
Spezifikationen sind meist pragmatische Ansätze, welche die Funktionstüchtigkeit als<br />
Hauptziel haben.<br />
Beispiele für OGC Spezifikationen sind:<br />
� „OpenGIS Simple Feature Specification (SF, approved)“<br />
� „OpenGIS Geography Markup Language (GML, approved)“<br />
� „OpenGIS Web Map Server Specification (WMS, approved)“<br />
� „OpenGIS Web Feature Server Specification (WFS, approved)“<br />
� Service Discovery<br />
� Service Description<br />
W3C<br />
Das World Wide Web Consortium wurde gegründet, um alle Möglichkeiten des Webs<br />
zu erschließen. Dazu werden einheitliche Technologien (Spezifikationen, Richtlinien,<br />
S<strong>of</strong>tware und Tools) entwickelt, die den Fortschritt des Webs fördern und seine <strong>Interoperabilität</strong><br />
sicherstellen.<br />
Hauptprodukte des W3C sind neue Empfehlungen, die als de facto St<strong>and</strong>ards für Protokolle<br />
und Anwendungen von den Mitgliedern begutachtet und gebilligt werden müssen.<br />
Ziel dabei ist es, einen möglichst breiten Konsens zu finden, was dadurch erreicht<br />
wird, dass jede Spezifikation ein bestimmtes Verfahren zu durchlaufen hat (sog. Recommendation<br />
Process).<br />
Ziel des W3C ist es, das WWW zu seiner vollen Entfaltung zu führen: Als ein funktionierendes<br />
Computer zu Computer System, als ein wirkungsvolles Mensch zu Computer<br />
Interface und als ein effizientes Mensch zu Mensch Kommunikationsmedium. Um die-<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 2.3
Nationale und internationale St<strong>and</strong>ards<br />
Überblick<br />
ses Ziel zu erreichen, arbeitet das W3C-Expertenteam zusammen mit seinen Mitgliedern<br />
in den folgenden fünf Bereichen:<br />
� Architecture Domain (DOM, Jigsaw, XML, XML Protocol, URI)<br />
� Document Formats Domain (HTML, Style Sheets, Math, Grafik, Internationalisierung,<br />
Amaya)<br />
� Interaction Domain (Device Independence, synchronisierte Multimediaanwendungen,<br />
Voice Browser)<br />
� Technology <strong>and</strong> Society Domain (Digitale Signaturen, Metadaten, elektronisches<br />
Geld, Datenschutz und Datensicherheit)<br />
� Web Accessibility Initiative<br />
2 <strong>Interoperabilität</strong><br />
Durch normierte Schnittstellen und Formate wird die systemunabhängige Kommunikation<br />
zwischen verschiedenen Informationssystemen ermöglicht, was als <strong>Interoperabilität</strong><br />
bezeichnet wird. <strong>Interoperabilität</strong> erlaubt den einfachen Zugang zu verschiedenen (auch<br />
raumbezogenen) Daten- und Verarbeitungsressourcen innerhalb eines Arbeitsablaufs<br />
bzw. die einfache Verknüpfung unterschiedlicher Systeme. Durch dieses einfache Zusammenspiel<br />
von Systemen und Daten wird es möglich, viele verschiedene Daten an<br />
einem Ort zu nutzen und diese Information gegebenenfalls auch zu veröffentlichen.<br />
Durch Spezifikationen und Normen entsteht <strong>Interoperabilität</strong>. <strong>Interoperabilität</strong> ist die<br />
Grundlage von IT-Infrastrukturen, d.h. von verteilten Systemen für eine Gesamt-<br />
Unternehmungslösung.<br />
<strong>Interoperabilität</strong> findet auf verschiedenen Ebenen statt.<br />
Schicht Charakteristik Begriffe<br />
Unterstützung von thin clients<br />
Präsentation<br />
J2ME<br />
und fat clients<br />
Services<br />
Applikationslogik<br />
Daten, Formate<br />
Interoperation und Offenheit:<br />
Einsatz von Internet-, IT- und<br />
GIS- St<strong>and</strong>ards<br />
Integration und IT-Konformität<br />
(API)<br />
Austausch und Investitionsschutz<br />
Plattform Plattformunabhängigkeit<br />
3 Marktbetrachtung<br />
HTTP, XML, SOAP, J2EE, UDDI;<br />
OGC: WMS, WFS<br />
.net, COM, Java SOAP, GML/XML,<br />
C++, VB<br />
DXF, DGN, SHP, OGC SF, INTER-<br />
LIS, GML, DBMS OS, PNG, JPG<br />
Unix (SUN, IBM, HP), DOS, Windows,<br />
Mac, Linux; DBMS (Oracle,<br />
SQL, DB2, Informix); WebServer<br />
(IIS, Websphere, Apache)<br />
Generell erleichtern Normen das Leben in einer vernetzen Welt. In den wenigsten Fällen<br />
werden Daten nur für einen kurzfristigen Moment erfasst und nur in einem System<br />
gehalten. Die Schaffung von Normen ist eine bedeutende Aufgabe. Wer befasst sich mit<br />
Normung?<br />
Ein Marktangebot soll sich an der Nachfrage orientieren. Denn nur diejenigen Normen<br />
werden sich durchsetzen, welche einen klaren Nutzen für den Anwender haben. Wem<br />
bringt Normung etwas?<br />
2.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nationale und internationale St<strong>and</strong>ards<br />
Überblick<br />
Die Antworten auf diese beiden Fragen sind nicht abschliessend:<br />
Verschiedene Organisationen bzw. Gremien befassen sich mit Normung. Die einschlägigen<br />
Normierungsorganisationen wie ISO, CEN und SNV aber auch OGC wurden bereits<br />
erwähnt. Neben den technischen Kommissionen (z.B. TC211 oder TK151) befassen<br />
sich auch weitere Gremien und Verbände (z.B. eCH, sia) mit Normung. Gerade Verbände<br />
sind gefordert, entstehende Normen für ihre Mitglieder auf ihre Praxistauglichkeit<br />
zu prüfen.<br />
EUROGI (European Umbrella Organisation for Geographic Information) will den<br />
Gebrauch von geographischen Informationen zugunsten der Bürger, der Regierungen<br />
und des H<strong>and</strong>els in Europa maximieren und die Sichtweise der Geographischen-<br />
Informationen-Gemeinschaft darstellen. Dies wird erreicht durch Förderung, Anregung<br />
und Unterstützung der Entwicklung und des Gebrauchs geographischer Informationen<br />
und Technologien.<br />
Das Schweizer Kontaktnetz e-geo.ch wurde initiiert, um den Aufbau einer NGDI zu<br />
fördern wie auch die Partnerschaften zwischen der öffentlichen H<strong>and</strong>, Organisationen<br />
und der Privatwirtschaft zu verbessern. Beide Initiativen benötigt für die Umsetzung<br />
die <strong>Interoperabilität</strong>. Für das Erreichen der Ziele sind praktikable und sinnvolle Normen<br />
von Vorteil.<br />
Hersteller sind angehalten, die vom Markt geforderten Normen zu implementieren.<br />
Davon pr<strong>of</strong>itiert der Kunde wie der Hersteller, weil weitere Aufgaben bewältigt und<br />
neue Marktsegmente erschlossen werden können.<br />
Datenproduzenten wollen ihre Daten einem möglichst grossen Publikum zugänglich<br />
machen. Die Bereitstellung in einem genormten Datenformat verringert den Aufw<strong>and</strong><br />
erheblich. Die Daten müssen nicht in verschiedenen proprietären Formaten von GIS-<br />
Systemlieferanten aufbereitet werden. Verschiedene Studien belegen, dass gut zugängliche<br />
Geobasisdaten für Privatwirtschaft wie für Verwaltung hohen volkswirtschaftlichen<br />
Nutzen haben (vgl. NGDI des Bundes).<br />
Der Anwender wird sich nicht im Detail damit befassen. Er wird sich informieren, damit<br />
er als Auftraggeber notwendige St<strong>and</strong>ards fordern bzw. als Auftragnehmer geforderte<br />
St<strong>and</strong>ards umsetzen kann. Schliesslich sollen Investitionen nachhaltig sein.<br />
Die Schaffung und Durchsetzung von Normen ist eine bedeutende Aufgabe. Normen<br />
erleichtern die Vernetzung und bauen technologische Hindernisse zur Zusammenarbeit<br />
ab. Die SOGI FG GIS-Technologie hat den Nutzen der Ergebnisse der Arbeit von OGC,<br />
ISO und SN für den GIS-Anwender in der Schweiz untersucht:<br />
Beschreibung OGC ISO SN<br />
Produktivitätssteigerung von Unternehmen und Behörden durch die<br />
X - e<br />
Nutzung genormter Programmschnittstellen.<br />
Produktivitätssteigerung von Unternehmen und Behörden durch die<br />
e e X<br />
Nutzung genormter Austauschformate und Mechanismen.<br />
Nutzen durch S<strong>of</strong>tware spezifischer Technologien ab der Stange. X - X<br />
Investitionsschutz (durch Plattformunabhängigkeit). ? e X<br />
CH ist nicht mehr eine Normeninsel. X X X<br />
Bessere Kontrolle der Daten. - e X<br />
Klar definierte Richtlinien für Ausschreibungen durch die zwingende<br />
Vorgabe des abzugebenden Datenformates, und damit Chancengleich- - - X<br />
heit für alle Anbieter.<br />
Im Bereich länderübergreifender Projekte, kommen proprietäre nationae<br />
e e<br />
le Normen (d.h. ohne Bezug zu internationalen Normen) nicht zum Ein-<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 2.5
Nationale und internationale St<strong>and</strong>ards<br />
Überblick<br />
satz. Dort ebnen internationale Normen den Weg für einen geregelten<br />
Datenbezug bzw. Datenaustausch.<br />
Normung wird auf einer systemneutralen Daten- und Modellierungsebene<br />
geführt.<br />
? X X<br />
Alle Beteiligten sprechen die gleiche „Sprache“. - ? X<br />
Legende: X Nutzen realisiert, e Nutzen zu erwarten/versprochen, ? Nutzen unklar, - kein<br />
Nutzen<br />
In einem Bericht der swisstopo wurde versucht, die konkreten Einsparungen beim sinnvollen<br />
Einsatz von Schweizer Normen zu schätzen (Bericht 17, www.swisstopo.ch). Es<br />
wird dort von einem Potential von einigen Millionen Schweizer Franken pro Jahr gerechnet.<br />
Ein <strong>and</strong>erer Bericht spricht von 3% Einsparung durch genormte Arbeitsabläufe<br />
und Werkzeuge (www.cgey.com/gcicase); dieser Prozentsatz dürfte im GIS-Bereich<br />
noch wesentlich höher liegen. Ebenso wichtig wie die Einsparungen ist jedoch der Zusatznutzen,<br />
der durch genormte Geoinformationsverarbeitung erzielt wird.<br />
Im Gegensatz zu üblichen Märkten ist Wettbewerb weniger gefragt. Organisationen sollen<br />
in jenen Bereichen, in denen sie sich thematisch überschneiden, zusammenarbeiten<br />
und ihre Normen angleichen. Dies passiert bereits. OGC-St<strong>and</strong>ards wie WFS oder WMS<br />
werden von ISO als Norm übernommen oder in entsprechenden Normen angepasst.<br />
Dasselbe geschieht auch umgekehrt, indem z.B. OGC ISO-Normen als St<strong>and</strong>ards übernimmt.<br />
Auch <strong>and</strong>ere Organisationen wie FGDC arbeiten enger mit ISO und OGC zusammen.<br />
Dies bringt den Organisationen weniger Arbeit und mehr Durchsetzungskraft.<br />
Für Entwickler, Hersteller und Anwender wird es einfacher.<br />
4 Literaturangaben<br />
� SOGI FG GIS-Technologie (2003): Worin liegt der praktische Nutzen von <strong>Interoperabilität</strong><br />
und Normung für den GIS-Anwender in der Schweiz?<br />
� SOGI FG GIS-Technologie (2005): Geo-Webdienst<br />
URL<br />
CEN, European Committee for St<strong>and</strong>ardisation (www.cenorm.be)<br />
INTERLIS (www.interlis.ch)<br />
ISO (www.iso.org)<br />
ISO TC/211 (www.isotc211.org)<br />
KOGIS (www.kogis.ch, www.e-geo.ch)<br />
OGC (www.opengis.org)<br />
Online Glossar (www.integis.ch)<br />
Schweizerischen Normen Vereinigung SNV (www.snv.ch)<br />
SOGI (www.sogi.ch)<br />
TC211 – OGC coordination group (www.opengis.org/iso)<br />
2.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Christine Giger, Pr<strong>of</strong>. Dr.<br />
Eidg. Technische Hochschule Zürich<br />
Institut für Geodäsie und Photogrammetrie<br />
ETH Hönggerberg<br />
CH-8093 Zürich<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 1 633 30 51<br />
+41 1 633 11 01<br />
3<br />
Informatik-St<strong>and</strong>ards<br />
Für die <strong>Interoperabilität</strong> von GIS relevante<br />
St<strong>and</strong>ards<br />
Christine Giger, ETH Zürich
1 Einleitung<br />
Die Entwicklung vernetzter, interoperabler Systeme betrifft aus Sicht der<br />
Informationstechnologien vier Aufgaben:<br />
1. Festlegung der Architekturen und technischen St<strong>and</strong>ards<br />
2. Prozessmodellierung<br />
3. Datenmodellierung<br />
4. Entwicklung von Basiskomponenten<br />
Alle vier Aufgaben sind im hohen Masse vonein<strong>and</strong>er abhängig und müssen<br />
aufein<strong>and</strong>er abgestimmt werden. In <strong>and</strong>eren Beiträgen dieser Tagung werden die<br />
verschiedenen Schritte unter verschiedenen Aspekten beleuchtet. Hier soll vor allem auf<br />
die erste Aufgabe eingegangen werden und dargestellt, welche allgemeinen,<br />
informationstechnischen St<strong>and</strong>ards existieren, die als Grundlage für die in <strong>and</strong>eren<br />
Beiträgen beh<strong>and</strong>elten Geoinformations- und Geomatik-St<strong>and</strong>ards dienen. Dabei wird<br />
mit dem Begriff „St<strong>and</strong>ard“ im folgenden Text sowohl ein de facto-St<strong>and</strong>ard (z.B.<br />
Hersteller- oder Domänen-spezifische aber weit verbreitete Schnittstellen) als auch ein<br />
de jure-St<strong>and</strong>ard (entspricht einer von einem <strong>of</strong>fiziellen Gremium definierten Norm)<br />
bezeichnet.<br />
Die Anzahl und Breite der informationstechnischen St<strong>and</strong>ards ist sehr gross und kann<br />
im Rahmen dieses Beitrags nicht umfassend und vollständig beschrieben werden. Um<br />
eine sinnvolle Eingrenzung des Themas vornehmen zu können, gehen wir zunächst von<br />
einer in Fachkreisen allgemein anerkannten Architektur für Geodateninfrastrukturen<br />
aus.<br />
Bild 1: Middleware-Architektur für Geodateninfrastrukturen gemäss INSPIRE [1]<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 3.1
Nationale und internationale St<strong>and</strong>ards<br />
Informatik-St<strong>and</strong>ards: für die <strong>Interoperabilität</strong> von GIS relevante St<strong>and</strong>ards<br />
Die in Bild 1 gezeigte 3-Schichten Architektur wurde so vom Expertengremium der EU-<br />
Initiative INSPIRE (Infrastructure for Spatial Information in Europe) [1] verabschiedet<br />
und basiert unter <strong>and</strong>erem auf den für den Geoinformationsbereich so bedeutsamen<br />
Gremien:<br />
� ISO/TC 211 – Geoinformation - Geomatics [5]<br />
� Open Geospatial Consortium (OGC) [8]<br />
Auf der untersten Ebene befinden sich Daten- und Metadatenquellen. Dort ist darauf zu<br />
achten, dass Daten und Metadaten maschinell gelesen, interpretiert und verarbeitet<br />
werden können. Schnittstellen zu Clients aber vor allem zu zugreifenden Diensten<br />
(darunter die wichtigen Katalog- und Suchdienste) müssen exakt spezifiziert und<br />
eingehalten werden. Nur so sind die vorh<strong>and</strong>enen Geodaten breit nutzbar.<br />
In der mittleren Schicht müssen Basis- und Mehrwertdienste angeboten werden. Diese<br />
müssen unabhängig von bestimmten Datenquellen funktionieren und austauschbar<br />
sowie mitein<strong>and</strong>er koppelbar sein. D.h. es müssen letztlich Schnittstellen zu<br />
Datenquellen wie auch zu Clients und <strong>and</strong>eren Diensten (Middleware-Komponenten)<br />
spezifiziert und eingehalten werden.<br />
In der obersten Schicht befinden sich die Endnutzer-Anwendungen, zu denen auch<br />
Portale zählen. Weitere Beispiele sind einfache Web-Browser, spezialisierte Dienste (z.B.<br />
Routenplanung, Immobilienbewertung) aber auch traditionelle GIS. Hier sind ebenfalls<br />
vor allem die Schnittstellen zu den Diensten und Datenquellen aber auch zu<br />
Suchdiensten relevant.<br />
Fasst man nun die S<strong>of</strong>tware-Architektur in Bild 1 als zu erreichendes Ziel auf, bleibt zu<br />
überlegen, wie die einzelnen dort aufgeführten Komponenten über st<strong>and</strong>ardisierte<br />
Schnittstellen mitein<strong>and</strong>er kommunizieren können. Idealerweise sollten zu diesem<br />
Zweck St<strong>and</strong>ards gewählt werden, die<br />
� leicht implementierbar sind,<br />
� die Freiheit bei der Implementierung der Komponenten möglichst nicht oder nur<br />
schwach einschränken<br />
� die Kommunikation zwischen den Komponenten sicherstellen,<br />
� den Ersatz einzelner Komponenten durch <strong>and</strong>ere/neue ermöglichen,<br />
� die Erweiterbarkeit des Gesamtsystems ermöglichen,<br />
� kompatibel zu allgemeinen IT-St<strong>and</strong>ards sind.<br />
Im Bild 2 sind die korrespondierenden St<strong>and</strong>ards der Reihe ISO 19100 des ISO/TC 211<br />
und die St<strong>and</strong>ards des OGC an den entsprechenden Schnittstellen oder für die<br />
entsprechenden Komponenten dargestellt.<br />
3.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nationale und internationale St<strong>and</strong>ards<br />
Informatik-St<strong>and</strong>ards: für die <strong>Interoperabilität</strong> von GIS relevante St<strong>and</strong>ards<br />
Bild 2: Middleware-Architektur mit ISO/TC 211 und OGC St<strong>and</strong>ards<br />
Auf die Beschreibung der St<strong>and</strong>ards, die in diesen beiden Gremien entwickelt werden,<br />
wird in diesem Beitrag explizit verzichtet, da <strong>and</strong>ere Beiträge sich diesen Themen<br />
widmen.<br />
Aus Sicht der Informatik sollte man die folgenden Normungsgremien betrachten, die<br />
auch einen Grossteil der Basis für ISO/TC 211 und OGC liefern:<br />
� Object Management Group (OMG) [6]<br />
� World Wide Web Consortium (W3C) [10]<br />
� International Organization for St<strong>and</strong>ardization (ISO) [4]<br />
� International Electrotechnical Commision (IEC) [3]<br />
Es existieren natürlich noch weitere Gremien, deren Beschreibung jedoch den Rahmen<br />
dieses Beitrags sprengen würde. Aus Platz-und Zeitgründen aber auch aus Gründen der<br />
unmittelbaren Relevanz beh<strong>and</strong>eltdieser Beitrag vor allem die GIS-relevanten St<strong>and</strong>ards<br />
von OMG und W3C<br />
Um diese in ihrer Funktion und in Relation zu <strong>and</strong>eren St<strong>and</strong>ards einordnen zu können,<br />
illustriert das folgende Bild 3 die Aufgaben der einzelnen St<strong>and</strong>ards im Zusammenhang<br />
mit den funktionalen Anforderungen der <strong>Interoperabilität</strong>.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 3.3
Nationale und internationale St<strong>and</strong>ards<br />
Informatik-St<strong>and</strong>ards: für die <strong>Interoperabilität</strong> von GIS relevante St<strong>and</strong>ards<br />
Bild 3: St<strong>and</strong>ards und ihre Aufgaben für die Realisierung von interoperablen Systemen<br />
Die Nennung der in der Spalte „<strong>Interoperabilität</strong>s-St<strong>and</strong>ards“ angegebenen St<strong>and</strong>ards<br />
erhebt keinerlei Anspruch auf Vollständigkeit. Im Rahmen dieses Beitrags wird auch<br />
nur auf einen geringen Teil der dort genannten St<strong>and</strong>ards eingegangen.<br />
2 Object Management Group (OMG)<br />
Die Object Management Group (OMG) wurde 1989 von 11 Firmen gegründet, darunter<br />
3Com, American Airlines, Canon, Data General, HP, Philips, SUN und Unisys. Das<br />
Industrie-Konsortium zählt heute mehr als 800 Mitglieder. Es st<strong>and</strong>ardisiert <strong>of</strong>fene,<br />
verteilte, objekt-orientierte Systeme auf Middleware-Basis.<br />
Unter den zahlreichen von der OMG entwickelten St<strong>and</strong>ards haben die folgenden die<br />
grösste Bedeutung für interoperable GIS:<br />
� Common Object Request Broker Architecture (CORBA)<br />
� Model Driven Architecture (MDA)<br />
� Unified Modeling Language (UML)<br />
Die St<strong>and</strong>ards werden in den folgenden Kapiteln etwas näher erklärt.<br />
2.1 Common Object Request Broker Architecture (CORBA)<br />
CORBA basiert auf dem ISO/IEC 10746 St<strong>and</strong>ard for Open Distributed Processing, einer<br />
allgemeinen Architektur <strong>of</strong>fener, verteilter komponentenbasierter Systeme. Das OGC<br />
beruft sich mit seinen Entwicklungen ebenfalls auf dieses ISO/IEC St<strong>and</strong>ard und auf die<br />
Entwicklungen der OMG. Eine 1. Version von CORBA wurde 1991 veröffentlicht. Seit<br />
2000 ist CORBA ebenfalls als St<strong>and</strong>ard der ISO (ISO/IEC 19500-2) erhältlich. CORBA<br />
definiert die Komponenten und Rollen der Komponenten von Middleware-<br />
Architekturen.<br />
3.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nationale und internationale St<strong>and</strong>ards<br />
Informatik-St<strong>and</strong>ards: für die <strong>Interoperabilität</strong> von GIS relevante St<strong>and</strong>ards<br />
2.2 Model Driven Architecture (MDA)<br />
Die MDA vereinheitlicht als modellbasierte S<strong>of</strong>tware-Architektur die Modellierungsund<br />
Middleware-Bereiche der OMG. Sie unterstützt Anwendungen über ihren<br />
gesamten Lebenszyklus von Analyse und Entwurf über Implementierung und<br />
Entwicklung bis hin zur Pflege und der Erweiterung von S<strong>of</strong>twaresystemen. Die MDA<br />
basiert auf UML Modellen. Die Beschreibungssprache UML wird im nächsten Kapitel<br />
noch etwas näher beschrieben.<br />
Das folgende Bild 4 illustriert die Funktion der MDA aus Sicht der OMG.<br />
Bild 4: Funktionen der Model Driven Architecture<br />
Die MDA integriert Anwendungen innerhalb eines Unternehmens und über das<br />
Unternehmen hinaus mit Anwendungen <strong>and</strong>erer Unternehmen. Sie wurde von den<br />
OMG-Mitgliedern als Basis für alle OMG-Spezifikationen im September 2001<br />
verabschiedet. Weitere Infos finden sich unter [7].<br />
2.3 Unified Modeling Language (UML)<br />
UML st<strong>and</strong>ardisiert die Repräsentation von objekt-orientierter Analyse und Entwurf. Es<br />
h<strong>and</strong>elt sich bei UML um eine graphische Sprache mit einem Dutzend Diagrammtypen<br />
(Anwendungs- und Aktivitätsdiagramme zur Anforderungserfassung, Klassen- und<br />
Objektdiagramme für den Systementwurf, Paket und Subsystemdiagramme für die<br />
Entwicklung, usw.). S<strong>of</strong>tware-Architekten und -Analysten können Anwendungen<br />
st<strong>and</strong>ardisiert visualisieren, spezifizieren, konstruieren und dokumentieren. Die OMG<br />
entwickelte UML also vor allem zum Entwurf von komplexen, verteilten<br />
S<strong>of</strong>twaresystemen.<br />
Im GIS-Bereich wird zur Zeit allerdings nur ein sehr kleiner Aspekt von UML genutzt:<br />
die Möglichkeit, mit UML Datenmodelle zu beschreiben. UML ist allerdings sehr<br />
verbreitet für die Nutzung und wird beispielsweise auch für die Spezifikation der ISO<br />
19100 [5] Normenreihe intensiv gebraucht.<br />
Weitere Informationen zu UML, Beispiele sowie UML-Kurse finden sich unter [9].<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 3.5
Nationale und internationale St<strong>and</strong>ards<br />
Informatik-St<strong>and</strong>ards: für die <strong>Interoperabilität</strong> von GIS relevante St<strong>and</strong>ards<br />
3 World Wide Web Consortium (W3C)<br />
Das World Wide Web wurde 1989 von Tim Berners-Lee während seiner Tätigkeit am<br />
CERN in Genf erfunden. Berners-Lee und <strong>and</strong>ere gründeten im Oktober 1994 das World<br />
Wide Web Consortium (W3C) als Industriekonsortium. Berners-Lee ist seit dem<br />
Direktor des W3C.<br />
Viele Informationen inklusive einer vollständigen Liste aller St<strong>and</strong>ards finden sich unter<br />
[10]. Kurse zu den meisten St<strong>and</strong>ards finden sich unter [11].<br />
Ziel des W3C ist es, Industrie-weiten Konsens über Web-Technologien herbei zu führen.<br />
Das W3C hat die Aufgabe, das Wide World Web zur Nutzung seiner vollen Kapazität<br />
zu führen, indem die gemeinsamen Protokolle entwickelt werden, die seine<br />
Weiterentwicklung fördern und seine <strong>Interoperabilität</strong> gewährleisten.<br />
Eine der Aufgaben des W3C ist es, einen Beitrag zur St<strong>and</strong>ardisierung der Web-<br />
Technologien zu leisten, indem “Recommendations” genannte Spezifikationen, welche die<br />
Grundlagen des Web beschreiben, produziert werden. Die Ziele des W3C können in den<br />
sieben folgenden Punkten zusammengefasst werden: Universal Access, Semantic Web,<br />
Trust, Interoperability, Evolvability, Decentralization und Cooler Multimedia.<br />
Um diese Ziele zu erreichen, wurden verschiedene Arbeitsgruppen gegründet, welche<br />
in fünf Bereiche aufgeteilt werden können:<br />
Architecture Domain: Sie entwickelt die Web-Technologien. Innerhalb dieser Domäne<br />
befinden sich Arbeitsgruppen zum Thema XML (XML Core Working Group, XML<br />
Linking Working Group, XML Query Working Group und XML Schema Working<br />
Group), WebServices (XML Protocol Working Group und WebServices Descriptor<br />
Working Group), Uniform Resource Identifiers, DOM und Jigsaw.<br />
Document Formats Domain: arbeitet an den Formaten und Sprachen für die<br />
Informationsdarstellung. Zum Beispiel an der Hypertext Markup Language (HTML),<br />
Style Sheets, Math, Graphics (z.B. Formate PNG, SVG, usw.),<br />
Interaction Domain: beschäftigt sich mit der Unterstützung des Benutzers in der<br />
Interaktion mit dem Web. Die Aktivitätsbereiche sind: Device Independence,<br />
Multimodal Interaction, Synchronized Multimedia (SMIL) und Voice Browser.<br />
Technology <strong>and</strong> Society Domain: berücksichtigt gesetzliche und sozialpolitische<br />
Aspekte in der Web-Entwicklung. Die Aktivitätsbereiche sind: Semantic Web (z. B.<br />
Resource Description Framework, RDF oder Web Ontology Language, OWL), Platform<br />
for Privacy Preferences (P3P), XML Signature (xmldsig), XML Encryption, XML Key<br />
Management, Patent Policy <strong>and</strong> St<strong>and</strong>ards.<br />
Web Accessibility Initiative (WAI): führt die Arbeiten zur Förderung des Web-Zugriffs<br />
anh<strong>and</strong> von fünf Arbeitsbereichen fort: technology, guidelines, tools, education <strong>and</strong><br />
outreach, und research <strong>and</strong> development.<br />
Das folgende Bild 5 illustriert die Funktionen der W3C St<strong>and</strong>ards im Hinblick auf die<br />
Funktionen und die Weiterentwicklung des World Wide Web.<br />
3.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nationale und internationale St<strong>and</strong>ards<br />
Informatik-St<strong>and</strong>ards: für die <strong>Interoperabilität</strong> von GIS relevante St<strong>and</strong>ards<br />
Bild 5: W3C-St<strong>and</strong>ards und die Weiterentwicklung des World Wide Web [10]<br />
Für die GI-Normung sind dabei vor allem die folgenden St<strong>and</strong>ards wichtig:<br />
� Uniform Resource Locators (URL), Uniform Resource Identifiers (URI),<br />
HyperText Transfer Protocol (HTTP), HyperText Markup Language (HTML)<br />
o Diese sind dem Leser (h<strong>of</strong>fentlich) bekannt und werden im folgenden<br />
nicht mehr näher erklärt<br />
� Extensible Markup Language (XML) und XML Schema<br />
� Scalable Vector Graphics (SVG)<br />
� Resource Description Framework (RDF)<br />
� Web Ontology Language (OWL)<br />
� Simple Object Access Protocol (SOAP)<br />
� Web Services Description Language (WSDL)<br />
3.1 Extensible Markup Language (XML)<br />
Bei XML h<strong>and</strong>elt es sich um ein Textformat, das als Derivat der<br />
Dokumentenbeschreibungssprache St<strong>and</strong>ard Generalized Markup Language SGML (ISO<br />
8879) entst<strong>and</strong>. XML nutzt zur Zeichenkodierung den ASCII-St<strong>and</strong>ard. Es ist beschreibt<br />
sequentiell die Struktur von Dokumenten (z.B. Titel, 1. Kapitel, Absatz, Absatz, 2.<br />
Kapitel, usw.). XML war ursprünglich nur für die breite elektronische Publikation von<br />
Dokumenten gedacht. Heute wird es zunehmend für den Austausch beliebiger Daten in<br />
der Informatik und eben auch zum Austausch von Geodaten verwendet.<br />
Beispiel:<br />
<br />
Tove<br />
Jani<br />
Reminder<br />
Don't forget me this weekend!<br />
<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 3.7
Nationale und internationale St<strong>and</strong>ards<br />
Informatik-St<strong>and</strong>ards: für die <strong>Interoperabilität</strong> von GIS relevante St<strong>and</strong>ards<br />
XML und XML-Derivate sind sehr gut für die Beschreibung von Daten geeignet, die<br />
automatisch von Rechnern weiterberabeitet werden sollen. Das Lesen von XML-Dateien<br />
durch Menschen ist natürlich möglich, aber extrem mühsam, da Menschen gewöhnlich<br />
eher objekt-orientiert als sequentiell denken, s<strong>of</strong>ern es sich bei den Daten nicht um<br />
Dokumente h<strong>and</strong>elt. XML und XML-Derivate zur Modellierung beliebiger Daten (nicht<br />
Dokumente) zu verwenden ist prinzipiell möglich aber ebenfalls unsinnig. UML zum<br />
Beispiel liegt viel näher an menschlichen Denkweisen.<br />
3.2 XML Schema<br />
XML Schema beschreibt so genannte shared vocabularies und bietet damit Methoden zur<br />
Definition der Strukturen, Inhalte und Semantik von XML-Dokumenten. XML Schema<br />
erlaubt die Definition von Klassen von XML-Dokumenten. Eine deutsche Beschreibung<br />
zu XML-Schema findet sich z.B. unter [1].<br />
XML Schema ist auch die Basis für den OGC St<strong>and</strong>ard GML [8].<br />
3.3 Scalable Vector Graphics (SVG)<br />
SVG beschreibt 2D Graphiken. Es besteht aus 2 Teilen: XML-basiertes Dateiformat und<br />
Programmierschnittstele für graphische Anwendungen. Es enthält z.B. verschiedene<br />
Formen, Text, und Rastergraphik. SVG unterstützt Scripts und Animationen. Es nutzt<br />
JPEG und PNG als Bildformate.<br />
SVG wird für interaktive Anwendungen im Web, auf mobilen Systemen, etc. benutzt. Es<br />
h<strong>and</strong>elt sich um einen systemunabhängigen, <strong>of</strong>fenen St<strong>and</strong>ard. Die Autoren kommen<br />
von: Adobe, Agfa, Apple, Canon, Corel, Ericsson, HP, IBM, Kodak, Macromedia,<br />
Micros<strong>of</strong>t, Nokia, Sharp und Sun Microsystems. SVG viewers gibt es für alle gängigen<br />
Web-Browser<br />
3.4 Resource Description Framework (RDF)<br />
RDF bietet einen Rahmen zur Beschreibung und zum Austausch von Metadaten, die<br />
Informationen im Internet betreffen, gemäss den folgenden Regeln:<br />
1. Eine Resource ist irgendetwas, dass einen URI haben kann; dies beinhaltet alle<br />
WWW-Seiten aber auch individuelle Teile eines XML-Dokuments.<br />
2. Ein PropertyType ist eine Resource, die einen Namen hat und als Property<br />
genutzt werden kann, z.B. Autor oder Titel. In vielen Fällen kümmern wir uns<br />
dabei nur um den Namen; aber ein PropertyType muss eine Resource sein,<br />
damit er eigenen Properties (Eigenschaften) haben kann.<br />
3. Eine Property ist die Kombination einer Resource, eines PropertyType und eines<br />
Werts.<br />
Beispiel:<br />
"The Author <strong>of</strong> http://www.textuality.com/RDF/Why.html is Tim Bray.“ Der<br />
Wert kann nur ein String sein, z.B. "Tim Bray" oder eine <strong>and</strong>ere Resource, z.B.<br />
"The Home-Page <strong>of</strong> http://www.textuality.com/RDF/Why.html is<br />
4.<br />
http://www.textuality.com“<br />
Diese Eigenschaften können direkt im XML beschrieben werden<br />
3.8 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nationale und internationale St<strong>and</strong>ards<br />
Informatik-St<strong>and</strong>ards: für die <strong>Interoperabilität</strong> von GIS relevante St<strong>and</strong>ards<br />
3.5 Web Ontology Language (OWL)<br />
OWL basiert auf RDF und bietet zusätzlich mehr Vokabular für die Beschreibung von<br />
Eigenschaften und Klassen an, z.B.:<br />
� unterein<strong>and</strong>er<br />
� Relationen zwischen Klassen<br />
� Kardinalitäten<br />
� Gleichheit<br />
� Charakteristika von Eigenschaften (z.B. Symmetrien)<br />
� Enumerationen<br />
RDF nutzt Description Logics zur Modellierung von Daten (z.B. Geoobjekten) und deren<br />
Eigenschaften.<br />
Bild 6 zeigt ein Beispiel für deskriptive Logik.<br />
Bild 6: Deskriptive Logik<br />
OWL ist (ähnlich wie zum Beispiel INTERLIS) auch eine konzeptionelle<br />
Beschreibungssprache.<br />
3.6 Simple Object Access Protocol (SOAP)<br />
Um Anwedungsprogramme auf einem Rechner zu koppeln, würde man typischerweise<br />
auf die Nutzung so genannter Remote Procedure Calls (RPC) zurückgreifen. Bei der<br />
Kopplung von Anwendungen, die jedoch auf verschiedenen Rechnern laufen, die durch<br />
das Internet verbunden sind, ist dies nicht möglich. Firewalls würden RPCs s<strong>of</strong>ort<br />
zurückweisen. Daher wurde SOAP entwickelt.<br />
SOAP ist ein Kommunikationsprotokoll, das die Kommunikation zwischen<br />
Applikationen, die auf verschiedenen Betriebssystemen mit verschiedenen<br />
Technologien und Programmiersprachen laufen, erlaubt. Es ist ein Format zum Senden<br />
von Nachrichten und wurde speziell für die Kommunikation via Internet entworfen. Es<br />
ist Plattform-unabhängig und basiert auf XML. Es ist einfach und erweiterbar und<br />
erlaubt die Umgehung von Firewalls.<br />
3.7 Web Services Description Language (WSDL)<br />
WSDL ist ein spezielles XML-Format zur Beschreibung von Netzwerkdiensten als<br />
Menge von Endpunkten, die auf Nachrichten operieren, die entweder Dokumentorientierte<br />
oder Prozedur-orientierte Informationen enthalten. Operationen und<br />
Nachrichten werden abstrakt beschrieben und dann an ein konkretes Netzprotokoll und<br />
Nachrichtenformat gebunden, um einen Endpunkt zu definieren. In Beziehung<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 3.9
Nationale und internationale St<strong>and</strong>ards<br />
Informatik-St<strong>and</strong>ards: für die <strong>Interoperabilität</strong> von GIS relevante St<strong>and</strong>ards<br />
stehende konkrete Endpunkte werden zu abstrakten Endpunkten (Diensten)<br />
kombiniert.<br />
WSDL ist unabhängig von Nachrichtenformaten und Protokollen. Üblich sind aber zur<br />
Zeit die Verwendung von SOAP 1.1, HTTP GET/POST, und MIME (Multipurpose<br />
Internet Mail Extensions) für WSDL.<br />
Insbesondere für Geodateninfrastrukturen, in denen man gerne Dienste suchen und<br />
finden und dann auch mitein<strong>and</strong>er verketten möchte, gewinnt WSDL eine zunehmende<br />
Bedeutung.<br />
4 Abschlussbemerkungen<br />
Die vorgestellte Liste der Informatik-St<strong>and</strong>ards ist keineswegs vollständig und skizziert<br />
auch nur gewisse Aspekte der St<strong>and</strong>ards und deren Bedeutung für die Nutzung von<br />
Geoinformationen. Alle St<strong>and</strong>ards sind in „Bewegung“, d.h. sie sind zum Teil noch<br />
nicht als St<strong>and</strong>ards verabschiedet und werden noch bearbeitet. GI-St<strong>and</strong>ards, die auf<br />
diesen Informatik-St<strong>and</strong>ards beruhen, sind allenfalls auch von diesem Aspekt der<br />
Instabilität betr<strong>of</strong>fen. Dies gilt insbesondere auch für den OGC-St<strong>and</strong>ard GML.<br />
Modellbasierte Ansätze beherrschen die Informatik-St<strong>and</strong>ards für verteilte interoperable<br />
Systeme. Die schlägt sich allerdings auch in den Ansätzen von ISO/TC 211, CEN/TC<br />
287, der EU-Initiative INSPIRE aber auch in der nationalen Normung einzelner Länder,<br />
darunter auch Deutschl<strong>and</strong> (AAA Modell) und die Schweiz (INTERLIS!) nieder.<br />
Das Semantic Web hat grosse Zukunft und wird stark vorangetrieben (z.B. mit RDF und<br />
OWL).<br />
Referenzen<br />
[1] http://www.edition-w3c.de/TR/2001/REC-xmlschema-0-20010502/<br />
[2] http://inspire.jrc.it/home.html<br />
[3] http://www.iec.org/<br />
[4] http://www.iso.org/<br />
[5] http://www.isotc211.org/<br />
[6] http://www.omg.org/<br />
[7] http://www.omg.org/mda/<br />
[8] http://www.opengeospatial.org/<br />
[9] http://www.uml.org/<br />
[10] http://www.w3.org/<br />
[11] http://www.w3schools.com/<br />
3.10 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Hans Rudolf Gnägi<br />
Eidg. Technische Hochschule Zürich<br />
Institut für Geodäsie und Photogrammetrie<br />
ETH Hönggerberg<br />
CH-8093 Zürich<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 1 633 30 60<br />
+41 1 633 11 01<br />
4<br />
Weltweite, europäische und<br />
schweizerische GeoNormen in<br />
Wechselwirkung<br />
Hans Rudolf Gnägi, ETH Zürich
1 Einleitung<br />
Wer an Normen denkt, dem fallen spontan Stichworte ein wie „Schraubengewinde“,<br />
„DIN A4“ und „Spurweite der Eisenbahn“. Dabei geht es um stabile Dinge des täglichen<br />
Lebens, die schon mehr oder weniger lang existieren und sich bewährt haben und<br />
wo es nur noch darum geht, einige Details einheitlich festzulegen, um einer noch uneingeschränkteren<br />
Verwendung dieser Dinge letzte Hindernisse aus dem Weg zu räumen.<br />
Ganz <strong>and</strong>ers ist die Situation im Geoinformationsbereich. Da ist sozusagen nichts stabil,<br />
Technisch jagen sich die inkompatiblen Versionen von Geoinformationssystemen und<br />
Geodiensten in einem atemraubenden Tempo, die Geodaten werden immer umfangreicher,<br />
waren schon immer und bleiben teuer in der Herstellung, die Vielfalt von Austauschformaten<br />
nimmt babylonische Ausmasse an.<br />
Und trotzdem sollten in dieser h<strong>of</strong>fnungslos dynamischen Situation mittels Normen<br />
stabile Pflöcke eingeschlagen werden. Schon immer war da der Bedarf, Geodaten auszutauschen<br />
über lokale, regionale und nationale Grenzen, auch über Systemgrenzen. Nationale,<br />
regionale und globale Geodateninfrastrukturen rufen heute nach vielseitiger<br />
Nutzung einmal erhobener Geodaten. Aber was und wie soll normiert werden? Wo sind<br />
die Schraubengewinde im Geobereich? Zur Dynamik der Technik gesellen sich zudem<br />
h<strong>and</strong>feste Interessenkonflikte. Während beispielsweise die Geodatennutzer an möglichst<br />
frei und vollständig austauschbaren sowie <strong>of</strong>fen beschriebenen Geodaten interessiert<br />
sind, möchte ein GIS-Hersteller tendenziell eher seine Kunden an sein System binden<br />
durch möglichst hohe Hürden, die Daten wohldokumentiert und vollständig in ein<br />
Mitbewerber-System transferieren zu können.<br />
Im Folgenden soll kurz gezeigt werden, ob und wie erfolgreich das weltweite (ISO/<br />
TC211), das europäische (CEN/TC287) und das nationale Normengremium (SNV/INB<br />
TK 151) den mehrdimensionalen Spagat zwischen Technikdynamik und Anforderungswidersprüchen<br />
meistern.<br />
2 Normen, was ist das? Qualitätskriterien, Entstehung,<br />
Beeinflussung<br />
DIN normt auch den Begriff „Normung” und zwar mit folgender Definition: Normung<br />
ist planmässige, durch die interessierten Kreise durchgeführte Vereinheitlichung von<br />
materiellen und immateriellen Gegenständen zum Nutzen der Allgemeinheit (DIN 820<br />
Teil 3). Eine „Norm” ist das Resultat solcher Normungstätigkeit.<br />
Das Interesse am „Nutzen für die Allgemeinheit“ von „Vereinheitlichungen“ im Geobereich<br />
meldete sich in der Schweiz, wie in den meisten Ländern, zunächst auf nationaler<br />
Ebene an. Bedeutung und Wert der umfangreichen Geodatensammlungen führten zu<br />
einer ersten Schweizer Norm „Sicherheit und Schutz von Geodaten“ (SN612010). Um<br />
den Datenaustausch zwischen amtlicher Vermessung einerseits und Architektur und<br />
Bau <strong>and</strong>ererseits zu entwirren wurde die Norm „Datenreferenzmodell DXF Geobau“<br />
(SN612020) erarbeitet. Die modellbasierte Methode, in Stürmen praktischer Anwendung<br />
gereift, wurde als Norm „INTERLIS Datenbeschreibungssprache und Transfermethode“<br />
(SN612030) fixiert Es folgten „INTERLIS 2“ (SN612031), „Gebäudeadressen“<br />
(SN612040), „Metadaten“ (SN612050), diese sind aber bereits beeinflusst von der weltweiten<br />
Geo-Normung, wo seit 1994 die wesentlichen Entwicklungen stattfinden.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 4.1
Nationale und internationale St<strong>and</strong>ards<br />
Weltweite, europäische und schweizerische Geonormen in Wechselwirkung<br />
Die Erfahrungen mit der Entwicklung von Schweizer Normen zeigten, dass eine Norm<br />
nur dann „zum Nutzen der Allgemeinheit“ dient, wenn sie den folgenden Qualitätskriterien<br />
genügt.<br />
E Exakte knappe Formulierung mit präzisen klar definierten Begriffen aber auch<br />
mit anschaulichen Erläuterungen.<br />
M Minimum, das nötig ist wurde festzulegen: „Vollständig“ ist eine Norm, wenn<br />
sie alles enthält, was nötig ist für ein Vereinheitlichung, nicht alles, was existiert.<br />
P Praxiserprobung war erfolgreich<br />
B Breit abgestützte Einflussnahme auf die Erarbeitung<br />
„Planmässig“ bedeutet im Geobereich, dass organisatorisch primär auf weltweiter Ebene<br />
normiert wird (ISO/TC211), diese Normen in Europa nach Prüfung von Bedarf und<br />
Eignung als Euronormen (EN) anerkannt werden (von CEN/TC287), und dass diese<br />
Euronormen von den Mitgliedländern schliesslich ins nationale Normenwerk übernommen<br />
werden müssen (in der Schweiz durch die Schweizerisch Normenvereinigung<br />
SNV). „Planmässig“ verläuft auch der Lebenszyklus einer Norm: Dieser startet damit,<br />
dass eine Mitgliednation oder ein Liaison-Mitglied die Idee für eine neue Norm als<br />
„New work item proposal“ (NWIP) formuliert. Wird dieses vom TC angenommen,<br />
beginnt ein Projektteam (PT) „Committee Drafts“ (CD) auszuarbeiten, die von den Mitgliedernationen<br />
beurteilt werden können. Änderungswünsche werden durch „Editing<br />
Committee Meetings“ (ECM) eingearbeitet. Ist ein CD stabil, dann kommt er zur Abstimmung<br />
als „Draft International St<strong>and</strong>ard“ (DIS) und schliesslich als „International<br />
St<strong>and</strong>ard“ (IS). Analog entstehen bei ISO „Technical Reports“ (TR): Vom NWIP über<br />
den „Provisional Draft Technical Report“ (PDTR) zum DTR und zum TR.<br />
Soweit das Prozedere zur Schaffung von sogenannten „de jure“ Normen über die <strong>of</strong>fiziellen<br />
Normengremien. Daneben haben sich im Geo-Bereich wie in der Informationstechnologie<br />
allgemein auch „de facto“ Normen durchgesetzt durch weitverbreiteten<br />
Gebrauch. Man denke etwa an das „Drawing eXchange File“ (DXF) zum Austausch von<br />
Vektorgrafik. Mit dem „Open Geospatial Consortium“ (OGC) hat sich ein Gremium<br />
konstituiert, mit dem Ziel, <strong>Interoperabilität</strong> von GIS zu realisieren, d.h. Funktionalität<br />
und Daten von GIS wechselseitig nutzbar zu machen, insbesondere, wenn nicht umfangreicher<br />
Datenaustausch gefordert ist. OGC umfasst als strategisch entscheidende<br />
„principle members“ vor allem die grossen GIS-Hersteller. Viele an GIS interessierte<br />
Administrationen, Universitäten und kleinere Firmen können zu bescheideneren Jahresbeiträgen<br />
und mit weniger Entscheidungsbefugnis ihre Ideen einbringen. Der grosse<br />
Vorteil der de facto Normen von OGC gegenüber den de jure Normen von ISO ist, dass<br />
meist erst auf Grund von Implementierungen für eine Idee der Normungsprozess gestartet<br />
wird, dass also das oben erwähnte Qualitätskriterium 3 der Praxiserprobung automatisch<br />
erfüllt ist. Entsprechend dem Ziel <strong>Interoperabilität</strong> liegt das Hauptinteresse<br />
der OGC-Normungsarbeit im Bereich Internet basierte Dienste.<br />
Einzigartig und ausserordentlich positiv für die Normung im Geo-Bereich ist, dass ein<br />
Zusammenarbeitsvertrag zust<strong>and</strong>e kam zwischen OGC und ISO/TC211. Er ist zwar ins<strong>of</strong>ern<br />
einseitig, als damit nur OGC Normenvorschläge in den ISO-Prozess einbringen<br />
kann und nicht auch umgekehrt ISO/TC 211 bei OGC die Implementierung und damit<br />
praktische Überprüfung von durch ISO entwickelten Normen beantragen kann. Aber<br />
schon, dass OGC-Realisierungen auch den ISO-Prozess durchlaufen und so mit breiten<br />
kritischen Stellungnahmen und Verbesserungsideen konfrontiert werden, die mittels<br />
4.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nationale und internationale St<strong>and</strong>ards<br />
Weltweite, europäische und schweizerische Geonormen in Wechselwirkung<br />
ECMs berücksichtigt werden, hat wesentliche Qualitätsverbesserungen zur Folge (Qualitätskriterium<br />
4!).<br />
Noch ein Blick auf die Normungsexperten von ISO/TC211: Deren Zusammensetzung<br />
ist nach wie vor von unglaublicher Heterogenität. Viele kennen GIS nur von ferne, theoretisch,<br />
viele sind fixiert auf das eine GIS, mit dem sie gelegentlich oder täglich arbeiten,<br />
Das Verständnis für die Bedeutung systemunabhängiger Lösungen und für die modellbasierte<br />
Methode ist zwar zunehmend aber immer noch sehr nahe bei Null.<br />
3 Geo-Normen, Übersicht<br />
Gesamtübersicht und St<strong>and</strong> der ISO Normenserie 19100 gibt Tabelle 1. Von den 47 insgesamt<br />
gestarteten Projektteams wurden 3 wieder gestrichen und die übrigen produzierten<br />
bis zum 16.2.2005 insgesamt 18 IS und TR, 11 DIS und DTR, 9 CD und PDTR<br />
und 6 NWIP sind noch nicht bis zum CD vorgedrungen.<br />
Die ganze Normenserie basiert auf der modellbasierten Methode. Das heisst, es wird<br />
grundsätzlich auf system-unabhängiger konzeptioneller Ebene normiert. Die konzeptionellen<br />
Schemata (Datenmodelle) der normierten Datenstrukturen bzw. Strukturelemente<br />
müssen für die Implementierung in GIS oder Datenbanken auf das logische<br />
Schema (Datenmodell) dieser Zielsysteme umgebaut werden, um von dort, meist automatisch,<br />
auf den physischen Level des Betriebssystems bzw. des Rechners übersetzt zu<br />
werden. Für den Datentransfer kann aus einem konzeptionellen Schema automatisch<br />
direkt die Beschreibung des Transferformats, also das physische oder Transferschema,<br />
hergeleitet werden.<br />
Als konzeptionelle Beschreibungssprache verwendet ISO19100 die Umified Modelling<br />
Language (UML). Als Transferformat wurde der XML-Dialekt GML gewählt, als physische<br />
Beschreibungssprache des Transferschemas zunächst XML-DTD und jetzt XML-<br />
Schema. Viele Leser aber auch Hersteller der Normen haben grosse Schwierigkeit, diese<br />
verschiedenen Beschreibungsstufen ausein<strong>and</strong>er zu halten. Es besteht ein wesentlicher<br />
Unterschied zwischen der Beschreibung der Datenstruktur auf konzeptioneller Ebene<br />
(bei ISO 19100 durch UML) und der Beschreibung des Transferformats (bei ISO 19100<br />
durch XML-Schema). Wer ein physisches Transferschema als konzeptionelles Datenmodell<br />
betrachtet und bezeichnet bereitet sich selber vor allem unnötige Schwierigkeiten<br />
und stiftet in der Geowelt unnötig Verwirrung.<br />
Die Normen der Serie ISO 19100 können gegliedert werden in die beiden Hauptbereiche<br />
Grundlagen und Anwendungen. Bei den Grundlagen zeichnen sich vier Teilbereiche ab:<br />
Basis – Integrierbarkeit/Transferierbarkeit – <strong>Interoperabilität</strong>. Bei den Anwendungen<br />
kann zur Zeit unterschieden werden zwischen Qualität/Metadaten – Pixelbilder/Gitterdaten<br />
– LBS – Adressen – Bewegte Objekte. Details zu den beiden Hauptbereichen<br />
sowie der Versuch eines Zust<strong>and</strong>svergleichs ISO-CEN-SNV für den Grundlagenbereich<br />
folgen im nächsten Abschnitt.<br />
Tabelle 1 enthält in der dritten Kolonne eine grobe Beurteilung aller Normen. Dabei fällt<br />
sehr unangenehm auf die grosse Zahl von Normen mit der Bemerkung „No“. Wegen<br />
der sehr beschränkten personellen und finanziellen Kapazität der Schweiz im Geo-<br />
Normenbereich konnten alle diese Dokumente überhaupt nicht bewertet werden<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 4.3
Nationale und internationale St<strong>and</strong>ards<br />
Weltweite, europäische und schweizerische Geonormen in Wechselwirkung<br />
Nr<br />
ISO<br />
Sta<br />
nd<br />
Beurteilung<br />
Titel Dokument Nr<br />
4.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten<br />
Seiten<br />
ISO<br />
CH Norm<br />
SN6120xx-y<br />
xx Nr.Teil<br />
y Kap,Annex<br />
6709 � ? Std, representation <strong>of</strong> lat., long., alti. for pt. loc. N1733 31-2.9.4 1<br />
19101 � �? GI – Reference Model N1197, ISO19101 48 31-1 13<br />
19101-2 � GI – Reference Model – Part 2: Imagery N1455,N1489<br />
19102 � GI – Overview<br />
19103 � �? TR GI – Conceptual Schema Language N1527 71 31-2 50<br />
19104 � ? GI – Terminology Spread sheets N1485, DIS 19104 19 31-L 22<br />
19105 � No GI – Conformance <strong>and</strong> Testing (2000) ISO 19105 26<br />
19106 � No Gi – Pr<strong>of</strong>iles N1483, (2004) ISO 19106 38<br />
19107 � ! � GI – Spatial Schema (siehe 19137) (2003) ISO 19107 184 31-2.8.11/12 10<br />
19108 � ? GI – Temporal Schema FDIS N1225, ISO 19108 55 31-H 4<br />
19109 � ? GI – Rules for Application Schema N1538, DIS 19109 83 Mod.Meth.G<br />
19110 � ? GI – Feature Cataloguing Methodology N1567 (2005) IS 60 Mod.Meth.G<br />
19111 � �! GI – Spatial Referencing by Coordinates (2003) IS 44 31-J 13<br />
19112 � ! GI – Spatial Referencing by Geo Identifiers (2003) IS 30 40<br />
19113 � No GI – Quality Principles (2002) ISO 19113 38<br />
19114 � No GI – Quality Evaluation Procedures (2003) ISO 19114 79<br />
19115 � �? GI – Metadata (2003) ISO 19115 150 50<br />
19115-2 | No GI – Metadata 2; Extensions for IGD N1396, N1425<br />
19116 � No GI – Positioning Services N1547 (2004) ISO 19116 59<br />
19117 � ? GI – Portrayal N1578 (2002) DIS 19117 47 31-2.16, -K 13<br />
19118 � ? GI – Encoding N1580 (2002) DIS 19118 117 31-3 15<br />
19119 � No GI – Services N1540 (2002) DIS 19119 74 Checker,...<br />
19120 � No TR GI – Functional st<strong>and</strong>ards (2001) ISO TR 19120<br />
19120 A � No TR GI – Functional st<strong>and</strong>ards amendmt 1<br />
19121 � No TR GI – Imagery <strong>and</strong> gridded data IGD (2000) ISO TR<br />
19122 � �? TR GI – Qualif. <strong>and</strong> certif. <strong>of</strong> pers N1491 (2004) ISO TR 12<br />
19123 � No GI – Schema for coverage geom. & funct N1740 FDIS 63<br />
19124 | No TR GI – Imagery <strong>and</strong> gridded data components N1017 39<br />
19125-1 � ! � GI – Simple feat. acc - P1 Comn arch N1563 (2004) IS 48 31-2.8.11/12 s.o.<br />
19125-2 � ! � GI – Simple feat. acc - P2 SQL option N1565 (2004) IS 72 31-2.8.11/12 s.o.<br />
19125-3 � ! � GI – Simple feature access – P3: COM/OLE opt. N997 124 31-2.8.11/12 s.o.<br />
19126 � No GI – Pr<strong>of</strong>ile – FACC data dictionary N1561<br />
19127 � �? TR GI – Geodetic codes <strong>and</strong> parameters N1751 FDTR 39 31-J s.o.<br />
19128 � No GI – Web map server interface N1675, DIS<br />
19129 | No TR GI – Imagery, gridded & coverage data frwk. N1252 107<br />
19130 � No GI – Sensor <strong>and</strong> data models for IGD N1772 76<br />
19131 � �? GI – Data product specification N1688 Mod.Meth.G<br />
19132 | No GI – Location based serv.- reference model N1599<br />
19133 � No GI – Location based serv tracking <strong>and</strong> navig. N1762,DIS<br />
19134 � No GI – Multimodal LBS for routing <strong>and</strong> navigation N1768<br />
19135 � No GI – Procedures for registration <strong>of</strong> GI-items N1605 DIS 20<br />
19136 � �? GI – GML N1576<br />
19137 � � GI – Core pr<strong>of</strong>ile <strong>of</strong> spatial schema N1670 DIS 19137<br />
19138 � � GI – Data quality measures N1744, PDTS<br />
19139 � ?,! GI – Metadata – XML schema implem. N1663, PDTS<br />
19140 | � GI – Technical amendment <strong>of</strong> ISO19100 series N1346<br />
19141 | No GI – Schema for moving features N1757<br />
Tab. 1 : St<strong>and</strong> der Geo-Normen-Serie 19100 von ISO/TC 211 (2005-02-16)<br />
Seiten<br />
CH
Nationale und internationale St<strong>and</strong>ards<br />
Weltweite, europäische und schweizerische Geonormen in Wechselwirkung<br />
Legende zu Tabelle 1: St<strong>and</strong> der Geo-Normen-Serie 19100 von ISO/TC 211 (2005-02-16)<br />
Legende St<strong>and</strong> der Normen Legende Beurteilung Sicht CH<br />
� = IS International St<strong>and</strong>ard (or TR Technical Report) � = zweckmässiges Konzept<br />
� = DIS Draft International St<strong>and</strong>ard (or DTR Draft Technical Report) ? = Unklarheiten, Probleme<br />
� = CD Committee Draft (or PDTR Provisional Draft Technical Report) ! = Widerspruch zu <strong>and</strong>eren Normen<br />
| = NWI New Work Item beschlossen �= Folgearbeiten notwendig<br />
� = aufgehoben No = keine Beurteilung Sicht CH<br />
Mod.Meth.G = Modellierungs Methode, INTERLIS Grundkurs<br />
4 Für Integrierbarkeit und <strong>Interoperabilität</strong> wesentliche<br />
Normen<br />
Für Integrierbarkeit und <strong>Interoperabilität</strong> wesentlich sind ohne Ausnahme alle Normen<br />
des Grundlagenbereichs. Tabelle 2 bringt eine vergleichende Übersicht dieser Grundlagennormen<br />
in thematischer Ordnung gemäss den oben beschriebenen Teilbereichen.<br />
Für die ISO/CEN-Normen einerseits und für die entsprechenden SNV-Normen <strong>and</strong>ererseits<br />
kommen die in Abschnitt 2 eingeführten Qualitätskriterien zur Anwendung.<br />
Nr ISO<br />
E<br />
Name ISO CEN<br />
E M P B Nr SNV Name CH Norm E M P B<br />
CEN<br />
N<br />
Basis .<br />
Conceptual schema lan-<br />
INTERLIS 2, Kapitel 2<br />
19103<br />
� s s u s 612031<br />
G s G G<br />
guage<br />
Beschreibungssprache<br />
INTERLIS 2, Anhang L<br />
19104 Terminology principles � G s G G 612031<br />
G G G G<br />
Glossar<br />
19107<br />
19123<br />
19125<br />
19137<br />
19111<br />
19127<br />
Spatial schema<br />
Schema for coverage..<br />
Simple features<br />
Minimal pr<strong>of</strong>ile spa sch<br />
Referencing by coord<br />
Geodetic codes <strong>and</strong> par<br />
�<br />
�<br />
�<br />
�<br />
�<br />
�<br />
s<br />
�<br />
s<br />
G<br />
s<br />
s<br />
u<br />
�<br />
G<br />
G<br />
s<br />
s<br />
u<br />
�<br />
G<br />
s<br />
s<br />
G<br />
u<br />
�<br />
612031<br />
s<br />
G<br />
G<br />
G 612031<br />
19108 Temporal schema � s u u s 612031<br />
19109<br />
19110<br />
Rules for applic schema<br />
Feature cataloguing met<br />
�<br />
�<br />
s<br />
s<br />
u<br />
u<br />
u<br />
s<br />
s<br />
G 612031<br />
19106 Pr<strong>of</strong>iles � � � � � 612031<br />
19119 Services � � � � � 612031<br />
INTERLIS 2, Abschnitt<br />
2.8.7 Koordinaten, 2.8.11<br />
Linienzüge,<br />
2.8.12 Flächen, Gebiete<br />
INTERLIS 2, Anhang J<br />
Koordinaten(ref)system<br />
INTERLIS 2 Anhang H<br />
Zeit-Definitionen<br />
INTERLIS 2, Kapitel 1,<br />
Grundprinzipien, UsHB<br />
INTERLIS 2, Abschnitt<br />
2.4 Vererbung<br />
INTERLIS 2, Abschnitt<br />
1.8 Dienste, Werkzeuge<br />
G G G G<br />
G G u G<br />
G s u G<br />
G G G G<br />
G G s G<br />
G u u G<br />
Integrierbarkeit/Transferierbarkeit .<br />
19118<br />
19136<br />
Encoding<br />
GML<br />
�<br />
�<br />
u<br />
s<br />
u<br />
u<br />
u<br />
s<br />
G<br />
G 612031<br />
INTERLIS 2, Kapitel 3<br />
sequentieller Transfer<br />
G G G G<br />
19117 Portrayal � u u u s 612031<br />
INTERLIS 2, Abschnitt<br />
2.16 Darstellungsbeschr<br />
s s s G<br />
<strong>Interoperabilität</strong> .<br />
19128 WMS � � � � � � � � � � �<br />
NWIP WFS � � � � � � � � � � �<br />
Tab. 2 : St<strong>and</strong> der Geo-Normen-Serie 19100 von ISO/TC 211 (2005-02-16)<br />
Legende: Kolonne EN: � = existiert als Euronorm, � = existiert noch nicht als Euronorm.<br />
Bewertungskolonnen E = Exakte knappe Formulierung. M = Minimum festgelegt,<br />
P = Praxiserprobung war erfolgreich, B = Breit abgestützte Erarbeitung.<br />
Bewertung: G = gut, s = genügend (sufficient), u = ungenügend, � = nicht bewertet<br />
Dass sich unter den Schweizer Normen bei INTERLIS 2 alle Themen der Basisnormen<br />
und der Normen zur Integrierbarkeit/Transferierbarkeit von ISO vorfinden beruht auf<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 4.5
Nationale und internationale St<strong>and</strong>ards<br />
Weltweite, europäische und schweizerische Geonormen in Wechselwirkung<br />
der Wechselwirkung, die zwischen diesen beiden Normengremien stattf<strong>and</strong>.<br />
INTERLIS 1 wurde auch auf Grund der Anforderungen von ISO/TC211 an die für die<br />
Normenserie ISO 19100 auszuwählende konzeptionelle Beschreibungssprache<br />
entsprechend weiterentwickelt zu INTERLIS 2. Hauptforderung des Projektteams 3 von<br />
ISO/TC211 war volle Objektorientierung. Auch war XML als Transferformat verlangt.<br />
Die Wahl von ISO/TC211 erfolgte dann für die grafische Sprache UML. Als textuelle<br />
CSL sind alle diejenigen zugelassen, deren Sprachelemente sich eindeutig auf die in ISO<br />
19103 festgelegten Sprachelemente von UML abbilden lassen. Das ist für INTERLIS 2<br />
der Fall.<br />
5 Nächste Schritte<br />
Die verschiedenen Lücken in Tabelle 2 zeigen deutlich den Verbesserungsbedarf vieler<br />
bereits verabschiedeter ISO-Normen. Dafür hat ISO/TC211 mit dem Projekt 41 den<br />
Amendment Prozess gestartet. Über diese Schiene sind begründete<br />
Verbesserungsanträge einzureichen.<br />
Gewisse Normen sind eigentlich eher technische Reports über den aktuellen St<strong>and</strong> der<br />
Dinge. So etwa das ‚Spatial schema’ ISO 19107 und das ‚Temporal schema’ ISO 19108.<br />
Beide haben deshalb in der Kolonne M „Minimum festgelegt“ ein u für „ungenügend“.<br />
Damit zu diesen Themen eine minimale aber echte Integrierbarkeit / <strong>Interoperabilität</strong><br />
unterstützt wird, muss für beide Normen eine konsistente Teilmenge als sogenanntes<br />
Pr<strong>of</strong>il definiert werden. Ein erster Schritt in dieser Richtung wurde bereits gemacht mit<br />
dem minimalen Pr<strong>of</strong>il des ‚Spatial schema’ durch ISO 19137.<br />
Eine Dauerfrage ist immer: Genügt eine graphische CSL auf konzeptioneller Ebene? Es<br />
ist klar, dass etwa im Bereich der Datentypen eine Präzisierung nötig ist, um Transferformate<br />
(und <strong>and</strong>ere Dienste) eindeutig generieren zu können. Diese Präzisierung sollte<br />
nicht versteckt werden in XSLT-Skripts, sondern <strong>of</strong>fengelegt werden mit einer normierten<br />
textueller konzeptionellen OO Beschreibungssprache.<br />
Die Lücke bei den Schweizer Normen im Bereich Web-Services bedeutet nicht, dass es<br />
keine INTERLIS basierten Web-Dienste gibt. Im Gegenteil. Es sind verschiedene grosse<br />
Geo-Portale in Betrieb mit Hilfe von INTERLIS. Hingegen soll darüber hinaus versucht<br />
werden, durch eine Kombination der modellbasierten Methode mit den OGC Web-<br />
Services eine „best <strong>of</strong>“ Lösung des Typs Model Driven Web Feature Server (MDWFS) zu<br />
bauen.<br />
6 Zusammenfassung<br />
Klar ist: Die modellbasierte Methode ist Basis der weltweiten und der europäischen<br />
Geo-Normung.<br />
Transferformate sollten eigentlich verschieden gewählt werden können entsprechend<br />
verschiedenen Bedürfnissen und Ansprüchen (Binär / ASCII / tagged). Der modellbasierte<br />
Ansatz, aus einem system- und formatunabhängigem Datenmodell automatisch<br />
verschiedene Formate herzuleiten gemäss definierten Regeln (und in Zukunft auch verschiedene<br />
Protokolle), ist auch in dieser Beziehung sehr viel versprechend.<br />
Bleibt zum Schluss noch die Frage, ob die Geo-Normung den mehrdimensionalen Spagat<br />
zwischen Technikdynamik und Anforderungswidersprüchen erfolgreich meistert.<br />
Wir müssen die Beantwortung der Zukunft überlassen. Aber mindestens ist mit dem<br />
Entscheid für die modellbasierte Methode eine sehr tragfähige Voraussetzung für einen<br />
Erfolg geschaffen.<br />
4.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Adrian Annen<br />
Fachhochschule beider Basel<br />
Abteilung Vermessung und Geoinformation<br />
Gründenstrasse 40<br />
CH-4132 Muttenz<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 61 467 44 68<br />
+41 61 467 44 60<br />
5<br />
Open Geospatial Consortium OGC<br />
GML, WMS und WFS<br />
Adrian Annen, Fachhochschule beider Basel<br />
(FHBB), Abt. Vermessung und Geoinformation
1 Kurzfassung<br />
Mit dem Open Geospatial Consortium (OGC) existiert ein internationales Industriekonsortium<br />
mit dem Ziel, die <strong>Interoperabilität</strong> von Geodaten zu verbessern. Die Abkürzungen<br />
GML, WMS und WFS, welche im Zusammenhang mit dem OGC <strong>of</strong>t verwendet<br />
werden, sind Bezeichnungen für <strong>of</strong>fene, systemunabhängige Mechanismen<br />
zum Austausch von Geodaten. Bei der Geography Markup Language (GML) h<strong>and</strong>elt<br />
es sich um eine XML-basierte Applikation für die Modellierung und den Austausch<br />
von Daten mit Raumbezug. GML wird unter <strong>and</strong>erem für verschiedene Webdienste<br />
verwendet. Als Beispiel kann der Web Feature Service (WFS) genannt werden, welcher<br />
für den Austausch und die Manipulation von Daten über das Web verwendet<br />
wird. Demgegenüber bietet der Web Map Service (WMS) einen Webdienst für gerenderte<br />
Karten an. Die WMS-Spezifikation ist die bisher am erfolgreichsten umgesetzte<br />
Spezifikation des OGC.<br />
2 Einleitung<br />
Im Zusammenhang mit dem Begriff der <strong>Interoperabilität</strong> im Geoinformationsbereich<br />
werden <strong>of</strong>t Abkürzungen wie OGC, GML, WMS und WFS verwendet. Seit den frühen<br />
neunziger Jahren hat sich in diesem Bereich eine breit abgestützte Organisation (Open<br />
Geospatial Consortium) gebildet, welche bestrebt ist, <strong>of</strong>fene, systemneutrale Schnittstellen<br />
zu schaffen, und so die Verfügbarkeit von Daten mit Raumbezug weltweit zu erhöhen.<br />
Dabei wird auf bestehende St<strong>and</strong>ards der Informatik-Welt aufgebaut. Zum Beispiel<br />
dient XML als Grundlage für praktisch alle Spezifikationen des OGC.<br />
Eine bereits erfolgreich umgesetzte Spezifikation des OGC ist der Web Map Service<br />
(WMS). Diese wurde von diversen kommerziellen Herstellern und von einigen Open-<br />
Source-Projekten erfolgreich implementiert.<br />
Den wohl wichtigsten St<strong>and</strong>ard des OGC stellt die Geography Markup Language<br />
(GML) dar. GML stellt einen Mechanismus zur Modellierung und zum Austausch von<br />
primär vektor-orientierten Geodaten zur Verfügung. Verschiedene Webdienste wiederum<br />
bauen auf GML auf. Ein Beispiel für solche Webdienste ist die Web Feature Service<br />
(WFS)-Spezifikation.<br />
In den folgenden Abschnitten werden das OGC selbst, sowie die oben genannten Spezifikationen<br />
näher vorgestellt. Zu beachten ist, dass damit nur ein kleiner Ausschnitt der<br />
vielfältigen Arbeit des OGC beleuchtet werden kann. Für detailliertere Informationen<br />
sei an dieser Stelle auf die Webseite www.opengeospatial.org verwiesen.<br />
3 Open Geospatial Consortium (OGC)<br />
3.1 Wer ist das OGC?<br />
Das Open Geospatial Consortium (OGC) ist ein internationales Industriekonsortium,<br />
bestehend aus über 270 Firmen, Behörden und Hochschulen, welches sich zum Ziel gesetzt<br />
hat, öffentlich verfügbare Schnittstellen-Spezifikationen im Konsensverfahren zu<br />
entwickeln. OGC-Spezifikationen unterstützen interoperable Lösungen, welche das<br />
Web, mobile Anwendungen, Location Based Services (LBS) und allgemeine Informatiklösungen<br />
um einen Raumbezug erweitern. Mit den OGC-Spezifikationen soll es Entwicklern<br />
möglich sein, komplexe Geoinformationen und darauf basierende Dienste einem<br />
breiten Spektrum von Nutzern und Anwendungen zugänglich zu machen.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 5.1
Nationale und internationale St<strong>and</strong>ards<br />
Open Geospatial Consortium OGC (GML, WMS und WFS)<br />
Das OGC finanziert sich primär über die Beiträge seiner Mitglieder. Zurzeit existieren<br />
acht verschiedene Mitgliederkategorien. Diese unterscheiden sich im zu entrichtenden<br />
Jahresbeitrag (zwischen 300$ bis >50'000$ pro Jahr) aber auch in den Rechten und Pflichten.<br />
OpenGIS® ist eine geschützte Marke des Open Geospatial Consortium, Inc. und dient<br />
gleichzeitig als Produktname für die Spezifikationen und Dokumente, welche vom OGC<br />
erstellt und publiziert werden.<br />
3.2 Geschichte<br />
Die wichtigsten Ereignisse in der Geschichte des OGC können wie folgt zusammengefasst<br />
werden:<br />
Jahr Meilenstein<br />
Diverse Aktivitäten rund um das Open Source Projekt GRASS<br />
80er Jahre<br />
(Geographic Resource <strong>and</strong> Analysis Support System)<br />
Gründung des Open GIS Consortium, Inc.<br />
1994<br />
Mitgliederzahl Ende 1994: 20<br />
Publikation der OpenGIS Web Map Server Interface Specification<br />
1999 und des Zusammenarbeitsvertrags zwischen ISO/TC 211 und OGC<br />
Mitgliederzahl Ende 1999: 182<br />
Umbenennung in Open Geospatial Consortium, Inc.<br />
2004<br />
Mitgliederzahl Ende 2004: 272<br />
Im Januar 2005 existierten 17 Abstract Specifications und 14 Implementation Specifications.<br />
Zusätzlich wurden unzählige Recommendation Papers und weitere Entwürfe öffentlich<br />
publiziert.<br />
4 Geography Markup Language (GML)<br />
4.1 Was ist GML?<br />
Die Geography Markup Language (GML) ist eine XML-Applikation des Open Geospatial<br />
Consortiums (OGC) für die Modellierung, den Austausch und die Speicherung<br />
von Informationen mit Raumbezug. Die wichtigsten Ziele von GML sind:<br />
� Unterstützung möglichst vieler Einsatzgebiete (auch nicht-räumliche Daten können<br />
abgebildet werden)<br />
� GML als Grundlage für Internet-GIS Anwendungen<br />
� Einfach zu verstehende Codierung räumlicher Daten und derer Beziehungen<br />
� Effiziente Codierung von Geometriedaten<br />
� Trennung der Daten von deren Präsentation<br />
� Einfache Integration bereits in XML vorh<strong>and</strong>ener, nicht-räumlicher Daten<br />
� Möglichkeit der Verknüpfung verschiedener Datensätze<br />
� Bereitstellung eines Basissatzes geometrischer Objekte<br />
Diese Ziele werden mit einer umfangreichen Spezifikation angepeilt. Die aktuelle Version<br />
(3.1) der GML-Spezifikation beinhaltet etwa 600 Seiten.<br />
5.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
4.2 Einsatzspektrum<br />
Nationale und internationale St<strong>and</strong>ards<br />
Open Geospatial Consortium OGC (GML, WMS und WFS)<br />
Eines der wichtigsten Ziele ist die universelle Verwendbarkeit von GML als Datenformat<br />
für beliebige Anwendungen mit räumlichem Bezug. Die hauptsächlichen<br />
Einsatzgebiete von GML sind:<br />
� Austausch von Daten zwischen verschiedenen GIS-Systemen<br />
� Basis für Internet-GIS Anwendungen (Bsp. Web Feature Service, WFS)<br />
� Basis für Location Based Services (LBS)<br />
4.3 Konzept<br />
Das Konzept von GML beruht auf dem Feature-Modell des OGC. Ein 'Feature' gemäss<br />
der OGC-Definition besteht aus einem Objekt mit einer Reihe von Eigenschaften ('Properties').<br />
Jede dieser Eigenschaften ist charakterisiert durch ihren Namen, ihren Typ und<br />
ihren Wert. Wenn der Typ zumindest einer Eigenschaft eines Features geometrisch ist,<br />
spricht man von einem geographischen Feature. Mehrere Features können zu Feature<br />
Collections zusammengefasst werden. Eine Feature Collection repräsentiert allerdings<br />
wiederum ein Feature, so dass eine beliebig tiefe Schachtelung modelliert werden kann.<br />
Abb. 1 : GML-Grundkonzept<br />
GML 3 ist in ca. 30 XML-Schema-Dokumenten (Basisschemen) definiert. Für eine konkrete<br />
Anwendung von GML muss ein anwendungsspezifisches Schema abgeleitet werden,<br />
welches auf den in den Basisschemen definierten Klassen aufbaut. Im Applikationsschema<br />
können eigene Features mit anwendungsspezifischen Eigenschaften definiert<br />
werden. Dies kann über Erweiterung oder Einschränkung der vorh<strong>and</strong>enen Klassen<br />
erreicht werden.<br />
4.4 Verbindung zu ISO<br />
Das OGC ist bemüht, seine Konzepte denjenigen der ISO (International Organization for<br />
St<strong>and</strong>ardization) anzupassen. So ist vorgesehen, die OGC-Spezifikation GML (Version<br />
3.x) mit der ISO Norm 19136 (Geography Markup Language GML) zu harmonisieren.<br />
Gegenwärtig ist die ISO Norm 19136 in der 'Commitee Stage' (St<strong>and</strong> Januar 2005). Das<br />
bedeutet, dass sich das zuständige Technical Commitee (TC) der ISO mit der Spezifikation<br />
befasst. In diesem Fall ist das TC 211 der ISO zuständig. Für nähere Angaben wird<br />
auf die Website der ISO (www.iso.org) verwiesen.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 5.3
Nationale und internationale St<strong>and</strong>ards<br />
Open Geospatial Consortium OGC (GML, WMS und WFS)<br />
5 OGC Web Services<br />
5.1 Zielsetzung<br />
Vielerorts sind bereits grosse Mengen von Daten in proprietären Datenformaten vorh<strong>and</strong>en.<br />
Die Nutzung dieser Daten von fremden Systemen aus ist nur mühsam, oder<br />
gar nicht möglich. Eine Lösung dafür bieten Webdienste an. Dabei wird über das Internet<br />
auf verteilte Datenquellen zugegriffen. Neben den grossen GIS-Herstellern, die solche<br />
Lösungen anbieten, sind auch Open Source Projekte verfügbar, die diese Funktionalität<br />
zur Verfügung stellen. Weiterhin ungelöst bleibt die Verknüpfung von unterschiedlichen<br />
Diensten (Insellösungen). Dies ist der Ansatzpunkt der OGC Web Services. Sie<br />
definieren Methoden, eine Reihe von Parametern sowie Kommunikationsregeln, die einem<br />
beliebigen System den Zugriff auf verteilte Datenquellen ermöglichen, s<strong>of</strong>ern beide<br />
Komponenten über die identische Schnittstelle verfügen.<br />
5.2 Grundprinzip<br />
Die OGC definierte in der OWS (OGC Web Services) Common Implementation Specification<br />
die Gemeinsamkeiten ihrer verschiedenen Web Services. Der Ausdruck Web Service<br />
beschreibt die st<strong>and</strong>ardisierte Weise der Integration netzwerk-basierter Applikationen.<br />
Für die Definition und Beschreibung der Applikationen wird XML verwendet. Die<br />
Kommunikation erfolgt auf der Basis von Internet-Protokollen. Durch den Einsatz von<br />
XML sind Web Services nicht an ein bestimmtes Betriebssystem oder eine bestimmte<br />
Programmiersprache gebunden.<br />
Abb. 2 : Funktionsschema OGC Web Services<br />
Das in Abb. 2 dargestellte Funktionsschema stellt folgende Funktionen dar:<br />
1. Client kontaktiert Server und fordert Capabilities-Dokument an<br />
2. Server liefert XML-formatierte Capabilities (Beschreibung der Funktionalität) des<br />
gewünschten Services an den Client<br />
3. Client fordert Daten vom Server an<br />
4. Server liefert die angeforderten Daten im verlangten Format<br />
Diese vier Schritte bilden die Grundfunktionalität eines Services nach OGC-Spezifikation.<br />
Je nach Service sind weitere Interaktionen zwischen Client und Server möglich,<br />
beispielsweise das Abfragen weiterer Informationen über ein Feature, ein Kartenlayer<br />
etc.<br />
Web Services kommunizieren (gemäss ihrer Definition) mit Hilfe von beliebigen Internet-Protokollen<br />
mitein<strong>and</strong>er. Die meisten OGC Web Services benutzen zurzeit das<br />
HTTP-Protokoll. Das Hyper Text Transfer Protocol (HTTP) verfügt über ein sehr einfaches<br />
Interaktionsschema zwischen Client und Server, welches aus einem von einem<br />
Client an einen Server gesendeten Request (Anfrage) und einer vom Server an den<br />
Client geschickten Response (Antwort) besteht.<br />
5.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
5.3 Web Map Service (WMS)<br />
Nationale und internationale St<strong>and</strong>ards<br />
Open Geospatial Consortium OGC (GML, WMS und WFS)<br />
Die WMS-Spezifikation beschreibt eine Schnittstelle, über welche georeferenzierte Karten<br />
bereitgestellt werden können. Die Realisierung basiert auf drei Grundoperationen,<br />
für die jeweils ein Parametersatz definiert ist:<br />
� Beschreibung der verfügbaren Daten (GetCapabilities)<br />
� Lieferung der angeforderten Daten (GetMap)<br />
� Abfragen weiterer Informationen (GetFeatureInfo)<br />
Dabei sind die ersten beiden Operationen zwingend zu implementieren, die Funktion<br />
zur Abfrage von Feature-Informationen ist optional.<br />
Der Zugriff auf einen WMS kann mit Hilfe eines St<strong>and</strong>ardbrowsers erfolgen, wobei die<br />
Parameter in der URL übermittelt werden (GET Methode). Komfortabler sind natürlich<br />
Programme mit einer graphischen Benutzeroberfläche (GUI), entweder als Browser- oder<br />
als St<strong>and</strong>alone-Applikation konzipiert. Mit der aktuellen WMS-Version (1.3) ist auch<br />
die Übermittlung der Anfragen mit der POST Methode festgelegt.<br />
Im Allgemeinen liefert ein WMS gerenderte Bilder in einem üblichen Bildformat wie<br />
PNG (Portable Network Graphics), JPEG (Joint Pictures Expert Group) oder GIF (Graphics<br />
Interchange Format). Denkbar ist aber auch die Erzeugung von Karten im SVG-<br />
Format (Scalable Vector Graphics).<br />
Abb. 3 : Schematische Darstellung verteilter WMS<br />
WMS-Karten können von beliebigen, verschiedenen WMS angefordert werden. Das<br />
heisst, die Spezifikation unterstützt den Aufbau eines Netzwerkes verteilter Map Server<br />
von denen ein Client Daten anfordern kann (siehe Abb. 3). Da jeder WMS unabhängig ist,<br />
muss jeder die Fähigkeit besitzen, seine Möglichkeiten und Ressourcen maschinenlesbar<br />
zu beschreiben.<br />
In Abb. 3 ist zudem das Konzept eines kaskadierenden Map Servers (Cascading Map<br />
Server) dargestellt. Dabei ist ein Map Server ein Client von <strong>and</strong>eren WMS und bildet<br />
gegen aussen einen neuen Web Map Service (Zusammenfassen mehrerer WMS in einen<br />
Service).<br />
Die Spezifikation WMS 1.3 des OGC wird zurzeit als ISO/DIS Norm 19128 (Web Map<br />
Server Interface) in die ISO-Normenserie integriert.<br />
5.4 Web Feature Service (WFS)<br />
Während mit dem WMS in der Regel gerenderte (Raster-)Daten geliefert werden, steht<br />
bei der WFS-Spezifikation die Übertragung von geographischen Objekten im Vordergrund.<br />
Dabei stellt sich das Problem, dass Geodaten <strong>of</strong>t nicht nach einem einheitlichen<br />
Datenschema modelliert sind. Deshalb ist es wichtig, dass das Datenschema mit den Daten<br />
mitgeliefert wird. Ein entsprechender Client muss somit mit diesem Datenschema<br />
und den Daten umgehen können.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 5.5
Nationale und internationale St<strong>and</strong>ards<br />
Open Geospatial Consortium OGC (GML, WMS und WFS)<br />
Als Grundlage für die WFS-Spezifikation dient der Datenaustauschmechanismus GML<br />
(Geography Markup Language) des OGC. Damit können Geodaten und ihr zugehöriges<br />
Schema in XML codiert und übertragen werden.<br />
Im Unterschied zum WMS ist es auch möglich, diese Daten zu manipulieren und zu<br />
verändern. Dazu wurden weiterführende Operationen wie 'Transaction' und 'LockFeature'<br />
definiert.<br />
Die folgenden Operationen sind in der WFS-Spezifikation definiert:<br />
� GetCapabilities: Ein WFS muss in der Lage sein, seine Funktionalität zu beschreiben.<br />
Im Speziellen muss er in der Lage sein, die unterstützen Feature-Typen und die<br />
darauf anwendbaren Operationen anzugeben.<br />
� DescribeFeatureType: Auf Anfrage muss ein WFS in der Lage sein, die Struktur jedes<br />
unterstützten Feature-Typen zu liefern (Datenschema). Konkret wird hier ein<br />
GML-Applikationsschema übertragen.<br />
� GetFeature: Ein WFS muss in der Lage sein, Instanzen (Objekte) von Feature-Typen<br />
zu liefern. Zusätzlich muss er erkennen, welche Eigenschaften (properties) er mitliefern<br />
soll, und er muss in der Lage sein, sowohl räumliche wie auch nichträumliche<br />
Selektionen zu unterstützen.<br />
� Transaction: Ein WFS kann in der Lage sein, Operationen an Objekten auszuführen.<br />
Diese Operationen sind 'create', 'update' und 'delete' an geographischen Objekten.<br />
� LockFeature: Ein WFS kann einen Lock-Request auf eine oder mehrere Instanzen<br />
während der Dauer einer Transaktion anwenden.<br />
Dementsprechend kann zwischen verschiedenen Typen von Web Feature Services unterschieden<br />
werden:<br />
� Basic WFS: Ein Basis-WFS unterstützt die Operationen 'GetCapabilities', 'Describe-<br />
FeatureType' und 'GetFeature'. Dies entspricht einem 'Read-Only'-WFS.<br />
� Transaction WFS: Dieser unterstützt sämtliche Operationen des Basis-WFS, und<br />
zusätzlich die Operationen 'Transaction' und 'LockFeature' (optional).<br />
Ein WFS liefert mit dem GetFeature-Aufruf ein GML-Instanzdokument. In der aktuell<br />
gültigen Version der WFS-Spezifikation (1.0) ist festgelegt, dass die GML-Version 2<br />
verwendet werden soll. Gegenwärtig ist die WFS-Spezifikation in einer Überarbeitungsphase,<br />
in welcher unter <strong>and</strong>erem die Integration der Version 3 von GML diskutiert<br />
wird. Allerdings ist noch nicht klar, ob die vollständige GML 3 – Spezifikation<br />
unterstützt werden soll. Auf Grund der Komplexität der aktuellen GML-Version wird<br />
über eine Einschränkung mit einem Pr<strong>of</strong>il (Level 0) diskutiert.<br />
6 Fazit<br />
Mit dem OGC hat sich im Geoinformationssektor ein sehr aktives, internationales Industriekonsortium<br />
mit internationalem St<strong>and</strong>ardisierungsanspruch etabliert. Durch die<br />
Mitwirkung grosser Systemhersteller, nationaler und internationaler Behörden und vieler<br />
Hochschulen ist das Konsortium mittlerweile breit abgestützt. Mit seinen Aktivitäten<br />
hat das OGC zu einer deutlichen Verlagerung bzw. Erweiterung des Fokus von den vielen<br />
nationalen Normen und St<strong>and</strong>ards auf die internationale St<strong>and</strong>ardisierung beigetragen.<br />
Erfreulich ist, dass dabei die OGC seit einigen Jahren ihre Aktivitäten mit denjenigen<br />
der ISO harmonisiert, was mittel- und langfristig zu einer breiteren Akzeptanz und<br />
auch zu stabileren St<strong>and</strong>ards führen dürfte.<br />
Mit WMS, WFS und GML hat das OGC drei sehr nützliche Spezifikationen geschaffen.<br />
Dabei hat sich am Beispiel des WMS gezeigt, dass sogar die Umsetzung eines relativ<br />
5.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nationale und internationale St<strong>and</strong>ards<br />
Open Geospatial Consortium OGC (GML, WMS und WFS)<br />
einfachen St<strong>and</strong>ards auf internationaler Basis mehrere Jahre in Anspruch nehmen kann.<br />
Es ist daher anzunehmen, dass die Definition von Minimalpr<strong>of</strong>ilen im Falle von GML<br />
und WFS eine erfolgreiche Umsetzung deutlich beschleunigen würde. Der für einen<br />
breiten Einsatz der St<strong>and</strong>ards dringende Übergang von formatbasierten auf modellbasierte<br />
Mechanismen wurde von OGC mittlerweile erkannt und eingeleitet. Das damit<br />
verbundene Umdenken bei Systemherstellern und Anwendern sowie die konsequente<br />
Umsetzung dürften aber noch viel Arbeit und Zeit erfordern.<br />
7 Literatur<br />
Nebiker S. und Annen A. , 2004<br />
Vergleichsstudie INTERLIS 2 – GML 3<br />
Verfügbar unter:<br />
http://www.kogis.ch/docs/Vergleichsstudie_ILI_GML_revidiert.pdf<br />
[Online 21. Jan. 05]<br />
Nebiker, S., et al., 2004<br />
Skript zum GIS/SIT-Workshop 2004: 'WMS, WFS, Simple Features und Co.'<br />
[durchgeführt am 30. März 2004 in Bern]<br />
Open Geospatial Consortium Inc. (OGC), 2004<br />
Geography Markup Language (GML) Recommendation Paper 3.1<br />
Verfügbar unter:<br />
http://portal.opengeospatial.org/files/?artifact_id=4700 [Online 21. Jan. 05]<br />
Open Geospatial Consortium Inc. (OGC), 2004<br />
Web Map Service (WMS) Implementation Specification 1.3<br />
Verfügbar unter:<br />
http://portal.opengeospatial.org/files/?artifact_id=5316 [Online 21. Jan. 05]<br />
Open Geospatial Consortium Inc. (OGC), 2002<br />
Web Feature Service (WFS) Implementation Specification 1.0<br />
Verfügbar unter:<br />
https://portal.opengeospatial.org/files/?artifact_id=7176 [Online 21. Jan. 05]<br />
International Organization for St<strong>and</strong>ardization (ISO).<br />
Informationen zu diversen St<strong>and</strong>ards<br />
Verfügbar unter:<br />
http://www.iso.org [Online 21. Jan. 05]<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 5.7
Andreas Donaubauer, Dr.-Ing. /<br />
Matthäus Schilcher, Univ.-Pr<strong>of</strong>. Dr.-Ing. /<br />
Anette Huber<br />
Technische Universität München<br />
Fachgebiet Geoinformationssysteme<br />
Arcisstraße 21<br />
D-80290 München<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+49 89 289 22973<br />
+49 89 289 22878<br />
6<br />
OGC-Lösungen<br />
Möglichkeiten und Grenzen<br />
Andreas Donaubauer, Matthäus Schilcher,<br />
Anette Huber, TU München
Vorwort<br />
Der Beitrag gibt einen Überblick über den St<strong>and</strong> der Technik zur Nutzung verteilter<br />
Geodaten auf der Basis der St<strong>and</strong>ards des Open Geospatial Consortium (OGC).<br />
Anh<strong>and</strong> von Praxistests werden die Möglichkeiten und Grenzen von OGC-St<strong>and</strong>ards<br />
diskutiert. Im Ausblick wird ein neues Forschungsprojekt zwischen ETH Zürich und TU<br />
München zum Aufbau einer grenzüberschreitenden Geodateninfrastruktur (GDI) vorgestellt,<br />
bei dem Synergien der beiden Lösungsansätze „modellbasierter Datentransfer“<br />
und „OGC Web Services“ untersucht werden sollen.<br />
1 Einführung und Begriffsbestimmung<br />
Seit nun gut 20 Jahren werden an verschiedensten Stellen in Verwaltung und Wirtschaft<br />
digitale Geodaten produziert. Dabei entst<strong>and</strong> im Laufe der Zeit eine große Anzahl an<br />
verteilten Geodatenbeständen, deren effiziente und nachhaltige Nutzung über organisatorische<br />
Grenzen hinweg jedoch meist durch die derzeit existierenden heterogenen GIS-<br />
L<strong>and</strong>schaften behindert wird. Die Probleme liegen vor allem in der Heterogenität der<br />
verschiedenen Systeme – deren proprietären Schnittstellen und Datenformaten – aber<br />
auch in der Verwendung verschiedener Datenmodelle sowohl auf konzeptioneller, logischer<br />
und physikalischer Ebene begründet.<br />
Zur Überwindung der derzeit bestehenden Probleme bei der kombinierten Nutzung<br />
verteilter, heterogener Geodaten werden in Wirtschaft und Forschung momentan zwei<br />
Lösungsansätze intensiv diskutiert und verfolgt, die auf internationalen St<strong>and</strong>ards und<br />
Normen basieren. Zum einen der modellbasierte Datentransfer zur Überwindung der<br />
Heterogenität der Daten und deren zugrunde liegenden Modellen, wie er in der Geo-<br />
Normenserie ISO19100 konzipiert ist und mit INTERLIS, einer Schweizer Norm ermöglicht<br />
wird, zum <strong>and</strong>eren die Verwendung von Geo Web Services des Open Geospatial<br />
Consortiums OGC zur Herstellung von <strong>Interoperabilität</strong> zwischen verschiedenen GI-<br />
Systemen in Bezug auf deren proprietäre Zugriffsschnittstellen und Datenformate.<br />
Dieser Beitrag beschreibt die Möglichkeiten und Grenzen des auf <strong>Interoperabilität</strong><br />
mittels OGC Web Services1 basierenden Lösungsansatzes und gibt einen Ausblick<br />
auf eine zukünftige Kombination der beiden Lösungsansätze „<strong>Interoperabilität</strong> mittels<br />
OGC Web Services“ und „modellbasierter Datentransfer“ – im Folgenden mit<br />
„Kombinierter Ansatz“ bezeichnet.<br />
Tabelle 1 gibt einen Überblick über Methoden zur kombinierten Nutzung verteilter<br />
Geodaten und erlaubt eine Einordnung der genannten Lösungsansätze.<br />
1 Dieser Beitrag beschränkt sich auf das Web als Plattform für die <strong>Interoperabilität</strong> von GI-Systemen.<br />
Das OGC erarbeitet neben den Spezifikationen auf Basis der Web-Technologie (OGC Web Services)<br />
auch St<strong>and</strong>ards für weitere Plattformen (z.B. SQL, CORBA, JAVA). Diese werden hier nicht betrachtet.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 6.1
St<strong>and</strong> der Technik, Implementierungen I<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
Beispiele für<br />
St<strong>and</strong>ards und<br />
Normen<br />
Beispiele für<br />
herstellerspezifische /<br />
proprietäre Formate /<br />
Zugriffsschnittstellen<br />
Datentransfer auf Dateiebene grafik-orientiert TIFF (ISO 12639), DBR (SICAD) DXF<br />
SVG (W3C)<br />
(CAD)<br />
„Datenintegration“ objektstrukturiert GDF (ISO 14825) Shape (ESRI), SQD<br />
modellbasiert INTERLIS ?<br />
<strong>Interoperabilität</strong> (Internet als grafik-orientiert OGC WMS Web-Zugriffs-<br />
Kommunikationsplattform<br />
Schnittstelle von<br />
zwischen den<br />
Autodesk MapGuide<br />
S<strong>of</strong>twarekomponenten) objektstrukturiert OGC WFS Zugriffsschnittstelle<br />
eines ESRI ArcIMS<br />
„Web Services“<br />
Feature Service<br />
modellbasiert OGC+INTERLIS<br />
(noch nicht<br />
verfügbar)<br />
„kombinierter Ansatz“ OGC Web Services<br />
Tab. 1 : Methoden zur kombinierten Nutzung verteilter Geodaten<br />
Im Folgenden werden einige grundlegende Begriffe für den Lösungsansatz „<strong>Interoperabilität</strong><br />
mittels OGC Web Services definiert.<br />
Verteilte (Geo-)Daten: (Geo-)Daten, die physikalisch oder logisch getrennt von ein<strong>and</strong>er<br />
vorgehalten werden.<br />
<strong>Interoperabilität</strong>: Fähigkeit zur Zusammenarbeit unabhängiger Systeme durch Anbieten<br />
bzw. Inanspruchnahme von Daten und Funktionalität über S<strong>of</strong>twareschnittstellen.<br />
Dienst / Service: Abgeschlossene Funktionalität, die von einer S<strong>of</strong>twarekomponente<br />
über eine S<strong>of</strong>twareschnittstelle angeboten wird. Komplexität und interne Strukturen der<br />
S<strong>of</strong>twarekomponente bleiben vor dem Nutzer eines Dienstes verborgen.<br />
Verkettung von Diensten / Service Chaining: Sequentieller oder paralleler Aufruf von<br />
Diensten, so dass die Antwort eines Dienstes als Eingabe für den Aufruf eines weiteren<br />
Dienstes in der Kette verwendet wird. Die Verkettung von Diensten ist grundlegend für<br />
die Erstellung von Dienstebündeln.<br />
Dienstebündel / Aggregate Service: Kombination einzelner Dienste zu einem höherwertigen<br />
Dienst. Ein Dienstebündel muss erstellt werden, wenn die Funktionalität oder<br />
das Datenangebot eines einzelnen Dienstes nicht ausreicht, um die Fragestellung eines<br />
Anwenders zu beantworten. Kern jedes Dienstebündels ist ein so genannter Aggregate<br />
Service, der die Benutzereingaben entgegennimmt, für die Verkettung der Dienste verantwortlich<br />
ist und das Endergebnis an den Benutzer ausliefert. Ein Aggregate Service<br />
tritt somit als Client für mehrere Dienste auf.<br />
Web Service: Funktionalität, die von einer S<strong>of</strong>twarekomponente über eine Web-<br />
Schnittstelle angeboten wird. Über die Web Schnittstelle können auch die Fähigkeiten<br />
und weitere Informationen über den Web Service angefragt werden<br />
Geo Web Service: Web Service mit der Funktionalität zur Nutzung von Geodaten<br />
OGC Web Service: Geo Web Service mit einer vom Open Geospatial Consortium OGC<br />
spezifizierten Schnittstelle.<br />
6.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
2 Möglichkeiten von OGC Web Services<br />
St<strong>and</strong> der Technik, Implementierungen I<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
Die Anwendung „Leitungsauskunft aus verteilten GIS“, ist in einem praxisorientierten<br />
Forschungsprojekt der Technischen Universität München und des Vereins Runder Tisch<br />
GIS e.V. entst<strong>and</strong>en. Sie soll im Folgenden beispielhaft die Möglichkeiten und Vorteile<br />
der einfachen Nutzung verteilter Geodaten mittels OGC Web Services aufzeigen.<br />
2.1 Erfahrungen der TU München und des Vereins Runder Tisch GIS<br />
e.V.<br />
Das Fachgebiet Geoinformationssysteme der TU München und der Verein Runder Tisch<br />
GIS e.V. konnten seit dem Jahr 2000 in mehreren Forschungsprojekten umfangreiche<br />
Erfahrungen mit der Entwicklung, Nutzung und herstellerübergreifenden Kombination<br />
von OGC Web Services sammeln.<br />
2.1.1 Forschungsschwerpunkte<br />
Schwerpunkte der Forschungsarbeiten der TU München und des Vereins Runder Tisch<br />
GIS e.V. im Bereich der Nutzung verteilter Geodaten sind:<br />
� Einfacherer Zugang und effizientere Nutzung vorh<strong>and</strong>ener Geodaten,<br />
� Nutzung verteilter Geodaten für eine neues Nutzerpr<strong>of</strong>il (GIS-Laien),<br />
� Verkettung von Geo Web Services,<br />
� Möglichkeiten und Grenzen der Nutzung von OGC Web Services,<br />
� Herstellerübergreifende <strong>Interoperabilität</strong> auf Basis der St<strong>and</strong>ards des OGC<br />
� Wirtschaftlichkeit und Geschäftsmodelle für die Nutzung verteilter Geodaten.<br />
2.1.2 OGC Testplattform des Vereins Runder Tisch GIS e.V.<br />
Im Rahmen der OGC-Testplattform, einer Testumgebung, in der Produkte aller führenden<br />
GIS-Hersteller sowie Open Source S<strong>of</strong>tware betrieben werden (siehe Abb. 1), wird<br />
vom Runden Tisch GIS e.V. GIS-herstellerübergreifend die Umsetzung von OGC Spezifikationen<br />
untersucht. Wesentliche Ziele sind es, zu zeigen:<br />
� dass GIS unterschiedlicher Hersteller auf Basis der OGC St<strong>and</strong>ards in gemeinsamen<br />
Anwendungen zusammenwirken können,<br />
� dass durch den Zugriff auf verteilte Daten von Behörden und aus der Wirtschaft<br />
mittels OGC Web Services ein Nutzen für den Anwender generiert werden kann,<br />
� dass Praxis-Anwendungen auf der Basis des Zugriffs auf existierende, verteilte<br />
Geodatenbestände mittels OGC Web Services entwickelt werden können,<br />
� dass der Ansatz im deutschen Umfeld und länderübergreifend erfolgreich eingesetzt<br />
werden kann.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 6.3
St<strong>and</strong> der Technik, Implementierungen I<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
Hersteller (Produkte) OGC-Spezifikationen<br />
AED-SICAD<br />
(Internet Suite 6.0)<br />
Autodesk<br />
(MapGuide 6.5)<br />
C-Plan<br />
(TB Internet)<br />
ESRI<br />
(ESRI ArcIMS 9.0 SP1<br />
mit WMS- und WFS-<br />
Connector)<br />
GE Energy (Smallworld<br />
SIAS 2.1)<br />
Intergraph (GeoMedia<br />
WebMap 5.1b mit WMS<br />
und WFS Adapter)<br />
M.O.S.S.<br />
(WEGA-MARS 4.2)<br />
Terradata<br />
University <strong>of</strong><br />
Minnesota (UMN Map<br />
Server 4.3)<br />
WMS (Web Map Service)<br />
WFS (Web Feature Service)<br />
WCTS (Web Coordinate<br />
Transformation Service)<br />
Aggregate Services:<br />
implementieren mehrere<br />
Spezifikationen als Client<br />
Testgebiete<br />
(Datenanbieter)<br />
Baden-Württemberg,<br />
Stadt Horb am Neckar<br />
Bayern:<br />
L<strong>and</strong>kreis Fürstenfeldbruck,<br />
Stadt Bad Wörish<strong>of</strong>en, Stadt<br />
München, Stadt Nürnberg<br />
Br<strong>and</strong>enburg:<br />
L<strong>and</strong>kreis Barnim<br />
Anwendungsbeispiele<br />
Herstellerübergreifender<br />
<strong>Interoperabilität</strong>stest WMS<br />
Immobilienbewertung<br />
(länderübergreifend)<br />
Leitungsauskunft aus<br />
verteilten GIS<br />
Universitäten<br />
Technische Universität<br />
München<br />
Universität der Bundeswehr<br />
München<br />
GIS-Dienstleistungsunternehmen<br />
Geo-IT<br />
RIWA<br />
Abb. 1 : OGC-Testplattform des Vereins Runder Tisch GIS e.V. (St<strong>and</strong> Januar 2005)<br />
Weitere Merkmale der OGC-Testplattform sind:<br />
� herstellerneutral,<br />
� hersteller- und branchenübergreifend,<br />
� grenzüberschreitend,<br />
� Aufbau durch Zusammenarbeit zwischen Datenlieferanten, Systemherstellern,<br />
Universitäten und GIS-Dienstleistungsunternehmen<br />
� Forschung anh<strong>and</strong> konkreter und praktisch verwertbarer Anwendungen,<br />
� Beitrag zum Aufbau von Geodateninfrastrukturen (GDI),<br />
� führend im Bereich der herstellerübergreifenden Nutzung von OGC Web Feature<br />
Services und im Bereich der Verkettung von OGC Web Services (Service Chaining).<br />
Auf der Fachmesse INTERGEO 2003 konnten mit dem hersteller- wie länderübergreifenden<br />
Anwendungsbeispiel „Immobilienbewertung“ demonstriert werden, dass die<br />
OGC-Web-Map-Service-Spezifikation (WMS) eine tragfähige Basis für interoperable<br />
Web-GIS-Auskunftslösungen ist. Im Vergleich zu früheren <strong>Interoperabilität</strong>s-<br />
Untersuchungen des Runden Tisch GIS e.V. konnte zudem gezeigt werden, dass die GI-<br />
Systeme der führenden Hersteller mittlerweile ausgereifte WMS-Schnittstellen besitzen.<br />
Auf der INTERGEO 2004 wurde das Anwendungsbeispiel „Leitungsauskunft aus verteilten<br />
GIS“ präsentiert, das erstmals einen herstellerübergreifenden <strong>Interoperabilität</strong>snachweis<br />
auf Basis der Web Feature Service Spezifikation (WFS) lieferte.<br />
2.2 Anwendungsbeispiel „Leitungsauskunft aus vereilten GIS“<br />
2.2.1 Ausgangssituation<br />
Betreiber von Leitungsnetzen (Energieversorgungs- und Telekommunikationsunternehmen,<br />
Kommunen etc.) sind gesetzlich dazu verpflichtet, Dritten Auskunft darüber<br />
zu geben, ob ihre Leitungen von einer geplanten Baumaßnahme betr<strong>of</strong>fen sind. Bei einem<br />
Energieversorger gehen je nach Größe des Unternehmens mehrere tausend solcher<br />
6.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen I<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
Anfragen pro Jahr ein. Jährlich entstehen durch die Beeinträchtigungen Dritter große<br />
Schadenssummen an den Leitungsnetzen. Daher ist es im Interesse jedes Leitungsbetreibers,<br />
der Auskunftspflicht genüge zu tun [KOPPERSCHMIDT 2004]. Aufgrund<br />
der Vielzahl an Trassen und Sparten sowie der großen Anzahl potenzieller Anwender<br />
birgt die Dienstleistung einer sparten- und unternehmensübergreifenden Leitungsauskunft<br />
ein großes Potenzial (siehe Abb. 2).<br />
Kundenpotenzial<br />
Bürger<br />
Kommunen<br />
Tiefbauämter<br />
Leitungsbetreiber<br />
...<br />
GIS<br />
Dienstleister<br />
Amtliche Geobasisdaten<br />
-Geocodierte Adressen<br />
-ALK, DFK, Orthophotos<br />
Leitungsbetreiber<br />
GIS A<br />
GIS B<br />
GIS . . . C<br />
Gasversorger<br />
Stromversorger<br />
Telekom<br />
Fernwärmeerzeuger<br />
Wasserversorger<br />
Kanalbetreiber<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 6.5<br />
. . .<br />
. . .<br />
. . .<br />
. . .<br />
Grafik modifiziert nach: micus management consulting GmbH<br />
Abb. 2 : Leitungsauskunft aus verteilten GIS als Dienstleistung<br />
Um eine derartige Lösung anbieten zu können, muss ein GIS-Dienstleister Zugriff auf<br />
die Geodaten der Leitungsbetreiber sowie auf amtliche Geobasisdaten haben.<br />
Zwei Hindernisse stellen sich dem GIS-Dienstleister als potenziellem Betreiber einer<br />
derartigen unternehmensübergreifenden Lösung entgegen: Zum einen ist dies die Heterogenität<br />
und Verteiltheit der Geodatenbestände der Leitungsbetreiber, zum <strong>and</strong>eren<br />
sind letztere selten dazu bereit, ihre Geodaten an Dritte abzugeben.<br />
2.2.2 Lösungsansätze<br />
Aus Sicht eines GIS-Dienstleisters gibt es prinzipiell zwei technische Lösungsansätze<br />
um die Verteiltheit und Heterogenität der Geodatenbestände der Leitungsbetreiber zu<br />
überwinden:<br />
� Lösungsansatz A: Datenintegration (Aufbau eines GIS beim Dienstleister, das<br />
Kopien der Daten aller Leitungsbetreiber sowie amtlicher Geobasisdaten enthält),<br />
� Lösungsansatz B: Stellen von Anfragen an verteilte GIS mittels OGC Web Services<br />
(Daten bleiben bei den Leitungsbetreibern, diese geben lediglich Auskunft<br />
über Web Services Schnittstellen nach den Spezifikationen des Open Geospatial<br />
Consortium OGC).<br />
Im Fall einer unternehmensübergreifenden Leitungsauskunft erweist sich der Lösungsansatz<br />
A jedoch aus folgenden Gründen als problematisch:<br />
� Leitungsbetreiber müssen ihre vollständigen Leitungsdaten an den Dienstleister<br />
abgeben.<br />
� Wegen der Heterogenität der Daten und Systeme der Leitungsbetreiber ist eine<br />
Datenintegration teuer und zeitaufwändig.<br />
...
St<strong>and</strong> der Technik, Implementierungen I<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
� Der Dienstleister ist für die Aktualität des integrierten Datenbest<strong>and</strong>s verantwortlich,<br />
was einerseits auf Seiten des Dienstleisters weitere Kosten verursacht<br />
und <strong>and</strong>ererseits auch zu Haftungsproblemen bei Fehlinformationen aufgrund<br />
veralterter Daten führen kann.<br />
Aufgrund dieser Überlegungen beschloss der Verein Runder Tisch GIS im Jahr 2004 auf<br />
Basis seiner OGC Testplattform eine Lösung nach dem Lösungsansatz B, dem Zugriff<br />
auf verteilte GIS mittels OGC Web Services zu entwickeln. Mit diesem Projekt wurden<br />
u.a. folgende Ziele verfolgt:<br />
� Hersteller- und länderübergreifende Nutzung von Auskunftsfunktionalität auf<br />
Basis der OGC Web Feature Service Spezifikation<br />
� Aufzeigen des Potenzials von Geo Web Services mit st<strong>and</strong>ardisierten Schnittstellen<br />
am Beispiel einer innovativen Auskunftslösung.<br />
2.2.3 Einsatz von OGC Web Services für die Leitungsauskunft aus verteilten GIS<br />
Abbildung 3 zeigt die Systemarchitektur und insbesondere den Einsatz der OGC<br />
Schnittstellen Web Map Service (WMS) und Web Feature Service (WFS).<br />
Browser<br />
OGC Web<br />
Map Service<br />
OGC Web<br />
Feature Service<br />
WFS Bridge<br />
Aggregate<br />
Service<br />
Internet-Verbindung<br />
Amtliche Geobasisdaten<br />
-Geocodierte Adressen<br />
-ALK, DFK, Orthophotos<br />
GIS A<br />
GIS B<br />
Strom<br />
Wasser<br />
Abwasser<br />
6.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten<br />
. . .<br />
GIS C<br />
GIS D<br />
GIS E<br />
Gas<br />
Beleuchtung<br />
Abb. 3 : Systemarchitektur<br />
Während die OGC Web Services den lesenden Zugriff auf die verteilten und über das<br />
Internet vernetzten Systeme der Leitungsbetreiber und der Anbieter amtlicher Geobasisdaten<br />
dienen, erfüllt der anwendungsspezifische so genannte Aggregate Service folgende<br />
Aufgaben:<br />
� Benutzereingaben entgegennehmen und in Anfragen an OGC Web Services<br />
(OWS) umformen,<br />
� Ergebnisse eines OGC Web Service in Anfragen an einen <strong>and</strong>eren OWS umformen,<br />
� Ergebnisse mehrerer OWS kombinieren,<br />
� abhängig vom Ergebnis eines OWS den Workflow regelbasiert verzweigen,<br />
� auf den Ausfall und auf Fehlermeldungen von OWS sowie auf Inkonsistenzen in<br />
den Ergebnissen der beteiligten OWS reagieren,<br />
� dem Anwender Zwischenergebnisse bzw. ein Endergebnis präsentieren,<br />
� Verbergen der Komplexität des verteilten Systems vor dem Anwender.<br />
Die folgenden Abbildungen geben den Ablauf einer Anfrage an das System „Leitungsauskunft<br />
aus verteilten GIS“ wieder.
Abb. 4 : Adresseingabe<br />
St<strong>and</strong> der Technik, Implementierungen I<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
Der Anwender erhält eine Eingabemaske für die Adresseingabe vom Aggregate Service<br />
und gibt Strasse, Hausnummer, Postleitzahl, Ort der Schadensstelle bzw. der geplanten<br />
Baumaßnahme ein.<br />
Abb. 5 : Geokodierung<br />
Die vom Anwender ausgewählte Adresse wird vom Aggregate Service an einen so genannten<br />
Geocoding Service (hier ein Web Feature Service, der den Zugriff auf geocodierte<br />
Adressdaten erlaubt) gesendet. Der Geocoding Service w<strong>and</strong>elt die Adresse in<br />
Koordinaten um.<br />
Abb. 6 : Laden der Liegenschaftskarte<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 6.7
St<strong>and</strong> der Technik, Implementierungen I<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
Für den geographischen Ausschnitt der Adresse wird durch einen WMS-Client ein entsprechender<br />
Ausschnitt aus der amtlichen Liegenschaftskarte geladen.<br />
Abb. 7 : Schadensstelle durch Polygon abgrenzen<br />
Der Anwender markiert die Schadensstelle bzw. den Ort einer geplanten Baumaßnahme<br />
durch Einzeichnen eines Polygons auf der Liegenschaftskarte<br />
Abb. 8 : Leitungsanfrage an einzelne Leitungsbetreiber<br />
Das Polygon wird vom Aggregate Service des GIS-Dienstleisters an die einzelnen Systeme<br />
(WFS-Bridges) der Leitungsbetreiber übermittelt. Die WFS-Bridges formulieren die<br />
Anfragen an die Web Feature Services der Leitungsbetreiber (Operation „GetFeature“,<br />
geometrischer Filter „Intersects“ mit Polygon als Argument des Filters), w<strong>and</strong>eln die<br />
Antworten der WFS (GML-Dokumente) in Antworten der Form „Leitungsnetz betr<strong>of</strong>fen“/“Leitungsnetz<br />
nicht betr<strong>of</strong>fen“ um und senden diese an den Aggregate Service des<br />
GIS-Dienstleisters zurück.<br />
Der Aggregate Service des GIS-Dienstleisters fasst die einzelnen Ergebnisse der Anfragen<br />
an die Systeme der Leitungsbetreiber zusammen und sendet das Gesamtergebnis in<br />
Form einer HTML-Seite an den Anwender zurück.<br />
2.3 Zusammenfassung<br />
Das vorgestellte Anwendungsbeispiel „Leitungsauskunft aus verteilten GIS“ zeigt deutlich<br />
das Prinzip, die Vorteile und die technische Machbarkeit von Lösungen auf der Basis<br />
von OGC Web Services zur losen Verknüpfung verteilter Systemkomponenten.<br />
6.8 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Das Prinzip:<br />
St<strong>and</strong> der Technik, Implementierungen I<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
� Verteilte Datenhaltung: Die Daten bleiben verteilt auf die Systeme, mit denen sie<br />
erfasst und gepflegt werden.<br />
� Dienstorientierte Architektur: Die Zusammenarbeit der Systeme funktioniert über<br />
den Aufruf entfernter Operationen, also über das Stellen von Anfragen. Vorrangiges<br />
Ziel der Anfragen ist es nicht, Geodaten zum Anwender zu transferieren,<br />
damit dieser sie analysieren und weiterverarbeiten kann. Vielmehr soll der Anwender<br />
eine Antwort auf seine raumbezogene Fragestellung erhalten (z.B. „Liegt<br />
das Flurstück X in einem Wasserschutzgebiet?“)<br />
� St<strong>and</strong>ardisierte Dienstschnittstellen: Sowohl die Anfragen als auch die Ergebnisse<br />
der Anfragen sind st<strong>and</strong>ardisiert. Dank der st<strong>and</strong>ardisierten Zugriffsschnittstellen<br />
sind die Anfragen an Systeme unterschiedlicher GIS-Hersteller identisch aufgebaut.<br />
Möglicherweise komplexe interne Strukturen der Systeme sowie das konzeptionelle<br />
Datenmodell bleiben vor dem Anwender dank der relativ einfach aufgebauten<br />
Dienstschnittstellen verborgen.<br />
Die Vorteile:<br />
� Einfache Clients: Beim Endanwender müssen weder Geodaten noch GIS-<br />
Funktionalität vorgehalten werden. Die Einstiegshürde zur Nutzung der GIS-<br />
Technologie ist gering. Neue Nutzergruppen für vorh<strong>and</strong>ene Geoinformations-<br />
Ressourcen können so erschlossen werden.<br />
� Geringer Aufw<strong>and</strong> für Betreiber von Auskunftslösungen: Der Betreiber einer<br />
Auskunftslösung spart Zeit und Kosten durch den Entfall der Arbeitsschritte Datenbeschaffung,<br />
Datentransfer, Formatkonvertierung, Datenaufbereitung und Datenpflege.<br />
� Datenaktualität: Der Web-Zugriff auf Geodaten des originären Datenanbieters hat<br />
eine Qualitätssteigerung durch die Nutzung aktueller Daten zur Folge.<br />
� Wiederverwendbarkeit von Komponenten: Einmal im Web veröffentlichte Geo<br />
Web Services sind mehrfach verwendbar. Durch die vielfältigen Kombinationsmöglichkeiten<br />
von Geo Web Services können einmal eingerichtete Geo Web Services<br />
in einer Vielzahl an Lösungen verwendet werden.<br />
3 Grenzen von OGC Web Services<br />
Die aktuellen Grenzen der <strong>Interoperabilität</strong> mittels OGC Web Services zur kombinierten<br />
Nutzung verteilter Geodaten werden im Folgenden dargestellt.<br />
3.1 Grenzen in der Praktikabilität<br />
Bei der Lösung raumbezogener Fragestellungen aus der Praxis mittels verteilten Geodaten<br />
und OGC Web Services zeigten sich folgende, heute noch bestehende Mängel in der<br />
Praktikabilität des Lösungsansatzes:<br />
� Aufw<strong>and</strong> bei der Kombination von OGC Web Services unterschiedlicher Typen:<br />
Sollen OGC Web Services unterschiedlicher Service-Typen (z.B. Gazetteer<br />
Service und Map Service) in einer Service Kette mitein<strong>and</strong>er verknüpft werden, so<br />
kommt es auf die Konsistenz der OGC St<strong>and</strong>ards unterein<strong>and</strong>er an. Hier sind<br />
noch einige Inkonsistenzen festzustellen, die bei der Kombination von OGC Web<br />
Services unterschiedlicher Typen zu einem Mehraufw<strong>and</strong> aufgrund syntaktischer<br />
Umformung bedeuten. Im oben beschriebenen Anwendungsbeispiel „Leitungs-<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 6.9
St<strong>and</strong> der Technik, Implementierungen I<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
auskunft aus verteilten GIS“ werden diese Inkonsistenzen durch Programmieraufw<strong>and</strong><br />
beim Aggregate Service kompensiert.<br />
� Betrachtet man die Konsistenz zwischen den St<strong>and</strong>ards für Web Services der Informatik<br />
und der Geoinformatik, so stellt man fest, dass die momentan gültigen<br />
Versionen der OGC Spezifikationen insbesondere den für Web Services gängigen<br />
SOAP-St<strong>and</strong>ard noch nicht unterstützen, was eine Integration der OGC Web Services<br />
in die allgemeine IT-L<strong>and</strong>schaft behindern könnte.<br />
� Übertragungsrate im Internet: Die Ergebnisse von Anfragen an OGC Web Services<br />
können ein großes Datenvolumen haben (z.B. hochaufgelöste Rasterbilder bei<br />
WMS, GML-Daten bei WFS), so dass bei den heute möglichen Übertragungsraten<br />
die verteilte Datenhaltung und verteilte Verarbeitung nicht immer praktikabel ist.<br />
� Grenzen der Verteiltheit und Modularität: Untersuchungen der TU München<br />
[Donaubauer 2004a] haben gezeigt, dass zur Lösung einer raumbezogenen Fragestellung<br />
auf Basis verteilter Datenhaltung und OGC Web Services im Vergleich<br />
mit dem Zugriff auf einen integrierten Datenbest<strong>and</strong> unter Umständen ein Vielfaches<br />
an Anfragen gestellt werden müssen.<br />
3.2 Grenzen in der Akzeptanz<br />
Die Akzeptanz des Lösungsansatzes in der Praxis, bei GIS-Herstellern wie bei den (potenziellen)<br />
Betreibern von OGC Web Services (z.B. Datenanbieter und Dienstleister) ist<br />
grundlegend dafür, dass ein Nutzen für Anwender entsteht. Erst wenn viele Hersteller<br />
ausgereifte OGC-Schnittstellen für ihre Systeme sowohl auf Server- als auch auf Client-<br />
Seite anbieten und erst wenn die Großkunden der GIS-Hersteller, z.B. die großen Datenproduzenten,<br />
diese Schnittstellen nachfragen und einsetzen, wird es interessant und<br />
wirtschaftlich sinnvoll, den Lösungsansatz für Praxisanwendungen einzusetzen.<br />
Ein Teil der Spezifikationen für OGC Web Services findet heute bereits eine breite Unterstützung<br />
in den Produkten der GIS-Hersteller. Herstellerübergreifende <strong>Interoperabilität</strong><br />
wurde insbesondere für die am häufigsten implementierte, grafikorientierte Spezifikation<br />
WMS mehrfach getestet (vgl. z.B. KUNKEL/TEEGE 2003). Die Praxistauglichkeit<br />
WMS-basierter Lösungen konnte nachgewiesen werden (vgl. SCHILCHER et al.<br />
2004 und WILLKOMM 2004). Die oben beschriebene OGC Testplattform des Runder<br />
Tisch GIS e.V. zeigt, dass zwar auch die WFS-Spezifikation heute bereits von vielen<br />
GIS-Herstellern unterstützt wird, jedoch nur sehr selten vollständig.<br />
Die Umsetzung der OGC Spezifikationen beschränkt sich heute meist auf Auskunft<br />
aus vorh<strong>and</strong>enen Geodatenbanken, also auf den lesenden Zugriff. Die Möglichkeit<br />
des schreibenden Zugriffs, die ein Transactional WFS bietet, wurde nur in sehr wenigen<br />
Fällen umgesetzt. Gründe hierfür sind einerseits in der Komplexität der Umsetzung eines<br />
st<strong>and</strong>ardisierten Schreibzugriffs (Transaktionsmanagement, Abbruch der Verbindung<br />
im Internet usw.) zu suchen, <strong>and</strong>ererseits aber auch in der mangelnden Nachfrage<br />
dieser Funktionalität seitens der potenziellen Betreiber von OGC Web Services.<br />
Generell gibt es immer noch große Bedenken seitens der Datenanbieter als potenziellen<br />
Betreibern von OGC Web Services, einen Zugriff auf ihre Systeme über das Internet zuzulassen.<br />
Dies könnte auch daran liegen, dass die OGC Spezifikation in den Bereichen<br />
Sicherheit und Zugriffskontrolle (Digital Rights Management) noch Lücken aufweisen.<br />
Auch ein St<strong>and</strong>ard für einen Web Service zur Abrechnung von Leistungen befindet<br />
sich noch in der Entwurfsphase.<br />
6.10 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
3.3 Grenzen in der Funktionalität<br />
St<strong>and</strong> der Technik, Implementierungen I<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
Auch wenn die Realisierung von Auskunftslösungen auf Basis von OGC Web Services<br />
heute kein Problem mehr darstellt, so decken die heute verfügbaren OGC Spezifikationen<br />
doch noch nicht alle wichtigen Analysemethoden für Geodatenbanken ab. So<br />
fehlen metrische Anfragen (Fläche, Umfang etc. der geometrischen Eigenschaften von<br />
Geoobjekten) sowie Analysemethoden, bei denen aus vorh<strong>and</strong>enen Mengen von<br />
Geoobjekten neue Geoobjekte gebildet werden (z.B. analytische Flächenverschneidung2).<br />
Die vom OGC spezifizierte Sprache „Filter Encoding“ für die Selektion von<br />
Geoobjekten ist in Ihrer Ausdrucksmächtigkeit verglichen beispielsweise mit SQL beschränkt.<br />
Prinzip des Lösungsansatzes „<strong>Interoperabilität</strong> mittels OGC Web Services“ ist es, komplexe<br />
interne Strukturen von Systemen vor dem Anwender zu verbergen, indem ein<br />
Zugriff auf die Systeme mittels der relativ einfach gehaltenen st<strong>and</strong>ardisierten Zugriffsschnittstellen<br />
ermöglicht wird (vgl. 2.3). Dies ist einerseits ein Vorteil, da der Zugriff auf<br />
Geodaten vereinfacht wird. Andererseits verbergen OGC Web Services so auch das<br />
konzeptionelle Modell, das hinter den Geodaten steckt, obwohl diese Informationen<br />
in bestimmten Fällen nötig wäre, um Daten weiterverarbeiten zu können, die von einem<br />
OGC Web Service geliefert werden. So muss zum Beispiel für komplexere Analysen die<br />
Struktur der einzelnen Geoobjekte und deren Beziehungen unterein<strong>and</strong>er ebenso bekannt<br />
sein, wie die Semantik der Daten – Informationen, die aus einer eindeutigen Beschreibung<br />
des konzeptionellen Modells abgeleitet werden könnten.<br />
4 Fazit und Ausblick<br />
Als Folge der aktuellen Möglichkeiten und Grenzen von OGC Web Services ergeben<br />
sich folgende bevorzugte Einsatzbereiche:<br />
� OGC Web Services eignen sich für das Erstellen von Auskunftslösungen im stationären<br />
und mobilen Internet,<br />
� OGC Web Services sind immer dann zu bevorzugen, wenn Geodatenhaltung und<br />
GIS-Kenntnisse beim Anwender nicht vorh<strong>and</strong>en sind,<br />
� Hohe Anforderungen an Datenaktualität gestellt werden,<br />
� Ad hoc Datenkombination, d.h. schnelle Zusammenführung von Informationen<br />
aus unterschiedlichen Quellen, beispielsweise im Krisen- oder Katastrophenfall<br />
benötigt wird.<br />
Die beiden eingangs erwähnten Lösungsansatze zur Nutzung verteilter, heterogener<br />
Geodaten, OGC Web Services und Modellbasierter Datentransfer, sind Forschungsschwerpunkte<br />
in der Geoinformatik an der TU München (<strong>Interoperabilität</strong> mittels OGC<br />
Web Services) und an der ETH Zürich (Modellbasierter Datentransfer). Beide Hochschulen<br />
betreuen aktuell in Kooperation mit dem Bundesamt für L<strong>and</strong>estopographie,<br />
Swisstopo und dem L<strong>and</strong>esvermessungsamt Baden – Württemberg ein Projekt zum<br />
Thema: Aufbau eines grenzüberschreitenden GIS in der Bodenseeregion Baden-<br />
Württemberg – Schweiz auf der Basis internationaler St<strong>and</strong>ards. Anh<strong>and</strong> des Anwendungsbeispiel<br />
grenzüberschreitende Regionalplanung wird deutlich, wie groß der Bedarf<br />
an der einfachen und schnellen Nutzung der Daten auch ‚jenseits der Grenze’ ist.<br />
2 Die TU München hat einen „Web Spatial Analysis Service“ genannten Dienst in den St<strong>and</strong>ardisierungsprozess<br />
des OGC eingebracht, der dazu beitragen soll, diese Lücke zu schließen (vgl.<br />
DONAUBAUER 2004a).<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 6.11
St<strong>and</strong> der Technik, Implementierungen I<br />
OGC-Lösungen: Möglichkeiten und Grenzen<br />
Die beiden oben genannten Lösungsansätze sollen dabei auf Vorteile und Grenzen hin<br />
untersucht werden. Darüber hinaus soll geklärt werden, wie eine Kombination der beiden<br />
Ansätze funktionieren könnte. Durch eine Verknüpfung dieser beiden Technologien<br />
würde eine, in dieser Ausprägung wohl erstmalige, neue Art von Web Service<br />
entstehen, der die vorh<strong>and</strong>enen Einschränkungen bisheriger OGC Web Services in<br />
Bezug auf modellbasierten Datentransfer aufheben würde. Auf Seiten von INTERLIS<br />
läge der Mehrwert eines solchen Konzeptes in der Integration der OGC Web Service<br />
Technologie.<br />
Der Nutzen den man sich von einer Kombination der beiden Ansätze verspricht, ist<br />
zum einen eine umfassende Erweiterung an Funktionalitäten, die effizientere Arbeitsabläufe<br />
ermöglichen, zum <strong>and</strong>eren lassen sich (intelligente, erweiterte) Web Services gut in<br />
Portallösungen integrieren. Portallösungen wiederum bieten den Vorteil, dass damit<br />
leichter nach geeigneten Web Services gesucht werden kann und diese einfacher zugänglich<br />
gemacht werden. Die angedachte Kombination verspricht darüber hinaus einen<br />
relevanten Beitrag zu regionalen, nationalen und internationalen Geodateninfrastrukturen<br />
zu leisten. Die Nachfrage nach Geodaten kann somit schnell und auf einfache<br />
Weise bedient werden, neue Nutzergruppen für vorh<strong>and</strong>ene Geodaten können so gewonnen<br />
werden.<br />
5 Literatur<br />
� Annen, A.: Geost<strong>and</strong>ards: OpenGeospatial Consortium OGC (GML, WFS, WMS). Vortrag<br />
im Rahmen von <strong>Interoperabilität</strong> für die breite Nutzung von Geoinformation,<br />
Zürich, 2005.<br />
� Donaubauer, A.: Interoperable Nutzung verteilter Geodatenbanken mittels st<strong>and</strong>ardisierter<br />
Geo Web Services, Dissertation an der TU München, 2004, Internet:<br />
http://tumb1.biblio.tu-muenchen.de/publ/diss/bv/2004/donaubauer.html<br />
� Donaubauer, A.; Fischer, F.; Huber, A.; Müller, S.; Plabst, S.; Straub, F.: Leitungsauskunft<br />
aus verteilten GIS. Projektbericht des Runder Tisch GIS e.V., München,<br />
2004. Internet: http://www.rundertischgis.de<br />
� Gnägi, H. R.; Plabst, S.: Modellbasierter Datenaustausch und Geo Web Services im Internet.<br />
In: Schilcher, M. (Hrsg.). Tagungsb<strong>and</strong> zum 9. Münchner Fortbildungsseminar<br />
Geoinformationssysteme, München, 2004.<br />
� Kopperschmidt, W.: Unternehmensprozesse optimieren durch Web-Services am Beispiel<br />
digitaler Planauskunft. In: Schilcher, M. (Hrsg.). Tagungsb<strong>and</strong> zum 9. Münchner<br />
Fortbildungsseminar Geoinformationssysteme, München, 2004.<br />
� Kunkel, T.; Teege, G.; Seuß, R.: Projektbericht zu den Stufen IA und IB des Projektes<br />
„<strong>Interoperabilität</strong> auf der Basis von OpenGIS Web Services – Länderübergreifende Datennutzung<br />
bei verteilten Geodatenbanken und unterschiedlichen Herstellersystemen für das<br />
Anwendungsbeispiel Real Estate“. Runder Tisch GIS e.V., München, 2003.<br />
� Shi, W.: Zum modellbasierten Austausch von Geodaten auf Basis XML. Dissertation an<br />
der Universität der Bundeswehr München, München, 2004<br />
� Schilcher, M. et al.: OGC Web Services zur interoperablen Nutzung verteilter Geodatenbanken<br />
für die Immobilienwirtschaft. In: Bernard, L., Fitzke, J. und R. Wagner (Hrsg.):<br />
Geodateninfrastrukturen. Grundlagen und Anwendungen. Heidelberg, 2004.<br />
� Schilcher, M.; Aumann, G. et al.: Abschlussbericht Forschungsprojekt GeoPortal. München,<br />
2004.<br />
� Willkomm, Ph: <strong>Interoperabilität</strong> auf der Basis von OpenGIS Web-Services Bericht aus<br />
Forschung und Praxis. In: Schilcher, M. (Hrsg.). Tagungsb<strong>and</strong> zum 9. Münchner<br />
Fortbildungsseminar Geoinformationssysteme, München, 2004.<br />
6.12 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Claude Eisenhut<br />
Eisenhut Informatik AG<br />
Rosenweg 14<br />
CH-3303 Jegenstorf<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 31 762 06 62<br />
+41 31 762 06 64<br />
7<br />
ISO-St<strong>and</strong>ards für den Datentransfer<br />
St<strong>and</strong> der Realisierungen / Werkzeuge<br />
Claude Eisenhut, Eisenhut Informatik AG
1 Theorie<br />
1.1 Was für eine <strong>Interoperabilität</strong>?<br />
<strong>Interoperabilität</strong> ist die Zusammenarbeit von Anwendungen in einem <strong>of</strong>fenen System.<br />
Unabhängig von der verwendeten Hardware, den eingesetzten Betriebssystemen, der<br />
verwendeten Netzwerktechnologie und der Realisierung einer Anwendung kann eine<br />
Zusammenarbeit mit <strong>and</strong>eren Anwendungen erfolgen. Dazu ist in der Regel die Einhaltung<br />
gemeinsamer St<strong>and</strong>ards notwendig, aber ohne dass dazu gesonderte Absprachen<br />
zwischen den Anwendungen notwendig sind.<br />
In einem Integrationsprojekt gibt es normalerweise einen Auftraggeber und (innerhalb<br />
des Projektes) eine definierte Anzahl Anwendungen die zusammenarbeiten sollen. Trifft<br />
man innerhalb des Projektes über den St<strong>and</strong>ard hinausgehende Absprachen, hat das auf<br />
die Zusammenarbeit keine negativen Auswirkungen. Die durch die Absprache betr<strong>of</strong>fenen<br />
Anwendungen sind bekannt und im Einflussbereich des Projektes.<br />
Beim Aufbau einer Daten-Infrastruktur sind die Anwendungen, die zusammenarbeiten<br />
sollen, nicht bekannt und/oder ändern sich laufend. Eine über den St<strong>and</strong>ard hinausgehende<br />
Absprache ist darum unmöglich!<br />
Funktionierende, „ausführbare“ St<strong>and</strong>ards, die keine zusätzlichen Absprachen erfordern,<br />
sind darum für <strong>Interoperabilität</strong>, wie sie eine Daten-Infrastruktur benötigt, eine<br />
zwingende Voraussetzung!<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 7.1
St<strong>and</strong> der Technik, Implementierungen I<br />
ISO-St<strong>and</strong>ards für den Datentransfer: St<strong>and</strong> der Realisierungen / Werkzeuge<br />
1.2 Welche ISO-Normen?<br />
Norm Titel St<strong>and</strong> Beschreibung<br />
OMG Unified Modeling Diverse<br />
Kästchendiagramme<br />
UML Language<br />
Versionen. 191xxx<br />
basiert auf UML<br />
1.3<br />
ISO 19103 Conceptual schema DTS Einschränkung von UML +<br />
language<br />
Basisdatentypen wie Text, Zahl,<br />
usw.<br />
ISO 19109 Rules for<br />
DIS Metamodell<br />
applicationschema<br />
(=Modellierungssprache).<br />
Überflüssig, da UML+19103 die<br />
Modellierungssprache definiert!<br />
ISO 19107 Spatial schema IS Geometrie-Datentypen (inkl.<br />
Topologie)<br />
ISO 19108 Temporal schema IS Zeit-Datentypen (inkl. Topologie)<br />
ISO 19111 Spatial referencing by IS Datenmodell für<br />
coordinates<br />
Koordinatenreferenzsysteme<br />
ISO 19112 Spatial referencing by IS Datenmodell für geographische<br />
geographic identifiers<br />
Namen<br />
ISO 19123 Schema for coverage<br />
geometry <strong>and</strong> functions<br />
DIS Coverage-Datentypen<br />
ISO 19115 Metadata IS Datenmodell für Metadaten<br />
ISO 19118 Encoding DIS Definiert, wie man<br />
Kodierungsregeln für den<br />
Datenaustausch definiert. Muss für<br />
<strong>Interoperabilität</strong> zuerst konkret<br />
definiert werden!<br />
W3C<br />
XML<br />
XML 1.0 (selten 1.1) Flexibles Textformat<br />
W3C XML-Schema 1.0 Beschreibungssprache für XML-<br />
XML-<br />
Schema<br />
Dateien<br />
ISO 19136 Geography Markup CD (GML 3.2) Gemeinsame Spezifikation von<br />
Language<br />
OGC und ISO für den<br />
Datentransfer.<br />
WD: Working draft ; CD: Committee draft; DIS/DTS: Draft International St<strong>and</strong>ard/Draft ;<br />
Technical Specification ; FDIS: Final Draft International St<strong>and</strong>ard ; IS: International St<strong>and</strong>ard<br />
7.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Modellierungs<br />
sprache<br />
(UML+19103<br />
(19109))<br />
St<strong>and</strong> der Technik, Implementierungen I<br />
ISO-St<strong>and</strong>ards für den Datentransfer: St<strong>and</strong> der Realisierungen / Werkzeuge<br />
Vordefinierte<br />
Datentypen und<br />
Modelle<br />
(19107, 19108,<br />
19111, 19112,<br />
19115, 19123)<br />
Kodierung<br />
(19118)<br />
GML (19136, XML, XML-Schema)<br />
Kodierungsregeln<br />
(müssen definiert<br />
werden!)<br />
Zusammenhang zwischen den einzelnen ISO-St<strong>and</strong>ards<br />
Applikationsmodell in<br />
UML (z.B. Amtl.<br />
Vermessung)<br />
Konkretes<br />
Transferformat<br />
Anwendung der ISO-St<strong>and</strong>ards ohne GML<br />
Man modelliert mit Hilfe von UML sein Datenmodell, berücksichtigt dabei die Einschränkungen<br />
von 19103 und verwendet die durch 19103, 19107 etc. definierten Basistypen.<br />
Zusätzlich definiert man allgemeine Kodierungsregeln, z.B. wie ein Objekt und<br />
dessen Attributwerte kodiert werden. Dann wendet man die selbst definierten Kodierungsregeln<br />
auf das eigene Datenmodell an, um so das konkrete Transferformat zu erhalten.<br />
Ohne ISO 19136 (GML) müssen für ein konkretes Transferformat zusätzliche Absprachen<br />
gemacht werden!<br />
Anwendung der ISO-St<strong>and</strong>ards mit GML<br />
Man modelliert mit Hilfe von UML sein Datenmodell, berücksichtigt dabei die Einschränkungen<br />
von GML (beinhaltet auch diejenigen von 19103), und verwendet die<br />
durch GML (beinhaltet 19103, 19107, etc.) definierten Basistypen. Dann wendet man die<br />
durch GML definierten Kodierungsregeln auf das eigene Datenmodell an, um so das<br />
konkrete Transferformat zu erhalten. Das Resultat ist ein XML-Schema das den Regeln<br />
von GML entspricht. Für ein konkretes Transferformat sind keine zusätzlichen Absprachen<br />
erforderlich.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 7.3
St<strong>and</strong> der Technik, Implementierungen I<br />
ISO-St<strong>and</strong>ards für den Datentransfer: St<strong>and</strong> der Realisierungen / Werkzeuge<br />
1.3 Verschiedene Modellierungsansätze<br />
Mit dem Aufkommen von GML treffen die folgenden zwei Ansichten aufein<strong>and</strong>er:<br />
� UML-Modell als Visualisierungsmittel; GML-Schema als Norm<br />
� UML-Modell als Norm; GML-Schema als Transferformat<br />
UML-Modell als Visualisierungsmittel; GML-Schema als Norm<br />
Gemäss diesem Ansatz, ist das GML-Schema massgebend und das UML-Modell dient<br />
nur zur Visualisierung der Datenstruktur und evtl. zur Entwicklung des GML-Schemas.<br />
Vorteile dieses Ansatzes:<br />
� Es ist keine Übersetzung des UML-Modells erforderlich, das Schema beschreibt<br />
direkt das Transferformat. Der S<strong>of</strong>tware-Entwickler muss vor allem das Transferformat<br />
während der Realisierung in Gedanken präsent haben.<br />
Nachteile:<br />
� Die Inhaltsstruktur lässt sich nicht von Formattricks unterscheiden.<br />
� Ein <strong>and</strong>eres Transferformat (für dieselben Daten) lässt sich nicht ohne weiteres<br />
herleiten.<br />
� Die in 19136 (Anhang F) definierten Abbildungsregeln von GML nach UML decken<br />
nicht alle möglichen GML-Schemas ab.<br />
UML-Modell als Norm; GML-Schema als Transferformat<br />
Gemäss diesem Ansatz ist das UML-Modell massgebend, und das automatisch hergeleitete<br />
GML-Schema dient nur zum Datentransfer.<br />
Vorteil dieses Ansatzes:<br />
� Es lassen sich auch <strong>and</strong>ere Transferformate herleiten.<br />
� Das UML-Modell beschreibt nur die Inhaltsstruktur, Formattricks fliessen durch<br />
die Kodierungsregeln ein.<br />
Nachteile:<br />
� Bestimmte Möglichkeiten von GML lassen sich nicht ausnützen, da die entsprechenden<br />
Abbildungsregeln von UML nach GML in 19136 (Anhang E) fehlen.<br />
� Für das konkrete Transferformat ist eine Übersetzung des UML-Modells notwendig.<br />
Für den Anwender ist das nur ein Knopfdruck, der S<strong>of</strong>tware-Entwickler<br />
muss aber das UML-Modell, das Transferformat und die Übersetzungsregeln<br />
während der Realisierung in Gedanken präsent haben.<br />
1.4 Beurteilungskriterien<br />
Bei der Auswahl eines Datentransferst<strong>and</strong>ards, sind die folgenden Kriterien zu berücksichtigen.<br />
Je nach Kontext wird man den einen oder <strong>and</strong>eren Faktor höher gewichten.<br />
� Wie sichert man die Daten gegen Verlust wegen heute noch unbekannten technischen<br />
Entwicklungen?<br />
� Wie sichert man die Daten gegen Verlust wegen Personalwechsel?<br />
� Welche Auswirkungen haben Modelländerungen?<br />
� Genügt ein einziges Transferformat oder werden für dieselben Daten verschiedene<br />
Transferformate benötigt?<br />
� Wie prüft der Nutzer, dass er erhalten hat, was er bestellt hat?<br />
7.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen I<br />
ISO-St<strong>and</strong>ards für den Datentransfer: St<strong>and</strong> der Realisierungen / Werkzeuge<br />
� Wie beweist der Produzent, dass er geliefert hat, was er versprochen hat?<br />
� Wie wird die H<strong>and</strong>habung der Daten beim Nutzer vereinfacht?<br />
� Wie wird die H<strong>and</strong>habung der Daten beim Produzenten vereinfacht?<br />
� Wie wird die H<strong>and</strong>habung der Daten beim Daten-Pool/Portal vereinfacht?<br />
� Wie wird das Auslagern von Dienstleistungen rund um die Daten vereinfacht?<br />
� Wie einfach ist die S<strong>of</strong>tware-Entwicklung?<br />
� Funktionieren diese St<strong>and</strong>ards mit grossen Datenmengen?<br />
� Wie wird Mehrsprachigkeit unterstützt?<br />
� Wie werden föderale Organisationsstrukturen unterstützt?<br />
� Sind diese St<strong>and</strong>ards beeinflussbar?<br />
� Welche Anwender und Datennutzer brauchen diese St<strong>and</strong>ards sonst noch?<br />
� Gibt es hier genügend Spezialisten?<br />
� Wie ist die Unterstützung durch St<strong>and</strong>ard-S<strong>of</strong>tware?<br />
2 Praxis/SW-Demo<br />
� Modellieren mit diversen Werkzeugen<br />
� Formatbeschreibung<br />
� Wie sehen die Daten aus?<br />
� Datenprüfung<br />
� Konvertierungswerkzeuge<br />
� Sind die Modellierungskonzepte in den GIS vorh<strong>and</strong>en?<br />
� Werkzeuge für die S<strong>of</strong>twareentwicklung<br />
3 Beurteilung<br />
Die ISO-Normen sind lesbar. Es ist aber aufwendig, einerseits wegen dem Umfang der<br />
einzelnen Normen, <strong>and</strong>ererseits weil sich die relevanten Konzepte über mehrere Normen<br />
verteilen.<br />
Mit entsprechendem Aufw<strong>and</strong> sind die ISO-Normen realisierbar. Der Aufw<strong>and</strong> ergibt<br />
sich dadurch, dass das jeweilige Thema, z.B. geometrische Datentypen, sehr umfassend<br />
definiert wird.<br />
Für <strong>Interoperabilität</strong> sind die ISO-Normen nur beschränkt tauglich. Es gibt zu viele Widersprüche<br />
zwischen den einzelnen Normen und zu <strong>of</strong>t werden abstrakte Ideen definiert,<br />
die sich nicht direkt realisieren lassen. Im Bereich des Datentransfers ist die Norm<br />
19136 (GML) ein erster nützlicher Schritt.<br />
Verbesserungsvorschlag<br />
Statt seit drei Jahren im Projekt 19139 ein Transferformat für Metadaten zu entwickeln,<br />
sollte das TC211 die Kodierungsregeln von 19136 (GML) auf das Metadatenmodell<br />
(19115) anwenden. So hätte man direkt innerhalb des TC211 eine Rückmeldung zur Realisierbarkeit.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 7.5
St<strong>and</strong> der Technik, Implementierungen I<br />
ISO-St<strong>and</strong>ards für den Datentransfer: St<strong>and</strong> der Realisierungen / Werkzeuge<br />
4 Ausblick<br />
Der Kosten/Leistungsdruck bleibt auch in Zukunft bestehen!<br />
Innovative Unternehmen suchen darum nach neuen Einteilungen der Prozessketten.<br />
<strong>Interoperabilität</strong> reduziert die Schnittstellenkosten und ermöglich somit neue Einteilungen.<br />
Datentransfer ist out! Die Zukunft gehört den (Web-)Diensten!<br />
(Web-)Dienste sind nicht für menschliche Benutzer gedacht sondern für Anwendungen,<br />
die automatisiert Daten austauschen und/oder Funktionen auf entfernten Rechnern<br />
aufrufen.<br />
Ohne funktionierenden Datentransfer geht bei Diensten aber gar nichts.<br />
Jeder Funktionsaufruf selbst ist implizit ein Datentransfer. Der Funktionsname und die<br />
aktuellen Funktionsargumente müssen von einem Rechner zum <strong>and</strong>eren transferiert<br />
werden und das Resultat muss wieder zurück.<br />
Braucht es noch INTERLIS?<br />
Das INTERLIS-Transferformat bietet einige Möglichkeiten (inkrementellen Transfer,<br />
mehrsprachige Tags), die GML nicht bietet. Benötigt man diese nicht, kann man ohne<br />
weiteres GML für den Transfer einsetzen. Das Basis-Schema des INTERLIS-<br />
Transferformats ist jedoch wesentlich kleiner, und darum einfacher zu realisieren.<br />
Die Möglichkeiten zur automatischen Datenprüfung sind mit UML/GML (gem. 19136)<br />
verglichen mit INTERLIS armselig. Die Datenbeschreibungsmöglichkeiten sind mit IN-<br />
TERLIS substanziell besser, auf INTERLIS als Beschreibungssprache zu verzichten, wäre<br />
darum ein Rückschritt.<br />
7.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Marc Gilgen<br />
État de Vaud<br />
Département des infrastructures<br />
Service de l’information sur le territoire<br />
Av. de l’Université 3<br />
CH-1014 Lausanne<br />
http://www.dinf.vd.ch/sit<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
8<br />
<strong>Interoperabilität</strong> von Geodaten<br />
Aktueller St<strong>and</strong> und Zukunftsperspektiven im<br />
Kanton Waadt<br />
+41 21 316 34 83<br />
+41 21 316 24 84<br />
Marc Gilgen, État de Vaud<br />
Service de l’information sur le territoire<br />
In Zusammenarbeit mit<br />
S<strong>and</strong>rine Durler, État de Vaud<br />
Lucien Imh<strong>of</strong>, État de Vaud<br />
Bruno Magoni, ASIT-VD
1 Einleitung<br />
Seit mehr als 10 Jahren hat der Kanton Waadt an der <strong>Interoperabilität</strong> im Bereich der<br />
Geodaten gearbeitet. Die Vereinigung für das L<strong>and</strong>informationssystem des Kantons<br />
Waadt (ASIT-VD1), mit ihrem Auftrag einer Plattform für den Datenaustausch, hat frühzeitig<br />
eine Metadatenbank mit einem Katalogisierungsdienst (dem so genannten Géocatalogue)<br />
und einem Online-Bestelldienst aufgebaut. Gleichzeitig hat die kantonale Verwaltung,<br />
wichtiges Mitglied der ASIT-VD, die notwendigen Mittel für ein Geoinformationssystem<br />
innerhalb der kantonalen Verwaltung2 aufgebracht. Diese Infrastruktur und<br />
Organisation haben den Datenaustausch gefördert und weiterentwickelt. Gleichzeitig<br />
sind auch <strong>Interoperabilität</strong>en zwischen Informatik-Applikationen entst<strong>and</strong>en.<br />
Dank des Geoportals der ASIT-VD ist der Kanton Waadt zur Zeit der Hauptlieferant<br />
raumbezogener Daten. Er pr<strong>of</strong>itiert von den Diensten der ASIT-VD im Bereich der Katalogisierung<br />
und der Bestellung und er nutzt sie häufig. Eine Voraussetzung dazu ist eine<br />
zweckmässige technische und organisatorische Infrastruktur innerhalb der kantonalen<br />
Verwaltung. Aus dem technischen St<strong>and</strong>punkt funktioniert das Informationssystem<br />
des Kantons hauptsächlich durch das Prinzip des Datenpools (Datawarehouse), bestehend<br />
aus den spezifischen Datenbanken der verschiedenen Abteilungen. Dieser zentrale<br />
Datenpool ermöglicht es, viele GIS-Applikationen innerhalb des Kantons anzubieten<br />
und <strong>Interoperabilität</strong>en im Bereich der Geodaten zu entwickeln.<br />
2 Aktueller St<strong>and</strong> der Realisierungen<br />
2.1 <strong>Interoperabilität</strong>en im Bereich der Geodaten<br />
Die von der kantonalen Verwaltung und von der ASIT-VD bearbeiteten <strong>Interoperabilität</strong>en<br />
im Bereich der Geodaten können einfach aus einem URL-Link aber auch aus viel<br />
komplexeren Realisierungen bestehen. Untenstehend kommen wir auf die folgenden<br />
<strong>Interoperabilität</strong>en einzeln zu sprechen :<br />
Abfrage von Geodaten in administrativen Applikationen<br />
� Abfrage von geographischen Ebenen für Baubewilligungen<br />
� Kartendienst für Internet-Applikationen<br />
� Online-Bestellung von Geodaten (geographische Objekte auswählen und extrahieren)<br />
Abfrage von administrativen Daten in GIS-Applikationen<br />
� Abfrage von entfernten Datenbanken<br />
� Zugang zu den Metadaten<br />
� Verbindung mit dem Geographischen Datenkatalog der Schweiz<br />
1 http://www.asit.vd.ch<br />
2 http://www.dinf.vd.ch/sit<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 8.1
St<strong>and</strong> der Technik, Implementierungen II<br />
<strong>Interoperabilität</strong> von Geodaten : aktueller St<strong>and</strong> und Zukunftsperspektiven im Kanton Waadt<br />
2.2 Abfrage von geographischen Ebenen für Baubewilligungen<br />
Die kantonale Abteilung, die die Baubewilligungen erteilt (Baubewilligungzentrale3) verfügt über eine Internet-Applikation, die es ermöglicht, verschiedene geographische<br />
Ebenen in der zentralen Datenbank abzufragen. Die Baubewilligung wird unter Berücksichtigung<br />
mehrerer Kriterien erteilt. Die geometrische Dimension in Verbindung mit<br />
der geographischen Lage des zukünftigen Baus spielt in vielen von diesen Kriterien eine<br />
wichtige Rolle. Zudem wird die vom Bau beeinflusste Ausdehnung in der Webapplikation<br />
erfasst, um das Ausmass des zukünftigen Baus möglichst gut zu berücksichtigen.<br />
Die räumliche Abfrage wird auf der Grundlage eines geometrischen Schnitts zwischen<br />
dem zum Ausmass des zukünftigen Baus proportionalen Kreis und den geographischen<br />
Ebenen durchgeführt. Die Resultate werden dann der Internet-Applikation zurückgeschickt.<br />
Diese <strong>Interoperabilität</strong> ermöglicht verschiedene Verifikationen, die ohne einen<br />
solchen automatischen Prozess sehr mühevoll wären.<br />
Eine der Verifikationen betrifft den Namen der Gemeinde. Dieser wird nämlich wie die<br />
geographischen Koordinaten des Baugesuchs manuell eingegeben. Dank der räumlichen<br />
Abfrage wird geprüft, ob die geographische Lage des Baugesuches innerhalb des<br />
Umkreises der Gemeinde liegt.<br />
Die Mehrheit der abgefragten Ebenen werden im Datawarehouse gespeichert. Einige<br />
sind in Dateien gespeichert. Durch diesen Mechanismus können wir die Verträglichkeit<br />
des Baus mit verschiedenen rechtskräftigen mit der Raumplanung verbundenen Einschränkungen<br />
prüfen, insbesondere mit der Bodennutzung, dem Grundwasserschutz,<br />
den Kantons- und Bundesinventaren, den Schutzmassnahmen für die Gebäude (für ein<br />
schon bestehendes Gebäude). Bei einem Interessenskonflikt zwischen einem Baugesuch<br />
und einer Zone eines Inventars beispielsweise, wird der Mechanismus die Abteilungen<br />
erwähnen, die befragt werden müssen, um eine Baubewilligung zu erteilen. Dieser automatisierte<br />
Prozess ermöglicht einer « nicht-geographischen » Applikation einen geographischen<br />
Server abzufragen.<br />
2.3 <strong>Interoperabilität</strong>en des kartografischen Internet-Schalters<br />
Dank des kartografischen Internet-Schalters des Kantons Waadt (GéoPlaNet4) können<br />
die von der kantonalen Verwaltung hergestellten und benutzten Geodaten auf dem Internet<br />
veröffentlicht werden. Dieser Internet-Schalter pr<strong>of</strong>itiert auch von der Integration<br />
der Geodaten in einem einzigen Datenpool. Es gibt ausserdem viele Schnittstellen (unioder<br />
bidirektional) mit <strong>and</strong>eren Applikationen. Zum Beispiel können wir folgende erwähnen<br />
: Schnittstellen mit dem Grundbuch5 (Grundbuchauszüge), mit der Baubewilligungszentrale6<br />
(Visualisierung der Akten), oder auch mit der wirtschaftlichen Förderung7<br />
(Suche nach verfügbarem Gelände).<br />
Die wichtigsten <strong>Interoperabilität</strong>en, die mit dem kartografischen Internet-Schalter verbunden<br />
sind, werden nachfolgend beschrieben. Diese <strong>Interoperabilität</strong>en zeigen schon<br />
das Prinzip, das Interesse und das Potential eines universellen Portals, das die Dienstleistungen<br />
des Kantons durch ein einziges Portal anbietet.<br />
3 http://www.camac.vd.ch<br />
4 http://www.geoplanet.vd.ch<br />
5 http://www.rf.vd.ch<br />
6 http://www.camac.vd.ch<br />
7 http://www.terrains.vd.ch<br />
8.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen II<br />
<strong>Interoperabilität</strong> von Geodaten : aktueller St<strong>and</strong> und Zukunftsperspektiven im Kanton Waadt<br />
2.3.1 Kartendienst für Internet-Applikationen<br />
Für die administrativen Applikationen des Kantons ist die <strong>Interoperabilität</strong> hauptsächlich<br />
beim Kartendienst von Interesse. Dieser von GéoPlaNet geleistete Dienst ermöglicht<br />
Karten in eine <strong>and</strong>ere Applikation dynamisch zu integrieren (einfacher Kartendienst)<br />
oder zur Benutzungsoberfläche des kartografischen Internet-Schalters zu kommen<br />
(Browserkartendienst). Die Lokalisierung wird mit Hilfe von Koordinaten oder mit Hilfe<br />
eines räumlichen Objekts (z.B. eine Parzelle in einer Gemeinde) gemacht. Die Parameter<br />
der Lokalisierung, des Massstabes und des Grösse der Karte, sowohl die Auswahl<br />
der Datenebenen werden über die URL-Adresse übermittelt. Die Applikationen des<br />
Grundbuchs, der Baubewilligungszentrale und der Wirtschaftsförderung benutzen diese<br />
Kartendienste.<br />
2.3.2 Abfrage von entfernten Datenbanken<br />
Umgekehrt ermöglicht der kartografische Internet-Schalter Informationen in entfernten<br />
Datenbanken zu finden. Zum Beispiel derjenigen des Grundbuchs: mit GéoPlaNet kann<br />
der Name des Besitzers einer Liegenschaft angezeigt werden. Diese Information wird<br />
bald mit <strong>and</strong>eren Informationen aus dem Grundbuchauszug ergänzt werden (Beschreibung<br />
des Grundstückes, Eigentum, Grunddienstbarkeiten, usw.). Das zeigt den Vorteil<br />
und die Rolle des kartografischen Internetschalters, um nicht-geografische Informationen<br />
zu erwerben. Dieser Zugang zur Information durch die geografische Dimension<br />
und durch einen einzigen Eingangspunkt ist ein grosser Gewinn für den Benutzer.<br />
2.3.3 Zugang zu den Metadaten<br />
Was die Metadaten betrifft, bietet der kartografische Internet-Schalter einen direkten<br />
Zugang zum Géocatalogue der ASIT-VD8 an, in dem alle Geodaten beschrieben werden.<br />
Es h<strong>and</strong>elt sich hier darum, dass die Koppelung der Daten mit den Metadaten innerhalb<br />
des Visualisierungsdienstes für Geodaten (GéoPlaNet) gewährleistet wird.<br />
2.4 Online-Bestellung von Geodaten<br />
Dank des Portals Géocomm<strong>and</strong>e der ASIT-VD9 können Geodaten auf dem Gebiet des<br />
Kantons Waadt online bestellt werden. Der Benutzer kann seine Daten via Géocatalogue<br />
auswählen und ein Suchgebiet für die Extraktion (Text- oder räumliche Suche) definieren.<br />
Zusätzlich zum Visualisierungsdienst, der benutzt wird, um die Basiskarten darzustellen,<br />
bietet die geografische Auswahl eigentlich einen Auswahldienst durch ein Objekt<br />
an. Die geografischen Objekte, die ausgewählt werden können, sind die Bezirke, die<br />
Gemeinden, die Umkreise der Katasterpläne und die Parzellen. Der Kartenserver ist<br />
derselbe wie derjenige des kartografischen Schalters (MapServer). Diese Auswahl durch<br />
ein Objekt wird durch eine Datenbank PostGIS gemacht.<br />
Sobald das Bestellungsformular ausgefüllt ist, wird es den betr<strong>of</strong>fenen Lieferanten geschickt.<br />
Für die Geodaten des Kantons Waadt wird die Abfrage automatisch verarbeitet:<br />
die Geodaten werden vom Datawarehouse aus dem ausgewählten Umkreis herausgezogen,<br />
dann zum Benutzer durch FTP übermittelt. Die Rechnung wird auch automatisch<br />
gemacht.<br />
8 http://www.asit.vd.ch/geoportal/geocatalog/public.asp<br />
9 http://www.asit.vd.ch/geoportal/geodata/public.asp<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 8.3
St<strong>and</strong> der Technik, Implementierungen II<br />
<strong>Interoperabilität</strong> von Geodaten : aktueller St<strong>and</strong> und Zukunftsperspektiven im Kanton Waadt<br />
Die Verarbeitungskette einer Online-Bestellung besteht aus vielen <strong>Interoperabilität</strong>en<br />
zwischen mehreren Applikationen: um den Bestellungsumkreis zu definieren (Auswahl<br />
von geografischen Objekten) und um die Abfrage zu übermitteln und zu verarbeiten<br />
(Herausziehen von geografischen Objekten).<br />
2.5 Verbindung mit dem Geographischen Datenkatalog der Schweiz<br />
Mit dem neuen Geographischen Datenkatalog der Schweiz10 arbeitet die ASIT-VD wie<br />
ein Partner vom Typus C (der Partner vom Typus A gibt seine Metadaten direkt in die<br />
zentrale Datenbank von geocat ein ; der Partner vom Typus B verfügt über seine eigene<br />
Datenbank aber kopiert seine Metadaten in die zentrale Datenbank ; der Partner vom<br />
Typus C erlaubt einen Zugang zu seiner Datenbank durch geocat ohne Duplizierung).<br />
Die ASIT-VD verfügt nämlich über seine eigene Metadatenbank, die geocat abfragen<br />
kann. Zu diesem Zweck wurde ein Abfrageprotokoll (Catalog Gateway Protocol) auf<br />
Bundesebene entwickelt und in die Applikation von der ASIT-VD eingebaut. Auf dieser<br />
Weise kann die ASIT-VD die Abfragen von geocat bekommen und verarbeiten, und<br />
dann eine Antwort zurückschicken, die der Struktur und dem Format von geocat entspricht.<br />
Diese <strong>Interoperabilität</strong> ist die erste konkrete Realisierung in die Richtung eines<br />
Schweizer Suchportals für Geodaten mit einem dezentralisierten Katalog.<br />
Die <strong>Interoperabilität</strong> zwischen geocat und dem Géocatalogue der ASIT-VD zeigt die<br />
Notwendigkeit, über gemeinsame Datenmodelle zu verfügen. Das Metadatenmodell<br />
GM03Core muss mindestens in jedem Metadatensystem implementiert werden. Auf der<br />
Basis von GM03Core werden die minimalen Metadaten ausgetauscht. Die ASIT-VD hat<br />
deswegen den Géocatalogue angepasst, um mit dem Schweizer Metadatenmodell<br />
GM03Core in Übereinstimmung zu sein. Alle obligatorische Metadaten von GM03Core<br />
können im Géocatalogue gefunden und dank geocat visualisiert werden.<br />
Die technischen Entwicklungen, die die <strong>Interoperabilität</strong> fördern, müssen von Bemühungen<br />
in <strong>and</strong>eren Bereichen begleitet werden. Hier müssen die Bemühungen erwähnt<br />
werden, um st<strong>and</strong>ardisierte Datenmodelle und Vorgehen für Geodatenaustausch zwischen<br />
den Partnern anzunehmen oder auszuarbeiten. Zu diesem Zweck arbeiten die<br />
kantonale Verwaltung und die ASIT-VD zusammen. Erste Schritte im Bereich der generellen<br />
Entwässerungspläne (GEP11) sind erfolgreich gewesen. Jetzt wird etwas im Bereich<br />
der Raumplanung unternommen, um den Austausch der Daten für die Bodennutzung<br />
zu vereinheitlichen.<br />
3 Perspektive<br />
3.1 Webdienst über Raumgliederungen<br />
Demnächst wird der Kanton einen Webdienst über die Raumgliederungen aufstellen.<br />
Zuerst werden der Kanton, die Bezirke, die Gemeinden, die Katasterpläne und die Parzellen<br />
betr<strong>of</strong>fen sein. Dieser Dienst gibt die Möglichkeit, Informationen über die Einheiten<br />
der vorher genannten Raumgliederungen (z.B. Bundesnummer und Name der Gemeinden)<br />
und über die Zusammensetzung und die Zugehörigkeit der Einheiten einer<br />
Raumgliederung in Beziehung mit den <strong>and</strong>eren Raumgliederungen (z.B. Nummer aller<br />
10 http://www.geocat.ch<br />
11 http://www.dse.vd.ch/eaux/assainissement/eaux/pgee.htm und<br />
http://www.asit.vd.ch/documentation/comm<strong>and</strong>.asp<br />
8.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen II<br />
<strong>Interoperabilität</strong> von Geodaten : aktueller St<strong>and</strong> und Zukunftsperspektiven im Kanton Waadt<br />
Parzellen und aller Katasterpläne, die einer Gemeinde gehören) in einer St<strong>and</strong>ardform<br />
und im Format XML zu übermitteln.<br />
Dieser Dienst wird vor allem beim Bestellungs- und Vertriebsvorgehen der Geodaten<br />
benutzt. Dieser Webdienst ist unabhängig von jeder Applikation und er wird dennoch<br />
später für <strong>and</strong>ere Bereiche benutzt werden können. Die Vorteile eines solchen Dienstes<br />
sind klar: die Aktualisierung der Datenbanken ist automatisch bei Veränderungen, wie<br />
z.B. bei den Fusionen von Gemeinden oder bei der Einführung von neuen Vermessungslosen.<br />
Im Vergleich brauchen die traditionellen Methoden der Aktualisierung viel<br />
Zeit, in Anbetracht der vielen Applikationen, die diese Informationen benutzen.<br />
Mit diesem Dienst wird auch die Aktualisierung der Postleitzahlen (PLZ) und der Orte<br />
in jeder betr<strong>of</strong>fenen Applikationen vorgesehen. Die PLZ wechseln regelmässig und<br />
werden mehrmals im Jahr aktualisiert12. 3.2 Geschützter Kartendienst<br />
Die ASIT-VD und der Kanton entwickeln und testen jetzt einen geschützten Kartendienst,<br />
der sich auf die OpenGIS Spezifikationen13 beruht. Im ersten Schritt wird die<br />
Spezifikation Web Map Service (WMS) implementiert, damit die Karten in Bildform geliefert<br />
werden. Der Zugang wird mit einem Benutzernamen und einem Passwort geschützt.<br />
Es gibt zwei Hauptziele:<br />
� Den Datenvertrieb mit einem direkten Zugang auf Daten durch den St<strong>and</strong>ard<br />
WMS ergänzen. Die Benutzung von WMS gibt jeder Applikation, die als WMS-<br />
Klient funktioniert, die Möglichkeit, Abfragen zu schicken und die zurückgeschickten<br />
Karten direkt in die Benutzungsoberfläche des Klienten zu integrieren.<br />
Die hier betr<strong>of</strong>fenen Applikationen sind besonders die GIS- und die Web-<br />
Applikationen. Folglich sind die betr<strong>of</strong>fenen Benutzer Fachleute der Vermessung,<br />
der Umwelt, der Raumplanung (usw.) aber auch zum Beispiel die Gemeinden.<br />
Im Bereich vom GIS bieten immer mehr S<strong>of</strong>twareprodukte – sowohl<br />
kommerzielle Produkte (z.B. MapInfo, ArcGIS) sowie "free" Programme (z.B.<br />
JUMP) – WMS-Klientfunktionalitäten. Die Zugangskontrolle ermöglicht es, die<br />
Identität des Benutzers zu erkennen und auch ein Rechnungssystem für diesen<br />
Direktzugangdienst zu definieren.<br />
� Einen zentralen kartografischen Schalterdienst (waadtländisches Portal) anbieten.<br />
Er wird vor allem den öffentlichen Verwaltungen angeboten unter der Bedingung,<br />
dass der Geodatenlieferant über einen Server verfügt, der WMS-<br />
Abfragen beantworten und Bilder, die diesem St<strong>and</strong>ard entsprechen, liefern<br />
kann. Der einzige kartografische Schalter, der von der ASIT-VD beherbergt und<br />
unterhalten wird, wird als WMS-Klient funktionieren und wird die Visualisierung<br />
von Geodaten von mehreren Lieferanten ermöglichen. Wir haben als Ziel,<br />
dass die Daten der kantonalen Verwaltung und die von den Gemeinden gegebenen<br />
Daten zusammen gelegt sind.<br />
Dieser geschützte Dienst wird zuerst die <strong>Interoperabilität</strong> nur im Bereich der Geodaten<br />
ermöglichen. Dann wollen wir die Entwicklungen in Richtung <strong>Interoperabilität</strong> der<br />
12 http://www.poste.ch/yellowbox<br />
13 http://www.opengeospatial.org<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 8.5
St<strong>and</strong> der Technik, Implementierungen II<br />
<strong>Interoperabilität</strong> von Geodaten : aktueller St<strong>and</strong> und Zukunftsperspektiven im Kanton Waadt<br />
Funktionalitäten orientieren. Das heisst, dass der Zugang zu Funktionalitäten der Applikation<br />
des Lieferanten durch den zentralen Schalter und auch von irgendwelchen<br />
Klienten möglich sein wird. Es ist klar, dass die Aufstellung einer solchen <strong>Interoperabilität</strong><br />
nur möglich ist, wenn Funktionalitäten in Form von Webdiensten entwickelt werden.<br />
Für die kantonale Verwaltung sind diese Perspektive nicht nur technische Ziele und<br />
Herausforderungen, sondern auch strategische. Die Aufstellung von solchen <strong>Interoperabilität</strong>en<br />
wird nämlich den Geodatenvertrieb, ihre Tarifgestaltung, ihre Verwaltung<br />
und ihre Aktualisierung (verteilte Kosten, gemeinsame Infrastrukturen) beeinflussen.<br />
4 Schlussfolgerungen<br />
Die <strong>Interoperabilität</strong> im Bereich der Geodaten spielt eine wichtige Rolle. Im Kanton<br />
Waadt können wir nach den realisierten Entwicklungen in diesem Bereich Folgendes<br />
bemerken:<br />
� Die <strong>Interoperabilität</strong> bietet technische Lösungen für organisatorische Probleme<br />
an (z.B. den Abfragedienst der geografischen Ebenen).<br />
� Dank der <strong>Interoperabilität</strong> wird Zeit und Geld gewonnen durch die Rationalisierung<br />
der Aufgaben, die mit der Erwerbung, der Verwaltung, der Aktualisierung,<br />
der Veröffentlichung und dem Vertrieb der Geodaten verbunden sind (z.B. dank<br />
eines Online-Bestellungsdienstes der Geodaten).<br />
� Die <strong>Interoperabilität</strong> unterstützt die Förderung und die Benutzung der Geodaten<br />
in Bereichen, die an Geomatik wenig oder nicht gewohnt sind (z.B. dank des<br />
Kartendienstes, der durch einen kartografischen Schalter verfügbar ist).<br />
� Die <strong>Interoperabilität</strong> erhöht die Zuverlässigkeit der Daten : wir vermeiden mehrfache<br />
Kopien, die Aktualisierung wird schneller gemacht, das Speichersystem<br />
wird nicht mehr so viel belastet und die Bemühungen für die Verwaltung der<br />
Geodaten sind nicht mehr so gross (z.B. dank des Informationsdienstes über die<br />
Raumgliederungen).<br />
8.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Ueli Forrer<br />
F+P GEOINFO AG<br />
Geoinformatik und Vermessung<br />
Kasernenstrasse 69<br />
CH-9100 Herisau<br />
http://www.geoinfo.ch<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 71 353 53 53<br />
+41 71 353 53 50<br />
9<br />
Die Komplexität der <strong>Interoperabilität</strong><br />
Ein einfacher Praxisbericht aus der<br />
Ostschweiz<br />
Ueli Forrer, F+P GEOINFO AG
1 Einleitung<br />
<strong>Interoperabilität</strong> ist für uns als GIS-Dienstleistungsunternehmen ein sehr aktuelles<br />
Thema und langfristig betrachtet, wird <strong>Interoperabilität</strong> zu einer Überlebensfrage solcher<br />
Unternehmen werden. Wenn wir uns mit Definitionen von <strong>Interoperabilität</strong> ausein<strong>and</strong>er<br />
setzen, geraten wir direkt zur Frage der Systemabgrenzung. In unserem System,<br />
einer regionalen Geodateninfrastruktur, können wir zur Zeit <strong>Interoperabilität</strong> in<br />
diversen Teilsystemen finden.<br />
1.1 Definitionen zur <strong>Interoperabilität</strong><br />
<strong>Interoperabilität</strong> wird in der Literatur unterschiedlich definiert. Wir beschränken uns in<br />
der Folge auf zwei unterschiedliche, jedoch sinngleiche Definitionen 1:<br />
1. Als <strong>Interoperabilität</strong> bezeichnet man die Fähigkeit zur Zusammenarbeit von verschiedenen<br />
Systemen, Techniken oder Organisationen. Dazu ist in der Regel<br />
die Einhaltung gemeinsamer St<strong>and</strong>ards notwendig. Wenn zwei Systeme mitein<strong>and</strong>er<br />
vereinbar sind, nennt man sie auch kompatibel.<br />
2. <strong>Interoperabilität</strong> ist die Fähigkeit unabhängiger, heterogener Systeme möglichst<br />
nahtlos zusammen zu arbeiten, um Informationen auf effiziente und verwertbare<br />
Art und Weise auszutauschen bzw. dem Benutzer zur Verfügung zu stellen,<br />
ohne dass dazu gesonderte Absprachen zwischen den Systemen notwendig sind.<br />
1.2 Systemabgrenzung<br />
Wenn aus der ersten Definition <strong>Interoperabilität</strong> als die Fähigkeit zur Zusammenarbeit<br />
von verschiedenen Systemen, Techniken oder Organisationen bezeichnet wird, dann<br />
lässt sich daraus logischerweise ableiten, dass die <strong>Interoperabilität</strong> vor allem auch eine<br />
Frage der Systemabgrenzung ist, egal ob es sich dabei um eine technische oder organisatorische<br />
Abgrenzung des Systems h<strong>and</strong>elt.<br />
2 <strong>Interoperabilität</strong> am Beispiel der IG GIS AG<br />
In der Ostschweiz haben sich die Kantone Appenzell A.Rh., Appenzell I.Rh. und St. Gallen<br />
und sowie ca. 60 Gemeinden (Bezirke im Kanton AI) zu einer Interessengemeinschaft<br />
GIS, der IG GIS AG zusammengeschlossen. Das eigentliche Betreiben des GIS ist<br />
in diesen Kantonen und Gemeinden teilweise bereits seit 1997 aus der Verwaltung ausgelagert<br />
und einem privaten Betreiber, der F+P GEOINFO AG übertragen worden. Die<br />
IG GIS AG hat einen rein koordinativen Charakter und bündelt die Interessen der Aktionäre<br />
(Gemeinden, Bezirke und Kantone) gegenüber dem GIS-Betreiber. Die Geschäftsführung<br />
(50% Stelle) der IG GIS AG ist dem Dienst für Informatikplanung des Kantons<br />
St. Gallen angegliedert.<br />
2.1 Gesamtsystem<br />
Wenn wir den heutigen St<strong>and</strong> der Architektur des Gesamtsystems betrachten, dann<br />
wird es relativ schwierig über <strong>Interoperabilität</strong> des Gesamtsystems zu berichten, weil<br />
das System sehr gross ist. Das Rechenzentrum der IG GIS AG ist zudem einerseits in<br />
das Rechenzentrum des Kantons St. Gallen (Abraxas Informatik AG) und <strong>and</strong>ererseits<br />
1 Quelle: http://de.wikipedia.org<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 9.1
St<strong>and</strong> der Technik, Implementierungen II<br />
Die Komplexität der <strong>Interoperabilität</strong>: ein einfacher Praxisbericht aus der Ostschweiz<br />
komplett in die Informatikstrukturen der <strong>and</strong>eren Kantone und Gemeinden eingebettet.<br />
Abbildung 1 zeigt die stark vereinfachte Architektur des RZ der IG GIS AG als Gesamtsystem:<br />
Abbildung 1<br />
Auf Grund der Grösse der IG GIS AG - drei Kantone und rund sechzig Gemeinden –<br />
können wir von einer regionalen Geodateninfrastruktur (RGDI) sprechen. Suchen wir<br />
in dieser Organisation <strong>Interoperabilität</strong>, dann finden wir diese in vielen, einzelnen Teilsystemen.<br />
Betrachten wir die „Aussenbeziehungen“ dieser<br />
Organisation, nämlich die vielen Datenlieferanten, <strong>and</strong>ere<br />
RGDI’s, die künftige NGDI (Nationale<br />
Geodateninfrastruktur) oder gar eine europäische<br />
Abbildung 2<br />
Organisation, welche eine Geodateninfrastruktur betreibt,<br />
dann denke ich ganz intuitiv an den Turmbau zu Babel.<br />
Gemäss der oben erwähnten Definition von <strong>Interoperabilität</strong><br />
müssen nun nämlich alle diese Organisationen „Informationen<br />
auf effiziente und verwertbare Art und Weise austauschen<br />
bzw. dem Benutzer zur Verfügung stellen, ohne dass dazu<br />
gesonderte Absprachen zwischen den Systemen notwendig sind.“<br />
Dazu müssten diese nicht nur hunderte von technischen<br />
St<strong>and</strong>ards und Normen einhalten, sie müssten auch in ihren<br />
betriebswirtschaftlichen Abläufen und Organisationsformen<br />
interoperabel oder kompatibel werden. Davon sind wir noch weit entfernt. Und wie<br />
beim Turmbau von Babel sind es die verschiedenen Sprachen die uns manchmal zur<br />
Verzweiflung bringen: So spricht der Ingenieur, welcher Fachdaten für eine Gemeinde<br />
9.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen II<br />
Die Komplexität der <strong>Interoperabilität</strong>: ein einfacher Praxisbericht aus der Ostschweiz<br />
erfasst, eine <strong>and</strong>ere Sprache als der Informatiker, der eine regionale Geodateninfrastruktur<br />
betreibt.<br />
Dieses Grundprinzip „der verschiedenen Sprachen“ in Bezug auf <strong>Interoperabilität</strong> lässt<br />
sich sehr einfach nachprüfen: Sucht man im Internet nach dem Wort „<strong>Interoperabilität</strong>“,<br />
zeigen viele Links auf Hilfsorganisationen. Auch dort treffen verschiedenste Organisationen,<br />
Sprachen, Techniken und Kulturen aufein<strong>and</strong>er.<br />
Im Folgenden ziehe ich die Systemgrenzen enger und fokussiere auf das Gesamtsystem<br />
IG GIS. Zwecks besserer Übersicht teile ich das Gesamtsystem in drei Teile auf:<br />
� Daten<br />
� Applikationslogik<br />
� Präsentation der Daten<br />
Weitere Teilsysteme wären noch:<br />
� Systemplattformen<br />
� Betriebssysteme<br />
� Netzwerke<br />
� Weitere Organisationsprozesse<br />
2.2 Teilsystem „Daten“<br />
2.2.1 St<strong>and</strong> Heute<br />
Betrachten wir das Teilsystem „Daten“, dann stechen in dieser Lösung die heterogenen<br />
Strukturen der Ostschweiz s<strong>of</strong>ort ins Auge. Kleinere Gemeinden (mit bis ca. 4500 Einwohner)<br />
mit bis zu 17<br />
verschiedenen, eigenständigen<br />
Korporationen sind<br />
keine Seltenheit.<br />
Dabei ist natürlich<br />
jede Korporation ihr<br />
eigener Datenherr<br />
und bestimmt<br />
autonom, wer auf ihre<br />
Daten Zugriff hat.<br />
Heute liefern 64 verschiedene Datenlieferanten, 178 Datenthemen (ein Thema ist z.B.<br />
die amtliche Vermessung (AV), der Leitungskataster Abwasser, usw.), in 609 Arten von<br />
Datensätzen (eine Datensatzart ist dabei z.B. die Ebene Liegenschaften in der AV), und<br />
15 verschiedenen Datenformaten an. Davon sind gerade einmal 9 Datensätze in IN-<br />
TERLIS I beschrieben und durch die Kantone2, den SIA3 Abbildung 3<br />
oder <strong>and</strong>ere Fachverbände<br />
normiert. Nur die Daten welche in INTERLIS I angeliefert werden, sind interoperabel.<br />
Wenn wir die 609 Arten von Datensätzen auf die geografischen Gebiete, also z.B. die<br />
einzelnen Gemeinden (AV-Liegenschaften der Gemeinde X, AV-Liegenschaften der<br />
Gemeinde Y, usw.) aufteilen, dann sind es 10'606 einzelne Datensätze. Wir betreiben<br />
und organisieren also eine ganze Menge Schnittstellen und wenden viel Zeit für Qualitätskontrollen<br />
auf. Und - es funktioniert sehr gut!<br />
2 Im Kanton SG die Geodatenkonferenz und im Kanton AR der GIS-Ausschuss AR<br />
3 Schweizerischer Ingenieur- und Architektenverein<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 9.3
St<strong>and</strong> der Technik, Implementierungen II<br />
Die Komplexität der <strong>Interoperabilität</strong>: ein einfacher Praxisbericht aus der Ostschweiz<br />
Im RZ der IG GIS halten wir sehr viele Daten auf einem RDMS4. Das sind Benutzerdaten,<br />
Benutzerrechte, Sichtendefinitionen usw. welche allerdings eher der Applikationslogik<br />
zugehören, ein klarer Trennungsstrich ist hier nicht möglich. Die grafischen Daten<br />
liegen immer noch in einem proprietären Format. Dies ist bei unseren grossen Datenmengen<br />
– leider – immer noch eine Frage der Systemperformance.<br />
Innerhalb des RZ des Kantons St. Gallen und über das Intranet der Kantone AR und AI,<br />
haben wir unterschiedliche Direktzugriffe in die Datenbestände <strong>and</strong>erer RDBMS realisiert.<br />
Gesamthaft sind heute 22 weitere Datenbanken (Fremddatenbanken) direkt an<br />
die Daten der IG GIS angebunden. Das heisst, dass der Nutzer direkt über sein GIS auf<br />
diese Datenbanken zugreift. Diese Einbettung in die vorh<strong>and</strong>enen IT-Strukturen zeugt<br />
wiederum von <strong>Interoperabilität</strong>.<br />
Zu dieser Auslegeordnung im Teilsystem Daten gehören zudem weitere, sehr wesentliche<br />
Aspekte:<br />
Die Darstellung der Daten, die dazu gehörenden Legenden, die rechtlichen Hinweise<br />
und der Aktualitätsst<strong>and</strong> spielen bei den Nutzern eine nicht zu unterschätzende Rolle.<br />
Wir führen über alle Datenbestände umfassende Metadaten, welche auf dem RDBMS<br />
abgelegt und bereits heute in einer Form vorh<strong>and</strong>en sind, die einen interoperablen Austausch<br />
mit Fremdsystemen zulässt.<br />
2.2.2 Aussichten<br />
In der Datennormierung warten wir auf St<strong>and</strong>ards der verschiedensten internationalen,<br />
nationalen und regionalen Gremien.<br />
Im Teilsystem Daten sehen wir für die Zukunft eine zentrale Datenverwaltung auf der<br />
Basis eines Geodatenservers mit einer RDBMS. Unsere Versuche, mit verschiedenen<br />
Applikationen auf einen Geodatenserver zuzugreifen, zeigen, dass bereits die Interpretationen<br />
simpler geometrischer Datentypen Fragen aufwerfen. Erschwerend kommt die<br />
produkteabhängige Darstellung der Daten dazu.<br />
Beim Datenaustausch und der Darstellung der Daten setzen wir auf INTERLIS II, wobei<br />
die Marktakzeptanz bei unseren Datenlieferanten aus heutiger Sicht teilweise doch<br />
sehr fraglich ist. In Frage kommt hier auch der internationale St<strong>and</strong>ard, nämlich GML3.<br />
4 Relationales Datenbank Managementsystem<br />
9.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen II<br />
Die Komplexität der <strong>Interoperabilität</strong>: ein einfacher Praxisbericht aus der Ostschweiz<br />
2.3 Teilsystem „Applikationslogik“<br />
2.3.1 St<strong>and</strong> Heute<br />
Wir betreiben einerseits verwaltungsintern Applikationen auf der Basis eines Desktop-<br />
GIS und verschiedene Web-Applikationen im Intranet, <strong>and</strong>ererseits öffentlich im Internet<br />
verschiedene Produkte wie z.B. das www.geoportal.ch. Der umfassende Teil unserer<br />
Applikationslogik liegt immer<br />
noch in den einzelnen Applikationen,<br />
ein kleiner Teil<br />
Abbildung 4<br />
auf dem RDBMS. In diesem<br />
Punkt ist <strong>Interoperabilität</strong> nicht<br />
gegeben.<br />
Wie im Teilsystem Daten bereits erwähnt, sehen wir im Bereich der Applikationslogik<br />
folgende wesentlichen und erwähnenswerten Punkte:<br />
� Wir betreiben eine sehr umfassende Benutzerverwaltung mit entsprechenden Vertragsregelungen<br />
und Zugriffsrechten. 907 registrierte Benutzer in 128 Benutzergruppen<br />
greifen verwaltungsintern geordnet auf unsere Datenbestände.<br />
� Wir legen unsere umfassende Datenbestände in Strukturen ab, dabei wenden wir<br />
folgende Ordnung an:<br />
� Kategorien<br />
� Bereiche<br />
� Themen<br />
� Datensätze<br />
� Um den Nutzern die Arbeit zu erleichtern, stellen wir ihnen Daten in den gewohnten<br />
Karten zur Verfügung. Karten sind dabei vordefinierte Kombinationen<br />
von Datensätzen oder definierte Sichten.<br />
� Wir haben zunehmend Datensätze, welche auch über ein Regelwerk definiert sind<br />
(z.B. Gewässernetze inkl. Kilometrierungen und Routenbildungen, Flächentopologien<br />
usw.).<br />
2.3.2 Aussichten<br />
In Bezug auf <strong>Interoperabilität</strong> innerhalb der Applikationslogik ist die Entwicklung aus<br />
der Informatik bereits vorgezeichnet: .net, COM, GML/XML usw. werden die künftigen<br />
Applikationen interoperabler gestalten.<br />
In Bezug auf die Daten-Zugriffsrechte ist eine echte <strong>Interoperabilität</strong> vermutlich sehr<br />
fraglich und nicht sinnvoll.<br />
Datenstrukturen (in der Form der oben erwähnten Gliederungen), vordefinierte Daten-<br />
Sichten usw. sind heute bereits in einem RDBMS abgelegt und sind im technischen Sinne<br />
bereits interoperabel.<br />
Mit INTERLIS II können wir künftig die Definition von Regeln zu den Daten interoperabel<br />
beschreiben. Die Regelwerke selber sind möglichst mit den Daten in einem<br />
RDBMS abzulegen.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 9.5
St<strong>and</strong> der Technik, Implementierungen II<br />
Die Komplexität der <strong>Interoperabilität</strong>: ein einfacher Praxisbericht aus der Ostschweiz<br />
2.4 Teilsystem „Präsentation“<br />
2.4.1 St<strong>and</strong> Heute<br />
Im Teilsystem Präsentation sind verschiedenste St<strong>and</strong>ards und Normierungen schon<br />
vorh<strong>and</strong>en. Z.B. verteilen wir verwaltungsintern in den Geoportalen für Betrachter<br />
(6000 bis 7500 Arbeitssitzungen pro Monat) und öffentlich im Internet (10’000 bis<br />
14’000 Arbeitssitzungen pro Monat) über http schon heute Daten auf verschiedenste<br />
Betriebssysteme. Ebenso leben wir beim Betrieb der Geoportale für Anwender (230 registrierte<br />
Benutzer) über die Metaframe/Citrix-Umgebung eine spezielle Art von <strong>Interoperabilität</strong><br />
über die Betriebsystemgrenzen hinweg.<br />
Abbildung 5<br />
Mit der heute verfügbaren Technik, insbesondere von WMS 5 und WFS 6, wäre eine weitere<br />
<strong>Interoperabilität</strong> (auch aus den proprietären Daten heraus) bereits möglich, wird<br />
aber wegen der Zugriffsrechte noch nicht angewendet. Die Anwendung von WMS ist<br />
deshalb zur Zeit nur für die öffentlichen Daten im Internet sinnvoll.<br />
2.4.2 Aussichten<br />
In diesem Teilsystem sehen wir die künftige Anwendung von diversen Web Servicen als<br />
sinnvolle Möglichkeit für die frei verfügbaren Daten im Internet:<br />
� WMS (Web Map Service)<br />
� WFS (Web Feature Service)<br />
� WCS (Web Coverage Service)<br />
� WCAS (Web Catalog Service)<br />
� WCTS (Web Coordinate Transformation Service)<br />
� Weitere Web Services<br />
Zur Zeit steht für unsere Anwendungen sicherlich der WMS (Web Map Service) im<br />
Vordergrund, da „fremde“ Institutionen Daten betrachten und drucken aber nicht in<br />
Vektorform beziehen können. Jedenfalls wäre das im Sinne vieler Datenherren, die insbesondere<br />
im Verwaltungsumfeld die Daten zum Betrachten und Drucken freigeben.<br />
5 Web Map Service<br />
6 Web Feature Service<br />
9.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
3 Fazit<br />
St<strong>and</strong> der Technik, Implementierungen II<br />
Die Komplexität der <strong>Interoperabilität</strong>: ein einfacher Praxisbericht aus der Ostschweiz<br />
In einer Organisationsstruktur für regionale Geodaten, wie derjenigen der IG GIS AG<br />
sind in verschiedensten Teilbereichen Ansätze zu einer <strong>Interoperabilität</strong> vorh<strong>and</strong>en.<br />
Diese Ansätze sind heute noch sehr technisch, vielschichtig und betreffen sehr verschiedene,<br />
spezielle Fachbereiche aus der Informatik und der Geoinformationsbranche.<br />
Von einer echten <strong>Interoperabilität</strong>, also einer <strong>Interoperabilität</strong> von Organisationen von<br />
regionalen und nationalen Geodatenstrukturen sind wir unseres Erachtens noch weit<br />
entfernt.<br />
Je grösser wir die Systemabgrenzung ziehen, desto komplexer wird die <strong>Interoperabilität</strong><br />
und umso mehr verlagert sich diese weg von Systemen und der Technik auf die<br />
Organisationen und deren Prozesse.<br />
4 Literatur<br />
INSPIRE. 2003. Spatial Data Infrastructure in Europe. Spatial Application Division<br />
K.U. Leuven, Research & Development<br />
Ott, Mathias. Datenaustausch und <strong>Interoperabilität</strong>, Dienste für eine <strong>of</strong>fene<br />
Geodatenstruktur,<br />
www.ikg.uni-bonn.de/Lehre/Geoinfo/is_iv_SS_04/Vorträge%5C04_05_27_Ott.ppt<br />
Open GIS Consortium. OpenGIS Service Architecture<br />
SOGI. 2003. Worin liegt der praktische Nutzen von <strong>Interoperabilität</strong> und Normung für den<br />
GIS-Anwender in der Schweiz?” Schweizerische<br />
Organisation für Geoinformation, Bericht der Fachgruppe GIS Technik<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 9.7
Jean-Claude Jasselette<br />
MET (D.432) Topographie et Cartographie<br />
CAMET - Boulevard du Nord, 8<br />
B-5000 Namur<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+32 817 733 51<br />
+32 817 738 88<br />
10<br />
Modellbasierte und interoperable<br />
Bearbeitung der Basisdaten in<br />
Wallonien<br />
Jean-Claude Jasselette, MET Belgien
1 Einführung<br />
1.1 Vorwort<br />
Jean-Claude Jasselette ist Adjunkt der Topographie- und Kartographieabteilung des<br />
Bau- und Verkehrsministeriums der Region Wallonien in Belgien. Er ist im Projekt<br />
InfraSIG involviert und hat sich insbesondere an den Arbeiten der Modellierung der<br />
topographischen Referenzdaten mit Hilfe von INTERLIS beteiligt.<br />
Das Hauptziel des Referates besteht darin, die Arbeiten vorzustellen, die im Rahmen<br />
der Einführung einer Infrastruktur für geographische Informationen in der Region Wallonien<br />
durchgeführt wurden. Im Referat wird versucht, die zugrunde liegenden Leitlinien<br />
und ihre Auswirkungen im Kontext der <strong>Interoperabilität</strong> für räumliche Daten aufzeigen.<br />
1.2 Übersicht<br />
Nach einer kurzen Beschreibung der Situation der belgischen Kartographie wird die<br />
Problematik in ihren wallonischen regionalen Zusammenhang gestellt. Schritt für<br />
Schritt werden die verfolgten Zielsetzungen, die eingesetzten Mittel und schließlich der<br />
St<strong>and</strong> der Arbeiten durchgegangen. Die Schlussfolgerungen werden sich auf die Vorteile<br />
des gewählten Vorgehens, auf die aufgetretenen Probleme sowie auf das daraus Gelernte<br />
beziehen.<br />
2 Kontext und Problematik<br />
2.1 Belgien, ein junger Bundesstaat<br />
BRÜSSEL<br />
162 km2 FLANDERN<br />
13 522 km2 WALLONIEN<br />
16 844 km2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 10.1
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
Bekanntlich setzt sich Belgien seit mehr als 20 Jahren für einen Regionalisierungsprozess<br />
ein. Für Themen wie die Kartographie ist die öffentliche H<strong>and</strong> einerseits unterteilt in<br />
eine föderale Ebene und <strong>and</strong>ererseits ein regionales Niveau, das die Region Wallonien<br />
(16.844 km 2), die Region Fl<strong>and</strong>ern (13.522 km 2) und die Region der Hauptstadt Brüssel<br />
(162 km 2) umfasst.<br />
2.2 Kartographie im Bundesstaat und in den Regionen<br />
Wie die meisten europäische Staaten verfügt Belgien über ein eigenes nationales geographisches<br />
Institut (IGN). Diese föderale öffentliche Verwaltung wird mit allen Kartographie-,<br />
Geodäsie- und Fernerkundungsaufgaben beauftragt, die sich auf das gesamte<br />
Staatsgebiet beziehen. Das belgische IGN ist Hersteller von qualitativ sehr hochstehenden<br />
Karten und topo-geographischen Daten in den Massstäben zwischen 1/300’000 und<br />
1/10’000.<br />
Abgesehen davon ist auf der föderalen Ebene das Katasteramt Hersteller von Grundstücksplänen<br />
mit sehr grossem Massstab. Momentan haben diese Pläne ausschliesslich<br />
steuerpolitische Ziele und haben meistens keine Vermessungsqualität. Ein ehrgeiziges<br />
Projekt zur Modernisierung des belgischen Katasteramtes ist in Vorbereitung.<br />
Infolge der Regionalisierung im Bereich der umweltrelevanten Kompetenzen der Raumordnung,<br />
der öffentlichen Arbeiten und erst kürzlich der L<strong>and</strong>wirtschaft hat die regionale<br />
öffentliche H<strong>and</strong> verschiedene kartographische Projekte geschaffen. Was die Referenzdaten<br />
betrifft, hat jede der drei Regionen ein digitales topographisches Kartographieprojekt<br />
in sehr grossem Massstab eingeführt. Es h<strong>and</strong>elt sich um die Projekte Urbis<br />
in der Region der Hauptstadt Brüssel, PICC in der Region Wallonien und GRB in der<br />
Region Fl<strong>and</strong>ern. Diese drei Projekte entsprechen ungefähr denselben Genauigkeitskriterien<br />
und sind vergleichbar mit einer Karte des Typs "öffentliche Arbeiten" im Maßstab<br />
von 1/1’000 oder besser. Sie werden im Allgemeinen durch numerische Orthophotoplan-Layer<br />
vervollständigt.<br />
Mangels einer Koordinationsstelle auf föderalem oder interregionalem Niveau haben<br />
die durch die drei Regionen eingeleiteten Projekte trotz allem deutlich verschiedene<br />
technische Eigenschaften.<br />
2.3 Kartographie in der Region Wallonien<br />
2.3.1 Verschiedene Ansätze und Referenzen<br />
Auch innerhalb einer Region ist die Homogenität nicht immer die Regel. Auf diese Art<br />
haben in Wallonien verschiedene Hersteller von analogen und numerischen kartographischen<br />
Daten verschiedene Methoden und Referenzen verwendet oder verwenden sie<br />
immer noch. Zum Beispiel ist es mangels gemeinsamer Referenz nicht selten so, dass<br />
Geometer, die für verschiedene Verwaltungen der Region Wallonien arbeiten, die gesammelten<br />
Vermessungsdaten nicht austauschen können.<br />
2.3.2 Die Vielfalt numerischer Daten<br />
Seit einigen Jahren wird der Gehalt der numerischen geographischen Daten, die durch<br />
die Verwaltungen der Region Wallonien produziert wurden, allerdings anerkannt. Daher<br />
bilden die Plans Photographiques Numériques Communaux (PPNC) einen numerischen<br />
Orthophotoplan in Farbe mit Meter-Auflösung flächendeckend für die ganze Region.<br />
Das Projet Informatique de Cartographie Continue (PICC) bietet eine numerische Kartographie<br />
im Massstab 1/1’000 über eine Fläche von mehr als 8’000 km2 an, die unter <strong>and</strong>e-<br />
10.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
rem in einer geographischen Datenbank mehr als 55% der 1'500’000 Gebäude, die die<br />
wallonische Region umfasst, enthält.<br />
Angesichts der Qualität der bestehenden Daten und der Kosten, die ihre Produktion<br />
dargestellt hat, begreift man, dass ihre Aufwertung ein wichtiger Einsatz ist, und dass<br />
nicht zu beabsichtigen ist, ein neues Projekt derselben Spannweite anzusetzen.<br />
2.3.3 Der Zukunftsvertrag und das Vorgehen eGov<br />
Im Zeitalter der Computerisierung und Vernetzung der Datenbanken ist die Notwendigkeit,<br />
die Aktivitäten der verschiedenen für die Erstellung von räumlichen Daten verantwortlichen<br />
öffentlichen Hoheitsträgern zu koordinieren, ein entscheidender Einsatz<br />
geworden.<br />
Die Regierung der Region Wallonien ist sich dieses Einsatzes bewusst. In einer der vorrangigen<br />
Massnahmen ihres Contrat d’Avenir pour la Wallonie (CAW), Absichtserklärung<br />
der Regionalpolitik, wird festgelegt, dass die Regierung "allen Beteiligten via Internet<br />
die Gesamtheit der kartographischen Daten der Region Wallonien zur Verfügung stellt"<br />
und das, indem sie "die verschiedenen Kartographieprojekte in ein <strong>of</strong>fenes, zusammenhängendes<br />
und koordiniertes System integrieren werden, das den Informationsaustausch<br />
erlaubt und das sowohl Redundanz als auch Inkompatibilität verhindert."<br />
Seit 2002 präzisiert das aktualisierte CAW, dass die "regionalen kartographischen Projekte<br />
der Öffentlichkeit im Rahmen des Projekts vom wallonischen e-Gouvernement übers<br />
Internet zur Verfügung gestellt werden." Man sieht also, dass der Zugang zu zusammenhängenden<br />
geographischen Daten und die Qualität durch die wallonische öffentliche<br />
H<strong>and</strong> für prioritär eingeschätzt werden.<br />
2.3.4 Das CTC und das Projekt InfraSIG<br />
In diesem Rahmen ist das Comité Technique Cartographique (CTC) der Region Wallonien<br />
im November 2000 ins Leben gerufen worden. Das CTC setzt sich aus Vertretern des mit<br />
der Kartographie beauftragten Ministeriums und aus den verschiedenen Generaldirektionen<br />
der wallonischen Ministerien zusammen. Sein Hauptziel besteht darin, die Kohärenz<br />
zwischen den verschiedenen Kartographiediensten der Region Wallonien zu gewährleisten<br />
und damit den Zielsetzungen des aktualisierten CAW zu entsprechen.<br />
Um der Regierung die Elemente einer Verwaltungs- und Verbreitungspolitik der öffentlichen<br />
geographischen Daten im Rahmen einer internetbasierten Infrastruktur vorschlagen<br />
zu können, hat das CTC im Jahre 2002 ein Projekt mit der Bezeichnung InfraSIG<br />
lanciert. Dieses Projekt zielt darauf ab, eine Infrastruktur für die Verwaltung und die<br />
Verbreitung der geographischen Daten der Region Wallonien zu definieren und zu verwirklichen,<br />
um den Anforderungen und den Bedürfnissen aller Benutzer zu entsprechen.<br />
Um dieses Projekt zu verwirklichen, pr<strong>of</strong>itiert das CTC von der technischen Hilfe<br />
eines Konsortiums, das durch die Gesellschaft GFI gesteuert wird.<br />
Das InfraSIG-Projekt entwickelt sich in vier Richtungen:<br />
1.Eine organisatorische Achse, um das Projekt zu koordinieren, die Rolle und die Verantwortung<br />
der Beteiligten zu definieren, die Benutzer zu sensibilisieren und auszubilden<br />
und einen Führer der guten Praktiken aufzustellen.<br />
2.Eine technische Achse, die zum Ziel hat, die Problematik zur Sprache zu bringen<br />
� von der Infrastruktur der Verbreitung der Daten,<br />
� der Metadaten,<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 10.3
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
� vom Setzen in Kohärenz der Referenzdaten und der thematischen Daten durch<br />
den Modellbau,<br />
� mit diesen Angaben assoziierte Dienste,<br />
� Aktualisierungsverfahren.<br />
3.Eine Rechtsachse, die anvisiert,<br />
� einerseits ein vereinheitlichtes Lizenzmodell für die Zurverfügungstellung geographischer<br />
Informationen durch die Region aufzustellen;<br />
� <strong>and</strong>ererseits die Auswirkung der Gesetzgebungen über den Zugang zur Information<br />
zu untersuchen.<br />
4.Eine sozioökonomische Achse, die zum Ziel hat, die Kosten, den Markt und die Anwendungen<br />
zu analysieren, um der wallonischen Regierung die Best<strong>and</strong>teile einer<br />
Politik für die Verbreitung der geographischen Daten vorzuschlagen.<br />
Jede dieser Achsen entspricht einer oder mehreren Arbeitsgruppen.<br />
Technisches Komitee Kartographie<br />
Projektleitung INFRASIG<br />
GT<br />
Organisation<br />
Koordination<br />
Organisation<br />
versch. DG<br />
Basisdaten<br />
Metadaten<br />
Minister M. DAERDEN<br />
(Kartographische Angelegenheiten)<br />
Ministerialkanzlei – “Carto”<br />
GT Technik<br />
Thematische<br />
Daten<br />
Infrastruktur Verteilung<br />
Permanenter Auftrag<br />
Technische<br />
Projektassistenz<br />
GT Recht GT<br />
Preis<br />
Technik Recht Preis<br />
Punktuelle Aufträge<br />
10.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
Schliesslich ist das CTC beauftragt, "die Zusammenarbeiten und die Kooperationsabkommen<br />
mit <strong>and</strong>eren regionalen und gemeinschaftlichen (OC Gis-Vla<strong>and</strong>eren, CIRB...),<br />
nationalen (IGN, Katasteramt...) und europäisch Instanzen (grenzüberschreitende Projekte,<br />
Initiative LEITEN...) zu koordinieren."<br />
3 Verfolgte Ziele<br />
Die wichtigsten Leitlinien, die bei der Einführung von der Infrastruktur der Verbreitung<br />
der wallonischen geographischen Informationen verfolgt werden, können wie folgt zusammengefasst<br />
werden.<br />
3.1 Datenverwendung<br />
Zunächst muss die Infrastruktur die Weiterverwendung der Daten vereinfachen und<br />
die Aufrechterhaltung des Qualitätsniveaus dieser Daten garantieren, was ihre Aktualisierung<br />
voraussetzt.<br />
Um zu garantieren, dass geographische Informationen, die im Rahmen eines Einzelvorhabens<br />
produziert wurden, an <strong>and</strong>eren Zielen wieder verwendet werden und dass sie<br />
durch die öffentliche H<strong>and</strong> befragt oder in Mehrwertdienste durch die Privatwirtschaft<br />
noch integriert werden, muss man ihnen zunächst eine bessere Sichtweite und eine adäquate<br />
Dokumentation gewährleisten. Man muss auch im Rahmen des Möglichen die<br />
Faktoren identifizieren und reduzieren, die den Zugang zu den geographischen Daten<br />
beschränken, wie die Trägheit, die mit der Verwaltung oder mit der Gesetzgebung zusammenhängt,<br />
die zu hohen Preise sowie eine Reihe von technischen Problemen.<br />
3.2 Begriff der authentischen Quellen<br />
Daher muss die Kohärenz verstärkt werden. Diese Zielsetzung deutet zum Beispiel an,<br />
dass eine gemeinsame Referenz identifiziert oder dargestellt wird, und dass man eine<br />
Verbreitung von Mehrfachkopien der Referenzdaten vermeidet. Diese letzte Sache lässt<br />
in der Tat gewaltige Probleme bei der Aktualisierung dieser Daten entstehen.<br />
Ein Ziel auf lange Sicht ist also die Konsolidierung des Begriffes der authentischen Quellen<br />
welche eine eindeutige und gut verfügbare Referenz erlaubt. Im Gegensatz dazu<br />
werden heute die PICC-Daten in der Zwischenversion des wallonischen Geoportals<br />
vierfach kopiert!<br />
3.3 <strong>Interoperabilität</strong> auf dem Datenniveau<br />
Die Online-Verbreitung der geographischen Daten setzt auch die <strong>Interoperabilität</strong> bei<br />
den Daten voraus.<br />
3.4 Berücksichtigung von Normen und internationalen St<strong>and</strong>ards<br />
Die Realisierung dieser Infrastruktur wird im Sinne der Integration und der Koordination<br />
mit der europäischen Initiative INSPIRE (Infrastructure for Spatial Information in<br />
Europe) sowie unter Berücksichtigung der bestehenden Normen und internationalen<br />
St<strong>and</strong>ards, die bereits bestehen oder erst in Vorbereitung sind (ISO, CEN, NBN, OGC,<br />
W3C...), geführt<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 10.5
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
3.5 Unabhängigkeit von Systemherstellern<br />
Schliesslich sucht die wallonische Region eine grösstmögliche Unabhängigkeit gegenüber<br />
den S<strong>of</strong>twareherstellern. Bei gleicher Leistung werden die „Open Source“-<br />
Lösungen gegenüber den proprietären Lösungen bevorzugt.<br />
4 Mitteleinsatz<br />
4.1 Projekt InfraSIG, öffentlich-private Interaktion<br />
Das InfraSIG-Projekt funktioniert auf der Basis einer Wechselwirkung zwischen den<br />
verschiedenen Verwaltungen und den privaten und universitären Partnern. Seit 2004 ist<br />
die Eidgenössische Technische Hochschule in Zürich ebenfalls im Projekt involviert.<br />
4.2 Methode INTERLIS 2<br />
Diese Partnerschaft ist vor allem dadurch begründet – wie wir noch detaillierter sehen<br />
werden – weil die modellbasierte Methode mit INTERLIS im Zusammenhang mit dem<br />
Projekt InfraSIG übernommen wurde.<br />
5 Fortschritt der Implementierung<br />
5.1 Abgeschlossene Realisierungen<br />
Die erste Phase des Projektes InfraSIG wird auf vier Jahre verteilt (Februar 2002-2006).<br />
Die folgenden Teilziele wurden bis jetzt erreicht:<br />
� Die Realisierung eines kartographischen Zwischenportals, das ins e-<br />
Gouvernement-Projekt der Region Wallonien integriert wurde.<br />
� Die Realisierung eines Metadaten-Verwaltungssystems gemäss den ISO-Normen<br />
19115 und 19139<br />
� Die Realisierung von Applikationen für den sicheren Zugriff auf prioritäre Referenzdaten,<br />
sowohl für die Visualisierungen als auch für das Laden der Daten über<br />
das Internet.<br />
� Die Redaktion von Berichten über die rechtlichen und wirtschaftlichen Aspekte.<br />
� Das Modell der topographischen Referenzdaten Walloniens wurde mit INTERLIS<br />
2 beschrieben und die entsprechenden technischen Anforderungen wurden in einem<br />
Pflichtenheft verfasst.<br />
5.2 Das vorläufige Portal<br />
5.2.1 St<strong>and</strong> der Arbeit<br />
Das kartographische Portal entspricht einem einzigen interaktiven Schalter für die<br />
Verbreitung der geographischen Information der Region Wallonien für alle Anwender<br />
wie Verwaltungen, Unternehmen und Bürger. Das heutige Portal ist eine Zwischenlösung,<br />
welche realisiert wurde, um schnell die Ziele der Abgabe der Referenzdaten erreichen<br />
zu können.<br />
Das Portal dient als einziger Zugang, um:<br />
� allen Interessenten den Zugriff auf die geographischen Daten aufgrund der vorh<strong>and</strong>enen<br />
Metadaten und der st<strong>and</strong>ardisierten Lizenzverträge zu gewähren und<br />
so die Geodaten zu verbreiten.<br />
10.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
� die Visualisierung und das sichere Herunterladen der prioritären Referenzgeodaten<br />
zu erlauben.<br />
� Allen via Internet-Verbindungen den Zugang zu den <strong>and</strong>eren heute verfügbaren<br />
geographischen Ressourcen (geologische Karte, Atlanten, statistische Karten, dynamische<br />
Karten wie Trafiroute usw.) zu gewähren die auf den verschiedenen<br />
Homepages der kartographischen Dienste der Region Wallonien verfügbar sind.<br />
� die Realisierung von St<strong>and</strong>ards zu fördern, um den Austausch und die Dokumentation<br />
der Qualitätsdaten durch die Bekanntgabe der Resultate des Projektes<br />
InfraSIG über den Führer der guten Praktiken und über Empfehlungen zu garantieren.<br />
� die Sensibilisierung der Benutzer zu gewährleisten, indem es die Grundkonzepte<br />
der geographischen Information definiert und die Daten der Kolloquien, Konferenzen<br />
oder Fachmessen und der Web-Links, die sich auf die geographische Information<br />
beziehen, bekannt gibt.<br />
5.2.2 Zukünftige Aktivitäten<br />
Definitives Portal – angestrebte technische Architektur<br />
Sicherheit / Authentifizierung<br />
Register<br />
Daten<br />
Services<br />
Zugriffsverwaltung /<br />
Authentifizierung<br />
Services<br />
Datenkatalog<br />
Web Services OGC & W3C<br />
Kartographische Werkzeuge<br />
Datenbank<br />
Benutzer<br />
Servicekatalog<br />
INTERLIS-<br />
Services<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 10.7<br />
FTP
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
Oracle spatial 10g<br />
Alle Daten sind in einem einzigen Datenbankverwaltungssystem gespeichert. Für die<br />
geographischen Daten hat die wallonische Region Oracle Spatial gewählt. Die Daten<br />
vom PICC zum Beispiel werden vom proprietären Format des Herkunft-GIS zu Oracle<br />
Spacial 10g übertragen.<br />
5.3 MétaWal und die ISO-Normen<br />
5.3.1 St<strong>and</strong> der Arbeit<br />
Die Fachleute sind sich einig, dass die Metadaten ein unentbehrliches Element der ganzen<br />
Raumdateninfrastruktur sind. Im Rahmen des Projektes InfraSIG wurden die Metadaten<br />
von allen öffentlichen Datensammlungen Walloniens gemäss den Normen ISO<br />
19115 beschrieben. Die erste Phase dieser Arbeit best<strong>and</strong> in der Auswahl und Übersetzung<br />
der Attribute, welche für die Beschreibung der wallonischen Daten nötig waren.<br />
Diese Attribute wurden anh<strong>and</strong> der Anwenderbedürfnisse mit wallonischen Erweiterungen<br />
ergänzt. Nach der Festlegung des Metadatenkatalogs wurde das konzeptuelle<br />
UML-Modell der ISO-Norm und der wallonischen Ergänzungen generiert. Das UML-<br />
Modell der Metadaten wurde danach im Datenbankverwaltungssystem von Oracle implementiert.<br />
Danach wurden Datenerfassungsschnittstellen Intranet – Extranet entwickelt, um die<br />
Kodierung der Metadaten durch den Datenverwalter zu ermöglichen, welcher sowohl<br />
für die Daten als auch für die Metadaten verantwortlich ist. Die Zutrittskontrollen an<br />
diesen Schnittstellen werden mittels eines extern akquirierten elektronischen Systems<br />
LDAP realisiert.<br />
Ein Import-/Export-XML-Werkzeug für Metadaten wurde entwickelt, welches die Vornorm<br />
ISO 19139 Version 6 vollständig erfüllt. Es ermöglicht sowohl die Integration von<br />
Metadaten aus <strong>and</strong>eren Quellen als auch den Austausch von Metadaten mit allen Partnern<br />
ausserhalb der Region Wallonien.<br />
Zurzeit ist das auf den Namen MétaWal getaufte System operationell und die Grundlagen<br />
der Metadaten wurden erfasst. Eine grosse Vielfalt von flexiblen Suchprozeduren<br />
wurde entwickelt um die Abfragen von verschiedenen Anwendern zu ermöglichen. Die<br />
Verbindung mit dem Suchwerkzeug Mugire ermöglicht mehrsprachige Suchprozesse.<br />
5.4 Die abgegebenen Daten – die dazugehörigen Dienste<br />
5.4.1 St<strong>and</strong> der Arbeiten<br />
Die Daten, auf welche durch das provisorische Portal zuerst Zugang verschafft wird,<br />
sind die Referenzdaten (PICC, PPNC, Strassenatlas, MNT Verlauf der Hauptgewässer).<br />
Bis heute erlauben die auf diesen Daten entwickelten Dienste einerseits ihre Visualisierung<br />
mittels zweier mit der OGC-Norm WMS kompatiblen Schnittstellen und <strong>and</strong>ererseits<br />
das Herunterladen der Datenfiles in zwei proprietären Formaten der GIS-S<strong>of</strong>tware.<br />
Es ist zu beachten, dass diese Daten laufend mit <strong>and</strong>eren thematischen Daten nach und<br />
nach (gem. Validierung) vervollständigt werden.<br />
5.4.2 Zukünftige Aktivitäten<br />
Das provisorische Portal verwaltet Dienste nach den Normen von OGC oder W3C. Diese<br />
Dienste verwenden kartographische Werkzeuge, welche Algorithmen und technische<br />
10.8 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
Funktionen aktivieren, die in den dem Besucher zugänglichen Web-Services enthalten<br />
sind.<br />
Neben den Applikationsdiensten und den Visualisierung- und Datenzugriffdiensten<br />
wird man weitere generische Dienste schrittweise den Anwendern und Entwicklern zur<br />
Verfügung stellen. Darunter wird man Lokalisierungsdienste (verbunden mit einem<br />
Gazetteer), Dienste für das Herunterladen und die INTERLIS-Dienste (Checker, semantische<br />
Transformation der Daten, Werkzeuge für die Formatumw<strong>and</strong>lung, Verwaltung<br />
von eindeutigen Identifikatoren) finden. Diese Werkzeuge werden ermöglichen die <strong>Interoperabilität</strong><br />
der Daten zu gewährleisten, die Anfragen der Anwender, welche mit<br />
verschiedener GIS-S<strong>of</strong>tware arbeiten, zu beantworten und die Daten in den erforderlichen<br />
Formaten herunterzuladen.<br />
Die Entwicklung des Dienstleistungsumfeldes sieht vor, Dienste zu integrieren, die elementareren<br />
Funktionen entsprechen. Es ist die Kombination solcher „atomaren“ Dienstleistungen,<br />
die erlauben wird, Applikationen auf einem den Bedürfnissen der Anwender<br />
entsprechenden Niveau zu realisieren.<br />
Ausserdem muss die Verbreitungsinfrastruktur einen Katalog von Diensten enthalten,<br />
welche wahrscheinlich der Norm OGC entsprechen. Mehrere auf dem Markt erhältliche<br />
Kataloge werden zurzeit im Rahmen des Projektes InfraSIG evaluiert. Ein Bewertungskriterium<br />
ist ihr Niveau der Erfüllung der Norm ebXML<br />
5.5 Rechtliche Aspekte<br />
5.5.1 St<strong>and</strong> des Fortschrittes<br />
Für jede Anwenderkategorie wurde ein einheitliches Lizenzmodell verfasst und auf<br />
dem kartographische Portal platziert, das für alle Daten, die durch die regionale Verwaltung<br />
verbreitet wurden, st<strong>and</strong>ardisiert ist.<br />
Das Herunterladen von Daten ist nur möglich, wenn der Anwender den Lizenzvertrag<br />
angenommen hat. Bei der Visualisierung der Daten erscheint ein rechtlicher Hinweis auf<br />
dem Bildschirm.<br />
Das hat die Prüfung der Gesetzgebungen zum geistigen Eigentum, über das Verwaltungsrecht,<br />
über die Daten von persönlichem Charakter und zur Respektierung des privaten<br />
Lebens, über den Verbraucherschutz, über die Verantwortung des Erzeugers und<br />
des Benutzers und über die elektronische Unterschrift erfordert.<br />
5.5.2 Zukünftige Aktivitäten<br />
Zurzeit wird die Frage diskutiert, inwieweit das Geoportal zur Visualisierung von Geobasisdaten<br />
der Öffentlichkeit zugänglich gemacht werden kann. Es fehlt allerdings eine<br />
hinreichende Rechtssprechung und es ist schwierig zu garantieren, dass die Veröffentlichung<br />
solcher Basisdaten nicht einer Verletzung der Bestimmungen über den Schutz der<br />
Privatsphäre bedeutet. Besonders stellt sich diese Frage für die Veröffentlichung von<br />
sehr detaillierten Orthophotoplänen, welche eine Visualisierung vom Innern privater<br />
Liegenschaften erlauben.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 10.9
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
5.6 Sozio-ökonomische Aspekte<br />
5.6.1 St<strong>and</strong> der Arbeit<br />
Um die Regeln für die Abgaben der geographischen Daten definitiv festzulegen ist es<br />
notwendig eine Preispolitik zu definieren. Für die Redaktion eines Vorschlages für die<br />
wallonische Regierung wurden drei Aspekte verfolgt:<br />
� Einerseits wurde eine Studie über die Anwendungen der geographischen Daten<br />
unternommen. Zu diesem Zweck wurde eine breite semantische Studie über eine<br />
grosse Menge Dokumente unternommen<br />
� Andererseits wurde eine Studie verfasst über die allgemeinen Kriterien der Preisfestlegung<br />
und über die heutige Situation im Bereich der geographischen Daten in<br />
Europa<br />
� Schliesslich wurde der Vorschlag gemacht, mit welchem eine Preispolitik beschrieben<br />
wird, die tiefe Preise bezweckt und in welcher man die R<strong>and</strong>kosten für<br />
die Abgaben berücksichtigt.<br />
Dieser Vorschlag entspricht den allgemeinen Zielen der Region Wallonien, welche eine<br />
breite Verbreitung der geographischen Daten bezweckt und globale Einsparungen sowie<br />
eine regionale Förderung ermöglicht.<br />
Der Vorschlag fusst auf den Charakteristika des Marktes geographischer Daten und liefert<br />
eine Matrix, welche es erlaubt, die Preise in Abhängigkeit von Dateneigenschaften,<br />
Benutzertypus und vorgesehener Verwendung zu bilden. So ist es zum Beispiel denkbar,<br />
dass ein Unternehmer freien Zugang zu gewissen als essentiell beurteilten Daten<br />
erhält, um für <strong>and</strong>ere – zur kommerziellen Nutzung vorgesehene – Daten bezahlen<br />
muss.<br />
5.6.2 Zukünftige Aktivitäten<br />
Wenn die wallonische Regierung die Vorschläge annimmt wird ein Abgabesystem entstehen<br />
in welchen die Geodaten für die öffentlichen Dienste und die Ausbildungsinstitutionen<br />
kostenlos im Rahmen ihres Auftrages abgegeben werden. Für die <strong>and</strong>eren Berufskreise<br />
wird man die Abgabe der Geodaten auf der Basis von Abonnements- oder<br />
Partnerschaftsverträgen regeln. Ein Detailverkauf in besonderen Fällen soll ebenfalls<br />
möglich sein.<br />
5.7 Die Modellierung der topographischen Referenzobjekte<br />
5.7.1 St<strong>and</strong> der Arbeiten<br />
Die Modellierung der Referenzdaten ist Best<strong>and</strong>teil der existierenden Daten und insbesondere<br />
vom PICC. Daher wird der Objektkatalog stark von letztgenannten Daten beeinflusst.<br />
Ein indirekter Effekt der Modellierungsprozesse war die Erhöhung des Bekanntheitsgrades<br />
der Daten von PICC. Ebenfalls verbreitete sich die Diskussion über die<br />
Referenzdaten auch auf <strong>and</strong>ere Berufskreise und blieb nicht nur beschränkt auf den<br />
Kreis der Geodaten-Produzenten. Diese Entwicklungen haben die Bedeutung des PICC<br />
aufgewertet. Dadurch wird es möglich, das PICC von einer rein numerischtopographischen<br />
Planform hin zu einer echten Datenbasis zu entwickeln.<br />
Das Konzept der Vererbung, typisch für die objektorientierten Technologien wurde eingesetzt<br />
um drei gekapselte Geodatenmodelle zu definieren. Das detaillierteste – innerste<br />
– Modell, das Geometermodell, enthält alle im Gelände nach dem System Walcors aufgenommenen<br />
Objekte (wallonisches GPS-RTK-Permanentnetz mit 23 Stationen); das<br />
10.10 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
mittlere Niveau ist das Modell PICC, welches ein Teil der Objekte des Geometermodells<br />
übernimmt. Schliesslich das Modell der Region Wallonien, welches nur die topographischen<br />
Objekte beinhaltet die für eine grosse Anzahl Applikationen benötigt werden. In<br />
der gleichen Art könnte ein Referenzmodell für das ganze L<strong>and</strong> oder für Europa aufgebaut<br />
werden.<br />
Um die sehr unterschiedlichen Detaillierungsstufen zu harmonisieren und zu konzipieren,<br />
ist die modellbasierte Methode mit INTERLIS 2 angewendet worden.<br />
Die Modellierung erlaubte einerseits die Datenstrukturen der Thematik unter Berücksichtigung<br />
der verschiedenen potenziellen Anwendungen zu verbessern. Andererseits<br />
schien es sinnvoll bei der Modellierung die Ergänzung der bestehenden Daten mit neuen<br />
Konzepten wie derjenigen der Strassenplattformen.<br />
5.7.2 Zukünftige Aktivitäten<br />
Die Einführung der neuen Konzepte und der Einsatz der INTERLIS-Werkzeuge (insbesonders<br />
dem Checker) machte eine Menge Inkonsistenzen in den Daten sichtbar. Man<br />
konnte feststellen, dass es nötig sein wird, ein Re-Engineering der Daten vorzunehmen.<br />
In der Folge wird man die Prozesse für die Nachführung der Daten unter der Verwendung<br />
der Methoden und Werkzeuge von INTERLIS gestalten. Zu diesem Zweck wird<br />
man eine immer stärkere Koordination der Anstrengungen anstreben. So sollte zum Beispiel<br />
nur eine einzige Feldaufnahme für die Nachführung der verschiedenen Datenebenen<br />
verwendet werden. Die Möglichkeit von INTERLIS 2 im Bereich der inkrementellen<br />
Nachführung ist vertieft zu analysieren. Es wird notwendig sein, ein Verwaltungssystem<br />
für eindeutige Objektidentifikatoren einzuführen.<br />
5.8 Gemeinsames Pflichtenheft für die topographischen Aufnahmen<br />
5.8.1 St<strong>and</strong> der Arbeit<br />
Die technischen Spezifikationen wurden in einem gemeinsamen Pflichtenheft aufgrund<br />
der konzeptuellen Datenmodellierung formuliert. Dieses Pflichtenheft könnte nach der<br />
definitiven Validierung als verbindlich für diejenigen Geometer erklärt werden, welche<br />
die Arbeiten für die wallonische öffentliche H<strong>and</strong> ausführen. In dieser Art werden die<br />
Ergebnisse ihrer Arbeiten kompatibel zuein<strong>and</strong>er und man wird sie verwenden, um die<br />
Daten des PICC sowie topografische Referenzobjekte auf einfache Weise zu aktualisieren.<br />
5.8.2 Zukünftige Aktivitäten<br />
Das Pflichtenheft muss noch in einer operationellen Umgebung getestet werden.<br />
Im Übrigen wird demnächst ein Pilotprojekt gestartet, um den Informationsaustausch<br />
zwischen den Feldequipen und der Verwaltung zu erleichtern. Dieser Pilot hat zum<br />
Ziel, im Rahmen des kartographischen Portals einen Web-Dienst für den Datenaustausch<br />
mit Hilfe von INTERLIS 2-Werkzeugen zu implementieren. Dieses System wird<br />
es den für die wallonische Verwaltung tätigen Geometern erlauben, nötige Dokumente<br />
aus dem Internet zu beziehen:<br />
� das Pflichtenheft, seine Dokumentation, die Datenmodelle usw.<br />
� die Daten der Geländeaufnahmen der Verwaltung unter Verwendung der IN-<br />
TERLIS 2-Werkzeuge zu übergeben um die eigenen Daten nach Bedarf zu trans-<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 10.11
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
formieren und um ihre Kompatibilität mit den entsprechenden Modellen mit dem<br />
INTERLIS-Checker zu überprüfen.<br />
� eine Validierung der eigenen Arbeit sobald die Verwaltung die Daten überprüft<br />
hat.<br />
Die organisatorischen und personellen Aspekte sind eine zentrale Frage des Projektes.<br />
Das Projekt kann nur erfolgreich sein wenn gemeinsame Interessen erkannt werden und<br />
wenn die Veränderungen breite Unterstützung finden.<br />
5.9 Weitere zukünftige Vorhaben<br />
5.9.1 Integration weiterer Partner<br />
Das Vorhaben der Region Wallonien, eine gemeinsame Geodaten-Infrastruktur – basierend<br />
auf einem Objektkatalog – zu erstellen, welche mit weiteren thematischen Informationen<br />
erweitert werden kann, lässt bereits heute erkennen, dass ein Koordinationsbedarf<br />
mit <strong>and</strong>eren Fachleuten der Regionen Wallonien, Fl<strong>and</strong>ern und Brüssel sowie Bundesstellen<br />
(IGN und Kataster) unerlässlich ist. Diese Koordination ist unter <strong>and</strong>erem<br />
notwendig, um die Anforderungen der europäischen Initiative INSPIRE zu erfüllen.<br />
6 Überlegungen<br />
6.1.1 Vorteile von INTERLIS<br />
INTERLIS 2 bietet einerseits die Vorteile der Objektorientierung wie Vererbung und Polymorphismus.<br />
Andererseits können die Daten mit einem so genannten Checker auf<br />
Modellkompatibilität überprüft werden. Ebenfalls sehr geschätzt ist in Belgien und insbesondere<br />
in der Region Wallonien die Mehrsprachigkeit der Lösung. Als Ergänzung<br />
erleichtert INTERLIS die Nachführung, da sie sich mit inkrementellen Verfahren organisieren<br />
lässt.<br />
Schliesslich ist die Unabhängigkeit der Methode von jeglichem Informatiksystem der<br />
entscheidende Vorteil. Er gewährt die <strong>Interoperabilität</strong>, sobald man die konzeptionellen<br />
Modelle mit INTERLIS beschrieben hat.<br />
6.1.2 Aufgetretene Schwierigkeiten<br />
Einige der erwähnten Vorteile gelten für die Version 2 von INTERLIS. Die Region Wallonien<br />
hat von Anfang an entschieden, diese Version zu implementieren, ohne die Version<br />
1 einzusetzen. Dieser Entscheid stellt die wallonische Verwaltung in die Position<br />
des Pioniers von INTERLIS 2, hat aber bereits einigen Zeitverlust verursacht und beinhaltet<br />
Risiken, die nicht so leicht abgeschätzt werden können.<br />
Man musste zum Beispiel die Modellierungsarbeit „blind“ vornehmen, da während dieser<br />
Zeit die Werkzeuge nur für INTERLIS 1 existierten. Wir sind weiterhin mit dem<br />
Problem konfrontiert, dass zu wenige Werkzeuge für die Modellierung der graphischen<br />
Darstellung zur Verfügung stehen. Werden wir eine direkte Beziehung mit SLD von<br />
OGC erleben?<br />
Es gibt noch weitere <strong>of</strong>fene technische Fragen: die Implementierung der OID und ihres<br />
Transfers zu <strong>and</strong>eren Formaten mittels Transformationen, die naturgemäss nie neutral<br />
sein können. Wie kann man die Arbeit st<strong>and</strong>ardisieren, um allen Datenproduzenten zu<br />
ermöglichen, mit dem gleichen Konfigurationsskript für die Transformationswerkzeuge<br />
zu operieren? Wie weit kann die inkrementelle Nachführung eingesetzt werden? Usw.<br />
10.12 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
St<strong>and</strong> der Technik, Implementierungen II<br />
Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien<br />
Aufgrund der bisherigen Erfahrungen plädieren wir für eine Vervollständigung der<br />
Norm INTERLIS 2 mit Implementierungsregeln, um die erwähnten Probleme zu vermeiden.<br />
Neben den technischen Schwierigkeiten zeigten sich ebenfalls organisatorische und<br />
menschliche Probleme. Es ist zum Beispiel nicht leicht, alle Betr<strong>of</strong>fenen in das Vorhaben<br />
zu integrieren. Die Beteiligung der Datenanwender war wesentlich kleiner als diejenige<br />
der Datenproduzenten, die bereits sensibilisiert sind auf die Bedürfnisse einer Datenmodellierung.<br />
Man stellte ebenfalls fest, dass eine Vielfalt von Arbeitsmethoden, insbesondere für die<br />
Feldaufnahmen, existiert. Dies ergibt sich aus der fehlenden St<strong>and</strong>ardisierungstradition<br />
im Kreis der wallonischen Datenproduzenten. Die Konsequenz daraus ist ein Bedarf<br />
nach tief greifenden Änderungen, um garantieren zu können, dass die Daten modellkonform<br />
erfasst werden. Man kann erwarten, dass Widerstände entstehen, die durch<br />
einen zwingenden rechtlichen Rahmen beseitigt werden können. Terminologische Probleme<br />
sind ebenfalls aufgetaucht.<br />
7 Schlussfolgerungen<br />
Die bisherigen Erfahrungen in der Region Wallonien sind global betrachtet positiv. Die<br />
INTERLIS-Lösungsansätze ermöglichten, ein konsistentes Vorgehen zu gestalten und<br />
diesem zu folgen. Eine vertiefte Diskussion über die topographischen Referenzdaten<br />
und über ihre langfristige Entwicklung wurde ebenfalls ausgelöst.<br />
Die Wahl von INTERLIS 2 bedeutete trotzdem ein nicht zu vernachlässigendes Risiko.<br />
Mehrere wichtige Fragen blieben bis jetzt unbeantwortet.<br />
Die realisierten Lösungen stehen zurzeit noch am Anfang der Entwicklung. Die nächsten<br />
Schritte der Evolution betreffen die Beziehungen zwischen Referenz- und thematischen<br />
Daten. Diese Zielsetzung wird den Einbezug einer grösseren Anzahl Partner erfordern.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 10.13
Andreas Morf<br />
Eidg. Technische Hochschule Zürich<br />
Institut für Geodäsie und Photogrammetrie<br />
ETH Hönggerberg<br />
CH-8093 Zürich<br />
Sepp Dorfschmid<br />
ADASYS AG<br />
Dörflistrasse 67<br />
Postfach 5019<br />
CH-8050 Zürich<br />
Tel :<br />
E-Mail :<br />
+41 1 633 32 56 (Morf)<br />
+41 1 363 19 39 (Dorfschmid)<br />
11<br />
Modellst<strong>and</strong>ardisierung vs.<br />
semantische <strong>Interoperabilität</strong><br />
Aktuelles aus der Forschung<br />
Andreas Morf, ETH Zürich<br />
Josef Dorfschmid, ADASYS AG
1 Problemstellung / Zielsetzung<br />
Immer wieder kommt es vor, dass Daten neu erfasst werden, obwohl sie an sich vorh<strong>and</strong>en<br />
wären. Sie liegen aber nicht in der gewünschten Form vor. Zum Teil müssten<br />
anspruchsvolle Umformungen durchgeführt, zum Teil sogar verschiedene Datenbestände<br />
in geeigneter aber nicht <strong>of</strong>fensichtlicher Art zusammengeführt werden.<br />
Bislang wurde versucht, die Problematik durch möglichst abschliessende St<strong>and</strong>ardisierung<br />
der Datenmodelle bzw. der Datenformate zu entschärfen. Wenn die Definition der<br />
Bedürfnisse und Ansprüche an die entsprechenden Daten möglich ist und der zugehörige<br />
Anwenderkreis an den 'runden Tisch' gebracht werden kann ist ein solches Vorgehen<br />
durchaus Erfolg versprechend.<br />
In vielen Fällen ist jedoch eine umfassende Festlegung und abschliessende St<strong>and</strong>ardisierung<br />
der Modelle nicht möglich oder mit unverhältnismässig grossem Aufw<strong>and</strong> verbunden:<br />
1.1 Möglichkeiten und Grenzen der Modell-St<strong>and</strong>ardisierung<br />
Mit der modellbasierten Methode (ISO/UML/INTERLIS) steht ein Werkzeug zur Verfügung,<br />
welches eine sehr flexible Datenmodellierung ermöglicht. Die Anwendung dieses<br />
Verfahren ist weitgehend etabliert und wurde in diversen Informationsgemeinschaften<br />
zur Definition ihrer Datenmodelle in der Form von St<strong>and</strong>ards verwendet (SIA 405,<br />
AVS, VSA-DSS).<br />
Mit den objektorientierten Konzepten, wie sie zum Beispiel in INTERLIS 2 zur Verfügung<br />
stehen, ist es nun auch möglich, Basismodelle zu spezifizieren und dann mittels<br />
Vererbung Modellerweiterungen für spezielle Bedürfnisse vorzunehmen (vergleichbar<br />
mit den heute praktizierten kantonalen Erweiterungen zum Bundesmodell der amtlichen<br />
Vermessung).<br />
Ist es nun aus administrativen oder rechtlichen Gründen nicht möglich, ein umfassendes<br />
und abschliessendes Datenmodell festzulegen ergeben sich <strong>of</strong>fensichtlich zwei<br />
grundsätzliche Probleme:<br />
� Verschiedene Teil-Informationsgemeinschaften (z.B. Kantone) erweitern ein Basismodell<br />
um Elemente, wobei die Erweiterungen wohl <strong>of</strong>tmals denselben Inhalt<br />
beschreiben, diesen jedoch vielleicht auf verschiedene Arten modellieren (Namen<br />
der Klassen/Tabellen/Attribute)<br />
� Übergeordnete und 'verw<strong>and</strong>te' Informationsgemeinschaften (Staat, EU-Raum)<br />
streben die Nutzung der Daten an und wollen zu diesem Zweck St<strong>and</strong>ardmodelle<br />
erstellen. Die Koordination aller Bedürfnisse der Beteiligten verursacht einen sehr<br />
grossen Aufw<strong>and</strong> und führt entweder zu Modellen, welche dem kleinsten gemeinsamen<br />
Nenner entsprechen und damit den wenigsten gerecht werden - oder<br />
aber alle Eventualitäten werden berücksichtigt und es entstehen Modelle mit einer<br />
Komplexität, welche in der Praxis kaum mehr h<strong>and</strong>habbar sind.<br />
Der Einsatz von spezialisierten S<strong>of</strong>twaresystemen im Geoinformationsbereich im Zusammenhang<br />
mit normierten St<strong>and</strong>ard-Datenmodellen ist <strong>of</strong>tmals mit einigen Hürden<br />
verbunden und häufig werden auch an sich geeignete S<strong>of</strong>tware-Pakete zur Erfassung,<br />
Bearbeitung und Auswertung von Daten nicht eingesetzt, weil sie die gewünschten Datenmodelle<br />
nicht unterstützen oder diese Unterstützung mit erheblichen Kosten verbunden<br />
wäre.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 11.1
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Modellst<strong>and</strong>ardisierung vs. semantische <strong>Interoperabilität</strong>: Aktuelles aus der Forschung<br />
1.2 Anforderungen an ein Lösungskonzept<br />
Wo die Einführung von St<strong>and</strong>ard-Datenmodellen aufgrund administrativer, politischer,<br />
rechtlicher und allenfalls auch technischer R<strong>and</strong>bedingungen nicht oder nur mit sehr<br />
grossem Aufw<strong>and</strong> möglich ist, sind Ansätze gefragt, welche die <strong>Interoperabilität</strong> auch<br />
in den Fällen sicherstellen, bei welchen die Datenmodelle der Beteiligten und deren jeweiligen<br />
Systemen nicht (genau) dieselben sind:<br />
� Diese semantische <strong>Interoperabilität</strong> wird mittels einer Transformation sichergestellt.<br />
Die Formulierung der Transformationsregeln für konkrete Datenmodelle ist<br />
ein Schritt, welcher nicht oder nur sehr beschränkt automatisierbar ist<br />
� Die Abbildungsfunktionen zwischen verschiedenen Modellen (welche jedoch einen<br />
ähnlichen oder gleichen Sachverhalt der Realwelt beschreiben) soll wie die<br />
Datenmodelle selbst mit einem systemunabhängigen Formalismus beschrieben<br />
werden (im Gegensatz zu einer Formatumw<strong>and</strong>lung, welche normalerweise mit<br />
einer Programmier-/Skriptsprache realisiert wird)<br />
� Die Anwendung eines solchen Formalismus soll für den Anwender und Modellierer<br />
möglichst intuitiv sein, wobei eine Unterstützung durch grafische Hilfsmittel<br />
(analog zur Datenmodellierung mit UML) anzustreben ist<br />
� Anbindung von Modellierverfahren und Datenformaten, welche verbreiteten Industriest<strong>and</strong>ards<br />
entsprechen, muss möglich sein und spezifiziert werden (insbesondere<br />
ISO/OGC <strong>Interoperabilität</strong>s-St<strong>and</strong>ards)<br />
Mit einem solchen Werkzeug zur Modellierung von semantischen Transformationen<br />
sind folgende Vorteile und Beispielanwendungen denkbar:<br />
� Formale Spezifikation und Visualisierung von Zusammenhängen zwischen Modellen<br />
für beteilige und verantwortliche Personen<br />
� Automatische Ableitung der für die Datentransformation notwendigen Programme,<br />
Skripte und Instruktionen. Denkbar sind XSLT, SQL-3, iG-Skript und weitere<br />
� Datenportale, welche es dem Kunden ermöglichen eigene Zielmodelle und Transformationen<br />
zu deklarieren und somit die Portalmodelle/-daten automatisch entsprechend<br />
umw<strong>and</strong>eln und ausliefern<br />
Es wäre also wünschenswert, wenn es S<strong>of</strong>twaremittel gäbe, dank denen anspruchsvolle<br />
Umformungen von Daten auf einfache Art definiert und entsprechend zuverlässig ausgeführt<br />
werden könnten.<br />
11.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Modellst<strong>and</strong>ardisierung vs. semantische <strong>Interoperabilität</strong>: Aktuelles aus der Forschung<br />
Bildlich wünscht man sich folgende Situation:<br />
Modelle der<br />
Inputdaten<br />
Min-1<br />
Din-1<br />
Inputdaten<br />
Din-2<br />
Min-2<br />
Modellierung<br />
Transformationsdef.<br />
Man könnte auch formulieren:<br />
Mout = f(Min-1, .., Min-i)<br />
Die Struktur der Inputdaten Din-1 bis Din-i ist durch die Datenmodelle Min-1 bis Min-i beschrieben.<br />
Diejenige der Outputdaten Dout durch das Datenmodell Mout. Die Beschreibung<br />
erfolgt mittels INTERLIS 2 oder einem <strong>and</strong>eren äquivalenten Beschreibungsmittel.<br />
Wie aber beschreibt man die Funktion f?<br />
2 Grundsätzliche Möglichkeiten zur Definition der<br />
Abbildungsfunktion<br />
2.1 Imperative Definition<br />
In vielen Fällen werden solche Datentransformationen mittels Programmiersprachen<br />
definiert.<br />
In einfachen Fällen kommen Skriptsprachen (z.B. PERL) zur Anwendung. Vielfach<br />
kommen aber auch eigentliche Programmiersprachen zum Einsatz. Man schreibt ein<br />
Programm welches die Aufgabe löst.<br />
2.2 Deskriptive Definition<br />
Modell der semant.<br />
Transformation<br />
Mtrf<br />
Transformations-<br />
Engine<br />
Steuerung<br />
Datenfluss<br />
Modell der<br />
veredelten Daten<br />
Oftmals möchte man die Erstellung eines Programms lieber vermeiden. Beschreibungen<br />
wären angenehmer, weil man sich bei ihrer Erstellung nicht um all die Aspekte der Implementierung<br />
kümmern muss.<br />
Einen interessanten Ansatz in diese Richtung bilden die Sichten (Views), wie sie auch in<br />
INTERLIS 2 vorgesehen sind.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 11.3<br />
Maut<br />
Dout<br />
Veredelte Daten
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Modellst<strong>and</strong>ardisierung vs. semantische <strong>Interoperabilität</strong>: Aktuelles aus der Forschung<br />
Gegenst<strong>and</strong> eines aktuellen Forschungsprojektes <strong>IGP</strong>/ETHZ ist die Abklärung der Eignung<br />
eines Formalismus zur Beschreibung der Abbildungsfunktion unter Zuhilfenahme<br />
der Modellierungssprache UML (Unified Modeling Language). UML bietet neben Klassendiagrammen<br />
zur Modellierung von Geodaten auch Diagrammtypen zur Beschreibung<br />
von (dynamischen) Prozessen. Damit lassen sich die Instruktionen, welche für die<br />
Abbildung von einer Datenstruktur auf eine <strong>and</strong>ere notwendig sind, in grafischer und<br />
für den Benutzer einfach verständlicher Form beschreiben.<br />
2.3 Beispiele dazu<br />
2.3.1 Grunddaten<br />
In einer Gegend gibt es – wie überall – Menschen, also entweder Frauen oder Männer.<br />
Das – etwas vereinfachte - Datenmodell dazu:<br />
MODEL Menschen =<br />
TOPIC Menschen =<br />
CLASS Mensch (ABSTRACT) =<br />
Vorname: TEXT*30;<br />
Name: TEXT*100;<br />
Geburtsjahr: 1900..3000;<br />
WohnPos: CHKoord;<br />
END Mensch;<br />
CLASS Frau EXTENDS Mensch =<br />
END Frau;<br />
CLASS Mann EXTENDS Mensch =<br />
END Mann;<br />
END Menschen;<br />
END Menschen.<br />
Nun sollen mögliche Paare gebildet und diese als Daten ausgewiesen werden.<br />
Für die Paare ergibt sich folgendes Modell:<br />
MODEL Paare =<br />
TOPIC Paare =<br />
CLASS Paar =<br />
VornameMann: TEXT*30;<br />
NameMann: TEXT*100;<br />
GeburtsjahrMann: 1900..3000;<br />
VornameFrau: TEXT*30;<br />
NameFrau: TEXT*100;<br />
GeburtsjahrFrau: 1900..3000;<br />
END Paar;<br />
END Paare;<br />
END Paare.<br />
11.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Modellst<strong>and</strong>ardisierung vs. semantische <strong>Interoperabilität</strong>: Aktuelles aus der Forschung<br />
2.3.2 Full-Join (kartesisches Produkt)<br />
Ist man an allen möglichen Paaren interessiert, müsste man folgende Transformation<br />
definieren:<br />
TRANSFORMATION MODEL AllePaare =<br />
IMPORTS Menschen, Paare;<br />
VIEW Paar<br />
JOIN OF M ~ Menschen.Menschen.Mann,<br />
F ~ Menschen.Menschen.Frau;<br />
=<br />
VornameMann: TEXT*30 := M->Vorname;<br />
…<br />
VornameFrau: TEXT*30 := F->Vorname;<br />
END Paar;<br />
MAP Paar TO Paare.Paare.Paar;<br />
END AllePaare.<br />
Eine vergleichbare imperative Definition hätte etwa folgendes Aussehen:<br />
loop M := alle Menschen.Menschen.Mann<br />
loop alle F := Menschen.Menschen.Frau<br />
VornameMann := M->Vorname;<br />
VornameFrau := F->Vorname;<br />
Paare.Paare.Paar kreieren<br />
Attribute darauf kopieren<br />
end<br />
end<br />
Der Unterschied ist <strong>of</strong>fensichtlich relativ klein.<br />
2.3.3 Equi-Join<br />
Ist man an allen Paaren interessiert, bei denen beide Partner im gleichen Jahr geboren<br />
sind, müsste man die Transformation leicht ergänzen:<br />
TRANSFORMATION MODEL GleichaltrigePaare =<br />
IMPORTS Menschen, Paare;<br />
VIEW Paar<br />
JOIN OF M ~ Menschen.Menschen.Mann,<br />
F ~ Menschen.Menschen.Frau;<br />
WHERE M->Geburtsjahr == F->Geburtsjahr;<br />
=<br />
VornameMann: TEXT*30 := M->Vorname;<br />
…<br />
VornameFrau: TEXT*30 := F->Vorname;<br />
END Paar;<br />
MAP Paar TO Paare.Paare.Paar;<br />
END GleichaltrigePaare.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 11.5
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Modellst<strong>and</strong>ardisierung vs. semantische <strong>Interoperabilität</strong>: Aktuelles aus der Forschung<br />
Analog könnte man in der imperativen Definition schreiben:<br />
loop M := alle Menschen.Menschen.Mann<br />
loop alle F := Menschen.Menschen.Frau<br />
if M->Geburtsjahr == M->Geburtsjahr then<br />
VornameMann := M->Vorname;<br />
VornameFrau := F->Vorname;<br />
Paare.Paare.Paar kreieren<br />
Attribute darauf kopieren<br />
end<br />
end<br />
end<br />
Es ist aber <strong>of</strong>fensichtlich, dass dies bei sehr grossen Datenmengen zu erheblichem Aufw<strong>and</strong><br />
führt, auch wenn die Ergebnismenge (also die gefundenen Paare) relativ klein ist,<br />
da nur die gleichaltrigen Menschen als Partner in Frage kommen. Bei jedem Mann werden<br />
alle Frauen angeschaut und dann auf Gleichaltrigkeit geprüft.<br />
Dies führt zu M * F Vergleichsoperationen.<br />
Würde man eine Hilfsstruktur aufbauen, dank der alle Frauen mit einem bestimmten<br />
Geburtsjahr effizient gefunden werden können, könnte das Programm ungefähr so aussehen:<br />
HF := ErzeugeHilfsstruktur (Menschen.Menschen.Frau,<br />
Geburtsjahr)<br />
loop M := alle Menschen.Menschen.Mann<br />
loop alle F := HilfsstrukturAuswahl(HF, M->Geburtsjahr)<br />
VornameMann := M->Vorname;<br />
VornameFrau := F->Vorname;<br />
Paare.Paare.Paar kreieren<br />
Attribute darauf kopieren<br />
end<br />
end<br />
Der Laufzeitaufw<strong>and</strong> würde damit im Prinzip auf M * log(F) sinken und damit auch die<br />
Bearbeitung grosser Datenmengen erlauben.<br />
Eigentlich möchte man sich im Rahmen der Definition einer semantischen Datentransformation<br />
aber nicht um solche Aspekte der Implementierung kümmern. Die deskriptive<br />
Form ist darum vorteilhafter. Allerdings hat sie den Nachteil, dass man dem Transformationsverfahren<br />
einiges aufbürdet, wenn es auf Grund der WHERE-Bedingung erkennen<br />
muss, dass es Optimierungsmöglichkeiten gibt.<br />
Das folgende Beispiel macht dies noch deutlicher.<br />
11.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Modellst<strong>and</strong>ardisierung vs. semantische <strong>Interoperabilität</strong>: Aktuelles aus der Forschung<br />
2.3.4 'Near' - Join<br />
Es besteht ein Interesse an allen Paaren, bei denen die Partner nicht weiter als einen Kilometer<br />
entfernt wohnen.<br />
TRANSFORMATION MODEL UmkreisPaare =<br />
IMPORTS Menschen, Paare;<br />
FUNCTION Distanz(P1: CHKoord; P2: CHKoord): NUMERIC;<br />
VIEW Paar<br />
JOIN OF M ~ Menschen.Menschen.Mann,<br />
F ~ Menschen.Menschen.Frau;<br />
WHERE Distanz(M->WohnPos, F->WohnPos) < 1000.0;<br />
=<br />
VornameMann: TEXT*30 := M->Vorname;<br />
…<br />
VornameFrau: TEXT*30 := F->Vorname;<br />
END Paar;<br />
MAP Paar TO Paare.Paare.Paar;<br />
END UmkreisPaare.<br />
Wie soll das Transformationsprogramm hier eine Optimierungsmöglichkeit erkennen?<br />
Würde man jedoch spezielle Definitionen einführen, bei welchen der Bezug zu den<br />
Grundmengen erkennbar ist und die im Rahmen einer WHERE-Bedingung eingesetzt<br />
werden können, wäre dies wieder einfach:<br />
TRANSFORMATION MODEL UmkreisPaare =<br />
IMPORTS Menschen, Paare;<br />
FUNCTION InnerhalbDistanz<br />
(Basis1: CLASS; P1Attr: ATRIBUTE;<br />
Basis2: CLASS; P2Attr: ATTRIBUTE;<br />
MaxDistanz: NUMERIC): BOOLEAN;<br />
VIEW Paar<br />
JOIN OF M ~ Menschen.Menschen.Mann,<br />
F ~ Menschen.Menschen.Frau;<br />
WHERE InnerhalbDistanz(M, WohnPos,<br />
F, WohnPos, 1000.0);<br />
=<br />
VornameMann: TEXT*30 := M->Vorname;<br />
…<br />
VornameFrau: TEXT*30 := F->Vorname;<br />
END Paar;<br />
MAP Paar TO Paare.Paare.Paar;<br />
END UmkreisPaare.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 11.7
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Modellst<strong>and</strong>ardisierung vs. semantische <strong>Interoperabilität</strong>: Aktuelles aus der Forschung<br />
2.3.5 'Nearest' - Join<br />
Ist man noch restriktiver bei der Paarbildung und bildet Paare nur zwischen der Frau,<br />
die am nächsten bei einem Mann wohnt oder umgekehrt, bleibt die Transformationsbeschreibung<br />
sehr ähnlich.<br />
TRANSFORMATION MODEL NachbarPaare =<br />
IMPORTS Menschen, Paare;<br />
FUNCTION KuerzesteDistanz<br />
(Basis1: CLASS; P1Attr: ATRIBUTE;<br />
Basis2: CLASS; P2Attr: ATTRIBUTE): BOOLEAN;<br />
VIEW Paar<br />
JOIN OF M ~ Menschen.Menschen.Mann,<br />
F ~ Menschen.Menschen.Frau;<br />
WHERE KuerzesteDistanz(M, WohnPos,<br />
F, WohnPos);<br />
=<br />
VornameMann: TEXT*30 := M->Vorname;<br />
…<br />
VornameFrau: TEXT*30 := F->Vorname;<br />
END Paar;<br />
MAP Paar TO Paare.Paare.Paar;<br />
END NachbarPaare.<br />
Will man die Transformation imperativ beschreiben, ist es <strong>of</strong>fensichtlich, dass die Lösung<br />
recht anspruchsvoll ist, wenn sie auch bei grossen Mengen zu vernünftigen Laufzeiten<br />
führen soll.<br />
2.4 Forschungsprojekt 'Neue Ansätze zur konzeptionellen<br />
Beschreibung semantischer Transformationen'<br />
2.4.1 Ausgangslage<br />
Vorgängig wurden die Grundlagen für den Einsatz von Views, welche die Abbildung<br />
von einer Ausgangsdatenstruktur auf eine Zieldatenstruktur leistet, ausführlich eingeführt.<br />
Für einen Anwender, welchem dieses Verfahren nicht aus der Datenbank-Welt<br />
vertraut ist, sind solche Abbildungsdefinitionen nicht ganz einfach zu verstehen und<br />
nachzuvollziehen. Darüber hinaus ist eine intuitive grafische Darstellung, welche den<br />
gleichen Sachverhalt der Transformation wiedergibt, schwierig zu erreichen.<br />
2.4.2 Zielsetzung: grafische Notation und daran angelehnter Formalismus<br />
Neben dem Diagrammtyp 'Klassendiagramm' stellt die grafische Modellierungssprache<br />
UML auch weitere Diagrammtypen zur Verfügung, welche die Erstellung von Modellen<br />
für Prozesse ermöglicht. Da jedoch mit diesen Mitteln die Transformation von Modellen<br />
nicht vollständig ausgedrückt werden kann, muss das Repertoire von UML zu diesem<br />
Zweck erweitert werden. Bei der OMG (Object Management Group), welche für die<br />
Weiterentwicklung von UML zuständig ist, wurde bereits ein Vorschlag für entsprechende<br />
Modellierungselemente eingereicht (MOF Query/Views/Transformations;<br />
UMLX)<br />
11.8 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Modellst<strong>and</strong>ardisierung vs. semantische <strong>Interoperabilität</strong>: Aktuelles aus der Forschung<br />
Für die Darstellung der semantischen Transformation von Geodaten müssen die geeigneten<br />
Diagrammelemente evaluiert und um notwendige Erweiterungen ergänzt werden.<br />
Die Anpassung der UML-Symbolik für eine Anwendungsdomäne (Geoinformatik)<br />
nennt man auch UML-Pr<strong>of</strong>il. Eine Modelltransformation könnte dann wie folgt dargestellt<br />
werden:<br />
Da grafische Darstellungen wie UML nicht direkt maschinell verarbeitbar sind, muss in<br />
Ergänzung dazu ein textueller Formalismus geschaffen werden. Die Realisierung kann<br />
zum Beispiel als Erweiterung von INTERLIS 2 erfolgen. Für Transformationen, bei welchen<br />
der mengenorientierte Zugriff ausreicht, können die Abbildungsvorschriften auch<br />
mittels Views repräsentiert werden.<br />
2.4.3 Implementierung der Transformationsmodelle<br />
Mit der Formulierung von Modellen und Transformationen auf konzeptioneller Ebene<br />
erhalten wir den 'Werkzeugkasten', mit welchem wir die semantische <strong>Interoperabilität</strong><br />
erreichen können. Wir sind damit nicht an ein konkretes GIS-System bzw. Transformationss<strong>of</strong>tware<br />
mit eigener Programmier-/Skriptsprache gebunden.<br />
Ebenso wie wir mit INTERLIS unabhängig vom Transferformat sind (XML, GML, ITF),<br />
lassen sich die Transformationsvorschriften in eine konkrete Transformations- bzw.<br />
Programmiersprache, welche für eine bestimmte Anwendung ideal geeignet ist, umsetzen.<br />
Denkbar wären z.B. SQL, XSLT, XQuery, iG-Skript, FME usw.<br />
Ähnlich wie die Kommunikation der am Daten-Modellierungsprozess beteiligten Experten<br />
durch konzeptionelle und grafische Mittel wie UML stark verbessert wird, macht es<br />
Sinn, die Zusammenhänge und Transformationen zwischen verschiedenen Datenmodellen<br />
(ähnlicher oder gleicher Themenbereiche) explizit zu formulieren. Dies kann mit<br />
einer Programmiersprache allein nicht sinnvoll geleistet werden.<br />
2.5 Folgerungen<br />
Die deskriptive Definition einer semantischen Transformation hat zweifellos Vorteile,<br />
denn sie trennt zwischen Definition und Implementierung.<br />
Um die Ansprüche an die Transformationsprogramme nicht a priori hoch zu schrauben<br />
oder das Risiko einzugehen, dass Optimierungsmöglichkeiten kaum genutzt werden,<br />
macht es Sinn, die Formulierung spezieller Bedingungen durch spezielle Operationen<br />
zu unterstützen. Für solche Operationen ist in den Transformationsprogrammen explizit<br />
entsprechender Code vorzusehen. Es ist aber den Transformationsprogrammen überlassen,<br />
inwiefern sie die Optimierungen auch realisieren.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 11.9
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Modellst<strong>and</strong>ardisierung vs. semantische <strong>Interoperabilität</strong>: Aktuelles aus der Forschung<br />
3 Ein Blick auf INTERLIS 2<br />
Wer INTERLIS 2 präsent hat, hat festgestellt, dass die Sichten 'AllePaare' und 'GleichaltrigePaare'<br />
mit den heutigen INTERLIS 2 – Mitteln formulierbar sind.<br />
Für die Sichten in den Modellen 'UmkreisPaare' und 'NachbarPaare' sowie für eine<br />
durch den Transformator leicht erkennbare 'GleichaltrigePaare'-Sicht ist es nötig IN-<br />
TERLIS 2 um View-Operatoren zu ergänzen. Es kann dazu ein ähnlicher Ansatz verwendet<br />
werden wie bei den bereits vorh<strong>and</strong>enen INTERLIS-Funktionen.<br />
Mit einem Zusatz muss dafür gesorgt werden können, dass aus einer Sicht Objekte gemäss<br />
einer Klasse eines Modells erzeugt werden können.<br />
� Mit einem bescheidenen Ausbau von INTERLIS 2 kann die semantische Datentransformation<br />
mittels INTERLIS 2 beschrieben werden.<br />
Die genaue Definition ist noch Gegenst<strong>and</strong> eines gemeinsamen Projektes.<br />
4 Hauptvorteile<br />
4.1 Kommunikation zwischen Menschen<br />
Mit INTERLIS wurde nebst dem eigentlichen Datentransfer eine gemeinsame Sprache<br />
geschaffen, damit sich Menschen möglichst präzis über die Struktur von Daten unterhalten<br />
können.<br />
Ähnlich könnte mit einem solchen Ansatz auch ein generelles Verständnis aufgebaut<br />
werden, wie man Transformationen von Daten beschreibt.<br />
Wie bei den Datenmodellen dürfte es auch bei den Datentransformationen teilweise anspruchsvoll<br />
sein, die besten geeignete Definition zu finden. Eine gemeinsame Sprache<br />
leistet dabei aber wichtige Dienste.<br />
4.2 Nutzen für Prozessoren<br />
Andere Quellen der<br />
Definition von<br />
Modellen und<br />
Transformationen<br />
Andere Tools<br />
I2-<br />
Modelle<br />
I2-Compiler<br />
Modelle<br />
in XML<br />
UML-Editor<br />
Inputdaten Transformator Outputdaten<br />
11.10 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Modellst<strong>and</strong>ardisierung vs. semantische <strong>Interoperabilität</strong>: Aktuelles aus der Forschung<br />
Der Transformator ist abstrakt gehalten und hat folgende grundlegenden Fähigkeiten:<br />
� Ist in der Lage Daten zu verarbeiten, die INTERLIS 2 – Datenmodellen entsprechen<br />
und kann somit recht anspruchsvolle Datenmodelle unterstützen.<br />
� Ist in der Lage auf eingelesenen Daten mit INTERLIS 2 definierte Sichten aufzubauen<br />
und modellbasierte Datentransformationen auszuführen.<br />
Dabei kann davon ausgegangen werden, dass einfache Datentransformationen direkt<br />
mit einer leicht erweiterten INTERLIS 2 – Beschreibungen definiert und ausgeführt<br />
werden können. Ähnlich zu den in INTERLIS 2 vorgesehenen Funktionen, wird man<br />
jedoch für anspruchsvollere Abbildungen spezifische Operatoren zur Bildung von Sichten<br />
definieren und entsprechend im Transformator codieren.<br />
Die INTERLIS 2 – Modelle (inkl. Transformation) können mit dem UML-Editor oder<br />
<strong>and</strong>eren Werkzeugen erstellt werden und mit dem INTERLIS 2 – Compiler in ein noch<br />
definitiv festzulegendes Format (z.B. in INTERLIS 2 oder XMI) gebracht werden. Alternativ<br />
ist es auch möglich, solche Modell- und Transformationsbeschreibungsdaten mit<br />
<strong>and</strong>eren Werkzeugen (unabhängig von INTERLIS) direkt zu erzeugen. Diese Modellund<br />
Transformationsdefinitionen werden durch den Transformator gelesen. Damit ist<br />
dem Transformator bekannt, wie die Inputdaten zu Outputdaten veredelt werden müssen.<br />
Durch diese klare Trennung der einzelnen Komponenten besteht eine hohe Anpassungsfähigkeit<br />
an verschiedene Bedürfnisse, die sich aus konkreten Systemsituationen<br />
ergeben.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 11.11
Théo Engel, Dr.<br />
SBB-Infrastruktur-Asset Management, Programmanager Fahrstrom<br />
Schanzenstrasse 5<br />
CH-3000 Bern 65<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 51 220 21 80<br />
+41 51 220 39 19<br />
12<br />
Datenmigration UIC<br />
Théophil Engel, UIC / SBB
1 Umfeld<br />
1.1 Übersicht<br />
1.1.1 Einstieg<br />
Der Gleisbau stützt sich schon lange auf Koordinatentrassen. Seit den 90er Jahren sind diese<br />
auch als Grundlage des systematischen Gleisunterhalts im Einsatz und bringen dort bedeutende<br />
finanzielle, technische, allgemein anerkannte Vorteile. Numerische Gleiskoordinaten sind<br />
auch die Basis einer erhöhten <strong>Interoperabilität</strong> aller Infrastrukturanlagen, sowie dank der, von<br />
der europäischen Union postulierte Harmonisierung der Koordinatenreferenzen, l<strong>and</strong>esgrenzenüberschreitend,<br />
eine Grundvoraussetzung ist für erfolgreiche, neue Anwendungsfelder wie z.B.<br />
die satellitenbasierte Navigation der Züge.<br />
1.1.2 Vierzehn Kernsätze<br />
1 Koordinatenbasierte, absolute Gleisedefinition (CNTD) als Grundlage des modernen Gleisbaus<br />
und Gleisunterhaltes //2 UIC-Projekt GEORAIL: Ein weiterer Konsolidationsschritt auf dem<br />
Weg der Einführung absoluter Koordinaten bei der Eisenbahn //3 Definition Bahngeodäsie,<br />
CNTD //4 Die wichtigsten Grundsätze im Umgang mit diesen Kerndaten der Infrastrukturanlagen<br />
//5 Wirtschaftliche und technischen Vorteile absoluter Koordinatentrassen //6 Bedeutung des<br />
Optimierungspotentials dank absoluten Trassenkoordinaten auf der Prozessebene //7 Umfassende<br />
Lösung bedingt grenzüberschreitende Sicht //8 Fundierte Vertiefung zu Fragen der Koordinatenreferenz,<br />
Datenst<strong>and</strong>ardisierung sowie Datenschnittstelle //9 Ansprechpartner von Georail<br />
Phase 2: Gleisbaufirmen, Eurogeographics (Europäische L<strong>and</strong>esvermessungsämter), Forschung,<br />
Gleisbauliteratur //10 UIC interne Absprache mit Projekt Track Machine Guidance //11 Dialog<br />
UIC � Eurogeographics. Ansprechsstelle Eisenbahn für die Eurogeographics? //12 Folgearbeit<br />
auf Steuerebene: UIC-Merkblatt mit Leitbildcharakter //13 Folgearbeit Technik: Nationale Bahnreglemente<br />
und dritte Auflage des Buches „Eisenbahnbau – Wichmann Verlag, 2006-7 //14 Weiterführung<br />
des Georail Gedankengutes durch UIC-Track-Expertengruppe?<br />
1.1.3 Ziel von GEORAIL und Inhalt des Berichtes<br />
Klärung der Grundsatzfragen zum Einsatz von absoluten Koordinaten für die Eisenbahn.<br />
Skizzierung erster Überlegungen, die im Umgang mit Koordinaten der Förderung<br />
der <strong>Interoperabilität</strong> aller Objekte der Infrastruktur dienen.<br />
Das erste Kapitel gibt Einblick in die Thematik Koordinaten bei der Eisenbahn mit<br />
Schwergewicht Gleisanwendungen. Das zweite Kapitel reflektiert die wichtigsten Resultate,<br />
welche im Rahmen des UIC-Projektes bezüglich der Frage der semantischen Transformation.<br />
Das dritte Kapitel zeichnet die weiterführende Stossrichtung auf.<br />
1.2 Historische Entwicklung<br />
Die koordinatenbasiert, kontinuierlich-numerische Trassendefinition, CNTD (engl., continuous<br />
numeric track definition) hat sich in den 90er Jahren als Basis der Gleisarbeiten<br />
durchgesetzt. Grosse Bahnnetze planen deren Einführung oder haben sie bereits hinter<br />
sich. Die Gleismaschinenindustrie steuern damit Gleisbaumaschinen.<br />
Die Schlüsselwörter wirtschaftlicher Gleisarbeiten sind: Einfache Nutzung, (bahn-)<br />
netzweite Einheitlichkeit, operative Präzision und Zuverlässigkeit, keine Spezialtricks<br />
bei der Anwendung. Daraus ergeben sich zwei geodätische Herausforderungen:<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 12.1
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Datenmigration UIC<br />
- Die Harmonisierung der heute europaweit heterogenen, geodätischen<br />
Grundlagen.<br />
- Die Abbildung des (globalen) räumlichen Gleisverlaufs auf die ebenen Pläne.<br />
In der UIC (Union internationales des chemins de fer) sind Gleisarbeiten das Kerngeschäften<br />
des „Track Expert Group“. Klassisch kennen sie keine Koordinaten. Erste Beiträge<br />
für den Einsatz von Koordinaten in den Gleisarbeiten kommen von der Gruppe<br />
6.4 „Track <strong>and</strong> utility lines“ der FIG (Fédération Internationale des Géomètres). FIG 6.4<br />
postuliert den Kontakt zu den Bahnspezialisten: Die Führung gehört langfristig nicht<br />
zur FIG, sondern zur UIC. Der Übergang erfolgt schrittweise:<br />
1990 – Entscheid der FIG zum Einstieg in die Thematik Bahngeodäsie.<br />
1996 – Die Präsidenten der FIG und der UIC erstellen einen ersten Kontakt.<br />
2000 – Die „Track Expert Group“ der UIC übernimmt die Leitung des Koordinatenprojektes<br />
zur Steuerung der Gleisbaumaschinen unter der Führung der schwedischen Bahnen<br />
(BV).<br />
2002 – Beginn des UIC Projektes Georail. Abschluss des FIG Engagements.<br />
2004 – Erste „Open Rail Session“ unter dem Patronat der UIC.<br />
Nebst den Bahnprojektpartnern sind folgende Bereiche in Georail involviert:<br />
- ExG-G (expertgroup geodesy, Arbeitsgruppe Geodäsie) von Eurogeographics<br />
als Vertreter der europäischen L<strong>and</strong>esvermessungsverwaltungen.<br />
In Abstimmung mit der EU-Kommission, legen sie in den 90er Jahren<br />
ETRS89 als europäische Koordinatenbasis fest.<br />
- ISO/TC211 und CEN/TC287 im Bereich der Datenst<strong>and</strong>ardisierung.<br />
- Die Vertreter der Gleisbaumaschinenindustrie Plasser-Theurer und Müller<br />
AG.<br />
- Die Forschung, vertreten durch das Institut für Geodäsie der ETH Zürich<br />
- Die Eisenbahnbauliteratur durch die Hauptverfasser des Buches „Eisenbahnbau“<br />
(G. Müller, Wichmann Verlag, 2000) der Hochschule für Technik<br />
und Wirtschaft in Dresden<br />
1.3 Einige Grundbegriffe<br />
CNTD oder Continuous, Numeric Track Definition ist der englische Begriff für absolute<br />
Gleistrassierung auf der Basis von Koordinaten.<br />
CNTD beschreibt die 3-dimensionale Gleisgeometrie mit mathematisch exakt definierten<br />
Elementen, die nahtlos anein<strong>and</strong>ergeknüpft, die Gleise an jedem beliebigen Punkt in<br />
Lage, Höhe und Überhöhung beschreiben.<br />
Nebst CNTD bilden folgende Elemente die Basis der Bahngeodäsie:<br />
- Die Ordnungsdaten als Schlüssel für die Datenabfrage und –<br />
-<br />
Strukturierung, in Form von eineindeutigen numerischen Streckentrassen.<br />
Netzweit gruppiert, bilden diese, „KM-Achsen“ genannten Trassen, die Streckennetze<br />
der Eisenbahngesellschaften.<br />
Die geodätischen Referenzpunkte. Über diese Punkte sind die Bahndaten<br />
am absoluten Koordinatensystem angebunden. Diese Punkte beinhalten<br />
auch die Funktionalität der Gleisvermarkung, was zu den, im folgenden Abschnitt<br />
beschrieben, Vorteilen führt.<br />
- Die Trassenpunkte und die kritischen Punkte des Lichtraums, welche der<br />
Trassenrechnung zugrunde liegen.<br />
12.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Datenmigration UIC<br />
Bahngeodäsie ist ein Teilfachgebiet der Ingenieurvermessung, das alle Geoinformationen<br />
für die topologische Datenstrukturierung, Verwaltung und interdisziplinäre Nutzung<br />
numerischer Gleistrassen liefert und die damit zusammenhängenden Verfahren<br />
beinhaltet.<br />
Die KM-Achsen bilden den Kern der hierarchisch strukturierten, koordinatengebundenen<br />
Daten der Infrastruktur (Abb. 1.1). Das zweite Niveau um den Kern, beinhaltet die<br />
Gleisdaten. Sie werden von allen Fachdiensten benötigt. Die dritte Schicht umfasst die<br />
wichtigsten Daten der Fachdienste welche auch von den <strong>and</strong>eren Bereichen benutzt<br />
werden und das letzte Niveau beinhaltet die Daten, deren Interessen auf den Fachdienst<br />
beschränkt sind.<br />
Diese Strukturierungsart erlaubt es, den Datenzugriff mittels zwei Koordinatenwerten<br />
durch eine eindimensionale Abfrage über einen KM-Wert zu ersetzen, was einer beträchtlichen<br />
Vereinfachung bezüglich der Organisation der Abfragealgorithmen gleichkommt.<br />
Koordinatenreferenzierte Infrastrukturobjekte,<br />
aufgebaut nach dem Schalenmodell:<br />
Kern: Das Streckennetz mit Knoten (die Betriebspunkte)<br />
und Kanten (die Strecken)<br />
Erste Schale: Das Gleisnetz<br />
Zweite Schale: Die Kern-Fachdienstdaten.<br />
Dritte Schale: Fachdienstdaten mit limitiertem<br />
Interesse<br />
CNTD: Geodätische Referenzpunkte sowie die<br />
Daten von Kern und erster Schale des Schalenmodells<br />
Abb. 1.1 : Hierarchisches Schichtenmodell der koordinatenbasierten Daten der Infrastruktur<br />
1.4 Technische Entwicklung<br />
Die Entwicklung von CNTD ist das Resultat der engen Zusammenarbeit von Fachleuten<br />
aus Vermessung, Bahndienst und Informatik. Die CNTD Entwicklung begann im operativen<br />
Tagesgeschäft der Eisenbahn nach dem „vom Benutzer für den Benutzer“ - Modus.<br />
Drei Jahrzehnte charakterisieren die Entwicklung wie folgt:<br />
- 80er Jahre: Verschiedene Einzelentwicklungen im Bottom-up Verfahren.<br />
- 90er Jahre: Verschiedene Konsolidierungsphasen bei den Bahnen, aber ohne<br />
grenzüberschreitende Koordination.<br />
- Ab 2000: Operative Reife der Systeme mit Erhöhung der Wirtschaftlichkeit<br />
im Gleisbereich. Erste internationale Abstimmungsbestrebungen.<br />
Die Optimierung auf Prozess- und Organisationsebene ist der nächste, wichtige Entwicklungsschritt.<br />
CNTD setzt den Methoden der bisherigen, relativen Gleistrassierung ein Ende.<br />
Diese alten Methoden beruhen alle auf dem Pfeilhöhenprinzip. Mit einer gespannten<br />
Schnur zwischen zwei Bezugspunkten, misst man die Pfeilhöhe eines Kurvenabschnittes<br />
und vergleicht ihn mit einem theoretischen Wert. Ab 1940, beginnen die Bahnen, die<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 12.3
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Datenmigration UIC<br />
Kurven ihres Netzes auf diese Art zu unterhalten. Senkrecht, einen Meter neben den<br />
Gleisen, alle 20m eingeschlagene Gleisstücke, sind die Bezugspunkte der Gleistrassierung,<br />
nachfolgenden Vermarkungspunkte genannt. Die zwischen den Kurven liegenden<br />
Geraden werden in der Regel nicht vermarkt.<br />
Erste Impulse für den Wechsel kommen:<br />
- Von der Gleisbaumaschinenindustrie, welche im Bereich der Automatisierung<br />
der Maschinensteuerung entscheidende Fortschritte macht.<br />
- Von den Bahnen welche beginnen, koordinatenbasierte, numerische Gleistrassen<br />
zu rechnen.<br />
Der Durchbruch erfolgt, durch das Zusammenlegen der Funktionalitäten „Vermarkungspunkt“<br />
und „geodätischer Fixpunkt“. Die Gleismaschinen können, dank den<br />
Fortschritten der automatischen Gleisbaumaschinensteuerung und den koordinatenmässig<br />
definierten Vermarkungspunkten, für jeden Gleispunkt in Echtzeit die IST-Lage<br />
des Gleises bestimmen, sowie die Differenz zwischen der effektiven Gleislage und der<br />
theoretischen Soll-Lage. Das Resultat dient als Steuerwert der Gleismaschinen, dessen<br />
Ermittlung automatisch aus folgenden Grunddaten ermittelt wird:<br />
- Die koordinatenmässig definierten Vermarkungspunkte,<br />
- Die kontinuierlich gerechneten, theoretischen Koordinatentrassen,<br />
- Die netzweit homogenen, eineindeutigen Koordinatenreferenz,<br />
- Die automatisiert ermittelte IST-Lage der Gleise.<br />
Die einführend aufgeführten Grundbedingungen für den automatisierten Einsatz der<br />
Gleismaschinen für den systematischen Unterhalt sind somit vollständig erfüllt: Einfache<br />
Nutzung, bahnnetzweite Einheitlichkeit, operative Präzision und Zuverlässigkeit,<br />
Keine Spezialtricks bei der Anwendung<br />
Dieser Automatisierungsprozess funktioniert heute in der Praxis des Gleisunterhaltes<br />
unterschiedlich.<br />
- Für Vermarkungspunkte die als geodätische Messpunkte materialisiert, auf<br />
den Fahrleitungsmasten fixiert sind, ist die Methodik voll operativ und ausgereift.<br />
- Die Variante, wo nur noch mit Satellitenpositionierung gearbeitet wird, ist<br />
heute erst im Aufbau. Anstelle einer Vermarkung entlang des Gleises gibt es<br />
nur noch alle 2 km einen, mit GPS bestimmten, geodätischen Referenzpunkt<br />
in Gleisnähe. Heute noch nicht gelöste Probleme sind:<br />
� Keine GPS-Signale in den Schattenzonen (z.B. in Tunnels, bei abgedeckten<br />
Bereichen der Bahnhöfe, ...).<br />
� Unzureichende Präzision für kritische Netzteile, z.B.: Komplexe Weichenverbindungen<br />
– häufig die Ein- und Ausfahrten grösserer Bahnhöfe<br />
– feste Fahrbahn und vor allem alle Strecken wo Hochgeschwindigkeit<br />
gefahren wird. Dort müssen repetitiv Absteckgenauigkeiten im mm-<br />
Bereich sichergestellt werden können, währenddem Werte in der Regel<br />
±5mm betragen, um die Vorteile der absoluten Koordinatentrassen voll<br />
nutzen zu können.<br />
Die treibende Kraft zur Harmonisierung der Koordinatenreferenz kommt im Gleisbereich<br />
von den Bedürfnissen der Satellitenpositionierung, wo höchste Genauigkeiten nur<br />
über völlig spannungsfreie Netze erreicht werden können.<br />
12.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
1.5 Gewinnfaktoren<br />
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Datenmigration UIC<br />
Erhöhung der Qualität der Gleislage<br />
Erhöhung der Wirtschaftlichkeit<br />
Datenhierarchie<br />
Funktionale Optimierungen: Prozesssupport<br />
Zusammenfassend: Katalysierender Effekt und Synergien dank Koordinaten<br />
2 Semantische Transformation<br />
Die im zweiten Kapitel beschriebenen Arbeiten, wurde von der ETH Zürich im Rahmen<br />
der UIC-Projektes Georail erbracht.<br />
2.1 Modellierung der Ordnungsdaten<br />
Grundlage für die Modellierung der Ordnungsdaten bilden die Streckenübersichtsdaten<br />
aus der Datenbank der festen Anlagen (DfA) sowie ergänzende Betriebspunktdaten.<br />
Aus diesem relevanten Realitätsausschnitt wird mit der textuellen CSL INTERLIS ein<br />
konzeptionelles Schema erstellt.<br />
2.2 St<strong>and</strong>ardisierung der Ordnungsdaten-Schnittstelle<br />
Mit dem „Compiler“ wird das textuelle Schema geprüft. Sobald diese Konsistenzprüfung<br />
fehlerfrei abläuft, wird daraus die Beschreibung des Transferformats (physisches<br />
Schema) erstellt. Im vorliegenden Beispiel wird das INTERLIS-Transferformat ITF verwendet.<br />
Analog kann jedoch auch das XTF- oder GML-Transferformat erzeugt werden.<br />
Das physische Schema enthält die Information, welches wie die Transferdatei strukturiert<br />
sein muss.<br />
Entsprechend diesem St<strong>and</strong>ardformat werden die Ausgangsdaten nun umstrukturiert.<br />
In den meisten Fällen genügt dazu eine einfache Programmier- oder Skriptsprache, zum<br />
Beispiel awk. Awk ist eine einfache Skriptsprache auf Basis der Mustererkennung, mit<br />
deren Hilfe ASCII-Dateien systematisch auf das St<strong>and</strong>ardformat umgebaut werden<br />
können.<br />
2.3 Visualisierung der Strecken- und Stationsdaten mit Geo-Shop<br />
Die SBB-Streckendaten liegen nun im systemunabhängigen INTERLIS-Transferformat<br />
(ITF) vor. Sie können mit einer S<strong>of</strong>tware, welche INTERLIS unterstützt, visualisiert<br />
werden. Im Folgenden wird dafür „GeoShop“ verwendet, eine S<strong>of</strong>tware, welche auf<br />
systemneutralen St<strong>and</strong>ards basiert (https, Java, INTERLIS). Sie ermöglicht die Bearbeitung<br />
von Geodaten unterschiedlicher Struktur (insbesondere die Visualisierung, die<br />
Verbreitung sowie der Verkauf dieser Daten) über das Intra- oder Internet. Geoshop besteht<br />
aus 3 Modulen:<br />
- Geoshop Server: Dieser zentrale Teil des Programms verwaltet die Geodaten<br />
sowie die Benutzerinformationen<br />
- Geoshop Client Tools: Sie ermöglichen die Visualisierung und Verbreitung<br />
der Daten, wobei vom Kunden einzig ein Java-fähiger Webbrowser benötigt<br />
wird.<br />
- Geoshop Administrator Tools: Sie steuern die Konfiguration des Servers, den<br />
Status von Benutzern und Bestellungen sowie die Darstellung der Geodaten.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 12.5
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Datenmigration UIC<br />
2.4 Modellierung der Fachdienst-Daten: FahrleitungAE<br />
In einem nächsten Schritt geht es darum, den Inhalt von nicht verknüpften Datenbanktabellen<br />
mit Hilfe der modellbasierten Methode gemeinsam nutzbar zu machen, vorausgesetzt<br />
beide Tabellen enthalten mindestens ein gemeinsames Attribut. Als Beispiel<br />
wird für die Fahrleitungsinformationen der SBB, welche zu den Fachdienst-Daten gehören,<br />
aus den Streckenübersichtsdaten die Geometrie hergeleitet.<br />
Die Informationen zu den Fahrleitungen sind in einer Excel-Tabelle enthalten, wobei<br />
jede Zeile einem Fahrleitungsabschnitt entspricht. Die Tabelle enthält für jeden Fahrleitungsabschnitt<br />
Attribute, beispielsweise das Erstelektrifizierungsjahr. Obwohl die Fahrleitungen<br />
einen eindeutigen Raumbezug aufweisen, sind in der Tabelle keine Koordinaten<br />
enthalten. Einzige räumliche Attribute bilden die Kilometrierungswerte (km von,<br />
km bis), welche jeweils Anfang und Ende eines Fahrleitungsabschnittes repräsentieren.<br />
Die Kilometer-Achsen der Streckenübersichtsdaten sind meist in mehrere Fahrleitungsabschnitte<br />
unterteilt, welche jeweils aus einer Vielzahl von minimalen Streckenabschnitten<br />
bestehen.<br />
Baujahr Fahrleitung<br />
BPK von Linie von Fil von LinieKorr km von<br />
Lausanne 100 100 West Lausanne 0.0000<br />
St-Maurice 100 100 West St-Maurice 51564.9400<br />
Sion 100 100 West St-Maurice 92432.0600<br />
Brig 100 100 West Brig 145548.5000<br />
Brig Tunnel 109 109 West Brig 147149.9000<br />
Vevey Ouest (bif) 111 111 West Lausanne 762.5000<br />
BPK bis Linie bis LinieKorr km bis Jahr 1. El.<br />
St-Maurice 100 100 St-Maurice 51564.9400 1924<br />
Sion 100 100 St-Maurice 92432.0600 1923<br />
Brig 100 100 Brig 145548.5000 1919<br />
Iselle di Trasquera 100 100 Brig 167478.3100 1906<br />
Iselle portail tunnel 109 109 Brig 166973.4000 1922<br />
Puidoux-Chexbres 111 111 Lausanne 7829.0000 1940<br />
Abb. 2.1 : Auszug aus der Exceldatei der Fahrleitungsdaten<br />
Die Herleitung von Fahrleitungsdaten und ihrem Verlauf aus Fahrleitungsdaten, die<br />
nur Anfangs- und End-Kilometrierungswerte enthalten, und aus Ordnungsdaten mit<br />
geometrischem Verlauf, ist ein typisches Beispiel für eine semantische Transformation.<br />
Zunächst ist die Ausgangsklasse der Fahrleitungsdaten mit UML und INTERLIS zu beschreiben.<br />
Das gibt eine UML-Klasse „FahrleitungAE“ und eine INTERLIS-Klasse<br />
„Fahrleitung“.<br />
12.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Datenmigration UIC<br />
2.4.1 St<strong>and</strong>ardisierung der Fachdienst-Schnittstelle: FahrleitungAE<br />
Aus dem INTERLIS-Modell kann automatisch die Formatbeschreibung für die Klasse<br />
„FahrleitungAE“ bestimmt werden. Mit einem 1:1 Prozessor werden die Daten der Excel-Tabelle<br />
umgebaut auf das St<strong>and</strong>ardformat ITF.<br />
2.4.2 Modellierung der Fachdienst-Daten: Fahrleitung (mit Verlauf)<br />
Als Zieldatei der semantischen Umformung wollen wir die einfache Klasse „Fahrleitung“<br />
mit nur zwei Attributen definieren: Das Attribut „Erstelektrifizierung“, das aus<br />
der Klasse „Fahrleitung “ übernommen wird, und das Attribut „Verlauf“ vom Typ PO-<br />
LYLINE, das neu berechnet wird aus den Attributen „km_von“ und „km_bis“ der Klasse<br />
„Fahrleitung“ und aus dem Attribut „Verlauf“ der Klasse „Achse“. Das UML-<br />
Diagramm dieser neuen Klasse „FahrleitungAE“ finden wir in Abb. 2.2, ihr INTERLIS-<br />
Datenmodell in Abb. 2.3.<br />
Fahrleitung<br />
Erstelektrifizierung<br />
Abb. 2.2 : Graphisches Datenmodell neue Klasse „Fahrleitung“ (UML-Diagramm)<br />
TABLE Fahrleitung =<br />
Erstelektrifizierung: [1900 .. 2500];<br />
Verlauf: POLYLINE WITH (STRAIGHTS, ARCS) VERTEX Koord2<br />
WITHOUT OVERLAPS > 0.50000;<br />
NO IDENT<br />
END Fahrleitung;<br />
Abb. 2.3 : Neue Klasse „Fahrleitung“ (mit Verlauf), INTERLIS-Modell<br />
2.4.3 Semantische Transformation<br />
Jetzt stehen zur Verfügung: Die Datenmodelle in INTERLIS der Ausgangsdateien „Achse“<br />
(aus 2.4.1) und „FahrleitungAE“ (aus 2.4.2) sowie diejenigen der Zieldatei „Fahrleitung“<br />
(aus 2.4.3) und ferner die Daten von „Achse“ und „Fahrleitung“ im St<strong>and</strong>ardformat<br />
ITF von INTERLIS.<br />
Es gibt S<strong>of</strong>tware-Werkzeuge, wie das INTERLIS-Conversion-System ICS, die es erlauben,<br />
auf konzeptioneller Ebene den Umbau von zwei (oder mehr) gegebenen Klassen in<br />
eine neue Klasse (oder mehrere) zu definieren mit Hilfe der beteiligten Datenmodelle<br />
und mit geeigneten Umbaufunktionen. Die Umbaufunktion die wir brauchen heisst:<br />
Aus den Linien von Klasse „Achse“ Stücke ausschneiden vom Anfangspunkt „km_von“ bis zum<br />
Endpunkt „km_bis“ eines Objektes aus der Klasse „FahrleitungAE“, und diesen Linienausschnitt<br />
zusammen mit dem Wert des Attributes „Jahr_erste_Elektrifizierung“ aus der Klasse<br />
„FahrleitungAE“ abspeichern als neues Objekt der Klasse „Fahrleitung“.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 12.7
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Datenmigration UIC<br />
[……]<br />
TABL Fahrleitung<br />
OBJE 0.0000.0100 1924<br />
STPT 537875.40604 152041.99120<br />
LIPT 537984.59908 152018.12626<br />
ARCP 538041.11107 151980.47901<br />
[..]<br />
ARCP 566299.34338 118421.92351<br />
LIPT 566299.35779 118418.30702<br />
ELIN<br />
[.....]<br />
OBJE 1763.3040.7744 1925<br />
STPT 681720.79964 248756.00813<br />
LIPT 681721.16279 248758.52014<br />
ARCP 681761.91402 248844.22701<br />
[..]<br />
LIPT 683823.44151 247149.25542 0.000 -263.000<br />
LIPT 683786.02309 247064.53648<br />
ELIN<br />
ETAB<br />
[……]<br />
Abb. 2.4 : Auszug aus der ITF-Datei der neuen Klasse „Fahrleitung“ (mit Verlauf)<br />
2.4.4 Visualisierung der Fahrleitungsdaten (mit Verlauf) im Geo-Shop<br />
Diese ITF-Datei der neuen Klasse „Fahrleitung“ (mit Verlauf) kann als Input für den<br />
„GeoShop“ verwenden. Bei der Visualisierung im „GeoShop“ werden die einzelnen Altersklassen<br />
der Fahrleitungsdaten unterschiedlich eingefärbt (Abb. 2.5).<br />
12.8 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
3 Zukunft<br />
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Datenmigration UIC<br />
Abb. 2.5 : Visualisierung der Fahrleitungen im Geoshop (mit Legende)<br />
3.1 Wie weiter? Leitgedanken<br />
3.1.1 Datenrichtigkeit<br />
Voll nutzbar sind koordinatenbasierte Daten nur dann, wenn in allen Bereichen alles<br />
stimmt: Koordinatenreferenz, Datenstruktur, Datenvollständigkeit, Datenrichtigkeit,<br />
Datenkonsistenz, Datentopologie, Netzsicht 100%.<br />
3.1.2 Harmonisierung der Datenstrukturen generell<br />
Harmonisierung von Datenstrukturen als Grundelement des Zusammenpassens von<br />
Daten ist das Fundament der <strong>Interoperabilität</strong>. Die Umsetzung dieser Aufgabe europa-<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 12.9
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Datenmigration UIC<br />
weit sicherzustellen ist eine Kernaufgabe der UIC. Ausgegangen muss immer von den<br />
heutigen, EDV-mässig bereist im Einsatz stehende Datenstrukturen der einzelnen Bahngesellschaften.<br />
Langfristziel ist, eine, von der UIC verabschiedete und von den Bahnen<br />
getragene, europaweite, harmonisierte Datenstruktur. Der Einsatz einer einheitlichen<br />
S<strong>of</strong>tware ist ein erster konkreter Harmonisierungsschritt.<br />
3.1.3 Harmonisierung der Datenstrukturen in angrenzenden, nicht abgestimmten<br />
Zonen<br />
In Grenzgebieten, wo unterschiedliche Netze zusammenkommen und die Bahnen nicht<br />
über die nötigen Ressourcen verfügen, um eine Abstimmungen vorzunehmen, respektive<br />
die technischen Anpassungen zu gross wären, können die Datensätze unverändert so<br />
stehen gelassen werden wie sie sind. Aus den Arbeiten zur Datenmodellierung geht<br />
hervor, dass Daten später immer zusammengebracht werden können. Trotzdem wird<br />
empfohlen, die Strukturen auf ihre Konsistenz hin zu prüfen und Unstimmigkeiten<br />
möglichst früh zu bereinigen.<br />
3.1.4 Übergang zwischen verschiedenen Koordinatensystemen<br />
Damit die Daten in den angrenzenden, nicht harmonisierten Koordinaten zusammengebracht<br />
werden können, müssen entlang der Streckenabschnitte in den Übergangszonen,<br />
Fixpunkte in beiden Systemen gerechnet werden. Aus den zwei Koordinatenpaaren<br />
der identischen Punkte können die Transformationsparameter für den Übergang<br />
vom einem ins <strong>and</strong>ere Systeme gerechnet werden. Der Massstabsfaktor der Transformation<br />
muss immer 1 sein um vor allem bei Konstruktionsteilen wie Weichen, die Massangaben<br />
nicht zu verändern.<br />
3.1.5 Abstimmung mit den Referenznetzen der amtlichen Vermessung<br />
Die Abstimmung bedingt hier zwingend den Dialog zwischen Eisenbahn und amtlicher<br />
Vermessung, um Doppelinvestionen bei der Festlegung des Fixpunktnetzes zu vermeiden.<br />
Es macht Sinn, wenn in den Übgangszonen, nebst den Koordinaten der beiden benachbarten<br />
Systeme als dritte Koordinatenangabe die ETRF89 Werte angebunden werden<br />
und daraus die Transformationswerte errechnet werden.<br />
3.2 Wie weiter? Konkret<br />
Klarheit und Einheitlichkeit bei der Einführung von CNTD, aufbauend auf den bahngeodätischen<br />
Grundlagen dieses Berichtes, soll von Anfang den europäischen Partnerbahnen<br />
der UIC ermöglichen, mit der neuen Koordinatentechnologie die bestmöglichen Resultate<br />
zu erzielen.<br />
Ein Merkblatt soll zuerst für die Bereiche Gleisbau und dann für alle zukünftigen, darauf<br />
aufbauenden Nutzungen, die Stossrichtung vorgeben.<br />
Dank<br />
An alle Mitarbeiter der ETH, der UIC der DB, der SNCF, der SBB welche am Fortschritt<br />
der Themen die in diesem Text erläutert sind gearbeitet haben.<br />
12.10 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Robert Balanche<br />
Seftigenstrasse 164<br />
CH-3084 Wabern<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 31 963 21 11<br />
+41 31 963 22 97<br />
13<br />
Integration der Daten der L<strong>and</strong>eskarte<br />
1:25’000 (VECTOR25) ins Datenmodell<br />
der Amtlichen Vermessung<br />
(DM.01-AV-CH)<br />
Robert Balanche, Eidgenössische<br />
Vermessungsdirektion/swisstopo
1 Einleitung<br />
Die Daten der Amtlichen Vermessung (AV) sind insbesondere seit Beginn der Umsetzung<br />
des Projektes Reform der Amtlichen Vermessung (RAV) immer populärer geworden.<br />
Dies beruht nicht zuletzt auf der seinerseits gewählten Strategie des modellbasierten<br />
Konzeptes für die Verwaltung der numerischen Daten. Es h<strong>and</strong>elte sich damals<br />
noch um eine visionäre Lösung, von welcher wir heute die Früchte « Nutzen und Ertrag<br />
» ernten können.<br />
Aufgrund unseres föderalistischen Systems und der dezentralen Organisationsstruktur<br />
der Amtlichen Vermessung der Schweiz ist der Arbeitsfortschritt bei der Erstellung der<br />
Daten der AV von Kanton zu Kanton und von Region zu Region verschieden. Auch<br />
heute noch sind die Daten der AV nicht flächendeckend über die ganze Schweiz vorh<strong>and</strong>en.<br />
Diese Tatsache führt dazu, dass eine ansehnliche Anzahl von Kunden diese<br />
sehr genauen und zuverlässigen Daten der AV nicht verwendet.<br />
Um dieser fehlenden Flächendeckung begegnen zu können, hat das Departement für<br />
Verteidigung, Bevölkerungsschutz und Sport (VBS) in der Strategie der Amtlichen Vermessung<br />
für die Jahre 2004-2007 mit einer Vision für die Folgejahre 1 im Kontext und im<br />
Zusammenhang mit der Nationalen Geodaten-Infrastruktur (NGDI) folgendes festgelegt:<br />
Die Referenzdaten der NGDI und damit auch die Daten der AV müssen folgende<br />
Voraussetzungen erfüllen:<br />
a. ein Datenmodell ist vorh<strong>and</strong>en,<br />
b. sie liegen flächendeckend vor,<br />
c. es besteht ein öffentliches Interesse,<br />
d. sie entsprechen einer definierten Qualität,<br />
e. die Nachführung ist gesichert und<br />
f. die Finanzierung ist gesichert.<br />
Damit die Voraussetzung b. der Flächendeckung kurzfristig erreicht werden kann, ist es<br />
nötig, einfache provisorische Ersatzprodukte (PEP) zu erstellen.<br />
Provisorische Ersatzprodukte (PEP) sind digitale Vektordaten, welche im Datenmodell<br />
der AV beschrieben und über die Amtliche Vermessungsschnittstelle (AVS) austauschbar<br />
sind. Deren Aktualität, Genauigkeit und Informationsgehalt erfüllen die Anforderungen<br />
der AV nicht. Sie dienen ausschliesslich für die Verwendung der AV als Referenzdaten<br />
für L<strong>and</strong>informationssysteme und nicht für die Bedürfnisse des Grundbuchs.<br />
Die PEP ergänzen die AV in Gebieten, in welchen noch keine AV-Daten oder nur graphische<br />
Grundbuchpläne existieren. Sie können auch die bestehenden Best<strong>and</strong>teile der<br />
digitalen AV-Daten mit fehlenden Informationsebenen oder Themen ergänzen.<br />
Es ist vorgesehen, die PEP für die Informationsebenen „Bodenbedeckung“, „Einzelobjekte“<br />
und „Nomenklatur“ aus bestehenden digitalen Produkten (z.B. VECTOR25 und<br />
SwissNames von swisstopo) abzuleiten.<br />
Die vorliegenden Ausführungen sind der Schnittstelle für die Überführung der Vektordaten<br />
der L<strong>and</strong>eskarte 1 : 25'000 (VECTOR25) ins Datenmodell der Amtlichen Vermessung<br />
(DM.01-AV-CH, Version 24) gewidmet.<br />
1 http://www.swisstopo.ch/data/vd/Documents/Strategie_AV_04_07.pdf<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 13.1
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
2 Vergleich der VECTOR25-Daten mit denjenigen der AV<br />
2.1 Die VECTOR25-Daten<br />
VECTOR25 ist das digitale L<strong>and</strong>schaftsmodell der Schweiz, welches inhaltlich und geometrisch<br />
auf der L<strong>and</strong>eskarte 1 : 25’000 basiert. VECTOR25 gibt die natürlichen und<br />
künstlichen Objekte der L<strong>and</strong>schaft im flexiblen Vektorformat wieder und eignet sich<br />
speziell für den Einsatz in geografischen Informationssystemen (GIS). VECTOR25 beschreibt<br />
rund 8.5 Millionen Objekte mit Lage, Form und ihren Nachbarschaftsbeziehungen<br />
(Topologie) sowie der Objektart und weiteren Sachattributen. Sein Perimeter umfasst<br />
die ganze Schweiz und das angrenzende Ausl<strong>and</strong> entsprechend dem Perimeter der<br />
L<strong>and</strong>eskarte 1 : 25‘000. Die Daten von VECTOR25 werden blattschnittfrei verwaltet. Um<br />
die H<strong>and</strong>habbarkeit der Daten zu gewährleisten, werden extra grosse Objekte (z.B. ausgedehnte<br />
Waldgebiete) an geeigneten Stellen künstlich aufgetrennt.<br />
2.1.1 Struktur von VECTOR25<br />
VECTOR25 besteht aus 9 thematischen Ebenen:<br />
Thematische Ebene Beschreibung<br />
Strassennetz Strassen- und Wegnetz<br />
Eisenbahnnetz Eisenbahnnetz<br />
Übriger Verkehr Fähren, Seilbahnen usw.<br />
Gewässernetz Gewässerachsen und Uferlinien<br />
Primärflächen Primäre Bodenbedeckung (Wald, See usw.)<br />
Gebäude Diverse Gebäudearten<br />
Hecken und Bäume Diverse Objektarten der Vegetation<br />
Anlagen Künstliche Areale und Anlagen<br />
Einzelobjekte Diverse künstliche Objekte<br />
Jede Ebene umfasst Topologietypen (z.B. Linien der Primärflächen). Pro Ebene und Topologietyp<br />
ist ein Attributsatz definiert, der mindestens aus den St<strong>and</strong>ardattributen<br />
(ObjectID, ObjectOrigin, ObjectVal bzw. Objektart, YearOfChange) besteht. VECTOR25<br />
umfasst insgesamt rund 150 unterschiedliche Objektarten (z.B. 2-Klass-Strasse, Bach).<br />
2.1.2 Qualität der VECTOR25-Daten<br />
VECTOR25 zeichnet sich durch folgende Qualitätsmerkmale aus:<br />
� flächendeckend in homogener Qualität und Form<br />
� blattschnittfrei über den gesamten Perimeter<br />
� Lagegenauigkeit: 3-8m (entsprechend der Kartengenauigkeit)<br />
� Topologie ermöglicht Analysen und Simulationen<br />
� Objekte haben geometrische Minimal- und Maximaldimensionen (� erleichterte<br />
H<strong>and</strong>habung)�<br />
� Koordinaten können ohne Topologieverlust auf Meter oder Dezimeter gerundet<br />
werden<br />
� eindeutige und stabile Objektidentifikation (� Voraussetzung für inkrementelle<br />
Nachlieferungen)<br />
� Einfache Struktur (� Transfer / Einsatz auf <strong>and</strong>eren GIS und CAD-Systemen<br />
problemlos möglich).<br />
13.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
2.2 Das Datenmodell der Amtlichen Vermessung<br />
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
Aus dem Projekt « Reform der Amtlichen Vermessung (RAV) » zu Beginn der 90-er-<br />
Jahre ist das erste Datenmodell der Amtlichen Vermessung entst<strong>and</strong>en, das DM93. Dieses<br />
Datenmodell als Best<strong>and</strong>teil der Technischen Verordnung über die Amtliche Vermessung<br />
(TVAV) 2 legte die Minimalanforderungen fest, welche die Kantone bei der Datenerhebung<br />
bezüglich Inhalt und Organisation der Daten einzuhalten hatten. Die meisten<br />
Kantone haben dieses Modell mit kantonalen Anforderungen erweitert; daher basieren<br />
alle Vermessungen ab 1993 auf diesem Modell. Heute erkennt man die grossen Vorteile,<br />
welche schweizweit einheitlich organisierte und strukturierte Daten in einem gemeinsamen<br />
Datenmodell mit sich bringen<br />
Ende der 90-er-Jahre zeigte es sich, dass das Datenmodell der AV überarbeitet und die<br />
Kinderkrankheiten korrigiert werden mussten, damit es den neuen Anforderungen gerecht<br />
werden konnte. So wurde am 18. Dezember 2001 das neue Datenmodell der AV,<br />
das DM.01-AV-CH publiziert. Unglücklicherweise enthielt dieses neue Datenmodell<br />
noch das provisorisch ausformulierte Thema « Gebäudeadressen », da die entsprechende<br />
Schweizer Norm SN 612040 zum Zeitpunkt der Modellerstellung noch nicht vollständig<br />
vorlag. Im Juni 2003 endlich wurde die Schweizer Norm « Gebäudeadressen »<br />
publiziert und zwei Wochen später wurde das Datenmodell DM.01-AV-CH, Version 24,<br />
welches die Vorgaben aus der Norm übernommen hatte, amtlich herausgegeben.<br />
2.2.1 Struktur von DM.01-AV-CH<br />
Die Amtliche Vermessung umfasst die nachstehenden 8 Informationsebenen:<br />
1. Fixpunkte<br />
2. Bodenbedeckung<br />
3. Einzelobjekte<br />
4. Höhen<br />
5. Liegenschaften<br />
6. Rohrleitungen<br />
7. Administrative Einteilungen<br />
Das Datenmodell der Amtlichen Vermessung gliedert sich in die nachstehenden 20<br />
Themen:<br />
1. FixpunkteKategorie1<br />
2. FixpunkteKategorie2<br />
3. FixpunkteKategorie3<br />
4. Bodenbedeckung<br />
5. Einzelobjekte<br />
6. Höhen<br />
7. Nomenklatur<br />
8. Liegenschaften<br />
9. Rohrleitungen<br />
10. Nummerierungsbereiche<br />
11. Gemeindegrenzen<br />
12. Bezirksgrenzen<br />
13. Kantonsgrenzen<br />
14. L<strong>and</strong>esgrenzen<br />
2 http://www.admin.ch/ch/f/rs/c211_432_21.html<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 13.3
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
15. Planeinteilungen<br />
16. TS-Einteilung<br />
17. Rutschgebiete<br />
18. PLZ, Ortschaft<br />
19. Gebäudeadressen<br />
20. Planrahmen<br />
2.2.2 Qualität der Daten der AV<br />
Die Qualitätsanforderungen der Daten der AV sind sehr hoch und werden festgelegt<br />
mit den Informationen über die Genauigkeit und die Zuverlässigkeit. Die Qualitätsanforderungen<br />
richten sich nach der Einteilung in die 5 Toleranzstufen, welche in der<br />
TVAV, Art. 3 wie folgt definiert wurden:<br />
� TS1: Stadtgebiete<br />
� TS2: Überbaute Gebiete und Bauzonen<br />
� TS3: Intensiv genutzte L<strong>and</strong>wirtschafts- und Forstwirtschaftsgebiete<br />
� TS4: Extensiv genutzte L<strong>and</strong>wirtschafts- und Forstwirtschaftsgebiete<br />
� TS5: Das Sömmerungsgebiet und unproduktive Gebiete<br />
Die TVAV definiert in den Art. 28 ff die Genauigkeitsanforderungen je nach Informationsebene<br />
und Toleranzstufe. Man findet dort beispielsweise für die Ebenen « Liegenschaften<br />
» und « Rohrleitungen » die nachstehenden Genauigkeitsanforderungen:<br />
Lagegenauigkeit (St<strong>and</strong>ardabweichung in cm) für einen im Gelände exakt definierten<br />
Punkt:<br />
TS2 TS3 TS4 TS5<br />
3.5 7 15 35<br />
N.B. die TS1 (Stadtgebiete) müssen mindestens die Anforderungen der TS2 erfüllen.<br />
Was die Zuverlässigkeit anbelangt, findet man in Art. 33 der TVAV:<br />
"Die Zuverlässigkeit ist für alle Punkte der Informationsebenen « Fixpunkte », « Liegenschaften<br />
» und für die Hoheitsgrenzen der Informationsebene « Administrative Einteilungen<br />
» sowie für spezielle Einzelpunkte nachzuweisen…<br />
3 Datentransfer von VECTOR25 ins DM.01-AV-CH<br />
3.1 Unterschiede in den beiden Datensätzen<br />
Gemäss der Beschreibung der Datenstruktur von VECTOR25 und den Daten im Datenmodell<br />
der AV gemäss Kapitel 2 erkennt man s<strong>of</strong>ort, dass nicht nur die Objekte verschieden<br />
strukturiert sind, sondern dass auch die Definition der Informationen unterschiedlich<br />
ist. In der Tat, wenn man die Bodenbedeckung etwas genauer unter die Lupe<br />
nimmt, erkennt man, dass die Modellierung derselben Realität unterschiedlich vorgenommen<br />
worden ist. Von Seiten VECTOR25 erhält man z.B. folgende Beschreibung:<br />
Die Ebene „Primärflächen“ beschreibt die primäre topografische Bodenbedeckung. Die Flächenarten<br />
dieser Ebene schliessen sich gegenseitig aus (See und Wald) und bilden ein redundanzfreies,<br />
lückenloses Flächennetz. Im Gegensatz zur L<strong>and</strong>eskarte sind in den Primärflächen interpretierte<br />
Siedlungsgebiete enthalten. Einzelgebäude sind in der Ebene Gebäude verwaltet.<br />
13.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
Die Informationsebene « Bodenbedeckung » ist in Art. 7, Ziff. b der TVAV wie folgt beschrieben:<br />
1. Gebäude;<br />
2. befestigte Flächen unterteilt in: Strasse/Weg, Trottoir, Verkehrsinsel, Bahn,<br />
Flugplatz, Wasserbecken sowie übrige befestigte Flächen;<br />
3. humusierte Flächen unterteilt in: Acker/Wiese/Weide, Intensivkulturen (weiter<br />
unterteilt in Reben und übrige Intensivkulturen), Gartenanlage, Hoch-<br />
/Flachmoor sowie übrige humusierte Flächen;<br />
4. Gewässer unterteilt in: stehendes Gewässer, fliessendes Gewässer sowie Schilfgürtel;<br />
5. bestockte Flächen unterteilt in: geschlossener Wald sowie übrige bestockte Flächen;<br />
6. vegetationslose Flächen unterteilt in: Fels, Gletscher/Firn, Geröll/S<strong>and</strong>, Abbau/Deponie<br />
sowie übrige vegetationslose Flächen.<br />
Zwischen den Informationsebenen der beiden Datensätze erkennt man zwei grosse Unterschiede:<br />
Die Bodenbedeckung gemäss Datensatz von VECTOR25 enthält weder die<br />
Gebäude noch die Strassen. Dies bedeutet, dass diesem Umst<strong>and</strong> beim Transfer der Daten<br />
von VECTOR25 ins Datenmodell der AV Rechnung getragen werden muss. Diese<br />
Elemente müssen <strong>and</strong>ers zusammengefasst und als Gebietseinteilung definiert werden.<br />
Nachstehend ein Beispiel, für welches beim Transfer der Daten eine Lösung gefunden<br />
werden muss.<br />
VECTOR25<br />
Primärflächen<br />
(Gebietseinteilung)<br />
Gebäude<br />
Strassen<br />
(Polyline)<br />
Figur 1 : Unterschiede zwischen der Bodenbedeckung von VECTOR25 und dem DM.01-AV-CH<br />
3.2 Übereinstimmung der Objekte<br />
(Flächen)<br />
DM.01-AV-CH<br />
Bodenbedeckung<br />
(Gebietseinteilung)<br />
Bei der Vorbereitung eines derartigen Datenaustausches muss als einer der ersten<br />
Schritte eine eindeutige Korrespondenztabelle für die Zielobjekte definiert werden. Dies<br />
ist eine relativ schwierige Aufgabe, welche mit dem Kunden klar abgesprochen werden<br />
muss Es kommt dabei vor, dass gewisse Objekte lediglich in einem Datensatz existieren.<br />
Was kehrt man vor, wenn ein Objekt lediglich in den Ausgangsdaten existiert; Soll man<br />
es ignorieren oder dennoch transferieren, um die Information nicht zu verlieren?<br />
Die nachstehenden Tabellen zeigen für jedes Objekt jeder VECTOR25-<br />
Informationsebene das zugeordnete Objekt im Datenmodell DM.01-AV-CH.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 13.5
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
3.2.1 Strassennetz<br />
Vector25.ObjectVal Beschreibung Target->DM01-AV-CH<br />
Autobahn Autobahn Strasse_Weg<br />
Autob_Ri Autobahn richtungsgetrennt Strasse_Weg<br />
Autostr Autostrasse Strasse_Weg<br />
Ein_Ausf<br />
Ein-/Ausfahrt (Autobahn /<br />
Strasse)<br />
Strasse_Weg<br />
A_Zufahrt Autobahnzufahrt Strasse_Weg<br />
1_Klass 1. Klass Strasse Strasse_Weg<br />
2_Klass 2. Klass Strasse Strasse_Weg<br />
3_Klass 3. Klass Strasse Strasse_Weg<br />
4_Klass 4. Klass Strasse Strasse_Weg<br />
5_Klass 5. Klass Strasse schmaler_Weg<br />
6_Klass 6. Klass Strasse schmaler_Weg<br />
Q_Klass Quartierstrasse Strasse_Weg<br />
HistWeg Historischer Weg / Strasse schmaler_Weg<br />
PzPiste Panzerpiste schmaler_Weg<br />
Parkweg Parkweg schmaler_Weg<br />
BrueckLe Alleinstehende Brücke Tunnel_Unterfuehrung_Galerie<br />
GedBruLe<br />
Alleinstehende Brücke gedeckt<br />
Tunnel_Unterfuehrung_Galerie<br />
StegLe Alleinstehender Steg Tunnel_Unterfuehrung_Galerie<br />
3.2.2 Eisenbahnnetz<br />
Vector25.ObjectVal Beschreibung Target->DM01-AV-CH<br />
Gt_Bahn Güterbahn Bahngeleise<br />
I_Geleis Industriegeleise Bahngeleise<br />
MS_Bahn Museumsbahn Bahngeleise<br />
NS_Bahn1 Normalspurbahn eingleisig Bahngeleise<br />
NS_Bahn2<br />
Normalspurbahn<br />
mehrgleisig<br />
Bahngeleise<br />
SS_Bahn1 Schmalspurbahn eingleisig Bahngeleise<br />
SS_Bahn2<br />
Schmalspurbahn mehrgleisig<br />
Bahngeleise<br />
Str_Bahn Strassenbahn Bahngeleise<br />
Str_Bh<strong>of</strong><br />
Streckenverknüpfung innerhalb<br />
des Bahnh<strong>of</strong>areals Bahngeleise<br />
3.2.3 Übriger Verkehr<br />
Vector25.ObjectVal Beschreibung Target->DM01-AV-CH<br />
A_Faehre Aut<strong>of</strong>ähre Faehre<br />
LS_Bahn Luftseilbahn Luftseilbahn<br />
Mat_Bahn Materialbahn Luftseilbahn<br />
P_Faehre Personenfähre Faehre<br />
Skilift Skilift Skilift<br />
13.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
3.2.4 Gewässernetz<br />
Vector25.ObjectVal Beschreibung Target->DM01-AV-CH<br />
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
Bach Bach Rinnsal<br />
Bachachs Bachachse -<br />
Bach_U Bachverlauf unterirdisch eingedoltes_oeffentliches_Gewaesser<br />
Bisse Bisse Rinnsal<br />
Druckl_1 Druckleitung einfach Druckleitung<br />
Druckl_2 Druckleitung mehrfach Druckleitung<br />
Drucksto Druckstollen Druckleitung<br />
Fluss Flussachse -<br />
Fluss_U Flussverlauf unterirdisch eingedoltes_oeffentliches_Gewaesser<br />
Kanal<br />
Bach ohne erkennbare /<br />
eindeutige Fliessrichtung<br />
Rinnsal<br />
Seeachse Seeachse -<br />
Seeinsel Seeinsel -<br />
See Seeufer -<br />
3.2.5 Primärflächen<br />
Vector25.ObjectVal Beschreibung Target->DM01-AV-CH<br />
Z_BaumS Baumschule geschlossener_Wald<br />
Z_Fels Fels Fels<br />
Z_Fluss Fluss fliessendes<br />
Z_Gebue Gebüsch uebrige_bestockte<br />
Z_GerGeb Geröll mit Gebüsch Geroell_S<strong>and</strong><br />
Z_GerGle Geröll auf Gletscher Geroell_S<strong>and</strong><br />
Z_Geroel Geröll Geroell_S<strong>and</strong><br />
Z_GerWa Geröll in Wald Geroell_S<strong>and</strong><br />
Z_GerWaO Geröll in <strong>of</strong>fenem Wald uebrige_bestockte<br />
Z_Glet Gletscher Gletscher_Firn<br />
Z_GsPist Graspiste Strasse_Weg<br />
Z_HaPist Piste mit Hartbelag Strasse_Weg<br />
Z_KiGrub Kiesgrube Abbau_Deponie<br />
Z_LeGrub Lehmgrube uebrige_vegetationslose<br />
Z_ObstAn Obstanlage uebrige_humusierte<br />
Z_Reben Reben Reben<br />
Z_See See stehendes<br />
Z_Siedl Siedlung uebrige_vegetationslose<br />
Z_StauDa Staudamm* uebrige_vegetationslose<br />
Z_StauMa Staumauer* Fels<br />
Z_SteBru Steinbruch Abbau_Deponie<br />
Z_SumGeb Sumpf und Gebüsch uebrige_humusierte<br />
Z_Sumpf Sumpf uebrige_humusierte<br />
Z_SumWa Sumpf in Wald uebrige_bestockte<br />
Z_SumWaO Sumpf in <strong>of</strong>fenem Wald uebrige_humusierte<br />
Z_Uebrig Übriges Gebiet Acker_Wiese_Weide<br />
Z_Wald Wald geschlossener_Wald<br />
Z_WaldOf Wald <strong>of</strong>fen uebrige_bestockte<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 13.7
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
3.2.6 Gebäude<br />
Vector25.ObjectVal Beschreibung Target->DM01-AV-CH<br />
Z_Gebaeude Gebäude / Einzelhaus Gebaeude<br />
Z_Innenh<strong>of</strong> Innenh<strong>of</strong> uebrige_befestigte<br />
Z_Gasth<strong>of</strong> Abgelegener Gasth<strong>of</strong> Gebaeude<br />
Z_Huette Hütte Gebaeude<br />
Z_Kirche Kirche Gebaeude<br />
Z_Kuehlturm Kühlturm Silo_Turm_Gasometer (EO)<br />
Z_Lagertank Lagertank Gebaeude<br />
Z_Perron Perrondach Bahnsteig (EO)<br />
Z_Schiessst<strong>and</strong> Schiessst<strong>and</strong>, Schützenhaus Gebaeude<br />
Z_Schloss Schloss, Burg Gebaeude<br />
Z_Station Station / ÖV Haltestelle Unterst<strong>and</strong><br />
Z_Treibhaus Treibhaus Unterst<strong>and</strong><br />
Z_WBecken<br />
Wasserbecken (Schwimmbäder,<br />
ARA)<br />
Wasserbecken<br />
3.2.7 Hecken und Bäume<br />
Vector25.ObjectVal Beschreibung Target->DM01-AV-CH<br />
BauReihe Baumreihe schmale_bestockte_Flaeche<br />
Hecke Hecke schmale_bestockte_Flaeche<br />
OBReihe Obstbaumreihe schmale_bestockte_Flaeche<br />
EinBaum Einzelbaum wichtiger_Einzelbaum<br />
ObstBaum Obstbaum wichtiger_Einzelbaum<br />
3.2.8 Anlagen<br />
Die Ebene Anlagen umfasst die Objektarten Bahnh<strong>of</strong>areal, Flughafenareal und Flughafenbahnh<strong>of</strong>-areal.<br />
Da für diese Objekte keine entsprechenden Elemente im Datenmodell<br />
DM.01-AV-CH existieren, werden sie nicht erfasst.<br />
3.2.9 Einzelobjekte<br />
Vector25.ObjectVal Beschreibung Target->DM01-AV-CH<br />
Antenne Antenne Mast_Antenne<br />
ARA Abwasserreinigungsanlage weitere<br />
AusTurm Aussichtsturm Aussichtsturm<br />
BiStock Bildstock /Wegkreuz Bildstock_Kruzifix<br />
Brunnen Brunnen Brunnen<br />
Denkmal Denkmal Denkmal<br />
Doline Doline weitere<br />
Drehsch Drehscheibe Aussichtsturm<br />
ElWerk Elektrizitätswerk weitere<br />
Hoehle Höhle / Grotte Grotte_Hoehleneingang<br />
Kamin Hochkamin Hochkamin<br />
Kapelle Kapelle Bildstock_Kruzifix<br />
KiTurm Kirchturm uebriger_Gebaeudeteil<br />
Quelle Quelle Quelle<br />
Reserv Reservoir Reservoir<br />
Schiffst Schiffstation L<strong>and</strong>ungssteg<br />
SendeAnl Sendeanlage Mast_Antenne<br />
13.8 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
Turm Turm Aussichtsturm<br />
W_Turm Wasserturm Aussichtsturm<br />
WaFall Wasserfall weitere<br />
ZistOff Zisterne <strong>of</strong>fen Reservoir<br />
HSP_Ltg Hochspannungsleitung Hochspannungsfreileitung<br />
Ruine Ruine Ruine_archaeologisches_Objekt<br />
Sender Radiosender Mast_Antenne<br />
3.3 Datentransfer<br />
Wenn die Korrespondenztabellen ausgearbeitet worden sind, « genügt es », das Interface<br />
für den Transfer all dieser Objekte von VECTOR25 nach MD.01-AV-CH zu schreiben.<br />
Dazu benötigt man ein Werkzeug, mit welchem die Parameter so gesetzt werden<br />
können, dass jedes Element aus VECTOR25 in die richtige Ebene von MD.01-AV-CH<br />
transferiert wird. Die Erarbeitung eines solchen Interfaces kann nicht über St<strong>and</strong>ard-<br />
Konversions-Werkzeuge erfolgen. Es bleibt einem nichts <strong>and</strong>eres übrig, als sich mit dem<br />
Quellcode ausein<strong>and</strong>erzusetzen und dieses Interface teilweise selbst zu programmieren.<br />
Nachstehend ein Auszug des notwendigen Skripts für die Erstellung eines solchen Interfaces<br />
mittels des Werkzeuges « ilitools ».<br />
Für dieses Interface, welches für die Modellierung in den Sprachen Französisch,<br />
Deutsch und Italienisch vorgesehen ist, war es notwendig, eine « Namens- und Attribut-<br />
Tabelle » zu erstellen, so dass das Skript lediglich einmal beschrieben werden musste.<br />
Am Anfang des Programmes wird ein Konfigurationsfile gelesen, welches die Zuordnung<br />
des gewünschten Modells definiert.<br />
Auszug aus der deutschsprachigen Namenstabelle der Primärflächen von VECTOR25 :<br />
MAP PRI<br />
LANG => D<br />
TOPIC => Bodenbedeckung<br />
TABLE => ProjBoFlaeche<br />
TABLE_NACH => BBNachfuehrung<br />
TABLE_SURFACE => ProjBoFlaeche_Geometrie<br />
OTHER => PEP<br />
Z_GERGEB_VAL => vegetationslos.Geroell_S<strong>and</strong><br />
Z_GERGEB => Z_GerGeb_X-Z_GerGle_X-Z_Geroel_X-Z_GerWa_X<br />
Z_FELS_VAL => vegetationslos.Fels<br />
Z_FELS => Z_Fels_X-Z_StauMa_X<br />
Z_FLUSS_VAL => Gewaesser.fliessendes<br />
Z_FLUSS => Z_Fluss_X<br />
Z_GEBUE_VAL => bestockt.uebrige_bestockte<br />
Z_GEBUE => Z_Gebue_X-Z_GerWaO_X-Z_SumWa_X-Z_WaldOf_X<br />
Z_GLET_VAL => vegetationslos.Gletscher_Firn<br />
Z_GLET => Z_Glet_X<br />
Z_KIGRUB_VAL => vegetationslos.Abbau_Deponie<br />
Z_KIGRUB => Z_KiGrub_X-Z_SteBru_X<br />
Z_SEE_VAL => Gewaesser.stehendes<br />
Z_SEE => Z_See_X<br />
Z_SUMPF_VAL => humusiert.uebrige_humusierte<br />
Z_SUMPF => Z_Sumpf_X-Z_ObstAn_X-Z_SumGeb_X-Z_SumWaO_X<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 13.9
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
Z_WALD_VAL => bestockt.geschlossener_Wald<br />
Z_WALD => Z_Wald_X-Z_BaumS_X<br />
Z_SOLD_VAL => vegetationslos.uebrige_vegetationslose<br />
Z_SOLD => Z_Siedl_X-Z_LeGrub_X-Z_StauDa_X<br />
Z_UEBRIG_VAL => humusiert.Acker_Wiese_Weide<br />
Z_UEBRIG => Z_Uebrig_X<br />
Z_BEFESTIGT_VAL => befestigt.Strasse_Weg<br />
Z_BEFESTIGT => Z_GsPist_X-Z_HaPist_X<br />
Z_REBEN_VAL => humusiert.Intensivkultur.Reben<br />
Z_REBEN => Z_Reben_X<br />
TMP<br />
END_MAP !PRI<br />
=> 1.0<br />
Auszug aus dem Skript:<br />
Kategorienwahl:<br />
! Here the Category who are inserted into Geroell_S<strong>and</strong> (BB)<br />
IF PRI.Z_GERGEB SHPIN_REC.objectval LOC IS_NOT_NULL THEN<br />
PRI.Z_GERGEB_VAL => VAR.ART<br />
PRI_SURFACE<br />
END_IF<br />
…<br />
PROCEDURE PRI_SURFACE<br />
!***********************************************************<br />
! Write the Object <strong>and</strong> the geometry for the category PRI<br />
!***********************************************************<br />
IF PRI.LANG = 'F' THEN<br />
VAR.ART => OUT.Genre<br />
ELSE<br />
VAR.ART => OUT.Art<br />
END_IF<br />
NEXT_OBJID => OUT.OBJID<br />
ILOUT_WRITE_OBJECT<br />
PRI.TABLE_SURFACE<br />
ILOUT_WRITE_SURFACE<br />
END_PROCEDURE !PRI_SURFACE<br />
13.10 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
3.4 Festgestellte Probleme<br />
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
3.4.1 Topologische Unterschiede<br />
Bevor die Daten gemäss den obigen Tabellenzuordnungen transferiert werden können,<br />
sind die topologischen Unterschiede zu untersuchen. In der Tat, wie bereits im Kapitel<br />
3.1. angesprochen, unterscheiden sich die Primärflächen des Produktes VECTOR25 und<br />
die Informationsebene Bodenbedeckung der AV.<br />
Eine der Schwierigkeiten betrifft die Informationen des Strassennetzes von VECTOR25.<br />
Diese sind in VECTOR25 als lineare Strassenachsen definiert, während die Strassen in<br />
der AV als flächenartige Information im DM.01-AV-CH ausgeschieden werden. Die<br />
Strassenbreiten sind a priori, ausgehend von der Information Strassenachse, nicht bekannt;<br />
man ist vielmehr gezwungen, diese Informationen der Zeichenerklärung zur<br />
L<strong>and</strong>eskarte 1 : 25'000 von swisstopo zu entnehmen, wo für jede Strassenklassierung<br />
eine bestimmte Mindestbreite vorgegeben wird. Durch diese zusätzliche attributive Information<br />
von VECTOR25 kann jedem Strassenelement eine bestimmte Breite zugeordnet<br />
werden und daraus können flächenhafte Objekte gebildet werden.<br />
Gemäss Flyer « Zeichenerklärung » zu den L<strong>and</strong>eskarten sind die Strassenklassierungen<br />
wie folgt definiert:<br />
� 1- Kl.-Strasse, (mind. 6m breit)<br />
� 2- Kl.-Strasse, (mind. 4m breit)<br />
� Quartierstrasse, (mind. 4m breit)<br />
� 3-Kl.-Strasse, (mind. 2,8m breit)<br />
� 4- Kl. Fahrweg (mind. 1,8m breit)<br />
� 5-Kl. Feld-, Wald-, Veloweg<br />
� 6- Kl.., Fussweg<br />
Die 5-Kl. und 6-Kl.-Objekte werden als Wege mit linearer Geometrie in die Informationsebene<br />
« Einzelobjekte » transferiert<br />
Die Strassenverbreiterungen, ausgehend von den linearen Objekten, und die Erstellung<br />
von gebietseinteilenden Flächenobjekten erfolgt mit konventionellen GIS-St<strong>and</strong>ard-<br />
Werkzeugen.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 13.11
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
0 25 50 75 100 125 Meter<br />
Figur 2 : Transformation des linearen Strassennetzes in « gebietseinteilende » Flächenelemente<br />
3.4.2 Generalisierung der Daten<br />
Die VECTOR25-Daten stammen aus der Digitalisierung der L<strong>and</strong>eskarten 1 : 25'000, einem<br />
kartographischen Produkt mit generalisierten Informationen. Es ist nicht möglich,<br />
ausgehend von diesen generalisierten Informationen, die Bedürfnisse der AV oder der<br />
provisorischen Ersatzprodukte (PEP) abdecken zu können. Es ist vielmehr nötig, dazu<br />
auf weitere Grundlagedaten zurückzugreifen, z.B. durch die Verwendung der Informationen<br />
für das Strassennetz, welche mittels des Programmes ATOMI von swisstopo aus<br />
den digitalen Orth<strong>of</strong>otos gewonnen werden.<br />
ATOMI ist ein Programm für die automatische Extraktion dreidimensionaler Strassenachsen<br />
aus Orth<strong>of</strong>otos, dem digitalen Geländemodell sowie dem bereits vorh<strong>and</strong>enen<br />
vektoriellen Strassennetz aus VECTOR25. Die nachstehende Figur 3 zeigt die Überlagerung<br />
der Informationen von VECTOR25 und ATOMI:<br />
13.12 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
Figur 3 : Überlagerung der VECTOR25-Daten mit denjenigen aus ATOMI<br />
0 25 50 75 100 125 Meter<br />
Diese Lösung verbessert die Qualität des Strassennetzes ganz erheblich, bringt jedoch<br />
weitere Probleme. Dadurch, dass die Strassen nun « geometrisch richtig » erfasst sind,<br />
stellt man fest wie die Gebäude diese Strassen zum Teil überlappen. Zur Lösung dieses<br />
Konfliktes sind mehrere Varianten möglich:<br />
� Man belässt die Originaldaten aus VECTOR25 ohne Verwendung der Strassen-<br />
Informationen aus ATOMI,<br />
� Man verwendet die Strassenauswertungen aus ATOMI und belässt die aus<br />
VECTOR25 erfassten Gebäudeinformationen, auch wenn diese die Strassen<br />
überlappen,<br />
� Man verwendet die Strassenauswertungen aus ATOMI und korrigiert die aus<br />
VECTOR25 erfassten Gebäude so, dass man einen kohärenten und realistischen<br />
Datensatz erhält. Der dafür notwendige Aufw<strong>and</strong> ist jedoch nicht zu vernachlässigen.<br />
Man kann feststellen, dass die Verbesserung von Datensätzen unweigerlich <strong>and</strong>ere<br />
Probleme oder Diskrepanzen aufwerfen. Dabei wird man jedoch auch mit der Kosten-<br />
Nutzen-Frage konfrontiert und man wird gezwungen, eine entsprechende Wahl zu treffen!<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 13.13
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
Der ganze Prozess kann wie folgt zusammengefasst werden:<br />
Beh<strong>and</strong>lung<br />
manuell<br />
3.5 Schlusskontrollen<br />
VECTOR25 ATOMI<br />
Vorbereitung<br />
der Daten<br />
nein<br />
Interface<br />
Resultat<br />
ja<br />
DM.01<br />
Vorbereitung<br />
der Daten<br />
Figur 4 : Integrationsprozess von verschiedenen Datenquellen<br />
Nachdem man die Vorgehenswahl getr<strong>of</strong>fen hat und die Daten transferiert worden<br />
sind, ist die Integrität der daraus resultierenden Daten zu überprüfen. Die AV verlangt<br />
eine hohe Qualität der Daten und exakt einzuhaltende Anforderungen, die mit entsprechenden<br />
Werkzeugen geprüft werden. Daher kann nach erfolgreich durchgeführtem<br />
Datentransfer ein INTERLIS-file im Datenmodell DM.01-AV-CH generiert werden, welches<br />
mit einem entsprechenden Checker geprüft wird. Dabei stellt man fest, dass im so<br />
neu erzeugten Datensatz noch viele Fehler und Ungereimtheiten existieren. Nachstehend<br />
einige Beispiele mit den von uns festgestellten Fehlern:<br />
Figur 5 : Ein einziges Zentroïd für 2 verschiedene Flächen<br />
Beh<strong>and</strong>lung<br />
manuell<br />
13.14 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten<br />
nein
Figur 8 : No area found for<br />
centroid<br />
Figur 6 : Resultierende Fläche sehr klein<br />
Figur 7 : Fehlende Punkte: noch zu erzeugen<br />
Figur 9 : Area with unknown<br />
centroid<br />
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
Figur 10 : Area with "n"<br />
centroids<br />
Figur 11 : duplicate line Figur 12 : Intersection Figur 13 : partial line overlap<br />
Figur 14 : full line overlap<br />
Für die Elimination obiger Fehler sind entweder weitere Routinen zu programmieren,<br />
welche diese Unzulänglichkeiten erkennen und beheben, oder es bedarf manueller Korrektureingriffe<br />
zur Erstellung eines kohärenten Datensatzes, welcher die Anforderungen<br />
der AV erfüllt. Auch nach der Vornahme dieser weiteren Verbesserungen gilt es<br />
abzuwägen, inwieweit das entst<strong>and</strong>ene Endprodukt den Bedürfnissen des provisorischen<br />
Ersatzproduktes gerecht wird. Können die geringere Qualität und die noch<br />
verbleibenden « Ungereimtheiten » akzeptiert werden?<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 13.15
Nächste Schritte in der <strong>Interoperabilität</strong><br />
Integration Vector25 / AV<br />
4 Schlussfolgerungen<br />
Der Datentransfer von VECTOR25 ins Datenmodell DM.01-AV-CH zeigt, wie wichtig, ja<br />
unerlässlich eine Datenbeschreibung ist. Wenn ein Datensatz weder über ein Datenmodell<br />
noch über eine klare Datenbeschreibung verfügt, ist es praktisch unmöglich, diese<br />
Informationen für verschiedene <strong>and</strong>ere Zwecke verwenden zu können. Sie sind nicht<br />
mehr „interoperabel“!<br />
Eine gute Datenbeschreibung reicht für die <strong>Interoperabilität</strong> jedoch noch nicht aus. Für<br />
die <strong>Interoperabilität</strong> der Daten bedarf es auch einer exakten Analyse, nicht nur des Datenmodells<br />
aber auch der Semantik.<br />
Man kann feststellen, dass die technische <strong>Interoperabilität</strong> weniger Probleme aufwirft<br />
als die semantische <strong>Interoperabilität</strong>. In der Tat muss man festhalten, dass der ursprünglich<br />
erfasste Datensatz für ein bestimmtes, festgelegtes Bedürfnis angelegt worden ist.<br />
Wenn man ihn nachher für <strong>and</strong>ere als die ursprünglich vorgesehenen Zwecke verwendet<br />
will, riskiert man, dass die Anforderungen des ursprünglichen Datensatzes nicht<br />
mehr denjenigen des zweiten entsprechen.<br />
Die semantische <strong>Interoperabilität</strong> umfasst auch die sprachlichen Probleme. Wenn beispielsweise<br />
die beiden Datensätze in verschiedenen Sprachen festgelegt worden sind,<br />
muss auch die Korrespondenz von Ausdrücken und Definitionen festgelegt werden. Ein<br />
technisches Wörterbuch ist bei der Festlegung des Datensatzes in einer Fremdsprache<br />
eine grosse Hilfe.<br />
Die <strong>Interoperabilität</strong> von Daten ist eine Notwendigkeit und ein unerlässliches Werkzeug<br />
für eine effiziente Nutzung von Informationen, insbesondere von geographischen Informationen.<br />
Literatur<br />
� Strategie der Amtlichen Vermessung für die Jahre 2004 bis 2007 mit Vision für<br />
die Folgejahre, Eidgenössisches Departement für Verteidigung, Bevölkerungsschutz<br />
und Sport, Bundesamt für L<strong>and</strong>estopografie, Eidgenössische Vermessungsdirektion.<br />
� VECTOR25. Das digitale L<strong>and</strong>schaftsmodell der Schweiz, Bundesamt für L<strong>and</strong>estopografie.<br />
� Transfert des données de VECTOR25 dans le MD.01, Semesterarbeit, A.<br />
WILDBOLZ, EIVD 2004.<br />
� «Interlis Tools», Dokumentation der Firma Infogrips GmbH.<br />
13.16 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
KOGIS<br />
Rolf Buser, Dipl. Ing. ETH<br />
Koordinationsstelle GI & GIS (KOGIS)<br />
c/o Bundesamt für L<strong>and</strong>estopografie / swisstopo<br />
Seftigenstrasse 264<br />
CH-3084 Wabern<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 31 963 24 03<br />
+41 31 963 23 25<br />
14<br />
Nationale Geodaten-Infrastruktur<br />
(NGDI)<br />
Organisatorische Aspekte der<br />
<strong>Interoperabilität</strong> beim Bund<br />
Rolf Buser, Stv. Leiter KOGIS<br />
Koordinationsstelle GI & GIS des Bundes
Unter der Nationalen Geodaten-Infrastruktur (NGDI) wird gemäss der Strategie1 und<br />
dem Umsetzungskonzept2 zur Strategie für Geoinformation beim Bund “… ein von allen<br />
für die Bereitstellung von Geobasisdaten Verantwortlichen gemeinsam entwickeltes, genutztes<br />
und fortgeführtes System von politischen, institutionellen und technologischen Massnahmen<br />
verst<strong>and</strong>en. Dieses System stellt sicher, dass Verfahren, Daten, Technologien, St<strong>and</strong>ards, rechtliche<br />
Grundlagen, finanzielle und personelle Ressourcen zur Gewinnung und Nutzung von Geoinformationen<br />
ziel- und bedarfsorientiert den beteiligten Verwaltungen, Organisationen und<br />
Bürgern auf allen Entscheidungsebenen (lokal, regional und national) zur Verfügung gestellt<br />
werden können.“<br />
Diese Umschreibung der NGDI zeigt auf, dass hier eine Infrastruktur entwickelt werden<br />
soll, welche hochgradig interoperabel sein muss. Interoperabel einerseits auf der politischen,<br />
organisatorischen und institutionellen Ebene, <strong>and</strong>ererseits auf der technischen,<br />
also der Daten- und Systemebene. Die technische Ebene bringt durch die schnelle Entwicklung<br />
der Internettechnologien immer bessere Lösungen. Auf dieser Ebene liegt jedoch<br />
auch beim Bund weniger das Problem. Technisch lässt sich schon vieles realisieren<br />
und es stehen schon gute Lösungen bereit.<br />
Auf der politischen, organisatorischen und institutionellen Ebene stehen wir hingegen<br />
bezüglich <strong>Interoperabilität</strong> im Geoinformationsbereich am Anfang.<br />
Nachfolgend werden einige organisatorische Aspekte beim Bund im Bereich der NGDI<br />
bezüglich <strong>Interoperabilität</strong> kurz dargelegt.<br />
Kontaktnetz<br />
Auf dem Weg zu einer NGDI muss die politische, organisatorische und institutionelle<br />
<strong>Interoperabilität</strong> der technischen vorausgehen. Eine gemeinsame Strategie, verbindliche<br />
Verfahren, eindeutige Begriffe, sowie genau abgestimmte Forderungen und Erwartungen<br />
der beteiligten Partner und Institutionen sind nötig. Eine umfassende und stetige<br />
„interpersonale“ Kommunikation und der Einbezug von Informationsgemeinschaften<br />
sind unabdingbar. Mit der konstituierenden Sitzung für das Kontaktnetz e-geo.ch im<br />
Januar 2005 ist ein erster Schritt in Richtung politischer, organisatorischer und institutioneller<br />
<strong>Interoperabilität</strong> getan. Das Kontaktnetz soll unter Berücksichtung oder gar<br />
Stärkung föderaler Strukturen und heterogener Systeme umgesetzt werden und wird<br />
durch ein Steuerorgan geleitet, in welchem sowohl alle Verwaltungsebenen als auch Institutionen<br />
und die Privatwirtschaft vertreten sind.<br />
Die neu gebildete Geschäftsstelle des Kontaktnetzes, welche vorerst vom Bund finanziert<br />
wird, bildet das Sekretariat des Steuerungsorgans und betreut in erster Linie die<br />
Aufgaben, welche ihr vom Steuerungsorgan anvertraut werden.<br />
Geobasisdaten und Geobasisdienste<br />
Mit höchster Priorität muss festgelegt werden, „WAS“ die Inhalte der NGDI Schweiz<br />
sind. d.h. welche Daten und Dienste die NGDI bereitstellen muss. Hier werden die oben<br />
erwähnten Informationsgemeinschaften eine entscheidende Rolle spielen. Innerhalb von<br />
eindeutig definierten Tätigkeitsbereichen (z.B. Raumplanung) müssen gemeinsame Vorstellungen<br />
über Modelle von Geobasisdaten- und Geobasisdiensten entwickelt werden.<br />
Nur dadurch kann die <strong>Interoperabilität</strong> auf der Datenebene und später bei angebotenen<br />
1 Strategie für Geoinformation beim Bund, GKG-KOGIS 2001, www.kogis.ch<br />
2 Umsetzungskonzept zur Strategie für Geoinformation beim Bund, GKG-KOGIS 2003, www.kogis.ch<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 14.1
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
Nationale Geodaten-Infrastruktur (NGDI): Organisatorische Aspekte der <strong>Interoperabilität</strong> beim Bund<br />
Diensten erfolgreich sein. Mit der Erstellung des Geobasisdaten-Katalogs des Bundes ist<br />
ein erster Schritt getan. Auf der Basis dieses Katalogs kann die Diskussion über Informationsgemeinschaften<br />
geführt werden.<br />
Beim Bund geht es auf organisatorischer Ebene primär darum, vorh<strong>and</strong>ene Informationsgemeinschaften<br />
für diese neuen Aufgaben zu motivieren oder den Aufbau von neuen<br />
Informationsgemeinschaften zu unterstützen. Weiter müssen die Entscheidungsträger<br />
für diese Bereiche sensibilisiert werden.<br />
Der Bund will grundlegende Geodienste bereitstellen und vernetzen. KOGIS koordiniert<br />
die Umsetzung der bundesweiten Plattform, welche auf „produktiven“ Normen<br />
basiert, wie jene, die aus den Arbeiten von SNV (Schweizerische Normen-Vereinigung)<br />
und OGC (Open Geospatial Consortium) hervorgegangen sind.<br />
Auf der organisatorischen Seite muss diskutiert werden, wie ein Register der Geobasisdienste<br />
aufgebaut werden kann, in welchem die Anbieter und deren Geobasisdienste<br />
strukturiert beschrieben und kategorisiert sind. Weiter müssen die Geobasisdienste exakt<br />
beschrieben werden, und es wird festgelegt, wie darauf zugegriffen werden kann<br />
und wie sie kommunizieren.<br />
St<strong>and</strong>ards / Normung<br />
Der modellbasierte Ansatz ist entscheidend für die <strong>Interoperabilität</strong> und soll beim Bund<br />
in Zukunft eine wichtige Rolle spielen.<br />
Folgende Richtlinien und St<strong>and</strong>ards werden auf Bundesebene festgelegt:<br />
� die Metadatenbeschreibung erfolgt über das auf der Basis von ISO 19115 entwickelte<br />
CH-Pr<strong>of</strong>il (im Minimum über das von ISO definierte Core-Pr<strong>of</strong>il),<br />
� die Geodatenmodellierung erfolgt mit der Modellierungssprache UML (Unified<br />
Modeling Language) und INTERLIS auf der Basis eines Objektkatalogs,<br />
� der systemneutrale Austausch von Geobasisdaten und Metadaten erfolgt mindestens<br />
auf der Basis der Modellbeschreibung INTERLIS/XML unter Berücksichtigung<br />
der Kompatibilität mit internationalen St<strong>and</strong>ards (z.B. mit GML).<br />
� die Vernetzung von grundlegenden Geodiensten erfolgt mindestens unter Berücksichtigung<br />
der Kompatibilität mit den internationalen St<strong>and</strong>ards (wie W3C<br />
(World Wide Web Consortium))<br />
Die Bestrebungen im Sinne einer nationalen Plattform Geonormen (NGN) sollen weiter<br />
gefördert und auch finanziell unterstützt werden. Die Entwicklung und Anwendung<br />
von Geo-Normen und Datenmodellen forciert und koordiniert werden. Datenmodelle<br />
und Normen sollen allen interessierten Nutzern zur Verfügung stehen und weiterentwickelt<br />
werden. Dazu sind in einem ersten Schritt vorh<strong>and</strong>ene effiziente aber unkoordinierte<br />
und ad hoc finanzierte Initiativen und Aktivitäten zu koordinieren und auf eine<br />
stabile finanzielle Basis zu stellen.<br />
Ziel ist die rasche Verbreitung des Wissens über Nutzen und Anwendung der Datenmodelle<br />
und Normen sowie deren konsequente Anwendung. Die Aufgabenbereiche<br />
Ausbildung, Technik, Datenmodelle, Support, Normen und Marketing bilden dabei die<br />
Haupttätigkeiten.<br />
14.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Rudolf Schneeberger<br />
Dorfstrasse 53<br />
CH-8105 Regensdorf<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 44 871 21 90<br />
+41 44 871 21 99<br />
15<br />
Nationale Pr<strong>of</strong>ile der internationalen<br />
St<strong>and</strong>ards am Beispiel Metadaten<br />
Rudolf Schneeberger, ITV Geomatik AG
1 Einleitung<br />
1.1 Definition von Metadaten<br />
Metadaten sind für viele Leute schwammig, undefinierbar und zu technisch, scheinen<br />
unwichtig, da die Daten vorh<strong>and</strong>en sind, werden <strong>of</strong>t vernachlässigt beh<strong>and</strong>elt, existieren<br />
nur auf Notizzetteln. Aus diesen Gründen werden Metadaten selten freiwillig erfasst<br />
und nachgeführt. Denn es ist heute dem Benutzer <strong>of</strong>t nicht ganz klar, wozu sie eigentlich<br />
dienen.<br />
Laut Definition h<strong>and</strong>elt es sich bei Metadaten um „Daten über Daten“, das heisst es sind<br />
beschreibende Daten der effektiven Daten. Zwei weitere Definitionen werden noch etwas<br />
klarer:<br />
� Unter Metadaten versteht man strukturierte Daten, mit deren Hilfe eine Informationsressource<br />
beschrieben und dadurch besser auffindbar gemacht wird.<br />
� Metadaten sind maschinenlesbare Informationen über elektronische Ressourcen<br />
oder <strong>and</strong>ere Dinge.<br />
Sehen wir uns einmal um, so stellen wir fest, dass wir jeden Tag Metadaten begegnen.<br />
Man stelle sich ein Schokoladengestell in einem Einkaufsladen vor, in dem jede Schokolade<br />
weiss eingepackt ist und „Schokolade“ drauf steht. Welche kaufen Sie? Wahrscheinlich<br />
keine, weil nicht bekannt ist, um was für eine Schokolade es sich h<strong>and</strong>elt. Der<br />
Käufer will wissen, ob es eine Schokolade ist mit Nüssen oder ohne, wer sie hergestellt<br />
hat, wie sie heisst, wie teuer sie ist, usw. Erst mit diesen Angaben werden die unterschiedlichen<br />
Schokoladen vergleichbar und er kann entscheiden, welches die Richtige<br />
ist und bei welcher das Preis/Leistungs-Verhältnis stimmt.<br />
Genau gleich verhält es sich mit Metadaten für Geodaten. Sie geben eine genaue Beschreibung<br />
des Geodatenbest<strong>and</strong>es. Erst wenn man den genauen Inhalt, die Genauigkeit,<br />
den Preis, das Modell, das Format und vieles mehr eines Geodatenbest<strong>and</strong>es kennt,<br />
kann man entscheiden, ob er den Ansprüchen genügt. Die wichtigsten Fragen, welche<br />
mit Metadaten beantwortet werden sind bei Geodaten:<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 15.1
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
Nationale Pr<strong>of</strong>ile der internationalen St<strong>and</strong>ards am Beispiel Metadaten<br />
WER bietet - Institutionen - Ansprechpartner<br />
- Ersteller / Verteiler<br />
- Zuständigkeit<br />
- Anschrift<br />
WAS und - Datenarten - Erfassungsdatum<br />
- Inhalte - Name und Beschreibung<br />
- Massstab - Art<br />
WIEVIEL - Datenmenge<br />
- Flächendeckung<br />
- Status<br />
WORÜBER - Objektarten - Thesaurus<br />
- räumlicher Bezug<br />
- zeitlicher Bezug<br />
- Fachgebiet<br />
WIE in - Format - Datenbank<br />
- Schnittstelle - Zugangsberechtigung<br />
- Analog / Digital - Zugangsadresse<br />
WELCHEM Zusammenhang - fachliche Bedeutung - Nutzungsrestriktionen<br />
und zu - Aufgabenbeschreibung<br />
- Eignungshinweis<br />
WELCHEN Konditionen - Preis - Rechtsinhaber<br />
1.2 Metainformation als Teil einer NGDI<br />
- Zugriffsrechte - Vervielfältigungen<br />
- Nutzungsrechte<br />
Das Hauptziel einer Nationalen Geodaten-Infrastruktur (NGDI) besteht darin, über einen<br />
leichten Zugang ein optimales Angebot und eine breitere Nutzung von Geoinformation<br />
zu bewirken. In dieser NGDI sind Metainformationen ein wesentlicher Best<strong>and</strong>teil.<br />
15.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
2 ISO Normen<br />
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
Nationale Pr<strong>of</strong>ile der internationalen St<strong>and</strong>ards am Beispiel Metadaten<br />
2.1 Inhalt von ISO von 19115:2003 - Metadata<br />
Struktur für die Beschreibung von digitalen geographischen Daten in Form eines abstrakten<br />
Modells (konzeptionelles Metadatenmodell):<br />
� Einführung mit Abmachungen und Definitionen<br />
� Klassendiagramme als UML-Diagramme<br />
� Objektkatalog (Datadictionary)<br />
� weitere Anhänge<br />
Die Norm sagt nichts über die Form der Umsetzung in einem GIS oder einer Datenbank<br />
aus und ist kein "Kochrezept" für eine Implementierung.<br />
2.2 Pr<strong>of</strong>ile und Erweiterungen von ISO 19115:2003 - Metadata<br />
Die ISO Norm 19115 geht vom Ansatz einer möglichst universellen Anwendung der<br />
Norm aus, jedoch mit der Möglichkeit den Gesamtumfang mit Pr<strong>of</strong>ilen wiederum einzuschränken.<br />
Die ISO Norm definiert mehr als 300 Metadatenelemente (Klassen, Attribute,<br />
Beziehungen), wobei die meisten davon optional verwendet werden können.<br />
Pr<strong>of</strong>ile<br />
Pr<strong>of</strong>ile erlauben es, Abbildungen aus dem umfassenden ISO-Metadatenmodell für spezifische<br />
Anwendungen zu erstellen. In jedem Pr<strong>of</strong>il muss das minimale ISO-<br />
Metadatenmodell vollumfänglich integriert sein. Zudem kann das Bedürfnis bestehen,<br />
ein Pr<strong>of</strong>il zu erweitern.<br />
Erweiterungen<br />
Ein Pr<strong>of</strong>il kann mit eigenen Metadatenelementen oder sonstigen Änderungen erweitert<br />
werden. Die ISO Norm 19115 schreibt im Annex C genau vor, wie die vorgegebenen<br />
Strukturen zu erweitern sind und welche Erweiterungen erlaubt sind.<br />
Umfassendes<br />
ISO Metadatenmodell<br />
(ISO Comprehensive Metadata Pr<strong>of</strong>ile)<br />
Minimales<br />
ISO Metadatenmodell<br />
(ISO Core Metadata<br />
components)<br />
Pr<strong>of</strong>il XY<br />
Erweiterung<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 15.3
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
Nationale Pr<strong>of</strong>ile der internationalen St<strong>and</strong>ards am Beispiel Metadaten<br />
Regeln für die Erstellung von Pr<strong>of</strong>ilen<br />
1. Vorh<strong>and</strong>ene Elemente dürfen in eigenen Pr<strong>of</strong>ilen nicht abgeändert werden.<br />
2. Werden in einer neuen Entitätsmenge bereits bestehende Attribute verwendet,<br />
dürfen deren Attribute nicht abgeändert werden.<br />
3. In Erweiterungen ist es erlaubt, ...<br />
... strengere Verbindungstypen festzulegen,<br />
4. ... den Entitäten und Attributen Wertebereiche zu zuweisen,<br />
5. ... bereits vorgegebene Wertebereiche zu kürzen,<br />
6. ... oder zu erweitern.<br />
7. Erweiterungen dürfen aber nicht erlauben, was der St<strong>and</strong>ard verbietet.<br />
3 Schweizer Norm für Metadaten<br />
3.1 Warum braucht es eine Schweizer Norm?<br />
Bestehende Metadateninventare sind entweder nur regional (Kantone), fachlich beschränkt<br />
(CDS, GeoMeta, Geostat) oder nicht Internet-tauglich betreffend Suche und<br />
Erfassung von Metadaten. Bisherige Metadatenbanken sind nicht kompatibel unterein<strong>and</strong>er<br />
und sind auch nicht kompatibel zu der ISO Norm 19115:2003.<br />
KOGIS ist für die Geodatenkoordination in der Bundesverwaltung verantwortlich und<br />
hatte darum auch bei Metadaten H<strong>and</strong>lungsbedarf. Da KOGIS nicht ein eigenes "Bundesmodell"<br />
entwickeln wollte, wurde in Zusammenarbeit mit einer Arbeitsgruppe aus<br />
Kantonen, Hochschulen und Firmen ein Metadatenmodell definiert, das die minimalen<br />
Anforderungen aller Beteiligten befriedigt, ISO kompatibel ist und welches vom SNV<br />
als Schweizer Norm veröffentlicht wird.<br />
3.2 Von der ISO-Norm zur Schweizer Norm<br />
SIK - GIS<br />
CDS<br />
Stellungnahmen<br />
zum Entwurf<br />
Arbeitsgruppe<br />
SNV - TK 151<br />
SNV<br />
Vernehmlassung<br />
ISO<br />
19115:2003<br />
Schweizer Norm<br />
SN 612050<br />
GM03<br />
Metadatenmodelle<br />
INTERLIS<br />
Beschreibung<br />
Pflichtenheft<br />
geocat.ch<br />
Pilot<br />
geocat.ch<br />
geocat.ch<br />
Catalog Gateway<br />
15.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
Nationale Pr<strong>of</strong>ile der internationalen St<strong>and</strong>ards am Beispiel Metadaten<br />
Um die Anliegen der Beteiligten in der Schweiz zu berücksichtigen, wurden die bestehenden<br />
Metadatenbanken der Schweizerischen Informatik Konferenz GIS (SIK-GIS) und<br />
des Bundesamtes für Wald und L<strong>and</strong>schaft (CDS) mit der ISO-Norm verglichen. Daraus<br />
entst<strong>and</strong> ein erster Entwurf eines Schweizer Metadatenpr<strong>of</strong>ils, in dem bereits Teile der<br />
ISO-Norm weggelassen wurden. Andere Teile wurden als Erweiterung neu modelliert.<br />
Man war sich bewusst, dass mit dem Vergleich lediglich zweier bestehender Metadatenbanken<br />
noch nicht alle Bedürfnisse abgedeckt sein würden. Stellungnahmen von<br />
Bundesämtern, Kantonen und weiteren interessierten Stellen ergaben zusätzliche Bedürfnisse.<br />
Das überarbeitete Metadatenmodell war Grundlage für den Schweizer<br />
Normentwurf, der Ende 2003 in eine <strong>of</strong>fizielle Vernehmlassung geschickt wurde. Die<br />
Resultate dieser Vernehmlassung wurden in einer Arbeitsgruppe (SNV/TK151) besprochen.<br />
Diese Arbeitsgruppe, bestehend aus Vertretern aller interessierten Stellen,<br />
entschied in jedem Fall darüber, ob eine Eingabe berücksichtigt wurde oder nicht. Daraus<br />
wurde ein definitives Modell erarbeitet, welches Grundlage für die Schweizer Norm<br />
ist.<br />
Parallel zur Erarbeitung der Schweizer Norm wurde das Portal und der Metadatenserver<br />
geocat.ch spezifiziert und entwickelt (siehe Kapitel 4).<br />
3.3 Weshalb ISO als Grundlage?<br />
� ISO ist die internationale Organisation für weltweite St<strong>and</strong>ards.<br />
� CEN ist das Europäische Pendant zu ISO und wird ISO 19115:2003 übernehmen.<br />
� Die Schweiz ist Mitglied von CEN und deshalb verpflichtet, deren Normen zu übernehmen,<br />
also auch ISO 19115:2003.<br />
� Nur auf der Basis des internationalen St<strong>and</strong>ards ISO 19915:2003 wird ein Datenaustausch<br />
mit <strong>and</strong>eren Ländern möglich.<br />
3.4 Unterschiede ISO Norm - CH Norm<br />
Die Modell-Beschreibung in UML in der Norm ISO 19115:2003 ist zu allgemein gehalten<br />
für eine konkrete Umsetzung. Aus diesem Grund wurde in der Schweiz das Modell detaillierter<br />
in INTERLIS 2, dem Schweizer St<strong>and</strong>ard für Datenmodellierung und Datenaustausch,<br />
modelliert und mit UML-Notation dokumentiert. Dadurch wird der Konkretisierungsgrad<br />
erhöht und ein Datenaustausch ermöglicht. INTERLIS 2 beinhaltet Codierungsregeln<br />
zur automatisierten Generierung einer XML-Schema-Beschreibung, welche<br />
maschinenlesbar und zum Aufbau einer Datenbankstruktur und einer Applikation<br />
verwendet werden kann. Mit diesen Regeln entfällt der Aufw<strong>and</strong>, neben einer UML-<br />
Beschreibung eine XML-Beschreibung in H<strong>and</strong>arbeit zu erstellen, wie es ISO mit der<br />
Norm 19139 zurzeit macht.<br />
Wie das Metadatenmodell der ISO kennt auch das Schweizer Metadatenmodell zwei<br />
Pr<strong>of</strong>ile, GM03Core und GM03Comprehensive, welche beide die ISO-Core Metadatenelemente<br />
enthalten. Es wurde jedoch ein <strong>and</strong>erer Ansatz der Modellierung gewählt (siehe<br />
Abbildung): ISO definiert ein möglichst umfassendes Metadatenmodell (Pr<strong>of</strong>il ISO-<br />
Comprehensive), schreibt vor, welche Elemente in jedem Pr<strong>of</strong>il enthalten sein müssen<br />
(ISO-Core) und überlässt es dann jeder Anwendergruppe, daraus ein eigenes Pr<strong>of</strong>il zu<br />
definieren. In der Schweiz dagegen, wird in die <strong>and</strong>ere Richtung modelliert. Als minimaler<br />
Kern wird GM03Core definiert und durch Vererbung zu GM03Comprehensive<br />
erweitert. Die Vorteile des Vorgehens in der Schweiz gegenüber der ISO ist die bei allen<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 15.5
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
Nationale Pr<strong>of</strong>ile der internationalen St<strong>and</strong>ards am Beispiel Metadaten<br />
Pr<strong>of</strong>ilen identische Grundlage, GM03Core, und somit ein garantierter gemeinsamer<br />
Nenner für den Austausch.<br />
Core<br />
Metadatenmodell<br />
Comprehensive<br />
Metadatenmodell<br />
Lokales<br />
Metadatenmodell<br />
Lokales<br />
Metadatenmodell<br />
Lokales<br />
Metadatenmodell<br />
GM03Core<br />
Metadatenmodell<br />
GM03Comprehensive<br />
Metadatenmodell<br />
Lokales<br />
Metadatenmodell<br />
3.5 Grundsätze bei der Ausarbeitung der Schweizer Norm<br />
Als Grundlage wurde ISO 19115:2003 Metadata gewählt:<br />
Lokales<br />
Metadatenmodell<br />
� Alle Metadatenelemente aus ISO-Core werden auch in GM03Core übernommen.<br />
� Es werden alle Metadatenelemente oder Klassen übernommen, die aus den Bedingungen<br />
und Vorgaben der Norm obligatorisch sind.<br />
� Es werden die Metadatenelemente definiert, welche notwendig sind, um die bestehenden<br />
Schweizer Datenkataloge abzudecken.<br />
Die Kompatibilität zu ISO 19115:2003 wird soweit sinnvoll sichergestellt:<br />
� Erweiterungen sind nach den Regeln in Anhang C der ISO-Norm modelliert (z.B.<br />
gesetzliche Informationen „Legislation Information“).<br />
� Die für die Schweiz notwendige Mehrsprachigkeit ist nach Anhang J der ISO-<br />
Norm umgesetzt.<br />
In einzelnen Fällen musste von der ISO-Norm abgewichen werden, damit eine brauchbare<br />
Lösung gefunden werden konnte:<br />
� verantwortliche Stelle („Responsible Party“)<br />
autorisierte Stelle („Authority“) und Identikator („Identifier“)<br />
� Wiederverwendung von Daten in mehreren Instanzen (z.B. „Responsible Party“,<br />
Koordinatensystem, etc.) bedingt Abweichung bei der Modellierung der Beziehungen<br />
3.6 GM03 Metadatenmodell<br />
Um eine minimale Beschreibung von Geodaten zu garantieren, wird das minimale Metadatenmodell<br />
GM03Core definiert. Zu GM03Core gehören die Metadatenelemente, mit<br />
welchen mindestens folgende Fragen beantwortet werden können:<br />
� Existiert ein Datenbest<strong>and</strong> zu einem bestimmten Thema? (WAS)<br />
� Gibt es den Datenbest<strong>and</strong> zu einem bestimmten Ort? (WO)<br />
� Bei wem erhalte ich diese Daten? (WER)<br />
� In welcher Form kann ich die Daten beziehen? (WIE)<br />
� Wann oder in welcher Periode wurde der Datenbest<strong>and</strong> erstellt oder zuletzt nachgeführt?<br />
(WANN)<br />
15.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
Nationale Pr<strong>of</strong>ile der internationalen St<strong>and</strong>ards am Beispiel Metadaten<br />
Das Modell GM03Core umfasst nur die wichtigsten Elemente und deckt nicht alle Anforderungen<br />
ab. Deshalb wurde ein umfassenderes Modell GM03Comprehensive ausgearbeitet,<br />
das alle Elemente von ISO enthält und weitere Bedürfnisse der Beteiligten<br />
abdeckt.<br />
3.7 Anwendungsbereich der Schweizer Norm SN612050<br />
Die Norm befasst sich mit Metadaten für Geodaten und gilt für Betriebe, die für die Erfassung,<br />
Verarbeitung, Verwaltung und Abgabe von Metadaten verantwortlich sind.<br />
Die Norm bezieht sich zwar auf Geodaten, kann aber sinngemäss auch für <strong>and</strong>ere Anwendungsbereiche<br />
eingesetzt werden.<br />
Die Norm regelt, wie Metadaten konzeptionell strukturiert werden. Sie ermöglicht damit<br />
ein einheitliches Verständnis aller an Metadaten interessierten Personen und Stellen.<br />
Sie regelt aber nicht, wie konkrete Einrichtungen (z.B. Datenbanken) aufgebaut sein sollen.<br />
Die Norm entwickelt selbst keine Technik zur präzisen Beschreibung der Festlegungen.<br />
Sie bedient sich dafür existierenden Techniken. Für die Beschreibung des<br />
Datenmodells wird die Unified Modelling Language (UML) und die Datenbeschreibungssprache<br />
INTERLIS 2 verwendet.<br />
Die Norm legt den Datenaustausch fest. Als gemeinsames Transferprotokoll wird XML<br />
(Regeln nach INTERLIS 2) verwendet.<br />
4 geocat.ch<br />
4.1 Metadatenportal geocat.ch und Geodatenkatalog<br />
Die Anforderungen an einen Geodatenkatalog lassen sich auf zwei wesentliche Punkte<br />
reduzieren:<br />
� Der Geodatenkatalog muss über eine Such-Applikation verfügen, damit erfasste<br />
Metadaten gesichtet werden können. Über ein heterogenes und dezentral organisiertes<br />
Metadatenportal wird dieser Geodatenkatalog abgefragt und die gewünschten<br />
Daten werden dem Benutzer zur Verfügung gestellt.<br />
� Der Geodatenkatalog muss über eine Administrations-Applikation verfügen, damit<br />
die Daten erfasst, verwaltet und aktuell gehalten werden können.<br />
Das Metadatenportal geocat.ch erfüllt genau diese genannten Anforderungen an einen<br />
Geodatenkatalog.<br />
4.2 Konkrete Umsetzung<br />
Das Hauptziel besteht darin, auf nationaler Ebene ein Portal für die Gesamtheit aller<br />
geographischen Metadaten zu verwirklichen. Es wird die Einführung einer dezentralisierten<br />
Infrastruktur beabsichtigt, welche die dezentralisierte Verwaltung und den Zugang<br />
auf alle angeschlossenen Metadatenkataloge erlaubt.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 15.7
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
Nationale Pr<strong>of</strong>ile der internationalen St<strong>and</strong>ards am Beispiel Metadaten<br />
3<br />
Catalog<br />
Server<br />
Database <strong>and</strong> Tool<br />
Administration<br />
general<br />
administrator<br />
KOGIS<br />
Search Server<br />
Metadatabase<br />
MetaCH<br />
2<br />
Metadata<br />
Management<br />
metadata<br />
contributor<br />
Catalog<br />
Gateway<br />
Partner <strong>and</strong><br />
producer <strong>of</strong><br />
Geodata<br />
Catalog<br />
Management<br />
catalog<br />
administrat<br />
or<br />
A<br />
1<br />
Discovery<br />
Service<br />
Discovery Service<br />
Gatew ay <strong>and</strong> Client <strong>of</strong><br />
Metadatabases<br />
Import / Export<br />
catalog<br />
administrat<br />
or<br />
Partner <strong>and</strong><br />
producer <strong>of</strong><br />
Geodata<br />
Es sind zwei Typen von Datenbanken verbunden:<br />
Metadata Metadata<br />
metadata<br />
contributor<br />
Partner <strong>and</strong><br />
producer <strong>of</strong><br />
Geodata<br />
15.8 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten<br />
user<br />
metadata<br />
contributor<br />
B<br />
gateway<br />
manager<br />
Search Server<br />
C<br />
user<br />
Catalog<br />
Management<br />
Partner A<br />
Metadata<br />
catalog<br />
administrat<br />
or<br />
Portal für die<br />
Suche<br />
Gateway<br />
Metadatenkatalog mit<br />
seinen Administrationsund<br />
Verwaltungstools<br />
Benutzer<br />
(Oberfläche)<br />
Komponenten<br />
der Infrastruktur<br />
Partner<br />
Metadatenbank<br />
Beziehung zwischen eine<br />
Benutzer und einer<br />
Komponente<br />
Informationsfluss<br />
� Die zentrale geocat.ch-Datenbank, welche erreichbar ist über die Suchapplikation<br />
geocat.ch.<br />
� Verteilte Datenbanken, die mittels Catalog Gateway mit der Suchapplikation geocat.ch<br />
verbunden sind.<br />
Für Datenproduzenten von Metadaten sind drei Partnertypen möglich:<br />
� Datenmanagement direkt in der zentralen Datenbank.<br />
� Datenmanagement in eigener Datenbank. Mittels eines Import/Export-Tools werden<br />
diese Daten in der zentralen Datenbank für die Suchapplikation verfügbar<br />
gemacht.<br />
� Datenmanagement in eigener Datenbank, welche durch die Suchapplikation über<br />
den Catalog Gateway abgefragt werden kann.<br />
4.3 Suchportal<br />
Das Suchportal gibt dem Nutzer von Geodaten einen umfassenden und einheitlich<br />
strukturierten Überblick und schnellen Zugriff zu notwendigen Informationen über<br />
Geodaten, ganz gleich, welche Institution die Geodaten anbietet. Dieser Suchdienst wird<br />
nicht zu einer zentralisierten Lösung für die Verwaltung und Verbreitung von geographischen<br />
Metadaten verwendet. Im Allgemeinen ist vorgesehen, dass die Metadaten<br />
direkt bei den Geodaten produzierenden Partnern mit Hilfe der innerhalb ihrer Institution<br />
verfügbaren Infrastruktur verwaltet werden (Partner C).
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
Nationale Pr<strong>of</strong>ile der internationalen St<strong>and</strong>ards am Beispiel Metadaten<br />
Die Applikation unterstützt zwei Arten der Suche: die einfache Textsuche und die ausführliche<br />
Suche, bei der nach jedem Element gesucht werden kann. Beiden Such-Arten<br />
gemeinsam ist die geographische Suche nach einer Gebietsbezeichnung (z.B. Kanton<br />
Bern), innerhalb eines umhüllenden Rechtecks oder innerhalb eines frei definierbaren<br />
Polygons.<br />
Der Suchdienst muss deshalb einen koordinierten und transparenten Zugriff auf verschiedenartige<br />
Metadatenbanken ermöglichen. Die Funktionstüchtigkeit einer solchen<br />
Lösung bedingt die Verwendung eines gemeinsamen Protokolls für Abfrage und Ergebnis.<br />
Dieses Protokoll, in SOAP (Simple Object Access Protocol) beschrieben, ist relativ<br />
kostengünstig implementierbar, sowohl für relationale Datenbanken als auch für<br />
XML basierte Lösungen.<br />
geocat.ch<br />
Discovery Client<br />
Quellenangaben<br />
Anfrage (HTML)<br />
Präsentation der Resultate<br />
Detaillierte Anfrage (HTML)<br />
Präsentation der Resultate<br />
aus GM03 (HTML)<br />
Geocat.ch<br />
Portal<br />
Konsolidierung<br />
der Resultate<br />
Gateway Protokoll<br />
Anfrage(n)<br />
Resultat(e) in XML<br />
GM03 Anfrage(n)<br />
GM03 Resultat(e) in XML<br />
Gateway<br />
Server(s)<br />
� Vermessung und Geoinformation - GM03 - Metadatenmodell, Ein Schweizer Metadatenmodell<br />
für Geodaten, SN 612050, Working Draft Version 1.4<br />
� ISO Norm 19115:2003, Geographic Information - Metadata<br />
� Aufbau eines Nationalen Metadaten-Portals als Teil einer Nationalen Geodaten-<br />
Infrastruktur in der Schweiz, Referat von D. Angst (ITV Geomatik AG) und A.<br />
Schneider (KOGIS), AGIT 2004 in Salzburg<br />
� Pflichtenheft geocat.ch Metadatenkatalog für Geodaten, August 2002<br />
� Catalog Gateway Protocol, Mai 2004, KOGIS, Version 0.99<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 15.9
Willy Müller<br />
Informatikstrategieorgan Bund<br />
Friedheimweg 14<br />
CH-3003 Bern<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 31 325 90 35<br />
+41 31 322 45 66<br />
16<br />
<strong>Interoperabilität</strong><br />
Nicht nur eine Frage der Technologie<br />
Willy Müller, Informatikstrategieorgan Bund
<strong>Interoperabilität</strong> im Geoinformationsbereich ist das Thema dieser Tagung. Aber was ist<br />
<strong>Interoperabilität</strong>? Nach der Definition in [IEEE 90] ist es, die Fähigkeit von zwei oder<br />
mehreren Systemen oder Komponenten, Informationen auszutauschen und die Information,<br />
welche ausgetauscht wurde, zu nutzen. In unserem Kontext geht es primär um<br />
die Möglichkeit, geografische Daten auszutauschen. Bis zu einem gewissen Grad ist <strong>Interoperabilität</strong><br />
auf irgendeine Weise fast immer gegeben. So kann z.B. ein Vermessungsbüro<br />
einen Plan erstellen, ihn auf Papier ausdrucken und per Post an ein <strong>and</strong>eres Büro<br />
versenden, das ihn manuell in sein System überträgt. Wenn wir damit zufrieden wären,<br />
wären wir wohl nicht hier. Wir streben eine bessere <strong>Interoperabilität</strong> an. Das heisst, <strong>Interoperabilität</strong><br />
kann besser oder schlechter sein. Die Güte der <strong>Interoperabilität</strong> hat dabei<br />
zwei Dimensionen: die eine korreliert negativ mit dem Aufw<strong>and</strong> und den Kosten, die<br />
nötig sind, um Daten elektronisch auszutauschen und weiter zu verwerten. Die <strong>and</strong>ere<br />
korreliert positiv mit der Menge der Systeme oder Komponenten, welche unterein<strong>and</strong>er<br />
Informationen austauschen und weiterverwenden können. Lassen sie uns daher für unseren<br />
Kontext die Definition von [IEEE 90] präzisieren: <strong>Interoperabilität</strong> ist die Fähigkeit<br />
möglichst vieler Systeme oder Komponenten, Daten elektronisch auszutauschen und sie<br />
mit möglichst wenig Aufw<strong>and</strong>, insbesondere ohne manuelle Bearbeitung, weiter zu<br />
verwenden.<br />
1 Der Bundesrates will eine reibungslose elektronische<br />
Zusammenarbeit<br />
Was hat der Staat zur <strong>Interoperabilität</strong> – insb. im Bereich der Geoinformationen - zu sagen?<br />
Soll er sich dazu überhaupt äussern, oder soll er besser die Finger davon lassen?<br />
Der Schweizer Staat - und das gilt für Bund, Kantone und Gemeinden gleichermassen -<br />
sieht sich in mehrerlei Hinsicht mit der auf den ersten Blick eher technischen Fragestellung<br />
konfrontiert:<br />
1. Er hat die Aufgabe, für Einwohnerinnen und Einwohner wie auch die Wirtschaft<br />
förderliche Rahmenbedingungen zu schaffen.<br />
2. Als Produzent und wichtiger Konsument von Geoinformationen ist er direkt betr<strong>of</strong>fen.<br />
3. Er muss sich mit den Folgen verbesserter <strong>Interoperabilität</strong> ausein<strong>and</strong>ersetzen.<br />
Der Bundesrat erachtet die Förderung der Informationsgesellschaft in der Schweiz als<br />
prioritär. Darüber hinaus will er seine Regierungs- und Verwaltungstätigkeit effizient,<br />
flexibel und transparent gestalten. In seiner eGovernment-Strategie hat er dazu drei<br />
Stossrichtungen definiert:<br />
1. Voraussetzungen schaffen: Die organisatorischen, technologischen und sicherheitsspezifischen<br />
Voraussetzungen für eine reibungslose Zusammenarbeit innerhalb<br />
der Verwaltung sollen geschaffen werden.<br />
2. Service excellence: Der Zugang zu den staatlichen Dienstleistungen – und dazu<br />
gehört auch die Bereitstellung einer ganzen Menge von Geoinformationen - soll<br />
für Privatwirtschaft, Bürgerinnen und Bürger leichter und transparenter werden.<br />
3. Vernetzung: Angestrebt wird die ‚elektronische Integration’ zwischen den Verwaltungsstellen<br />
der verschiedenen Staatsebenen (Bund, Kantone und Gemeinden)<br />
sowie zwischen dem Staat und seinen Partnern (öffentliche H<strong>and</strong>, Wirtschaft<br />
und Gesellschaft).<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 16.1
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
<strong>Interoperabilität</strong>: nicht nur eine Frage der Technologie<br />
Die Arbeiten zur Förderung der elektronischen Zusammenarbeit im Bereich der Geoinformationen<br />
sind also zu sehen als Teil einer übergeordneten Strategie. Zu diesem<br />
Zweck wurde u.a. KOGIS, die Koordinationsstelle für geografische Information und<br />
geografische Informationssysteme, ins Leben gerufen (vgl. www.kogis.ch). Die Stossrichtungen<br />
‚Voraussetzungen schaffen’ und ‚Vernetzung’ haben eine verbesserte <strong>Interoperabilität</strong><br />
zum Ziel.<br />
Um die <strong>Interoperabilität</strong> zu steigern, sind dabei Massnahmen auf unterschiedlichen Ebenen<br />
notwendig. In Anlehnung an das Modell, welches wir im Rahmen der E-<br />
Government-Architektur der Schweiz entwickelt haben [eGovCH], sind insbesondere<br />
zu unterscheiden:<br />
Politische, rechtliche und<br />
organisatorische Rahmenbedingungen<br />
Fach-Services<br />
Daten-Services<br />
Directory<br />
Infrastruktur-Services<br />
Services<br />
Technische Basis<br />
Abb. 1 : Bereiche, in denen zur Erreichung einer realen <strong>Interoperabilität</strong>, auf ein<strong>and</strong>er<br />
abgestimmte Massnahmen nötig sind.<br />
� Technologische Infrastruktur: Rechner, Speicher und Netzwerke für die elektronische<br />
Verarbeitung und den Datenaustausch,<br />
� Infrastruktur-Services: Nicht fachspezifische Anwendungen, welche den sicheren<br />
und zuverlässigen Datenaustausch ermöglichen,<br />
� Directory-Services: Elektronische, bei Bedarf maschinenlesbare Verzeichnisse über<br />
Kommunikationspartner und elektronisch zugängliche Dienstleistungen<br />
� Daten-Services: Definition der Syntax und Semantik, welche gewährleistet, dass<br />
Partner ausgetauschte Daten ohne grössere Probleme weiterverwenden können,<br />
� Fach-Services: Fachanwendungen, welche so geschrieben sind, dass sie mit <strong>and</strong>eren<br />
Fachanwendungen zusammenarbeiten können,<br />
� Organisation, Prozesse und Recht: Organisatorische und rechtliche Rahmenbedingungen,<br />
welche <strong>Interoperabilität</strong> zulassen und die Spielregeln für die elektronische<br />
Zusammenarbeit festlegen.<br />
Erst wenn auf allen Ebenen die geeigneten Voraussetzungen geschaffen sind, ist ein reibungsloses<br />
Zusammenspiel möglich. Nachfolgend wird exemplarisch auf einige kritische<br />
Themenkreise eingegangen. Zur Illustration wird in der Regel auf Beispiele im<br />
Geoinformationsbereich Bezug genommen.<br />
16.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
<strong>Interoperabilität</strong>: nicht nur eine Frage der Technologie<br />
2 Erste Stossrichtung: Voraussetzungen schaffen<br />
Damit Systeme ohne menschliche Intervention Daten austauschen können, müssen sie<br />
sich verstehen. Das ist nur möglich, wenn sie die gleiche Sprache sprechen. Wir beginnen<br />
zu verstehen, wie derartige Sprachen optimalerweise aussehen sollten und wie sie<br />
zu dokumentieren sind. Entsprechende Spezifikationen im Geoinformationsbereich sind<br />
vorh<strong>and</strong>en und haben - zumindest teilweise - erste Praxistests best<strong>and</strong>en (z.B. INTER-<br />
LIS, GML). Darauf im Detail einzugehen, ist nicht die Aufgabe dieses Beitrags. Bei der<br />
Ausein<strong>and</strong>ersetzung mit der Spezifikation von Klassen, Konsistenzregeln und Tags vergisst<br />
man jedoch gerne, dass es letztlich um mehr geht, als die präzise Spezifikation. Auf<br />
drei Aspekte soll im Folgenden speziell hingewiesen werden:<br />
� der Kampf um die richtige Sprache<br />
� die Vergabe von Namen und Identifikatoren<br />
� Verknüpfungen von Daten unterschiedlicher Domänen.<br />
2.1 Der Kampf um die richtige Sprache<br />
Unglücklicherweise gibt es keine Naturgesetze, welche sicherstellen, dass es nur eine<br />
einzige Sprache gibt. Üblicherweise bilden sich daher mehr oder weniger unabhängig<br />
vonein<strong>and</strong>er verschiedene Sprachgemeinschaften mit je eigenen Konventionen. Das ist<br />
bei den Geoinformationen nicht <strong>and</strong>ers: Neben nationalen und internationalen St<strong>and</strong>ardisierungsgremien<br />
setzen S<strong>of</strong>twareanbieter ihre eigenen Datenaustauschformate fest.<br />
Solange Mitglieder einer Sprachgemeinschaft lediglich unter sich Daten austauschen<br />
möchten, ist dies nicht weiter problematisch. Andernfalls stellen unterschiedliche Sprachen<br />
jedoch ein ernsthaftes <strong>Interoperabilität</strong>sproblem dar.<br />
Sprachen dienen leider nicht nur der Kommunikation, sondern genauso der Ausgrenzung.<br />
Der Entscheidung, wer an der Sprachgemeinschaft teilhaben soll, kommt daher<br />
strategische Bedeutung zu. Der Bundesrat spricht sich explizit für eine Vernetzung innerhalb<br />
der Schweiz und darüber hinaus aus. Gelingt dies, wird sich dadurch allerdings<br />
der Wettbewerb zwischen den betr<strong>of</strong>fenen S<strong>of</strong>tware- und Datenanbietern verschärfen.<br />
Nischen, die sich der eine oder <strong>and</strong>ere geschaffen hat, gehen verloren.<br />
2.2 Verknüpfungen<br />
Die Abgrenzung, was als Geoinformation zu betrachten ist, fällt schwerer, als auf den<br />
ersten Blick zu erwarten wäre. Im weiteren Sinn fällt darunter alles mit einem geografischen<br />
Bezug, d.h. alles, was in Beziehung zu einer Koordinate oder einem Areal st<strong>and</strong>,<br />
steht oder stehen wird. Bei genauerem Hinsehen sind das potentiell alle Objekte, welche<br />
eine räumliche Ausdehnung besitzen. Denn was eine räumliche Ausdehnung hat, befindet<br />
sich zwangsweise zu einem bestimmten Zeitpunkt an einem bestimmten Ort:<br />
Golfclubs, Webcams, Mobilfunkantennen, Raucher, Rinder, Gletscherhahnenfüsse, Gasleitungen,<br />
Niederschläge. Aber damit nicht genug! Selbst alles was mit einem solchen<br />
Objekt in Beziehung steht, kann zum Teil von Geoinformationen werden: Windgeschwindigkeiten,<br />
Kindersterblichkeit, Sexpraktiken oder Vorlieben für Rotwein.<br />
Was bleibt noch übrig? – Nicht viel! Da liegt es nahe, einen zusätzlichen Begriff einzuführen:<br />
die Referenzdaten. Referenzdaten sind Geoinformationen, welche herangezogen<br />
werden können, um weitere Informationen darauf zu projizieren. Die Idee ist einleuchtend,<br />
den Begriff präzise zu fassen, jedoch schwierig. Er wurde in den Entwurf des neuen<br />
Geoinformationsgesetzes aufgenommen, und hat in den vorberatenden Gremien zu<br />
entsprechend heftigen Diskussionen geführt. Bei genauerem Hinsehen enthalten selbst<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 16.3
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
<strong>Interoperabilität</strong>: nicht nur eine Frage der Technologie<br />
einfachste Geoinformationen Angaben zu 'Fremdobjekten', beispielsweise Länder, Kantone<br />
oder Gemeinden, Nationalstrassen, Hauptstrassen und Nebenstrassen, Haus- und<br />
Parzellennummern. Und mit Sachinformationen kombinierte Geoinformationen - z.B.<br />
eine mit geologischen Informationen angereicherte Karte - kann von <strong>and</strong>eren als Grundlage<br />
für weitere Arbeiten genutzt werden - beispielsweise die Planung von Atom-<br />
Endlagern.<br />
Wir möchten ein - möglichst weltumspannendes <strong>Interoperabilität</strong>snetz für Geoinformationen<br />
schaffen. Dazu sind Normen zur Abbildung von räumlichen Informationen notwendig,<br />
jedoch, wie diese Beispiele verdeutlichen, nicht hinreichend. Zusätzlich brauchen<br />
wir auch Normen zur Abbildung der Angaben, welche mit ihnen verknüpft werden<br />
sollen. <strong>Interoperabilität</strong> im Bereich der Geoinformationen kann und darf daher<br />
nicht bei den Geoinformationen im engeren Sinn stehen bleiben, sonst ist sie nur von<br />
begrenztem Nutzen.<br />
2.3 Vergabe von Namen und Identifikatoren<br />
Was wären L<strong>and</strong>eskarten ohne Ortsbezeichnungen oder Stadtpläne ohne Strassennamen?<br />
Im Gegensatz zur allgemeinen Syntax und Semantik ist es <strong>of</strong>t nicht, oder nur bedingt<br />
möglich, derartige Namen oder Identifikatoren in Normen oder St<strong>and</strong>ards festzuhalten,<br />
dennoch sind sie für die <strong>Interoperabilität</strong> unabdingbar. Nur wenn zwei Kommunikationspartner<br />
demselben Objekt gleich sagen, wissen sie, dass sie vom Gleichen<br />
sprechen. Neben St<strong>and</strong>ardisierungsgremien, welche die notwendigen Normen erarbeiten,<br />
herausgeben und pflegen, brauchen wir Institutionen, welche Objekte, zu denen wir<br />
Informationen austauschen möchten, identifizieren und die Listen der vergebenen Identifikatoren<br />
aktuell und für alle Betr<strong>of</strong>fenen elektronisch zugänglich publizieren.<br />
Idealerweise ist überschneidungsfrei definiert, wer für welche Namensräume zuständig<br />
ist. Diese aus technischer Sicht einfach aufzustellende Forderung enthält jedoch im Einzelfall<br />
einigen Zündst<strong>of</strong>f. So ist sich die Staatengemeinschaft nicht einig, ob Taiwan ein<br />
eigenständiger Staat ist oder lediglich eine – abtrünnige - Provinz Chinas. Die Anerkennung<br />
eines Staates ist ein politischer Akt, der im schlimmsten Fall zum Krieg führen<br />
kann.<br />
Vor dem Zeitalter der Vernetzung hat jede Anwendung notgedrungen die von ihr benötigten<br />
Daten selbst verwaltet und identifiziert. Möchte man sie austauschen, bringt das<br />
Probleme. In unterschiedlichsten Fachgebieten sind Arbeiten im Gang, diese anzugehen.<br />
Ein Beispiel sind die Bemühungen zur Einführung von Identifikatoren für juristische<br />
und natürliche Personen.<br />
Noch ist für viele Objekte nicht verbindlich geregelt, wer ihre Namen vergibt. Die Festlegung,<br />
wer w<strong>of</strong>ür Namen vergibt, und das Akzeptieren dieser Definitionsgewalt durch<br />
die Kommunikationsgemeinschaft sind primär organisatorische und politische Entscheide,<br />
und diese laufen selten ohne Ausein<strong>and</strong>ersetzungen und Machtkämpfe ab.<br />
Hier liegt noch einige Arbeit vor uns.<br />
3 Zweite Stossrichtung: Service excellence<br />
<strong>Interoperabilität</strong> ist kein Selbstzweck. Wir arbeiten daran, weil wir uns davon Vorteile<br />
versprechen. Diese Vorteile nutzen wir jedoch erst, wenn die Systeme in Realität zusammenarbeiten.<br />
Der Bundesrat hat zum Ziel, dass die Behörden die Möglichkeiten der<br />
Informationstechnologien nutzen, um der Privatwirtschaft, Bürgerinnen und Bürgern<br />
16.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
<strong>Interoperabilität</strong>: nicht nur eine Frage der Technologie<br />
den Zugang zu ihren Dienstleistungen erleichtern. Dabei ist sowohl die eingehende wie<br />
die ausgehende Kommunikation betr<strong>of</strong>fen:<br />
Dazu müssen:<br />
� die Datenproduzenten die Daten elektronisch erstellen (was, z.B. in der amtlichen<br />
Vermessung noch nicht überall der Fall ist)<br />
� die Daten in geeigneten Formaten und zu realistischen Konditionen elektronisch<br />
zur Verfügung gestellt werden<br />
� eine geeignete Infrastruktur für den Datenaustausch bereitstehen<br />
� die Datenempfänger über die geeignete Infrastruktur verfügen, um die Daten einzulesen<br />
und zu verarbeiten.<br />
Die aufgeführten Bedingungen mögen banal erscheinen. In der Praxis soweit zu kommen,<br />
dass z.B. die Pläne aller Grundstücke in der Schweiz tatsächlich elektronische erfasst<br />
sind und die Programme, welche sie verwalten, dazu in der Lage sind, sie elektronisch<br />
auszutauschen, ist alles <strong>and</strong>ere als trivial. Dazu sind ist Überzeugungsarbeit bei<br />
Amtlichen Vermessern, Gemeindepräsidenten und Politikern notwendig und sind teilweise<br />
grössere Investitionen unumgänglich. Selbstverständlich arbeitet auch der Bund<br />
daran, seine Geoinformationsdaten einfach elektronisch zugänglich zu machen.<br />
4 Dritte Stossrichtung: Vernetzung<br />
Wir streben nach einer dichteren Vernetzung und besseren <strong>Interoperabilität</strong>. Systemtheoretisch<br />
betrachtet, modifizieren wir damit die Interaktionsregeln innerhalb eines dynamischen<br />
Systems. Dies muss unweigerlich Auswirkungen auf das Gesamtsystem haben:<br />
Es wird sich verändern. Ob wir wollen oder nicht, wir werden nicht darum herum<br />
kommen, auf die Veränderungen zu reagieren. Wer strategisch denkt, wird sich nicht<br />
damit zufrieden geben. Er wird die möglichen Veränderungen vorwegnehmen und, so<br />
gut es geht, gestaltend darauf einwirken wollen.<br />
Einige der Felder, in denen Veränderungen bevorstehen, sind die folgenden:<br />
� Tarifierung und Finanzierung<br />
� Authentizität und Urheberrecht<br />
� Datenschutz<br />
� Verantwortung der Datenanbieter<br />
4.1 Die Tarifierungs- und Finanzierungsmodelle sind zu<br />
überarbeiten.<br />
Noch vor nicht allzu langer Zeit hatten Geoinformationen die Form von Karten oder<br />
Plänen und konnten daher wie klassische Güter geh<strong>and</strong>elt werden. Werden sie in Form<br />
von digitalen Datensätzen weitergegeben, ist das nur noch bedingt möglich. Denn digitale<br />
Informationen können in Sekundenbruchteilen kopiert, transportiert, neu zusammengestellt,<br />
verändert oder mit neuen Informationen verknüpft werden.<br />
Die elektronische Weitergabe schafft jedoch ein neues Potential: Für Partner, Behörden<br />
und auch Unternehmen, wird es leichter, Daten einzukaufen und sie zu neuen Produkten<br />
zu verarbeiten, welche sie dann ihrerseits weiterverkaufen.<br />
So gesehen wird der Staat gewissermassen zum Rohst<strong>of</strong>flieferanten für die weiterverarbeitende<br />
Industrie. Für die nachgelagerten Informationsverarbeiter wird die Nutzung<br />
der Rohdaten umso interessanter, je kostengünstiger er sie erwerben kann. Ist ihr Preis<br />
zu hoch, werden seine eigenen Produkte zu teuer und dadurch weniger attraktiv.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 16.5
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
<strong>Interoperabilität</strong>: nicht nur eine Frage der Technologie<br />
Der Bundesrat verfolgt die Strategie, seine Geodaten den Nutzern zu möglichst günstigen<br />
Preisen zur Verfügung zu stellen und so für die Wirtschaft förderliche Bedingungen<br />
zu schaffen. Er ist bemüht, die Kantone zu einer ähnlichen Strategie zu bewegen. Die<br />
gleichzeitig verfolgten Sparanstrengungen auf Seiten des Staates erschweren allerdings<br />
eine konsequente Umsetzung.<br />
4.2 Urheberrecht und Authentizität<br />
Daten, welche elektronisch weitergegeben werden, sieht man ohne spezielle Massnahmen<br />
den Urheber nicht mehr an, und sie können ohne sein Wissen und seine Zustimmung<br />
weiterbearbeitet, ja gar weiterverkauft werden. Ich kann ohne grössere Probleme<br />
Video-Dateien vom Internet herunterladen, mit einfachen Programmen bearbeiten, zusammenkopieren<br />
und das Resultat unter meinem Namen weiterverbreiten. Dies ist bei<br />
Geoinformationen nicht <strong>and</strong>ers.<br />
Die einfache Kopierbarkeit stellt ganze Geschäftsbereiche vor bisher ungelöste Probleme.<br />
Eingespielte Verrechnungsmechanismen werden ausgehöhlt. Die Durchsetzung des<br />
Urheberrechts in der E-Welt ist ein noch nicht gelöstes Problem. Was tun wir z.B. wenn<br />
das Kartenwerk der L<strong>and</strong>estopographie plötzlich in die Hände einer Gruppe gerät, welche<br />
es auf einem Server in Übersee ins Internet stellt?<br />
Die einfache Kopierbarkeit und Modifizierbarkeit produziert noch ein weiteres Problem:<br />
Woher weiss ich, ob ich eine autorisierte Version der Daten in den Händen habe? Wie<br />
kann ich z.B. sicher sein, ob es sich beim Vermessungsplan, den ich am Bildschirm sehe,<br />
um eine autorisierte Kopie h<strong>and</strong>elt?<br />
Zwar gibt es erste technologische Ansätze, die hier Abhilfe schaffen wollen wie z.B. die<br />
des Digital Rights Management (DRM), doch diese eignen sich für den uns interessierenden<br />
Kontext nur bedingt, da sie für Objekte konzipiert sind, welche als Einheit auf<br />
einem bestimmten Gerät abgespielt werden.<br />
Die gesetzlichen Grundlagen in diesem Bereich sind erst rudimentär vorh<strong>and</strong>en, die nötigen<br />
technischen Lösungen noch ungenügend.<br />
4.3 Datenschutz<br />
Die einfache Zugänglichkeit und Verknüpfbarkeit von Geoinformationen bringt auch<br />
neue Probleme mit sich. Eines besteht darin, dass es schwieriger wird, Informationen<br />
geheim zu halten. Angaben über dasselbe Gebiet aus verschiedenen Quellen können mit<br />
relativ geringem Aufw<strong>and</strong> verglichen und Unterschiede ausgewertet werden. So ist es<br />
möglich, Satellitenaufnahmen mit von den lokalen Behörden herausgegebenen Karten<br />
abzugleichen. Dabei können gerade Informationen, welche bewusst weggelassen wurden,<br />
Geheimdiensten interessante Aufschlüsse geben...<br />
Oder Personendaten können mit Geoinformationen verknüpft werden. Bringt man Angaben<br />
im Telefonbuch, Gebäudeadressen und Kartenmaterial zusammen, kann auf<br />
Knopfdruck sichtbar gemacht werden, wer wo wohnt. Trägt eine Person ein eingeschaltetes<br />
H<strong>and</strong>y bei sich, ist ihr Aufenthaltsort bekannt. Ohne grössere Probleme könnte auf<br />
einer Web-Seite eine Karte aufgeschaltet werden, welche anzeigt, wo wer sich gerade<br />
befindet. Derartige Informationen können in Katastrophensituationen helfen, Personen<br />
aufzufinden. Die Polizei kann sie nutzen, um Verbrecher zu fassen. Sie sind jedoch genauso<br />
interessant für Privatdetektive, Geheimdienste und Terroristen.<br />
Wenn wir die <strong>Interoperabilität</strong> verbessern, dürfen wir Massnahmen nicht vernachlässigen,<br />
welche sicherstellen, dass mit den Informationen kein Missbrauch getrieben wird.<br />
16.6 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
<strong>Interoperabilität</strong>: nicht nur eine Frage der Technologie<br />
Gegenwärtig tun sich Staat und Politik schwer bei der Festlegung, wie mit elektronischen<br />
Daten umgegangen werden, was erlaubt und was verboten sein soll. Manche gehen<br />
beispielsweise soweit, die elektronische Version der Schweizerkarte zu schützenswerten<br />
Personendaten zu erklären, da sie potentiell mit Personendaten verknüpft werden<br />
können.<br />
4.4 Verantwortung der Datenanbieter<br />
<strong>Interoperabilität</strong> ist kein abstrakter Wunsch. Geodaten sind mehr und mehr elektronisch<br />
zugänglich, und der Markt beginnt die sich daraus ergebenden Möglichkeiten zu nutzen.<br />
Es ist absehbar, dass sich nach und nach ganze Wertschöpfungsketten aufbauen<br />
werden. Ob gewollt oder ungewollt werden die Abnehmer von Daten sich mit steigenden<br />
Kundenwünschen konfrontiert sehen. Diese betreffen einerseits die Stabilität des<br />
Angebots: Wer Daten eines <strong>and</strong>eren nutzt, um daraus eigene Produkte zu generieren,<br />
zählt darauf, dass diese auch in Zukunft verfügbar sein werden. Der volkswirtschaftliche<br />
Nutzen wird dann am grössten sein, wenn die Datenanbieter ihre Produkte präzise<br />
definieren und ihren Kunden garantieren können, dass ihr Angebot über längere Zeit<br />
zur Verfügung stehen wird.<br />
Andererseits wird nicht zu vermeiden sein, dass die Kunden auf den Geschmack kommen<br />
und neue Wünsche vorbringen werden, welche die Anbieter unter Druck setzen.<br />
So ist beispielsweise vorhersehbar, dass die Forderungen nach höherer Aktualität der<br />
Daten steigen werden.<br />
5 Schlusswort<br />
Ist <strong>Interoperabilität</strong> im Geoinformationsbereich Realität, entsteht logisch gesehen ein<br />
riesiger Datenpool, zu dem unterschiedliche Parteien ihren Beitrag leisten. Die Beteiligten,<br />
dazu gehört der Staat genauso wie betr<strong>of</strong>fene private Unternehmen, müssen sich<br />
darauf einigen, wer welchen Beitrag zu diesem Datenpool leistet und wie damit umgegangen<br />
werden soll. Der Datenpool an sich stellt ein volkswirtschaftlich nicht zu unterschätzendes<br />
Kapital dar, dessen Wert mit der Menge der darin integrierten Informationen<br />
steigt. Wie dieses Kapital bewirtschaftet – oder nicht bewirtschaftet – wird, entscheidet<br />
darüber, wie gross die Wertschöpfung sein wird.<br />
[eGovS 99] Regieren in der Informationsgesellschaft. Die eGovernment-Strategie des Bundes.<br />
13. Februar 2002.<br />
http://www.isb.admin.ch/imperia/md/content/egoverment/egov_stra<br />
tegie/de/egov_strat_bv_dt.pdf<br />
[IEEE 90] <strong>Institute</strong> <strong>of</strong> Electrical <strong>and</strong> Electronics Engineers. IEEE St<strong>and</strong>ard Computer<br />
Dictionary: A Compilation <strong>of</strong> IEEE St<strong>and</strong>ard Computer Glossaries. New York,<br />
NY: 1990.<br />
[IGES 98] Strategie des Bundesrates für eine Informationsgesellschaft in der Schweiz vom<br />
18. Februar 1998.<br />
http://www.infosociety.ch/site/propos/references/details.asp?id_fiche<br />
=2867#<br />
[eGovCH 05] eGovCH - eGovernment Architektur Schweiz. Informatikstrategieorgan Bund<br />
(in Vorbereitung).<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 16.7
François Golay, Pr<strong>of</strong>. Dr.<br />
Laboratoire de Systèmes d'information géographique<br />
Ecole Polytechnique Fédérale de Lausanne<br />
CH-1015 Lausanne<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 21 693 57 81<br />
+41 21 693 57 90<br />
17<br />
<strong>Interoperabilität</strong> auf strategischer und<br />
administrativer Ebene<br />
François Golay, ETH Lausanne
1 Einleitung<br />
Man kann die <strong>Interoperabilität</strong> vor allem als eine technologische Antwort auf das Bedürfnis,<br />
Geoinformationssysteme zu öffnen, betrachten. Die OGIS spielt weltweit eine zentrale<br />
Rolle für die normierte technologische Entwicklung und die damit verbundenen<br />
Systemarchitekturen. Programmmodule, Webservices, etc – erlauben es, eine effiziente<br />
Implementierung zu gewährleisten. Schliesslich erlauben die innerhalb der ISO besonders<br />
unternommenen Normungsarbeiten, diese Konzepte dauerhaft zu verankern.<br />
Die vorangegangenen Präsentationen dieses Seminars haben bewiesen, dass das Datensharing<br />
nicht nur eine Übereinkunft über den Behälter – die Architekturen – aber<br />
auch über den Inhalt des Datenaustausches erfordert. Welche Daten sind bei einem Austausch<br />
beteiligt? Worauf gründen sich Information über gemeinsame Prozesse? Diese<br />
Fragen wurden von Morf und Dorfschmid in der Präsentation „Modellst<strong>and</strong>ardisierung<br />
oder semantische <strong>Interoperabilität</strong>“ [Morf 2005] beh<strong>and</strong>elt. Die Erarbeitung und Normalisierung<br />
von gemeinsamen Modellen stellen eine Antwort auf diese Fragen dar, genauso<br />
wie die Identifikation und die Definition von Referenzen, die interoperable Systeme<br />
verknüpfen.<br />
Die vorhergehenden Redner haben schliesslich betont, dass die Vielfalt der beteiligten<br />
Personen und Institutionen, die im Sharing von Informationen [Buser 2005] und Diensten<br />
einbezogen wurden, eine adäquate Organisation erfordert, die die institutionelle<br />
Verantwortung jedes einzelnen Beteiligten respektiert.<br />
Wir stellen in diesem Beitrag fest, dass es kein wirksames Datensharing ohne Anerkennung<br />
und Berücksichtigung der Aufgaben und Strategien von jeder der beteiligten Institutionen,<br />
insbesondere von Gemeinden, Kantonen und dem Bund, geben wird. Wir postulieren,<br />
dass die technische und semantische <strong>Interoperabilität</strong> nur im Rahmen einer guten,<br />
strategischen und administrativen <strong>Interoperabilität</strong> der beteiligten Institutionen verwirklicht<br />
werden kann.<br />
2 Föderalistische Organisation der Schweiz und Aufgaben<br />
der beteiligten Institutionen<br />
Im Rahmen der Vorstudie zum Projekt e-geo.ch: Organisatorische und technische Aspekte<br />
[Moreni & al. 2003] wurde eine Verschachtelung der Entscheidungsebenen auf dem<br />
Staatsgebiet am Beispiel der Schweiz vorgeschlagen (Figur 1). Man kann unterschiedliche<br />
Positionierungen der verschiedenen staatlichen, kantonalen und kommunalen Beteiligten<br />
feststellen.<br />
Die Arbeitsbereiche der Akteure der verschiedenen Entscheidungsebenen können sich<br />
jedoch, ihren Verantwortlichkeiten im Bodennutzungsmanagement entsprechend, erheblich<br />
unterscheiden.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 17.1
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
<strong>Interoperabilität</strong> auf strategischer und administrativer Ebene<br />
Somit:<br />
NATIONAL<br />
REGIONAL<br />
LOKAL<br />
Etat<br />
Stadt<br />
Kanton<br />
Bund<br />
Kanton Kanton<br />
Gem. Gem. Stadt Gem.<br />
Figur 1 : Verschachtelungen der Entscheidungsebenen auf dem Staatsgebiet<br />
� Sind auf lokaler (kommunaler) Ebene die Grund- und Bodenangelegenheiten<br />
vorherrschend. Es h<strong>and</strong>elt sich zuallererst darum, die rechtliche und technische<br />
Grund- und Bodenverordnung verlässlich zu dokumentieren und als Bezugseinheit<br />
ist die Parzelle ausschlaggebend. Die Lokalisierung von technischen Infrastrukturen,<br />
die Verwaltung des bebauten Kulturgutes, usw., sind typische Beispiele<br />
für diese Ebene.<br />
� Auf regionaler (kantonaler) Ebene ist die räumliche Information vor allem ein<br />
Werkzeug für die Raumplanung. Die Erwartungen bestehen hauptsächlich im<br />
Erhalt von korrekt aktualisierten, und zusammenhängenden Informationen zur<br />
Bodennutzung und der Umwelt. Öffentliche Gelände, verseuchte Gebiete, Bodennutzungsstatistiken,<br />
Räume, die durch natürliche Gefahren bedroht werden,<br />
sind einige Beispiele für Informationen auf diesem Niveau.<br />
� Auf nationaler (eidgenössischer) Ebene geht es vor allem darum, die Konzeption<br />
und Planung von kohärenten Strategien durch zuständige Organisationen und<br />
Einrichtungen möglich zu machen. Ein globaler und homogener Zugang zu den<br />
Informationen, ohne „Grenzen zwischen den Regionen, stellt eine nötige Vorbedingung<br />
dar.<br />
17.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten<br />
Einrichtungen öffentlichen Rechtes, z. B. Elektrizitätswerke usw.)<br />
Privatgesellschaften
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
<strong>Interoperabilität</strong> auf strategischer und administrativer Ebene<br />
3 Datenintegration zwischen verschiedenen Entscheidungsebenen<br />
Die Primärdaten, die für die Erfüllung der Aufgaben dieser verschiedenen strategischen<br />
Niveaus notwendig sind, sind jedoch teilweise dieselben: Indikatoren, welche die L<strong>and</strong>schaftsnutzung<br />
im Kantonsmassstab angeben, können von den kommunalen Rahmennutzungsplänen<br />
abgeleitet werden. Bodennutzungsstatistiken auf nationaler Ebene<br />
können anh<strong>and</strong> lokaler Bodennutzungsangaben erstellt werden, usw. Aus Effizienzgründen<br />
sollen die entsprechenden Daten nur ein einziges Mal erstellt und verwaltet werden,<br />
und zwar auf der am besten geeigneten Ebene (Dieses Prinzip wird im [INSPIRE 2002]-<br />
Bericht für geographische Infrastrukturen und Daten beschrieben)<br />
Die oben aufgeführten, speziellen Bedürfnisse jeder Entscheidungsebene müssen unabhängig<br />
von der Einrichtung, die mit deren Realisierung beauftragt ist, bei der Datenerfassung<br />
und Verteilung berücksichtigt werden. Einige kürzlich aufgetretene Schwierigkeiten<br />
zeugen von den Schwierigkeiten, die auf diese Wechselbeziehung der Bedürfnisse<br />
zurückzuführen sind<br />
� Gemeinden, welche Katasterdaten besitzen, geben sich aus Furcht vor einer übermässigen<br />
Zentralisierung zurückhaltend, diese Daten der kantonalen Stelle<br />
zu übergeben. Wie sollen kantonale Stellen eine umfassende Verwaltung des<br />
Kantonsgebiets verwirklichen?<br />
� Hingegen haben Kantone, welche Daten in grossem Massstab besitzen, kein Interesse<br />
daran eine klar dokumentierte, systematische Qualität ihrer Daten zu fördern.<br />
Diese Daten sind folglich nicht brauchbar für Verwaltungsaufgaben auf lokaler<br />
Ebene.<br />
� Einige Kantone widersetzen sich der Harmonisierung von Datenstrukturen, welche<br />
vom Bund verlangt wird, um einen nahtlosen Datenzugang für die ganze<br />
Schweiz zu ermöglichen.<br />
Solche Probleme existieren auch zwischen öffentlichen Einrichtungen und Privaten Unternehmen.<br />
Wieso war es z.B. notwendig, das Strassennetz für die Bedürfnisse der automobilen<br />
Navigation nochmals zu erfassen?<br />
4 Die <strong>Interoperabilität</strong> auf strategischer und administrativer<br />
Ebene – eine entwicklungsbedürftige Ressource !<br />
Die Wiederverwendung von Daten zwischen verschiedenen strategischen Ebenen setzt<br />
jedoch voraus, dass jeder Beteiligte einer Entscheidungsebene die Bedürfnisse der <strong>and</strong>eren<br />
Entscheidungsebenen kennt (und anerkennt!), und dass er bereit ist, die Datenerfassung,<br />
für die er zuständig ist, gemäss der Bedürfnisse sämtlicher <strong>and</strong>erer Partner durchzuführen.<br />
Dieser Anspruch betrifft nicht die technischen und organisatorischen Dimensionen der<br />
<strong>Interoperabilität</strong>, sondern eine Art der Anerkennungsteilung und der Teilung von Zielsetzungen<br />
und Aufgaben. Es ist schwieriger die <strong>Interoperabilität</strong> auf strategischer und<br />
administrativer Ebene durchzuführen, als auf der technischen Ebene, jedoch stellt die<br />
<strong>Interoperabilität</strong> auf strategischer und administrativer Ebene eine Anforderung an<br />
die technische, semantische und organisatorische Ebene. Diese Anforderung wird im<br />
[INSPIRE 2002] – Bericht beschrieben: administrative interoperability should precede geospatial<br />
interoperability.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 17.3
Organisatorische Folgen der <strong>Interoperabilität</strong> I<br />
<strong>Interoperabilität</strong> auf strategischer und administrativer Ebene<br />
Die Berücksichtigung des Grundsatzes der strategischen und administrativen <strong>Interoperabilität</strong><br />
müsste auch die Annahme und die Umsetzung durch alle Beteiligten erleichtern<br />
und eine gute H<strong>and</strong>habung der <strong>Interoperabilität</strong> ermöglichen:<br />
� Man sollte versuchen, die Datenerfassung und -verwaltung von gemeinsamen<br />
Interesse zu an eine einzige Instanz zu delegieren.<br />
� Um eine adäquate Qualität dieser Aufgaben zu garantieren, die den wesentlichen<br />
Bedürfnissen sämtlicher Partner entspricht, müssen die Normen auf dem<br />
höchsten Entscheidungsniveau definiert werden (SNV/ASN – Normen für die<br />
gesamte Schweiz).<br />
Bibliographie<br />
Buser, R., 2005, Conséquences organisationnelles de l’interopérabilité, Actes de la journée<br />
d’étude « Interopérabilité pour l’utilisation généralisée de la géoinformation », mars<br />
2005, A. Carosio éd., ETH Zürich.<br />
INSPIRE, 2002, INSPIRE Architecture <strong>and</strong> St<strong>and</strong>ards Position Paper, JRC-<strong>Institute</strong> for Environment<br />
<strong>and</strong> Sustainability, Ispra.<br />
Moreni, C. & al., 2003, Etude préliminaire au projet e-geo.ch: aspects organisationnels et<br />
techniques, Rapport sur m<strong>and</strong>at de la COSIG, EPFL-LASIG et ETHZ-Geoinformation.<br />
Morf, A. & Dorfschmied, J., 2005, Modèles st<strong>and</strong>ardizes ou interopérabilité sémantique,<br />
Actes de la journée d’étude « Interopérabilité pour l’utilisation généralisée de la géoinformation<br />
», mars 2005, A. Carosio éd., ETH Zürich.<br />
17.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Ivo A. Leiss, Dr.<br />
Zollikerstr. 65<br />
CH-8702 Zollikon<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 44 395 12 80<br />
+41 44 395 12 34<br />
18<br />
<strong>Interoperabilität</strong> in der Praxis<br />
Erfahrungen aus Projekten im In- und<br />
Ausl<strong>and</strong><br />
Ivo A. Leiss, Ernst Basler + Partner AG
1 Einleitung<br />
Die <strong>Interoperabilität</strong> bei der Nutzung von Geoinformation ist bei GIS-Projekten im Planungs-<br />
und Umweltbereich ein allgegenwärtiges Thema. In der Praxis trifft man auf<br />
verschiedene Aspekte der <strong>Interoperabilität</strong>:<br />
� beim Austausch von Geodaten (z.B. mit Auftraggebern oder Partnerfirmen)<br />
� beim Austausch von Applikationen und Systemen (z.B. Businessapplikationen<br />
ohne geografischen Bezug)<br />
� beim Austausch von Prozessen (z.B. Service zur Geocodierung von Adressen)<br />
Der vorliegende Beitrag soll die <strong>Interoperabilität</strong> von Geoinformation am Beispiel von<br />
ausgewählten Projekten der Firma Ernst Basler + Partner AG im In- und Ausl<strong>and</strong> beleuchten.<br />
Typische <strong>Interoperabilität</strong>sprobleme und deren Lösungsansätze werden aufgezeigt.<br />
Die Bedeutung der <strong>Interoperabilität</strong> für die Zukunft wird bewertet.<br />
2 Beispielprojekte<br />
2.1 Nationale Projekte: Drei kantonale Beispiele<br />
Die <strong>Interoperabilität</strong> bei der Nutzung von Geoinformation in den Kantonen soll anh<strong>and</strong><br />
drei verschiedener GIS-Projekte beleuchtet werden (Tab. 1).<br />
Projektname<br />
Auftraggeber Aufgaben Projektpartner<br />
(Laufzeit)<br />
Strassenlärm<br />
Zürich<br />
(2000 – 2005)<br />
Gefahrenhinweiskarte<br />
Hochwasser<br />
Luzern<br />
(2003 – 2005)<br />
SPATZ<br />
Mapserver<br />
Graubünden<br />
(2004 – 2005)<br />
Baudirektion des<br />
Kantons Zürich,<br />
Fachstelle Lärmschutz<br />
Bau-, Umwelt- und<br />
Wirtschaftsdepartemen<br />
t des Kantons Luzern,<br />
Dienststelle Verkehr<br />
und Infrastruktur<br />
Archäologischer<br />
Dienst, Kanton<br />
Graubünden<br />
Portierung des<br />
Strassenlärmkatasters<br />
(Emissionen), GIS-<br />
Analyse<br />
lärmbetr<strong>of</strong>fener<br />
Gebäude<br />
(Immissionen)<br />
Erstellen einer<br />
Gefahrenhinweiskarte<br />
für den<br />
Naturgefahrenprozess<br />
Hochwasser im Kanton<br />
Luzern, Erstellen eines<br />
Ereigniskatasters<br />
Darstellung von<br />
archäologischen<br />
Informationen<br />
(SPATZ) in einem<br />
Intranet-Kartendienst,<br />
Interaktion zwischen<br />
dem Archäologischen<br />
Informationssystem<br />
und dem Kartendienst<br />
(z.B. Editieren von<br />
Punkten)<br />
Norsonic Brechbühl<br />
AG<br />
F. Preisig AG<br />
GIS-Zentrum Kt.<br />
Zürich<br />
Kost+Partner AG<br />
ITECO<br />
Geoinformation und<br />
Vermessung Kt.<br />
Luzern<br />
GIS<br />
Kompetenzzentrum Kt.<br />
Graubünden<br />
GWZ Informatik<br />
Tab. 1 : Übersicht über drei kantonale Projekte. Sie dienen als Grundlage für die nachfolgenden<br />
Überlegungen.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 18.1
Organisatorische Folgen der <strong>Interoperabilität</strong> II<br />
<strong>Interoperabilität</strong> in der Praxis: Erfahrungen aus Projekten im In- und Ausl<strong>and</strong><br />
2.2 Internationale Projekte: Transnationales Internet Karten-<br />
Informationssystem für Überschwemmungen (TIMIS flood)<br />
Das Projekt TIMIS flood hat zum Ziel, für das internationale Einzugsgebiet der Mosel<br />
und der Nahe ein transnationales Informationssystem für Überschwemmungen aufzubauen.<br />
Dabei kommen innovative GIS und IT-Technologien zum Einsatz. TIMIS flood<br />
soll folgende Informationen bereitstellen:<br />
� harmonisierte und qualitativ hochstehende räumliche Daten,<br />
� Informationen über Gefahr und Risiko sowie<br />
� Informationen zur Vorhersage und Warnung.<br />
Sämtliche resultierenden Informationsdienste sollen schliesslich unter einer Plattform<br />
namens TIMIS flood Service kombiniert werden. Dieser Service wird den verschiedenen<br />
Benutzern (Behörden, Wissenschaftler und Öffentlichkeit) im Jahr 2008 zugänglich sein.<br />
Auftraggeber sind sieben verschiedene Behörden aus Luxemburg, Deutschl<strong>and</strong> und<br />
Frankreich. Die Firma Ernst Basler + Partner AG ist als Generalunternehmer für die Koordination<br />
des Projekts und die Realisierung des Informationssystems verantwortlich.<br />
Sie wird unterstützt durch die Firma Hydrotec aus Aachen (Deutschl<strong>and</strong>) sowie durch<br />
zahlreiche Subunternehmer im Bereich der Datenerfassung. Weitere Informationen sind<br />
unter http://www.timisflood.net erhältlich.<br />
3 Aspekte der <strong>Interoperabilität</strong><br />
3.1 Austausch von Geodaten<br />
Der Austausch der Geodaten bildet im Rahmen der Beispielprojekte die weitaus grösste<br />
Herausforderung im Bereich der <strong>Interoperabilität</strong>. Zwischen folgenden Beteiligten müssen<br />
Daten ausgetauscht werden (Abbildung 1):<br />
� Ernst Basler + Partner als Auftragnehmer<br />
� Auftraggeber<br />
� Projektpartner (Partnerfirmen, Subunternehmer, <strong>and</strong>ere Beteiligte)<br />
� Externe Geodatenlieferanten (z.B. Swisstopo, Vermessungsbüros)<br />
Abb. 1 : Beteiligte beim Austausch von Geodaten.<br />
St<strong>and</strong>ardisierte Austauschformate werden zum heutigen Zeitpunkt kaum verwendet. In<br />
der Regel wird im Vorfeld eines Datenaustauschs ein geeignetes Transferformat – in<br />
Abhängigkeit der Möglichkeiten von Quell- und Zielsystem – festgelegt (Tabelle 2).<br />
18.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Organisatorische Folgen der <strong>Interoperabilität</strong> II<br />
<strong>Interoperabilität</strong> in der Praxis: Erfahrungen aus Projekten im In- und Ausl<strong>and</strong><br />
Austauschformate für Vektordaten Anteil (geschätzt)<br />
ESRI (Shape, Coverage, Personal Geodatabase, Exportdatei) 60%<br />
CAD (DXF, DGN) 10%<br />
Datenbanken und Tabellen (MS Access, MS Excel, dbf) 10%<br />
XML 10%<br />
sAndere (INTERLIS, ASCII) 10%<br />
Austauschformate für Rasterdaten Anteil (geschätzt)<br />
Tiff (World, Geo) 50%<br />
ESRI (Grid) 20%<br />
ASCII 20%<br />
Andere 10%<br />
Tab. 2 : Verwendete Formate für den Austausch von Geodaten. Der Anteil bezieht sich auf die<br />
Anzahl zu transferierenden Informationen in den Beispielprojekten und ist geschätzt.<br />
Der hohe Anteil an ESRI-Formaten lässt sich damit begründen, dass die Firma Ernst<br />
Basler + Partner AG auf ESRI spezialisiert ist und damit häufig Auftraggeber und Projektpartner<br />
hat, welche ebenfalls mit ESRI arbeiten.<br />
Nur rund 20% aller Daten, welche uns von den Auftraggebern zur Verfügung gestellt<br />
werden, beinhalten nutzbare Metainformationen. Aber auch hier hat sich noch kein interkantonaler,<br />
geschweige denn ein internationaler St<strong>and</strong>ard durchgesetzt.<br />
3.2 Austausch von Applikationen und Systemen<br />
Die gemeinsame Nutzung von Applikationen hat in den letzten Jahren an Bedeutung<br />
gewonnen. Grund dafür ist die generell zunehmende Vernetzung von Systemen.<br />
In den Beispielprojekten kommt dieser Aspekt in den webbasierten Projekten "SPATZ<br />
Mapserver" und "TIMIS flood" zum Tragen.<br />
Beim archäologischen Informationssystem SPATZ h<strong>and</strong>elt es sich um eine Oracle-<br />
Datenbank mit Benutzerschnittstelle für die Datenbewirtschaftung. Der lesende Zugriff<br />
auf SPATZ erfolgt via OGR Virtual Format, einem Open Source Treiber, welcher einfache<br />
Geoobjekte aus einer ODBC-Datenbank anh<strong>and</strong> einer XML-Konfigurationsdatei<br />
liest. Der schreibende Zugriff auf die Oracle-Datenbank wird durch eine Schnittstelle<br />
der Firma GWZ Informatik (Vertreiber von SPATZ) sichergestellt. Die Parameter werden<br />
dabei mittels ASCII-Datei übergeben.<br />
Da es sich beim SPATZ Mapserver um eine Intranet-Anwendung h<strong>and</strong>elt, kommen zur<br />
Zeit keine OGC-kompatiblen Austauschformate (WFS, WMS) zum Einsatz.<br />
Im Projekt TIMIS flood werden die geografischen Informationsdienste zur Zeit basierend<br />
auf WFS und WMS konzipiert. Für das Internet-Portal (auf Basis von ESRI ArcIMS)<br />
ist dies mittlerweile eine St<strong>and</strong>ardfunktionalität. Zum heutigen Zeitpunkt ist jedoch<br />
noch nicht sichergestellt, dass alle nationalen Server diese OGC-Formate unterstützen.<br />
Wir gehen aber davon aus, dass sich diese OGC-Formate in den kommenden Jahren<br />
durchsetzen werden.<br />
3.3 Austausch von Prozessen<br />
Die <strong>Interoperabilität</strong> von Prozessen ist zum heutigen Zeitpunkt noch am wenigsten<br />
fortgeschritten. Im Zusammenhang mit Web-Services (z.B. für die Geocodierung von<br />
Adressen) wird dieser Aspekt in Zukunft aber immer wichtiger.<br />
Der Austausch von Prozessen ist unter den Beispielprojekten einzig im Projekt TIMIS<br />
flood vorgesehen. Ab 2008 soll es möglich sein, die Hochwasservorhersage für einen<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 18.3
Organisatorische Folgen der <strong>Interoperabilität</strong> II<br />
<strong>Interoperabilität</strong> in der Praxis: Erfahrungen aus Projekten im In- und Ausl<strong>and</strong><br />
St<strong>and</strong>ort an der deutschen Mosel (Rheinl<strong>and</strong>-Pfalz) aus der Kombination verschiedener<br />
Prozesse zu generieren: aus der Wettervorhersage des deutschen Wetterdienstes, aus<br />
den aktuellen Pegelmessungen im Einzugsgebiet (Frankreich, Luxemburg und Deutschl<strong>and</strong>),<br />
aus einer Abflussvorhersage aus Baden-Württemberg und aus einer hydraulischen<br />
Modellierung für den entsprechenden St<strong>and</strong>ort in Rheinl<strong>and</strong>-Pfalz. Als Resultat<br />
erhält der Benutzer die Hochwasservorhersage in Karten- und Textform (ähnlich wie<br />
bei der Wettervorhersage). Die gleichen Prozesse können auch für beliebige Orte in Luxemburg<br />
beansprucht werden.<br />
Noch sind nicht alle Fragen gelöst. Die grössten Hürden liegen jedoch weniger in der<br />
technischen Realisierbarkeit, sondern viel eher in der Akzeptanz der verschiedenen<br />
(ausländischen) Prozesse und Verfahren. Für eine erfolgreiche Umsetzung sind hier<br />
weniger St<strong>and</strong>ards, sondern eher eine gute Kommunikation innerhalb und ausserhalb<br />
des Projekts notwendig.<br />
3.4 <strong>Interoperabilität</strong> und Projektplanung<br />
Die oben erwähnten Aspekte kommen zum Tragen, wenn ein Projekt ausgelöst ist. Erfahrungen<br />
in der Praxis haben aber gezeigt, dass der Kosten-, Kommunikations- und<br />
Zeitaufw<strong>and</strong> für die <strong>Interoperabilität</strong> im Allgemeinen unterschätzt wird. Bei der Planung<br />
eines Projekts sind folgende Informationen häufig nicht oder nur unzureichend<br />
vorh<strong>and</strong>en:<br />
� Qualität der Geodaten oder der Systeme<br />
Neben der grundsätzlich zu prüfenden Qualität der Datengrundlage kann es alleine<br />
aufgrund der genutzten Formate zu Qualitätsproblemen kommen: Ein<br />
CAD-Format setzt <strong>and</strong>ere Integritätsregeln auf einen geometrischen Datensatz<br />
als ein GIS-Format. Selbst innerhalb verschiedener GIS-Formate bestehen unterschiedlich<br />
strenge Anforderungen an den Aufbau und die Konsistenz der Daten.<br />
� Erstellung oder Anpassung notwendiger Schnittstellen<br />
Während der Bearbeitung eines Projektes kann es passieren, dass aus rein technischen<br />
Gründen neue Schnittstellen notwendig werden oder geplante Schnittstellen<br />
angepasst werden müssen.<br />
� Vollständige Dokumentationen<br />
Bei der Planung werden Eigenschaften der zu nutzenden Daten oder Systeme<br />
implizit angenommen, die nicht oder nur unzureichend dokumentiert oder in<br />
Metadaten vorh<strong>and</strong>en sind.<br />
Der Vollständigkeit halber soll auch erwähnt sein, dass Projektideen immer wieder<br />
durch zu hohe Tarife für Geodaten wieder begraben werden.<br />
4 Fazit<br />
Aus den oben dargestellten Projekten lassen sich bezüglich <strong>Interoperabilität</strong> bei der<br />
Nutzung von Geodaten folgende Folgerungen ableiten:<br />
� Bei GIS-Projekten im Planungs- und Umweltbereicht steht heute bezüglich <strong>Interoperabilität</strong><br />
vor allem der Austausch von Daten im Vordergrund.<br />
� Beim Datenaustausch gelangen kaum St<strong>and</strong>ards zum Einsatz. Am häufigsten<br />
werden die Formate ESRI Shape und Tiff verwendet. Dies hängt aber in erster<br />
Linie von den Möglichkeiten (der GIS-S<strong>of</strong>tware) der Parteien ab. INTERLIS wird<br />
zur Zeit (zu) wenig eingesetzt.<br />
18.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Organisatorische Folgen der <strong>Interoperabilität</strong> II<br />
<strong>Interoperabilität</strong> in der Praxis: Erfahrungen aus Projekten im In- und Ausl<strong>and</strong><br />
� XML als Austauschformat ist im Vormarsch, doch wird die <strong>Interoperabilität</strong><br />
durch die unzähligen Variationen (WFS, GML, ESRI XML, INTERLIS 2, etc.) reduziert.<br />
� Die OGC-Formate WFS und WMS werden sich etablieren und zumindest bei internationalen<br />
Projekten zum St<strong>and</strong>ard werden. Andere Formate werden vom<br />
Markt verschwinden oder ein Nischendasein führen.<br />
Insgesamt ist festzuhalten: Die Anzahl Projekte, bei denen Daten oder Systeme zusammengeführt<br />
werden müssen, steigt stetig. Aus diesem Grund wird die <strong>Interoperabilität</strong><br />
von Applikationen und Prozessen in den kommenden Jahren zunehmen. Ob sich in Zukunft<br />
St<strong>and</strong>ards einstellen oder nicht: wir als Dienstleister im Bereich der Geoinformatik<br />
müssen uns ohnehin anpassen; an die Bedürfnisse der Auftraggeber und Projektpartner<br />
oder an die vorgegebenen St<strong>and</strong>ards.<br />
Abkürzungen und Begriffe<br />
Abkürzung/Begriff Definition<br />
ASCII American St<strong>and</strong>ard Code for Information Interchange; Codierung<br />
von insgesamt 128 Zeichen (Buchstaben, Zahlen und Satz- und<br />
Sonderzeichen)<br />
CAD Computer Aided Design<br />
DXF Vektorbasiertes Dateiformat der Firma Autodesk, speziell für<br />
CAD-Lösungen entwickelt.<br />
DGN Vektorbasiertes Dateiformat der Firma Intergraph<br />
GIS Geographische Informationssysteme<br />
GML Geography Markup Language; XML-basiertes Format für den Austausch<br />
von GIS-Daten<br />
Grid Rasterbasiertes Dateiformat der Firma ESRI<br />
INTERLIS Datenbeschreibungs- und –modellierungssprache, basiert in der<br />
Version 2 auf XML<br />
ODBC Open Data Base Connectivity, Datenbanktreiber für anwendungsunabhängige<br />
Datenbankzugriffe<br />
OGC Open Geospatial Consortium<br />
OGR S<strong>of</strong>twarebibliothek für den Zugriff auf verschiedene GIS Vektorformate<br />
Oracle S<strong>of</strong>twareanbieter für Datenbanken<br />
Shape Dateiformat für Vektordaten, entwickelt von der Firma ESRI<br />
Tiff Dateiformat zur Speicherung von Rasterdaten<br />
TIMIS Transnational Internet Map Information System<br />
SPATZ Synergie Projekt Archäologie Thurgau und Zürich<br />
WFS Web Feature Service; Internet-Protokoll zum Lesen und Schreiben<br />
von GIS-Daten im Vektorformat, basiert auf GML<br />
WMS Web Map Service, Internet-Protokoll zum Lesen und Schreiben<br />
von digitalen Karten<br />
XML Extensible Markup Language; Format zur Erstellung strukturierter<br />
Dokumente<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 18.5
Kaul Beratungen GmbH<br />
Christian Kaul<br />
Flaachtalstrasse 8<br />
CH-8412 Hünikon<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 52 343 79 01<br />
+41 52 343 79 02<br />
19<br />
Perspektiven für die Geomatik-Berufe<br />
Christian Kaul, Kaul Beratungen GmbH
Perspektiven für die Geomatik-Berufe …<br />
… oder was es braucht, damit das zarte Pflänzchen „<strong>Interoperabilität</strong>“ zum Blühen<br />
kommt.<br />
1 Einleitung<br />
Die zentrale Aussage gleich vorweg: Die neuen technischen Möglichkeiten der <strong>Interoperabilität</strong><br />
alleine sichern der Geomatik-Branche noch keine neuen Märkte!<br />
<strong>Interoperabilität</strong> ist auch kein technisches Projekt, das nach Abschluss eine Firma interoperabel<br />
macht. <strong>Interoperabilität</strong> muss viel mehr zu einer grundlegenden Denkhaltung<br />
in allen Geomatik-Berufen werden. Damit können auch die rasanten Entwicklungen der<br />
Zukunft in diesem Bereich proaktiv genutzt werden.<br />
Damit die Chancen und Möglichkeiten der <strong>Interoperabilität</strong> neue Perspektiven für die<br />
Geomatik-Berufe eröffnen werden, ist das Zusammenspiel von verschiedenen Ebenen<br />
und Facetten notwendig. Die technischen Herausforderungen sind dabei nur ein Blatt<br />
einer weitgefächerten Blüte.<br />
Systemtechnisches<br />
denken<br />
und<br />
h<strong>and</strong>eln<br />
Technische<br />
Fähigkeiten<br />
Visionär<br />
kooperativ<br />
Generalist<br />
Permanente<br />
berufliche<br />
Weiterentwicklung<br />
Arbeit in<br />
Multidisziplinären<br />
Projekten<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 19.1
Organisatorische Folgen der <strong>Interoperabilität</strong> II<br />
Perspektiven für die Geomatik-Berufe<br />
2 In Zentrum - der Unternehmer<br />
Im Zentrum steht die unternehmerische Persönlichkeit in Privatwirtschaft und Verwaltung.<br />
Das Thema <strong>Interoperabilität</strong> kann nicht passiv-reaktiv angegangen werden. Es<br />
braucht den visionären Geist, der eine - vielleicht nur vage - Vorstellung davon hat, wohin<br />
die Reise gehen könnten. Ohne Visionen ist jede Organisation in dieser schnelllebigen<br />
Zeit früher oder später dem Untergang geweiht.<br />
Inter-operability braucht Inter-working. Die Fähigkeit und der Wille zur Kooperation<br />
mit <strong>and</strong>eren Organisationen muss von den Chefs vorgelebt und gefördert werden. Dabei<br />
darf ruhig anerkannt werden, dass <strong>and</strong>ere auch etwas können – denn das ist die Basis<br />
der gemeinsamen künftigen Erfolge.<br />
Mit der <strong>Interoperabilität</strong> der Geo-Daten geht eine massive Ausweitung der Daten-<br />
Inhalte einher, mit der eine Organisation konfrontiert wird. Damit rückt die alte Fähigkeit<br />
des Generalisten wieder mehr ins Zentrum des Interesses. Nach Pr<strong>of</strong>. Dr. Hans Ulrich<br />
ist ein Generalist: "... jem<strong>and</strong>, der auch in seinem eigenen Wirkungsbereich lange<br />
nicht alles weiss, der aber das Ganze versteht." Als integrierende Ergänzung der Spezialisten<br />
in den Unternehmen muss sich der Unternehmer stärker der Übersicht, dem Ganzen<br />
widmen.<br />
3 Die Blütenblätter – das Unternehmen<br />
Für die Mitarbeiter eines Unternehmens sind folgende vier Bereiche im Hinblick auf interoperables<br />
Arbeiten von Bedeutung:<br />
Technische Fähigkeiten<br />
Das Unternehmen muss die notwendigen Techniken für interoperables Arbeiten beherrschen.<br />
Dabei wird sich das Schwergewicht noch mehr auf die Informatik verlagern. Eine<br />
Firma muss in der Lage sein, die sich immer schneller ändernden Bedürfnisse der Kunden<br />
zufrieden zu stellen und gleichzeitig die rasante technische Entwicklung aktiv zu<br />
nutzen.<br />
Inhaltlich werden die Web-Technologien sehr stark ins Zentrum des Interesses rücken.<br />
Die datentechnischen Fähigkeiten müssen aber parallel dazu noch weiter ausgebaut<br />
werden.<br />
Arbeiten in multidisziplinären Projekten<br />
Die <strong>Interoperabilität</strong> bietet die Chance in themenübergreifenden Projekten effizient zusammenzuarbeiten.<br />
Dies erfordert eine <strong>of</strong>fene und interessierte Haltung aller Beteiligter<br />
bezüglich <strong>and</strong>erer Themen und <strong>and</strong>eren Teams und ein Bewusstsein, dass dies nicht<br />
von selber erfolgreich geschieht, sondern gelernt und geübt werden kann und muss.<br />
Systemtechnisches Denken und H<strong>and</strong>eln<br />
Die Anforderungen an die Produkte der Geomatik-Branche werden auch weiterhin stetig<br />
steigen. Die einfachen, klaren Antworten werden immer seltener werden. In einem<br />
solchen Umfeld haben sich seit Jahren die Grundsätze und Methoden der Systemtechnik<br />
bewährt. Diese Art des Denkens und H<strong>and</strong>elns kann nicht einigen Spezialisten überlassen<br />
werden, denn sie bildet die Grundlage für ein erfolgreiches interoperables Arbeiten<br />
aller Geomatik-Berufe.<br />
Permanente berufliche Weiterentwicklung<br />
Die oben beschriebenen Anforderungen an die Mitarbeiter können nicht einfach neben<br />
dem Alltagsgeschehen entwickelt werden. Es braucht eine aktive, gezielte und vor allem<br />
19.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Organisatorische Folgen der <strong>Interoperabilität</strong> II<br />
Perspektiven für die Geomatik-Berufe<br />
permanente Weiterentwicklung aller Mitarbeiter. Mit kurzfristigen Feuerwehrübungen<br />
können die notwendigen Fähigkeiten in einer Firma nicht nachhaltig erarbeitet und aufrechterhalten<br />
werden.<br />
4 Die Kelchblätter – eine nachhaltige Basis<br />
Die UNO definiert nachhaltige Entwicklung als: "... eine Entwicklung, die die Bedürfnisse<br />
der Gegenwart befriedigt, ohne zu riskieren, dass künftige Generationen ihre eigenen<br />
Bedürfnisse nicht befriedigen können." Diese Definition ist weitherum anerkannt und<br />
bildet die Basis der so genannten "Agenda21" der UNO.<br />
Im Zusammenhang mit nachhaltiger Entwicklung werden <strong>of</strong>t die drei Zieldimensionen<br />
Gesellschaft, Wirtschaft und Umwelt beleuchtet.<br />
Gesellschaft<br />
Durch ihren Hauptauftraggeber, die Öffentliche H<strong>and</strong>, haben die Dienstleistungen der<br />
Geomatik-Branche traditionell einen grossen Bezug zur Gesellschaft. Aktivitäten im Bereich<br />
der <strong>Interoperabilität</strong> sind zum Teil sehr stark vom Rahmen der Gesellschaft geprägt.<br />
Eine sehr grosse Bedeutung muss in diesem Zusammenhang dem Rechtssystem<br />
beigemessen werden. Die rechtlichen Rahmenbedingungen sind immer höher einzustufen<br />
als die technischen. Deshalb bilden gute rechtliche Kenntnisse und eine sorgfältige<br />
Analyse dieser Sachverhalte die Grundlage erfolgreicher Projekte und Produkte.<br />
Einen weiteren massgebenden Faktor bildet die Normierung. Wie an dieser Tagung<br />
aufgezeigt, sind zur Zeit sehr grosse Bestrebungen auf Stufe ISO und CEN im Gange.<br />
Hier gilt es, aktiv die langjährige praktische Erfahrung der Schweiz in diese Normierungsarbeiten<br />
einzubringen.<br />
Wirtschaft<br />
Das heisst nichts <strong>and</strong>eres, als dass sich auch die Aktivitäten im Bereich der <strong>Interoperabilität</strong><br />
schlussendlich positiv aufrechnen lassen. Das wird nur gelingen, wenn den Aufwändungen<br />
auch ein entsprechend nachgefragter Nutzen gegenübersteht. Demzufolge<br />
definiert der Nutzer und Endkunde die Rahmenbedingungen für die Wirtschaftlichkeit<br />
und nicht die eigenen Vorstellungen der Branchen-Insider. Das bedingt jedoch viel bessere<br />
und ehrlichere Kenntnis der echten Bedürfnisse der Kunden.<br />
Diese Überlegungen gelten auch für die staatlich finanzierten Aktivitäten. Ein Geo-<br />
Dienst könnte vom Staat, durch Steuergelder finanziert, für den Nutzer unentgeltlich<br />
angeboten werden. Doch auch hier muss dem Aufw<strong>and</strong> an Steuergeldern ein entsprechender<br />
Nutzen gegenüberstehen.<br />
Umwelt<br />
Diese Zieldimension beinhaltet den Umgang mit Ressourcen in einem umfassenden<br />
Sinne, also die Aufforderung, die Aktivitäten im Bereich der <strong>Interoperabilität</strong> mit einem<br />
Minimum an Aufw<strong>and</strong> von Energie, Material, Arbeit und Geld umzusetzen. Im Bereich<br />
der <strong>Interoperabilität</strong> kann dies in erster Linie mit einer exzellenten Nachführbarkeit der<br />
Lösungen und einem systemneutralen Investitionsschutz für die Daten erreicht werden.<br />
Auch die genialste technische Lösung wird nie nachhaltig sein, wenn sie alle zwei Jahre<br />
neu aufgesetzt werden muss. Der gesicherte Investitionsschutz und die konsequente<br />
Nachführung der Daten sind eine grosse Verantwortung der Branche gegenüber kommenden<br />
Generationen.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 19.3
Organisatorische Folgen der <strong>Interoperabilität</strong> II<br />
Perspektiven für die Geomatik-Berufe<br />
5 Neue Perspektiven dank <strong>Interoperabilität</strong><br />
Auf der Basis der bisherigen Überlegungen kann gesagt werden:<br />
� es wird einfacher, grossflächige regionale oder überregionale Projekte zu bearbeiten<br />
� die Zusammenarbeit verschiedener interner und externer Teams wird effizienter<br />
� es können gemeinsam Produkte entwickelt und lanciert werden, die für eine<br />
einzelne Firma nicht denkbar sind. Z.B. Portallösungen für Geodaten-Nutzung<br />
� die bewährte Zusammenarbeit von öffentlicher H<strong>and</strong> und Privatwirtschaft (Public-Private-Partnership<br />
PPP) kann vertieft werden<br />
� durch die vermehrte Zusammenarbeit und das bessere gegenseitige Verständnis<br />
werden sich neue Tätigkeitsfelder eröffnen<br />
� die gemeinsame Nutzung von Technologien, Know-how, Kapazitäten (von Mitarbeitern,<br />
HW, SW, etc.) , Datenleitungen, etc. wird attraktiver<br />
� bereits vorh<strong>and</strong>ene Fähigkeiten können unter dem Titel "<strong>Interoperabilität</strong>" besser<br />
kommuniziert werden<br />
Weiterführende Informationen:<br />
- Buch Systems Engineering, Methodik und Praxis, Hrsg: Daenzer / Huber, Verlag Industrielle<br />
Organisation, Zürich, ISBN 3-85743-998-X<br />
- Zur Agenda 21: http://www.are.admin.ch/are/de/na<br />
19.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Jürg Kaufmann, dipl. Ing. ETH<br />
KAUFMANN CONSULTING/FIG<br />
Hauffeld 109<br />
CH-8455 Rüdlingen<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 1 867 14 36<br />
+41 1 867 34 89<br />
20<br />
Tarifierung, Kostenfragen<br />
Jürg Kaufmann, KAUFMANN Consulting / FIG
1 Einleitung<br />
Die folgenden Überlegungen sollen aufzeigen, wie sich die <strong>Interoperabilität</strong> auf die Kostengestaltung<br />
und die Festlegung von Tarifen auswirken.<br />
Um diese Fragen zu klären seien zunächst einmal einige Begriffe definiert:<br />
<strong>Interoperabilität</strong>:<br />
Zusammenarbeit in einem <strong>of</strong>fenen System (gemäß dem Client/Server--Modell). Unabhängig von<br />
der verwendeten Hardware, den eingesetzten Betriebssystemen, der verwendeten Netzwerktechnologie<br />
und der Realisierung einer Anwendung kann eine Zusammenarbeit zwischen diesen<br />
Anwendungen erfolgen.<br />
Tarif:<br />
1. verbindliches Verzeichnis der Preis- bzw. Gebührensätze für bestimmte Lieferungen, Leistungen,<br />
Steuern u. a.<br />
2. durch Vertrag od. Verordnung festgelegte Höhe von Preisen, Löhnen, Gehältern u. a.<br />
Tarifieren:<br />
die Höhe einer Leistung durch Tarif bestimmen.<br />
Der Begriff der Kosten darf wohl als bekannt vorausgesetzt werden.<br />
Um die Folgen der <strong>Interoperabilität</strong> abschätzen zu können wird zunächst der traditionelle<br />
Ablauf der Leistungserbringung dargestellt. Der Vergleich mit dem Ablauf bei<br />
Anwendung der <strong>Interoperabilität</strong> kann Hinweise auf die Veränderung der Kostenfaktoren<br />
geben.<br />
Die Auswirkungen der <strong>Interoperabilität</strong> auf die Kostenstruktur sollen aufgezeigt werden.<br />
In einem weiteren Kapitel werden die Überlegungen zur Tarifierung dargestellt.<br />
Schliesslich werden die Resultate der Groupe de Réflexion "Datenabgabe und Gebühren",<br />
sowie die Arbeiten der KOGIS im Bereich Tarifierung und in Bezug auf die Auswirkungen<br />
der <strong>Interoperabilität</strong> beleuchtet.<br />
Einige Schlussfolgerungen sollen das zukünftige Verhalten der Informationsgesellschaft<br />
skizzieren.<br />
2 Auswirkungen der <strong>Interoperabilität</strong> auf den Ablauf der<br />
Leistungserbringung<br />
Das uns allen bestens bekannte Schema für den Bezug von Leistungen ist in Abbildung 1<br />
dargestellt.<br />
Bestellung<br />
Empfangen der Lieferung<br />
Bezahlung<br />
Abb. 1 : Schema für den Bezug von Leistungen<br />
Anfrage bei Logistik<br />
Bereitstellung der Lieferung<br />
Inkasso<br />
Dieser Ablauf war seit Beginn der H<strong>and</strong>elsaktivitäten des Menschen immer derselbe<br />
und er spielt auch heute noch eine dominierende Rolle. Gewisse Neuerungen führten zu<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 20.1
Organisatorische Folgen der <strong>Interoperabilität</strong> II<br />
Tarifierung, Kostenfragen<br />
verkürzten Abläufen, beispielsweise bei der Selbstbedienung oder zu effizienteren Zahlungsverfahren,<br />
wie bei der Verwendung von Strichcodes. Auch das e-shopping läuft<br />
nach demselben Schema ab. Die Verkäuferin wird durch ein Terminal und ihre Beratung<br />
durch Text und Bilder ersetzt. Nur für das Lächeln und die Ausstrahlung der Verkäuferin<br />
oder der Serviertochter kann diese Art der Leistungserbringung nicht überzeugend<br />
ersetzen.<br />
Bei Anwendung der <strong>Interoperabilität</strong> wird genau dasselbe Schema durchlaufen. Aber<br />
alle menschlichen Teilnehmer an der Leistungserbringung sind durch Maschinen ersetzt.<br />
Angesichts der hohen Lohnkosten in der Schweiz, muss also die Leistungserbringung<br />
grundsätzlich günstiger werden.<br />
Da die Leistungen durch Automaten erbracht werden, ist es notwendig, die Abrechnung<br />
automatisch zu erfassen<br />
3 Auswirkungen der <strong>Interoperabilität</strong> auf die Kosten<br />
Die anwendbaren Kostenkomponenten für die Leistungserbringung sind normalerweise:<br />
� Die Kosten für die Bestellungsaufnahme<br />
� Die Kosten für die Bestellungsübermittlung<br />
� Die Kosten der Bereitstellung der Lieferung<br />
� Die Kosten für die Lieferung<br />
� Die Kosten für die Rechnungsstellung und das Inkasso.<br />
Im Normalfall werden diese Kosten als Gemeinkostenanteil auf den Preis der gelieferten<br />
Ware oder Dienstleistung geschlagen. Gegenüber dem Kunden wird diese Kostenkomponente<br />
nicht <strong>of</strong>fen gelegt. Gemeinkostenanteile können ermittelt werden, wenn die Beteiligten<br />
an einem Prozess und ihre spezifischen Kosten bekannt sind.<br />
Branchenübliche Festlegungen der Gemeinkostenzuschläge sind im traditionellen System<br />
die Regel.<br />
Bei einer interoperablen Arbeitsweise ist aber nicht mehr à priori bekannt, welche Maschinen/Systeme/Automaten<br />
an der Ausführung einer Lieferung beteiligt sind. Die bestellte<br />
Ware wird dort abgeholt oder eingesehen, wo sie verfügbar ist.<br />
Unabhängig davon, wie man einen Preis für die Ware oder die Dienstleistung festsetzt,<br />
muss eine Lösung gefunden werden, welche ohne Gemeinkostenzuschlag auskommt.<br />
Man muss die Kosten für die Leistungserbringung gesondert betrachten.<br />
Da die Leistungserbringung durch Automaten erfolgt, muss die Erfassung der preisbildenden<br />
Faktoren automatisch erfolgen können, weil es im Umfeld der <strong>Interoperabilität</strong><br />
unmöglich wird, die Wege zu verfolgen und die nötigen Abrechnungsdaten manuell zu<br />
erfassen.<br />
Es ist zudem wenig sinnvoll jede Komponente, die bei der Leistungserbringung zum<br />
Zuge kommt, individuell und mit eigenen Kostensätzen in ein Abrechnungssystem einzubringen,<br />
da die Preisgestaltung der einzelnen beteiligten Dienstleister wohl niemals<br />
über einen Leist geschlagen werden können.<br />
Deshalb ist es im Zeitalter der <strong>Interoperabilität</strong> zwingend, mit vereinbarten Tarifen zu<br />
arbeiten.<br />
20.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Organisatorische Folgen der <strong>Interoperabilität</strong> II<br />
Tarifierung, Kostenfragen<br />
4 Auswirkungen der <strong>Interoperabilität</strong> auf die Tarifierung<br />
Eine vernünftige Tarifierung der Leistungserbringung ist also eine Notwendigkeit, damit<br />
die Vorteile der <strong>Interoperabilität</strong> schliesslich voll zum Tragen kommen.<br />
Die Anforderungen an die Tarifierung wurden teilweise bereits bei den Kosten genannt:<br />
� Die preisbildenden Faktoren müssen automatisch ermittelt, festgehalten und abgerechnet<br />
werden können.<br />
� Die festgelegten Tarife müssen mit dem Aufw<strong>and</strong> für die Erbringung der Leistung<br />
in einem sinnvollen Verhältnis stehen.<br />
� Die Tarife müssen für den Besteller nachvollziehbar sein.<br />
Über die Art der Preisgestaltung sind Lösungsansätze vorh<strong>and</strong>en, aber es hat sich bisher<br />
keine einheitliche Lösung herauskristallisiert.<br />
5 Resultate bisheriger Tarifierungsanstrengungen<br />
In der Schweiz existieren zwei Arbeiten, die sich mit der Tarifierung beschäftigen. Einerseits<br />
hat eine von der V+D1 eingesetzte, paritätische Groupe de Réflexion sich mit den<br />
Problemen der Datenabgabe und Gebühren befasst. Eine weitere Expertenarbeit über<br />
Tarifierungsprobleme wurde im Auftrag von KOGIS erstellt. Die Arbeiten dieser Teams<br />
wurden auf höchster Stufe koordiniert.<br />
Beide Arbeiten kommen zum Schluss, dass für Geodaten eine Strategie der marginal cost<br />
anzuwenden sei. Marginal cost umfassen ausschliesslich die Bearbeitungs- und Lieferkosten.<br />
Als Begründung für diese Empfehlung wird angeführt, dass Geodaten in der<br />
Regel in Erfüllung eines gesetzlichen Auftrags beschafft werden. Dies trifft in der Tat<br />
auf die meisten Geodaten zu. Im Entwurf des Geoinformationsgesetzes wird denn auch<br />
von Geobasisdaten gesprochen, die von nationalem, kantonalem oder kommunalem Interesse<br />
liegen, je nachdem, welche Stufe den gesetzlichen Auftrag beschlossen hat. Damit<br />
sind die Investitionskosten, d.h. die Kosten für die Datenbeschaffung von der Allgemeinheit<br />
zu übernehmen. Um aber einen möglichst grossen Kostenrückfluss zu generieren,<br />
sollen die Daten möglichst günstig an die Interessenten abgegeben werden, damit<br />
deren Steuern möglichst hoch ausfallen, weil die Gewinne nicht durch Beschaffungskosten<br />
geschmälert und möglichst gross werden, wenn aus diesen Daten Produkte<br />
mit Mehrwert generiert werden können.<br />
Im Rahmen der Arbeiten der Groupe de Réflexion wurde nachgewiesen, dass die Investitionskostenbeiträge,<br />
wie sie durch den Bericht Buschor im Rahmen der Arbeiten zur Reform<br />
der Amtlichen Vermessung vorgeschlagen und in der Mehrzahl der Kantone eingeführt<br />
wurden, keinen signifikanten Beitrag zur Abschreibung der getätigten Investition<br />
in die Amtliche Vermessung zu liefern vermag. Bei hohen Preisen wird die Anzahl<br />
Bezüge durch die Benützer minimiert indem das Abgaberegime unterlaufen wird. Bei<br />
tiefen Preisen werden die Daten zwar häufiger bezogen, aber die eingenommenen Beiträge<br />
fallen zu klein aus, um zu einer sinnvollen Amortisationsdauer zu führen. Die<br />
Groupe de Réflexion empfiehlt deshalb, zum Regime der marginal cost, das bis zur Einführung<br />
des Vorschlags Buschor Gültigkeit hatte, zurückzukehren.<br />
Die Groupe de Réflexion hat sich ebenfalls über Tarifansätze Gedanken gemacht. Dabei<br />
hat sie versucht, die Auswirkungen der <strong>Interoperabilität</strong> in ihre Betrachtungen einzubeziehen.<br />
1 Anm. d. Red. : V+D :Eidgenössische Vermessungsdirektion<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 20.3
Organisatorische Folgen der <strong>Interoperabilität</strong> II<br />
Tarifierung, Kostenfragen<br />
Sie hat folgende Kostenfaktoren gemäss Abbildung 2 vorgesehen:<br />
Komponente Ansatz vorgeschlagener Preis<br />
Administrative Bearbeitung eines Auftrages Pauschale pro Auftrag CHF 50.-/Auftrag<br />
Technische Bearbeitung eines Auftrages Pauschale pro Auftrag CHF 50.-/Auftrag<br />
Vertriebsaufw<strong>and</strong> für die Ablieferung des<br />
Resultates<br />
Pauschale pro Auftrag CHF 20.-/Auftrag<br />
Benützung der Infrastruktur für die<br />
Erstellung des gewünschten Produktes<br />
CHF/Megabyte<br />
bezogener Daten<br />
CHF 5.-/Megabyte<br />
Vektordaten<br />
(INTERLIS-Format)<br />
Benützung der Internetinfrastruktur bei<br />
Bezug der Daten über das Internet<br />
Pro Anfrage CHF 10.- pro Anfrage<br />
Abb. 2 : Tarifierungsvorschlag der Groupe de Réflexion<br />
Bei einer bediensten Abgabe kommen die ersten vier Komponenten zur Anwendung.<br />
Wird das Internet oder eine <strong>and</strong>ere interoperable Infrastruktur benützt, werden die grau<br />
unterlegten Komponenten verrechnet.<br />
Ein völlig neuer und transparenter Ansatz ist die Erfassung und Belastung der Menge<br />
der tatsächlich bezogenen Daten, wobei bei den Vektordaten das wohldefinierte IN-<br />
TERLIS-Format, für Rasterdaten ein Äquivalent zur Anwendung kommt. Mit diesem<br />
Ansatz soll die Bereitstellung der Lieferung entschädigt werden. Dem Bezüger wird<br />
damit eine Rechnung gestellt, die den Daten, die er bezogen hat, objektiv entspricht. Er<br />
kann damit seinen Bezugspreis beeinflussen.<br />
Dieses Konstrukt sollte den Herausforderungen der <strong>Interoperabilität</strong> genügen können.<br />
Allerdings sind die Tauglichkeit des Ansatzes und die Höhe der Tarife im praktischen<br />
Einsatz zu testen.<br />
Die Strategie der marginal cost wurde zwar in den Entwurf zum neuen Geoinformationsgesetz<br />
aufgenommen. Ob sie zur Anwendung kommt ist vorerst nicht klar. Es ist in<br />
jedem Fall weise, die Bearbeitungs- und Lieferkosten separat festzusetzen und damit<br />
vom traditionellen Muster des Gemeinkostenzuschlags wegzugehen.<br />
6 Schlussfolgerungen<br />
Die <strong>Interoperabilität</strong> ändert die traditionellen Kostenfragen nicht grundsätzlich, verschiebt<br />
aber den Schwerpunkt auf hochautomatisierte Prozesse bei der Leistungserbringung.<br />
Es müssen einfache und transparente Tarife geschaffen werden, um interoperable<br />
Lösungen auch kommerziell sinnvoll auszugestalten.<br />
Erste Ansätze sind vorh<strong>and</strong>en. Diese müssen aber in der praktischen Anwendung ausprobiert<br />
und allenfalls den Erfahrungen angepasst werden.<br />
Literatur<br />
Groupe de Réflexion Datenabgabe und Gebühren [2003] 'Vorschlag für die zukünftige<br />
Regelung der Datenabgabe und der Gebühren in der Amtlichen Vermessung, V+D,<br />
Bern<br />
Groupe de Réflexion diffusion des données et émoluments [2003] 'Proposition pour la<br />
future réglementation de la diffusion des données et des émoluments dans la Mensuration<br />
Officielle', D+M, Berne<br />
KOGISTarif [2002] Neue Tarifierungs- und Vertriebsstrategien von Geodaten des Bundes,<br />
INFRAS im Auftrage von KOGIS, 26. September 2002<br />
20.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Horst Düster, Dr.<br />
Amt für Geoinformation Kanton Solothurn<br />
Abteilung SO!GIS Koordination<br />
Werkh<strong>of</strong>str. 65<br />
CH-4509 Solothurn<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 32 627 25 32<br />
+41 32 627 22 14<br />
21<br />
Georeferenzierung, <strong>Interoperabilität</strong><br />
zwischen Vermessungsdaten und<br />
darauf aufbauender Rauminformation,<br />
Datenhierarchie und Nachführung der<br />
abhängigen Rauminformation<br />
Horst Düster,<br />
Amt für Geoinformation Kanton Solothurn
1 Situation<br />
Eine kantonale Verwaltung hat Ähnlichkeiten mit einer heterogenen Unternehmensstruktur.<br />
Die Verwaltungsorgane verfügen über eine vielfältige Aufgabenstruktur mit<br />
gleichzeitiger räumlicher Trennung der Einheiten. Herausragend ist dabei der grosse<br />
Informationsbedarf, besonders nach Geoinformationen.<br />
Zur Befriedigung dieses Informationsbedarfes steht eine grosse Zahl unabhängig funktionierender<br />
Informationsquellen bereit. In der Regel weisen diese Quellen Redundanzen<br />
auf. So werden z.B. Grundbuchzugehörigkeiten, Flurnamen von verschiedenen Objekten<br />
in unterschiedlichen Datenhaltungssystemen redundant bereit gehalten. Eine<br />
konsistente Pflege und Nachführung dieser eigentlich ungebundenen Informationen ist<br />
in der Regel unmöglich.<br />
Die Folge dieser Situation ist eine ineffiziente Ressourcennutzung, die insbesondere<br />
durch Entscheidungsunsicherheit hervorgerufen wird.<br />
Im Kanton Solothurn wurde ein GIS Leitbild entworfen, dessen Kernsätze sich auf die<br />
Erhöhung der Produktivität, Verbesserung der Entscheidungssicherheit und damit die<br />
Erhöhung des operationellen Nutzens sowie die Verbesserung des strategischen Nutzens<br />
mit dem Ziel die staatlichen Strukturen und Instrumente zu verbessern, beziehen.<br />
2 Strategie<br />
Die Vision zur strategischen Umsetzung des Leitbildes sieht eine Beschleunigung und<br />
Verbesserung der grundlegenden Verwaltungs- und Entscheidungsprozesse durch konsistente<br />
digitale Geo- und Sachinformationen vor. Dazu müssen Raum- und Sachinformationen<br />
logisch und redundanzfrei normalisiert vereint werden können. Die Voraussetzung<br />
dazu ist technische <strong>Interoperabilität</strong> durch <strong>of</strong>fene Schnittstellen. Um diese nutzen<br />
zu können wird konzeptionelle <strong>Interoperabilität</strong> durch <strong>of</strong>fene Systeme vorausgesetzt.<br />
Aufgrund des Regierungsziels 2005, "... 90% der St<strong>and</strong>ard-Benutzer sowie der Anwendungen<br />
sind auf Terminalserver unter Linux migriert", wird durch die Abteilung<br />
SO!GIS Koordination weitgehend freie und <strong>of</strong>fene S<strong>of</strong>tware eingesetzt.<br />
Open Source GIS bietet sich zur Umsetzung der Vision auf der Grundlage des Regierungsziels<br />
an. Da seitens dieser S<strong>of</strong>tware kein Interesse besteht, die Anwender an ein<br />
herstellerabhängiges System/Produkt zu binden, werden ein grosse Zahl verschiedener<br />
Datenformate unterstützt. Ausserdem wird eine breite Unterstützung <strong>of</strong>fener Spezifikationen<br />
und Schnittstellen wie z.B. die vielfältigen OGC Spezifikationen gewährleistet.<br />
Schliesslich sind die verwendeten Systemschnittstellen der Open Source GIS S<strong>of</strong>tware<br />
<strong>of</strong>fen dokumentiert und frei erhältlich.<br />
3 Systemumgebung<br />
Im Kanton Solothurn werden die folgenden Open Source GIS Komponenten im Rahmen<br />
einer Multischicht-Architektur eingesetzt. Zur persistenten Datenhaltung wird in der<br />
Datenschicht PostgreSQL verwendet. PostgreSQL folgt den St<strong>and</strong>ards SQL92 und<br />
SQL99. Mit der Erweiterung PostGIS wird PostgreSQL um den Funktionsumfang der<br />
OGC Spezifikation SQL for simple features erweitert. Auf diese Weise steht eine vollständig<br />
GIS fähige Datenhaltungsschicht, mit der über st<strong>and</strong>ardisierte Schnittstellen, als<br />
Grundlage zur technischen <strong>Interoperabilität</strong>, kommuniziert werden kann, zu Verfü-<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 21.1
Spezielle Aspekte der <strong>Interoperabilität</strong> in der Praxis<br />
Georeferenzierung, <strong>Interoperabilität</strong> zwischen Vermessungsdaten und darauf aufbauender<br />
Rauminformation, Datenhierarchie und Nachführung der abhängigen Rauminformation<br />
gung. Diese Umgebung bildet die Grundlage für die normalisierte Datenhaltung und<br />
Informationsverarbeitung. Applikationsschichten bzw. Anwendungen müssen deshalb<br />
nicht grundsätzlich über GIS-Funktionalität verfügen.<br />
Die Applikationsschichten und Applikationen sind den Anforderungen entsprechend<br />
vielfältig. Sowohl proprietäre Systeme auf Client-Server Basis über ODBC, JDBC,<br />
GDAL/OGR oder nativen Schnittstellen, als auch echte Multischicht-Architekturen, in<br />
der Regel Web basierend, werden eingesetzt.<br />
Grundsätzlich ist dieser Ansatz unabhängig von den eingesetzten Betriebssystemen,<br />
Programmiersprachen und Entwicklungsumgebungen, da die Kommunikation zwischen<br />
den einzelnen Komponenten st<strong>and</strong>ardisiert abläuft.<br />
4 Beispiel Bodenpr<strong>of</strong>il<br />
Am Beispiel der Abfrage von Informationen zu einem Bodenpr<strong>of</strong>il soll die Konzeption<br />
und Systemumgebung in einem konkreten Fall, wie er in Solothurn umgesetzt ist, illustriert<br />
werden.<br />
4.1 Problemstellung<br />
Die Informationen zu einem Bodenpr<strong>of</strong>il sollen redundanzfrei normalisiert abgelegt<br />
und gepflegt werden können. Dazu wird eine persistente und normalisierte Datenhaltung<br />
aufgebaut, die in eine Multischicht-Architektur integriert ist. Die Vereinigung der<br />
originären Information erfolgt über den Raum auf der Grundlage von SQL92 und dem<br />
OGC St<strong>and</strong>ard SQL for simple features. Die Applikationsschicht ist, in diesem Fall, mit<br />
Web Technologien aufgebaut. Es werden technisch und konzeptionell <strong>of</strong>fene und interoperable<br />
Schnittstellen verwendet.<br />
Ein Abfrageergebnis soll der Bodentyp sowie die aktuelle Grundbuchnummer der Liegenschaft,<br />
den aktuellen Flurnamen und die aktuelle Höhe, in der das jeweilige Bodenpr<strong>of</strong>il<br />
liegt, ermittelt werden.<br />
4.2 Lösung<br />
Aus der Sicht des Bodenpr<strong>of</strong>ils können die originären Informationen die Lage des Pr<strong>of</strong>ils<br />
im Raum als Geometrie und der Bodentyp sein. Sie werden in einer<br />
PostgreSQL/PostGIS Datenbank abgelegt und gepflegt. Zur Lösung der Problemstellung<br />
werden vom Bodenpr<strong>of</strong>il keine weiteren Informationen benötigt. Abgeleitet sind<br />
zur Lösung der Fragestellung, aus der Sicht des Bodenpr<strong>of</strong>ils, die Informationen aktuelle<br />
Parzellennummer, aktueller Flurname und aktuelle bekannte Höhe. Die abgeleiteten<br />
Informationen stammen alle aus dem Datenstamm der amtlichen Vermessung und<br />
werden dort unabhängig von den Bodeninformationen, in der PostgreSQL/PostGIS Datenbank<br />
gepflegt. Die Informationsebenen bilden somit eine flache Hierarchie, die a priori,<br />
ausser über den Raum, keine Beziehung zuein<strong>and</strong>er aufweisen. Die Beziehungen<br />
werden erst durch die Fragestellung generiert.<br />
Wird nun eine Abfrage via SQL for simple features formuliert, an die Datenbank geschickt,<br />
erfolgt die im SQL Statement formulierte Verschneidung und das System kann<br />
mit dem gewünschten Ergebnis antworten. So sieht die SQL Query für die Ermittlung<br />
der Grundbuchnummer der Parzelle in der das Pr<strong>of</strong>il liegt folgendermassen aus:<br />
21.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
Spezielle Aspekte der <strong>Interoperabilität</strong> in der Praxis<br />
Georeferenzierung, <strong>Interoperabilität</strong> zwischen Vermessungsdaten und darauf aufbauender<br />
Rauminformation, Datenhierarchie und Nachführung der abhängigen Rauminformation<br />
select bodenpr<strong>of</strong>il.bodentyp, parzellen.nummer<br />
from bodenpr<strong>of</strong>il, parzellen<br />
where distance(bodenpr<strong>of</strong>il.geometrie,parzellen.geometrie)=0;<br />
Grundsätzlich kann diese Query von jeder beliebigen Applikationsschicht bzw. Applikation<br />
abgesetzt werden. Die <strong>Interoperabilität</strong> wird durch ODBC, JDBC, GDAL/OGR<br />
oder native aber technisch <strong>of</strong>fen dokumentierte Schnittstellen gewährleistet.<br />
Abb. 1 : Systemarchitektur am Beispiel Bodenpr<strong>of</strong>il<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 21.3
Spezielle Aspekte der <strong>Interoperabilität</strong> in der Praxis<br />
Georeferenzierung, <strong>Interoperabilität</strong> zwischen Vermessungsdaten und darauf aufbauender<br />
Rauminformation, Datenhierarchie und Nachführung der abhängigen Rauminformation<br />
5 Fazit<br />
Die vorgestellte Strategie der Multischicht-Systemumgebung in Verbindung mit einer<br />
normalisierten Kommunikation zwischen den Komponenten ist sowohl unabhängig<br />
von Betriebssystemen als auch von Programmiersprachen, unter der Voraussetzung,<br />
dass die Kommunikationsst<strong>and</strong>ards zur <strong>Interoperabilität</strong> eingehalten werden. So ergeben<br />
sich die folgenden Verbesserungen.<br />
geringere Redundanzen<br />
Die seit mehreren Jahren in Solothurn verfolgte Strategie der Normalisierung der<br />
Grundlageninformationen führte zur erheblichen Reduktion der Redundanzen in der<br />
Grundlagenhaltung, da Objektfremde abgeleitete Informationen nicht mehr mit den jeweiligen<br />
Objekten gemeinsam gespeichert werden.<br />
effektiveres Datenmanagement<br />
Das Datenmanagement ist vereinfacht und effektiver geworden. Die Nachführung der<br />
Grundlagen erfolgt ausschliesslich auf den normalisierten Grundlageninformationen in<br />
einer horizontalen Hierarchie.<br />
verbindliche Daten<br />
Die normalisierten Grundlageninformationen werden separat gepflegt und aktualisiert.<br />
Da die gewünschte Information erst im Moment einer Abfrage generiert wird, konnte<br />
die Qualität der Abfrageergebnisse erheblich verbessert und die Entscheidungssicherheit<br />
erhöht werden.<br />
21.4 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten
22<br />
Der Mobilitäts-Graph<br />
Ein geographisches Rahmenwerk für die<br />
Partner des Mobilitäts-Informationssystems<br />
der Region Genf<br />
Pascal Oehrli<br />
SSIG - Service des Systèmes d'Information et de Géomatique<br />
DIAE - Département de l'Intérieur, de l'Agriculture et de l'Environnement<br />
7, rue des Gazomètres<br />
Case Postale 36<br />
CH-1211 Genève 8<br />
Tel :<br />
Fax :<br />
E-Mail :<br />
+41 22 327 79 29<br />
+41 22 327 50 70<br />
Pascal Oehrli, SSIG Genf
Das Mobilitäts-Informationssystem der Region Genf (SI Mobilité) ist ein thematisches<br />
Informationssystem aufgebaut im Rahmen des Système d’Information du Territoire Genevois<br />
(SITG). Die SI Mobilité ist eine Partnerschaft zwischen den verschiedenen Institutionen<br />
und Beteiligten, die mit Verkehr und deren Infrastrukturen zu tun haben (gilt für<br />
alle Verkehrsmittel). Seine Ziele sind es die Daten und Produkte im Bezug auf die Mobilität<br />
in Genf zu sammeln, organisieren, verwerten, koordinieren und vertreiben.<br />
Die Analyse der Situation hat gezeigt, dass die durch die verschiedenen Partner produzierten<br />
oder verwalteten Daten vonein<strong>and</strong>er unabhängig, manchmal redundant und<br />
direkt in einer Anwendung oder einem Modell insgesamt unbrauchbar waren. Trotz der<br />
Existenz eines Routen-Graphs innerhalb der SITG sind von den Beteiligten entsprechend<br />
den berufsspezifischen Bedürfnissen <strong>and</strong>ere Graphe entwickelt worden. Es existierten<br />
bis zu 5 oder 6 verschiedene Darstellungen der Geographie der Straßen.<br />
Aufgrund dieser Tatsachen ist eine Vorgehensweise lanciert worden um einen gemeinsamen<br />
Routen-Graph auszuarbeiten, der die Besonderheiten von jedem der Partner maximal<br />
integriert. Es hat sich schnell gezeigt, wie wertvoll es ist, über ein einziges und auf<br />
zentrale Art gehaltenes geographisches Bezugssystem verfügen zu können. Als Antwort<br />
auf dieses Bedürfnis entst<strong>and</strong> der Mobilitäts-Graph. Er integriert die Geographie derverschiedenen<br />
der Fortbewegung dienenden Infrastrukturen (Straßen, Wege und Pfade,<br />
Schiene und Wasserstraßen) sowie die Verbindungspunkte (Kreuzungen, Bahnsteige<br />
und Anlegeplätze). Ein Paket so genannter Anschlussregeln erlaubt das logische Verbinden<br />
verschiedener Komponenten des Mobilitäts-Graphs.<br />
Dieses allen Partnern von SI Mobilité zur Verfügung gestellte geographische Bezugssystem<br />
erlaubt es, die verschiedenen Daten, welche durch die Partner produziert und verwaltet<br />
werden, zu koordinieren. Diese Daten sind in einem Datenmodell organisiert<br />
welches die folgenden Aspekte integriert: die Infrastruktur selbst, die dafür aufgestellten<br />
Einrichtungen, die Mobilität im Allgemeinen, die verschiedenen angewendeten Gesetzgebungen,<br />
die Mittel zur Umsetzung dieser Gesetzgebungen und die Aspekte der<br />
Umwelt oder der Sicherheit. Diese vielfältigen Informationen unterschiedlicher Natur<br />
können durch den Mobilitäts-Graphen auf verschiedene Arten wie die lineare Gliederung,<br />
die Netztopologie oder <strong>and</strong>ere geographische oder nichtgeographische Beziehungsmittel<br />
koordiniert werden. Ausserdem bildet der Mobilitäts-Graph eine Basis für<br />
die Netzanalyse und die Routenberechnung oder <strong>and</strong>eren zeitlichen oder geographischen<br />
Abfragen auf einem multimodalen Reisenetz.<br />
<strong>Interoperabilität</strong> für die breite Nutzung von Geodaten 22.1
Spezielle Aspekte der <strong>Interoperabilität</strong> in der Praxis<br />
Der Mobilitäts-Graph: ein geographisches Rahmenwerk für die Partner<br />
des Mobilitäts-Informationssystems der Region Genf<br />
Parkplatz<br />
Linien TC<br />
Parkplatzzufahrten-<br />
Graph<br />
Wasserstrassen-<br />
Graph<br />
Halt TC<br />
Anlegestellen<br />
Routen-Graph<br />
Kreuzungen<br />
Anschlüsse<br />
Bahnsteig_Bahnh<strong>of</strong><br />
Eisenbahn-Graph<br />
Langsamverkehrs-<br />
Graph<br />
Mobilitäts-Graph<br />
Flughäfen<br />
Bahnhö-<br />
Fluglinien<br />
Der Mobilitäts-Graph wird durch den mit der Amtlichen Vermessung beauftragten<br />
Dienst verwaltet, auf den neusten St<strong>and</strong> gebracht und allen Partnern von SITG frei zur<br />
Verfügung gestellt.<br />
Als Schlussfolgerung kann man sagen, dass die Existenz eines minimalen gemeinsamen<br />
Bezugssystems eine wesentliche Basis für die <strong>Interoperabilität</strong> in einem Informationssystem<br />
darstellt, am Beispiel eines Koordinatensystems… oder eines für die linearen<br />
Strukturen gemeinsamen Referenz-Graphen. Der gemeinschaftliche Genfer Mobilitäts-<br />
Graph, ebenso wie die Vorgehensweise, die zu einer Übereinkunft aller betr<strong>of</strong>fenen Beteiligten<br />
geführt hat und die verschiedenen Modelle, die man durch dynamisches Segmentieren<br />
daran anknüpfen kann, scheinen ein gutes Beispiel für die Ausarbeitung eines<br />
gemeinsamen Bezugssystems zu sein.<br />
22.2 <strong>Interoperabilität</strong> für die breite Nutzung von Geodaten