INTERLIS ist ein Beschreibungs- und Transfermechanismus für Geodaten (daher "The GeoLanguage"). Mit dieser einheitlichen Sprache können Fachleute ihre Datenmodelle präzise modellieren und daraus Softwareapplikationen und Schnittstellendienste ableiten. Die Grundidee von INTERLIS besteht darin, dass ein digitaler Austausch von strukturierten Informationen nur möglich ist, wenn die am Austausch beteiligten Stellen eine genaue und einheitliche Vorstellung über die Art der auszutauschenden Daten haben. INTERLIS befasst sich deshalb sowohl mit der systemneutralen, konzeptionellen Beschreibung von Geodatenstrukturen als auch mit der Festlegung des Austauschformates. Vordefiniert ist zurzeit das systemneutrale INTERLIS-Dateitransferformat (ITF, Version 1) und INTERLIS 2/XML (Version 2). INTERLIS 1 wurde 1993 in der Gesetzgebung über die amtliche Vermessung vorgeschrieben und wird seit 1998 von der Schweizer Normen-Vereinigung (www.snv.ch) als Norm SN 612030 herausgegeben. Im September 2003 wird INTERLIS 2 - nach mehrjähriger Entwicklung und Tests - offiziell als Norm SN 612031 publiziert. INTERLIS 2 enthält wichtige, von den Benutzern geforderte Erweiterungen, wie z.B. Datenreplikation (Synchronisation, sog. inkrementelle Nachlieferung), volle Kompatibilität zu UML-Strukturdiagrammen, XML und ISO 19100 sowie Möglichkeiten zur Grafikdefinitionen. Mit diesem modell-basierten Ansatz lässt sich auch die Prüfung und Archivierung von Geodaten automatisieren (vgl. Anforderungen von SN 612010). Die meisten auf dem (Schweizer) Markt erhältlichen Geoinformationssysteme unterstützen diesen Standard und es gibt mittlerweile über hundert Projekte - darunter Richtlinien verschiedenster Fachverbände - in denen INTERLIS mit Erfolg eingesetzt wird (Stand Ende 1999).

Das sind 5 Hauptgründe für den Einsatz von UML (Struktur-, bzw. Klassendiagrammen) zusammen mit INTERLIS: 

• Verständigung unter Fachspezialisten unterschiedlicher Ausrichtung, vom Geomatiker und Planer bis zum Informatiker 
• Automatisierter Transfer durch Kompatibilität der Systeme (sog. Interoperabilität von Daten und Systemen durch modell-basierter Transfer) 
• Langfristiger Investitionsschutz 
• Effiziente Integration von Daten und Systemen 
• Qualitätssicherung (Verifikation) von Daten 

Der Nutzen von INTERLIS wurde in einem Bericht anhand von Kriterien und Fallstudien in harten Franken nachgewiesen (siehe Bericht 17 der L+T www.swisstopo.ch).

Das sind die 5 Unterscheidungsmerkmale ("unique selling points") für den Einsatz von UML (Struktur-, bzw. Klassendiagrammen) zusammen mit INTERLIS: 

• INTERLIS ermöglicht Integration von Daten und Systemen 
• INTERLIS bietet Investitionsschutz von Daten, Applikations-Dokumentation und Wissen durch internationale Kompatibilität und national breite Abstützung (Normen, Kurse) 
• INTERLIS fördert Effizienz durch implementierte Werkzeuge 
• INTERLIS beweist Zukunftssicherheit: hat bereits Trends überlebt 
• INTERLIS ist konkurrenzlos (d.h. es gibt kaum Alternativen): 
  • UML alleine genügt nicht, ISO 19100 liefert nicht 
  • OGC liefert nur Teile: verwendet UML nur informell und XML Schema ist nicht modell-basiert, nicht gut lesbar 
  • Webservices z.B. sind a) noch nicht da und b) verlangen nach Datenbeschreibung... also UML/INTERLIS 
  • Datenbanken (z.B. ORACLE) alleine sind meist zentralistisch, per Definition proprietär, dokumentieren nicht konzeptionell, bieten keine offenen Schnittstellen und sind ohne externe Schnittstellen nicht Migrations-sicher

