Interoperabilität - Institute of Geodesy and Photogrammetry (IGP ...

Interoperabilität für die 

breite Nutzung von 

Geoinformation 

Weiterbildungstagung 17. und 18. März 2005 

Herausgegeben von A. Carosio 

Veranstalter 

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

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

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

Fachhochschule beider Basel Nordwestschweiz FHBB 

Schweizerischer Verband für Geomatik und Landmanagement geosuisse 

Konferenz der Kantonalen Vermessungsämter KKVA 

Schweizerische Organisation für Geo-Information SOGI 

Bundesamt für Landestopographie swisstopo 

Koordination der Geoinformationen und der geographischen 

Informationssysteme beim Bund KOGIS 

Schweizerischer Ingenieur- und Architektenverein SIA 

Bundesamt für Landwirtschaft BLW

Deutsche Ausgabe : 

Weiterbildungstagung 17. und 18. März 2005 

IGP Bericht Nr. 298 d 

ISBN 3-906467-51-1 

Interoperabilität für die breite Nutzung von Geoinformation 

Herausgegeben von A. Carosio 

Edition française : 

Journées d‘étude des 17 et 18 mars 2005 

IGP Rapport Nr. 298 f 

ISBN 3-906467-52-X 

Interopérabilité pour l'utilisation généralisée de la Géoinformation 

Textes rassemblés par A. Carosio 

©2005 

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

Alle Rechte vorbehalten

1 Vorwort 

Die Verwirklichung der NGDI (Nationale Geodaten-Infrastrukturen) in Europa und 

weltweit ist unlösbar mit der Problematik der Vernetzung der Geoinformationssysteme 

verbunden. Geodaten gemeinsam nutzen ist eine dringende Notwendigkeit. Dafür 

braucht man technische und organisatorische Lösungen. Das Zauberwort, das zum Ziel 

führen soll, heisst: Interoperabilität! 

In Fachgremien und in Gesprächen mit Fachleuten fällt aber oft auf, dass Fragen und 

Lösungsansätze nur zum Teil bekannt sind. 

Es schien daher angebracht, eine Weiterbildungstagung zu diesem Thema zu organisieren, 

um das verfügbare Wissen zu sammeln, darzustellen und zu präsentieren. 

Wir glauben, dass es durch die Beteiligung der Organisationen, die heute an der Entwicklung 

von interoperablen Systemen arbeiten, gelungen ist, ein vielseitiges Programm 

zusammenzustellen, das die unterschiedlichsten Probleme beleuchtet und beschreibt. 

Den Autoren, die sich freiwillig zur Verfügung stellten, den Mitarbeitern der ETHZ und 

EPFL, die bei der Redaktion der deutschen und französischen Versionen des Berichtes 

mitwirkten sowie allen anderen Beteiligten möchten wir unseren herzlichen Dank aussprechen. 

Alessandro Carosio 

Zürich, 3. März 2005

Organisationskomitee 

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

Alain Buogo, dipl.Ing. KOGIS 

Thomas Glatthard, dipl.Ing. SOGI, geosuisse 

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

Francis Grin, dipl.Ing. EIVD Yverdon 

Jens Ingensand, dipl.Ing. LaSIG-ETH Lausanne 

Peter Jordan, Dr. SIA 

Christian Just, dipl.Ing. swisstopo 

Jürg Kaufmann, dipl.Ing. geosuisse 

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

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

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

Pierre-Alain Trachsel, dipl.Ing. KKVA

Inhaltsverzeichnis 

1 

Interoperabilität in GIS: Anforderungen, Strategien, 

Lösungsansätze 

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

Nationale und internationale Standards 

2 

3 

4 

5 

Überblick 

Urs Flückiger, SOGI Fachgruppe GISTechnologie 

Informatik-Standards (UML, XML, SOAP) 

Prof. Dr. Christine Giger, IGP ETH Zürich 

Weltweite, europäische und schweizerische GeoNormen in 

Wechselwirkung 

Hans-Rudolf Gnägi, IGP-ETH Zürich, OSIG GT Normes 

OpenGeospatial Consortium OGC (GML, WMS, WFS) 

Adrian Annen, FHBB 

Stand der Technik, Implementierungen I 

6 

7 

OGC-Lösungen: Möglichkeiten und Grenzen 

Dr. Andreas Donaubauer, TUM, Prof. Dr. Matthäus Schilcher, 

Anette Huber, TUM 

ISO-Standards für den Datentransfer: Stand der Realisierungen / 

Werkzeuge 

Claude Eisenhut, Eisenhut Informatik AG 

Stand der Technik, Implementierungen II 

Realisierungen im Rahmen der GDI 

8 

9 

10 

Interoperabilität von Geodaten: aktueller Stand und 

Zukunftsperspektiven im Kanton Waadt 

Marc Gilgen, DINF-VD 

Die Komplexität der Interoperabilität: ein einfacher Praxisbericht 

aus der Ostschweiz 

Ueli Forrer, F+P Geoinfo AG 

Modellbasierte und interoperable Bearbeitung der Basisdaten in 

Wallonien 

Jean-Claude Jasselette, MET Belgien

Nächste Schritte in der Interoperabilität 

11 

Modellstandardisierung vs. semantische Interoperabilität: 

aktuelles aus der Forschung 

Andreas Morf, IGP-ETH Zürich, Josef Dorfschmid, ADASYS AG 

Semantische Interoperabilität – aktuelle Projekte 

12 

13 

Datenmigration UIC 

Dr. Théophil Engel, SBB 

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

Datenmodell der Amtlichen Vermessung (DM.01 AV CH) 

Robert Balanche, swisstopo 

Organisatorische Folgen der Interoperabilität I 

14 

15 

16 

17 

Nationale Geodaten-Infrastruktur (NGDI): Organisatorische Aspekte 

der Interoperabilität beim Bund 

Rolf Buser, KOGIS 

Nationale Profile der internationalen Standards am Beispiel 

Metadaten 

Rudolf Schneeberger, ITV Geomatik AG 

Interoperabilität – nicht nur eine Frage der Technologie 

Willy Müller, Informatik Strategie Organ Bund 

Interoperabilität auf strategischer und administrativer Ebene 

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

Organisatorische Folgen der Interoperabilität II 

18 

19 

20 

Interoperabilität in der Praxis: Erfahrungen aus Projekten im In- und 

Ausland 

Dr. Ivo Leiss, Ernst Basler + Partner AG 

Perspektiven für die Geomatik-Berufe 

Christian Kaul, Kaul Beratungen GmbH 

Tarifierung, Kostenfrage 

Jürg Kaufmann, Kaufmann Consulting 

Spezielle Aspekte der Interoperabilität in der Praxis 

21 

22 

Georeferenzierung, Interoperabilität zwischen Vermessungsdaten 

und darauf aufbauender Rauminformation, Datenhierarchie und 

Nachführung der abhängigen Rauminformation 

Dr. Horst Düster, AGI Solothurn 

Der Mobilitäts-Graph: ein geographisches Rahmenwerk für die 

Partner des Mobilitäts-Informationssystems der Region Genf 

Pascal Oehrli, SIT Genf

Alessandro Carosio, Prof. Dr. 

Eidg. Technische Hochschule Zürich 

Institut für Geodäsie und Photogrammetrie 

ETH Hönggerberg 

CH-8093 Zürich 

Tel : 

Fax : 

E-Mail : 

+41 1 633 30 52 

+41 1 633 11 01 

1 

Interoperabilität in GIS 

Anforderungen, Strategien, Lösungsansätze 

Alessandro Carosio, ETH Zürich

1 Interoperabilität und Datentransfer: Eine zentrale 

Funktion jedes GIS 

Das Entstehen und der erfolgreiche Einsatz von Geoinformationssystemen sind mit einer 

wirksamen Lösung des Problems der Interoperabilität und des Transfers der Geodaten 

untrennbar gekoppelt. Nur kleine Applikationen, die die Verarbeitung von kleinen 

Datenmengen während kurzer Zeit erfordern (z.B. GIS-Übungen in der Ausbildung), 

können ohne eine Lösung des Datentransferproblems auskommen. 

Wir verfügen heute über eine immer grösser werdende Menge geographischer Daten in 

digitaler Form und einer grossen Anzahl Organisationen, die mit Daten dieser Art arbeiten. 

Das Risiko, dass Doppelspurigkeiten und Widersprüche entstehen, ist gross. 

Oft existieren die benötigten Daten bereits. Sie werden aber wieder erfasst, weil: 

� eine geeignete Dokumentation fehlt oder 

� sie eine inkompatible Struktur aufweisen. 

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

Abb. 1 : Die Kommunikation zwischen Geoinformationssystemen 

Die Anforderungen und die Bedürfnisse sind allerdings sehr unterschiedlich. Dies ist 

der Grund, warum es bis jetzt relativ schwierig war, eine alles umfassende Standardlösung 

zu finden. 

Die wirtschaftlich entwickelten Länder realisieren zur Zeit geeignete nationale Geodateninfrastrukturen 

(NGDI), in welchen Private, Ämter, Lieferanten und Anwender integriert 

werden, damit sie gemeinsam Technologien und existierende Daten nutzen 

können. 

Voraussetzung für die Realisierung von Koordinationszentren (Clearinghouses), für den 

Informationsaustausch und für die interoperable Nutzung der Geodaten ist die Lösung 

der in Abbildung 2 beschriebenen organisatorischen und technischen Problemen. 

Alle aufgezeigten Punkte sind sehr wichtig. Der vorliegende Beitrag befasst sich jedoch 

nur mit der technischen Thematik der Interoperabilität und der Datenübertragung zwischen 

Systemen unterschiedlicher Hersteller. 

Die erforderlichen Lösungsansätze für diese beiden Aufgaben sind besonders aktuell, 

da man zurzeit sowohl auf nationaler Ebene als auch in internationalen Institutionen 

(Europa, Welt) an der Entwicklung von technischen Normen arbeitet, die die Realisierung 

von interoperablen Systemen ermöglichen sollen. 

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

Einführung in die Thematik 

Interoperabilität in GIS - Anforderungen, Strategien, Lösungsansätze 

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

2 Bedürfnisse, Lösungsansätze 

GIS GIS 

Abb. 3 : Datenaustausch und Interoperabilität 

2.1 Die Vielfalt der Anforderungen 

Die Komplexität der Frage der Datenübertragung ist die direkte Folge der Vielfalt der 

Anwendungen. 

Ausgetauscht oder angefragt werden zum Beispiel: 

� Graphische Darstellungen (digitale Karten und Pläne) 

� Beschreibungen der GIS-Inhalte (Metadaten) 

� Resultate von Abfragen (Tabellen, Karten usw.) 

� Strukturierte Datenbankinhalte (z.B. Tabellen, Attribute) ohne Änderung der Datenstrukturen 

� Daten von einer Datenbank in eine andere Datenbank mit unterschiedlichen Datenstrukturen 

� Vollständige Objekte in einer objektorientierten Umgebung (inkl. Operationen) 

Bereits diese kleine Auswahl von häufig auftretenden Datentransferwünschen gibt einen 

Eindruck über die Vielfalt der Bedürfnisse mit ihren sehr unterschiedlichen Komplexitäten. 

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

2.2 Die Vielfalt der Lösungen 



Interoperable GIS können auf unterschiedliche Arten realisiert werden: 

� Datentransfer 

o Datenaustausch zwischen gleichen Systemen 

o Datenaustausch mit Standardformaten 

o Modellbasierte Datentransfermethoden 

� Interoperabilität 

o Interoperabilität (nach OGC = Open Geospatial Consortium; früher Open 

GIS Consortium) 

3 Der eigentliche Datentransfer 

3.1 Proprietäre Transferformate: ein Grundbedürfnis 

Das Inbetriebsetzen einer GIS-Applikation, die Verkaufsvorführungen, die erste Schulung 

von neuen Anwendern und die Tests des Herstellers während der Softwareentwicklung 

erfordern die Übernahme von Demonstrationsdaten des gleichen GIS- 

Herstellers von einer Applikation zu einer anderen. So verfügen alle GIS über die Möglichkeit, 

die gespeicherten Daten in Standarddateien (in der Regel sequentielle Dateien) 

auszugeben und aus den gleichen Dateien wieder zu übernehmen. Die verwendeten 

Formate sind ausschliesslich geeignet für eine bestimmte GIS-Software (proprietäres 

Format) und erfordern beim Sender und beim Empfänger die identische Datenstruktur 

für die transferierten Daten. 

GIS 

Abb. 4 : Datentransfer mit proprietären Formaten 

Andere proprietäre Formate, welche oft de facto Standard geworden sind, werden für 

die Ausgabe von graphischen Darstellungen (z.B. Plottfiles), die aus der raumbezogenen 

Information hergeleitet werden (Karten und Pläne), verwendet. Die GIS-Software beinhaltet 

normalerweise die Treiber für die erforderliche Steuerung und Generierung der 

Datenformate. 

3.2 Standard-Formate 

Das Bedürfnis, Geoinformationen zwischen Systemen unterschiedlicher Hersteller auszutauschen 

war bereits in der Vergangenheit, besonders in grossen Organisationen (Telecom, 

Eisenbahngesellschaften, militärische Organisationen, usw.), stark spürbar. 

Bei solchen Anwendungen hat man mit Geoinformationssystemen zu tun, in welchen 

die zu verwaltenden Informationen für alle Systeme einheitlich festgelegt sind. Dies ist 

vor allem in stark hierarchischen Organisationen der Fall (NATO, Staatsbetriebe usw.). 

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

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öglich 

in jedem System die entsprechende Schnittstelle für das Lesen und Schreiben der 

Transferdateien in das definierte Format einzubauen. So wurden zum Beispiel für die 

NATO das Austauschformat DIGEST (Digitial Geographic Information Exchange Standard) 

und für den Ordnance Suvey (OS) in Grossbritannien das Format NTF (National 

Transfer Format) definiert. 

GIS 

Abb. 5 : Datentransfer mit Standard-Formaten 

Ein weiteres Bedürfnis, das sehr verbreitet ist, ist die Abgabe von Geoinformationen an 

Partner, die sie nur graphisch auf ihren Computersystemen weiter verarbeiten werden. 

Auf diese Art verwenden oft Architekten und Bauingenieure die erhaltenen Geodaten. 

Sie werden in CAD-Systemen für die Projektierung eingesetzt. Der de facto Standard im 

CAD-Bereich ist zurzeit DXF, ein Format, in welchem die Information in thematische 

Ebenen (Layer) unterteilt wird. 

Die meisten GIS-Hersteller sehen vor, Daten in DXF auszugeben und auch zu lesen. Dabei 

ist zu beachten, dass nur eine Teilmenge der Information (hauptsächlich die Graphik) 

in DXF abgebildet werden kann (�Informationsverlust). Sehr vorteilhaft sind bei 

dieser Form der Datenabgabe Vereinbarungen oder Normen, um die Layer-Zuordnung 

und Nummerierung einheitlich zu gestalten. 

Als das Projekt der Reform der Amtlichen Vermessung in der Schweiz realisiert wurde, 

stellte man mit Besorgnis fest, dass die Festlegung von einheitlichen Datenstrukturen 

für die Systeme der 26 Kantone unrealistisch war. Folglich war auch die Definition eines 

gemeinsamen Datentransferformats ein unmögliches Bestreben. 

Nicht anders geschah es ein paar Jahre später auf europäischer Ebene. Auf Anregung 

von Frankreich wurde das TC 287 der europäischen Normungsorganisation CEN gegründet, 

um unter anderem auch Normen für den Transfer geographischer Daten in 

Kraft zu setzen. Grossbritannien und Frankreich hatten sich vorgestellt, ihre Formate 

NTF und EDIGéO (Echange de Données Informatisées GéOgraphiques) für Europa zu 

erweitern (z.B. ETF). Die ersten Sitzungen zeigten aber, dass die Bedürfnisse und die 

Systeminhalte sehr unterschiedlich und vor allem die Anwendungen extrem vielfältig 

sind und daher die Festlegung von Standardformaten ein unmögliches Unterfangen ist. 

Man brauchte andere Lösungsansätze. Wenn unterschiedliche Datenstrukturen erwartet 

werden, sind modellbasierte Verfahren anstatt feste Formate der richtige Weg. 

3.3 Modellbasierte Transferverfahren 

Geoinformationen der heutigen Zeit bieten den Anwendern neben einer festgelegten 

Datenstruktur für die geometrischen Daten die Möglichkeit, die thematischen Inhalte 

frei zu definieren. Das System bildet dann aufgrund der Datenstrukturbeschreibung 




(Eingabe des DB-Schemas) die erforderlichen Entitätsklassen (in der Regel relationale 

DB-Tabellen). Somit passt sich die Datenverwaltung den Bedürfnissen an. 

GIS 

Abb. 6 : Modellbasierte Transferverfahren 

Man kann diese Idee auch brauchen, um den Datentransfer flexibel zu gestalten: Die 

Struktur der Daten, die man übertragen möchte, wird beschrieben und daraus kann ein 

Format für diese Daten hergeleitet werden. Dafür benötigt man zwei Komponenten: erstens 

eine standardisierte Datenbeschreibungssprache, um die Struktur der Daten, die 

man transferieren möchte, eindeutig und konsistent zu beschreiben, und zweitens ein 

genormtes Verfahren, um aus der Datenstruktur ein Format herzuleiten. 

Format- 

Herleitung 

Abb. 7 : Komponente des modellbasierten Transferverfahrens 

In der europäischen Normung wurde EXPRESS als Sprache festgelegt, da sie bereits eine 

gewisse Verbreitung hat (CAD, Automobilindustrie usw.). Applikationen im Geo- 

Bereich existieren allerdings noch nicht und ihre Komplexität ist für eine Implementierung 

nicht förderlich. 

In der Schweiz wurde für die Amtliche Vermessung vor mehr als 10 Jahren die Sprache 

INTERLIS definiert, welche die Beschreibung der Thematik in einem GIS nach einem 

relationalen Modell und der Geometrie aufgrund von festgelegten Geometrieelementen 

(Punkte, Geraden, Kreisbögen, Einzelflächen, Gebietseinteilungen) ermöglicht. Die 

Sprache passt sehr gut zu den heutigen GIS. Sie verfügte von Anfang an über einen 

Compiler für die automatische Herleitung der Transferformate und wird zunehmend 

eingesetzt. Zurzeit kann weltweit keine andere Lösung als operationell betrachtet werden. 

Im Technischen Komitee der ISO (TC 211) konnte nur INTERLIS als in GIS implementierter 

modellbasierter Transfermechanismus für Geodaten vorgeführt werden. 

ISO hat bisher folgendes beschlossen: 

� Die modellbasierten Transferverfahren sind als Standard erklärt. 

� UML wurde als graphischer Formalismus für die Beschreibung der Datenstrukturen 

festgelegt. 




� Eine textuelle Sprache, die automatisch gelesen und interpretiert werden kann, 

ist vorgesehen, ihre Eigenschaften wurden beschrieben und festgelegt. Kein Entscheid 

wurde getroffen. Mögliche Lösung INTERLIS 2. 

Die Schweiz hat die neue INTERLIS Version (INTERLIS 2) entwickelt, um die volle 

Kompatibilität mit den ISO-Normen (Objektorientierung, Inkrementelle Nachführung, 

usw.) zu erfüllen. In diesem Rahmen wurde auch die Schnittstelle zwischen UML und 

INTERLIS realisiert, damit ein UML-Schema in INTERLIS automatisch übersetzt werden 

kann (und umgekehrt). Ebenfalls wurde das Transferformat im 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 konzeptionellen 

Schema (in UML oder in INTERLIS): 

� ArcGIS (ESRI) kann die Datenstruktur aus Schemata in UML (erzeugt mit Microsoft 

Visio) implementieren 

� GeosPro/GeoMedia (a/m/t, Intergraph) aus INTERLIS 

� Topobase (C-Plan) aus INTERLIS oder aus UML 

4 Interoperabilität 

Während die bisherigen Lösungen alle als Ziel haben, die Daten von einem System zu 

einem anderen zu transferieren, sind Kommunikationsmöglichkeiten denkbar, die ohne 

Verschiebung der Originalgeodaten auskommen. Diese Lösung ist besonders interessant, 

wenn nur einfache Auswertungen der Information benötigt werden (z.B. eine graphische 

Darstellung von einem Ausschnitt oder die Auflistung von bestimmten Objekten). 

In diesen Fällen ist es einfacher, die Auswertungsbefehle und -ergebnisse zu standardisieren 

und zu transferieren als die Grunddaten selbst. 

Die Interoperabilität bedeutet die Parallelnutzung von verschiedenen GIS, indem die 

Befehle (Anfragen) und die daraus entstehenden Ergebnisse (Antworten) ausgetauscht 

werden (siehe Abb.8). 

Die GIS-Industrie (Softwarehersteller) hat diesen Weg als für den Markt interessant angesehen 

und das Open Geospatial Consortium (OGC) gegründet, um diese Technik 

möglichst weit zu entwickeln. Dank der Beteiligung der führenden weltweit tätigen 

Firmen (ESRI, Intergraph, Siemens, Oracle, Microsoft usw.) und der Einbindung von 

Universitäten und Forschungsinstitutionen hat OGC grosse Resonanz erhalten und entsprechend 

grosse Erwartungen geweckt. 




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 (syntaktische 

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 Probleme: 

es fehlen oft Informationen über die verfügbaren Geoinformationssysteme und 

ihre Daten. Um diese wichtigen Informationen zugänglich zu machen, entstehen Metainformationssysteme, 

welche Metadaten (Daten über die Daten) verwalten. Diese Systeme 

sind ihrerseits Geoinformationssysteme, in welchen ein Teil der Metainformationen 

raumbezogen ist (wo und über welches Gebiet findet man Daten). Zu den Metadaten 

gehören Informationen über die Qualität, die Verfügbarkeit, die Nutzungsbeschränkungen, 

die Kosten usw. Die Beschreibung der Datenstruktur in einer genormten Sprache 

(EXPRESS, INTERLIS, UML usw.) kann ebenfalls dazu gehören. 

Ansätze für die Normung von Metadaten befinden sich im ISO-Normenwerk. In der 

Nationalen Geodaten-Infrastruktur (NGDI) wird man aus den internationalen Normen 

nationale Profile (Teilmengen) definieren, um eindeutige Interpretationen zu ermöglichen. 

Zurzeit werden Metadaten zur visuellen Konsultation zur Verfügung gestellt. In Zukunft 

werden sie automatisch von interoperierenden Systemen bei der Datensuche genutzt 

werden. 

6 Die Wünsche und das Erreichbare 

6.1 Wünschbares 

Die optimistischen Beschreibungen der unterschiedlichen Datentransfer-Konzepte 

könnten den Eindruck entstehen lassen, dass - mit etwas Geduld und finanziellen Mitteln 

- das Problem des automatischen Austausches von Geoinformationen zwischen beliebigen 

Systemen ohne weiteres lösbar sei. 

GIS GIS GIS 

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

gewünscht. 

Dies entspricht selbstverständlich dem, was man sich wünscht. Man möchte die wertvollen 

Informationen, die an verschiedenen Orten erfasst und verwaltet werden, gemeinsam 

nutzen. 

6.2 Technische Grenzen 

Eine voll automatische Datenübertragung oder die gemeinsame Nutzung der Daten in 

beliebig konfigurierten Geoinformationssystemen ist nicht möglich. Die unüberwindbare 

Grenze liegt in der nicht standardisierten Semantik der Datenstrukturbeschreibungen. 




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 Strassen 

in einer Ortschaft (Schlossweg, Alpenweg usw.). Noch häufiger sind die Fälle dazwischen, 

in welchen die thematischen Elemente andere Bezeichnungen und auch eine 

andere Unterteilung haben (Abb.10). 

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

stattfinden. 

Die Semantik der Datenbeschreibung kann in einem freien Umfeld nicht standardisiert 

werden. Für die Zuordnung der Entitäten und der Attribute braucht man Zusatzinformationen. 

Es ist zu beachten, dass die Zuordnung von der Bedeutung der Objekte und 

der Attribute abhängig ist. Sie ist daher auch von den Betriebsanweisungen und von 

den Regeln der Datenakquisition beeinflusst. Weder Mensch noch Computer werden in 

der Lage sein, ohne Zusatzauskünfte die Zuordnung der Entitäten und der Attribute 

vorzunehmen. Man wird sich zuerst erkundigen müssen oder ausführliche Beschreibungen 

lesen, um aufgrund der eigenen Interpretationen und Zielsetzungen die Datenfelder 

in Beziehung zu bringen. 

Diese Zuordnung muss das erste Mal aufgrund von: 

� Einer Analyse eines Experten 

� Anfragen bei den Verantwortlichen 

� Konsultationen von Metadaten erfolgen 

Erst danach kann eine semantische Transformation automatisch ausgeführt werden. 

Für die modellbasierten Transferverfahren haben Software-Hersteller Module entwickelt, 

die zwei Datenstrukturen (z.B. aus ihrer Beschreibung in INTERLIS) darstellen 




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). 

Agent 

Abb. 11: Semantische Transformationen mit Hilfe von Ontologien 

Zwischen föderierten Systemen (unter gemeinsamen Regeln organisiert) wird es in spezifischen 

Bereichen möglich sein, Ontologien zu entwickeln, welche die Semantik von 

mehreren Systemen beschreiben und die Herstellung von automatischen Transformationsmodulen 

(Agenten) ermöglichen werden. 

Die Ontologien sind Gegenstand der heutigen Forschung. Man wird allerdings nur die 

Semantik in klar definierten und abgegrenzten Sektoren eindeutig beschreiben können. 

Eine Ontologie entspricht einer Standardisierung der Begriffe, die man für die Modellbildung 

und für die Bezeichnung der Elemente der Datenstruktur im GIS verwendet 

hat. 

7 Entwicklungsstrategien 

Ontologie 

Agent 

Jeder der bisher geschilderten Lösungsansätze ist, trotz der erwähnten technischen 

Grenzen, eine optimale Antwort für einzelne Fälle mit ihren unterschiedlichen Anforderungen. 

Es ist daher nicht zu erwarten, dass sich ein einziger besonderer Lösungsansatz 

als Weltstandard für den Transfer von Geoinformationen durchsetzen wird: 

� Proprietäre Formate werden zu jeder GIS-Software gehören. Sie sind die optimale 

Lösung für die Systemadministration. Sie übertragen die Daten eines bestimmten 

Systems vollständig (inkl. Konfigurationsparameter). Sie können auch 

für den internen Datenaustausch in grossen Organisationen dienen, die mehrere 

identische Systeme betreiben. 

� Standardformate sind einzusetzen, wenn die Inhalte der GIS zentral festgelegt 

werden. Zur beschlossenen Datenstruktur kann ein Format definiert werden, mit 

welchem die Daten sequentiell übertragen werden können. Standardformate 

sind ebenfalls die geeignete Lösung für die Abgabe von GIS-Daten an CAD- 

Systeme. DXF ist im CAD-Bereich am meisten verbreitet. Wünschenswert ist dabei 

die Normung der Layer. 




� Modellbasierte Transferverfahren sind die Lösung für den Datenaustausch 

zwischen Systemen, die eine eigene Datenstruktur besitzen. Die ankommenden 

Daten beinhalten die Datenstrukturbeschreibung in einem genormten Formalismus 

(Datenbeschreibungssprache). Zur Sprache gehört auch das Verfahren, um 

daraus die Formate herzuleiten. Wenn die Strukturen der erhaltenen Daten und 

der Daten des Empfänger-Systems nicht identisch sind, kann eine voll automatische 

Übernahme nicht stattfinden. Die Zuordnung der Entitätsklassen und der 

Attribute muss das erste Mal aufgrund menschlicher Interpretation geschehen. 

Um diese interaktive Arbeit zu erleichtern, haben Software-Hersteller Module 

entwickelt, die zwei Datenstrukturen vergleichen und am Bildschirm die Zuordnung 

der Tabellenfelder erlauben (z.B. INTERLIS-Studio von Leica). 

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

sein. 

� Interoperabilität ist die Alternative, mit welcher die Kommunikation zwischen 

den GIS ohne Austausch der Geodaten stattfinden kann. Genormt werden die 

Anfragen und die Formate für die Übermittlung der Antworten (Services Interfaces). 

Der tatsächliche Umfang der Möglichkeiten, die im Rahmen der OGC- 

Arbeiten entstehen werden, ist schwer vorherzusagen. Zurzeit sind einfache Anfragen 

(Visualisierungen, Selektionen) und der Zugriff auf einfache geographische 

Objekte spezifiziert. 

Sicher werden einfache Anfragen (Visualisierungen, Selektionen) zur Verfügung 

stehen. Ebenfalls spezifiziert ist bereits der Zugriff zu einer einfachen Koordinatengeometrie. 

Da in den Absichten des Open Geospatial Consortium (OGC) 

nicht nur die Kommunikation zwischen den Systemen im Vordergrund steht, 

sondern auch das Zusammensetzen von ganzen GIS aus selbstständigen Komponenten, 

werden die Schnittstellen zwischen den frei gewählten 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 Methoden 

werden sich als Standard durchsetzen. Die nächsten Schritte der Forschung sind im 

Bereich der semantischen Interoperabilität und der semantischen Transformationen zu 

erwarten. 

Diese Arbeiten sind die Voraussetzung, damit Geoinformationssysteme ihre wertvollen 

Daten ohne Verzögerung und Hindernisse der ganzen Gesellschaft zur Verfügung stellen 

können. 


Urs Flückiger 

ESRI Geoinformatik AG 

Beckenhofstr. 72 


Tel : 

Fax : 

E-Mail : 

+41 1 360 24 60 

+41 1 360 24 70 

2 

Überblick 

Urs Flückiger, SOGI Fachgruppe GIS Technologie

Dieser Beitrag soll dem Interessenten einen Überblick zum Thema nationale und internationale 

Standards im Gesamtkontext zu „Interoperabilität für die breite Nutzung von 

Geodaten“ geben. Im Gegensatz zu den nachfolgenden Beiträgen kann dieser Einstieg 

ins Thema nicht in die Details gehen. An der Tagung behandelte Themen finden sich als 

Beispiele wieder. 

Was ist Interoperabilität? – Interoperabilität ist, wenn ein System mit anderen Systemen 

unterschiedlichen Ursprungs innerhalb vordefinierter Grenzen zusammenarbeiten kann 

und darf. Durch Spezifikationen und Normen entsteht Interoperabilität. Interoperabilität 

findet auf verschiedenen technologischen Ebenen statt. 

Leisten Normen einen Beitrag zur Interoperabilität? – Normen erleichtern das Leben in 

einer vernetzten Welt. In den wenigsten Fällen werden Daten nur für einen kurzfristigen 

Moment erfasst und nur in einem System gehalten. Deshalb ist die Schaffung und 

Durchsetzung von Normen eine bedeutende Aufgabe. Normen erleichtern die Vernetzung 

und bauen technologische Hindernisse zur Zusammenarbeit ab. 

Gibt es einen Markt für Normen? – Verschiedene Gruppierungen befassen sich damit. 

Der Nutzen ist unterschiedlich. Alle Beteiligten profitieren jedoch in irgendeiner Weise. 

1 Normung 

1.1 Definition von Normung 

Normung heisst die planmässige, durch interessierte Kreise durchgeführte Vereinheitlichung 

von materiellen und immateriellen Gegenständen zum Nutzen der Allgemeinheit 

(DIN). Das Ergebnis von Normung ist eine technische Vorschrift, die man Norm nennt 

(englisch: standard). Eine „de jure Norm“ (oder kurz Norm) ist eine solche technische 

Vorschrift, die von nationalen oder internationalen Normenverbänden festgelegt wird. 

Eine „de facto Norm“ ist eine allgemein anerkannte und mehrheitlich genutzte technische 

Vorschrift, die sich aus der weiten Verbreitung eines Produktes ergibt, durch die 

ausschliessliche Nutzung innerhalb eines Unternehmens (so genannter Industrie- 

Standard) oder durch nationale oder internationale Interessengemeinschaften oder Konsortien 

festgelegt wird. Sowohl Normen als auch de facto Normen sind nur dann verbindlich 

und müssen durch natürliche und juristische Personen angewendet werden, 

wenn durch gesetzliche oder vertragliche Regelungen deren Einhaltung gefordert wird. 

Typ Norm (Gremium) De facto Norm (Gremium) 

Betriebssysteme Unix, Linux (ANSI) Windows 2000 (Microsoft) 

Datenbanken SQL-92 (ISO) 

DXF (AutoCAD), Shapefile 

Datenformat XML (W3C), ITF (SNV) 

(ESRI) 

Java (Sun), Visual Basic (Micro- 

Programmiersprachen C++ (ANSI) 

soft) 

J2EE (SUN Microsystems), 

Internet-Dienste HTTP (ISO), SOAP, UDDI 

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 (einheitliche 

Beschreibungssprache) sowie den Datenaustausch (Bezugsmechanismus und Datenformat) 

erhöhen die Flexibilität, die Funktionalität und die Produktivität eines Informationssystems. 



Ü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 Informationen 

und Geomatik beschäftigt. Dieses Komitee bearbeitet die Normenserie ISO 19100, 

welche verschiedenste Geodaten-Standards (Metadata, Spatial Schema, Spatial Reference, 

Application Schema, Conceptual Schema Language, Quality, Encoding, Catalog ...) 

beinhaltet. 

Die ISO TC211 und das Open Geospatial Consortium (OGC) arbeiten zusammen und 

unterstützen sich gegenseitig. Eine Spezifikation bei OGC entspricht einer Ebene der 

19100-er Normenserie bei ISO. Die mit dem Abkommen verfolgten Ziele sind: 

� 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 beschliessen 

die Normenserie ISO 19100 weitgehend zu übernehmen. Die Mitglieder von 

CEN haben sich verpflichtet die CEN-Normen zu ratifizieren. 

Schweizerische Normenvereinigung (SNV) 

Die SNV ist Mitglied von CEN und daher verpflichtet, die CEN-Normen und somit die 

ISO-Normen zu übernehmen, falls diese zu CEN-Normen werden. Dies bedeutet, dass 

allfällige Schweizer Normen, welche im Widerspruch mit CEN bzw. ISO-Normen stehen, 

voraussichtlich eliminiert werden müssten. Da die Schweizer Geonormen auf 

Grund von praktischen Bedürfnissen entwickelt, implementiert und getestet wurden, ist 

die Schweiz daran interessiert, dass auch die allfällig zu übernehmenden internationalen 

Normen im GI-Bereich den praktischen Bedürfnissen entsprechen und durch Implementierung 

auf ihre Brauchbarkeit geprüft werden. Dafür setzen sich die Schweizer 

Vertreter in den entsprechenden Gremien mit zunehmendem Erfolg ein. 



Überblick 

Andererseits bemüht man sich in der Schweiz ebenfalls erfolgreich, die existierenden 

und bewährten Normen den aktuellen Entwicklungen in der Informationstechnologie 

und im GI-Normenbereich schrittweise anzupassen. 

Beispiele für SNV-Normen: 

� SN 612 030 und SN 612 031: INTERLIS Modellierungssprache und Datentransfermethode 

� SN 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 Forschungseinrichtungen 

haben sich 1994 im Open Geospatial Consortium (OGC) zusammengeschlossen. 

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 Einsatz 

interoperabler Software-Komponenten von der Stange (Components of the shelf), 

die vollständige Integration der Geodatenverarbeitung mit der normalen Informationstechnologie 

und der Schritt von Geodaten zu Geoinformationsdiensten. Die 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 

W3C 

Das World Wide Web Consortium wurde gegründet, um alle Möglichkeiten des Webs 

zu erschließen. Dazu werden einheitliche Technologien (Spezifikationen, Richtlinien, 

Software und Tools) entwickelt, die den Fortschritt des Webs fördern und seine Interoperabilität 

sicherstellen. 

Hauptprodukte des W3C sind neue Empfehlungen, die als de facto Standards für Protokolle 

und Anwendungen von den Mitgliedern begutachtet und gebilligt werden müssen. 

Ziel dabei ist es, einen möglichst breiten Konsens zu finden, was dadurch erreicht 

wird, dass jede Spezifikation ein bestimmtes Verfahren zu durchlaufen hat (sog. Recommendation 

Process). 

Ziel des W3C ist es, das WWW zu seiner vollen Entfaltung zu führen: Als ein funktionierendes 

Computer zu Computer System, als ein wirkungsvolles Mensch zu Computer 

Interface und als ein effizientes Mensch zu Mensch Kommunikationsmedium. Um die- 



Überblick 

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, Internationalisierung, 

Amaya) 

� Interaction Domain (Device Independence, synchronisierte Multimediaanwendungen, 

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 Kommunikation 

zwischen verschiedenen Informationssystemen ermöglicht, was als Interoperabilität 

bezeichnet wird. Interoperabilität erlaubt den einfachen Zugang zu verschiedenen (auch 

raumbezogenen) Daten- und Verarbeitungsressourcen innerhalb eines Arbeitsablaufs 

bzw. die einfache Verknüpfung unterschiedlicher Systeme. Durch dieses einfache Zusammenspiel 

von Systemen und Daten wird es möglich, viele verschiedene Daten an 

einem Ort zu nutzen und diese Information gegebenenfalls auch zu veröffentlichen. 

Durch Spezifikationen und Normen entsteht Interoperabilität. Interoperabilität ist die 

Grundlage von IT-Infrastrukturen, d.h. von verteilten Systemen für eine Gesamt- 

Unternehmungslösung. 

Interoperabilität findet auf verschiedenen Ebenen statt. 

Schicht Charakteristik Begriffe 

Unterstützung von thin clients 

Präsentation 

J2ME 

und fat clients 

Services 

Applikationslogik 

Daten, Formate 

Interoperation und Offenheit: 

Einsatz von Internet-, IT- und 

GIS- Standards 

Integration und IT-Konformität 

(API) 

Austausch und Investitionsschutz 

Plattform Plattformunabhängigkeit 

3 Marktbetrachtung 

HTTP, XML, SOAP, J2EE, UDDI; 

OGC: WMS, WFS 

.net, COM, Java SOAP, GML/XML, 

C++, VB 

DXF, DGN, SHP, OGC SF, INTER- 

LIS, GML, DBMS OS, PNG, JPG 

Unix (SUN, IBM, HP), DOS, Windows, 

Mac, Linux; DBMS (Oracle, 

SQL, DB2, Informix); WebServer 

(IIS, Websphere, Apache) 

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? 



Überblick 

Die Antworten auf diese beiden Fragen sind nicht abschliessend: 

Verschiedene Organisationen bzw. Gremien befassen sich mit Normung. Die einschlägigen 

Normierungsorganisationen wie ISO, CEN und SNV aber auch OGC wurden bereits 

erwähnt. Neben den technischen Kommissionen (z.B. TC211 oder TK151) befassen 

sich auch weitere Gremien und Verbände (z.B. eCH, sia) mit Normung. Gerade Verbände 

sind gefordert, entstehende Normen für ihre Mitglieder auf ihre Praxistauglichkeit 

zu prüfen. 

EUROGI (European Umbrella Organisation for Geographic Information) will den 

Gebrauch von geographischen Informationen zugunsten der Bürger, der Regierungen 

und des Handels in Europa maximieren und die Sichtweise der 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ängliche 

Geobasisdaten für Privatwirtschaft wie für Verwaltung hohen volkswirtschaftlichen 

Nutzen haben (vgl. NGDI des Bundes). 

Der Anwender wird sich nicht im Detail damit befassen. Er wird sich informieren, damit 

er als Auftraggeber notwendige Standards fordern bzw. als Auftragnehmer geforderte 

Standards umsetzen kann. Schliesslich sollen Investitionen nachhaltig sein. 

Die Schaffung und Durchsetzung von Normen ist eine bedeutende Aufgabe. Normen 

erleichtern die Vernetzung und bauen technologische Hindernisse zur Zusammenarbeit 

ab. Die SOGI FG GIS-Technologie hat den Nutzen der Ergebnisse der Arbeit von OGC, 

ISO und SN für den GIS-Anwender in der Schweiz untersucht: 

Beschreibung OGC ISO SN 

Produktivitätssteigerung von Unternehmen und Behörden durch die 

X - e 

Nutzung genormter Programmschnittstellen. 

Produktivitätssteigerung von Unternehmen und Behörden durch die 

e e X 

Nutzung genormter Austauschformate und Mechanismen. 

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- - - X 

heit für alle Anbieter. 

Im Bereich länderübergreifender Projekte, kommen proprietäre nationae 

e e 

le Normen (d.h. ohne Bezug zu internationalen Normen) nicht zum Ein- 



Überblick 

satz. Dort ebnen internationale Normen den Weg für einen geregelten 

Datenbezug bzw. Datenaustausch. 

Normung wird auf einer systemneutralen Daten- und Modellierungsebene 

geführt. 

? 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 sinnvollen 

Einsatz von Schweizer Normen zu schätzen (Bericht 17, www.swisstopo.ch). Es 

wird dort von einem Potential von einigen Millionen Schweizer Franken pro Jahr gerechnet. 

Ein anderer Bericht spricht von 3% Einsparung durch genormte Arbeitsabläufe 

und Werkzeuge (www.cgey.com/gcicase); dieser Prozentsatz dürfte im GIS-Bereich 

noch wesentlich höher liegen. Ebenso wichtig wie die Einsparungen ist jedoch der Zusatznutzen, 

der durch genormte Geoinformationsverarbeitung erzielt wird. 

Im Gegensatz zu üblichen Märkten ist Wettbewerb weniger gefragt. Organisationen sollen 

in jenen Bereichen, in denen sie sich thematisch überschneiden, zusammenarbeiten 

und ihre Normen angleichen. Dies passiert bereits. OGC-Standards wie WFS oder WMS 

werden von ISO als Norm übernommen oder in entsprechenden Normen angepasst. 

Dasselbe geschieht auch umgekehrt, indem z.B. OGC ISO-Normen als Standards übernimmt. 

Auch andere Organisationen wie FGDC arbeiten enger mit ISO und OGC zusammen. 

Dies bringt den Organisationen weniger Arbeit und mehr Durchsetzungskraft. 

Für Entwickler, Hersteller und Anwender wird es einfacher. 

4 Literaturangaben 

� SOGI FG GIS-Technologie (2003): Worin liegt der praktische Nutzen von Interoperabilität 

und Normung für den GIS-Anwender in der Schweiz? 

� SOGI FG GIS-Technologie (2005): Geo-Webdienst 

URL 

CEN, European Committee for Standardisation (www.cenorm.be) 

INTERLIS (www.interlis.ch) 

ISO (www.iso.org) 

ISO TC/211 (www.isotc211.org) 

KOGIS (www.kogis.ch, www.e-geo.ch) 

OGC (www.opengis.org) 

Online Glossar (www.integis.ch) 

Schweizerischen Normen Vereinigung SNV (www.snv.ch) 

SOGI (www.sogi.ch) 

TC211 – OGC coordination group (www.opengis.org/iso) 


Christine Giger, Prof. Dr. 





Tel : 

Fax : 

E-Mail : 

+41 1 633 30 51 

+41 1 633 11 01 

3 

Informatik-Standards 

Für die Interoperabilität von GIS relevante 

Standards 

Christine Giger, ETH Zürich

1 Einleitung 

Die Entwicklung vernetzter, interoperabler Systeme betrifft aus Sicht der 

Informationstechnologien vier Aufgaben: 

1. Festlegung der Architekturen und technischen Standards 

2. Prozessmodellierung 

3. 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] 



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 Modellierungsund 

Middleware-Bereiche der OMG. Sie unterstützt Anwendungen über ihren 

gesamten Lebenszyklus von Analyse und Entwurf über Implementierung und 

Entwicklung bis hin zur Pflege und der Erweiterung von Softwaresystemen. Die MDA 

basiert auf UML Modellen. Die Beschreibungssprache UML wird im nächsten Kapitel 

noch etwas näher beschrieben. 

Das folgende Bild 4 illustriert die Funktion der MDA aus Sicht der OMG. 

Bild 4: Funktionen der Model Driven Architecture 

Die MDA integriert Anwendungen innerhalb eines Unternehmens und über das 

Unternehmen hinaus mit Anwendungen anderer Unternehmen. Sie wurde von den 

OMG-Mitgliedern als Basis für alle OMG-Spezifikationen im September 2001 

verabschiedet. Weitere Infos finden sich unter [7]. 

2.3 Unified Modeling Language (UML) 

UML standardisiert die Repräsentation von objekt-orientierter Analyse und Entwurf. Es 

handelt sich bei UML um eine graphische Sprache mit einem Dutzend Diagrammtypen 

(Anwendungs- und Aktivitätsdiagramme zur Anforderungserfassung, Klassen- und 

Objektdiagramme für den Systementwurf, Paket und Subsystemdiagramme für die 

Entwicklung, usw.). Software-Architekten und -Analysten können Anwendungen 

standardisiert visualisieren, spezifizieren, konstruieren und dokumentieren. Die OMG 

entwickelte UML also vor allem zum Entwurf von komplexen, verteilten 

Softwaresystemen. 

Im GIS-Bereich wird zur Zeit allerdings nur ein sehr kleiner Aspekt von UML genutzt: 

die Möglichkeit, mit UML Datenmodelle zu beschreiben. UML ist allerdings sehr 

verbreitet für die Nutzung und wird beispielsweise auch für die Spezifikation der ISO 

19100 [5] Normenreihe intensiv gebraucht. 

Weitere Informationen zu UML, Beispiele sowie UML-Kurse finden sich unter [9]. 




3 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: 

 

Tove 

Jani 

Reminder 

Don't forget me this weekend! 

 




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 

4. 

http://www.textuality.com“ 

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äten 

� Gleichheit 

� Charakteristika von Eigenschaften (z.B. Symmetrien) 

� Enumerationen 

RDF nutzt Description Logics zur Modellierung von Daten (z.B. Geoobjekten) und deren 

Eigenschaften. 

Bild 6 zeigt ein Beispiel für deskriptive Logik. 

Bild 6: Deskriptive Logik 

OWL ist (ähnlich wie 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 Dokumentorientierte 

oder Prozedur-orientierte Informationen enthalten. Operationen und 

Nachrichten werden abstrakt beschrieben und dann an ein konkretes Netzprotokoll und 

Nachrichtenformat gebunden, um einen Endpunkt zu definieren. In Beziehung 




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/ 


Hans Rudolf Gnägi 





Tel : 

Fax : 

E-Mail : 

+41 1 633 30 60 

+41 1 633 11 01 

4 

Weltweite, europäische und 

schweizerische GeoNormen in 

Wechselwirkung 

Hans Rudolf Gnägi, ETH Zürich

1 Einleitung 

Wer an Normen denkt, dem fallen spontan Stichworte ein wie „Schraubengewinde“, 

„DIN A4“ und „Spurweite der Eisenbahn“. Dabei geht es um stabile Dinge des täglichen 

Lebens, die schon mehr oder weniger lang existieren und sich bewährt haben und 

wo es nur noch darum geht, einige Details einheitlich festzulegen, um einer noch uneingeschränkteren 

Verwendung dieser Dinge letzte Hindernisse aus dem Weg zu räumen. 

Ganz anders ist die Situation im Geoinformationsbereich. Da ist sozusagen nichts stabil, 

Technisch jagen sich die inkompatiblen Versionen von Geoinformationssystemen und 

Geodiensten in einem atemraubenden Tempo, die Geodaten werden immer umfangreicher, 

waren schon immer und bleiben teuer in der Herstellung, die Vielfalt von Austauschformaten 

nimmt babylonische Ausmasse an. 

Und trotzdem sollten in dieser hoffnungslos dynamischen Situation mittels Normen 

stabile Pflöcke eingeschlagen werden. Schon immer war da der Bedarf, Geodaten auszutauschen 

über lokale, regionale und nationale Grenzen, auch über Systemgrenzen. Nationale, 

regionale und globale Geodateninfrastrukturen rufen heute nach vielseitiger 

Nutzung einmal erhobener Geodaten. Aber was und wie soll normiert werden? Wo sind 

die Schraubengewinde im Geobereich? Zur Dynamik der Technik gesellen sich zudem 

handfeste Interessenkonflikte. Während beispielsweise die Geodatennutzer an möglichst 

frei und vollständig austauschbaren sowie offen beschriebenen Geodaten interessiert 

sind, möchte ein GIS-Hersteller tendenziell eher seine Kunden an sein System binden 

durch möglichst hohe Hürden, die Daten wohldokumentiert und vollständig in ein 

Mitbewerber-System transferieren zu können. 

Im Folgenden soll kurz gezeigt werden, ob und wie erfolgreich das weltweite (ISO/ 

TC211), das europäische (CEN/TC287) und das nationale Normengremium (SNV/INB 

TK 151) den mehrdimensionalen Spagat zwischen Technikdynamik und Anforderungswidersprüchen 

meistern. 

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

Beeinflussung 

DIN normt auch den Begriff „Normung” und zwar mit folgender Definition: Normung 

ist planmässige, durch die interessierten Kreise durchgeführte Vereinheitlichung von 

materiellen und immateriellen Gegenständen zum Nutzen der Allgemeinheit (DIN 820 

Teil 3). Eine „Norm” ist das Resultat solcher Normungstätigkeit. 

Das Interesse am „Nutzen für die Allgemeinheit“ von „Vereinheitlichungen“ im Geobereich 

meldete sich in der Schweiz, wie in den meisten Ländern, zunächst auf nationaler 

Ebene an. Bedeutung und Wert der umfangreichen Geodatensammlungen führten zu 

einer ersten Schweizer Norm „Sicherheit und Schutz von Geodaten“ (SN612010). Um 

den Datenaustausch zwischen amtlicher Vermessung einerseits und Architektur und 

Bau andererseits zu entwirren wurde die Norm „Datenreferenzmodell DXF Geobau“ 

(SN612020) erarbeitet. Die modellbasierte Methode, in Stürmen praktischer Anwendung 

gereift, wurde als Norm „INTERLIS Datenbeschreibungssprache und Transfermethode“ 

(SN612030) fixiert Es folgten „INTERLIS 2“ (SN612031), „Gebäudeadressen“ 

(SN612040), „Metadaten“ (SN612050), diese sind aber bereits beeinflusst von der weltweiten 

Geo-Normung, wo seit 1994 die wesentlichen Entwicklungen stattfinden. 



Weltweite, europäische und schweizerische Geonormen in Wechselwirkung 

Die Erfahrungen mit der Entwicklung von Schweizer Normen zeigten, dass eine Norm 

nur dann „zum Nutzen der Allgemeinheit“ dient, wenn sie den folgenden Qualitätskriterien 

genügt. 

E Exakte knappe Formulierung mit präzisen klar definierten Begriffen aber auch 

mit anschaulichen Erläuterungen. 

M Minimum, das nötig ist wurde festzulegen: „Vollständig“ ist eine Norm, wenn 

sie alles enthält, was nötig ist für ein Vereinheitlichung, nicht alles, was existiert. 

P Praxiserprobung war erfolgreich 

B Breit abgestützte Einflussnahme auf die Erarbeitung 

„Planmässig“ bedeutet im Geobereich, dass organisatorisch primär auf weltweiter Ebene 

normiert wird (ISO/TC211), diese Normen in Europa nach Prüfung von Bedarf und 

Eignung als Euronormen (EN) anerkannt werden (von CEN/TC287), und dass diese 

Euronormen von den Mitgliedländern schliesslich ins nationale Normenwerk übernommen 

werden müssen (in der Schweiz durch die Schweizerisch Normenvereinigung 

SNV). „Planmässig“ verläuft auch der Lebenszyklus einer Norm: Dieser startet damit, 

dass eine Mitgliednation oder ein Liaison-Mitglied die Idee für eine neue Norm als 

„New work item proposal“ (NWIP) formuliert. Wird dieses vom TC angenommen, 

beginnt ein Projektteam (PT) „Committee Drafts“ (CD) auszuarbeiten, die von den Mitgliedernationen 

beurteilt werden können. Änderungswünsche werden durch „Editing 

Committee Meetings“ (ECM) eingearbeitet. Ist ein CD stabil, dann kommt er zur Abstimmung 

als „Draft International Standard“ (DIS) und schliesslich als „International 

Standard“ (IS). Analog entstehen bei ISO „Technical Reports“ (TR): Vom NWIP über 

den „Provisional Draft Technical Report“ (PDTR) zum DTR und zum TR. 

Soweit das Prozedere zur Schaffung von sogenannten „de jure“ Normen über die offiziellen 

Normengremien. Daneben haben sich im Geo-Bereich wie in der Informationstechnologie 

allgemein auch „de facto“ Normen durchgesetzt durch weitverbreiteten 

Gebrauch. Man denke etwa an das „Drawing eXchange File“ (DXF) zum Austausch von 

Vektorgrafik. Mit dem „Open Geospatial Consortium“ (OGC) hat sich ein Gremium 

konstituiert, mit dem Ziel, Interoperabilität von GIS zu realisieren, d.h. Funktionalität 

und Daten von GIS wechselseitig nutzbar zu machen, insbesondere, wenn nicht umfangreicher 

Datenaustausch gefordert ist. OGC umfasst als strategisch entscheidende 

„principle members“ vor allem die grossen GIS-Hersteller. Viele an GIS interessierte 

Administrationen, Universitäten und kleinere Firmen können zu bescheideneren Jahresbeiträgen 

und mit weniger Entscheidungsbefugnis ihre Ideen einbringen. Der grosse 

Vorteil der de facto Normen von OGC gegenüber den de jure Normen von ISO ist, dass 

meist erst auf Grund von Implementierungen für eine Idee der Normungsprozess gestartet 

wird, dass also das oben erwähnte Qualitätskriterium 3 der Praxiserprobung automatisch 

erfüllt ist. Entsprechend dem Ziel Interoperabilität liegt das Hauptinteresse 

der OGC-Normungsarbeit im Bereich Internet basierte Dienste. 

Einzigartig und ausserordentlich positiv für die Normung im Geo-Bereich ist, dass ein 

Zusammenarbeitsvertrag zustande kam zwischen OGC und ISO/TC211. Er ist zwar insofern 

einseitig, als damit nur OGC Normenvorschläge in den ISO-Prozess einbringen 

kann und nicht auch umgekehrt ISO/TC 211 bei OGC die Implementierung und damit 

praktische Überprüfung von durch ISO entwickelten Normen beantragen kann. Aber 

schon, dass OGC-Realisierungen auch den ISO-Prozess durchlaufen und so mit breiten 

kritischen Stellungnahmen und Verbesserungsideen konfrontiert werden, die mittels 




ECMs berücksichtigt werden, hat wesentliche Qualitätsverbesserungen zur Folge (Qualitätskriterium 

4!). 

Noch ein Blick auf die Normungsexperten von ISO/TC211: Deren Zusammensetzung 

ist nach wie vor von unglaublicher Heterogenität. Viele kennen GIS nur von ferne, theoretisch, 

viele sind fixiert auf das eine GIS, mit dem sie gelegentlich oder täglich arbeiten, 

Das Verständnis für die Bedeutung systemunabhängiger Lösungen und für die modellbasierte 

Methode ist zwar zunehmend aber immer noch sehr nahe bei Null. 

3 Geo-Normen, Übersicht 

Gesamtübersicht und Stand der ISO Normenserie 19100 gibt Tabelle 1. Von den 47 insgesamt 

gestarteten Projektteams wurden 3 wieder gestrichen und die übrigen produzierten 

bis zum 16.2.2005 insgesamt 18 IS und TR, 11 DIS und DTR, 9 CD und PDTR 

und 6 NWIP sind noch nicht bis zum CD vorgedrungen. 

Die ganze Normenserie basiert auf der modellbasierten Methode. Das heisst, es wird 

grundsätzlich auf system-unabhängiger konzeptioneller Ebene normiert. Die konzeptionellen 

Schemata (Datenmodelle) der normierten Datenstrukturen bzw. Strukturelemente 

müssen für die Implementierung in GIS oder Datenbanken auf das logische 

Schema (Datenmodell) dieser Zielsysteme umgebaut werden, um von dort, meist automatisch, 

auf den physischen Level des Betriebssystems bzw. des Rechners übersetzt zu 

werden. Für den Datentransfer kann aus einem konzeptionellen Schema automatisch 

direkt die Beschreibung des Transferformats, also das physische oder Transferschema, 

hergeleitet werden. 

Als konzeptionelle Beschreibungssprache verwendet ISO19100 die Umified Modelling 

Language (UML). Als Transferformat wurde der XML-Dialekt GML gewählt, als physische 

Beschreibungssprache des Transferschemas zunächst XML-DTD und jetzt 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 Datenmodell 

betrachtet und bezeichnet bereitet sich selber vor allem unnötige Schwierigkeiten 

und stiftet in der Geowelt unnötig Verwirrung. 

Die Normen der Serie ISO 19100 können gegliedert werden in die beiden Hauptbereiche 

Grundlagen und Anwendungen. Bei den Grundlagen zeichnen sich vier Teilbereiche ab: 

Basis – Integrierbarkeit/Transferierbarkeit – Interoperabilität. Bei den Anwendungen 

kann zur Zeit unterschieden werden zwischen Qualität/Metadaten – Pixelbilder/Gitterdaten 

– LBS – Adressen – Bewegte Objekte. Details zu den beiden Hauptbereichen 

sowie der Versuch eines Zustandsvergleichs ISO-CEN-SNV für den Grundlagenbereich 

folgen im nächsten Abschnitt. 

Tabelle 1 enthält in der dritten Kolonne eine grobe Beurteilung aller Normen. Dabei fällt 

sehr unangenehm auf die grosse Zahl von Normen mit der Bemerkung „No“. Wegen 

der sehr beschränkten personellen und finanziellen Kapazität der Schweiz im Geo- 

Normenbereich konnten alle diese Dokumente überhaupt nicht bewertet werden 




Nr 

ISO 

Sta 

nd 

Beurteilung 

Titel Dokument Nr 

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

Seiten 

ISO 

CH Norm 

SN6120xx-y 

xx Nr.Teil 

y Kap,Annex 

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) 

Seiten 

CH



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 Grundlagennormen 

in thematischer Ordnung gemäss den oben beschriebenen Teilbereichen. 

Für die ISO/CEN-Normen einerseits und für die entsprechenden SNV-Normen andererseits 

kommen die in Abschnitt 2 eingeführten Qualitätskriterien zur Anwendung. 

Nr ISO 

E 

Name ISO CEN 

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

CEN 

N 

Basis . 

Conceptual schema lan- 

INTERLIS 2, Kapitel 2 

19103 

� s s u s 612031 

G s G G 

guage 

Beschreibungssprache 

INTERLIS 2, Anhang L 

19104 Terminology principles � G s G G 612031 

G G G G 

Glossar 

19107 

19123 

19125 

19137 

19111 

19127 

Spatial schema 

Schema for coverage.. 

Simple features 

Minimal profile spa sch 

Referencing by coord 

Geodetic codes and par 

� 

� 

� 

� 

� 

� 

s 

� 

s 

G 

s 

s 

u 

� 

G 

G 

s 

s 

u 

� 

G 

s 

s 

G 

u 

� 

612031 

s 

G 

G 

G 612031 

19108 Temporal schema � s u u s 612031 

19109 

19110 

Rules for applic schema 

Feature cataloguing met 

� 

� 

s 

s 

u 

u 

u 

s 

s 

G 612031 

19106 Profiles � � � � � 612031 

19119 Services � � � � � 612031 

INTERLIS 2, Abschnitt 

2.8.7 Koordinaten, 2.8.11 

Linienzüge, 

2.8.12 Flächen, Gebiete 

INTERLIS 2, Anhang J 

Koordinaten(ref)system 

INTERLIS 2 Anhang H 

Zeit-Definitionen 

INTERLIS 2, Kapitel 1, 

Grundprinzipien, UsHB 


2.4 Vererbung 


1.8 Dienste, Werkzeuge 

G G G G 

G G u G 

G s u G 

G G G G 

G G s G 

G u u G 

Integrierbarkeit/Transferierbarkeit . 

19118 

19136 

Encoding 

GML 

� 

� 

u 

s 

u 

u 

u 

s 

G 

G 612031 

INTERLIS 2, Kapitel 3 

sequentieller Transfer 

G G G G 

19117 Portrayal � u u u s 612031 


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 Transferformate 

(und andere Dienste) eindeutig generieren zu können. Diese Präzisierung sollte 

nicht versteckt werden in XSLT-Skripts, sondern offengelegt werden mit einer normierten 

textueller konzeptionellen OO Beschreibungssprache. 

Die Lücke bei den Schweizer Normen im Bereich Web-Services bedeutet nicht, dass es 

keine INTERLIS basierten Web-Dienste gibt. Im Gegenteil. Es sind verschiedene grosse 

Geo-Portale in Betrieb mit Hilfe von INTERLIS. Hingegen soll darüber hinaus versucht 

werden, durch eine Kombination der modellbasierten Methode mit den OGC 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 modellbasierte 

Ansatz, aus einem system- und formatunabhängigem Datenmodell automatisch 

verschiedene Formate herzuleiten gemäss definierten Regeln (und in Zukunft auch verschiedene 

Protokolle), ist auch in dieser Beziehung sehr viel versprechend. 

Bleibt zum Schluss noch die Frage, ob die Geo-Normung den mehrdimensionalen Spagat 

zwischen Technikdynamik und Anforderungswidersprüchen erfolgreich meistert. 

Wir müssen die Beantwortung der Zukunft überlassen. Aber mindestens ist mit dem 

Entscheid für die modellbasierte Methode eine sehr tragfähige Voraussetzung für einen 

Erfolg geschaffen. 


Adrian Annen 

Fachhochschule beider Basel 

Abteilung Vermessung und Geoinformation 

Gründenstrasse 40 

CH-4132 Muttenz 

Tel : 

Fax : 

E-Mail : 

+41 61 467 44 68 

+41 61 467 44 60 

5 

Open Geospatial Consortium OGC 

GML, WMS und WFS 

Adrian Annen, Fachhochschule beider Basel 

(FHBB), Abt. Vermessung und Geoinformation

1 Kurzfassung 

Mit dem Open Geospatial Consortium (OGC) existiert ein internationales Industriekonsortium 

mit dem Ziel, die Interoperabilität von Geodaten zu verbessern. Die Abkürzungen 

GML, WMS und WFS, welche im Zusammenhang mit dem OGC oft verwendet 

werden, sind Bezeichnungen für offene, systemunabhängige Mechanismen 

zum Austausch von Geodaten. Bei der Geography Markup Language (GML) handelt 

es sich um eine XML-basierte Applikation für die Modellierung und den Austausch 

von Daten mit Raumbezug. GML wird unter anderem für verschiedene Webdienste 

verwendet. Als Beispiel kann der Web Feature Service (WFS) genannt werden, welcher 

für den Austausch und die Manipulation von Daten über das Web verwendet 

wird. Demgegenüber bietet der Web Map Service (WMS) einen Webdienst für gerenderte 

Karten an. Die WMS-Spezifikation ist die bisher am erfolgreichsten umgesetzte 

Spezifikation des OGC. 

2 Einleitung 

Im Zusammenhang mit dem Begriff der Interoperabilität im Geoinformationsbereich 

werden oft Abkürzungen wie OGC, GML, WMS und WFS verwendet. Seit den frühen 

neunziger Jahren hat sich in diesem Bereich eine breit abgestützte Organisation (Open 

Geospatial Consortium) gebildet, welche bestrebt ist, offene, systemneutrale Schnittstellen 

zu schaffen, und so die Verfügbarkeit von Daten mit Raumbezug weltweit zu erhöhen. 

Dabei wird auf bestehende Standards der Informatik-Welt aufgebaut. Zum Beispiel 

dient XML als Grundlage für praktisch alle Spezifikationen des OGC. 

Eine bereits erfolgreich umgesetzte Spezifikation des OGC ist der Web Map Service 

(WMS). Diese wurde von diversen kommerziellen Herstellern und von einigen 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 wiederum 

bauen auf GML auf. Ein Beispiel für solche Webdienste ist die Web Feature Service 

(WFS)-Spezifikation. 

In den folgenden Abschnitten werden das OGC selbst, sowie die oben genannten Spezifikationen 

näher vorgestellt. Zu beachten ist, dass damit nur ein kleiner Ausschnitt der 

vielfältigen Arbeit des OGC beleuchtet werden kann. Für detailliertere Informationen 

sei an dieser Stelle auf die Webseite www.opengeospatial.org verwiesen. 

3 Open Geospatial Consortium (OGC) 

3.1 Wer ist das OGC? 

Das Open Geospatial Consortium (OGC) ist ein internationales Industriekonsortium, 

bestehend aus über 270 Firmen, Behörden und Hochschulen, welches sich zum Ziel gesetzt 

hat, öffentlich verfügbare Schnittstellen-Spezifikationen im Konsensverfahren zu 

entwickeln. OGC-Spezifikationen unterstützen interoperable Lösungen, welche das 

Web, mobile Anwendungen, Location Based Services (LBS) und allgemeine Informatiklösungen 

um einen Raumbezug erweitern. Mit den OGC-Spezifikationen soll es Entwicklern 

möglich sein, komplexe Geoinformationen und darauf basierende Dienste einem 

breiten Spektrum von Nutzern und Anwendungen zugänglich zu machen. 



Open Geospatial Consortium OGC (GML, WMS und WFS) 

Das OGC finanziert sich primär über die Beiträge seiner Mitglieder. Zurzeit existieren 

acht verschiedene Mitgliederkategorien. Diese unterscheiden sich im zu entrichtenden 

Jahresbeitrag (zwischen 300$ bis >50'000$ pro Jahr) aber auch in den Rechten und Pflichten. 

OpenGIS® ist eine geschützte Marke des Open Geospatial Consortium, Inc. und dient 

gleichzeitig als Produktname für die Spezifikationen und Dokumente, welche vom OGC 

erstellt und publiziert werden. 

3.2 Geschichte 

Die wichtigsten Ereignisse in der Geschichte des OGC können wie folgt zusammengefasst 

werden: 

Jahr Meilenstein 

Diverse Aktivitäten rund um das Open Source Projekt GRASS 

80er Jahre 

(Geographic Resource and Analysis Support System) 

Gründung des Open GIS Consortium, Inc. 

1994 

Mitgliederzahl Ende 1994: 20 

Publikation der OpenGIS Web Map Server Interface Specification 

1999 und des Zusammenarbeitsvertrags zwischen ISO/TC 211 und OGC 


Umbenennung in Open Geospatial Consortium, Inc. 

2004 


Im Januar 2005 existierten 17 Abstract Specifications und 14 Implementation Specifications. 

Zusätzlich wurden unzählige Recommendation Papers und weitere Entwürfe öffentlich 

publiziert. 

4 Geography Markup Language (GML) 

4.1 Was ist GML? 

Die Geography Markup Language (GML) ist eine XML-Applikation des Open Geospatial 

Consortiums (OGC) für die Modellierung, den Austausch und die Speicherung 

von Informationen mit Raumbezug. Die wichtigsten Ziele von GML sind: 

� Unterstützung möglichst vieler Einsatzgebiete (auch nicht-räumliche Daten können 

abgebildet werden) 

� GML als Grundlage für Internet-GIS Anwendungen 

� Einfach zu verstehende Codierung räumlicher Daten und derer Beziehungen 

� Effiziente Codierung von Geometriedaten 

� Trennung der Daten von deren Präsentation 

� Einfache Integration bereits in XML vorhandener, nicht-räumlicher Daten 

� Möglichkeit der Verknüpfung verschiedener Datensätze 

� Bereitstellung eines Basissatzes geometrischer Objekte 

Diese Ziele werden mit einer umfangreichen Spezifikation angepeilt. Die aktuelle Version 

(3.1) der GML-Spezifikation beinhaltet etwa 600 Seiten. 


4.2 Einsatzspektrum 



Eines der wichtigsten Ziele ist die universelle Verwendbarkeit von GML als Datenformat 

für beliebige Anwendungen mit räumlichem Bezug. Die hauptsächlichen 

Einsatzgebiete von GML sind: 

� Austausch von Daten zwischen verschiedenen GIS-Systemen 

� Basis für Internet-GIS Anwendungen (Bsp. Web Feature Service, WFS) 

� Basis für Location Based Services (LBS) 

4.3 Konzept 

Das Konzept von GML beruht auf dem Feature-Modell des OGC. Ein 'Feature' gemäss 

der OGC-Definition besteht aus einem Objekt mit einer Reihe von Eigenschaften ('Properties'). 

Jede dieser Eigenschaften ist charakterisiert durch ihren Namen, ihren Typ und 

ihren Wert. Wenn der Typ zumindest einer Eigenschaft eines Features geometrisch ist, 

spricht man von einem geographischen Feature. Mehrere Features können zu Feature 

Collections zusammengefasst werden. Eine Feature Collection repräsentiert allerdings 

wiederum ein Feature, so dass eine beliebig tiefe Schachtelung modelliert werden kann. 

Abb. 1 : GML-Grundkonzept 

GML 3 ist in ca. 30 XML-Schema-Dokumenten (Basisschemen) definiert. Für eine konkrete 

Anwendung von GML muss ein anwendungsspezifisches Schema abgeleitet werden, 

welches auf den in den Basisschemen definierten Klassen aufbaut. Im Applikationsschema 

können eigene Features mit anwendungsspezifischen Eigenschaften definiert 

werden. Dies kann über Erweiterung oder Einschränkung der vorhandenen Klassen 

erreicht werden. 

4.4 Verbindung zu ISO 

Das OGC ist bemüht, seine Konzepte denjenigen der ISO (International Organization for 

Standardization) anzupassen. So ist vorgesehen, die OGC-Spezifikation GML (Version 

3.x) mit der ISO Norm 19136 (Geography Markup Language GML) zu harmonisieren. 

Gegenwärtig ist die ISO Norm 19136 in der 'Commitee Stage' (Stand Januar 2005). Das 

bedeutet, dass sich das zuständige Technical Commitee (TC) der ISO mit der Spezifikation 

befasst. In diesem Fall ist das TC 211 der ISO zuständig. Für nähere Angaben wird 

auf die Website der ISO (www.iso.org) verwiesen. 




5 OGC Web Services 

5.1 Zielsetzung 

Vielerorts sind bereits grosse Mengen von Daten in proprietären Datenformaten vorhanden. 

Die Nutzung dieser Daten von fremden Systemen aus ist nur mühsam, oder 

gar nicht möglich. Eine Lösung dafür bieten Webdienste an. Dabei wird über das Internet 

auf verteilte Datenquellen zugegriffen. Neben den grossen GIS-Herstellern, die solche 

Lösungen anbieten, sind auch Open Source Projekte verfügbar, die diese Funktionalität 

zur Verfügung stellen. Weiterhin ungelöst bleibt die Verknüpfung von unterschiedlichen 

Diensten (Insellösungen). Dies ist der Ansatzpunkt der OGC Web Services. Sie 

definieren Methoden, eine Reihe von Parametern sowie Kommunikationsregeln, die einem 

beliebigen System den Zugriff auf verteilte Datenquellen ermöglichen, sofern beide 

Komponenten über die identische Schnittstelle verfügen. 

5.2 Grundprinzip 

Die OGC definierte in der OWS (OGC Web Services) Common Implementation Specification 

die Gemeinsamkeiten ihrer verschiedenen Web Services. Der Ausdruck Web Service 

beschreibt die standardisierte Weise der Integration netzwerk-basierter Applikationen. 

Für die Definition und Beschreibung der Applikationen wird XML verwendet. Die 

Kommunikation erfolgt auf der Basis von Internet-Protokollen. Durch den Einsatz von 

XML sind Web Services nicht an ein bestimmtes Betriebssystem oder eine bestimmte 

Programmiersprache gebunden. 

Abb. 2 : Funktionsschema OGC Web Services 

Das in Abb. 2 dargestellte Funktionsschema stellt folgende Funktionen dar: 

1. Client kontaktiert Server und fordert Capabilities-Dokument an 

2. Server liefert XML-formatierte Capabilities (Beschreibung der Funktionalität) des 

gewünschten Services an den Client 

3. Client fordert Daten vom Server an 

4. Server liefert die angeforderten Daten im verlangten Format 

Diese vier Schritte bilden die Grundfunktionalität eines Services nach OGC-Spezifikation. 

Je nach Service sind weitere Interaktionen zwischen Client und Server möglich, 

beispielsweise das Abfragen weiterer Informationen über ein Feature, ein Kartenlayer 

etc. 

Web Services kommunizieren (gemäss ihrer Definition) mit Hilfe von beliebigen Internet-Protokollen 

miteinander. Die meisten OGC Web Services benutzen zurzeit das 

HTTP-Protokoll. Das Hyper Text Transfer Protocol (HTTP) verfügt über ein sehr einfaches 

Interaktionsschema zwischen Client und Server, welches aus einem von einem 

Client an einen Server gesendeten Request (Anfrage) und einer vom Server an den 

Client geschickten Response (Antwort) besteht. 


5.3 Web Map Service (WMS) 



Die WMS-Spezifikation beschreibt eine Schnittstelle, über welche georeferenzierte Karten 

bereitgestellt werden können. Die Realisierung basiert auf drei Grundoperationen, 

für die jeweils ein Parametersatz definiert ist: 

� Beschreibung der verfügbaren Daten (GetCapabilities) 

� Lieferung der angeforderten Daten (GetMap) 

� Abfragen weiterer Informationen (GetFeatureInfo) 

Dabei sind die ersten beiden Operationen zwingend zu implementieren, die Funktion 

zur Abfrage von Feature-Informationen ist optional. 

Der Zugriff auf einen WMS kann mit Hilfe eines Standardbrowsers erfolgen, wobei die 

Parameter in der URL übermittelt werden (GET Methode). Komfortabler sind natürlich 

Programme mit einer graphischen Benutzeroberfläche (GUI), entweder als Browser- oder 

als Standalone-Applikation konzipiert. Mit der aktuellen WMS-Version (1.3) ist auch 

die Übermittlung der Anfragen mit der POST Methode festgelegt. 

Im Allgemeinen liefert ein WMS gerenderte Bilder in einem üblichen Bildformat wie 

PNG (Portable Network Graphics), JPEG (Joint Pictures Expert Group) oder GIF (Graphics 

Interchange Format). Denkbar ist aber auch die Erzeugung von Karten im 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 maschinenlesbar 

zu beschreiben. 

In Abb. 3 ist zudem das Konzept eines kaskadierenden Map Servers (Cascading Map 

Server) dargestellt. Dabei ist ein Map Server ein Client von anderen WMS und bildet 

gegen aussen einen neuen Web Map Service (Zusammenfassen mehrerer WMS in einen 

Service). 

Die Spezifikation WMS 1.3 des OGC wird zurzeit als ISO/DIS Norm 19128 (Web Map 

Server Interface) in die ISO-Normenserie integriert. 

5.4 Web Feature Service (WFS) 

Während mit dem WMS in der Regel gerenderte (Raster-)Daten geliefert werden, steht 

bei der WFS-Spezifikation die Übertragung von geographischen Objekten im Vordergrund. 

Dabei stellt sich das Problem, dass Geodaten oft nicht nach einem einheitlichen 

Datenschema modelliert sind. Deshalb ist es wichtig, dass das Datenschema mit den Daten 

mitgeliefert wird. Ein entsprechender Client muss somit mit diesem Datenschema 

und den Daten umgehen können. 




Als Grundlage für die WFS-Spezifikation dient der Datenaustauschmechanismus GML 

(Geography Markup Language) des OGC. Damit können Geodaten und ihr zugehöriges 

Schema in XML codiert und übertragen werden. 

Im Unterschied zum WMS ist es auch möglich, diese Daten zu manipulieren und zu 

verändern. Dazu wurden weiterführende Operationen wie 'Transaction' und 'LockFeature' 

definiert. 

Die folgenden Operationen sind in der WFS-Spezifikation definiert: 

� GetCapabilities: Ein WFS muss in der Lage sein, seine Funktionalität zu beschreiben. 

Im Speziellen muss er in der Lage sein, die unterstützen Feature-Typen und die 

darauf anwendbaren Operationen anzugeben. 

� DescribeFeatureType: Auf Anfrage muss ein WFS in der Lage sein, die Struktur jedes 

unterstützten Feature-Typen zu liefern (Datenschema). Konkret wird hier ein 

GML-Applikationsschema übertragen. 

� GetFeature: Ein WFS muss in der Lage sein, Instanzen (Objekte) von Feature-Typen 

zu liefern. Zusätzlich muss er erkennen, welche Eigenschaften (properties) er mitliefern 

soll, und er muss in der Lage sein, sowohl räumliche wie auch nichträumliche 

Selektionen zu unterstützen. 

� Transaction: Ein WFS kann in der Lage sein, Operationen an Objekten auszuführen. 

Diese Operationen sind 'create', 'update' und 'delete' an geographischen Objekten. 

� LockFeature: Ein WFS kann einen Lock-Request auf eine oder mehrere Instanzen 

während der Dauer einer Transaktion anwenden. 

Dementsprechend kann zwischen verschiedenen Typen von Web Feature Services unterschieden 

werden: 

� 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 Überarbeitungsphase, 

in welcher unter anderem die Integration der Version 3 von GML diskutiert 

wird. Allerdings ist noch nicht klar, ob die vollständige GML 3 – Spezifikation 

unterstützt werden soll. Auf Grund der Komplexität der aktuellen GML-Version wird 

über eine Einschränkung mit einem Profil (Level 0) diskutiert. 

6 Fazit 

Mit dem OGC hat sich im Geoinformationssektor ein sehr aktives, internationales Industriekonsortium 

mit internationalem Standardisierungsanspruch etabliert. Durch die 

Mitwirkung grosser Systemhersteller, nationaler und internationaler Behörden und vieler 

Hochschulen ist das Konsortium mittlerweile breit abgestützt. Mit seinen Aktivitäten 

hat das OGC zu einer deutlichen Verlagerung bzw. Erweiterung des Fokus von den vielen 

nationalen Normen und Standards auf die internationale Standardisierung beigetragen. 

Erfreulich ist, dass dabei die OGC seit einigen Jahren ihre Aktivitäten mit denjenigen 

der ISO harmonisiert, was mittel- und langfristig zu einer breiteren Akzeptanz und 

auch zu stabileren Standards führen dürfte. 

Mit WMS, WFS und GML hat das OGC drei sehr nützliche Spezifikationen geschaffen. 

Dabei hat sich am Beispiel des WMS gezeigt, dass sogar die Umsetzung eines relativ 




einfachen Standards auf internationaler Basis mehrere Jahre in Anspruch nehmen kann. 

Es ist daher anzunehmen, dass die Definition von Minimalprofilen im Falle von GML 

und WFS eine erfolgreiche Umsetzung deutlich beschleunigen würde. Der für einen 

breiten Einsatz der Standards dringende Übergang von formatbasierten auf modellbasierte 

Mechanismen wurde von OGC mittlerweile erkannt und eingeleitet. Das damit 

verbundene Umdenken bei Systemherstellern und Anwendern sowie die konsequente 

Umsetzung dürften aber noch viel Arbeit und Zeit erfordern. 

7 Literatur 

Nebiker S. und Annen A. , 2004 

Vergleichsstudie INTERLIS 2 – GML 3 

Verfügbar unter: 

http://www.kogis.ch/docs/Vergleichsstudie_ILI_GML_revidiert.pdf 

[Online 21. Jan. 05] 

Nebiker, S., et al., 2004 

Skript zum GIS/SIT-Workshop 2004: 'WMS, WFS, Simple Features und Co.' 

[durchgeführt am 30. März 2004 in Bern] 

Open Geospatial Consortium Inc. (OGC), 2004 

Geography Markup Language (GML) Recommendation Paper 3.1 


http://portal.opengeospatial.org/files/?artifact_id=4700 [Online 21. Jan. 05] 


Web Map Service (WMS) Implementation Specification 1.3 


http://portal.opengeospatial.org/files/?artifact_id=5316 [Online 21. Jan. 05] 


Web Feature Service (WFS) Implementation Specification 1.0 


https://portal.opengeospatial.org/files/?artifact_id=7176 [Online 21. Jan. 05] 

International Organization for Standardization (ISO). 

Informationen zu diversen Standards 


http://www.iso.org [Online 21. Jan. 05] 


Andreas Donaubauer, Dr.-Ing. / 

Matthäus Schilcher, Univ.-Prof. Dr.-Ing. / 

Anette Huber 

Technische Universität München 

Fachgebiet Geoinformationssysteme 

Arcisstraße 21 

D-80290 München 

Tel : 

Fax : 

E-Mail : 

+49 89 289 22973 

+49 89 289 22878 

6 

OGC-Lösungen 

Möglichkeiten und Grenzen 

Andreas Donaubauer, Matthäus Schilcher, 

Anette Huber, TU München

Vorwort 

Der Beitrag gibt einen Überblick über den Stand der Technik zur Nutzung verteilter 

Geodaten auf der Basis der Standards des Open Geospatial Consortium (OGC). 

Anhand von Praxistests werden die Möglichkeiten und Grenzen von OGC-Standards 

diskutiert. Im Ausblick wird ein neues Forschungsprojekt zwischen ETH Zürich und TU 

München zum Aufbau einer grenzüberschreitenden Geodateninfrastruktur (GDI) vorgestellt, 

bei dem Synergien der beiden Lösungsansätze „modellbasierter Datentransfer“ 

und „OGC Web Services“ untersucht werden sollen. 

1 Einführung und Begriffsbestimmung 

Seit nun gut 20 Jahren werden an verschiedensten Stellen in Verwaltung und Wirtschaft 

digitale Geodaten produziert. Dabei entstand im Laufe der Zeit eine große Anzahl an 

verteilten Geodatenbeständen, deren effiziente und nachhaltige Nutzung über organisatorische 

Grenzen hinweg jedoch meist durch die derzeit existierenden heterogenen 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, logischer 

und physikalischer Ebene begründet. 

Zur Überwindung der derzeit bestehenden Probleme bei der kombinierten Nutzung 

verteilter, heterogener Geodaten werden in Wirtschaft und Forschung momentan zwei 

Lösungsansätze intensiv diskutiert und verfolgt, die auf internationalen Standards und 

Normen basieren. Zum einen der modellbasierte Datentransfer zur Überwindung der 

Heterogenität der Daten und deren zugrunde liegenden Modellen, wie er in der Geo- 

Normenserie ISO19100 konzipiert ist und mit INTERLIS, einer Schweizer Norm ermöglicht 

wird, zum anderen die Verwendung von Geo Web Services des Open Geospatial 

Consortiums OGC zur Herstellung von Interoperabilität zwischen verschiedenen 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 mittels 

OGC Web Services“ und „modellbasierter Datentransfer“ – im Folgenden mit 

„Kombinierter Ansatz“ bezeichnet. 

Tabelle 1 gibt einen Überblick über Methoden zur kombinierten Nutzung verteilter 

Geodaten und erlaubt eine Einordnung der genannten Lösungsansätze. 

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. 




Beispiele für 

Standards und 

Normen 

Beispiele für 

herstellerspezifische / 

proprietäre Formate / 

Zugriffsschnittstellen 

Datentransfer auf Dateiebene grafik-orientiert TIFF (ISO 12639), DBR (SICAD) DXF 

SVG (W3C) 

(CAD) 

„Datenintegration“ objektstrukturiert GDF (ISO 14825) Shape (ESRI), SQD 

modellbasiert INTERLIS ? 

Interoperabilität (Internet als grafik-orientiert OGC WMS Web-Zugriffs- 

Kommunikationsplattform 

Schnittstelle von 

zwischen den 

Autodesk MapGuide 

Softwarekomponenten) objektstrukturiert OGC WFS Zugriffsschnittstelle 

eines ESRI ArcIMS 

„Web Services“ 

Feature Service 

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 „Interoperabilität 

mittels OGC Web Services definiert. 

Verteilte (Geo-)Daten: (Geo-)Daten, die physikalisch oder logisch getrennt von einander 

vorgehalten werden. 

Interoperabilität: Fähigkeit zur Zusammenarbeit unabhängiger Systeme durch Anbieten 

bzw. Inanspruchnahme von Daten und Funktionalität über Softwareschnittstellen. 

Dienst / Service: Abgeschlossene Funktionalität, die von einer Softwarekomponente 

über eine Softwareschnittstelle angeboten wird. Komplexität und interne Strukturen der 

Softwarekomponente bleiben vor dem Nutzer eines Dienstes verborgen. 

Verkettung von Diensten / Service Chaining: Sequentieller oder paralleler Aufruf von 

Diensten, so dass die Antwort eines Dienstes als Eingabe für den Aufruf eines weiteren 

Dienstes in der Kette verwendet wird. Die Verkettung von Diensten ist grundlegend für 

die Erstellung von Dienstebündeln. 

Dienstebündel / Aggregate Service: Kombination einzelner Dienste zu einem höherwertigen 

Dienst. Ein Dienstebündel muss erstellt werden, wenn die Funktionalität oder 

das Datenangebot eines einzelnen Dienstes nicht ausreicht, um die Fragestellung eines 

Anwenders zu beantworten. Kern jedes Dienstebündels ist ein so genannter Aggregate 

Service, der die Benutzereingaben entgegennimmt, für die Verkettung der Dienste verantwortlich 

ist und das Endergebnis an den Benutzer ausliefert. Ein Aggregate Service 

tritt somit als Client für mehrere Dienste auf. 

Web Service: Funktionalität, die von einer Softwarekomponente über eine 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ührenden 

GIS-Hersteller sowie Open Source Software betrieben werden (siehe Abb. 1), wird 

vom Runden Tisch GIS e.V. GIS-herstellerübergreifend die Umsetzung von OGC Spezifikationen 

untersucht. Wesentliche Ziele sind es, zu zeigen: 

� dass GIS unterschiedlicher Hersteller auf Basis der OGC Standards in gemeinsamen 

Anwendungen zusammenwirken können, 

� dass durch den Zugriff auf verteilte Daten von Behörden und aus der Wirtschaft 

mittels OGC Web Services ein Nutzen für den Anwender generiert werden kann, 

� dass Praxis-Anwendungen auf der Basis des Zugriffs auf existierende, verteilte 

Geodatenbestände mittels OGC Web Services entwickelt werden können, 

� dass der Ansatz im deutschen Umfeld und länderübergreifend erfolgreich eingesetzt 

werden kann. 




Hersteller (Produkte) OGC-Spezifikationen 

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 Coordinate 

Transformation Service) 

Aggregate Services: 

implementieren mehrere 

Spezifikationen als Client 

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 

Anwendungsbeispiele 

Herstellerübergreifender 

Interoperabilitätstest WMS 

Immobilienbewertung 

(länderübergreifend) 

Leitungsauskunft aus 

verteilten GIS 

Universitäten 

Technische Universität 

München 

Universität der Bundeswehr 

München 

GIS-Dienstleistungsunternehmen 

Geo-IT 

RIWA 

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

Weitere Merkmale der OGC-Testplattform sind: 

� herstellerneutral, 

� hersteller- und branchenübergreifend, 

� grenzüberschreitend, 

� Aufbau durch Zusammenarbeit zwischen Datenlieferanten, Systemherstellern, 

Universitäten und GIS-Dienstleistungsunternehmen 

� Forschung anhand konkreter und praktisch verwertbarer Anwendungen, 

� Beitrag zum Aufbau von Geodateninfrastrukturen (GDI), 

� führend im Bereich der herstellerübergreifenden Nutzung von OGC Web Feature 

Services und im Bereich der Verkettung von OGC Web Services (Service Chaining). 

Auf der Fachmesse INTERGEO 2003 konnten mit dem hersteller- wie länderübergreifenden 

Anwendungsbeispiel „Immobilienbewertung“ demonstriert werden, dass die 

OGC-Web-Map-Service-Spezifikation (WMS) eine tragfähige Basis für interoperable 

Web-GIS-Auskunftslösungen ist. Im Vergleich zu früheren Interoperabilitä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 verteilten 

GIS“ präsentiert, das erstmals einen herstellerübergreifenden Interoperabilitätsnachweis 

auf Basis der Web Feature Service Spezifikation (WFS) lieferte. 

2.2 Anwendungsbeispiel „Leitungsauskunft aus vereilten GIS“ 

2.2.1 Ausgangssituation 

Betreiber von Leitungsnetzen (Energieversorgungs- und Telekommunikationsunternehmen, 

Kommunen etc.) sind gesetzlich dazu verpflichtet, Dritten Auskunft darüber 

zu geben, ob ihre Leitungen von einer geplanten Baumaßnahme betroffen sind. Bei einem 

Energieversorger gehen je nach Größe des Unternehmens mehrere tausend solcher 




Anfragen pro Jahr ein. Jährlich entstehen durch die Beeinträchtigungen Dritter große 

Schadenssummen an den Leitungsnetzen. Daher ist es im Interesse jedes Leitungsbetreibers, 

der Auskunftspflicht genüge zu tun [KOPPERSCHMIDT 2004]. Aufgrund 

der Vielzahl an Trassen und Sparten sowie der großen Anzahl potenzieller Anwender 

birgt die Dienstleistung einer sparten- und unternehmensübergreifenden Leitungsauskunft 

ein großes Potenzial (siehe Abb. 2). 

Kundenpotenzial 

Bürger 

Kommunen 

Tiefbauämter 

Leitungsbetreiber 

... 

GIS 

Dienstleister 

Amtliche Geobasisdaten 

-Geocodierte Adressen 

-ALK, DFK, Orthophotos 

Leitungsbetreiber 

GIS A 

GIS B 

GIS . . . C 

Gasversorger 

Stromversorger 

Telekom 

Fernwärmeerzeuger 

Wasserversorger 

Kanalbetreiber 


. . . 

. . . 

. . . 

. . . 

Grafik modifiziert nach: micus management consulting GmbH 

Abb. 2 : Leitungsauskunft aus verteilten GIS als Dienstleistung 

Um eine derartige Lösung anbieten zu können, muss ein GIS-Dienstleister Zugriff auf 

die Geodaten der Leitungsbetreiber sowie auf amtliche Geobasisdaten haben. 

Zwei Hindernisse stellen sich dem GIS-Dienstleister als potenziellem Betreiber einer 

derartigen unternehmensübergreifenden Lösung entgegen: Zum einen ist dies die Heterogenität 

und Verteiltheit der Geodatenbestände der Leitungsbetreiber, zum anderen 

sind letztere selten dazu bereit, ihre Geodaten an Dritte abzugeben. 

2.2.2 Lösungsansätze 

Aus Sicht eines GIS-Dienstleisters gibt es prinzipiell zwei technische Lösungsansätze 

um die Verteiltheit und Heterogenität der Geodatenbestände der Leitungsbetreiber zu 

überwinden: 

� Lösungsansatz A: Datenintegration (Aufbau eines GIS beim Dienstleister, das 

Kopien der Daten aller Leitungsbetreiber sowie amtlicher Geobasisdaten enthält), 

� Lösungsansatz B: Stellen von Anfragen an verteilte GIS mittels OGC Web Services 

(Daten bleiben bei den Leitungsbetreibern, diese geben lediglich Auskunft 

über Web Services Schnittstellen nach den Spezifikationen des Open Geospatial 

Consortium OGC). 

Im Fall einer unternehmensübergreifenden Leitungsauskunft erweist sich der Lösungsansatz 

A jedoch aus folgenden Gründen als problematisch: 

� 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 verantwortlich, 

was einerseits auf Seiten des Dienstleisters weitere Kosten verursacht 

und andererseits auch zu Haftungsproblemen bei Fehlinformationen aufgrund 

veralterter Daten führen kann. 

Aufgrund dieser Überlegungen beschloss der Verein Runder Tisch GIS im Jahr 2004 auf 

Basis seiner OGC Testplattform eine Lösung nach dem Lösungsansatz B, dem Zugriff 

auf verteilte GIS mittels OGC Web Services zu entwickeln. Mit diesem Projekt wurden 

u.a. folgende Ziele verfolgt: 

� Hersteller- und länderübergreifende Nutzung von Auskunftsfunktionalität auf 

Basis der OGC Web Feature Service Spezifikation 

� Aufzeigen des Potenzials von Geo Web Services mit standardisierten Schnittstellen 

am Beispiel einer innovativen Auskunftslösung. 

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). 

Browser 

OGC Web 

Map Service 

OGC Web 

Feature Service 

WFS Bridge 

Aggregate 

Service 

Internet-Verbindung 

Amtliche Geobasisdaten 

-Geocodierte Adressen 

-ALK, DFK, Orthophotos 

GIS A 

GIS B 

Strom 

Wasser 

Abwasser 


. . . 

GIS C 

GIS D 

GIS E 

Gas 

Beleuchtung 

Abb. 3 : Systemarchitektur 

Während die OGC Web Services den lesenden Zugriff auf die verteilten und über das 

Internet vernetzten Systeme der Leitungsbetreiber und der Anbieter amtlicher Geobasisdaten 

dienen, erfüllt der anwendungsspezifische so genannte Aggregate Service folgende 

Aufgaben: 

� Benutzereingaben entgegennehmen und in Anfragen an OGC Web Services 

(OWS) umformen, 

� Ergebnisse eines OGC Web Service in Anfragen an einen anderen OWS umformen, 

� Ergebnisse mehrerer OWS kombinieren, 

� abhängig vom Ergebnis eines OWS den Workflow regelbasiert verzweigen, 

� auf den Ausfall und auf Fehlermeldungen von OWS sowie auf Inkonsistenzen in 

den Ergebnissen der beteiligten OWS reagieren, 

� dem Anwender Zwischenergebnisse bzw. ein Endergebnis präsentieren, 

� Verbergen der Komplexität des verteilten Systems vor dem Anwender. 

Die folgenden Abbildungen geben den Ablauf einer Anfrage an das System „Leitungsauskunft 

aus verteilten GIS“ wieder.

Abb. 4 : Adresseingabe 



Der Anwender erhält eine Eingabemaske für die Adresseingabe vom Aggregate Service 

und gibt Strasse, Hausnummer, Postleitzahl, Ort der Schadensstelle bzw. der geplanten 

Baumaßnahme ein. 

Abb. 5 : Geokodierung 

Die vom Anwender ausgewählte Adresse wird vom Aggregate Service an einen so genannten 

Geocoding Service (hier ein Web Feature Service, der den Zugriff auf geocodierte 

Adressdaten erlaubt) gesendet. Der Geocoding Service wandelt die Adresse in 

Koordinaten um. 

Abb. 6 : Laden der Liegenschaftskarte 




Für den geographischen Ausschnitt der Adresse wird durch einen WMS-Client ein entsprechender 

Ausschnitt aus der amtlichen Liegenschaftskarte geladen. 

Abb. 7 : Schadensstelle durch Polygon abgrenzen 

Der Anwender markiert die Schadensstelle bzw. den Ort einer geplanten Baumaßnahme 

durch Einzeichnen eines Polygons auf der Liegenschaftskarte 

Abb. 8 : Leitungsanfrage an einzelne Leitungsbetreiber 

Das Polygon wird vom Aggregate Service des GIS-Dienstleisters an die einzelnen Systeme 

(WFS-Bridges) der Leitungsbetreiber übermittelt. Die WFS-Bridges formulieren die 

Anfragen an die Web Feature Services der Leitungsbetreiber (Operation „GetFeature“, 

geometrischer Filter „Intersects“ mit Polygon als Argument des Filters), wandeln die 

Antworten der WFS (GML-Dokumente) in Antworten der Form „Leitungsnetz betroffen“/“Leitungsnetz 

nicht betroffen“ um und senden diese an den Aggregate Service des 

GIS-Dienstleisters zurück. 

Der Aggregate Service des GIS-Dienstleisters fasst die einzelnen Ergebnisse der Anfragen 

an die Systeme der Leitungsbetreiber zusammen und sendet das Gesamtergebnis in 

Form einer HTML-Seite an den Anwender zurück. 

2.3 Zusammenfassung 

Das vorgestellte Anwendungsbeispiel „Leitungsauskunft aus verteilten GIS“ zeigt deutlich 

das Prinzip, die Vorteile und die technische Machbarkeit von Lösungen auf der Basis 

von OGC Web Services zur losen Verknüpfung verteilter Systemkomponenten. 


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. Vorrangiges 

Ziel der Anfragen ist es nicht, Geodaten zum Anwender zu transferieren, 

damit dieser sie analysieren und weiterverarbeiten kann. Vielmehr soll der Anwender 

eine Antwort auf seine raumbezogene Fragestellung erhalten (z.B. „Liegt 

das Flurstück X in einem Wasserschutzgebiet?“) 

� Standardisierte Dienstschnittstellen: Sowohl die Anfragen als auch die Ergebnisse 

der Anfragen sind standardisiert. Dank der standardisierten Zugriffsschnittstellen 

sind die Anfragen an Systeme unterschiedlicher GIS-Hersteller identisch aufgebaut. 

Möglicherweise komplexe interne Strukturen der Systeme sowie das konzeptionelle 

Datenmodell bleiben vor dem Anwender dank der relativ einfach aufgebauten 

Dienstschnittstellen verborgen. 

Die Vorteile: 

� 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 Datenbeschaffung, 

Datentransfer, Formatkonvertierung, Datenaufbereitung und Datenpflege. 

� Datenaktualität: Der Web-Zugriff auf Geodaten des originären Datenanbieters hat 

eine Qualitätssteigerung durch die Nutzung aktueller Daten zur Folge. 

� Wiederverwendbarkeit von Komponenten: Einmal im Web veröffentlichte Geo 

Web Services sind mehrfach verwendbar. Durch die vielfältigen Kombinationsmöglichkeiten 

von Geo Web Services können einmal eingerichtete Geo Web Services 

in einer Vielzahl an Lösungen verwendet werden. 

3 Grenzen von OGC Web Services 

Die aktuellen Grenzen der Interoperabilität mittels OGC Web Services zur kombinierten 

Nutzung verteilter Geodaten werden im Folgenden dargestellt. 

3.1 Grenzen in der Praktikabilität 

Bei der Lösung raumbezogener Fragestellungen aus der Praxis mittels verteilten Geodaten 

und OGC Web Services zeigten sich folgende, heute noch bestehende Mängel in der 

Praktikabilität des Lösungsansatzes: 

� Aufwand bei der Kombination von OGC Web Services unterschiedlicher Typen: 

Sollen OGC Web Services unterschiedlicher Service-Typen (z.B. Gazetteer 

Service und Map Service) in einer Service Kette miteinander verknüpft werden, so 

kommt es auf die Konsistenz der OGC Standards untereinander an. Hier sind 

noch einige Inkonsistenzen festzustellen, die bei der Kombination von OGC Web 

Services unterschiedlicher Typen zu einem Mehraufwand aufgrund syntaktischer 

Umformung bedeuten. Im oben beschriebenen Anwendungsbeispiel „Leitungs- 




auskunft aus verteilten GIS“ werden diese Inkonsistenzen durch Programmieraufwand 

beim Aggregate Service kompensiert. 

� Betrachtet man die Konsistenz zwischen den Standards für Web Services der Informatik 

und der Geoinformatik, so stellt man fest, dass die momentan gültigen 

Versionen der OGC Spezifikationen insbesondere den für Web Services gängigen 

SOAP-Standard noch nicht unterstützen, was eine Integration der OGC Web Services 

in die allgemeine IT-Landschaft behindern könnte. 

� Übertragungsrate im Internet: Die Ergebnisse von Anfragen an OGC Web Services 

können ein großes Datenvolumen haben (z.B. hochaufgelöste Rasterbilder bei 

WMS, GML-Daten bei WFS), so dass bei den heute möglichen Übertragungsraten 

die verteilte Datenhaltung und verteilte Verarbeitung nicht immer praktikabel ist. 

� Grenzen der Verteiltheit und Modularität: Untersuchungen der TU München 

[Donaubauer 2004a] haben gezeigt, dass zur Lösung einer raumbezogenen Fragestellung 

auf Basis verteilter Datenhaltung und OGC Web Services im Vergleich 

mit dem Zugriff auf einen integrierten Datenbestand unter Umständen ein Vielfaches 

an Anfragen gestellt werden müssen. 

3.2 Grenzen in der Akzeptanz 

Die Akzeptanz des Lösungsansatzes in der Praxis, bei GIS-Herstellern wie bei den (potenziellen) 

Betreibern von OGC Web Services (z.B. Datenanbieter und Dienstleister) ist 

grundlegend dafür, dass ein Nutzen für Anwender entsteht. Erst wenn viele Hersteller 

ausgereifte OGC-Schnittstellen für ihre Systeme sowohl auf Server- als auch auf Client- 

Seite anbieten und erst wenn die Großkunden der GIS-Hersteller, z.B. die großen Datenproduzenten, 

diese Schnittstellen nachfragen und einsetzen, wird es interessant und 

wirtschaftlich sinnvoll, den Lösungsansatz für Praxisanwendungen einzusetzen. 

Ein Teil der Spezifikationen für OGC Web Services findet heute bereits eine breite Unterstützung 

in den Produkten der GIS-Hersteller. Herstellerübergreifende Interoperabilität 

wurde insbesondere für die am häufigsten implementierte, grafikorientierte Spezifikation 

WMS mehrfach getestet (vgl. z.B. KUNKEL/TEEGE 2003). Die Praxistauglichkeit 

WMS-basierter Lösungen konnte nachgewiesen werden (vgl. SCHILCHER et al. 

2004 und WILLKOMM 2004). Die oben beschriebene OGC Testplattform des Runder 

Tisch GIS e.V. zeigt, dass zwar auch die WFS-Spezifikation heute bereits von vielen 

GIS-Herstellern unterstützt wird, jedoch nur sehr selten vollständig. 

Die Umsetzung der OGC Spezifikationen beschränkt sich heute meist auf Auskunft 

aus vorhandenen Geodatenbanken, also auf den lesenden Zugriff. Die Möglichkeit 

des schreibenden Zugriffs, die ein Transactional WFS bietet, wurde nur in sehr wenigen 

Fällen umgesetzt. Gründe hierfür sind einerseits in der Komplexität der Umsetzung eines 

standardisierten Schreibzugriffs (Transaktionsmanagement, Abbruch der Verbindung 

im Internet usw.) zu suchen, andererseits aber auch in der mangelnden Nachfrage 

dieser Funktionalität seitens der potenziellen Betreiber von OGC Web Services. 

Generell gibt es immer noch große Bedenken seitens der Datenanbieter als potenziellen 

Betreibern von OGC Web Services, einen Zugriff auf ihre Systeme über das Internet zuzulassen. 

Dies könnte auch daran liegen, dass die OGC Spezifikation in den Bereichen 

Sicherheit und Zugriffskontrolle (Digital Rights Management) noch Lücken aufweisen. 

Auch ein Standard für einen Web Service zur Abrechnung von Leistungen befindet 

sich noch in der Entwurfsphase. 


3.3 Grenzen in der Funktionalität 



Auch wenn die Realisierung von Auskunftslösungen auf Basis von OGC Web Services 

heute kein Problem mehr darstellt, so decken die heute verfügbaren OGC Spezifikationen 

doch noch nicht alle wichtigen Analysemethoden für Geodatenbanken ab. So 

fehlen metrische Anfragen (Fläche, Umfang etc. der geometrischen Eigenschaften von 

Geoobjekten) sowie Analysemethoden, bei denen aus vorhandenen Mengen von 

Geoobjekten neue Geoobjekte gebildet werden (z.B. analytische Flächenverschneidung2). 

Die vom OGC spezifizierte Sprache „Filter Encoding“ für die Selektion von 

Geoobjekten ist in Ihrer Ausdrucksmächtigkeit verglichen beispielsweise mit SQL beschränkt. 

Prinzip des Lösungsansatzes „Interoperabilität mittels OGC Web Services“ ist es, komplexe 

interne Strukturen von Systemen vor dem Anwender zu verbergen, indem ein 

Zugriff auf die Systeme mittels der relativ einfach gehaltenen standardisierten Zugriffsschnittstellen 

ermöglicht wird (vgl. 2.3). Dies ist einerseits ein Vorteil, da der Zugriff auf 

Geodaten vereinfacht wird. Andererseits verbergen OGC Web Services so auch das 

konzeptionelle Modell, das hinter den Geodaten steckt, obwohl diese Informationen 

in bestimmten Fällen nötig wäre, um Daten weiterverarbeiten zu können, die von einem 

OGC Web Service geliefert werden. So muss zum Beispiel für komplexere Analysen die 

Struktur der einzelnen Geoobjekte und deren Beziehungen untereinander ebenso bekannt 

sein, wie die Semantik der Daten – Informationen, die aus einer eindeutigen Beschreibung 

des konzeptionellen Modells abgeleitet werden könnten. 

4 Fazit und Ausblick 

Als Folge der aktuellen Möglichkeiten und Grenzen von OGC Web Services ergeben 

sich folgende bevorzugte Einsatzbereiche: 

� OGC Web Services eignen sich für das Erstellen von Auskunftslösungen im stationären 

und mobilen Internet, 

� OGC Web Services sind immer dann zu bevorzugen, wenn Geodatenhaltung und 

GIS-Kenntnisse beim Anwender nicht vorhanden sind, 

� Hohe Anforderungen an Datenaktualität gestellt werden, 

� Ad hoc Datenkombination, d.h. schnelle Zusammenführung von Informationen 

aus unterschiedlichen Quellen, beispielsweise im Krisen- oder Katastrophenfall 

benötigt wird. 

Die beiden eingangs erwähnten Lösungsansatze zur Nutzung verteilter, heterogener 

Geodaten, OGC Web Services und Modellbasierter Datentransfer, sind Forschungsschwerpunkte 

in der Geoinformatik an der TU München (Interoperabilität mittels OGC 

Web Services) und an der ETH Zürich (Modellbasierter Datentransfer). Beide Hochschulen 

betreuen aktuell in Kooperation mit dem Bundesamt für Landestopographie, 

Swisstopo und dem Landesvermessungsamt Baden – Württemberg ein Projekt zum 

Thema: Aufbau eines grenzüberschreitenden GIS in der Bodenseeregion Baden- 

Württemberg – Schweiz auf der Basis internationaler Standards. Anhand des Anwendungsbeispiel 

grenzüberschreitende Regionalplanung wird deutlich, wie groß der Bedarf 

an der einfachen und schnellen Nutzung der Daten auch ‚jenseits der Grenze’ ist. 

2 Die TU München hat einen „Web Spatial Analysis Service“ genannten Dienst in den Standardisierungsprozess 

des OGC eingebracht, der dazu beitragen soll, diese Lücke zu schließen (vgl. 

DONAUBAUER 2004a). 




Die beiden oben genannten Lösungsansätze sollen dabei auf Vorteile und Grenzen hin 

untersucht werden. Darüber hinaus soll geklärt werden, wie eine Kombination der beiden 

Ansätze funktionieren könnte. Durch eine Verknüpfung dieser beiden Technologien 

würde eine, in dieser Ausprägung wohl erstmalige, neue Art von Web Service 

entstehen, der die vorhandenen Einschränkungen bisheriger OGC Web Services in 

Bezug auf modellbasierten Datentransfer aufheben würde. Auf Seiten von INTERLIS 

läge der Mehrwert eines solchen Konzeptes in der Integration der OGC Web Service 

Technologie. 

Der Nutzen den man sich von einer Kombination der beiden Ansätze verspricht, ist 

zum einen eine umfassende Erweiterung an Funktionalitäten, die effizientere Arbeitsabläufe 

ermöglichen, zum anderen lassen sich (intelligente, erweiterte) Web Services gut in 

Portallösungen integrieren. Portallösungen wiederum bieten den Vorteil, dass damit 

leichter nach geeigneten Web Services gesucht werden kann und diese einfacher zugänglich 

gemacht werden. Die angedachte Kombination verspricht darüber hinaus einen 

relevanten Beitrag zu regionalen, nationalen und internationalen Geodateninfrastrukturen 

zu leisten. Die Nachfrage nach Geodaten kann somit schnell und auf einfache 

Weise bedient werden, neue Nutzergruppen für vorhandene Geodaten können so gewonnen 

werden. 

5 Literatur 

� Annen, A.: Geostandards: OpenGeospatial Consortium OGC (GML, WFS, WMS). Vortrag 

im Rahmen von Interoperabilität für die breite Nutzung von Geoinformation, 

Zürich, 2005. 

� Donaubauer, A.: Interoperable Nutzung verteilter Geodatenbanken mittels standardisierter 

Geo Web Services, Dissertation an der TU München, 2004, Internet: 

http://tumb1.biblio.tu-muenchen.de/publ/diss/bv/2004/donaubauer.html 

� Donaubauer, A.; Fischer, F.; Huber, A.; Müller, S.; Plabst, S.; Straub, F.: Leitungsauskunft 

aus verteilten GIS. Projektbericht des Runder Tisch GIS e.V., München, 

2004. Internet: http://www.rundertischgis.de 

� Gnägi, H. R.; Plabst, S.: Modellbasierter Datenaustausch und Geo Web Services im Internet. 

In: Schilcher, M. (Hrsg.). Tagungsband zum 9. Münchner Fortbildungsseminar 

Geoinformationssysteme, München, 2004. 

� Kopperschmidt, W.: Unternehmensprozesse optimieren durch Web-Services am Beispiel 

digitaler Planauskunft. In: Schilcher, M. (Hrsg.). Tagungsband zum 9. Münchner 

Fortbildungsseminar Geoinformationssysteme, München, 2004. 

� Kunkel, T.; Teege, G.; Seuß, R.: Projektbericht zu den Stufen IA und IB des Projektes 

„Interoperabilität auf der Basis von OpenGIS Web Services – Länderübergreifende Datennutzung 

bei verteilten Geodatenbanken und unterschiedlichen Herstellersystemen für das 

Anwendungsbeispiel Real Estate“. Runder Tisch GIS e.V., München, 2003. 

� Shi, W.: Zum modellbasierten Austausch von Geodaten auf Basis XML. Dissertation an 

der Universität der Bundeswehr München, München, 2004 

� Schilcher, M. et al.: OGC Web Services zur interoperablen Nutzung verteilter Geodatenbanken 

für die Immobilienwirtschaft. In: Bernard, L., Fitzke, J. und R. Wagner (Hrsg.): 

Geodateninfrastrukturen. Grundlagen und Anwendungen. Heidelberg, 2004. 

� Schilcher, M.; Aumann, G. et al.: Abschlussbericht Forschungsprojekt GeoPortal. München, 

2004. 

� Willkomm, Ph: Interoperabilität auf der Basis von OpenGIS Web-Services Bericht aus 

Forschung und Praxis. In: Schilcher, M. (Hrsg.). Tagungsband zum 9. Münchner 

Fortbildungsseminar Geoinformationssysteme, München, 2004. 


Claude Eisenhut 

Eisenhut Informatik AG 

Rosenweg 14 

CH-3303 Jegenstorf 

Tel : 

Fax : 

E-Mail : 

+41 31 762 06 62 

+41 31 762 06 64 

7 

ISO-Standards für den Datentransfer 

Stand der Realisierungen / Werkzeuge 

Claude Eisenhut, Eisenhut Informatik AG

1 Theorie 

1.1 Was für eine Interoperabilität? 

Interoperabilität ist die Zusammenarbeit von Anwendungen in einem offenen System. 

Unabhängig von der verwendeten Hardware, den eingesetzten Betriebssystemen, der 

verwendeten Netzwerktechnologie und der Realisierung einer Anwendung kann eine 

Zusammenarbeit mit anderen Anwendungen erfolgen. Dazu ist in der Regel die Einhaltung 

gemeinsamer Standards notwendig, aber ohne dass dazu gesonderte Absprachen 

zwischen den Anwendungen notwendig sind. 

In einem Integrationsprojekt gibt es normalerweise einen Auftraggeber und (innerhalb 

des Projektes) eine definierte Anzahl Anwendungen die zusammenarbeiten sollen. Trifft 

man innerhalb des Projektes über den Standard hinausgehende Absprachen, hat das auf 

die Zusammenarbeit keine negativen Auswirkungen. Die durch die Absprache betroffenen 

Anwendungen sind bekannt und im Einflussbereich des Projektes. 

Beim Aufbau einer Daten-Infrastruktur sind die Anwendungen, die zusammenarbeiten 

sollen, nicht bekannt und/oder ändern sich laufend. Eine über den Standard hinausgehende 

Absprache ist darum unmöglich! 

Funktionierende, „ausführbare“ Standards, die keine zusätzlichen Absprachen erfordern, 

sind darum für Interoperabilität, wie sie eine Daten-Infrastruktur benötigt, eine 

zwingende Voraussetzung! 



ISO-Standards für den Datentransfer: Stand der Realisierungen / Werkzeuge 

1.2 Welche ISO-Normen? 

Norm Titel Stand Beschreibung 

OMG Unified Modeling Diverse 

Kästchendiagramme 

UML Language 

Versionen. 191xxx 

basiert auf UML 

1.3 

ISO 19103 Conceptual schema DTS Einschränkung von UML + 

language 

Basisdatentypen wie Text, Zahl, 

usw. 

ISO 19109 Rules for 

DIS Metamodell 

applicationschema 

(=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 IS Datenmodell für 

coordinates 

Koordinatenreferenzsysteme 

ISO 19112 Spatial referencing by IS Datenmodell für geographische 

geographic identifiers 

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! 

W3C 

XML 

XML 1.0 (selten 1.1) Flexibles Textformat 

W3C XML-Schema 1.0 Beschreibungssprache für XML- 

XML- 

Schema 

Dateien 

ISO 19136 Geography Markup CD (GML 3.2) Gemeinsame Spezifikation von 

Language 

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 


Modellierungs 

sprache 

(UML+19103 

(19109)) 



Vordefinierte 

Datentypen und 

Modelle 

(19107, 19108, 

19111, 19112, 

19115, 19123) 

Kodierung 

(19118) 

GML (19136, XML, XML-Schema) 

Kodierungsregeln 

(müssen definiert 

werden!) 

Zusammenhang zwischen den einzelnen ISO-Standards 

Applikationsmodell in 

UML (z.B. Amtl. 

Vermessung) 

Konkretes 

Transferformat 

Anwendung der ISO-Standards ohne GML 

Man modelliert mit Hilfe von UML sein Datenmodell, berücksichtigt dabei die Einschränkungen 

von 19103 und verwendet die durch 19103, 19107 etc. definierten Basistypen. 

Zusätzlich definiert man allgemeine Kodierungsregeln, z.B. wie ein Objekt und 

dessen Attributwerte kodiert werden. Dann wendet man die selbst definierten Kodierungsregeln 

auf das eigene Datenmodell an, um so das konkrete Transferformat zu erhalten. 

Ohne ISO 19136 (GML) müssen für ein konkretes Transferformat zusätzliche Absprachen 

gemacht werden! 

Anwendung der ISO-Standards mit GML 

Man modelliert mit Hilfe von UML sein Datenmodell, berücksichtigt dabei die Einschränkungen 

von GML (beinhaltet auch diejenigen von 19103), und verwendet die 

durch GML (beinhaltet 19103, 19107, etc.) definierten Basistypen. Dann wendet man die 

durch GML definierten Kodierungsregeln auf das eigene Datenmodell an, um so das 

konkrete Transferformat zu erhalten. Das Resultat ist ein XML-Schema das den Regeln 

von GML entspricht. Für ein konkretes Transferformat sind keine zusätzlichen Absprachen 

erforderlich. 




1.3 Verschiedene Modellierungsansätze 

Mit 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 Transferformat 

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 decken 

nicht alle möglichen GML-Schemas ab. 

UML-Modell als Norm; GML-Schema als Transferformat 

Gemäss diesem Ansatz ist das UML-Modell massgebend, und das automatisch hergeleitete 

GML-Schema dient nur zum Datentransfer. 

Vorteil dieses Ansatzes: 

� 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 entsprechenden 

Abbildungsregeln von UML nach GML in 19136 (Anhang E) fehlen. 

� Für das konkrete Transferformat ist eine Übersetzung des UML-Modells notwendig. 

Für den Anwender ist das nur ein Knopfdruck, der Software-Entwickler 

muss aber das UML-Modell, das Transferformat und die Übersetzungsregeln 

während der Realisierung in Gedanken präsent haben. 

1.4 Beurteilungskriterien 

Bei der Auswahl eines Datentransferstandards, sind die folgenden Kriterien zu berücksichtigen. 

Je nach Kontext wird man den einen oder anderen Faktor höher gewichten. 

� Wie sichert man die Daten gegen Verlust wegen heute noch unbekannten technischen 

Entwicklungen? 

� Wie sichert man die Daten gegen Verlust wegen Personalwechsel? 

� Welche Auswirkungen haben Modelländerungen? 

� Genügt ein einziges Transferformat oder werden für dieselben Daten verschiedene 

Transferformate benötigt? 

� Wie prüft der Nutzer, dass er erhalten hat, was er bestellt hat? 




� 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 

� Formatbeschreibung 

� Wie sehen die Daten aus? 

� Datenprüfung 

� Konvertierungswerkzeuge 

� Sind die Modellierungskonzepte in den GIS vorhanden? 

� Werkzeuge für die Softwareentwicklung 

3 Beurteilung 

Die ISO-Normen sind lesbar. Es ist aber aufwendig, einerseits wegen dem Umfang der 

einzelnen Normen, andererseits weil sich die relevanten Konzepte über mehrere Normen 

verteilen. 

Mit entsprechendem Aufwand sind die ISO-Normen realisierbar. Der Aufwand ergibt 

sich dadurch, dass das jeweilige Thema, z.B. geometrische Datentypen, sehr umfassend 

definiert wird. 

Für Interoperabilität sind die ISO-Normen nur beschränkt tauglich. Es gibt zu viele Widersprüche 

zwischen den einzelnen Normen und zu oft werden abstrakte Ideen definiert, 

die sich nicht direkt realisieren lassen. Im Bereich des Datentransfers ist die Norm 

19136 (GML) ein erster nützlicher Schritt. 

Verbesserungsvorschlag 

Statt seit drei Jahren im Projekt 19139 ein Transferformat für Metadaten zu entwickeln, 

sollte das TC211 die Kodierungsregeln von 19136 (GML) auf das Metadatenmodell 

(19115) anwenden. So hätte man direkt innerhalb des TC211 eine Rückmeldung zur Realisierbarkeit. 




4 Ausblick 

Der Kosten/Leistungsdruck bleibt auch in Zukunft bestehen! 

Innovative Unternehmen suchen darum nach neuen Einteilungen der Prozessketten. 

Interoperabilität reduziert die Schnittstellenkosten und ermöglich somit neue Einteilungen. 

Datentransfer ist out! Die Zukunft gehört den (Web-)Diensten! 

(Web-)Dienste sind nicht für menschliche Benutzer gedacht sondern für Anwendungen, 

die automatisiert Daten austauschen und/oder Funktionen auf entfernten Rechnern 

aufrufen. 

Ohne funktionierenden Datentransfer geht bei Diensten aber gar nichts. 

Jeder Funktionsaufruf selbst ist implizit ein Datentransfer. Der Funktionsname und die 

aktuellen Funktionsargumente müssen von einem Rechner zum anderen transferiert 

werden und das Resultat muss wieder zurück. 

Braucht es noch INTERLIS? 

Das INTERLIS-Transferformat bietet einige Möglichkeiten (inkrementellen Transfer, 

mehrsprachige Tags), die GML nicht bietet. Benötigt man diese nicht, kann man ohne 

weiteres GML für den Transfer einsetzen. Das Basis-Schema des 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. 


Marc Gilgen 

État de Vaud 

Département des infrastructures 

Service de l’information sur le territoire 

Av. de l’Université 3 

CH-1014 Lausanne 

http://www.dinf.vd.ch/sit 

Tel : 

Fax : 

E-Mail : 

8 

Interoperabilität von Geodaten 

Aktueller Stand und Zukunftsperspektiven im 

Kanton Waadt 

+41 21 316 34 83 

+41 21 316 24 84 

Marc Gilgen, État de Vaud 

Service de l’information sur le territoire 

In Zusammenarbeit mit 

Sandrine Durler, État de Vaud 

Lucien Imhof, État de Vaud 

Bruno Magoni, ASIT-VD

1 Einleitung 

Seit mehr als 10 Jahren hat der Kanton Waadt an der Interoperabilität im Bereich der 

Geodaten gearbeitet. Die Vereinigung für das Landinformationssystem des Kantons 

Waadt (ASIT-VD1), mit ihrem Auftrag einer Plattform für den Datenaustausch, hat frühzeitig 

eine Metadatenbank mit einem Katalogisierungsdienst (dem so genannten Géocatalogue) 

und einem Online-Bestelldienst aufgebaut. Gleichzeitig hat die kantonale Verwaltung, 

wichtiges Mitglied der ASIT-VD, die notwendigen Mittel für ein Geoinformationssystem 

innerhalb der kantonalen Verwaltung2 aufgebracht. Diese Infrastruktur und 

Organisation haben den Datenaustausch gefördert und weiterentwickelt. Gleichzeitig 

sind auch Interoperabilitäten zwischen Informatik-Applikationen entstanden. 

Dank des Geoportals der ASIT-VD ist der Kanton Waadt zur Zeit der Hauptlieferant 

raumbezogener Daten. Er profitiert von den Diensten der ASIT-VD im Bereich der Katalogisierung 

und der Bestellung und er nutzt sie häufig. Eine Voraussetzung dazu ist eine 

zweckmässige technische und organisatorische Infrastruktur innerhalb der kantonalen 

Verwaltung. Aus dem technischen Standpunkt funktioniert das Informationssystem 

des Kantons hauptsächlich durch das Prinzip des Datenpools (Datawarehouse), bestehend 

aus den spezifischen Datenbanken der verschiedenen Abteilungen. Dieser zentrale 

Datenpool ermöglicht es, viele GIS-Applikationen innerhalb des Kantons anzubieten 

und Interoperabilitäten im Bereich der Geodaten zu entwickeln. 

2 Aktueller Stand der Realisierungen 

2.1 Interoperabilitäten im Bereich der Geodaten 

Die von der kantonalen Verwaltung und von der ASIT-VD bearbeiteten Interoperabilitäten 

im Bereich der Geodaten können einfach aus einem URL-Link aber auch aus viel 

komplexeren Realisierungen bestehen. Untenstehend kommen wir auf die folgenden 

Interoperabilitäten einzeln zu sprechen : 

Abfrage von Geodaten in administrativen Applikationen 

� Abfrage von geographischen Ebenen für Baubewilligungen 

� Kartendienst für Internet-Applikationen 

� Online-Bestellung von Geodaten (geographische Objekte auswählen und extrahieren) 

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.ch 

2 http://www.dinf.vd.ch/sit 



Interoperabilität von Geodaten : aktueller Stand und Zukunftsperspektiven im Kanton Waadt 

2.2 Abfrage von geographischen Ebenen für Baubewilligungen 

Die kantonale Abteilung, die die Baubewilligungen erteilt (Baubewilligungzentrale3) verfügt über eine Internet-Applikation, die es ermöglicht, verschiedene geographische 

Ebenen in der zentralen Datenbank abzufragen. Die Baubewilligung wird unter Berücksichtigung 

mehrerer Kriterien erteilt. Die geometrische Dimension in Verbindung mit 

der geographischen Lage des zukünftigen Baus spielt in vielen von diesen Kriterien eine 

wichtige Rolle. Zudem wird die vom Bau beeinflusste Ausdehnung in der Webapplikation 

erfasst, um das Ausmass des zukünftigen Baus möglichst gut zu berücksichtigen. 

Die räumliche Abfrage wird auf der Grundlage eines geometrischen Schnitts zwischen 

dem zum Ausmass des zukünftigen Baus proportionalen Kreis und den geographischen 

Ebenen durchgeführt. Die Resultate werden dann der Internet-Applikation zurückgeschickt. 

Diese Interoperabilität ermöglicht verschiedene Verifikationen, die ohne einen 

solchen automatischen Prozess sehr mühevoll wären. 

Eine der Verifikationen betrifft den Namen der Gemeinde. Dieser wird nämlich wie die 

geographischen Koordinaten des Baugesuchs manuell eingegeben. Dank der räumlichen 

Abfrage wird geprüft, ob die geographische Lage des Baugesuches innerhalb des 

Umkreises der Gemeinde liegt. 

Die Mehrheit der abgefragten Ebenen werden im Datawarehouse gespeichert. Einige 

sind in Dateien gespeichert. Durch diesen Mechanismus können wir die Verträglichkeit 

des Baus mit verschiedenen rechtskräftigen mit der Raumplanung verbundenen Einschränkungen 

prüfen, insbesondere mit der Bodennutzung, dem Grundwasserschutz, 

den Kantons- und Bundesinventaren, den Schutzmassnahmen für die Gebäude (für ein 

schon bestehendes Gebäude). Bei einem Interessenskonflikt zwischen einem Baugesuch 

und einer Zone eines Inventars beispielsweise, wird der Mechanismus die Abteilungen 

erwähnen, die befragt werden müssen, um eine Baubewilligung zu erteilen. Dieser automatisierte 

Prozess ermöglicht einer « nicht-geographischen » Applikation einen geographischen 

Server abzufragen. 

2.3 Interoperabilitäten des kartografischen Internet-Schalters 

Dank des kartografischen Internet-Schalters des Kantons Waadt (GéoPlaNet4) können 

die von der kantonalen Verwaltung hergestellten und benutzten Geodaten auf dem Internet 

veröffentlicht werden. Dieser Internet-Schalter profitiert auch von der Integration 

der Geodaten in einem einzigen Datenpool. Es gibt ausserdem viele Schnittstellen (unioder 

bidirektional) mit anderen Applikationen. Zum Beispiel können wir folgende erwähnen 

: Schnittstellen mit dem Grundbuch5 (Grundbuchauszüge), mit der Baubewilligungszentrale6 

(Visualisierung der Akten), oder auch mit der wirtschaftlichen Förderung7 

(Suche nach verfügbarem Gelände). 

Die wichtigsten Interoperabilitäten, die mit dem kartografischen Internet-Schalter verbunden 

sind, werden nachfolgend beschrieben. Diese Interoperabilitäten zeigen schon 

das Prinzip, das Interesse und das Potential eines universellen Portals, das die Dienstleistungen 

des Kantons durch ein einziges Portal anbietet. 

3 http://www.camac.vd.ch 

4 http://www.geoplanet.vd.ch 

5 http://www.rf.vd.ch 

6 http://www.camac.vd.ch 

7 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ächlich 

beim Kartendienst von Interesse. Dieser von GéoPlaNet geleistete Dienst ermöglicht 

Karten in eine andere Applikation dynamisch zu integrieren (einfacher Kartendienst) 

oder zur Benutzungsoberfläche des kartografischen Internet-Schalters zu kommen 

(Browserkartendienst). Die Lokalisierung wird mit Hilfe von Koordinaten oder mit Hilfe 

eines räumlichen Objekts (z.B. eine Parzelle in einer Gemeinde) gemacht. Die Parameter 

der Lokalisierung, des Massstabes und des Grösse der Karte, sowohl die Auswahl 

der Datenebenen werden über die URL-Adresse übermittelt. Die Applikationen des 

Grundbuchs, der Baubewilligungszentrale und der Wirtschaftsförderung benutzen diese 

Kartendienste. 

2.3.2 Abfrage von entfernten Datenbanken 

Umgekehrt ermöglicht der kartografische Internet-Schalter Informationen in entfernten 

Datenbanken zu finden. Zum Beispiel derjenigen des Grundbuchs: mit GéoPlaNet kann 

der Name des Besitzers einer Liegenschaft angezeigt werden. Diese Information wird 

bald mit anderen Informationen aus dem Grundbuchauszug ergänzt werden (Beschreibung 

des Grundstückes, Eigentum, Grunddienstbarkeiten, usw.). Das zeigt den Vorteil 

und die Rolle des kartografischen Internetschalters, um nicht-geografische Informationen 

zu erwerben. Dieser Zugang zur Information durch die geografische Dimension 

und durch einen einzigen Eingangspunkt ist ein grosser Gewinn für den Benutzer. 

2.3.3 Zugang zu den Metadaten 

Was die Metadaten betrifft, bietet der kartografische Internet-Schalter einen direkten 

Zugang zum Géocatalogue der ASIT-VD8 an, in dem alle Geodaten beschrieben werden. 

Es handelt sich hier darum, dass die Koppelung der Daten mit den Metadaten innerhalb 

des Visualisierungsdienstes für Geodaten (GéoPlaNet) gewährleistet wird. 

2.4 Online-Bestellung von Geodaten 

Dank des Portals Géocommande der ASIT-VD9 können Geodaten auf dem Gebiet des 

Kantons Waadt online bestellt werden. Der Benutzer kann seine Daten via Géocatalogue 

auswählen und ein Suchgebiet für die Extraktion (Text- oder räumliche Suche) definieren. 

Zusätzlich zum Visualisierungsdienst, der benutzt wird, um die Basiskarten darzustellen, 

bietet die geografische Auswahl eigentlich einen Auswahldienst durch ein Objekt 

an. Die geografischen Objekte, die ausgewählt werden können, sind die Bezirke, die 

Gemeinden, die Umkreise der Katasterpläne und die Parzellen. Der Kartenserver ist 

derselbe wie derjenige des kartografischen Schalters (MapServer). Diese Auswahl durch 

ein Objekt wird durch eine Datenbank PostGIS gemacht. 

Sobald das Bestellungsformular ausgefüllt ist, wird es den betroffenen Lieferanten geschickt. 

Für die Geodaten des Kantons Waadt wird die Abfrage automatisch verarbeitet: 

die Geodaten werden vom Datawarehouse aus dem ausgewählten Umkreis herausgezogen, 

dann zum Benutzer durch FTP übermittelt. Die Rechnung wird auch automatisch 

gemacht. 

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

9 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 entspricht. 

Diese Interoperabilität ist die erste konkrete Realisierung in die Richtung eines 

Schweizer Suchportals für Geodaten mit einem dezentralisierten Katalog. 

Die Interoperabilität zwischen geocat und dem Géocatalogue der ASIT-VD zeigt die 

Notwendigkeit, über gemeinsame Datenmodelle zu verfügen. Das Metadatenmodell 

GM03Core muss mindestens in jedem Metadatensystem implementiert werden. Auf der 

Basis von GM03Core werden die minimalen Metadaten ausgetauscht. Die ASIT-VD hat 

deswegen den Géocatalogue angepasst, um mit dem Schweizer Metadatenmodell 

GM03Core in Übereinstimmung zu sein. Alle obligatorische Metadaten von GM03Core 

können im Géocatalogue gefunden und dank geocat visualisiert werden. 

Die technischen Entwicklungen, die die Interoperabilität fördern, müssen von Bemühungen 

in anderen Bereichen begleitet werden. Hier müssen die Bemühungen erwähnt 

werden, um standardisierte Datenmodelle und Vorgehen für Geodatenaustausch zwischen 

den Partnern anzunehmen oder auszuarbeiten. Zu diesem Zweck arbeiten die 

kantonale Verwaltung und die ASIT-VD zusammen. Erste Schritte im Bereich der generellen 

Entwässerungspläne (GEP11) sind erfolgreich gewesen. Jetzt wird etwas im Bereich 

der Raumplanung unternommen, um den Austausch der Daten für die Bodennutzung 

zu vereinheitlichen. 

3 Perspektive 

3.1 Webdienst über Raumgliederungen 

Demnächst wird der Kanton einen Webdienst über die Raumgliederungen aufstellen. 

Zuerst werden der Kanton, die Bezirke, die Gemeinden, die Katasterpläne und die Parzellen 

betroffen sein. Dieser Dienst gibt die Möglichkeit, Informationen über die Einheiten 

der vorher genannten Raumgliederungen (z.B. Bundesnummer und Name der Gemeinden) 

und über die Zusammensetzung und die Zugehörigkeit der Einheiten einer 

Raumgliederung in Beziehung mit den anderen Raumgliederungen (z.B. Nummer aller 

10 http://www.geocat.ch 

11 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 Vermessungslosen. 

Im Vergleich brauchen die traditionellen Methoden der Aktualisierung viel 

Zeit, in Anbetracht der vielen Applikationen, die diese Informationen benutzen. 

Mit diesem Dienst wird auch die Aktualisierung der Postleitzahlen (PLZ) und der Orte 

in jeder betroffenen Applikationen vorgesehen. Die PLZ wechseln regelmässig und 

werden mehrmals im Jahr aktualisiert12. 3.2 Geschützter Kartendienst 

Die ASIT-VD und der Kanton entwickeln und testen jetzt einen geschützten Kartendienst, 

der sich auf die OpenGIS Spezifikationen13 beruht. Im ersten Schritt wird die 

Spezifikation Web Map Service (WMS) implementiert, damit die Karten in Bildform geliefert 

werden. Der Zugang wird mit einem Benutzernamen und einem Passwort geschützt. 

Es gibt zwei Hauptziele: 

� 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ückgeschickten 

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 Vermessung, 

der Umwelt, der Raumplanung (usw.) aber auch zum Beispiel die Gemeinden. 

Im Bereich vom GIS bieten immer mehr Softwareprodukte – sowohl 

kommerzielle Produkte (z.B. MapInfo, ArcGIS) sowie "free" Programme (z.B. 

JUMP) – WMS-Klientfunktionalitäten. Die Zugangskontrolle ermöglicht es, die 

Identität des Benutzers zu erkennen und auch ein Rechnungssystem für diesen 

Direktzugangdienst zu definieren. 

� Einen zentralen kartografischen Schalterdienst (waadtländisches Portal) anbieten. 

Er wird vor allem den öffentlichen Verwaltungen angeboten unter der Bedingung, 

dass der Geodatenlieferant über einen Server verfügt, der 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 Visualisierung 

von Geodaten von mehreren Lieferanten ermöglichen. Wir haben als Ziel, 

dass die Daten der kantonalen Verwaltung und die von den Gemeinden gegebenen 

Daten zusammen gelegt sind. 

Dieser geschützte Dienst wird zuerst die Interoperabilität nur im Bereich der Geodaten 

ermöglichen. Dann wollen wir die Entwicklungen in Richtung Interoperabilität der 

12 http://www.poste.ch/yellowbox 

13 http://www.opengeospatial.org 




Funktionalitäten orientieren. Das heisst, dass der Zugang zu Funktionalitäten der Applikation 

des Lieferanten durch den zentralen Schalter und auch von irgendwelchen 

Klienten möglich sein wird. Es ist klar, dass die Aufstellung einer solchen Interoperabilität 

nur möglich ist, wenn Funktionalitäten in Form von Webdiensten entwickelt werden. 

Für die kantonale Verwaltung sind diese Perspektive nicht nur technische Ziele und 

Herausforderungen, sondern auch strategische. Die Aufstellung von solchen Interoperabilitäten 

wird nämlich den Geodatenvertrieb, ihre Tarifgestaltung, ihre Verwaltung 

und ihre Aktualisierung (verteilte Kosten, gemeinsame Infrastrukturen) beeinflussen. 

4 Schlussfolgerungen 

Die Interoperabilität im Bereich der Geodaten spielt eine wichtige Rolle. Im Kanton 

Waadt können wir nach den realisierten Entwicklungen in diesem Bereich Folgendes 

bemerken: 

� 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 Rationalisierung 

der Aufgaben, die mit der Erwerbung, der Verwaltung, der Aktualisierung, 

der Veröffentlichung und dem Vertrieb der Geodaten verbunden sind (z.B. dank 

eines Online-Bestellungsdienstes der Geodaten). 

� 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 mehrfache 

Kopien, die Aktualisierung wird schneller gemacht, das Speichersystem 

wird nicht mehr so viel belastet und die Bemühungen für die Verwaltung der 

Geodaten sind nicht mehr so gross (z.B. dank des Informationsdienstes über die 

Raumgliederungen). 


Ueli Forrer 

F+P GEOINFO AG 

Geoinformatik und Vermessung 

Kasernenstrasse 69 

CH-9100 Herisau 

http://www.geoinfo.ch 

Tel : 

Fax : 

E-Mail : 

+41 71 353 53 53 

+41 71 353 53 50 

9 

Die Komplexität der Interoperabilität 

Ein einfacher Praxisbericht aus der 

Ostschweiz 

Ueli Forrer, F+P GEOINFO AG

1 Einleitung 

Interoperabilität ist für uns als GIS-Dienstleistungsunternehmen ein sehr aktuelles 

Thema und langfristig betrachtet, wird Interoperabilität zu einer Überlebensfrage solcher 

Unternehmen werden. Wenn wir uns mit Definitionen von Interoperabilität auseinander 

setzen, geraten wir direkt zur Frage der Systemabgrenzung. In unserem System, 

einer regionalen Geodateninfrastruktur, können wir zur Zeit Interoperabilität in 

diversen Teilsystemen finden. 

1.1 Definitionen zur Interoperabilität 

Interoperabilität wird in der Literatur unterschiedlich definiert. Wir beschränken uns in 

der Folge auf zwei unterschiedliche, jedoch sinngleiche Definitionen 1: 

1. Als Interoperabilität bezeichnet man die Fähigkeit zur Zusammenarbeit von verschiedenen 

Systemen, Techniken oder Organisationen. Dazu ist in der Regel 

die Einhaltung gemeinsamer Standards notwendig. Wenn zwei Systeme miteinander 

vereinbar sind, nennt man sie auch kompatibel. 

2. Interoperabilität ist die Fähigkeit unabhängiger, heterogener Systeme möglichst 

nahtlos zusammen zu arbeiten, um Informationen auf effiziente und verwertbare 

Art und Weise auszutauschen bzw. dem Benutzer zur Verfügung zu stellen, 

ohne dass dazu gesonderte Absprachen zwischen den Systemen notwendig sind. 

1.2 Systemabgrenzung 

Wenn aus der ersten Definition Interoperabilität als die Fähigkeit zur Zusammenarbeit 

von verschiedenen Systemen, Techniken oder Organisationen bezeichnet wird, dann 

lässt sich daraus logischerweise ableiten, dass die Interoperabilität vor allem auch eine 

Frage der Systemabgrenzung ist, egal ob es sich dabei um eine technische oder organisatorische 

Abgrenzung des Systems handelt. 

2 Interoperabilität am Beispiel der IG GIS AG 

In der Ostschweiz haben sich die Kantone Appenzell A.Rh., Appenzell I.Rh. und St. Gallen 

und sowie ca. 60 Gemeinden (Bezirke im Kanton AI) zu einer Interessengemeinschaft 

GIS, der IG GIS AG zusammengeschlossen. Das eigentliche Betreiben des GIS ist 

in diesen Kantonen und Gemeinden teilweise bereits seit 1997 aus der Verwaltung ausgelagert 

und einem privaten Betreiber, der F+P GEOINFO AG übertragen worden. Die 

IG GIS AG hat einen rein koordinativen Charakter und bündelt die Interessen der Aktionäre 

(Gemeinden, Bezirke und Kantone) gegenüber dem GIS-Betreiber. Die Geschäftsführung 

(50% Stelle) der IG GIS AG ist dem Dienst für Informatikplanung des Kantons 

St. Gallen angegliedert. 

2.1 Gesamtsystem 

Wenn wir den heutigen Stand der Architektur des Gesamtsystems betrachten, dann 

wird es relativ schwierig über Interoperabilität des Gesamtsystems zu berichten, weil 

das System sehr gross ist. Das Rechenzentrum der IG GIS AG ist zudem einerseits in 

das Rechenzentrum des Kantons St. Gallen (Abraxas Informatik AG) und andererseits 

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



Die Komplexität der Interoperabilität: ein einfacher Praxisbericht aus der Ostschweiz 

komplett in die Informatikstrukturen der anderen Kantone und Gemeinden eingebettet. 

Abbildung 1 zeigt die stark vereinfachte Architektur des RZ der IG GIS AG als Gesamtsystem: 

Abbildung 1 

Auf Grund der Grösse der IG GIS AG - drei Kantone und rund sechzig Gemeinden – 

können wir von einer regionalen Geodateninfrastruktur (RGDI) sprechen. Suchen wir 

in dieser Organisation Interoperabilität, dann finden wir diese in vielen, einzelnen Teilsystemen. 

Betrachten wir die „Aussenbeziehungen“ dieser 

Organisation, nämlich die vielen Datenlieferanten, andere 

RGDI’s, die künftige NGDI (Nationale 

Geodateninfrastruktur) oder gar eine europäische 

Abbildung 2 

Organisation, welche eine Geodateninfrastruktur betreibt, 

dann denke ich ganz intuitiv an den Turmbau zu Babel. 

Gemäss der oben erwähnten Definition von Interoperabilität 

müssen nun nämlich alle diese Organisationen „Informationen 

auf effiziente und verwertbare Art und Weise austauschen 

bzw. dem Benutzer zur Verfügung stellen, ohne dass dazu 

gesonderte Absprachen zwischen den Systemen notwendig sind.“ 

Dazu müssten diese nicht nur hunderte von technischen 

Standards und Normen einhalten, sie müssten auch in ihren 

betriebswirtschaftlichen Abläufen und Organisationsformen 

interoperabel oder kompatibel werden. Davon sind wir noch weit entfernt. Und wie 

beim Turmbau von Babel sind es die verschiedenen Sprachen die uns manchmal zur 

Verzweiflung bringen: So spricht der Ingenieur, welcher Fachdaten für eine Gemeinde 




erfasst, eine andere Sprache als der Informatiker, der eine regionale Geodateninfrastruktur 

betreibt. 

Dieses Grundprinzip „der verschiedenen Sprachen“ in Bezug auf Interoperabilität lässt 

sich sehr einfach nachprüfen: Sucht man im Internet nach dem Wort „Interoperabilität“, 

zeigen viele Links auf Hilfsorganisationen. Auch dort treffen verschiedenste Organisationen, 

Sprachen, Techniken und Kulturen aufeinander. 

Im Folgenden ziehe ich die Systemgrenzen enger und fokussiere auf das Gesamtsystem 

IG GIS. Zwecks besserer Übersicht teile ich das Gesamtsystem in drei Teile auf: 

� Daten 

� Applikationslogik 

� Präsentation der Daten 

Weitere Teilsysteme wären noch: 

� Systemplattformen 

� Betriebssysteme 

� Netzwerke 

� Weitere Organisationsprozesse 

2.2 Teilsystem „Daten“ 

2.2.1 Stand Heute 

Betrachten wir das Teilsystem „Daten“, dann stechen in dieser Lösung die heterogenen 

Strukturen der Ostschweiz sofort ins Auge. Kleinere Gemeinden (mit bis ca. 4500 Einwohner) 

mit bis zu 17 

verschiedenen, eigenständigen 

Korporationen sind 

keine Seltenheit. 

Dabei ist natürlich 

jede Korporation ihr 

eigener Datenherr 

und bestimmt 

autonom, wer auf ihre 

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 Abbildung 3 

oder andere Fachverbände 

normiert. Nur die Daten welche in INTERLIS I angeliefert werden, sind interoperabel. 

Wenn wir die 609 Arten von Datensätzen auf die geografischen Gebiete, also z.B. die 

einzelnen Gemeinden (AV-Liegenschaften der Gemeinde X, AV-Liegenschaften der 

Gemeinde Y, usw.) aufteilen, dann sind es 10'606 einzelne Datensätze. Wir betreiben 

und organisieren also eine ganze Menge Schnittstellen und wenden viel Zeit für Qualitätskontrollen 

auf. Und - es funktioniert sehr gut! 

2 Im Kanton SG die Geodatenkonferenz und im Kanton AR der GIS-Ausschuss AR 

3 Schweizerischer Ingenieur- und Architektenverein 




Im RZ der IG GIS halten wir sehr viele Daten auf einem RDMS4. Das sind Benutzerdaten, 

Benutzerrechte, Sichtendefinitionen usw. welche allerdings eher der Applikationslogik 

zugehören, ein klarer Trennungsstrich ist hier nicht möglich. Die grafischen Daten 

liegen immer noch in einem proprietären Format. Dies ist bei unseren grossen Datenmengen 

– leider – immer noch eine Frage der Systemperformance. 

Innerhalb des RZ des Kantons St. Gallen und über das Intranet der Kantone AR und AI, 

haben wir unterschiedliche Direktzugriffe in die Datenbestände anderer RDBMS realisiert. 

Gesamthaft sind heute 22 weitere Datenbanken (Fremddatenbanken) direkt an 

die Daten der IG GIS angebunden. Das heisst, dass der Nutzer direkt über sein GIS auf 

diese Datenbanken zugreift. Diese Einbettung in die vorhandenen IT-Strukturen zeugt 

wiederum von Interoperabilität. 

Zu dieser Auslegeordnung im Teilsystem Daten gehören zudem weitere, sehr wesentliche 

Aspekte: 

Die Darstellung der Daten, die dazu gehörenden Legenden, die rechtlichen Hinweise 

und der Aktualitätsstand spielen bei den Nutzern eine nicht zu unterschätzende Rolle. 

Wir führen über alle Datenbestände umfassende Metadaten, welche auf dem RDBMS 

abgelegt und bereits heute in einer Form vorhanden sind, die einen interoperablen Austausch 

mit Fremdsystemen zulässt. 

2.2.2 Aussichten 

In der Datennormierung warten wir auf Standards der verschiedensten internationalen, 

nationalen und regionalen Gremien. 

Im Teilsystem Daten sehen wir für die Zukunft eine zentrale Datenverwaltung auf der 

Basis eines Geodatenservers mit einer RDBMS. Unsere Versuche, mit verschiedenen 

Applikationen auf einen Geodatenserver zuzugreifen, zeigen, dass bereits die Interpretationen 

simpler geometrischer Datentypen Fragen aufwerfen. Erschwerend kommt die 

produkteabhängige Darstellung der Daten dazu. 

Beim Datenaustausch und der Darstellung der Daten setzen wir auf INTERLIS II, wobei 

die Marktakzeptanz bei unseren Datenlieferanten aus heutiger Sicht teilweise doch 

sehr fraglich ist. In Frage kommt hier auch der internationale Standard, nämlich GML3. 

4 Relationales Datenbank Managementsystem 




2.3 Teilsystem „Applikationslogik“ 


Wir betreiben einerseits verwaltungsintern Applikationen auf der Basis eines Desktop- 

GIS und verschiedene Web-Applikationen im Intranet, andererseits öffentlich im Internet 

verschiedene Produkte wie z.B. das www.geoportal.ch. Der umfassende Teil unserer 

Applikationslogik liegt immer 

noch in den einzelnen Applikationen, 

ein kleiner Teil 

Abbildung 4 

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 Vertragsregelungen 

und Zugriffsrechten. 907 registrierte Benutzer in 128 Benutzergruppen 

greifen verwaltungsintern geordnet auf unsere Datenbestände. 

� Wir legen unsere umfassende Datenbestände in Strukturen ab, dabei wenden wir 

folgende Ordnung an: 

� Kategorien 

� Bereiche 

� Themen 

� Datensätze 

� Um den Nutzern die Arbeit zu erleichtern, stellen wir ihnen Daten in den gewohnten 

Karten zur Verfügung. Karten sind dabei vordefinierte Kombinationen 

von Datensätzen oder definierte Sichten. 

� Wir haben zunehmend Datensätze, welche auch über ein Regelwerk definiert sind 

(z.B. Gewässernetze inkl. Kilometrierungen und Routenbildungen, Flächentopologien 

usw.). 


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 Sinne 

bereits interoperabel. 

Mit INTERLIS II können wir künftig die Definition von Regeln zu den Daten interoperabel 

beschreiben. Die Regelwerke selber sind möglichst mit den Daten in einem 

RDBMS abzulegen. 




2.4 Teilsystem „Präsentation“ 


Im Teilsystem Präsentation sind verschiedenste Standards und Normierungen schon 

vorhanden. Z.B. verteilen wir verwaltungsintern in den Geoportalen für Betrachter 

(6000 bis 7500 Arbeitssitzungen pro Monat) und öffentlich im Internet (10’000 bis 

14’000 Arbeitssitzungen pro Monat) über http schon heute Daten auf verschiedenste 

Betriebssysteme. Ebenso leben wir beim Betrieb der Geoportale für Anwender (230 registrierte 

Benutzer) über die Metaframe/Citrix-Umgebung eine spezielle Art von Interoperabilität 

über die Betriebsystemgrenzen hinweg. 

Abbildung 5 

Mit der heute verfügbaren Technik, insbesondere von WMS 5 und WFS 6, wäre eine weitere 

Interoperabilität (auch aus den proprietären Daten heraus) bereits möglich, wird 

aber wegen der Zugriffsrechte noch nicht angewendet. Die Anwendung von WMS ist 

deshalb zur Zeit nur für die öffentlichen Daten im Internet sinnvoll. 


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 insbesondere 

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 verschiedene, 

spezielle Fachbereiche aus der Informatik und der Geoinformationsbranche. 

Von einer echten Interoperabilität, also einer Interoperabilität von Organisationen von 

regionalen und nationalen Geodatenstrukturen sind wir unseres Erachtens noch weit 

entfernt. 

Je grösser wir die Systemabgrenzung ziehen, desto komplexer wird die Interoperabilität 

und umso mehr verlagert sich diese weg von Systemen und der Technik auf die 

Organisationen und deren Prozesse. 

4 Literatur 

INSPIRE. 2003. Spatial Data Infrastructure in Europe. Spatial Application Division 

K.U. Leuven, Research & Development 

Ott, Mathias. Datenaustausch und Interoperabilität, Dienste für eine offene 

Geodatenstruktur, 

www.ikg.uni-bonn.de/Lehre/Geoinfo/is_iv_SS_04/Vorträge%5C04_05_27_Ott.ppt 

Open GIS Consortium. OpenGIS Service Architecture 

SOGI. 2003. Worin liegt der praktische Nutzen von Interoperabilität und Normung für den 

GIS-Anwender in der Schweiz?” Schweizerische 

Organisation für Geoinformation, Bericht der Fachgruppe GIS Technik 


Jean-Claude Jasselette 

MET (D.432) Topographie et Cartographie 

CAMET - Boulevard du Nord, 8 

B-5000 Namur 

Tel : 

Fax : 

E-Mail : 

+32 817 733 51 

+32 817 738 88 

10 

Modellbasierte und interoperable 

Bearbeitung der Basisdaten in 

Wallonien 

Jean-Claude Jasselette, MET Belgien

1 Einführung 

1.1 Vorwort 

Jean-Claude Jasselette ist Adjunkt der Topographie- und Kartographieabteilung des 

Bau- und Verkehrsministeriums der Region Wallonien in Belgien. Er ist im Projekt 

InfraSIG involviert und hat sich insbesondere an den Arbeiten der Modellierung der 

topographischen Referenzdaten mit Hilfe von INTERLIS beteiligt. 

Das Hauptziel des Referates besteht darin, die Arbeiten vorzustellen, die im Rahmen 

der Einführung einer Infrastruktur für geographische Informationen in der Region Wallonien 

durchgeführt wurden. Im Referat wird versucht, die zugrunde liegenden Leitlinien 

und ihre Auswirkungen im Kontext der Interoperabilität für räumliche Daten aufzeigen. 

1.2 Übersicht 

Nach einer kurzen Beschreibung der Situation der belgischen Kartographie wird die 

Problematik in ihren wallonischen regionalen Zusammenhang gestellt. Schritt für 

Schritt werden die verfolgten Zielsetzungen, die eingesetzten Mittel und schließlich der 

Stand der Arbeiten durchgegangen. Die Schlussfolgerungen werden sich auf die Vorteile 

des gewählten Vorgehens, auf die aufgetretenen Probleme sowie auf das daraus Gelernte 

beziehen. 

2 Kontext und Problematik 

2.1 Belgien, ein junger Bundesstaat 

BRÜSSEL 

162 km2 FLANDERN 

13 522 km2 WALLONIEN 

16 844 km2 Interoperabilität für die breite Nutzung von Geodaten 10.1


Modellbasierte und interoperable Bearbeitung der Basisdaten in Wallonien 

Bekanntlich setzt sich Belgien seit mehr als 20 Jahren für einen Regionalisierungsprozess 

ein. Für Themen wie die Kartographie ist die öffentliche Hand einerseits unterteilt in 

eine föderale Ebene und andererseits ein regionales Niveau, das die Region Wallonien 

(16.844 km 2), die Region Flandern (13.522 km 2) und die Region der Hauptstadt Brüssel 

(162 km 2) umfasst. 

2.2 Kartographie im Bundesstaat und in den Regionen 

Wie die meisten europäische Staaten verfügt Belgien über ein eigenes nationales geographisches 

Institut (IGN). Diese föderale öffentliche Verwaltung wird mit allen Kartographie-, 

Geodäsie- und Fernerkundungsaufgaben beauftragt, die sich auf das gesamte 

Staatsgebiet beziehen. Das belgische IGN ist Hersteller von qualitativ sehr hochstehenden 

Karten und topo-geographischen Daten in den Massstäben zwischen 1/300’000 und 

1/10’000. 

Abgesehen davon ist auf der föderalen Ebene das Katasteramt Hersteller von Grundstücksplänen 

mit sehr grossem Massstab. Momentan haben diese Pläne ausschliesslich 

steuerpolitische Ziele und haben meistens keine Vermessungsqualität. Ein ehrgeiziges 

Projekt zur Modernisierung des belgischen Katasteramtes ist in Vorbereitung. 

Infolge der Regionalisierung im Bereich der umweltrelevanten Kompetenzen der Raumordnung, 

der öffentlichen Arbeiten und erst kürzlich der Landwirtschaft hat die regionale 

öffentliche Hand verschiedene kartographische Projekte geschaffen. Was die Referenzdaten 

betrifft, hat jede der drei Regionen ein digitales topographisches Kartographieprojekt 

in sehr grossem Massstab eingeführt. Es handelt sich um die Projekte Urbis 

in der Region der Hauptstadt Brüssel, PICC in der Region Wallonien und GRB in der 

Region Flandern. Diese drei Projekte entsprechen ungefähr denselben Genauigkeitskriterien 

und sind vergleichbar mit einer Karte des Typs "öffentliche Arbeiten" im Maßstab 

von 1/1’000 oder besser. Sie werden im Allgemeinen durch numerische Orthophotoplan-Layer 

vervollständigt. 

Mangels einer Koordinationsstelle auf föderalem oder interregionalem Niveau haben 

die durch die drei Regionen eingeleiteten Projekte trotz allem deutlich verschiedene 

technische Eigenschaften. 

2.3 Kartographie in der Region Wallonien 

2.3.1 Verschiedene Ansätze und Referenzen 

Auch innerhalb einer Region ist die Homogenität nicht immer die Regel. Auf diese Art 

haben in Wallonien verschiedene Hersteller von analogen und numerischen kartographischen 

Daten verschiedene Methoden und Referenzen verwendet oder verwenden sie 

immer noch. Zum Beispiel ist es mangels gemeinsamer Referenz nicht selten so, dass 

Geometer, die für verschiedene Verwaltungen der Region Wallonien arbeiten, die gesammelten 

Vermessungsdaten nicht austauschen können. 

2.3.2 Die Vielfalt numerischer Daten 

Seit einigen Jahren wird der Gehalt der numerischen geographischen Daten, die durch 

die Verwaltungen der Region Wallonien produziert wurden, allerdings anerkannt. Daher 

bilden die Plans Photographiques Numériques Communaux (PPNC) einen numerischen 

Orthophotoplan in Farbe mit Meter-Auflösung flächendeckend für die ganze Region. 

Das Projet Informatique de Cartographie Continue (PICC) bietet eine numerische Kartographie 

im Massstab 1/1’000 über eine Fläche von mehr als 8’000 km2 an, die unter ande- 




rem in einer geographischen Datenbank mehr als 55% der 1'500’000 Gebäude, die die 

wallonische Region umfasst, enthält. 

Angesichts der Qualität der bestehenden Daten und der Kosten, die ihre Produktion 

dargestellt hat, begreift man, dass ihre Aufwertung ein wichtiger Einsatz ist, und dass 

nicht zu beabsichtigen ist, ein neues Projekt derselben Spannweite anzusetzen. 

2.3.3 Der Zukunftsvertrag und das Vorgehen eGov 

Im Zeitalter der Computerisierung und Vernetzung der Datenbanken ist die Notwendigkeit, 

die Aktivitäten der verschiedenen für die Erstellung von räumlichen Daten verantwortlichen 

öffentlichen Hoheitsträgern zu koordinieren, ein entscheidender Einsatz 

geworden. 

Die Regierung der Region Wallonien ist sich dieses Einsatzes bewusst. In einer der vorrangigen 

Massnahmen ihres Contrat d’Avenir pour la Wallonie (CAW), Absichtserklärung 

der Regionalpolitik, wird festgelegt, dass die Regierung "allen Beteiligten via Internet 

die Gesamtheit der kartographischen Daten der Region Wallonien zur Verfügung stellt" 

und das, indem sie "die verschiedenen Kartographieprojekte in ein offenes, zusammenhängendes 

und koordiniertes System integrieren werden, das den Informationsaustausch 

erlaubt und das sowohl Redundanz als auch Inkompatibilität verhindert." 

Seit 2002 präzisiert das aktualisierte CAW, dass die "regionalen kartographischen Projekte 

der Öffentlichkeit im Rahmen des Projekts vom wallonischen e-Gouvernement übers 

Internet zur Verfügung gestellt werden." Man sieht also, dass der Zugang zu zusammenhängenden 

geographischen Daten und die Qualität durch die wallonische öffentliche 

Hand für prioritär eingeschätzt werden. 

2.3.4 Das CTC und das Projekt InfraSIG 

In diesem Rahmen ist das Comité Technique Cartographique (CTC) der Region Wallonien 

im November 2000 ins Leben gerufen worden. Das CTC setzt sich aus Vertretern des mit 

der Kartographie beauftragten Ministeriums und aus den verschiedenen Generaldirektionen 

der wallonischen Ministerien zusammen. Sein Hauptziel besteht darin, die Kohärenz 

zwischen den verschiedenen Kartographiediensten der Region Wallonien zu gewährleisten 

und damit den Zielsetzungen des aktualisierten CAW zu entsprechen. 

Um der Regierung die Elemente einer Verwaltungs- und Verbreitungspolitik der öffentlichen 

geographischen Daten im Rahmen einer internetbasierten Infrastruktur vorschlagen 

zu können, hat das CTC im Jahre 2002 ein Projekt mit der Bezeichnung InfraSIG 

lanciert. Dieses Projekt zielt darauf ab, eine Infrastruktur für die Verwaltung und die 

Verbreitung der geographischen Daten der Region Wallonien zu definieren und zu verwirklichen, 

um den Anforderungen und den Bedürfnissen aller Benutzer zu entsprechen. 

Um dieses Projekt zu verwirklichen, profitiert das CTC von der technischen Hilfe 

eines Konsortiums, das durch die Gesellschaft GFI gesteuert wird. 

Das InfraSIG-Projekt entwickelt sich in vier Richtungen: 

1.Eine organisatorische Achse, um das Projekt zu koordinieren, die Rolle und die Verantwortung 

der Beteiligten zu definieren, die Benutzer zu sensibilisieren und auszubilden 

und einen Führer der guten Praktiken aufzustellen. 

2.Eine technische Achse, die zum Ziel hat, die Problematik zur Sprache zu bringen 

� 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 geographischer 

Informationen durch die Region aufzustellen; 

� andererseits die Auswirkung der Gesetzgebungen über den Zugang zur Information 

zu untersuchen. 

4.Eine sozioökonomische Achse, die zum Ziel hat, die Kosten, den Markt und die Anwendungen 

zu analysieren, um der wallonischen Regierung die Bestandteile einer 

Politik für die Verbreitung der geographischen Daten vorzuschlagen. 

Jede dieser Achsen entspricht einer oder mehreren Arbeitsgruppen. 

Technisches Komitee Kartographie 

Projektleitung INFRASIG 

GT 

Organisation 

Koordination 

Organisation 

versch. DG 

Basisdaten 

Metadaten 

Minister M. DAERDEN 

(Kartographische Angelegenheiten) 

Ministerialkanzlei – “Carto” 

GT Technik 

Thematische 

Daten 

Infrastruktur Verteilung 

Permanenter Auftrag 

Technische 

Projektassistenz 

GT Recht GT 

Preis 

Technik Recht Preis 

Punktuelle Aufträge 




Schliesslich ist das CTC beauftragt, "die Zusammenarbeiten und die Kooperationsabkommen 

mit anderen regionalen und gemeinschaftlichen (OC Gis-Vlaanderen, CIRB...), 

nationalen (IGN, Katasteramt...) und europäisch Instanzen (grenzüberschreitende Projekte, 

Initiative LEITEN...) zu koordinieren." 

3 Verfolgte Ziele 

Die wichtigsten Leitlinien, die bei der Einführung von der Infrastruktur der Verbreitung 

der wallonischen geographischen Informationen verfolgt werden, können wie folgt zusammengefasst 

werden. 

3.1 Datenverwendung 

Zunächst muss die Infrastruktur die Weiterverwendung der Daten vereinfachen und 

die Aufrechterhaltung des Qualitätsniveaus dieser Daten garantieren, was ihre Aktualisierung 

voraussetzt. 

Um zu garantieren, dass geographische Informationen, die im Rahmen eines Einzelvorhabens 

produziert wurden, an anderen Zielen wieder verwendet werden und dass sie 

durch die öffentliche Hand befragt oder in Mehrwertdienste durch die Privatwirtschaft 

noch integriert werden, muss man ihnen zunächst eine bessere Sichtweite und eine adäquate 

Dokumentation gewährleisten. Man muss auch im Rahmen des Möglichen die 

Faktoren identifizieren und reduzieren, die den Zugang zu den geographischen Daten 

beschränken, wie die Trägheit, die mit der Verwaltung oder mit der Gesetzgebung zusammenhängt, 

die zu hohen Preise sowie eine Reihe von technischen Problemen. 

3.2 Begriff der authentischen Quellen 

Daher muss die Kohärenz verstärkt werden. Diese Zielsetzung deutet zum Beispiel an, 

dass eine gemeinsame Referenz identifiziert oder dargestellt wird, und dass man eine 

Verbreitung von Mehrfachkopien der Referenzdaten vermeidet. Diese letzte Sache lässt 

in der Tat gewaltige Probleme bei der Aktualisierung dieser Daten entstehen. 

Ein Ziel auf lange Sicht ist also die Konsolidierung des Begriffes der authentischen Quellen 

welche eine eindeutige und gut verfügbare Referenz erlaubt. Im Gegensatz dazu 

werden heute die PICC-Daten in der Zwischenversion des wallonischen Geoportals 

vierfach kopiert! 

3.3 Interoperabilität auf dem Datenniveau 

Die Online-Verbreitung der geographischen Daten setzt auch die Interoperabilität bei 

den Daten voraus. 

3.4 Berücksichtigung von Normen und internationalen Standards 

Die Realisierung dieser Infrastruktur wird im Sinne der Integration und der Koordination 

mit der europäischen Initiative INSPIRE (Infrastructure for Spatial Information in 

Europe) sowie unter Berücksichtigung der bestehenden Normen und internationalen 

Standards, die bereits bestehen oder erst in Vorbereitung sind (ISO, CEN, NBN, OGC, 

W3C...), geführt 




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 Referenzdaten, 

sowohl für die Visualisierungen als auch für das Laden der Daten über 

das Internet. 

� Die Redaktion von Berichten über die rechtlichen und wirtschaftlichen Aspekte. 

� Das Modell der topographischen Referenzdaten Walloniens wurde mit INTERLIS 

2 beschrieben und die entsprechenden technischen Anforderungen wurden in einem 

Pflichtenheft verfasst. 

5.2 Das vorläufige Portal 

5.2.1 Stand der Arbeit 

Das kartographische Portal entspricht einem einzigen interaktiven Schalter für die 

Verbreitung der geographischen Information der Region Wallonien für alle Anwender 

wie Verwaltungen, Unternehmen und Bürger. Das heutige Portal ist eine Zwischenlösung, 

welche realisiert wurde, um schnell die Ziele der Abgabe der Referenzdaten erreichen 

zu können. 

Das Portal dient als einziger Zugang, um: 

� allen Interessenten den Zugriff auf die geographischen Daten aufgrund der vorhandenen 

Metadaten und der standardisierten Lizenzverträge zu gewähren und 

so die Geodaten zu verbreiten. 




� die Visualisierung und das sichere Herunterladen der prioritären Referenzgeodaten 

zu erlauben. 

� Allen via Internet-Verbindungen den Zugang zu den anderen heute verfügbaren 

geographischen Ressourcen (geologische Karte, Atlanten, statistische Karten, dynamische 

Karten wie Trafiroute usw.) zu gewähren die auf den verschiedenen 

Homepages der kartographischen Dienste der Region Wallonien verfügbar sind. 

� die Realisierung von Standards zu fördern, um den Austausch und die Dokumentation 

der Qualitätsdaten durch die Bekanntgabe der Resultate des Projektes 

InfraSIG über den Führer der guten Praktiken und über Empfehlungen zu garantieren. 

� die Sensibilisierung der Benutzer zu gewährleisten, indem es die Grundkonzepte 

der geographischen Information definiert und die Daten der Kolloquien, Konferenzen 

oder Fachmessen und der Web-Links, die sich auf die geographische Information 

beziehen, bekannt gibt. 

5.2.2 Zukünftige Aktivitäten 

Definitives Portal – angestrebte technische Architektur 

Sicherheit / Authentifizierung 

Register 

Daten 

Services 

Zugriffsverwaltung / 

Authentifizierung 

Services 

Datenkatalog 

Web Services OGC & W3C 

Kartographische Werkzeuge 

Datenbank 

Benutzer 

Servicekatalog 

INTERLIS- 

Services 


FTP



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 


Die Fachleute sind sich einig, dass die Metadaten ein unentbehrliches Element der ganzen 

Raumdateninfrastruktur sind. Im Rahmen des Projektes InfraSIG wurden die Metadaten 

von allen öffentlichen Datensammlungen Walloniens gemäss den Normen ISO 

19115 beschrieben. Die erste Phase dieser Arbeit bestand in der Auswahl und Übersetzung 

der Attribute, welche für die Beschreibung der wallonischen Daten nötig waren. 

Diese Attribute wurden anhand der Anwenderbedürfnisse mit wallonischen Erweiterungen 

ergänzt. Nach der Festlegung des Metadatenkatalogs wurde das konzeptuelle 

UML-Modell der ISO-Norm und der wallonischen Ergänzungen generiert. Das UML- 

Modell der Metadaten wurde danach im Datenbankverwaltungssystem von Oracle implementiert. 

Danach wurden Datenerfassungsschnittstellen Intranet – Extranet entwickelt, um die 

Kodierung der Metadaten durch den Datenverwalter zu ermöglichen, welcher sowohl 

für die Daten als auch für die Metadaten verantwortlich ist. Die Zutrittskontrollen an 

diesen Schnittstellen werden mittels eines extern akquirierten elektronischen Systems 

LDAP realisiert. 

Ein Import-/Export-XML-Werkzeug für Metadaten wurde entwickelt, welches die Vornorm 

ISO 19139 Version 6 vollständig erfüllt. Es ermöglicht sowohl die Integration von 

Metadaten aus anderen Quellen als auch den Austausch von Metadaten mit allen Partnern 

ausserhalb der Region Wallonien. 

Zurzeit ist das auf den Namen MétaWal getaufte System operationell und die Grundlagen 

der Metadaten wurden erfasst. Eine grosse Vielfalt von flexiblen Suchprozeduren 

wurde entwickelt um die Abfragen von verschiedenen Anwendern zu ermöglichen. Die 

Verbindung mit dem Suchwerkzeug Mugire ermöglicht mehrsprachige Suchprozesse. 

5.4 Die abgegebenen Daten – die dazugehörigen Dienste 

5.4.1 Stand der Arbeiten 

Die Daten, auf welche durch das provisorische Portal zuerst Zugang verschafft wird, 

sind die Referenzdaten (PICC, PPNC, Strassenatlas, MNT Verlauf der Hauptgewässer). 

Bis heute erlauben die auf diesen Daten entwickelten Dienste einerseits ihre Visualisierung 

mittels zweier mit der OGC-Norm WMS kompatiblen Schnittstellen und andererseits 

das Herunterladen der Datenfiles in zwei proprietären Formaten der GIS-Software. 

Es ist zu beachten, dass diese Daten laufend mit anderen thematischen Daten nach und 

nach (gem. Validierung) vervollständigt werden. 


Das provisorische Portal verwaltet Dienste nach den Normen von OGC oder W3C. Diese 

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, semantische 

Transformation der Daten, Werkzeuge für die Formatumwandlung, Verwaltung 

von eindeutigen Identifikatoren) finden. Diese Werkzeuge werden ermöglichen die Interoperabilität 

der Daten zu gewährleisten, die Anfragen der Anwender, welche mit 

verschiedener GIS-Software arbeiten, zu beantworten und die Daten in den erforderlichen 

Formaten herunterzuladen. 

Die Entwicklung des Dienstleistungsumfeldes sieht vor, Dienste zu integrieren, die elementareren 

Funktionen entsprechen. Es ist die Kombination solcher „atomaren“ Dienstleistungen, 

die erlauben wird, Applikationen auf einem den Bedürfnissen der Anwender 

entsprechenden Niveau zu realisieren. 

Ausserdem muss die Verbreitungsinfrastruktur einen Katalog von Diensten enthalten, 

welche wahrscheinlich der Norm OGC entsprechen. Mehrere auf dem Markt erhältliche 

Kataloge werden zurzeit im Rahmen des Projektes InfraSIG evaluiert. Ein Bewertungskriterium 

ist ihr Niveau der Erfüllung der Norm ebXML 

5.5 Rechtliche Aspekte 

5.5.1 Stand des Fortschrittes 

Für jede Anwenderkategorie wurde ein einheitliches Lizenzmodell verfasst und auf 

dem kartographische Portal platziert, das für alle Daten, die durch die regionale Verwaltung 

verbreitet wurden, standardisiert ist. 

Das Herunterladen von Daten ist nur möglich, wenn der Anwender den Lizenzvertrag 

angenommen hat. Bei der Visualisierung der Daten erscheint ein rechtlicher Hinweis auf 

dem Bildschirm. 

Das hat die Prüfung der Gesetzgebungen zum geistigen Eigentum, über das Verwaltungsrecht, 

über die Daten von persönlichem Charakter und zur Respektierung des privaten 

Lebens, über den Verbraucherschutz, über die Verantwortung des Erzeugers und 

des Benutzers und über die elektronische Unterschrift erfordert. 


Zurzeit wird die Frage diskutiert, inwieweit das Geoportal zur Visualisierung von Geobasisdaten 

der Öffentlichkeit zugänglich gemacht werden kann. Es fehlt allerdings eine 

hinreichende Rechtssprechung und es ist schwierig zu garantieren, dass die Veröffentlichung 

solcher Basisdaten nicht einer Verletzung der Bestimmungen über den Schutz der 

Privatsphäre bedeutet. Besonders stellt sich diese Frage für die Veröffentlichung von 

sehr detaillierten Orthophotoplänen, welche eine Visualisierung vom Innern privater 

Liegenschaften erlauben. 




5.6 Sozio-ökonomische Aspekte 


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 Preisfestlegung 

und über die heutige Situation im Bereich der geographischen Daten in 

Europa 

� Schliesslich wurde der Vorschlag gemacht, mit welchem eine Preispolitik beschrieben 

wird, die tiefe Preise bezweckt und in welcher man die Randkosten für 

die Abgaben berücksichtigt. 

Dieser Vorschlag entspricht den allgemeinen Zielen der Region Wallonien, welche eine 

breite Verbreitung der geographischen Daten bezweckt und globale Einsparungen sowie 

eine regionale Förderung ermöglicht. 

Der Vorschlag fusst auf den Charakteristika des Marktes geographischer Daten und liefert 

eine Matrix, welche es erlaubt, die Preise in Abhängigkeit von Dateneigenschaften, 

Benutzertypus und vorgesehener Verwendung zu bilden. So ist es zum Beispiel denkbar, 

dass ein Unternehmer freien Zugang zu gewissen als essentiell beurteilten Daten 

erhält, um für andere – zur kommerziellen Nutzung vorgesehene – Daten bezahlen 

muss. 


Wenn die wallonische Regierung die Vorschläge annimmt wird ein Abgabesystem entstehen 

in welchen die Geodaten für die öffentlichen Dienste und die Ausbildungsinstitutionen 

kostenlos im Rahmen ihres Auftrages abgegeben werden. Für die anderen Berufskreise 

wird man die Abgabe der Geodaten auf der Basis von Abonnements- oder 

Partnerschaftsverträgen regeln. Ein Detailverkauf in besonderen Fällen soll ebenfalls 

möglich sein. 

5.7 Die Modellierung der topographischen Referenzobjekte 

5.7.1 Stand der Arbeiten 

Die Modellierung der Referenzdaten ist Bestandteil der existierenden Daten und insbesondere 

vom PICC. Daher wird der Objektkatalog stark von letztgenannten Daten beeinflusst. 

Ein indirekter Effekt der Modellierungsprozesse war die Erhöhung des Bekanntheitsgrades 

der Daten von PICC. Ebenfalls verbreitete sich die Diskussion über die 

Referenzdaten auch auf andere Berufskreise und blieb nicht nur beschränkt auf den 

Kreis der Geodaten-Produzenten. Diese Entwicklungen haben die Bedeutung des PICC 

aufgewertet. Dadurch wird es möglich, das PICC von einer rein numerischtopographischen 

Planform hin zu einer echten Datenbasis zu entwickeln. 

Das Konzept der Vererbung, typisch für die objektorientierten Technologien wurde eingesetzt 

um drei gekapselte Geodatenmodelle zu definieren. Das detaillierteste – innerste 

– Modell, das Geometermodell, enthält alle im Gelände nach dem System Walcors aufgenommenen 

Objekte (wallonisches GPS-RTK-Permanentnetz mit 23 Stationen); das 




mittlere Niveau ist das Modell PICC, welches ein Teil der Objekte des Geometermodells 

übernimmt. Schliesslich das Modell der Region Wallonien, welches nur die topographischen 

Objekte beinhaltet die für eine grosse Anzahl Applikationen benötigt werden. In 

der gleichen Art könnte ein Referenzmodell für das ganze Land oder für Europa aufgebaut 

werden. 

Um die sehr unterschiedlichen Detaillierungsstufen zu harmonisieren und zu konzipieren, 

ist die modellbasierte Methode mit INTERLIS 2 angewendet worden. 

Die Modellierung erlaubte einerseits die Datenstrukturen der Thematik unter Berücksichtigung 

der verschiedenen potenziellen Anwendungen zu verbessern. Andererseits 

schien es sinnvoll bei der Modellierung die Ergänzung der bestehenden Daten mit neuen 

Konzepten wie derjenigen der Strassenplattformen. 


Die Einführung der neuen Konzepte und der Einsatz der INTERLIS-Werkzeuge (insbesonders 

dem Checker) machte eine Menge Inkonsistenzen in den Daten sichtbar. Man 

konnte feststellen, dass es nötig sein wird, ein Re-Engineering der Daten vorzunehmen. 

In der Folge wird man die Prozesse für die Nachführung der Daten unter der Verwendung 

der Methoden und Werkzeuge von INTERLIS gestalten. Zu diesem Zweck wird 

man eine immer stärkere Koordination der Anstrengungen anstreben. So sollte zum Beispiel 

nur eine einzige Feldaufnahme für die Nachführung der verschiedenen Datenebenen 

verwendet werden. Die Möglichkeit von INTERLIS 2 im Bereich der inkrementellen 

Nachführung ist vertieft zu analysieren. Es wird notwendig sein, ein Verwaltungssystem 

für eindeutige Objektidentifikatoren einzuführen. 

5.8 Gemeinsames Pflichtenheft für die topographischen Aufnahmen 


Die technischen Spezifikationen wurden in einem gemeinsamen Pflichtenheft aufgrund 

der konzeptuellen Datenmodellierung formuliert. Dieses Pflichtenheft könnte nach der 

definitiven Validierung als verbindlich für diejenigen Geometer erklärt werden, welche 

die Arbeiten für die wallonische öffentliche Hand ausführen. In dieser Art werden die 

Ergebnisse ihrer Arbeiten kompatibel zueinander und man wird sie verwenden, um die 

Daten des PICC sowie topografische Referenzobjekte auf einfache Weise zu aktualisieren. 


Das Pflichtenheft muss noch in einer operationellen Umgebung getestet werden. 

Im Übrigen wird demnächst ein Pilotprojekt gestartet, um den Informationsaustausch 

zwischen den Feldequipen und der Verwaltung zu erleichtern. Dieser Pilot hat zum 

Ziel, im Rahmen des kartographischen Portals einen Web-Dienst für den Datenaustausch 

mit Hilfe von INTERLIS 2-Werkzeugen zu implementieren. Dieses System wird 

es den für die wallonische Verwaltung tätigen Geometern erlauben, nötige Dokumente 

aus dem Internet zu beziehen: 

� das Pflichtenheft, seine Dokumentation, die Datenmodelle usw. 

� die Daten der Geländeaufnahmen der Verwaltung unter Verwendung der 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 – basierend 

auf einem Objektkatalog – zu erstellen, welche mit weiteren thematischen Informationen 

erweitert werden kann, lässt bereits heute erkennen, dass ein Koordinationsbedarf 

mit anderen Fachleuten der Regionen Wallonien, Flandern und Brüssel sowie Bundesstellen 

(IGN und Kataster) unerlässlich ist. Diese Koordination ist unter anderem 

notwendig, um die Anforderungen der europäischen Initiative INSPIRE zu erfüllen. 

6 Überlegungen 

6.1.1 Vorteile von INTERLIS 

INTERLIS 2 bietet einerseits die Vorteile der Objektorientierung wie Vererbung und Polymorphismus. 

Andererseits können die Daten mit einem so genannten Checker auf 

Modellkompatibilität überprüft werden. Ebenfalls sehr geschätzt ist in Belgien und insbesondere 

in der Region Wallonien die Mehrsprachigkeit der Lösung. Als Ergänzung 

erleichtert INTERLIS die Nachführung, da sie sich mit inkrementellen Verfahren organisieren 

lässt. 

Schliesslich ist die Unabhängigkeit der Methode von jeglichem Informatiksystem der 

entscheidende Vorteil. Er gewährt die Interoperabilität, sobald man die konzeptionellen 

Modelle mit INTERLIS beschrieben hat. 

6.1.2 Aufgetretene Schwierigkeiten 

Einige der erwähnten Vorteile gelten für die Version 2 von INTERLIS. Die Region Wallonien 

hat von Anfang an entschieden, diese Version zu implementieren, ohne die Version 

1 einzusetzen. Dieser Entscheid stellt die wallonische Verwaltung in die Position 

des Pioniers von INTERLIS 2, hat aber bereits einigen Zeitverlust verursacht und beinhaltet 

Risiken, die nicht so leicht abgeschätzt werden können. 

Man musste zum Beispiel die Modellierungsarbeit „blind“ vornehmen, da während dieser 

Zeit die Werkzeuge nur für INTERLIS 1 existierten. Wir sind weiterhin mit dem 

Problem konfrontiert, dass zu wenige Werkzeuge für die Modellierung der graphischen 

Darstellung zur Verfügung stehen. Werden wir eine direkte Beziehung mit SLD von 

OGC erleben? 

Es gibt noch weitere offene technische Fragen: die Implementierung der OID und ihres 

Transfers zu anderen Formaten mittels Transformationen, die naturgemäss nie neutral 

sein können. Wie kann man die Arbeit standardisieren, um allen Datenproduzenten zu 

ermöglichen, mit dem gleichen Konfigurationsskript für die Transformationswerkzeuge 

zu operieren? Wie weit kann die inkrementelle Nachführung eingesetzt werden? Usw. 




Aufgrund der bisherigen Erfahrungen plädieren wir für eine Vervollständigung der 

Norm INTERLIS 2 mit Implementierungsregeln, um die erwähnten Probleme zu vermeiden. 

Neben den technischen Schwierigkeiten zeigten sich ebenfalls organisatorische und 

menschliche Probleme. Es ist zum Beispiel nicht leicht, alle Betroffenen in das Vorhaben 

zu integrieren. Die Beteiligung der Datenanwender war wesentlich kleiner als diejenige 

der Datenproduzenten, die bereits sensibilisiert sind auf die Bedürfnisse einer Datenmodellierung. 

Man stellte ebenfalls fest, dass eine Vielfalt von Arbeitsmethoden, insbesondere für die 

Feldaufnahmen, existiert. Dies ergibt sich aus der fehlenden Standardisierungstradition 

im Kreis der wallonischen Datenproduzenten. Die Konsequenz daraus ist ein Bedarf 

nach tief greifenden Änderungen, um garantieren zu können, dass die Daten modellkonform 

erfasst werden. Man kann erwarten, dass Widerstände entstehen, die durch 

einen zwingenden rechtlichen Rahmen beseitigt werden können. Terminologische Probleme 

sind ebenfalls aufgetaucht. 


Die bisherigen Erfahrungen in der Region Wallonien sind global betrachtet positiv. Die 

INTERLIS-Lösungsansätze ermöglichten, ein konsistentes Vorgehen zu gestalten und 

diesem zu folgen. Eine vertiefte Diskussion über die topographischen Referenzdaten 

und über ihre langfristige Entwicklung wurde ebenfalls ausgelöst. 

Die Wahl von INTERLIS 2 bedeutete trotzdem ein nicht zu vernachlässigendes Risiko. 

Mehrere wichtige Fragen blieben bis jetzt unbeantwortet. 

Die realisierten Lösungen stehen zurzeit noch am Anfang der Entwicklung. Die nächsten 

Schritte der Evolution betreffen die Beziehungen zwischen Referenz- und thematischen 

Daten. Diese Zielsetzung wird den Einbezug einer grösseren Anzahl Partner erfordern. 


Andreas Morf 





Sepp Dorfschmid 

ADASYS AG 

Dörflistrasse 67 

Postfach 5019 


Tel : 

E-Mail : 

+41 1 633 32 56 (Morf) 

+41 1 363 19 39 (Dorfschmid) 

11 

Modellstandardisierung vs. 

semantische Interoperabilität 

Aktuelles aus der Forschung 

Andreas Morf, ETH Zürich 

Josef Dorfschmid, ADASYS AG

1 Problemstellung / Zielsetzung 

Immer wieder kommt es vor, dass Daten neu erfasst werden, obwohl sie an sich vorhanden 

wären. Sie liegen aber nicht in der gewünschten Form vor. Zum Teil müssten 

anspruchsvolle Umformungen durchgeführt, zum Teil sogar verschiedene Datenbestände 

in geeigneter aber nicht offensichtlicher Art zusammengeführt werden. 

Bislang wurde versucht, die Problematik durch möglichst abschliessende Standardisierung 

der Datenmodelle bzw. der Datenformate zu entschärfen. Wenn die Definition der 

Bedürfnisse und Ansprüche an die entsprechenden Daten möglich ist und der zugehörige 

Anwenderkreis an den 'runden Tisch' gebracht werden kann ist ein solches Vorgehen 

durchaus Erfolg versprechend. 

In vielen Fällen ist jedoch eine umfassende Festlegung und abschliessende Standardisierung 

der Modelle nicht möglich oder mit unverhältnismässig grossem Aufwand verbunden: 

1.1 Möglichkeiten und Grenzen der Modell-Standardisierung 

Mit der modellbasierten Methode (ISO/UML/INTERLIS) steht ein Werkzeug zur Verfügung, 

welches eine sehr flexible Datenmodellierung ermöglicht. Die Anwendung dieses 

Verfahren ist weitgehend etabliert und wurde in diversen Informationsgemeinschaften 

zur Definition ihrer Datenmodelle in der Form von Standards verwendet (SIA 405, 

AVS, VSA-DSS). 

Mit den objektorientierten Konzepten, wie sie zum Beispiel in INTERLIS 2 zur Verfügung 

stehen, ist es nun auch möglich, Basismodelle zu spezifizieren und dann mittels 

Vererbung Modellerweiterungen für spezielle Bedürfnisse vorzunehmen (vergleichbar 

mit den heute praktizierten kantonalen Erweiterungen zum Bundesmodell der amtlichen 

Vermessung). 

Ist es nun aus administrativen oder rechtlichen Gründen nicht möglich, ein umfassendes 

und abschliessendes Datenmodell festzulegen ergeben sich offensichtlich zwei 

grundsätzliche Probleme: 

� Verschiedene Teil-Informationsgemeinschaften (z.B. Kantone) erweitern ein Basismodell 

um Elemente, wobei die Erweiterungen wohl oftmals denselben Inhalt 

beschreiben, diesen jedoch vielleicht auf verschiedene Arten modellieren (Namen 

der Klassen/Tabellen/Attribute) 

� Übergeordnete und 'verwandte' Informationsgemeinschaften (Staat, EU-Raum) 

streben die Nutzung der Daten an und wollen zu diesem Zweck Standardmodelle 

erstellen. Die Koordination aller Bedürfnisse der Beteiligten verursacht einen sehr 

grossen Aufwand und führt entweder zu Modellen, welche dem kleinsten gemeinsamen 

Nenner entsprechen und damit den wenigsten gerecht werden - oder 

aber alle Eventualitäten werden berücksichtigt und es entstehen Modelle mit einer 

Komplexität, welche in der Praxis kaum mehr handhabbar sind. 

Der Einsatz von spezialisierten Softwaresystemen im Geoinformationsbereich im Zusammenhang 

mit normierten Standard-Datenmodellen ist oftmals mit einigen Hürden 

verbunden und häufig werden auch an sich geeignete Software-Pakete zur Erfassung, 

Bearbeitung und Auswertung von Daten nicht eingesetzt, weil sie die gewünschten Datenmodelle 

nicht unterstützen oder diese Unterstützung mit erheblichen Kosten verbunden 

wäre. 



Modellstandardisierung vs. semantische Interoperabilität: Aktuelles aus der Forschung 

1.2 Anforderungen an ein Lösungskonzept 

Wo die Einführung von Standard-Datenmodellen aufgrund administrativer, politischer, 

rechtlicher und allenfalls auch technischer Randbedingungen nicht oder nur mit sehr 

grossem Aufwand möglich ist, sind Ansätze gefragt, welche die Interoperabilität auch 

in den Fällen sicherstellen, bei welchen die Datenmodelle der Beteiligten und deren jeweiligen 

Systemen nicht (genau) dieselben sind: 

� Diese semantische Interoperabilität wird mittels einer Transformation sichergestellt. 

Die Formulierung der Transformationsregeln für konkrete Datenmodelle ist 

ein Schritt, welcher nicht oder nur sehr beschränkt automatisierbar ist 

� Die Abbildungsfunktionen zwischen verschiedenen Modellen (welche jedoch einen 

ähnlichen oder gleichen Sachverhalt der Realwelt beschreiben) soll wie die 

Datenmodelle selbst mit einem systemunabhängigen Formalismus beschrieben 

werden (im Gegensatz zu einer Formatumwandlung, welche normalerweise mit 

einer Programmier-/Skriptsprache realisiert wird) 

� Die Anwendung eines solchen Formalismus soll für den Anwender und Modellierer 

möglichst intuitiv sein, wobei eine Unterstützung durch grafische Hilfsmittel 

(analog zur Datenmodellierung mit UML) anzustreben ist 

� Anbindung von Modellierverfahren und Datenformaten, welche verbreiteten Industriestandards 

entsprechen, muss möglich sein und spezifiziert werden (insbesondere 

ISO/OGC Interoperabilitäts-Standards) 

Mit einem solchen Werkzeug zur Modellierung von semantischen Transformationen 

sind folgende Vorteile und Beispielanwendungen denkbar: 

� Formale Spezifikation und Visualisierung von Zusammenhängen zwischen Modellen 

für beteilige und verantwortliche Personen 

� Automatische Ableitung der für die Datentransformation notwendigen Programme, 

Skripte und Instruktionen. Denkbar sind XSLT, SQL-3, iG-Skript und weitere 

� Datenportale, welche es dem Kunden ermöglichen eigene Zielmodelle und Transformationen 

zu deklarieren und somit die Portalmodelle/-daten automatisch entsprechend 

umwandeln und ausliefern 

Es wäre also wünschenswert, wenn es Softwaremittel gäbe, dank denen anspruchsvolle 

Umformungen von Daten auf einfache Art definiert und entsprechend zuverlässig ausgeführt 

werden könnten. 




Bildlich wünscht man sich folgende Situation: 

Modelle der 

Inputdaten 

Min-1 

Din-1 

Inputdaten 

Din-2 

Min-2 

Modellierung 

Transformationsdef. 

Man könnte auch formulieren: 

Mout = f(Min-1, .., Min-i) 

Die Struktur der Inputdaten Din-1 bis Din-i ist durch die Datenmodelle Min-1 bis Min-i beschrieben. 

Diejenige der Outputdaten Dout durch das Datenmodell Mout. Die Beschreibung 

erfolgt mittels INTERLIS 2 oder einem anderen äquivalenten Beschreibungsmittel. 

Wie aber beschreibt man die Funktion f? 

2 Grundsätzliche Möglichkeiten zur Definition der 

Abbildungsfunktion 

2.1 Imperative Definition 

In vielen Fällen werden solche Datentransformationen mittels Programmiersprachen 

definiert. 

In einfachen Fällen kommen Skriptsprachen (z.B. PERL) zur Anwendung. Vielfach 

kommen aber auch eigentliche Programmiersprachen zum Einsatz. Man schreibt ein 

Programm welches die Aufgabe löst. 

2.2 Deskriptive Definition 

Modell der semant. 

Transformation 

Mtrf 

Transformations- 

Engine 

Steuerung 

Datenfluss 

Modell der 

veredelten Daten 

Oftmals möchte man die Erstellung eines Programms lieber vermeiden. Beschreibungen 

wären angenehmer, weil man sich bei ihrer Erstellung nicht um all die Aspekte der Implementierung 

kümmern muss. 

Einen interessanten Ansatz in diese Richtung bilden die Sichten (Views), wie sie auch in 

INTERLIS 2 vorgesehen sind. 


Maut 

Dout 

Veredelte Daten



Gegenstand eines aktuellen Forschungsprojektes IGP/ETHZ ist die Abklärung der Eignung 

eines Formalismus zur Beschreibung der Abbildungsfunktion unter Zuhilfenahme 

der Modellierungssprache UML (Unified Modeling Language). UML bietet neben Klassendiagrammen 

zur Modellierung von Geodaten auch Diagrammtypen zur Beschreibung 

von (dynamischen) Prozessen. Damit lassen sich die Instruktionen, welche für die 

Abbildung von einer Datenstruktur auf eine andere notwendig sind, in grafischer und 

für den Benutzer einfach verständlicher Form beschreiben. 

2.3 Beispiele dazu 

2.3.1 Grunddaten 

In einer Gegend gibt es – wie überall – Menschen, also entweder Frauen oder Männer. 

Das – etwas vereinfachte - Datenmodell dazu: 

MODEL Menschen = 

TOPIC Menschen = 

CLASS Mensch (ABSTRACT) = 

Vorname: TEXT*30; 

Name: TEXT*100; 

Geburtsjahr: 1900..3000; 

WohnPos: CHKoord; 

END Mensch; 

CLASS Frau EXTENDS Mensch = 

END Frau; 

CLASS Mann EXTENDS Mensch = 

END Mann; 

END Menschen; 

END Menschen. 

Nun sollen mögliche Paare gebildet und diese als Daten ausgewiesen werden. 

Für die Paare ergibt sich folgendes Modell: 

MODEL Paare = 

TOPIC Paare = 

CLASS Paar = 

VornameMann: TEXT*30; 

NameMann: TEXT*100; 

GeburtsjahrMann: 1900..3000; 

VornameFrau: TEXT*30; 

NameFrau: TEXT*100; 

GeburtsjahrFrau: 1900..3000; 

END Paar; 

END Paare; 

END Paare. 




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 Aufwand 

führt, auch wenn die Ergebnismenge (also die gefundenen Paare) relativ klein ist, 

da nur die gleichaltrigen Menschen als Partner in Frage kommen. Bei jedem Mann werden 

alle Frauen angeschaut und dann auf Gleichaltrigkeit geprüft. 

Dies führt zu M * F Vergleichsoperationen. 

Würde man eine Hilfsstruktur aufbauen, dank der alle Frauen mit einem bestimmten 

Geburtsjahr effizient gefunden werden können, könnte das Programm ungefähr so aussehen: 

HF := ErzeugeHilfsstruktur (Menschen.Menschen.Frau, 

Geburtsjahr) 


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





end 

end 

Der Laufzeitaufwand würde damit im Prinzip auf M * log(F) sinken und damit auch die 

Bearbeitung grosser Datenmengen erlauben. 

Eigentlich möchte man sich im Rahmen der Definition einer semantischen Datentransformation 

aber nicht um solche Aspekte der Implementierung kümmern. Die deskriptive 

Form ist darum vorteilhafter. Allerdings hat sie den Nachteil, dass man dem Transformationsverfahren 

einiges aufbürdet, wenn es auf Grund der WHERE-Bedingung erkennen 

muss, dass es Optimierungsmöglichkeiten gibt. 

Das folgende Beispiel macht dies noch deutlicher. 




2.3.4 'Near' - Join 

Es besteht ein Interesse an allen Paaren, bei denen die Partner nicht weiter als einen Kilometer 

entfernt wohnen. 

TRANSFORMATION MODEL UmkreisPaare = 


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

VIEW Paar 



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

= 


… 


END Paar; 


END UmkreisPaare. 

Wie soll das Transformationsprogramm hier eine Optimierungsmöglichkeit erkennen? 

Würde man jedoch spezielle Definitionen einführen, bei welchen der Bezug zu den 

Grundmengen erkennbar ist und die im Rahmen einer WHERE-Bedingung eingesetzt 

werden können, wäre dies wieder einfach: 

TRANSFORMATION MODEL UmkreisPaare = 


FUNCTION InnerhalbDistanz 

(Basis1: CLASS; P1Attr: ATRIBUTE; 

Basis2: CLASS; P2Attr: ATTRIBUTE; 

MaxDistanz: NUMERIC): BOOLEAN; 

VIEW Paar 



WHERE InnerhalbDistanz(M, WohnPos, 

F, WohnPos, 1000.0); 

= 


… 


END Paar; 


END UmkreisPaare. 




2.3.5 'Nearest' - Join 

Ist man noch restriktiver bei der Paarbildung und bildet Paare nur zwischen der Frau, 

die am nächsten bei einem Mann wohnt oder umgekehrt, bleibt die Transformationsbeschreibung 

sehr ähnlich. 

TRANSFORMATION MODEL NachbarPaare = 


FUNCTION KuerzesteDistanz 

(Basis1: CLASS; P1Attr: ATRIBUTE; 

Basis2: CLASS; P2Attr: ATTRIBUTE): BOOLEAN; 

VIEW Paar 



WHERE KuerzesteDistanz(M, WohnPos, 

F, WohnPos); 

= 


… 


END Paar; 


END NachbarPaare. 

Will man die Transformation imperativ beschreiben, ist es offensichtlich, dass die Lösung 

recht anspruchsvoll ist, wenn sie auch bei grossen Mengen zu vernünftigen Laufzeiten 

führen soll. 

2.4 Forschungsprojekt 'Neue Ansätze zur konzeptionellen 

Beschreibung semantischer Transformationen' 

2.4.1 Ausgangslage 

Vorgängig wurden die Grundlagen für den Einsatz von Views, welche die Abbildung 

von einer Ausgangsdatenstruktur auf eine Zieldatenstruktur leistet, ausführlich eingeführt. 

Für einen Anwender, welchem dieses Verfahren nicht aus der Datenbank-Welt 

vertraut ist, sind solche Abbildungsdefinitionen nicht ganz einfach zu verstehen und 

nachzuvollziehen. Darüber hinaus ist eine intuitive grafische Darstellung, welche den 

gleichen Sachverhalt der Transformation wiedergibt, schwierig zu erreichen. 

2.4.2 Zielsetzung: grafische Notation und daran angelehnter Formalismus 

Neben dem Diagrammtyp 'Klassendiagramm' stellt die grafische Modellierungssprache 

UML auch weitere Diagrammtypen zur Verfügung, welche die Erstellung von Modellen 

für Prozesse ermöglicht. Da jedoch mit diesen Mitteln die Transformation von Modellen 

nicht vollständig ausgedrückt werden kann, muss das Repertoire von UML zu diesem 

Zweck erweitert werden. Bei der OMG (Object Management Group), welche für die 

Weiterentwicklung von UML zuständig ist, wurde bereits ein Vorschlag für entsprechende 

Modellierungselemente eingereicht (MOF Query/Views/Transformations; 

UMLX) 




Für die Darstellung der semantischen Transformation von Geodaten müssen die geeigneten 

Diagrammelemente evaluiert und um notwendige Erweiterungen ergänzt werden. 

Die Anpassung der UML-Symbolik für eine Anwendungsdomäne (Geoinformatik) 

nennt man auch UML-Profil. Eine Modelltransformation könnte dann wie folgt dargestellt 

werden: 

Da grafische Darstellungen wie UML nicht direkt maschinell verarbeitbar sind, muss in 

Ergänzung dazu ein textueller Formalismus geschaffen werden. Die Realisierung kann 

zum Beispiel als Erweiterung von INTERLIS 2 erfolgen. Für Transformationen, bei welchen 

der mengenorientierte Zugriff ausreicht, können die Abbildungsvorschriften auch 

mittels Views repräsentiert werden. 

2.4.3 Implementierung der Transformationsmodelle 

Mit der Formulierung von Modellen und Transformationen auf konzeptioneller Ebene 

erhalten wir den 'Werkzeugkasten', mit welchem wir die semantische Interoperabilität 

erreichen können. Wir sind damit nicht an ein konkretes GIS-System bzw. Transformationssoftware 

mit eigener Programmier-/Skriptsprache gebunden. 

Ebenso wie wir mit INTERLIS unabhängig vom Transferformat sind (XML, GML, ITF), 

lassen sich die Transformationsvorschriften in eine konkrete Transformations- bzw. 

Programmiersprache, welche für eine bestimmte Anwendung ideal geeignet ist, umsetzen. 

Denkbar wären z.B. SQL, XSLT, XQuery, iG-Skript, FME usw. 

Ähnlich wie die Kommunikation der am Daten-Modellierungsprozess beteiligten Experten 

durch konzeptionelle und grafische Mittel wie UML stark verbessert wird, macht es 

Sinn, die Zusammenhänge und Transformationen zwischen verschiedenen Datenmodellen 

(ähnlicher oder gleicher Themenbereiche) explizit zu formulieren. Dies kann mit 

einer Programmiersprache allein nicht sinnvoll geleistet werden. 

2.5 Folgerungen 

Die deskriptive Definition einer semantischen Transformation hat zweifellos Vorteile, 

denn sie trennt zwischen Definition und Implementierung. 

Um die Ansprüche an die Transformationsprogramme nicht a priori hoch zu schrauben 

oder das Risiko einzugehen, dass Optimierungsmöglichkeiten kaum genutzt werden, 

macht es Sinn, die Formulierung spezieller Bedingungen durch spezielle Operationen 

zu unterstützen. Für solche Operationen ist in den Transformationsprogrammen explizit 

entsprechender Code vorzusehen. Es ist aber den Transformationsprogrammen überlassen, 

inwiefern sie die Optimierungen auch realisieren. 




3 Ein Blick auf INTERLIS 2 

Wer INTERLIS 2 präsent hat, hat festgestellt, dass die Sichten 'AllePaare' und 'GleichaltrigePaare' 

mit den heutigen INTERLIS 2 – Mitteln formulierbar sind. 

Für die Sichten in den Modellen 'UmkreisPaare' und 'NachbarPaare' sowie für eine 

durch den Transformator leicht erkennbare 'GleichaltrigePaare'-Sicht ist es nötig IN- 

TERLIS 2 um View-Operatoren zu ergänzen. Es kann dazu ein ähnlicher Ansatz verwendet 

werden wie bei den bereits vorhandenen INTERLIS-Funktionen. 

Mit einem Zusatz muss dafür gesorgt werden können, dass aus einer Sicht Objekte gemäss 

einer Klasse eines Modells erzeugt werden können. 

� Mit einem bescheidenen Ausbau von INTERLIS 2 kann die semantische Datentransformation 

mittels INTERLIS 2 beschrieben werden. 

Die genaue Definition ist noch Gegenstand eines gemeinsamen Projektes. 

4 Hauptvorteile 

4.1 Kommunikation zwischen Menschen 

Mit INTERLIS wurde nebst dem eigentlichen Datentransfer eine gemeinsame Sprache 

geschaffen, damit sich Menschen möglichst präzis über die Struktur von Daten unterhalten 

können. 

Ähnlich könnte mit einem solchen Ansatz auch ein generelles Verständnis aufgebaut 

werden, wie man Transformationen von Daten beschreibt. 

Wie bei den Datenmodellen dürfte es auch bei den Datentransformationen teilweise anspruchsvoll 

sein, die besten geeignete Definition zu finden. Eine gemeinsame Sprache 

leistet dabei aber wichtige Dienste. 

4.2 Nutzen für Prozessoren 

Andere Quellen der 

Definition von 

Modellen und 

Transformationen 

Andere Tools 

I2- 

Modelle 

I2-Compiler 

Modelle 

in XML 

UML-Editor 

Inputdaten Transformator Outputdaten 




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

� Ist in der Lage Daten zu verarbeiten, die INTERLIS 2 – Datenmodellen entsprechen 

und kann somit recht anspruchsvolle Datenmodelle unterstützen. 

� Ist in der Lage auf eingelesenen Daten mit INTERLIS 2 definierte Sichten aufzubauen 

und modellbasierte Datentransformationen auszuführen. 

Dabei kann davon ausgegangen werden, dass einfache Datentransformationen direkt 

mit einer leicht erweiterten INTERLIS 2 – Beschreibungen definiert und ausgeführt 

werden können. Ähnlich zu den in INTERLIS 2 vorgesehenen Funktionen, wird man 

jedoch für anspruchsvollere Abbildungen spezifische Operatoren zur Bildung von Sichten 

definieren und entsprechend im Transformator codieren. 

Die INTERLIS 2 – Modelle (inkl. Transformation) können mit dem UML-Editor oder 

anderen Werkzeugen erstellt werden und mit dem INTERLIS 2 – Compiler in ein noch 

definitiv festzulegendes Format (z.B. in INTERLIS 2 oder XMI) gebracht werden. Alternativ 

ist es auch möglich, solche Modell- und Transformationsbeschreibungsdaten mit 

anderen Werkzeugen (unabhängig von INTERLIS) direkt zu erzeugen. Diese Modellund 

Transformationsdefinitionen werden durch den Transformator gelesen. Damit ist 

dem Transformator bekannt, wie die Inputdaten zu Outputdaten veredelt werden müssen. 

Durch diese klare Trennung der einzelnen Komponenten besteht eine hohe Anpassungsfähigkeit 

an verschiedene Bedürfnisse, die sich aus konkreten Systemsituationen 

ergeben. 


Théo Engel, Dr. 

SBB-Infrastruktur-Asset Management, Programmanager Fahrstrom 

Schanzenstrasse 5 

CH-3000 Bern 65 

Tel : 

Fax : 

E-Mail : 

+41 51 220 21 80 

+41 51 220 39 19 

12 


Théophil Engel, UIC / SBB

1 Umfeld 

1.1 Übersicht 

1.1.1 Einstieg 

Der Gleisbau stützt sich schon lange auf Koordinatentrassen. Seit den 90er Jahren sind diese 

auch als Grundlage des systematischen Gleisunterhalts im Einsatz und bringen dort bedeutende 

finanzielle, technische, allgemein anerkannte Vorteile. Numerische Gleiskoordinaten sind 

auch die Basis einer erhöhten Interoperabilität aller Infrastrukturanlagen, sowie dank der, von 

der europäischen Union postulierte Harmonisierung der Koordinatenreferenzen, landesgrenzenüberschreitend, 

eine Grundvoraussetzung ist für erfolgreiche, neue Anwendungsfelder wie z.B. 

die satellitenbasierte Navigation der Züge. 

1.1.2 Vierzehn Kernsätze 

1 Koordinatenbasierte, absolute Gleisedefinition (CNTD) als Grundlage des modernen Gleisbaus 

und Gleisunterhaltes //2 UIC-Projekt GEORAIL: Ein weiterer Konsolidationsschritt auf dem 

Weg der Einführung absoluter Koordinaten bei der Eisenbahn //3 Definition Bahngeodäsie, 

CNTD //4 Die wichtigsten Grundsätze im Umgang mit diesen Kerndaten der Infrastrukturanlagen 

//5 Wirtschaftliche und technischen Vorteile absoluter Koordinatentrassen //6 Bedeutung des 

Optimierungspotentials dank absoluten Trassenkoordinaten auf der Prozessebene //7 Umfassende 

Lösung bedingt grenzüberschreitende Sicht //8 Fundierte Vertiefung zu Fragen der Koordinatenreferenz, 

Datenstandardisierung sowie Datenschnittstelle //9 Ansprechpartner von Georail 

Phase 2: Gleisbaufirmen, Eurogeographics (Europäische Landesvermessungsämter), Forschung, 

Gleisbauliteratur //10 UIC interne Absprache mit Projekt Track Machine Guidance //11 Dialog 

UIC � Eurogeographics. Ansprechsstelle Eisenbahn für die Eurogeographics? //12 Folgearbeit 

auf Steuerebene: UIC-Merkblatt mit Leitbildcharakter //13 Folgearbeit Technik: Nationale Bahnreglemente 

und dritte Auflage des Buches „Eisenbahnbau – Wichmann Verlag, 2006-7 //14 Weiterführung 

des Georail Gedankengutes durch UIC-Track-Expertengruppe? 

1.1.3 Ziel von GEORAIL und Inhalt des Berichtes 

Klärung der Grundsatzfragen zum Einsatz von absoluten Koordinaten für die Eisenbahn. 

Skizzierung erster Überlegungen, die im Umgang mit Koordinaten der Förderung 

der Interoperabilität aller Objekte der Infrastruktur dienen. 

Das erste Kapitel gibt Einblick in die Thematik Koordinaten bei der Eisenbahn mit 

Schwergewicht Gleisanwendungen. Das zweite Kapitel reflektiert die wichtigsten Resultate, 

welche im Rahmen des UIC-Projektes bezüglich der Frage der semantischen Transformation. 

Das dritte Kapitel zeichnet die weiterführende Stossrichtung auf. 

1.2 Historische Entwicklung 

Die koordinatenbasiert, kontinuierlich-numerische Trassendefinition, CNTD (engl., continuous 

numeric track definition) hat sich in den 90er Jahren als Basis der Gleisarbeiten 

durchgesetzt. Grosse Bahnnetze planen deren Einführung oder haben sie bereits hinter 

sich. Die Gleismaschinenindustrie steuern damit Gleisbaumaschinen. 

Die Schlüsselwörter wirtschaftlicher Gleisarbeiten sind: Einfache Nutzung, (bahn-) 

netzweite Einheitlichkeit, operative Präzision und Zuverlässigkeit, keine Spezialtricks 

bei der Anwendung. Daraus ergeben sich zwei geodätische Herausforderungen: 




- Die Harmonisierung der heute europaweit heterogenen, geodätischen 

Grundlagen. 

- Die Abbildung des (globalen) räumlichen Gleisverlaufs auf die ebenen Pläne. 

In der UIC (Union internationales des chemins de fer) sind Gleisarbeiten das Kerngeschäften 

des „Track Expert Group“. Klassisch kennen sie keine Koordinaten. Erste Beiträge 

für den Einsatz von Koordinaten in den Gleisarbeiten kommen von der Gruppe 

6.4 „Track and utility lines“ der FIG (Fédération Internationale des Géomètres). FIG 6.4 

postuliert den Kontakt zu den Bahnspezialisten: Die Führung gehört langfristig nicht 

zur FIG, sondern zur UIC. Der Übergang erfolgt schrittweise: 

1990 – Entscheid der FIG zum Einstieg in die Thematik Bahngeodäsie. 

1996 – Die Präsidenten der FIG und der UIC erstellen einen ersten Kontakt. 

2000 – Die „Track Expert Group“ der UIC übernimmt die Leitung des Koordinatenprojektes 

zur Steuerung der Gleisbaumaschinen unter der Führung der schwedischen Bahnen 

(BV). 

2002 – Beginn des UIC Projektes Georail. Abschluss des FIG Engagements. 

2004 – Erste „Open Rail Session“ unter dem Patronat der UIC. 

Nebst den Bahnprojektpartnern sind folgende Bereiche in Georail involviert: 

- ExG-G (expertgroup geodesy, Arbeitsgruppe Geodäsie) von Eurogeographics 

als Vertreter der europäischen Landesvermessungsverwaltungen. 

In Abstimmung mit der EU-Kommission, legen sie in den 90er Jahren 

ETRS89 als europäische Koordinatenbasis fest. 

- ISO/TC211 und CEN/TC287 im Bereich der Datenstandardisierung. 

- Die Vertreter der Gleisbaumaschinenindustrie Plasser-Theurer und Müller 

AG. 

- Die Forschung, vertreten durch das Institut für Geodäsie der ETH Zürich 

- Die Eisenbahnbauliteratur durch die Hauptverfasser des Buches „Eisenbahnbau“ 

(G. Müller, Wichmann Verlag, 2000) der Hochschule für Technik 

und Wirtschaft in Dresden 

1.3 Einige Grundbegriffe 

CNTD oder Continuous, Numeric Track Definition ist der englische Begriff für absolute 

Gleistrassierung auf der Basis von Koordinaten. 

CNTD beschreibt die 3-dimensionale Gleisgeometrie mit mathematisch exakt definierten 

Elementen, die nahtlos aneinandergeknüpft, die Gleise an jedem beliebigen Punkt in 

Lage, Höhe und Überhöhung beschreiben. 

Nebst CNTD bilden folgende Elemente die Basis der Bahngeodäsie: 

- Die Ordnungsdaten als Schlüssel für die Datenabfrage und – 

- 

Strukturierung, in Form von eineindeutigen numerischen Streckentrassen. 

Netzweit gruppiert, bilden diese, „KM-Achsen“ genannten Trassen, die Streckennetze 

der Eisenbahngesellschaften. 

Die geodätischen Referenzpunkte. Über diese Punkte sind die Bahndaten 

am absoluten Koordinatensystem angebunden. Diese Punkte beinhalten 

auch die Funktionalität der Gleisvermarkung, was zu den, im folgenden Abschnitt 

beschrieben, Vorteilen führt. 

- Die Trassenpunkte und die kritischen Punkte des Lichtraums, welche der 

Trassenrechnung zugrunde liegen. 




Bahngeodäsie ist ein Teilfachgebiet der Ingenieurvermessung, das alle Geoinformationen 

für die topologische Datenstrukturierung, Verwaltung und interdisziplinäre Nutzung 

numerischer Gleistrassen liefert und die damit zusammenhängenden Verfahren 

beinhaltet. 

Die KM-Achsen bilden den Kern der hierarchisch strukturierten, koordinatengebundenen 

Daten der Infrastruktur (Abb. 1.1). Das zweite Niveau um den Kern, beinhaltet die 

Gleisdaten. Sie werden von allen Fachdiensten benötigt. Die dritte Schicht umfasst die 

wichtigsten Daten der Fachdienste welche auch von den anderen Bereichen benutzt 

werden und das letzte Niveau beinhaltet die Daten, deren Interessen auf den Fachdienst 

beschränkt sind. 

Diese Strukturierungsart erlaubt es, den Datenzugriff mittels zwei Koordinatenwerten 

durch eine eindimensionale Abfrage über einen KM-Wert zu ersetzen, was einer beträchtlichen 

Vereinfachung bezüglich der Organisation der Abfragealgorithmen gleichkommt. 

Koordinatenreferenzierte Infrastrukturobjekte, 

aufgebaut nach dem Schalenmodell: 

Kern: Das Streckennetz mit Knoten (die Betriebspunkte) 

und Kanten (die Strecken) 

Erste Schale: Das Gleisnetz 

Zweite Schale: Die Kern-Fachdienstdaten. 

Dritte Schale: Fachdienstdaten mit limitiertem 

Interesse 

CNTD: Geodätische Referenzpunkte sowie die 

Daten von Kern und erster Schale des Schalenmodells 

Abb. 1.1 : Hierarchisches Schichtenmodell der koordinatenbasierten Daten der Infrastruktur 

1.4 Technische Entwicklung 

Die Entwicklung von CNTD ist das Resultat der engen Zusammenarbeit von Fachleuten 

aus Vermessung, Bahndienst und Informatik. Die CNTD Entwicklung begann im operativen 

Tagesgeschäft der Eisenbahn nach dem „vom Benutzer für den Benutzer“ - Modus. 

Drei Jahrzehnte charakterisieren die Entwicklung wie folgt: 

- 80er Jahre: Verschiedene Einzelentwicklungen im Bottom-up Verfahren. 

- 90er Jahre: Verschiedene Konsolidierungsphasen bei den Bahnen, aber ohne 

grenzüberschreitende Koordination. 

- Ab 2000: Operative Reife der Systeme mit Erhöhung der Wirtschaftlichkeit 

im Gleisbereich. Erste internationale Abstimmungsbestrebungen. 

Die Optimierung auf Prozess- und Organisationsebene ist der nächste, wichtige Entwicklungsschritt. 

CNTD setzt den Methoden der bisherigen, relativen Gleistrassierung ein Ende. 

Diese alten Methoden beruhen alle auf dem Pfeilhöhenprinzip. Mit einer gespannten 

Schnur zwischen zwei Bezugspunkten, misst man die Pfeilhöhe eines Kurvenabschnittes 

und vergleicht ihn mit einem theoretischen Wert. Ab 1940, beginnen die Bahnen, die 




Kurven ihres Netzes auf diese Art zu unterhalten. Senkrecht, einen Meter neben den 

Gleisen, alle 20m eingeschlagene Gleisstücke, sind die Bezugspunkte der Gleistrassierung, 

nachfolgenden Vermarkungspunkte genannt. Die zwischen den Kurven liegenden 

Geraden werden in der Regel nicht vermarkt. 

Erste Impulse für den Wechsel kommen: 

- Von der Gleisbaumaschinenindustrie, welche im Bereich der Automatisierung 

der Maschinensteuerung entscheidende Fortschritte macht. 

- Von den Bahnen welche beginnen, koordinatenbasierte, numerische Gleistrassen 

zu rechnen. 

Der Durchbruch erfolgt, durch das Zusammenlegen der Funktionalitäten „Vermarkungspunkt“ 

und „geodätischer Fixpunkt“. Die Gleismaschinen können, dank den 

Fortschritten der automatischen Gleisbaumaschinensteuerung und den koordinatenmässig 

definierten Vermarkungspunkten, für jeden Gleispunkt in Echtzeit die IST-Lage 

des Gleises bestimmen, sowie die Differenz zwischen der effektiven Gleislage und der 

theoretischen Soll-Lage. Das Resultat dient als Steuerwert der Gleismaschinen, dessen 

Ermittlung automatisch aus folgenden Grunddaten ermittelt wird: 

- Die koordinatenmässig definierten Vermarkungspunkte, 

- Die kontinuierlich gerechneten, theoretischen Koordinatentrassen, 

- Die netzweit homogenen, eineindeutigen Koordinatenreferenz, 

- Die automatisiert ermittelte IST-Lage der Gleise. 

Die einführend aufgeführten Grundbedingungen für den automatisierten Einsatz der 

Gleismaschinen für den systematischen Unterhalt sind somit vollständig erfüllt: Einfache 

Nutzung, bahnnetzweite Einheitlichkeit, operative Präzision und Zuverlässigkeit, 

Keine Spezialtricks bei der Anwendung 

Dieser Automatisierungsprozess funktioniert heute in der Praxis des Gleisunterhaltes 

unterschiedlich. 

- Für Vermarkungspunkte die als geodätische Messpunkte materialisiert, auf 

den Fahrleitungsmasten fixiert sind, ist die Methodik voll operativ und ausgereift. 

- Die Variante, wo nur noch mit Satellitenpositionierung gearbeitet wird, ist 

heute erst im Aufbau. Anstelle einer Vermarkung entlang des Gleises gibt es 

nur noch alle 2 km einen, mit GPS bestimmten, geodätischen Referenzpunkt 

in Gleisnähe. Heute noch nicht gelöste Probleme sind: 

� Keine GPS-Signale in den Schattenzonen (z.B. in Tunnels, bei abgedeckten 

Bereichen der Bahnhöfe, ...). 

� Unzureichende Präzision für kritische Netzteile, z.B.: Komplexe Weichenverbindungen 

– häufig die Ein- und Ausfahrten grösserer Bahnhöfe 

– feste Fahrbahn und vor allem alle Strecken wo Hochgeschwindigkeit 

gefahren wird. Dort müssen repetitiv Absteckgenauigkeiten im 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 Gleisbereich 

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-Schnittstelle 

Mit dem „Compiler“ wird das textuelle Schema geprüft. Sobald diese Konsistenzprüfung 

fehlerfrei abläuft, wird daraus die Beschreibung des Transferformats (physisches 

Schema) erstellt. Im vorliegenden Beispiel wird das INTERLIS-Transferformat ITF verwendet. 

Analog kann jedoch auch das XTF- oder GML-Transferformat erzeugt werden. 

Das physische Schema enthält die Information, welches wie die Transferdatei strukturiert 

sein muss. 

Entsprechend diesem Standardformat werden die Ausgangsdaten nun umstrukturiert. 

In den meisten Fällen genügt dazu eine einfache Programmier- oder Skriptsprache, zum 

Beispiel awk. Awk ist eine einfache Skriptsprache auf Basis der Mustererkennung, mit 

deren Hilfe ASCII-Dateien systematisch auf das Standardformat umgebaut werden 

können. 

2.3 Visualisierung der Strecken- und Stationsdaten mit Geo-Shop 

Die SBB-Streckendaten liegen nun im systemunabhängigen INTERLIS-Transferformat 

(ITF) vor. Sie können mit einer Software, welche INTERLIS unterstützt, visualisiert 

werden. Im Folgenden wird dafür „GeoShop“ verwendet, eine Software, welche auf 

systemneutralen Standards basiert (https, Java, INTERLIS). Sie ermöglicht die Bearbeitung 

von Geodaten unterschiedlicher Struktur (insbesondere die Visualisierung, die 

Verbreitung sowie der Verkauf dieser Daten) über das Intra- oder Internet. Geoshop besteht 

aus 3 Modulen: 

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

sowie die Benutzerinformationen 

- Geoshop Client Tools: Sie ermöglichen die Visualisierung und Verbreitung 

der Daten, wobei vom Kunden einzig ein Java-fähiger Webbrowser benötigt 

wird. 

- Geoshop Administrator Tools: Sie steuern die Konfiguration des Servers, den 

Status von Benutzern und Bestellungen sowie die Darstellung der Geodaten. 




2.4 Modellierung der Fachdienst-Daten: FahrleitungAE 

In einem nächsten Schritt geht es darum, den Inhalt von nicht verknüpften Datenbanktabellen 

mit Hilfe der modellbasierten Methode gemeinsam nutzbar zu machen, vorausgesetzt 

beide Tabellen enthalten mindestens ein gemeinsames Attribut. Als Beispiel 

wird für die Fahrleitungsinformationen der SBB, welche zu den Fachdienst-Daten gehören, 

aus den Streckenübersichtsdaten die Geometrie hergeleitet. 

Die Informationen zu den Fahrleitungen sind in einer Excel-Tabelle enthalten, wobei 

jede Zeile einem Fahrleitungsabschnitt entspricht. Die Tabelle enthält für jeden Fahrleitungsabschnitt 

Attribute, beispielsweise das Erstelektrifizierungsjahr. Obwohl die Fahrleitungen 

einen eindeutigen Raumbezug aufweisen, sind in der Tabelle keine Koordinaten 

enthalten. Einzige räumliche Attribute bilden die Kilometrierungswerte (km von, 

km bis), welche jeweils Anfang und Ende eines Fahrleitungsabschnittes repräsentieren. 

Die Kilometer-Achsen der Streckenübersichtsdaten sind meist in mehrere Fahrleitungsabschnitte 

unterteilt, welche jeweils aus einer Vielzahl von minimalen Streckenabschnitten 

bestehen. 

Baujahr Fahrleitung 

BPK von Linie von Fil von LinieKorr km von 

Lausanne 100 100 West Lausanne 0.0000 

St-Maurice 100 100 West St-Maurice 51564.9400 

Sion 100 100 West St-Maurice 92432.0600 

Brig 100 100 West Brig 145548.5000 

Brig Tunnel 109 109 West Brig 147149.9000 

Vevey Ouest (bif) 111 111 West Lausanne 762.5000 

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

St-Maurice 100 100 St-Maurice 51564.9400 1924 

Sion 100 100 St-Maurice 92432.0600 1923 

Brig 100 100 Brig 145548.5000 1919 

Iselle di Trasquera 100 100 Brig 167478.3100 1906 

Iselle portail tunnel 109 109 Brig 166973.4000 1922 

Puidoux-Chexbres 111 111 Lausanne 7829.0000 1940 

Abb. 2.1 : Auszug aus der Exceldatei der Fahrleitungsdaten 

Die Herleitung von Fahrleitungsdaten und ihrem Verlauf aus Fahrleitungsdaten, die 

nur Anfangs- und End-Kilometrierungswerte enthalten, und aus Ordnungsdaten mit 

geometrischem Verlauf, ist ein typisches Beispiel für eine semantische Transformation. 

Zunächst ist die Ausgangsklasse der Fahrleitungsdaten mit UML und INTERLIS zu beschreiben. 

Das gibt eine UML-Klasse „FahrleitungAE“ und eine INTERLIS-Klasse 

„Fahrleitung“. 




2.4.1 Standardisierung der Fachdienst-Schnittstelle: FahrleitungAE 

Aus dem INTERLIS-Modell kann automatisch die Formatbeschreibung für die Klasse 

„FahrleitungAE“ bestimmt werden. Mit einem 1:1 Prozessor werden die Daten der Excel-Tabelle 

umgebaut auf das Standardformat ITF. 

2.4.2 Modellierung der Fachdienst-Daten: Fahrleitung (mit Verlauf) 

Als Zieldatei der semantischen Umformung wollen wir die einfache Klasse „Fahrleitung“ 

mit nur zwei Attributen definieren: Das Attribut „Erstelektrifizierung“, das aus 

der Klasse „Fahrleitung “ übernommen wird, und das Attribut „Verlauf“ vom Typ PO- 

LYLINE, das neu berechnet wird aus den Attributen „km_von“ und „km_bis“ der Klasse 

„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 „Achse“ 

(aus 2.4.1) und „FahrleitungAE“ (aus 2.4.2) sowie diejenigen der Zieldatei „Fahrleitung“ 

(aus 2.4.3) und ferner die Daten von „Achse“ und „Fahrleitung“ im Standardformat 

ITF von INTERLIS. 

Es gibt Software-Werkzeuge, wie das INTERLIS-Conversion-System ICS, die es erlauben, 

auf konzeptioneller Ebene den Umbau von zwei (oder mehr) gegebenen Klassen in 

eine neue Klasse (oder mehrere) zu definieren mit Hilfe der beteiligten Datenmodelle 

und mit geeigneten Umbaufunktionen. Die Umbaufunktion die wir brauchen heisst: 

Aus den Linien von Klasse „Achse“ Stücke ausschneiden vom Anfangspunkt „km_von“ bis zum 

Endpunkt „km_bis“ eines Objektes aus der Klasse „FahrleitungAE“, und diesen Linienausschnitt 

zusammen mit dem Wert des Attributes „Jahr_erste_Elektrifizierung“ aus der Klasse 

„FahrleitungAE“ abspeichern als neues Objekt der Klasse „Fahrleitung“. 




[……] 

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 Altersklassen 

der Fahrleitungsdaten unterschiedlich eingefärbt (Abb. 2.5). 


3 Zukunft 



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

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 Bahngesellschaften. 

Langfristziel ist, eine, von der UIC verabschiedete und von den Bahnen 

getragene, europaweite, harmonisierte Datenstruktur. Der Einsatz einer einheitlichen 

Software ist ein erster konkreter Harmonisierungsschritt. 

3.1.3 Harmonisierung der Datenstrukturen in angrenzenden, nicht abgestimmten 

Zonen 

In Grenzgebieten, wo unterschiedliche Netze zusammenkommen und die Bahnen nicht 

über die nötigen Ressourcen verfügen, um eine Abstimmungen vorzunehmen, respektive 

die technischen Anpassungen zu gross wären, können die Datensätze unverändert so 

stehen gelassen werden wie sie sind. Aus den Arbeiten zur Datenmodellierung geht 

hervor, dass Daten später immer zusammengebracht werden können. Trotzdem wird 

empfohlen, die Strukturen auf ihre Konsistenz hin zu prüfen und Unstimmigkeiten 

möglichst früh zu bereinigen. 

3.1.4 Übergang zwischen verschiedenen Koordinatensystemen 

Damit die Daten in den angrenzenden, nicht harmonisierten Koordinaten zusammengebracht 

werden können, müssen entlang der Streckenabschnitte in den Übergangszonen, 

Fixpunkte in beiden Systemen gerechnet werden. Aus den zwei Koordinatenpaaren 

der identischen Punkte können die Transformationsparameter für den Übergang 

vom einem ins andere Systeme gerechnet werden. Der Massstabsfaktor der Transformation 

muss immer 1 sein um vor allem bei Konstruktionsteilen wie Weichen, die Massangaben 

nicht zu verändern. 

3.1.5 Abstimmung mit den Referenznetzen der amtlichen Vermessung 

Die Abstimmung bedingt hier zwingend den Dialog zwischen Eisenbahn und amtlicher 

Vermessung, um Doppelinvestionen bei der Festlegung des Fixpunktnetzes zu vermeiden. 

Es macht Sinn, wenn in den Übgangszonen, nebst den Koordinaten der beiden benachbarten 

Systeme als dritte Koordinatenangabe die ETRF89 Werte angebunden werden 

und daraus die Transformationswerte errechnet werden. 

3.2 Wie weiter? Konkret 

Klarheit und Einheitlichkeit bei der Einführung von CNTD, aufbauend auf den bahngeodätischen 

Grundlagen dieses Berichtes, soll von Anfang den europäischen Partnerbahnen 

der UIC ermöglichen, mit der neuen Koordinatentechnologie die bestmöglichen Resultate 

zu erzielen. 

Ein Merkblatt soll zuerst für die Bereiche Gleisbau und dann für alle zukünftigen, darauf 

aufbauenden Nutzungen, die Stossrichtung vorgeben. 

Dank 

An alle Mitarbeiter der ETH, der UIC der DB, der SNCF, der SBB welche am Fortschritt 

der Themen die in diesem Text erläutert sind gearbeitet haben. 


Robert Balanche 

Seftigenstrasse 164 

CH-3084 Wabern 

Tel : 

Fax : 

E-Mail : 

+41 31 963 21 11 

+41 31 963 22 97 

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

1 Einleitung 

Die Daten der Amtlichen Vermessung (AV) sind insbesondere seit Beginn der Umsetzung 

des Projektes Reform der Amtlichen Vermessung (RAV) immer populärer geworden. 

Dies beruht nicht zuletzt auf der seinerseits gewählten Strategie des modellbasierten 

Konzeptes für die Verwaltung der numerischen Daten. Es handelte sich damals 

noch um eine visionäre Lösung, von welcher wir heute die Früchte « Nutzen und Ertrag 

» ernten können. 

Aufgrund unseres föderalistischen Systems und der dezentralen Organisationsstruktur 

der Amtlichen Vermessung der Schweiz ist der Arbeitsfortschritt bei der Erstellung der 

Daten der AV von Kanton zu Kanton und von Region zu Region verschieden. Auch 

heute noch sind die Daten der AV nicht flächendeckend über die ganze Schweiz vorhanden. 

Diese Tatsache führt dazu, dass eine ansehnliche Anzahl von Kunden diese 

sehr genauen und zuverlässigen Daten der AV nicht verwendet. 

Um dieser fehlenden Flächendeckung begegnen zu können, hat das Departement für 

Verteidigung, Bevölkerungsschutz und Sport (VBS) in der Strategie der Amtlichen Vermessung 

für die Jahre 2004-2007 mit einer Vision für die Folgejahre 1 im Kontext und im 

Zusammenhang mit der Nationalen Geodaten-Infrastruktur (NGDI) folgendes festgelegt: 

Die Referenzdaten der NGDI und damit auch die Daten der AV müssen folgende 

Voraussetzungen erfüllen: 

a. 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 Datenmodell 

der AV beschrieben und über die Amtliche Vermessungsschnittstelle (AVS) austauschbar 

sind. Deren Aktualität, Genauigkeit und Informationsgehalt erfüllen die Anforderungen 

der AV nicht. Sie dienen ausschliesslich für die Verwendung der AV als Referenzdaten 

für Landinformationssysteme und nicht für die Bedürfnisse des Grundbuchs. 

Die PEP ergänzen die AV in Gebieten, in welchen noch keine AV-Daten oder nur graphische 

Grundbuchpläne existieren. Sie können auch die bestehenden Bestandteile der 

digitalen AV-Daten mit fehlenden Informationsebenen oder Themen ergänzen. 

Es ist vorgesehen, die PEP für die Informationsebenen „Bodenbedeckung“, „Einzelobjekte“ 

und „Nomenklatur“ aus bestehenden digitalen Produkten (z.B. VECTOR25 und 

SwissNames von swisstopo) abzuleiten. 

Die vorliegenden Ausführungen sind der Schnittstelle für die Überführung der Vektordaten 

der Landeskarte 1 : 25'000 (VECTOR25) ins Datenmodell der Amtlichen Vermessung 

(DM.01-AV-CH, Version 24) gewidmet. 

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



Integration Vector25 / AV 

2 Vergleich der VECTOR25-Daten mit denjenigen der AV 

2.1 Die VECTOR25-Daten 

VECTOR25 ist das digitale Landschaftsmodell der Schweiz, welches inhaltlich und geometrisch 

auf der Landeskarte 1 : 25’000 basiert. VECTOR25 gibt die natürlichen und 

künstlichen Objekte der Landschaft im flexiblen Vektorformat wieder und eignet sich 

speziell für den Einsatz in geografischen Informationssystemen (GIS). VECTOR25 beschreibt 

rund 8.5 Millionen Objekte mit Lage, Form und ihren Nachbarschaftsbeziehungen 

(Topologie) sowie der Objektart und weiteren Sachattributen. Sein Perimeter umfasst 

die ganze Schweiz und das angrenzende Ausland entsprechend dem Perimeter der 

Landeskarte 1 : 25‘000. Die Daten von VECTOR25 werden blattschnittfrei verwaltet. Um 

die Handhabbarkeit der Daten zu gewährleisten, werden extra grosse Objekte (z.B. ausgedehnte 

Waldgebiete) an geeigneten Stellen künstlich aufgetrennt. 

2.1.1 Struktur von VECTOR25 

VECTOR25 besteht aus 9 thematischen Ebenen: 

Thematische Ebene 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 Topologietyp 

ist ein Attributsatz definiert, der mindestens aus den Standardattributen 

(ObjectID, ObjectOrigin, ObjectVal bzw. Objektart, YearOfChange) besteht. VECTOR25 

umfasst insgesamt rund 150 unterschiedliche Objektarten (z.B. 2-Klass-Strasse, Bach). 

2.1.2 Qualität der VECTOR25-Daten 

VECTOR25 zeichnet sich durch folgende Qualitätsmerkmale aus: 

� 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 

werden 

� eindeutige und stabile Objektidentifikation (� Voraussetzung für inkrementelle 

Nachlieferungen) 

� Einfache Struktur (� Transfer / Einsatz auf anderen GIS und CAD-Systemen 

problemlos möglich). 


2.2 Das Datenmodell der Amtlichen Vermessung 



Aus dem Projekt « Reform der Amtlichen Vermessung (RAV) » zu Beginn der 90-er- 

Jahre ist das erste Datenmodell der Amtlichen Vermessung entstanden, das DM93. Dieses 

Datenmodell als Bestandteil der Technischen Verordnung über die Amtliche Vermessung 

(TVAV) 2 legte die Minimalanforderungen fest, welche die Kantone bei der Datenerhebung 

bezüglich Inhalt und Organisation der Daten einzuhalten hatten. Die meisten 

Kantone haben dieses Modell mit kantonalen Anforderungen erweitert; daher basieren 

alle Vermessungen ab 1993 auf diesem Modell. Heute erkennt man die grossen Vorteile, 

welche schweizweit einheitlich organisierte und strukturierte Daten in einem gemeinsamen 

Datenmodell mit sich bringen 

Ende der 90-er-Jahre zeigte es sich, dass das Datenmodell der AV überarbeitet und die 

Kinderkrankheiten korrigiert werden mussten, damit es den neuen Anforderungen gerecht 

werden konnte. So wurde am 18. Dezember 2001 das neue Datenmodell der AV, 

das DM.01-AV-CH publiziert. Unglücklicherweise enthielt dieses neue Datenmodell 

noch das provisorisch ausformulierte Thema « Gebäudeadressen », da die entsprechende 

Schweizer Norm SN 612040 zum Zeitpunkt der Modellerstellung noch nicht vollständig 

vorlag. Im Juni 2003 endlich wurde die Schweizer Norm « Gebäudeadressen » 

publiziert und zwei Wochen später wurde das Datenmodell DM.01-AV-CH, Version 24, 

welches die Vorgaben aus der Norm übernommen hatte, amtlich herausgegeben. 

2.2.1 Struktur von DM.01-AV-CH 

Die Amtliche Vermessung umfasst die nachstehenden 8 Informationsebenen: 

1. Fixpunkte 

2. Bodenbedeckung 

3. Einzelobjekte 

4. Höhen 

5. Liegenschaften 

6. Rohrleitungen 

7. Administrative Einteilungen 

Das Datenmodell der Amtlichen Vermessung gliedert sich in die nachstehenden 20 

Themen: 

1. FixpunkteKategorie1 



4. Bodenbedeckung 

5. Einzelobjekte 

6. Höhen 

7. Nomenklatur 

8. Liegenschaften 

9. Rohrleitungen 

10. Nummerierungsbereiche 

11. Gemeindegrenzen 

12. Bezirksgrenzen 

13. Kantonsgrenzen 

14. Landesgrenzen 

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




15. Planeinteilungen 

16. TS-Einteilung 

17. Rutschgebiete 

18. PLZ, Ortschaft 

19. Gebäudeadressen 

20. 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ätsanforderungen 

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 Informationsebene 

und Toleranzstufe. Man findet dort beispielsweise für die Ebenen « Liegenschaften 

» und « Rohrleitungen » die nachstehenden Genauigkeitsanforderungen: 

Lagegenauigkeit (Standardabweichung in cm) für einen im Gelände exakt definierten 

Punkt: 

TS2 TS3 TS4 TS5 

3.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 », « Liegenschaften 

» und für die Hoheitsgrenzen der Informationsebene « Administrative Einteilungen 

» sowie für spezielle Einzelpunkte nachzuweisen… 

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

3.1 Unterschiede in den beiden Datensätzen 

Gemäss der Beschreibung der Datenstruktur von VECTOR25 und den Daten im Datenmodell 

der AV gemäss Kapitel 2 erkennt man sofort, dass nicht nur die Objekte verschieden 

strukturiert sind, sondern dass auch die Definition der Informationen unterschiedlich 

ist. In der Tat, wenn man die Bodenbedeckung etwas genauer unter die Lupe 

nimmt, erkennt man, dass die Modellierung derselben Realität unterschiedlich vorgenommen 

worden ist. Von Seiten VECTOR25 erhält man z.B. folgende Beschreibung: 

Die Ebene „Primärflächen“ beschreibt die primäre topografische Bodenbedeckung. Die Flächenarten 

dieser Ebene schliessen sich gegenseitig aus (See und Wald) und bilden ein redundanzfreies, 

lückenloses Flächennetz. Im Gegensatz zur Landeskarte sind in den Primärflächen interpretierte 

Siedlungsgebiete enthalten. Einzelgebäude sind in der Ebene Gebäude verwaltet. 




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

1. Gebäude; 

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

Flugplatz, Wasserbecken sowie übrige befestigte Flächen; 

3. humusierte Flächen unterteilt in: Acker/Wiese/Weide, Intensivkulturen (weiter 

unterteilt in Reben und übrige Intensivkulturen), Gartenanlage, Hoch- 

/Flachmoor sowie übrige humusierte Flächen; 

4. Gewässer unterteilt in: stehendes Gewässer, fliessendes Gewässer sowie Schilfgürtel; 

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

6. vegetationslose Flächen unterteilt in: Fels, Gletscher/Firn, Geröll/Sand, Abbau/Deponie 

sowie übrige vegetationslose Flächen. 

Zwischen den Informationsebenen der beiden Datensätze erkennt man zwei grosse Unterschiede: 

Die Bodenbedeckung gemäss Datensatz von VECTOR25 enthält weder die 

Gebäude noch die Strassen. Dies bedeutet, dass diesem Umstand beim Transfer der Daten 

von VECTOR25 ins Datenmodell der AV Rechnung getragen werden muss. Diese 

Elemente müssen anders zusammengefasst und als Gebietseinteilung definiert werden. 

Nachstehend ein Beispiel, für welches beim Transfer der Daten eine Lösung gefunden 

werden muss. 

VECTOR25 

Primärflächen 

(Gebietseinteilung) 

Gebäude 

Strassen 

(Polyline) 

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

3.2 Übereinstimmung der Objekte 

(Flächen) 

DM.01-AV-CH 

Bodenbedeckung 

(Gebietseinteilung) 

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. 




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 




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 gedeckt 

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 mehrgleisig 

Bahngeleise 

Str_Bahn Strassenbahn Bahngeleise 

Str_Bhof 

Streckenverknüpfung innerhalb 

des Bahnhofareals Bahngeleise 

3.2.3 Übriger Verkehr 


A_Faehre Autofähre Faehre 

LS_Bahn Luftseilbahn Luftseilbahn 

Mat_Bahn Materialbahn Luftseilbahn 

P_Faehre Personenfähre Faehre 

Skilift 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 Gebaeude 

Z_Innenhof Innenhof uebrige_befestigte 

Z_Gasthof Abgelegener Gasthof Gebaeude 

Z_Huette Hütte Gebaeude 

Z_Kirche Kirche Gebaeude 

Z_Kuehlturm Kühlturm Silo_Turm_Gasometer (EO) 

Z_Lagertank Lagertank Gebaeude 

Z_Perron Perrondach Bahnsteig (EO) 

Z_Schiessstand Schiessstand, Schützenhaus Gebaeude 

Z_Schloss Schloss, Burg Gebaeude 

Z_Station Station / ÖV Haltestelle Unterstand 

Z_Treibhaus Treibhaus Unterstand 

Z_WBecken 

Wasserbecken (Schwimmbä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 Flughafenbahnhof-areal. 

Da für diese Objekte keine entsprechenden Elemente im Datenmodell 

DM.01-AV-CH existieren, werden sie nicht erfasst. 

3.2.9 Einzelobjekte 


Antenne Antenne Mast_Antenne 

ARA Abwasserreinigungsanlage weitere 

AusTurm Aussichtsturm Aussichtsturm 

BiStock Bildstock /Wegkreuz Bildstock_Kruzifix 

Brunnen Brunnen Brunnen 

Denkmal Denkmal Denkmal 

Doline Doline weitere 

Drehsch Drehscheibe Aussichtsturm 

ElWerk Elektrizitätswerk weitere 

Hoehle Höhle / Grotte Grotte_Hoehleneingang 

Kamin Hochkamin Hochkamin 

Kapelle Kapelle Bildstock_Kruzifix 

KiTurm Kirchturm uebriger_Gebaeudeteil 

Quelle Quelle Quelle 

Reserv Reservoir Reservoir 

Schiffst Schiffstation Landungssteg 

SendeAnl Sendeanlage Mast_Antenne 




Turm Turm Aussichtsturm 

W_Turm Wasserturm Aussichtsturm 

WaFall Wasserfall weitere 

ZistOff 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 Interface 

für den Transfer all dieser Objekte von VECTOR25 nach MD.01-AV-CH zu schreiben. 

Dazu benötigt man ein Werkzeug, mit welchem die Parameter so gesetzt werden 

können, dass jedes Element aus VECTOR25 in die richtige Ebene von MD.01-AV-CH 

transferiert wird. Die Erarbeitung eines solchen Interfaces kann nicht über 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 Interfaces 

mittels des Werkzeuges « ilitools ». 

Für dieses Interface, welches für die Modellierung in den Sprachen Französisch, 

Deutsch und Italienisch vorgesehen ist, war es notwendig, eine « Namens- und Attribut- 

Tabelle » zu erstellen, so dass das Skript lediglich einmal beschrieben werden musste. 

Am Anfang des Programmes wird ein Konfigurationsfile gelesen, welches die Zuordnung 

des gewünschten Modells definiert. 

Auszug aus der deutschsprachigen Namenstabelle der Primärflächen von VECTOR25 : 

MAP PRI 

LANG => D 

TOPIC => Bodenbedeckung 

TABLE => ProjBoFlaeche 

TABLE_NACH => BBNachfuehrung 

TABLE_SURFACE => ProjBoFlaeche_Geometrie 

OTHER => PEP 

Z_GERGEB_VAL => vegetationslos.Geroell_Sand 

Z_GERGEB => Z_GerGeb_X-Z_GerGle_X-Z_Geroel_X-Z_GerWa_X 

Z_FELS_VAL => vegetationslos.Fels 

Z_FELS => Z_Fels_X-Z_StauMa_X 

Z_FLUSS_VAL => Gewaesser.fliessendes 

Z_FLUSS => Z_Fluss_X 

Z_GEBUE_VAL => bestockt.uebrige_bestockte 

Z_GEBUE => Z_Gebue_X-Z_GerWaO_X-Z_SumWa_X-Z_WaldOf_X 

Z_GLET_VAL => vegetationslos.Gletscher_Firn 

Z_GLET => Z_Glet_X 

Z_KIGRUB_VAL => vegetationslos.Abbau_Deponie 

Z_KIGRUB => Z_KiGrub_X-Z_SteBru_X 

Z_SEE_VAL => Gewaesser.stehendes 

Z_SEE => Z_See_X 

Z_SUMPF_VAL => humusiert.uebrige_humusierte 

Z_SUMPF => Z_Sumpf_X-Z_ObstAn_X-Z_SumGeb_X-Z_SumWaO_X 




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 

END_MAP !PRI 

=> 1.0 

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 bekannt; 

man ist vielmehr gezwungen, diese Informationen der Zeichenerklärung zur 

Landeskarte 1 : 25'000 von swisstopo zu entnehmen, wo für jede Strassenklassierung 

eine bestimmte Mindestbreite vorgegeben wird. Durch diese zusätzliche attributive Information 

von VECTOR25 kann jedem Strassenelement eine bestimmte Breite zugeordnet 

werden und daraus können flächenhafte Objekte gebildet werden. 

Gemäss Flyer « Zeichenerklärung » zu den Landeskarten sind die Strassenklassierungen 

wie folgt definiert: 

� 1- Kl.-Strasse, (mind. 6m breit) 

� 2- Kl.-Strasse, (mind. 4m breit) 

� Quartierstrasse, (mind. 4m breit) 

� 3-Kl.-Strasse, (mind. 2,8m breit) 

� 4- Kl. Fahrweg (mind. 1,8m breit) 

� 5-Kl. Feld-, Wald-, Veloweg 

� 6- Kl.., Fussweg 

Die 5-Kl. und 6-Kl.-Objekte werden als Wege mit linearer Geometrie in die Informationsebene 

« Einzelobjekte » transferiert 

Die Strassenverbreiterungen, ausgehend von den linearen Objekten, und die Erstellung 

von gebietseinteilenden Flächenobjekten erfolgt mit konventionellen GIS-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, einem 

kartographischen Produkt mit generalisierten Informationen. Es ist nicht möglich, 

ausgehend von diesen generalisierten Informationen, die Bedürfnisse der AV oder der 

provisorischen Ersatzprodukte (PEP) abdecken zu können. Es ist vielmehr nötig, dazu 

auf weitere Grundlagedaten zurückzugreifen, z.B. durch die Verwendung der Informationen 

für das Strassennetz, welche mittels des Programmes ATOMI von swisstopo aus 

den digitalen Orthofotos gewonnen werden. 

ATOMI ist ein Programm für die automatische Extraktion dreidimensionaler Strassenachsen 

aus Orthofotos, dem digitalen Geländemodell sowie dem bereits vorhandenen 

vektoriellen Strassennetz aus VECTOR25. Die nachstehende Figur 3 zeigt die Überlagerung 

der Informationen von VECTOR25 und ATOMI: 




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

0 25 50 75 100 125 Meter 

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ässigen. 

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 treffen! 




Der ganze Prozess kann wie folgt zusammengefasst werden: 

Behandlung 

manuell 

3.5 Schlusskontrollen 

VECTOR25 ATOMI 

Vorbereitung 

der Daten 

nein 

Interface 

Resultat 

ja 

DM.01 

Vorbereitung 

der Daten 

Figur 4 : Integrationsprozess von verschiedenen Datenquellen 

Nachdem man die Vorgehenswahl getroffen hat und die Daten transferiert worden 

sind, ist die Integrität der daraus resultierenden Daten zu überprüfen. Die AV verlangt 

eine hohe Qualität der Daten und exakt einzuhaltende Anforderungen, die mit entsprechenden 

Werkzeugen geprüft werden. Daher kann nach erfolgreich durchgeführtem 

Datentransfer ein INTERLIS-file im Datenmodell DM.01-AV-CH generiert werden, welches 

mit einem entsprechenden Checker geprüft wird. Dabei stellt man fest, dass im so 

neu erzeugten Datensatz noch viele Fehler und Ungereimtheiten existieren. Nachstehend 

einige Beispiele mit den von uns festgestellten Fehlern: 

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

Behandlung 

manuell 


nein

Figur 8 : No area found for 

centroid 

Figur 6 : Resultierende Fläche sehr klein 

Figur 7 : Fehlende Punkte: noch zu erzeugen 

Figur 9 : Area with unknown 

centroid 



Figur 10 : Area with "n" 

centroids 

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

Figur 14 : full line overlap 

Für die Elimination obiger Fehler sind entweder weitere Routinen zu programmieren, 

welche diese Unzulänglichkeiten erkennen und beheben, oder es bedarf manueller Korrektureingriffe 

zur Erstellung eines kohärenten Datensatzes, welcher die Anforderungen 

der AV erfüllt. Auch nach der Vornahme dieser weiteren Verbesserungen gilt es 

abzuwägen, inwieweit das entstandene Endprodukt den Bedürfnissen des provisorischen 

Ersatzproduktes gerecht wird. Können die geringere Qualität und die noch 

verbleibenden « Ungereimtheiten » akzeptiert werden? 





Der Datentransfer von VECTOR25 ins Datenmodell DM.01-AV-CH zeigt, wie wichtig, ja 

unerlässlich eine Datenbeschreibung ist. Wenn ein Datensatz weder über ein Datenmodell 

noch über eine klare Datenbeschreibung verfügt, ist es praktisch unmöglich, diese 

Informationen für verschiedene andere Zwecke verwenden zu können. Sie sind nicht 

mehr „interoperabel“! 

Eine gute Datenbeschreibung reicht für die Interoperabilität jedoch noch nicht aus. Für 

die Interoperabilität der Daten bedarf es auch einer exakten Analyse, nicht nur des Datenmodells 

aber auch der Semantik. 

Man kann feststellen, dass die technische Interoperabilität weniger Probleme aufwirft 

als die semantische Interoperabilität. In der Tat muss man festhalten, dass der ursprünglich 

erfasste Datensatz für ein bestimmtes, festgelegtes Bedürfnis angelegt worden ist. 

Wenn man ihn nachher für andere als die ursprünglich vorgesehenen Zwecke verwendet 

will, riskiert man, dass die Anforderungen des ursprünglichen Datensatzes nicht 

mehr denjenigen des zweiten entsprechen. 

Die semantische Interoperabilität umfasst auch die sprachlichen Probleme. Wenn beispielsweise 

die beiden Datensätze in verschiedenen Sprachen festgelegt worden sind, 

muss auch die Korrespondenz von Ausdrücken und Definitionen festgelegt werden. Ein 

technisches Wörterbuch ist bei der Festlegung des Datensatzes in einer Fremdsprache 

eine grosse Hilfe. 

Die Interoperabilität von Daten ist eine Notwendigkeit und ein unerlässliches Werkzeug 

für eine effiziente Nutzung von Informationen, insbesondere von geographischen Informationen. 

Literatur 

� Strategie der Amtlichen Vermessung für die Jahre 2004 bis 2007 mit Vision für 

die Folgejahre, Eidgenössisches Departement für Verteidigung, Bevölkerungsschutz 

und Sport, Bundesamt für Landestopografie, Eidgenössische Vermessungsdirektion. 

� VECTOR25. Das digitale Landschaftsmodell der Schweiz, Bundesamt für Landestopografie. 

� Transfert des données de VECTOR25 dans le MD.01, Semesterarbeit, A. 

WILDBOLZ, EIVD 2004. 

� «Interlis Tools», Dokumentation der Firma Infogrips GmbH. 


KOGIS 

Rolf Buser, Dipl. Ing. ETH 

Koordinationsstelle GI & GIS (KOGIS) 

c/o Bundesamt für Landestopografie / swisstopo 

Seftigenstrasse 264 

CH-3084 Wabern 

Tel : 

Fax : 

E-Mail : 

+41 31 963 24 03 

+41 31 963 23 25 

14 

Nationale Geodaten-Infrastruktur 

(NGDI) 

Organisatorische Aspekte der 

Interoperabilität beim Bund 

Rolf Buser, Stv. Leiter KOGIS 

Koordinationsstelle GI & GIS des Bundes

Unter der Nationalen Geodaten-Infrastruktur (NGDI) wird gemäss der Strategie1 und 

dem Umsetzungskonzept2 zur Strategie für Geoinformation beim Bund “… ein von allen 

für die Bereitstellung von Geobasisdaten Verantwortlichen gemeinsam entwickeltes, genutztes 

und fortgeführtes System von politischen, institutionellen und technologischen Massnahmen 

verstanden. Dieses System stellt sicher, dass Verfahren, Daten, Technologien, Standards, rechtliche 

Grundlagen, finanzielle und personelle Ressourcen zur Gewinnung und Nutzung von Geoinformationen 

ziel- und bedarfsorientiert den beteiligten Verwaltungen, Organisationen und 

Bürgern auf allen Entscheidungsebenen (lokal, regional und national) zur Verfügung gestellt 

werden können.“ 

Diese Umschreibung der NGDI zeigt auf, dass hier eine Infrastruktur entwickelt werden 

soll, welche hochgradig interoperabel sein muss. Interoperabel einerseits auf der politischen, 

organisatorischen und institutionellen Ebene, andererseits auf der technischen, 

also der Daten- und Systemebene. Die technische Ebene bringt durch die schnelle Entwicklung 

der Internettechnologien immer bessere Lösungen. Auf dieser Ebene liegt jedoch 

auch beim Bund weniger das Problem. Technisch lässt sich schon vieles realisieren 

und es stehen schon gute Lösungen bereit. 

Auf der politischen, organisatorischen und institutionellen Ebene stehen wir hingegen 

bezüglich Interoperabilität im Geoinformationsbereich am Anfang. 

Nachfolgend werden einige organisatorische Aspekte beim Bund im Bereich der NGDI 

bezüglich Interoperabilität kurz dargelegt. 

Kontaktnetz 

Auf dem Weg zu einer NGDI muss die politische, organisatorische und institutionelle 

Interoperabilität der technischen vorausgehen. Eine gemeinsame Strategie, verbindliche 

Verfahren, eindeutige Begriffe, sowie genau abgestimmte Forderungen und Erwartungen 

der beteiligten Partner und Institutionen sind nötig. Eine umfassende und stetige 

„interpersonale“ Kommunikation und der Einbezug von Informationsgemeinschaften 

sind unabdingbar. Mit der konstituierenden Sitzung für das Kontaktnetz e-geo.ch im 

Januar 2005 ist ein erster Schritt in Richtung politischer, organisatorischer und institutioneller 

Interoperabilität getan. Das Kontaktnetz soll unter Berücksichtung oder gar 

Stärkung föderaler Strukturen und heterogener Systeme umgesetzt werden und wird 

durch ein Steuerorgan geleitet, in welchem sowohl alle Verwaltungsebenen als auch Institutionen 

und die Privatwirtschaft vertreten sind. 

Die neu gebildete Geschäftsstelle des Kontaktnetzes, welche vorerst vom Bund finanziert 

wird, bildet das Sekretariat des Steuerungsorgans und betreut in erster Linie die 

Aufgaben, welche ihr vom Steuerungsorgan anvertraut werden. 

Geobasisdaten und Geobasisdienste 

Mit höchster Priorität muss festgelegt werden, „WAS“ die Inhalte der NGDI Schweiz 

sind. d.h. welche Daten und Dienste die NGDI bereitstellen muss. Hier werden die oben 

erwähnten Informationsgemeinschaften eine entscheidende Rolle spielen. Innerhalb von 

eindeutig definierten Tätigkeitsbereichen (z.B. Raumplanung) müssen gemeinsame Vorstellungen 

über Modelle von Geobasisdaten- und Geobasisdiensten entwickelt werden. 

Nur dadurch kann die Interoperabilität auf der Datenebene und später bei angebotenen 

1 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 



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

Diensten erfolgreich sein. Mit der Erstellung des Geobasisdaten-Katalogs des Bundes ist 

ein erster Schritt getan. Auf der Basis dieses Katalogs kann die Diskussion über Informationsgemeinschaften 

geführt werden. 

Beim Bund geht es auf organisatorischer Ebene primär darum, vorhandene Informationsgemeinschaften 

für diese neuen Aufgaben zu motivieren oder den Aufbau von neuen 

Informationsgemeinschaften zu unterstützen. Weiter müssen die Entscheidungsträger 

für diese Bereiche sensibilisiert werden. 

Der Bund will grundlegende Geodienste bereitstellen und vernetzen. KOGIS koordiniert 

die Umsetzung der bundesweiten Plattform, welche auf „produktiven“ Normen 

basiert, wie jene, die aus den Arbeiten von SNV (Schweizerische Normen-Vereinigung) 

und OGC (Open Geospatial Consortium) hervorgegangen sind. 

Auf der organisatorischen Seite muss diskutiert werden, wie ein Register der Geobasisdienste 

aufgebaut werden kann, in welchem die Anbieter und deren Geobasisdienste 

strukturiert beschrieben und kategorisiert sind. Weiter müssen die Geobasisdienste exakt 

beschrieben werden, und es wird festgelegt, wie darauf zugegriffen werden kann 

und wie sie kommunizieren. 

Standards / Normung 

Der modellbasierte Ansatz ist entscheidend für die Interoperabilität und soll beim Bund 

in Zukunft eine wichtige Rolle spielen. 

Folgende Richtlinien und Standards werden auf Bundesebene festgelegt: 

� die Metadatenbeschreibung erfolgt über das auf der Basis von ISO 19115 entwickelte 

CH-Profil (im Minimum über das von ISO definierte Core-Profil), 

� die Geodatenmodellierung erfolgt mit der Modellierungssprache UML (Unified 

Modeling Language) und INTERLIS auf der Basis eines Objektkatalogs, 

� der systemneutrale Austausch von Geobasisdaten und Metadaten erfolgt mindestens 

auf der Basis der Modellbeschreibung INTERLIS/XML unter Berücksichtigung 

der Kompatibilität mit internationalen Standards (z.B. mit GML). 

� die Vernetzung von grundlegenden Geodiensten erfolgt mindestens unter Berücksichtigung 

der Kompatibilität mit den internationalen Standards (wie W3C 

(World Wide Web Consortium)) 

Die Bestrebungen im Sinne einer nationalen Plattform Geonormen (NGN) sollen weiter 

gefördert und auch finanziell unterstützt werden. Die Entwicklung und Anwendung 

von Geo-Normen und Datenmodellen forciert und koordiniert werden. Datenmodelle 

und Normen sollen allen interessierten Nutzern zur Verfügung stehen und weiterentwickelt 

werden. Dazu sind in einem ersten Schritt vorhandene effiziente aber unkoordinierte 

und ad hoc finanzierte Initiativen und Aktivitäten zu koordinieren und auf eine 

stabile finanzielle Basis zu stellen. 

Ziel ist die rasche Verbreitung des Wissens über Nutzen und Anwendung der Datenmodelle 

und Normen sowie deren konsequente Anwendung. Die Aufgabenbereiche 

Ausbildung, Technik, Datenmodelle, Support, Normen und Marketing bilden dabei die 

Haupttätigkeiten. 


Rudolf Schneeberger 

Dorfstrasse 53 

CH-8105 Regensdorf 

Tel : 

Fax : 

E-Mail : 

+41 44 871 21 90 

+41 44 871 21 99 

15 

Nationale Profile der internationalen 

Standards am Beispiel Metadaten 

Rudolf Schneeberger, ITV Geomatik AG

1 Einleitung 

1.1 Definition von Metadaten 

Metadaten sind für viele Leute schwammig, undefinierbar und zu technisch, scheinen 

unwichtig, da die Daten vorhanden sind, werden oft vernachlässigt behandelt, existieren 

nur auf Notizzetteln. Aus diesen Gründen werden Metadaten selten freiwillig erfasst 

und nachgeführt. Denn es ist heute dem Benutzer oft nicht ganz klar, wozu sie eigentlich 

dienen. 

Laut Definition handelt es sich bei Metadaten um „Daten über Daten“, das heisst es sind 

beschreibende Daten der effektiven Daten. Zwei weitere Definitionen werden noch etwas 

klarer: 

� Unter Metadaten versteht man strukturierte Daten, mit deren Hilfe eine Informationsressource 

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 Schokolade 

weiss eingepackt ist und „Schokolade“ drauf steht. Welche kaufen Sie? Wahrscheinlich 

keine, weil nicht bekannt ist, um was für eine Schokolade es sich handelt. Der 

Käufer will wissen, ob es eine Schokolade ist mit Nüssen oder ohne, wer sie hergestellt 

hat, wie sie heisst, wie teuer sie ist, usw. Erst mit diesen Angaben werden die unterschiedlichen 

Schokoladen vergleichbar und er kann entscheiden, welches die Richtige 

ist und bei welcher das Preis/Leistungs-Verhältnis stimmt. 

Genau gleich verhält es sich mit Metadaten für Geodaten. Sie geben eine genaue Beschreibung 

des Geodatenbestandes. Erst wenn man den genauen Inhalt, die Genauigkeit, 

den Preis, das Modell, das Format und vieles mehr eines Geodatenbestandes kennt, 

kann man entscheiden, ob er den Ansprüchen genügt. Die wichtigsten Fragen, welche 

mit Metadaten beantwortet werden sind bei Geodaten: 



Nationale Profile der internationalen Standards am Beispiel Metadaten 

WER bietet - Institutionen - Ansprechpartner 

- Ersteller / Verteiler 

- Zuständigkeit 

- Anschrift 

WAS und - Datenarten - Erfassungsdatum 

- Inhalte - Name und Beschreibung 

- Massstab - Art 

WIEVIEL - Datenmenge 

- Flächendeckung 

- Status 

WORÜBER - Objektarten - Thesaurus 

- räumlicher Bezug 

- zeitlicher Bezug 

- Fachgebiet 

WIE in - Format - Datenbank 

- Schnittstelle - Zugangsberechtigung 

- Analog / Digital - Zugangsadresse 

WELCHEM Zusammenhang - fachliche Bedeutung - Nutzungsrestriktionen 

und zu - Aufgabenbeschreibung 

- Eignungshinweis 

WELCHEN Konditionen - Preis - Rechtsinhaber 

1.2 Metainformation als Teil einer NGDI 

- Zugriffsrechte - Vervielfältigungen 

- Nutzungsrechte 

Das Hauptziel einer Nationalen Geodaten-Infrastruktur (NGDI) besteht darin, über einen 

leichten Zugang ein optimales Angebot und eine breitere Nutzung von Geoinformation 

zu bewirken. In dieser NGDI sind Metainformationen ein wesentlicher Bestandteil. 


2 ISO Normen 



2.1 Inhalt von ISO von 19115:2003 - Metadata 

Struktur für die Beschreibung von digitalen geographischen Daten in Form eines abstrakten 

Modells (konzeptionelles Metadatenmodell): 

� 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 einzuschränken. 

Die ISO Norm definiert mehr als 300 Metadatenelemente (Klassen, Attribute, 

Beziehungen), wobei die meisten davon optional verwendet werden können. 

Profile 

Profile erlauben es, Abbildungen aus dem umfassenden ISO-Metadatenmodell für spezifische 

Anwendungen zu erstellen. In jedem Profil muss das minimale 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. 

Umfassendes 

ISO Metadatenmodell 

(ISO Comprehensive Metadata Profile) 

Minimales 

ISO Metadatenmodell 

(ISO Core Metadata 

components) 

Profil XY 

Erweiterung 




Regeln für die Erstellung von Profilen 

1. Vorhandene Elemente dürfen in eigenen Profilen nicht abgeändert werden. 

2. Werden in einer neuen Entitätsmenge bereits bestehende Attribute verwendet, 

dürfen deren Attribute nicht abgeändert werden. 

3. In Erweiterungen ist es erlaubt, ... 

... strengere Verbindungstypen festzulegen, 

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

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

6. ... oder zu erweitern. 

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

3 Schweizer Norm für Metadaten 

3.1 Warum braucht es eine Schweizer Norm? 

Bestehende Metadateninventare sind entweder nur regional (Kantone), fachlich beschränkt 

(CDS, GeoMeta, Geostat) oder nicht Internet-tauglich betreffend Suche und 

Erfassung von Metadaten. Bisherige Metadatenbanken sind nicht kompatibel untereinander 

und sind auch nicht kompatibel zu der ISO Norm 19115:2003. 

KOGIS ist für die Geodatenkoordination in der Bundesverwaltung verantwortlich und 

hatte darum auch bei Metadaten Handlungsbedarf. Da KOGIS nicht ein eigenes "Bundesmodell" 

entwickeln wollte, wurde in Zusammenarbeit mit einer Arbeitsgruppe aus 

Kantonen, Hochschulen und Firmen ein Metadatenmodell definiert, das die minimalen 

Anforderungen aller Beteiligten befriedigt, ISO kompatibel ist und welches vom SNV 

als Schweizer Norm veröffentlicht wird. 

3.2 Von der ISO-Norm zur Schweizer Norm 

SIK - GIS 

CDS 

Stellungnahmen 

zum Entwurf 

Arbeitsgruppe 

SNV - TK 151 

SNV 

Vernehmlassung 

ISO 

19115:2003 

Schweizer Norm 

SN 612050 

GM03 

Metadatenmodelle 

INTERLIS 

Beschreibung 

Pflichtenheft 

geocat.ch 

Pilot 

geocat.ch 

geocat.ch 

Catalog Gateway 




Um die Anliegen der Beteiligten in der Schweiz zu berücksichtigen, wurden die bestehenden 

Metadatenbanken der Schweizerischen Informatik Konferenz GIS (SIK-GIS) und 

des Bundesamtes für Wald und Landschaft (CDS) mit der ISO-Norm verglichen. Daraus 

entstand ein erster Entwurf eines Schweizer Metadatenprofils, in dem bereits Teile der 

ISO-Norm weggelassen wurden. Andere Teile wurden als Erweiterung neu modelliert. 

Man war sich bewusst, dass mit dem Vergleich lediglich zweier bestehender Metadatenbanken 

noch nicht alle Bedürfnisse abgedeckt sein würden. Stellungnahmen von 

Bundesämtern, Kantonen und weiteren interessierten Stellen ergaben zusätzliche Bedürfnisse. 

Das überarbeitete Metadatenmodell war Grundlage für den Schweizer 

Normentwurf, der Ende 2003 in eine offizielle Vernehmlassung geschickt wurde. Die 

Resultate dieser Vernehmlassung wurden in einer Arbeitsgruppe (SNV/TK151) besprochen. 

Diese Arbeitsgruppe, bestehend aus Vertretern aller interessierten Stellen, 

entschied in jedem Fall darüber, ob eine Eingabe berücksichtigt wurde oder nicht. Daraus 

wurde ein definitives Modell erarbeitet, welches Grundlage für die Schweizer Norm 

ist. 

Parallel zur Erarbeitung der Schweizer Norm wurde das Portal und der Metadatenserver 

geocat.ch spezifiziert und entwickelt (siehe Kapitel 4). 

3.3 Weshalb ISO als Grundlage? 

� 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 Datenaustausch 

mit anderen Ländern möglich. 

3.4 Unterschiede ISO Norm - CH Norm 

Die Modell-Beschreibung in UML in der Norm ISO 19115:2003 ist zu allgemein gehalten 

für eine konkrete Umsetzung. Aus diesem Grund wurde in der Schweiz das Modell detaillierter 

in INTERLIS 2, dem Schweizer Standard für Datenmodellierung und Datenaustausch, 

modelliert und mit UML-Notation dokumentiert. Dadurch wird der Konkretisierungsgrad 

erhöht und ein Datenaustausch ermöglicht. INTERLIS 2 beinhaltet Codierungsregeln 

zur automatisierten Generierung einer XML-Schema-Beschreibung, welche 

maschinenlesbar und zum Aufbau einer Datenbankstruktur und einer Applikation 

verwendet werden kann. Mit diesen Regeln entfällt der Aufwand, neben einer 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 Metadatenelemente 

enthalten. Es wurde jedoch ein anderer Ansatz der Modellierung gewählt (siehe 

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 minimaler 

Kern wird GM03Core definiert und durch Vererbung zu GM03Comprehensive 

erweitert. Die Vorteile des Vorgehens in der Schweiz gegenüber der ISO ist die bei allen 




Profilen identische Grundlage, GM03Core, und somit ein garantierter gemeinsamer 

Nenner für den Austausch. 

Core 

Metadatenmodell 

Comprehensive 


Lokales 


Lokales 


Lokales 


GM03Core 


GM03Comprehensive 


Lokales 


3.5 Grundsätze bei der Ausarbeitung der Schweizer Norm 

Als Grundlage wurde ISO 19115:2003 Metadata gewählt: 

Lokales 


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

� Es werden alle Metadatenelemente oder Klassen übernommen, die aus den Bedingungen 

und Vorgaben der Norm obligatorisch sind. 

� Es werden die Metadatenelemente definiert, welche notwendig sind, um die bestehenden 

Schweizer Datenkataloge abzudecken. 

Die Kompatibilität zu ISO 19115:2003 wird soweit sinnvoll sichergestellt: 

� 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 brauchbare 

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 Beziehungen 

3.6 GM03 Metadatenmodell 

Um eine minimale Beschreibung von Geodaten zu garantieren, wird das minimale Metadatenmodell 

GM03Core definiert. Zu GM03Core gehören die Metadatenelemente, mit 

welchen mindestens folgende Fragen beantwortet werden können: 

� 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 nachgeführt? 

(WANN) 




Das Modell GM03Core umfasst nur die wichtigsten Elemente und deckt nicht alle Anforderungen 

ab. Deshalb wurde ein umfassenderes Modell GM03Comprehensive ausgearbeitet, 

das alle Elemente von ISO enthält und weitere Bedürfnisse der Beteiligten 

abdeckt. 

3.7 Anwendungsbereich der Schweizer Norm SN612050 

Die Norm befasst sich mit Metadaten für Geodaten und gilt für Betriebe, die für die Erfassung, 

Verarbeitung, Verwaltung und Abgabe von Metadaten verantwortlich sind. 

Die Norm bezieht sich zwar auf Geodaten, kann aber sinngemäss auch für andere Anwendungsbereiche 

eingesetzt werden. 

Die Norm regelt, wie Metadaten konzeptionell strukturiert werden. Sie ermöglicht damit 

ein einheitliches Verständnis aller an Metadaten interessierten Personen und Stellen. 

Sie regelt aber nicht, wie konkrete Einrichtungen (z.B. Datenbanken) aufgebaut sein sollen. 

Die Norm entwickelt selbst keine Technik zur präzisen Beschreibung der Festlegungen. 

Sie bedient sich dafür existierenden Techniken. Für die Beschreibung des 

Datenmodells wird die Unified Modelling Language (UML) und die Datenbeschreibungssprache 

INTERLIS 2 verwendet. 

Die Norm legt den Datenaustausch fest. Als gemeinsames Transferprotokoll wird XML 

(Regeln nach INTERLIS 2) verwendet. 

4 geocat.ch 

4.1 Metadatenportal geocat.ch und Geodatenkatalog 

Die Anforderungen an einen Geodatenkatalog lassen sich auf zwei wesentliche Punkte 

reduzieren: 

� Der Geodatenkatalog muss über eine Such-Applikation verfügen, damit erfasste 

Metadaten gesichtet werden können. Über ein heterogenes und dezentral organisiertes 

Metadatenportal wird dieser Geodatenkatalog abgefragt und die gewünschten 

Daten werden dem Benutzer zur Verfügung gestellt. 

� Der Geodatenkatalog muss über eine Administrations-Applikation verfügen, damit 

die Daten erfasst, verwaltet und aktuell gehalten werden können. 

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

Geodatenkatalog. 

4.2 Konkrete Umsetzung 

Das Hauptziel besteht darin, auf nationaler Ebene ein Portal für die Gesamtheit aller 

geographischen Metadaten zu verwirklichen. Es wird die Einführung einer dezentralisierten 

Infrastruktur beabsichtigt, welche die dezentralisierte Verwaltung und den Zugang 

auf alle angeschlossenen Metadatenkataloge erlaubt. 




3 

Catalog 

Server 

Database and Tool 

Administration 

general 

administrator 

KOGIS 

Search Server 

Metadatabase 

MetaCH 

2 

Metadata 

Management 

metadata 

contributor 

Catalog 

Gateway 

Partner and 

producer of 

Geodata 

Catalog 

Management 

catalog 

administrat 

or 

A 

1 

Discovery 

Service 

Discovery Service 

Gatew ay and Client of 

Metadatabases 

Import / Export 

catalog 

administrat 

or 



Geodata 

Es sind zwei Typen von Datenbanken verbunden: 

Metadata Metadata 

metadata 

contributor 



Geodata 


user 

metadata 

contributor 

B 

gateway 

manager 

Search Server 

C 

user 

Catalog 

Management 

Partner A 

Metadata 

catalog 

administrat 

or 

Portal für die 

Suche 

Gateway 

Metadatenkatalog mit 

seinen Administrationsund 

Verwaltungstools 

Benutzer 

(Oberfläche) 

Komponenten 

der Infrastruktur 

Partner 

Metadatenbank 

Beziehung zwischen eine 

Benutzer und einer 

Komponente 

Informationsfluss 

� Die zentrale geocat.ch-Datenbank, welche erreichbar ist über die Suchapplikation 

geocat.ch. 

� Verteilte Datenbanken, die mittels Catalog Gateway mit der Suchapplikation geocat.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 werden 

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 geographischen 

Metadaten verwendet. Im Allgemeinen ist vorgesehen, dass die Metadaten 

direkt bei den Geodaten produzierenden Partnern mit Hilfe der innerhalb ihrer Institution 

verfügbaren Infrastruktur verwaltet werden (Partner C).



Die Applikation unterstützt zwei Arten der Suche: die einfache Textsuche und die ausführliche 

Suche, bei der nach jedem Element gesucht werden kann. Beiden Such-Arten 

gemeinsam ist die geographische Suche nach einer Gebietsbezeichnung (z.B. Kanton 

Bern), innerhalb eines umhüllenden Rechtecks oder innerhalb eines frei definierbaren 

Polygons. 

Der Suchdienst muss deshalb einen koordinierten und transparenten Zugriff auf verschiedenartige 

Metadatenbanken ermöglichen. Die Funktionstüchtigkeit einer solchen 

Lösung bedingt die Verwendung eines gemeinsamen Protokolls für Abfrage und Ergebnis. 

Dieses Protokoll, in SOAP (Simple Object Access Protocol) beschrieben, ist relativ 

kostengünstig implementierbar, sowohl für relationale Datenbanken als auch für 

XML basierte Lösungen. 

geocat.ch 

Discovery Client 

Quellenangaben 

Anfrage (HTML) 

Präsentation der Resultate 

Detaillierte Anfrage (HTML) 

Präsentation der Resultate 

aus GM03 (HTML) 

Geocat.ch 

Portal 

Konsolidierung 

der Resultate 

Gateway Protokoll 

Anfrage(n) 

Resultat(e) in XML 

GM03 Anfrage(n) 

GM03 Resultat(e) in XML 

Gateway 

Server(s) 

� Vermessung und Geoinformation - GM03 - Metadatenmodell, Ein Schweizer Metadatenmodell 

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 


Willy Müller 

Informatikstrategieorgan Bund 

Friedheimweg 14 

CH-3003 Bern 

Tel : 

Fax : 

E-Mail : 

+41 31 325 90 35 

+41 31 322 45 66 

16 

Interoperabilität 

Nicht nur eine Frage der Technologie 

Willy Müller, Informatikstrategieorgan Bund

Interoperabilität im Geoinformationsbereich ist das Thema dieser Tagung. Aber was ist 

Interoperabilität? Nach der Definition in [IEEE 90] ist es, die Fähigkeit von zwei oder 

mehreren Systemen oder Komponenten, Informationen auszutauschen und die Information, 

welche ausgetauscht wurde, zu nutzen. In unserem Kontext geht es primär um 

die Möglichkeit, geografische Daten auszutauschen. Bis zu einem gewissen Grad ist Interoperabilität 

auf irgendeine Weise fast immer gegeben. So kann z.B. ein Vermessungsbüro 

einen Plan erstellen, ihn auf Papier ausdrucken und per Post an ein anderes Büro 

versenden, das ihn manuell in sein System überträgt. Wenn wir damit zufrieden wären, 

wären wir wohl nicht hier. Wir streben eine bessere Interoperabilität an. Das heisst, Interoperabilität 

kann besser oder schlechter sein. Die Güte der Interoperabilität hat dabei 

zwei Dimensionen: die eine korreliert negativ mit dem Aufwand und den Kosten, die 

nötig sind, um Daten elektronisch auszutauschen und weiter zu verwerten. Die andere 

korreliert positiv mit der Menge der Systeme oder Komponenten, welche untereinander 

Informationen austauschen und weiterverwenden können. Lassen sie uns daher für unseren 

Kontext die Definition von [IEEE 90] präzisieren: Interoperabilität ist die Fähigkeit 

möglichst vieler Systeme oder Komponenten, Daten elektronisch auszutauschen und sie 

mit möglichst wenig Aufwand, insbesondere ohne manuelle Bearbeitung, weiter zu 

verwenden. 

1 Der Bundesrates will eine reibungslose elektronische 

Zusammenarbeit 

Was hat der Staat zur Interoperabilität – insb. im Bereich der Geoinformationen - zu sagen? 

Soll er sich dazu überhaupt äussern, oder soll er besser die Finger davon lassen? 

Der Schweizer Staat - und das gilt für Bund, Kantone und Gemeinden gleichermassen - 

sieht sich in mehrerlei Hinsicht mit der auf den ersten Blick eher technischen Fragestellung 

konfrontiert: 

1. Er hat die Aufgabe, für Einwohnerinnen und Einwohner wie auch die Wirtschaft 

förderliche Rahmenbedingungen zu schaffen. 

2. Als Produzent und wichtiger Konsument von Geoinformationen ist er direkt betroffen. 

3. Er muss sich mit den Folgen verbesserter Interoperabilität auseinandersetzen. 

Der Bundesrat erachtet die Förderung der Informationsgesellschaft in der Schweiz als 

prioritär. Darüber hinaus will er seine Regierungs- und Verwaltungstätigkeit effizient, 

flexibel und transparent gestalten. In seiner eGovernment-Strategie hat er dazu drei 

Stossrichtungen definiert: 

1. Voraussetzungen schaffen: Die organisatorischen, technologischen und sicherheitsspezifischen 

Voraussetzungen für eine reibungslose Zusammenarbeit innerhalb 

der Verwaltung sollen geschaffen werden. 

2. Service excellence: Der Zugang zu den staatlichen Dienstleistungen – und dazu 

gehört auch die Bereitstellung einer ganzen Menge von Geoinformationen - soll 

für Privatwirtschaft, Bürgerinnen und Bürger leichter und transparenter werden. 

3. Vernetzung: Angestrebt wird die ‚elektronische Integration’ zwischen den Verwaltungsstellen 

der verschiedenen Staatsebenen (Bund, Kantone und Gemeinden) 

sowie zwischen dem Staat und seinen Partnern (öffentliche Hand, Wirtschaft 

und Gesellschaft). 



Interoperabilität: nicht nur eine Frage der Technologie 

Die Arbeiten zur Förderung der elektronischen Zusammenarbeit im Bereich der Geoinformationen 

sind also zu sehen als Teil einer übergeordneten Strategie. Zu diesem 

Zweck wurde u.a. KOGIS, die Koordinationsstelle für geografische Information und 

geografische Informationssysteme, ins Leben gerufen (vgl. www.kogis.ch). Die Stossrichtungen 

‚Voraussetzungen schaffen’ und ‚Vernetzung’ haben eine verbesserte Interoperabilität 

zum Ziel. 

Um die Interoperabilität zu steigern, sind dabei Massnahmen auf unterschiedlichen Ebenen 

notwendig. In Anlehnung an das Modell, welches wir im Rahmen der E- 

Government-Architektur der Schweiz entwickelt haben [eGovCH], sind insbesondere 

zu unterscheiden: 

Politische, rechtliche und 

organisatorische Rahmenbedingungen 

Fach-Services 

Daten-Services 

Directory 

Infrastruktur-Services 

Services 

Technische Basis 

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 elektronische 

Verarbeitung und den Datenaustausch, 

� Infrastruktur-Services: Nicht fachspezifische Anwendungen, welche den sicheren 

und zuverlässigen Datenaustausch ermöglichen, 

� Directory-Services: Elektronische, bei Bedarf maschinenlesbare Verzeichnisse über 

Kommunikationspartner und elektronisch zugängliche Dienstleistungen 

� Daten-Services: Definition der Syntax und Semantik, welche gewährleistet, dass 

Partner ausgetauschte Daten ohne grössere Probleme weiterverwenden können, 

� Fach-Services: Fachanwendungen, welche so geschrieben sind, dass sie mit anderen 

Fachanwendungen zusammenarbeiten können, 

� Organisation, Prozesse und Recht: Organisatorische und rechtliche Rahmenbedingungen, 

welche Interoperabilität zulassen und die Spielregeln für die elektronische 

Zusammenarbeit festlegen. 

Erst wenn auf allen Ebenen die geeigneten Voraussetzungen geschaffen sind, ist ein reibungsloses 

Zusammenspiel möglich. Nachfolgend wird exemplarisch auf einige kritische 

Themenkreise eingegangen. Zur Illustration wird in der Regel auf Beispiele im 

Geoinformationsbereich Bezug genommen. 




2 Erste Stossrichtung: Voraussetzungen schaffen 

Damit Systeme ohne menschliche Intervention Daten austauschen können, müssen sie 

sich verstehen. Das ist nur möglich, wenn sie die gleiche Sprache sprechen. Wir beginnen 

zu verstehen, wie derartige Sprachen optimalerweise aussehen sollten und wie sie 

zu dokumentieren sind. Entsprechende Spezifikationen im Geoinformationsbereich sind 

vorhanden und haben - zumindest teilweise - erste Praxistests bestanden (z.B. INTER- 

LIS, GML). Darauf im Detail einzugehen, ist nicht die Aufgabe dieses Beitrags. Bei der 

Auseinandersetzung mit der Spezifikation von Klassen, Konsistenzregeln und Tags vergisst 

man jedoch gerne, dass es letztlich um mehr geht, als die präzise Spezifikation. Auf 

drei Aspekte soll im Folgenden speziell hingewiesen werden: 

� der Kampf um die richtige Sprache 

� die Vergabe von Namen und Identifikatoren 

� Verknüpfungen von Daten unterschiedlicher Domänen. 

2.1 Der Kampf um die richtige Sprache 

Unglücklicherweise gibt es keine Naturgesetze, welche sicherstellen, dass es nur eine 

einzige Sprache gibt. Üblicherweise bilden sich daher mehr oder weniger unabhängig 

voneinander verschiedene Sprachgemeinschaften mit je eigenen Konventionen. Das ist 

bei den Geoinformationen nicht anders: Neben nationalen und internationalen Standardisierungsgremien 

setzen Softwareanbieter ihre eigenen Datenaustauschformate fest. 

Solange Mitglieder einer Sprachgemeinschaft lediglich unter sich Daten austauschen 

möchten, ist dies nicht weiter problematisch. Andernfalls stellen unterschiedliche Sprachen 

jedoch ein ernsthaftes Interoperabilitätsproblem dar. 

Sprachen dienen leider nicht nur der Kommunikation, sondern genauso der Ausgrenzung. 

Der Entscheidung, wer an der Sprachgemeinschaft teilhaben soll, kommt daher 

strategische Bedeutung zu. Der Bundesrat spricht sich explizit für eine Vernetzung innerhalb 

der Schweiz und darüber hinaus aus. Gelingt dies, wird sich dadurch allerdings 

der Wettbewerb zwischen den betroffenen Software- und Datenanbietern verschärfen. 

Nischen, die sich der eine oder andere geschaffen hat, gehen verloren. 

2.2 Verknüpfungen 

Die Abgrenzung, was als Geoinformation zu betrachten ist, fällt schwerer, als auf den 

ersten Blick zu erwarten wäre. Im weiteren Sinn fällt darunter alles mit einem geografischen 

Bezug, d.h. alles, was in Beziehung zu einer Koordinate oder einem Areal stand, 

steht oder stehen wird. Bei genauerem Hinsehen sind das potentiell alle Objekte, welche 

eine räumliche Ausdehnung besitzen. Denn was eine räumliche Ausdehnung hat, befindet 

sich zwangsweise zu einem bestimmten Zeitpunkt an einem bestimmten Ort: 

Golfclubs, Webcams, Mobilfunkantennen, Raucher, Rinder, Gletscherhahnenfüsse, Gasleitungen, 

Niederschläge. Aber damit nicht genug! Selbst alles was mit einem solchen 

Objekt in Beziehung steht, kann zum Teil von Geoinformationen werden: Windgeschwindigkeiten, 

Kindersterblichkeit, Sexpraktiken oder Vorlieben für Rotwein. 

Was bleibt noch übrig? – Nicht viel! Da liegt es nahe, einen zusätzlichen Begriff einzuführen: 

die Referenzdaten. Referenzdaten sind Geoinformationen, welche herangezogen 

werden können, um weitere Informationen darauf zu projizieren. Die Idee ist einleuchtend, 

den Begriff präzise zu fassen, jedoch schwierig. Er wurde in den Entwurf des neuen 

Geoinformationsgesetzes aufgenommen, und hat in den vorberatenden Gremien zu 

entsprechend heftigen Diskussionen geführt. Bei genauerem Hinsehen enthalten selbst 




einfachste Geoinformationen Angaben zu 'Fremdobjekten', beispielsweise Länder, Kantone 

oder Gemeinden, Nationalstrassen, Hauptstrassen und Nebenstrassen, Haus- und 

Parzellennummern. Und mit Sachinformationen kombinierte Geoinformationen - z.B. 

eine mit geologischen Informationen angereicherte Karte - kann von anderen als Grundlage 

für weitere Arbeiten genutzt werden - beispielsweise die Planung von Atom- 

Endlagern. 

Wir möchten ein - möglichst weltumspannendes Interoperabilitätsnetz für Geoinformationen 

schaffen. Dazu sind Normen zur Abbildung von räumlichen Informationen notwendig, 

jedoch, wie diese Beispiele verdeutlichen, nicht hinreichend. Zusätzlich brauchen 

wir auch Normen zur Abbildung der Angaben, welche mit ihnen verknüpft werden 

sollen. Interoperabilität im Bereich der Geoinformationen kann und darf daher 

nicht bei den Geoinformationen im engeren Sinn stehen bleiben, sonst ist sie nur von 

begrenztem Nutzen. 

2.3 Vergabe von Namen und Identifikatoren 

Was wären Landeskarten ohne Ortsbezeichnungen oder Stadtpläne ohne Strassennamen? 

Im Gegensatz zur allgemeinen Syntax und Semantik ist es oft nicht, oder nur bedingt 

möglich, derartige Namen oder Identifikatoren in Normen oder Standards festzuhalten, 

dennoch sind sie für die Interoperabilität unabdingbar. Nur wenn zwei Kommunikationspartner 

demselben Objekt gleich sagen, wissen sie, dass sie vom Gleichen 

sprechen. Neben Standardisierungsgremien, welche die notwendigen Normen erarbeiten, 

herausgeben und pflegen, brauchen wir Institutionen, welche Objekte, zu denen wir 

Informationen austauschen möchten, identifizieren und die Listen der vergebenen Identifikatoren 

aktuell und für alle Betroffenen elektronisch zugänglich publizieren. 

Idealerweise ist überschneidungsfrei definiert, wer für welche Namensräume zuständig 

ist. Diese aus technischer Sicht einfach aufzustellende Forderung enthält jedoch im Einzelfall 

einigen Zündstoff. So ist sich die Staatengemeinschaft nicht einig, ob Taiwan ein 

eigenständiger Staat ist oder lediglich eine – abtrünnige - Provinz Chinas. Die Anerkennung 

eines Staates ist ein politischer Akt, der im schlimmsten Fall zum Krieg führen 

kann. 

Vor dem Zeitalter der Vernetzung hat jede Anwendung notgedrungen die von ihr benötigten 

Daten selbst verwaltet und identifiziert. Möchte man sie austauschen, bringt das 

Probleme. In unterschiedlichsten Fachgebieten sind Arbeiten im Gang, diese anzugehen. 

Ein Beispiel sind die Bemühungen zur Einführung von Identifikatoren für juristische 

und natürliche Personen. 

Noch ist für viele Objekte nicht verbindlich geregelt, wer ihre Namen vergibt. Die Festlegung, 

wer wofür Namen vergibt, und das Akzeptieren dieser Definitionsgewalt durch 

die Kommunikationsgemeinschaft sind primär organisatorische und politische Entscheide, 

und diese laufen selten ohne Auseinandersetzungen und Machtkämpfe ab. 

Hier liegt noch einige Arbeit vor uns. 

3 Zweite Stossrichtung: Service excellence 

Interoperabilität ist kein Selbstzweck. Wir arbeiten daran, weil wir uns davon Vorteile 

versprechen. Diese Vorteile nutzen wir jedoch erst, wenn die Systeme in Realität zusammenarbeiten. 

Der Bundesrat hat zum Ziel, dass die Behörden die Möglichkeiten der 

Informationstechnologien nutzen, um der Privatwirtschaft, Bürgerinnen und Bürgern 




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 einzulesen 

und zu verarbeiten. 

Die aufgeführten Bedingungen mögen banal erscheinen. In der Praxis soweit zu kommen, 

dass z.B. die Pläne aller Grundstücke in der Schweiz tatsächlich elektronische erfasst 

sind und die Programme, welche sie verwalten, dazu in der Lage sind, sie elektronisch 

auszutauschen, ist alles andere als trivial. Dazu sind ist Überzeugungsarbeit bei 

Amtlichen Vermessern, Gemeindepräsidenten und Politikern notwendig und sind teilweise 

grössere Investitionen unumgänglich. Selbstverständlich arbeitet auch der Bund 

daran, seine Geoinformationsdaten einfach elektronisch zugänglich zu machen. 

4 Dritte Stossrichtung: Vernetzung 

Wir streben nach einer dichteren Vernetzung und besseren Interoperabilität. Systemtheoretisch 

betrachtet, modifizieren wir damit die Interaktionsregeln innerhalb eines dynamischen 

Systems. Dies muss unweigerlich Auswirkungen auf das Gesamtsystem haben: 

Es wird sich verändern. Ob wir wollen oder nicht, wir werden nicht darum herum 

kommen, auf die Veränderungen zu reagieren. Wer strategisch denkt, wird sich nicht 

damit zufrieden geben. Er wird die möglichen Veränderungen vorwegnehmen und, so 

gut es geht, gestaltend darauf einwirken wollen. 

Einige der Felder, in denen Veränderungen bevorstehen, sind die folgenden: 

� Tarifierung und Finanzierung 

� Authentizität und Urheberrecht 

� Datenschutz 

� Verantwortung der Datenanbieter 

4.1 Die Tarifierungs- und Finanzierungsmodelle sind zu 

überarbeiten. 

Noch vor nicht allzu langer Zeit hatten Geoinformationen die Form von Karten oder 

Plänen und konnten daher wie klassische Güter gehandelt werden. Werden sie in Form 

von digitalen Datensätzen weitergegeben, ist das nur noch bedingt möglich. Denn digitale 

Informationen können in Sekundenbruchteilen kopiert, transportiert, neu zusammengestellt, 

verändert oder mit neuen Informationen verknüpft werden. 

Die elektronische Weitergabe schafft jedoch ein neues Potential: Für Partner, Behörden 

und auch Unternehmen, wird es leichter, Daten einzukaufen und sie zu neuen Produkten 

zu verarbeiten, welche sie dann ihrerseits weiterverkaufen. 

So gesehen wird der Staat gewissermassen zum Rohstofflieferanten für die weiterverarbeitende 

Industrie. Für die nachgelagerten Informationsverarbeiter wird die Nutzung 

der Rohdaten umso interessanter, je kostengünstiger er sie erwerben kann. Ist ihr Preis 

zu hoch, werden seine eigenen Produkte zu teuer und dadurch weniger attraktiv. 




Der Bundesrat verfolgt die Strategie, seine Geodaten den Nutzern zu möglichst günstigen 

Preisen zur Verfügung zu stellen und so für die Wirtschaft förderliche Bedingungen 

zu schaffen. Er ist bemüht, die Kantone zu einer ähnlichen Strategie zu bewegen. Die 

gleichzeitig verfolgten Sparanstrengungen auf Seiten des Staates erschweren allerdings 

eine konsequente Umsetzung. 

4.2 Urheberrecht und Authentizität 

Daten, welche elektronisch weitergegeben werden, sieht man ohne spezielle Massnahmen 

den Urheber nicht mehr an, und sie können ohne sein Wissen und seine Zustimmung 

weiterbearbeitet, ja gar weiterverkauft werden. Ich kann ohne grössere Probleme 

Video-Dateien vom Internet herunterladen, mit einfachen Programmen bearbeiten, zusammenkopieren 

und das Resultat unter meinem Namen weiterverbreiten. Dies ist bei 

Geoinformationen nicht anders. 

Die einfache Kopierbarkeit stellt ganze Geschäftsbereiche vor bisher ungelöste Probleme. 

Eingespielte Verrechnungsmechanismen werden ausgehöhlt. Die Durchsetzung des 

Urheberrechts in der E-Welt ist ein noch nicht gelöstes Problem. Was tun wir z.B. wenn 

das Kartenwerk der Landestopographie plötzlich in die Hände einer Gruppe gerät, welche 

es auf einem Server in Übersee ins Internet stellt? 

Die einfache Kopierbarkeit und Modifizierbarkeit produziert noch ein weiteres Problem: 

Woher weiss ich, ob ich eine autorisierte Version der Daten in den Händen habe? Wie 

kann ich z.B. sicher sein, ob es sich beim Vermessungsplan, den ich am Bildschirm sehe, 

um eine autorisierte Kopie handelt? 

Zwar gibt es erste technologische Ansätze, die hier Abhilfe schaffen wollen wie z.B. die 

des Digital Rights Management (DRM), doch diese eignen sich für den uns interessierenden 

Kontext nur bedingt, da sie für Objekte konzipiert sind, welche als Einheit auf 

einem bestimmten Gerät abgespielt werden. 

Die gesetzlichen Grundlagen in diesem Bereich sind erst rudimentär vorhanden, die nötigen 

technischen Lösungen noch ungenügend. 

4.3 Datenschutz 

Die einfache Zugänglichkeit und Verknüpfbarkeit von Geoinformationen bringt auch 

neue Probleme mit sich. Eines besteht darin, dass es schwieriger wird, Informationen 

geheim zu halten. Angaben über dasselbe Gebiet aus verschiedenen Quellen können mit 

relativ geringem Aufwand verglichen und Unterschiede ausgewertet werden. So ist es 

möglich, Satellitenaufnahmen mit von den lokalen Behörden herausgegebenen Karten 

abzugleichen. Dabei können gerade Informationen, welche bewusst weggelassen wurden, 

Geheimdiensten interessante Aufschlüsse geben... 

Oder Personendaten können mit Geoinformationen verknüpft werden. Bringt man Angaben 

im Telefonbuch, Gebäudeadressen und Kartenmaterial zusammen, kann auf 

Knopfdruck sichtbar gemacht werden, wer wo wohnt. Trägt eine Person ein eingeschaltetes 

Handy bei sich, ist ihr Aufenthaltsort bekannt. Ohne grössere Probleme könnte auf 

einer Web-Seite eine Karte aufgeschaltet werden, welche anzeigt, wo wer sich gerade 

befindet. Derartige Informationen können in Katastrophensituationen helfen, Personen 

aufzufinden. Die Polizei kann sie nutzen, um Verbrecher zu fassen. Sie sind jedoch genauso 

interessant für Privatdetektive, Geheimdienste und Terroristen. 

Wenn wir die Interoperabilität verbessern, dürfen wir Massnahmen nicht vernachlässigen, 

welche sicherstellen, dass mit den Informationen kein Missbrauch getrieben wird. 




Gegenwärtig tun sich Staat und Politik schwer bei der Festlegung, wie mit elektronischen 

Daten umgegangen werden, was erlaubt und was verboten sein soll. Manche gehen 

beispielsweise soweit, die elektronische Version der Schweizerkarte zu schützenswerten 

Personendaten zu erklären, da sie potentiell mit Personendaten verknüpft werden 

können. 

4.4 Verantwortung der Datenanbieter 

Interoperabilität ist kein abstrakter Wunsch. Geodaten sind mehr und mehr elektronisch 

zugänglich, und der Markt beginnt die sich daraus ergebenden Möglichkeiten zu nutzen. 

Es ist absehbar, dass sich nach und nach ganze Wertschöpfungsketten aufbauen 

werden. Ob gewollt oder ungewollt werden die Abnehmer von Daten sich mit steigenden 

Kundenwünschen konfrontiert sehen. Diese betreffen einerseits die Stabilität des 

Angebots: Wer Daten eines anderen nutzt, um daraus eigene Produkte zu generieren, 

zählt darauf, dass diese auch in Zukunft verfügbar sein werden. Der volkswirtschaftliche 

Nutzen wird dann am grössten sein, wenn die Datenanbieter ihre Produkte präzise 

definieren und ihren Kunden garantieren können, dass ihr Angebot über längere Zeit 

zur Verfügung stehen wird. 

Andererseits wird nicht zu vermeiden sein, dass die Kunden auf den Geschmack kommen 

und neue Wünsche vorbringen werden, welche die Anbieter unter Druck setzen. 

So ist beispielsweise vorhersehbar, dass die Forderungen nach höherer Aktualität der 

Daten steigen werden. 

5 Schlusswort 

Ist Interoperabilität im Geoinformationsbereich Realität, entsteht logisch gesehen ein 

riesiger Datenpool, zu dem unterschiedliche Parteien ihren Beitrag leisten. Die Beteiligten, 

dazu gehört der Staat genauso wie betroffene private Unternehmen, müssen sich 

darauf einigen, wer welchen Beitrag zu diesem Datenpool leistet und wie damit umgegangen 

werden soll. Der Datenpool an sich stellt ein volkswirtschaftlich nicht zu unterschätzendes 

Kapital dar, dessen Wert mit der Menge der darin integrierten Informationen 

steigt. Wie dieses Kapital bewirtschaftet – oder nicht bewirtschaftet – wird, entscheidet 

darüber, wie gross die Wertschöpfung sein wird. 

[eGovS 99] Regieren in der Informationsgesellschaft. Die eGovernment-Strategie des Bundes. 

13. Februar 2002. 

http://www.isb.admin.ch/imperia/md/content/egoverment/egov_stra 

tegie/de/egov_strat_bv_dt.pdf 

[IEEE 90] Institute of Electrical and Electronics Engineers. IEEE Standard Computer 

Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, 

NY: 1990. 

[IGES 98] Strategie des Bundesrates für eine Informationsgesellschaft in der Schweiz vom 

18. Februar 1998. 

http://www.infosociety.ch/site/propos/references/details.asp?id_fiche 

=2867# 

[eGovCH 05] eGovCH - eGovernment Architektur Schweiz. Informatikstrategieorgan Bund 

(in Vorbereitung). 


François Golay, Prof. Dr. 

Laboratoire de Systèmes d'information géographique 

Ecole Polytechnique Fédérale de Lausanne 

CH-1015 Lausanne 

Tel : 

Fax : 

E-Mail : 

+41 21 693 57 81 

+41 21 693 57 90 

17 

Interoperabilität auf strategischer und 

administrativer Ebene 

François Golay, ETH Lausanne

1 Einleitung 

Man kann die Interoperabilität vor allem als eine technologische Antwort auf das Bedürfnis, 

Geoinformationssysteme zu öffnen, betrachten. Die OGIS spielt weltweit eine zentrale 

Rolle für die normierte technologische Entwicklung und die damit verbundenen 

Systemarchitekturen. Programmmodule, Webservices, etc – erlauben es, eine effiziente 

Implementierung zu gewährleisten. Schliesslich erlauben die innerhalb der ISO besonders 

unternommenen Normungsarbeiten, diese Konzepte dauerhaft zu verankern. 

Die vorangegangenen Präsentationen dieses Seminars haben bewiesen, dass das Datensharing 

nicht nur eine Übereinkunft über den Behälter – die Architekturen – aber 

auch über den Inhalt des Datenaustausches erfordert. Welche Daten sind bei einem Austausch 

beteiligt? Worauf gründen sich Information über gemeinsame Prozesse? Diese 

Fragen wurden von Morf und Dorfschmid in der Präsentation „Modellstandardisierung 

oder semantische Interoperabilität“ [Morf 2005] behandelt. Die Erarbeitung und Normalisierung 

von gemeinsamen Modellen stellen eine Antwort auf diese Fragen dar, genauso 

wie die Identifikation und die Definition von Referenzen, die interoperable Systeme 

verknüpfen. 

Die vorhergehenden Redner haben schliesslich betont, dass die Vielfalt der beteiligten 

Personen und Institutionen, die im Sharing von Informationen [Buser 2005] und Diensten 

einbezogen wurden, eine adäquate Organisation erfordert, die die institutionelle 

Verantwortung jedes einzelnen Beteiligten respektiert. 

Wir stellen in diesem Beitrag fest, dass es kein wirksames Datensharing ohne Anerkennung 

und Berücksichtigung der Aufgaben und Strategien von jeder der beteiligten Institutionen, 

insbesondere von Gemeinden, Kantonen und dem Bund, geben wird. Wir postulieren, 

dass die technische und semantische Interoperabilität nur im Rahmen einer guten, 

strategischen und administrativen Interoperabilität der beteiligten Institutionen verwirklicht 

werden kann. 

2 Föderalistische Organisation der Schweiz und Aufgaben 

der beteiligten Institutionen 

Im Rahmen der Vorstudie zum Projekt e-geo.ch: Organisatorische und technische Aspekte 

[Moreni & al. 2003] wurde eine Verschachtelung der Entscheidungsebenen auf dem 

Staatsgebiet am Beispiel der Schweiz vorgeschlagen (Figur 1). Man kann unterschiedliche 

Positionierungen der verschiedenen staatlichen, kantonalen und kommunalen Beteiligten 

feststellen. 

Die Arbeitsbereiche der Akteure der verschiedenen Entscheidungsebenen können sich 

jedoch, ihren Verantwortlichkeiten im Bodennutzungsmanagement entsprechend, erheblich 

unterscheiden. 




Somit: 

NATIONAL 

REGIONAL 

LOKAL 

Etat 

Stadt 

Kanton 

Bund 

Kanton Kanton 

Gem. Gem. Stadt Gem. 

Figur 1 : Verschachtelungen der Entscheidungsebenen auf dem Staatsgebiet 

� Sind auf lokaler (kommunaler) Ebene die Grund- und Bodenangelegenheiten 

vorherrschend. Es handelt sich zuallererst darum, die rechtliche und technische 

Grund- und Bodenverordnung verlässlich zu dokumentieren und als Bezugseinheit 

ist die Parzelle ausschlaggebend. Die Lokalisierung von technischen Infrastrukturen, 

die Verwaltung des bebauten Kulturgutes, usw., sind typische Beispiele 

für diese Ebene. 

� Auf regionaler (kantonaler) Ebene ist die räumliche Information vor allem ein 

Werkzeug für die Raumplanung. Die Erwartungen bestehen hauptsächlich im 

Erhalt von korrekt aktualisierten, und zusammenhängenden Informationen zur 

Bodennutzung und der Umwelt. Öffentliche Gelände, verseuchte Gebiete, Bodennutzungsstatistiken, 

Räume, die durch natürliche Gefahren bedroht werden, 

sind einige Beispiele für Informationen auf diesem Niveau. 

� Auf nationaler (eidgenössischer) Ebene geht es vor allem darum, die Konzeption 

und Planung von kohärenten Strategien durch zuständige Organisationen und 

Einrichtungen möglich zu machen. Ein globaler und homogener Zugang zu den 

Informationen, ohne „Grenzen zwischen den Regionen, stellt eine nötige Vorbedingung 

dar. 


Einrichtungen öffentlichen Rechtes, z. B. Elektrizitätswerke usw.) 

Privatgesellschaften



3 Datenintegration zwischen verschiedenen Entscheidungsebenen 

Die Primärdaten, die für die Erfüllung der Aufgaben dieser verschiedenen strategischen 

Niveaus notwendig sind, sind jedoch teilweise dieselben: Indikatoren, welche die Landschaftsnutzung 

im Kantonsmassstab angeben, können von den kommunalen Rahmennutzungsplänen 

abgeleitet werden. Bodennutzungsstatistiken auf nationaler Ebene 

können anhand lokaler Bodennutzungsangaben erstellt werden, usw. Aus Effizienzgründen 

sollen die entsprechenden Daten nur ein einziges Mal erstellt und verwaltet werden, 

und zwar auf der am besten geeigneten Ebene (Dieses Prinzip wird im [INSPIRE 2002]- 

Bericht für geographische Infrastrukturen und Daten beschrieben) 

Die oben aufgeführten, speziellen Bedürfnisse jeder Entscheidungsebene müssen unabhängig 

von der Einrichtung, die mit deren Realisierung beauftragt ist, bei der Datenerfassung 

und Verteilung berücksichtigt werden. Einige kürzlich aufgetretene Schwierigkeiten 

zeugen von den Schwierigkeiten, die auf diese Wechselbeziehung der Bedürfnisse 

zurückzuführen sind 

� 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 Interesse 

daran eine klar dokumentierte, systematische Qualität ihrer Daten zu fördern. 

Diese Daten sind folglich nicht brauchbar für Verwaltungsaufgaben auf lokaler 

Ebene. 

� Einige Kantone widersetzen sich der Harmonisierung von Datenstrukturen, welche 

vom Bund verlangt wird, um einen nahtlosen Datenzugang für die ganze 

Schweiz zu ermöglichen. 

Solche Probleme existieren auch zwischen öffentlichen Einrichtungen und Privaten Unternehmen. 

Wieso war es z.B. notwendig, das Strassennetz für die Bedürfnisse der automobilen 

Navigation nochmals zu erfassen? 

4 Die Interoperabilität auf strategischer und administrativer 

Ebene – eine entwicklungsbedürftige Ressource ! 

Die Wiederverwendung von Daten zwischen verschiedenen strategischen Ebenen setzt 

jedoch voraus, dass jeder Beteiligte einer Entscheidungsebene die Bedürfnisse der anderen 

Entscheidungsebenen kennt (und anerkennt!), und dass er bereit ist, die Datenerfassung, 

für die er zuständig ist, gemäss der Bedürfnisse sämtlicher anderer Partner durchzuführen. 

Dieser Anspruch betrifft nicht die technischen und organisatorischen Dimensionen der 

Interoperabilität, sondern eine Art der Anerkennungsteilung und der Teilung von Zielsetzungen 

und Aufgaben. Es ist schwieriger die Interoperabilität auf strategischer und 

administrativer Ebene durchzuführen, als auf der technischen Ebene, jedoch stellt die 

Interoperabilität auf strategischer und administrativer Ebene eine Anforderung an 

die technische, semantische und organisatorische Ebene. Diese Anforderung wird im 

[INSPIRE 2002] – Bericht beschrieben: administrative interoperability should precede geospatial 

interoperability. 




Die Berücksichtigung des Grundsatzes der strategischen und administrativen Interoperabilität 

müsste auch die Annahme und die Umsetzung durch alle Beteiligten erleichtern 

und eine gute Handhabung der Interoperabilität ermöglichen: 

� 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 wesentlichen 

Bedürfnissen sämtlicher Partner entspricht, müssen die Normen auf dem 

höchsten Entscheidungsniveau definiert werden (SNV/ASN – Normen für die 

gesamte Schweiz). 

Bibliographie 

Buser, R., 2005, Conséquences organisationnelles de l’interopérabilité, Actes de la journée 

d’étude « Interopérabilité pour l’utilisation généralisée de la géoinformation », mars 

2005, A. Carosio éd., ETH Zürich. 

INSPIRE, 2002, INSPIRE Architecture and Standards Position Paper, JRC-Institute for Environment 

and Sustainability, Ispra. 

Moreni, C. & al., 2003, Etude préliminaire au projet e-geo.ch: aspects organisationnels et 

techniques, Rapport sur mandat de la COSIG, EPFL-LASIG et ETHZ-Geoinformation. 

Morf, A. & Dorfschmied, J., 2005, Modèles standardizes ou interopérabilité sémantique, 

Actes de la journée d’étude « Interopérabilité pour l’utilisation généralisée de la géoinformation 

», mars 2005, A. Carosio éd., ETH Zürich. 


Ivo A. Leiss, Dr. 

Zollikerstr. 65 

CH-8702 Zollikon 

Tel : 

Fax : 

E-Mail : 

+41 44 395 12 80 

+41 44 395 12 34 

18 

Interoperabilität in der Praxis 

Erfahrungen aus Projekten im In- und 

Ausland 

Ivo A. Leiss, Ernst Basler + Partner AG

1 Einleitung 

Die Interoperabilität bei der Nutzung von Geoinformation ist bei GIS-Projekten im Planungs- 

und Umweltbereich ein allgegenwärtiges Thema. In der Praxis trifft man auf 

verschiedene Aspekte der Interoperabilität: 

� beim Austausch von Geodaten (z.B. mit Auftraggebern oder Partnerfirmen) 

� beim Austausch von Applikationen und Systemen (z.B. Businessapplikationen 

ohne geografischen Bezug) 

� beim Austausch von Prozessen (z.B. Service zur Geocodierung von Adressen) 

Der vorliegende Beitrag soll die Interoperabilität von Geoinformation am Beispiel von 

ausgewählten Projekten der Firma Ernst Basler + Partner AG im In- und Ausland beleuchten. 

Typische Interoperabilitätsprobleme und deren Lösungsansätze werden aufgezeigt. 

Die Bedeutung der Interoperabilität für die Zukunft wird bewertet. 

2 Beispielprojekte 

2.1 Nationale Projekte: Drei kantonale Beispiele 

Die Interoperabilität bei der Nutzung von Geoinformation in den Kantonen soll anhand 

drei verschiedener GIS-Projekte beleuchtet werden (Tab. 1). 

Projektname 

Auftraggeber Aufgaben Projektpartner 

(Laufzeit) 

Strassenlärm 

Zürich 

(2000 – 2005) 

Gefahrenhinweiskarte 

Hochwasser 

Luzern 

(2003 – 2005) 

SPATZ 

Mapserver 

Graubünden 

(2004 – 2005) 

Baudirektion des 

Kantons Zürich, 

Fachstelle Lärmschutz 

Bau-, Umwelt- und 

Wirtschaftsdepartemen 

t des Kantons Luzern, 

Dienststelle Verkehr 

und Infrastruktur 

Archäologischer 

Dienst, Kanton 

Graubünden 

Portierung des 

Strassenlärmkatasters 

(Emissionen), GIS- 

Analyse 

lärmbetroffener 

Gebäude 

(Immissionen) 

Erstellen einer 

Gefahrenhinweiskarte 

für den 

Naturgefahrenprozess 

Hochwasser im Kanton 

Luzern, Erstellen eines 

Ereigniskatasters 

Darstellung von 

archäologischen 

Informationen 

(SPATZ) in einem 

Intranet-Kartendienst, 

Interaktion zwischen 

dem Archäologischen 

Informationssystem 

und dem Kartendienst 

(z.B. Editieren von 

Punkten) 

Norsonic Brechbühl 

AG 

F. Preisig AG 

GIS-Zentrum Kt. 

Zürich 

Kost+Partner AG 

ITECO 

Geoinformation und 

Vermessung Kt. 

Luzern 

GIS 

Kompetenzzentrum Kt. 

Graubünden 

GWZ Informatik 

Tab. 1 : Übersicht über drei kantonale Projekte. Sie dienen als Grundlage für die nachfolgenden 

Überlegungen. 



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 aufzubauen. 

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 Koordination 

des Projekts und die Realisierung des Informationssystems verantwortlich. 

Sie wird unterstützt durch die Firma Hydrotec aus Aachen (Deutschland) sowie durch 

zahlreiche Subunternehmer im Bereich der Datenerfassung. Weitere Informationen sind 

unter http://www.timisflood.net erhältlich. 

3 Aspekte der Interoperabilität 

3.1 Austausch von Geodaten 

Der Austausch der Geodaten bildet im Rahmen der Beispielprojekte die weitaus grösste 

Herausforderung im Bereich der Interoperabilität. Zwischen folgenden Beteiligten müssen 

Daten ausgetauscht werden (Abbildung 1): 

� 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 Projektpartner 

hat, welche ebenfalls mit ESRI arbeiten. 

Nur rund 20% aller Daten, welche uns von den Auftraggebern zur Verfügung gestellt 

werden, beinhalten nutzbare Metainformationen. Aber auch hier hat sich noch kein interkantonaler, 

geschweige denn ein internationaler Standard durchgesetzt. 

3.2 Austausch von Applikationen und Systemen 

Die gemeinsame Nutzung von Applikationen hat in den letzten Jahren an Bedeutung 

gewonnen. Grund dafür ist die generell zunehmende Vernetzung von Systemen. 

In den Beispielprojekten kommt dieser Aspekt in den webbasierten Projekten "SPATZ 

Mapserver" und "TIMIS flood" zum Tragen. 

Beim archäologischen Informationssystem SPATZ handelt es sich um eine Oracle- 

Datenbank mit Benutzerschnittstelle für die Datenbewirtschaftung. Der lesende Zugriff 

auf SPATZ erfolgt via OGR Virtual Format, einem Open Source Treiber, welcher einfache 

Geoobjekte aus einer ODBC-Datenbank anhand einer XML-Konfigurationsdatei 

liest. Der schreibende Zugriff auf die Oracle-Datenbank wird durch eine Schnittstelle 

der Firma GWZ Informatik (Vertreiber von SPATZ) sichergestellt. Die Parameter werden 

dabei mittels ASCII-Datei übergeben. 

Da es sich beim SPATZ Mapserver um eine Intranet-Anwendung handelt, kommen zur 

Zeit keine OGC-kompatiblen Austauschformate (WFS, WMS) zum Einsatz. 

Im Projekt TIMIS flood werden die geografischen Informationsdienste zur Zeit basierend 

auf WFS und WMS konzipiert. Für das Internet-Portal (auf Basis von ESRI ArcIMS) 

ist dies mittlerweile eine Standardfunktionalität. Zum heutigen Zeitpunkt ist jedoch 

noch nicht sichergestellt, dass alle nationalen Server diese OGC-Formate unterstützen. 

Wir gehen aber davon aus, dass sich diese OGC-Formate in den kommenden Jahren 

durchsetzen werden. 

3.3 Austausch von Prozessen 

Die Interoperabilität von Prozessen ist zum heutigen Zeitpunkt noch am wenigsten 

fortgeschritten. Im Zusammenhang mit Web-Services (z.B. für die Geocodierung von 

Adressen) wird dieser Aspekt in Zukunft aber immer wichtiger. 

Der Austausch von Prozessen ist unter den Beispielprojekten einzig im Projekt TIMIS 

flood vorgesehen. Ab 2008 soll es möglich sein, die Hochwasservorhersage für einen 




Standort an der deutschen Mosel (Rheinland-Pfalz) aus der Kombination verschiedener 

Prozesse zu generieren: aus der Wettervorhersage des deutschen Wetterdienstes, aus 

den aktuellen Pegelmessungen im Einzugsgebiet (Frankreich, Luxemburg und Deutschland), 

aus einer Abflussvorhersage aus Baden-Württemberg und aus einer hydraulischen 

Modellierung für den entsprechenden Standort in Rheinland-Pfalz. Als Resultat 

erhält der Benutzer die Hochwasservorhersage in Karten- und Textform (ähnlich wie 

bei der Wettervorhersage). Die gleichen Prozesse können auch für beliebige Orte in Luxemburg 

beansprucht werden. 

Noch sind nicht alle Fragen gelöst. Die grössten Hürden liegen jedoch weniger in der 

technischen Realisierbarkeit, sondern viel eher in der Akzeptanz der verschiedenen 

(ausländischen) Prozesse und Verfahren. Für eine erfolgreiche Umsetzung sind hier 

weniger Standards, sondern eher eine gute Kommunikation innerhalb und ausserhalb 

des Projekts notwendig. 

3.4 Interoperabilität und Projektplanung 

Die oben erwähnten Aspekte kommen zum Tragen, wenn ein Projekt ausgelöst ist. Erfahrungen 

in der Praxis haben aber gezeigt, dass der Kosten-, Kommunikations- und 

Zeitaufwand für die Interoperabilität im Allgemeinen unterschätzt wird. Bei der Planung 

eines Projekts sind folgende Informationen häufig nicht oder nur unzureichend 

vorhanden: 

� Qualität der Geodaten oder der Systeme 

Neben der grundsätzlich zu prüfenden Qualität der Datengrundlage kann es alleine 

aufgrund der genutzten Formate zu Qualitätsproblemen kommen: Ein 

CAD-Format setzt andere Integritätsregeln auf einen geometrischen Datensatz 

als ein GIS-Format. Selbst innerhalb verschiedener GIS-Formate bestehen unterschiedlich 

strenge Anforderungen an den Aufbau und die Konsistenz der Daten. 

� Erstellung oder Anpassung notwendiger Schnittstellen 

Während der Bearbeitung eines Projektes kann es passieren, dass aus rein technischen 

Gründen neue Schnittstellen notwendig werden oder geplante Schnittstellen 

angepasst werden müssen. 

� 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 Interoperabilität 

vor allem der Austausch von Daten im Vordergrund. 

� Beim Datenaustausch gelangen kaum Standards zum Einsatz. Am häufigsten 

werden die Formate ESRI Shape und Tiff verwendet. Dies hängt aber in erster 

Linie von den Möglichkeiten (der GIS-Software) der Parteien ab. INTERLIS wird 

zur Zeit (zu) wenig eingesetzt. 




� XML als Austauschformat ist im Vormarsch, doch wird die Interoperabilität 

durch die unzähligen Variationen (WFS, GML, ESRI XML, INTERLIS 2, etc.) reduziert. 

� Die OGC-Formate WFS und WMS werden sich etablieren und zumindest bei internationalen 

Projekten zum Standard werden. Andere Formate werden vom 

Markt verschwinden oder ein Nischendasein führen. 

Insgesamt ist festzuhalten: Die Anzahl Projekte, bei denen Daten oder Systeme zusammengeführt 

werden müssen, steigt stetig. Aus diesem Grund wird die Interoperabilität 

von Applikationen und Prozessen in den kommenden Jahren zunehmen. Ob sich in Zukunft 

Standards einstellen oder nicht: wir als Dienstleister im Bereich der Geoinformatik 

müssen uns ohnehin anpassen; an die Bedürfnisse der Auftraggeber und Projektpartner 

oder an die vorgegebenen Standards. 

Abkürzungen und Begriffe 

Abkürzung/Begriff 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 Austausch 

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 anwendungsunabhängige 

Datenbankzugriffe 

OGC Open Geospatial Consortium 

OGR Softwarebibliothek für den Zugriff auf verschiedene GIS Vektorformate 

Oracle 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 


Kaul Beratungen GmbH 

Christian Kaul 

Flaachtalstrasse 8 

CH-8412 Hünikon 

Tel : 

Fax : 

E-Mail : 

+41 52 343 79 01 

+41 52 343 79 02 

19 


Christian Kaul, Kaul Beratungen GmbH

Perspektiven für die Geomatik-Berufe … 

… oder was es braucht, damit das zarte Pflänzchen „Interoperabilität“ zum Blühen 

kommt. 

1 Einleitung 

Die zentrale Aussage gleich vorweg: Die neuen technischen Möglichkeiten der Interoperabilität 

alleine sichern der Geomatik-Branche noch keine neuen Märkte! 

Interoperabilität ist auch kein technisches Projekt, das nach Abschluss eine Firma interoperabel 

macht. Interoperabilität muss viel mehr zu einer grundlegenden Denkhaltung 

in allen Geomatik-Berufen werden. Damit können auch die rasanten Entwicklungen der 

Zukunft in diesem Bereich proaktiv genutzt werden. 

Damit die Chancen und Möglichkeiten der Interoperabilität neue Perspektiven für die 

Geomatik-Berufe eröffnen werden, ist das Zusammenspiel von verschiedenen Ebenen 

und Facetten notwendig. Die technischen Herausforderungen sind dabei nur ein Blatt 

einer weitgefächerten Blüte. 

Systemtechnisches 

denken 

und 

handeln 

Technische 

Fähigkeiten 

Visionär 

kooperativ 

Generalist 

Permanente 

berufliche 

Weiterentwicklung 

Arbeit in 

Multidisziplinären 

Projekten 




2 In Zentrum - der Unternehmer 

Im Zentrum steht die unternehmerische Persönlichkeit in Privatwirtschaft und Verwaltung. 

Das Thema Interoperabilität kann nicht passiv-reaktiv angegangen werden. Es 

braucht den visionären Geist, der eine - vielleicht nur vage - Vorstellung davon hat, wohin 

die Reise gehen könnten. Ohne Visionen ist jede Organisation in dieser schnelllebigen 

Zeit früher oder später dem Untergang geweiht. 

Inter-operability braucht Inter-working. Die Fähigkeit und der Wille zur Kooperation 

mit anderen Organisationen muss von den Chefs vorgelebt und gefördert werden. Dabei 

darf ruhig anerkannt werden, dass andere auch etwas können – denn das ist die Basis 

der gemeinsamen künftigen Erfolge. 

Mit der Interoperabilität der Geo-Daten geht eine massive Ausweitung der Daten- 

Inhalte einher, mit der eine Organisation konfrontiert wird. Damit rückt die alte Fähigkeit 

des Generalisten wieder mehr ins Zentrum des Interesses. Nach Prof. Dr. Hans Ulrich 

ist ein Generalist: "... jemand, der auch in seinem eigenen Wirkungsbereich lange 

nicht alles weiss, der aber das Ganze versteht." Als integrierende Ergänzung der Spezialisten 

in den Unternehmen muss sich der Unternehmer stärker der Übersicht, dem Ganzen 

widmen. 

3 Die Blütenblätter – das Unternehmen 

Für die Mitarbeiter eines Unternehmens sind folgende vier Bereiche im Hinblick auf interoperables 

Arbeiten von Bedeutung: 

Technische Fähigkeiten 

Das Unternehmen muss die notwendigen Techniken für interoperables Arbeiten beherrschen. 

Dabei wird sich das Schwergewicht noch mehr auf die Informatik verlagern. Eine 

Firma muss in der Lage sein, die sich immer schneller ändernden Bedürfnisse der Kunden 

zufrieden zu stellen und gleichzeitig die rasante technische Entwicklung aktiv zu 

nutzen. 

Inhaltlich werden die Web-Technologien sehr stark ins Zentrum des Interesses rücken. 

Die datentechnischen Fähigkeiten müssen aber parallel dazu noch weiter ausgebaut 

werden. 

Arbeiten in multidisziplinären Projekten 

Die Interoperabilität bietet die Chance in themenübergreifenden Projekten effizient zusammenzuarbeiten. 

Dies erfordert eine offene und interessierte Haltung aller Beteiligter 

bezüglich anderer Themen und anderen Teams und ein Bewusstsein, dass dies nicht 

von selber erfolgreich geschieht, sondern gelernt und geübt werden kann und muss. 

Systemtechnisches Denken und Handeln 

Die Anforderungen an die Produkte der Geomatik-Branche werden auch weiterhin stetig 

steigen. Die einfachen, klaren Antworten werden immer seltener werden. In einem 

solchen Umfeld haben sich seit Jahren die Grundsätze und Methoden der Systemtechnik 

bewährt. Diese Art des Denkens und Handelns kann nicht einigen Spezialisten überlassen 

werden, denn sie bildet die Grundlage für ein erfolgreiches interoperables Arbeiten 

aller Geomatik-Berufe. 

Permanente berufliche Weiterentwicklung 

Die oben beschriebenen Anforderungen an die Mitarbeiter können nicht einfach neben 

dem Alltagsgeschehen entwickelt werden. Es braucht eine aktive, gezielte und vor allem 




permanente Weiterentwicklung aller Mitarbeiter. Mit kurzfristigen Feuerwehrübungen 

können die notwendigen Fähigkeiten in einer Firma nicht nachhaltig erarbeitet und aufrechterhalten 

werden. 

4 Die Kelchblätter – eine nachhaltige Basis 

Die UNO definiert nachhaltige Entwicklung als: "... eine Entwicklung, die die Bedürfnisse 

der Gegenwart befriedigt, ohne zu riskieren, dass künftige Generationen ihre eigenen 

Bedürfnisse nicht befriedigen können." Diese Definition ist weitherum anerkannt und 

bildet die Basis der so genannten "Agenda21" der UNO. 

Im Zusammenhang mit nachhaltiger Entwicklung werden oft die drei Zieldimensionen 

Gesellschaft, Wirtschaft und Umwelt beleuchtet. 

Gesellschaft 

Durch ihren Hauptauftraggeber, die Öffentliche Hand, haben die Dienstleistungen der 

Geomatik-Branche traditionell einen grossen Bezug zur Gesellschaft. Aktivitäten im Bereich 

der Interoperabilität sind zum Teil sehr stark vom Rahmen der Gesellschaft geprägt. 

Eine sehr grosse Bedeutung muss in diesem Zusammenhang dem Rechtssystem 

beigemessen werden. Die rechtlichen Rahmenbedingungen sind immer höher einzustufen 

als die technischen. Deshalb bilden gute rechtliche Kenntnisse und eine sorgfältige 

Analyse dieser Sachverhalte die Grundlage erfolgreicher Projekte und Produkte. 

Einen weiteren massgebenden Faktor bildet die Normierung. Wie an dieser Tagung 

aufgezeigt, sind zur Zeit sehr grosse Bestrebungen auf Stufe ISO und CEN im Gange. 

Hier gilt es, aktiv die langjährige praktische Erfahrung der Schweiz in diese Normierungsarbeiten 

einzubringen. 

Wirtschaft 

Das heisst nichts anderes, als dass sich auch die Aktivitäten im Bereich der Interoperabilität 

schlussendlich positiv aufrechnen lassen. Das wird nur gelingen, wenn den Aufwändungen 

auch ein entsprechend nachgefragter Nutzen gegenübersteht. Demzufolge 

definiert der Nutzer und Endkunde die Rahmenbedingungen für die Wirtschaftlichkeit 

und nicht die eigenen Vorstellungen der Branchen-Insider. Das bedingt jedoch viel bessere 

und ehrlichere Kenntnis der echten Bedürfnisse der Kunden. 

Diese Überlegungen gelten auch für die staatlich finanzierten Aktivitäten. Ein 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 entsprechender 

Nutzen gegenüberstehen. 

Umwelt 

Diese Zieldimension beinhaltet den Umgang mit Ressourcen in einem umfassenden 

Sinne, also die Aufforderung, die Aktivitäten im Bereich der Interoperabilität mit einem 

Minimum an Aufwand von Energie, Material, Arbeit und Geld umzusetzen. Im Bereich 

der Interoperabilität kann dies in erster Linie mit einer exzellenten Nachführbarkeit der 

Lösungen und einem systemneutralen Investitionsschutz für die Daten erreicht werden. 

Auch die genialste technische Lösung wird nie nachhaltig sein, wenn sie alle zwei Jahre 

neu aufgesetzt werden muss. Der gesicherte Investitionsschutz und die konsequente 

Nachführung der Daten sind eine grosse Verantwortung der Branche gegenüber kommenden 

Generationen. 




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 bearbeiten 

� 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 (Public-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 Mitarbeitern, 

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 Industrielle 

Organisation, Zürich, ISBN 3-85743-998-X 

- Zur Agenda 21: http://www.are.admin.ch/are/de/na 


Jürg Kaufmann, dipl. Ing. ETH 

KAUFMANN CONSULTING/FIG 

Hauffeld 109 

CH-8455 Rüdlingen 

Tel : 

Fax : 

E-Mail : 

+41 1 867 14 36 

+41 1 867 34 89 

20 

Tarifierung, Kostenfragen 

Jürg Kaufmann, KAUFMANN Consulting / FIG

1 Einleitung 

Die folgenden Überlegungen sollen aufzeigen, wie sich die Interoperabilität auf die Kostengestaltung 

und die Festlegung von Tarifen auswirken. 

Um diese Fragen zu klären seien zunächst einmal einige Begriffe definiert: 

Interoperabilität: 

Zusammenarbeit in einem offenen System (gemäß dem Client/Server--Modell). Unabhängig von 

der verwendeten Hardware, den eingesetzten Betriebssystemen, der verwendeten Netzwerktechnologie 

und der Realisierung einer Anwendung kann eine Zusammenarbeit zwischen diesen 

Anwendungen erfolgen. 

Tarif: 

1. verbindliches Verzeichnis der Preis- bzw. Gebührensätze für bestimmte Lieferungen, Leistungen, 

Steuern u. a. 

2. durch Vertrag od. Verordnung festgelegte Höhe von Preisen, Löhnen, Gehältern u. a. 

Tarifieren: 

die Höhe einer Leistung durch Tarif bestimmen. 

Der Begriff der Kosten darf wohl als bekannt vorausgesetzt werden. 

Um die Folgen der Interoperabilität abschätzen zu können wird zunächst der traditionelle 

Ablauf der Leistungserbringung dargestellt. Der Vergleich mit dem Ablauf bei 

Anwendung der Interoperabilität kann Hinweise auf die Veränderung der Kostenfaktoren 

geben. 

Die Auswirkungen der Interoperabilität auf die Kostenstruktur sollen aufgezeigt werden. 

In einem weiteren Kapitel werden die Überlegungen zur Tarifierung dargestellt. 

Schliesslich werden die Resultate der Groupe de Réflexion "Datenabgabe und Gebühren", 

sowie die Arbeiten der KOGIS im Bereich Tarifierung und in Bezug auf die Auswirkungen 

der Interoperabilität beleuchtet. 

Einige Schlussfolgerungen sollen das zukünftige Verhalten der Informationsgesellschaft 

skizzieren. 

2 Auswirkungen der Interoperabilität auf den Ablauf der 

Leistungserbringung 

Das uns allen bestens bekannte Schema für den Bezug von Leistungen ist in Abbildung 1 

dargestellt. 

Bestellung 

Empfangen der Lieferung 

Bezahlung 

Abb. 1 : Schema für den Bezug von Leistungen 

Anfrage bei Logistik 

Bereitstellung der Lieferung 

Inkasso 

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 




verkürzten Abläufen, beispielsweise bei der Selbstbedienung oder zu effizienteren Zahlungsverfahren, 

wie bei der Verwendung von Strichcodes. Auch das e-shopping läuft 

nach demselben Schema ab. Die Verkäuferin wird durch ein Terminal und ihre Beratung 

durch Text und Bilder ersetzt. Nur für das Lächeln und die Ausstrahlung der Verkäuferin 

oder der Serviertochter kann diese Art der Leistungserbringung nicht überzeugend 

ersetzen. 

Bei Anwendung der Interoperabilität wird genau dasselbe Schema durchlaufen. Aber 

alle menschlichen Teilnehmer an der Leistungserbringung sind durch Maschinen ersetzt. 

Angesichts der hohen Lohnkosten in der Schweiz, muss also die Leistungserbringung 

grundsätzlich günstiger werden. 

Da die Leistungen durch Automaten erbracht werden, ist es notwendig, die Abrechnung 

automatisch zu erfassen 

3 Auswirkungen der Interoperabilität auf die Kosten 

Die anwendbaren Kostenkomponenten für die Leistungserbringung sind normalerweise: 

� Die Kosten für die Bestellungsaufnahme 

� Die Kosten für die Bestellungsübermittlung 

� Die Kosten der Bereitstellung der Lieferung 

� Die Kosten für die Lieferung 

� Die Kosten für die Rechnungsstellung und das Inkasso. 

Im Normalfall werden diese Kosten als Gemeinkostenanteil auf den Preis der gelieferten 

Ware oder Dienstleistung geschlagen. Gegenüber dem Kunden wird diese Kostenkomponente 

nicht offen gelegt. Gemeinkostenanteile können ermittelt werden, wenn die Beteiligten 

an einem Prozess und ihre spezifischen Kosten bekannt sind. 

Branchenübliche Festlegungen der Gemeinkostenzuschläge sind im traditionellen System 

die Regel. 

Bei einer interoperablen Arbeitsweise ist aber nicht mehr à priori bekannt, welche Maschinen/Systeme/Automaten 

an der Ausführung einer Lieferung beteiligt sind. Die bestellte 

Ware wird dort abgeholt oder eingesehen, wo sie verfügbar ist. 

Unabhängig davon, wie man einen Preis für die Ware oder die Dienstleistung festsetzt, 

muss eine Lösung gefunden werden, welche ohne Gemeinkostenzuschlag auskommt. 

Man muss die Kosten für die Leistungserbringung gesondert betrachten. 

Da die Leistungserbringung durch Automaten erfolgt, muss die Erfassung der preisbildenden 

Faktoren automatisch erfolgen können, weil es im Umfeld der Interoperabilität 

unmöglich wird, die Wege zu verfolgen und die nötigen Abrechnungsdaten manuell zu 

erfassen. 

Es ist zudem wenig sinnvoll jede Komponente, die bei der Leistungserbringung zum 

Zuge kommt, individuell und mit eigenen Kostensätzen in ein Abrechnungssystem einzubringen, 

da die Preisgestaltung der einzelnen beteiligten Dienstleister wohl niemals 

über einen Leist geschlagen werden können. 

Deshalb ist es im Zeitalter der Interoperabilität zwingend, mit vereinbarten Tarifen zu 

arbeiten. 




4 Auswirkungen der Interoperabilität auf die Tarifierung 

Eine vernünftige Tarifierung der Leistungserbringung ist also eine Notwendigkeit, damit 

die Vorteile der Interoperabilität schliesslich voll zum Tragen kommen. 

Die Anforderungen an die Tarifierung wurden teilweise bereits bei den Kosten genannt: 

� Die preisbildenden Faktoren müssen automatisch ermittelt, festgehalten und abgerechnet 

werden können. 

� Die festgelegten Tarife müssen mit dem Aufwand für die Erbringung der Leistung 

in einem sinnvollen Verhältnis stehen. 

� Die Tarife müssen für den Besteller nachvollziehbar sein. 

Über die Art der Preisgestaltung sind Lösungsansätze vorhanden, aber es hat sich bisher 

keine einheitliche Lösung herauskristallisiert. 

5 Resultate bisheriger Tarifierungsanstrengungen 

In der Schweiz existieren zwei Arbeiten, die sich mit der Tarifierung beschäftigen. Einerseits 

hat eine von der V+D1 eingesetzte, paritätische Groupe de Réflexion sich mit den 

Problemen der Datenabgabe und Gebühren befasst. Eine weitere Expertenarbeit über 

Tarifierungsprobleme wurde im Auftrag von KOGIS erstellt. Die Arbeiten dieser Teams 

wurden auf höchster Stufe koordiniert. 

Beide Arbeiten kommen zum Schluss, dass für Geodaten eine Strategie der marginal cost 

anzuwenden sei. Marginal cost umfassen ausschliesslich die Bearbeitungs- und Lieferkosten. 

Als Begründung für diese Empfehlung wird angeführt, dass Geodaten in der 

Regel in Erfüllung eines gesetzlichen Auftrags beschafft werden. Dies trifft in der Tat 

auf die meisten Geodaten zu. Im Entwurf des Geoinformationsgesetzes wird denn auch 

von Geobasisdaten gesprochen, die von nationalem, kantonalem oder kommunalem Interesse 

liegen, je nachdem, welche Stufe den gesetzlichen Auftrag beschlossen hat. Damit 

sind die Investitionskosten, d.h. die Kosten für die Datenbeschaffung von der Allgemeinheit 

zu übernehmen. Um aber einen möglichst grossen Kostenrückfluss zu generieren, 

sollen die Daten möglichst günstig an die Interessenten abgegeben werden, damit 

deren Steuern möglichst hoch ausfallen, weil die Gewinne nicht durch Beschaffungskosten 

geschmälert und möglichst gross werden, wenn aus diesen Daten Produkte 

mit Mehrwert generiert werden können. 

Im Rahmen der Arbeiten der Groupe de Réflexion wurde nachgewiesen, dass die Investitionskostenbeiträge, 

wie sie durch den Bericht Buschor im Rahmen der Arbeiten zur Reform 

der Amtlichen Vermessung vorgeschlagen und in der Mehrzahl der Kantone eingeführt 

wurden, keinen signifikanten Beitrag zur Abschreibung der getätigten Investition 

in die Amtliche Vermessung zu liefern vermag. Bei hohen Preisen wird die Anzahl 

Bezüge durch die Benützer minimiert indem das Abgaberegime unterlaufen wird. Bei 

tiefen Preisen werden die Daten zwar häufiger bezogen, aber die eingenommenen Beiträge 

fallen zu klein aus, um zu einer sinnvollen Amortisationsdauer zu führen. Die 

Groupe de Réflexion empfiehlt deshalb, zum Regime der marginal cost, das bis zur Einführung 

des Vorschlags Buschor Gültigkeit hatte, zurückzukehren. 

Die Groupe de Réflexion hat sich ebenfalls über Tarifansätze Gedanken gemacht. Dabei 

hat sie versucht, die Auswirkungen der Interoperabilität in ihre Betrachtungen einzubeziehen. 

1 Anm. d. Red. : V+D :Eidgenössische Vermessungsdirektion 




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 Geoinformationsgesetz 

aufgenommen. Ob sie zur Anwendung kommt ist vorerst nicht klar. Es ist in 

jedem Fall weise, die Bearbeitungs- und Lieferkosten separat festzusetzen und damit 

vom traditionellen Muster des Gemeinkostenzuschlags wegzugehen. 


Die Interoperabilität ändert die traditionellen Kostenfragen nicht grundsätzlich, verschiebt 

aber den Schwerpunkt auf hochautomatisierte Prozesse bei der Leistungserbringung. 

Es müssen einfache und transparente Tarife geschaffen werden, um interoperable 

Lösungen auch kommerziell sinnvoll auszugestalten. 

Erste Ansätze sind vorhanden. Diese müssen aber in der praktischen Anwendung ausprobiert 

und allenfalls den Erfahrungen angepasst werden. 

Literatur 

Groupe de Réflexion Datenabgabe und Gebühren [2003] 'Vorschlag für die zukünftige 

Regelung der Datenabgabe und der Gebühren in der Amtlichen Vermessung, V+D, 

Bern 

Groupe de Réflexion diffusion des données et émoluments [2003] 'Proposition pour la 

future réglementation de la diffusion des données et des émoluments dans la Mensuration 

Officielle', D+M, Berne 

KOGISTarif [2002] Neue Tarifierungs- und Vertriebsstrategien von Geodaten des Bundes, 

INFRAS im Auftrage von KOGIS, 26. September 2002 


Horst Düster, Dr. 

Amt für Geoinformation Kanton Solothurn 

Abteilung SO!GIS Koordination 

Werkhofstr. 65 

CH-4509 Solothurn 

Tel : 

Fax : 

E-Mail : 

+41 32 627 25 32 

+41 32 627 22 14 

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

1 Situation 

Eine kantonale Verwaltung hat Ähnlichkeiten mit einer heterogenen Unternehmensstruktur. 

Die Verwaltungsorgane verfügen über eine vielfältige Aufgabenstruktur mit 

gleichzeitiger räumlicher Trennung der Einheiten. Herausragend ist dabei der grosse 

Informationsbedarf, besonders nach Geoinformationen. 

Zur Befriedigung dieses Informationsbedarfes steht eine grosse Zahl unabhängig funktionierender 

Informationsquellen bereit. In der Regel weisen diese Quellen Redundanzen 

auf. So werden z.B. Grundbuchzugehörigkeiten, Flurnamen von verschiedenen Objekten 

in unterschiedlichen Datenhaltungssystemen redundant bereit gehalten. Eine 

konsistente Pflege und Nachführung dieser eigentlich ungebundenen Informationen ist 

in der Regel unmöglich. 

Die Folge dieser Situation ist eine ineffiziente Ressourcennutzung, die insbesondere 

durch Entscheidungsunsicherheit hervorgerufen wird. 

Im Kanton Solothurn wurde ein GIS Leitbild entworfen, dessen Kernsätze sich auf die 

Erhöhung der Produktivität, Verbesserung der Entscheidungssicherheit und damit die 

Erhöhung des operationellen Nutzens sowie die Verbesserung des strategischen Nutzens 

mit dem Ziel die staatlichen Strukturen und Instrumente zu verbessern, beziehen. 

2 Strategie 

Die Vision zur strategischen Umsetzung des Leitbildes sieht eine Beschleunigung und 

Verbesserung der grundlegenden Verwaltungs- und Entscheidungsprozesse durch konsistente 

digitale Geo- und Sachinformationen vor. Dazu müssen Raum- und Sachinformationen 

logisch und redundanzfrei normalisiert vereint werden können. Die Voraussetzung 

dazu ist technische Interoperabilität durch offene Schnittstellen. Um diese nutzen 

zu können wird konzeptionelle Interoperabilität durch offene Systeme vorausgesetzt. 

Aufgrund des Regierungsziels 2005, "... 90% der Standard-Benutzer sowie der Anwendungen 

sind auf Terminalserver unter Linux migriert", wird durch die Abteilung 

SO!GIS Koordination weitgehend freie und offene Software eingesetzt. 

Open Source GIS bietet sich zur Umsetzung der Vision auf der Grundlage des Regierungsziels 

an. Da seitens dieser Software kein Interesse besteht, die Anwender an ein 

herstellerabhängiges System/Produkt zu binden, werden ein grosse Zahl verschiedener 

Datenformate unterstützt. Ausserdem wird eine breite Unterstützung offener Spezifikationen 

und Schnittstellen wie z.B. die vielfältigen OGC Spezifikationen gewährleistet. 

Schliesslich sind die verwendeten Systemschnittstellen der Open Source GIS Software 

offen dokumentiert und frei erhältlich. 

3 Systemumgebung 

Im Kanton Solothurn werden die folgenden Open Source GIS Komponenten im Rahmen 

einer Multischicht-Architektur eingesetzt. Zur persistenten Datenhaltung wird in der 

Datenschicht PostgreSQL verwendet. PostgreSQL folgt den Standards SQL92 und 

SQL99. Mit der Erweiterung PostGIS wird PostgreSQL um den Funktionsumfang der 

OGC Spezifikation SQL for simple features erweitert. Auf diese Weise steht eine vollständig 

GIS fähige Datenhaltungsschicht, mit der über standardisierte Schnittstellen, als 

Grundlage zur technischen Interoperabilität, kommuniziert werden kann, zu Verfü- 



Georeferenzierung, Interoperabilität zwischen Vermessungsdaten und darauf aufbauender 

Rauminformation, Datenhierarchie und Nachführung der abhängigen Rauminformation 

gung. Diese Umgebung bildet die Grundlage für die normalisierte Datenhaltung und 

Informationsverarbeitung. Applikationsschichten bzw. Anwendungen müssen deshalb 

nicht grundsätzlich über GIS-Funktionalität verfügen. 

Die Applikationsschichten und Applikationen sind den Anforderungen entsprechend 

vielfältig. Sowohl proprietäre Systeme auf Client-Server Basis über ODBC, JDBC, 

GDAL/OGR oder nativen Schnittstellen, als auch echte Multischicht-Architekturen, in 

der Regel Web basierend, werden eingesetzt. 

Grundsätzlich ist dieser Ansatz unabhängig von den eingesetzten Betriebssystemen, 

Programmiersprachen und Entwicklungsumgebungen, da die Kommunikation zwischen 

den einzelnen Komponenten standardisiert abläuft. 

4 Beispiel Bodenprofil 

Am Beispiel der Abfrage von Informationen zu einem Bodenprofil soll die Konzeption 

und Systemumgebung in einem konkreten Fall, wie er in Solothurn umgesetzt ist, illustriert 

werden. 

4.1 Problemstellung 

Die Informationen zu einem Bodenprofil sollen redundanzfrei normalisiert abgelegt 

und gepflegt werden können. Dazu wird eine persistente und normalisierte Datenhaltung 

aufgebaut, die in eine Multischicht-Architektur integriert ist. Die Vereinigung der 

originären Information erfolgt über den Raum auf der Grundlage von SQL92 und dem 

OGC Standard SQL for simple features. Die Applikationsschicht ist, in diesem Fall, mit 

Web Technologien aufgebaut. Es werden technisch und konzeptionell offene und interoperable 

Schnittstellen verwendet. 

Ein Abfrageergebnis soll der Bodentyp sowie die aktuelle Grundbuchnummer der Liegenschaft, 

den aktuellen Flurnamen und die aktuelle Höhe, in der das jeweilige Bodenprofil 

liegt, ermittelt werden. 

4.2 Lösung 

Aus der Sicht des Bodenprofils können die originären Informationen die Lage des Profils 

im Raum als Geometrie und der Bodentyp sein. Sie werden in einer 

PostgreSQL/PostGIS Datenbank abgelegt und gepflegt. Zur Lösung der Problemstellung 

werden vom Bodenprofil keine weiteren Informationen benötigt. Abgeleitet sind 

zur Lösung der Fragestellung, aus der Sicht des Bodenprofils, die Informationen aktuelle 

Parzellennummer, aktueller Flurname und aktuelle bekannte Höhe. Die abgeleiteten 

Informationen stammen alle aus dem Datenstamm der amtlichen Vermessung und 

werden dort unabhängig von den Bodeninformationen, in der PostgreSQL/PostGIS Datenbank 

gepflegt. Die Informationsebenen bilden somit eine flache Hierarchie, die a priori, 

ausser über den Raum, keine Beziehung zueinander aufweisen. Die Beziehungen 

werden erst durch die Fragestellung generiert. 

Wird nun eine Abfrage via SQL for simple features formuliert, an die Datenbank geschickt, 

erfolgt die im SQL Statement formulierte Verschneidung und das System kann 

mit dem gewünschten Ergebnis antworten. So sieht die SQL Query für die Ermittlung 

der Grundbuchnummer der Parzelle in der das Profil liegt folgendermassen aus: 





select bodenprofil.bodentyp, parzellen.nummer 

from bodenprofil, parzellen 

where distance(bodenprofil.geometrie,parzellen.geometrie)=0; 

Grundsätzlich kann diese Query von jeder beliebigen Applikationsschicht bzw. Applikation 

abgesetzt werden. Die Interoperabilität wird durch ODBC, JDBC, GDAL/OGR 

oder native aber technisch offen dokumentierte Schnittstellen gewährleistet. 

Abb. 1 : Systemarchitektur am Beispiel Bodenprofil 





5 Fazit 

Die vorgestellte Strategie der Multischicht-Systemumgebung in Verbindung mit einer 

normalisierten Kommunikation zwischen den Komponenten ist sowohl unabhängig 

von Betriebssystemen als auch von Programmiersprachen, unter der Voraussetzung, 

dass die Kommunikationsstandards zur Interoperabilität eingehalten werden. So ergeben 

sich die folgenden Verbesserungen. 

geringere Redundanzen 

Die seit mehreren Jahren in Solothurn verfolgte Strategie der Normalisierung der 

Grundlageninformationen führte zur erheblichen Reduktion der Redundanzen in der 

Grundlagenhaltung, da Objektfremde abgeleitete Informationen nicht mehr mit den jeweiligen 

Objekten gemeinsam gespeichert werden. 

effektiveres Datenmanagement 

Das Datenmanagement ist vereinfacht und effektiver geworden. Die Nachführung der 

Grundlagen erfolgt ausschliesslich auf den normalisierten Grundlageninformationen in 

einer horizontalen Hierarchie. 

verbindliche Daten 

Die normalisierten Grundlageninformationen werden separat gepflegt und aktualisiert. 

Da die gewünschte Information erst im Moment einer Abfrage generiert wird, konnte 

die Qualität der Abfrageergebnisse erheblich verbessert und die Entscheidungssicherheit 

erhöht werden. 


22 

Der Mobilitäts-Graph 

Ein geographisches Rahmenwerk für die 

Partner des Mobilitäts-Informationssystems 

der Region Genf 

Pascal Oehrli 

SSIG - Service des Systèmes d'Information et de Géomatique 

DIAE - Département de l'Intérieur, de l'Agriculture et de l'Environnement 

7, rue des Gazomètres 

Case Postale 36 

CH-1211 Genève 8 

Tel : 

Fax : 

E-Mail : 

+41 22 327 79 29 

+41 22 327 50 70 

Pascal Oehrli, SSIG Genf

Das Mobilitäts-Informationssystem der Region Genf (SI Mobilité) ist ein thematisches 

Informationssystem aufgebaut im Rahmen des Système d’Information du Territoire Genevois 

(SITG). Die SI Mobilité ist eine Partnerschaft zwischen den verschiedenen Institutionen 

und Beteiligten, die mit Verkehr und deren Infrastrukturen zu tun haben (gilt für 

alle Verkehrsmittel). Seine Ziele sind es die Daten und Produkte im Bezug auf die Mobilität 

in Genf zu sammeln, organisieren, verwerten, koordinieren und vertreiben. 

Die Analyse der Situation hat gezeigt, dass die durch die verschiedenen Partner produzierten 

oder verwalteten Daten voneinander unabhängig, manchmal redundant und 

direkt in einer Anwendung oder einem Modell insgesamt unbrauchbar waren. Trotz der 

Existenz eines Routen-Graphs innerhalb der SITG sind von den Beteiligten entsprechend 

den berufsspezifischen Bedürfnissen andere Graphe entwickelt worden. Es existierten 

bis zu 5 oder 6 verschiedene Darstellungen der Geographie der Straßen. 

Aufgrund dieser Tatsachen ist eine Vorgehensweise lanciert worden um einen gemeinsamen 

Routen-Graph auszuarbeiten, der die Besonderheiten von jedem der Partner maximal 

integriert. Es hat sich schnell gezeigt, wie wertvoll es ist, über ein einziges und auf 

zentrale Art gehaltenes geographisches Bezugssystem verfügen zu können. Als Antwort 

auf dieses Bedürfnis entstand der Mobilitäts-Graph. Er integriert die Geographie derverschiedenen 

der Fortbewegung dienenden Infrastrukturen (Straßen, Wege und Pfade, 

Schiene und Wasserstraßen) sowie die Verbindungspunkte (Kreuzungen, Bahnsteige 

und Anlegeplätze). Ein Paket so genannter Anschlussregeln erlaubt das logische Verbinden 

verschiedener Komponenten des Mobilitäts-Graphs. 

Dieses allen Partnern von SI Mobilité zur Verfügung gestellte geographische Bezugssystem 

erlaubt es, die verschiedenen Daten, welche durch die Partner produziert und verwaltet 

werden, zu koordinieren. Diese Daten sind in einem Datenmodell organisiert 

welches die folgenden Aspekte integriert: die Infrastruktur selbst, die dafür aufgestellten 

Einrichtungen, die Mobilität im Allgemeinen, die verschiedenen angewendeten Gesetzgebungen, 

die Mittel zur Umsetzung dieser Gesetzgebungen und die Aspekte der 

Umwelt oder der Sicherheit. Diese vielfältigen Informationen unterschiedlicher Natur 

können durch den Mobilitäts-Graphen auf verschiedene Arten wie die lineare Gliederung, 

die Netztopologie oder andere geographische oder nichtgeographische Beziehungsmittel 

koordiniert werden. Ausserdem bildet der Mobilitäts-Graph eine Basis für 

die Netzanalyse und die Routenberechnung oder anderen zeitlichen oder geographischen 

Abfragen auf einem multimodalen Reisenetz. 



Der Mobilitäts-Graph: ein geographisches Rahmenwerk für die Partner 

des Mobilitäts-Informationssystems der Region Genf 

Parkplatz 

Linien TC 

Parkplatzzufahrten- 

Graph 

Wasserstrassen- 

Graph 

Halt TC 

Anlegestellen 

Routen-Graph 

Kreuzungen 

Anschlüsse 

Bahnsteig_Bahnhof 

Eisenbahn-Graph 

Langsamverkehrs- 

Graph 

Mobilitäts-Graph 

Flughäfen 

Bahnhö- 

Fluglinien 

Der Mobilitäts-Graph wird durch den mit der Amtlichen Vermessung beauftragten 

Dienst verwaltet, auf den neusten Stand gebracht und allen Partnern von SITG frei zur 

Verfügung gestellt. 

Als Schlussfolgerung kann man sagen, dass die Existenz eines minimalen gemeinsamen 

Bezugssystems eine wesentliche Basis für die Interoperabilität in einem Informationssystem 

darstellt, am Beispiel eines Koordinatensystems… oder eines für die linearen 

Strukturen gemeinsamen Referenz-Graphen. Der gemeinschaftliche Genfer Mobilitäts- 

Graph, ebenso wie die Vorgehensweise, die zu einer Übereinkunft aller betroffenen Beteiligten 

geführt hat und die verschiedenen Modelle, die man durch dynamisches Segmentieren 

daran anknüpfen kann, scheinen ein gutes Beispiel für die Ausarbeitung eines 

gemeinsamen Bezugssystems zu sein.

Interoperabilität - Institute of Geodesy and Photogrammetry (IGP ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?