Interoperabilität für die - ETH Z · NATO das Austauschformat DIGEST (Digitial Geographic...

Interoperabilität für die breite Nutzung von GeoinformationWeiterbildungstagung 17. und 18. März 2005 Herausgegeben von A. Carosio

Veranstalter

Institut für Geodäsie und Photogrammetrie, ETH Zürich ETHZ

Laboratoire de Systèmes d'information géographique, ETH Lausanne EPFL

Ecole d’ingénieurs du Canton de Vaud, Yverdon EIVD

Fachhochschule beider Basel Nordwestschweiz FHBB

Schweizerischer Verband für Geomatik und Landmanagement geosuisse

Konferenz der Kantonalen Vermessungsämter KKVA

Schweizerische Organisation für Geo-Information SOGI

Bundesamt für Landestopographie swisstopo

Koordination der Geoinformationen und der geographischen Informationssysteme beim Bund KOGIS

Schweizerischer Ingenieur- und Architektenverein SIA

Bundesamt für Landwirtschaft BLW

Deutsche Ausgabe : Weiterbildungstagung 17. und 18. März 2005 IGP Bericht Nr. 298 d ISBN 3-906467-51-1

Interoperabilität für die breite Nutzung von Geoinformation Herausgegeben von A. Carosio

Edition française : Journées d‘étude des 17 et 18 mars 2005 IGP Rapport Nr. 298 f ISBN 3-906467-52-X

Interopérabilité pour l'utilisation généralisée de la Géoinformation Textes rassemblés par A. Carosio

©2005Institut für Geodäsie und Photogrammetrie, ETH Zürich Alle Rechte vorbehalten

1 Vorwort

Die Verwirklichung der NGDI (Nationale Geodaten-Infrastrukturen) in Europa und weltweit ist unlösbar mit der Problematik der Vernetzung der Geoinformationssysteme verbunden. Geodaten gemeinsam nutzen ist eine dringende Notwendigkeit. Dafür braucht man technische und organisatorische Lösungen. Das Zauberwort, das zum Ziel führen soll, heisst: Interoperabilität!In Fachgremien und in Gesprächen mit Fachleuten fällt aber oft auf, dass Fragen und Lösungsansätze nur zum Teil bekannt sind. Es schien daher angebracht, eine Weiterbildungstagung zu diesem Thema zu organisie-ren, um das verfügbare Wissen zu sammeln, darzustellen und zu präsentieren. Wir glauben, dass es durch die Beteiligung der Organisationen, die heute an der Ent-wicklung von interoperablen Systemen arbeiten, gelungen ist, ein vielseitiges Programm zusammenzustellen, das die unterschiedlichsten Probleme beleuchtet und beschreibt. Den Autoren, die sich freiwillig zur Verfügung stellten, den Mitarbeitern der ETHZ und EPFL, die bei der Redaktion der deutschen und französischen Versionen des Berichtes mitwirkten sowie allen anderen Beteiligten möchten wir unseren herzlichen Dank aus-sprechen.

Alessandro Carosio Zürich, 3. März 2005

Organisationskomitee

Alessandro Carosio, Prof. Dr. IGP-ETH Zürich (Vorsitz)

Alain Buogo, dipl.Ing. KOGIS

Thomas Glatthard, dipl.Ing. SOGI, geosuisse

François Golay, Prof. Dr. LaSIG-ETH Lausanne

Francis Grin, dipl.Ing. EIVD Yverdon

Jens Ingensand, dipl.Ing. LaSIG-ETH Lausanne

Peter Jordan, Dr. SIA

Christian Just, dipl.Ing. swisstopo

Jürg Kaufmann, dipl.Ing. geosuisse

Andreas Morf, dipl.Ing. IGP-ETH Zürich

Stephan Nebiker, Prof. Dr. FHBB Abt. Vermessung und Geoinformation, Muttenz

Anton Stübi, dipl.Ing. BA Landwirtschaft Abt. Strukturverbesserung

Pierre-Alain Trachsel, dipl.Ing. KKVA

Inhaltsverzeichnis

1Interoperabilität in GIS: Anforderungen, Strategien, Lösungsansätze Prof. Dr. Alessandro Carosio, IGP-ETH Zürich

Nationale und internationale Standards

2 ÜberblickUrs Flückiger, SOGI Fachgruppe GISTechnologie

3 Informatik-Standards (UML, XML, SOAP)Prof. Dr. Christine Giger, IGP ETH Zürich

4Weltweite, europäische und schweizerische GeoNormen in WechselwirkungHans-Rudolf Gnägi, IGP-ETH Zürich, OSIG GT Normes

5 OpenGeospatial Consortium OGC (GML, WMS, WFS)Adrian Annen, FHBB

Stand der Technik, Implementierungen I

6OGC-Lösungen: Möglichkeiten und GrenzenDr. Andreas Donaubauer, TUM, Prof. Dr. Matthäus Schilcher, Anette Huber, TUM

7ISO-Standards für den Datentransfer: Stand der Realisierungen / Werkzeuge Claude Eisenhut, Eisenhut Informatik AG

Stand der Technik, Implementierungen II Realisierungen im Rahmen der GDI

8Interoperabilität von Geodaten: aktueller Stand und Zukunftsperspektiven im Kanton WaadtMarc Gilgen, DINF-VD

9Die Komplexität der Interoperabilität: ein einfacher Praxisbericht aus der OstschweizUeli Forrer, F+P Geoinfo AG

10Modellbasierte und interoperable Bearbeitung der Basisdaten in WallonienJean-Claude Jasselette, MET Belgien

Nächste Schritte in der Interoperabilität

11Modellstandardisierung vs. semantische Interoperabilität: aktuelles aus der Forschung Andreas Morf, IGP-ETH Zürich, Josef Dorfschmid, ADASYS AG

Semantische Interoperabilität – aktuelle Projekte

12 Datenmigration UICDr. Théophil Engel, SBB

13Integration der Daten der Landeskarte 1:25’000 (VECTOR25) ins Datenmodell der Amtlichen Vermessung (DM.01 AV CH)Robert Balanche, swisstopo

Organisatorische Folgen der Interoperabilität I

14Nationale Geodaten-Infrastruktur (NGDI): Organisatorische Aspekte der Interoperabilität beim BundRolf Buser, KOGIS

15Nationale Profile der internationalen Standards am Beispiel MetadatenRudolf Schneeberger, ITV Geomatik AG

16 Interoperabilität – nicht nur eine Frage der Technologie Willy Müller, Informatik Strategie Organ Bund

17 Interoperabilität auf strategischer und administrativer EbeneProf. Dr.François Golay, LaSIG-ETH Lausanne

Organisatorische Folgen der Interoperabilität II

18Interoperabilität in der Praxis: Erfahrungen aus Projekten im In- und AuslandDr. Ivo Leiss, Ernst Basler + Partner AG

19 Perspektiven für die Geomatik-BerufeChristian Kaul, Kaul Beratungen GmbH

20 Tarifierung, KostenfrageJürg Kaufmann, Kaufmann Consulting

Spezielle Aspekte der Interoperabilität in der Praxis

21Georeferenzierung, Interoperabilität zwischen Vermessungsdaten und darauf aufbauender Rauminformation, Datenhierarchie und Nachführung der abhängigen RauminformationDr. Horst Düster, AGI Solothurn

22Der Mobilitäts-Graph: ein geographisches Rahmenwerk für die Partner des Mobilitäts-Informationssystems der Region GenfPascal Oehrli, SIT Genf

1

Interoperabilität in GIS

Anforderungen, Strategien, Lösungsansätze

Alessandro Carosio, ETH Zürich

Alessandro Carosio, Prof. Dr. Eidg. Technische Hochschule Zürich Institut für Geodäsie und Photogrammetrie ETH Hönggerberg CH-8093 Zürich

Tel : Fax : E-Mail :

+41 1 633 30 52 +41 1 633 11 01

Interoperabilität für die breite Nutzung von Geodaten 1.1

1 Interoperabilität und Datentransfer: Eine zentrale Funktion jedes GIS

Das Entstehen und der erfolgreiche Einsatz von Geoinformationssystemen sind mit ei-ner wirksamen Lösung des Problems der Interoperabilität und des Transfers der Geoda-ten untrennbar gekoppelt. Nur kleine Applikationen, die die Verarbeitung von kleinen Datenmengen während kurzer Zeit erfordern (z.B. GIS-Übungen in der Ausbildung), können ohne eine Lösung des Datentransferproblems auskommen. Wir verfügen heute über eine immer grösser werdende Menge geographischer Daten in digitaler Form und einer grossen Anzahl Organisationen, die mit Daten dieser Art arbei-ten. Das Risiko, dass Doppelspurigkeiten und Widersprüche entstehen, ist gross. Oft existieren die benötigten Daten bereits. Sie werden aber wieder erfasst, weil:

eine geeignete Dokumentation fehlt oder sie eine inkompatible Struktur aufweisen.

Ein GIS ist nur erfolgreich, wenn es die Anforderungen möglichst vieler User erfüllt.

Abb. 1 : Die Kommunikation zwischen Geoinformationssystemen

Die Anforderungen und die Bedürfnisse sind allerdings sehr unterschiedlich. Dies ist der Grund, warum es bis jetzt relativ schwierig war, eine alles umfassende Standardlö-sung zu finden. Die wirtschaftlich entwickelten Länder realisieren zur Zeit geeignete nationale Geoda-teninfrastrukturen (NGDI), in welchen Private, Ämter, Lieferanten und Anwender in-tegriert werden, damit sie gemeinsam Technologien und existierende Daten nutzen können.Voraussetzung für die Realisierung von Koordinationszentren (Clearinghouses), für den Informationsaustausch und für die interoperable Nutzung der Geodaten ist die Lösung der in Abbildung 2 beschriebenen organisatorischen und technischen Problemen. Alle aufgezeigten Punkte sind sehr wichtig. Der vorliegende Beitrag befasst sich jedoch nur mit der technischen Thematik der Interoperabilität und der Datenübertragung zwi-schen Systemen unterschiedlicher Hersteller. Die erforderlichen Lösungsansätze für diese beiden Aufgaben sind besonders aktuell, da man zurzeit sowohl auf nationaler Ebene als auch in internationalen Institutionen (Europa, Welt) an der Entwicklung von technischen Normen arbeitet, die die Realisie-rung von interoperablen Systemen ermöglichen sollen.

Einführung in die Thematik Interoperabilität in GIS - Anforderungen, Strategien, Lösungsansätze

1.2 Interoperabilität für die breite Nutzung von Geodaten

Abb. 2 : Organisatorische und technische Voraussetzungen für eine NGDI

2 Bedürfnisse, Lösungsansätze

Abb. 3 : Datenaustausch und Interoperabilität

2.1 Die Vielfalt der Anforderungen Die Komplexität der Frage der Datenübertragung ist die direkte Folge der Vielfalt der Anwendungen.Ausgetauscht oder angefragt werden zum Beispiel:

Graphische Darstellungen (digitale Karten und Pläne) Beschreibungen der GIS-Inhalte (Metadaten) Resultate von Abfragen (Tabellen, Karten usw.) Strukturierte Datenbankinhalte (z.B. Tabellen, Attribute) ohne Änderung der Da-tenstrukturenDaten von einer Datenbank in eine andere Datenbank mit unterschiedlichen Da-tenstrukturenVollständige Objekte in einer objektorientierten Umgebung (inkl. Operationen)

Bereits diese kleine Auswahl von häufig auftretenden Datentransferwünschen gibt ei-nen Eindruck über die Vielfalt der Bedürfnisse mit ihren sehr unterschiedlichen Kom-plexitäten.

GIS GIS



2.2 Die Vielfalt der Lösungen Interoperable GIS können auf unterschiedliche Arten realisiert werden:

Datentransfero Datenaustausch zwischen gleichen Systemen o Datenaustausch mit Standardformaten o Modellbasierte Datentransfermethoden Interoperabilitäto Interoperabilität (nach OGC = Open Geospatial Consortium; früher Open

GIS Consortium)

3 Der eigentliche Datentransfer

3.1 Proprietäre Transferformate: ein Grundbedürfnis Das Inbetriebsetzen einer GIS-Applikation, die Verkaufsvorführungen, die erste Schu-lung von neuen Anwendern und die Tests des Herstellers während der Softwareent-wicklung erfordern die Übernahme von Demonstrationsdaten des gleichen GIS-Herstellers von einer Applikation zu einer anderen. So verfügen alle GIS über die Mög-lichkeit, die gespeicherten Daten in Standarddateien (in der Regel sequentielle Dateien) auszugeben und aus den gleichen Dateien wieder zu übernehmen. Die verwendeten Formate sind ausschliesslich geeignet für eine bestimmte GIS-Software (proprietäres Format) und erfordern beim Sender und beim Empfänger die identische Datenstruktur für die transferierten Daten.

Abb. 4 : Datentransfer mit proprietären Formaten

Andere proprietäre Formate, welche oft de facto Standard geworden sind, werden für die Ausgabe von graphischen Darstellungen (z.B. Plottfiles), die aus der raumbezogenen Information hergeleitet werden (Karten und Pläne), verwendet. Die GIS-Software bein-haltet normalerweise die Treiber für die erforderliche Steuerung und Generierung der Datenformate.

3.2 Standard-Formate Das Bedürfnis, Geoinformationen zwischen Systemen unterschiedlicher Hersteller aus-zutauschen war bereits in der Vergangenheit, besonders in grossen Organisationen (Te-lecom, Eisenbahngesellschaften, militärische Organisationen, usw.), stark spürbar. Bei solchen Anwendungen hat man mit Geoinformationssystemen zu tun, in welchen die zu verwaltenden Informationen für alle Systeme einheitlich festgelegt sind. Dies ist vor allem in stark hierarchischen Organisationen der Fall (NATO, Staatsbetriebe usw.).

GIS GIS



Wenn sowohl die geometrischen als auch die thematischen Inhalte feststehen, kann man ein passendes Format definieren, das die Information aufnehmen kann und es ist mög-lich in jedem System die entsprechende Schnittstelle für das Lesen und Schreiben der Transferdateien in das definierte Format einzubauen. So wurden zum Beispiel für die NATO das Austauschformat DIGEST (Digitial Geographic Information Exchange Stan-dard) und für den Ordnance Suvey (OS) in Grossbritannien das Format NTF (National Transfer Format) definiert.

Abb. 5 : Datentransfer mit Standard-Formaten

Ein weiteres Bedürfnis, das sehr verbreitet ist, ist die Abgabe von Geoinformationen an Partner, die sie nur graphisch auf ihren Computersystemen weiter verarbeiten werden. Auf diese Art verwenden oft Architekten und Bauingenieure die erhaltenen Geodaten. Sie werden in CAD-Systemen für die Projektierung eingesetzt. Der de facto Standard im CAD-Bereich ist zurzeit DXF, ein Format, in welchem die Information in thematische Ebenen (Layer) unterteilt wird. Die meisten GIS-Hersteller sehen vor, Daten in DXF auszugeben und auch zu lesen. Da-bei ist zu beachten, dass nur eine Teilmenge der Information (hauptsächlich die Gra-phik) in DXF abgebildet werden kann ( Informationsverlust). Sehr vorteilhaft sind bei dieser Form der Datenabgabe Vereinbarungen oder Normen, um die Layer-Zuordnung und Nummerierung einheitlich zu gestalten. Als das Projekt der Reform der Amtlichen Vermessung in der Schweiz realisiert wurde, stellte man mit Besorgnis fest, dass die Festlegung von einheitlichen Datenstrukturen für die Systeme der 26 Kantone unrealistisch war. Folglich war auch die Definition eines gemeinsamen Datentransferformats ein unmögliches Bestreben. Nicht anders geschah es ein paar Jahre später auf europäischer Ebene. Auf Anregung von Frankreich wurde das TC 287 der europäischen Normungsorganisation CEN ge-gründet, um unter anderem auch Normen für den Transfer geographischer Daten in Kraft zu setzen. Grossbritannien und Frankreich hatten sich vorgestellt, ihre Formate NTF und EDIGéO (Echange de Données Informatisées GéOgraphiques) für Europa zu erweitern (z.B. ETF). Die ersten Sitzungen zeigten aber, dass die Bedürfnisse und die Systeminhalte sehr unterschiedlich und vor allem die Anwendungen extrem vielfältig sind und daher die Festlegung von Standardformaten ein unmögliches Unterfangen ist. Man brauchte andere Lösungsansätze. Wenn unterschiedliche Datenstrukturen erwartet werden, sind modellbasierte Verfahren anstatt feste Formate der richtige Weg.

3.3 Modellbasierte Transferverfahren Geoinformationen der heutigen Zeit bieten den Anwendern neben einer festgelegten Datenstruktur für die geometrischen Daten die Möglichkeit, die thematischen Inhalte frei zu definieren. Das System bildet dann aufgrund der Datenstrukturbeschreibung

GISGIS



(Eingabe des DB-Schemas) die erforderlichen Entitätsklassen (in der Regel relationale DB-Tabellen). Somit passt sich die Datenverwaltung den Bedürfnissen an.

Abb. 6 : Modellbasierte Transferverfahren

Man kann diese Idee auch brauchen, um den Datentransfer flexibel zu gestalten: Die Struktur der Daten, die man übertragen möchte, wird beschrieben und daraus kann ein Format für diese Daten hergeleitet werden. Dafür benötigt man zwei Komponenten: ers-tens eine standardisierte Datenbeschreibungssprache, um die Struktur der Daten, die man transferieren möchte, eindeutig und konsistent zu beschreiben, und zweitens ein genormtes Verfahren, um aus der Datenstruktur ein Format herzuleiten.

Abb. 7 : Komponente des modellbasierten Transferverfahrens

In der europäischen Normung wurde EXPRESS als Sprache festgelegt, da sie bereits ei-ne gewisse Verbreitung hat (CAD, Automobilindustrie usw.). Applikationen im Geo-Bereich existieren allerdings noch nicht und ihre Komplexität ist für eine Implementie-rung nicht förderlich.In der Schweiz wurde für die Amtliche Vermessung vor mehr als 10 Jahren die Sprache INTERLIS definiert, welche die Beschreibung der Thematik in einem GIS nach einem relationalen Modell und der Geometrie aufgrund von festgelegten Geometrieelementen (Punkte, Geraden, Kreisbögen, Einzelflächen, Gebietseinteilungen) ermöglicht. Die Sprache passt sehr gut zu den heutigen GIS. Sie verfügte von Anfang an über einen Compiler für die automatische Herleitung der Transferformate und wird zunehmend eingesetzt. Zurzeit kann weltweit keine andere Lösung als operationell betrachtet wer-den. Im Technischen Komitee der ISO (TC 211) konnte nur INTERLIS als in GIS imple-mentierter modellbasierter Transfermechanismus für Geodaten vorgeführt werden. ISO hat bisher folgendes beschlossen:

Die modellbasierten Transferverfahren sind als Standard erklärt. UML wurde als graphischer Formalismus für die Beschreibung der Datenstruk-turen festgelegt.

Format-Herleitung

GIS



Eine textuelle Sprache, die automatisch gelesen und interpretiert werden kann, ist vorgesehen, ihre Eigenschaften wurden beschrieben und festgelegt. Kein Ent-scheid wurde getroffen. Mögliche Lösung INTERLIS 2.

Die Schweiz hat die neue INTERLIS Version (INTERLIS 2) entwickelt, um die volle Kompatibilität mit den ISO-Normen (Objektorientierung, Inkrementelle Nachführung, usw.) zu erfüllen. In diesem Rahmen wurde auch die Schnittstelle zwischen UML und INTERLIS realisiert, damit ein UML-Schema in INTERLIS automatisch übersetzt wer-den kann (und umgekehrt). Ebenfalls wurde das Transferformat im Informatik-Standard XML definiert. Demnächst wird man auch ein Transferformat auf der Basis von GML erzeugen können. Die modellbasierten Technologien bieten auch für andere Bereiche Lösungsansätze. Moderne GIS ermöglichen heute die Implementierung des Modells direkt aus dem kon-zeptionellen Schema (in UML oder in INTERLIS):

ArcGIS (ESRI) kann die Datenstruktur aus Schemata in UML (erzeugt mit Micro-soft Visio) implementieren GeosPro/GeoMedia (a/m/t, Intergraph) aus INTERLIS Topobase (C-Plan) aus INTERLIS oder aus UML

4 Interoperabilität Während die bisherigen Lösungen alle als Ziel haben, die Daten von einem System zu einem anderen zu transferieren, sind Kommunikationsmöglichkeiten denkbar, die ohne Verschiebung der Originalgeodaten auskommen. Diese Lösung ist besonders interes-sant, wenn nur einfache Auswertungen der Information benötigt werden (z.B. eine gra-phische Darstellung von einem Ausschnitt oder die Auflistung von bestimmten Objek-ten). In diesen Fällen ist es einfacher, die Auswertungsbefehle und -ergebnisse zu stan-dardisieren und zu transferieren als die Grunddaten selbst. Die Interoperabilität bedeutet die Parallelnutzung von verschiedenen GIS, indem die Befehle (Anfragen) und die daraus entstehenden Ergebnisse (Antworten) ausgetauscht werden (siehe Abb.8).Die GIS-Industrie (Softwarehersteller) hat diesen Weg als für den Markt interessant an-gesehen und das Open Geospatial Consortium (OGC) gegründet, um diese Technik möglichst weit zu entwickeln. Dank der Beteiligung der führenden weltweit tätigen Firmen (ESRI, Intergraph, Siemens, Oracle, Microsoft usw.) und der Einbindung von Universitäten und Forschungsinstitutionen hat OGC grosse Resonanz erhalten und ent-sprechend grosse Erwartungen geweckt.



Abb. 8 : Interoperabilität

Aus dem Konzept der Interoperabilität sieht man sofort die Vorteile: das Datenverwaltungskonzept kann in den kommunizierenden Systemen sehr unterschiedlich sein. Das abfragende System muss nichts über die Datenorganisation des angefragten Systems wissen. Die Systeme geben nur Teile der Information weiter. Der volle Inhalt bleibt unter der eigenen Kontrolle (Urheberrecht).

Ein Vorteil für die GIS-Hersteller: die Kunden können nicht so leicht das System wechseln

Ebenfalls sichtbar sind die Grenzen: die Vielfalt der standardisierten Abfragen und der Antwortformen darf nicht zu gross sein. Falls die gewünschten Interoperationen zu komplex, zu vielfältig und anzahlmässig zu gross werden, ist der Austausch der Daten einfacher und günstiger als die Standardisierung der Operationen. Selbstverständlich müssen die Systeme vergleichbare Informationen enthalten. Zurzeit hat OGC nur Lö-sungen vorgesehen für Abfragen, die in den Bezeichnungen angeglichen wurde (syntak-tische Interoperabilität). Zusammenfassend kann man sagen, dass die Interoperabilität interessant ist, wenn:

einfache Auswertungen der Geoinformationen benötigt werden (z.B. graphische Darstellungen, Listen von Objekten oder Attributen) die Systeme, die angefragt werden, gleichzeitig in Betrieb sind



5 Metadaten Die immer grössere Verbreitung der Geoinformationssysteme stellt uns vor neue Prob-leme: es fehlen oft Informationen über die verfügbaren Geoinformationssysteme und ihre Daten. Um diese wichtigen Informationen zugänglich zu machen, entstehen Meta-informationssysteme, welche Metadaten (Daten über die Daten) verwalten. Diese Sys-teme sind ihrerseits Geoinformationssysteme, in welchen ein Teil der Metainformatio-nen raumbezogen ist (wo und über welches Gebiet findet man Daten). Zu den Metada-ten gehören Informationen über die Qualität, die Verfügbarkeit, die Nutzungsbeschrän-kungen, die Kosten usw. Die Beschreibung der Datenstruktur in einer genormten Spra-che (EXPRESS, INTERLIS, UML usw.) kann ebenfalls dazu gehören. Ansätze für die Normung von Metadaten befinden sich im ISO-Normenwerk. In der Nationalen Geodaten-Infrastruktur (NGDI) wird man aus den internationalen Normen nationale Profile (Teilmengen) definieren, um eindeutige Interpretationen zu ermögli-chen.Zurzeit werden Metadaten zur visuellen Konsultation zur Verfügung gestellt. In Zu-kunft werden sie automatisch von interoperierenden Systemen bei der Datensuche ge-nutzt werden.

6 Die Wünsche und das Erreichbare

6.1 Wünschbares Die optimistischen Beschreibungen der unterschiedlichen Datentransfer-Konzepte könnten den Eindruck entstehen lassen, dass - mit etwas Geduld und finanziellen Mit-teln - das Problem des automatischen Austausches von Geoinformationen zwischen be-liebigen Systemen ohne weiteres lösbar sei.

Abb. 9 : Interoperabilität zwischen beliebigen Systemen mit beliebigen Datenstrukturen sind gewünscht.

Dies entspricht selbstverständlich dem, was man sich wünscht. Man möchte die wert-vollen Informationen, die an verschiedenen Orten erfasst und verwaltet werden, ge-meinsam nutzen.

6.2 Technische Grenzen Eine voll automatische Datenübertragung oder die gemeinsame Nutzung der Daten in beliebig konfigurierten Geoinformationssystemen ist nicht möglich. Die unüberwindba-re Grenze liegt in der nicht standardisierten Semantik der Datenstrukturbeschreibun-gen.

GIS GIS GIS



Die folgenden Beispiele illustrieren häufig vorkommende Fälle. Im Sendersystem wird eine thematische Klasse von Elementen mit dem Begriff „HÄU-SER“ identifiziert, während der Empfänger dasselbe mit „GEBÄUDEN“ bezeichnet. Selbstverständlich können Fremdsprachen und Abkürzungen weitere Hindernisse zu einer automatischen Interpretation bieten. Es kommt auch die umgekehrte Situation vor. Gleiche Begriffe bedeuten in den zwei kommunizierenden Systemen andere Objekte. In einem System bedeutet der Begriff „WEGE“ die Menge aller Verkehrsverbindungen (Strassen, Eisenbahnen, schiffbare Kanäle usw.), im anderen sind „WEGE“ kleine Stras-sen in einer Ortschaft (Schlossweg, Alpenweg usw.). Noch häufiger sind die Fälle da-zwischen, in welchen die thematischen Elemente andere Bezeichnungen und auch eine andere Unterteilung haben (Abb.10).

Abb. 10 : Im allgemeinen Fall kann die Zuordnung der einzelnen Attribute nicht automatisch stattfinden.

Die Semantik der Datenbeschreibung kann in einem freien Umfeld nicht standardisiert werden. Für die Zuordnung der Entitäten und der Attribute braucht man Zusatzinfor-mationen. Es ist zu beachten, dass die Zuordnung von der Bedeutung der Objekte und der Attribute abhängig ist. Sie ist daher auch von den Betriebsanweisungen und von den Regeln der Datenakquisition beeinflusst. Weder Mensch noch Computer werden in der Lage sein, ohne Zusatzauskünfte die Zuordnung der Entitäten und der Attribute vorzunehmen. Man wird sich zuerst erkundigen müssen oder ausführliche Beschrei-bungen lesen, um aufgrund der eigenen Interpretationen und Zielsetzungen die Daten-felder in Beziehung zu bringen. Diese Zuordnung muss das erste Mal aufgrund von:

Einer Analyse eines Experten Anfragen bei den Verantwortlichen Konsultationen von Metadaten erfolgen

Erst danach kann eine semantische Transformation automatisch ausgeführt werden. Für die modellbasierten Transferverfahren haben Software-Hersteller Module entwi-ckelt, die zwei Datenstrukturen (z.B. aus ihrer Beschreibung in INTERLIS) darstellen



und die Zuordnung der Entitätsklassen und Attribute auf Formatebene interaktiv am Bildschirm erlauben. Weitere Entwicklungen in dieser Richtung aber auf konzeptueller Ebene sind zu erwarten (semantische Transformationen, semantische Interoperabilität).

Abb. 11: Semantische Transformationen mit Hilfe von Ontologien

Zwischen föderierten Systemen (unter gemeinsamen Regeln organisiert) wird es in spe-zifischen Bereichen möglich sein, Ontologien zu entwickeln, welche die Semantik von mehreren Systemen beschreiben und die Herstellung von automatischen Transformati-onsmodulen (Agenten) ermöglichen werden. Die Ontologien sind Gegenstand der heutigen Forschung. Man wird allerdings nur die Semantik in klar definierten und abgegrenzten Sektoren eindeutig beschreiben können. Eine Ontologie entspricht einer Standardisierung der Begriffe, die man für die Modell-bildung und für die Bezeichnung der Elemente der Datenstruktur im GIS verwendet hat.

7 Entwicklungsstrategien Jeder der bisher geschilderten Lösungsansätze ist, trotz der erwähnten technischen Grenzen, eine optimale Antwort für einzelne Fälle mit ihren unterschiedlichen Anforde-rungen. Es ist daher nicht zu erwarten, dass sich ein einziger besonderer Lösungsansatz als Weltstandard für den Transfer von Geoinformationen durchsetzen wird:

Proprietäre Formate werden zu jeder GIS-Software gehören. Sie sind die optima-le Lösung für die Systemadministration. Sie übertragen die Daten eines be-stimmten Systems vollständig (inkl. Konfigurationsparameter). Sie können auch für den internen Datenaustausch in grossen Organisationen dienen, die mehrere identische Systeme betreiben. Standardformate sind einzusetzen, wenn die Inhalte der GIS zentral festgelegt werden. Zur beschlossenen Datenstruktur kann ein Format definiert werden, mit welchem die Daten sequentiell übertragen werden können. Standardformate sind ebenfalls die geeignete Lösung für die Abgabe von GIS-Daten an CAD-Systeme. DXF ist im CAD-Bereich am meisten verbreitet. Wünschenswert ist da-bei die Normung der Layer.

OOnnttoollooggiiee

AAggeenntt AAggeenntt



Modellbasierte Transferverfahren sind die Lösung für den Datenaustausch zwischen Systemen, die eine eigene Datenstruktur besitzen. Die ankommenden Daten beinhalten die Datenstrukturbeschreibung in einem genormten Formalis-mus (Datenbeschreibungssprache). Zur Sprache gehört auch das Verfahren, um daraus die Formate herzuleiten. Wenn die Strukturen der erhaltenen Daten und der Daten des Empfänger-Systems nicht identisch sind, kann eine voll automati-sche Übernahme nicht stattfinden. Die Zuordnung der Entitätsklassen und der Attribute muss das erste Mal aufgrund menschlicher Interpretation geschehen. Um diese interaktive Arbeit zu erleichtern, haben Software-Hersteller Module entwickelt, die zwei Datenstrukturen vergleichen und am Bildschirm die Zuord-nung der Tabellenfelder erlauben (z.B. INTERLIS-Studio von Leica).

Abb. 12 : Bei der ersten Datenübertragung muss die Beziehung zwischen den Attributen definiert sein.

Interoperabilität ist die Alternative, mit welcher die Kommunikation zwischen den GIS ohne Austausch der Geodaten stattfinden kann. Genormt werden die Anfragen und die Formate für die Übermittlung der Antworten (Services Inter-faces). Der tatsächliche Umfang der Möglichkeiten, die im Rahmen der OGC-Arbeiten entstehen werden, ist schwer vorherzusagen. Zurzeit sind einfache An-fragen (Visualisierungen, Selektionen) und der Zugriff auf einfache geographi-sche Objekte spezifiziert. Sicher werden einfache Anfragen (Visualisierungen, Selektionen) zur Verfügung stehen. Ebenfalls spezifiziert ist bereits der Zugriff zu einer einfachen Koordina-tengeometrie. Da in den Absichten des Open Geospatial Consortium (OGC) nicht nur die Kommunikation zwischen den Systemen im Vordergrund steht, sondern auch das Zusammensetzen von ganzen GIS aus selbstständigen Kom-ponenten, werden die Schnittstellen zwischen den frei gewählten Software-Modulen ebenfalls benötigt. Die erforderliche Zeit und die Erreichbarkeit der Ziele sind nicht leicht vorsehbar.



8 Schlussfolgerung Die Kommunikation zwischen Geoinformationssystemen ist eine vielseitige Aufgabe, für welche eine Vielfalt von Lösungsansätzen zur Verfügung steht. Die Probleme, die Anforderungen und die technischen Grenzen sind erst in neuster Zeit in ihrer ganzen Breite wahrgenommen worden. Die heute eingesetzten Datentransferverfahren und die Interoperabilität werden sich in den nächsten Jahren stark entwickeln. Mehrere Metho-den werden sich als Standard durchsetzen. Die nächsten Schritte der Forschung sind im Bereich der semantischen Interoperabilität und der semantischen Transformationen zu erwarten.Diese Arbeiten sind die Voraussetzung, damit Geoinformationssysteme ihre wertvollen Daten ohne Verzögerung und Hindernisse der ganzen Gesellschaft zur Verfügung stel-len können.

2

Überblick

Urs Flückiger, SOGI Fachgruppe GIS Technologie

Urs Flückiger ESRI Geoinformatik AG Beckenhofstr. 72 CH-8006 Zürich


+41 1 360 24 60 +41 1 360 24 70


Dieser Beitrag soll dem Interessenten einen Überblick zum Thema nationale und inter-nationale Standards im Gesamtkontext zu „Interoperabilität für die breite Nutzung von Geodaten“ geben. Im Gegensatz zu den nachfolgenden Beiträgen kann dieser Einstieg ins Thema nicht in die Details gehen. An der Tagung behandelte Themen finden sich als Beispiele wieder. Was ist Interoperabilität? – Interoperabilität ist, wenn ein System mit anderen Systemen unterschiedlichen Ursprungs innerhalb vordefinierter Grenzen zusammenarbeiten kann und darf. Durch Spezifikationen und Normen entsteht Interoperabilität. Interoperabili-tät findet auf verschiedenen technologischen Ebenen statt. Leisten Normen einen Beitrag zur Interoperabilität? – Normen erleichtern das Leben in einer vernetzten Welt. In den wenigsten Fällen werden Daten nur für einen kurzfristi-gen Moment erfasst und nur in einem System gehalten. Deshalb ist die Schaffung und Durchsetzung von Normen eine bedeutende Aufgabe. Normen erleichtern die Vernet-zung und bauen technologische Hindernisse zur Zusammenarbeit ab. Gibt es einen Markt für Normen? – Verschiedene Gruppierungen befassen sich damit. Der Nutzen ist unterschiedlich. Alle Beteiligten profitieren jedoch in irgendeiner Weise.

1 Normung

1.1 Definition von Normung Normung heisst die planmässige, durch interessierte Kreise durchgeführte Vereinheitli-chung von materiellen und immateriellen Gegenständen zum Nutzen der Allgemeinheit (DIN). Das Ergebnis von Normung ist eine technische Vorschrift, die man Norm nennt (englisch: standard). Eine „de jure Norm“ (oder kurz Norm) ist eine solche technische Vorschrift, die von nationalen oder internationalen Normenverbänden festgelegt wird. Eine „de facto Norm“ ist eine allgemein anerkannte und mehrheitlich genutzte techni-sche Vorschrift, die sich aus der weiten Verbreitung eines Produktes ergibt, durch die ausschliessliche Nutzung innerhalb eines Unternehmens (so genannter Industrie-Standard) oder durch nationale oder internationale Interessengemeinschaften oder Kon-sortien festgelegt wird. Sowohl Normen als auch de facto Normen sind nur dann ver-bindlich und müssen durch natürliche und juristische Personen angewendet werden, wenn durch gesetzliche oder vertragliche Regelungen deren Einhaltung gefordert wird.

Typ Norm (Gremium) De facto Norm (Gremium) Betriebssysteme Unix, Linux (ANSI) Windows 2000 (Microsoft) Datenbanken SQL-92 (ISO)

Datenformat XML (W3C), ITF (SNV) DXF (AutoCAD), Shapefile (ESRI)

Programmiersprachen C++ (ANSI) Java (Sun), Visual Basic (Micro-soft)

Internet-Dienste HTTP (ISO), SOAP, UDDI J2EE (SUN Microsystems), WSDL (W3C)

GI-Standards ISO 19115 Metadaten (ISO) WMS (OGC) Verbandsspezifisch SIA-Norm 405 (SIA)

Tab. 1 : Beispiele von Normen und de facto Normen

Normen, insbesondere für die Dokumentation (Metadaten), die Modellierung (einheitli-che Beschreibungssprache) sowie den Datenaustausch (Bezugsmechanismus und Daten-format) erhöhen die Flexibilität, die Funktionalität und die Produktivität eines Informa-tionssystems.

Nationale und internationale Standards Überblick


1.2 Normierungsorganisationen

1.2.1 De jure Normierungsorganisationen

Internationale Organisation für Standardisierung (ISO) ISO ist die Internationale Organisation für Standardisierung für Business, Behörden und Gesellschaft. Die Mitglieder-Organisationen können die Normen übernehmen. Beispiele für ISO-Normen:

ISO 19103 Geographic Information – Conceptual Schema Language ISO 19115 Geographic Information – Metadata ISO 19119 Geographic Information – Services ISO 19136 Geographic Information – Geography Markup Language ISO 19139 Geographic Information – Metadata – Implementation Specification

TC211 ist das technische Komitee Nr. 211 der ISO, das sich mit Geografischen Informa-tionen und Geomatik beschäftigt. Dieses Komitee bearbeitet die Normenserie ISO 19100, welche verschiedenste Geodaten-Standards (Metadata, Spatial Schema, Spatial Referen-ce, Application Schema, Conceptual Schema Language, Quality, Encoding, Catalog ...) beinhaltet.Die ISO TC211 und das Open Geospatial Consortium (OGC) arbeiten zusammen und unterstützen sich gegenseitig. Eine Spezifikation bei OGC entspricht einer Ebene der 19100-er Normenserie bei ISO. Die mit dem Abkommen verfolgten Ziele sind:

OGC-konforme Produkte werden (fast) konform mit dem Standard aus ISO TC211.Verbesserung der Standards bei OGC und ISO TC211. Schnellere Entwicklung und Austesten von Spezifikationen in Testumgebung und Pilotprojekten.Beachtung von Marktkonditionen.

Europäisches Komitee für Standardisierung (CEN) CEN ist das Europäische Komitee für Standardisierung. CEN wird voraussichtlich be-schliessen die Normenserie ISO 19100 weitgehend zu übernehmen. Die Mitglieder von CEN haben sich verpflichtet die CEN-Normen zu ratifizieren.

Schweizerische Normenvereinigung (SNV) Die SNV ist Mitglied von CEN und daher verpflichtet, die CEN-Normen und somit die ISO-Normen zu übernehmen, falls diese zu CEN-Normen werden. Dies bedeutet, dass allfällige Schweizer Normen, welche im Widerspruch mit CEN bzw. ISO-Normen ste-hen, voraussichtlich eliminiert werden müssten. Da die Schweizer Geonormen auf Grund von praktischen Bedürfnissen entwickelt, implementiert und getestet wurden, ist die Schweiz daran interessiert, dass auch die allfällig zu übernehmenden internationa-len Normen im GI-Bereich den praktischen Bedürfnissen entsprechen und durch Imp-lementierung auf ihre Brauchbarkeit geprüft werden. Dafür setzen sich die Schweizer Vertreter in den entsprechenden Gremien mit zunehmendem Erfolg ein.



Andererseits bemüht man sich in der Schweiz ebenfalls erfolgreich, die existierenden und bewährten Normen den aktuellen Entwicklungen in der Informationstechnologie und im GI-Normenbereich schrittweise anzupassen. Beispiele für SNV-Normen:

SN 612 030 und SN 612 031: INTERLIS Modellierungssprache und Datentransfer-methodeSN 612 040: Gebäudeadressen SN 612 050: GM03 - Metadatenmodell

1.2.2 De facto Normierungsorganisationen

Open Geospatial Consortium (OGC) Führende GIS-Hersteller, Datenproduzenten, Behörden, Organisationen und For-schungseinrichtungen haben sich 1994 im Open Geospatial Consortium (OGC) zusam-mengeschlossen. Ziel des Zusammenschlusses ist die Definition von hersteller-übergreifenden, "offenen" Programmschnittstellen, die Standardisierung von GIS-Techniken sowie die Förderung der GIS-Technologie. Die angestrebten de facto Normen sollen erreichen, dass die Dienste von Anbietern einem grossen Kreis von Nutzern auf einfache Weise zugänglich gemacht werden können. Angestrebt werden ein breiter Ein-satz interoperabler Software-Komponenten von der Stange (Components of the shelf), die vollständige Integration der Geodatenverarbeitung mit der normalen Informations-technologie und der Schritt von Geodaten zu Geoinformationsdiensten. Die OGC-Spezifikationen sind meist pragmatische Ansätze, welche die Funktionstüchtigkeit als Hauptziel haben. Beispiele für OGC Spezifikationen sind:

„OpenGIS Simple Feature Specification (SF, approved)“ „OpenGIS Geography Markup Language (GML, approved)“ „OpenGIS Web Map Server Specification (WMS, approved)“ „OpenGIS Web Feature Server Specification (WFS, approved)“ Service Discovery Service Description

W3CDas World Wide Web Consortium wurde gegründet, um alle Möglichkeiten des Webs zu erschließen. Dazu werden einheitliche Technologien (Spezifikationen, Richtlinien, Software und Tools) entwickelt, die den Fortschritt des Webs fördern und seine Intero-perabilität sicherstellen. Hauptprodukte des W3C sind neue Empfehlungen, die als de facto Standards für Pro-tokolle und Anwendungen von den Mitgliedern begutachtet und gebilligt werden müs-sen. Ziel dabei ist es, einen möglichst breiten Konsens zu finden, was dadurch erreicht wird, dass jede Spezifikation ein bestimmtes Verfahren zu durchlaufen hat (sog. Re-commendation Process). Ziel des W3C ist es, das WWW zu seiner vollen Entfaltung zu führen: Als ein funktio-nierendes Computer zu Computer System, als ein wirkungsvolles Mensch zu Computer Interface und als ein effizientes Mensch zu Mensch Kommunikationsmedium. Um die-



ses Ziel zu erreichen, arbeitet das W3C-Expertenteam zusammen mit seinen Mitgliedern in den folgenden fünf Bereichen:

Architecture Domain (DOM, Jigsaw, XML, XML Protocol, URI) Document Formats Domain (HTML, Style Sheets, Math, Grafik, Internationalisie-rung, Amaya) Interaction Domain (Device Independence, synchronisierte Multimediaanwen-dungen, Voice Browser) Technology and Society Domain (Digitale Signaturen, Metadaten, elektronisches Geld, Datenschutz und Datensicherheit) Web Accessibility Initiative

2 Interoperabilität Durch normierte Schnittstellen und Formate wird die systemunabhängige Kommunika-tion zwischen verschiedenen Informationssystemen ermöglicht, was als Interoperabilität bezeichnet wird. Interoperabilität erlaubt den einfachen Zugang zu verschiedenen (auch raumbezogenen) Daten- und Verarbeitungsressourcen innerhalb eines Arbeitsablaufs bzw. die einfache Verknüpfung unterschiedlicher Systeme. Durch dieses einfache Zu-sammenspiel von Systemen und Daten wird es möglich, viele verschiedene Daten an einem Ort zu nutzen und diese Information gegebenenfalls auch zu veröffentlichen. Durch Spezifikationen und Normen entsteht Interoperabilität. Interoperabilität ist die Grundlage von IT-Infrastrukturen, d.h. von verteilten Systemen für eine Gesamt-Unternehmungslösung.Interoperabilität findet auf verschiedenen Ebenen statt.

Schicht Charakteristik Begriffe

Präsentation Unterstützung von thin clients und fat clients J2ME

ServicesInteroperation und Offenheit: Einsatz von Internet-, IT- und GIS- Standards

HTTP, XML, SOAP, J2EE, UDDI; OGC: WMS, WFS

Applikationslogik Integration und IT-Konformität (API)

.net, COM, Java SOAP, GML/XML, C++, VB

Daten, Formate Austausch und Investitions-schutz

DXF, DGN, SHP, OGC SF, INTER-LIS, GML, DBMS OS, PNG, JPG

Plattform Plattformunabhängigkeit

Unix (SUN, IBM, HP), DOS, Win-dows, Mac, Linux; DBMS (Oracle, SQL, DB2, Informix); WebServer (IIS, Websphere, Apache)

3 Marktbetrachtung Generell erleichtern Normen das Leben in einer vernetzen Welt. In den wenigsten Fällen werden Daten nur für einen kurzfristigen Moment erfasst und nur in einem System gehalten. Die Schaffung von Normen ist eine bedeutende Aufgabe. Wer befasst sich mit Normung?Ein Marktangebot soll sich an der Nachfrage orientieren. Denn nur diejenigen Normen werden sich durchsetzen, welche einen klaren Nutzen für den Anwender haben. Wem bringt Normung etwas?



Die Antworten auf diese beiden Fragen sind nicht abschliessend: Verschiedene Organisationen bzw. Gremien befassen sich mit Normung. Die einschlä-gigen Normierungsorganisationen wie ISO, CEN und SNV aber auch OGC wurden be-reits erwähnt. Neben den technischen Kommissionen (z.B. TC211 oder TK151) befassen sich auch weitere Gremien und Verbände (z.B. eCH, sia) mit Normung. Gerade Verbän-de sind gefordert, entstehende Normen für ihre Mitglieder auf ihre Praxistauglichkeit zu prüfen. EUROGI (European Umbrella Organisation for Geographic Information) will den Gebrauch von geographischen Informationen zugunsten der Bürger, der Regierungen und des Handels in Europa maximieren und die Sichtweise der Geographischen-Informationen-Gemeinschaft darstellen. Dies wird erreicht durch Förderung, Anregung und Unterstützung der Entwicklung und des Gebrauchs geographischer Informationen und Technologien.Das Schweizer Kontaktnetz e-geo.ch wurde initiiert, um den Aufbau einer NGDI zu fördern wie auch die Partnerschaften zwischen der öffentlichen Hand, Organisationen und der Privatwirtschaft zu verbessern. Beide Initiativen benötigt für die Umsetzung die Interoperabilität. Für das Erreichen der Ziele sind praktikable und sinnvolle Normen von Vorteil. Hersteller sind angehalten, die vom Markt geforderten Normen zu implementieren. Davon profitiert der Kunde wie der Hersteller, weil weitere Aufgaben bewältigt und neue Marktsegmente erschlossen werden können. Datenproduzenten wollen ihre Daten einem möglichst grossen Publikum zugänglich machen. Die Bereitstellung in einem genormten Datenformat verringert den Aufwand erheblich. Die Daten müssen nicht in verschiedenen proprietären Formaten von GIS-Systemlieferanten aufbereitet werden. Verschiedene Studien belegen, dass gut zugängli-che Geobasisdaten für Privatwirtschaft wie für Verwaltung hohen volkswirtschaftlichen Nutzen haben (vgl. NGDI des Bundes). Der Anwender wird sich nicht im Detail damit befassen. Er wird sich informieren, da-mit er als Auftraggeber notwendige Standards fordern bzw. als Auftragnehmer gefor-derte Standards umsetzen kann. Schliesslich sollen Investitionen nachhaltig sein. Die Schaffung und Durchsetzung von Normen ist eine bedeutende Aufgabe. Normen erleichtern die Vernetzung und bauen technologische Hindernisse zur Zusammenarbeit ab. Die SOGI FG GIS-Technologie hat den Nutzen der Ergebnisse der Arbeit von OGC, ISO und SN für den GIS-Anwender in der Schweiz untersucht:

Beschreibung OGC ISO SNProduktivitätssteigerung von Unternehmen und Behörden durch die Nutzung genormter Programmschnittstellen. X - e

Produktivitätssteigerung von Unternehmen und Behörden durch die Nutzung genormter Austauschformate und Mechanismen. e e X

Nutzen durch Software spezifischer Technologien ab der Stange. X - X Investitionsschutz (durch Plattformunabhängigkeit). ? e X CH ist nicht mehr eine Normeninsel. X X X Bessere Kontrolle der Daten. - e X Klar definierte Richtlinien für Ausschreibungen durch die zwingende Vorgabe des abzugebenden Datenformates, und damit Chancengleich-heit für alle Anbieter.

- - X

Im Bereich länderübergreifender Projekte, kommen proprietäre nationa-le Normen (d.h. ohne Bezug zu internationalen Normen) nicht zum Ein- e e e



satz. Dort ebnen internationale Normen den Weg für einen geregelten Datenbezug bzw. Datenaustausch. Normung wird auf einer systemneutralen Daten- und Modellierungs-ebene geführt. ? X X

Alle Beteiligten sprechen die gleiche „Sprache“. - ? X

Legende: X Nutzen realisiert, e Nutzen zu erwarten/versprochen, ? Nutzen unklar, - kein Nutzen

In einem Bericht der swisstopo wurde versucht, die konkreten Einsparungen beim sinn-vollen Einsatz von Schweizer Normen zu schätzen (Bericht 17, www.swisstopo.ch). Es wird dort von einem Potential von einigen Millionen Schweizer Franken pro Jahr ge-rechnet. Ein anderer Bericht spricht von 3% Einsparung durch genormte Arbeitsabläufe und Werkzeuge (www.cgey.com/gcicase); dieser Prozentsatz dürfte im GIS-Bereich noch wesentlich höher liegen. Ebenso wichtig wie die Einsparungen ist jedoch der Zu-satznutzen, der durch genormte Geoinformationsverarbeitung erzielt wird. Im Gegensatz zu üblichen Märkten ist Wettbewerb weniger gefragt. Organisationen sol-len in jenen Bereichen, in denen sie sich thematisch überschneiden, zusammenarbeiten und ihre Normen angleichen. Dies passiert bereits. OGC-Standards wie WFS oder WMS werden von ISO als Norm übernommen oder in entsprechenden Normen angepasst. Dasselbe geschieht auch umgekehrt, indem z.B. OGC ISO-Normen als Standards über-nimmt. Auch andere Organisationen wie FGDC arbeiten enger mit ISO und OGC zu-sammen. Dies bringt den Organisationen weniger Arbeit und mehr Durchsetzungskraft. Für Entwickler, Hersteller und Anwender wird es einfacher.

4 Literaturangaben SOGI FG GIS-Technologie (2003): Worin liegt der praktische Nutzen von Interope-rabilität und Normung für den GIS-Anwender in der Schweiz? SOGI FG GIS-Technologie (2005): Geo-Webdienst

URLCEN, European Committee for Standardisation (www.cenorm.be) INTERLIS (www.interlis.ch) ISO (www.iso.org) ISO TC/211 (www.isotc211.org) KOGIS (www.kogis.ch, www.e-geo.ch) OGC (www.opengis.org) Online Glossar (www.integis.ch) Schweizerischen Normen Vereinigung SNV (www.snv.ch) SOGI (www.sogi.ch) TC211 – OGC coordination group (www.opengis.org/iso)

3

Informatik-Standards

Für die Interoperabilität von GIS relevante Standards

Christine Giger, ETH Zürich

Christine Giger, Prof. Dr. Eidg. Technische Hochschule Zürich Institut für Geodäsie und Photogrammetrie ETH Hönggerberg CH-8093 Zürich


+41 1 633 30 51 +41 1 633 11 01


1 Einleitung Die Entwicklung vernetzter, interoperabler Systeme betrifft aus Sicht der Informationstechnologien vier Aufgaben:

1. Festlegung der Architekturen und technischen Standards 2. Prozessmodellierung3. Datenmodellierung 4. Entwicklung von Basiskomponenten

Alle vier Aufgaben sind im hohen Masse voneinander abhängig und müssen aufeinander abgestimmt werden. In anderen Beiträgen dieser Tagung werden die verschiedenen Schritte unter verschiedenen Aspekten beleuchtet. Hier soll vor allem auf die erste Aufgabe eingegangen werden und dargestellt, welche allgemeinen, informationstechnischen Standards existieren, die als Grundlage für die in anderen Beiträgen behandelten Geoinformations- und Geomatik-Standards dienen. Dabei wird mit dem Begriff „Standard“ im folgenden Text sowohl ein de facto-Standard (z.B. Hersteller- oder Domänen-spezifische aber weit verbreitete Schnittstellen) als auch ein de jure-Standard (entspricht einer von einem offiziellen Gremium definierten Norm) bezeichnet. Die Anzahl und Breite der informationstechnischen Standards ist sehr gross und kann im Rahmen dieses Beitrags nicht umfassend und vollständig beschrieben werden. Um eine sinnvolle Eingrenzung des Themas vornehmen zu können, gehen wir zunächst von einer in Fachkreisen allgemein anerkannten Architektur für Geodateninfrastrukturen aus.

Bild 1: Middleware-Architektur für Geodateninfrastrukturen gemäss INSPIRE [1]

Nationale und internationale Standards Informatik-Standards: für die Interoperabilität von GIS relevante Standards


Die in Bild 1 gezeigte 3-Schichten Architektur wurde so vom Expertengremium der EU-Initiative INSPIRE (Infrastructure for Spatial Information in Europe) [1] verabschiedet und basiert unter anderem auf den für den Geoinformationsbereich so bedeutsamen Gremien:

ISO/TC 211 – Geoinformation - Geomatics [5] Open Geospatial Consortium (OGC) [8]

Auf der untersten Ebene befinden sich Daten- und Metadatenquellen. Dort ist darauf zu achten, dass Daten und Metadaten maschinell gelesen, interpretiert und verarbeitet werden können. Schnittstellen zu Clients aber vor allem zu zugreifenden Diensten (darunter die wichtigen Katalog- und Suchdienste) müssen exakt spezifiziert und eingehalten werden. Nur so sind die vorhandenen Geodaten breit nutzbar. In der mittleren Schicht müssen Basis- und Mehrwertdienste angeboten werden. Diese müssen unabhängig von bestimmten Datenquellen funktionieren und austauschbar sowie miteinander koppelbar sein. D.h. es müssen letztlich Schnittstellen zu Datenquellen wie auch zu Clients und anderen Diensten (Middleware-Komponenten) spezifiziert und eingehalten werden. In der obersten Schicht befinden sich die Endnutzer-Anwendungen, zu denen auch Portale zählen. Weitere Beispiele sind einfache Web-Browser, spezialisierte Dienste (z.B. Routenplanung, Immobilienbewertung) aber auch traditionelle GIS. Hier sind ebenfalls vor allem die Schnittstellen zu den Diensten und Datenquellen aber auch zu Suchdiensten relevant. Fasst man nun die Software-Architektur in Bild 1 als zu erreichendes Ziel auf, bleibt zu überlegen, wie die einzelnen dort aufgeführten Komponenten über standardisierte Schnittstellen miteinander kommunizieren können. Idealerweise sollten zu diesem Zweck Standards gewählt werden, die

leicht implementierbar sind, die Freiheit bei der Implementierung der Komponenten möglichst nicht oder nur schwach einschränken die Kommunikation zwischen den Komponenten sicherstellen, den Ersatz einzelner Komponenten durch andere/neue ermöglichen, die Erweiterbarkeit des Gesamtsystems ermöglichen, kompatibel zu allgemeinen IT-Standards sind.

Im Bild 2 sind die korrespondierenden Standards der Reihe ISO 19100 des ISO/TC 211 und die Standards des OGC an den entsprechenden Schnittstellen oder für die entsprechenden Komponenten dargestellt.



Bild 2: Middleware-Architektur mit ISO/TC 211 und OGC Standards

Auf die Beschreibung der Standards, die in diesen beiden Gremien entwickelt werden, wird in diesem Beitrag explizit verzichtet, da andere Beiträge sich diesen Themen widmen.Aus Sicht der Informatik sollte man die folgenden Normungsgremien betrachten, die auch einen Grossteil der Basis für ISO/TC 211 und OGC liefern:

Object Management Group (OMG) [6] World Wide Web Consortium (W3C) [10] International Organization for Standardization (ISO) [4] International Electrotechnical Commision (IEC) [3]

Es existieren natürlich noch weitere Gremien, deren Beschreibung jedoch den Rahmen dieses Beitrags sprengen würde. Aus Platz-und Zeitgründen aber auch aus Gründen der unmittelbaren Relevanz behandeltdieser Beitrag vor allem die GIS-relevanten Standards von OMG und W3C Um diese in ihrer Funktion und in Relation zu anderen Standards einordnen zu können, illustriert das folgende Bild 3 die Aufgaben der einzelnen Standards im Zusammenhang mit den funktionalen Anforderungen der Interoperabilität.



Bild 3: Standards und ihre Aufgaben für die Realisierung von interoperablen Systemen

Die Nennung der in der Spalte „Interoperabilitäts-Standards“ angegebenen Standards erhebt keinerlei Anspruch auf Vollständigkeit. Im Rahmen dieses Beitrags wird auch nur auf einen geringen Teil der dort genannten Standards eingegangen.

2 Object Management Group (OMG) Die Object Management Group (OMG) wurde 1989 von 11 Firmen gegründet, darunter 3Com, American Airlines, Canon, Data General, HP, Philips, SUN und Unisys. Das Industrie-Konsortium zählt heute mehr als 800 Mitglieder. Es standardisiert offene, verteilte, objekt-orientierte Systeme auf Middleware-Basis. Unter den zahlreichen von der OMG entwickelten Standards haben die folgenden die grösste Bedeutung für interoperable GIS:

Common Object Request Broker Architecture (CORBA) Model Driven Architecture (MDA) Unified Modeling Language (UML)

Die Standards werden in den folgenden Kapiteln etwas näher erklärt.

2.1 Common Object Request Broker Architecture (CORBA) CORBA basiert auf dem ISO/IEC 10746 Standard for Open Distributed Processing, einer allgemeinen Architektur offener, verteilter komponentenbasierter Systeme. Das OGC beruft sich mit seinen Entwicklungen ebenfalls auf dieses ISO/IEC Standard und auf die Entwicklungen der OMG. Eine 1. Version von CORBA wurde 1991 veröffentlicht. Seit 2000 ist CORBA ebenfalls als Standard der ISO (ISO/IEC 19500-2) erhältlich. CORBA definiert die Komponenten und Rollen der Komponenten von Middleware-Architekturen.



2.2 Model Driven Architecture (MDA) Die MDA vereinheitlicht als modellbasierte Software-Architektur die Modellierungs- und Middleware-Bereiche der OMG. Sie unterstützt Anwendungen über ihren gesamten Lebenszyklus von Analyse und Entwurf über Implementierung und Entwicklung bis hin zur Pflege und der Erweiterung von Softwaresystemen. Die MDA basiert auf UML Modellen. Die Beschreibungssprache UML wird im nächsten Kapitel noch etwas näher beschrieben. Das folgende Bild 4 illustriert die Funktion der MDA aus Sicht der OMG.

Bild 4: Funktionen der Model Driven Architecture

Die MDA integriert Anwendungen innerhalb eines Unternehmens und über das Unternehmen hinaus mit Anwendungen anderer Unternehmen. Sie wurde von den OMG-Mitgliedern als Basis für alle OMG-Spezifikationen im September 2001 verabschiedet. Weitere Infos finden sich unter [7].

2.3 Unified Modeling Language (UML) UML standardisiert die Repräsentation von objekt-orientierter Analyse und Entwurf. Es handelt sich bei UML um eine graphische Sprache mit einem Dutzend Diagrammtypen (Anwendungs- und Aktivitätsdiagramme zur Anforderungserfassung, Klassen- und Objektdiagramme für den Systementwurf, Paket und Subsystemdiagramme für die Entwicklung, usw.). Software-Architekten und -Analysten können Anwendungen standardisiert visualisieren, spezifizieren, konstruieren und dokumentieren. Die OMG entwickelte UML also vor allem zum Entwurf von komplexen, verteilten Softwaresystemen.Im GIS-Bereich wird zur Zeit allerdings nur ein sehr kleiner Aspekt von UML genutzt: die Möglichkeit, mit UML Datenmodelle zu beschreiben. UML ist allerdings sehr verbreitet für die Nutzung und wird beispielsweise auch für die Spezifikation der ISO 19100 [5] Normenreihe intensiv gebraucht. Weitere Informationen zu UML, Beispiele sowie UML-Kurse finden sich unter [9].



3 World Wide Web Consortium (W3C) Das World Wide Web wurde 1989 von Tim Berners-Lee während seiner Tätigkeit am CERN in Genf erfunden. Berners-Lee und andere gründeten im Oktober 1994 das World Wide Web Consortium (W3C) als Industriekonsortium. Berners-Lee ist seit dem Direktor des W3C. Viele Informationen inklusive einer vollständigen Liste aller Standards finden sich unter [10]. Kurse zu den meisten Standards finden sich unter [11]. Ziel des W3C ist es, Industrie-weiten Konsens über Web-Technologien herbei zu führen. Das W3C hat die Aufgabe, das Wide World Web zur Nutzung seiner vollen Kapazität zu führen, indem die gemeinsamen Protokolle entwickelt werden, die seine Weiterentwicklung fördern und seine Interoperabilität gewährleisten. Eine der Aufgaben des W3C ist es, einen Beitrag zur Standardisierung der Web-Technologien zu leisten, indem “Recommendations” genannte Spezifikationen, welche die Grundlagen des Web beschreiben, produziert werden. Die Ziele des W3C können in den sieben folgenden Punkten zusammengefasst werden: Universal Access, Semantic Web, Trust, Interoperability, Evolvability, Decentralization und Cooler Multimedia.Um diese Ziele zu erreichen, wurden verschiedene Arbeitsgruppen gegründet, welche in fünf Bereiche aufgeteilt werden können: Architecture Domain: Sie entwickelt die Web-Technologien. Innerhalb dieser Domäne befinden sich Arbeitsgruppen zum Thema XML (XML Core Working Group, XML Linking Working Group, XML Query Working Group und XML Schema Working Group), WebServices (XML Protocol Working Group und WebServices Descriptor Working Group), Uniform Resource Identifiers, DOM und Jigsaw. Document Formats Domain: arbeitet an den Formaten und Sprachen für die Informationsdarstellung. Zum Beispiel an der Hypertext Markup Language (HTML), Style Sheets, Math, Graphics (z.B. Formate PNG, SVG, usw.), Interaction Domain: beschäftigt sich mit der Unterstützung des Benutzers in der Interaktion mit dem Web. Die Aktivitätsbereiche sind: Device Independence, Multimodal Interaction, Synchronized Multimedia (SMIL) und Voice Browser. Technology and Society Domain: berücksichtigt gesetzliche und sozialpolitische Aspekte in der Web-Entwicklung. Die Aktivitätsbereiche sind: Semantic Web (z. B. Resource Description Framework, RDF oder Web Ontology Language, OWL), Platform for Privacy Preferences (P3P), XML Signature (xmldsig), XML Encryption, XML Key Management, Patent Policy and Standards. Web Accessibility Initiative (WAI): führt die Arbeiten zur Förderung des Web-Zugriffs anhand von fünf Arbeitsbereichen fort: technology, guidelines, tools, education and outreach, und research and development.Das folgende Bild 5 illustriert die Funktionen der W3C Standards im Hinblick auf die Funktionen und die Weiterentwicklung des World Wide Web.



Bild 5: W3C-Standards und die Weiterentwicklung des World Wide Web [10]

Für die GI-Normung sind dabei vor allem die folgenden Standards wichtig: Uniform Resource Locators (URL), Uniform Resource Identifiers (URI), HyperText Transfer Protocol (HTTP), HyperText Markup Language (HTML)

o Diese sind dem Leser (hoffentlich) bekannt und werden im folgenden nicht mehr näher erklärt

Extensible Markup Language (XML) und XML Schema Scalable Vector Graphics (SVG) Resource Description Framework (RDF) Web Ontology Language (OWL) Simple Object Access Protocol (SOAP) Web Services Description Language (WSDL)

3.1 Extensible Markup Language (XML) Bei XML handelt es sich um ein Textformat, das als Derivat der Dokumentenbeschreibungssprache Standard Generalized Markup Language SGML (ISO 8879) entstand. XML nutzt zur Zeichenkodierung den ASCII-Standard. Es ist beschreibt sequentiell die Struktur von Dokumenten (z.B. Titel, 1. Kapitel, Absatz, Absatz, 2. Kapitel, usw.). XML war ursprünglich nur für die breite elektronische Publikation von Dokumenten gedacht. Heute wird es zunehmend für den Austausch beliebiger Daten in der Informatik und eben auch zum Austausch von Geodaten verwendet. Beispiel:

<note><to>Tove</to><from>Jani</from><heading>Reminder</heading><body>Don't forget me this weekend!</body> </note>



XML und XML-Derivate sind sehr gut für die Beschreibung von Daten geeignet, die automatisch von Rechnern weiterberabeitet werden sollen. Das Lesen von XML-Dateien durch Menschen ist natürlich möglich, aber extrem mühsam, da Menschen gewöhnlich eher objekt-orientiert als sequentiell denken, sofern es sich bei den Daten nicht um Dokumente handelt. XML und XML-Derivate zur Modellierung beliebiger Daten (nicht Dokumente) zu verwenden ist prinzipiell möglich aber ebenfalls unsinnig. UML zum Beispiel liegt viel näher an menschlichen Denkweisen.

3.2 XML Schema XML Schema beschreibt so genannte shared vocabularies und bietet damit Methoden zur Definition der Strukturen, Inhalte und Semantik von XML-Dokumenten. XML Schema erlaubt die Definition von Klassen von XML-Dokumenten. Eine deutsche Beschreibung zu XML-Schema findet sich z.B. unter [1]. XML Schema ist auch die Basis für den OGC Standard GML [8].

3.3 Scalable Vector Graphics (SVG) SVG beschreibt 2D Graphiken. Es besteht aus 2 Teilen: XML-basiertes Dateiformat und Programmierschnittstele für graphische Anwendungen. Es enthält z.B. verschiedene Formen, Text, und Rastergraphik. SVG unterstützt Scripts und Animationen. Es nutzt JPEG und PNG als Bildformate. SVG wird für interaktive Anwendungen im Web, auf mobilen Systemen, etc. benutzt. Es handelt sich um einen systemunabhängigen, offenen Standard. Die Autoren kommen von: Adobe, Agfa, Apple, Canon, Corel, Ericsson, HP, IBM, Kodak, Macromedia, Microsoft, Nokia, Sharp und Sun Microsystems. SVG viewers gibt es für alle gängigen Web-Browser

3.4 Resource Description Framework (RDF) RDF bietet einen Rahmen zur Beschreibung und zum Austausch von Metadaten, die Informationen im Internet betreffen, gemäss den folgenden Regeln:

1. Eine Resource ist irgendetwas, dass einen URI haben kann; dies beinhaltet alle WWW-Seiten aber auch individuelle Teile eines XML-Dokuments.

2. Ein PropertyType ist eine Resource, die einen Namen hat und als Property genutzt werden kann, z.B. Autor oder Titel. In vielen Fällen kümmern wir uns dabei nur um den Namen; aber ein PropertyType muss eine Resource sein, damit er eigenen Properties (Eigenschaften) haben kann.

3. Eine Property ist die Kombination einer Resource, eines PropertyType und eines Werts.Beispiel:"The Author of http://www.textuality.com/RDF/Why.html is Tim Bray.“ Der Wert kann nur ein String sein, z.B. "Tim Bray" oder eine andere Resource, z.B. "The Home-Page of http://www.textuality.com/RDF/Why.html is http://www.textuality.com“

4. Diese Eigenschaften können direkt im XML beschrieben werden



3.5 Web Ontology Language (OWL) OWL basiert auf RDF und bietet zusätzlich mehr Vokabular für die Beschreibung von Eigenschaften und Klassen an, z.B.:

untereinander Relationen zwischen Klassen KardinalitätenGleichheitCharakteristika von Eigenschaften (z.B. Symmetrien) Enumerationen

RDF nutzt Description Logics zur Modellierung von Daten (z.B. Geoobjekten) und deren Eigenschaften. Bild 6 zeigt ein Beispiel für deskriptive Logik.

Bild 6: Deskriptive Logik

OWL ist (ähnlich wie zum Beispiel INTERLIS) auch eine konzeptionelle Beschreibungssprache.

3.6 Simple Object Access Protocol (SOAP) Um Anwedungsprogramme auf einem Rechner zu koppeln, würde man typischerweise auf die Nutzung so genannter Remote Procedure Calls (RPC) zurückgreifen. Bei der Kopplung von Anwendungen, die jedoch auf verschiedenen Rechnern laufen, die durch das Internet verbunden sind, ist dies nicht möglich. Firewalls würden RPCs sofort zurückweisen. Daher wurde SOAP entwickelt. SOAP ist ein Kommunikationsprotokoll, das die Kommunikation zwischen Applikationen, die auf verschiedenen Betriebssystemen mit verschiedenen Technologien und Programmiersprachen laufen, erlaubt. Es ist ein Format zum Senden von Nachrichten und wurde speziell für die Kommunikation via Internet entworfen. Es ist Plattform-unabhängig und basiert auf XML. Es ist einfach und erweiterbar und erlaubt die Umgehung von Firewalls.

3.7 Web Services Description Language (WSDL) WSDL ist ein spezielles XML-Format zur Beschreibung von Netzwerkdiensten als Menge von Endpunkten, die auf Nachrichten operieren, die entweder Dokument-orientierte oder Prozedur-orientierte Informationen enthalten. Operationen und Nachrichten werden abstrakt beschrieben und dann an ein konkretes Netzprotokoll und Nachrichtenformat gebunden, um einen Endpunkt zu definieren. In Beziehung



stehende konkrete Endpunkte werden zu abstrakten Endpunkten (Diensten) kombiniert. WSDL ist unabhängig von Nachrichtenformaten und Protokollen. Üblich sind aber zur Zeit die Verwendung von SOAP 1.1, HTTP GET/POST, und MIME (Multipurpose Internet Mail Extensions) für WSDL. Insbesondere für Geodateninfrastrukturen, in denen man gerne Dienste suchen und finden und dann auch miteinander verketten möchte, gewinnt WSDL eine zunehmende Bedeutung.

4 Abschlussbemerkungen Die vorgestellte Liste der Informatik-Standards ist keineswegs vollständig und skizziert auch nur gewisse Aspekte der Standards und deren Bedeutung für die Nutzung von Geoinformationen. Alle Standards sind in „Bewegung“, d.h. sie sind zum Teil noch nicht als Standards verabschiedet und werden noch bearbeitet. GI-Standards, die auf diesen Informatik-Standards beruhen, sind allenfalls auch von diesem Aspekt der Instabilität betroffen. Dies gilt insbesondere auch für den OGC-Standard GML. Modellbasierte Ansätze beherrschen die Informatik-Standards für verteilte interoperable Systeme. Die schlägt sich allerdings auch in den Ansätzen von ISO/TC 211, CEN/TC 287, der EU-Initiative INSPIRE aber auch in der nationalen Normung einzelner Länder, darunter auch Deutschland (AAA Modell) und die Schweiz (INTERLIS!) nieder. Das Semantic Web hat grosse Zukunft und wird stark vorangetrieben (z.B. mit RDF und OWL).

Referenzen[1] http://www.edition-w3c.de/TR/2001/REC-xmlschema-0-20010502/ [2] http://inspire.jrc.it/home.html[3] http://www.iec.org/[4] http://www.iso.org/[5] http://www.isotc211.org/ [6] http://www.omg.org/[7] http://www.omg.org/mda/[8] http://www.opengeospatial.org/ [9] http://www.uml.org/[10] http://www.w3.org/ [11] http://www.w3schools.com/

4

Weltweite, europäische und schweizerische GeoNormen in

Wechselwirkung

Hans Rudolf Gnägi, ETH Zürich

Hans Rudolf Gnägi Eidg. Technische Hochschule Zürich Institut für Geodäsie und Photogrammetrie ETH Hönggerberg CH-8093 Zürich


+41 1 633 30 60 +41 1 633 11 01


1 Einleitung Wer an Normen denkt, dem fallen spontan Stichworte ein wie „Schraubengewinde“, „DIN A4“ und „Spurweite der Eisenbahn“. Dabei geht es um stabile Dinge des tägli-chen Lebens, die schon mehr oder weniger lang existieren und sich bewährt haben und wo es nur noch darum geht, einige Details einheitlich festzulegen, um einer noch unein-geschränkteren Verwendung dieser Dinge letzte Hindernisse aus dem Weg zu räumen. Ganz anders ist die Situation im Geoinformationsbereich. Da ist sozusagen nichts stabil, Technisch jagen sich die inkompatiblen Versionen von Geoinformationssystemen und Geodiensten in einem atemraubenden Tempo, die Geodaten werden immer umfangrei-cher, waren schon immer und bleiben teuer in der Herstellung, die Vielfalt von Aus-tauschformaten nimmt babylonische Ausmasse an. Und trotzdem sollten in dieser hoffnungslos dynamischen Situation mittels Normen stabile Pflöcke eingeschlagen werden. Schon immer war da der Bedarf, Geodaten auszu-tauschen über lokale, regionale und nationale Grenzen, auch über Systemgrenzen. Nati-onale, regionale und globale Geodateninfrastrukturen rufen heute nach vielseitiger Nutzung einmal erhobener Geodaten. Aber was und wie soll normiert werden? Wo sind die Schraubengewinde im Geobereich? Zur Dynamik der Technik gesellen sich zudem handfeste Interessenkonflikte. Während beispielsweise die Geodatennutzer an mög-lichst frei und vollständig austauschbaren sowie offen beschriebenen Geodaten interes-siert sind, möchte ein GIS-Hersteller tendenziell eher seine Kunden an sein System bin-den durch möglichst hohe Hürden, die Daten wohldokumentiert und vollständig in ein Mitbewerber-System transferieren zu können. Im Folgenden soll kurz gezeigt werden, ob und wie erfolgreich das weltweite (ISO/ TC211), das europäische (CEN/TC287) und das nationale Normengremium (SNV/INB TK 151) den mehrdimensionalen Spagat zwischen Technikdynamik und Anforde-rungswidersprüchen meistern.

2 Normen, was ist das? Qualitätskriterien, Entstehung, Beeinflussung

DIN normt auch den Begriff „Normung” und zwar mit folgender Definition: Normung ist planmässige, durch die interessierten Kreise durchgeführte Vereinheitlichung von materiellen und immateriellen Gegenständen zum Nutzen der Allgemeinheit (DIN 820 Teil 3). Eine „Norm” ist das Resultat solcher Normungstätigkeit. Das Interesse am „Nutzen für die Allgemeinheit“ von „Vereinheitlichungen“ im Geobe-reich meldete sich in der Schweiz, wie in den meisten Ländern, zunächst auf nationaler Ebene an. Bedeutung und Wert der umfangreichen Geodatensammlungen führten zu einer ersten Schweizer Norm „Sicherheit und Schutz von Geodaten“ (SN612010). Um den Datenaustausch zwischen amtlicher Vermessung einerseits und Architektur und Bau andererseits zu entwirren wurde die Norm „Datenreferenzmodell DXF Geobau“ (SN612020) erarbeitet. Die modellbasierte Methode, in Stürmen praktischer Anwendung gereift, wurde als Norm „INTERLIS Datenbeschreibungssprache und Transfermethode“ (SN612030) fixiert Es folgten „INTERLIS 2“ (SN612031), „Gebäudeadressen“ (SN612040), „Metadaten“ (SN612050), diese sind aber bereits beeinflusst von der welt-weiten Geo-Normung, wo seit 1994 die wesentlichen Entwicklungen stattfinden.

Nationale und internationale StandardsWeltweite, europäische und schweizerische Geonormen in Wechselwirkung


Die Erfahrungen mit der Entwicklung von Schweizer Normen zeigten, dass eine Norm nur dann „zum Nutzen der Allgemeinheit“ dient, wenn sie den folgenden Qualitätskri-terien genügt. E Exakte knappe Formulierung mit präzisen klar definierten Begriffen aber auch

mit anschaulichen Erläuterungen. M Minimum, das nötig ist wurde festzulegen: „Vollständig“ ist eine Norm, wenn

sie alles enthält, was nötig ist für ein Vereinheitlichung, nicht alles, was existiert. P Praxiserprobung war erfolgreich B Breit abgestützte Einflussnahme auf die Erarbeitung „Planmässig“ bedeutet im Geobereich, dass organisatorisch primär auf weltweiter Ebe-ne normiert wird (ISO/TC211), diese Normen in Europa nach Prüfung von Bedarf und Eignung als Euronormen (EN) anerkannt werden (von CEN/TC287), und dass diese Euronormen von den Mitgliedländern schliesslich ins nationale Normenwerk über-nommen werden müssen (in der Schweiz durch die Schweizerisch Normenvereinigung SNV). „Planmässig“ verläuft auch der Lebenszyklus einer Norm: Dieser startet damit, dass eine Mitgliednation oder ein Liaison-Mitglied die Idee für eine neue Norm als „New work item proposal“ (NWIP) formuliert. Wird dieses vom TC angenommen, beginnt ein Projektteam (PT) „Committee Drafts“ (CD) auszuarbeiten, die von den Mit-gliedernationen beurteilt werden können. Änderungswünsche werden durch „Editing Committee Meetings“ (ECM) eingearbeitet. Ist ein CD stabil, dann kommt er zur Ab-stimmung als „Draft International Standard“ (DIS) und schliesslich als „International Standard“ (IS). Analog entstehen bei ISO „Technical Reports“ (TR): Vom NWIP über den „Provisional Draft Technical Report“ (PDTR) zum DTR und zum TR. Soweit das Prozedere zur Schaffung von sogenannten „de jure“ Normen über die offi-ziellen Normengremien. Daneben haben sich im Geo-Bereich wie in der Informations-technologie allgemein auch „de facto“ Normen durchgesetzt durch weitverbreiteten Gebrauch. Man denke etwa an das „Drawing eXchange File“ (DXF) zum Austausch von Vektorgrafik. Mit dem „Open Geospatial Consortium“ (OGC) hat sich ein Gremium konstituiert, mit dem Ziel, Interoperabilität von GIS zu realisieren, d.h. Funktionalität und Daten von GIS wechselseitig nutzbar zu machen, insbesondere, wenn nicht um-fangreicher Datenaustausch gefordert ist. OGC umfasst als strategisch entscheidende „principle members“ vor allem die grossen GIS-Hersteller. Viele an GIS interessierte Administrationen, Universitäten und kleinere Firmen können zu bescheideneren Jah-resbeiträgen und mit weniger Entscheidungsbefugnis ihre Ideen einbringen. Der grosse Vorteil der de facto Normen von OGC gegenüber den de jure Normen von ISO ist, dass meist erst auf Grund von Implementierungen für eine Idee der Normungsprozess ge-startet wird, dass also das oben erwähnte Qualitätskriterium 3 der Praxiserprobung au-tomatisch erfüllt ist. Entsprechend dem Ziel Interoperabilität liegt das Hauptinteresse der OGC-Normungsarbeit im Bereich Internet basierte Dienste. Einzigartig und ausserordentlich positiv für die Normung im Geo-Bereich ist, dass ein Zusammenarbeitsvertrag zustande kam zwischen OGC und ISO/TC211. Er ist zwar in-sofern einseitig, als damit nur OGC Normenvorschläge in den ISO-Prozess einbringen kann und nicht auch umgekehrt ISO/TC 211 bei OGC die Implementierung und damit praktische Überprüfung von durch ISO entwickelten Normen beantragen kann. Aber schon, dass OGC-Realisierungen auch den ISO-Prozess durchlaufen und so mit breiten kritischen Stellungnahmen und Verbesserungsideen konfrontiert werden, die mittels

Nationale und internationale Standards Weltweite, europäische und schweizerische Geonormen in Wechselwirkung


ECMs berücksichtigt werden, hat wesentliche Qualitätsverbesserungen zur Folge (Qua-litätskriterium 4!). Noch ein Blick auf die Normungsexperten von ISO/TC211: Deren Zusammensetzung ist nach wie vor von unglaublicher Heterogenität. Viele kennen GIS nur von ferne, theo-retisch, viele sind fixiert auf das eine GIS, mit dem sie gelegentlich oder täglich arbeiten, Das Verständnis für die Bedeutung systemunabhängiger Lösungen und für die modell-basierte Methode ist zwar zunehmend aber immer noch sehr nahe bei Null.

3 Geo-Normen, Übersicht Gesamtübersicht und Stand der ISO Normenserie 19100 gibt Tabelle 1. Von den 47 ins-gesamt gestarteten Projektteams wurden 3 wieder gestrichen und die übrigen produ-zierten bis zum 16.2.2005 insgesamt 18 IS und TR, 11 DIS und DTR, 9 CD und PDTR und 6 NWIP sind noch nicht bis zum CD vorgedrungen. Die ganze Normenserie basiert auf der modellbasierten Methode. Das heisst, es wird grundsätzlich auf system-unabhängiger konzeptioneller Ebene normiert. Die konzepti-onellen Schemata (Datenmodelle) der normierten Datenstrukturen bzw. Strukturele-mente müssen für die Implementierung in GIS oder Datenbanken auf das logische Schema (Datenmodell) dieser Zielsysteme umgebaut werden, um von dort, meist auto-matisch, auf den physischen Level des Betriebssystems bzw. des Rechners übersetzt zu werden. Für den Datentransfer kann aus einem konzeptionellen Schema automatisch direkt die Beschreibung des Transferformats, also das physische oder Transferschema, hergeleitet werden. Als konzeptionelle Beschreibungssprache verwendet ISO19100 die Umified Modelling Language (UML). Als Transferformat wurde der XML-Dialekt GML gewählt, als physi-sche Beschreibungssprache des Transferschemas zunächst XML-DTD und jetzt XML-Schema. Viele Leser aber auch Hersteller der Normen haben grosse Schwierigkeit, diese verschiedenen Beschreibungsstufen auseinander zu halten. Es besteht ein wesentlicher Unterschied zwischen der Beschreibung der Datenstruktur auf konzeptioneller Ebene (bei ISO 19100 durch UML) und der Beschreibung des Transferformats (bei ISO 19100 durch XML-Schema). Wer ein physisches Transferschema als konzeptionelles Datenmo-dell betrachtet und bezeichnet bereitet sich selber vor allem unnötige Schwierigkeiten und stiftet in der Geowelt unnötig Verwirrung. Die Normen der Serie ISO 19100 können gegliedert werden in die beiden Hauptbereiche Grundlagen und Anwendungen. Bei den Grundlagen zeichnen sich vier Teilbereiche ab: Basis – Integrierbarkeit/Transferierbarkeit – Interoperabilität. Bei den Anwendungen kann zur Zeit unterschieden werden zwischen Qualität/Metadaten – Pixelbil-der/Gitterdaten – LBS – Adressen – Bewegte Objekte. Details zu den beiden Hauptbe-reichen sowie der Versuch eines Zustandsvergleichs ISO-CEN-SNV für den Grundla-genbereich folgen im nächsten Abschnitt. Tabelle 1 enthält in der dritten Kolonne eine grobe Beurteilung aller Normen. Dabei fällt sehr unangenehm auf die grosse Zahl von Normen mit der Bemerkung „No“. Wegen der sehr beschränkten personellen und finanziellen Kapazität der Schweiz im Geo-Normenbereich konnten alle diese Dokumente überhaupt nicht bewertet werden



NrISO

Stand

Be-ur-tei-

lung

Titel Dokument Nr Sei-tenISO

CH Norm SN6120xx-yxx Nr.Teil y Kap,Annex

Sei-tenCH

6709 ? Std, representation of lat., long., alti. for pt. loc. N1733 31-2.9.4 1 19101 ? GI – Reference Model N1197, ISO19101 48 31-1 13 19101-2 GI – Reference Model – Part 2: Imagery N1455,N1489 19102 GI – Overview 19103 ? TR GI – Conceptual Schema Language N1527 71 31-2 50 19104 ? GI – Terminology Spread sheets N1485, DIS 19104 19 31-L 22 19105 No GI – Conformance and Testing (2000) ISO 19105 26 19106 No Gi – Profiles N1483, (2004) ISO 19106 38 19107 ! GI – Spatial Schema (siehe 19137) (2003) ISO 19107 184 31-2.8.11/12 10 19108 ? GI – Temporal Schema FDIS N1225, ISO 19108 55 31-H 4 19109 ? GI – Rules for Application Schema N1538, DIS 19109 83 Mod.Meth.G 19110 ? GI – Feature Cataloguing Methodology N1567 (2005) IS 60 Mod.Meth.G 19111 ! GI – Spatial Referencing by Coordinates (2003) IS 44 31-J 13 19112 ! GI – Spatial Referencing by Geo Identifiers (2003) IS 30 40 19113 No GI – Quality Principles (2002) ISO 19113 38 19114 No GI – Quality Evaluation Procedures (2003) ISO 19114 79 19115 ? GI – Metadata (2003) ISO 19115 150 50 19115-2 | No GI – Metadata 2; Extensions for IGD N1396, N1425 19116 No GI – Positioning Services N1547 (2004) ISO 19116 59 19117 ? GI – Portrayal N1578 (2002) DIS 19117 47 31-2.16, -K 13 19118 ? GI – Encoding N1580 (2002) DIS 19118 117 31-3 15 19119 No GI – Services N1540 (2002) DIS 19119 74 Checker,... 19120 No TR GI – Functional standards (2001) ISO TR 19120 19120 A No TR GI – Functional standards amendmt 1 19121 No TR GI – Imagery and gridded data IGD (2000) ISO TR 19122 ? TR GI – Qualif. and certif. of pers N1491 (2004) ISO TR 12 19123 No GI – Schema for coverage geom. & funct N1740 FDIS 63 19124 | No TR GI – Imagery and gridded data components N1017 39 19125-1 ! GI – Simple feat. acc - P1 Comn arch N1563 (2004) IS 48 31-2.8.11/12 s.o. 19125-2 ! GI – Simple feat. acc - P2 SQL option N1565 (2004) IS 72 31-2.8.11/12 s.o. 19125-3 ! GI – Simple feature access – P3: COM/OLE opt. N997 124 31-2.8.11/12 s.o. 19126 No GI – Profile – FACC data dictionary N1561 19127 ? TR GI – Geodetic codes and parameters N1751 FDTR 39 31-J s.o. 19128 No GI – Web map server interface N1675, DIS 19129 | No TR GI – Imagery, gridded & coverage data frwk. N1252 107 19130 No GI – Sensor and data models for IGD N1772 76 19131 ? GI – Data product specification N1688 Mod.Meth.G 19132 | No GI – Location based serv.- reference model N1599 19133 No GI – Location based serv tracking and navig. N1762,DIS 19134 No GI – Multimodal LBS for routing and navigation N1768 19135 No GI – Procedures for registration of GI-items N1605 DIS 20 19136 ? GI – GML N1576 19137 GI – Core profile of spatial schema N1670 DIS 19137 19138 GI – Data quality measures N1744, PDTS 19139 ?,! GI – Metadata – XML schema implem. N1663, PDTS 19140 | GI – Technical amendment of ISO19100 series N1346 19141 | No GI – Schema for moving features N1757

Tab. 1 : Stand der Geo-Normen-Serie 19100 von ISO/TC 211 (2005-02-16)

Nationale und internationale Standards Weltweite, europäische und schweizerische Geonormen in Wechselwirkung


Legende zu Tabelle 1: Stand der Geo-Normen-Serie 19100 von ISO/TC 211 (2005-02-16) Legende Stand der Normen Legende Beurteilung Sicht CH

= IS International Standard (or TR Technical Report) = zweckmässiges Konzept

= DIS Draft International Standard (or DTR Draft Technical Report) ? = Unklarheiten, Probleme

= CD Committee Draft (or PDTR Provisional Draft Technical Report) ! = Widerspruch zu anderen Normen

| = NWI New Work Item beschlossen = Folgearbeiten notwendig

= aufgehoben No = keine Beurteilung Sicht CH

Mod.Meth.G = Modellierungs Methode, INTERLIS Grundkurs

4 Für Integrierbarkeit und Interoperabilität wesentliche Normen

Für Integrierbarkeit und Interoperabilität wesentlich sind ohne Ausnahme alle Normen des Grundlagenbereichs. Tabelle 2 bringt eine vergleichende Übersicht dieser Grundla-gennormen in thematischer Ordnung gemäss den oben beschriebenen Teilbereichen. Für die ISO/CEN-Normen einerseits und für die entsprechenden SNV-Normen ande-rerseits kommen die in Abschnitt 2 eingeführten Qualitätskriterien zur Anwendung.

Nr ISO CEN Name ISO CEN E

N E M P B Nr SNV Name CH Norm E M P B

Basis .

19103 Conceptual schema lan-guage s s u s 612031 INTERLIS 2, Kapitel 2

Beschreibungssprache G s G G

19104 Terminology principles G s G G 612031 INTERLIS 2, Anhang L Glossar G G G G

19107191231912519137

Spatial schema Schema for coverage.. Simple features Minimal profile spa sch

s

sG

u

GG

u

Gs

u

sG

612031

INTERLIS 2, Abschnitt 2.8.7 Koordinaten, 2.8.11 Linienzüge, 2.8.12 Flächen, Gebiete

G G G G

1911119127

Referencing by coord Geodetic codes and par

ss

ss

sG

GG 612031 INTERLIS 2, Anhang J

Koordinaten(ref)system G G u G

19108 Temporal schema s u u s 612031 INTERLIS 2 Anhang H Zeit-Definitionen G s u G

1910919110

Rules for applic schema Feature cataloguing met

ss

uu

us

sG 612031 INTERLIS 2, Kapitel 1,

Grundprinzipien, UsHB G G G G

19106 Profiles 612031 INTERLIS 2, Abschnitt 2.4 Vererbung G G s G

19119 Services 612031 INTERLIS 2, Abschnitt 1.8 Dienste, Werkzeuge G u u G

Integrierbarkeit/Transferierbarkeit . 1911819136

Encoding GML

us

uu

us

GG 612031 INTERLIS 2, Kapitel 3

sequentieller Transfer G G G G

19117 Portrayal u u u s 612031 INTERLIS 2, Abschnitt 2.16 Darstellungsbeschr s s s G

Interoperabilität . 19128 WMS NWIP WFS

Tab. 2 : Stand der Geo-Normen-Serie 19100 von ISO/TC 211 (2005-02-16)

Legende: Kolonne EN: = existiert als Euronorm, = existiert noch nicht als Euronorm. Bewertungskolonnen E = Exakte knappe Formulierung. M = Minimum festgelegt,

P = Praxiserprobung war erfolgreich, B = Breit abgestützte Erarbeitung. Bewertung: G = gut, s = genügend (sufficient), u = ungenügend, = nicht bewertet

Dass sich unter den Schweizer Normen bei INTERLIS 2 alle Themen der Basisnormen und der Normen zur Integrierbarkeit/Transferierbarkeit von ISO vorfinden beruht auf



der Wechselwirkung, die zwischen diesen beiden Normengremien stattfand. INTERLIS 1 wurde auch auf Grund der Anforderungen von ISO/TC211 an die für die Normenserie ISO 19100 auszuwählende konzeptionelle Beschreibungssprache entsprechend weiterentwickelt zu INTERLIS 2. Hauptforderung des Projektteams 3 von ISO/TC211 war volle Objektorientierung. Auch war XML als Transferformat verlangt. Die Wahl von ISO/TC211 erfolgte dann für die grafische Sprache UML. Als textuelle CSL sind alle diejenigen zugelassen, deren Sprachelemente sich eindeutig auf die in ISO 19103 festgelegten Sprachelemente von UML abbilden lassen. Das ist für INTERLIS 2 der Fall.

5 Nächste Schritte Die verschiedenen Lücken in Tabelle 2 zeigen deutlich den Verbesserungsbedarf vieler bereits verabschiedeter ISO-Normen. Dafür hat ISO/TC211 mit dem Projekt 41 den Amendment Prozess gestartet. Über diese Schiene sind begründete Verbesserungsanträge einzureichen. Gewisse Normen sind eigentlich eher technische Reports über den aktuellen Stand der Dinge. So etwa das ‚Spatial schema’ ISO 19107 und das ‚Temporal schema’ ISO 19108. Beide haben deshalb in der Kolonne M „Minimum festgelegt“ ein u für „ungenügend“. Damit zu diesen Themen eine minimale aber echte Integrierbarkeit / Interoperabilität unterstützt wird, muss für beide Normen eine konsistente Teilmenge als sogenanntes Profil definiert werden. Ein erster Schritt in dieser Richtung wurde bereits gemacht mit dem minimalen Profil des ‚Spatial schema’ durch ISO 19137. Eine Dauerfrage ist immer: Genügt eine graphische CSL auf konzeptioneller Ebene? Es ist klar, dass etwa im Bereich der Datentypen eine Präzisierung nötig ist, um Transfer-formate (und andere Dienste) eindeutig generieren zu können. Diese Präzisierung sollte nicht versteckt werden in XSLT-Skripts, sondern offengelegt werden mit einer normier-ten textueller konzeptionellen OO Beschreibungssprache. Die Lücke bei den Schweizer Normen im Bereich Web-Services bedeutet nicht, dass es keine INTERLIS basierten Web-Dienste gibt. Im Gegenteil. Es sind verschiedene grosse Geo-Portale in Betrieb mit Hilfe von INTERLIS. Hingegen soll darüber hinaus versucht werden, durch eine Kombination der modellbasierten Methode mit den OGC Web-Services eine „best of“ Lösung des Typs Model Driven Web Feature Server (MDWFS) zu bauen.

6 Zusammenfassung Klar ist: Die modellbasierte Methode ist Basis der weltweiten und der europäischen Geo-Normung.Transferformate sollten eigentlich verschieden gewählt werden können entsprechend verschiedenen Bedürfnissen und Ansprüchen (Binär / ASCII / tagged). Der modellba-sierte Ansatz, aus einem system- und formatunabhängigem Datenmodell automatisch verschiedene Formate herzuleiten gemäss definierten Regeln (und in Zukunft auch ver-schiedene Protokolle), ist auch in dieser Beziehung sehr viel versprechend. Bleibt zum Schluss noch die Frage, ob die Geo-Normung den mehrdimensionalen Spa-gat zwischen Technikdynamik und Anforderungswidersprüchen erfolgreich meistert. Wir müssen die Beantwortung der Zukunft überlassen. Aber mindestens ist mit dem Entscheid für die modellbasierte Methode eine sehr tragfähige Voraussetzung für einen Erfolg geschaffen.

5

Open Geospatial Consortium OGC

GML, WMS und WFS

Adrian Annen, Fachhochschule beider Basel (FHBB), Abt. Vermessung und Geoinformation

Adrian Annen Fachhochschule beider Basel Abteilung Vermessung und Geoinformation Gründenstrasse 40 CH-4132 Muttenz


+41 61 467 44 68 +41 61 467 44 60


1 Kurzfassung Mit dem Open Geospatial Consortium (OGC) existiert ein internationales Industrie-konsortium mit dem Ziel, die Interoperabilität von Geodaten zu verbessern. Die Ab-kürzungen GML, WMS und WFS, welche im Zusammenhang mit dem OGC oft ver-wendet werden, sind Bezeichnungen für offene, systemunabhängige Mechanismen zum Austausch von Geodaten. Bei der Geography Markup Language (GML) handelt es sich um eine XML-basierte Applikation für die Modellierung und den Austausch von Daten mit Raumbezug. GML wird unter anderem für verschiedene Webdienste verwendet. Als Beispiel kann der Web Feature Service (WFS) genannt werden, wel-cher für den Austausch und die Manipulation von Daten über das Web verwendet wird. Demgegenüber bietet der Web Map Service (WMS) einen Webdienst für ge-renderte Karten an. Die WMS-Spezifikation ist die bisher am erfolgreichsten umge-setzte Spezifikation des OGC.

2 Einleitung Im Zusammenhang mit dem Begriff der Interoperabilität im Geoinformationsbereich werden oft Abkürzungen wie OGC, GML, WMS und WFS verwendet. Seit den frühen neunziger Jahren hat sich in diesem Bereich eine breit abgestützte Organisation (Open Geospatial Consortium) gebildet, welche bestrebt ist, offene, systemneutrale Schnittstel-len zu schaffen, und so die Verfügbarkeit von Daten mit Raumbezug weltweit zu erhö-hen. Dabei wird auf bestehende Standards der Informatik-Welt aufgebaut. Zum Beispiel dient XML als Grundlage für praktisch alle Spezifikationen des OGC. Eine bereits erfolgreich umgesetzte Spezifikation des OGC ist der Web Map Service (WMS). Diese wurde von diversen kommerziellen Herstellern und von einigen Open-Source-Projekten erfolgreich implementiert. Den wohl wichtigsten Standard des OGC stellt die Geography Markup Language (GML) dar. GML stellt einen Mechanismus zur Modellierung und zum Austausch von primär vektor-orientierten Geodaten zur Verfügung. Verschiedene Webdienste wieder-um bauen auf GML auf. Ein Beispiel für solche Webdienste ist die Web Feature Service (WFS)-Spezifikation.In den folgenden Abschnitten werden das OGC selbst, sowie die oben genannten Spezi-fikationen näher vorgestellt. Zu beachten ist, dass damit nur ein kleiner Ausschnitt der vielfältigen Arbeit des OGC beleuchtet werden kann. Für detailliertere Informationen sei an dieser Stelle auf die Webseite www.opengeospatial.org verwiesen.

3 Open Geospatial Consortium (OGC)

3.1 Wer ist das OGC? Das Open Geospatial Consortium (OGC) ist ein internationales Industriekonsortium, bestehend aus über 270 Firmen, Behörden und Hochschulen, welches sich zum Ziel ge-setzt hat, öffentlich verfügbare Schnittstellen-Spezifikationen im Konsensverfahren zu entwickeln. OGC-Spezifikationen unterstützen interoperable Lösungen, welche das Web, mobile Anwendungen, Location Based Services (LBS) und allgemeine Informatik-lösungen um einen Raumbezug erweitern. Mit den OGC-Spezifikationen soll es Ent-wicklern möglich sein, komplexe Geoinformationen und darauf basierende Dienste ei-nem breiten Spektrum von Nutzern und Anwendungen zugänglich zu machen.

Nationale und internationale Standards Open Geospatial Consortium OGC (GML, WMS und WFS)


Das OGC finanziert sich primär über die Beiträge seiner Mitglieder. Zurzeit existieren acht verschiedene Mitgliederkategorien. Diese unterscheiden sich im zu entrichtenden Jahresbeitrag (zwischen 300$ bis >50'000$ pro Jahr) aber auch in den Rechten und Pflich-ten.OpenGIS® ist eine geschützte Marke des Open Geospatial Consortium, Inc. und dient gleichzeitig als Produktname für die Spezifikationen und Dokumente, welche vom OGC erstellt und publiziert werden.

3.2 Geschichte Die wichtigsten Ereignisse in der Geschichte des OGC können wie folgt zusam-mengefasst werden:

Jahr Meilenstein

80er Jahre Diverse Aktivitäten rund um das Open Source Projekt GRASS (Geographic Resource and Analysis Support System)

1994 Gründung des Open GIS Consortium, Inc. Mitgliederzahl Ende 1994: 20

1999Publikation der OpenGIS Web Map Server Interface Specification und des Zusammenarbeitsvertrags zwischen ISO/TC 211 und OGC Mitgliederzahl Ende 1999: 182

2004 Umbenennung in Open Geospatial Consortium, Inc. Mitgliederzahl Ende 2004: 272

Im Januar 2005 existierten 17 Abstract Specifications und 14 Implementation Specificati-ons. Zusätzlich wurden unzählige Recommendation Papers und weitere Entwürfe öf-fentlich publiziert.

4 Geography Markup Language (GML)

4.1 Was ist GML? Die Geography Markup Language (GML) ist eine XML-Applikation des Open Geo-spatial Consortiums (OGC) für die Modellierung, den Austausch und die Speicherung von Informationen mit Raumbezug. Die wichtigsten Ziele von GML sind:

Unterstützung möglichst vieler Einsatzgebiete (auch nicht-räumliche Daten kön-nen abgebildet werden) GML als Grundlage für Internet-GIS Anwendungen Einfach zu verstehende Codierung räumlicher Daten und derer Beziehungen Effiziente Codierung von Geometriedaten Trennung der Daten von deren Präsentation Einfache Integration bereits in XML vorhandener, nicht-räumlicher Daten Möglichkeit der Verknüpfung verschiedener Datensätze Bereitstellung eines Basissatzes geometrischer Objekte

Diese Ziele werden mit einer umfangreichen Spezifikation angepeilt. Die aktuelle Versi-on (3.1) der GML-Spezifikation beinhaltet etwa 600 Seiten.



4.2 Einsatzspektrum Eines der wichtigsten Ziele ist die universelle Verwendbarkeit von GML als Daten-format für beliebige Anwendungen mit räumlichem Bezug. Die hauptsächlichen Einsatzgebiete von GML sind:

Austausch von Daten zwischen verschiedenen GIS-Systemen Basis für Internet-GIS Anwendungen (Bsp. Web Feature Service, WFS) Basis für Location Based Services (LBS)

4.3 Konzept Das Konzept von GML beruht auf dem Feature-Modell des OGC. Ein 'Feature' gemäss der OGC-Definition besteht aus einem Objekt mit einer Reihe von Eigenschaften ('Pro-perties'). Jede dieser Eigenschaften ist charakterisiert durch ihren Namen, ihren Typ und ihren Wert. Wenn der Typ zumindest einer Eigenschaft eines Features geometrisch ist, spricht man von einem geographischen Feature. Mehrere Features können zu Feature Collections zusammengefasst werden. Eine Feature Collection repräsentiert allerdings wiederum ein Feature, so dass eine beliebig tiefe Schachtelung modelliert werden kann.

Abb. 1 : GML-Grundkonzept

GML 3 ist in ca. 30 XML-Schema-Dokumenten (Basisschemen) definiert. Für eine kon-krete Anwendung von GML muss ein anwendungsspezifisches Schema abgeleitet wer-den, welches auf den in den Basisschemen definierten Klassen aufbaut. Im Applikati-onsschema können eigene Features mit anwendungsspezifischen Eigenschaften defi-niert werden. Dies kann über Erweiterung oder Einschränkung der vorhandenen Klas-sen erreicht werden.

4.4 Verbindung zu ISO Das OGC ist bemüht, seine Konzepte denjenigen der ISO (International Organization for Standardization) anzupassen. So ist vorgesehen, die OGC-Spezifikation GML (Version 3.x) mit der ISO Norm 19136 (Geography Markup Language GML) zu harmonisieren. Gegenwärtig ist die ISO Norm 19136 in der 'Commitee Stage' (Stand Januar 2005). Das bedeutet, dass sich das zuständige Technical Commitee (TC) der ISO mit der Spezifika-tion befasst. In diesem Fall ist das TC 211 der ISO zuständig. Für nähere Angaben wird auf die Website der ISO (www.iso.org) verwiesen.



5 OGC Web Services

5.1 Zielsetzung Vielerorts sind bereits grosse Mengen von Daten in proprietären Datenformaten vor-handen. Die Nutzung dieser Daten von fremden Systemen aus ist nur mühsam, oder gar nicht möglich. Eine Lösung dafür bieten Webdienste an. Dabei wird über das Inter-net auf verteilte Datenquellen zugegriffen. Neben den grossen GIS-Herstellern, die sol-che Lösungen anbieten, sind auch Open Source Projekte verfügbar, die diese Funktiona-lität zur Verfügung stellen. Weiterhin ungelöst bleibt die Verknüpfung von unterschied-lichen Diensten (Insellösungen). Dies ist der Ansatzpunkt der OGC Web Services. Sie definieren Methoden, eine Reihe von Parametern sowie Kommunikationsregeln, die ei-nem beliebigen System den Zugriff auf verteilte Datenquellen ermöglichen, sofern beide Komponenten über die identische Schnittstelle verfügen.

5.2 Grundprinzip Die OGC definierte in der OWS (OGC Web Services) Common Implementation Specifi-cation die Gemeinsamkeiten ihrer verschiedenen Web Services. Der Ausdruck Web Ser-vice beschreibt die standardisierte Weise der Integration netzwerk-basierter Applikatio-nen. Für die Definition und Beschreibung der Applikationen wird XML verwendet. Die Kommunikation erfolgt auf der Basis von Internet-Protokollen. Durch den Einsatz von XML sind Web Services nicht an ein bestimmtes Betriebssystem oder eine bestimmte Programmiersprache gebunden.

Abb. 2 : Funktionsschema OGC Web Services

Das in Abb. 2 dargestellte Funktionsschema stellt folgende Funktionen dar: 1. Client kontaktiert Server und fordert Capabilities-Dokument an 2. Server liefert XML-formatierte Capabilities (Beschreibung der Funktionalität) des

gewünschten Services an den Client 3. Client fordert Daten vom Server an 4. Server liefert die angeforderten Daten im verlangten Format

Diese vier Schritte bilden die Grundfunktionalität eines Services nach OGC-Spezifi-kation. Je nach Service sind weitere Interaktionen zwischen Client und Server möglich, beispielsweise das Abfragen weiterer Informationen über ein Feature, ein Kartenlayer etc.Web Services kommunizieren (gemäss ihrer Definition) mit Hilfe von beliebigen Inter-net-Protokollen miteinander. Die meisten OGC Web Services benutzen zurzeit das HTTP-Protokoll. Das Hyper Text Transfer Protocol (HTTP) verfügt über ein sehr einfa-ches Interaktionsschema zwischen Client und Server, welches aus einem von einem Client an einen Server gesendeten Request (Anfrage) und einer vom Server an den Client geschickten Response (Antwort) besteht.



5.3 Web Map Service (WMS) Die WMS-Spezifikation beschreibt eine Schnittstelle, über welche georeferenzierte Kar-ten bereitgestellt werden können. Die Realisierung basiert auf drei Grundoperationen, für die jeweils ein Parametersatz definiert ist:

Beschreibung der verfügbaren Daten (GetCapabilities) Lieferung der angeforderten Daten (GetMap) Abfragen weiterer Informationen (GetFeatureInfo)

Dabei sind die ersten beiden Operationen zwingend zu implementieren, die Funktion zur Abfrage von Feature-Informationen ist optional. Der Zugriff auf einen WMS kann mit Hilfe eines Standardbrowsers erfolgen, wobei die Parameter in der URL übermittelt werden (GET Methode). Komfortabler sind natürlich Programme mit einer graphischen Benutzeroberfläche (GUI), entweder als Browser- o-der als Standalone-Applikation konzipiert. Mit der aktuellen WMS-Version (1.3) ist auch die Übermittlung der Anfragen mit der POST Methode festgelegt. Im Allgemeinen liefert ein WMS gerenderte Bilder in einem üblichen Bildformat wie PNG (Portable Network Graphics), JPEG (Joint Pictures Expert Group) oder GIF (Gra-phics Interchange Format). Denkbar ist aber auch die Erzeugung von Karten im SVG-Format (Scalable Vector Graphics).

Abb. 3 : Schematische Darstellung verteilter WMS

WMS-Karten können von beliebigen, verschiedenen WMS angefordert werden. Das heisst, die Spezifikation unterstützt den Aufbau eines Netzwerkes verteilter Map Server von denen ein Client Daten anfordern kann (siehe Abb. 3). Da jeder WMS unabhängig ist, muss jeder die Fähigkeit besitzen, seine Möglichkeiten und Ressourcen maschinen-lesbar zu beschreiben. In Abb. 3 ist zudem das Konzept eines kaskadierenden Map Servers (Cascading Map Server) dargestellt. Dabei ist ein Map Server ein Client von anderen WMS und bildet gegen aussen einen neuen Web Map Service (Zusammenfassen mehrerer WMS in einen Service).Die Spezifikation WMS 1.3 des OGC wird zurzeit als ISO/DIS Norm 19128 (Web Map Server Interface) in die ISO-Normenserie integriert.

5.4 Web Feature Service (WFS) Während mit dem WMS in der Regel gerenderte (Raster-)Daten geliefert werden, steht bei der WFS-Spezifikation die Übertragung von geographischen Objekten im Vorder-grund. Dabei stellt sich das Problem, dass Geodaten oft nicht nach einem einheitlichen Datenschema modelliert sind. Deshalb ist es wichtig, dass das Datenschema mit den Da-ten mitgeliefert wird. Ein entsprechender Client muss somit mit diesem Datenschema und den Daten umgehen können.



Als Grundlage für die WFS-Spezifikation dient der Datenaustauschmechanismus GML (Geography Markup Language) des OGC. Damit können Geodaten und ihr zugehöriges Schema in XML codiert und übertragen werden. Im Unterschied zum WMS ist es auch möglich, diese Daten zu manipulieren und zu verändern. Dazu wurden weiterführende Operationen wie 'Transaction' und 'LockFea-ture' definiert. Die folgenden Operationen sind in der WFS-Spezifikation definiert:

GetCapabilities: Ein WFS muss in der Lage sein, seine Funktionalität zu beschreiben. Im Speziellen muss er in der Lage sein, die unterstützen Feature-Typen und die darauf anwendbaren Operationen anzugeben. DescribeFeatureType: Auf Anfrage muss ein WFS in der Lage sein, die Struktur jedes unterstützten Feature-Typen zu liefern (Datenschema). Konkret wird hier ein GML-Applikationsschema übertragen. GetFeature: Ein WFS muss in der Lage sein, Instanzen (Objekte) von Feature-Typen zu liefern. Zusätzlich muss er erkennen, welche Eigenschaften (properties) er mit-liefern soll, und er muss in der Lage sein, sowohl räumliche wie auch nicht-räumliche Selektionen zu unterstützen. Transaction: Ein WFS kann in der Lage sein, Operationen an Objekten auszuführen. Diese Operationen sind 'create', 'update' und 'delete' an geographischen Objekten. LockFeature: Ein WFS kann einen Lock-Request auf eine oder mehrere Instanzen während der Dauer einer Transaktion anwenden.

Dementsprechend kann zwischen verschiedenen Typen von Web Feature Services un-terschieden werden:

Basic WFS: Ein Basis-WFS unterstützt die Operationen 'GetCapabilities', 'Describe-FeatureType' und 'GetFeature'. Dies entspricht einem 'Read-Only'-WFS. Transaction WFS: Dieser unterstützt sämtliche Operationen des Basis-WFS, und zusätzlich die Operationen 'Transaction' und 'LockFeature' (optional).

Ein WFS liefert mit dem GetFeature-Aufruf ein GML-Instanzdokument. In der aktuell gültigen Version der WFS-Spezifikation (1.0) ist festgelegt, dass die GML-Version 2 verwendet werden soll. Gegenwärtig ist die WFS-Spezifikation in einer Über-arbeitungsphase, in welcher unter anderem die Integration der Version 3 von GML dis-kutiert wird. Allerdings ist noch nicht klar, ob die vollständige GML 3 – Spezifikation unterstützt werden soll. Auf Grund der Komplexität der aktuellen GML-Version wird über eine Einschränkung mit einem Profil (Level 0) diskutiert.

6 Fazit Mit dem OGC hat sich im Geoinformationssektor ein sehr aktives, internationales In-dustriekonsortium mit internationalem Standardisierungsanspruch etabliert. Durch die Mitwirkung grosser Systemhersteller, nationaler und internationaler Behörden und vie-ler Hochschulen ist das Konsortium mittlerweile breit abgestützt. Mit seinen Aktivitäten hat das OGC zu einer deutlichen Verlagerung bzw. Erweiterung des Fokus von den vie-len nationalen Normen und Standards auf die internationale Standardisierung beigetra-gen. Erfreulich ist, dass dabei die OGC seit einigen Jahren ihre Aktivitäten mit denjeni-gen der ISO harmonisiert, was mittel- und langfristig zu einer breiteren Akzeptanz und auch zu stabileren Standards führen dürfte. Mit WMS, WFS und GML hat das OGC drei sehr nützliche Spezifikationen geschaffen. Dabei hat sich am Beispiel des WMS gezeigt, dass sogar die Umsetzung eines relativ



einfachen Standards auf internationaler Basis mehrere Jahre in Anspruch nehmen kann. Es ist daher anzunehmen, dass die Definition von Minimalprofilen im Falle von GML und WFS eine erfolgreiche Umsetzung deutlich beschleunigen würde. Der für einen breiten Einsatz der Standards dringende Übergang von formatbasierten auf modellba-sierte Mechanismen wurde von OGC mittlerweile erkannt und eingeleitet. Das damit verbundene Umdenken bei Systemherstellern und Anwendern sowie die konsequente Umsetzung dürften aber noch viel Arbeit und Zeit erfordern.

7 Literatur Nebiker S. und Annen A. , 2004 Vergleichsstudie INTERLIS 2 – GML 3 Verfügbar unter: http://www.kogis.ch/docs/Vergleichsstudie_ILI_GML_revidiert.pdf[Online 21. Jan. 05]

Nebiker, S., et al., 2004 Skript zum GIS/SIT-Workshop 2004: 'WMS, WFS, Simple Features und Co.' [durchgeführt am 30. März 2004 in Bern]

Open Geospatial Consortium Inc. (OGC), 2004 Geography Markup Language (GML) Recommendation Paper 3.1 Verfügbar unter: http://portal.opengeospatial.org/files/?artifact_id=4700 [Online 21. Jan. 05]

Open Geospatial Consortium Inc. (OGC), 2004 Web Map Service (WMS) Implementation Specification 1.3 Verfügbar unter: http://portal.opengeospatial.org/files/?artifact_id=5316 [Online 21. Jan. 05]

Open Geospatial Consortium Inc. (OGC), 2002 Web Feature Service (WFS) Implementation Specification 1.0 Verfügbar unter: https://portal.opengeospatial.org/files/?artifact_id=7176 [Online 21. Jan. 05]

International Organization for Standardization (ISO). Informationen zu diversen Standards Verfügbar unter: http://www.iso.org [Online 21. Jan. 05]

6

OGC-Lösungen

Möglichkeiten und Grenzen

Andreas Donaubauer, Matthäus Schilcher,Anette Huber, TU München

Andreas Donaubauer, Dr.-Ing. / Matthäus Schilcher, Univ.-Prof. Dr.-Ing. / Anette Huber Technische Universität München Fachgebiet Geoinformationssysteme Arcisstraße 21 D-80290 München


+49 89 289 22973 +49 89 289 22878


VorwortDer Beitrag gibt einen Überblick über den Stand der Technik zur Nutzung verteilter Geodaten auf der Basis der Standards des Open Geospatial Consortium (OGC). Anhand von Praxistests werden die Möglichkeiten und Grenzen von OGC-Standards diskutiert. Im Ausblick wird ein neues Forschungsprojekt zwischen ETH Zürich und TU München zum Aufbau einer grenzüberschreitenden Geodateninfrastruktur (GDI) vor-gestellt, bei dem Synergien der beiden Lösungsansätze „modellbasierter Datentransfer“ und „OGC Web Services“ untersucht werden sollen.

1 Einführung und Begriffsbestimmung Seit nun gut 20 Jahren werden an verschiedensten Stellen in Verwaltung und Wirtschaft digitale Geodaten produziert. Dabei entstand im Laufe der Zeit eine große Anzahl an verteilten Geodatenbeständen, deren effiziente und nachhaltige Nutzung über organisa-torische Grenzen hinweg jedoch meist durch die derzeit existierenden heterogenen GIS-Landschaften behindert wird. Die Probleme liegen vor allem in der Heterogenität der verschiedenen Systeme – deren proprietären Schnittstellen und Datenformaten – aber auch in der Verwendung verschiedener Datenmodelle sowohl auf konzeptioneller, logi-scher und physikalischer Ebene begründet. Zur Überwindung der derzeit bestehenden Probleme bei der kombinierten Nutzung verteilter, heterogener Geodaten werden in Wirtschaft und Forschung momentan zwei Lösungsansätze intensiv diskutiert und verfolgt, die auf internationalen Standards und Normen basieren. Zum einen der modellbasierte Datentransfer zur Überwindung der Heterogenität der Daten und deren zugrunde liegenden Modellen, wie er in der Geo-Normenserie ISO19100 konzipiert ist und mit INTERLIS, einer Schweizer Norm ermög-licht wird, zum anderen die Verwendung von Geo Web Services des Open Geospatial Consortiums OGC zur Herstellung von Interoperabilität zwischen verschiedenen GI-Systemen in Bezug auf deren proprietäre Zugriffsschnittstellen und Datenformate. Dieser Beitrag beschreibt die Möglichkeiten und Grenzen des auf Interoperabilität mittels OGC Web Services1 basierenden Lösungsansatzes und gibt einen Ausblick auf eine zukünftige Kombination der beiden Lösungsansätze „Interoperabilität mit-tels OGC Web Services“ und „modellbasierter Datentransfer“ – im Folgenden mit „Kombinierter Ansatz“ bezeichnet. Tabelle 1 gibt einen Überblick über Methoden zur kombinierten Nutzung verteilter Geodaten und erlaubt eine Einordnung der genannten Lösungsansätze.

1 Dieser Beitrag beschränkt sich auf das Web als Plattform für die Interoperabilität von GI-Systemen. Das OGC erarbeitet neben den Spezifikationen auf Basis der Web-Technologie (OGC Web Services) auch Standards für weitere Plattformen (z.B. SQL, CORBA, JAVA). Diese werden hier nicht betrachtet.

Stand der Technik, Implementierungen I OGC-Lösungen: Möglichkeiten und Grenzen


Beispiele fürStandards und Normen

Beispiele für herstellerspezifische / proprietäre Formate / Zugriffsschnittstellen

grafik-orientiert TIFF (ISO 12639), SVG (W3C)

DBR (SICAD) DXF (CAD)

objektstrukturiert GDF (ISO 14825) Shape (ESRI), SQD

Datentransfer auf Dateiebene

„Datenintegration“ modellbasiert INTERLIS ? grafik-orientiert OGC WMS Web-Zugriffs-

Schnittstelle von Autodesk MapGuide

objektstrukturiert OGC WFS Zugriffsschnittstelle eines ESRI ArcIMS Feature Service

Interoperabilität (Internet als Kommunikationsplattform zwischen den Softwarekomponenten)

„Web Services“ modellbasiert OGC+INTERLIS

(noch nicht verfügbar)

„kombinierter Ansatz“ OGC Web Services

Tab. 1 : Methoden zur kombinierten Nutzung verteilter Geodaten

Im Folgenden werden einige grundlegende Begriffe für den Lösungsansatz „Interope-rabilität mittels OGC Web Services definiert. Verteilte (Geo-)Daten: (Geo-)Daten, die physikalisch oder logisch getrennt von einan-der vorgehalten werden. Interoperabilität: Fähigkeit zur Zusammenarbeit unabhängiger Systeme durch Anbie-ten bzw. Inanspruchnahme von Daten und Funktionalität über Softwareschnittstellen. Dienst / Service: Abgeschlossene Funktionalität, die von einer Softwarekomponente über eine Softwareschnittstelle angeboten wird. Komplexität und interne Strukturen der Softwarekomponente bleiben vor dem Nutzer eines Dienstes verborgen. Verkettung von Diensten / Service Chaining: Sequentieller oder paralleler Aufruf von Diensten, so dass die Antwort eines Dienstes als Eingabe für den Aufruf eines weiteren Dienstes in der Kette verwendet wird. Die Verkettung von Diensten ist grundlegend für die Erstellung von Dienstebündeln. Dienstebündel / Aggregate Service: Kombination einzelner Dienste zu einem höher-wertigen Dienst. Ein Dienstebündel muss erstellt werden, wenn die Funktionalität oder das Datenangebot eines einzelnen Dienstes nicht ausreicht, um die Fragestellung eines Anwenders zu beantworten. Kern jedes Dienstebündels ist ein so genannter Aggregate Service, der die Benutzereingaben entgegennimmt, für die Verkettung der Dienste ver-antwortlich ist und das Endergebnis an den Benutzer ausliefert. Ein Aggregate Service tritt somit als Client für mehrere Dienste auf. Web Service: Funktionalität, die von einer Softwarekomponente über eine Web-Schnittstelle angeboten wird. Über die Web Schnittstelle können auch die Fähigkeiten und weitere Informationen über den Web Service angefragt werden Geo Web Service: Web Service mit der Funktionalität zur Nutzung von Geodaten OGC Web Service: Geo Web Service mit einer vom Open Geospatial Consortium OGC spezifizierten Schnittstelle.



2 Möglichkeiten von OGC Web Services Die Anwendung „Leitungsauskunft aus verteilten GIS“, ist in einem praxisorientierten Forschungsprojekt der Technischen Universität München und des Vereins Runder Tisch GIS e.V. entstanden. Sie soll im Folgenden beispielhaft die Möglichkeiten und Vorteile der einfachen Nutzung verteilter Geodaten mittels OGC Web Services aufzeigen.

2.1 Erfahrungen der TU München und des Vereins Runder Tisch GIS e.V.

Das Fachgebiet Geoinformationssysteme der TU München und der Verein Runder Tisch GIS e.V. konnten seit dem Jahr 2000 in mehreren Forschungsprojekten umfangreiche Erfahrungen mit der Entwicklung, Nutzung und herstellerübergreifenden Kombination von OGC Web Services sammeln.

2.1.1 Forschungsschwerpunkte Schwerpunkte der Forschungsarbeiten der TU München und des Vereins Runder Tisch GIS e.V. im Bereich der Nutzung verteilter Geodaten sind:

Einfacherer Zugang und effizientere Nutzung vorhandener Geodaten, Nutzung verteilter Geodaten für eine neues Nutzerprofil (GIS-Laien), Verkettung von Geo Web Services, Möglichkeiten und Grenzen der Nutzung von OGC Web Services, Herstellerübergreifende Interoperabilität auf Basis der Standards des OGC Wirtschaftlichkeit und Geschäftsmodelle für die Nutzung verteilter Geodaten.

2.1.2 OGC Testplattform des Vereins Runder Tisch GIS e.V. Im Rahmen der OGC-Testplattform, einer Testumgebung, in der Produkte aller führen-den GIS-Hersteller sowie Open Source Software betrieben werden (siehe Abb. 1), wird vom Runden Tisch GIS e.V. GIS-herstellerübergreifend die Umsetzung von OGC Spezi-fikationen untersucht. Wesentliche Ziele sind es, zu zeigen:

dass GIS unterschiedlicher Hersteller auf Basis der OGC Standards in gemeinsa-men Anwendungen zusammenwirken können, dass durch den Zugriff auf verteilte Daten von Behörden und aus der Wirtschaft mittels OGC Web Services ein Nutzen für den Anwender generiert werden kann, dass Praxis-Anwendungen auf der Basis des Zugriffs auf existierende, verteilte Geodatenbestände mittels OGC Web Services entwickelt werden können, dass der Ansatz im deutschen Umfeld und länderübergreifend erfolgreich einge-setzt werden kann.



• AED-SICAD(Internet Suite 6.0)

• Autodesk(MapGuide 6.5)

• C-Plan (TB Internet)

• ESRI(ESRI ArcIMS 9.0 SP1 mit WMS- und WFS-Connector)

• GE Energy (Smallworld SIAS 2.1)

• Intergraph (GeoMedia WebMap 5.1b mit WMS und WFS Adapter)

• M.O.S.S.(WEGA-MARS 4.2)

• Terradata• University of

Minnesota (UMN Map Server 4.3)

• WMS (Web Map Service)

• WFS (Web Feature Service)

• WCTS (Web CoordinateTransformation Service)

• Aggregate Services:implementieren mehrere Spezifikationen als Client

• Herstellerübergreifender Interoperabilitätstest WMS

• Immobilienbewertung(länderübergreifend)

• Leitungsauskunft aus verteilten GIS

Hersteller (Produkte) OGC-Spezifikationen Anwendungs-beispiele

Testgebiete (Datenanbieter)

• Baden-Württemberg,Stadt Horb am Neckar

• Bayern:Landkreis Fürstenfeldbruck, Stadt Bad Wörishofen, Stadt München, Stadt Nürnberg

• Brandenburg:Landkreis Barnim

Universitäten

• Technische Universität München

• Universität der Bundeswehr München

GIS-Dienstleistungs-unternehmen

• Geo-IT

• RIWA

Abb. 1 : OGC-Testplattform des Vereins Runder Tisch GIS e.V. (Stand Januar 2005)

Weitere Merkmale der OGC-Testplattform sind: herstellerneutral,hersteller- und branchenübergreifend, grenzüberschreitend, Aufbau durch Zusammenarbeit zwischen Datenlieferanten, Systemherstellern, Universitäten und GIS-Dienstleistungsunternehmen Forschung anhand konkreter und praktisch verwertbarer Anwendungen, Beitrag zum Aufbau von Geodateninfrastrukturen (GDI), führend im Bereich der herstellerübergreifenden Nutzung von OGC Web Feature Services und im Bereich der Verkettung von OGC Web Services (Service Chai-ning).

Auf der Fachmesse INTERGEO 2003 konnten mit dem hersteller- wie länderübergrei-fenden Anwendungsbeispiel „Immobilienbewertung“ demonstriert werden, dass die OGC-Web-Map-Service-Spezifikation (WMS) eine tragfähige Basis für interoperable Web-GIS-Auskunftslösungen ist. Im Vergleich zu früheren Interoperabilitäts-Untersuchungen des Runden Tisch GIS e.V. konnte zudem gezeigt werden, dass die GI-Systeme der führenden Hersteller mittlerweile ausgereifte WMS-Schnittstellen besitzen. Auf der INTERGEO 2004 wurde das Anwendungsbeispiel „Leitungsauskunft aus ver-teilten GIS“ präsentiert, das erstmals einen herstellerübergreifenden Interoperabilitäts-nachweis auf Basis der Web Feature Service Spezifikation (WFS) lieferte.

2.2 Anwendungsbeispiel „Leitungsauskunft aus vereilten GIS“

2.2.1 Ausgangssituation Betreiber von Leitungsnetzen (Energieversorgungs- und Telekommunikationsunter-nehmen, Kommunen etc.) sind gesetzlich dazu verpflichtet, Dritten Auskunft darüber zu geben, ob ihre Leitungen von einer geplanten Baumaßnahme betroffen sind. Bei ei-nem Energieversorger gehen je nach Größe des Unternehmens mehrere tausend solcher



Anfragen pro Jahr ein. Jährlich entstehen durch die Beeinträchtigungen Dritter große Schadenssummen an den Leitungsnetzen. Daher ist es im Interesse jedes Leitungs-betreibers, der Auskunftspflicht genüge zu tun [KOPPERSCHMIDT 2004]. Aufgrund der Vielzahl an Trassen und Sparten sowie der großen Anzahl potenzieller Anwender birgt die Dienstleistung einer sparten- und unternehmensübergreifenden Leitungsaus-kunft ein großes Potenzial (siehe Abb. 2).

Amtliche Geobasisdaten-Geocodierte Adressen-ALK, DFK, Orthophotos

Bürger

Kommunen

Tiefbauämter

Leitungsbetreiber

LeitungsbetreiberKundenpotenzial

...

GISDienstleister

Stromversorger

Telekom

Fernwärmeerzeuger

Kanalbetreiber

Wasserversorger

...

Gasversorger

. . .

. . .

. . .

. . .

. . .

GIS A

GIS B

GIS C

Grafik modifiziert nach: micus management consulting GmbH

Abb. 2 : Leitungsauskunft aus verteilten GIS als Dienstleistung

Um eine derartige Lösung anbieten zu können, muss ein GIS-Dienstleister Zugriff auf die Geodaten der Leitungsbetreiber sowie auf amtliche Geobasisdaten haben. Zwei Hindernisse stellen sich dem GIS-Dienstleister als potenziellem Betreiber einer derartigen unternehmensübergreifenden Lösung entgegen: Zum einen ist dies die Hete-rogenität und Verteiltheit der Geodatenbestände der Leitungsbetreiber, zum anderen sind letztere selten dazu bereit, ihre Geodaten an Dritte abzugeben.

2.2.2 Lösungsansätze Aus Sicht eines GIS-Dienstleisters gibt es prinzipiell zwei technische Lösungsansätze um die Verteiltheit und Heterogenität der Geodatenbestände der Leitungsbetreiber zu überwinden:

Lösungsansatz A: Datenintegration (Aufbau eines GIS beim Dienstleister, das Kopien der Daten aller Leitungsbetreiber sowie amtlicher Geobasisdaten enthält), Lösungsansatz B: Stellen von Anfragen an verteilte GIS mittels OGC Web Ser-vices (Daten bleiben bei den Leitungsbetreibern, diese geben lediglich Auskunft über Web Services Schnittstellen nach den Spezifikationen des Open Geospatial Consortium OGC).

Im Fall einer unternehmensübergreifenden Leitungsauskunft erweist sich der Lösungs-ansatz A jedoch aus folgenden Gründen als problematisch:

Leitungsbetreiber müssen ihre vollständigen Leitungsdaten an den Dienstleister abgeben.Wegen der Heterogenität der Daten und Systeme der Leitungsbetreiber ist eine Datenintegration teuer und zeitaufwändig.



Der Dienstleister ist für die Aktualität des integrierten Datenbestands verant-wortlich, was einerseits auf Seiten des Dienstleisters weitere Kosten verursacht und andererseits auch zu Haftungsproblemen bei Fehlinformationen aufgrund veralterter Daten führen kann.

Aufgrund dieser Überlegungen beschloss der Verein Runder Tisch GIS im Jahr 2004 auf Basis seiner OGC Testplattform eine Lösung nach dem Lösungsansatz B, dem Zugriff auf verteilte GIS mittels OGC Web Services zu entwickeln. Mit diesem Projekt wurden u.a. folgende Ziele verfolgt:

Hersteller- und länderübergreifende Nutzung von Auskunftsfunktionalität auf Basis der OGC Web Feature Service Spezifikation Aufzeigen des Potenzials von Geo Web Services mit standardisierten Schnittstel-len am Beispiel einer innovativen Auskunftslösung.

2.2.3 Einsatz von OGC Web Services für die Leitungsauskunft aus verteilten GIS Abbildung 3 zeigt die Systemarchitektur und insbesondere den Einsatz der OGC Schnittstellen Web Map Service (WMS) und Web Feature Service (WFS).

Aggregate Service Strom

Wasser

Abwasser

Gas

. . .

Amtliche Geobasisdaten-Geocodierte Adressen-ALK, DFK, Orthophotos

Browser

WFS Bridge

OGC Web Feature Service

Beleuchtung

OGC WebMap Service

GIS A

GIS B

GIS C

GIS D

GIS E

Internet-Verbindung

Abb. 3 : Systemarchitektur

Während die OGC Web Services den lesenden Zugriff auf die verteilten und über das Internet vernetzten Systeme der Leitungsbetreiber und der Anbieter amtlicher Geoba-sisdaten dienen, erfüllt der anwendungsspezifische so genannte Aggregate Service fol-gende Aufgaben:

Benutzereingaben entgegennehmen und in Anfragen an OGC Web Services (OWS) umformen, Ergebnisse eines OGC Web Service in Anfragen an einen anderen OWS umfor-men,Ergebnisse mehrerer OWS kombinieren, abhängig vom Ergebnis eines OWS den Workflow regelbasiert verzweigen, auf den Ausfall und auf Fehlermeldungen von OWS sowie auf Inkonsistenzen in den Ergebnissen der beteiligten OWS reagieren, dem Anwender Zwischenergebnisse bzw. ein Endergebnis präsentieren, Verbergen der Komplexität des verteilten Systems vor dem Anwender.

Die folgenden Abbildungen geben den Ablauf einer Anfrage an das System „Leitungs-auskunft aus verteilten GIS“ wieder.



Abb. 4 : Adresseingabe

Der Anwender erhält eine Eingabemaske für die Adresseingabe vom Aggregate Service und gibt Strasse, Hausnummer, Postleitzahl, Ort der Schadensstelle bzw. der geplanten Baumaßnahme ein.

Abb. 5 : Geokodierung

Die vom Anwender ausgewählte Adresse wird vom Aggregate Service an einen so ge-nannten Geocoding Service (hier ein Web Feature Service, der den Zugriff auf geoco-dierte Adressdaten erlaubt) gesendet. Der Geocoding Service wandelt die Adresse in Koordinaten um.

Abb. 6 : Laden der Liegenschaftskarte



Für den geographischen Ausschnitt der Adresse wird durch einen WMS-Client ein ent-sprechender Ausschnitt aus der amtlichen Liegenschaftskarte geladen.

Abb. 7 : Schadensstelle durch Polygon abgrenzen

Der Anwender markiert die Schadensstelle bzw. den Ort einer geplanten Baumaßnahme durch Einzeichnen eines Polygons auf der Liegenschaftskarte

Abb. 8 : Leitungsanfrage an einzelne Leitungsbetreiber

Das Polygon wird vom Aggregate Service des GIS-Dienstleisters an die einzelnen Sys-teme (WFS-Bridges) der Leitungsbetreiber übermittelt. Die WFS-Bridges formulieren die Anfragen an die Web Feature Services der Leitungsbetreiber (Operation „GetFeature“, geometrischer Filter „Intersects“ mit Polygon als Argument des Filters), wandeln die Antworten der WFS (GML-Dokumente) in Antworten der Form „Leitungsnetz betrof-fen“/“Leitungsnetz nicht betroffen“ um und senden diese an den Aggregate Service des GIS-Dienstleisters zurück. Der Aggregate Service des GIS-Dienstleisters fasst die einzelnen Ergebnisse der Anfra-gen an die Systeme der Leitungsbetreiber zusammen und sendet das Gesamtergebnis in Form einer HTML-Seite an den Anwender zurück.

2.3 Zusammenfassung Das vorgestellte Anwendungsbeispiel „Leitungsauskunft aus verteilten GIS“ zeigt deut-lich das Prinzip, die Vorteile und die technische Machbarkeit von Lösungen auf der Ba-sis von OGC Web Services zur losen Verknüpfung verteilter Systemkomponenten.



Das Prinzip: Verteilte Datenhaltung: Die Daten bleiben verteilt auf die Systeme, mit denen sie erfasst und gepflegt werden. Dienstorientierte Architektur: Die Zusammenarbeit der Systeme funktioniert ü-ber den Aufruf entfernter Operationen, also über das Stellen von Anfragen. Vor-rangiges Ziel der Anfragen ist es nicht, Geodaten zum Anwender zu transferieren, damit dieser sie analysieren und weiterverarbeiten kann. Vielmehr soll der An-wender eine Antwort auf seine raumbezogene Fragestellung erhalten (z.B. „Liegt das Flurstück X in einem Wasserschutzgebiet?“) Standardisierte Dienstschnittstellen: Sowohl die Anfragen als auch die Ergebnis-se der Anfragen sind standardisiert. Dank der standardisierten Zugriffsschnittstel-len sind die Anfragen an Systeme unterschiedlicher GIS-Hersteller identisch auf-gebaut. Möglicherweise komplexe interne Strukturen der Systeme sowie das kon-zeptionelle Datenmodell bleiben vor dem Anwender dank der relativ einfach auf-gebauten Dienstschnittstellen verborgen.

Die Vorteile: Einfache Clients: Beim Endanwender müssen weder Geodaten noch GIS-Funktionalität vorgehalten werden. Die Einstiegshürde zur Nutzung der GIS-Technologie ist gering. Neue Nutzergruppen für vorhandene Geoinformations-Ressourcen können so erschlossen werden. Geringer Aufwand für Betreiber von Auskunftslösungen: Der Betreiber einer Auskunftslösung spart Zeit und Kosten durch den Entfall der Arbeitsschritte Da-tenbeschaffung, Datentransfer, Formatkonvertierung, Datenaufbereitung und Da-tenpflege.Datenaktualität: Der Web-Zugriff auf Geodaten des originären Datenanbieters hat eine Qualitätssteigerung durch die Nutzung aktueller Daten zur Folge. Wiederverwendbarkeit von Komponenten: Einmal im Web veröffentlichte Geo Web Services sind mehrfach verwendbar. Durch die vielfältigen Kombinations-möglichkeiten von Geo Web Services können einmal eingerichtete Geo Web Servi-ces in einer Vielzahl an Lösungen verwendet werden.

3 Grenzen von OGC Web Services Die aktuellen Grenzen der Interoperabilität mittels OGC Web Services zur kombinierten Nutzung verteilter Geodaten werden im Folgenden dargestellt.

3.1 Grenzen in der Praktikabilität Bei der Lösung raumbezogener Fragestellungen aus der Praxis mittels verteilten Geoda-ten und OGC Web Services zeigten sich folgende, heute noch bestehende Mängel in der Praktikabilität des Lösungsansatzes:

Aufwand bei der Kombination von OGC Web Services unterschiedlicher Ty-pen: Sollen OGC Web Services unterschiedlicher Service-Typen (z.B. Gazetteer Service und Map Service) in einer Service Kette miteinander verknüpft werden, so kommt es auf die Konsistenz der OGC Standards untereinander an. Hier sind noch einige Inkonsistenzen festzustellen, die bei der Kombination von OGC Web Services unterschiedlicher Typen zu einem Mehraufwand aufgrund syntaktischer Umformung bedeuten. Im oben beschriebenen Anwendungsbeispiel „Leitungs-



auskunft aus verteilten GIS“ werden diese Inkonsistenzen durch Programmier-aufwand beim Aggregate Service kompensiert. Betrachtet man die Konsistenz zwischen den Standards für Web Services der In-formatik und der Geoinformatik, so stellt man fest, dass die momentan gültigen Versionen der OGC Spezifikationen insbesondere den für Web Services gängigen SOAP-Standard noch nicht unterstützen, was eine Integration der OGC Web Ser-vices in die allgemeine IT-Landschaft behindern könnte. Übertragungsrate im Internet: Die Ergebnisse von Anfragen an OGC Web Servi-ces können ein großes Datenvolumen haben (z.B. hochaufgelöste Rasterbilder bei WMS, GML-Daten bei WFS), so dass bei den heute möglichen Übertragungsraten die verteilte Datenhaltung und verteilte Verarbeitung nicht immer praktikabel ist. Grenzen der Verteiltheit und Modularität: Untersuchungen der TU München [Donaubauer 2004a] haben gezeigt, dass zur Lösung einer raumbezogenen Frage-stellung auf Basis verteilter Datenhaltung und OGC Web Services im Vergleich mit dem Zugriff auf einen integrierten Datenbestand unter Umständen ein Vielfa-ches an Anfragen gestellt werden müssen.

3.2 Grenzen in der Akzeptanz Die Akzeptanz des Lösungsansatzes in der Praxis, bei GIS-Herstellern wie bei den (po-tenziellen) Betreibern von OGC Web Services (z.B. Datenanbieter und Dienstleister) ist grundlegend dafür, dass ein Nutzen für Anwender entsteht. Erst wenn viele Hersteller ausgereifte OGC-Schnittstellen für ihre Systeme sowohl auf Server- als auch auf Client-Seite anbieten und erst wenn die Großkunden der GIS-Hersteller, z.B. die großen Da-tenproduzenten, diese Schnittstellen nachfragen und einsetzen, wird es interessant und wirtschaftlich sinnvoll, den Lösungsansatz für Praxisanwendungen einzusetzen. Ein Teil der Spezifikationen für OGC Web Services findet heute bereits eine breite Un-terstützung in den Produkten der GIS-Hersteller. Herstellerübergreifende Interopera-bilität wurde insbesondere für die am häufigsten implementierte, grafikorientierte Spe-zifikation WMS mehrfach getestet (vgl. z.B. KUNKEL/TEEGE 2003). Die Praxistaug-lichkeit WMS-basierter Lösungen konnte nachgewiesen werden (vgl. SCHILCHER et al. 2004 und WILLKOMM 2004). Die oben beschriebene OGC Testplattform des Runder Tisch GIS e.V. zeigt, dass zwar auch die WFS-Spezifikation heute bereits von vielen GIS-Herstellern unterstützt wird, jedoch nur sehr selten vollständig.Die Umsetzung der OGC Spezifikationen beschränkt sich heute meist auf Auskunft aus vorhandenen Geodatenbanken, also auf den lesenden Zugriff. Die Möglichkeit des schreibenden Zugriffs, die ein Transactional WFS bietet, wurde nur in sehr wenigen Fällen umgesetzt. Gründe hierfür sind einerseits in der Komplexität der Umsetzung ei-nes standardisierten Schreibzugriffs (Transaktionsmanagement, Abbruch der Verbin-dung im Internet usw.) zu suchen, andererseits aber auch in der mangelnden Nachfrage dieser Funktionalität seitens der potenziellen Betreiber von OGC Web Services. Generell gibt es immer noch große Bedenken seitens der Datenanbieter als potenziellen Betreibern von OGC Web Services, einen Zugriff auf ihre Systeme über das Internet zu-zulassen. Dies könnte auch daran liegen, dass die OGC Spezifikation in den Bereichen Sicherheit und Zugriffskontrolle (Digital Rights Management) noch Lücken aufwei-sen. Auch ein Standard für einen Web Service zur Abrechnung von Leistungen befindet sich noch in der Entwurfsphase.



3.3 Grenzen in der Funktionalität Auch wenn die Realisierung von Auskunftslösungen auf Basis von OGC Web Servi-ces heute kein Problem mehr darstellt, so decken die heute verfügbaren OGC Spezifi-kationen doch noch nicht alle wichtigen Analysemethoden für Geodatenbanken ab. So fehlen metrische Anfragen (Fläche, Umfang etc. der geometrischen Eigenschaften von Geoobjekten) sowie Analysemethoden, bei denen aus vorhandenen Mengen von Geoobjekten neue Geoobjekte gebildet werden (z.B. analytische Flächenverschnei-dung2). Die vom OGC spezifizierte Sprache „Filter Encoding“ für die Selektion von Geoobjekten ist in Ihrer Ausdrucksmächtigkeit verglichen beispielsweise mit SQL be-schränkt.Prinzip des Lösungsansatzes „Interoperabilität mittels OGC Web Services“ ist es, kom-plexe interne Strukturen von Systemen vor dem Anwender zu verbergen, indem ein Zugriff auf die Systeme mittels der relativ einfach gehaltenen standardisierten Zugriffs-schnittstellen ermöglicht wird (vgl. 2.3). Dies ist einerseits ein Vorteil, da der Zugriff auf Geodaten vereinfacht wird. Andererseits verbergen OGC Web Services so auch das konzeptionelle Modell, das hinter den Geodaten steckt, obwohl diese Informationen in bestimmten Fällen nötig wäre, um Daten weiterverarbeiten zu können, die von einem OGC Web Service geliefert werden. So muss zum Beispiel für komplexere Analysen die Struktur der einzelnen Geoobjekte und deren Beziehungen untereinander ebenso be-kannt sein, wie die Semantik der Daten – Informationen, die aus einer eindeutigen Be-schreibung des konzeptionellen Modells abgeleitet werden könnten.

4 Fazit und Ausblick Als Folge der aktuellen Möglichkeiten und Grenzen von OGC Web Services ergeben sich folgende bevorzugte Einsatzbereiche:

OGC Web Services eignen sich für das Erstellen von Auskunftslösungen im stati-onären und mobilen Internet,OGC Web Services sind immer dann zu bevorzugen, wenn Geodatenhaltung und GIS-Kenntnisse beim Anwender nicht vorhanden sind,Hohe Anforderungen an Datenaktualität gestellt werden, Ad hoc Datenkombination, d.h. schnelle Zusammenführung von Informationen aus unterschiedlichen Quellen, beispielsweise im Krisen- oder Katastrophenfall benötigt wird.

Die beiden eingangs erwähnten Lösungsansatze zur Nutzung verteilter, heterogener Geodaten, OGC Web Services und Modellbasierter Datentransfer, sind Forschungs-schwerpunkte in der Geoinformatik an der TU München (Interoperabilität mittels OGC Web Services) und an der ETH Zürich (Modellbasierter Datentransfer). Beide Hochschu-len betreuen aktuell in Kooperation mit dem Bundesamt für Landestopographie, Swisstopo und dem Landesvermessungsamt Baden – Württemberg ein Projekt zum Thema: Aufbau eines grenzüberschreitenden GIS in der Bodenseeregion Baden-Württemberg – Schweiz auf der Basis internationaler Standards. Anhand des Anwen-dungsbeispiel grenzüberschreitende Regionalplanung wird deutlich, wie groß der Be-darf an der einfachen und schnellen Nutzung der Daten auch ‚jenseits der Grenze’ ist.

2 Die TU München hat einen „Web Spatial Analysis Service“ genannten Dienst in den Standardi-sierungsprozess des OGC eingebracht, der dazu beitragen soll, diese Lücke zu schließen (vgl. DONAUBAUER 2004a).



Die beiden oben genannten Lösungsansätze sollen dabei auf Vorteile und Grenzen hin untersucht werden. Darüber hinaus soll geklärt werden, wie eine Kombination der bei-den Ansätze funktionieren könnte. Durch eine Verknüpfung dieser beiden Technolo-gien würde eine, in dieser Ausprägung wohl erstmalige, neue Art von Web Service entstehen, der die vorhandenen Einschränkungen bisheriger OGC Web Services in Bezug auf modellbasierten Datentransfer aufheben würde. Auf Seiten von INTERLIS läge der Mehrwert eines solchen Konzeptes in der Integration der OGC Web Service Technologie.Der Nutzen den man sich von einer Kombination der beiden Ansätze verspricht, ist zum einen eine umfassende Erweiterung an Funktionalitäten, die effizientere Arbeitsab-läufe ermöglichen, zum anderen lassen sich (intelligente, erweiterte) Web Services gut in Portallösungen integrieren. Portallösungen wiederum bieten den Vorteil, dass damit leichter nach geeigneten Web Services gesucht werden kann und diese einfacher zu-gänglich gemacht werden. Die angedachte Kombination verspricht darüber hinaus ei-nen relevanten Beitrag zu regionalen, nationalen und internationalen Geodateninfra-strukturen zu leisten. Die Nachfrage nach Geodaten kann somit schnell und auf einfache Weise bedient werden, neue Nutzergruppen für vorhandene Geodaten können so ge-wonnen werden.

5 Literatur Annen, A.: Geostandards: OpenGeospatial Consortium OGC (GML, WFS, WMS). Vor-trag im Rahmen von Interoperabilität für die breite Nutzung von Geoinformation, Zürich, 2005. Donaubauer, A.: Interoperable Nutzung verteilter Geodatenbanken mittels standardisier-ter Geo Web Services, Dissertation an der TU München, 2004, Internet: http://tumb1.biblio.tu-muenchen.de/publ/diss/bv/2004/donaubauer.htmlDonaubauer, A.; Fischer, F.; Huber, A.; Müller, S.; Plabst, S.; Straub, F.: Leitungs-auskunft aus verteilten GIS. Projektbericht des Runder Tisch GIS e.V., München, 2004. Internet: http://www.rundertischgis.de Gnägi, H. R.; Plabst, S.: Modellbasierter Datenaustausch und Geo Web Services im In-ternet. In: Schilcher, M. (Hrsg.). Tagungsband zum 9. Münchner Fortbildungsse-minar Geoinformationssysteme, München, 2004. Kopperschmidt, W.: Unternehmensprozesse optimieren durch Web-Services am Beispiel digitaler Planauskunft. In: Schilcher, M. (Hrsg.). Tagungsband zum 9. Münchner Fortbildungsseminar Geoinformationssysteme, München, 2004. Kunkel, T.; Teege, G.; Seuß, R.: Projektbericht zu den Stufen IA und IB des Projektes „Interoperabilität auf der Basis von OpenGIS Web Services – Länderübergreifende Daten-nutzung bei verteilten Geodatenbanken und unterschiedlichen Herstellersystemen für das Anwendungsbeispiel Real Estate“. Runder Tisch GIS e.V., München, 2003. Shi, W.: Zum modellbasierten Austausch von Geodaten auf Basis XML. Dissertation an der Universität der Bundeswehr München, München, 2004 Schilcher, M. et al.: OGC Web Services zur interoperablen Nutzung verteilter Geodaten-banken für die Immobilienwirtschaft. In: Bernard, L., Fitzke, J. und R. Wagner (Hrsg.): Geodateninfrastrukturen. Grundlagen und Anwendungen. Heidelberg, 2004. Schilcher, M.; Aumann, G. et al.: Abschlussbericht Forschungsprojekt GeoPortal. Mün-chen, 2004. Willkomm, Ph: Interoperabilität auf der Basis von OpenGIS Web-Services Bericht aus Forschung und Praxis. In: Schilcher, M. (Hrsg.). Tagungsband zum 9. Münchner Fortbildungsseminar Geoinformationssysteme, München, 2004.

7

ISO-Standards für den Datentransfer

Stand der Realisierungen / Werkzeuge

Claude Eisenhut, Eisenhut Informatik AG

Claude Eisenhut Eisenhut Informatik AG Rosenweg 14 CH-3303 Jegenstorf


+41 31 762 06 62 +41 31 762 06 64


1 Theorie

1.1 Was für eine Interoperabilität? Interoperabilität ist die Zusammenarbeit von Anwendungen in einem offenen System. Unabhängig von der verwendeten Hardware, den eingesetzten Betriebssystemen, der verwendeten Netzwerktechnologie und der Realisierung einer Anwendung kann eine Zusammenarbeit mit anderen Anwendungen erfolgen. Dazu ist in der Regel die Einhal-tung gemeinsamer Standards notwendig, aber ohne dass dazu gesonderte Absprachen zwischen den Anwendungen notwendig sind. In einem Integrationsprojekt gibt es normalerweise einen Auftraggeber und (innerhalb des Projektes) eine definierte Anzahl Anwendungen die zusammenarbeiten sollen. Trifft man innerhalb des Projektes über den Standard hinausgehende Absprachen, hat das auf die Zusammenarbeit keine negativen Auswirkungen. Die durch die Absprache betrof-fenen Anwendungen sind bekannt und im Einflussbereich des Projektes. Beim Aufbau einer Daten-Infrastruktur sind die Anwendungen, die zusammenarbeiten sollen, nicht bekannt und/oder ändern sich laufend. Eine über den Standard hinausge-hende Absprache ist darum unmöglich! Funktionierende, „ausführbare“ Standards, die keine zusätzlichen Absprachen erfor-dern, sind darum für Interoperabilität, wie sie eine Daten-Infrastruktur benötigt, eine zwingende Voraussetzung!

Stand der Technik, Implementierungen IISO-Standards für den Datentransfer: Stand der Realisierungen / Werkzeuge


1.2 Welche ISO-Normen? Norm Titel Stand Beschreibung OMGUML

Unified Modeling Language

Diverse Versionen. 191xxx basiert auf UML 1.3

Kästchendiagramme

ISO 19103 Conceptual schema language

DTS Einschränkung von UML + Basisdatentypen wie Text, Zahl, usw.

ISO 19109 Rules for applicationschema

DIS Metamodell (=Modellierungssprache). Überflüssig, da UML+19103 die Modellierungssprache definiert!

ISO 19107 Spatial schema IS Geometrie-Datentypen (inkl. Topologie)

ISO 19108 Temporal schema IS Zeit-Datentypen (inkl. Topologie) ISO 19111 Spatial referencing by

coordinatesIS Datenmodell für

Koordinatenreferenzsysteme ISO 19112 Spatial referencing by

geographic identifiers IS Datenmodell für geographische

Namen ISO 19123 Schema for coverage

geometry and functions DIS Coverage-Datentypen

ISO 19115 Metadata IS Datenmodell für Metadaten ISO 19118 Encoding DIS Definiert, wie man

Kodierungsregeln für den Datenaustausch definiert. Muss für Interoperabilität zuerst konkret definiert werden!

W3CXML

XML 1.0 (selten 1.1) Flexibles Textformat

W3CXML-Schema

XML-Schema 1.0 Beschreibungssprache für XML-Dateien

ISO 19136 Geography Markup Language

CD (GML 3.2) Gemeinsame Spezifikation von OGC und ISO für den Datentransfer.

WD: Working draft ; CD: Committee draft; DIS/DTS: Draft International Standard/Draft ; Technical Specification ; FDIS: Final Draft International Standard ; IS: International Standard

Stand der Technik, Implementierungen I ISO-Standards für den Datentransfer: Stand der Realisierungen / Werkzeuge


GML (19136, XML, XML-Schema)

Modellierungssprache

(UML+19103(19109))

VordefinierteDatentypen und

Modelle(19107, 19108,19111, 19112,19115, 19123)

Kodierung(19118)

Applikationsmodell inUML (z.B. Amtl.Vermessung)

KonkretesTransferformat

Kodierungsregeln(müssen definiert

werden!)

Zusammenhang zwischen den einzelnen ISO-Standards

Anwendung der ISO-Standards ohne GML Man modelliert mit Hilfe von UML sein Datenmodell, berücksichtigt dabei die Ein-schränkungen von 19103 und verwendet die durch 19103, 19107 etc. definierten Basisty-pen. Zusätzlich definiert man allgemeine Kodierungsregeln, z.B. wie ein Objekt und dessen Attributwerte kodiert werden. Dann wendet man die selbst definierten Kodie-rungsregeln auf das eigene Datenmodell an, um so das konkrete Transferformat zu er-halten.Ohne ISO 19136 (GML) müssen für ein konkretes Transferformat zusätzliche Abspra-chen gemacht werden!

Anwendung der ISO-Standards mit GML Man modelliert mit Hilfe von UML sein Datenmodell, berücksichtigt dabei die Ein-schränkungen von GML (beinhaltet auch diejenigen von 19103), und verwendet die durch GML (beinhaltet 19103, 19107, etc.) definierten Basistypen. Dann wendet man die durch GML definierten Kodierungsregeln auf das eigene Datenmodell an, um so das konkrete Transferformat zu erhalten. Das Resultat ist ein XML-Schema das den Regeln von GML entspricht. Für ein konkretes Transferformat sind keine zusätzlichen Abspra-chen erforderlich.



1.3 Verschiedene ModellierungsansätzeMit dem Aufkommen von GML treffen die folgenden zwei Ansichten aufeinander:

UML-Modell als Visualisierungsmittel; GML-Schema als Norm UML-Modell als Norm; GML-Schema als Transferformat

UML-Modell als Visualisierungsmittel; GML-Schema als Norm Gemäss diesem Ansatz, ist das GML-Schema massgebend und das UML-Modell dient nur zur Visualisierung der Datenstruktur und evtl. zur Entwicklung des GML-Schemas. Vorteile dieses Ansatzes:

Es ist keine Übersetzung des UML-Modells erforderlich, das Schema beschreibt direkt das Transferformat. Der Software-Entwickler muss vor allem das Trans-ferformat während der Realisierung in Gedanken präsent haben.

Nachteile:Die Inhaltsstruktur lässt sich nicht von Formattricks unterscheiden. Ein anderes Transferformat (für dieselben Daten) lässt sich nicht ohne weiteres herleiten.Die in 19136 (Anhang F) definierten Abbildungsregeln von GML nach UML de-cken nicht alle möglichen GML-Schemas ab.

UML-Modell als Norm; GML-Schema als Transferformat Gemäss diesem Ansatz ist das UML-Modell massgebend, und das automatisch hergelei-tete GML-Schema dient nur zum Datentransfer. Vorteil dieses Ansatzes:

Es lassen sich auch andere Transferformate herleiten. Das UML-Modell beschreibt nur die Inhaltsstruktur, Formattricks fliessen durch die Kodierungsregeln ein.

Nachteile:Bestimmte Möglichkeiten von GML lassen sich nicht ausnützen, da die entspre-chenden Abbildungsregeln von UML nach GML in 19136 (Anhang E) fehlen. Für das konkrete Transferformat ist eine Übersetzung des UML-Modells not-wendig. Für den Anwender ist das nur ein Knopfdruck, der Software-Entwickler muss aber das UML-Modell, das Transferformat und die Übersetzungsregeln während der Realisierung in Gedanken präsent haben.

1.4 Beurteilungskriterien Bei der Auswahl eines Datentransferstandards, sind die folgenden Kriterien zu berück-sichtigen. Je nach Kontext wird man den einen oder anderen Faktor höher gewichten.

Wie sichert man die Daten gegen Verlust wegen heute noch unbekannten techni-schen Entwicklungen? Wie sichert man die Daten gegen Verlust wegen Personalwechsel? Welche Auswirkungen haben Modelländerungen? Genügt ein einziges Transferformat oder werden für dieselben Daten verschie-dene Transferformate benötigt? Wie prüft der Nutzer, dass er erhalten hat, was er bestellt hat?

Stand der Technik, Implementierungen I ISO-Standards für den Datentransfer: Stand der Realisierungen / Werkzeuge


Wie beweist der Produzent, dass er geliefert hat, was er versprochen hat? Wie wird die Handhabung der Daten beim Nutzer vereinfacht? Wie wird die Handhabung der Daten beim Produzenten vereinfacht? Wie wird die Handhabung der Daten beim Daten-Pool/Portal vereinfacht? Wie wird das Auslagern von Dienstleistungen rund um die Daten vereinfacht? Wie einfach ist die Software-Entwicklung? Funktionieren diese Standards mit grossen Datenmengen? Wie wird Mehrsprachigkeit unterstützt? Wie werden föderale Organisationsstrukturen unterstützt? Sind diese Standards beeinflussbar? Welche Anwender und Datennutzer brauchen diese Standards sonst noch? Gibt es hier genügend Spezialisten? Wie ist die Unterstützung durch Standard-Software?

2 Praxis/SW-Demo Modellieren mit diversen Werkzeugen FormatbeschreibungWie sehen die Daten aus? DatenprüfungKonvertierungswerkzeuge Sind die Modellierungskonzepte in den GIS vorhanden? Werkzeuge für die Softwareentwicklung

3 Beurteilung Die ISO-Normen sind lesbar. Es ist aber aufwendig, einerseits wegen dem Umfang der einzelnen Normen, andererseits weil sich die relevanten Konzepte über mehrere Nor-men verteilen. Mit entsprechendem Aufwand sind die ISO-Normen realisierbar. Der Aufwand ergibt sich dadurch, dass das jeweilige Thema, z.B. geometrische Datentypen, sehr umfassend definiert wird. Für Interoperabilität sind die ISO-Normen nur beschränkt tauglich. Es gibt zu viele Wi-dersprüche zwischen den einzelnen Normen und zu oft werden abstrakte Ideen defi-niert, die sich nicht direkt realisieren lassen. Im Bereich des Datentransfers ist die Norm 19136 (GML) ein erster nützlicher Schritt.

Verbesserungsvorschlag Statt seit drei Jahren im Projekt 19139 ein Transferformat für Metadaten zu entwickeln, sollte das TC211 die Kodierungsregeln von 19136 (GML) auf das Metadatenmodell (19115) anwenden. So hätte man direkt innerhalb des TC211 eine Rückmeldung zur Rea-lisierbarkeit.



4 Ausblick Der Kosten/Leistungsdruck bleibt auch in Zukunft bestehen! Innovative Unternehmen suchen darum nach neuen Einteilungen der Prozessketten. Interoperabilität reduziert die Schnittstellenkosten und ermöglich somit neue Einteilun-gen.

Datentransfer ist out! Die Zukunft gehört den (Web-)Diensten! (Web-)Dienste sind nicht für menschliche Benutzer gedacht sondern für Anwendungen, die automatisiert Daten austauschen und/oder Funktionen auf entfernten Rechnern aufrufen.Ohne funktionierenden Datentransfer geht bei Diensten aber gar nichts. Jeder Funktionsaufruf selbst ist implizit ein Datentransfer. Der Funktionsname und die aktuellen Funktionsargumente müssen von einem Rechner zum anderen transferiert werden und das Resultat muss wieder zurück.

Braucht es noch INTERLIS? Das INTERLIS-Transferformat bietet einige Möglichkeiten (inkrementellen Transfer, mehrsprachige Tags), die GML nicht bietet. Benötigt man diese nicht, kann man ohne weiteres GML für den Transfer einsetzen. Das Basis-Schema des INTERLIS-Transferformats ist jedoch wesentlich kleiner, und darum einfacher zu realisieren. Die Möglichkeiten zur automatischen Datenprüfung sind mit UML/GML (gem. 19136) verglichen mit INTERLIS armselig. Die Datenbeschreibungsmöglichkeiten sind mit IN-TERLIS substanziell besser, auf INTERLIS als Beschreibungssprache zu verzichten, wäre darum ein Rückschritt.

8

Interoperabilität von Geodaten

Aktueller Stand und Zukunftsperspektiven im Kanton Waadt

Marc Gilgen, État de VaudService de l’information sur le territoire

In Zusammenarbeit mit Sandrine Durler, État de Vaud

Lucien Imhof, État de Vaud Bruno Magoni, ASIT-VD

Marc Gilgen État de Vaud Département des infrastructures Service de l’information sur le territoire Av. de l’Université 3 CH-1014 Lausanne http://www.dinf.vd.ch/sit


+41 21 316 34 83 +41 21 316 24 84


1 Einleitung Seit mehr als 10 Jahren hat der Kanton Waadt an der Interoperabilität im Bereich der Geodaten gearbeitet. Die Vereinigung für das Landinformationssystem des Kantons Waadt (ASIT-VD1), mit ihrem Auftrag einer Plattform für den Datenaustausch, hat früh-zeitig eine Metadatenbank mit einem Katalogisierungsdienst (dem so genannten Géoca-talogue) und einem Online-Bestelldienst aufgebaut. Gleichzeitig hat die kantonale Ver-waltung, wichtiges Mitglied der ASIT-VD, die notwendigen Mittel für ein Geoinforma-tionssystem innerhalb der kantonalen Verwaltung2 aufgebracht. Diese Infrastruktur und Organisation haben den Datenaustausch gefördert und weiterentwickelt. Gleichzeitig sind auch Interoperabilitäten zwischen Informatik-Applikationen entstanden. Dank des Geoportals der ASIT-VD ist der Kanton Waadt zur Zeit der Hauptlieferant raumbezogener Daten. Er profitiert von den Diensten der ASIT-VD im Bereich der Kata-logisierung und der Bestellung und er nutzt sie häufig. Eine Voraussetzung dazu ist ei-ne zweckmässige technische und organisatorische Infrastruktur innerhalb der kantona-len Verwaltung. Aus dem technischen Standpunkt funktioniert das Informationssystem des Kantons hauptsächlich durch das Prinzip des Datenpools (Datawarehouse), beste-hend aus den spezifischen Datenbanken der verschiedenen Abteilungen. Dieser zentrale Datenpool ermöglicht es, viele GIS-Applikationen innerhalb des Kantons anzubieten und Interoperabilitäten im Bereich der Geodaten zu entwickeln.

2 Aktueller Stand der Realisierungen

2.1 Interoperabilitäten im Bereich der Geodaten Die von der kantonalen Verwaltung und von der ASIT-VD bearbeiteten Interoperabili-täten im Bereich der Geodaten können einfach aus einem URL-Link aber auch aus viel komplexeren Realisierungen bestehen. Untenstehend kommen wir auf die folgenden Interoperabilitäten einzeln zu sprechen : Abfrage von Geodaten in administrativen Applikationen

Abfrage von geographischen Ebenen für Baubewilligungen

Kartendienst für Internet-Applikationen

Online-Bestellung von Geodaten (geographische Objekte auswählen und extra-hieren)

Abfrage von administrativen Daten in GIS-Applikationen Abfrage von entfernten Datenbanken

Zugang zu den Metadaten

Verbindung mit dem Geographischen Datenkatalog der Schweiz

1 http://www.asit.vd.ch2 http://www.dinf.vd.ch/sit

Stand der Technik, Implementierungen II Interoperabilität von Geodaten : aktueller Stand und Zukunftsperspektiven im Kanton Waadt


2.2 Abfrage von geographischen Ebenen für Baubewilligungen Die kantonale Abteilung, die die Baubewilligungen erteilt (Baubewilligungzentrale3)verfügt über eine Internet-Applikation, die es ermöglicht, verschiedene geographische Ebenen in der zentralen Datenbank abzufragen. Die Baubewilligung wird unter Berück-sichtigung mehrerer Kriterien erteilt. Die geometrische Dimension in Verbindung mit der geographischen Lage des zukünftigen Baus spielt in vielen von diesen Kriterien eine wichtige Rolle. Zudem wird die vom Bau beeinflusste Ausdehnung in der Webapplika-tion erfasst, um das Ausmass des zukünftigen Baus möglichst gut zu berücksichtigen. Die räumliche Abfrage wird auf der Grundlage eines geometrischen Schnitts zwischen dem zum Ausmass des zukünftigen Baus proportionalen Kreis und den geographischen Ebenen durchgeführt. Die Resultate werden dann der Internet-Applikation zurückge-schickt. Diese Interoperabilität ermöglicht verschiedene Verifikationen, die ohne einen solchen automatischen Prozess sehr mühevoll wären. Eine der Verifikationen betrifft den Namen der Gemeinde. Dieser wird nämlich wie die geographischen Koordinaten des Baugesuchs manuell eingegeben. Dank der räumli-chen Abfrage wird geprüft, ob die geographische Lage des Baugesuches innerhalb des Umkreises der Gemeinde liegt. Die Mehrheit der abgefragten Ebenen werden im Datawarehouse gespeichert. Einige sind in Dateien gespeichert. Durch diesen Mechanismus können wir die Verträglichkeit des Baus mit verschiedenen rechtskräftigen mit der Raumplanung verbundenen Ein-schränkungen prüfen, insbesondere mit der Bodennutzung, dem Grundwasserschutz, den Kantons- und Bundesinventaren, den Schutzmassnahmen für die Gebäude (für ein schon bestehendes Gebäude). Bei einem Interessenskonflikt zwischen einem Baugesuch und einer Zone eines Inventars beispielsweise, wird der Mechanismus die Abteilungen erwähnen, die befragt werden müssen, um eine Baubewilligung zu erteilen. Dieser au-tomatisierte Prozess ermöglicht einer « nicht-geographischen » Applikation einen geo-graphischen Server abzufragen.

2.3 Interoperabilitäten des kartografischen Internet-Schalters Dank des kartografischen Internet-Schalters des Kantons Waadt (GéoPlaNet4) können die von der kantonalen Verwaltung hergestellten und benutzten Geodaten auf dem In-ternet veröffentlicht werden. Dieser Internet-Schalter profitiert auch von der Integration der Geodaten in einem einzigen Datenpool. Es gibt ausserdem viele Schnittstellen (uni- oder bidirektional) mit anderen Applikationen. Zum Beispiel können wir folgende er-wähnen : Schnittstellen mit dem Grundbuch5 (Grundbuchauszüge), mit der Baubewilli-gungszentrale6 (Visualisierung der Akten), oder auch mit der wirtschaftlichen Förde-rung7 (Suche nach verfügbarem Gelände). Die wichtigsten Interoperabilitäten, die mit dem kartografischen Internet-Schalter ver-bunden sind, werden nachfolgend beschrieben. Diese Interoperabilitäten zeigen schon das Prinzip, das Interesse und das Potential eines universellen Portals, das die Dienst-leistungen des Kantons durch ein einziges Portal anbietet.

3 http://www.camac.vd.ch4 http://www.geoplanet.vd.ch5 http://www.rf.vd.ch6 http://www.camac.vd.ch7 http://www.terrains.vd.ch



2.3.1 Kartendienst für Internet-Applikationen Für die administrativen Applikationen des Kantons ist die Interoperabilität hauptsäch-lich beim Kartendienst von Interesse. Dieser von GéoPlaNet geleistete Dienst ermöglicht Karten in eine andere Applikation dynamisch zu integrieren (einfacher Kartendienst) oder zur Benutzungsoberfläche des kartografischen Internet-Schalters zu kommen (Browserkartendienst). Die Lokalisierung wird mit Hilfe von Koordinaten oder mit Hil-fe eines räumlichen Objekts (z.B. eine Parzelle in einer Gemeinde) gemacht. Die Parame-ter der Lokalisierung, des Massstabes und des Grösse der Karte, sowohl die Auswahl der Datenebenen werden über die URL-Adresse übermittelt. Die Applikationen des Grundbuchs, der Baubewilligungszentrale und der Wirtschaftsförderung benutzen die-se Kartendienste.

2.3.2 Abfrage von entfernten Datenbanken Umgekehrt ermöglicht der kartografische Internet-Schalter Informationen in entfernten Datenbanken zu finden. Zum Beispiel derjenigen des Grundbuchs: mit GéoPlaNet kann der Name des Besitzers einer Liegenschaft angezeigt werden. Diese Information wird bald mit anderen Informationen aus dem Grundbuchauszug ergänzt werden (Beschrei-bung des Grundstückes, Eigentum, Grunddienstbarkeiten, usw.). Das zeigt den Vorteil und die Rolle des kartografischen Internetschalters, um nicht-geografische Informatio-nen zu erwerben. Dieser Zugang zur Information durch die geografische Dimension und durch einen einzigen Eingangspunkt ist ein grosser Gewinn für den Benutzer.

2.3.3 Zugang zu den Metadaten Was die Metadaten betrifft, bietet der kartografische Internet-Schalter einen direkten Zugang zum Géocatalogue der ASIT-VD8 an, in dem alle Geodaten beschrieben werden. Es handelt sich hier darum, dass die Koppelung der Daten mit den Metadaten innerhalb des Visualisierungsdienstes für Geodaten (GéoPlaNet) gewährleistet wird.

2.4 Online-Bestellung von Geodaten Dank des Portals Géocommande der ASIT-VD9 können Geodaten auf dem Gebiet des Kantons Waadt online bestellt werden. Der Benutzer kann seine Daten via Géocatalogue auswählen und ein Suchgebiet für die Extraktion (Text- oder räumliche Suche) definie-ren. Zusätzlich zum Visualisierungsdienst, der benutzt wird, um die Basiskarten darzu-stellen, bietet die geografische Auswahl eigentlich einen Auswahldienst durch ein Ob-jekt an. Die geografischen Objekte, die ausgewählt werden können, sind die Bezirke, die Gemeinden, die Umkreise der Katasterpläne und die Parzellen. Der Kartenserver ist derselbe wie derjenige des kartografischen Schalters (MapServer). Diese Auswahl durch ein Objekt wird durch eine Datenbank PostGIS gemacht. Sobald das Bestellungsformular ausgefüllt ist, wird es den betroffenen Lieferanten ge-schickt. Für die Geodaten des Kantons Waadt wird die Abfrage automatisch verarbeitet: die Geodaten werden vom Datawarehouse aus dem ausgewählten Umkreis herausge-zogen, dann zum Benutzer durch FTP übermittelt. Die Rechnung wird auch automa-tisch gemacht.

8 http://www.asit.vd.ch/geoportal/geocatalog/public.asp9 http://www.asit.vd.ch/geoportal/geodata/public.asp



Die Verarbeitungskette einer Online-Bestellung besteht aus vielen Interoperabilitäten zwischen mehreren Applikationen: um den Bestellungsumkreis zu definieren (Auswahl von geografischen Objekten) und um die Abfrage zu übermitteln und zu verarbeiten (Herausziehen von geografischen Objekten).

2.5 Verbindung mit dem Geographischen Datenkatalog der Schweiz Mit dem neuen Geographischen Datenkatalog der Schweiz10 arbeitet die ASIT-VD wie ein Partner vom Typus C (der Partner vom Typus A gibt seine Metadaten direkt in die zentrale Datenbank von geocat ein ; der Partner vom Typus B verfügt über seine eigene Datenbank aber kopiert seine Metadaten in die zentrale Datenbank ; der Partner vom Typus C erlaubt einen Zugang zu seiner Datenbank durch geocat ohne Duplizierung). Die ASIT-VD verfügt nämlich über seine eigene Metadatenbank, die geocat abfragen kann. Zu diesem Zweck wurde ein Abfrageprotokoll (Catalog Gateway Protocol) auf Bundesebene entwickelt und in die Applikation von der ASIT-VD eingebaut. Auf dieser Weise kann die ASIT-VD die Abfragen von geocat bekommen und verarbeiten, und dann eine Antwort zurückschicken, die der Struktur und dem Format von geocat ent-spricht. Diese Interoperabilität ist die erste konkrete Realisierung in die Richtung eines Schweizer Suchportals für Geodaten mit einem dezentralisierten Katalog. Die Interoperabilität zwischen geocat und dem Géocatalogue der ASIT-VD zeigt die Notwendigkeit, über gemeinsame Datenmodelle zu verfügen. Das Metadatenmodell GM03Core muss mindestens in jedem Metadatensystem implementiert werden. Auf der Basis von GM03Core werden die minimalen Metadaten ausgetauscht. Die ASIT-VD hat deswegen den Géocatalogue angepasst, um mit dem Schweizer Metadatenmodell GM03Core in Übereinstimmung zu sein. Alle obligatorische Metadaten von GM03Core können im Géocatalogue gefunden und dank geocat visualisiert werden. Die technischen Entwicklungen, die die Interoperabilität fördern, müssen von Bemü-hungen in anderen Bereichen begleitet werden. Hier müssen die Bemühungen erwähnt werden, um standardisierte Datenmodelle und Vorgehen für Geodatenaustausch zwi-schen den Partnern anzunehmen oder auszuarbeiten. Zu diesem Zweck arbeiten die kantonale Verwaltung und die ASIT-VD zusammen. Erste Schritte im Bereich der gene-rellen Entwässerungspläne (GEP11) sind erfolgreich gewesen. Jetzt wird etwas im Be-reich der Raumplanung unternommen, um den Austausch der Daten für die Bodennut-zung zu vereinheitlichen.

3 Perspektive

3.1 Webdienst über Raumgliederungen Demnächst wird der Kanton einen Webdienst über die Raumgliederungen aufstellen. Zuerst werden der Kanton, die Bezirke, die Gemeinden, die Katasterpläne und die Par-zellen betroffen sein. Dieser Dienst gibt die Möglichkeit, Informationen über die Einhei-ten der vorher genannten Raumgliederungen (z.B. Bundesnummer und Name der Ge-meinden) und über die Zusammensetzung und die Zugehörigkeit der Einheiten einer Raumgliederung in Beziehung mit den anderen Raumgliederungen (z.B. Nummer aller

10 http://www.geocat.ch11 http://www.dse.vd.ch/eaux/assainissement/eaux/pgee.htm und http://www.asit.vd.ch/documentation/command.asp



Parzellen und aller Katasterpläne, die einer Gemeinde gehören) in einer Standardform und im Format XML zu übermitteln. Dieser Dienst wird vor allem beim Bestellungs- und Vertriebsvorgehen der Geodaten benutzt. Dieser Webdienst ist unabhängig von jeder Applikation und er wird dennoch später für andere Bereiche benutzt werden können. Die Vorteile eines solchen Dienstes sind klar: die Aktualisierung der Datenbanken ist automatisch bei Veränderungen, wie z.B. bei den Fusionen von Gemeinden oder bei der Einführung von neuen Vermes-sungslosen. Im Vergleich brauchen die traditionellen Methoden der Aktualisierung viel Zeit, in Anbetracht der vielen Applikationen, die diese Informationen benutzen. Mit diesem Dienst wird auch die Aktualisierung der Postleitzahlen (PLZ) und der Orte in jeder betroffenen Applikationen vorgesehen. Die PLZ wechseln regelmässig und werden mehrmals im Jahr aktualisiert12.

3.2 Geschützter Kartendienst Die ASIT-VD und der Kanton entwickeln und testen jetzt einen geschützten Karten-dienst, der sich auf die OpenGIS Spezifikationen13 beruht. Im ersten Schritt wird die Spezifikation Web Map Service (WMS) implementiert, damit die Karten in Bildform ge-liefert werden. Der Zugang wird mit einem Benutzernamen und einem Passwort ge-schützt.Es gibt zwei Hauptziele:

Den Datenvertrieb mit einem direkten Zugang auf Daten durch den Standard WMS ergänzen. Die Benutzung von WMS gibt jeder Applikation, die als WMS-Klient funktioniert, die Möglichkeit, Abfragen zu schicken und die zurückge-schickten Karten direkt in die Benutzungsoberfläche des Klienten zu integrieren. Die hier betroffenen Applikationen sind besonders die GIS- und die Web-Applikationen. Folglich sind die betroffenen Benutzer Fachleute der Vermes-sung, der Umwelt, der Raumplanung (usw.) aber auch zum Beispiel die Ge-meinden. Im Bereich vom GIS bieten immer mehr Softwareprodukte – sowohl kommerzielle Produkte (z.B. MapInfo, ArcGIS) sowie "free" Programme (z.B. JUMP) – WMS-Klientfunktionalitäten. Die Zugangskontrolle ermöglicht es, die Identität des Benutzers zu erkennen und auch ein Rechnungssystem für diesen Direktzugangdienst zu definieren.

Einen zentralen kartografischen Schalterdienst (waadtländisches Portal) anbie-ten. Er wird vor allem den öffentlichen Verwaltungen angeboten unter der Be-dingung, dass der Geodatenlieferant über einen Server verfügt, der WMS-Abfragen beantworten und Bilder, die diesem Standard entsprechen, liefern kann. Der einzige kartografische Schalter, der von der ASIT-VD beherbergt und unterhalten wird, wird als WMS-Klient funktionieren und wird die Visualisie-rung von Geodaten von mehreren Lieferanten ermöglichen. Wir haben als Ziel, dass die Daten der kantonalen Verwaltung und die von den Gemeinden gegebe-nen Daten zusammen gelegt sind.

Dieser geschützte Dienst wird zuerst die Interoperabilität nur im Bereich der Geodaten ermöglichen. Dann wollen wir die Entwicklungen in Richtung Interoperabilität der

12 http://www.poste.ch/yellowbox13 http://www.opengeospatial.org



Funktionalitäten orientieren. Das heisst, dass der Zugang zu Funktionalitäten der Ap-plikation des Lieferanten durch den zentralen Schalter und auch von irgendwelchen Klienten möglich sein wird. Es ist klar, dass die Aufstellung einer solchen Interoperabili-tät nur möglich ist, wenn Funktionalitäten in Form von Webdiensten entwickelt werden. Für die kantonale Verwaltung sind diese Perspektive nicht nur technische Ziele und Herausforderungen, sondern auch strategische. Die Aufstellung von solchen Interope-rabilitäten wird nämlich den Geodatenvertrieb, ihre Tarifgestaltung, ihre Verwaltung und ihre Aktualisierung (verteilte Kosten, gemeinsame Infrastrukturen) beeinflussen.

4 Schlussfolgerungen Die Interoperabilität im Bereich der Geodaten spielt eine wichtige Rolle. Im Kanton Waadt können wir nach den realisierten Entwicklungen in diesem Bereich Folgendes bemerken:

Die Interoperabilität bietet technische Lösungen für organisatorische Probleme an (z.B. den Abfragedienst der geografischen Ebenen).

Dank der Interoperabilität wird Zeit und Geld gewonnen durch die Rationalisie-rung der Aufgaben, die mit der Erwerbung, der Verwaltung, der Aktualisierung, der Veröffentlichung und dem Vertrieb der Geodaten verbunden sind (z.B. dank eines Online-Bestellungsdienstes der Geodaten).

Die Interoperabilität unterstützt die Förderung und die Benutzung der Geodaten in Bereichen, die an Geomatik wenig oder nicht gewohnt sind (z.B. dank des Kartendienstes, der durch einen kartografischen Schalter verfügbar ist).

Die Interoperabilität erhöht die Zuverlässigkeit der Daten : wir vermeiden mehr-fache Kopien, die Aktualisierung wird schneller gemacht, das Speichersystem wird nicht mehr so viel belastet und die Bemühungen für die Verwaltung der Geodaten sind nicht mehr so gross (z.B. dank des Informationsdienstes über die Raumgliederungen).

9

Die Komplexität der Interoperabilität

Ein einfacher Praxisbericht aus der Ostschweiz

Ueli Forrer, F+P GEOINFO AG

Ueli Forrer F+P GEOINFO AG Geoinformatik und Vermessung Kasernenstrasse 69 CH-9100 Herisau http://www.geoinfo.ch


+41 71 353 53 53 +41 71 353 53 50


1 Einleitung Interoperabilität ist für uns als GIS-Dienstleistungsunternehmen ein sehr aktuelles Thema und langfristig betrachtet, wird Interoperabilität zu einer Überlebensfrage sol-cher Unternehmen werden. Wenn wir uns mit Definitionen von Interoperabilität aus-einander setzen, geraten wir direkt zur Frage der Systemabgrenzung. In unserem Sys-tem, einer regionalen Geodateninfrastruktur, können wir zur Zeit Interoperabilität in diversen Teilsystemen finden.

1.1 Definitionen zur Interoperabilität Interoperabilität wird in der Literatur unterschiedlich definiert. Wir beschränken uns in der Folge auf zwei unterschiedliche, jedoch sinngleiche Definitionen1:

1. Als Interoperabilität bezeichnet man die Fähigkeit zur Zusammenarbeit von ver-schiedenen Systemen, Techniken oder Organisationen. Dazu ist in der Regel die Einhaltung gemeinsamer Standards notwendig. Wenn zwei Systeme mitein-ander vereinbar sind, nennt man sie auch kompatibel.

2. Interoperabilität ist die Fähigkeit unabhängiger, heterogener Systeme möglichst nahtlos zusammen zu arbeiten, um Informationen auf effiziente und verwertba-re Art und Weise auszutauschen bzw. dem Benutzer zur Verfügung zu stellen, ohne dass dazu gesonderte Absprachen zwischen den Systemen notwendig sind.

1.2 Systemabgrenzung Wenn aus der ersten Definition Interoperabilität als die Fähigkeit zur Zusammenarbeit von verschiedenen Systemen, Techniken oder Organisationen bezeichnet wird, dann lässt sich daraus logischerweise ableiten, dass die Interoperabilität vor allem auch eine Frage der Systemabgrenzung ist, egal ob es sich dabei um eine technische oder organi-satorische Abgrenzung des Systems handelt.

2 Interoperabilität am Beispiel der IG GIS AG In der Ostschweiz haben sich die Kantone Appenzell A.Rh., Appenzell I.Rh. und St. Gal-len und sowie ca. 60 Gemeinden (Bezirke im Kanton AI) zu einer Interessengemein-schaft GIS, der IG GIS AG zusammengeschlossen. Das eigentliche Betreiben des GIS ist in diesen Kantonen und Gemeinden teilweise bereits seit 1997 aus der Verwaltung aus-gelagert und einem privaten Betreiber, der F+P GEOINFO AG übertragen worden. Die IG GIS AG hat einen rein koordinativen Charakter und bündelt die Interessen der Akti-onäre (Gemeinden, Bezirke und Kantone) gegenüber dem GIS-Betreiber. Die Geschäfts-führung (50% Stelle) der IG GIS AG ist dem Dienst für Informatikplanung des Kantons St. Gallen angegliedert.

2.1 Gesamtsystem Wenn wir den heutigen Stand der Architektur des Gesamtsystems betrachten, dann wird es relativ schwierig über Interoperabilität des Gesamtsystems zu berichten, weil das System sehr gross ist. Das Rechenzentrum der IG GIS AG ist zudem einerseits in das Rechenzentrum des Kantons St. Gallen (Abraxas Informatik AG) und andererseits

1 Quelle: http://de.wikipedia.org

Stand der Technik, Implementierungen II Die Komplexität der Interoperabilität: ein einfacher Praxisbericht aus der Ostschweiz


komplett in die Informatikstrukturen der anderen Kantone und Gemeinden eingebettet. Abbildung 1 zeigt die stark vereinfachte Architektur des RZ der IG GIS AG als Gesamt-system:

Abbildung 1

Auf Grund der Grösse der IG GIS AG - drei Kantone und rund sechzig Gemeinden – können wir von einer regionalen Geodateninfrastruktur (RGDI) sprechen. Suchen wir in dieser Organisation Interoperabilität, dann finden wir diese in vielen, einzelnen Teil-systemen.

Betrachten wir die „Aussenbeziehungen“ dieser Organisation, nämlich die vielen Datenlieferanten, andere RGDI’s, die künftige NGDI (Nationale Geodateninfrastruktur) oder gar eine europäische Organisation, welche eine Geodateninfrastruktur betreibt, dann denke ich ganz intuitiv an den Turmbau zu Babel. Gemäss der oben erwähnten Definition von Interoperabilität müssen nun nämlich alle diese Organisationen „Informa-tionen auf effiziente und verwertbare Art und Weise austauschen bzw. dem Benutzer zur Verfügung stellen, ohne dass dazu gesonderte Absprachen zwischen den Systemen notwendig sind.“Dazu müssten diese nicht nur hunderte von technischen Standards und Normen einhalten, sie müssten auch in ihren betriebswirtschaftlichen Abläufen und Organisationsformen

interoperabel oder kompatibel werden. Davon sind wir noch weit entfernt. Und wie beim Turmbau von Babel sind es die verschiedenen Sprachen die uns manchmal zur Verzweiflung bringen: So spricht der Ingenieur, welcher Fachdaten für eine Gemeinde

Abbildung 2



erfasst, eine andere Sprache als der Informatiker, der eine regionale Geodateninfrastruk-tur betreibt.Dieses Grundprinzip „der verschiedenen Sprachen“ in Bezug auf Interoperabilität lässt sich sehr einfach nachprüfen: Sucht man im Internet nach dem Wort „Interoperabilität“, zeigen viele Links auf Hilfsorganisationen. Auch dort treffen verschiedenste Organisati-onen, Sprachen, Techniken und Kulturen aufeinander. Im Folgenden ziehe ich die Systemgrenzen enger und fokussiere auf das Gesamtsystem IG GIS. Zwecks besserer Übersicht teile ich das Gesamtsystem in drei Teile auf:

DatenApplikationslogik Präsentation der Daten

Weitere Teilsysteme wären noch: Systemplattformen Betriebssysteme NetzwerkeWeitere Organisationsprozesse

2.2 Teilsystem „Daten“

2.2.1 Stand Heute Betrachten wir das Teilsystem „Daten“, dann stechen in dieser Lösung die heterogenen Strukturen der Ostschweiz sofort ins Auge. Kleinere Gemeinden (mit bis ca. 4500 Ein-wohner) mit bis zu 17 verschiedenen, eigen-ständigen Korporationen sind keine Seltenheit. Dabei ist natürlich jede Korporation ihr eigener Datenherr und bestimmt autonom, wer auf ihre Daten Zugriff hat. Heute liefern 64 verschiedene Datenlieferanten, 178 Datenthemen (ein Thema ist z.B. die amtliche Vermessung (AV), der Leitungskataster Abwasser, usw.), in 609 Arten von Datensätzen (eine Datensatzart ist dabei z.B. die Ebene Liegenschaften in der AV), und 15 verschiedenen Datenformaten an. Davon sind gerade einmal 9 Datensätze in IN-TERLIS I beschrieben und durch die Kantone2, den SIA3 oder andere Fachverbände normiert. Nur die Daten welche in INTERLIS I angeliefert werden, sind interoperabel. Wenn wir die 609 Arten von Datensätzen auf die geografischen Gebiete, also z.B. die einzelnen Gemeinden (AV-Liegenschaften der Gemeinde X, AV-Liegenschaften der Gemeinde Y, usw.) aufteilen, dann sind es 10'606 einzelne Datensätze. Wir betreiben und organisieren also eine ganze Menge Schnittstellen und wenden viel Zeit für Quali-tätskontrollen auf. Und - es funktioniert sehr gut!

2 Im Kanton SG die Geodatenkonferenz und im Kanton AR der GIS-Ausschuss AR 3 Schweizerischer Ingenieur- und Architektenverein

Abbildung 3



Im RZ der IG GIS halten wir sehr viele Daten auf einem RDMS4. Das sind Benutzerda-ten, Benutzerrechte, Sichtendefinitionen usw. welche allerdings eher der Applikations-logik zugehören, ein klarer Trennungsstrich ist hier nicht möglich. Die grafischen Datenliegen immer noch in einem proprietären Format. Dies ist bei unseren grossen Daten-mengen – leider – immer noch eine Frage der Systemperformance. Innerhalb des RZ des Kantons St. Gallen und über das Intranet der Kantone AR und AI, haben wir unterschiedliche Direktzugriffe in die Datenbestände anderer RDBMS rea-lisiert. Gesamthaft sind heute 22 weitere Datenbanken (Fremddatenbanken) direkt an die Daten der IG GIS angebunden. Das heisst, dass der Nutzer direkt über sein GIS auf diese Datenbanken zugreift. Diese Einbettung in die vorhandenen IT-Strukturen zeugt wiederum von Interoperabilität.Zu dieser Auslegeordnung im Teilsystem Daten gehören zudem weitere, sehr wesentli-che Aspekte: Die Darstellung der Daten, die dazu gehörenden Legenden, die rechtlichen Hinweiseund der Aktualitätsstand spielen bei den Nutzern eine nicht zu unterschätzende Rolle. Wir führen über alle Datenbestände umfassende Metadaten, welche auf dem RDBMS abgelegt und bereits heute in einer Form vorhanden sind, die einen interoperablen Aus-tausch mit Fremdsystemen zulässt.

2.2.2 Aussichten In der Datennormierung warten wir auf Standards der verschiedensten inter-nationalen, nationalen und regionalen Gremien. Im Teilsystem Daten sehen wir für die Zukunft eine zentrale Datenverwaltung auf der Basis eines Geodatenservers mit einer RDBMS. Unsere Versuche, mit verschiedenen Applikationen auf einen Geodatenserver zuzugreifen, zeigen, dass bereits die Interpre-tationen simpler geometrischer Datentypen Fragen aufwerfen. Erschwerend kommt die produkteabhängige Darstellung der Daten dazu. Beim Datenaustausch und der Darstellung der Daten setzen wir auf INTERLIS II, wo-bei die Marktakzeptanz bei unseren Datenlieferanten aus heutiger Sicht teilweise doch sehr fraglich ist. In Frage kommt hier auch der internationale Standard, nämlich GML3.

4 Relationales Datenbank Managementsystem



2.3 Teilsystem „Applikationslogik“

2.3.1 Stand Heute Wir betreiben einerseits verwaltungsintern Applikationen auf der Basis eines Desktop-GIS und verschiedene Web-Applikationen im Intranet, andererseits öffentlich im Inter-net verschiedene Produkte wie z.B. das www.geoportal.ch. Der umfassende Teil unserer

Applikationslogik liegt immer noch in den einzelnen Applika-tionen, ein kleiner Teil auf dem RDBMS. In diesem Punkt ist Interoperabilität nicht gegeben.

Wie im Teilsystem Daten bereits erwähnt, sehen wir im Bereich der Applikationslogik folgende wesentlichen und erwähnenswerten Punkte:

Wir betreiben eine sehr umfassende Benutzerverwaltung mit entsprechenden Ver-tragsregelungen und Zugriffsrechten. 907 registrierte Benutzer in 128 Benutzer-gruppen greifen verwaltungsintern geordnet auf unsere Datenbestände. Wir legen unsere umfassende Datenbestände in Strukturen ab, dabei wenden wir folgende Ordnung an:

KategorienBereiche

ThemenDatensätze

Um den Nutzern die Arbeit zu erleichtern, stellen wir ihnen Daten in den ge-wohnten Karten zur Verfügung. Karten sind dabei vordefinierte Kombinationen von Datensätzen oder definierte Sichten.Wir haben zunehmend Datensätze, welche auch über ein Regelwerk definiert sind (z.B. Gewässernetze inkl. Kilometrierungen und Routenbildungen, Flächentopo-logien usw.).

2.3.2 Aussichten In Bezug auf Interoperabilität innerhalb der Applikationslogik ist die Entwicklung aus der Informatik bereits vorgezeichnet: .net, COM, GML/XML usw. werden die künftigen Applikationen interoperabler gestalten. In Bezug auf die Daten-Zugriffsrechte ist eine echte Interoperabilität vermutlich sehr fraglich und nicht sinnvoll. Datenstrukturen (in der Form der oben erwähnten Gliederungen), vordefinierte Daten-Sichten usw. sind heute bereits in einem RDBMS abgelegt und sind im technischen Sin-ne bereits interoperabel. Mit INTERLIS II können wir künftig die Definition von Regeln zu den Daten interope-rabel beschreiben. Die Regelwerke selber sind möglichst mit den Daten in einem RDBMS abzulegen.

Abbildung 4



2.4 Teilsystem „Präsentation“

2.4.1 Stand Heute Im Teilsystem Präsentation sind verschiedenste Standards und Normierungen schon vorhanden. Z.B. verteilen wir verwaltungsintern in den Geoportalen für Betrachter (6000 bis 7500 Arbeitssitzungen pro Monat) und öffentlich im Internet (10’000 bis 14’000 Arbeitssitzungen pro Monat) über http schon heute Daten auf verschiedenste Betriebssysteme. Ebenso leben wir beim Betrieb der Geoportale für Anwender (230 re-gistrierte Benutzer) über die Metaframe/Citrix-Umgebung eine spezielle Art von Inte-roperabilität über die Betriebsystemgrenzen hinweg.

Abbildung 5

Mit der heute verfügbaren Technik, insbesondere von WMS5 und WFS6, wäre eine wei-tere Interoperabilität (auch aus den proprietären Daten heraus) bereits möglich, wird aber wegen der Zugriffsrechte noch nicht angewendet. Die Anwendung von WMS ist deshalb zur Zeit nur für die öffentlichen Daten im Internet sinnvoll.

2.4.2 Aussichten In diesem Teilsystem sehen wir die künftige Anwendung von diversen Web Servicen als sinnvolle Möglichkeit für die frei verfügbaren Daten im Internet:

WMS (Web Map Service) WFS (Web Feature Service) WCS (Web Coverage Service) WCAS (Web Catalog Service) WCTS (Web Coordinate Transformation Service) Weitere Web Services

Zur Zeit steht für unsere Anwendungen sicherlich der WMS (Web Map Service) im Vordergrund, da „fremde“ Institutionen Daten betrachten und drucken aber nicht in Vektorform beziehen können. Jedenfalls wäre das im Sinne vieler Datenherren, die ins-besondere im Verwaltungsumfeld die Daten zum Betrachten und Drucken freigeben.

5 Web Map Service 6 Web Feature Service



3 Fazit In einer Organisationsstruktur für regionale Geodaten, wie derjenigen der IG GIS AG sind in verschiedensten Teilbereichen Ansätze zu einer Interoperabilität vorhanden. Diese Ansätze sind heute noch sehr technisch, vielschichtig und betreffen sehr ver-schiedene, spezielle Fachbereiche aus der Informatik und der Geoinformationsbranche. Von einer echten Interoperabilität, also einer Interoperabilität von Organisationen von regionalen und nationalen Geodatenstrukturen sind wir unseres Erachtens noch weit entfernt.Je grösser wir die Systemabgrenzung ziehen, desto komplexer wird die Interoperabi-lität und umso mehr verlagert sich diese weg von Systemen und der Technik auf die Organisationen und deren Prozesse.

4 Literatur

INSPIRE. 2003. Spatial Data Infrastructure in Europe. Spatial Application Division K.U. Leuven, Research & Development

Ott, Mathias. Datenaustausch und Interoperabilität, Dienste für eine offene Geodatenstruktur,www.ikg.uni-bonn.de/Lehre/Geoinfo/is_iv_SS_04/Vorträge%5C04_05_27_Ott.ppt

Open GIS Consortium. OpenGIS Service Architecture

SOGI. 2003. Worin liegt der praktische Nutzen von Interoperabilität und Normung für den GIS-Anwender in der Schweiz?” SchweizerischeOrganisation für Geoinformation, Bericht der Fachgruppe GIS Technik

10

Modellbasierte und interoperable Bearbeitung der Basisdaten in

Wallonien

Jean-Claude Jasselette, MET Belgien

Jean-Claude Jasselette MET (D.432) Topographie et Cartographie CAMET - Boulevard du Nord, 8 B-5000 Namur


+32 817 733 51 +32 817 738 88


1 Einführung

1.1 Vorwort Jean-Claude Jasselette ist Adjunkt der Topographie- und Kartographieabteilung des Bau- und Verkehrsministeriums der Region Wallonien in Belgien. Er ist im Projekt InfraSIG involviert und hat sich insbesondere an den Arbeiten der Modellierung der topographischen Referenzdaten mit Hilfe von INTERLIS beteiligt. Das Hauptziel des Referates besteht darin, die Arbeiten vorzustellen, die im Rahmen der Einführung einer Infrastruktur für geographische Informationen in der Region Wal-lonien durchgeführt wurden. Im Referat wird versucht, die zugrunde liegenden Leitli-nien und ihre Auswirkungen im Kontext der Interoperabilität für räumliche Daten auf-zeigen.

1.2 Übersicht Nach einer kurzen Beschreibung der Situation der belgischen Kartographie wird die Problematik in ihren wallonischen regionalen Zusammenhang gestellt. Schritt für Schritt werden die verfolgten Zielsetzungen, die eingesetzten Mittel und schließlich der Stand der Arbeiten durchgegangen. Die Schlussfolgerungen werden sich auf die Vortei-le des gewählten Vorgehens, auf die aufgetretenen Probleme sowie auf das daraus Ge-lernte beziehen.

2 Kontext und Problematik

2.1 Belgien, ein junger Bundesstaat

FLANDERN13 522 km2

WALLONIEN16 844 km2BRÜSSEL

162 km2

Stand der Technik, Implementierungen II Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien


Bekanntlich setzt sich Belgien seit mehr als 20 Jahren für einen Regionalisierungsprozess ein. Für Themen wie die Kartographie ist die öffentliche Hand einerseits unterteilt in eine föderale Ebene und andererseits ein regionales Niveau, das die Region Wallonien (16.844 km2), die Region Flandern (13.522 km2) und die Region der Hauptstadt Brüssel (162 km2) umfasst.

2.2 Kartographie im Bundesstaat und in den Regionen Wie die meisten europäische Staaten verfügt Belgien über ein eigenes nationales geo-graphisches Institut (IGN). Diese föderale öffentliche Verwaltung wird mit allen Karto-graphie-, Geodäsie- und Fernerkundungsaufgaben beauftragt, die sich auf das gesamte Staatsgebiet beziehen. Das belgische IGN ist Hersteller von qualitativ sehr hochstehen-den Karten und topo-geographischen Daten in den Massstäben zwischen 1/300’000 und 1/10’000. Abgesehen davon ist auf der föderalen Ebene das Katasteramt Hersteller von Grund-stücksplänen mit sehr grossem Massstab. Momentan haben diese Pläne ausschliesslich steuerpolitische Ziele und haben meistens keine Vermessungsqualität. Ein ehrgeiziges Projekt zur Modernisierung des belgischen Katasteramtes ist in Vorbereitung. Infolge der Regionalisierung im Bereich der umweltrelevanten Kompetenzen der Raum-ordnung, der öffentlichen Arbeiten und erst kürzlich der Landwirtschaft hat die regio-nale öffentliche Hand verschiedene kartographische Projekte geschaffen. Was die Refe-renzdaten betrifft, hat jede der drei Regionen ein digitales topographisches Kartogra-phieprojekt in sehr grossem Massstab eingeführt. Es handelt sich um die Projekte Urbis in der Region der Hauptstadt Brüssel, PICC in der Region Wallonien und GRB in der Region Flandern. Diese drei Projekte entsprechen ungefähr denselben Genauigkeitskri-terien und sind vergleichbar mit einer Karte des Typs "öffentliche Arbeiten" im Maßstab von 1/1’000 oder besser. Sie werden im Allgemeinen durch numerische Orthopho-toplan-Layer vervollständigt. Mangels einer Koordinationsstelle auf föderalem oder interregionalem Niveau haben die durch die drei Regionen eingeleiteten Projekte trotz allem deutlich verschiedene technische Eigenschaften.

2.3 Kartographie in der Region Wallonien

2.3.1 Verschiedene Ansätze und Referenzen Auch innerhalb einer Region ist die Homogenität nicht immer die Regel. Auf diese Art haben in Wallonien verschiedene Hersteller von analogen und numerischen kartogra-phischen Daten verschiedene Methoden und Referenzen verwendet oder verwenden sie immer noch. Zum Beispiel ist es mangels gemeinsamer Referenz nicht selten so, dass Geometer, die für verschiedene Verwaltungen der Region Wallonien arbeiten, die ge-sammelten Vermessungsdaten nicht austauschen können.

2.3.2 Die Vielfalt numerischer Daten Seit einigen Jahren wird der Gehalt der numerischen geographischen Daten, die durch die Verwaltungen der Region Wallonien produziert wurden, allerdings anerkannt. Da-her bilden die Plans Photographiques Numériques Communaux (PPNC) einen numerischen Orthophotoplan in Farbe mit Meter-Auflösung flächendeckend für die ganze Region. Das Projet Informatique de Cartographie Continue (PICC) bietet eine numerische Kartogra-phie im Massstab 1/1’000 über eine Fläche von mehr als 8’000 km2 an, die unter ande-



rem in einer geographischen Datenbank mehr als 55% der 1'500’000 Gebäude, die die wallonische Region umfasst, enthält. Angesichts der Qualität der bestehenden Daten und der Kosten, die ihre Produktion dargestellt hat, begreift man, dass ihre Aufwertung ein wichtiger Einsatz ist, und dass nicht zu beabsichtigen ist, ein neues Projekt derselben Spannweite anzusetzen.

2.3.3 Der Zukunftsvertrag und das Vorgehen eGov Im Zeitalter der Computerisierung und Vernetzung der Datenbanken ist die Notwen-digkeit, die Aktivitäten der verschiedenen für die Erstellung von räumlichen Daten ver-antwortlichen öffentlichen Hoheitsträgern zu koordinieren, ein entscheidender Einsatz geworden.Die Regierung der Region Wallonien ist sich dieses Einsatzes bewusst. In einer der vor-rangigen Massnahmen ihres Contrat d’Avenir pour la Wallonie (CAW), Absichtserklärung der Regionalpolitik, wird festgelegt, dass die Regierung "allen Beteiligten via Internet die Gesamtheit der kartographischen Daten der Region Wallonien zur Verfügung stellt" und das, indem sie "die verschiedenen Kartographieprojekte in ein offenes, zusammen-hängendes und koordiniertes System integrieren werden, das den Informationsaus-tausch erlaubt und das sowohl Redundanz als auch Inkompatibilität verhindert."Seit 2002 präzisiert das aktualisierte CAW, dass die "regionalen kartographischen Pro-jekte der Öffentlichkeit im Rahmen des Projekts vom wallonischen e-Gouvernement ü-bers Internet zur Verfügung gestellt werden." Man sieht also, dass der Zugang zu zu-sammenhängenden geographischen Daten und die Qualität durch die wallonische öf-fentliche Hand für prioritär eingeschätzt werden.

2.3.4 Das CTC und das Projekt InfraSIG In diesem Rahmen ist das Comité Technique Cartographique (CTC) der Region Wallonien im November 2000 ins Leben gerufen worden. Das CTC setzt sich aus Vertretern des mit der Kartographie beauftragten Ministeriums und aus den verschiedenen Generaldirek-tionen der wallonischen Ministerien zusammen. Sein Hauptziel besteht darin, die Kohä-renz zwischen den verschiedenen Kartographiediensten der Region Wallonien zu ge-währleisten und damit den Zielsetzungen des aktualisierten CAW zu entsprechen. Um der Regierung die Elemente einer Verwaltungs- und Verbreitungspolitik der öffent-lichen geographischen Daten im Rahmen einer internetbasierten Infrastruktur vorschla-gen zu können, hat das CTC im Jahre 2002 ein Projekt mit der Bezeichnung InfraSIG lanciert. Dieses Projekt zielt darauf ab, eine Infrastruktur für die Verwaltung und die Verbreitung der geographischen Daten der Region Wallonien zu definieren und zu ver-wirklichen, um den Anforderungen und den Bedürfnissen aller Benutzer zu entspre-chen. Um dieses Projekt zu verwirklichen, profitiert das CTC von der technischen Hilfe eines Konsortiums, das durch die Gesellschaft GFI gesteuert wird. Das InfraSIG-Projekt entwickelt sich in vier Richtungen:

1.Eine organisatorische Achse, um das Projekt zu koordinieren, die Rolle und die Ver-antwortung der Beteiligten zu definieren, die Benutzer zu sensibilisieren und aus-zubilden und einen Führer der guten Praktiken aufzustellen.

2.Eine technische Achse, die zum Ziel hat, die Problematik zur Sprache zu bringen von der Infrastruktur der Verbreitung der Daten, der Metadaten,



vom Setzen in Kohärenz der Referenzdaten und der thematischen Daten durch den Modellbau,mit diesen Angaben assoziierte Dienste, Aktualisierungsverfahren.

3.Eine Rechtsachse, die anvisiert, einerseits ein vereinheitlichtes Lizenzmodell für die Zurverfügungstellung geo-graphischer Informationen durch die Region aufzustellen; andererseits die Auswirkung der Gesetzgebungen über den Zugang zur Infor-mation zu untersuchen.

4.Eine sozioökonomische Achse, die zum Ziel hat, die Kosten, den Markt und die An-wendungen zu analysieren, um der wallonischen Regierung die Bestandteile einer Politik für die Verbreitung der geographischen Daten vorzuschlagen.

Jede dieser Achsen entspricht einer oder mehreren Arbeitsgruppen.

Technisches Komitee Kartographie Technische Projektassistenz

GTOrganisation

GT Technik GT Recht GTPreis

Technik Recht Preis

Punktuelle Aufträge

Permanenter Auftrag

Ministerialkanzlei – “Carto”

Minister M. DAERDEN (Kartographische Angelegenheiten)

Projektleitung INFRASIG

Basisdaten

Metadaten

Organisation

versch. DG

Infrastruktur Verteilung

ThematischeDaten

Koordination



Schliesslich ist das CTC beauftragt, "die Zusammenarbeiten und die Kooperationsab-kommen mit anderen regionalen und gemeinschaftlichen (OC Gis-Vlaanderen, CIRB...), nationalen (IGN, Katasteramt...) und europäisch Instanzen (grenzüberschreitende Pro-jekte, Initiative LEITEN...) zu koordinieren."

3 Verfolgte Ziele Die wichtigsten Leitlinien, die bei der Einführung von der Infrastruktur der Verbreitung der wallonischen geographischen Informationen verfolgt werden, können wie folgt zu-sammengefasst werden.

3.1 Datenverwendung Zunächst muss die Infrastruktur die Weiterverwendung der Daten vereinfachen und die Aufrechterhaltung des Qualitätsniveaus dieser Daten garantieren, was ihre Aktuali-sierung voraussetzt. Um zu garantieren, dass geographische Informationen, die im Rahmen eines Einzelvor-habens produziert wurden, an anderen Zielen wieder verwendet werden und dass sie durch die öffentliche Hand befragt oder in Mehrwertdienste durch die Privatwirtschaft noch integriert werden, muss man ihnen zunächst eine bessere Sichtweite und eine adä-quate Dokumentation gewährleisten. Man muss auch im Rahmen des Möglichen die Faktoren identifizieren und reduzieren, die den Zugang zu den geographischen Daten beschränken, wie die Trägheit, die mit der Verwaltung oder mit der Gesetzgebung zu-sammenhängt, die zu hohen Preise sowie eine Reihe von technischen Problemen.

3.2 Begriff der authentischen Quellen Daher muss die Kohärenz verstärkt werden. Diese Zielsetzung deutet zum Beispiel an, dass eine gemeinsame Referenz identifiziert oder dargestellt wird, und dass man eine Verbreitung von Mehrfachkopien der Referenzdaten vermeidet. Diese letzte Sache lässt in der Tat gewaltige Probleme bei der Aktualisierung dieser Daten entstehen. Ein Ziel auf lange Sicht ist also die Konsolidierung des Begriffes der authentischen Quel-len welche eine eindeutige und gut verfügbare Referenz erlaubt. Im Gegensatz dazu werden heute die PICC-Daten in der Zwischenversion des wallonischen Geoportals vierfach kopiert!

3.3 Interoperabilität auf dem Datenniveau Die Online-Verbreitung der geographischen Daten setzt auch die Interoperabilität bei den Daten voraus.

3.4 Berücksichtigung von Normen und internationalen Standards Die Realisierung dieser Infrastruktur wird im Sinne der Integration und der Koordinati-on mit der europäischen Initiative INSPIRE (Infrastructure for Spatial Information in Europe) sowie unter Berücksichtigung der bestehenden Normen und internationalen Standards, die bereits bestehen oder erst in Vorbereitung sind (ISO, CEN, NBN, OGC, W3C...), geführt



3.5 Unabhängigkeit von Systemherstellern Schliesslich sucht die wallonische Region eine grösstmögliche Unabhängigkeit gegen-über den Softwareherstellern. Bei gleicher Leistung werden die „Open Source“-Lösungen gegenüber den proprietären Lösungen bevorzugt.

4 Mitteleinsatz

4.1 Projekt InfraSIG, öffentlich-private Interaktion Das InfraSIG-Projekt funktioniert auf der Basis einer Wechselwirkung zwischen den verschiedenen Verwaltungen und den privaten und universitären Partnern. Seit 2004 ist die Eidgenössische Technische Hochschule in Zürich ebenfalls im Projekt involviert.

4.2 Methode INTERLIS 2 Diese Partnerschaft ist vor allem dadurch begründet – wie wir noch detaillierter sehen werden – weil die modellbasierte Methode mit INTERLIS im Zusammenhang mit dem Projekt InfraSIG übernommen wurde.

5 Fortschritt der Implementierung

5.1 Abgeschlossene Realisierungen Die erste Phase des Projektes InfraSIG wird auf vier Jahre verteilt (Februar 2002-2006). Die folgenden Teilziele wurden bis jetzt erreicht:

Die Realisierung eines kartographischen Zwischenportals, das ins e-Gouvernement-Projekt der Region Wallonien integriert wurde. Die Realisierung eines Metadaten-Verwaltungssystems gemäss den ISO-Normen 19115 und 19139 Die Realisierung von Applikationen für den sicheren Zugriff auf prioritäre Refe-renzdaten, sowohl für die Visualisierungen als auch für das Laden der Daten über das Internet. Die Redaktion von Berichten über die rechtlichen und wirtschaftlichen Aspekte. Das Modell der topographischen Referenzdaten Walloniens wurde mit INTERLIS 2 beschrieben und die entsprechenden technischen Anforderungen wurden in ei-nem Pflichtenheft verfasst.

5.2 Das vorläufige Portal

5.2.1 Stand der Arbeit Das kartographische Portal entspricht einem einzigen interaktiven Schalter für die Verbreitung der geographischen Information der Region Wallonien für alle Anwender wie Verwaltungen, Unternehmen und Bürger. Das heutige Portal ist eine Zwischenlö-sung, welche realisiert wurde, um schnell die Ziele der Abgabe der Referenzdaten errei-chen zu können.Das Portal dient als einziger Zugang, um:

allen Interessenten den Zugriff auf die geographischen Daten aufgrund der vor-handenen Metadaten und der standardisierten Lizenzverträge zu gewähren und so die Geodaten zu verbreiten.



die Visualisierung und das sichere Herunterladen der prioritären Referenzgeoda-ten zu erlauben. Allen via Internet-Verbindungen den Zugang zu den anderen heute verfügbaren geographischen Ressourcen (geologische Karte, Atlanten, statistische Karten, dy-namische Karten wie Trafiroute usw.) zu gewähren die auf den verschiedenen Homepages der kartographischen Dienste der Region Wallonien verfügbar sind. die Realisierung von Standards zu fördern, um den Austausch und die Dokumen-tation der Qualitätsdaten durch die Bekanntgabe der Resultate des Projektes InfraSIG über den Führer der guten Praktiken und über Empfehlungen zu garan-tieren.die Sensibilisierung der Benutzer zu gewährleisten, indem es die Grundkonzepte der geographischen Information definiert und die Daten der Kolloquien, Konfe-renzen oder Fachmessen und der Web-Links, die sich auf die geographische In-formation beziehen, bekannt gibt.

5.2.2 Zukünftige Aktivitäten

Definitives Portal – angestrebte technische Architektur

Benutzer

Datenbank

Services

Web Services OGC & W3C

Kartographische Werkzeuge

INTERLIS-Services

FTP

ServicekatalogDatenkatalog

Register Daten ServicesZugriffsverwaltung / Authentifizierung

Sicherheit / Authentifizierung



Oracle spatial 10g Alle Daten sind in einem einzigen Datenbankverwaltungssystem gespeichert. Für die geographischen Daten hat die wallonische Region Oracle Spatial gewählt. Die Daten vom PICC zum Beispiel werden vom proprietären Format des Herkunft-GIS zu Oracle Spacial 10g übertragen.

5.3 MétaWal und die ISO-Normen

5.3.1 Stand der Arbeit Die Fachleute sind sich einig, dass die Metadaten ein unentbehrliches Element der gan-zen Raumdateninfrastruktur sind. Im Rahmen des Projektes InfraSIG wurden die Meta-daten von allen öffentlichen Datensammlungen Walloniens gemäss den Normen ISO 19115 beschrieben. Die erste Phase dieser Arbeit bestand in der Auswahl und Überset-zung der Attribute, welche für die Beschreibung der wallonischen Daten nötig waren. Diese Attribute wurden anhand der Anwenderbedürfnisse mit wallonischen Erweite-rungen ergänzt. Nach der Festlegung des Metadatenkatalogs wurde das konzeptuelle UML-Modell der ISO-Norm und der wallonischen Ergänzungen generiert. Das UML-Modell der Metadaten wurde danach im Datenbankverwaltungssystem von Oracle imp-lementiert.Danach wurden Datenerfassungsschnittstellen Intranet – Extranet entwickelt, um die Kodierung der Metadaten durch den Datenverwalter zu ermöglichen, welcher sowohl für die Daten als auch für die Metadaten verantwortlich ist. Die Zutrittskontrollen an diesen Schnittstellen werden mittels eines extern akquirierten elektronischen Systems LDAP realisiert. Ein Import-/Export-XML-Werkzeug für Metadaten wurde entwickelt, welches die Vor-norm ISO 19139 Version 6 vollständig erfüllt. Es ermöglicht sowohl die Integration von Metadaten aus anderen Quellen als auch den Austausch von Metadaten mit allen Part-nern ausserhalb der Region Wallonien. Zurzeit ist das auf den Namen MétaWal getaufte System operationell und die Grundla-gen der Metadaten wurden erfasst. Eine grosse Vielfalt von flexiblen Suchprozeduren wurde entwickelt um die Abfragen von verschiedenen Anwendern zu ermöglichen. Die Verbindung mit dem Suchwerkzeug Mugire ermöglicht mehrsprachige Suchprozesse.

5.4 Die abgegebenen Daten – die dazugehörigen Dienste

5.4.1 Stand der Arbeiten Die Daten, auf welche durch das provisorische Portal zuerst Zugang verschafft wird, sind die Referenzdaten (PICC, PPNC, Strassenatlas, MNT Verlauf der Hauptgewässer). Bis heute erlauben die auf diesen Daten entwickelten Dienste einerseits ihre Visualisie-rung mittels zweier mit der OGC-Norm WMS kompatiblen Schnittstellen und anderer-seits das Herunterladen der Datenfiles in zwei proprietären Formaten der GIS-Software.Es ist zu beachten, dass diese Daten laufend mit anderen thematischen Daten nach und nach (gem. Validierung) vervollständigt werden.

5.4.2 Zukünftige Aktivitäten Das provisorische Portal verwaltet Dienste nach den Normen von OGC oder W3C. Die-se Dienste verwenden kartographische Werkzeuge, welche Algorithmen und technische



Funktionen aktivieren, die in den dem Besucher zugänglichen Web-Services enthalten sind.Neben den Applikationsdiensten und den Visualisierung- und Datenzugriffdiensten wird man weitere generische Dienste schrittweise den Anwendern und Entwicklern zur Verfügung stellen. Darunter wird man Lokalisierungsdienste (verbunden mit einem Gazetteer), Dienste für das Herunterladen und die INTERLIS-Dienste (Checker, seman-tische Transformation der Daten, Werkzeuge für die Formatumwandlung, Verwaltung von eindeutigen Identifikatoren) finden. Diese Werkzeuge werden ermöglichen die In-teroperabilität der Daten zu gewährleisten, die Anfragen der Anwender, welche mit verschiedener GIS-Software arbeiten, zu beantworten und die Daten in den erforderli-chen Formaten herunterzuladen. Die Entwicklung des Dienstleistungsumfeldes sieht vor, Dienste zu integrieren, die ele-mentareren Funktionen entsprechen. Es ist die Kombination solcher „atomaren“ Dienst-leistungen, die erlauben wird, Applikationen auf einem den Bedürfnissen der Anwen-der entsprechenden Niveau zu realisieren. Ausserdem muss die Verbreitungsinfrastruktur einen Katalog von Diensten enthalten, welche wahrscheinlich der Norm OGC entsprechen. Mehrere auf dem Markt erhältliche Kataloge werden zurzeit im Rahmen des Projektes InfraSIG evaluiert. Ein Bewertungs-kriterium ist ihr Niveau der Erfüllung der Norm ebXML

5.5 Rechtliche Aspekte

5.5.1 Stand des Fortschrittes Für jede Anwenderkategorie wurde ein einheitliches Lizenzmodell verfasst und auf dem kartographische Portal platziert, das für alle Daten, die durch die regionale Ver-waltung verbreitet wurden, standardisiert ist. Das Herunterladen von Daten ist nur möglich, wenn der Anwender den Lizenzvertrag angenommen hat. Bei der Visualisierung der Daten erscheint ein rechtlicher Hinweis auf dem Bildschirm. Das hat die Prüfung der Gesetzgebungen zum geistigen Eigentum, über das Verwal-tungsrecht, über die Daten von persönlichem Charakter und zur Respektierung des pri-vaten Lebens, über den Verbraucherschutz, über die Verantwortung des Erzeugers und des Benutzers und über die elektronische Unterschrift erfordert.

5.5.2 Zukünftige Aktivitäten Zurzeit wird die Frage diskutiert, inwieweit das Geoportal zur Visualisierung von Geo-basisdaten der Öffentlichkeit zugänglich gemacht werden kann. Es fehlt allerdings eine hinreichende Rechtssprechung und es ist schwierig zu garantieren, dass die Veröffentli-chung solcher Basisdaten nicht einer Verletzung der Bestimmungen über den Schutz der Privatsphäre bedeutet. Besonders stellt sich diese Frage für die Veröffentlichung von sehr detaillierten Orthophotoplänen, welche eine Visualisierung vom Innern privater Liegenschaften erlauben.



5.6 Sozio-ökonomische Aspekte

5.6.1 Stand der Arbeit Um die Regeln für die Abgaben der geographischen Daten definitiv festzulegen ist es notwendig eine Preispolitik zu definieren. Für die Redaktion eines Vorschlages für die wallonische Regierung wurden drei Aspekte verfolgt:

Einerseits wurde eine Studie über die Anwendungen der geographischen Daten unternommen. Zu diesem Zweck wurde eine breite semantische Studie über eine grosse Menge Dokumente unternommen Andererseits wurde eine Studie verfasst über die allgemeinen Kriterien der Preis-festlegung und über die heutige Situation im Bereich der geographischen Daten in EuropaSchliesslich wurde der Vorschlag gemacht, mit welchem eine Preispolitik be-schrieben wird, die tiefe Preise bezweckt und in welcher man die Randkosten für die Abgaben berücksichtigt.

Dieser Vorschlag entspricht den allgemeinen Zielen der Region Wallonien, welche eine breite Verbreitung der geographischen Daten bezweckt und globale Einsparungen so-wie eine regionale Förderung ermöglicht. Der Vorschlag fusst auf den Charakteristika des Marktes geographischer Daten und lie-fert eine Matrix, welche es erlaubt, die Preise in Abhängigkeit von Dateneigenschaften, Benutzertypus und vorgesehener Verwendung zu bilden. So ist es zum Beispiel denk-bar, dass ein Unternehmer freien Zugang zu gewissen als essentiell beurteilten Daten erhält, um für andere – zur kommerziellen Nutzung vorgesehene – Daten bezahlen muss.

5.6.2 Zukünftige Aktivitäten Wenn die wallonische Regierung die Vorschläge annimmt wird ein Abgabesystem ent-stehen in welchen die Geodaten für die öffentlichen Dienste und die Ausbildungsinsti-tutionen kostenlos im Rahmen ihres Auftrages abgegeben werden. Für die anderen Be-rufskreise wird man die Abgabe der Geodaten auf der Basis von Abonnements- oder Partnerschaftsverträgen regeln. Ein Detailverkauf in besonderen Fällen soll ebenfalls möglich sein.

5.7 Die Modellierung der topographischen Referenzobjekte

5.7.1 Stand der Arbeiten Die Modellierung der Referenzdaten ist Bestandteil der existierenden Daten und insbe-sondere vom PICC. Daher wird der Objektkatalog stark von letztgenannten Daten be-einflusst. Ein indirekter Effekt der Modellierungsprozesse war die Erhöhung des Be-kanntheitsgrades der Daten von PICC. Ebenfalls verbreitete sich die Diskussion über die Referenzdaten auch auf andere Berufskreise und blieb nicht nur beschränkt auf den Kreis der Geodaten-Produzenten. Diese Entwicklungen haben die Bedeutung des PICC aufgewertet. Dadurch wird es möglich, das PICC von einer rein numerisch-topographischen Planform hin zu einer echten Datenbasis zu entwickeln. Das Konzept der Vererbung, typisch für die objektorientierten Technologien wurde ein-gesetzt um drei gekapselte Geodatenmodelle zu definieren. Das detaillierteste – innerste – Modell, das Geometermodell, enthält alle im Gelände nach dem System Walcors auf-genommenen Objekte (wallonisches GPS-RTK-Permanentnetz mit 23 Stationen); das



mittlere Niveau ist das Modell PICC, welches ein Teil der Objekte des Geometermodells übernimmt. Schliesslich das Modell der Region Wallonien, welches nur die topographi-schen Objekte beinhaltet die für eine grosse Anzahl Applikationen benötigt werden. In der gleichen Art könnte ein Referenzmodell für das ganze Land oder für Europa aufge-baut werden. Um die sehr unterschiedlichen Detaillierungsstufen zu harmonisieren und zu konzipie-ren, ist die modellbasierte Methode mit INTERLIS 2 angewendet worden. Die Modellierung erlaubte einerseits die Datenstrukturen der Thematik unter Berück-sichtigung der verschiedenen potenziellen Anwendungen zu verbessern. Andererseits schien es sinnvoll bei der Modellierung die Ergänzung der bestehenden Daten mit neu-en Konzepten wie derjenigen der Strassenplattformen.

5.7.2 Zukünftige Aktivitäten Die Einführung der neuen Konzepte und der Einsatz der INTERLIS-Werkzeuge (insbe-sonders dem Checker) machte eine Menge Inkonsistenzen in den Daten sichtbar. Man konnte feststellen, dass es nötig sein wird, ein Re-Engineering der Daten vorzunehmen. In der Folge wird man die Prozesse für die Nachführung der Daten unter der Verwen-dung der Methoden und Werkzeuge von INTERLIS gestalten. Zu diesem Zweck wird man eine immer stärkere Koordination der Anstrengungen anstreben. So sollte zum Bei-spiel nur eine einzige Feldaufnahme für die Nachführung der verschiedenen Datenebe-nen verwendet werden. Die Möglichkeit von INTERLIS 2 im Bereich der inkrementellen Nachführung ist vertieft zu analysieren. Es wird notwendig sein, ein Verwaltungssys-tem für eindeutige Objektidentifikatoren einzuführen.

5.8 Gemeinsames Pflichtenheft für die topographischen Aufnahmen

5.8.1 Stand der Arbeit Die technischen Spezifikationen wurden in einem gemeinsamen Pflichtenheft aufgrund der konzeptuellen Datenmodellierung formuliert. Dieses Pflichtenheft könnte nach der definitiven Validierung als verbindlich für diejenigen Geometer erklärt werden, welche die Arbeiten für die wallonische öffentliche Hand ausführen. In dieser Art werden die Ergebnisse ihrer Arbeiten kompatibel zueinander und man wird sie verwenden, um die Daten des PICC sowie topografische Referenzobjekte auf einfache Weise zu aktualisie-ren.

5.8.2 Zukünftige Aktivitäten Das Pflichtenheft muss noch in einer operationellen Umgebung getestet werden. Im Übrigen wird demnächst ein Pilotprojekt gestartet, um den Informationsaustausch zwischen den Feldequipen und der Verwaltung zu erleichtern. Dieser Pilot hat zum Ziel, im Rahmen des kartographischen Portals einen Web-Dienst für den Datenaus-tausch mit Hilfe von INTERLIS 2-Werkzeugen zu implementieren. Dieses System wird es den für die wallonische Verwaltung tätigen Geometern erlauben, nötige Dokumente aus dem Internet zu beziehen:

das Pflichtenheft, seine Dokumentation, die Datenmodelle usw. die Daten der Geländeaufnahmen der Verwaltung unter Verwendung der IN-TERLIS 2-Werkzeuge zu übergeben um die eigenen Daten nach Bedarf zu trans-



formieren und um ihre Kompatibilität mit den entsprechenden Modellen mit dem INTERLIS-Checker zu überprüfen. eine Validierung der eigenen Arbeit sobald die Verwaltung die Daten überprüft hat.

Die organisatorischen und personellen Aspekte sind eine zentrale Frage des Projektes. Das Projekt kann nur erfolgreich sein wenn gemeinsame Interessen erkannt werden und wenn die Veränderungen breite Unterstützung finden.

5.9 Weitere zukünftige Vorhaben

5.9.1 Integration weiterer Partner Das Vorhaben der Region Wallonien, eine gemeinsame Geodaten-Infrastruktur – basie-rend auf einem Objektkatalog – zu erstellen, welche mit weiteren thematischen Informa-tionen erweitert werden kann, lässt bereits heute erkennen, dass ein Koordinationsbe-darf mit anderen Fachleuten der Regionen Wallonien, Flandern und Brüssel sowie Bun-desstellen (IGN und Kataster) unerlässlich ist. Diese Koordination ist unter anderem notwendig, um die Anforderungen der europäischen Initiative INSPIRE zu erfüllen.

6 Überlegungen 6.1.1 Vorteile von INTERLIS INTERLIS 2 bietet einerseits die Vorteile der Objektorientierung wie Vererbung und Po-lymorphismus. Andererseits können die Daten mit einem so genannten Checker auf Modellkompatibilität überprüft werden. Ebenfalls sehr geschätzt ist in Belgien und ins-besondere in der Region Wallonien die Mehrsprachigkeit der Lösung. Als Ergänzung erleichtert INTERLIS die Nachführung, da sie sich mit inkrementellen Verfahren organi-sieren lässt. Schliesslich ist die Unabhängigkeit der Methode von jeglichem Informatiksystem der entscheidende Vorteil. Er gewährt die Interoperabilität, sobald man die konzeptionellen Modelle mit INTERLIS beschrieben hat.

6.1.2 Aufgetretene Schwierigkeiten Einige der erwähnten Vorteile gelten für die Version 2 von INTERLIS. Die Region Wal-lonien hat von Anfang an entschieden, diese Version zu implementieren, ohne die Ver-sion 1 einzusetzen. Dieser Entscheid stellt die wallonische Verwaltung in die Position des Pioniers von INTERLIS 2, hat aber bereits einigen Zeitverlust verursacht und bein-haltet Risiken, die nicht so leicht abgeschätzt werden können. Man musste zum Beispiel die Modellierungsarbeit „blind“ vornehmen, da während die-ser Zeit die Werkzeuge nur für INTERLIS 1 existierten. Wir sind weiterhin mit dem Problem konfrontiert, dass zu wenige Werkzeuge für die Modellierung der graphischen Darstellung zur Verfügung stehen. Werden wir eine direkte Beziehung mit SLD von OGC erleben? Es gibt noch weitere offene technische Fragen: die Implementierung der OID und ihres Transfers zu anderen Formaten mittels Transformationen, die naturgemäss nie neutral sein können. Wie kann man die Arbeit standardisieren, um allen Datenproduzenten zu ermöglichen, mit dem gleichen Konfigurationsskript für die Transformationswerkzeuge zu operieren? Wie weit kann die inkrementelle Nachführung eingesetzt werden? Usw.



Aufgrund der bisherigen Erfahrungen plädieren wir für eine Vervollständigung der Norm INTERLIS 2 mit Implementierungsregeln, um die erwähnten Probleme zu ver-meiden.Neben den technischen Schwierigkeiten zeigten sich ebenfalls organisatorische und menschliche Probleme. Es ist zum Beispiel nicht leicht, alle Betroffenen in das Vorhaben zu integrieren. Die Beteiligung der Datenanwender war wesentlich kleiner als diejenige der Datenproduzenten, die bereits sensibilisiert sind auf die Bedürfnisse einer Daten-modellierung. Man stellte ebenfalls fest, dass eine Vielfalt von Arbeitsmethoden, insbesondere für die Feldaufnahmen, existiert. Dies ergibt sich aus der fehlenden Standardisierungstradition im Kreis der wallonischen Datenproduzenten. Die Konsequenz daraus ist ein Bedarf nach tief greifenden Änderungen, um garantieren zu können, dass die Daten modell-konform erfasst werden. Man kann erwarten, dass Widerstände entstehen, die durch einen zwingenden rechtlichen Rahmen beseitigt werden können. Terminologische Prob-leme sind ebenfalls aufgetaucht.

7 Schlussfolgerungen Die bisherigen Erfahrungen in der Region Wallonien sind global betrachtet positiv. Die INTERLIS-Lösungsansätze ermöglichten, ein konsistentes Vorgehen zu gestalten und diesem zu folgen. Eine vertiefte Diskussion über die topographischen Referenzdaten und über ihre langfristige Entwicklung wurde ebenfalls ausgelöst. Die Wahl von INTERLIS 2 bedeutete trotzdem ein nicht zu vernachlässigendes Risiko. Mehrere wichtige Fragen blieben bis jetzt unbeantwortet. Die realisierten Lösungen stehen zurzeit noch am Anfang der Entwicklung. Die nächs-ten Schritte der Evolution betreffen die Beziehungen zwischen Referenz- und themati-schen Daten. Diese Zielsetzung wird den Einbezug einer grösseren Anzahl Partner er-fordern.

11

Modellstandardisierung vs. semantische Interoperabilität

Aktuelles aus der Forschung

Andreas Morf, ETH Zürich

Josef Dorfschmid, ADASYS AG

Andreas Morf Eidg. Technische Hochschule Zürich Institut für Geodäsie und Photogrammetrie ETH Hönggerberg CH-8093 Zürich

Sepp Dorfschmid ADASYS AG Dörflistrasse 67 Postfach 5019 CH-8050 Zürich

Tel :

E-Mail :

+41 1 633 32 56 (Morf) +41 1 363 19 39 (Dorfschmid)


1 Problemstellung / Zielsetzung Immer wieder kommt es vor, dass Daten neu erfasst werden, obwohl sie an sich vor-handen wären. Sie liegen aber nicht in der gewünschten Form vor. Zum Teil müssten anspruchsvolle Umformungen durchgeführt, zum Teil sogar verschiedene Datenbe-stände in geeigneter aber nicht offensichtlicher Art zusammengeführt werden. Bislang wurde versucht, die Problematik durch möglichst abschliessende Standardisie-rung der Datenmodelle bzw. der Datenformate zu entschärfen. Wenn die Definition der Bedürfnisse und Ansprüche an die entsprechenden Daten möglich ist und der zugehö-rige Anwenderkreis an den 'runden Tisch' gebracht werden kann ist ein solches Vorge-hen durchaus Erfolg versprechend. In vielen Fällen ist jedoch eine umfassende Festlegung und abschliessende Standardisie-rung der Modelle nicht möglich oder mit unverhältnismässig grossem Aufwand ver-bunden:

1.1 Möglichkeiten und Grenzen der Modell-Standardisierung Mit der modellbasierten Methode (ISO/UML/INTERLIS) steht ein Werkzeug zur Ver-fügung, welches eine sehr flexible Datenmodellierung ermöglicht. Die Anwendung die-ses Verfahren ist weitgehend etabliert und wurde in diversen Informationsgemeinschaf-ten zur Definition ihrer Datenmodelle in der Form von Standards verwendet (SIA 405, AVS, VSA-DSS). Mit den objektorientierten Konzepten, wie sie zum Beispiel in INTERLIS 2 zur Verfü-gung stehen, ist es nun auch möglich, Basismodelle zu spezifizieren und dann mittels Vererbung Modellerweiterungen für spezielle Bedürfnisse vorzunehmen (vergleichbar mit den heute praktizierten kantonalen Erweiterungen zum Bundesmodell der amtli-chen Vermessung). Ist es nun aus administrativen oder rechtlichen Gründen nicht möglich, ein umfassen-des und abschliessendes Datenmodell festzulegen ergeben sich offensichtlich zwei grundsätzliche Probleme:

Verschiedene Teil-Informationsgemeinschaften (z.B. Kantone) erweitern ein Ba-sismodell um Elemente, wobei die Erweiterungen wohl oftmals denselben Inhalt beschreiben, diesen jedoch vielleicht auf verschiedene Arten modellieren (Namen der Klassen/Tabellen/Attribute)

Übergeordnete und 'verwandte' Informationsgemeinschaften (Staat, EU-Raum) streben die Nutzung der Daten an und wollen zu diesem Zweck Standardmodelle erstellen. Die Koordination aller Bedürfnisse der Beteiligten verursacht einen sehr grossen Aufwand und führt entweder zu Modellen, welche dem kleinsten ge-meinsamen Nenner entsprechen und damit den wenigsten gerecht werden - oder aber alle Eventualitäten werden berücksichtigt und es entstehen Modelle mit einer Komplexität, welche in der Praxis kaum mehr handhabbar sind.

Der Einsatz von spezialisierten Softwaresystemen im Geoinformationsbereich im Zu-sammenhang mit normierten Standard-Datenmodellen ist oftmals mit einigen Hürden verbunden und häufig werden auch an sich geeignete Software-Pakete zur Erfassung, Bearbeitung und Auswertung von Daten nicht eingesetzt, weil sie die gewünschten Da-tenmodelle nicht unterstützen oder diese Unterstützung mit erheblichen Kosten ver-bunden wäre.

Nächste Schritte in der Interoperabilität Modellstandardisierung vs. semantische Interoperabilität: Aktuelles aus der Forschung


1.2 Anforderungen an ein Lösungskonzept Wo die Einführung von Standard-Datenmodellen aufgrund administrativer, politischer, rechtlicher und allenfalls auch technischer Randbedingungen nicht oder nur mit sehr grossem Aufwand möglich ist, sind Ansätze gefragt, welche die Interoperabilität auch in den Fällen sicherstellen, bei welchen die Datenmodelle der Beteiligten und deren je-weiligen Systemen nicht (genau) dieselben sind:

Diese semantische Interoperabilität wird mittels einer Transformation sicherge-stellt. Die Formulierung der Transformationsregeln für konkrete Datenmodelle ist ein Schritt, welcher nicht oder nur sehr beschränkt automatisierbar ist

Die Abbildungsfunktionen zwischen verschiedenen Modellen (welche jedoch ei-nen ähnlichen oder gleichen Sachverhalt der Realwelt beschreiben) soll wie die Datenmodelle selbst mit einem systemunabhängigen Formalismus beschrieben werden (im Gegensatz zu einer Formatumwandlung, welche normalerweise mit einer Programmier-/Skriptsprache realisiert wird)

Die Anwendung eines solchen Formalismus soll für den Anwender und Modellie-rer möglichst intuitiv sein, wobei eine Unterstützung durch grafische Hilfsmittel (analog zur Datenmodellierung mit UML) anzustreben ist

Anbindung von Modellierverfahren und Datenformaten, welche verbreiteten In-dustriestandards entsprechen, muss möglich sein und spezifiziert werden (insbe-sondere ISO/OGC Interoperabilitäts-Standards)

Mit einem solchen Werkzeug zur Modellierung von semantischen Transformationen sind folgende Vorteile und Beispielanwendungen denkbar:

Formale Spezifikation und Visualisierung von Zusammenhängen zwischen Mo-dellen für beteilige und verantwortliche Personen

Automatische Ableitung der für die Datentransformation notwendigen Program-me, Skripte und Instruktionen. Denkbar sind XSLT, SQL-3, iG-Skript und weitere

Datenportale, welche es dem Kunden ermöglichen eigene Zielmodelle und Trans-formationen zu deklarieren und somit die Portalmodelle/-daten automatisch ent-sprechend umwandeln und ausliefern

Es wäre also wünschenswert, wenn es Softwaremittel gäbe, dank denen anspruchsvolle Umformungen von Daten auf einfache Art definiert und entsprechend zuverlässig aus-geführt werden könnten.



Bildlich wünscht man sich folgende Situation:

Man könnte auch formulieren: Mout = f(Min-1, .., Min-i)Die Struktur der Inputdaten Din-1 bis Din-i ist durch die Datenmodelle Min-1 bis Min-i be-schrieben. Diejenige der Outputdaten Dout durch das Datenmodell Mout. Die Beschrei-bung erfolgt mittels INTERLIS 2 oder einem anderen äquivalenten Beschreibungsmittel. Wie aber beschreibt man die Funktion f?

2 Grundsätzliche Möglichkeiten zur Definition der Abbildungsfunktion

2.1 Imperative Definition In vielen Fällen werden solche Datentransformationen mittels Programmiersprachen definiert.In einfachen Fällen kommen Skriptsprachen (z.B. PERL) zur Anwendung. Vielfach kommen aber auch eigentliche Programmiersprachen zum Einsatz. Man schreibt ein Programm welches die Aufgabe löst.

2.2 Deskriptive Definition Oftmals möchte man die Erstellung eines Programms lieber vermeiden. Beschreibungen wären angenehmer, weil man sich bei ihrer Erstellung nicht um all die Aspekte der Imp-lementierung kümmern muss. Einen interessanten Ansatz in diese Richtung bilden die Sichten (Views), wie sie auch in INTERLIS 2 vorgesehen sind.

Transfor-mations-EngineDin-1

Din-2

Inputdaten

Dout

Modelle der Inputdaten

Maut

Modell der veredelten Daten

Modell der semant. Transformation

Min-1

Min-2

Veredelte Daten

ModellierungTransformationsdef.

Steuerung Datenfluss

Mtrf



Gegenstand eines aktuellen Forschungsprojektes IGP/ETHZ ist die Abklärung der Eig-nung eines Formalismus zur Beschreibung der Abbildungsfunktion unter Zuhilfenahme der Modellierungssprache UML (Unified Modeling Language). UML bietet neben Klas-sendiagrammen zur Modellierung von Geodaten auch Diagrammtypen zur Beschrei-bung von (dynamischen) Prozessen. Damit lassen sich die Instruktionen, welche für die Abbildung von einer Datenstruktur auf eine andere notwendig sind, in grafischer und für den Benutzer einfach verständlicher Form beschreiben.

2.3 Beispiele dazu

2.3.1 Grunddaten In einer Gegend gibt es – wie überall – Menschen, also entweder Frauen oder Männer. Das – etwas vereinfachte - Datenmodell dazu:

MODEL Menschen =

TOPIC Menschen =

CLASS Mensch (ABSTRACT) =

Vorname: TEXT*30;

Name: TEXT*100;

Geburtsjahr: 1900..3000;

WohnPos: CHKoord;

END Mensch;

CLASS Frau EXTENDS Mensch =

END Frau;

CLASS Mann EXTENDS Mensch =

END Mann;

END Menschen;

END Menschen.

Nun sollen mögliche Paare gebildet und diese als Daten ausgewiesen werden. Für die Paare ergibt sich folgendes Modell:

MODEL Paare =

TOPIC Paare =

CLASS Paar =

VornameMann: TEXT*30;

NameMann: TEXT*100;

GeburtsjahrMann: 1900..3000;

VornameFrau: TEXT*30;

NameFrau: TEXT*100;

GeburtsjahrFrau: 1900..3000;

END Paar;

END Paare;

END Paare.



2.3.2 Full-Join (kartesisches Produkt) Ist man an allen möglichen Paaren interessiert, müsste man folgende Transformation definieren:

TRANSFORMATION MODEL AllePaare =

IMPORTS Menschen, Paare;

VIEW Paar

JOIN OF M ~ Menschen.Menschen.Mann,

F ~ Menschen.Menschen.Frau;

=

VornameMann: TEXT*30 := M->Vorname;

…

VornameFrau: TEXT*30 := F->Vorname;

END Paar;

MAP Paar TO Paare.Paare.Paar;

END AllePaare.

Eine vergleichbare imperative Definition hätte etwa folgendes Aussehen:

loop M := alle Menschen.Menschen.Mann

loop alle F := Menschen.Menschen.Frau

VornameMann := M->Vorname;

VornameFrau := F->Vorname;

Paare.Paare.Paar kreieren

Attribute darauf kopieren

end

end

Der Unterschied ist offensichtlich relativ klein.

2.3.3 Equi-Join Ist man an allen Paaren interessiert, bei denen beide Partner im gleichen Jahr geboren sind, müsste man die Transformation leicht ergänzen:

TRANSFORMATION MODEL GleichaltrigePaare =


VIEW Paar



WHERE M->Geburtsjahr == F->Geburtsjahr;

=


…


END Paar;


END GleichaltrigePaare.



Analog könnte man in der imperativen Definition schreiben:


loop alle F := Menschen.Menschen.Frau

if M->Geburtsjahr == M->Geburtsjahr then





end

end

end

Es ist aber offensichtlich, dass dies bei sehr grossen Datenmengen zu erheblichem Auf-wand führt, auch wenn die Ergebnismenge (also die gefundenen Paare) relativ klein ist, da nur die gleichaltrigen Menschen als Partner in Frage kommen. Bei jedem Mann wer-den alle Frauen angeschaut und dann auf Gleichaltrigkeit geprüft. Dies führt zu M * F Vergleichsoperationen. Würde man eine Hilfsstruktur aufbauen, dank der alle Frauen mit einem bestimmten Geburtsjahr effizient gefunden werden können, könnte das Programm ungefähr so aus-sehen:

HF := ErzeugeHilfsstruktur (Menschen.Menschen.Frau,

Geburtsjahr)


loop alle F := HilfsstrukturAuswahl(HF, M->Geburtsjahr)





end

end

Der Laufzeitaufwand würde damit im Prinzip auf M * log(F) sinken und damit auch die Bearbeitung grosser Datenmengen erlauben. Eigentlich möchte man sich im Rahmen der Definition einer semantischen Datentrans-formation aber nicht um solche Aspekte der Implementierung kümmern. Die deskripti-ve Form ist darum vorteilhafter. Allerdings hat sie den Nachteil, dass man dem Trans-formationsverfahren einiges aufbürdet, wenn es auf Grund der WHERE-Bedingung er-kennen muss, dass es Optimierungsmöglichkeiten gibt. Das folgende Beispiel macht dies noch deutlicher.



2.3.4 'Near' - Join Es besteht ein Interesse an allen Paaren, bei denen die Partner nicht weiter als einen Ki-lometer entfernt wohnen.

TRANSFORMATION MODEL UmkreisPaare =


FUNCTION Distanz(P1: CHKoord; P2: CHKoord): NUMERIC;

VIEW Paar



WHERE Distanz(M->WohnPos, F->WohnPos) < 1000.0;

=


…


END Paar;


END UmkreisPaare.

Wie soll das Transformationsprogramm hier eine Optimierungsmöglichkeit erkennen? Würde man jedoch spezielle Definitionen einführen, bei welchen der Bezug zu den Grundmengen erkennbar ist und die im Rahmen einer WHERE-Bedingung eingesetzt werden können, wäre dies wieder einfach:

TRANSFORMATION MODEL UmkreisPaare =


FUNCTION InnerhalbDistanz

(Basis1: CLASS; P1Attr: ATRIBUTE;

Basis2: CLASS; P2Attr: ATTRIBUTE;

MaxDistanz: NUMERIC): BOOLEAN;

VIEW Paar



WHERE InnerhalbDistanz(M, WohnPos,

F, WohnPos, 1000.0);

=


…


END Paar;


END UmkreisPaare.



2.3.5 'Nearest' - Join Ist man noch restriktiver bei der Paarbildung und bildet Paare nur zwischen der Frau, die am nächsten bei einem Mann wohnt oder umgekehrt, bleibt die Transformationsbe-schreibung sehr ähnlich.

TRANSFORMATION MODEL NachbarPaare =


FUNCTION KuerzesteDistanz

(Basis1: CLASS; P1Attr: ATRIBUTE;

Basis2: CLASS; P2Attr: ATTRIBUTE): BOOLEAN;

VIEW Paar



WHERE KuerzesteDistanz(M, WohnPos,

F, WohnPos);

=


…


END Paar;


END NachbarPaare.

Will man die Transformation imperativ beschreiben, ist es offensichtlich, dass die Lö-sung recht anspruchsvoll ist, wenn sie auch bei grossen Mengen zu vernünftigen Lauf-zeiten führen soll.

2.4 Forschungsprojekt 'Neue Ansätze zur konzeptionellen Beschreibung semantischer Transformationen'

2.4.1 Ausgangslage Vorgängig wurden die Grundlagen für den Einsatz von Views, welche die Abbildung von einer Ausgangsdatenstruktur auf eine Zieldatenstruktur leistet, ausführlich einge-führt. Für einen Anwender, welchem dieses Verfahren nicht aus der Datenbank-Welt vertraut ist, sind solche Abbildungsdefinitionen nicht ganz einfach zu verstehen und nachzuvollziehen. Darüber hinaus ist eine intuitive grafische Darstellung, welche den gleichen Sachverhalt der Transformation wiedergibt, schwierig zu erreichen.

2.4.2 Zielsetzung: grafische Notation und daran angelehnter Formalismus Neben dem Diagrammtyp 'Klassendiagramm' stellt die grafische Modellierungssprache UML auch weitere Diagrammtypen zur Verfügung, welche die Erstellung von Modellen für Prozesse ermöglicht. Da jedoch mit diesen Mitteln die Transformation von Modellen nicht vollständig ausgedrückt werden kann, muss das Repertoire von UML zu diesem Zweck erweitert werden. Bei der OMG (Object Management Group), welche für die Weiterentwicklung von UML zuständig ist, wurde bereits ein Vorschlag für entspre-chende Modellierungselemente eingereicht (MOF Query/Views/Transformations; UMLX)



Für die Darstellung der semantischen Transformation von Geodaten müssen die geeig-neten Diagrammelemente evaluiert und um notwendige Erweiterungen ergänzt wer-den. Die Anpassung der UML-Symbolik für eine Anwendungsdomäne (Geoinformatik) nennt man auch UML-Profil. Eine Modelltransformation könnte dann wie folgt darge-stellt werden:

Da grafische Darstellungen wie UML nicht direkt maschinell verarbeitbar sind, muss in Ergänzung dazu ein textueller Formalismus geschaffen werden. Die Realisierung kann zum Beispiel als Erweiterung von INTERLIS 2 erfolgen. Für Transformationen, bei wel-chen der mengenorientierte Zugriff ausreicht, können die Abbildungsvorschriften auch mittels Views repräsentiert werden.

2.4.3 Implementierung der Transformationsmodelle Mit der Formulierung von Modellen und Transformationen auf konzeptioneller Ebene erhalten wir den 'Werkzeugkasten', mit welchem wir die semantische Interoperabilität erreichen können. Wir sind damit nicht an ein konkretes GIS-System bzw. Transforma-tionssoftware mit eigener Programmier-/Skriptsprache gebunden. Ebenso wie wir mit INTERLIS unabhängig vom Transferformat sind (XML, GML, ITF), lassen sich die Transformationsvorschriften in eine konkrete Transformations- bzw. Programmiersprache, welche für eine bestimmte Anwendung ideal geeignet ist, umset-zen. Denkbar wären z.B. SQL, XSLT, XQuery, iG-Skript, FME usw. Ähnlich wie die Kommunikation der am Daten-Modellierungsprozess beteiligten Exper-ten durch konzeptionelle und grafische Mittel wie UML stark verbessert wird, macht es Sinn, die Zusammenhänge und Transformationen zwischen verschiedenen Datenmo-dellen (ähnlicher oder gleicher Themenbereiche) explizit zu formulieren. Dies kann mit einer Programmiersprache allein nicht sinnvoll geleistet werden.

2.5 Folgerungen Die deskriptive Definition einer semantischen Transformation hat zweifellos Vorteile, denn sie trennt zwischen Definition und Implementierung. Um die Ansprüche an die Transformationsprogramme nicht a priori hoch zu schrauben oder das Risiko einzugehen, dass Optimierungsmöglichkeiten kaum genutzt werden, macht es Sinn, die Formulierung spezieller Bedingungen durch spezielle Operationen zu unterstützen. Für solche Operationen ist in den Transformationsprogrammen explizit entsprechender Code vorzusehen. Es ist aber den Transformationsprogrammen überlas-sen, inwiefern sie die Optimierungen auch realisieren.



3 Ein Blick auf INTERLIS 2 Wer INTERLIS 2 präsent hat, hat festgestellt, dass die Sichten 'AllePaare' und 'Glei-chaltrigePaare' mit den heutigen INTERLIS 2 – Mitteln formulierbar sind. Für die Sichten in den Modellen 'UmkreisPaare' und 'NachbarPaare' sowie für eine durch den Transformator leicht erkennbare 'GleichaltrigePaare'-Sicht ist es nötig IN-TERLIS 2 um View-Operatoren zu ergänzen. Es kann dazu ein ähnlicher Ansatz ver-wendet werden wie bei den bereits vorhandenen INTERLIS-Funktionen. Mit einem Zusatz muss dafür gesorgt werden können, dass aus einer Sicht Objekte ge-mäss einer Klasse eines Modells erzeugt werden können.

Mit einem bescheidenen Ausbau von INTERLIS 2 kann die semantische Daten-transformation mittels INTERLIS 2 beschrieben werden.

Die genaue Definition ist noch Gegenstand eines gemeinsamen Projektes.

4 Hauptvorteile

4.1 Kommunikation zwischen Menschen Mit INTERLIS wurde nebst dem eigentlichen Datentransfer eine gemeinsame Sprache geschaffen, damit sich Menschen möglichst präzis über die Struktur von Daten unter-halten können. Ähnlich könnte mit einem solchen Ansatz auch ein generelles Verständnis aufgebaut werden, wie man Transformationen von Daten beschreibt. Wie bei den Datenmodellen dürfte es auch bei den Datentransformationen teilweise an-spruchsvoll sein, die besten geeignete Definition zu finden. Eine gemeinsame Sprache leistet dabei aber wichtige Dienste.

4.2 Nutzen für Prozessoren

UML-Editor Andere Tools

I2-Modelle

I2-Compiler

Modellein XML

TransformatorInputdaten Outputdaten

Andere Quellen der Definition von Modellen und Transformationen



Der Transformator ist abstrakt gehalten und hat folgende grundlegenden Fähigkeiten:

Ist in der Lage Daten zu verarbeiten, die INTERLIS 2 – Datenmodellen entspre-chen und kann somit recht anspruchsvolle Datenmodelle unterstützen.

Ist in der Lage auf eingelesenen Daten mit INTERLIS 2 definierte Sichten aufzu-bauen und modellbasierte Datentransformationen auszuführen.

Dabei kann davon ausgegangen werden, dass einfache Datentransformationen direkt mit einer leicht erweiterten INTERLIS 2 – Beschreibungen definiert und ausgeführt werden können. Ähnlich zu den in INTERLIS 2 vorgesehenen Funktionen, wird man jedoch für anspruchsvollere Abbildungen spezifische Operatoren zur Bildung von Sich-ten definieren und entsprechend im Transformator codieren. Die INTERLIS 2 – Modelle (inkl. Transformation) können mit dem UML-Editor oder anderen Werkzeugen erstellt werden und mit dem INTERLIS 2 – Compiler in ein noch definitiv festzulegendes Format (z.B. in INTERLIS 2 oder XMI) gebracht werden. Alter-nativ ist es auch möglich, solche Modell- und Transformationsbeschreibungsdaten mit anderen Werkzeugen (unabhängig von INTERLIS) direkt zu erzeugen. Diese Modell- und Transformationsdefinitionen werden durch den Transformator gelesen. Damit ist dem Transformator bekannt, wie die Inputdaten zu Outputdaten veredelt werden müs-sen.Durch diese klare Trennung der einzelnen Komponenten besteht eine hohe Anpas-sungsfähigkeit an verschiedene Bedürfnisse, die sich aus konkreten Systemsituationen ergeben.

12

Datenmigration UIC

Théophil Engel, UIC / SBB

Théo Engel, Dr. SBB-Infrastruktur-Asset Management, Programmanager Fahrstrom Schanzenstrasse 5 CH-3000 Bern 65


+41 51 220 21 80 +41 51 220 39 19


1 Umfeld

1.1 Übersicht

1.1.1 Einstieg Der Gleisbau stützt sich schon lange auf Koordinatentrassen. Seit den 90er Jahren sind diese auch als Grundlage des systematischen Gleisunterhalts im Einsatz und bringen dort bedeutende finanzielle, technische, allgemein anerkannte Vorteile. Numerische Gleiskoordinaten sind auch die Basis einer erhöhten Interoperabilität aller Infrastrukturanlagen, sowie dank der, von der europäischen Union postulierte Harmonisierung der Koordinatenreferenzen, landesgrenzen-überschreitend, eine Grundvoraussetzung ist für erfolgreiche, neue Anwendungsfelder wie z.B. die satellitenbasierte Navigation der Züge.

1.1.2 Vierzehn Kernsätze 1 Koordinatenbasierte, absolute Gleisedefinition (CNTD) als Grundlage des modernen Gleisbaus und Gleisunterhaltes //2 UIC-Projekt GEORAIL: Ein weiterer Konsolidationsschritt auf dem Weg der Einführung absoluter Koordinaten bei der Eisenbahn //3 Definition Bahngeodäsie, CNTD //4 Die wichtigsten Grundsätze im Umgang mit diesen Kerndaten der Infrastrukturanla-gen //5 Wirtschaftliche und technischen Vorteile absoluter Koordinatentrassen //6 Bedeutung des Optimierungspotentials dank absoluten Trassenkoordinaten auf der Prozessebene //7 Umfassen-de Lösung bedingt grenzüberschreitende Sicht //8 Fundierte Vertiefung zu Fragen der Koordina-tenreferenz, Datenstandardisierung sowie Datenschnittstelle //9 Ansprechpartner von Georail Phase 2: Gleisbaufirmen, Eurogeographics (Europäische Landesvermessungsämter), Forschung, Gleisbauliteratur //10 UIC interne Absprache mit Projekt Track Machine Guidance //11 Dialog UIC Eurogeographics. Ansprechsstelle Eisenbahn für die Eurogeographics? //12 Folgearbeit auf Steuerebene: UIC-Merkblatt mit Leitbildcharakter //13 Folgearbeit Technik: Nationale Bahn-reglemente und dritte Auflage des Buches „Eisenbahnbau – Wichmann Verlag, 2006-7 //14 Wei-terführung des Georail Gedankengutes durch UIC-Track-Expertengruppe?

1.1.3 Ziel von GEORAIL und Inhalt des Berichtes Klärung der Grundsatzfragen zum Einsatz von absoluten Koordinaten für die Eisen-bahn. Skizzierung erster Überlegungen, die im Umgang mit Koordinaten der Förderung der Interoperabilität aller Objekte der Infrastruktur dienen. Das erste Kapitel gibt Einblick in die Thematik Koordinaten bei der Eisenbahn mit Schwergewicht Gleisanwendungen. Das zweite Kapitel reflektiert die wichtigsten Resul-tate, welche im Rahmen des UIC-Projektes bezüglich der Frage der semantischen Trans-formation. Das dritte Kapitel zeichnet die weiterführende Stossrichtung auf.

1.2 Historische Entwicklung Die koordinatenbasiert, kontinuierlich-numerische Trassendefinition, CNTD (engl., con-tinuous numeric track definition) hat sich in den 90er Jahren als Basis der Gleisarbeiten durchgesetzt. Grosse Bahnnetze planen deren Einführung oder haben sie bereits hinter sich. Die Gleismaschinenindustrie steuern damit Gleisbaumaschinen.Die Schlüsselwörter wirtschaftlicher Gleisarbeiten sind: Einfache Nutzung, (bahn-) netzweite Einheitlichkeit, operative Präzision und Zuverlässigkeit, keine Spezialtricks bei der Anwendung. Daraus ergeben sich zwei geodätische Herausforderungen:

Nächste Schritte in der Interoperabilität Datenmigration UIC


- Die Harmonisierung der heute europaweit heterogenen, geodätischen Grundlagen.

- Die Abbildung des (globalen) räumlichen Gleisverlaufs auf die ebenen Pläne. In der UIC (Union internationales des chemins de fer) sind Gleisarbeiten das Kernge-schäften des „Track Expert Group“. Klassisch kennen sie keine Koordinaten. Erste Bei-träge für den Einsatz von Koordinaten in den Gleisarbeiten kommen von der Gruppe 6.4 „Track and utility lines“ der FIG (Fédération Internationale des Géomètres). FIG 6.4 postuliert den Kontakt zu den Bahnspezialisten: Die Führung gehört langfristig nicht zur FIG, sondern zur UIC. Der Übergang erfolgt schrittweise: 1990 – Entscheid der FIG zum Einstieg in die Thematik Bahngeodäsie. 1996 – Die Präsidenten der FIG und der UIC erstellen einen ersten Kontakt. 2000 – Die „Track Expert Group“ der UIC übernimmt die Leitung des Koordinatenpro-jektes zur Steuerung der Gleisbaumaschinen unter der Führung der schwedischen Bah-nen (BV).2002 – Beginn des UIC Projektes Georail. Abschluss des FIG Engagements. 2004 – Erste „Open Rail Session“ unter dem Patronat der UIC. Nebst den Bahnprojektpartnern sind folgende Bereiche in Georail involviert:

- ExG-G (expertgroup geodesy, Arbeitsgruppe Geodäsie) von Euroge-ographics als Vertreter der europäischen Landesvermessungsverwaltungen. In Abstimmung mit der EU-Kommission, legen sie in den 90er Jahren ETRS89 als europäische Koordinatenbasis fest.

- ISO/TC211 und CEN/TC287 im Bereich der Datenstandardisierung. - Die Vertreter der Gleisbaumaschinenindustrie Plasser-Theurer und Müller

AG.- Die Forschung, vertreten durch das Institut für Geodäsie der ETH Zürich - Die Eisenbahnbauliteratur durch die Hauptverfasser des Buches „Eisen-

bahnbau“ (G. Müller, Wichmann Verlag, 2000) der Hochschule für Technik und Wirtschaft in Dresden

1.3 Einige Grundbegriffe CNTD oder Continuous, Numeric Track Definition ist der englische Begriff für absolute Gleistrassierung auf der Basis von Koordinaten. CNTD beschreibt die 3-dimensionale Gleisgeometrie mit mathematisch exakt definier-ten Elementen, die nahtlos aneinandergeknüpft, die Gleise an jedem beliebigen Punkt in Lage, Höhe und Überhöhung beschreiben. Nebst CNTD bilden folgende Elemente die Basis der Bahngeodäsie:

- Die Ordnungsdaten als Schlüssel für die Datenabfrage und –Strukturierung, in Form von eineindeutigen numerischen Streckentrassen. Netzweit gruppiert, bilden diese, „KM-Achsen“ genannten Trassen, die Stre-ckennetze der Eisenbahngesellschaften.

- Die geodätischen Referenzpunkte. Über diese Punkte sind die Bahndaten am absoluten Koordinatensystem angebunden. Diese Punkte beinhalten auch die Funktionalität der Gleisvermarkung, was zu den, im folgenden Ab-schnitt beschrieben, Vorteilen führt.

- Die Trassenpunkte und die kritischen Punkte des Lichtraums, welche der Trassenrechnung zugrunde liegen.



Bahngeodäsie ist ein Teilfachgebiet der Ingenieurvermessung, das alle Geoinformatio-nen für die topologische Datenstrukturierung, Verwaltung und interdisziplinäre Nut-zung numerischer Gleistrassen liefert und die damit zusammenhängenden Verfahren beinhaltet.Die KM-Achsen bilden den Kern der hierarchisch strukturierten, koordinatengebunde-nen Daten der Infrastruktur (Abb. 1.1). Das zweite Niveau um den Kern, beinhaltet die Gleisdaten. Sie werden von allen Fachdiensten benötigt. Die dritte Schicht umfasst die wichtigsten Daten der Fachdienste welche auch von den anderen Bereichen benutzt werden und das letzte Niveau beinhaltet die Daten, deren Interessen auf den Fachdienst beschränkt sind. Diese Strukturierungsart erlaubt es, den Datenzugriff mittels zwei Koordinatenwerten durch eine eindimensionale Abfrage über einen KM-Wert zu ersetzen, was einer be-trächtlichen Vereinfachung bezüglich der Organisation der Abfragealgorithmen gleich-kommt.

Koordinatenreferenzierte Infrastrukturobjekte, aufgebaut nach dem Schalenmodell: Kern: Das Streckennetz mit Knoten (die Be-triebspunkte) und Kanten (die Strecken) Erste Schale: Das Gleisnetz Zweite Schale: Die Kern-Fachdienstdaten. Dritte Schale: Fachdienstdaten mit limitiertem InteresseCNTD: Geodätische Referenzpunkte sowie die Daten von Kern und erster Schale des Schalen-modells

Abb. 1.1 : Hierarchisches Schichtenmodell der koordinatenbasierten Daten der Infrastruktur

1.4 Technische Entwicklung Die Entwicklung von CNTD ist das Resultat der engen Zusammenarbeit von Fachleuten aus Vermessung, Bahndienst und Informatik. Die CNTD Entwicklung begann im opera-tiven Tagesgeschäft der Eisenbahn nach dem „vom Benutzer für den Benutzer“ - Mo-dus.Drei Jahrzehnte charakterisieren die Entwicklung wie folgt:

- 80er Jahre: Verschiedene Einzelentwicklungen im Bottom-up Verfahren. - 90er Jahre: Verschiedene Konsolidierungsphasen bei den Bahnen, aber ohne

grenzüberschreitende Koordination. - Ab 2000: Operative Reife der Systeme mit Erhöhung der Wirtschaftlichkeit

im Gleisbereich. Erste internationale Abstimmungsbestrebungen. Die Optimierung auf Prozess- und Organisationsebene ist der nächste, wichtige Ent-wicklungsschritt.CNTD setzt den Methoden der bisherigen, relativen Gleistrassierung ein Ende. Diese alten Methoden beruhen alle auf dem Pfeilhöhenprinzip. Mit einer gespannten Schnur zwischen zwei Bezugspunkten, misst man die Pfeilhöhe eines Kurvenabschnit-tes und vergleicht ihn mit einem theoretischen Wert. Ab 1940, beginnen die Bahnen, die



Kurven ihres Netzes auf diese Art zu unterhalten. Senkrecht, einen Meter neben den Gleisen, alle 20m eingeschlagene Gleisstücke, sind die Bezugspunkte der Gleistrassie-rung, nachfolgenden Vermarkungspunkte genannt. Die zwischen den Kurven liegen-den Geraden werden in der Regel nicht vermarkt. Erste Impulse für den Wechsel kommen:

- Von der Gleisbaumaschinenindustrie, welche im Bereich der Automatisie-rung der Maschinensteuerung entscheidende Fortschritte macht.

- Von den Bahnen welche beginnen, koordinatenbasierte, numerische Gleis-trassen zu rechnen.

Der Durchbruch erfolgt, durch das Zusammenlegen der Funktionalitäten „Vermar-kungspunkt“ und „geodätischer Fixpunkt“. Die Gleismaschinen können, dank den Fortschritten der automatischen Gleisbaumaschinensteuerung und den koordinaten-mässig definierten Vermarkungspunkten, für jeden Gleispunkt in Echtzeit die IST-Lage des Gleises bestimmen, sowie die Differenz zwischen der effektiven Gleislage und der theoretischen Soll-Lage. Das Resultat dient als Steuerwert der Gleismaschinen, dessen Ermittlung automatisch aus folgenden Grunddaten ermittelt wird:

- Die koordinatenmässig definierten Vermarkungspunkte, - Die kontinuierlich gerechneten, theoretischen Koordinatentrassen, - Die netzweit homogenen, eineindeutigen Koordinatenreferenz, - Die automatisiert ermittelte IST-Lage der Gleise.

Die einführend aufgeführten Grundbedingungen für den automatisierten Einsatz der Gleismaschinen für den systematischen Unterhalt sind somit vollständig erfüllt: Einfa-che Nutzung, bahnnetzweite Einheitlichkeit, operative Präzision und Zuverlässigkeit, Keine Spezialtricks bei der Anwendung Dieser Automatisierungsprozess funktioniert heute in der Praxis des Gleisunterhaltes unterschiedlich.

- Für Vermarkungspunkte die als geodätische Messpunkte materialisiert, auf den Fahrleitungsmasten fixiert sind, ist die Methodik voll operativ und aus-gereift.

- Die Variante, wo nur noch mit Satellitenpositionierung gearbeitet wird, ist heute erst im Aufbau. Anstelle einer Vermarkung entlang des Gleises gibt es nur noch alle 2 km einen, mit GPS bestimmten, geodätischen Referenzpunkt in Gleisnähe. Heute noch nicht gelöste Probleme sind:

Keine GPS-Signale in den Schattenzonen (z.B. in Tunnels, bei abgedeck-ten Bereichen der Bahnhöfe, ...).Unzureichende Präzision für kritische Netzteile, z.B.: Komplexe Wei-chenverbindungen – häufig die Ein- und Ausfahrten grösserer Bahnhöfe – feste Fahrbahn und vor allem alle Strecken wo Hochgeschwindigkeit gefahren wird. Dort müssen repetitiv Absteckgenauigkeiten im mm-Bereich sichergestellt werden können, währenddem Werte in der Regel ±5mm betragen, um die Vorteile der absoluten Koordinatentrassen voll nutzen zu können.

Die treibende Kraft zur Harmonisierung der Koordinatenreferenz kommt im Gleisbe-reich von den Bedürfnissen der Satellitenpositionierung, wo höchste Genauigkeiten nur über völlig spannungsfreie Netze erreicht werden können.



1.5 Gewinnfaktoren Erhöhung der Qualität der Gleislage Erhöhung der Wirtschaftlichkeit Datenhierarchie Funktionale Optimierungen: Prozesssupport Zusammenfassend: Katalysierender Effekt und Synergien dank Koordinaten

2 Semantische Transformation Die im zweiten Kapitel beschriebenen Arbeiten, wurde von der ETH Zürich im Rahmen der UIC-Projektes Georail erbracht.

2.1 Modellierung der Ordnungsdaten Grundlage für die Modellierung der Ordnungsdaten bilden die Streckenübersichtsdaten aus der Datenbank der festen Anlagen (DfA) sowie ergänzende Betriebspunktdaten. Aus diesem relevanten Realitätsausschnitt wird mit der textuellen CSL INTERLIS ein konzeptionelles Schema erstellt.

2.2 Standardisierung der Ordnungsdaten-SchnittstelleMit dem „Compiler“ wird das textuelle Schema geprüft. Sobald diese Konsistenzprü-fung fehlerfrei abläuft, wird daraus die Beschreibung des Transferformats (physisches Schema) erstellt. Im vorliegenden Beispiel wird das INTERLIS-Transferformat ITF ver-wendet. Analog kann jedoch auch das XTF- oder GML-Transferformat erzeugt werden. Das physische Schema enthält die Information, welches wie die Transferdatei struktu-riert sein muss. Entsprechend diesem Standardformat werden die Ausgangsdaten nun umstrukturiert. In den meisten Fällen genügt dazu eine einfache Programmier- oder Skriptsprache, zum Beispiel awk. Awk ist eine einfache Skriptsprache auf Basis der Mustererkennung, mit deren Hilfe ASCII-Dateien systematisch auf das Standardformat umgebaut werden können.

2.3 Visualisierung der Strecken- und Stationsdaten mit Geo-Shop Die SBB-Streckendaten liegen nun im systemunabhängigen INTERLIS-Transferformat (ITF) vor. Sie können mit einer Software, welche INTERLIS unterstützt, visualisiert werden. Im Folgenden wird dafür „GeoShop“ verwendet, eine Software, welche auf systemneutralen Standards basiert (https, Java, INTERLIS). Sie ermöglicht die Bearbei-tung von Geodaten unterschiedlicher Struktur (insbesondere die Visualisierung, die Verbreitung sowie der Verkauf dieser Daten) über das Intra- oder Internet. Geoshop be-steht aus 3 Modulen:

- Geoshop Server: Dieser zentrale Teil des Programms verwaltet die Geodaten sowie die Benutzerinformationen

- Geoshop Client Tools: Sie ermöglichen die Visualisierung und Verbreitung der Daten, wobei vom Kunden einzig ein Java-fähiger Webbrowser benötigt wird.

- Geoshop Administrator Tools: Sie steuern die Konfiguration des Servers, den Status von Benutzern und Bestellungen sowie die Darstellung der Geodaten.



2.4 Modellierung der Fachdienst-Daten: FahrleitungAE In einem nächsten Schritt geht es darum, den Inhalt von nicht verknüpften Datenbank-tabellen mit Hilfe der modellbasierten Methode gemeinsam nutzbar zu machen, vor-ausgesetzt beide Tabellen enthalten mindestens ein gemeinsames Attribut. Als Beispiel wird für die Fahrleitungsinformationen der SBB, welche zu den Fachdienst-Daten gehö-ren, aus den Streckenübersichtsdaten die Geometrie hergeleitet. Die Informationen zu den Fahrleitungen sind in einer Excel-Tabelle enthalten, wobei jede Zeile einem Fahrleitungsabschnitt entspricht. Die Tabelle enthält für jeden Fahrlei-tungsabschnitt Attribute, beispielsweise das Erstelektrifizierungsjahr. Obwohl die Fahr-leitungen einen eindeutigen Raumbezug aufweisen, sind in der Tabelle keine Koordina-ten enthalten. Einzige räumliche Attribute bilden die Kilometrierungswerte (km von, km bis), welche jeweils Anfang und Ende eines Fahrleitungsabschnittes repräsentieren. Die Kilometer-Achsen der Streckenübersichtsdaten sind meist in mehrere Fahrleitungs-abschnitte unterteilt, welche jeweils aus einer Vielzahl von minimalen Streckenabschnit-ten bestehen.

Baujahr Fahrleitung

BPK von Linie von Fil von LinieKorr km von

Lausanne 100 100 West Lausanne 0.0000

St-Maurice 100 100 West St-Maurice 51564.9400

Sion 100 100 West St-Maurice 92432.0600

Brig 100 100 West Brig 145548.5000

Brig Tunnel 109 109 West Brig 147149.9000

Vevey Ouest (bif) 111 111 West Lausanne 762.5000

BPK bis Linie bis LinieKorr km bis Jahr 1. El.

St-Maurice 100 100 St-Maurice 51564.9400 1924

Sion 100 100 St-Maurice 92432.0600 1923

Brig 100 100 Brig 145548.5000 1919

Iselle di Trasquera 100 100 Brig 167478.3100 1906

Iselle portail tunnel 109 109 Brig 166973.4000 1922

Puidoux-Chexbres 111 111 Lausanne 7829.0000 1940

Abb. 2.1 : Auszug aus der Exceldatei der Fahrleitungsdaten

Die Herleitung von Fahrleitungsdaten und ihrem Verlauf aus Fahrleitungsdaten, die nur Anfangs- und End-Kilometrierungswerte enthalten, und aus Ordnungsdaten mit geometrischem Verlauf, ist ein typisches Beispiel für eine semantische Transfor-mation.Zunächst ist die Ausgangsklasse der Fahrleitungsdaten mit UML und INTERLIS zu be-schreiben. Das gibt eine UML-Klasse „FahrleitungAE“ und eine INTERLIS-Klasse „Fahrleitung“.



2.4.1 Standardisierung der Fachdienst-Schnittstelle: FahrleitungAE Aus dem INTERLIS-Modell kann automatisch die Formatbeschreibung für die Klasse „FahrleitungAE“ bestimmt werden. Mit einem 1:1 Prozessor werden die Daten der Ex-cel-Tabelle umgebaut auf das Standardformat ITF.

2.4.2 Modellierung der Fachdienst-Daten: Fahrleitung (mit Verlauf) Als Zieldatei der semantischen Umformung wollen wir die einfache Klasse „Fahrlei-tung“ mit nur zwei Attributen definieren: Das Attribut „Erstelektrifizierung“, das aus der Klasse „Fahrleitung “ übernommen wird, und das Attribut „Verlauf“ vom Typ PO-LYLINE, das neu berechnet wird aus den Attributen „km_von“ und „km_bis“ der Klas-se „Fahrleitung“ und aus dem Attribut „Verlauf“ der Klasse „Achse“. Das UML-Diagramm dieser neuen Klasse „FahrleitungAE“ finden wir in Abb. 2.2, ihr INTERLIS-Datenmodell in Abb. 2.3.

Fahrleitung

Erstelektrifizierung

Abb. 2.2 : Graphisches Datenmodell neue Klasse „Fahrleitung“ (UML-Diagramm)

TABLE Fahrleitung =

Erstelektrifizierung: [1900 .. 2500];

Verlauf: POLYLINE WITH (STRAIGHTS, ARCS) VERTEX Koord2

WITHOUT OVERLAPS > 0.50000;

NO IDENT

END Fahrleitung;

Abb. 2.3 : Neue Klasse „Fahrleitung“ (mit Verlauf), INTERLIS-Modell

2.4.3 Semantische Transformation Jetzt stehen zur Verfügung: Die Datenmodelle in INTERLIS der Ausgangsdateien „Ach-se“ (aus 2.4.1) und „FahrleitungAE“ (aus 2.4.2) sowie diejenigen der Zieldatei „Fahrlei-tung“ (aus 2.4.3) und ferner die Daten von „Achse“ und „Fahrleitung“ im Standardfor-mat ITF von INTERLIS. Es gibt Software-Werkzeuge, wie das INTERLIS-Conversion-System ICS, die es erlau-ben, auf konzeptioneller Ebene den Umbau von zwei (oder mehr) gegebenen Klassen in eine neue Klasse (oder mehrere) zu definieren mit Hilfe der beteiligten Datenmodelle und mit geeigneten Umbaufunktionen. Die Umbaufunktion die wir brauchen heisst: Aus den Linien von Klasse „Achse“ Stücke ausschneiden vom Anfangspunkt „km_von“ bis zum Endpunkt „km_bis“ eines Objektes aus der Klasse „FahrleitungAE“, und diesen Linienaus-schnitt zusammen mit dem Wert des Attributes „Jahr_erste_Elektrifizierung“ aus der Klasse „FahrleitungAE“ abspeichern als neues Objekt der Klasse „Fahrleitung“.



[……]

TABL Fahrleitung

OBJE 0.0000.0100 1924

STPT 537875.40604 152041.99120

LIPT 537984.59908 152018.12626

ARCP 538041.11107 151980.47901

[..]

ARCP 566299.34338 118421.92351

LIPT 566299.35779 118418.30702

ELIN

[.....]

OBJE 1763.3040.7744 1925

STPT 681720.79964 248756.00813

LIPT 681721.16279 248758.52014

ARCP 681761.91402 248844.22701

[..]

LIPT 683823.44151 247149.25542 0.000 -263.000

LIPT 683786.02309 247064.53648

ELIN

ETAB

[……]

Abb. 2.4 : Auszug aus der ITF-Datei der neuen Klasse „Fahrleitung“ (mit Verlauf)

2.4.4 Visualisierung der Fahrleitungsdaten (mit Verlauf) im Geo-Shop Diese ITF-Datei der neuen Klasse „Fahrleitung“ (mit Verlauf) kann als Input für den „GeoShop“ verwenden. Bei der Visualisierung im „GeoShop“ werden die einzelnen Al-tersklassen der Fahrleitungsdaten unterschiedlich eingefärbt (Abb. 2.5).



Abb. 2.5 : Visualisierung der Fahrleitungen im Geoshop (mit Legende)

3 Zukunft

3.1 Wie weiter? Leitgedanken

3.1.1 Datenrichtigkeit Voll nutzbar sind koordinatenbasierte Daten nur dann, wenn in allen Bereichen alles stimmt: Koordinatenreferenz, Datenstruktur, Datenvollständigkeit, Datenrichtigkeit, Datenkonsistenz, Datentopologie, Netzsicht 100%.

3.1.2 Harmonisierung der Datenstrukturen generell Harmonisierung von Datenstrukturen als Grundelement des Zusammenpassens von Daten ist das Fundament der Interoperabilität. Die Umsetzung dieser Aufgabe europa-



weit sicherzustellen ist eine Kernaufgabe der UIC. Ausgegangen muss immer von den heutigen, EDV-mässig bereist im Einsatz stehende Datenstrukturen der einzelnen Bahn-gesellschaften. Langfristziel ist, eine, von der UIC verabschiedete und von den Bahnen getragene, europaweite, harmonisierte Datenstruktur. Der Einsatz einer einheitlichen Software ist ein erster konkreter Harmonisierungsschritt.

3.1.3 Harmonisierung der Datenstrukturen in angrenzenden, nicht abgestimmten Zonen

In Grenzgebieten, wo unterschiedliche Netze zusammenkommen und die Bahnen nicht über die nötigen Ressourcen verfügen, um eine Abstimmungen vorzunehmen, respekti-ve die technischen Anpassungen zu gross wären, können die Datensätze unverändert so stehen gelassen werden wie sie sind. Aus den Arbeiten zur Datenmodellierung geht hervor, dass Daten später immer zusammengebracht werden können. Trotzdem wird empfohlen, die Strukturen auf ihre Konsistenz hin zu prüfen und Unstimmigkeiten möglichst früh zu bereinigen.

3.1.4 Übergang zwischen verschiedenen Koordinatensystemen Damit die Daten in den angrenzenden, nicht harmonisierten Koordinaten zusammen-gebracht werden können, müssen entlang der Streckenabschnitte in den Übergangszo-nen, Fixpunkte in beiden Systemen gerechnet werden. Aus den zwei Koordinatenpaa-ren der identischen Punkte können die Transformationsparameter für den Übergang vom einem ins andere Systeme gerechnet werden. Der Massstabsfaktor der Transforma-tion muss immer 1 sein um vor allem bei Konstruktionsteilen wie Weichen, die Massan-gaben nicht zu verändern.

3.1.5 Abstimmung mit den Referenznetzen der amtlichen Vermessung Die Abstimmung bedingt hier zwingend den Dialog zwischen Eisenbahn und amtlicher Vermessung, um Doppelinvestionen bei der Festlegung des Fixpunktnetzes zu vermei-den. Es macht Sinn, wenn in den Übgangszonen, nebst den Koordinaten der beiden be-nachbarten Systeme als dritte Koordinatenangabe die ETRF89 Werte angebunden wer-den und daraus die Transformationswerte errechnet werden.

3.2 Wie weiter? Konkret Klarheit und Einheitlichkeit bei der Einführung von CNTD, aufbauend auf den bahnge-odätischen Grundlagen dieses Berichtes, soll von Anfang den europäischen Partnerbah-nen der UIC ermöglichen, mit der neuen Koordinatentechnologie die bestmöglichen Re-sultate zu erzielen. Ein Merkblatt soll zuerst für die Bereiche Gleisbau und dann für alle zukünftigen, dar-auf aufbauenden Nutzungen, die Stossrichtung vorgeben.

DankAn alle Mitarbeiter der ETH, der UIC der DB, der SNCF, der SBB welche am Fortschritt der Themen die in diesem Text erläutert sind gearbeitet haben.

13

Integration der Daten der Landeskarte 1:25’000 (VECTOR25) ins Datenmodell

der Amtlichen Vermessung (DM.01-AV-CH)

Robert Balanche, Eidgenössische Vermessungsdirektion/swisstopo

Robert Balanche Seftigenstrasse 164 CH-3084 Wabern


+41 31 963 21 11 +41 31 963 22 97


1 Einleitung Die Daten der Amtlichen Vermessung (AV) sind insbesondere seit Beginn der Umset-zung des Projektes Reform der Amtlichen Vermessung (RAV) immer populärer gewor-den. Dies beruht nicht zuletzt auf der seinerseits gewählten Strategie des modellbasier-ten Konzeptes für die Verwaltung der numerischen Daten. Es handelte sich damals noch um eine visionäre Lösung, von welcher wir heute die Früchte « Nutzen und Er-trag » ernten können. Aufgrund unseres föderalistischen Systems und der dezentralen Organisationsstruktur der Amtlichen Vermessung der Schweiz ist der Arbeitsfortschritt bei der Erstellung der Daten der AV von Kanton zu Kanton und von Region zu Region verschieden. Auch heute noch sind die Daten der AV nicht flächendeckend über die ganze Schweiz vor-handen. Diese Tatsache führt dazu, dass eine ansehnliche Anzahl von Kunden diese sehr genauen und zuverlässigen Daten der AV nicht verwendet. Um dieser fehlenden Flächendeckung begegnen zu können, hat das Departement für Verteidigung, Bevölkerungsschutz und Sport (VBS) in der Strategie der Amtlichen Ver-messung für die Jahre 2004-2007 mit einer Vision für die Folgejahre 1 im Kontext und im Zusammenhang mit der Nationalen Geodaten-Infrastruktur (NGDI) folgendes festge-legt: Die Referenzdaten der NGDI und damit auch die Daten der AV müssen folgende Voraussetzungen erfüllen:

a. ein Datenmodell ist vorhanden, b. sie liegen flächendeckend vor, c. es besteht ein öffentliches Interesse, d. sie entsprechen einer definierten Qualität, e. die Nachführung ist gesichert und f. die Finanzierung ist gesichert.

Damit die Voraussetzung b. der Flächendeckung kurzfristig erreicht werden kann, ist es nötig, einfache provisorische Ersatzprodukte (PEP) zu erstellen. Provisorische Ersatzprodukte (PEP) sind digitale Vektordaten, welche im Datenmodellder AV beschrieben und über die Amtliche Vermessungsschnittstelle (AVS) austausch-bar sind. Deren Aktualität, Genauigkeit und Informationsgehalt erfüllen die Anforde-rungen der AV nicht. Sie dienen ausschliesslich für die Verwendung der AV als Refe-renzdaten für Landinformationssysteme und nicht für die Bedürfnisse des Grund-buchs.Die PEP ergänzen die AV in Gebieten, in welchen noch keine AV-Daten oder nur gra-phische Grundbuchpläne existieren. Sie können auch die bestehenden Bestandteile der digitalen AV-Daten mit fehlenden Informationsebenen oder Themen ergänzen. Es ist vorgesehen, die PEP für die Informationsebenen „Bodenbedeckung“, „Einzelob-jekte“ und „Nomenklatur“ aus bestehenden digitalen Produkten (z.B. VECTOR25 und SwissNames von swisstopo) abzuleiten.Die vorliegenden Ausführungen sind der Schnittstelle für die Überführung der Vektor-daten der Landeskarte 1 : 25'000 (VECTOR25) ins Datenmodell der Amtlichen Vermes-sung (DM.01-AV-CH, Version 24) gewidmet.

1 http://www.swisstopo.ch/data/vd/Documents/Strategie_AV_04_07.pdf

Nächste Schritte in der Interoperabilität Integration Vector25 / AV


2 Vergleich der VECTOR25-Daten mit denjenigen der AV

2.1 Die VECTOR25-Daten VECTOR25 ist das digitale Landschaftsmodell der Schweiz, welches inhaltlich und ge-ometrisch auf der Landeskarte 1 : 25’000 basiert. VECTOR25 gibt die natürlichen und künstlichen Objekte der Landschaft im flexiblen Vektorformat wieder und eignet sich speziell für den Einsatz in geografischen Informationssystemen (GIS). VECTOR25 be-schreibt rund 8.5 Millionen Objekte mit Lage, Form und ihren Nachbarschaftsbeziehun-gen (Topologie) sowie der Objektart und weiteren Sachattributen. Sein Perimeter um-fasst die ganze Schweiz und das angrenzende Ausland entsprechend dem Perimeter der Landeskarte 1 : 25‘000. Die Daten von VECTOR25 werden blattschnittfrei verwaltet. Um die Handhabbarkeit der Daten zu gewährleisten, werden extra grosse Objekte (z.B. aus-gedehnte Waldgebiete) an geeigneten Stellen künstlich aufgetrennt.

2.1.1 Struktur von VECTOR25 VECTOR25 besteht aus 9 thematischen Ebenen:

Thematische Ebene Beschreibung Strassennetz Strassen- und Wegnetz Eisenbahnnetz Eisenbahnnetz Übriger Verkehr Fähren, Seilbahnen usw. Gewässernetz Gewässerachsen und Uferlinien Primärflächen Primäre Bodenbedeckung (Wald, See usw.) Gebäude Diverse Gebäudearten Hecken und Bäume Diverse Objektarten der Vegetation Anlagen Künstliche Areale und Anlagen Einzelobjekte Diverse künstliche Objekte

Jede Ebene umfasst Topologietypen (z.B. Linien der Primärflächen). Pro Ebene und To-pologietyp ist ein Attributsatz definiert, der mindestens aus den Standardattributen (ObjectID, ObjectOrigin, ObjectVal bzw. Objektart, YearOfChange) besteht. VECTOR25 umfasst insgesamt rund 150 unterschiedliche Objektarten (z.B. 2-Klass-Strasse, Bach).

2.1.2 Qualität der VECTOR25-Daten VECTOR25 zeichnet sich durch folgende Qualitätsmerkmale aus:

flächendeckend in homogener Qualität und Form blattschnittfrei über den gesamten Perimeter Lagegenauigkeit: 3-8m (entsprechend der Kartengenauigkeit) Topologie ermöglicht Analysen und Simulationen Objekte haben geometrische Minimal- und Maximaldimensionen ( erleichterte Handhabung)Koordinaten können ohne Topologieverlust auf Meter oder Dezimeter gerundet werdeneindeutige und stabile Objektidentifikation ( Voraussetzung für inkrementelle Nachlieferungen)Einfache Struktur ( Transfer / Einsatz auf anderen GIS und CAD-Systemen problemlos möglich).



2.2 Das Datenmodell der Amtlichen Vermessung Aus dem Projekt « Reform der Amtlichen Vermessung (RAV) » zu Beginn der 90-er-Jahre ist das erste Datenmodell der Amtlichen Vermessung entstanden, das DM93. Die-ses Datenmodell als Bestandteil der Technischen Verordnung über die Amtliche Ver-messung (TVAV)2 legte die Minimalanforderungen fest, welche die Kantone bei der Da-tenerhebung bezüglich Inhalt und Organisation der Daten einzuhalten hatten. Die meis-ten Kantone haben dieses Modell mit kantonalen Anforderungen erweitert; daher basie-ren alle Vermessungen ab 1993 auf diesem Modell. Heute erkennt man die grossen Vor-teile, welche schweizweit einheitlich organisierte und strukturierte Daten in einem ge-meinsamen Datenmodell mit sich bringen Ende der 90-er-Jahre zeigte es sich, dass das Datenmodell der AV überarbeitet und die Kinderkrankheiten korrigiert werden mussten, damit es den neuen Anforderungen ge-recht werden konnte. So wurde am 18. Dezember 2001 das neue Datenmodell der AV, das DM.01-AV-CH publiziert. Unglücklicherweise enthielt dieses neue Datenmodell noch das provisorisch ausformulierte Thema « Gebäudeadressen », da die entsprechen-de Schweizer Norm SN 612040 zum Zeitpunkt der Modellerstellung noch nicht voll-ständig vorlag. Im Juni 2003 endlich wurde die Schweizer Norm « Gebäudeadressen » publiziert und zwei Wochen später wurde das Datenmodell DM.01-AV-CH, Version 24, welches die Vorgaben aus der Norm übernommen hatte, amtlich herausgegeben.

2.2.1 Struktur von DM.01-AV-CH Die Amtliche Vermessung umfasst die nachstehenden 8 Informationsebenen:

1. Fixpunkte2. Bodenbedeckung3. Einzelobjekte4. Höhen5. Liegenschaften 6. Rohrleitungen 7. Administrative Einteilungen

Das Datenmodell der Amtlichen Vermessung gliedert sich in die nachstehenden 20 Themen:

1. FixpunkteKategorie12. FixpunkteKategorie23. FixpunkteKategorie34. Bodenbedeckung5. Einzelobjekte6. Höhen7. Nomenklatur8. Liegenschaften 9. Rohrleitungen 10. Nummerierungsbereiche 11. Gemeindegrenzen12. Bezirksgrenzen13. Kantonsgrenzen 14. Landesgrenzen

2 http://www.admin.ch/ch/f/rs/c211_432_21.html



15. Planeinteilungen16. TS-Einteilung 17. Rutschgebiete 18. PLZ, Ortschaft 19. Gebäudeadressen20. Planrahmen

2.2.2 Qualität der Daten der AV Die Qualitätsanforderungen der Daten der AV sind sehr hoch und werden festgelegt mit den Informationen über die Genauigkeit und die Zuverlässigkeit. Die Qualitätsan-forderungen richten sich nach der Einteilung in die 5 Toleranzstufen, welche in der TVAV, Art. 3 wie folgt definiert wurden:

TS1: Stadtgebiete TS2: Überbaute Gebiete und Bauzonen TS3: Intensiv genutzte Landwirtschafts- und Forstwirtschaftsgebiete TS4: Extensiv genutzte Landwirtschafts- und Forstwirtschaftsgebiete TS5: Das Sömmerungsgebiet und unproduktive Gebiete

Die TVAV definiert in den Art. 28 ff die Genauigkeitsanforderungen je nach Informati-onsebene und Toleranzstufe. Man findet dort beispielsweise für die Ebenen « Liegen-schaften » und « Rohrleitungen » die nachstehenden Genauigkeitsanforderungen: Lagegenauigkeit (Standardabweichung in cm) für einen im Gelände exakt definierten Punkt:

TS2 TS3 TS4 TS53.5 7 15 35

N.B. die TS1 (Stadtgebiete) müssen mindestens die Anforderungen der TS2 erfüllen. Was die Zuverlässigkeit anbelangt, findet man in Art. 33 der TVAV: "Die Zuverlässigkeit ist für alle Punkte der Informationsebenen « Fixpunkte », « Liegen-schaften » und für die Hoheitsgrenzen der Informationsebene « Administrative Eintei-lungen » sowie für spezielle Einzelpunkte nachzuweisen…

3 Datentransfer von VECTOR25 ins DM.01-AV-CH

3.1 Unterschiede in den beiden Datensätzen Gemäss der Beschreibung der Datenstruktur von VECTOR25 und den Daten im Daten-modell der AV gemäss Kapitel 2 erkennt man sofort, dass nicht nur die Objekte ver-schieden strukturiert sind, sondern dass auch die Definition der Informationen unter-schiedlich ist. In der Tat, wenn man die Bodenbedeckung etwas genauer unter die Lupe nimmt, erkennt man, dass die Modellierung derselben Realität unterschiedlich vorge-nommen worden ist. Von Seiten VECTOR25 erhält man z.B. folgende Beschreibung: Die Ebene „Primärflächen“ beschreibt die primäre topografische Bodenbedeckung. Die Flächenar-ten dieser Ebene schliessen sich gegenseitig aus (See und Wald) und bilden ein redundanzfreies, lückenloses Flächennetz. Im Gegensatz zur Landeskarte sind in den Primärflächen interpretierte Siedlungsgebiete enthalten. Einzelgebäude sind in der Ebene Gebäude verwaltet.



Die Informationsebene « Bodenbedeckung » ist in Art. 7, Ziff. b der TVAV wie folgt be-schrieben:

1. Gebäude;2. befestigte Flächen unterteilt in: Strasse/Weg, Trottoir, Verkehrsinsel, Bahn,

Flugplatz, Wasserbecken sowie übrige befestigte Flächen; 3. humusierte Flächen unterteilt in: Acker/Wiese/Weide, Intensivkulturen (weiter

unterteilt in Reben und übrige Intensivkulturen), Gartenanlage, Hoch-/Flachmoor sowie übrige humusierte Flächen;

4. Gewässer unterteilt in: stehendes Gewässer, fliessendes Gewässer sowie Schilf-gürtel;

5. bestockte Flächen unterteilt in: geschlossener Wald sowie übrige bestockte Flä-chen;

6. vegetationslose Flächen unterteilt in: Fels, Gletscher/Firn, Geröll/Sand, Ab-bau/Deponie sowie übrige vegetationslose Flächen.

Zwischen den Informationsebenen der beiden Datensätze erkennt man zwei grosse Un-terschiede: Die Bodenbedeckung gemäss Datensatz von VECTOR25 enthält weder die Gebäude noch die Strassen. Dies bedeutet, dass diesem Umstand beim Transfer der Da-ten von VECTOR25 ins Datenmodell der AV Rechnung getragen werden muss. Diese Elemente müssen anders zusammengefasst und als Gebietseinteilung definiert werden. Nachstehend ein Beispiel, für welches beim Transfer der Daten eine Lösung gefunden werden muss.

Figur 1 : Unterschiede zwischen der Bodenbedeckung von VECTOR25 und dem DM.01-AV-CH

3.2 Übereinstimmung der Objekte Bei der Vorbereitung eines derartigen Datenaustausches muss als einer der ersten Schritte eine eindeutige Korrespondenztabelle für die Zielobjekte definiert werden. Dies ist eine relativ schwierige Aufgabe, welche mit dem Kunden klar abgesprochen werden muss Es kommt dabei vor, dass gewisse Objekte lediglich in einem Datensatz existieren. Was kehrt man vor, wenn ein Objekt lediglich in den Ausgangsdaten existiert; Soll man es ignorieren oder dennoch transferieren, um die Information nicht zu verlieren? Die nachstehenden Tabellen zeigen für jedes Objekt jeder VECTOR25-Informationsebene das zugeordnete Objekt im Datenmodell DM.01-AV-CH.

VECTOR25

Primärflächen(Gebietseinteilung)

Gebäude

Strassen (Polyline)

DM.01-AV-CH

(Flächen)

Bodenbedeckung(Gebietseinteilung)



3.2.1 Strassennetz

Vector25.ObjectVal Beschreibung Target->DM01-AV-CH

Autobahn Autobahn Strasse_Weg Autob_Ri Autobahn richtungsgetrennt Strasse_Weg Autostr Autostrasse Strasse_Weg

Ein_Ausf Ein-/Ausfahrt (Autobahn / Strasse) Strasse_Weg

A_Zufahrt Autobahnzufahrt Strasse_Weg 1_Klass 1. Klass Strasse Strasse_Weg 2_Klass 2. Klass Strasse Strasse_Weg 3_Klass 3. Klass Strasse Strasse_Weg 4_Klass 4. Klass Strasse Strasse_Weg 5_Klass 5. Klass Strasse schmaler_Weg 6_Klass 6. Klass Strasse schmaler_Weg Q_Klass Quartierstrasse Strasse_Weg HistWeg Historischer Weg / Strasse schmaler_Weg PzPiste Panzerpiste schmaler_Weg Parkweg Parkweg schmaler_Weg BrueckLe Alleinstehende Brücke Tunnel_Unterfuehrung_Galerie

GedBruLe Alleinstehende Brücke ge-deckt Tunnel_Unterfuehrung_Galerie

StegLe Alleinstehender Steg Tunnel_Unterfuehrung_Galerie

3.2.2 Eisenbahnnetz


Gt_Bahn Güterbahn Bahngeleise I_Geleis Industriegeleise Bahngeleise MS_Bahn Museumsbahn Bahngeleise NS_Bahn1 Normalspurbahn eingleisig Bahngeleise

NS_Bahn2 Normalspurbahn mehrgleisig Bahngeleise

SS_Bahn1 Schmalspurbahn eingleisig Bahngeleise

SS_Bahn2 Schmalspurbahn mehrglei-sig Bahngeleise

Str_Bahn Strassenbahn Bahngeleise

Str_Bhof Streckenverknüpfung in-nerhalb des Bahnhofareals Bahngeleise

3.2.3 Übriger Verkehr


A_Faehre Autofähre FaehreLS_Bahn Luftseilbahn Luftseilbahn Mat_Bahn Materialbahn Luftseilbahn P_Faehre Personenfähre FaehreSkilift Skilift Skilift



3.2.4 Gewässernetz


Bach Bach Rinnsal Bachachs Bachachse - Bach_U Bachverlauf unterirdisch eingedoltes_oeffentliches_Gewaesser Bisse Bisse Rinnsal Druckl_1 Druckleitung einfach Druckleitung Druckl_2 Druckleitung mehrfach Druckleitung Drucksto Druckstollen Druckleitung Fluss Flussachse - Fluss_U Flussverlauf unterirdisch eingedoltes_oeffentliches_Gewaesser

Kanal Bach ohne erkennbare / eindeutige Fliessrichtung Rinnsal

Seeachse Seeachse - Seeinsel Seeinsel - See Seeufer -

3.2.5 Primärflächen


Z_BaumS Baumschule geschlossener_Wald Z_Fels Fels Fels Z_Fluss Fluss fliessendes Z_Gebue Gebüsch uebrige_bestockte Z_GerGeb Geröll mit Gebüsch Geroell_Sand Z_GerGle Geröll auf Gletscher Geroell_Sand Z_Geroel Geröll Geroell_Sand Z_GerWa Geröll in Wald Geroell_Sand Z_GerWaO Geröll in offenem Wald uebrige_bestockte Z_Glet Gletscher Gletscher_Firn Z_GsPist Graspiste Strasse_Weg Z_HaPist Piste mit Hartbelag Strasse_Weg Z_KiGrub Kiesgrube Abbau_Deponie Z_LeGrub Lehmgrube uebrige_vegetationslose Z_ObstAn Obstanlage uebrige_humusierte Z_Reben Reben Reben Z_See See stehendes Z_Siedl Siedlung uebrige_vegetationslose Z_StauDa Staudamm* uebrige_vegetationslose Z_StauMa Staumauer* Fels Z_SteBru Steinbruch Abbau_Deponie Z_SumGeb Sumpf und Gebüsch uebrige_humusierte Z_Sumpf Sumpf uebrige_humusierte Z_SumWa Sumpf in Wald uebrige_bestockte Z_SumWaO Sumpf in offenem Wald uebrige_humusierte Z_Uebrig Übriges Gebiet Acker_Wiese_Weide Z_Wald Wald geschlossener_Wald Z_WaldOf Wald offen uebrige_bestockte



3.2.6 Gebäude


Z_Gebaeude Gebäude / Einzelhaus GebaeudeZ_Innenhof Innenhof uebrige_befestigte Z_Gasthof Abgelegener Gasthof GebaeudeZ_Huette Hütte GebaeudeZ_Kirche Kirche GebaeudeZ_Kuehlturm Kühlturm Silo_Turm_Gasometer (EO) Z_Lagertank Lagertank GebaeudeZ_Perron Perrondach Bahnsteig (EO) Z_Schiessstand Schiessstand, Schützenhaus GebaeudeZ_Schloss Schloss, Burg GebaeudeZ_Station Station / ÖV Haltestelle Unterstand Z_Treibhaus Treibhaus Unterstand

Z_WBecken Wasserbecken (Schwimm-bäder, ARA) Wasserbecken

3.2.7 Hecken und Bäume


BauReihe Baumreihe schmale_bestockte_Flaeche Hecke Hecke schmale_bestockte_Flaeche OBReihe Obstbaumreihe schmale_bestockte_Flaeche EinBaum Einzelbaum wichtiger_Einzelbaum ObstBaum Obstbaum wichtiger_Einzelbaum

3.2.8 Anlagen Die Ebene Anlagen umfasst die Objektarten Bahnhofareal, Flughafenareal und Flugha-fenbahnhof-areal. Da für diese Objekte keine entsprechenden Elemente im Datenmodell DM.01-AV-CH existieren, werden sie nicht erfasst.

3.2.9 Einzelobjekte Vector25.ObjectVal Beschreibung Target->DM01-AV-CH Antenne Antenne Mast_Antenne ARA Abwasserreinigungsanlage weitere AusTurm Aussichtsturm Aussichtsturm BiStock Bildstock /Wegkreuz Bildstock_Kruzifix Brunnen Brunnen BrunnenDenkmal Denkmal DenkmalDoline Doline weitereDrehsch Drehscheibe Aussichtsturm ElWerk Elektrizitätswerk weitereHoehle Höhle / Grotte Grotte_Hoehleneingang Kamin Hochkamin Hochkamin Kapelle Kapelle Bildstock_Kruzifix KiTurm Kirchturm uebriger_Gebaeudeteil Quelle Quelle QuelleReserv Reservoir Reservoir Schiffst Schiffstation Landungssteg SendeAnl Sendeanlage Mast_Antenne



Turm Turm Aussichtsturm W_Turm Wasserturm Aussichtsturm WaFall Wasserfall weitereZistOff Zisterne offen Reservoir HSP_Ltg Hochspannungsleitung Hochspannungsfreileitung Ruine Ruine Ruine_archaeologisches_Objekt Sender Radiosender Mast_Antenne

3.3 Datentransfer Wenn die Korrespondenztabellen ausgearbeitet worden sind, « genügt es », das Inter-face für den Transfer all dieser Objekte von VECTOR25 nach MD.01-AV-CH zu schrei-ben. Dazu benötigt man ein Werkzeug, mit welchem die Parameter so gesetzt werden können, dass jedes Element aus VECTOR25 in die richtige Ebene von MD.01-AV-CH transferiert wird. Die Erarbeitung eines solchen Interfaces kann nicht über Standard-Konversions-Werkzeuge erfolgen. Es bleibt einem nichts anderes übrig, als sich mit dem Quellcode auseinanderzusetzen und dieses Interface teilweise selbst zu programmieren. Nachstehend ein Auszug des notwendigen Skripts für die Erstellung eines solchen In-terfaces mittels des Werkzeuges « ilitools ». Für dieses Interface, welches für die Modellierung in den Sprachen Französisch, Deutsch und Italienisch vorgesehen ist, war es notwendig, eine « Namens- und Attribut-Tabelle » zu erstellen, so dass das Skript lediglich einmal beschrieben werden musste. Am Anfang des Programmes wird ein Konfigurationsfile gelesen, welches die Zuord-nung des gewünschten Modells definiert. Auszug aus der deutschsprachigen Namenstabelle der Primärflächen von VECTOR25 :

MAP PRI

LANG => D

TOPIC => Bodenbedeckung

TABLE => ProjBoFlaeche

TABLE_NACH => BBNachfuehrung

TABLE_SURFACE => ProjBoFlaeche_Geometrie

OTHER => PEP

Z_GERGEB_VAL => vegetationslos.Geroell_Sand

Z_GERGEB => Z_GerGeb_X-Z_GerGle_X-Z_Geroel_X-Z_GerWa_X

Z_FELS_VAL => vegetationslos.Fels

Z_FELS => Z_Fels_X-Z_StauMa_X

Z_FLUSS_VAL => Gewaesser.fliessendes

Z_FLUSS => Z_Fluss_X

Z_GEBUE_VAL => bestockt.uebrige_bestockte

Z_GEBUE => Z_Gebue_X-Z_GerWaO_X-Z_SumWa_X-Z_WaldOf_X

Z_GLET_VAL => vegetationslos.Gletscher_Firn

Z_GLET => Z_Glet_X

Z_KIGRUB_VAL => vegetationslos.Abbau_Deponie

Z_KIGRUB => Z_KiGrub_X-Z_SteBru_X

Z_SEE_VAL => Gewaesser.stehendes

Z_SEE => Z_See_X

Z_SUMPF_VAL => humusiert.uebrige_humusierte

Z_SUMPF => Z_Sumpf_X-Z_ObstAn_X-Z_SumGeb_X-Z_SumWaO_X



Z_WALD_VAL => bestockt.geschlossener_Wald

Z_WALD => Z_Wald_X-Z_BaumS_X

Z_SOLD_VAL => vegetationslos.uebrige_vegetationslose

Z_SOLD => Z_Siedl_X-Z_LeGrub_X-Z_StauDa_X

Z_UEBRIG_VAL => humusiert.Acker_Wiese_Weide

Z_UEBRIG => Z_Uebrig_X

Z_BEFESTIGT_VAL => befestigt.Strasse_Weg

Z_BEFESTIGT => Z_GsPist_X-Z_HaPist_X

Z_REBEN_VAL => humusiert.Intensivkultur.Reben

Z_REBEN => Z_Reben_X

TMP => 1.0

END_MAP !PRI

Auszug aus dem Skript: Kategorienwahl:

! Here the Category who are inserted into Geroell_Sand (BB)

IF PRI.Z_GERGEB SHPIN_REC.objectval LOC IS_NOT_NULL THEN

PRI.Z_GERGEB_VAL => VAR.ART

PRI_SURFACE

END_IF

…

PROCEDURE PRI_SURFACE

!***********************************************************

! Write the Object and the geometry for the category PRI

!***********************************************************

IF PRI.LANG = 'F' THEN

VAR.ART => OUT.Genre

ELSE

VAR.ART => OUT.Art

END_IF

NEXT_OBJID => OUT.OBJID

ILOUT_WRITE_OBJECT

PRI.TABLE_SURFACE

ILOUT_WRITE_SURFACE

END_PROCEDURE !PRI_SURFACE



3.4 Festgestellte Probleme

3.4.1 Topologische Unterschiede Bevor die Daten gemäss den obigen Tabellenzuordnungen transferiert werden können, sind die topologischen Unterschiede zu untersuchen. In der Tat, wie bereits im Kapitel 3.1. angesprochen, unterscheiden sich die Primärflächen des Produktes VECTOR25 und die Informationsebene Bodenbedeckung der AV. Eine der Schwierigkeiten betrifft die Informationen des Strassennetzes von VECTOR25. Diese sind in VECTOR25 als lineare Strassenachsen definiert, während die Strassen in der AV als flächenartige Information im DM.01-AV-CH ausgeschieden werden. Die Strassenbreiten sind a priori, ausgehend von der Information Strassenachse, nicht be-kannt; man ist vielmehr gezwungen, diese Informationen der Zeichenerklärung zur Landeskarte 1 : 25'000 von swisstopo zu entnehmen, wo für jede Strassenklassierung eine bestimmte Mindestbreite vorgegeben wird. Durch diese zusätzliche attributive In-formation von VECTOR25 kann jedem Strassenelement eine bestimmte Breite zugeord-net werden und daraus können flächenhafte Objekte gebildet werden. Gemäss Flyer « Zeichenerklärung » zu den Landeskarten sind die Strassenklassierungen wie folgt definiert:

1- Kl.-Strasse, (mind. 6m breit) 2- Kl.-Strasse, (mind. 4m breit) Quartierstrasse, (mind. 4m breit) 3-Kl.-Strasse, (mind. 2,8m breit) 4- Kl. Fahrweg (mind. 1,8m breit) 5-Kl. Feld-, Wald-, Veloweg 6- Kl.., Fussweg

Die 5-Kl. und 6-Kl.-Objekte werden als Wege mit linearer Geometrie in die Informati-onsebene « Einzelobjekte » transferiert Die Strassenverbreiterungen, ausgehend von den linearen Objekten, und die Erstellung von gebietseinteilenden Flächenobjekten erfolgt mit konventionellen GIS-Standard-Werkzeugen.



0 25 50 75 100 125 Meter

Figur 2 : Transformation des linearen Strassennetzes in « gebietseinteilende » Flächenelemente

3.4.2 Generalisierung der Daten Die VECTOR25-Daten stammen aus der Digitalisierung der Landeskarten 1 : 25'000, ei-nem kartographischen Produkt mit generalisierten Informationen. Es ist nicht möglich, ausgehend von diesen generalisierten Informationen, die Bedürfnisse der AV oder der provisorischen Ersatzprodukte (PEP) abdecken zu können. Es ist vielmehr nötig, dazu auf weitere Grundlagedaten zurückzugreifen, z.B. durch die Verwendung der Informa-tionen für das Strassennetz, welche mittels des Programmes ATOMI von swisstopo aus den digitalen Orthofotos gewonnen werden. ATOMI ist ein Programm für die automatische Extraktion dreidimensionaler Strassen-achsen aus Orthofotos, dem digitalen Geländemodell sowie dem bereits vorhandenen vektoriellen Strassennetz aus VECTOR25. Die nachstehende Figur 3 zeigt die Überlage-rung der Informationen von VECTOR25 und ATOMI:



0 25 50 75 100 125 Meter

Figur 3 : Überlagerung der VECTOR25-Daten mit denjenigen aus ATOMI

Diese Lösung verbessert die Qualität des Strassennetzes ganz erheblich, bringt jedoch weitere Probleme. Dadurch, dass die Strassen nun « geometrisch richtig » erfasst sind, stellt man fest wie die Gebäude diese Strassen zum Teil überlappen. Zur Lösung dieses Konfliktes sind mehrere Varianten möglich:

Man belässt die Originaldaten aus VECTOR25 ohne Verwendung der Strassen-Informationen aus ATOMI, Man verwendet die Strassenauswertungen aus ATOMI und belässt die aus VECTOR25 erfassten Gebäudeinformationen, auch wenn diese die Strassen überlappen,Man verwendet die Strassenauswertungen aus ATOMI und korrigiert die aus VECTOR25 erfassten Gebäude so, dass man einen kohärenten und realistischen Datensatz erhält. Der dafür notwendige Aufwand ist jedoch nicht zu vernachläs-sigen.

Man kann feststellen, dass die Verbesserung von Datensätzen unweigerlich andere Probleme oder Diskrepanzen aufwerfen. Dabei wird man jedoch auch mit der Kosten-Nutzen-Frage konfrontiert und man wird gezwungen, eine entsprechende Wahl zu tref-fen!



Der ganze Prozess kann wie folgt zusammengefasst werden:

Figur 4 : Integrationsprozess von verschiedenen Datenquellen

3.5 Schlusskontrollen Nachdem man die Vorgehenswahl getroffen hat und die Daten transferiert worden sind, ist die Integrität der daraus resultierenden Daten zu überprüfen. Die AV verlangt eine hohe Qualität der Daten und exakt einzuhaltende Anforderungen, die mit entspre-chenden Werkzeugen geprüft werden. Daher kann nach erfolgreich durchgeführtem Datentransfer ein INTERLIS-file im Datenmodell DM.01-AV-CH generiert werden, wel-ches mit einem entsprechenden Checker geprüft wird. Dabei stellt man fest, dass im so neu erzeugten Datensatz noch viele Fehler und Ungereimtheiten existieren. Nachste-hend einige Beispiele mit den von uns festgestellten Fehlern:

Figur 5 : Ein einziges Zentroïd für 2 verschiedene Flächen

VECTOR25 ATOMI

DM.01

Resultat

ja

Behandlung

manuell

Behandlung

manuell

neinnein

Vorbereitung

der Daten

Vorbereitung

der Daten

Interface



Figur 6 : Resultierende Fläche sehr klein

Figur 7 : Fehlende Punkte: noch zu erzeugen

Figur 8 : No area found for centroid

Figur 9 : Area with unknown centroid

Figur 10 : Area with "n" centroids

Figur 11 : duplicate line Figur 12 : Intersection Figur 13 : partial line overlap

Figur 14 : full line overlap

Für die Elimination obiger Fehler sind entweder weitere Routinen zu programmieren, welche diese Unzulänglichkeiten erkennen und beheben, oder es bedarf manueller Kor-rektureingriffe zur Erstellung eines kohärenten Datensatzes, welcher die Anforderun-gen der AV erfüllt. Auch nach der Vornahme dieser weiteren Verbesserungen gilt es abzuwägen, inwieweit das entstandene Endprodukt den Bedürfnissen des provisori-schen Ersatzproduktes gerecht wird. Können die geringere Qualität und die noch verbleibenden « Ungereimtheiten » akzeptiert werden?



4 Schlussfolgerungen Der Datentransfer von VECTOR25 ins Datenmodell DM.01-AV-CH zeigt, wie wichtig, ja unerlässlich eine Datenbeschreibung ist. Wenn ein Datensatz weder über ein Datenmo-dell noch über eine klare Datenbeschreibung verfügt, ist es praktisch unmöglich, diese Informationen für verschiedene andere Zwecke verwenden zu können. Sie sind nicht mehr „interoperabel“! Eine gute Datenbeschreibung reicht für die Interoperabilität jedoch noch nicht aus. Für die Interoperabilität der Daten bedarf es auch einer exakten Analyse, nicht nur des Da-tenmodells aber auch der Semantik. Man kann feststellen, dass die technische Interoperabilität weniger Probleme aufwirft als die semantische Interoperabilität. In der Tat muss man festhalten, dass der ursprüng-lich erfasste Datensatz für ein bestimmtes, festgelegtes Bedürfnis angelegt worden ist. Wenn man ihn nachher für andere als die ursprünglich vorgesehenen Zwecke verwen-det will, riskiert man, dass die Anforderungen des ursprünglichen Datensatzes nicht mehr denjenigen des zweiten entsprechen. Die semantische Interoperabilität umfasst auch die sprachlichen Probleme. Wenn bei-spielsweise die beiden Datensätze in verschiedenen Sprachen festgelegt worden sind, muss auch die Korrespondenz von Ausdrücken und Definitionen festgelegt werden. Ein technisches Wörterbuch ist bei der Festlegung des Datensatzes in einer Fremdsprache eine grosse Hilfe. Die Interoperabilität von Daten ist eine Notwendigkeit und ein unerlässliches Werkzeug für eine effiziente Nutzung von Informationen, insbesondere von geographischen In-formationen.

LiteraturStrategie der Amtlichen Vermessung für die Jahre 2004 bis 2007 mit Vision für die Folgejahre, Eidgenössisches Departement für Verteidigung, Bevölkerungs-schutz und Sport, Bundesamt für Landestopografie, Eidgenössische Vermes-sungsdirektion.

VECTOR25. Das digitale Landschaftsmodell der Schweiz, Bundesamt für Lan-destopografie.

Transfert des données de VECTOR25 dans le MD.01, Semesterarbeit, A. WILDBOLZ, EIVD 2004.

«Interlis Tools», Dokumentation der Firma Infogrips GmbH.

14

Nationale Geodaten-Infrastruktur (NGDI)

Organisatorische Aspekte der Interoperabilität beim Bund

Rolf Buser, Stv. Leiter KOGIS Koordinationsstelle GI & GIS des Bundes

KOGIS Rolf Buser, Dipl. Ing. ETH Koordinationsstelle GI & GIS (KOGIS) c/o Bundesamt für Landestopografie / swisstopo Seftigenstrasse 264 CH-3084 Wabern


+41 31 963 24 03 +41 31 963 23 25


Unter der Nationalen Geodaten-Infrastruktur (NGDI) wird gemäss der Strategie1 und dem Umsetzungskonzept2 zur Strategie für Geoinformation beim Bund “… ein von allen für die Bereitstellung von Geobasisdaten Verantwortlichen gemeinsam entwickeltes, genutztes und fortgeführtes System von politischen, institutionellen und technologischen Massnahmen verstanden. Dieses System stellt sicher, dass Verfahren, Daten, Technologien, Standards, rechtli-che Grundlagen, finanzielle und personelle Ressourcen zur Gewinnung und Nutzung von Geo-informationen ziel- und bedarfsorientiert den beteiligten Verwaltungen, Organisationen und Bürgern auf allen Entscheidungsebenen (lokal, regional und national) zur Verfügung gestellt werden können.“Diese Umschreibung der NGDI zeigt auf, dass hier eine Infrastruktur entwickelt werden soll, welche hochgradig interoperabel sein muss. Interoperabel einerseits auf der politi-schen, organisatorischen und institutionellen Ebene, andererseits auf der technischen, also der Daten- und Systemebene. Die technische Ebene bringt durch die schnelle Ent-wicklung der Internettechnologien immer bessere Lösungen. Auf dieser Ebene liegt je-doch auch beim Bund weniger das Problem. Technisch lässt sich schon vieles realisieren und es stehen schon gute Lösungen bereit. Auf der politischen, organisatorischen und institutionellen Ebene stehen wir hingegen bezüglich Interoperabilität im Geoinformationsbereich am Anfang. Nachfolgend werden einige organisatorische Aspekte beim Bund im Bereich der NGDI bezüglich Interoperabilität kurz dargelegt.

KontaktnetzAuf dem Weg zu einer NGDI muss die politische, organisatorische und institutionelle Interoperabilität der technischen vorausgehen. Eine gemeinsame Strategie, verbindliche Verfahren, eindeutige Begriffe, sowie genau abgestimmte Forderungen und Erwartun-gen der beteiligten Partner und Institutionen sind nötig. Eine umfassende und stetige „interpersonale“ Kommunikation und der Einbezug von Informationsgemeinschaften sind unabdingbar. Mit der konstituierenden Sitzung für das Kontaktnetz e-geo.ch im Januar 2005 ist ein erster Schritt in Richtung politischer, organisatorischer und instituti-oneller Interoperabilität getan. Das Kontaktnetz soll unter Berücksichtung oder gar Stärkung föderaler Strukturen und heterogener Systeme umgesetzt werden und wird durch ein Steuerorgan geleitet, in welchem sowohl alle Verwaltungsebenen als auch In-stitutionen und die Privatwirtschaft vertreten sind. Die neu gebildete Geschäftsstelle des Kontaktnetzes, welche vorerst vom Bund finan-ziert wird, bildet das Sekretariat des Steuerungsorgans und betreut in erster Linie die Aufgaben, welche ihr vom Steuerungsorgan anvertraut werden.

Geobasisdaten und Geobasisdienste Mit höchster Priorität muss festgelegt werden, „WAS“ die Inhalte der NGDI Schweiz sind. d.h. welche Daten und Dienste die NGDI bereitstellen muss. Hier werden die oben erwähnten Informationsgemeinschaften eine entscheidende Rolle spielen. Innerhalb von eindeutig definierten Tätigkeitsbereichen (z.B. Raumplanung) müssen gemeinsame Vor-stellungen über Modelle von Geobasisdaten- und Geobasisdiensten entwickelt werden. Nur dadurch kann die Interoperabilität auf der Datenebene und später bei angebotenen

1 Strategie für Geoinformation beim Bund, GKG-KOGIS 2001, www.kogis.ch 2 Umsetzungskonzept zur Strategie für Geoinformation beim Bund, GKG-KOGIS 2003, www.kogis.ch

Organisatorische Folgen der Interoperabilität I Nationale Geodaten-Infrastruktur (NGDI): Organisatorische Aspekte der Interoperabilität beim Bund


Diensten erfolgreich sein. Mit der Erstellung des Geobasisdaten-Katalogs des Bundes ist ein erster Schritt getan. Auf der Basis dieses Katalogs kann die Diskussion über Informa-tionsgemeinschaften geführt werden. Beim Bund geht es auf organisatorischer Ebene primär darum, vorhandene Informati-onsgemeinschaften für diese neuen Aufgaben zu motivieren oder den Aufbau von neu-en Informationsgemeinschaften zu unterstützen. Weiter müssen die Entscheidungsträ-ger für diese Bereiche sensibilisiert werden. Der Bund will grundlegende Geodienste bereitstellen und vernetzen. KOGIS koordi-niert die Umsetzung der bundesweiten Plattform, welche auf „produktiven“ Normen basiert, wie jene, die aus den Arbeiten von SNV (Schweizerische Normen-Vereinigung) und OGC (Open Geospatial Consortium) hervorgegangen sind. Auf der organisatorischen Seite muss diskutiert werden, wie ein Register der Geobasis-dienste aufgebaut werden kann, in welchem die Anbieter und deren Geobasisdienste strukturiert beschrieben und kategorisiert sind. Weiter müssen die Geobasisdienste ex-akt beschrieben werden, und es wird festgelegt, wie darauf zugegriffen werden kann und wie sie kommunizieren.

Standards / Normung Der modellbasierte Ansatz ist entscheidend für die Interoperabilität und soll beim Bund in Zukunft eine wichtige Rolle spielen. Folgende Richtlinien und Standards werden auf Bundesebene festgelegt:

die Metadatenbeschreibung erfolgt über das auf der Basis von ISO 19115 entwi-ckelte CH-Profil (im Minimum über das von ISO definierte Core-Profil), die Geodatenmodellierung erfolgt mit der Modellierungssprache UML (Unified Modeling Language) und INTERLIS auf der Basis eines Objektkatalogs, der systemneutrale Austausch von Geobasisdaten und Metadaten erfolgt min-destens auf der Basis der Modellbeschreibung INTERLIS/XML unter Berück-sichtigung der Kompatibilität mit internationalen Standards (z.B. mit GML). die Vernetzung von grundlegenden Geodiensten erfolgt mindestens unter Be-rücksichtigung der Kompatibilität mit den internationalen Standards (wie W3C (World Wide Web Consortium))

Die Bestrebungen im Sinne einer nationalen Plattform Geonormen (NGN) sollen weiter gefördert und auch finanziell unterstützt werden. Die Entwicklung und Anwendung von Geo-Normen und Datenmodellen forciert und koordiniert werden. Datenmodelle und Normen sollen allen interessierten Nutzern zur Verfügung stehen und weiterent-wickelt werden. Dazu sind in einem ersten Schritt vorhandene effiziente aber unkoordi-nierte und ad hoc finanzierte Initiativen und Aktivitäten zu koordinieren und auf eine stabile finanzielle Basis zu stellen. Ziel ist die rasche Verbreitung des Wissens über Nutzen und Anwendung der Daten-modelle und Normen sowie deren konsequente Anwendung. Die Aufgabenbereiche Ausbildung, Technik, Datenmodelle, Support, Normen und Marketing bilden dabei die Haupttätigkeiten.

15

Nationale Profile der internationalen Standards am Beispiel Metadaten

Rudolf Schneeberger, ITV Geomatik AG

Rudolf Schneeberger Dorfstrasse 53 CH-8105 Regensdorf


+41 44 871 21 90 +41 44 871 21 99


1 Einleitung

1.1 Definition von Metadaten Metadaten sind für viele Leute schwammig, undefinierbar und zu technisch, scheinen unwichtig, da die Daten vorhanden sind, werden oft vernachlässigt behandelt, existie-ren nur auf Notizzetteln. Aus diesen Gründen werden Metadaten selten freiwillig er-fasst und nachgeführt. Denn es ist heute dem Benutzer oft nicht ganz klar, wozu sie ei-gentlich dienen.

Laut Definition handelt es sich bei Metadaten um „Daten über Daten“, das heisst es sind beschreibende Daten der effektiven Daten. Zwei weitere Definitionen werden noch et-was klarer:

Unter Metadaten versteht man strukturierte Daten, mit deren Hilfe eine Informa-tionsressource beschrieben und dadurch besser auffindbar gemacht wird.

Metadaten sind maschinenlesbare Informationen über elektronische Ressourcen oder andere Dinge.

Sehen wir uns einmal um, so stellen wir fest, dass wir jeden Tag Metadaten begegnen. Man stelle sich ein Schokoladengestell in einem Einkaufsladen vor, in dem jede Schoko-lade weiss eingepackt ist und „Schokolade“ drauf steht. Welche kaufen Sie? Wahr-scheinlich keine, weil nicht bekannt ist, um was für eine Schokolade es sich handelt. Der Käufer will wissen, ob es eine Schokolade ist mit Nüssen oder ohne, wer sie hergestellt hat, wie sie heisst, wie teuer sie ist, usw. Erst mit diesen Angaben werden die unter-schiedlichen Schokoladen vergleichbar und er kann entscheiden, welches die Richtige ist und bei welcher das Preis/Leistungs-Verhältnis stimmt. Genau gleich verhält es sich mit Metadaten für Geodaten. Sie geben eine genaue Be-schreibung des Geodatenbestandes. Erst wenn man den genauen Inhalt, die Genauig-keit, den Preis, das Modell, das Format und vieles mehr eines Geodatenbestandes kennt, kann man entscheiden, ob er den Ansprüchen genügt. Die wichtigsten Fragen, welche mit Metadaten beantwortet werden sind bei Geodaten:

Organisatorische Folgen der Interoperabilität I Nationale Profile der internationalen Standards am Beispiel Metadaten


WER bietet - Institutionen - Ansprechpartner - Ersteller / Verteiler - Anschrift - Zuständigkeit

WAS und - Datenarten - Erfassungsdatum - Inhalte - Name und Beschreibung - Massstab - Art

WIEVIEL - Datenmenge - Flächendeckung - Status

WORÜBER - Objektarten - Thesaurus - räumlicher Bezug - Fachgebiet - zeitlicher Bezug

WIE in - Format - Datenbank - Schnittstelle - Zugangsberechtigung - Analog / Digital - Zugangsadresse

WELCHEM Zusammenhang - fachliche Bedeutung - Nutzungsrestriktionen und zu - Aufgabenbeschreibung - Eignungshinweis

WELCHEN Konditionen - Preis - Rechtsinhaber - Zugriffsrechte - Vervielfältigungen - Nutzungsrechte

1.2 Metainformation als Teil einer NGDI Das Hauptziel einer Nationalen Geodaten-Infrastruktur (NGDI) besteht darin, über ei-nen leichten Zugang ein optimales Angebot und eine breitere Nutzung von Geoinfor-mation zu bewirken. In dieser NGDI sind Metainformationen ein wesentlicher Bestand-teil.



2 ISO Normen

2.1 Inhalt von ISO von 19115:2003 - Metadata Struktur für die Beschreibung von digitalen geographischen Daten in Form eines abs-trakten Modells (konzeptionelles Metadatenmodell):

Einführung mit Abmachungen und Definitionen

Klassendiagramme als UML-Diagramme

Objektkatalog (Datadictionary)

weitere Anhänge

Die Norm sagt nichts über die Form der Umsetzung in einem GIS oder einer Datenbank aus und ist kein "Kochrezept" für eine Implementierung.

2.2 Profile und Erweiterungen von ISO 19115:2003 - Metadata Die ISO Norm 19115 geht vom Ansatz einer möglichst universellen Anwendung der Norm aus, jedoch mit der Möglichkeit den Gesamtumfang mit Profilen wiederum ein-zuschränken. Die ISO Norm definiert mehr als 300 Metadatenelemente (Klassen, Attri-bute, Beziehungen), wobei die meisten davon optional verwendet werden können.

ProfileProfile erlauben es, Abbildungen aus dem umfassenden ISO-Metadatenmodell für spe-zifische Anwendungen zu erstellen. In jedem Profil muss das minimale ISO-Metadatenmodell vollumfänglich integriert sein. Zudem kann das Bedürfnis bestehen, ein Profil zu erweitern.

Erweiterungen Ein Profil kann mit eigenen Metadatenelementen oder sonstigen Änderungen erweitert werden. Die ISO Norm 19115 schreibt im Annex C genau vor, wie die vorgegebenen Strukturen zu erweitern sind und welche Erweiterungen erlaubt sind.

UmfassendesISO Metadatenmodell

(ISO Comprehensive Metadata Profile)

MinimalesISO Metadatenmodell

(ISO Core Metadatacomponents)

Profil XYErweiterung



Regeln für die Erstellung von Profilen 1. Vorhandene Elemente dürfen in eigenen Profilen nicht abgeändert werden.

2. Werden in einer neuen Entitätsmenge bereits bestehende Attribute verwendet, dürfen deren Attribute nicht abgeändert werden.

3. In Erweiterungen ist es erlaubt, ... ... strengere Verbindungstypen festzulegen,

4. ... den Entitäten und Attributen Wertebereiche zu zuweisen,

5. ... bereits vorgegebene Wertebereiche zu kürzen,

6. ... oder zu erweitern.

7. Erweiterungen dürfen aber nicht erlauben, was der Standard verbietet.

3 Schweizer Norm für Metadaten

3.1 Warum braucht es eine Schweizer Norm? Bestehende Metadateninventare sind entweder nur regional (Kantone), fachlich be-schränkt (CDS, GeoMeta, Geostat) oder nicht Internet-tauglich betreffend Suche und Erfassung von Metadaten. Bisherige Metadatenbanken sind nicht kompatibel unterein-ander und sind auch nicht kompatibel zu der ISO Norm 19115:2003. KOGIS ist für die Geodatenkoordination in der Bundesverwaltung verantwortlich und hatte darum auch bei Metadaten Handlungsbedarf. Da KOGIS nicht ein eigenes "Bun-desmodell" entwickeln wollte, wurde in Zusammenarbeit mit einer Arbeitsgruppe aus Kantonen, Hochschulen und Firmen ein Metadatenmodell definiert, das die minimalen Anforderungen aller Beteiligten befriedigt, ISO kompatibel ist und welches vom SNV als Schweizer Norm veröffentlicht wird.

3.2 Von der ISO-Norm zur Schweizer Norm

Schweizer NormSN 612050

INTERLISBeschreibung

GM03Metadatenmodelle

ISO19115:2003

Stellungnahmenzum Entwurf

Pflichtenheftgeocat.ch

geocat.chCatalog Gateway

SIK - GISCDS

ArbeitsgruppeSNV - TK 151

SNVVernehmlassung

Pilotgeocat.ch



Um die Anliegen der Beteiligten in der Schweiz zu berücksichtigen, wurden die beste-henden Metadatenbanken der Schweizerischen Informatik Konferenz GIS (SIK-GIS) und des Bundesamtes für Wald und Landschaft (CDS) mit der ISO-Norm verglichen. Daraus entstand ein erster Entwurf eines Schweizer Metadatenprofils, in dem bereits Teile der ISO-Norm weggelassen wurden. Andere Teile wurden als Erweiterung neu modelliert. Man war sich bewusst, dass mit dem Vergleich lediglich zweier bestehender Metada-tenbanken noch nicht alle Bedürfnisse abgedeckt sein würden. Stellungnahmen von Bundesämtern, Kantonen und weiteren interessierten Stellen ergaben zusätzliche Be-dürfnisse. Das überarbeitete Metadatenmodell war Grundlage für den Schweizer Normentwurf, der Ende 2003 in eine offizielle Vernehmlassung geschickt wurde. Die Resultate dieser Vernehmlassung wurden in einer Arbeitsgruppe (SNV/TK151) be-sprochen. Diese Arbeitsgruppe, bestehend aus Vertretern aller interessierten Stellen, entschied in jedem Fall darüber, ob eine Eingabe berücksichtigt wurde oder nicht. Dar-aus wurde ein definitives Modell erarbeitet, welches Grundlage für die Schweizer Norm ist.Parallel zur Erarbeitung der Schweizer Norm wurde das Portal und der Metadatenser-ver geocat.ch spezifiziert und entwickelt (siehe Kapitel 4).

3.3 Weshalb ISO als Grundlage? ISO ist die internationale Organisation für weltweite Standards.

CEN ist das Europäische Pendant zu ISO und wird ISO 19115:2003 übernehmen.

Die Schweiz ist Mitglied von CEN und deshalb verpflichtet, deren Normen zu ü-bernehmen, also auch ISO 19115:2003.

Nur auf der Basis des internationalen Standards ISO 19915:2003 wird ein Daten-austausch mit anderen Ländern möglich.

3.4 Unterschiede ISO Norm - CH Norm Die Modell-Beschreibung in UML in der Norm ISO 19115:2003 ist zu allgemein gehalten für eine konkrete Umsetzung. Aus diesem Grund wurde in der Schweiz das Modell de-taillierter in INTERLIS 2, dem Schweizer Standard für Datenmodellierung und Daten-austausch, modelliert und mit UML-Notation dokumentiert. Dadurch wird der Konkre-tisierungsgrad erhöht und ein Datenaustausch ermöglicht. INTERLIS 2 beinhaltet Co-dierungsregeln zur automatisierten Generierung einer XML-Schema-Beschreibung, wel-che maschinenlesbar und zum Aufbau einer Datenbankstruktur und einer Applikation verwendet werden kann. Mit diesen Regeln entfällt der Aufwand, neben einer UML-Beschreibung eine XML-Beschreibung in Handarbeit zu erstellen, wie es ISO mit der Norm 19139 zurzeit macht. Wie das Metadatenmodell der ISO kennt auch das Schweizer Metadatenmodell zwei Profile, GM03Core und GM03Comprehensive, welche beide die ISO-Core Metadaten-elemente enthalten. Es wurde jedoch ein anderer Ansatz der Modellierung gewählt (sie-he Abbildung): ISO definiert ein möglichst umfassendes Metadatenmodell (Profil ISO-Comprehensive), schreibt vor, welche Elemente in jedem Profil enthalten sein müssen (ISO-Core) und überlässt es dann jeder Anwendergruppe, daraus ein eigenes Profil zu definieren. In der Schweiz dagegen, wird in die andere Richtung modelliert. Als mini-maler Kern wird GM03Core definiert und durch Vererbung zu GM03Comprehensive erweitert. Die Vorteile des Vorgehens in der Schweiz gegenüber der ISO ist die bei allen



Profilen identische Grundlage, GM03Core, und somit ein garantierter gemeinsamer Nenner für den Austausch.

ComprehensiveMetadatenmodell

LokalesMetadatenmodell

CoreMetadatenmodell


GM03CoreMetadatenmodell

GM03ComprehensiveMetadatenmodell




3.5 Grundsätze bei der Ausarbeitung der Schweizer Norm Als Grundlage wurde ISO 19115:2003 Metadata gewählt:

Alle Metadatenelemente aus ISO-Core werden auch in GM03Core übernommen.

Es werden alle Metadatenelemente oder Klassen übernommen, die aus den Be-dingungen und Vorgaben der Norm obligatorisch sind.

Es werden die Metadatenelemente definiert, welche notwendig sind, um die be-stehenden Schweizer Datenkataloge abzudecken.

Die Kompatibilität zu ISO 19115:2003 wird soweit sinnvoll sichergestellt: Erweiterungen sind nach den Regeln in Anhang C der ISO-Norm modelliert (z.B. gesetzliche Informationen „Legislation Information“).

Die für die Schweiz notwendige Mehrsprachigkeit ist nach Anhang J der ISO-Norm umgesetzt.

In einzelnen Fällen musste von der ISO-Norm abgewichen werden, damit eine brauch-bare Lösung gefunden werden konnte:

verantwortliche Stelle („Responsible Party“) autorisierte Stelle („Authority“) und Identikator („Identifier“)

Wiederverwendung von Daten in mehreren Instanzen (z.B. „Responsible Party“, Koordinatensystem, etc.) bedingt Abweichung bei der Modellierung der Bezie-hungen

3.6 GM03 Metadatenmodell Um eine minimale Beschreibung von Geodaten zu garantieren, wird das minimale Me-tadatenmodell GM03Core definiert. Zu GM03Core gehören die Metadatenelemente, mit welchen mindestens folgende Fragen beantwortet werden können:

Existiert ein Datenbestand zu einem bestimmten Thema? (WAS)

Gibt es den Datenbestand zu einem bestimmten Ort? (WO)

Bei wem erhalte ich diese Daten? (WER)

In welcher Form kann ich die Daten beziehen? (WIE)

Wann oder in welcher Periode wurde der Datenbestand erstellt oder zuletzt nach-geführt? (WANN)



Das Modell GM03Core umfasst nur die wichtigsten Elemente und deckt nicht alle An-forderungen ab. Deshalb wurde ein umfassenderes Modell GM03Comprehensive aus-gearbeitet, das alle Elemente von ISO enthält und weitere Bedürfnisse der Beteiligten abdeckt.

3.7 Anwendungsbereich der Schweizer Norm SN612050 Die Norm befasst sich mit Metadaten für Geodaten und gilt für Betriebe, die für die Er-fassung, Verarbeitung, Verwaltung und Abgabe von Metadaten verantwortlich sind. Die Norm bezieht sich zwar auf Geodaten, kann aber sinngemäss auch für andere An-wendungsbereiche eingesetzt werden. Die Norm regelt, wie Metadaten konzeptionell strukturiert werden. Sie ermöglicht da-mit ein einheitliches Verständnis aller an Metadaten interessierten Personen und Stellen. Sie regelt aber nicht, wie konkrete Einrichtungen (z.B. Datenbanken) aufgebaut sein sol-len.Die Norm entwickelt selbst keine Technik zur präzisen Beschreibung der Festlegungen. Sie bedient sich dafür existierenden Techniken. Für die Beschreibung des Datenmodells wird die Unified Modelling Language (UML) und die Datenbeschrei-bungssprache INTERLIS 2 verwendet. Die Norm legt den Datenaustausch fest. Als gemeinsames Transferprotokoll wird XML (Regeln nach INTERLIS 2) verwendet.

4 geocat.ch

4.1 Metadatenportal geocat.ch und Geodatenkatalog Die Anforderungen an einen Geodatenkatalog lassen sich auf zwei wesentliche Punkte reduzieren:

Der Geodatenkatalog muss über eine Such-Applikation verfügen, damit erfasste Metadaten gesichtet werden können. Über ein heterogenes und dezentral organi-siertes Metadatenportal wird dieser Geodatenkatalog abgefragt und die ge-wünschten Daten werden dem Benutzer zur Verfügung gestellt.

Der Geodatenkatalog muss über eine Administrations-Applikation verfügen, da-mit die Daten erfasst, verwaltet und aktuell gehalten werden können.

Das Metadatenportal geocat.ch erfüllt genau diese genannten Anforderungen an einen Geodatenkatalog.

4.2 Konkrete Umsetzung Das Hauptziel besteht darin, auf nationaler Ebene ein Portal für die Gesamtheit aller geographischen Metadaten zu verwirklichen. Es wird die Einführung einer dezentrali-sierten Infrastruktur beabsichtigt, welche die dezentralisierte Verwaltung und den Zu-gang auf alle angeschlossenen Metadatenkataloge erlaubt.



user

CatalogManagement

Metadata

Partner A

Benutzer(Oberfläche)Komponentender Infrastruktur

Portal für dieSuche

Gateway

Metadatenkatalog mitseinen Administrations-und Verwaltungstools

Metadatenbank

Partner

Beziehung zwischen eineBenutzer und einerKomponente

Informationsfluss

generaladministrator

catalogadministrat

or

metadatacontributor

CPartner andproducer of

GeodataB

Partner andproducer of

Geodata

Partner andproducer of

GeodataA

Metadata Metadata

Discovery Service1

Database and ToolAdministration

MetadatabaseMetaCH

3

MetadataManagement

Import / ExportSearch Server

Search Server

2Gatew ay and Client of

Metadatabases

KOGIS

catalogadministrat

or

metadatacontributor

catalogadministrat

or

gatewaymanager

user

metadatacontributor

CatalogServer

CatalogGateway

CatalogManagement

DiscoveryService

Es sind zwei Typen von Datenbanken verbunden: Die zentrale geocat.ch-Datenbank, welche erreichbar ist über die Suchapplikation geocat.ch.

Verteilte Datenbanken, die mittels Catalog Gateway mit der Suchapplikation geo-cat.ch verbunden sind.

Für Datenproduzenten von Metadaten sind drei Partnertypen möglich: Datenmanagement direkt in der zentralen Datenbank.

Datenmanagement in eigener Datenbank. Mittels eines Import/Export-Tools wer-den diese Daten in der zentralen Datenbank für die Suchapplikation verfügbar gemacht.

Datenmanagement in eigener Datenbank, welche durch die Suchapplikation über den Catalog Gateway abgefragt werden kann.

4.3 Suchportal Das Suchportal gibt dem Nutzer von Geodaten einen umfassenden und einheitlich strukturierten Überblick und schnellen Zugriff zu notwendigen Informationen über Geodaten, ganz gleich, welche Institution die Geodaten anbietet. Dieser Suchdienst wird nicht zu einer zentralisierten Lösung für die Verwaltung und Verbreitung von geogra-phischen Metadaten verwendet. Im Allgemeinen ist vorgesehen, dass die Metadaten direkt bei den Geodaten produzierenden Partnern mit Hilfe der innerhalb ihrer Institu-tion verfügbaren Infrastruktur verwaltet werden (Partner C).



Die Applikation unterstützt zwei Arten der Suche: die einfache Textsuche und die aus-führliche Suche, bei der nach jedem Element gesucht werden kann. Beiden Such-Arten gemeinsam ist die geographische Suche nach einer Gebietsbezeichnung (z.B. Kanton Bern), innerhalb eines umhüllenden Rechtecks oder innerhalb eines frei definierbaren Polygons.Der Suchdienst muss deshalb einen koordinierten und transparenten Zugriff auf ver-schiedenartige Metadatenbanken ermöglichen. Die Funktionstüchtigkeit einer solchen Lösung bedingt die Verwendung eines gemeinsamen Protokolls für Abfrage und Er-gebnis. Dieses Protokoll, in SOAP (Simple Object Access Protocol) beschrieben, ist rela-tiv kostengünstig implementierbar, sowohl für relationale Datenbanken als auch für XML basierte Lösungen.

Gateway Protokoll

Präsentation der Resultate

geocat.chDiscovery Client

Geocat.chPortal

Anfrage (HTML)

Anfrage(n)

Resultat(e) in XML

GatewayServer(s)

Konsolidierungder Resultate

Detaillierte Anfrage (HTML)

GM03 Anfrage(n)

GM03 Resultat(e) in XMLPräsentation der Resultate

aus GM03 (HTML)

Quellenangaben Vermessung und Geoinformation - GM03 - Metadatenmodell, Ein Schweizer Me-tadatenmodell für Geodaten, SN 612050, Working Draft Version 1.4

ISO Norm 19115:2003, Geographic Information - Metadata

Aufbau eines Nationalen Metadaten-Portals als Teil einer Nationalen Geodaten-Infrastruktur in der Schweiz, Referat von D. Angst (ITV Geomatik AG) und A. Schneider (KOGIS), AGIT 2004 in Salzburg

Pflichtenheft geocat.ch Metadatenkatalog für Geodaten, August 2002

Catalog Gateway Protocol, Mai 2004, KOGIS, Version 0.99

16

Interoperabilität

Nicht nur eine Frage der Technologie

Willy Müller, Informatikstrategieorgan Bund

Willy Müller Informatikstrategieorgan Bund Friedheimweg 14 CH-3003 Bern


+41 31 325 90 35 +41 31 322 45 66


Interoperabilität im Geoinformationsbereich ist das Thema dieser Tagung. Aber was ist Interoperabilität? Nach der Definition in [IEEE 90] ist es, die Fähigkeit von zwei oder mehreren Systemen oder Komponenten, Informationen auszutauschen und die Infor-mation, welche ausgetauscht wurde, zu nutzen. In unserem Kontext geht es primär um die Möglichkeit, geografische Daten auszutauschen. Bis zu einem gewissen Grad ist In-teroperabilität auf irgendeine Weise fast immer gegeben. So kann z.B. ein Vermessungs-büro einen Plan erstellen, ihn auf Papier ausdrucken und per Post an ein anderes Büro versenden, das ihn manuell in sein System überträgt. Wenn wir damit zufrieden wären, wären wir wohl nicht hier. Wir streben eine bessere Interoperabilität an. Das heisst, Inte-roperabilität kann besser oder schlechter sein. Die Güte der Interoperabilität hat dabei zwei Dimensionen: die eine korreliert negativ mit dem Aufwand und den Kosten, die nötig sind, um Daten elektronisch auszutauschen und weiter zu verwerten. Die andere korreliert positiv mit der Menge der Systeme oder Komponenten, welche untereinander Informationen austauschen und weiterverwenden können. Lassen sie uns daher für un-seren Kontext die Definition von [IEEE 90] präzisieren: Interoperabilität ist die Fähigkeit möglichst vieler Systeme oder Komponenten, Daten elektronisch auszutauschen und sie mit möglichst wenig Aufwand, insbesondere ohne manuelle Bearbeitung, weiter zu verwenden.

1 Der Bundesrates will eine reibungslose elektronische Zusammenarbeit

Was hat der Staat zur Interoperabilität – insb. im Bereich der Geoinformationen - zu sa-gen? Soll er sich dazu überhaupt äussern, oder soll er besser die Finger davon lassen? Der Schweizer Staat - und das gilt für Bund, Kantone und Gemeinden gleichermassen - sieht sich in mehrerlei Hinsicht mit der auf den ersten Blick eher technischen Fragestel-lung konfrontiert:

1. Er hat die Aufgabe, für Einwohnerinnen und Einwohner wie auch die Wirtschaft förderliche Rahmenbedingungen zu schaffen.

2. Als Produzent und wichtiger Konsument von Geoinformationen ist er direkt be-troffen.

3. Er muss sich mit den Folgen verbesserter Interoperabilität auseinandersetzen. Der Bundesrat erachtet die Förderung der Informationsgesellschaft in der Schweiz als prioritär. Darüber hinaus will er seine Regierungs- und Verwaltungstätigkeit effizient, flexibel und transparent gestalten. In seiner eGovernment-Strategie hat er dazu drei Stossrichtungen definiert:

1. Voraussetzungen schaffen: Die organisatorischen, technologischen und sicher-heitsspezifischen Voraussetzungen für eine reibungslose Zusammenarbeit in-nerhalb der Verwaltung sollen geschaffen werden.

2. Service excellence: Der Zugang zu den staatlichen Dienstleistungen – und dazu gehört auch die Bereitstellung einer ganzen Menge von Geoinformationen - soll für Privatwirtschaft, Bürgerinnen und Bürger leichter und transparenter werden.

3. Vernetzung: Angestrebt wird die ‚elektronische Integration’ zwischen den Ver-waltungsstellen der verschiedenen Staatsebenen (Bund, Kantone und Gemein-den) sowie zwischen dem Staat und seinen Partnern (öffentliche Hand, Wirt-schaft und Gesellschaft).

Organisatorische Folgen der Interoperabilität I Interoperabilität: nicht nur eine Frage der Technologie


Die Arbeiten zur Förderung der elektronischen Zusammenarbeit im Bereich der Geoin-formationen sind also zu sehen als Teil einer übergeordneten Strategie. Zu diesem Zweck wurde u.a. KOGIS, die Koordinationsstelle für geografische Information und geografische Informationssysteme, ins Leben gerufen (vgl. www.kogis.ch). Die Stoss-richtungen ‚Voraussetzungen schaffen’ und ‚Vernetzung’ haben eine verbesserte Intero-perabilität zum Ziel. Um die Interoperabilität zu steigern, sind dabei Massnahmen auf unterschiedlichen E-benen notwendig. In Anlehnung an das Modell, welches wir im Rahmen der E-Government-Architektur der Schweiz entwickelt haben [eGovCH], sind insbesondere zu unterscheiden:

Politische, rechtliche undorganisatorische Rahmenbedingungen

Technische Basis

Infrastruktur-Services

Daten-Services

Fach-Services Directory Services


Technische Basis


Daten-Services


Technische Basis


Daten-Services



Technische Basis


Daten-Services


Technische Basis


Daten-Services



Technische Basis


Daten-Services


Technische Basis


Daten-Services


Abb. 1 : Bereiche, in denen zur Erreichung einer realen Interoperabilität, auf einander abgestimmte Massnahmen nötig sind.

Technologische Infrastruktur: Rechner, Speicher und Netzwerke für die elektro-nische Verarbeitung und den Datenaustausch, Infrastruktur-Services: Nicht fachspezifische Anwendungen, welche den sicheren und zuverlässigen Datenaustausch ermöglichen, Directory-Services: Elektronische, bei Bedarf maschinenlesbare Verzeichnisse ü-ber Kommunikationspartner und elektronisch zugängliche Dienstleistungen Daten-Services: Definition der Syntax und Semantik, welche gewährleistet, dass Partner ausgetauschte Daten ohne grössere Probleme weiterverwenden können, Fach-Services: Fachanwendungen, welche so geschrieben sind, dass sie mit ande-ren Fachanwendungen zusammenarbeiten können, Organisation, Prozesse und Recht: Organisatorische und rechtliche Rahmenbe-dingungen, welche Interoperabilität zulassen und die Spielregeln für die elektro-nische Zusammenarbeit festlegen.

Erst wenn auf allen Ebenen die geeigneten Voraussetzungen geschaffen sind, ist ein rei-bungsloses Zusammenspiel möglich. Nachfolgend wird exemplarisch auf einige kriti-sche Themenkreise eingegangen. Zur Illustration wird in der Regel auf Beispiele im Geoinformationsbereich Bezug genommen.



2 Erste Stossrichtung: Voraussetzungen schaffen Damit Systeme ohne menschliche Intervention Daten austauschen können, müssen sie sich verstehen. Das ist nur möglich, wenn sie die gleiche Sprache sprechen. Wir begin-nen zu verstehen, wie derartige Sprachen optimalerweise aussehen sollten und wie sie zu dokumentieren sind. Entsprechende Spezifikationen im Geoinformationsbereich sind vorhanden und haben - zumindest teilweise - erste Praxistests bestanden (z.B. INTER-LIS, GML). Darauf im Detail einzugehen, ist nicht die Aufgabe dieses Beitrags. Bei der Auseinandersetzung mit der Spezifikation von Klassen, Konsistenzregeln und Tags ver-gisst man jedoch gerne, dass es letztlich um mehr geht, als die präzise Spezifikation. Auf drei Aspekte soll im Folgenden speziell hingewiesen werden:

der Kampf um die richtige Sprache die Vergabe von Namen und Identifikatoren Verknüpfungen von Daten unterschiedlicher Domänen.

2.1 Der Kampf um die richtige Sprache Unglücklicherweise gibt es keine Naturgesetze, welche sicherstellen, dass es nur eine einzige Sprache gibt. Üblicherweise bilden sich daher mehr oder weniger unabhängig voneinander verschiedene Sprachgemeinschaften mit je eigenen Konventionen. Das ist bei den Geoinformationen nicht anders: Neben nationalen und internationalen Standar-disierungsgremien setzen Softwareanbieter ihre eigenen Datenaustauschformate fest. Solange Mitglieder einer Sprachgemeinschaft lediglich unter sich Daten austauschen möchten, ist dies nicht weiter problematisch. Andernfalls stellen unterschiedliche Spra-chen jedoch ein ernsthaftes Interoperabilitätsproblem dar. Sprachen dienen leider nicht nur der Kommunikation, sondern genauso der Ausgren-zung. Der Entscheidung, wer an der Sprachgemeinschaft teilhaben soll, kommt daher strategische Bedeutung zu. Der Bundesrat spricht sich explizit für eine Vernetzung in-nerhalb der Schweiz und darüber hinaus aus. Gelingt dies, wird sich dadurch allerdings der Wettbewerb zwischen den betroffenen Software- und Datenanbietern verschärfen. Nischen, die sich der eine oder andere geschaffen hat, gehen verloren.

2.2 Verknüpfungen Die Abgrenzung, was als Geoinformation zu betrachten ist, fällt schwerer, als auf den ersten Blick zu erwarten wäre. Im weiteren Sinn fällt darunter alles mit einem geografi-schen Bezug, d.h. alles, was in Beziehung zu einer Koordinate oder einem Areal stand, steht oder stehen wird. Bei genauerem Hinsehen sind das potentiell alle Objekte, welche eine räumliche Ausdehnung besitzen. Denn was eine räumliche Ausdehnung hat, be-findet sich zwangsweise zu einem bestimmten Zeitpunkt an einem bestimmten Ort: Golfclubs, Webcams, Mobilfunkantennen, Raucher, Rinder, Gletscherhahnenfüsse, Gas-leitungen, Niederschläge. Aber damit nicht genug! Selbst alles was mit einem solchen Objekt in Beziehung steht, kann zum Teil von Geoinformationen werden: Windge-schwindigkeiten, Kindersterblichkeit, Sexpraktiken oder Vorlieben für Rotwein. Was bleibt noch übrig? – Nicht viel! Da liegt es nahe, einen zusätzlichen Begriff einzu-führen: die Referenzdaten. Referenzdaten sind Geoinformationen, welche herangezogen werden können, um weitere Informationen darauf zu projizieren. Die Idee ist einleuch-tend, den Begriff präzise zu fassen, jedoch schwierig. Er wurde in den Entwurf des neu-en Geoinformationsgesetzes aufgenommen, und hat in den vorberatenden Gremien zu entsprechend heftigen Diskussionen geführt. Bei genauerem Hinsehen enthalten selbst



einfachste Geoinformationen Angaben zu 'Fremdobjekten', beispielsweise Länder, Kan-tone oder Gemeinden, Nationalstrassen, Hauptstrassen und Nebenstrassen, Haus- und Parzellennummern. Und mit Sachinformationen kombinierte Geoinformationen - z.B. eine mit geologischen Informationen angereicherte Karte - kann von anderen als Grund-lage für weitere Arbeiten genutzt werden - beispielsweise die Planung von Atom-Endlagern.Wir möchten ein - möglichst weltumspannendes Interoperabilitätsnetz für Geoinforma-tionen schaffen. Dazu sind Normen zur Abbildung von räumlichen Informationen not-wendig, jedoch, wie diese Beispiele verdeutlichen, nicht hinreichend. Zusätzlich brau-chen wir auch Normen zur Abbildung der Angaben, welche mit ihnen verknüpft wer-den sollen. Interoperabilität im Bereich der Geoinformationen kann und darf daher nicht bei den Geoinformationen im engeren Sinn stehen bleiben, sonst ist sie nur von begrenztem Nutzen.

2.3 Vergabe von Namen und Identifikatoren Was wären Landeskarten ohne Ortsbezeichnungen oder Stadtpläne ohne Strassenna-men? Im Gegensatz zur allgemeinen Syntax und Semantik ist es oft nicht, oder nur be-dingt möglich, derartige Namen oder Identifikatoren in Normen oder Standards festzu-halten, dennoch sind sie für die Interoperabilität unabdingbar. Nur wenn zwei Kom-munikationspartner demselben Objekt gleich sagen, wissen sie, dass sie vom Gleichen sprechen. Neben Standardisierungsgremien, welche die notwendigen Normen erarbei-ten, herausgeben und pflegen, brauchen wir Institutionen, welche Objekte, zu denen wir Informationen austauschen möchten, identifizieren und die Listen der vergebenen Iden-tifikatoren aktuell und für alle Betroffenen elektronisch zugänglich publizieren. Idealerweise ist überschneidungsfrei definiert, wer für welche Namensräume zuständig ist. Diese aus technischer Sicht einfach aufzustellende Forderung enthält jedoch im Ein-zelfall einigen Zündstoff. So ist sich die Staatengemeinschaft nicht einig, ob Taiwan ein eigenständiger Staat ist oder lediglich eine – abtrünnige - Provinz Chinas. Die Anerken-nung eines Staates ist ein politischer Akt, der im schlimmsten Fall zum Krieg führen kann.Vor dem Zeitalter der Vernetzung hat jede Anwendung notgedrungen die von ihr benö-tigten Daten selbst verwaltet und identifiziert. Möchte man sie austauschen, bringt das Probleme. In unterschiedlichsten Fachgebieten sind Arbeiten im Gang, diese anzugehen. Ein Beispiel sind die Bemühungen zur Einführung von Identifikatoren für juristische und natürliche Personen. Noch ist für viele Objekte nicht verbindlich geregelt, wer ihre Namen vergibt. Die Fest-legung, wer wofür Namen vergibt, und das Akzeptieren dieser Definitionsgewalt durch die Kommunikationsgemeinschaft sind primär organisatorische und politische Ent-scheide, und diese laufen selten ohne Auseinandersetzungen und Machtkämpfe ab. Hier liegt noch einige Arbeit vor uns.

3 Zweite Stossrichtung: Service excellence Interoperabilität ist kein Selbstzweck. Wir arbeiten daran, weil wir uns davon Vorteile versprechen. Diese Vorteile nutzen wir jedoch erst, wenn die Systeme in Realität zu-sammenarbeiten. Der Bundesrat hat zum Ziel, dass die Behörden die Möglichkeiten der Informationstechnologien nutzen, um der Privatwirtschaft, Bürgerinnen und Bürgern



den Zugang zu ihren Dienstleistungen erleichtern. Dabei ist sowohl die eingehende wie die ausgehende Kommunikation betroffen: Dazu müssen:

die Datenproduzenten die Daten elektronisch erstellen (was, z.B. in der amtlichen Vermessung noch nicht überall der Fall ist) die Daten in geeigneten Formaten und zu realistischen Konditionen elektronisch zur Verfügung gestellt werden eine geeignete Infrastruktur für den Datenaustausch bereitstehen die Datenempfänger über die geeignete Infrastruktur verfügen, um die Daten ein-zulesen und zu verarbeiten.

Die aufgeführten Bedingungen mögen banal erscheinen. In der Praxis soweit zu kom-men, dass z.B. die Pläne aller Grundstücke in der Schweiz tatsächlich elektronische er-fasst sind und die Programme, welche sie verwalten, dazu in der Lage sind, sie elektro-nisch auszutauschen, ist alles andere als trivial. Dazu sind ist Überzeugungsarbeit bei Amtlichen Vermessern, Gemeindepräsidenten und Politikern notwendig und sind teil-weise grössere Investitionen unumgänglich. Selbstverständlich arbeitet auch der Bund daran, seine Geoinformationsdaten einfach elektronisch zugänglich zu machen.

4 Dritte Stossrichtung: Vernetzung Wir streben nach einer dichteren Vernetzung und besseren Interoperabilität. Systemthe-oretisch betrachtet, modifizieren wir damit die Interaktionsregeln innerhalb eines dy-namischen Systems. Dies muss unweigerlich Auswirkungen auf das Gesamtsystem ha-ben: Es wird sich verändern. Ob wir wollen oder nicht, wir werden nicht darum herum kommen, auf die Veränderungen zu reagieren. Wer strategisch denkt, wird sich nicht damit zufrieden geben. Er wird die möglichen Veränderungen vorwegnehmen und, so gut es geht, gestaltend darauf einwirken wollen. Einige der Felder, in denen Veränderungen bevorstehen, sind die folgenden:

Tarifierung und Finanzierung Authentizität und UrheberrechtDatenschutzVerantwortung der Datenanbieter

4.1 Die Tarifierungs- und Finanzierungsmodelle sind zu überarbeiten.

Noch vor nicht allzu langer Zeit hatten Geoinformationen die Form von Karten oder Plänen und konnten daher wie klassische Güter gehandelt werden. Werden sie in Form von digitalen Datensätzen weitergegeben, ist das nur noch bedingt möglich. Denn digi-tale Informationen können in Sekundenbruchteilen kopiert, transportiert, neu zusam-mengestellt, verändert oder mit neuen Informationen verknüpft werden. Die elektronische Weitergabe schafft jedoch ein neues Potential: Für Partner, Behörden und auch Unternehmen, wird es leichter, Daten einzukaufen und sie zu neuen Produk-ten zu verarbeiten, welche sie dann ihrerseits weiterverkaufen. So gesehen wird der Staat gewissermassen zum Rohstofflieferanten für die weiterverar-beitende Industrie. Für die nachgelagerten Informationsverarbeiter wird die Nutzung der Rohdaten umso interessanter, je kostengünstiger er sie erwerben kann. Ist ihr Preis zu hoch, werden seine eigenen Produkte zu teuer und dadurch weniger attraktiv.



Der Bundesrat verfolgt die Strategie, seine Geodaten den Nutzern zu möglichst günsti-gen Preisen zur Verfügung zu stellen und so für die Wirtschaft förderliche Bedingungen zu schaffen. Er ist bemüht, die Kantone zu einer ähnlichen Strategie zu bewegen. Die gleichzeitig verfolgten Sparanstrengungen auf Seiten des Staates erschweren allerdings eine konsequente Umsetzung.

4.2 Urheberrecht und Authentizität Daten, welche elektronisch weitergegeben werden, sieht man ohne spezielle Massnah-men den Urheber nicht mehr an, und sie können ohne sein Wissen und seine Zustim-mung weiterbearbeitet, ja gar weiterverkauft werden. Ich kann ohne grössere Probleme Video-Dateien vom Internet herunterladen, mit einfachen Programmen bearbeiten, zu-sammenkopieren und das Resultat unter meinem Namen weiterverbreiten. Dies ist bei Geoinformationen nicht anders. Die einfache Kopierbarkeit stellt ganze Geschäftsbereiche vor bisher ungelöste Proble-me. Eingespielte Verrechnungsmechanismen werden ausgehöhlt. Die Durchsetzung des Urheberrechts in der E-Welt ist ein noch nicht gelöstes Problem. Was tun wir z.B. wenn das Kartenwerk der Landestopographie plötzlich in die Hände einer Gruppe gerät, wel-che es auf einem Server in Übersee ins Internet stellt? Die einfache Kopierbarkeit und Modifizierbarkeit produziert noch ein weiteres Problem: Woher weiss ich, ob ich eine autorisierte Version der Daten in den Händen habe? Wie kann ich z.B. sicher sein, ob es sich beim Vermessungsplan, den ich am Bildschirm sehe, um eine autorisierte Kopie handelt? Zwar gibt es erste technologische Ansätze, die hier Abhilfe schaffen wollen wie z.B. die des Digital Rights Management (DRM), doch diese eignen sich für den uns interessie-renden Kontext nur bedingt, da sie für Objekte konzipiert sind, welche als Einheit auf einem bestimmten Gerät abgespielt werden. Die gesetzlichen Grundlagen in diesem Bereich sind erst rudimentär vorhanden, die nö-tigen technischen Lösungen noch ungenügend.

4.3 Datenschutz Die einfache Zugänglichkeit und Verknüpfbarkeit von Geoinformationen bringt auch neue Probleme mit sich. Eines besteht darin, dass es schwieriger wird, Informationen geheim zu halten. Angaben über dasselbe Gebiet aus verschiedenen Quellen können mit relativ geringem Aufwand verglichen und Unterschiede ausgewertet werden. So ist es möglich, Satellitenaufnahmen mit von den lokalen Behörden herausgegebenen Karten abzugleichen. Dabei können gerade Informationen, welche bewusst weggelassen wur-den, Geheimdiensten interessante Aufschlüsse geben... Oder Personendaten können mit Geoinformationen verknüpft werden. Bringt man An-gaben im Telefonbuch, Gebäudeadressen und Kartenmaterial zusammen, kann auf Knopfdruck sichtbar gemacht werden, wer wo wohnt. Trägt eine Person ein eingeschal-tetes Handy bei sich, ist ihr Aufenthaltsort bekannt. Ohne grössere Probleme könnte auf einer Web-Seite eine Karte aufgeschaltet werden, welche anzeigt, wo wer sich gerade befindet. Derartige Informationen können in Katastrophensituationen helfen, Personen aufzufinden. Die Polizei kann sie nutzen, um Verbrecher zu fassen. Sie sind jedoch ge-nauso interessant für Privatdetektive, Geheimdienste und Terroristen. Wenn wir die Interoperabilität verbessern, dürfen wir Massnahmen nicht vernachlässi-gen, welche sicherstellen, dass mit den Informationen kein Missbrauch getrieben wird.



Gegenwärtig tun sich Staat und Politik schwer bei der Festlegung, wie mit elektroni-schen Daten umgegangen werden, was erlaubt und was verboten sein soll. Manche ge-hen beispielsweise soweit, die elektronische Version der Schweizerkarte zu schützens-werten Personendaten zu erklären, da sie potentiell mit Personendaten verknüpft wer-den können.

4.4 Verantwortung der Datenanbieter Interoperabilität ist kein abstrakter Wunsch. Geodaten sind mehr und mehr elektronisch zugänglich, und der Markt beginnt die sich daraus ergebenden Möglichkeiten zu nut-zen. Es ist absehbar, dass sich nach und nach ganze Wertschöpfungsketten aufbauen werden. Ob gewollt oder ungewollt werden die Abnehmer von Daten sich mit steigen-den Kundenwünschen konfrontiert sehen. Diese betreffen einerseits die Stabilität des Angebots: Wer Daten eines anderen nutzt, um daraus eigene Produkte zu generieren, zählt darauf, dass diese auch in Zukunft verfügbar sein werden. Der volkswirtschaftli-che Nutzen wird dann am grössten sein, wenn die Datenanbieter ihre Produkte präzise definieren und ihren Kunden garantieren können, dass ihr Angebot über längere Zeit zur Verfügung stehen wird. Andererseits wird nicht zu vermeiden sein, dass die Kunden auf den Geschmack kom-men und neue Wünsche vorbringen werden, welche die Anbieter unter Druck setzen. So ist beispielsweise vorhersehbar, dass die Forderungen nach höherer Aktualität der Daten steigen werden.

5 Schlusswort Ist Interoperabilität im Geoinformationsbereich Realität, entsteht logisch gesehen ein riesiger Datenpool, zu dem unterschiedliche Parteien ihren Beitrag leisten. Die Beteilig-ten, dazu gehört der Staat genauso wie betroffene private Unternehmen, müssen sich darauf einigen, wer welchen Beitrag zu diesem Datenpool leistet und wie damit umge-gangen werden soll. Der Datenpool an sich stellt ein volkswirtschaftlich nicht zu unter-schätzendes Kapital dar, dessen Wert mit der Menge der darin integrierten Informatio-nen steigt. Wie dieses Kapital bewirtschaftet – oder nicht bewirtschaftet – wird, ent-scheidet darüber, wie gross die Wertschöpfung sein wird.

[eGovS 99] Regieren in der Informationsgesellschaft. Die eGovernment-Strategie des Bun-des. 13. Februar 2002.http://www.isb.admin.ch/imperia/md/content/egoverment/egov_strategie/de/egov_strat_bv_dt.pdf

[IEEE 90] Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.

[IGES 98] Strategie des Bundesrates für eine Informationsgesellschaft in der Schweiz vom 18. Februar 1998.http://www.infosociety.ch/site/propos/references/details.asp?id_fiche=2867#

[eGovCH 05] eGovCH - eGovernment Architektur Schweiz. Informatikstrategieorgan Bund(in Vorbereitung).

17

Interoperabilität auf strategischer und administrativer Ebene

François Golay, ETH Lausanne

François Golay, Prof. Dr. Laboratoire de Systèmes d'information géographique Ecole Polytechnique Fédérale de Lausanne CH-1015 Lausanne


+41 21 693 57 81 +41 21 693 57 90


1 Einleitung Man kann die Interoperabilität vor allem als eine technologische Antwort auf das Bedürf-nis, Geoinformationssysteme zu öffnen, betrachten. Die OGIS spielt weltweit eine zent-rale Rolle für die normierte technologische Entwicklung und die damit verbundenen Systemarchitekturen. Programmmodule, Webservices, etc – erlauben es, eine effiziente Implementierung zu gewährleisten. Schliesslich erlauben die innerhalb der ISO beson-ders unternommenen Normungsarbeiten, diese Konzepte dauerhaft zu verankern. Die vorangegangenen Präsentationen dieses Seminars haben bewiesen, dass das Da-tensharing nicht nur eine Übereinkunft über den Behälter – die Architekturen – aber auch über den Inhalt des Datenaustausches erfordert. Welche Daten sind bei einem Aus-tausch beteiligt? Worauf gründen sich Information über gemeinsame Prozesse? Diese Fragen wurden von Morf und Dorfschmid in der Präsentation „Modellstandardisierungoder semantische Interoperabilität“ [Morf 2005] behandelt. Die Erarbeitung und Normali-sierung von gemeinsamen Modellen stellen eine Antwort auf diese Fragen dar, genauso wie die Identifikation und die Definition von Referenzen, die interoperable Systeme verknüpfen. Die vorhergehenden Redner haben schliesslich betont, dass die Vielfalt der beteiligten Personen und Institutionen, die im Sharing von Informationen [Buser 2005] und Diens-ten einbezogen wurden, eine adäquate Organisation erfordert, die die institutionelle Verantwortung jedes einzelnen Beteiligten respektiert. Wir stellen in diesem Beitrag fest, dass es kein wirksames Datensharing ohne Anerken-nung und Berücksichtigung der Aufgaben und Strategien von jeder der beteiligten Insti-tutionen, insbesondere von Gemeinden, Kantonen und dem Bund, geben wird. Wir pos-tulieren, dass die technische und semantische Interoperabilität nur im Rahmen einer gu-ten, strategischen und administrativen Interoperabilität der beteiligten Institutionen ver-wirklicht werden kann.

2 Föderalistische Organisation der Schweiz und Aufgaben der beteiligten Institutionen

Im Rahmen der Vorstudie zum Projekt e-geo.ch: Organisatorische und technische Aspekte[Moreni & al. 2003] wurde eine Verschachtelung der Entscheidungsebenen auf dem Staatsgebiet am Beispiel der Schweiz vorgeschlagen (Figur 1). Man kann unterschiedli-che Positionierungen der verschiedenen staatlichen, kantonalen und kommunalen Betei-ligten feststellen.Die Arbeitsbereiche der Akteure der verschiedenen Entscheidungsebenen können sich jedoch, ihren Verantwortlichkeiten im Bodennutzungsmanagement entsprechend, er-heblich unterscheiden.

Organisatorische Folgen der Interoperabilität I Interoperabilität auf strategischer und administrativer Ebene


Figur 1 : Verschachtelungen der Entscheidungsebenen auf dem Staatsgebiet

Somit:Sind auf lokaler (kommunaler) Ebene die Grund- und Bodenangelegenheiten vorherrschend. Es handelt sich zuallererst darum, die rechtliche und technische Grund- und Bodenverordnung verlässlich zu dokumentieren und als Bezugs-einheit ist die Parzelle ausschlaggebend. Die Lokalisierung von technischen Inf-rastrukturen, die Verwaltung des bebauten Kulturgutes, usw., sind typische Bei-spiele für diese Ebene.

Auf regionaler (kantonaler) Ebene ist die räumliche Information vor allem ein Werkzeug für die Raumplanung. Die Erwartungen bestehen hauptsächlich im Erhalt von korrekt aktualisierten, und zusammenhängenden Informationen zur Bodennutzung und der Umwelt. Öffentliche Gelände, verseuchte Gebiete, Bo-dennutzungsstatistiken, Räume, die durch natürliche Gefahren bedroht werden, sind einige Beispiele für Informationen auf diesem Niveau.

Auf nationaler (eidgenössischer) Ebene geht es vor allem darum, die Konzeption und Planung von kohärenten Strategien durch zuständige Organisationen und Einrichtungen möglich zu machen. Ein globaler und homogener Zugang zu den Informationen, ohne „Grenzen zwischen den Regionen, stellt eine nötige Vorbe-dingung dar.

Priv

atge

sells

chaf

ten

Bund

Kanton

Gem. Gem. Stadt Gem.

Einr

icht

unge

n öf

fent

liche

n Re

chte

s, z

. B. E

lekt

rizi

täts

wer

ke u

sw.)

Kanton Kanton

NA

TIO

NA

LR

EGIO

NA

LLO

KA

L

Stadt

Etat



3 Datenintegration zwischen verschiedenen Entschei-dungsebenen

Die Primärdaten, die für die Erfüllung der Aufgaben dieser verschiedenen strategischen Niveaus notwendig sind, sind jedoch teilweise dieselben: Indikatoren, welche die Land-schaftsnutzung im Kantonsmassstab angeben, können von den kommunalen Rahmen-nutzungsplänen abgeleitet werden. Bodennutzungsstatistiken auf nationaler Ebene können anhand lokaler Bodennutzungsangaben erstellt werden, usw. Aus Effizienz-gründen sollen die entsprechenden Daten nur ein einziges Mal erstellt und verwaltet werden,und zwar auf der am besten geeigneten Ebene (Dieses Prinzip wird im [INSPIRE 2002]-Bericht für geographische Infrastrukturen und Daten beschrieben) Die oben aufgeführten, speziellen Bedürfnisse jeder Entscheidungsebene müssen unab-hängig von der Einrichtung, die mit deren Realisierung beauftragt ist, bei der Datener-fassung und Verteilung berücksichtigt werden. Einige kürzlich aufgetretene Schwierig-keiten zeugen von den Schwierigkeiten, die auf diese Wechselbeziehung der Bedürfnis-se zurückzuführen sind

Gemeinden, welche Katasterdaten besitzen, geben sich aus Furcht vor einer ü-bermässigen Zentralisierung zurückhaltend, diese Daten der kantonalen Stelle zu übergeben. Wie sollen kantonale Stellen eine umfassende Verwaltung des Kantonsgebiets verwirklichen?

Hingegen haben Kantone, welche Daten in grossem Massstab besitzen, kein Inte-resse daran eine klar dokumentierte, systematische Qualität ihrer Daten zu för-dern. Diese Daten sind folglich nicht brauchbar für Verwaltungsaufgaben auf lo-kaler Ebene.

Einige Kantone widersetzen sich der Harmonisierung von Datenstrukturen, wel-che vom Bund verlangt wird, um einen nahtlosen Datenzugang für die ganze Schweiz zu ermöglichen.

Solche Probleme existieren auch zwischen öffentlichen Einrichtungen und Privaten Un-ternehmen. Wieso war es z.B. notwendig, das Strassennetz für die Bedürfnisse der au-tomobilen Navigation nochmals zu erfassen?

4 Die Interoperabilität auf strategischer und administrativer Ebene – eine entwicklungsbedürftige Ressource !

Die Wiederverwendung von Daten zwischen verschiedenen strategischen Ebenen setzt jedoch voraus, dass jeder Beteiligte einer Entscheidungsebene die Bedürfnisse der ande-ren Entscheidungsebenen kennt (und anerkennt!), und dass er bereit ist, die Datenerfas-sung, für die er zuständig ist, gemäss der Bedürfnisse sämtlicher anderer Partner durch-zuführen.Dieser Anspruch betrifft nicht die technischen und organisatorischen Dimensionen der Interoperabilität, sondern eine Art der Anerkennungsteilung und der Teilung von Ziel-setzungen und Aufgaben. Es ist schwieriger die Interoperabilität auf strategischer und administrativer Ebene durchzuführen, als auf der technischen Ebene, jedoch stellt die Interoperabilität auf strategischer und administrativer Ebene eine Anforderung an die technische, semantische und organisatorische Ebene. Diese Anforderung wird im [INSPIRE 2002] – Bericht beschrieben: administrative interoperability should precede geospa-tial interoperability.



Die Berücksichtigung des Grundsatzes der strategischen und administrativen Interope-rabilität müsste auch die Annahme und die Umsetzung durch alle Beteiligten erleich-tern und eine gute Handhabung der Interoperabilität ermöglichen:

Man sollte versuchen, die Datenerfassung und -verwaltung von gemeinsamen Interesse zu an eine einzige Instanz zu delegieren.

Um eine adäquate Qualität dieser Aufgaben zu garantieren, die den wesentli-chen Bedürfnissen sämtlicher Partner entspricht, müssen die Normen auf dem höchsten Entscheidungsniveau definiert werden (SNV/ASN – Normen für die gesamte Schweiz).

BibliographieBuser, R., 2005, Conséquences organisationnelles de l’interopérabilité, Actes de la jour-née d’étude « Interopérabilité pour l’utilisation généralisée de la géoinformation », mars 2005, A. Carosio éd., ETH Zürich. INSPIRE, 2002, INSPIRE Architecture and Standards Position Paper, JRC-Institute for Envi-ronment and Sustainability, Ispra. Moreni, C. & al., 2003, Etude préliminaire au projet e-geo.ch: aspects organisationnels et techniques, Rapport sur mandat de la COSIG, EPFL-LASIG et ETHZ-Geoinformation. Morf, A. & Dorfschmied, J., 2005, Modèles standardizes ou interopérabilité sémantique, Actes de la journée d’étude « Interopérabilité pour l’utilisation généralisée de la géoin-formation », mars 2005, A. Carosio éd., ETH Zürich.

18

Interoperabilität in der Praxis

Erfahrungen aus Projekten im In- und Ausland

Ivo A. Leiss, Ernst Basler + Partner AG

Ivo A. Leiss, Dr. Zollikerstr. 65 CH-8702 Zollikon


+41 44 395 12 80 +41 44 395 12 34


1 Einleitung Die Interoperabilität bei der Nutzung von Geoinformation ist bei GIS-Projekten im Pla-nungs- und Umweltbereich ein allgegenwärtiges Thema. In der Praxis trifft man auf verschiedene Aspekte der Interoperabilität:

beim Austausch von Geodaten (z.B. mit Auftraggebern oder Partnerfirmen) beim Austausch von Applikationen und Systemen (z.B. Businessapplikationen ohne geografischen Bezug) beim Austausch von Prozessen (z.B. Service zur Geocodierung von Adressen)

Der vorliegende Beitrag soll die Interoperabilität von Geoinformation am Beispiel von ausgewählten Projekten der Firma Ernst Basler + Partner AG im In- und Ausland be-leuchten. Typische Interoperabilitätsprobleme und deren Lösungsansätze werden auf-gezeigt. Die Bedeutung der Interoperabilität für die Zukunft wird bewertet.

2 Beispielprojekte

2.1 Nationale Projekte: Drei kantonale Beispiele Die Interoperabilität bei der Nutzung von Geoinformation in den Kantonen soll anhand drei verschiedener GIS-Projekte beleuchtet werden (Tab. 1).

Projektname (Laufzeit) Auftraggeber Aufgaben Projektpartner

StrassenlärmZürich (2000 – 2005)

Baudirektion des Kantons Zürich, Fachstelle Lärmschutz

Portierung des Strassenlärmkatasters (Emissionen), GIS-Analyselärmbetroffener Gebäude (Immissionen)

Norsonic Brechbühl AGF. Preisig AG GIS-Zentrum Kt. Zürich

Gefahrenhinweis-karte Hochwasser Luzern(2003 – 2005)

Bau-, Umwelt- und Wirtschaftsdepartement des Kantons Luzern, Dienststelle Verkehr und Infrastruktur

Erstellen einer Gefahrenhinweiskarte für den Naturgefahrenprozess Hochwasser im Kanton Luzern, Erstellen eines Ereigniskatasters

Kost+Partner AG ITECOGeoinformation und Vermessung Kt. Luzern

SPATZ Mapserver Graubünden(2004 – 2005)

Archäologischer Dienst, Kanton Graubünden

Darstellung von archäologischen Informationen (SPATZ) in einem Intranet-Kartendienst,Interaktion zwischen dem Archäologischen Informationssystem und dem Kartendienst (z.B. Editieren von Punkten)

GISKompetenzzentrum Kt. GraubündenGWZ Informatik

Tab. 1 : Übersicht über drei kantonale Projekte. Sie dienen als Grundlage für die nachfolgenden Überlegungen.

Organisatorische Folgen der Interoperabilität II Interoperabilität in der Praxis: Erfahrungen aus Projekten im In- und Ausland


2.2 Internationale Projekte: Transnationales Internet Karten-Informationssystem für Überschwemmungen (TIMIS flood)

Das Projekt TIMIS flood hat zum Ziel, für das internationale Einzugsgebiet der Mosel und der Nahe ein transnationales Informationssystem für Überschwemmungen aufzu-bauen. Dabei kommen innovative GIS und IT-Technologien zum Einsatz. TIMIS flood soll folgende Informationen bereitstellen:

harmonisierte und qualitativ hochstehende räumliche Daten, Informationen über Gefahr und Risiko sowie Informationen zur Vorhersage und Warnung.

Sämtliche resultierenden Informationsdienste sollen schliesslich unter einer Plattform namens TIMIS flood Service kombiniert werden. Dieser Service wird den verschiedenen Benutzern (Behörden, Wissenschaftler und Öffentlichkeit) im Jahr 2008 zugänglich sein. Auftraggeber sind sieben verschiedene Behörden aus Luxemburg, Deutschland und Frankreich. Die Firma Ernst Basler + Partner AG ist als Generalunternehmer für die Ko-ordination des Projekts und die Realisierung des Informationssystems verantwortlich. Sie wird unterstützt durch die Firma Hydrotec aus Aachen (Deutschland) sowie durch zahlreiche Subunternehmer im Bereich der Datenerfassung. Weitere Informationen sind unter http://www.timisflood.net erhältlich.

3 Aspekte der Interoperabilität

3.1 Austausch von Geodaten Der Austausch der Geodaten bildet im Rahmen der Beispielprojekte die weitaus grösste Herausforderung im Bereich der Interoperabilität. Zwischen folgenden Beteiligten müs-sen Daten ausgetauscht werden (Abbildung 1):

Ernst Basler + Partner als Auftragnehmer Auftraggeber Projektpartner (Partnerfirmen, Subunternehmer, andere Beteiligte) Externe Geodatenlieferanten (z.B. Swisstopo, Vermessungsbüros)

Abb. 1 : Beteiligte beim Austausch von Geodaten.

Standardisierte Austauschformate werden zum heutigen Zeitpunkt kaum verwendet. In der Regel wird im Vorfeld eines Datenaustauschs ein geeignetes Transferformat – in Abhängigkeit der Möglichkeiten von Quell- und Zielsystem – festgelegt (Tabelle 2).



Austauschformate für Vektordaten Anteil (geschätzt) ESRI (Shape, Coverage, Personal Geodatabase, Exportdatei) 60% CAD (DXF, DGN) 10% Datenbanken und Tabellen (MS Access, MS Excel, dbf) 10% XML 10% sAndere (INTERLIS, ASCII) 10% Austauschformate für Rasterdaten Anteil (geschätzt) Tiff (World, Geo) 50% ESRI (Grid) 20% ASCII 20% Andere 10%

Tab. 2 : Verwendete Formate für den Austausch von Geodaten. Der Anteil bezieht sich auf die Anzahl zu transferierenden Informationen in den Beispielprojekten und ist geschätzt.

Der hohe Anteil an ESRI-Formaten lässt sich damit begründen, dass die Firma Ernst Basler + Partner AG auf ESRI spezialisiert ist und damit häufig Auftraggeber und Pro-jektpartner hat, welche ebenfalls mit ESRI arbeiten. Nur rund 20% aller Daten, welche uns von den Auftraggebern zur Verfügung gestellt werden, beinhalten nutzbare Metainformationen. Aber auch hier hat sich noch kein in-terkantonaler, geschweige denn ein internationaler Standard durchgesetzt.

3.2 Austausch von Applikationen und Systemen Die gemeinsame Nutzung von Applikationen hat in den letzten Jahren an Bedeutung gewonnen. Grund dafür ist die generell zunehmende Vernetzung von Systemen. In den Beispielprojekten kommt dieser Aspekt in den webbasierten Projekten "SPATZ Mapserver" und "TIMIS flood" zum Tragen. Beim archäologischen Informationssystem SPATZ handelt es sich um eine Oracle-Datenbank mit Benutzerschnittstelle für die Datenbewirtschaftung. Der lesende Zugriff auf SPATZ erfolgt via OGR Virtual Format, einem Open Source Treiber, welcher einfa-che Geoobjekte aus einer ODBC-Datenbank anhand einer XML-Konfigurationsdatei liest. Der schreibende Zugriff auf die Oracle-Datenbank wird durch eine Schnittstelle der Firma GWZ Informatik (Vertreiber von SPATZ) sichergestellt. Die Parameter wer-den dabei mittels ASCII-Datei übergeben. Da es sich beim SPATZ Mapserver um eine Intranet-Anwendung handelt, kommen zur Zeit keine OGC-kompatiblen Austauschformate (WFS, WMS) zum Einsatz. Im Projekt TIMIS flood werden die geografischen Informationsdienste zur Zeit basie-rend auf WFS und WMS konzipiert. Für das Internet-Portal (auf Basis von ESRI ArcIMS) ist dies mittlerweile eine Standardfunktionalität. Zum heutigen Zeitpunkt ist jedoch noch nicht sichergestellt, dass alle nationalen Server diese OGC-Formate unterstützen. Wir gehen aber davon aus, dass sich diese OGC-Formate in den kommenden Jahren durchsetzen werden.

3.3 Austausch von Prozessen Die Interoperabilität von Prozessen ist zum heutigen Zeitpunkt noch am wenigsten fortgeschritten. Im Zusammenhang mit Web-Services (z.B. für die Geocodierung von Adressen) wird dieser Aspekt in Zukunft aber immer wichtiger. Der Austausch von Prozessen ist unter den Beispielprojekten einzig im Projekt TIMIS flood vorgesehen. Ab 2008 soll es möglich sein, die Hochwasservorhersage für einen



Standort an der deutschen Mosel (Rheinland-Pfalz) aus der Kombination verschiedener Prozesse zu generieren: aus der Wettervorhersage des deutschen Wetterdienstes, aus den aktuellen Pegelmessungen im Einzugsgebiet (Frankreich, Luxemburg und Deutsch-land), aus einer Abflussvorhersage aus Baden-Württemberg und aus einer hydrauli-schen Modellierung für den entsprechenden Standort in Rheinland-Pfalz. Als Resultat erhält der Benutzer die Hochwasservorhersage in Karten- und Textform (ähnlich wie bei der Wettervorhersage). Die gleichen Prozesse können auch für beliebige Orte in Lu-xemburg beansprucht werden. Noch sind nicht alle Fragen gelöst. Die grössten Hürden liegen jedoch weniger in der technischen Realisierbarkeit, sondern viel eher in der Akzeptanz der verschiedenen (ausländischen) Prozesse und Verfahren. Für eine erfolgreiche Umsetzung sind hier weniger Standards, sondern eher eine gute Kommunikation innerhalb und ausserhalb des Projekts notwendig.

3.4 Interoperabilität und Projektplanung Die oben erwähnten Aspekte kommen zum Tragen, wenn ein Projekt ausgelöst ist. Er-fahrungen in der Praxis haben aber gezeigt, dass der Kosten-, Kommunikations- und Zeitaufwand für die Interoperabilität im Allgemeinen unterschätzt wird. Bei der Pla-nung eines Projekts sind folgende Informationen häufig nicht oder nur unzureichend vorhanden:

Qualität der Geodaten oder der Systeme Neben der grundsätzlich zu prüfenden Qualität der Datengrundlage kann es al-leine aufgrund der genutzten Formate zu Qualitätsproblemen kommen: Ein CAD-Format setzt andere Integritätsregeln auf einen geometrischen Datensatz als ein GIS-Format. Selbst innerhalb verschiedener GIS-Formate bestehen unter-schiedlich strenge Anforderungen an den Aufbau und die Konsistenz der Daten. Erstellung oder Anpassung notwendiger Schnittstellen Während der Bearbeitung eines Projektes kann es passieren, dass aus rein tech-nischen Gründen neue Schnittstellen notwendig werden oder geplante Schnitt-stellen angepasst werden müssen. Vollständige Dokumentationen Bei der Planung werden Eigenschaften der zu nutzenden Daten oder Systeme implizit angenommen, die nicht oder nur unzureichend dokumentiert oder in Metadaten vorhanden sind.

Der Vollständigkeit halber soll auch erwähnt sein, dass Projektideen immer wieder durch zu hohe Tarife für Geodaten wieder begraben werden.

4 Fazit Aus den oben dargestellten Projekten lassen sich bezüglich Interoperabilität bei der Nutzung von Geodaten folgende Folgerungen ableiten:

Bei GIS-Projekten im Planungs- und Umweltbereicht steht heute bezüglich Inte-roperabilität vor allem der Austausch von Daten im Vordergrund. Beim Datenaustausch gelangen kaum Standards zum Einsatz. Am häufigsten werden die Formate ESRI Shape und Tiff verwendet. Dies hängt aber in erster Linie von den Möglichkeiten (der GIS-Software) der Parteien ab. INTERLIS wird zur Zeit (zu) wenig eingesetzt.



XML als Austauschformat ist im Vormarsch, doch wird die Interoperabilität durch die unzähligen Variationen (WFS, GML, ESRI XML, INTERLIS 2, etc.) re-duziert.Die OGC-Formate WFS und WMS werden sich etablieren und zumindest bei in-ternationalen Projekten zum Standard werden. Andere Formate werden vom Markt verschwinden oder ein Nischendasein führen.

Insgesamt ist festzuhalten: Die Anzahl Projekte, bei denen Daten oder Systeme zusam-mengeführt werden müssen, steigt stetig. Aus diesem Grund wird die Interoperabilität von Applikationen und Prozessen in den kommenden Jahren zunehmen. Ob sich in Zu-kunft Standards einstellen oder nicht: wir als Dienstleister im Bereich der Geoinformatik müssen uns ohnehin anpassen; an die Bedürfnisse der Auftraggeber und Projektpartner oder an die vorgegebenen Standards.

Abkürzungen und Begriffe Abkürzung/Begriff Definition ASCII American Standard Code for Information Interchange; Codierung

von insgesamt 128 Zeichen (Buchstaben, Zahlen und Satz- und Sonderzeichen)

CAD Computer Aided Design DXF Vektorbasiertes Dateiformat der Firma Autodesk, speziell für

CAD-Lösungen entwickelt. DGN Vektorbasiertes Dateiformat der Firma Intergraph GIS Geographische Informationssysteme GML Geography Markup Language; XML-basiertes Format für den Aus-

tausch von GIS-Daten Grid Rasterbasiertes Dateiformat der Firma ESRI INTERLIS Datenbeschreibungs- und –modellierungssprache, basiert in der

Version 2 auf XML ODBC Open Data Base Connectivity, Datenbanktreiber für anwendungs-

unabhängige Datenbankzugriffe OGC Open Geospatial Consortium OGR Softwarebibliothek für den Zugriff auf verschiedene GIS Vektor-

formateOracle Softwareanbieter für Datenbanken Shape Dateiformat für Vektordaten, entwickelt von der Firma ESRI Tiff Dateiformat zur Speicherung von Rasterdaten TIMIS Transnational Internet Map Information System SPATZ Synergie Projekt Archäologie Thurgau und Zürich WFS Web Feature Service; Internet-Protokoll zum Lesen und Schreiben

von GIS-Daten im Vektorformat, basiert auf GML WMS Web Map Service, Internet-Protokoll zum Lesen und Schreiben

von digitalen Karten XML Extensible Markup Language; Format zur Erstellung strukturierter

Dokumente

19

Perspektiven für die Geomatik-Berufe

Christian Kaul, Kaul Beratungen GmbH

Kaul Beratungen GmbH Christian Kaul Flaachtalstrasse 8 CH-8412 Hünikon


+41 52 343 79 01 +41 52 343 79 02


Perspektiven für die Geomatik-Berufe … … oder was es braucht, damit das zarte Pflänzchen „Interoperabilität“ zum Blühen kommt.

1 Einleitung Die zentrale Aussage gleich vorweg: Die neuen technischen Möglichkeiten der Interope-rabilität alleine sichern der Geomatik-Branche noch keine neuen Märkte! Interoperabilität ist auch kein technisches Projekt, das nach Abschluss eine Firma inte-roperabel macht. Interoperabilität muss viel mehr zu einer grundlegenden Denkhaltung in allen Geomatik-Berufen werden. Damit können auch die rasanten Entwicklungen der Zukunft in diesem Bereich proaktiv genutzt werden. Damit die Chancen und Möglichkeiten der Interoperabilität neue Perspektiven für die Geomatik-Berufe eröffnen werden, ist das Zusammenspiel von verschiedenen Ebenen und Facetten notwendig. Die technischen Herausforderungen sind dabei nur ein Blatt einer weitgefächerten Blüte.

Technische Fähigkeiten

System-technisches

denkenund

handeln

Arbeit in Multidiszi-plinären

Projekten

PermanenteberuflicheWeiterent-wicklung

VisionärkooperativGeneralist

Organisatorische Folgen der Interoperabilität II Perspektiven für die Geomatik-Berufe


2 In Zentrum - der Unternehmer Im Zentrum steht die unternehmerische Persönlichkeit in Privatwirtschaft und Verwal-tung. Das Thema Interoperabilität kann nicht passiv-reaktiv angegangen werden. Es braucht den visionären Geist, der eine - vielleicht nur vage - Vorstellung davon hat, wo-hin die Reise gehen könnten. Ohne Visionen ist jede Organisation in dieser schnelllebi-gen Zeit früher oder später dem Untergang geweiht. Inter-operability braucht Inter-working. Die Fähigkeit und der Wille zur Kooperation mit anderen Organisationen muss von den Chefs vorgelebt und gefördert werden. Da-bei darf ruhig anerkannt werden, dass andere auch etwas können – denn das ist die Ba-sis der gemeinsamen künftigen Erfolge. Mit der Interoperabilität der Geo-Daten geht eine massive Ausweitung der Daten-Inhalte einher, mit der eine Organisation konfrontiert wird. Damit rückt die alte Fähig-keit des Generalisten wieder mehr ins Zentrum des Interesses. Nach Prof. Dr. Hans Ul-rich ist ein Generalist: "... jemand, der auch in seinem eigenen Wirkungsbereich lange nicht alles weiss, der aber das Ganze versteht." Als integrierende Ergänzung der Spezia-listen in den Unternehmen muss sich der Unternehmer stärker der Übersicht, dem Gan-zen widmen.

3 Die Blütenblätter – das Unternehmen Für die Mitarbeiter eines Unternehmens sind folgende vier Bereiche im Hinblick auf in-teroperables Arbeiten von Bedeutung: Technische Fähigkeiten Das Unternehmen muss die notwendigen Techniken für interoperables Arbeiten beherr-schen. Dabei wird sich das Schwergewicht noch mehr auf die Informatik verlagern. Eine Firma muss in der Lage sein, die sich immer schneller ändernden Bedürfnisse der Kun-den zufrieden zu stellen und gleichzeitig die rasante technische Entwicklung aktiv zu nutzen.Inhaltlich werden die Web-Technologien sehr stark ins Zentrum des Interesses rücken. Die datentechnischen Fähigkeiten müssen aber parallel dazu noch weiter ausgebaut werden.Arbeiten in multidisziplinären Projekten Die Interoperabilität bietet die Chance in themenübergreifenden Projekten effizient zu-sammenzuarbeiten. Dies erfordert eine offene und interessierte Haltung aller Beteiligter bezüglich anderer Themen und anderen Teams und ein Bewusstsein, dass dies nicht von selber erfolgreich geschieht, sondern gelernt und geübt werden kann und muss. Systemtechnisches Denken und Handeln Die Anforderungen an die Produkte der Geomatik-Branche werden auch weiterhin ste-tig steigen. Die einfachen, klaren Antworten werden immer seltener werden. In einem solchen Umfeld haben sich seit Jahren die Grundsätze und Methoden der Systemtechnik bewährt. Diese Art des Denkens und Handelns kann nicht einigen Spezialisten überlas-sen werden, denn sie bildet die Grundlage für ein erfolgreiches interoperables Arbeiten aller Geomatik-Berufe. Permanente berufliche Weiterentwicklung Die oben beschriebenen Anforderungen an die Mitarbeiter können nicht einfach neben dem Alltagsgeschehen entwickelt werden. Es braucht eine aktive, gezielte und vor allem



permanente Weiterentwicklung aller Mitarbeiter. Mit kurzfristigen Feuerwehrübungen können die notwendigen Fähigkeiten in einer Firma nicht nachhaltig erarbeitet und auf-rechterhalten werden.

4 Die Kelchblätter – eine nachhaltige Basis Die UNO definiert nachhaltige Entwicklung als: "... eine Entwicklung, die die Bedürfnis-se der Gegenwart befriedigt, ohne zu riskieren, dass künftige Generationen ihre eigenen Bedürfnisse nicht befriedigen können." Diese Definition ist weitherum anerkannt und bildet die Basis der so genannten "Agenda21" der UNO. Im Zusammenhang mit nachhaltiger Entwicklung werden oft die drei Zieldimensionen Gesellschaft, Wirtschaft und Umwelt beleuchtet. Gesellschaft Durch ihren Hauptauftraggeber, die Öffentliche Hand, haben die Dienstleistungen der Geomatik-Branche traditionell einen grossen Bezug zur Gesellschaft. Aktivitäten im Be-reich der Interoperabilität sind zum Teil sehr stark vom Rahmen der Gesellschaft ge-prägt. Eine sehr grosse Bedeutung muss in diesem Zusammenhang dem Rechtssystem beigemessen werden. Die rechtlichen Rahmenbedingungen sind immer höher einzustu-fen als die technischen. Deshalb bilden gute rechtliche Kenntnisse und eine sorgfältige Analyse dieser Sachverhalte die Grundlage erfolgreicher Projekte und Produkte. Einen weiteren massgebenden Faktor bildet die Normierung. Wie an dieser Tagung aufgezeigt, sind zur Zeit sehr grosse Bestrebungen auf Stufe ISO und CEN im Gange. Hier gilt es, aktiv die langjährige praktische Erfahrung der Schweiz in diese Normie-rungsarbeiten einzubringen. Wirtschaft Das heisst nichts anderes, als dass sich auch die Aktivitäten im Bereich der Interoperabi-lität schlussendlich positiv aufrechnen lassen. Das wird nur gelingen, wenn den Auf-wändungen auch ein entsprechend nachgefragter Nutzen gegenübersteht. Demzufolge definiert der Nutzer und Endkunde die Rahmenbedingungen für die Wirtschaftlichkeit und nicht die eigenen Vorstellungen der Branchen-Insider. Das bedingt jedoch viel bes-sere und ehrlichere Kenntnis der echten Bedürfnisse der Kunden. Diese Überlegungen gelten auch für die staatlich finanzierten Aktivitäten. Ein Geo-Dienst könnte vom Staat, durch Steuergelder finanziert, für den Nutzer unentgeltlich angeboten werden. Doch auch hier muss dem Aufwand an Steuergeldern ein entspre-chender Nutzen gegenüberstehen. UmweltDiese Zieldimension beinhaltet den Umgang mit Ressourcen in einem umfassenden Sinne, also die Aufforderung, die Aktivitäten im Bereich der Interoperabilität mit einem Minimum an Aufwand von Energie, Material, Arbeit und Geld umzusetzen. Im Bereich der Interoperabilität kann dies in erster Linie mit einer exzellenten Nachführbarkeit der Lösungen und einem systemneutralen Investitionsschutz für die Daten erreicht werden. Auch die genialste technische Lösung wird nie nachhaltig sein, wenn sie alle zwei Jahre neu aufgesetzt werden muss. Der gesicherte Investitionsschutz und die konsequente Nachführung der Daten sind eine grosse Verantwortung der Branche gegenüber kom-menden Generationen.



5 Neue Perspektiven dank Interoperabilität Auf der Basis der bisherigen Überlegungen kann gesagt werden:

es wird einfacher, grossflächige regionale oder überregionale Projekte zu bear-beiten

die Zusammenarbeit verschiedener interner und externer Teams wird effizienter

es können gemeinsam Produkte entwickelt und lanciert werden, die für eine einzelne Firma nicht denkbar sind. Z.B. Portallösungen für Geodaten-Nutzung

die bewährte Zusammenarbeit von öffentlicher Hand und Privatwirtschaft (Pub-lic-Private-Partnership PPP) kann vertieft werden

durch die vermehrte Zusammenarbeit und das bessere gegenseitige Verständnis werden sich neue Tätigkeitsfelder eröffnen

die gemeinsame Nutzung von Technologien, Know-how, Kapazitäten (von Mit-arbeitern, HW, SW, etc.) , Datenleitungen, etc. wird attraktiver

bereits vorhandene Fähigkeiten können unter dem Titel "Interoperabilität" besser kommuniziert werden

Weiterführende Informationen: - Buch Systems Engineering, Methodik und Praxis, Hrsg: Daenzer / Huber, Verlag In-

dustrielle Organisation, Zürich, ISBN 3-85743-998-X - Zur Agenda 21: http://www.are.admin.ch/are/de/na

20

Tarifierung, Kostenfragen

Jürg Kaufmann, KAUFMANN Consulting / FIG

Jürg Kaufmann, dipl. Ing. ETH KAUFMANN CONSULTING/FIG Hauffeld 109 CH-8455 Rüdlingen


+41 1 867 14 36 +41 1 867 34 89


1 Einleitung Die folgenden Überlegungen sollen aufzeigen, wie sich die Interoperabilität auf die Kos-tengestaltung und die Festlegung von Tarifen auswirken.Um diese Fragen zu klären seien zunächst einmal einige Begriffe definiert:

Interoperabilität:Zusammenarbeit in einem offenen System (gemäß dem Client/Server--Modell). Unabhängig von der verwendeten Hardware, den eingesetzten Betriebssystemen, der verwendeten Netzwerktech-nologie und der Realisierung einer Anwendung kann eine Zusammenarbeit zwischen diesen Anwendungen erfolgen.

Tarif:1. verbindliches Verzeichnis der Preis- bzw. Gebührensätze für bestimmte Lieferungen, Leis-

tungen, Steuern u. a.2. durch Vertrag od. Verordnung festgelegte Höhe von Preisen, Löhnen, Gehältern u. a.

Tarifieren:die Höhe einer Leistung durch Tarif bestimmen. Der Begriff der Kosten darf wohl als bekannt vorausgesetzt werden. Um die Folgen der Interoperabilität abschätzen zu können wird zunächst der traditio-nelle Ablauf der Leistungserbringung dargestellt. Der Vergleich mit dem Ablauf bei Anwendung der Interoperabilität kann Hinweise auf die Veränderung der Kostenfakto-ren geben. Die Auswirkungen der Interoperabilität auf die Kostenstruktur sollen aufgezeigt wer-den. In einem weiteren Kapitel werden die Überlegungen zur Tarifierung dargestellt. Schliesslich werden die Resultate der Groupe de Réflexion "Datenabgabe und Gebüh-ren", sowie die Arbeiten der KOGIS im Bereich Tarifierung und in Bezug auf die Aus-wirkungen der Interoperabilität beleuchtet. Einige Schlussfolgerungen sollen das zukünftige Verhalten der Informationsgesellschaft skizzieren.

2 Auswirkungen der Interoperabilität auf den Ablauf der Leistungserbringung

Das uns allen bestens bekannte Schema für den Bezug von Leistungen ist in Abbildung 1dargestellt.

Abb. 1 : Schema für den Bezug von Leistungen

Dieser Ablauf war seit Beginn der Handelsaktivitäten des Menschen immer derselbe und er spielt auch heute noch eine dominierende Rolle. Gewisse Neuerungen führten zu

Bestellung

Empfangen der Lieferung

Bezahlung

Anfrage bei Logistik

Bereitstellung der Lieferung

Inkasso

Organisatorische Folgen der Interoperabilität II Tarifierung, Kostenfragen


verkürzten Abläufen, beispielsweise bei der Selbstbedienung oder zu effizienteren Zah-lungsverfahren, wie bei der Verwendung von Strichcodes. Auch das e-shopping läuft nach demselben Schema ab. Die Verkäuferin wird durch ein Terminal und ihre Bera-tung durch Text und Bilder ersetzt. Nur für das Lächeln und die Ausstrahlung der Ver-käuferin oder der Serviertochter kann diese Art der Leistungserbringung nicht überzeu-gend ersetzen. Bei Anwendung der Interoperabilität wird genau dasselbe Schema durchlaufen. Aber alle menschlichen Teilnehmer an der Leistungserbringung sind durch Maschinen er-setzt.Angesichts der hohen Lohnkosten in der Schweiz, muss also die Leistungserbringung grundsätzlich günstiger werden. Da die Leistungen durch Automaten erbracht werden, ist es notwendig, die Abrech-nung automatisch zu erfassen

3 Auswirkungen der Interoperabilität auf die Kosten Die anwendbaren Kostenkomponenten für die Leistungserbringung sind normalerwei-se:

Die Kosten für die Bestellungsaufnahme Die Kosten für die Bestellungsübermittlung Die Kosten der Bereitstellung der Lieferung Die Kosten für die Lieferung Die Kosten für die Rechnungsstellung und das Inkasso.

Im Normalfall werden diese Kosten als Gemeinkostenanteil auf den Preis der gelieferten Ware oder Dienstleistung geschlagen. Gegenüber dem Kunden wird diese Kostenkom-ponente nicht offen gelegt. Gemeinkostenanteile können ermittelt werden, wenn die Be-teiligten an einem Prozess und ihre spezifischen Kosten bekannt sind. Branchenübliche Festlegungen der Gemeinkostenzuschläge sind im traditionellen Sys-tem die Regel. Bei einer interoperablen Arbeitsweise ist aber nicht mehr à priori bekannt, welche Ma-schinen/Systeme/Automaten an der Ausführung einer Lieferung beteiligt sind. Die be-stellte Ware wird dort abgeholt oder eingesehen, wo sie verfügbar ist. Unabhängig davon, wie man einen Preis für die Ware oder die Dienstleistung festsetzt, muss eine Lösung gefunden werden, welche ohne Gemeinkostenzuschlag auskommt. Man muss die Kosten für die Leistungserbringung gesondert betrachten. Da die Leistungserbringung durch Automaten erfolgt, muss die Erfassung der preisbil-denden Faktoren automatisch erfolgen können, weil es im Umfeld der Interoperabilität unmöglich wird, die Wege zu verfolgen und die nötigen Abrechnungsdaten manuell zu erfassen.Es ist zudem wenig sinnvoll jede Komponente, die bei der Leistungserbringung zum Zuge kommt, individuell und mit eigenen Kostensätzen in ein Abrechnungssystem ein-zubringen, da die Preisgestaltung der einzelnen beteiligten Dienstleister wohl niemals über einen Leist geschlagen werden können. Deshalb ist es im Zeitalter der Interoperabilität zwingend, mit vereinbarten Tarifen zu arbeiten.



4 Auswirkungen der Interoperabilität auf die Tarifierung Eine vernünftige Tarifierung der Leistungserbringung ist also eine Notwendigkeit, da-mit die Vorteile der Interoperabilität schliesslich voll zum Tragen kommen. Die Anforderungen an die Tarifierung wurden teilweise bereits bei den Kosten genannt:

Die preisbildenden Faktoren müssen automatisch ermittelt, festgehalten und ab-gerechnet werden können. Die festgelegten Tarife müssen mit dem Aufwand für die Erbringung der Leis-tung in einem sinnvollen Verhältnis stehen. Die Tarife müssen für den Besteller nachvollziehbar sein.

Über die Art der Preisgestaltung sind Lösungsansätze vorhanden, aber es hat sich bisher keine einheitliche Lösung herauskristallisiert.

5 Resultate bisheriger Tarifierungsanstrengungen In der Schweiz existieren zwei Arbeiten, die sich mit der Tarifierung beschäftigen. Ei-nerseits hat eine von der V+D1 eingesetzte, paritätische Groupe de Réflexion sich mit den Problemen der Datenabgabe und Gebühren befasst. Eine weitere Expertenarbeit über Tarifierungsprobleme wurde im Auftrag von KOGIS erstellt. Die Arbeiten dieser Teams wurden auf höchster Stufe koordiniert. Beide Arbeiten kommen zum Schluss, dass für Geodaten eine Strategie der marginal costanzuwenden sei. Marginal cost umfassen ausschliesslich die Bearbeitungs- und Liefer-kosten. Als Begründung für diese Empfehlung wird angeführt, dass Geodaten in der Regel in Erfüllung eines gesetzlichen Auftrags beschafft werden. Dies trifft in der Tat auf die meisten Geodaten zu. Im Entwurf des Geoinformationsgesetzes wird denn auch von Geobasisdaten gesprochen, die von nationalem, kantonalem oder kommunalem In-teresse liegen, je nachdem, welche Stufe den gesetzlichen Auftrag beschlossen hat. Da-mit sind die Investitionskosten, d.h. die Kosten für die Datenbeschaffung von der All-gemeinheit zu übernehmen. Um aber einen möglichst grossen Kostenrückfluss zu gene-rieren, sollen die Daten möglichst günstig an die Interessenten abgegeben werden, da-mit deren Steuern möglichst hoch ausfallen, weil die Gewinne nicht durch Beschaf-fungskosten geschmälert und möglichst gross werden, wenn aus diesen Daten Produkte mit Mehrwert generiert werden können.Im Rahmen der Arbeiten der Groupe de Réflexion wurde nachgewiesen, dass die Investi-tionskostenbeiträge, wie sie durch den Bericht Buschor im Rahmen der Arbeiten zur Re-form der Amtlichen Vermessung vorgeschlagen und in der Mehrzahl der Kantone ein-geführt wurden, keinen signifikanten Beitrag zur Abschreibung der getätigten Investiti-on in die Amtliche Vermessung zu liefern vermag. Bei hohen Preisen wird die Anzahl Bezüge durch die Benützer minimiert indem das Abgaberegime unterlaufen wird. Bei tiefen Preisen werden die Daten zwar häufiger bezogen, aber die eingenommenen Bei-träge fallen zu klein aus, um zu einer sinnvollen Amortisationsdauer zu führen. Die Groupe de Réflexion empfiehlt deshalb, zum Regime der marginal cost, das bis zur Einfüh-rung des Vorschlags Buschor Gültigkeit hatte, zurückzukehren. Die Groupe de Réflexion hat sich ebenfalls über Tarifansätze Gedanken gemacht. Dabei hat sie versucht, die Auswirkungen der Interoperabilität in ihre Betrachtungen einzube-ziehen.

1 Anm. d. Red. : V+D :Eidgenössische Vermessungsdirektion



Sie hat folgende Kostenfaktoren gemäss Abbildung 2 vorgesehen: Komponente Ansatz vorgeschlagener Preis Administrative Bearbeitung eines Auftrages Pauschale pro Auftrag CHF 50.-/Auftrag Technische Bearbeitung eines Auftrages Pauschale pro Auftrag CHF 50.-/Auftrag Vertriebsaufwand für die Ablieferung des Resultates Pauschale pro Auftrag CHF 20.-/Auftrag

Benützung der Infrastruktur für die Erstellung des gewünschten Produktes

CHF/Megabyte bezogener Daten

CHF 5.-/Megabyte Vektordaten(INTERLIS-Format)

Benützung der Internetinfrastruktur bei Bezug der Daten über das Internet Pro Anfrage CHF 10.- pro Anfrage

Abb. 2 : Tarifierungsvorschlag der Groupe de Réflexion

Bei einer bediensten Abgabe kommen die ersten vier Komponenten zur Anwendung. Wird das Internet oder eine andere interoperable Infrastruktur benützt, werden die grau unterlegten Komponenten verrechnet. Ein völlig neuer und transparenter Ansatz ist die Erfassung und Belastung der Menge der tatsächlich bezogenen Daten, wobei bei den Vektordaten das wohldefinierte IN-TERLIS-Format, für Rasterdaten ein Äquivalent zur Anwendung kommt. Mit diesem Ansatz soll die Bereitstellung der Lieferung entschädigt werden. Dem Bezüger wird damit eine Rechnung gestellt, die den Daten, die er bezogen hat, objektiv entspricht. Er kann damit seinen Bezugspreis beeinflussen.Dieses Konstrukt sollte den Herausforderungen der Interoperabilität genügen können. Allerdings sind die Tauglichkeit des Ansatzes und die Höhe der Tarife im praktischen Einsatz zu testen. Die Strategie der marginal cost wurde zwar in den Entwurf zum neuen Geoinformati-onsgesetz aufgenommen. Ob sie zur Anwendung kommt ist vorerst nicht klar. Es ist in jedem Fall weise, die Bearbeitungs- und Lieferkosten separat festzusetzen und damit vom traditionellen Muster des Gemeinkostenzuschlags wegzugehen.

6 Schlussfolgerungen Die Interoperabilität ändert die traditionellen Kostenfragen nicht grundsätzlich, ver-schiebt aber den Schwerpunkt auf hochautomatisierte Prozesse bei der Leistungserbrin-gung. Es müssen einfache und transparente Tarife geschaffen werden, um interoperable Lösungen auch kommerziell sinnvoll auszugestalten. Erste Ansätze sind vorhanden. Diese müssen aber in der praktischen Anwendung aus-probiert und allenfalls den Erfahrungen angepasst werden.

LiteraturGroupe de Réflexion Datenabgabe und Gebühren [2003] 'Vorschlag für die zukünftige Regelung der Datenabgabe und der Gebühren in der Amtlichen Vermessung, V+D, BernGroupe de Réflexion diffusion des données et émoluments [2003] 'Proposition pour la future réglementation de la diffusion des données et des émoluments dans la Mensura-tion Officielle', D+M, Berne KOGISTarif [2002] Neue Tarifierungs- und Vertriebsstrategien von Geodaten des Bun-des, INFRAS im Auftrage von KOGIS, 26. September 2002

21

Georeferenzierung, Interoperabilität zwischen Vermessungsdaten und

darauf aufbauender Rauminformation, Datenhierarchie und Nachführung der

abhängigen Rauminformation

Horst Düster,Amt für Geoinformation Kanton Solothurn

Horst Düster, Dr. Amt für Geoinformation Kanton Solothurn Abteilung SO!GIS Koordination Werkhofstr. 65 CH-4509 Solothurn


+41 32 627 25 32 +41 32 627 22 14


1 Situation Eine kantonale Verwaltung hat Ähnlichkeiten mit einer heterogenen Unternehmens-struktur. Die Verwaltungsorgane verfügen über eine vielfältige Aufgabenstruktur mit gleichzeitiger räumlicher Trennung der Einheiten. Herausragend ist dabei der grosse Informationsbedarf, besonders nach Geoinformationen. Zur Befriedigung dieses Informationsbedarfes steht eine grosse Zahl unabhängig funk-tionierender Informationsquellen bereit. In der Regel weisen diese Quellen Redundan-zen auf. So werden z.B. Grundbuchzugehörigkeiten, Flurnamen von verschiedenen Ob-jekten in unterschiedlichen Datenhaltungssystemen redundant bereit gehalten. Eine konsistente Pflege und Nachführung dieser eigentlich ungebundenen Informationen ist in der Regel unmöglich. Die Folge dieser Situation ist eine ineffiziente Ressourcennutzung, die insbesondere durch Entscheidungsunsicherheit hervorgerufen wird. Im Kanton Solothurn wurde ein GIS Leitbild entworfen, dessen Kernsätze sich auf die Erhöhung der Produktivität, Verbesserung der Entscheidungssicherheit und damit die Erhöhung des operationellen Nutzens sowie die Verbesserung des strategischen Nut-zens mit dem Ziel die staatlichen Strukturen und Instrumente zu verbessern, beziehen.

2 Strategie Die Vision zur strategischen Umsetzung des Leitbildes sieht eine Beschleunigung und Verbesserung der grundlegenden Verwaltungs- und Entscheidungsprozesse durch kon-sistente digitale Geo- und Sachinformationen vor. Dazu müssen Raum- und Sachinfor-mationen logisch und redundanzfrei normalisiert vereint werden können. Die Voraus-setzung dazu ist technische Interoperabilität durch offene Schnittstellen. Um diese nut-zen zu können wird konzeptionelle Interoperabilität durch offene Systeme vorausge-setzt.Aufgrund des Regierungsziels 2005, "... 90% der Standard-Benutzer sowie der Anwen-dungen sind auf Terminalserver unter Linux migriert", wird durch die Abteilung SO!GIS Koordination weitgehend freie und offene Software eingesetzt. Open Source GIS bietet sich zur Umsetzung der Vision auf der Grundlage des Regie-rungsziels an. Da seitens dieser Software kein Interesse besteht, die Anwender an ein herstellerabhängiges System/Produkt zu binden, werden ein grosse Zahl verschiedener Datenformate unterstützt. Ausserdem wird eine breite Unterstützung offener Spezifika-tionen und Schnittstellen wie z.B. die vielfältigen OGC Spezifikationen gewährleistet. Schliesslich sind die verwendeten Systemschnittstellen der Open Source GIS Software offen dokumentiert und frei erhältlich.

3 Systemumgebung Im Kanton Solothurn werden die folgenden Open Source GIS Komponenten im Rahmen einer Multischicht-Architektur eingesetzt. Zur persistenten Datenhaltung wird in der Datenschicht PostgreSQL verwendet. PostgreSQL folgt den Standards SQL92 und SQL99. Mit der Erweiterung PostGIS wird PostgreSQL um den Funktionsumfang der OGC Spezifikation SQL for simple features erweitert. Auf diese Weise steht eine voll-ständig GIS fähige Datenhaltungsschicht, mit der über standardisierte Schnittstellen, als Grundlage zur technischen Interoperabilität, kommuniziert werden kann, zu Verfü-

Spezielle Aspekte der Interoperabilität in der Praxis Georeferenzierung, Interoperabilität zwischen Vermessungsdaten und darauf aufbauender Rauminformation, Datenhierarchie und Nachführung der abhängigen Rauminformation


gung. Diese Umgebung bildet die Grundlage für die normalisierte Datenhaltung und Informationsverarbeitung. Applikationsschichten bzw. Anwendungen müssen deshalb nicht grundsätzlich über GIS-Funktionalität verfügen. Die Applikationsschichten und Applikationen sind den Anforderungen entsprechend vielfältig. Sowohl proprietäre Systeme auf Client-Server Basis über ODBC, JDBC, GDAL/OGR oder nativen Schnittstellen, als auch echte Multischicht-Architekturen, in der Regel Web basierend, werden eingesetzt. Grundsätzlich ist dieser Ansatz unabhängig von den eingesetzten Betriebssystemen, Programmiersprachen und Entwicklungsumgebungen, da die Kommunikation zwi-schen den einzelnen Komponenten standardisiert abläuft.

4 Beispiel Bodenprofil Am Beispiel der Abfrage von Informationen zu einem Bodenprofil soll die Konzeption und Systemumgebung in einem konkreten Fall, wie er in Solothurn umgesetzt ist, illust-riert werden.

4.1 Problemstellung Die Informationen zu einem Bodenprofil sollen redundanzfrei normalisiert abgelegt und gepflegt werden können. Dazu wird eine persistente und normalisierte Datenhal-tung aufgebaut, die in eine Multischicht-Architektur integriert ist. Die Vereinigung der originären Information erfolgt über den Raum auf der Grundlage von SQL92 und dem OGC Standard SQL for simple features. Die Applikationsschicht ist, in diesem Fall, mit Web Technologien aufgebaut. Es werden technisch und konzeptionell offene und inte-roperable Schnittstellen verwendet. Ein Abfrageergebnis soll der Bodentyp sowie die aktuelle Grundbuchnummer der Lie-genschaft, den aktuellen Flurnamen und die aktuelle Höhe, in der das jeweilige Boden-profil liegt, ermittelt werden.

4.2 Lösung Aus der Sicht des Bodenprofils können die originären Informationen die Lage des Pro-fils im Raum als Geometrie und der Bodentyp sein. Sie werden in einer PostgreSQL/PostGIS Datenbank abgelegt und gepflegt. Zur Lösung der Problemstel-lung werden vom Bodenprofil keine weiteren Informationen benötigt. Abgeleitet sind zur Lösung der Fragestellung, aus der Sicht des Bodenprofils, die Informationen aktuel-le Parzellennummer, aktueller Flurname und aktuelle bekannte Höhe. Die abgeleiteten Informationen stammen alle aus dem Datenstamm der amtlichen Vermessung und werden dort unabhängig von den Bodeninformationen, in der PostgreSQL/PostGIS Da-tenbank gepflegt. Die Informationsebenen bilden somit eine flache Hierarchie, die a pri-ori, ausser über den Raum, keine Beziehung zueinander aufweisen. Die Beziehungen werden erst durch die Fragestellung generiert. Wird nun eine Abfrage via SQL for simple features formuliert, an die Datenbank ge-schickt, erfolgt die im SQL Statement formulierte Verschneidung und das System kann mit dem gewünschten Ergebnis antworten. So sieht die SQL Query für die Ermittlung der Grundbuchnummer der Parzelle in der das Profil liegt folgendermassen aus:



select bodenprofil.bodentyp, parzellen.nummer

from bodenprofil, parzellen

where distance(bodenprofil.geometrie,parzellen.geometrie)=0;

Grundsätzlich kann diese Query von jeder beliebigen Applikationsschicht bzw. Appli-kation abgesetzt werden. Die Interoperabilität wird durch ODBC, JDBC, GDAL/OGR oder native aber technisch offen dokumentierte Schnittstellen gewährleistet.

Abb. 1 : Systemarchitektur am Beispiel Bodenprofil



5 Fazit Die vorgestellte Strategie der Multischicht-Systemumgebung in Verbindung mit einer normalisierten Kommunikation zwischen den Komponenten ist sowohl unabhängig von Betriebssystemen als auch von Programmiersprachen, unter der Voraussetzung, dass die Kommunikationsstandards zur Interoperabilität eingehalten werden. So erge-ben sich die folgenden Verbesserungen.

geringere Redundanzen Die seit mehreren Jahren in Solothurn verfolgte Strategie der Normalisierung der Grundlageninformationen führte zur erheblichen Reduktion der Redundanzen in der Grundlagenhaltung, da Objektfremde abgeleitete Informationen nicht mehr mit den je-weiligen Objekten gemeinsam gespeichert werden.

effektiveres Datenmanagement Das Datenmanagement ist vereinfacht und effektiver geworden. Die Nachführung der Grundlagen erfolgt ausschliesslich auf den normalisierten Grundlageninformationen in einer horizontalen Hierarchie.

verbindliche Daten Die normalisierten Grundlageninformationen werden separat gepflegt und aktualisiert. Da die gewünschte Information erst im Moment einer Abfrage generiert wird, konnte die Qualität der Abfrageergebnisse erheblich verbessert und die Entscheidungssicher-heit erhöht werden.

22

Der Mobilitäts-Graph

Ein geographisches Rahmenwerk für die Partner des Mobilitäts-Informationssystems

der Region Genf

Pascal Oehrli, SSIG Genf

Pascal Oehrli SSIG - Service des Systèmes d'Information et de Géomatique DIAE - Département de l'Intérieur, de l'Agriculture et de l'Environnement 7, rue des Gazomètres Case Postale 36 CH-1211 Genève 8


+41 22 327 79 29 +41 22 327 50 70


Das Mobilitäts-Informationssystem der Region Genf (SI Mobilité) ist ein thematisches Informationssystem aufgebaut im Rahmen des Système d’Information du Territoire Ge-nevois (SITG). Die SI Mobilité ist eine Partnerschaft zwischen den verschiedenen Institu-tionen und Beteiligten, die mit Verkehr und deren Infrastrukturen zu tun haben (gilt für alle Verkehrsmittel). Seine Ziele sind es die Daten und Produkte im Bezug auf die Mobi-lität in Genf zu sammeln, organisieren, verwerten, koordinieren und vertreiben.

Die Analyse der Situation hat gezeigt, dass die durch die verschiedenen Partner produ-zierten oder verwalteten Daten voneinander unabhängig, manchmal redundant und direkt in einer Anwendung oder einem Modell insgesamt unbrauchbar waren. Trotz der Existenz eines Routen-Graphs innerhalb der SITG sind von den Beteiligten entspre-chend den berufsspezifischen Bedürfnissen andere Graphe entwickelt worden. Es exis-tierten bis zu 5 oder 6 verschiedene Darstellungen der Geographie der Straßen.

Aufgrund dieser Tatsachen ist eine Vorgehensweise lanciert worden um einen gemein-samen Routen-Graph auszuarbeiten, der die Besonderheiten von jedem der Partner ma-ximal integriert. Es hat sich schnell gezeigt, wie wertvoll es ist, über ein einziges und auf zentrale Art gehaltenes geographisches Bezugssystem verfügen zu können. Als Antwort auf dieses Bedürfnis entstand der Mobilitäts-Graph. Er integriert die Geographie der-verschiedenen der Fortbewegung dienenden Infrastrukturen (Straßen, Wege und Pfade, Schiene und Wasserstraßen) sowie die Verbindungspunkte (Kreuzungen, Bahnsteige und Anlegeplätze). Ein Paket so genannter Anschlussregeln erlaubt das logische Ver-binden verschiedener Komponenten des Mobilitäts-Graphs.

Dieses allen Partnern von SI Mobilité zur Verfügung gestellte geographische Bezugssys-tem erlaubt es, die verschiedenen Daten, welche durch die Partner produziert und ver-waltet werden, zu koordinieren. Diese Daten sind in einem Datenmodell organisiert welches die folgenden Aspekte integriert: die Infrastruktur selbst, die dafür aufgestell-ten Einrichtungen, die Mobilität im Allgemeinen, die verschiedenen angewendeten Ge-setzgebungen, die Mittel zur Umsetzung dieser Gesetzgebungen und die Aspekte der Umwelt oder der Sicherheit. Diese vielfältigen Informationen unterschiedlicher Natur können durch den Mobilitäts-Graphen auf verschiedene Arten wie die lineare Gliede-rung, die Netztopologie oder andere geographische oder nichtgeographische Bezie-hungsmittel koordiniert werden. Ausserdem bildet der Mobilitäts-Graph eine Basis für die Netzanalyse und die Routenberechnung oder anderen zeitlichen oder geographi-schen Abfragen auf einem multimodalen Reisenetz.

Spezielle Aspekte der Interoperabilität in der Praxis Der Mobilitäts-Graph: ein geographisches Rahmenwerk für die Partner des Mobilitäts-Informationssystems der Region Genf


Der Mobilitäts-Graph wird durch den mit der Amtlichen Vermessung beauftragten Dienst verwaltet, auf den neusten Stand gebracht und allen Partnern von SITG frei zur Verfügung gestellt. Als Schlussfolgerung kann man sagen, dass die Existenz eines minimalen gemeinsamen Bezugssystems eine wesentliche Basis für die Interoperabilität in einem Informations-system darstellt, am Beispiel eines Koordinatensystems… oder eines für die linearen Strukturen gemeinsamen Referenz-Graphen. Der gemeinschaftliche Genfer Mobilitäts-Graph, ebenso wie die Vorgehensweise, die zu einer Übereinkunft aller betroffenen Be-teiligten geführt hat und die verschiedenen Modelle, die man durch dynamisches Seg-mentieren daran anknüpfen kann, scheinen ein gutes Beispiel für die Ausarbeitung ei-nes gemeinsamen Bezugssystems zu sein.

Linien TC

MMoobbiilliittäättss--GGrraapphh

Parkplatz

Routen-Graph

Langsamverkehrs-Graph

Halt TC

Eisenbahn-Graph

Wasserstrassen-Graph

Parkplatzzufahrten-Graph

Kreuzungen

Bahnsteig_Bahnhof

Anlegestellen

Anschlüsse

Flughäfen

Fluglinien

Bahnhö-

Interoperabilität für die - ETH Z · NATO das Austauschformat DIGEST (Digitial Geographic...

Documents

Transcript of Interoperabilität für die - ETH Z · NATO das Austauschformat DIGEST (Digitial Geographic...