• INTERLIS ist kompatibel und konsistent zu internationalen Standards 
• INTERLIS ist modell-basiert (investitionssichernd) durch klare Schnittstellen für Daten und Operationen, d.h. Verständigung mit Daten-Schemas, insbesondere Geodaten-Schemas, kombiniert mit automatisierter Definition von system-neutralen Datenschnittstellen (XML, APIs) 
• INTERLIS ist kompakt, stabil und konsistent, denn das Referenzhandbuch umfasst weniger als 80 Seiten und ändert nicht jedes halbe Jahr; INTERLIS 2 bietet eine gleichartige Syntax für alle inkl. Datensichten 
• INTERLIS wurde als verschiedenste Software implementiert, ist also praxis-getestet und ausserden frei verfügbar als eine offizielle Norm! 
• INTERLIS ist generisch und universell integrierend, denn die Spezifikation... 
  • ist objektorientiert: computergestütztes Modellieren und Lesen von erweiterten Daten 
  • erlaubt Synchronisation: Replikation verteilter Systeme/Daten (sog. inkrementelle Nachlieferung) 
  • erlaubt Mehrsprachigkeit: automatisches Lesen und Verwalten von Daten aus mehrsprachigen Datenmodellen 
  • ist Geodaten-spezifisch: kennt (bei Bedarf) Geometrie-Datentypen, Konsistenzbedingungen, Grafikdefinitionen inkl. Signaturen

Siehe Rubrik Datenmodelle

Siehe Rubrik Datenmodelle

Siehe Downloads > Testdatensätze.

In Vorbereitung ...

Die INTERLIS-Spezifikation wird von der Koordinationsstelle GIS beim Bund, KOGIS, gepflegt und weiterentwickelt im Auftrag der Eidg. Vermessungsdirektion, Swisstopo, Wabern bei Bern/CH, abgestützt auf ein Gesetz der Schweizerischen amtlichen Vermessung. Die Eidg. Vermessungsdirektion und KOGIS wiederum haben die eigentliche Spezifikationsarbeit einem Gremium von ausgewiesenen Fachleuten übertragen ("Das INTERLIS-Kernteam"), das sich aus Vertretern der Hochschule, der öffentlichen Verwaltung, der Softwareindustrie und aus Beratern zusammensetzt. INTERLIS wurde mit Erfolg an internationalen GIS-Konferenzen vorgestellt und ist in den einschlägigen internationalen Normierungsgremien bekannt als wohl die erste Norm, welche die modell-basierte Methode auf breiter Basis und mit Werkzeugen realisiert hat.

Primär stehen Bundesstellen hinter der Entwicklung von INTERLIS, allen voran KOGIS, zusammen mit der Eidg. Vermessungsdirektion. Dann sind es die kantonale und kommunale Stellen, welche die Kompetenz oder einfach den Bedarf haben, die Verwaltung und den Austausch von Geodaten zu regeln. Angesichts der Tatsache, dass der grösste Nutzen bei der Gesamtorganisation, d.h. bei öffentlichen Verwaltung (oder sonst einer grossen Organisation) anfällt, ist es auch konsequent, dass diese Norm von diesen Stellen eingesetzt und gefördert wird. Zu den grossen Organisationen sind auch die Dachverbände zu zählen, welche diese Norm ihren Mitgliedern empfehlen, wie z.B. die SOGI, der SVGW oder der VSA, etc. Eigentlich sind es ja die Benutzer, die einen Bedarf haben, ihre Daten zu dokumentieren und mit anderen zu integrieren. Die GIS-Benutzergemeinde hat jedoch keine einheitliche Stimme, weswegen wir hier nur auf die verschiedenen Berichte und "Success Stories" verweisen wollen. Letzlich sind es jedoch immer Firmen, welche Software entwickeln und den Benutzern beratend zu Seite stehen.

Zurzeit sind uns keine Alternativen bekannt, welche die modell-basierte Methode mit UML und INTERLIS ersetzen könnten. Es gibt wohl einige Bestrebungen in dieser Richtung, wie die folgenden (dabei ist zu beachten, dass man jederzeit und automatisiert von INTERLIS auf alle erwähnten Alternativen wechseln könnte, wenn man wollte, kaum aber umgekehrt):

• ISO 19100 (Stand 2003): Die ISO 19100-Serie verwendet ebenfalls UML verbunden mit spezifischen Datentypen und Ergänzungen, z.T. ganz ähnlich wie INTERLIS. Die fast dreissig (!) ISO 19100-Spezifikationen sind jedoch weder getestet worden noch sind sie "schlank". D.h. es ist in Frage gestellt, ob sie implementierbar sind. Dies wurde von der ISO selbst erkannt und es wurden Arbeiten zur Erarbeitung von sogenannten "Profilen" angesetzt. Bis die letzten ISO 19100-Normen verabschiedet sind, vergehen noch Jahre. Und ob sich die ISO-Normen gegenüber agileren "de facto"-Standards, wie OGC, durchsetzen, ist völlig ungewiss. Möglich ist auch, dass die ISO-Spezifikationen von OGC "absorbiert" werden.
• UML informell (Stand 2003): OGC verwendet zum Beispiel zwar ebenfalls UML in seinen Spezifkationen, jedoch nur als reine informelle (Nach-) Dokumentation. Die verbindlichen Regelungen werden plattform-spezifisch festgelegt, was als "Multi-Plattform"-Ansatz bezeichnet werden kann. Dieser hat den Nachteil, dass Änderungen an den Basisspezifikation einzeln und von Hand von allen abhängigen Spezifikationen nachvollzogen werden müssen und dass Spezifikationen für zusätzliche Plattformen ebenfalls mit grösserer Handarbeit (und viel Text) verbunden sind. Ausserdem verunmöglicht dieser Ansatz praktisch die Erstellung generischer Software. Das alles erschwert die Realisierung, führt zu mangelnder Wiederverwendbarkeit sowie zu erhöhtem Migrationsaufwand.
• XML Schema alleine: XML Schema geht zwar in dieselbe Richtung wie INTERLIS, ist aber eng mit XML verbunden und enthält Datentypen, die auf Programmiersprachen ausgerichtet sind. Ganz allgemein wurde XML Schema zur Prüfung von XML-Dokumenten angelegt und erreicht nicht das konzeptionelle Niveau, welches nötig (und machbar) ist, um Schnittstellendienste zu beschreiben. Ausserdem ist XML Schema deutlich schlechter von Menschen lesbar und enthält im Gegensatz zu UML und INTERLIS weder höhere objektorientierte Konzepte (UML: Aggregation, Packages), noch Geometriedatentypen, noch die erweiterten Möglichkeiten von INTERLIS 2 (Mehrsprachigkeit, Masseinheiten, Grafikdefinitionen, Referenzsysteme, geometrische Konsistenzbedingungen, etc.).
• GML mit XML Schema (Stand 2003): GML basiert auf XML Schema, d.h. alle in Punkt 3 erwähnten Einschränkungen gelten weiterhin, ausgenommen die geometrischen Datentypen (OGC Simple Features) und ab GML Version 3.0 Referenzsysteme und Masseinheiten. Die Simple Features von GML enthalten wichtige Einschränkungen (keine Topologie, nur ganze Randlinien) und es fehlen weiterhin wichtige Eigenschaften (inkrementelle Nachlieferung, Grafikdefinitionen, etc.). Ausserdem ist die Spezifikation nicht mehr als "schlank" (viele XML-Substandards) und robust implementierbar zu bezeichnen. Neue GML-Versionen sind absehbar (mit grösseren Änderungen) und der hohe Release-Rhythmus (verbunden mit konkurrierenden Kandidaten-Spezifikationen, wie z.B. für Grafikdefinitionen) macht es sicher nicht einfach, der Entwicklung zu folgen.
• UML Human Readable Textual Notation (HUTN) und XMI: Bei der OMG sind relativ neue Spezifikationsvorschläge publiziert worden, um die "Model-Driven Architecture" zu verbessern. Dies sind jedoch reine Diskussionsgrundlagen mit ungewissem Ausgang und Zeithorizont.
  Letztere und weitere Alternativen beweisen vor allem, dass vieles im Fluss ist und dass die Interoperabilität von Daten und Systemen nicht mit kurzfristigen Lösungen zu erreichen ist. Der Vollständigkeit halber hier noch weitere Alternativen, die eigentlich nicht als solche bezeichnet werden dürften:
  • Webservices: Der gegenwärtige "Hype" um diese "neue" Technologie darf nicht vergessen lassen, dass netzbasierte Operationen auf Daten operieren - und Daten müssen in Strukturen (Datentypen) beschrieben sein. Sogar die aktuellste Diskussion dreht sich um Metadaten zu Operationen (d.h. Daten über Operationen). Alles dies verlangt nach Dokumentations(-Sprachen) und Applikationsschemas, womit wir wieder bei der Datenbeschreibung mit UML und INTERLIS sind...
  • Eigene Schnittstellendienste: Es können auch eigene Sprachen und Schnittstellendienste entwickelt werden, unter der Annahme: "Selber machen und niemandem zeigen" (kann auch von Herstellern angewendet werden, um Kunden eng an sich zu binden...).
  • UML- oder Entity Relationship Diagramme als alleinige definitorische Sprache(n): Strukturdiagramme alleine einzusetzen, bedeutet, dass es keine direkte und keine dokumentierte Abbildung auf Schnittstellendienste gibt.
  • Keine Interoperabilität von Daten und Systemen: Daten und Software, die für sich alleine erfasst, bzw, geschrieben werden und/oder danach weder gepflegt noch wiederverwendet werden, benötigen auch weder Dokumentation noch gemeinsame Schnittstellen.

Antwort 1: Wenn man keine Interoperabilität von Daten und Systemen benötigt.

Antwort 2: Wenn man zum Schluss kommt, dass eine der wenigen Alternativen für die eigenen, aktuellen Bedürfnisse genügen (siehe Frage "Welche Alternativen gibt es zur modell-basierten Methode mit UML und INTERLIS?").

Antwort 3: Wenn man zum Schluss kommt, dass man Interoperabilität von Daten und Systemen noch nicht benötigt (siehe letzte Antwort zur Frage "Welche Alternativen gibt es zur modell-basierten Methode mit UML und INTERLIS?").

Shapefiles sind proprietär (auch wenn sie veröffentlicht sind) und genügen weder als Format und sicher nicht als Beschreibungssprache. Damit gehen Informationen (d.h. Arbeit) verloren und das oben erwähnte technische und volkswirtschaftliche Nutzenpotential wird nicht ausgeschöpft (siehe die Antworten zu Fragen wie "Was sind die Gründe (der Nutzen), die für INTERLIS sprechen?" oder "Was sind die Unterscheidungsmerkmale von INTERLIS gegenüber anderen Standards?").

• INTERLIS 2 kann mehr als INTERLIS 1:

  • inkrementelle Nachlieferung (Replikation)

  • Grafikdefinitionen und Signaturen

  • präziser (Masseinheiten, Konsistenzbedingungen)

  • mehrsprachige Datenmodelle und Daten möglich

  • kontrollierbare Modell-Erweiterungen

• INTERLIS 2 ist einfacher als INTERLIS 1:

  • Lesen erweiterter Daten ohne Zusatzkonfiguration

  • AREA ist wie SURFACE codiert

• INTERLIS 2 ist gleichartig wie INTERLIS 1:

  • stabil: Schnellebige Standards werden überdauert

  • automatisierend: Es gibt Werkzeuge zur Konversion

  • realisierbar durch Einfach- und Kompaktheit (< 80 Seiten)

  • weiterhin deutlich kompakter als viele andere Standards

• INTERLIS 2 beweist die Zukunftssicherheit dieser Norm:
  • erlaubt inkrementelle Nachlieferung, d.h. effizientere Basisdaten
  • kennt Grafikbeschreibung inkl. farbige, wiederverwendbare Signaturen
  • ist konsistent zu internationalen Standards wie XML, GML, UML und ISO 19100
• und weiter kann man mit INTERLIS 2:
  • automatisch (z.B. kantonal) erweiterte Daten ohne Zusatzkonfiguration lesen
  • mehrsprachige Schemas und Daten verwalten und lesen
  • mehr Konsistenzbedingungen und Masseinheiten angeben, d.h. noch bessere Qualitätssicherung
  • einfach von INTERLIS 1 zu INTERLIS 2 migrieren (und zurück)

D.h. INTERLIS 2 ist noch effizienter, noch internationaler abgestützt und bietet noch mehr Investitionsschutz.

Die sogenannte "modell-basierte" Methode, das ist die Anwendung moderner Projektmanagement-Techniken (Geodaten-Modellierung) unter Verwendung einer Beschreibungssprache (z.B. die INTERLIS-Sprache) und dazugehöriger Regeln, die systemneutrale Schnittstellendienste erlauben (z.B. INTERLIS 2/XML-Datei-Transferformat). Hinweis: Das grösste Informatikhersteller-Konsortium, OMG, hat 2001 ein strategisches und breit angelegtes Programm unter dem Motto "The Model-Drive Approach" vorgestellt, der genau dem Prinzip der modell-basierten Methode entspricht (www.omg,org/mda).

INTERLIS 1 gibt es seit über 10 Jahren (2001) und wird in der Amtlichen Vermessung noch einige Jahre genutzt. INTERLIS 2 wurde 2003 als Schweizer Norm publiziert und bewies damit, dass eine Adaption aktueller Technologien, wie z.B. die Objektorientierung oder XML, möglich ist. Für die modell-basierte Methode kennen wir keine Alternative! Wenn der Zeiptunkt gekommen ist, bei dem die internationalen Normen besser sind, kann man auf eine dokumentierte und qualitätsgeprüfte Datenbasis mit Werkzeugen migrieren. Zurzeit ist in der internationalen Normenszene immer noch alles im Fluss. Da ist man froh, wenn es beständige Normen gibt. Daher spricht man bei INTERLIS von einer nachhaltigen und zukunftssicheren Norm.

Ja. Eine Dokumentation macht auch im Nachhinein Sinn. Viele Metadaten über Geodaten werden zur Zeit ja in dieser Weise nach-erfasst. Das ist, wie wenn man die Pläne antiker Städte im Nachhinein rekonstruiert. Diese Pläne ergeben eine Zusatzinformation (z.B. einen Überblick oder ein Muster), die durch reines Betrachten der einzelnen Gebäude nicht zu erkennen gewesen wäre.

Ja! Genauer gesagt: kompatibel bezogen zum UML-Struktur- bzw. Klassendiagramm und z.T. zu OCL. Andere Diagrammarten, wie z.B. Sequenzdiagramme sind (noch) keine Ziele von INTERLIS, da diese Bedürfnisse z.B. durch andere modell-basierte Methoden oder durch Programmiersprachen abgedeckt sind. Man beachte auch den grundlegenden Mehrwert von INTERLIS zsätzlich zu UML (siehe Frage "Welche Alternativen gibt es zur modell-basierten Methode mit UML und INTERLIS").

Ja, 100%: Siehe das INTERLIS 2-Referenzhandbuch und der INTERLIS 2-Compiler, der aus INTERLIS 1 und 2 ein entsprechendes XML Schema erzeugt. Man beachte auch den grundlegenden Mehrwert von INTERLIS zusätzlich zu XML Schema (siehe Frage "Welche Alternativen gibt es zur modell-basierten Methode mit UML und INTERLIS").

Ja! Aber es gibt Unterschiede und es kommt darauf an welche GML-Version gemeint ist... Durch die grössere Mächtigkeit und die Flexibilität von INTERLIS ist es möglich - und wird es auf für künftige Versionen möglich sein - GML (Version 1, 1.1, 2.1, 3, ...) zu 100% zu generieren und zu 99% zu übernehmen. Man beachte auch grundlegenden Mehrwert von INTERLIS zusätzlich zu GML (siehe Frage "Welche Alternativen gibt es zur modell-basierten Methode mit UML und INTERLIS").

Ja, seit 2003 als KOGIS-Spezifikation und beim SNV als SN 612031, seit 2016 als Standard eCH-0031

INTERLIS 1=>UML mit Visio (ili2visio von Eisenhut Informatik); INTERLIS 1=>UML mit UML/INTERLIS-Editor von KOGIS und Rational Rose Tool; INTERLIS 1>INTERLIS 2 & INTERLIS 1=>INTERLIS 2 mit Compiler und mit UML-Editor; UML=>INTERLIS 2/INTERLIS 1 mit dem UML/INTERLIS-Editor von KOGIS und dem Rational Rose Tool.

Siehe Datenmodell-Ablagen

Ja, z.T. automatisch, z.T. mit Angabe des Datenmodells (z.B. DM.01).

Ja, z.T. automatisch, z.T. mit Angabe des Datenmodells (z.B. DM.01); (übrigens geht auch die Konversion nach GML; vgl. andere FAQ).

Ja! Siehe das INTERLIS 2 Referenzhandbuch.

Die wichtigsten Werkzeuge sind unter Downloads publiziert. Die Entwickler dieser Werkzeuge sind: infoGrips GmbH und Eisenhut Informatik AG.