INTERLIS-Dokumentation

Vorwort

Das vorliegende Dokument ist eine Kopie des Standards eCH-0031 INTERLIS 2-Referenzhandbuch Version 2.1.0 (2024). Die Bereitstellung als Website erlaubt es, aus anderen Webapplikationen (Forum, GitHub usw.) direkt auf ein Kapitel zu verweisen, wenn daraus zitiert wird. Ein umständliches Nachschlagen in einem zusätzlichen PDF-Dokument entfällt.

Abgelöste Versionen des Standards:

Version 2.0 (INTERLIS 2.4, 2017) (nur als PDF bei eCH verfügbar)
Version 1.0 (INTERLIS 2.3, 2006) (nur als PDF bei eCH verfügbar)

Als Ergänzung zu den HTML-Ankern vor den Kapiteln und Unterkapiteln wurden, wo sinnvoll, zusätzliche Anker bei den Codeblöcken (EBNF) eingearbeitet. Diese sind durch das Zeichen ※ gekennzeichnet. Damit lässt sich direkt auf einen Codeblock innerhalb eines Kapitels verweisen.

Fehler oder Abweichungen zum Standarddokument von eCH können im zugrunde liegenden Github Repository als Issue erfasst werden. Für inhaltliche Änderungen muss bei der eCH Fachgruppe Geoinformation ein Request for Change (RFC) eingereicht werden.

1. Einleitung

1.1. Status

Genehmigt: Das Dokument wurde vom Expertenausschuss genehmigt. Es hat für das definierte Einsatzgebiet im festgelegten Gültigkeitsbereich normative Kraft.

1.2. Vorwort

Dieses Referenzhandbuch richtet sich an Fachleute, die sich mit Informationssystemen, insbesondere mit Geo-Informationssystemen oder Landinformationssystemen befassen. Es dürfte insbesondere auch für Entscheidungsträger von Interesse sein, für die der sorgfältige Umgang mit den Daten ein Anliegen ist.

Im Jahre 1991 erschien erstmals «INTERLIS – ein Datenaustausch-Mechanismus für Land-Informationssysteme». Hauptziel und Zweck von INTERLIS ist die möglichst präzise Beschreibung von Daten. Dieser Mechanismus besteht aus einer konzeptionellen Beschreibungssprache und einem sequentiellen Transferformat mit besonderer Berücksichtigung raumbezogener Daten (kurz Geodaten). Damit wird die Kompatibilität unter den Systemen und eine langfristige Verfügbarkeit, d.h. Archivierung und Dokumentation der Daten ermöglicht. Wird INTERLIS bei Entscheidungs-, Planungs- und Verwaltungs-Prozessen sinnvoll eingesetzt, kann daraus ein grosser Nutzen entstehen. Oft lassen sich – zum Beispiel durch Mehrfachverwendung und einheitlicher Abgabe von dokumentierten und geprüften Daten – erhebliche Einsparungen erzielen.

Fünf Jahre nach seiner Veröffentlichung ist INTERLIS, das wir rückblickend Version 1, bzw. INTERLIS 1 nennen, aus seinem «Dornröschenschlaf» geweckt worden. Seither ist eine beachtliche Palette von Softwarewerkzeugen verfügbar, mit denen die Benutzer in INTERLIS beschriebene und codierte Geodaten verarbeiten können. INTERLIS ist aus einem Bedürfnis der Amtlichen Vermessung heraus entstanden, sein Anwendungsspektrum ist aber wesentlich umfassender. Das zeigen die weit über hundert Datenmodelle und Projekte, die zehn Jahre nach der Publikation von INTERLIS damit arbeiten. Der Standard «INTERLIS 1» wird als Schweizer Norm SN 612030 – parallel zu seinen Nachfolge-Versionen – noch eine Weile von Nutzen sein.

Aufgrund von gestiegenen Benutzeranforderungen drängten sich verschiedene Erweiterungen von INTERLIS 1 auf, wie zum Beispiel die inkrementelle Nachlieferung, die strukturelle Objektorientierung oder die formale Beschreibung der grafischen Abbildung von Objekten. 1998 war der Beginn eines mehrjährigen Konsensprozesses, für den ein halbes Dutzend Fachleute aus Forschung, Verwaltung, Beratung und Softwareindustrie zusammengearbeitet haben. Herausgekommen ist ein Produkt, das man eine Erweiterung von INTERLIS 1 und gleichzeitig eine Synthese neuester Konzepte bezeichnen darf.

Beim INTERLIS-2-Referenzhandbuch wurde wieder darauf geachtet, dass nur das absolut Notwendigste festgelegt wird: Beispiele und Figuren erscheinen nur dort, wo der knappe Text sinnvoll ergänzt wird. Damit bleibt die Spezifikation übersichtlich und einfach implementierbar. Wenn einige Sprachelemente, wie z.B. Sichten oder Darstellungsbeschreibungen, anspruchsvoll wirken, so liegt das höchst wahrscheinlich nicht an INTERLIS selbst, sondern am komplexen Sachverhalt. Zur Lösung dieses Problems sind uns folgende Wege bekannt: gute Beispiele, Aus- und Weiterbildung, sowie so genannte «Profile», d.h. Untermengen von wohl definierten INTERLIS-Werkzeugfähigkeiten.

Für ein erstes Grundverständnis von den INTERLIS-2-Konzepten wird jedem Leser empfohlen, mindestens das Kapitel 2, Grundprinzipien durchzulesen.

Erweiterungen von INTERLIS 2.4 gegenüber INTERLIS 2.3

INTERLIS 2.3 wurde im Interesse von Verlässlichkeit und Investitionsschutz über eine längere Zeit stabil gehalten. Aus der Praxis mit Datenmodellierung und Datenaustausch haben sich in der Zwischenzeit verschiedene Verbesserungswünsche ergeben. Mit der Version INTERLIS 2.4 sollen vor allem diejenigen Anliegen rasch umgesetzt werden, welche für die Praxis von besonderer Bedeutung und relativ einfach realisierbar sind.

Dies betrifft vor allem den Bereich des Datentransfers. Transfer-Files gemäss INTERLIS 2.4 unterscheiden sich erheblich von solchen gemäss INTERLIS 2.3 wegen wesentlicher Vereinfachungen und der Anpassung an die Gepflogenheiten in der XML-Welt (XML Best Practice). Wichtige Stichworte sind:

Präzise Definition der Zeichencodierung,
Regelung des Umgangs mit XML-Namespaces,
Verzicht auf die Alias-Tabelle in der Header-Section, weil sich das ursprünglich angestrebte polymorphe Lesen nicht durchgesetzt hat,
Für Objekt-Tags muss im Normalfall nur noch der Klassenname angegeben werden. Die Tags werden darum wesentlich kürzer, das Transfer-File kleiner und übersichtlicher,
Vereinfachung bei der Behandlung von Untermengen (LIST, BAG).

Es wurden zudem die Regeln für die Ableitung von XML-Schemas (XSD) aus INTERLIS-Modellen in die Norm aufgenommen.

Die meisten Änderungen der Modellierungssprache betreffen eher Detailpunkte:

Konsistenzbedingungen (Constraints) können mit Namen versehen werden, damit sie klar gekennzeichnet sind.
Constraints können auch zu Domains formuliert werden.
Eindeutigkeitsbedingungen können auf den einzelnen Transfer beschränkt werden.
Implikation als Vereinfachung für Ausdrücke in Constraints.
MULTI-Geometrien zur verbesserten Kompatibilität mit OGC, insbesondere das «Exklaven»-Problem wird damit vereinfacht.
Vereinfachung des Umgangs mit Zeit.
Untermengen (LIST und BAG) sind auch mit primitiven Typen (nicht nur mit Strukturen) möglich.
Linienattribute werden abgeschafft.

Von spezieller Bedeutung dürfte die neue Möglichkeit generischer Koordinaten-Wertebereiche sein. Damit können Modelle definiert werden, deren konkrete Koordinaten noch offen sind (insbesondere kann offen gelassen werden, ob es sich um LV03- oder LV95-Koordinaten handelt). Die konkrete Festlegung erfolgt in spezifischen Modellen oder sogar erst in den Transferdaten.

Für die Praxis ohne Belang dürfte die Änderung sein, dass die Deklaration von Modellen als «CONTRACTED» keine Bedeutung mehr hat. Das Konzept der Kontrakte hat in der Praxis keinen Niederschlag gefunden und wurde darum jetzt aufgegeben.

Sprachlich wurden alle Änderungen so vorgenommen, dass gültige INTERLIS-2.3-Modelle durch die Änderung der Versions-Nummer auf 2.4 zu gültigen INTERLIS-2.4-Modellen werden. Trotzdem kann es aber für bestehende Modelle Sinn machen, die Modelle anzupassen und dabei die verschiedenen Neuerungen zu nutzen.

Erweiterungen von INTERLIS 2 gegenüber INTERLIS 1

Die bestehende INTERLIS-1-Beschreibungssprache wurde bis auf wenige Ausnahmen erweitert und nicht abgeändert. Erweitert wurden zum Beispiel die Möglichkeiten, Beziehungen zwischen Objekten zu beschreiben (eigentliche Beziehungen als Assoziationsklasse und Referenzattribute mit REFERENCE TO). Hinweis: Die «→»-Syntax des INTERLIS-1-Beziehungsattributs erhielt eine andere Bedeutung, wobei darauf geachtet wurde, dass der Übergang von INTERLIS 1 auf 2 nicht unnötig erschwert wird (vgl. Kapitel 3.7, “Eigentliche Beziehungen”). Eigentliche Beziehungen und Referenzattribute können neu mit bestimmten Bedingungen auf Objekte in anderen Behältern verweisen. Behälter ist ein neuer Begriff für die uns wohlbekannte Organisation von Objekten (d.h. von Daten, die Realweltobjekte beschreiben, auch Objektinstanzen oder Instanzen genannt) in einer Datenbank.

Verändert hat sich der Begriff Tabelle (TABLE), der neu Klasse (CLASS) heisst, entsprechend dem Übergang vom relationalen zum objekt-orientierten Formalismus. Ohne weitere Angaben gilt ein Attribut als fakultativ (OPTIONAL entfällt) und es muss angegeben werden, wenn es obligatorisch ist (MANDATORY). Ferner hat die Eindeutigkeitsbezeichnung (IDENT) ebenfalls einen neuen Namen bekommen (UNIQUE). Die neuen objekt-orientierten Konzepte umfassen Vererbung unter anderem von Themen, Klassen, Sichten, Darstellungsbeschreibungen und Wertebereichen. Weitere mächtige Erweiterungen sind Mengen-Datentypen (LIST, BAG), Konsistenzbedingungen, Datensichten, Darstellungsbeschreibungen, Beschreibungen von Einheiten, Beschreibung von Meta-Objekten (Koordinatensysteme und Grafiksignaturen) und die inkrementelle Nachlieferung. Zudem sind spezielle, anwendungsspezifische Erweiterungen wie z.B. Funktionen und weitere Liniengeometrien definierbar. Dafür sollen aber Kontrakte, d.h. Vereinbarungen mit den Werkzeuganbietern, eingegangen werden.

Neu übernimmt die eXtensible Markup Language (XML) die Codierung für das INTERLIS-2-Transferformat. Durch die absehbare internationale Verbreitung von XML erwarten wir eine gute Akzeptanz dieses Formats und eine grosse Anzahl kompatibler Softwareprodukte.

Für den mit INTERLIS 1 vertrauten Benutzer ändert sich nicht viel, solange er die neuen Konzepte, wie Objekt-Orientierung oder Darstellungsbeschreibung, nicht nutzen will: Er kann seine bisherigen Kenntnisse in INTERLIS 2 weiterhin einsetzen. Werkzeuge, wie der frei erhältliche INTERLIS-2-Compiler, unterstützen ihn beim Umsteigen. Diejenigen Hersteller, welche bereits bei der Implementierung von INTERLIS 1 auf flexible Konfigurationsmöglichkeiten und auf die Regeln der Software-Entwicklungskunst (z.B. Modularisierung und Abstraktion) geachtet haben, werden ihre bisherigen Investitionen erhalten können; durch frei erhältliche Programmbibliotheken können sich die Softwarehersteller auf die Anbindung ihrer Systeme an INTERLIS 2 konzentrieren.

Ausblick

INTERLIS 1 erschien zu einem Zeitpunkt, in dem beispielsweise die relationale Datendefinitionssprache SQL-92 noch nicht standardisiert und von Objektorientierung noch kaum die Rede war. Einige dieser heute etablierten Konzepte hat der Urheber von INTERLIS 1, Joseph Dorfschmid, in vorausschauender Weise in die Sprache einfliessen lassen. Mit dem Überarbeitungsprozess und der Einbindung objekt-orientierter und spezifischer Informatikkonzepte hat INTERLIS einen neuen Reifegrad erreicht. INTERLIS 2 kann damit heute – und nicht erst morgen – als effizientes Werkzeug eingesetzt werden.

Es ist uns bewusst, dass die Suche nach der universellen Datenbeschreibungssprache noch nicht abgeschlossen ist. Jedes Zuwarten wäre aber mit ähnlichen Folgen verbunden, wie der kurzsichtige Umgang mit den Ressourcen unserer Erde. INTERLIS hat es verdient, nicht nur als Austauschformat sondern auch als nachhaltiges Werkzeug wahrgenommen zu werden: Mit INTERLIS bekam die Forderung nach nachhaltigem Umgang mit der Technik einen Namen!

Wabern, März 2016 / Rolf Zürcher

Anmerkung zur Version 2.1.0

Auch während der «Corona-Zeit 2021/22» wurde weiter intensiv an der Verbesserung von INTERLIS gearbeitet. Resultat sind die Ergebnisse des NGDI-Projekts 21-08 «Klärungen zum Umgang mit Geometrie in INTERLIS». Das Ergebnis sind Vorschläge, wie der Umgang mit Geometrien vereinfacht werden kann. Wesentliche Grundgedanken dabei waren: Die in INTERLIS bzw. in Systemen festgehaltene geometrische Beschreibung von Sachobjekten ist zwangsläufig mit Unsicherheiten behaftet, aber am Grundsatz von INTERLIS, nicht in die Systeme hinein zu regulieren, soll weiterhin festgehalten werden.

Daraus ergaben sich folgende, grundsätzlich neue Regelungen, um die das Referenzhandbuch in Kapitel 2.8, “Umgang mit Rundung von numerischen Werten und Koordinaten” (neu), Kapitel 3.1, “Verwendete Syntax”, Kapitel 3.2, “Grundsymbole der Sprache” und Kapitel 3.3, “Hauptregel” erweitert worden ist:

Umgang mit flachen Kreisbögen.
Flächenberandung gemäss OGC/ISO.
Hinweis betr. Umgang/Berechnung von Bogenmitten.
Präzisierung betr. Umgang mit Lücken in Gebietsnetzen.
Zusätzliche Funktionen (insbesondere für Flächeninhalt und Linienlänge) zur Verwendung für abgeleitete Attribute.

Wir sind überzeugt, dass INTERLIS damit neben seinen praktischen Vorzügen weiterhin auch ein höchst zeitgemässes Werkzeug im Umgang mit Geodaten bleibt.

Wabern, Januar 2024 / Frank Gottsmann

2. Grundprinzipien

2.1. Übersicht

INTERLIS dient der Zusammenarbeit von Informationssystemen, insbesondere von geografischen Informationssystemen oder Landinformationssystemen. Wie der Name sagt, steht INTERLIS zwischen (INTER) Land-Infomations-Systemen. Zentral hierfür ist, dass alle beteiligten Systeme eine klare Vorstellung von jenen Konzepten besitzen, die für die Zusammenarbeit relevant sind.

Abbildung 1. Datentransfer zwischen verschiedenen Datenbanken über gemeinsames Datenmodell (Datenschema) beschrieben mit gemeinsamer Datenbeschreibungssprache.

INTERLIS umfasst aus diesem Grund eine konzeptionelle Beschreibungssprache. Mit dieser Sprache kann der Ausschnitt der Realwelt beschrieben werden, der für eine bestimmte Anwendung von Interesse ist. Eine solche Beschreibung heisst (konzeptionelles) Anwendungsmodell oder Anwendungsschema, bzw. kurz Modell oder Schema. Mit wenigen Konzepten mit genau definierter Bedeutung werden Klassen von Objekten mit ihren Eigenschaften und ihren Beziehungen beschrieben (modelliert). Zudem erlaubt die Beschreibungssprache von INTERLIS, Klassen von abgeleiteten Objekten einzuführen, die als Sichten auf andere Klassen von Objekten definiert werden. Sowohl echte als auch abgeleitete Klassen von Objekten können als Grundlage von Darstellungsbeschreibungen dienen, wobei INTERLIS eine strikte Trennung von Darstellungsbeschreibung und Beschreibung der zu Grunde liegenden Datenstruktur (Objektmodell) sicherstellt.

INTERLIS ist nicht auf eine bestimmte Anwendung ausgerichtet. Beim Entwurf, der sich an allgemeinen objekt-orientierten Prinzipien orientiert, wurde jedoch darauf geachtet, dass jene Konzepte besonders gut unterstützt werden, die für geografische Informationssysteme wichtig sind. So sind Koordinaten, Linien und Flächen als Datentypen Grundkonstrukte von INTERLIS, und es stehen Sprachelemente zur Beschreibung von Messgenauigkeiten und Einheiten zur Verfügung. Dennoch können durchaus auch nicht-geografische Anwendungen mit INTERLIS bearbeitet werden.

Aspekte, die für ein Anwendungsgebiet grundlegend sind, können in einem Basismodell beschrieben werden. Dieses Basismodell wird anschliessend z.B. gemäss den spezifischen Bedürfnissen eines Landes, in weiteren Stufen gemäss denen einer bestimmten Gegend (wie Kanton, Region oder Gemeinde) spezialisiert (siehe Abbildung 2). INTERLIS 2 bietet als Mittel zur Spezialisierung die objekt-orientierten Konzepte der Vererbung und des Polymorphismus an. So ist sichergestellt, dass bereits erfolgte Definitionen nicht wiederholt werden müssen oder gar irrtümlicherweise in Frage gestellt werden können.

Das Hauptziel von INTERLIS ist die Interoperabilität von Daten. Daten, die in einem System gemäss einem konkreten INTERLIS-Modell erfasst wurden, sollen ohne Probleme in ein anderes System transferiert werden können. Da INTERLIS nicht unnötig in die Systeme hinein regeln will, können numerische Daten (inkl. Koordinaten und Linien) in Systemen, in den Transferdaten und in den Prüfprogrammen durchaus unterschiedlich gerundet sein. Damit dies nicht zu Problemen führt, wird der Rundungsproblematik speziell Rechnung getragen (vgl. Kapitel 2.8, “Umgang mit Rundung von numerischen Werten und Koordinaten”).

Abbildung 2. Spezialisierung der Modellierung eines Konzepts von Stufe Bund über kantonale (länderspezifische) bis lokale Stufe.

Grössere Anwendungen müssen nicht in einer einzigen Beschreibung definiert werden. Sie können vielmehr in mehrere Beschreibungseinheiten (Modelle, Schemas) aufgeteilt werden. Eine Beschreibungseinheit kann mehrere Themen umfassen. Im Interesse der Lesbarkeit der Modelle ist es auch möglich, Modelle als reine Übersetzungen von anderen Modellen zu definieren.

2.2. Nutzung von Modellen

Ein INTERLIS-Modell (bzw. INTERLIS-Schema) ist primär eine Verständigungshilfe für Anwender. Die Sprache ist so gestaltet, dass ein Modell leicht von Menschen gelesen werden kann. Dennoch sind INTERLIS-Modelle präzis, eindeutig und ohne Missverständnisse interpretierbar. Die textuelle INTERLIS-Sprache bietet sich daher geradezu an als notwendige Ergänzung der grafischen Beschreibungssprache Unified Modeling Language (UML, www.omg.org/uml).

INTERLIS geht aber noch einen Schritt weiter: Da ein Modell eine formal klar definierte Bedeutung besitzt, ist die Implementation eines Dienstes in einem Computersystem automatisch aus diesem (konzeptionellen) Modell ableitbar. Beispielsweise umfasst INTERLIS einen XML-basierten Transfer-Dienst, dessen Definitionen regelbasiert aus den jeweiligen Modellen erzeugt werden. Die Nutzung der Datenmodellierung in enger Verbindung mit systemneutralen Schnittstellendiensten nennt man den modell-basierten oder den modell-getriebenen Ansatz (siehe «Model-Driven Architecture» von OMG, www.omg.org/mda/).

Modelle können auf gemeinsamen Basiskonzepten aufbauen. Da INTERLIS erlaubt, dies durch die Benutzung von Vererbung und Polymorphismus explizit zu beschreiben, ist jederzeit klar, welche Konzepte gemeinsam und welche jeweils spezifisch sind. Dies ist im Hinblick auf eine angestrebte semantische Interoperabilität von grosser Bedeutung. Beispielsweise kann die Transferdatei einer Gemeinde problemlos von einer übergeordneten Verwaltungseinheit (Kanton, Bund) interpretiert werden, ohne dass sich die Beteiligten dafür auf ein einziges Modell einigen müssten. Es genügt, wenn jede Stufe ihr Modell auf jenem der übergeordneten Einheit aufbaut.

Es ist denkbar und durchaus erwünscht, dass neue Dienste auf der Basis von INTERLIS entwickelt werden. Dies wird erheblich durch einen INTERLIS 2-Compiler erleichtert. Dieses Programm liest und schreibt INTERLIS-Modelle, erlaubt deren Änderung und überprüft, ob Modelle den syntaktischen und semantischen Bedingungen von INTERLIS entsprechen. Dieser Compiler kann – gemäss dem aktuellen INTERLIS-Transferdienst mit XML – unter anderem aus INTERLIS-Modellen automatisch XML-Schema-Dokumente (www.w3.org/XML/Schema) generieren. Damit können die konkreten INTERLIS-XML-Daten durch entsprechende allgemeine XML-Werkzeuge noch breiter genutzt werden. Solange die Nutzungsbedingungen nicht verletzt werden, steht dieser INTERLIS-Compiler zum Erstellen neuer Werkzeuge zur Verfügung.

2.3. Gliederung in Modelle und Thema

In einem Modell (bzw. Schema) wird eine Vorstellung der Welt beschrieben, wie sie für eine bestimmte Anwendung von Bedeutung ist. Ein Modell ist in sich abgeschlossen, darf aber Teile von anderen Modellen verwenden oder erweitern. Ein INTERLIS-Modell ist dadurch in gewisser Weise mit den Modulen oder «Packages» mancher Programmiersprachen vergleichbar.

Primär können Modelle unterschieden werden, die nur typenmässige Definitionen (Einheiten, Wertebereiche, Strukturen) enthalten und solchen, zu denen Daten existieren können. Modelle enthalten nebst ihrem Namen auch einen Herausgeber und eine Versionsangabe. Die Beschreibungen, zu denen Daten existieren können, werden in Themen gegliedert. Diese Gliederung erfolgt gemäss den Vorstellungen, in welchen Organisationseinheiten und durch wen die Daten verwaltet und gebraucht werden. Daten, die typischerweise durch unterschiedliche Stellen verwaltet oder gebraucht werden, sollen auch in verschiedenen Themen definiert werden. Themen dürfen voneinander abhängig sein. Solche Abhängigkeiten sollen sich jedoch auf das Minimum beschränken. Beziehungen zwischen Themen, deren Daten durch verschiedene Stellen verwaltet werden, sollen möglichst vermieden werden, da für die Erhaltung der Konsistenz mit speziellem Aufwand zu rechnen ist. Zyklische Abhängigkeiten sind in jedem Fall ausgeschlossen. Themen können nebst den eigentlichen Datendefinitionen auch Definitionen für Sichten und Grafiken umfassen.

Ein Thema kann ein anderes erweitern. Damit werden alle Konzepte, welche das Basisthema definiert, übernommen und können ergänzt bzw. spezialisiert werden.

Beispielsweise könnte ein Modell der Amtlichen Vermessung eines Landes unter anderem die Themen «Adressen» und «Gebäude» umfassen (siehe Abbildung 3). Diese Konzepte sind voneinander unabhängig; der Bezug wird algorithmisch über Koordinaten hergestellt. Personen weisen Adressen auf, so dass das Personen-Modell dieses Landes auf dem Landesmodell der Amtlichen Vermessung aufbaut, wobei das Thema «Personen» vom Thema «Adressen» des Vermessungsmodells abhängt.

Abbildung 3. Vererbungs-Hierarchie von Adresse, Person und Gebäude.

Nun möchte man die Personen in einer Gegend A präziser beschreiben, als es das Landes-Personen-Modell vorsieht. Diese Gegend A verfasst daher ihr eigenes Modell, in dem das Thema «Personen» aus dem landesweiten Personen-Modell übernommen und erweitert wird.

In einer Gegend B will man einerseits eine explizite Beziehung zwischen Gebäuden und Adressen herstellen, andererseits wird auch hier das Landes-Personen-Modell als zu grob erachtet. Wiederum werden die jeweiligen Themen übernommen und spezialisiert. Beide Erweiterungen werden in einem einzigen Modell – der «Weltsicht» der Gegend B – zusammengefasst.

2.4. Objekt-Konzept

2.4.1. Objekte und Klassen

Ein Objekt (auch Objektinstanz oder einfach Instanz genannt) besteht aus den Daten eines Gegenstandes der realen Welt und ist eindeutig identifizierbar. Typischerweise besitzen zahlreiche Objekte gleichartige Eigenschaften und können daher zusammengefasst werden. Eine Menge von Objekten (Objektmenge) mit gleichartigen Eigenschaften wird als Klasse bezeichnet. Jeder Eigenschaft entspricht (mindestens) ein Attribut. INTERLIS 1 verwendete anstelle des Begriffs Klasse den Begriff Tabelle. Andere Begriffe für Klasse sind Entitätsmenge, Entitätstyp, Feature(typ).

Mit der Beschreibung einer Klasse wird unter anderem auch festgehalten, welche Eigenschaften oder Merkmale die einzelnen Objekte tragen. Diese werden Attribute genannt. Die Attributwerte der einzelnen Objekte sind dabei nicht beliebig, sondern müssen bestimmten Bedingungen genügen, die zur Beschreibung eines Attributes gehören.

INTERLIS bietet dafür eine Reihe von grundlegenden Datentypen an (Basis-Datentypen: Zeichenketten, numerische Datentypen, Aufzählungen, kartesische und elliptische 2D- bzw. 3D-Koordinaten, Linien, Flächen), auf deren Basis neue, komplexere Datenstrukturen definiert werden können. Um die Aussage noch zu präzisieren, können numerische Attribute mit einer Masseinheit versehen und auf ein Referenzsystem bezogen werden; Koordinaten können auf ein Koordinatensystem bezogen werden.

Datum und Zeit sind eigentlich Anwendungen von formatierten Wertebereichen. Weil Zeitangaben aber häufig vorkommen, wurde für Datum und Zeit eine eigene Struktur definiert (XMLTime, XMLDate und XMLDateTime).

Neben diesen Basis-Datentypen kann ein Attribut auch Unterstrukturen enthalten. Die einzelnen Elemente der Unterstruktur sind als Strukturelemente aufzufassen, die nur im Zusammenhang mit ihrem Hauptobjekt existieren und auch nur über dieses auffindbar sind. Der Aufbau der Strukturelemente wird ähnlich wie jener von Klassen beschrieben.

Abgesehen davon, dass alle Attributwerte ihrem jeweiligen Typ entsprechen müssen, können weitere Bedingungen formuliert werden. INTERLIS unterscheidet zwischen folgenden Arten von Konsistenzbedingungen:

Solchen, die sich auf ein einzelnes Objekt beziehen. Diese werden weiter untergliedert in Bedingungen, die jedes Objekt einer Klasse erfüllen muss («harte» Konsistenzbedingungen), und Bedingungen, deren Verletzung zwar an sich möglich, aber selten ist («weiche» Konsistenzbedingungen).
Solchen, welche die Eindeutigkeit von Attributkombinationen aller Objekte einer Klasse fordern.
Solchen, welche die Existenz eines Attributwertes in einer Instanz einer anderen Klasse fordern.
Kompliziertere Bedingungen, die sich auf Objektmengen beziehen und mittels Sichten formuliert werden.

2.4.2. Klassenerweiterung

Klassen sind entweder eigenständig oder erweitern (spezialisieren, erben) eine Basisklasse. D.h. die Beschreibung einer Klasse ist entweder unabhängig oder enthält Erweiterungen von einer anderen, ererbten Beschreibung. Eine Klassenerweiterung (auch Unterklasse oder Subklasse genannt) kann einerseits zusätzliche Attribute und Konsistenzbedingungen haben, andererseits übernommene Bedingungen (Datentypen, Konsistenzbedingungen) verschärfen.

Jedes einzelne Objekt gehört zu genau einer Klasse (man sagt auch: ist Objektinstanz oder Instanz einer Klasse). Es erfüllt aber immer auch sämtliche Bedingungen, welche die Basisklassen (d.h. die Oberklassen) stellen. Zu jeder Klasse gibt es eine Menge von Objekten, die Instanzen der Klasse oder einer ihrer Erweiterungen sind. Im Falle konkreter Klassen besteht eine normalerweise kleinere Untermenge von Instanzen, die exakt zu dieser Klasse gehören.

Die Elemente von Unterstrukturen sind keine eigentlichen selbständigen Objekte, sondern Strukturelemente und gehören damit auch nicht zur Menge der Instanzen irgendeiner Klasse.

2.4.3. Meta-Modelle und Meta-Objekte

Koordinaten- und Referenzsysteme sowie Grafiksignaturen stellen sich aus der Sicht der Anwendung als Modellelement (bzw. Schemaelement) dar, die in den Anwendungsdefinitionen verwendet werden können. Da aber verschiedene Koordinaten- und Referenzsysteme und vor allem verschiedene Grafiksignaturen auf die gleiche Art beschrieben werden können, macht es Sinn, ihre Eigenschaften ebenfalls innerhalb von Modellen mittels Klassen zu beschreiben. Jedem einzelnen System, bzw. jeder Grafiksignatur (z.B. ein Punktsymbol, eine Linienart) entspricht dann ein Objekt.

Meta-Objekte müssen in einem Meta-Modell definiert sein (s. Kapitel 3.10.1, “Allgemeine Aussagen zu Metaobjekten”). Die verwendbaren Objekte müssen explizit als Meta-Objekte gekennzeichnet sein (Erweiterungen der vordefinierten Klasse METAOBJECT) und können dann von der Anwendung über den Namen referenziert werden. Dafür ist es nötig, dass die Meta-Objekte dem Werkzeug, das die Anwendungsdefinition verarbeitet, mittels Behältern (vgl. Kapitel 2.4.5, “Behälter, Replikation und Datentransfer”) zur Verfügung stehen.

2.4.4. Beziehungen zwischen Objekten

INTERLIS 2 unterscheidet (im Gegensatz zu INTERLIS 1) zwei Arten von Beziehungen zwischen Objekten: eigentliche Beziehung und Referenzattribut.

Als eigentliche Beziehung wird eine Menge von Objektpaaren (bzw. im allgemeinen Fall von Objekt-n-Tupeln) bezeichnet. Das erste Objekt jedes Paares gehört zu einer ersten Klasse A, das zweite zu einer zweiten Klasse B. Dabei soll die Zuordnung von Objekten zu den Paaren vorgegeben sein, sie muss also nur beschrieben, d.h. modelliert werden. Wie weiter unten im Kapitel 2.5, “Sichten-Konzept” gezeigt wird, ist es im Gegensatz dazu auch möglich, Zuordnungen algorithmisch z.B. aufgrund von Attributwerten zu berechnen.

Eigentliche Beziehungen werden als eigenständige Konstrukte, so genannte Beziehungsklassen (bzw. Assoziationsklassen), beschrieben, die auch selbst wieder erweiterbar sind. INTERLIS 2 unterstützt nicht nur Zweierbeziehungen, sondern erlaubt auch mehrfache Beziehungen und solche mit eigenen Attributen. Eine Beziehungsklasse ist damit auch selbst wieder eine Objektklasse.

Wichtige Eigenschaften solcher Beziehungen sind:

Kardinalität – Wie viele Objekte der Klasse B (bzw. A) können einem Objekt der Klasse A (bzw. B) durch die Beziehung zugeordnet werden? D.h. wie viele Paare von Objekten kann es mit einem bestimmten Objekt an erster bzw. zweiter Stelle geben. Im allgemeinen Fall: Wie viele n-Tupel kann es mit bestimmten Objekten an n-1 Stellen geben?
Stärke – INTERLIS 2 unterscheidet zwischen Assoziation, Aggregation und Komposition. In allen Fällen sind die beteiligten Objekte individuell ansprechbar. Bei Assoziation und Aggregation existieren die beteiligten Objekte unabhängig voneinander. Bei Aggregation und Komposition gibt es eine Asymmetrie zwischen den beteiligten Klassen: Die Objekte der einen Klasse (der Oberklasse) werden als Ganze (bzw. als Oberobjekte)) bezeichnet, die Objekte der anderen Klasse (der Unterklasse) als Teile (bzw. als Unterobjekte). Bei Assoziation sind die Objekte gleichberechtigt und lose miteinander verbunden. Aggregation und Komposition sind konzeptionell gerichtete Beziehungen: Einem Ganzen (Oberobjekt der Oberklasse) sind mehrere Teile (Unterobjekte der Unterklasse) zugeordnet. Anders als bei der Assoziation werden im Fall der Aggregation beim Kopieren eines Ganzen auch alle zugeordneten Teile mitkopiert, während bei der Löschung des Ganzen die Teile erhalten bleiben. Für eine Komposition gilt gegenüber der Aggregation zusätzlich, dass im Falle der Löschung des Ganzen auch die Teile gelöscht werden. Wie sich Beziehungen zu anderen Objekten beim Kopieren verhalten, ist im Kapitel 3.7.2, “Stärke der Beziehung” beschrieben. Hinweis: Die Unterobjekte (Teile) von Kompositionen sind im Gegensatz zu Strukturelementen von Unterstrukturen identifizierbare Objekte.
Rolle – Welche Bedeutung besitzen die beteiligten Klassen aus der Sicht der Beziehung? Das wird für jede der beteiligten Klassen mit Hilfe der Rolle festgelegt.

Mit einem Referenzattribut wird der Bezug von einem Objekt bzw. einem Strukturelement zu einem anderen Objekt geschaffen. Eine solche Beziehung ist nur dem referenzierenden, nicht aber dem referenzierten Objekt bekannt. Sie ist also einseitig.

Ohne die Unabhängigkeit der Themen zu verletzen, können mittels spezieller Kennzeichnung (EXTERNAL) auch Beziehungen (d.h. eigentliche Beziehungen und Referenzattribute) definiert werden, die einen Bezug zu Objekten eines anderen Behälters des gleichen oder eines anderen Themas schaffen. Voraussetzung dazu ist allerdings, dass die Struktur, in der die Beziehung definiert wird, zu einem Thema gehört, das von demjenigen, zu dessen Klasse es verweist, abhängig ist.

Im Interesse einer klaren Ordnung können sich Beziehungen nur auf Klassen beziehen, die an der Stelle wo die Beziehungsklasse (bzw. das Referenzattribut) definiert wird, bereits bekannt sind.

2.4.5. Behälter, Replikation und Datentransfer

Als Behälter wird eine abgeschlossene Sammlung von Objekten bezeichnet, die zu einem Thema oder zu dessen Erweiterungen gehören. Abgeschlossen heisst, dass ein Behälter alle Objekte enthalten soll, die innerhalb des Themas zueinander in Beziehung stehen. Typischerweise wird ein Behälter alle Objekte einer bestimmten Gegend (z.B. einer Gemeinde, eines Kantons oder gar des ganzen Landes) enthalten. Ein Behälter kann insbesondere auch Daten verschiedener Erweiterungen (z.B. verschiedener Kantone mit eigenen Themenerweiterungen) enthalten. Dies bedingt allerdings, dass im Rahmen einer solchen Transfergemeinschaft, die Bezeichnungen der Modelle, Themen und Themenerweiterungen eindeutig sind.

Im Rahmen von Konsistenzbedingungen wird häufig von «allen» Objekten einer Klasse gesprochen. Konzeptionell meint man damit auch grundsätzlich alle Objekte, die die gewünschte Eigenschaft haben und die es überhaupt, d.h. behälterübergreifend gibt. Es ist aber aus verschiedenen Gründen (Effizienz, Verfügbarkeit, Zugriffsberechtigung, etc.) offensichtlich, dass eine Überprüfung nur innerhalb der lokal zugänglichen Behälter möglich ist. Im Falle von Behältern mit Meta-Objekten gelten die Konsistenzbedingungen ausdrücklich nur innerhalb eines Behälters, da davon ausgegangen wird, dass die Meta-Daten beschreibenden Charakter haben und deshalb jeweils vollständig (quasi als Bibliothek) in einem Behälter zur Verfügung stehen müssen.

Es werden verschiedene Arten von Behältern unterschieden:

Daten-Behälter – Umfasst die Instanzen von Klassen des Themas.
Sicht-Behälter – Umfasst die Instanzen von Sichten des Themas.
Behälter mit den Basis-Daten für die Grafik – Umfasst die Instanzen aller Daten oder Sichten, die für die Grafiken des Themas benötigt werden. Damit kann eine Grafik-Umsetzer-Software bedient werden.
Behälter mit den Grafik-Elementen – Umfasst die Instanzen aller Grafikobjekte (= Signaturen), die gemäss den Grafiken des Themas benötigt werden. Damit kann eine Grafik-Darstellungs-Software (Renderer) bedient werden (siehe Abbildung 5).

INTERLIS regelt nicht, wie die Objekte in den Systemen gehalten werden müssen. Die Regelungen betreffen nur die Schnittstelle zwischen den Systemen. Aktuell ist eine Schnittstelle zum Transfer von Behältern als XML-Dateien definiert. Dabei wird nicht nur der vollständige Transfer des ganzen Behälters, sondern auch die inkrementelle Nachlieferung unterstützt.

Beim vollständigen Transfer wird davon ausgegangen, dass der Empfänger neue, eigenständige Objektkopien aufbaut, die keinen unmittelbaren Zusammenhang zum Ursprungsobjekt aufweisen. Im Rahmen des vollständigen Transfers müssen die Objekte darum nur mit einer temporären Transferidentifikation (Transferidentifikator, abgekürzt TID) versehen werden. Diese wird zum Transferieren von Beziehungen genutzt.

Abbildung 4. Nachführung in der Primär-Datenbank und anschliessende Nachlieferung an Sekundär-Datenbanken (ein doppelter Pfeil bedeutet inkrementelle Nachlieferung).

Beim inkrementellen Transfer wird davon ausgegangen, dass der Sender einmal einen Initialzustand eines Datenbehälters (andere Behälterarten sind ausgeschlossen) liefert und den Empfänger anschliessend mit Nachlieferungen versorgt, die diesem erlauben, seine Daten zu aktualisieren (siehe Abbildung 4). Die Objekte werden damit repliziert und behalten den Zusammenhang zum Originalobjekt, d.h. sie können nicht unabhängig vom Original verändert werden und erhalten keine neue Identifikation.

Dabei geht man davon aus, dass zwischen den Betreibern der Primär- und der Sekundär-Datenbanken vertragliche Abmachungen getroffen werden (unter anderem Umfang, Häufigkeit der Nachlieferung), die aktuell nicht mit Instrumenten von INTERLIS beschrieben werden können. Für die eigentliche Nachlieferung stellt INTERLIS aber die nötigen Mittel zur Verfügung. Neue Objekte werden wie beim ersten Transfer mitgeteilt. Ihnen ist eine eindeutige Objektidentifikation (Objektidentifikator, abgekürzt OID) zugeordnet, die über die Zeit erhalten bleiben muss. Bei Änderungen wird auf diesen eindeutigen OID Bezug genommen und alle Attribute des Objektes (inkl. aller Strukturelemente von Strukturattributen) werden neu geliefert. Auf die gleiche Art werden auch Löschungen mitgeteilt. Dabei trägt primär der Sender die Verantwortung für die Konsistenz der Objekte (z.B. Einhaltung von Konsistenzbedingungen, Korrektheit und Kardinalität von Beziehungen). Er meldet dazu den Empfängern, welche Objekte geändert oder gelöscht und welche neu erzeugt wurden. Bei themenübergreifenden Referenzattributen wird – im Interesse der Unabhängigkeit der Themen – nicht vorausgesetzt, dass die Integrität jederzeit gewährleistet ist. Es ist Sache des Empfängers, damit zurechtzukommen, dass vorübergehend Inkonsistenzen zwischen Basisthemen und abhängigen Themen bestehen, d.h. dass ein referenziertes Objekt nicht existiert.

Der Rahmen, in dem die Eindeutigkeit des OID gewährleistet ist, ist durch INTERLIS selbst nicht bestimmt. Eine Möglichkeit, wie ein solcher OID aufgebaut sein kann, ist in Anhang F Aufbau von Objektidentifikatoren (OID) beschrieben. Andere Möglichkeiten sind aber ohne weiteres denkbar. Wichtig ist, dass der OID durch die verschiedenen Datenerfasser einer Transfergemeinschaft bei korrekter Anwendung der Regel zum Aufbau des OID immer im Rahmen der Transfergemeinschaft eindeutig ist. Je nach Aufbau des OID ist der inkrementelle Datenaustausch in einem grösseren (z.B. weltweit) oder in einem kleineren (z.B. organisationsintern) Rahmen möglich. Das gewählte Verfahren zur Bestimmung des OID definiert somit die potenzielle Transfergemeinschaft.

Ein Objekt darf nur in seinem Originalbehälter bzw. ausserhalb nur mit Erlaubnis dessen Verwalters verändert werden. Alle anderen, sekundären Behälter dürfen ein Objekt nur als Folge einer Nachlieferung verändern. INTERLIS 2 verlangt darum, dass – im Rahmen der inkrementellen Nachlieferung – nebst den Objekten auch die Behälter eindeutig und dauerhaft identifizierbar sein müssen. Die Behälter erhalten dann ebenfalls einen OID. Beim vollständigen Transfer braucht auch der Behälter nur eine Transferidentifikation (TID). Wo die Unterscheidung zum normalen OID (bzw. TID) wesentlich ist, wird vom Behälteridentifikator BOID (bzw. vom Behältertransferidentifikator BID) gesprochen.

Es muss davon ausgegangen werden, dass verschiedene Objekte zunächst in Behältern z.B. einer Gemeinde geführt werden, diese Behälter dann als Ganzes an den Kanton übermittelt und dort in Behälter, die pro Thema den ganzen Kanton enthalten, integriert werden. Allenfalls werden diese Behälter dann wieder z.B. an den Bund weitergegeben. Damit jederzeit klar ist, welches der Originalbehälter ist, wird dessen BOID bei jedem replizierten Objekt mitgegeben. Ein Empfänger kann damit eine Behälter-Verwaltung aufbauen, in dem er festhält, in welchen eigenen Behältern er replizierte Objekte von welchen Originalbehältern aufbewahrt (INTERLIS 2 bietet auch die nötigen Mittel an, dass solche Behälter mit INTERLIS selbst beschrieben und wie normale Objekte ausgetauscht werden können). Nutzt der Empfänger die Eigenschaft von INTERLIS 2, dass bei themenübergreifenden Beziehungen nicht nur die OID des Bezugsobjektes sondern auch die BOID dessen Originalbehälters transferiert wird, kann er auf effiziente Art bestimmen, in welchem seiner Behälter das Bezugsobjekt liegt.

2.5. Sichten-Konzept

Mit INTERLIS 2 können neben den eigentlichen Sachobjekten auch Sichten modelliert werden. Sichten sind im Prinzip virtuelle Klassen, deren Instanzen nicht Daten eines eigentlichen Gegenstandes der realen Welt sind, sondern rechnerisch aus anderen Objekten abgeleitet werden.

Eine Sichtdefinition besteht aus folgenden Teilen:

Basismengen – Von welchen Klassen bzw. Sichten fliessen die Objekte in die Berechnung der Sicht-Objekte ein? Bei Klassen werden jeweils nicht nur die eigentlichen Instanzen herangezogen, sondern auch im Sinne des Polymorphismus alle Instanzen von Erweiterungen. INTERLIS definiert nicht, welche Behälter ein System zum Errechnen einer Sicht berücksichtigen muss.
Verknüpfungsvorschrift – Wie werden die Basismengen verknüpft? INTERLIS 2 kennt Verbindungen (Join), Vereinigungen (Union), Zusammenfassungen (Aggregation) und Aufschlüsselungen (Inspection) von Unterstrukturen. Mengentheoretisch gesehen bilden Verbindungen das Kreuzprodukt und Vereinigungen die Vereinigungsmenge der Basismengen. Zusammenfassungen erlauben es, Objekte der Basismenge zu einem neuen Sichtobjekt zusammenzufassen, wenn sie definierbare Kriterien erfüllen. Inspektionen von Unterstrukturen ermöglichen es, die Strukturelemente einer Unterstruktur als Menge von Strukturelementen zu sehen. Verbindungen und Zusammenfassungen können auch als virtuelle Assoziationen aufgefasst werden.
Selektion – Welche errechneten Objekte sollen tatsächlich zur Sicht gehören? INTERLIS erlaubt es, hierfür komplexe Bedingungen anzugeben.

2.6. Grafik-Konzept

Darstellungsbeschreibungen bauen auf Klassen oder Sichten auf und deklarieren in so genannten Grafikdefinitionen (siehe Abbildung 5 und Anhang M Glossar) welche Grafiksignaturen (z.B. Punktsymbol, Linie, Flächenfüllung oder Textanschrift) den Objekten der Sicht zugeordnet werden sollen, damit ein Grafikumsetzer darstellbare Grafikobjekte erzeugen kann. Die Grafiksignaturen sind in einem eigenen Signaturenmodell definiert, wo auch die Signatur-Eigenschaften beschrieben sind.

Abbildung 5. Grafikdefinitionen, die einerseits auf Daten und Sichten und andererseits auf Signaturen aufbauen, um da-raus eine Grafik zu erzeugen (abstrahierte Darstellung).

Der Verweis auf die gefragten Grafiksignaturen erfolgt mittels Namen (siehe Signaturobjektnamen in Abbildung 5). Die Grafiksignaturen selbst (auch Signaturobjekte genannt) sind als Meta-Objekte (Daten) in entsprechenden Behältern enthalten. Einen Behälter mit solchen Signaturobjekten nennt man oft auch Signaturenbibliothek.

Im Signaturenmodell wird für jede Signaturart in der entsprechenden Signaturklassen-Definition festgelegt, welche Parameter (z.B. Lage und Orientierung einer Signatur) für die Darstellung nötig sind. Damit wird die Schnittstelle zum Grafiksubsystem (der Grafik-Umsetzer-Software) der jeweiligen Systeme nicht durch INTERLIS selbst, sondern durch die Signaturenmodelle festgelegt. In diesem Rahmen können zudem globale Laufzeit-Parameter deklariert werden (z.B. der Darstellungsmassstab), die zur Laufzeit dem Grafiksubsystem bekannt sind und den Entscheid, mit welchen Signaturen die Darstellung erfolgen soll, beeinflussen können.

Eine Darstellungsbeschreibung muss die Umsetzung in Signaturen nicht abschliessend regeln. Sie kann vielmehr durch eine andere Darstellungsbeschreibung geerbt werden. Darin können Parameter, die in Basisdefinitionen offen gelassen worden sind, ergänzt werden oder es können bereits erfolgte Darstellungsanweisungen ersetzt werden.

2.7. Dienste, Werkzeugfähigkeit und Konformität

INTERLIS 2 ermöglicht die konzeptionelle Beschreibung von Daten und definiert einen systemneutralen Daten-Transfer. INTERLIS 2 verzichtet bewusst darauf, die Implementation vorzuschreiben und bleibt damit systemunabhängig. In der Praxis wird sich damit häufig die Frage stellen, ob ein bestimmtes Werkzeug oder ein bestimmter Dienst INTERLIS 2-konform ist oder nicht.

INTERLIS 2 geht nicht davon aus, dass nur ein Ja (d.h. vollständige Erfüllung) oder ein Nein (d.h. Nichterfüllung) möglich ist. Vielmehr kann ein Dienst für bestimmte Aspekte INTERLIS 2-konform sein, während er andere Anforderungen nicht erfüllt.

Im einfachsten Fall erfüllt ein bestimmtes System die INTERLIS-Spezifikationen für einen bestimmten Fall (für eine bestimmte Menge von Modellen, nur für das Lesen oder nur für das Schreiben oder beides, etc.).

Im Idealfall kann einem INTERLIS-Werkzeug eine Menge von INTERLIS-Modellen übergeben und damit erreicht werden, dass das Werkzeug damit seine Dienste und Fähigkeiten automatisch der durch die Modelle definierten Situation anpasst. In vielen Fällen wird diese Anpassung jedoch mit weiteren manuellen Tätigkeiten (System-Konfigurierung oder gar Programmierung) verbunden sein. Zur Basisfunktionalität (Basisdienst) solcher Werkzeuge gehört sicher, dass sie INTERLIS-Modell-Beschreibungen korrekt einlesen können. Dazu gehört vor allem, dass die Systemfähigkeiten korrekt gemäss den INTERLIS-Konstrukten, insbesondere den Vererbungskonstrukten angeboten werden.

Aus der Sicht von INTERLIS können die Fähigkeiten solcher Werkzeuge wie folgt gegliedert werden (so genannte Werkzeugfähigkeiten, Funktionalitäten oder Dienste):

Daten einlesen (inkl. gespeicherte Sichten, ohne Sicht-Objekte erzeugen)
Daten einlesen (inkl. gespeicherte Sichten, mit Sicht-Objekte erzeugen)
Konsistenzen prüfen
Sichten (Views) schreiben
Grafik erzeugen (inkl. Sichten (Views) lesen)
Daten bearbeiten und schreiben
Objektidentifikatoren (OID) erzeugen
Nachlieferung lesen (inkrementelle Nachlieferung)
Nachlieferung schreiben (inkrementelle Nachlieferung)

Es ist auch durchaus möglich, dass ein bestimmtes Werkzeug oder ein bestimmter Dienst für einzelne Modelle und Themen (Daten oder Sichten) bestimmte Fähigkeiten (z.B. inkrementelle Nachlieferung) aufweist, sie aber bei anderen Modellen oder Themen nicht unterstützt.

Abbildung 6. Die verschiedenen Einsatzgebiete von INTERLIS (ein doppelter Pfeil bedeutet inkrementelle Nachlieferung).

Betrachtet man ein Beispiel des Zusammenwirkens verschiedener Beteiligter, ist es offensichtlich, dass je nach Einsatzgebiet und Rolle eines Beteiligten unterschiedliche Werkzeugfähigkeiten oder Dienste von INTERLIS 2 gefragt sind (siehe Abbildung 6). Ein einzelner Beteiligter kann in einer Anwendung (d.h. INTERLIS-Modell) mit verschiedenen Themen (TOPICS) mehrere Rollen einnehmen:

Erstdatenerfasser – Daten bearbeiten und schreiben; gegebenenfalls OID erzeugen.
Geodatenveränderer (Nachführen, Ergänzen) – Daten einlesen; Daten bearbeiten und schreiben; OID erzeugen; Inkremente produzieren; Inkremente lesen; Konsistenzen (lokal) prüfen.
Geodatenverwalter/Geodatenzentrale – Daten einlesen; Daten bearbeiten und schreiben; OID erzeugen; Inkremente lesen; Konsistenzen prüfen (global).
Geodatenabnehmer – Daten einlesen; Inkremente lesen.
Geodatenviewer – Daten einlesen; Sicht-Objekte und grafische Darstellungen erzeugen.
Planproduzent – Daten einlesen; Inkremente lesen; Sichten lesen und grafische Darstellungen erzeugen.

2.8. Umgang mit Rundung von numerischen Werten und Koordinaten

In INTERLIS wird von numerischen Werten, von Punkten, Linien und Flächen / Flächennetzen gesprochen. Dabei kann definiert werden, welche Stellenzahl die Werte aufweisen sollen. Da INTERLIS nicht in die Systeme hinein regulieren will, ist es den Systemen überlassen, wie sie die Werte (Zahlen, Koordinaten) intern speichern. Die Speicherung muss nur in der Lage sein, Werte gemäss der Wertebereichdefinition festzuhalten.

Numerische Werte weisen in digitaler Form eine endliche Genauigkeit auf, die von der Form der Speicherung abhängt. Für 2D-Koordinaten kann man sich bildlich ein kariertes Papier („Hüslipapier“) vorstellen: Speicherbare Koordinaten können nur auf den Kreuzungspunkten der Karo-Linien liegen.

Betrachtet man nun eine gespeicherte Gerade, deren Anfangs- und Endpunkte auf Kreuzungspunkten unterschiedlicher Karo-Linien liegen, und teilt diese an einer Zwischen-Stelle auf, ergibt sich (ausser in Ausnahmefällen) geometrisch ein Punkt, der im Innern eines Karos liegt. Um ihn zu speichern, wird zwangsläufig auf den nächstliegenden Kreuzungspunkt gerundet. Eine berechnete Koordinate liegt also (ausser in Ausnahmefällen) nicht exakt an der Stelle des geometrischen Ortes, für den sie berechnet wurde. Dies führt insbesondere bei Berechnungen, welche die Koordinaten nutzen, zwangsläufig zu Differenzen.

Typische Folgen der Rundung sind etwa:

Punkte können zu einem Punkt zusammenfallen
Kreisbogen-Overlaps ausserhalb der Toleranz
Verlangte Schnittfreiheit von Linien nicht mehr erfüllt
Abgeleitete Attribute (insbesondere Längen, Flächenmasse) stimmen nicht mehr mit der geometrischen Auswertung überein

Mit einer höheren Speichergenauigkeit können solche Probleme auch nicht behoben werden. Es sinkt nur die Wahrscheinlichkeit, dass solche Differenzen als störend betrachtet werden. Numerische Werte werden darum im INTERLIS2-Transfer gemäss der Wertebereichsdefinition im Daten-Modell dargestellt. Konsistenzbedingungen müssen mit den gerundeten Werten (auf- oder abgerundet) eingehalten sein. Funktional abgeleitete Attribute müssen (sofern nicht transient) dem auf- oder abgerundeten Funktionswert entsprechen. Prüfprogramme müssen also bei ihrer Prüfung auf- und abgerundete Werte als in Ordnung taxieren.

2.9. Das kleine Beispiel Roads als Einstieg

Im Appendix E, Das kleine Beispiel Roads (informativ) ist ein kleines Beispiel beigefügt, das die wichtigsten INTERLIS-Sprachelemente im Rahmen einer einfachen Anwendung vorstellt.

Abbildung 7. Das kleine Beispiel Roads.

2.10. Weitere Gliederung des Referenzhandbuchs

Im nächsten Kapitel 3 wird die Beschreibungssprache formal definiert. Im Kapitel 4 wird der sequentielle Transfer von Geodaten spezifiziert. Dieses Kapitel enthält einen allgemeinen Teil, der für alle aktuellen und künftigen sequentiellen INTERLIS 2-Transferdienste gilt und einen speziellen Teil, der für den INTERLIS 2-Transferdienst mit XML gilt.

Die Anhänge gliedern sich in vier normative Anhänge A bis D, ergänzt durch einen informativen Anhang E, in die Standard-Erweiterungsvorschläge F bis L sowie ein Glossar (Anhang M) und einen Index (Anhang N).

Die normativen Anhänge sind integrierender Bestandteil dieser Spezifikation. Die Standard-Erweiterungsvorschläge (Anhänge F bis L) sind sehr zur Implementation empfohlen. Es sind dies informative (nicht-normative) Anhänge mit eigenständigem Charakter. Die entsprechenden Fragestellungen können von Implementationen auch anders gelöst werden, sie sind dadurch immer noch INTERLIS 2-konform. In diesen Fällen ist es dann aber Sache der am Transfer Beteiligten, sich über die Spezifikation zu einigen.

3. Beschreibungssprache

3.1. Verwendete Syntax

Zur Festlegung des konzeptionellen Datenmodells (Datenschemas) und der Transferparameter eines Datentransfers wird in den folgenden Kapiteln eine formale Sprache definiert. Diese Sprache ist selbst formal definiert. Syntaxregeln beschreiben dabei die zulässige Reihenfolge von Symbolen.

Die Beschreibung folgt damit der Art und Weise, die bei der Beschreibung moderner Programmiersprachen üblich ist. Hier wird deshalb nur eine knappe, für das Verständnis nötige Darstellung angegeben. Für Einzelheiten wird auf die Literatur verwiesen. Eine kurze Einführung befindet sich z.B. in «Programmieren in Modula-2» von Niklaus Wirth.

Eine Formel wird im Sinne der erweiterten Backus-Naur-Notation (EBNF) wie folgt aufgebaut:

Formel-Name = Formel-Ausdruck.

Der Formel-Ausdruck ist eine Kombination von: - fixen Wörtern (inkl. Spezialzeichen) der Sprache. Sie werden in Apostrophe eingeschlossen, z.B. 'BEGIN'. - Referenzen von anderen Formeln durch Angabe des Formelnamens.

Als Kombination kommen in Frage:

Aneinanderreihung

a b c         zuerst a, dann b, dann c.

Gruppierung

( a )         runde Klammern gruppieren Formel-Ausdrücke.

Auswahl

a | b | c     a, b oder c.

Option

[ a ]         a oder nichts (leer).

Fakultative Wiederholung

{ a }         beliebige Folgen von a oder nichts (leer).

Obligatorische Wiederholung (als Zusatz zur EBNF)

(* a *)       beliebige Folge von a, aber mindestens eins.

Beispiele von Formel-Ausdrücken:

(a|b)(c|d)    ac, ad, bc oder bd
a[b]c         abc oder ac
a{ba}         a, aba, ababa, abababa, ...
{a|b}c        c, ac, bc, aac, abc, bbc, bac, ...
a(*b*)        ab, abb, abbb, abbbb, ...
(*ab|[c]d*)   ab, d, cd, abd, dab, cdab, ababddd, cdababcddcd, ...

Häufig möchte man eine syntaktisch gleiche Formel in verschiedenen Zusammenhängen, für verschiedene Zwecke verwenden. Um diesen Zusammenhang auch ausdrücken zu können, müsste man eine zusätzliche Formel schreiben:

Example = 'CLASS' Classname '=' Classdef.
Classname = Name.

Damit dieser Umweg vermieden werden kann, wird folgende abgekürzte Schreibweise angewendet:

Example = 'CLASS' Class-Name '=' Classdef.

Die Formel Class-Name wird nicht definiert. Syntaktisch kommt direkt die Regel "Name" zur Anwendung (vgl. Kapitel 3.2.2, “Namen”). Von der Bedeutung her ist der Name jedoch ein Klassenname. "Class" wird damit quasi zu einem Kommentar.

3.2. Grundsymbole der Sprache

Die Beschreibungssprache weist die folgenden Symbol-Klassen auf: Namen, Zeichenketten, Zahlen, Erläuterungen, Sonderzeichen, reservierte Wörter und Kommentare.

3.2.1. Zeichenvorrat, Zwischenräume und Zeilenenden

Die eigentliche Sprache verwendet nur die druckbaren US-ASCII-Zeichen (32 bis 126). Welche Zeichen nebst dem Leerzeichen als Zwischenräume gelten, ist durch die konkrete Compiler-Implementation festzulegen. Diese legt auch fest, welche Zeichen oder Zeichenkombinationen als Zeilenende gelten. Wie die Zeichen gespeichert werden (Zeichensatz) ist Sache der Implementation des Compilers. Sie kann insbesondere je nach Plattform unterschiedlich sein.

Im Rahmen von Kommentaren dürfen auch weitere Zeichen (z.B. Umlaute und Akzente) vorkommen.

3.2.2. Namen

Ein Name ist definiert als eine Folge von maximal 255 Buchstaben, Ziffern und Unterstrichen, wobei das erste Zeichen ein Buchstabe sein muss. Gross- und Kleinbuchstaben werden dabei unterschieden. Namen, die mit reservierten Wörtern der Sprache (vgl. Kapitel 3.2.7, “Sonderzeichen und reservierte Wörter”) zusammenfallen, sind unzulässig.

※

Syntaxregeln:

Name = Letter { Letter | Digit | '_' }.
Letter = ( 'A' | .. | 'Z' | 'a' | .. | 'z' ).
Digit = ( '0' | '1' | .. | '9' ).
HexDigit = ( Digit | 'A' | .. | 'F' | 'a' | .. | 'f' ).

Näheres zur Eindeutigkeit und zum Gültigkeitsbereich von Namen ist im Kapitel 3.5.4, “Namensräume” beschrieben.

3.2.3. Zeichenketten

Zeichenketten (Strings) kommen im Zusammenhang mit Konstanten vor. Sie beginnen und enden mit einem Anführungszeichen und dürfen sich nicht über mehrere Zeilen erstrecken. \" steht für ein Anführungszeichen und \\ für einen «Backslash» innerhalb des Strings.

Eine Sequenz von \u, unmittelbar gefolgt von exakt vier Hexadezimalziffern, steht für ein beliebiges Unicode-Zeichen. Zeichen ab U+10000 sind wie in der UTF-16-Codierung mit zwei Surrogatcodes zu bezeichnen (siehe https://www.unicode.org).

※

Syntaxregel:

String = '"' { <any character except '\' or '"'>
             | '\"'
             | '\\'
             | '\u' HexDigit HexDigit HexDigit HexDigit
             } '"'.

3.2.4. Zahlen

Zahlen kommen in verschiedener Weise vor: Positive ganze Zahlen inklusive 0 (PosNumber), ganze Zahlen (Number), Dezimalzahlen (Dec) und strukturierte Zahlen. Bei Dezimalzahlen kann die Skalierung als Zehnerpotenz angegeben werden (z.B. 1E2 ist 100, 1E-1 ist 0.1). Strukturierte Zahlen machen nur im Zusammenhang mit entsprechenden Einheiten und Wertebereichen (z.B. Uhrzeit) einen Sinn. Wesentlich ist der Wert der Zahl, nicht deren Darstellung. So ist etwa 007 dieselbe Zahl wie 7.

※

Syntaxregeln:

PosNumber = (* Digit *).
Number = [ '+' | '-' ] PosNumber.
Dec = ( Number [ '.' PosNumber ] | Float ).
Float = [ '+' | '-' ] '0.' ( ( '1' | '2' | .. | '9' ) [ PosNumber ]
                             | (* '0' *) ) Scaling.
Scaling = ( 'e' | 'E' ) Number.

Beispiele:

PosNumber:   5134523              1           23
Number:          123           -435        +5769
Dec:         123.456     0.123456e4    -0.123e-2
Float:         0.1e7   -0.123456E+4   0.987e-100

3.2.5. Eigenschaftsmengen

Für verschiedene Zwecke müssen einem Beschreibungsgegenstand Eigenschaften zugeordnet werden. Dies kann mit einer generellen Syntax erfolgen:

※

Syntaxregel:

Properties = [ '(' Property { ',' Property } ')' ].

Um zu definieren, dass an einer bestimmten Stelle einer Syntaxregel solche Eigenschaften definiert werden sollen, wird in der Syntax folgendes Konstrukt eingefügt:

'Properties' '<' Property-Keyword { ',' Property-Keyword } '>'

Man schreibt also "Properties" und definiert in spitzen Klammern die zulässigen Schlüsselwörter. Nimmt man als Beispiel die Regel ClassDef (vgl. Kapitel 3.5.3, “Klassen und Strukturen”) werden mit "Properties<ABSTRACT,EXTENDED,FINAL>" die Schlüsselwörter "ABSTRACT", "EXTENDED" und "FINAL" für die Beschreibung von Eigenschaften akzeptiert. In einer INTERLIS 2-Definition wären dann unter anderem folgende Definitionen möglich:

CLASS A (ABSTRACT) = .....
CLASS A (EXTENDED, FINAL) = .....

3.2.6. Erläuterungen

Erläuterungen werden dort verlangt, wo ein Sachverhalt näher beschrieben werden muss. Aus der Sicht des Standard-Mechanismus wird die Erläuterung nicht weiter interpretiert, also als Kommentar aufgefasst. Es ist aber durchaus zulässig, Erläuterungen detaillierter zu formalisieren und damit einer weitergehenden maschinellen Verarbeitung zugänglich zu machen. Als Anfang und Abschluss einer Erläuterung wurde // gewählt. Innerhalb der Erläuterung dürfen zwei aufeinander folgende Schrägstriche nie vorkommen.

※

Syntaxregel:

Explanation = '//' any character except // '//'.

3.2.7. Sonderzeichen und reservierte Wörter

Sonderzeichen und reservierte Wörter sind in den Syntaxregeln der Sprache (nicht aber bei einer Datenbeschreibung) immer zwischen Apostrophen geschrieben, z.B. ',' oder 'MODEL'. Die reservierten Wörter werden grundsätzlich mit Grossbuchstaben geschrieben. Konflikte zwischen Namen und reservierten Wörtern sind vermeidbar, wenn Namen nicht ausschliesslich aus Grossbuchstaben bestehen. Es werden folgende reservierten Wörter verwendet (einige davon wurden in INTERLIS 1 bzw. 2.3 benutzt und bleiben aus Gründen der Kompatibilität reserviert; sie sind nicht fett und kursiv dargestellt):

Tabelle 1. Reservierte Wörter in INTERLIS 2.
`ABSTRACT`	`ACCORDING`	`AGGREGATES`	`AGGREGATION`
`ALL`	`AND`	`ANY`	`ANYCLASS`
`ANYSTRUCTURE`	`ARCS`	`AREA`	`AS`
`ASSOCIATION`	`AT`	`ATTRIBUTE`	`ATTRIBUTES`
`BAG`	`BASE`	`BASED`	`BASKET`
`BINARY`	`BLACKBOX`	`BLANK`	`BOOLEAN`
`BY`	`CARDINALITY`	`CHARSET`	`CIRCULAR`
`CLASS`	`CLOCKWISE`	`CODE`	`CONSTRAINT`
`CONSTRAINTS`	`CONTEXT`	`CONTINUE`	`CONTINUOUS`
`CONTOUR`	`CONTRACTED`	`COORD`	`COORD2`
`COORD3`	`COUNTERCLOCKWISE`	`DATE`	`DATETIME`
`DEFAULT`	`DEFERRED`	`DEFINED`	`DEGREES`
`DEPENDS`	`DERIVATIVES`	`DERIVED`	`DIM1`
`DIM2`	`DIRECTED`	`DOMAIN`	`END`
`ENUMTREEVAL`	`ENUMVAL`	`EQUAL`	`EXISTENCE`
`EXTENDED`	`EXTENDS`	`EXTERNAL`	`FINAL`
`FIRST`	`FIX`	`FONT`	`FORM`
`FORMAT`	`FREE`	`FROM`	`FUNCTION`
`GENERIC`	`GENERICS`	`GRADS`	`GRAPHIC`
`HALIGNMENT`	`HIDING`	`I16`	`I32`
`IDENT`	`IMPORTS`	`IN`	`INHERITANCE`
`INSPECTION`	`INTERLIS`	`JOIN`	`LAST`
`LINE`	`LINEATTR`	`LINESIZE`	`LIST`
`LNBASE`	`LOCAL`	`MANDATORY`	`METAOBJECT`
`MODEL`	`MTEXT`	`MULTIAREA`	`MULTICOORD`
`MULTIPOLYLINE`	`MULTISURFACE`	`NAME`	`NO`
`NOINCREMENTALTRANSFER`	`NOT`	`NULL`	`NUMERIC`
`OBJECT`	`OBJECTS`	`OF`	`OID`
`ON`	`OPTIONAL`	`OR`	`ORDERED`
`OTHERS`	`OVERLAPS`	`PARAMETER`	`PARENT`
`PERIPHERY`	`PI`	`POLYLINE`	`PROJECTION`
`RADIANS`	`REFERENCE`	`REFSYS`	`REFSYSTEM`
`REQUIRED`	`RESTRICTION`	`ROTATION`	`SET`
`SIGN`	`STRAIGHTS`	`STRUCTURE`	`SUBDIVISION`
`SURFACE`	`SYMBOLOGY`	`TABLE`	`TEXT`
`THATAREA`	`THIS`	`THISAREA`	`TID`
`TIDSIZE`	`TIMEOFDAY`	`TO`	`TOPIC`
`TRANSFER`	`TRANSIENT`	`TRANSLATION`	`TYPE`
`UNDEFINED`	`UNION`	`UNIQUE`	`UNIT`
`UNQUALIFIED`	`URI`	`VALIGNMENT`	`VERSION`
`VERTEX`	`VERTEXINFO`	`VIEW`	`WHEN`
`WHERE`	`WITH`	`WITHOUT`	`XMLNS`

3.2.8. Kommentare

Es werden zwei Kommentarformen angeboten:

3.2.8.1. Zeilenkommentar

Ein Zeilenkommentar wird mit zwei Ausrufezeichen eröffnet, die unmittelbar aufeinander folgen. Der Zeilenkommentar wird durch das Zeilenende abgeschlossen.

※

Syntaxregel:

!! Line comment; goes until end of line

3.2.8.2. Blockkommentar

Der Blockkommentar wird durch einen Schrägstrich und einen Stern eingeleitet; abgeschlossen wird er durch einen Stern und einen Schrägstrich. Er darf sich über mehrere Zeilen hinweg erstrecken und seinerseits Zeilenkommentare enthalten. Geschachtelte Blockkommentare sind zugelassen.

※

Syntaxregel:

/* Block comment,
    additional line comment */

3.3. Hauptregel

Jede Beschreibungseinheit beginnt mit der Angabe der Sprach-Version. Damit wird die Basis für spätere Sprachzusätze gelegt. Die in diesem Dokument beschriebene Version von INTERLIS ist 2.4.

Nachher folgen die Modellbeschreibungen.

※

Syntaxregel:

INTERLIS2Def = 'INTERLIS' Version-Dec ';'
               { ModelDef }.

3.4. Vererbung

Verschiedene Konstrukte von INTERLIS können im Sinne der objekt-orientierten Denkweise erweitert werden: Eine erste Definition schafft die Grundlage, die dann in mehreren Schritten spezialisiert werden kann.

Themen, Klassen, Sichten, Grafikdefinitionen, Einheiten und Wertebereiche können die entsprechenden Grundkonstrukte erweitern (Schlüsselwort EXTENDS bzw. EXTENDED) und erben damit alle ihre Eigenschaften. Ein zuvor definiertes Konstrukt kann in bestimmten Fällen durch Angabe von EXTENDED unter Beibehaltung des Namens erweitert werden.

Mit FINAL wird das Erweitern einer Definition verhindert. Verschiedene Konstrukte können in einer noch unvollständigen Form (Schlüsselwort ABSTRACT) definiert werden; sie werden später in einer Erweiterung zu einer konkreten Definition ergänzt.

Um die in einem bestimmten Kontext zulässigen Schlüsselwörter anzugeben, wird jeweils die generelle Property-Schreibweise verwendet (vgl. Kapitel 3.2.5, “Eigenschaftsmengen”).

3.5. Modelle, Themen, Klassen

3.5.1. Modelle

Als Modell wird eine in sich geschlossene, vollständige Definition bezeichnet. Je nach Art des Modells kann es verschiedene Konstrukte enthalten.

Ein reines Typenmodell (TYPE MODEL) darf nur Masseinheiten, Wertebereiche, Funktionen und Linienformen deklarieren.

Ein Referenzsystem-Modell (REFSYSTEM MODEL) soll nebst den Definitionen eines Typenmodells nur Themen und Klassen deklarieren, die im Bezug zu Erweiterungen der vordefinierten Klassen AXIS bzw. REFSYSTEM stehen (vgl. Kapitel 3.10.3, “Referenzsysteme”). Die Einhaltung dieser Regel kann durch die Sprache nicht erzwungen werden. Es ist Sache des Anwenders, sich daran zu halten.

Ein Signaturenmodell (SYMBOLOGY MODEL) soll nebst den Definitionen eines Typenmodells nur Themen und Klassen, die im Bezug zu Erweiterungen der vordefinierten Klasse SIGN stehen, sowie Laufzeitparameter deklarieren (vgl. Kapitel 3.16, “Darstellungsbeschreibungen” und Kapitel 3.11, “Laufzeitparameter”). Die Einhaltung dieser Regel ist ebenfalls Sache des Anwenders.

Wird keine solche einschränkende Modelleigenschaft definiert, darf ein Modell alle möglichen Konstrukte enthalten.

Nach dem Modellnamen kann optional die Sprache angegeben werden. Wenn möglich sollte die Angabe anhand der durch die ISO-Norm 639 standardisierten zwei-buchstabigen Bezeichnungen in Kleinbuchstaben erfolgen (siehe https://www.iso.org); zum Beispiel steht "de" für Deutsch, "fr" für Französisch, "it" für Italienisch, "rm" für Rätoromanisch und "en" für Englisch. Durch einen Unterstrich getrennt darf ein Ländercode gemäss ISO-Norm 3166 nachgestellt werden, um die in einem bestimmten Land benutzte Varietät einer Sprache zu bezeichnen: "de_CH" steht für das in der Schweiz verwendete (Schrift-)Deutsch. Diese Angabe hat dokumentarischen Wert. Sie steht im Zusammenhang mit der Möglichkeit, ein Modell als eine Übersetzung eines anderen zu deklarieren (TRANSLATION OF). Die beiden Modelle müssen dann strukturell exakt übereinstimmen. Sie dürfen sich also nur in den verwendeten Namen unterscheiden. Die Deklaration als Übersetzung ist aber nicht an die Sprachangabe gebunden. Um z.B. lokale oder branchenspezifische Sprachgebräuche zu unterstützen, sind insbesondere auch Übersetzungen in die gleiche Sprache wie die Ursprungsbeschreibung zulässig.

Mit der Angabe NOINCREMENTALTRANSFER wird definiert, dass beim Datentransfer (vgl. Kapitel 4, Sequentieller Transfer) kein inkrementeller Transfer unterstützt werden muss.^[1] Insbesondere enthält das aus dem Modell generierte XML-Schema keine entsprechenden Möglichkeiten.

Anschliessend wird mittels Angabe des entsprechenden URI (vgl. Kapitel 3.2.3, “Zeichenketten”) der Herausgeber des Modells identifiziert. Es wird erwartet, dass der Modellname in diesem Kontext eindeutig ist.

※

Syntaxregel:

ModelDef = [ 'CONTRACTED' ] [ 'TYPE' | 'REFSYSTEM' | 'SYMBOLOGY' ]
           'MODEL' Model-Name [ '(' Language-Name ')' ]
           [ 'NOINCREMENTALTRANSFER' ]
             'AT' URI-String
             'VERSION' ModelVersion-String [ Explanation ]
           [ 'TRANSLATION' 'OF' Model-Name '[' ModelVersion-String ']' ]
             '='
               [ 'CHARSET' IANA-Name-String ';' ]
               [ 'XMLNS' XMLNS-String ';' ]
               { 'IMPORTS' [ 'UNQUALIFIED' ] Model-Name
               { ',' [ 'UNQUALIFIED' ] Model-Name } ';' }
               { MetaDataBasketDef
               | UnitDef
               | FunctionDef
               | LineFormTypeDef
               | DomainDef
               | ContextDef
               | RunTimeParameterDef
               | ClassDef
               | StructureDef
               | TopicDef }
           'END' Model-Name '.'.

Mit der Modellversion können verschiedene Versionen (insbesondere verschiedene Entwicklungsstufen) eines Modells unterschieden werden. In der Erläuterung können zusätzliche Angaben wie Hinweise zur Kompatibilität mit früheren Versionen gemacht werden. In einem bestimmten Zeitpunkt soll aber nur eine Modellversion bestehen. Deshalb wird beim Import von Modellen auch keine Version angegeben. Ist ein Modell eine Übersetzung eines anderen, ist dessen Version in eckigen Klammern anzugeben. Mit der Versionsangabe im Rahmen einer Übersetzungsdefinition (TRANSLATION OF) wird nur dokumentiert, auf Grund welcher Basisversion die Übersetzung erstellt wurde und mit welcher sie also auch strukturell exakt übereinstimmt.

Das Schlüsselwort CONTRACTED hat keine Funktion mehr, bleibt zur Kompatibilität hier aber zulässig.

Optional kann - eingeleitet durch das Schlüsselwort CHARSET - der Name eines Zeichensatzes definiert werden. Zulässige Namen werden durch IANA festgelegt.^[2] Fehlt die Angabe, gilt der Zeichensatz gemäss Anhang D. Die Definition des Zeichensatzes definiert den Umfang an Zeichen die eine Software verarbeiten (wie z.B. Speichern, Suchen, Sortieren, Ausdrucken) können muss und nicht den im Transfer zulässigen Zeichensatz oder die zulässige Zeichencodierung (vgl. Kapitel 4.3.2, “Zeichencodierung”).

Mit der Angabe nach XMLNS kann optional für den XML-Transfer gemäss Kapitel 3 der XML-Namensraum^[3] festgelegt werden.^[4] Ohne Angabe ergibt sich der XML-Namensraum nach einer fixen Regel (vgl. Kapitel 4, Sequentieller Transfer) aus dem Namen des Modells.

Bezieht sich ein INTERLIS-Konstrukt auf eine Definition, die in einem anderen Modell vorgenommen wurde, muss dieses Modell importiert werden (Schlüsselwort IMPORTS). So können beispielsweise Themen erweitert und der Bezug auf Klassen geschaffen werden. IMPORTS eröffnet aber nur die Möglichkeit des Gebrauchs. Bei der Verwendung der importierten Definitionen, sind diese dennoch mit qualifiziertem Namen (Modell, Thema) zu referenzieren, ausser man verwendet das Schlüsselwort UNQUALIFIED. Themen gehören nur dann zu einem Modell (und können entsprechend Kapitel 4.3.6, “Codierung von Themen” transferiert werden), wenn sie innerhalb dieses Modells definiert sind (Regel TopicDef).

Mit der Sprache verbunden ist auch ein vordefiniertes Basis-Modell "INTERLIS" (vgl. Anhang A Das interne INTERLIS-Datenmodell). Dieses muss nicht importiert werden. Hingegen stehen auch dessen Elemente nur dann mit unqualifizierten Namen zur Verfügung, wenn das Modell mit IMPORTS UNQUALIFIED INTERLIS eingeführt wird.

3.5.2. Themen

Ein Thema (Schlüsselwort TOPIC) enthält alle zur Beschreibung eines bestimmten sachlichen Teils der Realwelt nötigen Definitionen. Ein Thema kann auch Typen wie Masseinheiten, Wertebereiche oder Strukturen definieren oder diese vom umhüllenden Modell oder einem importierten Modell benützen. In runden Klammern können die Vererbungseigenschaften definiert werden. Enthält ein Thema abstrakte Definitionen, die nicht im selben Thema konkretisiert werden, muss das Thema als ABSTRACT deklariert werden. Abstrakte Definitionen müssen dann in konkreten Erweiterungen des Themas noch konkretisiert werden. Für einen Datentransfer braucht es ein konkretes Thema. Da sich eine Erweiterung eines Themas immer auf ein Thema mit einem anderen Namen bezieht, macht EXTENDED keinen Sinn und ist deshalb nicht zulässig.

※

Syntaxregeln:

TopicDef = [ 'VIEW' ] 'TOPIC' Topic-Name
               Properties<ABSTRACT,FINAL>
               [ 'EXTENDS' TopicRef ] '='
                   [ 'BASKET' 'OID' 'AS' OID-DomainRef ';' ]
                   [ 'OID' 'AS' OID-DomainRef ';' ]
                   { 'DEPENDS' 'ON' TopicRef { ',' TopicRef } ';' }
                   [ 'DEFERRED' 'GENERICS'
                        GenericRef { ',' GenericRef } ';' ]
                   Definitions
           'END' Topic-Name ';'.

Definitions = { MetaDataBasketDef
              | UnitDef
              | FunctionDef
              | DomainDef
              | ClassDef
              | StructureDef
              | AssociationDef
              | ConstraintsDef
              | ViewDef
              | GraphicDef }.

TopicRef = [ Model-Name '.' ] Topic-Name.

GenericRef = GenericCoordType-DomainRef.

Zu einem bestimmten Thema, das konkrete Klassen enthält, können beliebig viele Behälter (Datenbanken etc.) existieren. Sie weisen alle die dem Thema entsprechende Struktur auf, enthalten aber unterschiedliche Objekte.

In einem Datenbehälter kommen dabei nur die Instanzen von Klassen (und ihrer Unterstrukturen) vor. Enthält ein Thema Darstellungsbeschreibungen, können drei Arten von Behältern gebildet werden:

Datenbehälter.
Behälter mit den Basisdaten für die Grafik. Solche Behälter enthalten die Instanzen von Klassen oder Sichten, welche die Grundlage der Darstellungsbeschreibungen bilden.
Grafikbehälter. Solche Behälter enthalten die umgesetzten Grafikobjekte (entsprechend der Parameter-Definition der verwendeten Signaturen).

Datenbehälter und Objekte weisen in der Regel eine Objektidentifikation auf. Ihr Wertebereich ergibt sich aus der entsprechenden Definition: BASKET OID AS für die Objektidentifikationen der Datenbehälter, OID AS für die Objektidentifikationen der Objekte, sofern bei der jeweiligen Klasse keine spezifische Definition dafür gemacht wird. Wurde einem Thema ein OID-Wertebereich zugeordnet, kann die Zuordnung in Erweiterungen nicht mehr geändert werden. In vielen Fällen wird es Sinn machen, den Standardwertebereich STANDARDOID (vgl. Kapitel 3.8.9, “Wertebereiche von Objektidentifikationen” sowie Anhänge A und F) zu verwenden. Fehlt die OID-Definition für ein Thema oder eine bestimmte Klasse, erhalten diese Behälter bzw. Objekte keine stabilen Objektidentifikationen. Der inkrementelle Datenaustausch ist dann für sie nicht möglich.

Ohne weitere Angaben ist ein Thema datenmässig unabhängig von anderen Themen. Datenmässige Abhängigkeiten entstehen als Folge von Beziehungen bzw. Referenzattributen, die in einen anderen Behälter verweisen, durch spezielle Konsistenzbedingungen oder durch den Aufbau von Sichten oder Grafikdefinitionen auf Klassen oder anderen Sichten, nicht aber durch die Verwendung von Metaobjekten (vgl. Kapitel 3.10.1, “Allgemeine Aussagen zu Metaobjekten”). Im Interesse der klaren Erkennbarkeit solcher Abhängigkeiten, müssen diese aber bereits im Themenkopf explizit deklariert werden (Schlüsselwort DEPENDS ON). Die detaillierten Definitionen (z.B. Beziehungsdefinitionen) dürfen dann die Abhängigkeitsdeklaration nicht verletzen. Zyklische Abhängigkeiten sind nicht erlaubt. Ein erweitertes Thema besitzt ohne zusätzliche Deklarationen dieselben Abhängigkeiten wie sein Basis-Thema.

Referenziert ein Thema direkt oder indirekt generische Festlegungen, die letztlich erst im Transfer festgelegt werden, müssen sie explizit aufgeführt werden (DEFERRED GENERICS). Aktuell besteht diese Möglichkeit nur für Koordinaten-Wertebereiche (vgl. Kapitel 3.8.8, “Koordinaten”).

3.5.3. Klassen und Strukturen

Eine Klassendefinition (Schlüsselwort CLASS) deklariert die Eigenschaften aller zugehörigen Objekte. Eine Klasse wird in einem Thema abschliessend definiert. Klassendefinitionen sind erweiterbar, wobei eine Erweiterung primär sämtliche Attribute ihrer Basis-Klasse erbt. Deren Wertebereiche dürfen eingeschränkt werden. Zudem dürfen weitere Attribute oder zusätzliche Konsistenzbedingungen definiert werden.

Der Wertebereich der Objektidentifikationen aller Objekte dieser Klasse kann explizit festgelegt werden (OID AS oder NO OID). Fehlt die Definition, gilt diejenige des Themas, es sei denn, es werde explizit festgelegt, dass keine Objektidentifikationen gefragt sind (NO OID). Fehlt die Definition auch beim Thema, gilt implizit NO OID. NO OID bedeutet, dass die Objektidentifikation nicht stabil ist. Als Folge ist es weder möglich, Objekte dieser Klasse inkrementell nachzuliefern, noch Referenzen (Beziehungen, Beziehungsattribute) auf diese Klasse zu definieren. Eine bereits gemachte OID-Definition kann nicht erweitert werden, ausser dass ein geerbtes NO OID durch ANY, und ein geerbtes ANY durch eine konkrete Definition ersetzt werden kann. Ein geerbtes ANY kann jedoch nicht durch NO OID ersetzt werden. (vgl. Kapitel 3.8.9, “Wertebereiche von Objektidentifikationen”).

Als Teil einer Klassendefinition können Konsistenzbedingungen angegeben werden. Die Bedingungen stellen Regeln dar, welchen die Objekte zusätzlich genügen müssen. Ererbte Konsistenzbedingungen können nicht ausser Kraft gesetzt werden, sondern gelten immer zusätzlich zu den lokal deklarierten.

Die Objekte einer Klasse sind immer selbständig und individuell identifizierbar. Strukturen (Schlüsselwort STRUCTURE) sind zwar formal gleich wie Klassen definiert, ihre Strukturelemente sind jedoch unselbständig und können nicht einzeln identifiziert werden. Sie kommen entweder innerhalb von Unterstrukturen von Objekten vor (vgl. Kapitel 3.6, “Attribute”), oder sie existieren nur temporär als Ergebnisse von Funktionen. Strukturen dürfen zu Klassen erweitert werden; Objekte solcher Klassen sind wie normale Objekte selbständig und identifizierbar. Klassen dürfen nicht zu Strukturen erweitert werden.

Spezielle Klassen wie diejenigen für Referenzsysteme, Koordinatensystem-Achsen und Grafik-Signaturen (also Erweiterungen der vordefinierten Klasse METAOBJECT) werden im Kapitel 3.10, “Umgang mit Metaobjekten” beschrieben.

In runden Klammern (Regel Properties) können die Vererbungseigenschaften definiert werden. Es sind alle Möglichkeiten zulässig. Enthält eine Klasse oder Struktur abstrakte Attribute, ist sie als ABSTRACT zu deklarieren. Abstrakte Attribute müssen dann in konkreten Erweiterungen der Klasse noch konkretisiert werden. Es ist aber auch zulässig, Klassen als abstrakt zu erklären, deren Attribute vollständig definiert sind. Objektinstanzen können nur für konkrete Klassen existieren, die innerhalb eines Themas definiert wurden, d.h. für einen Datentransfer braucht es konkrete Klassen, die in einem konkreten Thema definiert sind.

Wird eine einzelne Klasse und nicht ein ganzes Thema geerbt, dürfen keine Beziehungen (vgl. Kapitel 3.7, “Eigentliche Beziehungen”) zu ihr definiert sein.

Erweitert ein Thema ein anderes, werden alle Klassen des geerbten Themas übernommen. Sie werden also zu Klassen des aktuellen Themas und haben denselben Namen wie im geerbten Thema. Eine solche Klasse kann auch unter Beibehaltung ihres Namens erweitert werden (EXTENDED). Erweitert z.B. ein Thema T2 das Thema T1, das die Klasse C enthält, gibt es mit C (EXTENDED) innerhalb von T2 nur eine Klasse, nämlich C. Neue Klassen, die sich namensmässig von den geerbten unterscheiden müssen, dürfen auch geerbte erweitern. Mit C2 EXTENDS C, gibt es dann in T2 zwei Klassen (C und C2). Da INTERLIS im Interesse von Einfachheit und Klarheit nur Einfachvererbung unterstützt, ist EXTENDED allerdings nur zulässig, wenn weder im Basis-Thema noch im aktuellen Thema die Basis-Klasse mit EXTENDS erweitert wurde. EXTENDED und EXTENDS schliessen sich in der gleichen Klassendefinition aus.

※

Syntaxregeln:

ClassDef = 'CLASS' Class-Name
             Properties<ABSTRACT,EXTENDED,FINAL>
               [ 'EXTENDS' ClassRef ] '='         (1)
             [ ( 'OID' 'AS' OID-DomainRef | 'NO' 'OID' ) ';' ]
             ClassOrStructureDef
           'END' Class-Name ';'.

StructureDef = 'STRUCTURE' Structure-Name
                 Properties<ABSTRACT,EXTENDED,FINAL>
                   [ 'EXTENDS' StructureRef ] '='
                 ClassOrStructureDef
               'END' Structure-Name ';'.

ClassOrStructureDef = [ 'ATTRIBUTE' ] { AttributeDef }
                      { ConstraintDef }
                      [ 'PARAMETER' { ParameterDef } ].

ClassRef = [ Model-Name '.' [ Topic-Name '.' ] ] Class-Name.

StructureRef = [ Model-Name '.' [ Topic-Name '.' ] ] Structure-Name.

ClassOrStructureRef = ( ClassRef | StructureRef ).

1	Im PDF-Dokument des Referenzhandbuchs (Version 2.1.0) steht an dieser Stelle ClassOrStructureRef. In INTERLIS 2.4 dürfen aber Strukturen nicht mehr zu Klassen erweitert werden. Siehe dazu auch dieses Issue.

Welche Namen qualifiziert werden müssen (durch Model-Name bzw. durch Model-Name.Topic-Name) ist am Schluss des folgenden Abschnitts (vgl. Kapitel 3.5.4, “Namensräume”) erklärt. Klassen und Strukturen, die nicht auf einer bereits definierten Klasse oder Struktur aufbauen, brauchen keinen EXTENDS-Teil.

3.5.4. Namensräume

Als Namensraum bezeichnet man eine Menge von (eindeutigen) Namen. Jedes Modellierungselement (Datenmodell, Thema, Klassenelement) sowie die Metadaten-Behälter stellen jeweils einen eigenen Namensraum für ihre Namenskategorien (Typnamen, Bestandteilnamen, Metaobjektnamen) bereit.

Modellierungselemente gibt es auf drei Hierarchiestufen:

Modell (MODEL ist einziges Modellierungselement auf oberster Stufe)
Thema (TOPIC ist einziges Modellierungselement auf dieser Stufe)
Klassenelemente sind Klasse (CLASS), Struktur (STRUCTURE), Assoziation (ASSOCIATION), Sicht (VIEW), Grafikdefinition (GRAPHIC)

Metadaten-Behälter-Namen eröffnen den Zugang zu den Metaobjekten (vgl. Kapitel 3.10, “Umgang mit Metaobjekten”).

Es gibt drei Namenskategorien, die folgende Namen enthalten:

Typnamen sind die Kurzzeichen (Namen) von Einheiten und die Namen von Funktionen, Linienformtypen, Wertebereichen, Strukturen, Themen, Klassen, Assoziationen, Sichten, Grafikdefinitionen, Behältern.
Bestandteilnamen heissen die Namen von Laufzeitparametern, Attributen, Zeichnungsregeln, Parametern, Rollen und Basissichten.
Metaobjektnamen heissen die Namen von Metaobjekten. Sie existieren nur innerhalb von Metadatenbehältern.

Erweitert ein Modellierungselement ein anderes, werden seinen Namensräumen alle Namen des Basis-Modellierungselementes zugefügt. Um Missverständnisse auszuschliessen übernehmen Modellierungselemente zudem die Namen des übergeordneten Modellierungselementes entsprechend der Namenskategorie. Ein lokal im Modellierungselement definierter Name darf nicht mit einem übernommenen Namen kollidieren, es sei denn es handle sich ausdrücklich um eine Erweiterung (EXTENDED).

Will man Beschreibungselemente des Datenmodells referenzieren, muss ihr Name normalerweise qualifiziert, d.h. mit vorangestelltem Modell- und Thema-Namen angegeben werden. Unqualifiziert können die Namen der Namensräume des jeweiligen Modellierungselementes verwendet werden.

3.6. Attribute

3.6.1. Allgemeine Aussagen zu Attributen

Jedes Attribut wird durch seinen Namen und seinen Typ definiert. In runden Klammern (Regel Properties) können die Vererbungseigenschaften definiert werden. Ist ein Attribut eine Erweiterung eines geerbten Attributes, muss dies mit EXTENDED ausdrücklich angemerkt werden. Ist der Wertebereich eines Attributs abstrakt, muss das Attribut als ABSTRACT deklariert werden. Ein numerisches Attribut (vgl. Kapitel 3.8.5, “Numerische Datentypen”) kann als eine Unterteilung (Schlüsselwort SUBDIVISION) des ebenfalls numerischen Vorgängerattributes definiert sein (z.B. Minuten als Unterteilung von Stunden). Dieses Vorgängerattribut muss ganzzahlig und der Wertebereich der Unterteilung muss positiv sein. Ist die Unterteilung kontinuierlich (Schlüsselwort CONTINUOUS), muss die Differenz der Wertebereichsgrenzen mit dem Faktor zwischen der Einheit des Attributs und demjenigen des Vorgängerattributs übereinstimmen. Ist zu einer Unterteilung ein Referenzsystem definiert, muss dieses zum Wertesystem eines direkten oder indirekten Vorgängerattributes passen. Ein INTERLIS-Compiler oder ein Laufzeitsystem muss dies jedoch nicht überprüfen.

※

Syntaxregel:

AttributeDef = [ [ 'CONTINUOUS' ] 'SUBDIVISION' ]
               Attribute-Name Properties<ABSTRACT,EXTENDED,FINAL,TRANSIENT>
                 ':' AttrTypeDef
                     [ ':=' Expression { ',' Expression } ] ';'.

Wird der Attributwert mittels eines Faktors (vgl. Kapitel 3.13, “Ausdrücke”) festgelegt, muss dessen Ergebnistyp zuweisungskompatibel zum definierten Attribut sein, d.h. es muss den gleichen Wertebereich oder einen erweiterten, d.h. spezialisierten Wertebereich aufweisen. Im Rahmen von Sichten - vor allem bei Vereinigungen und Sichterweiterungen (vgl. Kapitel 3.15, “Sichten”) – können mehrere Faktoren festgelegt werden und in zusätzlichen Sichterweiterungen noch zusätzliche beigefügt werden. Es gilt jeweils der letzte (Basis zuerst, Erweiterung anschliessend), dessen Wert definiert ist. Mittels eines Faktors festgelegte Attribute sollen, falls sie nur innerhalb weiterer Faktoren von Bedeutung sind, vom Datentransfer ausgeschlossen werden können, sie sollen dann als transient bezeichnet werden.

Ein Attribut kann in Erweiterungen wie folgt übersteuert werden:

durch einen eingeschränkten Wertebereich.
durch eine Konstante aus dem verlangten Wertebereich. Eine solche Definition ist implizit final, d.h. sie kann nicht mehr weiter übersteuert werden.
durch einen Faktor, wenn der Typ des Ergebnisses als Erweiterung des Attributs zulässig wäre. Eine weitere Übersteuerung ist zulässig.

※

Syntaxregeln:

AttrTypeDef = ( 'MANDATORY' [ AttrType ]
              | AttrType
              | ( ( 'BAG' | 'LIST' ) [ Cardinality ]
                  'OF' AttrType ) ).

AttrType = ( Type
           | DomainRef
           | ReferenceAttr
           | RestrictedStructureRef ).

ReferenceAttr = 'REFERENCE' 'TO'
                  Properties<EXTERNAL> RestrictedClassOrAssRef.

RestrictedClassOrAssRef = ( ClassOrAssociationRef | 'ANYCLASS' )
                              [ 'RESTRICTION' '(' ClassOrAssociationRef
                                  { ';' ClassOrAssociationRef } ')' ].

ClassOrAssociationRef = ( ClassRef | AssociationRef ).

RestrictedStructureRef = ( StructureRef | 'ANYSTRUCTURE' )
                             [ 'RESTRICTION' '(' StructureRef
                                 { ';' StructureRef } ')' ].

(1)

1	Im PDF-Dokument des Referenzhandbuchs (Version 2.1.0) ist an dieser Stelle die Regel RestrictedClassOrStructureRef abgebildet. Diese wird in INTERLIS 2.4 nicht mehr verwendet und deshalb aus der Online-Version entfernt. Siehe dazu auch dieses Issue.

Im Rahmen von Erweiterungen ist es zulässig, nur MANDATORY anzugeben. Es gilt dann der bereits definierte Attributtyp. Es wird aber verlangt, dass der Wert immer definiert ist.

3.6.2. Attribute mit Wertebereichen als Typ

Als Typ eines Attributs kommen direkte Typendefinitionen (Regel Type) und die Verwendung bereits definierter Wertebereiche (Regel DomainRef) in Frage. Die verschiedenen Möglichkeiten sind im Kapitel 3.8, “Wertebereiche und Konstanten” aufgeführt.

3.6.3. Referenzattribute

Mit einem Referenzattribut kann der Verweis zu einem anderen Objekt geschaffen werden. Zusammenhänge zwischen eigenständigen Objekten sind mittels eigentlichen Beziehungen (vgl. Kapitel 3.7, “Eigentliche Beziehungen”) zu definieren.

Die Klassen, deren Objekte für den Bezug in Frage kommen, dürfen konkrete oder abstrakte Objekt- oder Beziehungsklassen, jedoch keine Strukturen sein (da diese keine eigenständigen Objekte sind). Dabei kommen alle konkreten Klassen in Frage, die der aufgeführten primären bzw. einer der aufgeführten einschränkenden (RESTRICTION TO) Klassen entsprechen (Klasse selbst oder Unterklasse davon). Auf jeder Restriktionsstufe (Erstdefinition oder in Erweiterungsschritten) müssen jeweils alle noch zulässigen Klassen aufgeführt werden. Jede als Einschränkung definierte Klasse muss Unterklasse einer bisher zulässigen Klasse sein. Eine so in Frage kommende Klasse ist allerdings nur zulässig, wenn sie zum selben Thema wie das Referenzattribut oder zu einem Thema gehört, von denen das referenzierende Thema abhängig (DEPENDS ON) ist. Soll die Referenz auf ein Objekt eines anderen Behälters des gleichen oder eines anderen (DEPENDS ON vorausgesetzt) Themas verweisen dürfen, muss die Eigenschaft EXTERNAL angegeben werden. In Erweiterungen kann diese Eigenschaft weggelassen und damit ausgeschlossen, nicht aber zugefügt werden. Es muss mindestens eine zulässige konkrete Unterklasse geben, wenn das Referenzattribut nicht als abstrakt deklariert ist.

3.6.4. Strukturattribute

Die Werte von Strukturattributen bestehen aus einem oder mehreren Strukturelementen (Instanzen von Strukturen; vgl. Kapitel 3.5.3, “Klassen und Strukturen”). Strukturelemente haben keine OID, existieren nur im Zusammenhang mit ihrem Hauptobjekt und sind auch nur über dieses auffindbar. Die zulässige Anzahl der Strukturelemente ergibt sich aus der angegebenen Kardinalität bzw. dem vorhandenen oder abwesenden Schlüsselwort MANDATORY. Mit LIST kann man erreichen, dass die Strukturelemente in einer bestimmten Reihenfolge geführt werden. Diese Reihenfolge muss beim Transfer erhalten bleiben. Mit BAG sind die Strukturelemente ungeordnet.

Strukturattribute dürfen mit konkreten oder abstrakten Typen (Strukturen, Wertebereiche, Referenzattribute; aber keine Klassen) definiert werden.

Bei Strukturen ergibt sich der Aufbau durch die angegebene Struktur (Regel RestrictedStructureRef). Für die konkreten Strukturelemente kommen grundsätzlich alle Strukturen (nicht aber Klassen) in Frage, die der primären und den einschränkend (RESTRICTION TO) aufgeführten Strukturen entsprechen oder diese erweitern. Für die Strukturen des aktuellen Themas braucht es dafür keine weiteren Angaben. Strukturen anderer Themen werden nur berücksichtigt, wenn sie bzw. eine ebenfalls in diesem anderen Thema definierte Basisklasse als primäre oder einschränkende Struktur bei der Definition des Strukturattributes explizit aufgeführt ist. Auf jeder Restriktionsstufe (Erstdefinition oder in Erweiterungsschritten) müssen jeweils alle noch zulässigen Strukturen aufgeführt werden. Jede als Erweiterung definierte Struktur muss Erweiterung einer bisher zulässigen Struktur sein.

Ist die Struktur eines Strukturattributs beliebig (ANYSTRUCTURE) oder findet sich keine konkrete Struktur, die der Definition genügt, muss das Strukturattribut als abstrakt deklariert werden, sofern es obligatorisch ist bzw. eine minimale Kardinalität grösser null hat. Werden Strukturen als formale Funktionsargumente definiert (Kapitel 3.14, “Funktionen”) kommen als aktuelle Argumente Pfade zu Strukturelementen oder zu Objekten in Frage. Insbesondere sind mit ANYSTRUCTURE alle Strukturelemente und alle Objekte verträglich.

Eine geordnete Unterstruktur (LIST) darf nicht durch eine ungeordnete (BAG) erweitert werden. Für die Kardinalität gelten die gleichen Regeln wie bei Beziehungen (vgl. Kapitel 3.7.3, “Kardinalität”).

3.7. Eigentliche Beziehungen

3.7.1. Beschreibung von Beziehungen

Eigentliche Beziehungen (im Gegensatz zu Referenzattributen; vgl. Kapitel 3.6, “Attribute”) werden als eigenständige Konstrukte beschrieben. Sie haben aber weitgehend gleiche Eigenschaften wie Klassen. So können sie selbst lokale Attribute und Konsistenzbedingungen aufweisen. Der Assoziationsname darf auch fehlen. Er wird dann implizit aus der Zusammensetzung der Rollennamen (erster, dann zweiter, usw.) gebildet. Die wichtigste Eigenschaft einer Beziehung besteht jedoch in der Auflistung von mindestens zwei Rollen mit den zugeordneten Klassen oder Beziehungen (Regeln wie bei den Referenzattributen, vgl. Kapitel 3.6.3, “Referenzattribute”) und den Detaileigenschaften wie Stärke der Beziehung und Kardinalität. Die Rollennamen sollen typischerweise Substantive sein. Sie können, müssen aber nicht, mit den Namen der zugeordneten Klassen oder Beziehungen übereinstimmen. Die zu definierende Beziehung darf aber nicht Erweiterung einer so zugeordneten Beziehung sein. Einer Rolle können auch alternativ verschiedene Klassen oder Beziehungen zugeordnet sein. Eine solche alternative Klasse oder Beziehung darf keine Erweiterung einer anderen alternativen Klasse oder Beziehung derselben Rolle sein.

Beispiel einer Beziehung, zwischen der Klasse K einerseits und den Klassen K oder L andererseits:

※

ASSOCIATION A =
  K –- K;
  KL –- K OR L;
END A;

Beziehungen können primär wie Klassen erweitert werden. Damit die Bedeutung der Beziehung klar und unveränderlich ist, dürfen in Erweiterungen keine zusätzlichen Rollen beigefügt werden. Die zugeordneten Klassen oder Beziehungen und die Kardinalität können aber eingeschränkt werden. Unveränderte Rollen müssen nicht aufgeführt werden.

Beispiel, wie die Beziehung A zu A1 spezialisiert wird, wo nur noch Bezüge zu K1 (einer Subklasse von K) einerseits und zu K, L1, L2 (Subklassen von L) andererseits zulässig sind:

※

ASSOCIATION A1 EXTENDS A =
  K (EXTENDED) –- K1;
  KL (EXTENDED) –- K OR L RESTRICTION (L1, L2);
END A1;

Ein Objekt der Klasse K1 kann damit entweder über eine Beziehung A mit Objekten der Klassen K oder L (zulässig, da K1 eine Subklasse von K ist) oder über eine Beziehung A1 mit Objekten der Klassen K, L1 oder L2 verbunden sein. Möchte man zusätzlich erreichen, dass ein Objekt K1 in der Rolle K nur die spezialisierte Beziehung A1 (und nicht auch die allgemeine Beziehung A) eingehen kann, ist die Rolle K als verdeckend (HIDING) zu kennzeichnen.

※

ASSOCIATION A1 EXTENDS A =
  K (EXTENDED, HIDING) –- K1;
  KL (EXTENDED) –- K OR L RESTRICTION (L1, L2);
END A1;

Dies ist allerdings nur zulässig, wenn für K1 keine anderen aus A erweiterten Beziehungen definiert sind, bei denen die Rolle K nicht als verdeckend gekennzeichnet ist.

※

Syntaxregeln:

AssociationDef = 'ASSOCIATION' [ Association-Name ]
                   Properties<ABSTRACT,EXTENDED,FINAL,OID>
                   [ 'EXTENDS' AssociationRef ]
                   [ 'DERIVED' 'FROM' RenamedViewableRef ] '='
                   [ ( 'OID' 'AS' OID-DomainRef | 'NO' 'OID' ) ';' ]
                   { RoleDef }
                   [ 'ATTRIBUTE' ] { AttributeDef }
                   [ 'CARDINALITY' '=' Cardinality ';' ]
                   { ConstraintDef }
                 'END' [ Association-Name ] ';'.

AssociationRef = [ Model-Name '.' [ Topic-Name '.' ] ] Association-Name.

RoleDef = Role-Name Properties<ABSTRACT,EXTENDED,FINAL,HIDING,
                               ORDERED,EXTERNAL>
            ( '--' | '-<>' | '-<#>' ) [ Cardinality ]
            RestrictedClassOrAssRef { 'OR' RestrictedClassOrAssRef }
            [ ':=' Role-Factor ] ';'.

Cardinality = '{' ( '*' | PosNumber [ '..' ( PosNumber | '*' ) ] ) '}'.

Eine Instanz einer Beziehung zwischen Objekten kann als eigenständiges Objekt (Beziehungsinstanz) betrachtet werden. Primär werden auf dieser Beziehungsinstanz für alle Rollen die Bezüge zu den Bezugsobjekten festgehalten (alle müssen definiert sein!). Ohne weitere Angabe wird die Beziehungsinstanz durch die Bezüge zu den Objekten, die sie verbindet, identifiziert. Zwischen diesen Objekten ist dann nur eine solche Beziehungsinstanz zulässig. Mehrere Beziehungsinstanzen zwischen derselben Objektkombination sind nur zulässig, wenn für die Beziehung explizit eine Kardinalität mit Obergrenze grösser eins verlangt wird (CARDINALITY). In diesem Fall muss auch eine Objektidentifikation (mittels Property OID) verlangt werden. Wird eine eigene Objektidentifikation verlangt, kann die Beziehung auch selbst wieder in Rollen als Bezug verwendet werden.

Wird Kompatibilität mit INTERLIS 1 angestrebt, sollen nur Beziehungen mit zwei Rollen definiert werden, wobei die maximale Anzahl der Kardinalität einer Rolle nicht grösser als 1 sein darf.

Normalerweise müssen die konkreten Beziehungen zwischen Objekten mittels einer Anwendung explizit erstellt und dann durch das Bearbeitungssystem als Instanz festgehalten werden. Eine Beziehung kann aber auch aus einer Sicht abgeleitet werden, ohne dass sie instanziiert wird (DERIVED FROM). Eine solche Beziehung kann eine Erweiterung einer abstrakten Beziehung sein. Sie kann nicht selbst abstrakt sein. Wird sie erweitert, muss die Erweiterung auf der gleichen Sicht oder einer Erweiterung davon aufbauen. Allen Rollen und Attributen müssen entsprechend Objektpfade oder Attributpfade der Sicht zugewiesen sein. Dabei muss ein Objektpfad (vgl. Kapitel 3.13, “Ausdrücke”) angegeben werden, der letztlich eine der Rolle entsprechende Klasse oder Assoziation bezeichnet. Die Kardinalität muss mit der Leistung der Sicht übereinstimmen. Dies kann aber nur zur Laufzeit geprüft werden.

Ein typischer Anwendungsfall dürfte die Herleitung einer Beziehung aus den geometrischen Verhältnissen sein: In einer Sicht (Verbindung), auf die in der Assoziation Bezug genommen wird, werden z.B. Gebäude auf Grund der Geometrie mit den Liegenschaften, auf denen sie stehen, in Beziehung gebracht (vgl. Kapitel 3.15, “Sichten”).

3.7.2. Stärke der Beziehung

In Anlehnung an UML werden verschiedene Beziehungsstärken unterschieden. Für ihre Erklärung wird vor allem beschrieben, welchen Einfluss die Beziehungsstärke beim Kopieren und Löschen von Objekten hat. Für INTERLIS 2 ist jedoch nur das Löschen von Objekten (als Folge der inkrementellen Nachlieferung) von Bedeutung. Darüber hinaus gibt es noch andere Überlegungen, die die Beziehungsstärke beeinflussen. Insbesondere ist es den Bearbeitungssystemen überlassen, feinere Beziehungsstärken oder gar andere Kriterien für das Verhalten bei bestimmten Operationen vorzusehen.

Assoziation: Die beteiligten Objekte sind lose miteinander verbunden. Wird ein beteiligtes Objekt kopiert, ist die Kopie mit denselben Objekten verbunden wie das Original. Wird ein beteiligtes Objekt gelöscht, wird die Beziehung ebenfalls gelöscht, das verbundene Objekt bleibt aber bestehen. Syntaktisch wird bei allen Rollen '--' angegeben.
Aggregation: Es besteht eine schwache Beziehung zwischen einem Ganzen und seinen Teilen. Aggregationen sind nur in Beziehungen mit zwei Rollen erlaubt. Syntaktisch muss die Rolle, die zum Ganzen führt, mit einem Rhombus '-<>' angegeben sein. Die Rolle, die zum Teil führt, wird mit '--' definiert. Eine Objektklasse kann in verschiedenen Aggregationen in der Teile-Rolle auftreten. Einem bestimmten Teile-Objekt können dann auch verschiedene Ganze-Objekte zugeordnet sein. Anders als bei Assoziationen werden als Folge der Erstellung einer Kopie des Ganzen auch entsprechende Kopien der Teile erstellt. Da im Rahmen von INTERLIS 2 das Kopieren von Objekten nicht von Bedeutung ist, behandelt INTERLIS 2 Aggregationen wie Assoziationen.
Komposition: Es besteht eine starke Beziehung zwischen dem Ganzen und seinen Teilen. Eine Objektklasse darf in mehr als einer Komposition in der Teile-Rolle auftreten. Einem bestimmten Teile-Objekt darf aber höchstens ein Ganzes zugeordnet sein. Bei der Löschung des Ganzen werden auch seine Teile gelöscht. Bei der Rolle, die zum Ganzen führt, wird ein gefüllter Rhombus '-<#>' angegeben.

Assoziationen dürfen zu Aggregationen, diese zu Kompositionen erweitert werden, nicht aber umgekehrt.

3.7.3. Kardinalität

Die Kardinalität definiert die minimale und die maximale Anzahl erlaubter Objekte; steht nur ein Wert, ist das Minimum gleich dem Maximum. Steht als Maximum ein Stern anstatt einer Zahl, gibt es keine obere Schranke für die Anzahl der Unterobjekte. Die Kardinalitätsangabe {*} ist äquivalent mit {0..*}. Falls die Kardinalitätsangabe weggelassen wird, gilt normalerweise {0..*}. Bei Kompositionsrollen ist nur {0..1} oder {1} zugelassen (ein Teil kann nur zu einem Ganzen gehören). Fehlt die Angabe gilt {0..1}.

Die Kardinalität darf in Erweiterungen nur eingeschränkt, nicht jedoch erweitert werden. Wird also zunächst eine Kardinalität von {2..4} angegeben, darf eine Erweiterung nicht {2..5}, {7} oder {*} deklarieren. Das Weglassen der Kardinalitätsangabe wird bei erweiterten Attributen als Übernehmen des ererbten Wertes verstanden.

Je nach Verwendung hat die Kardinalität folgende Bedeutung:

Bei Unterstrukturen: Anzahl der zulässigen Elemente.
Bei Rollen von Beziehungen: Anzahl der einer Rolle entsprechenden Objekte, die einer beliebigen Kombination von Objekten, die den anderen Rollen entsprechen, über die Beziehung zugeordnet sein dürfen.
Bei der Beziehung als Ganzes: Anzahl der Beziehungsinstanzen für eine beliebige Kombination von Objekten gemäss allen Rollen der Beziehung.

3.7.4. Geordnete Beziehungen

Will man erreichen, dass die Beziehung aus der Sicht einer bestimmten Bezugsklasse in einer bestimmten Ordnung geführt wird, muss dies bei der Rolle als Eigenschaft (ORDERED) verlangt werden. Diese Ordnung wird beim Etablieren der Beziehung definiert und muss bei Transfers erhalten bleiben.

3.7.5. Beziehungszugänge

Als Beziehungszugang (AssociationAccess) wird die Möglichkeit bezeichnet, aus der Sicht eines Objektes gemäss einer Beziehung zu den Beziehungsinstanzen und weiter zu den Bezugsobjekten zu navigieren. Beziehungszugänge müssen nicht definiert werden, sondern entstehen mit der Definition einer Beziehung für alle über Rollen zugeordneten Klassen, die im gleichen Thema wie die Beziehung definiert wurden. Ist eine an einer Beziehung beteiligte Klasse in einem anderen Thema definiert (themenübergreifende Beziehung) oder soll es zulässig sein, dass ein der Rolle entsprechendes Bezugsobjekt in einem anderen Behälter als die Beziehungsinstanz liegen darf, muss dies bei der Rolle speziell angemerkt werden (EXTERNAL, vgl. Kapitel 3.7.1, “Beschreibung von Beziehungen” und Kapitel 3.6.3, “Referenzattribute”). Die Klasse erhält dann keine Beziehungszugänge. Diese Eigenschaft wird in der Basisdefinition einer Beziehung festgelegt und kann in einer Erweiterung nicht mehr verändert werden. Bezieht sich eine Rolle auf eine vom geerbten Thema geerbte Klasse, sind Beziehungszugänge aus dieser Klasse nur möglich, wenn diese Klasse im aktuellen Thema mit gleichem Namen erweitert wurde (EXTENDED). Durch diese Einschränkungen wird vermieden, dass eine Klasse nachträglich (d.h. ausserhalb des Rahmens, in dem sie definiert wurde) nochmals eine Änderung erfährt.

Beziehungszugänge werden an die Subklassen vererbt, sofern dies nicht durch Verdeckungsforderung bei einer Rolle einer erweiternden Beziehung (HIDING) ausgeschlossen wird.

Beziehungszugänge sind für Pfadbeschreibungen von Bedeutung (vgl. Kapitel 3.13, “Ausdrücke”).

3.8. Wertebereiche und Konstanten

Mit der Vorstellung eines Wertebereichs sind verschiedene Aspekte verbunden. Primär muss ein Datentyp festgelegt werden. Die INTERLIS-Datentypen sind unabhängig von der Implementation. Es wird deshalb z.B. nicht von Integer oder Real, sondern einfach von numerischen Datentypen gesprochen (vgl. Kapitel 3.8.5, “Numerische Datentypen”).

Werden numerische Attribute (inkl. Koordinaten, Linien), die nicht TRANSIENT (vgl. unten) sind, insbesondere im Rahmen von Ausdrücken verwendet, sind die Werte (unabhängig von der Speicherung im jeweiligen System) immer gemäss Wertebereichsdefinition zu runden. Damit das Rundungsverfahren nicht vorgeschrieben werden muss (z.B. kaufmännisch [0.5 immer aufrunden]), gelten Werte von funktional berechneten Attributen, die nicht TRANSIENT (vgl. unten) sind, als korrekt, wenn sie auf- oder abgerundet sind.

Ist der Datentyp festgelegt, sind – je nach Datentyp – noch weitere Präzisierungen nötig oder möglich. Ist eine Wertebereich-Definition noch unvollständig (fehlt z.B. bei einem numerischen Wertebereich noch die konkrete Bereichsdefinition), muss sie als abstrakt deklariert werden (Schlüsselwort ABSTRACT, Regel Properties). Um insbesondere den Übergang von LV03- auf LV95-Koordinaten zu erleichtern, kann der Wertebereich von Koordinaten als generisch (Schlüsselwort GENERIC, Regel Properties) definiert werden. Die verwendenden Wertebereiche (insbesondere Linien), Attribute, Klassen und Themen müssen deswegen nicht abstrakt definiert werden, obwohl der Koordinaten-Wertebereich erst in spezifischen Modellen oder sogar erst in den Transferdaten festgelegt wird (vgl. Kapitel 3.8.8, “Koordinaten”).

Wertebereiche können – wie andere Konstrukte – auch geerbt und dann erweitert werden, sofern sie nicht als FINAL definiert wurden. Wichtig ist dabei der Grundsatz, dass eine erweiterte Definition immer mit der Basis-Definition kompatibel sein muss. Bei Wertebereichen sind Erweiterungen (Schlüsselwort EXTENDS) somit eigentlich Präzisierungen bzw. Einschränkungen. Das Schlüsselwort EXTENDED (Regel Property) ist nicht zulässig. Im Interesse der Lesbarkeit wird empfohlen, Definitionsteile von Basis-Wertebereichen (z.B. die Masseinheit) in der Erweiterung auch dann zu wiederholen, wenn sie unverändert sind.

Beispiel:

DOMAIN
  Wert (ABSTRACT) = NUMERIC .. NUMERIC;    !! abstrakter Wertebereich
  GenWert EXTENDS Wert = 10.0 .. 100.0;    !! konkrete Erweiterung
  SpezWert EXTENDS GenWert = 20.0 .. 90.0; !! in Ordnung
  SpezWert EXTENDS GenWert = 0.0 .. 110.0; !! falsch, da unverträglich

Eine wichtige Frage bei der Definition von Wertebereichen ist, ob der Wert "Undefiniert" auch zum Wertebereich gehört oder nicht. Ohne weitere Angabe gehört er dazu. Es kann aber verlangt werden, dass er nicht dazu gehört, d.h. dass ein Attribut mit diesem Wertebereich immer definiert sein muss (Schlüsselwort MANDATORY). MANDATORY allein ist nur bei Erweiterungen zulässig.

Bei der Definition eines Attributs einer Klasse oder Struktur (und nur dort) darf auch dann MANDATORY stehen, wenn der Wertebereich als FINAL deklariert wurde und somit eigentlich nicht weiter eingeschränkt werden dürfte.

Mit dem Schlüsselwort CONSTRAINTS kann die Wertebereichsdefinition um eine oder mehrere Einschränkungen ergänzt werden, um z.B. bei einem Textwertebereich nur bestimmte Zeichenfolgenmuster zuzulassen. Werden mehrere Einschränkungen gemacht, gelten alle. Jede Einschränkung hat innerhalb der Wertebereichsdefinition einen eindeutigen Namen.

※

Syntaxregeln:

DomainDef = 'DOMAIN'
               { Domain-Name Properties<ABSTRACT,GENERIC,FINAL>
                   [ 'EXTENDS' DomainRef ] '='
               ( 'MANDATORY' [ Type ] | Type ) [ 'CONSTRAINTS'
                 Constraints-Name ':' Logical-Expression
                 { ',' Constraints-Name ':' Logical-Expression } ] ';' }.

Type = ( BaseType | LineType ).

DomainRef = [ Model-Name '.' [ Topic-Name '.' ] ] Domain-Name.

BaseType = ( TextType
           | EnumerationType
           | EnumTreeValueType
           | AlignmentType
           | BooleanType
           | NumericType
           | FormattedType
           | DateTimeType
           | CoordinateType
           | OIDType
           | BlackboxType
           | ClassType
           | AttributePathType ).

In Vergleichsoperationen (vgl. Kapitel 3.13, “Ausdrücke”) können Attributwerte auch mit Konstanten verglichen werden. Diese sind wie folgt definiert:

Constant = ( 'UNDEFINED'
           | NumericConst
           | TextConst
           | FormattedConst
           | EnumerationConst
           | ClassConst
           | AttributePathConst ).

Die typenspezifischen Konstanten sind bei den einzelnen Datentypen definiert.

3.8.1. Zeichenketten

Eine Zeichenkette ist eine Folge von Zeichen mit einer maximalen Länge. Der Zeichenvorrat muss klar definiert sein (vgl. Anhang D Zeichentabelle).

Im Datentyp MTEXT sind die Zeichen «Carriage Return» (Wagenrücklauf) (#xD), «Line Feed» (Zeilenvorschub) (#xA) und «Tabulatorzeichen» (#x9), im Gegensatz zum Wertebereich des Datentyps TEXT, enthalten.

Beim Datentyp Zeichenkette (TEXT) ist primär die Länge der Zeichenkette von Interesse. Je nach der Form der Definition wird sie explizit oder implizit angegeben. Bei der expliziten Form (TEXT * …) wird die maximale Länge in Anzahl Zeichen festgelegt (grösser Null). Werden nur die Schlüsselwörter TEXT oder MTEXT angegeben, ist die Anzahl Zeichen unbeschränkt. Im Rahmen einer Erweiterung kann die Länge verkürzt werden (eine Verlängerung würde zu einem Wertebereich führen, der mit dem Basis-Wertebereich nicht mehr verträglich ist).

Die INTERLIS-Zeichenkettenlänge bezeichnet die Zahl der Zeichen, wie sie von Benutzern wahrgenommen wird, nicht aber die Zahl der Speicherstellen, die ein System maximal zur Repräsentation einer Zeichenkette benötigt. Zeichenketten der Länge null gelten als undefiniert.

Bemerkung: Im Zusammenhang mit INTERLIS ist die Länge einer Zeichenkette als Anzahl jener Zeichen definiert, welche gemäss Unicode-Standard die kanonische Kombinationsklasse Nr. 0 besitzen, nachdem die Zeichenkette in die kanonisch dekomponierte Form von Unicode gebracht wurde (siehe https://www.unicode.org/unicode/reports/tr15/). So besitzt etwa eine Zeichenkette, die aus der Kette <LATIN CAPITAL LETTER C WITH CIRCUMFLEX><COMBINING CEDILLA> besteht, ebenso die Länge 1 wie die äquivalente Zeichenkette <LATIN CAPITAL LETTER C>< COMBINING CIRCUMFLEX ACCENT><COMBINING CEDILLA>. Gemäss der obigen Definition besitzen Ligaturen für «fl» oder «ffi» die Länge 1. Es wird aber davon abgeraten, solche Darstellungsformen überhaupt für Zeichenkettenattribute zu verwenden.

Der Namen-Zeichenkettentyp (Schlüsselwort NAME) definiert einen Wertebereich, der genau demjenigen der INTERLIS-Namen entspricht (vgl. Kapitel 3.2.2, “Namen”). Er wird in der vordefinierten Klasse METAOBJECT (siehe vordefiniertes Basismodell INTERLIS) und damit vor allem in den Klassen für Referenzsysteme sowie Signaturen eingesetzt (vgl. Kapitel 3.10.3, “Referenzsysteme” und Kapitel 3.16, “Darstellungsbeschreibungen”), weil dort Datenattribute mit Beschreibungselementen von Modellen übereinstimmen müssen.

Als weiterer Zeichenkettentyp wird der URI (Uniform Resource Identifier) geführt, z.B. http-, ftp- oder mailto-Adressen (s. Abschnitt 1.2 im Internet-Standard IETF RFC 2396 in https://www.w3.org). Die Länge eines URI ist in INTERLIS auf 1023 Zeichen beschränkt. Er entspricht damit folgender Definition:

DOMAIN
  URI (FINAL) = TEXT*1023;  !! ACHTUNG: gemäss IETF RFC 2396
  NAME (FINAL) = TEXT*255;  !! ACHTUNG: gemäss Kapitel 2.2.2 Namen

※

Syntaxregeln:

TextType = ( 'MTEXT' [ '*' MaxLength-PosNumber ]
           | 'TEXT' [ '*' MaxLength-PosNumber ]
           | 'NAME'
           | 'URI' ).

TextConst = String.

3.8.2. Aufzählungen

Mit einer Aufzählung werden die für diesen Typ zulässigen Werte festgelegt. Die Aufzählung ist jedoch nicht einfach linear, sondern im Sinne eines Baumes strukturiert. Die Blätter des Baumes (nicht aber die Knoten) bilden die Menge der zulässigen Werte.

Beispiel:

DOMAIN
  Farben = (rot (dunkelrot, orange, karmin),
            gelb,
            gruen (hellgruen, dunkelgruen));

ergibt die folgenden - mittels Konstanten beschriebenen - zulässigen Werte:

#rot.dunkelrot #rot.orange #rot.karmin #gelb #gruen.hellgruen #gruen.dunkelgruen

Abbildung 8. Beispiel einer Aufzählung

Eine Schachtelung wird in runden Klammern angegeben. Die Elementnamen jeder Schachtelung müssen eindeutig sein. Die Schachtelungstiefe ist frei wählbar.

Ist eine Aufzählung geordnet (Schlüsselwort ORDERED), ist eine Reihenfolge der Elemente definiert. Ist die Aufzählung zirkulär (Schlüsselwort CIRCULAR), ist die Reihenfolge der Elemente definiert, wie wenn die Aufzählung geordnet wäre. Zudem wird ausgesagt, dass nach dem letzten Element wieder das erste folgt.

Nebst der eigentlichen Aufzählungsdefinition ist es auch möglich, einen Wertebereich zu definieren, der als zulässige Werte alle Blätter und Knoten einer Aufzählungsdefinition umfasst (ALL). Einem solchen Attribut kann darum auch der Wert eines Attributs, der zu Grunde liegenden Aufzählungsdefinition zugewiesen werden.

Beispiele:

DOMAIN
  Lage = (unten, mitte, oben) ORDERED;
  Wochentage = (Werktage (Montag, Dienstag, Mittwoch,
                          Donnerstag, Freitag, Samstag),
                Sonntag) CIRCULAR;
  WochentagsWerte = ALL OF Wochentage;

※

Syntaxregeln:

EnumerationType = Enumeration [ 'ORDERED' | 'CIRCULAR' ].

EnumTreeValueType = 'ALL' 'OF' Enumeration-DomainRef.

Enumeration = '(' EnumElement { ',' EnumElement } [ ':' 'FINAL' ]
               | 'FINAL' ')'.

EnumElement = EnumElement-Name { '.' EnumElement-Name } [Sub-Enumeration].

EnumerationConst = '#' ( EnumElement-Name { '.' EnumElement-Name }
                                          [ '.' 'OTHERS' ]
                       | 'OTHERS' ).

Im Rahmen von Neudefinitionen von Aufzählungen (Primärdefinition, zusätzliche Elemente einer Erweiterung) darf das EnumElement nur aus einem Namen bestehen. Mehrere Namen sind nur zulässig, um für eine Erweiterung ein bisheriges Aufzählungselement zu identifizieren.

Aufzählungen können einerseits erweitert werden, indem für Blätter (also Aufzählungselemente, die keine Unter-Aufzählung aufweisen) der bisherigen Aufzählung Unter-Aufzählungen definiert werden. In der erweiterten Definition werden aus bisherigen Blättern neu Knoten, für die keine Werte definiert werden dürfen.

Andererseits kann jede einzelne Teilaufzählung in Erweiterungen durch weitere Elemente (Knoten oder Blätter) ergänzt werden. Die Basisaufzählungen umfassen dadurch nebst den genannten Elementen immer auch noch potenziell weitere Elemente, die erst in Erweiterungen definiert werden. Solche potenziellen Werte können auf der Basisstufe in Ausdrücken, Funktionsargumenten und Signaturzuweisungen (vgl. Kapitel 3.13, “Ausdrücke”, Kapitel 3.14, “Funktionen” und Kapitel 3.16, “Darstellungsbeschreibungen”) mit dem Wert OTHERS angesprochen werden. OTHERS ist jedoch kein zulässiger Wert im Rahmen der Klasse, zu der das Objekt gehört. Die Möglichkeit, in Erweiterungen zusätzliche Aufzählelemente anfügen zu können, kann unterbunden werden, indem die Teilaufzählung als abschliessend erklärt wird (FINAL). Dies erfolgt entweder nach dem letzten aufgeführten Element oder im Rahmen einer Erweiterung auch ohne dass neue Elemente angefügt werden.

Zirkuläre Aufzählungen (Schlüsselwort CIRCULAR) können nicht erweitert werden.

Beispiel:

DOMAIN
  Farbe = (rot,
           gelb,
           gruen);
  FarbePlus EXTENDS Farbe = (rot (dunkelrot, orange, karmin),
                             gruen (hellgruen, dunkelgruen: FINAL),
                             blau);
  FarbePlusPlus EXTENDS FarbePlus = (rot (FINAL),
                                     blau (hellblau, dunkelblau));

ergibt für FarbePlus die folgenden - mittels Konstanten beschriebenen - zulässigen Werte:

#rot.dunkelrot #rot.orange #rot.karmin #gelb #gruen.hellgruen #gruen.dunkelgruen #blau

und für FarbePlusPlus:

#blau.hellblau #blau.dunkelblau statt #blau (1)

1	Die Richtigkeit dieser Zeile ist umstritten. Siehe dazu auch dieses Issue.

Durch die Angabe von FINAL bei den Grünstufen von FarbePlus ist es in FarbePlusPlus nicht zulässig weitere Grünstufen zu definieren. Mit der Angabe von FINAL für die Unterteilung von Rot in FarbePlusPlus wird verhindert, dass in möglichen Erweiterungen von FarbePlusPlus noch weitere Rotvarianten angefügt werden können.

3.8.3. Textausrichtungen

Für die Aufbereitung von Plänen und Karten müssen die Positionen von Texten festgehalten werden. Dabei muss festgelegt werden, welcher Stelle des Textes die Position entspricht. Mit dem horizontalen Alignment wird festgelegt, ob die Position auf dem linken oder rechten Rand des Textes oder in der Textmitte liegt. Das vertikale Alignment legt die Position in Richtung der Texthöhe fest.

Der Abstand Cap-Base entspricht der Höhe der Grossbuchstaben. Unterlängen befinden sich im Bereich von Base-Bottom.

Abbildung 9. Textausrichtung horizontal (HALIGNMENT) und vertikal (VALIGNMENT).

Horizontales und vertikales Alignment können als folgende vordefinierte Aufzählung verstanden werden:

DOMAIN
  HALIGNMENT (FINAL) = (Left, Center, Right) ORDERED;
  VALIGNMENT (FINAL) = (Top, Cap, Half, Base, Bottom) ORDERED;

※

Syntaxregel:

AlignmentType = ( 'HALIGNMENT' | 'VALIGNMENT' ).

3.8.4. Boolean

Der Typ Boolean weist die Werte false und true auf. Er kann als folgende vordefinierte Aufzählung verstanden werden:

DOMAIN
  BOOLEAN (FINAL) = (false, true) ORDERED;

※

Syntaxregel:

BooleanType = 'BOOLEAN'.

3.8.5. Numerische Datentypen

Die wichtigste Angabe bei numerischen Datentypen ist der Minimal- und der Maximal-Wert inklusive Stellenzahl (Nachkommastellen) sowie der Skalierungsfaktor. Zusätzlich kann angegeben werden, dass der Typ zirkulär ist (Schlüsselwort CIRCULAR), d.h. dass der in der letzten signifikanten Stelle um 1 erhöhte Maximalwert und der Minimalwert sachlich die gleiche Bedeutung haben (z.B. bei Winkeln 0 .. 359 Grad). Ist das Attribut als eine kontinuierliche Unterteilung des Vorgängerattributs definiert (vgl. Kapitel 3.6.1, “Allgemeine Aussagen zu Attributen”), muss der Typ als zirkulär definiert sein. Fehlt die Angabe des Minimal- und Maximal-Wertes (Schlüsselwort NUMERIC), gilt der Wertebereich als abstrakt.

DOMAIN
  Winkel1 = 0.00 .. 359.99 CIRCULAR [degree]; !! richtig
  Winkel2 = 0.00 .. 360.00 CIRCULAR [degree]; !! syntaktisch zwar richtig,
                                              !! sachlich aber falsch, da damit
                                              !! 360.01 dem Minimalwert 0.00
                                              !! entspricht

Die Stellenzahl muss beim Minimal- und beim Maximal-Wert übereinstimmen. Mit Hilfe der Skalierung können Float-Zahlen beschrieben werden, aber dann sind sowohl der Minimal- als auch der Maximal-Wert in Mantissendarstellung anzugeben, d.h. beginnend mit Null (0) und gefolgt vom Dezimalpunkt (.) muss die erste Ziffer nach dem Dezimalpunkt von Null (0) verschieden sein. Die Skalierung des Minimalwertes muss kleiner sein als die Skalierung des Maximalwertes. Die Schreibweise von Minimal- und Maximalwert bedeutet aber keineswegs eine Anweisung, wie die Werte transferiert werden sollen (ist ein Wertebereich mit 000 .. 999 definiert, bedeutet das nicht, dass der Wert 7 als 007 transferiert wird). Eine Ausnahme von dieser Regel bilden die Float-Zahlen. Diese sind in Mantissendarstellung und mit Skalierung zu transferieren.

Bei Erweiterungen dürfen die Maximal- bzw. Minimalwerte nur eingeschränkt werden. Der numerische Bereich wird damit also kleiner. Die Genauigkeit (Stellenzahl) darf nicht verändert werden.

Beispiele:

DOMAIN
  Normal = 0.00 .. 7.99;
  Genau EXTENDS Normal = 0.0000 .. 7.9949;      !! falsch, da Stellenzahl grösser
  Eingeschraenkt EXTENDS Normal = 1.00 .. 6.99; !! richtig

Um die Bedeutung des Wertes genauer zu erklären kann eine Masseinheit angegeben werden (vgl. Kapitel 3.9, “Einheiten”). Abstrakte Masseinheiten sind nur zulässig, solange der Wertebereich selbst noch undefiniert ist (Schlüsselwort NUMERIC).

Für Erweiterungen gelten folgende Regeln:

Weist ein konkreter Basis-Wertebereich keine Masseinheit auf, darf auch in Erweiterungen des Basis-Wertebereichs keine angegeben werden.
Verwendet der Basis-Wertebereich eine abstrakte Masseinheit, dürfen in Erweiterungen des Basis-Wertebereichs nur Masseinheiten verwendet werden, die Erweiterungen der Masseinheit sind.
Verwendet der Basis-Wertebereich eine konkrete Masseinheit, kann sie in Erweiterungen nicht übersteuert werden.

Beispiele:

UNIT
  foot [ft] = 0.3048 [m];

DOMAIN
  Distanz (ABSTRACT) = NUMERIC [Length];
  MeterDist (ABSTRACT) EXTENDS Distanz = NUMERIC [m];
  FussDist (ABSTRACT) EXTENDS Distanz = NUMERIC [ft];
  KurzeMeter EXTENDS MeterDist = 0.00 .. 100.00 [m];
  KurzeFuesse EXTENDS FussDist = 0.00 .. 100.00 [ft];
  KurzeFuesse2 (ABSTRACT) EXTENDS KurzeMeter = NUMERIC [ft]; !! falsch: m vs. ft

Einem numerischen Wertebereich kann auch ein Skalarsystem zugeordnet werden (vgl. Kapitel 3.10.3, “Referenzsysteme”). Damit beziehen sich die Werte auf den durch das Skalarsystem bestimmten Nullpunkt. Es sind also absolute Werte in diesem Skalarsystem. Ist in der Klasse des Skalarsystems die Einheit nicht ANYUNIT, muss beim numerischen Datentyp eine Einheit angegeben werden, die mit jener des Referenzsystems verträglich ist. Bezieht man sich auf ein Koordinatensystem, kann die Achse angegeben werden, auf die sich die Werte beziehen. Die Einheit muss mit jener der entsprechenden Achse verträglich sein. Fehlt diese Angabe, ist der Bezug nicht genauer definiert, sondern ergibt sich aus dem Fachgebiet (z.B. bezieht man sich bei einer Höhe auf ein Ellipsoid, meint man ellipsoidische Höhen). Bezieht man sich auf einen anderen Wertebereich, soll das gleiche Referenzsystem gelten wie bei diesem Wertebereich. In diesem Fall darf die Angabe der Achse nur fehlen, wenn es sich um einen numerischen Wertebereich handelt. Bei einem Koordinatenwertebereich ist die Achsenangabe obligatorisch. Die Angabe des Referenzsystems kann in Erweiterungen nicht mehr geändert werden.

Stellt der numerische Wert einen Winkel dar, kann sein Richtungssinn festgelegt werden. Im Falle von Richtungen kann angegeben werden, auf welches Koordinatensystem (definiert durch einen Koordinaten-Wertebereich) sich die Richtung bezieht. Damit ist bekannt, wie die Nullrichtung (Azimut) und der Drehsinn definiert sind (vgl. Kapitel 3.8.8, “Koordinaten”). Diese Angabe kann in Erweiterungen nicht mehr geändert werden.

Als numerische Konstanten sind nebst den Dezimalzahlen auch die Zahlen Pi (Schlüsselwort PI) und e – Basis des natürlichen Logarithmus – (Schlüsselwort LNBASE) definiert.

※

Syntaxregeln:

NumericType = ( Min-Dec '..' Max-Dec | 'NUMERIC' ) [ 'CIRCULAR' ]
              [ '[' UnitRef ']' ]
              [ 'CLOCKWISE' | 'COUNTERCLOCKWISE' | RefSys ].

RefSys = ( '{' RefSys-MetaObjectRef [ '[' Axis-PosNumber ']' ] '}'
         | '<' Coord-DomainRef [ '[' Axis-PosNumber ']' ] '>' ).

DecConst = ( Dec | 'PI' | 'LNBASE' ).

NumericConst = DecConst [ '[' UnitRef ']' ].

3.8.6. Formatierte Wertebereiche

Formatierte Wertebereiche basieren auf Strukturen und verwenden deren numerische oder formatierte Attribute in einem Format. Dieses Format dient einerseits dem Datenaustausch (vgl. 3.3.11.5 Codierung von formatierten Wertebereichen), andererseits der Definition von unterer und oberer Grenze des Wertebereichs.

※

Syntaxregeln:

FormattedType = ( 'FORMAT' ( 'BASED' 'ON' StructureRef FormatDef
                             [ Min-String '..' Max-String ]
                           | FormattedType-DomainRef
                             Min-String '..' Max-String
                           ) )
                | Min-String '..' Max-String.

FormatDef = '(' [ 'INHERITANCE' ]
                  [ NonNum-String ] { BaseAttrRef NonNum-String }
                                      BaseAttrRef [ NonNum-String ] ')'.

BaseAttrRef = ( NumericAttribute-Name [ '/' IntPos-PosNumber ]
              | StructureAttribute-Name '/' Formatted-DomainRef ).

FormattedConst = String.

Eine Basisdefinition eines formatierten Wertebereichs definiert primär die Struktur, auf welcher er aufbaut und das Format das zur Anwendung kommt. Zusätzlich können die untere und obere Grenze des Wertebereichs definiert werden. Sie dürfen die mit der Struktur definierten Grenzen nicht ausweiten.

Im Rahmen einer Erweiterung kann auf eine Erweiterung der ursprünglichen Struktur Bezug genommen, das Format ergänzt (der geerbte Teil muss am Anfang stehen und im Interesse von Klarheit mittels des Schlüsselwortes INHERITANCE erwähnt werden) und der Wertebereich eingeschränkt werden.

In der Formatdefinition können einerseits konstante Strings, die nicht mit einer Ziffer beginnen (am Anfang, am Ende und zwischen den einzelnen Attributreferenzen) und andererseits direkte oder indirekte Attributreferenzen (über Strukturattribute) enthalten sein. Die Attributreferenz muss entweder ein numerisches Attribut oder ein Strukturattribut bezeichnen. Im Falle eines numerischen Attributes können Vorkommastellen festgelegt werden. Als Folge ergeben sich nötigenfalls führende Nullen. Die Nachkommastellen ergeben sich aus dem numerischen Wertebereich. Bei Strukturattributen muss definiert werden, gemäss welchem formatierten Wertebereich es formatiert werden soll. Die Struktur muss mit der Basisstruktur des Wertebereichs übereinstimmen oder eine Erweiterung davon sein.

3.8.7. Datum und Zeit

Wo Datums- oder Zeitangaben nicht nur aus einem einzigen Wert (z.B. Jahr, Sekunde) bestehen, werden üblicherweise formatierte Wertebereiche verwendet.

※

Syntaxregel:

DateTimeType = ( 'DATE' | 'TIMEOFDAY' | 'DATETIME' ).

Die Wertebereiche für DATE, TIMEOFDAY bzw. DATETIME entsprechen den im Folgenden definierten INTERLIS.XMLDate, INTERLIS.XMLTime bzw. INTERLIS.XMLDateTime.

Im Interesse der Kompatibilität mit XML werden entsprechende Elemente durch INTERLIS vordefiniert:

UNIT
  Minute [min] = 60 [INTERLIS.s];
  Hour   [h]   = 60 [min];
  Day    [d]   = 24 [h];
  Month [M] EXTENDS INTERLIS.TIME;
  Year [Y] EXTENDS INTERLIS.TIME;

REFSYSTEM BASKET BaseTimeSystems ~ TIMESYSTEMS
  OBJECTS OF CALENDAR: GregorianCalendar
  OBJECTS OF TIMEOFDAYSYS: UTC;

STRUCTURE TimeOfDay (ABSTRACT) =
  Hours: 0 .. 23 CIRCULAR [h];
  CONTINUOUS SUBDIVISION Minutes: 0 .. 59 CIRCULAR [min];
  CONTINUOUS SUBDIVISION Seconds: 0.000 .. 59.999 CIRCULAR [INTERLIS.s];
END TimeOfDay;

STRUCTURE UTC EXTENDS TimeOfDay =
  Hours(EXTENDED): 0 .. 23 {UTC};
END UTC;

DOMAIN
  GregorianYear = 1582 .. 2999 [Y] {GregorianCalendar};

STRUCTURE GregorianDate =
  Year: GregorianYear;
  SUBDIVISION Month: 1 .. 12 [M];
  SUBDIVISION Day: 1 .. 31 [d];
END GregorianDate;

STRUCTURE GregorianDateTime EXTENDS GregorianDate =
  SUBDIVISION Hours: 0 .. 23 CIRCULAR [h] {UTC};
  CONTINUOUS SUBDIVISION Minutes: 0 .. 59 CIRCULAR [min];
  CONTINUOUS SUBDIVISION Seconds: 0.000 .. 59.999 CIRCULAR [INTERLIS.s];
END GregorianDate;

DOMAIN XMLDate = FORMAT BASED ON GregorianDate ( Year/4 "-" Month/2 "-" Day/2 );
DOMAIN XMLTime = FORMAT BASED ON UTC ( Hours/2 ":" Minutes/2 ":" Seconds/2 );
DOMAIN XMLDateTime EXTENDS XMLDate = FORMAT BASED ON GregorianDateTime
                           ( INHERITANCE "T" Hours/2 ":" Minutes/2 ":" Seconds/2 );

Anwendungsbeispiel:

CLASS Projekt =
  Start: FORMAT INTERLIS.XMLDateTime "2000-01-01T00:00:00.000" ..
                                     "2005-12-31T23:59:59.999";
  Ende: FORMAT INTERLIS.XMLDateTime "2002-01-01T00:00:00.000" ..
                                    "2007-12-31T23:59:59.999";
END Projekt;

3.8.8. Koordinaten

Koordinaten können ein-, zwei- oder dreidimensional definiert werden und sind entsprechend eine Einzelzahl, ein Zahlenpaar oder ein Zahlentripel. Es ist zulässig, dass die zweite oder dritte Dimension erst in einer Erweiterung beigefügt wird. Für jede Dimension muss der numerische Wertebereich sowie allenfalls eine Masseinheit und ein Koordinatensystem (inkl. Achsnummern) angegeben werden. Es gelten die gleichen Regeln wie bei den numerischen Datentypen. Es können nur konkrete Masseinheiten angegeben werden. Wird kein Referenzsystem angegeben und sind die Masseinheiten entweder nicht oder als Längeneinheit definiert, darf ein Programmsystem, das das Modell implementiert, davon ausgehen, dass es sich um kartesische Koordinaten handelt.

Wird eine Rotationsangabe gemacht (Schlüsselwort ROTATION) kann im Rahmen von Richtungsdefinitionen (vgl. Kapitel 3.8.5, “Numerische Datentypen”) auf ein solches Koordinaten-Referenzsystem verwiesen werden. Die Rotationsdefinition legt fest, welche Achse des Koordinaten-Wertebereichs der Nullrichtung und welche der Richtung eines positiven, rechten Winkels entsprechen. Sie darf auch in einer konkreten Koordinatendefinition fehlen und dann allenfalls in einer Erweiterung beigefügt werden.

Die Angaben betreffend Achsbezug und Rotation können in Erweiterungen nicht geändert werden.

Beispiel

DOMAIN
  CHKoord = COORD 480000.00 .. 850000.00 [m] {CHLV03[1]},
                   60000.00 .. 320000.00 [m] {CHLV03[2]},
                  ROTATION 2 -> 1 REFSYS "EPSG:21781";

Bei den zwei definierten Achsen wird nebst dem zulässigen Bereich angegeben, auf welche Einheiten und welches Referenzsystem samt Achsennummer sich die Koordinaten beziehen. Die eigentlichen Achsen sind beim Referenzsystem definiert. Die Rotationsdefinition legt fest, dass die Nullrichtung von der zweiten zur ersten Achse führt, beim Schweizerischen System, wo der erste Wert der Ostwert, der zweite der Nordwert ist, zeigt die Nullrichtung nach Norden und dreht im Uhrzeigersinn.

DOMAIN
  WGS84Koord = COORD –90.00000 ..  90.00000          [Units.Angle_Degree] {WGS84[1]},
                       0.00000 .. 359.99999 CIRCULAR [Units.Angle_Degree] {WGS84[2]},
                      -1000.00 .. 9000.00            [m] {WGS84Alt[1]};

Geografische Koordinaten sind typischerweise in Grad dargestellt und beziehen sich auf ein ellipsoidisches Koordinatensystem (z.B. CH1903). Die Höhe andererseits ist in Meter beschrieben. Sie bezieht sich auf ein spezielles Ellipsoid-Höhen-System mit einer Achse.

※

Syntaxregeln:

CoordinateType = ( 'COORD' | 'MULTICOORD' ) NumericType
                   [ ',' NumericType [ ',' NumericType ]
                       [ ',' RotationDef ] [ 'REFSYS' Name-String ] ].

RotationDef = 'ROTATION' NullAxis-PosNumber '->' PiHalfAxis-PosNumber.

Mit der optionalen Angabe REFSYS kann der EPSG-Code^[5] des Referenzsystems gemäss dem Muster EPSG:PosNumber festgelegt werden.

Mit dem Schlüsselwort MULTICOORD statt COORD wird als Wertebereich eine ungeordnete Menge von Koordinaten definiert. Im Unterschied zu einer Formulierung mit LIST/BAG haben die einzelnen Werte aber zwingend dasselbe Referenzsystem.

Sind die Definitionen unvollständig, muss der Wertebereich entweder als abstrakt (Property ABSTRACT) oder als generisch (Property GENERIC) deklariert werden.

Bei abstrakten Koordinatenbereichen kann selbst die Anzahl Dimensionen offen bleiben. Abstrakte Wertebereiche können nur in Attributen verwendet werden, die als abstrakt deklariert sind. Abstrakte Koordinatenbereiche können dann auf verschiedene Arten konkretisiert werden.

Bei generischen Koordinatenbereichen muss die Anzahl der Dimensionen festgelegt sein. Es ist aber zulässig, dass dabei nur die Angabe NUMERIC gemacht wird. Generische Wertebereiche können auch in Attributen verwendet werden, die nicht als abstrakt deklariert sind. Generische Koordinaten-Wertebereiche können gleich wie abstrakte konkretisiert werden. Dabei werden insbesondere die numerischen Wertebereiche der Achsen und das Referenzsystem (Concrete-DomainRef) festgelegt bzw. eingeschränkt.

DOMAIN
  Coord2 (GENERIC) = COORD NUMERIC, NUMERIC;

CLASS Punkt =
  Pos: Coord2;
END Punkt;

Das Thema (TOPIC), zu dem eine solche Definition gehört, muss aber als abstrakt deklariert werden, sofern keine Kontextdefinition wirkt.

Mit einer Kontextdefinition können für einen generischen Koordinaten-Wertebereich (Generic-CoordDef-DomainRef) konkrete Koordinaten-Wertebereiche definiert werden. Wurde für einen generischen Koordinaten-Wertebereich nicht nur ein einzelner, sondern eine Auswahl von möglichen konkreten Koordinaten-Wertebereichen festgelegt, wird beim Transfer des einzelnen Behälters, der für diesen Behälter geltende Wertebereich festgehalten (vgl. Kapitel 4.3.6, “Codierung von Themen”). Die Tatsache, dass die Festlegung aufgeschoben ist, muss beim Thema angemerkt werden (vgl. Kapitel 3.5.2, “Themen”). Der letztlich gültige konkrete Koordinaten-Wertebereich gilt bei allen Verwendungen des generischen Koordinaten-Wertebereichs und bei allen Verwendungen von Linien-Wertebereichen, die auf dem generischen Koordinaten-Wertebereich basieren.

※

Syntaxregel:

ContextDef = 'CONTEXT' { Context-Name '=' { GenericCoordDef-DomainRef '='
             Concrete-DomainRef { 'OR' Concrete-DomainRef } ';' } }.

Der Name des Kontexts ist ohne Bedeutung muss aber nach den allgemeinen Regeln eindeutig sein und dient z.B. für allfällige Fehlermeldungen. Ein Kontext wirkt in dem Modell wo er definiert wird und in allen Modellen, welche das definierende Modell direkt oder indirekt importieren.

CONTEXT default =
  MyModel.Coord2 = GeometryCHLV03.Coord2 OR GeometryCHLV95.Coord2;

Wirkt für einen bestimmten generischen Koordinaten-Wertebereich bereits eine Kontextdefinition, kann mit einer neuen Kontextdefinition für denselben generischen Koordinaten-Wertebereich eine neue Festlegung für den konkreten Wertebereich gemacht werden. Diese neuen Wertebereiche müssen aber Spezialisierungen der bestehenden Festlegungen sein.

DOMAIN
  Coord2Special EXTENDS GeometryCHLV03.Coord2 = COORD … ;

CONTEXT default =
  MyModel.Coord2 = Coord2Special;

3.8.9. Wertebereiche von Objektidentifikationen

Identifizierbare Objekte werden immer mit einer Objektidentifikation versehen. Damit für die Systeme klar ist, welcher Speicherplatz dafür vorgesehen werden muss und wie die Objektidentifikationen erzeugt werden müssen, können entsprechende Wertebereiche definiert und diese den Themen bzw. Klassen (vgl. Kapitel 3.5.2, “Themen” und Kapitel 3.5.3, “Klassen und Strukturen”) zugeordnet werden. Für die Verwaltung von Objektidentifikationen, insbesondere auch von Behältern, macht es aber Sinn, gewöhnliche Attribute mit solchen Wertebereichen zu führen.

※

Syntaxregel:

OIDType = 'OID' ( 'ANY' | NumericType | TextType ).

INTERLIS 2 selbst definiert die folgenden OID-Wertebereiche (vgl. Anhang A Das interne INTERLIS-Datenmodell):

DOMAIN
  NOOID = OID ANY;                             !! beliebiger, nicht stabiler
                                               !! Identifikator
  ANYOID (ABSTRACT) EXTENDS NOOID = OID ANY;
  I32OID EXTENDS ANYOID = OID 0 .. 2147483647; !! positive, 4 Bytes Integerwerte
  STANDARDOID EXTENDS ANYOID = OID TEXT*16;    !! gemäss Anhang F (nur Ziffern
                                               !! und Buchstaben erlaubt)
  UUIDOID EXTENDS ANYOID = OID TEXT*36;        !! gemäss ISO 11578

Es ist nicht möglich, eine OID-Definition zu erweitern, ausser dass ein NOOID durch ANYOID, und ANYOID zu einer konkreten Definition (nicht OID ANY) erweitert werden kann.

Wird ANYOID für abstrakte Themen bzw. Klassen angewendet, wird verlangt, dass eine Objektidentifikation erwartet wird, die genaue Definition aber noch offen ist. Sonst kann ANYOID nur als Wertebereich von Attributen verwendet werden. Zum Attributwert gehört dann nicht nur die eigentliche OID, sondern auch der konkrete OID-Wertebereich. OID-Werte von textlichen OID-Wertebereichen müssen die XML-ID Regel in Kapitel 4.3.1, “Einleitung” erfüllen: erstes Zeichen muss ein Buchstabe, eine Ziffer oder ein Unterstrich sein, dann folgen Buchstaben, Ziffern, Punkte, Minuszeichen, Unterstriche; keine Doppelpunkte (!).

3.8.10. Gefässe

Durch Einsatz dieses Datentyps können Attribute modelliert werden, deren Inhalt nicht spezifiziert werden kann. Die Variante XML beschreibt ein Attribut mit XML-Inhalt und die Variante BINARY einen binären Inhalt. Dieser Typ kann in Erweiterungen nicht verfeinert werden.

※

Syntaxregel:

BlackboxType = 'BLACKBOX' ( 'XML' | 'BINARY' ).

3.8.11. Wertebereiche von Klassen und Attributpfaden

Es kann Sinn machen, dass Datenobjekte Verweise auf bestimmte Klassen und Attribute enthalten.

※

Syntaxregeln:

ClassType = ( 'CLASS'
                [ 'RESTRICTION' '(' ViewableRef
                                    { ';' ViewableRef } ')' ]
            | 'STRUCTURE'
                [ 'RESTRICTION' '(' ClassOrStructureRef
                                    { ';' ClassOrStructureRef } ')' ] ).

AttributePathType = 'ATTRIBUTE'
                    [ 'OF' ( ClassType-AttributePath
                           | '@' Argument-Name ) ]
                    [ 'RESTRICTION' '(' AttrTypeDef
                                        { ';' AttrTypeDef } ')' ].

ClassConst = '>' ViewableRef.

AttributePathConst = '>>' [ ViewableRef '->' ] Attribute-Name.

Mit der Angabe von STRUCTURE wird eine beliebige Struktur oder Klasse, mit CLASS (auch als Erweiterung von STRUCTURE zulässig) eine beliebige Klasse (aber keine Strukturen) zugelassen. Sollen nur bestimmte Strukturen bzw. Klassen und ihre Erweiterungen zugelassen sein, sind diese aufzuführen (RESTRICTION). In Erweiterungen müssen erneut alle zulässigen Strukturen bzw. Klassen aufgeführt werden. Sie dürfen aber nicht im Widerspruch zur Basisdefinition sein. Sobald solche Einschränkungen definiert sind, kann darum STRUCTURE nicht mehr durch CLASS erweitert werden.

Mit der Angabe von ATTRIBUTE wird ein Attributpfadtyp zugelassen. Es kann verlangt werden, dass es zu einer Klasse (keine Subklasse!) gemäss einer anderen Definition gehört (OF). Dabei kann entweder auf ein ClassType-Attribut oder im Falle einer Definition einer Funktion (vgl. Kapitel 3.14, “Funktionen”) auf ein anderes Argument verwiesen werden. Die möglichen Attributtypen können zudem eingeschränkt werden (RESTRICTION). Als Konstante kommen die Namen von Attributen der Klassen, Strukturen, Assoziationen und Sichten in Frage. Der entsprechende Klassenname kann explizit angegeben werden oder ergibt sich aus dem Kontext bzw. aus dem Verweis auf ein anderes Attribut oder ein anderes Argument (OF).

3.8.12. Linienzüge

3.8.12.1. Geometrie des Linienzugs

Anschaulich ist ein Kurvenstück ein 1-dimensionales Gebilde, das keine Risse, keine Ecken und keine Doppelpunkte jeglicher Art hat (siehe Abbildung 10 und Abbildung 11). Kurvenstücke sind also glatt und eindeutig. Strecken, Kreisbogen, Parabel- und Klothoidenstücke sind Beispiele von Kurvenstücken. Jedes Kurvenstück hat zwei Randpunkte (Anfangs- und Endpunkt), die nicht zusammenfallen dürfen. Die übrigen Punkte des Kurvenstückes heissen innere Punkte. Diese bilden das Innere des Kurvenstückes.

Exakte Definition (mathematische Begriffe, die nicht weiter erklärt werden, deren Definition man aber in Lehrbüchern findet, werden «kursiv und in Anführungszeichen» geschrieben): Kurvenstück heisst eine Teilmenge des «3-dimensionalen» «Euklidischen Raumes» (im folgenden kurz Raum genannt), die «Bildmenge» einer «glatten» und «injektiven» «Abbildung» eines «Intervalls» (der «Zahlengerade») ist. Anfangs- und Endpunkt des Kurvenstücks sind die Bilder der Intervallenden. Ebenes Kurvenstück heisst ein Kurvenstück, das in einer Ebene («2-dimensionaler» «Unterraum» des Raumes) liegt.

Abbildung 10. Beispiele von ebenen Kurvenstücken.

Abbildung 11. Beispiele von ebenen Mengen, die nicht Kurvenstücke sind (ein doppelter Kreis bedeutet "nicht glatt" und ein doppeltes Rechteck "nicht injektiv").

Ein Linienzug ist eine endliche Folge von Kurvenstücken. Ausser beim ersten Kurvenstück stimmt der Anfangspunkt jeweils mit dem Endpunkt des Vorgänger-Kurvenstückes überein. Diese Punkte heissen Stützpunkte des Linienzuges. Anschaulich kann ein Linienzug mehrfach benützte Kurvenstücke, Kurvenstücke mit zusammenfallenden Stützpunkten, sich schneidende Kurvenstücke und im Innern von Kurvenstücken endende oder startende Kurvenstücke enthalten (siehe Abbildung 12 und Abbildung 13). Ein einfacher Linienzug weist keinerlei Selbst-Schnittpunkte auf (siehe Abbildung 14). Bei einem einfach geschlossenen Linienzug stimmt zudem der Anfangspunkt des ersten Kurvenstücks mit dem Endpunkt des letzten überein.

Exakte Definition (mathematische Begriffe, die nicht weiter erklärt werden, deren Definition man aber in Lehrbüchern findet, werden «kursiv und in Anführungszeichen» geschrieben): Linienzug heisst eine Teilmenge des Raumes, die «Bildmenge» einer "stetigen" und «stückweise glatten» (aber nicht notwendigerweise «injektiven») «Abbildung» eines «Intervalls» ist (der so genannten zugeordneten Abbildung) und nur endlich viele «nicht glatte Stellen» aufweist. Eine «nicht glatte Stelle» heisst Ecke. Bei einem geschlossenen Linienzug stimmen Anfangs- und Endpunkt überein. Einfacher Linienzug heisst ein Linienzug, dessen zugeordnete Abbildung auch «injektiv» ist. Einfach geschlossener Linienzug heisst ein Linienzug, dessen zugeordnete Abbildung auch «injektiv» ist, abgesehen von seinem Anfangs- und Endpunkt, die übereinstimmen.

Abbildung 12. Beispiele von (ebenen) Linienzügen.

Abbildung 13. Beispiele von ebenen Mengen, die nicht Linienzüge sind (ein doppelter Kreis bedeutet hier "nicht stetig" und der Rhombus "nicht Bild eines Intervalls").

Abbildung 14. Beispiele von (ebenen) einfachen Linienzügen.

3.8.12.2. Linienzug mit Strecken und Kreisbogen als vordefinierte Kurvenstücke

INTERLIS 2 kennt gerichtete (DIRECTED POLYLINE), ungerichtete (POLYLINE) oder eine Menge von ungerichteten (MULTIPOLYLINE) Linienzügen. Bei einem einzelnen Linienzug ([DIRECTED] POLYLINE) sind aber beim Transfer eines Ausschnittes auch MULTIPOLYLINE zulässig (vgl. Kapitel 4.3.6, “Codierung von Themen”). Bei einer Menge von Linienzügen (MULTIPOLYLINE) müssen die einzelnen Linienzüge nicht miteinander verbunden sein. Zudem werden Linienzüge im Rahmen von Einzelflächen und Gebietseinteilungen (vgl. Kapitel 3.8.13, “Einzelflächen und Gebietseinteilungen”) verwendet.

Zur Definition eines konkreten Linienzug-Wertebereichs gehört immer die Angabe der erlaubten Kurvenstück-Formen mittels Aufzählung, z.B. Strecken (Schlüsselwort STRAIGHTS), Kreisbogen (Schlüsselwort ARCS) oder weitere Möglichkeiten (vgl. Kapitel 3.8.12.3, “Weitere Kurvenstück-Formen”), und die Angabe des Wertebereichs der Stützpunkte. In einem abstrakten Linienzug-Wertebereich dürfen diese Angaben fehlen. Für Wertebereichserweiterungen gelten folgende Regeln:

Die Kurvenstück-Form darf nur reduziert, nicht aber ergänzt werden.
Der Koordinaten-Wertebereich, der im Rahmen einer Erweiterung eines Linienzug-Wertebereichs angegeben wird, muss eine Einschränkung des Koordinaten-Wertebereichs des Basis-Linienzug-Wertebereichs sein, sofern ein solcher definiert ist.

Die Kurvenstücke werden immer als Erweiterung der Grundstruktur 'LineSegment' aufgefasst. Der darin verwendete Koordinatenwertebereich ist der in der Liniendefinition angegebene.

STRUCTURE LineSegment (ABSTRACT) =
  SegmentEndPoint: MANDATORY LineCoord;
END LineSegment;

STRUCTURE StartSegment (FINAL) EXTENDS LineSegment =
END StartSegment;

STRUCTURE StraightSegment (FINAL) EXTENDS LineSegment =
END StraightSegment;

STRUCTURE ArcSegment (FINAL) EXTENDS LineSegment =
  ArcPoint: MANDATORY LineCoord;
  Radius: NUMERIC [LENGTH];
END ArcSegment;

Das erste Kurvenstück eines Linienzuges ist immer ein Startsegment. Das Startsegment besteht nur aus dem Startpunkt selbst, der zugleich auch Endpunkt des Startsegments ist. Das Geradenstück hat einen Endpunkt und definiert dadurch eine Strecke vom Endpunkt des vorherigen Kurvenstücks zu seinem Endpunkt. Startsegment und Geradenstücke brauchen keine weiteren Angaben. Die entsprechenden Erweiterungen von 'LineSegment' sind darum leer. Zwei aufeinander folgende Stützpunkte (SegmentEndPoints) dürfen in der Projektion nicht aufeinander fallen.

Ein Kreisbogenstück beschreibt ein Kurvenstück, das in der Projektion als echtes Kreisbogenstück erscheint. Ein Kreisbogenstück wird zusätzlich zum Endpunkt mit einem Zwischenpunkt und fakultativ einem Radius beschrieben. Der Zwischenpunkt ist nur in der Lage von Bedeutung und gilt nicht als Stützpunkt des Linienzuges. Er soll möglichst exakt in der Mitte zwischen Anfangs- und Endpunkt liegen und mindestens die gleiche Genauigkeit (Anzahl Nachkommastellen) wie die Stützpunkte aufweisen. Ist kein Radius angegeben, ergibt sich der Kreisbogen aus Anfangs-, Zwischen- und Endpunkt des Kurvenstücks. Wird der effektive Radius angegeben, ist er für die Kreisbogendefinition massgebend. Der Zwischenpunkt legt nur noch fest, welcher der vier möglichen Kreisbogen der gewünschte ist.

Bei dreidimensionalen Koordinaten wird die Höhe auf dem Kreisbogenstück linear interpoliert. Man kann sich die Kurve als Gewindestück einer zylindrischen Schraube vorstellen, die senkrecht auf der Projektionsfläche steht. INTERLIS regelt nicht, wie der Kreisbogen im Detail verläuft und wie der zusätzliche Punkt bestimmt werden muss. In einem System kann ein INTERLIS-Kreisbogen je nach internem Umgang leicht unterschiedlich dargestellt werden und bei einer erneuten Ausgabe nach INTERLIS auch zu unterschiedlichen Daten führen. INTERLIS-Kreisbogen beschreiben also nicht ihren exakten Verlauf, sondern eine Spur, die beidseitig des exakten Verlaufs je einen Abstand aufweist, der kleiner ist als der Wert 1 der hintersten Stelle gemäss Wertebereichsdefinition multipliziert mit der Hälfte der Quadratwurzel von 2 [z.B. 0.001 * sqrt(2) / 2 bei Koordinaten mit 3 Nachkommastellen]. Liegt die gerade Verbindung zwischen Anfangs- und Endpunkt eines Kreisbogens innerhalb dieser Spur, darf das Leseprogramm den Kreisbogen durch ein Geradenstück ersetzen.

Aus fachlicher Sicht soll oft ausgedrückt werden, dass es sich bei einem Linienzug um einen einfachen Linienzug handelt, d.h. anschaulich, dass Überlappungsfreiheit gegenüber konkurrierenden Linienzügen (vgl. unten) besteht. Bei der Überprüfung der Überlappungsfreiheit durch Systeme besteht bei Kreisbogen allerdings das technische Problem, dass in Grenzsituationen unterschiedliche Systeme auf Grund unterschiedlicher Rechengenauigkeiten und unterschiedlicher Berechnungsweisen zu unterschiedlichen Resultaten bezüglich Überschneidung kommen. Um dies möglichst zu vermeiden, sollen Systeme dafür sorgen, dass konkurrierende Linienstücke nicht mit der Spur des Kreisbogens überlappen. Dennoch ist es möglich, dass ein anderes System minimale Überlappungen darstellt.

Bei Daten, die grafisch erfasst wurden, kann es Sinn machen, grössere Überlappungen (z.B. einige Zentimeter) zu tolerieren, um einen enormen Nachbearbeitungsaufwand zu vermeiden. Dafür wird Überlappungsfreiheit bei Kreisbogen wie folgt geregelt:

Weisen ein Kreisbogen und ein konkurrierendes Linienstück einen gemeinsamen Stützpunkt auf, dürfen sie sich in einem weiteren Punkt (kein Stützpunkt) schneiden, falls das von der Strecke abgeschnittene Kreissegment (bzw. das vom anderen Kreisbogen abgeschnittene Doppel-Kreissegment) eine Pfeilhöhe aufweist, die kleiner oder gleich der definierten Toleranz ist. Fehlt die Toleranzangabe, gilt der Wert gemäss den technischen Überlegungen (vgl. oben). Bei expliziter Angabe (auf WITHOUT OVERLAPS > folgende Dezimalzahl) muss sie mit derselben numerischen Stellenzahl wie diejenige der Stützpunktkoordinaten erfolgen und einen Wert grösser Null aufweisen.

Abbildung 15. a) Die Pfeilhöhe darf nicht grösser als die angegebene Toleranz sein; b), c) unzulässige Überschneidungen eines Linienzuges, da Strecke und Kreisbogen, die sich treffen, nicht von einem gemeinsamen Stützpunkt ausgehen.

Konkurrierende Linienstücke ergeben sich wie folgt:

Bei einzelnen Linienzügen (POLYLINE): durch die anderen Linienstücke des Linienzugs, sofern Überlappungsfreiheit (WITHOUT OVERLAPS) verlangt wurde.
Bei Einzelflächen (SURFACE): durch die anderen Linienstücke der Flächenberandung.
Bei Gebietseinteilung (AREA): durch alle anderen Linienstücke der Gebietseinteilung.

Da die Überlappungsfreiheit bei Einzelflächen und Gebietseinteilung zwingend ist, kann auf die Verwendung WITHOUT OVERLAPS verzichtet werden, wenn nur die Spurbreite zur Anwendung kommen soll.

Die Toleranzangabe (explizit oder implizit) kann nicht übersteuert werden. Im Rahmen von Wertebereichsdefinitionen und Attributserweiterungen können ungerichtete Linienzüge zu gerichteten Linienzügen erweitert werden (vgl. Kapitel 3.8.13.4, “Erweiterbarkeit”). Sind Linienzüge gerichtet, muss ihr Richtungssinn immer (auch bei einem Datentransfer) erhalten bleiben.

Für die Stützpunkte wird der Wertebereich der Koordinaten definiert. Für INTERLIS-Linien kommen nur kartesische Koordinatensysteme in Frage, bei denen die Wertebereiche aller Achsen dieselbe Stellenzahl aufweisen. Mittels der Existenzbedingung REQUIRED IN (vgl. Kapitel 3.12, “Konsistenzbedingungen” und Kapitel 3.13, “Ausdrücke”) kann zudem gefordert werden, dass die Koordinaten nicht beliebig sein dürfen, sondern denjenigen der Punkte bestimmter Klassen entsprechen müssen.

Ist der Koordinatentyp der Stützpunkte abstrakt, muss der Linienzug seinerseits als abstrakt deklariert werden.

※

Syntaxregeln:

LineType = ( [ 'DIRECTED' ] 'POLYLINE' | 'SURFACE' | 'AREA' |
            [ 'DIRECTED' ] 'MULTIPOLYLINE' | 'MULTISURFACE' | 'MULTIAREA' )
           [ LineForm ] [ ControlPoints ] [ IntersectionDef ].

LineForm = 'WITH' '(' LineFormType { ',' LineFormType } ')'.

LineFormType = ( 'STRAIGHTS' | 'ARCS'
               | [ Model-Name '.' ] LineFormType-Name ).

ControlPoints = 'VERTEX' CoordType-DomainRef.

IntersectionDef = 'WITHOUT' 'OVERLAPS' [ '>' Dec ].

Linien können auf generischen Koordinaten aufbauen, ohne dass sie selbst als generisch deklariert werden. Sie erhalten ihre konkrete Festlegung mit der Festlegung des Koordinaten-Wertebereichs (im Rahmen einer Kontextdefinition bzw. im Rahmen des Datentransfers). Es ist dafür nicht nötig (aber durchaus zulässig), dass zu Linien-Wertebereichen, die auf generischen Koordinaten-Wertebereichen aufbauen, Linien-Wertebereiche definiert sind, die auf konkreten Koordinaten-Wertebereichen aufbauen.

DOMAIN
  Coord2 (GENERIC) = COORD NUMERIC, NUMERIC;
  Line = POLYLINE WITH (STRAIGHTS, ARCS) VERTEX Coord2;

3.8.12.3. Weitere Kurvenstück-Formen

Nebst Geradenstücken und Kreisbogen sind weitere Kurvenstück-Formen definierbar. Nebst dem Namen muss angegeben werden, gemäss welcher Struktur ein Kurvenstück beschrieben wird.

※

Syntaxregeln

LineFormTypeDef = 'LINE' 'FORM'
                    { LineFormType-Name ':' LineStructure-Name ';' }.

Eine Linienstruktur muss immer eine Erweiterung der durch INTERLIS definierten Struktur LineSegment sein (vgl. Kapitel 3.8.12.2, “Linienzug mit Strecken und Kreisbogen als vordefinierte Kurvenstücke”).

3.8.13. Einzelflächen und Gebietseinteilungen

3.8.13.1. Geometrie von Flächen

Für die Modellierung von Geodaten genügen meist ebene Flächen. INTERLIS unterstützt darüber hinaus ebene allgemeine Flächen. Anschaulich ist eine ebene allgemeine Fläche durch eine äussere und allenfalls eine oder mehrere innere Randlinien begrenzt (siehe Abbildung 20). Die Randlinien selbst müssen aus einfachen Linienzügen bestehen, die aus geometrischer Sicht jeweils zu einfach geschlossenen Linienzügen zusammengefasst werden können. Sie müssen zudem so angeordnet sein, dass es von einem beliebigen Punkt im Innern der Fläche immer einen Weg zu einem beliebigen anderen Punkt im Innern der Fläche gibt, der weder eine Randlinie schneidet noch einen Stützpunkt einer Randlinie enthält (siehe Abbildung 20). Soweit diese Bedingung nicht verletzt wird, dürfen sich Ränder in Stützpunkten berühren. In solchen Situationen kann man sich grundsätzlich verschiedene Möglichkeiten vorstellen, wie die Umrandung der Fläche als Ganzes in einzelne Linienzüge aufgeteilt wird (siehe Abbildung 22). INTERLIS schliesst sich aber einer verbreiteten Regelung (z.B. OGC/ISO) an und verlangt, dass alle Punkte einer Randlinie (ausser Anfangs- /Endpunkt) disjunkt sein müssen. Die Varianten b und c von Abbildung 22 sind im Transfer darum nicht zugelassen.

Exakte Definitionen (mathematische Begriffe, die nicht weiter erklärt werden, deren Definition man aber in Lehrbüchern findet, werden «kursiv und in Anführungszeichen» geschrieben):

Flächenelement heisst eine Teilmenge des Raumes, die «Bildmenge» einer «glatten» und «injektiven» «Abbildung» eines «ebenen» «regulären Vielecks» ist (siehe Abbildung 16 und Abbildung 17).

Fläche heisst die Vereinigung F von endlich vielen Flächenelementen, die «zusammenhängend» ist und folgender Bedingung genügt: Zu jedem Punkt P der Fläche gibt es eine «Umgebung», die sich in ein ebenes reguläres Vieleck deformieren (d.h. «homöomorph abbilden») lässt. Wenn bei einer solchen Deformation der Punkt P in den Rand des Vielecks übergeführt wird, heisst er Randpunkt von F, andernfalls innerer Punkt von F. Es gilt: Der «Rand» (d.h. die Menge aller Randpunkte) einer Fläche ist die Vereinigung von endlich vielen Kurvenstücken, die nur Endpunkte gemeinsam haben. Eine ebene Fläche ist eine Fläche, die Teilmenge einer Ebene ist. Es gilt: Der Rand einer «einfach zusammenhängenden» ebenen Fläche (anschaulich: einer Fläche ohne Löcher) ist ein einfach geschlossener Linienzug und heisst äusserer Rand. Der Rand einer «n-fach zusammenhängenden» ebenen Fläche (anschaulich: einer Fläche mit n-1 Löchern) besteht aus dem entsprechenden äusseren Rand und aus n-1 weiteren einfach geschlossenen Linienzügen (den so genannten inneren Rändern). Der äussere Rand und alle inneren Ränder haben keine Punkte gemeinsam. Ein durch einen inneren Rand ausgespartes Flächenstück heisst Enklave (siehe Abbildung 18, Abbildung 19 und Abbildung 20). Eine allgemeine Fläche ist eine Fläche mit zusätzlich endlich vielen singulären Punkten aber mit «zusammenhängendem» Inneren (Menge der inneren Punkte). Ein singulärer Punkt kann zusammen mit einer «Umgebung» in eine ebene Propellermenge deformiert werden, er selbst ins Zentrum. Propellermenge heisst die Vereinigung endlich vieler Dreiecksflächen, die genau einen Punkt gemeinsam haben, das Zentrum. Ebene allgemeine Fläche heisst eine allgemeine Fläche, die Teilmenge einer Ebene ist (siehe Abbildung 21). Es gilt: Der Rand einer ebenen allgemeinen Fläche kann auf verschiedene Art zusammengesetzt werden aus endlich vielen geschlossenen Linienzügen, die höchstens endlich viele Punkte gemeinsam haben und je höchstens endlich viele Doppelpunkte aufweisen (siehe Abbildung 22).

Abbildung 16. Beispiele von Flächenelementen.

Abbildung 17. Beispiele von Punktmengen im Raum, die nicht Flächenelemente sind (ein doppelter Kreis bedeutet hier "nicht glatt").

Abbildung 18. Beispiele von Flächen im Raum.

Abbildung 19. Beispiele ebener Punktmengen, die nicht Flächen sind (ein doppelter Kreis bedeutet "singulärer Punkt").

Abbildung 20. Ebene Fläche mit Rändern und Enklaven.

Abbildung 21. a) Beispiele von allgemeinen ebenen Flächen; b) Beispiele von ebenen Mengen, die nicht allgemeine Flächen sind, weil ihr Inneres nicht zusammenhängend ist. Diese ebenen Mengen können aber in allgemeine Flächen unterteilt werden ("---" zeigt die Unterteilung in Flächenelemente und "===" die Unterteilung in allgemeine Flächen).

Abbildung 22. Verschiedene mögliche Aufteilungen des Randes einer allgemeinen Fläche. Variante a): gültig; Variante b): ungültig; Variante c): ungültig.

Mit der Definition von (allgemeinen) Einzelflächen bzw. (allgemeinen) Flächen einer Gebietseinteilung wird auch festgelegt, oberhalb welcher Toleranz sich die Kurvenstücke des Randes nicht überlappen dürfen (ohne Angabe von WITHOUT OVERLAPS gilt die implizite bzw. die geerbte Toleranz). Das Überlappungs- bzw. Schnittverbot gilt bei Einzelflächen nicht nur zwischen den Kurvenstücken eines einzelnen Linienzuges sondern zwischen allen Kurvenstücken aller Linienzüge des Flächenrandes. Für Flächen einer Gebietseinteilung gilt es sogar für alle an der Gebietseinteilung beteiligten Linienzüge. Zudem sind Linienzüge, die nicht zum Rand einer (allgemeinen) Fläche gehören, gemäss Definition der (allgemeinen) Fläche ausgeschlossen.

Linienzüge, die nicht zu einem Rand gehören, sind nicht erlaubt.

Abbildung 23. Nicht erlaubte Linien von Flächen.

3.8.13.2. Einzelflächen

Abbildung 24. Einzelflächen (SURFACE).

Für (allgemeine) Flächen, die sich ganz oder teilweise überlappen dürfen, d.h. die nicht nur Randpunkte gemeinsam haben dürfen, steht der geometrische Attributtyp SURFACE zur Verfügung (siehe Abbildung 24). Dieser Typ wird Einzelflächen genannt. Eine Einzelfläche hat einen äusseren und allenfalls mehrere inneren Ränder (um die Enklaven). Jeder Rand besteht aus mindestens einem Linienzug.

Mit dem Attributtyp MULTISURFACE kann auch eine Menge von Einzelflächen als ein einzelner Wert definiert werden. Die einzelnen Flächen eines MULTISURFACE-Wertes dürfen keine gemeinsamen Kanten haben und dürfen sich abgesehen von Overlaps nicht überlappen.

3.8.13.3. Flächen einer Gebietseinteilung

Abbildung 25. Gebietseinteilung (AREA).

Gebietseinteilung (Flächennetz) heisst eine endliche Menge von (allgemeinen) Flächen und Restflächen, welche die Ebene überlappungsfrei überdecken.

Für Gebietseinteilungen steht primär der geometrische Attributtyp AREA zur Verfügung. Dieser darf aber nicht innerhalb von Strukturen vorkommen, da die Menge der Gebietsobjekte erst durch die Verwendung der Struktur innerhalb einer Klasse klar ist. Sollen Einzelflächen von Strukturattributen ein Gebietsnetz bilden, soll dies mittels Konsistenzbedingungen mit den Standardfunktionen areAreasWithoutGaps bzw. areAreasWithoutGaps2 definiert werden.

Jedem Gebietsobjekt (bzw. Strukturelement) ist höchstens eine Fläche der Gebietseinteilung, nicht aber die Restfläche, zugeordnet. Soll jeder Fläche der Gebietseinteilung ein Gebietsobjekt entsprechen, soll dies mittels Konsistenzbedingungen mit den Standardfunktionen withoutGaps bzw. withoutGaps2 definiert werden.

Für Gebietsobjekte ergibt sich damit auch die gleiche implizite Struktur wie für Einzelflächen. Zusätzlich gilt aber folgende Konsistenzbedingung:

Liegen auf beiden Seiten eines Linienzuges definierte Gebietsobjekte, muss jedes Kurvenstück (Verbindung zweier Stützpunkte) des einen Gebietsobjektes genau einem Kurvenstück des anderen Gebietsobjektes entsprechen.

Damit die Linienzüge einer Gebietseinteilung auch als einzelne Objekte angesprochen werden können (und zwar als ein Objekt, auch wenn der Linienzug zwei Gebietsobjekte begrenzt), steht die AREA INSPECTION zur Verfügung (vgl. Kapitel 3.15, “Sichten”). Mit dem Attributtyp MULTIAREA kann auch eine Menge von einzelnen AREA-Objekten als ein einzelner Wert definiert werden. Die einzelnen Flächen eines MULTIAREA-Wertes dürfen keine gemeinsamen Kanten haben und dürfen sich abgesehen von Overlaps nicht überlappen.

3.8.13.4. Erweiterbarkeit

Einzelflächen können zu Gebietseinteilungen erweitert werden. Die Erweiterung eines Linienzuges zu einer Fläche ist unzulässig, da bei einer Fläche mit mehreren Linienzügen gerechnet werden muss, während mit der Definition eines Linienzuges nur einer erwartet wird.

Unabhängige Flächen und Flächen einer Gebietseinteilung können in zweierlei Hinsicht erweitert werden:

Ist primär SURFACE definiert, sind also Überlappungen zugelassen, darf dies in Erweiterungen durch AREA ersetzt werden, da damit die Grunddefinition nicht verletzt wird.

3.9. Einheiten

Einheiten werden immer durch eine Bezeichnung und (in [ ]-Klammern) ein Kurzzeichen beschrieben. Bezeichnung und Kurzzeichen müssen Namen sein. Fehlt die Kurzzeichen-Angabe, ist sie gleich der Bezeichnung. Je nach Art der Einheit können weitere Angaben folgen. Der Gebrauch einer Einheit erfolgt immer über das Kurzzeichen. Die Bezeichnung hat damit nur dokumentarischen Charakter.

3.9.1. Basiseinheiten

Basis-Einheiten sind Meter, Sekunden, etc. Sie brauchen keine weiteren Angaben mehr. Basis-Einheiten können aber auch abstrakt (Schlüsselwort ABSTRACT) definiert werden, wenn die Einheit selbst noch nicht bekannt ist, wohl aber der zu bezeichnende Gegenstand (z.B. Temperatur, Geld). Abstrakten Einheiten ist noch kein Kurzzeichen zugeordnet. Konkrete Einheiten können nicht mehr erweitert werden.

Beispiele:

UNIT
  Laenge (ABSTRACT);
  Zeit (ABSTRACT);
  Geld (ABSTRACT);
  Temperatur (ABSTRACT);
  Meter [m] EXTENDS Laenge;
  Sekunde [s] EXTENDS Zeit;
  SchweizerFranken [CHF] EXTENDS Geld;
  Celsius [C] EXTENDS Temperatur;

Durch INTERLIS selbst ist die abstrakte Einheit ANYUNIT definiert. Alle anderen Einheiten erben sie direkt oder indirekt (vgl. Kapitel 3.10.3, “Referenzsysteme”), ohne dass dies definiert werden muss. Folgende Einheiten sind durch INTERLIS direkt (d.h. intern) definiert:

UNIT
  ANYUNIT            (ABSTRACT);
  DIMENSIONLESS      (ABSTRACT);
  LENGTH             (ABSTRACT);
  MASS               (ABSTRACT);
  TIME               (ABSTRACT);
  ELECTRIC_CURRENT   (ABSTRACT);
  TEMPERATURE        (ABSTRACT);
  AMOUNT_OF_MATTER   (ABSTRACT);
  ANGLE              (ABSTRACT);
  SOLID_ANGLE        (ABSTRACT);
  LUMINOUS_INTENSITY (ABSTRACT);
  MONEY              (ABSTRACT);

  METER [m]          EXTENDS LENGTH;
  KILOGRAMM [kg]     EXTENDS MASS;
  SECOND [s]         EXTENDS TIME;
  AMPERE [A]         EXTENDS ELECTRIC_CURRENT;
  DEGREE_KELVIN [K]  EXTENDS TEMPERATURE;
  MOLE [mol]         EXTENDS AMOUNT_OF_MATTER;
  RADIAN [rad]       EXTENDS ANGLE;
  STERADIAN [sr]     EXTENDS SOLID_ANGLE;
  CANDELA [cd]       EXTENDS LUMINOUS_INTENSITY;

Hinweis: Im Anhang H Einheiten-Definitionen sind die gebräuchlichsten Einheiten in einem erweiterten Typenmodell zusammengefasst.

3.9.2. Abgeleitete Einheiten

Abgeleitete Einheiten sind durch Multiplikationen bzw. Divisionen mit Konstanten oder Funktion in eine andere Einheit umrechenbar.

Beispiele:

UNIT
  Kilometer [km] = 1000 [m];
  Centimeter [cm] = 1 / 100 [m];
  Inch [in] = 0.0254 [m];         !! 1 Zoll ist 2.54 cm
  Fahrenheit [oF] = FUNCTION // (oF + 459.67) / 1.8 // [K];

Werte in Kilometer müssen mit Tausend multipliziert werden, um Werte in Meter zu werden. Werte in Inch müssen mit 2.54 multipliziert werden um Werte in Zentimeter zu werden. Werte in Grad Fahrenheit müssen um 459.67 erhöht und durch 1.8 dividiert werden um zu Kelvin-Werten zu werden.

Eine abgeleitete Einheit ist automatisch eine Erweiterung der gleichen abstrakten Einheit, wie diejenige in die sie umgerechnet werden kann.

3.9.3. Zusammengesetze Einheiten

Zusammengesetzte Einheiten (z.B. km pro h) ergeben sich durch Multiplikationen oder Divisionen von anderen Einheiten (Basis-Einheit, abgeleitete oder zusammengesetzte Einheit). Zusammengesetzte Einheiten können auch als abstrakte Einheiten definiert werden. Sie müssen sich dann vollständig auf andere abstrakte Einheiten beziehen.

Die bei der konkreten Erweiterung verwendeten Einheiten müssen dann konkrete Erweiterungen der in der abstrakten Definition verwendeten Einheiten sein.

Beispiel:

UNIT
  Geschwindigkeit (ABSTRACT) = ( Laenge / Zeit );
  Stundenkilometer [kmph] EXTENDS Geschwindigkeit = ( km / h );

Syntaxregeln

UnitDef = 'UNIT'
            { Unit-Name
                [ '(' 'ABSTRACT' ')' | '[' UnitShort-Name ']' ]
                [ 'EXTENDS' Abstract-UnitRef ]
                [ '=' ( DerivedUnit | ComposedUnit ) ] ';' }.

DerivedUnit = [ DecConst { ( '*' | '/' ) DecConst }
              | 'FUNCTION' Explanation ] '[' UnitRef ']'.

ComposedUnit = '(' UnitRef { ( '*' | '/' ) UnitRef } ')'.

UnitRef = [ Model-Name '.' [ Topic-Name '.' ] ] UnitShort-Name.

3.10. Umgang mit Metaobjekten

3.10.1. Allgemeine Aussagen zu Metaobjekten

Metaobjekte im Sinne von INTERLIS 2 sind Objekte, die im Rahmen der Beschreibung von Anwendungsmodellen von Bedeutung sind. Dies wird für Referenzsysteme und Grafiksignaturen genutzt.

Der Aufbau von Referenzsystem- oder Signaturobjekten muss in einem REFSYSTEM MODEL oder einem SYMBOLOGY MODEL mit den üblichen Mitteln von Klassen und Strukturen definiert sein. Referenzsystem-, Achsen- bzw. Signatur-Klassen müssen dabei Erweiterungen der durch INTERLIS angebotenen Klassen COORDSYSTEM, REFSYSTEM, AXIS bzw. SIGN sein, die ihrerseits Erweiterungen der Klasse METAOBJECT sind. Diese weist ein Attribut Name auf, das im Rahmen aller Metaobjekte eines Behälters eindeutig sein muss.

Für die eigentliche Beschreibung eines Anwendungsmodells wird das Metaobjekt selbst nicht gebraucht. Es genügt, den Namen als Stellvertreter des Metaobjektes zu kennen. Für ein laufendes System müssen die Metaobjekte jedoch in der Regel vollständig, also mit allen ihren Attributen, bekannt sein. Für ein Laufzeitsystem muss es darum klar sein, in welchem Behälter ein Metaobjekt mit einem bestimmten Namen enthalten ist. Damit Metaobjekte (bzw. ihre Namen) in Modellen verwendet werden können, müssen sie deklariert werden. Dabei wird ein Behältername eingeführt, das dabei vorausgesetzte Thema angegeben und dann (pro Klasse) die Namen der dort erwarteten Objekte aufgezählt (Regel MetaDataBasketDef). Der Behältername kann dabei auch als Erweiterung eines bereits eingeführten Namens definiert werden (EXTENDS). Das zugehörige Thema muss dann das gleiche wie beim Basisnamen oder eine Erweiterung davon sein.

Wird der Bezug auf ein Metaobjekt (Regel MetaObjectRef) unter dem erweiterten Behälternamen gemacht, muss der Name des Metaobjektes dort oder in einer geerbten Definition erwähnt sein. Von einem Laufzeitsystem wird das Metaobjekt zuerst im zugehörigen Behälter gesucht. Wird dort kein solches Metaobjekt gefunden, wird die Suche in den Behältern gemäss den direkt oder indirekt geerbten Behälternamen fortgesetzt. Damit können Metaobjekte in mehreren Stufen bereitgestellt und verfeinert werden. Zum Beispiel können zunächst allgemeine Grafiksignaturen definiert werden, die dann auf regionaler Stufe verfeinert und ergänzt werden. Wie der konkrete Behälter auf Grund des Behälternamens angesprochen werden kann, ist dabei Sache des eingesetzten Laufzeitsystems.

In einem übersetzten Anwendungsmodell (vgl. Kapitel 3.5.1, “Modelle”), kann einem Behälternamen auch ein konkreter Behälter zugewiesen werden, der nur Übersetzungen enthält (METAOBJECT_TRANSLATION Objekte; vgl. Anhang A Das interne INTERLIS-Datenmodell). Damit werden diejenigen Metaobjekte übersetzt, die durch den entsprechenden Behälter im zu Grunde liegenden Modell eingeführt wurden. Ist das zu Grunde liegende Modell selbst eine Übersetzung, kann auch da dem Behälternamen ein konkreter Behälter zugewiesen sein, der nur Übersetzungen enthält. Ist das Modell keine Übersetzung, kann einem Behälternamen nur ein konkreter Behälter zugewiesen werden, der keine Übersetzungen (d.h. keine METAOBJECT_TRANSLATION Objekte) enthält.

※

Syntaxregeln:

MetaDataBasketDef = ( 'SIGN' | 'REFSYSTEM' ) 'BASKET' Basket-Name
                       Properties<FINAL>
                       [ 'EXTENDS' MetaDataBasketRef ]
                           '~' TopicRef
                       { 'OBJECTS' 'OF' Class-Name ':' MetaObject-Name
                           { ',' MetaObject-Name } } ';'.

MetaDataBasketRef = [ Model-Name '.' [ Topic-Name '.' ] ] Basket-Name.

MetaObjectRef = [ MetaDataBasketRef '.' ] Metaobject-Name.

Wird im aktuellen Kontext nur ein Metadaten-Behältername benötigt, muss die Referenz auf den Metadatenbehälter (MetaDataBasketRef) in der Metaobjekt-Referenz nicht angegeben werden.

3.10.2. Parameter

Mittels Parametern werden im Metamodell diejenigen Eigenschaften bezeichnet, die nicht das Metaobjekt selbst, sondern dessen Gebrauch in der Anwendung betreffen. Ihre Definition ist durch das Schlüsselwort PARAMETER eingeleitet und ist ähnlich aufgebaut wie diejenige der Attribute.

3.10.2.1. Parameter für Referenz- und Koordinatensysteme

Für Referenz- und Koordinatensysteme bzw. ihre Achsen ist nur der vordefinierte Parameter Unit zulässig.

Wird in der Definition eines numerischen Datentyps (vgl. Kapitel 3.8.5, “Numerische Datentypen”) oder eines Koordinatentyps (vgl. Kapitel 3.8.8, “Koordinaten”) auf ein Referenz- oder Koordinatensystem verwiesen (Regel RefSys) muss eine Einheit angegeben sein, die derjenigen der entsprechenden Achse des Koordinatensystems bzw. der einzigen Achse des Referenzsystems (vgl. Kapitel 3.10.3, “Referenzsysteme”) verträglich ist.

3.10.2.2. Parameter von Signaturen

Die Parameter von Signaturen sind frei definierbar. Diese Parameter entsprechen den Angaben (z.B. Punktsymbol-Identifikation, Position, Drehung), die einem Grafiksystem übergeben werden müssen, damit es die Grafik erzeugen kann. Primär muss die Signatur selbst gewählt werden können. Dies erfolgt durch die Definition eines Parameters für die Referenz zur Signaturklasse, in der der Parameter definiert ist (METAOBJECT). Als Parameter einer Signatur kann auch eine Referenz zu einem anderen Meta-Objekt angegeben werden (METAOBJECT OF). In beiden Fällen wird in der Anwendung (vgl. Kapitel 3.16, “Darstellungsbeschreibungen”) eine Metaobjekt-Referenz angegeben, d.h. es werden der Behälterreferenzname und der Metaobjektname angegeben. Damit können die effektive Behälter-Identifikation und MetaObjektidentifikation durch das jeweilige Werkzeug bestimmt werden.

Nebst diesen speziellen Parametern können Parameter gleich wie Attribute definiert werden.

※

Syntaxregel:

ParameterDef = Parameter-Name Properties<ABSTRACT,EXTENDED,FINAL>
                 ':' ( AttrTypeDef
                     | 'METAOBJECT' [ 'OF' MetaObject-ClassRef ] ) ';'.

3.10.3. Referenzsysteme

Ohne weitere Angaben sind numerische Werte und Koordinaten Differenzangaben; sie haben keinen definierten absoluten Bezug. Um dies zu erreichen, muss ein Koordinatensystem bzw. ein Skalarsystem definiert sein. Die Modelldefinition erfolgt dabei in einem REFSYSTEM MODEL. INTERLIS stellt dafür die folgenden Klassen zur Verfügung:

CLASS METAOBJECT (ABSTRACT) =
  Name: MANDATORY NAME;
UNIQUE Name;
END METAOBJECT;

STRUCTURE AXIS =
  PARAMETER
    Unit: NUMERIC [ ANYUNIT ];
END AXIS;

CLASS REFSYSTEM (ABSTRACT) EXTENDS METAOBJECT =
END REFSYSTEM;

CLASS COORDSYSTEM (ABSTRACT) EXTENDS REFSYSTEM =
  ATTRIBUTE
    Axis: LIST {1..3} OF AXIS;
END COORDSYSTEM;

CLASS SCALSYSTEM (ABSTRACT) EXTENDS REFSYSTEM =
  PARAMETER
    Unit: NUMERIC [ ANYUNIT ];
END SCALSYSTEM;

In Erweiterungen können weitere für die Art der Skalar- und Koordinatensysteme typische Attribute beigefügt werden und auch die Einheit durch eine Erweiterung ersetzt werden (Syntax für die Parameterdefinition vgl. Kapitel 3.10.2, “Parameter” und Kapitel 3.5.3, “Klassen und Strukturen”). Die in einem Wertebereich definierte Einheit muss dann mit ihr verträglich sein (vgl. Kapitel 3.9, “Einheiten”).

3.11. Laufzeitparameter

Nebst den eigentlichen Daten und den Metadaten können auch einzelne Datenelemente definiert werden, bei denen erwartet wird, dass sie von einem Bearbeitungs-, Auswerte- oder Darstellungssystem zur Laufzeit bereitgestellt werden. Sie heissen Laufzeitparameter.

※

Syntaxregel:

RunTimeParameterDef = 'PARAMETER'
                        { RunTimeParameter-Name ':' AttrTypeDef ';' }.

Gebietseinteilungen (Schlüsselwort AREA) sind für Laufzeitparameter nicht zugelassen.

Typische Laufzeitparameter sind zum Beispiel der Darstellungsmassstab und das aktuelle Datum.

3.12. Konsistenzbedingungen

Konsistenzbedingungen dienen der Definition von Einschränkungen, welchen die Objekte genügen müssen.

Konsistenzbedingungen können einen Namen haben, der innerhalb der Klasse bzw. des Wertebereichs, zu dem sie definiert werden, eindeutig sein muss.

Bei der Prüfung von Konsistenzbedingungen (insbesondere der Einhaltung der Schnittfreiheit inkl. Overlaps) sollen (auch wenn die Daten in einem System mit höherer Genauigkeit gespeichert sind) gemäss Wertebereichdefinition gerundete Attribut-Werte verwendet werden (vgl. Kapitel 2.8, “Umgang mit Rundung von numerischen Werten und Koordinaten”).

Konsistenzbedingungen, die sich auf ein einzelnes Objekt beziehen, werden durch einen logischen Ausdruck beschrieben, der sich auf die Attribute des Objektes bezieht (s. nächstes Kapitel). Solche Bedingungen dürfen keine Funktion verwenden, die auf einem Argument (typischerweise auf dem ersten) eine Menge von Objekten (OBJECTS OF) erwartet. Dabei können Konsistenzbedingungen definiert werden, die obligatorisch sind und somit für alle Objekte zwingend gelten (Schlüsselwort MANDATORY), und solche, die nur in der Regel gelten. Im letzteren Fall wird angegeben, welcher Prozentanteil der Instanzen der Klasse die Bedingung normalerweise erfüllen soll (Regel PlausibilityConstraint).

Mit der Existenzbedingung (Regel ExistenceConstraint) kann gefordert werden, dass der Wert eines Attributes jedes Objektes der Bedingungs-Klasse in einem bestimmten Attribut einer Instanz anderer Klassen vorkommt. Das bedingt, dass das Bedingungsattribut mit dem anderen Attribut kompatibel ist und hat folgende Wirkung:

Ist der Wertebereich des Bedingungsattributes gleich dem Wertebereich des anderen Attributes oder einer Erweiterung davon, muss der Bedingungswert im verlangten Attribut einer anderen Instanz vorkommen.
Ist der Wertebereich des Attributes eine Struktur, werden alle darin enthaltenen Attribute verglichen.
Ist der Wertebereich des anderen Attributes eine Koordinate und der Wertebereich des Bedingungsattributes eine Linie, Einzelfläche oder Gebietseinteilung mit dem gleichen oder einem erweiterten Koordinatenbereich, müssen alle Koordinaten der Stützpunkte der Linie, Einzelfläche oder Gebietseinteilung im verlangten Attribut einer anderen Instanz vorkommen.

Eindeutigkeitsforderungen werden mit dem Schlüsselwort UNIQUE eingeleitet (Regel UniquenessConstraint).

Konzeptionell bedeutet "global", dass alle in beliebigen Behältern existierenden Objekte dieser Bedingung genügen müssen. Mit der Angabe (BASKET) gilt die Eindeutigkeitsbedingung nicht mehr global, sondern pro Basket.

Bei Strukturen, Klassen und Assoziationen kann gefordert werden, dass eine bestimmte Kombination von Attributen von Unterstrukturen, die mit BAG OF oder LIST OF definiert sind, lokal (LOCAL), d.h. im Rahmen aller dem aktuellen Objekt oder Strukturelement zugeordneten Strukturelemente, eindeutig sein müssen.

Beispiel:

CLASS A =
  K: (A, B, C);
  ID: TEXT*10;
UNIQUE K, ID;
END A;

Ist an einer Eindeutigkeitsbedingung (UNIQUE) ein Attribut beteiligt, dessen Wert undefiniert ist, gilt die Eindeutigkeitsbedingung für das aktuelle Objekt als erfüllt. Strukturattribute sind als Attribut einer Eindeutigkeitsbedingung nicht zulässig.

Ist eine Konsistenzbedingung (MANDATORY CONSTRAINT) nicht berechenbar (weil z.B. ein Attribut beteiligt ist, dessen Wert undefiniert ist, oder der Divisor 0 beträgt) so gilt die Konsistenzbedingung für das aktuelle Objekt als erfüllt.

Mit Konsistenzbedingungen, die sich auf die Klasse beziehen (SET CONSTRAINT), können Bedingungen formuliert werden, die für die Gesamtmenge der Objekte der Klasse (bzw. der Teilmenge, welche die einschränkende WHERE-Bedingung erfüllt) gelten. Solche Bedingungen müssen mindestens eine Funktion verwenden, die auf einem Argument (typischerweise auf dem ersten) eine Menge von Objekten (OBJECTS OF) erwartet. Um die Gesamtmenge der Objekte der Klasse (bzw. der Teilmenge, welche die einschränkende WHERE-Bedingung erfüllt) diesem Argument zu übergeben, wird ALL (ohne Angabe der eigenen Klasse) angegeben. Da sich solche Konsistenzbedingungen nicht auf das einzelne Objekt beziehen, können nie die Werte von Attributen angesprochen werden. Als weitere Argumente und für Vergleiche kommen darum nur Konstanten, Laufzeitparameter, Klassentypen, und Attributtypen und weitere Funktionsaufrufe, die diese Einschränkung erfüllen, in Frage.

Beispiele:

CLASS B =
  Art: (a, b, c);
  Geometrie: SURFACE ...;
SET CONSTRAINT WHERE Art == #a :
  areAreas(ALL, UNDEFINED, >> Geometrie);
END B;

STRUCTURE F =
  Geometrie: SURFACE ...;
END F;

CLASS C =
  Flaechen: BAG OF F;
SET CONSTRAINT
  areAreas(ALL, >> Flaechen, >> F->Geometrie);
END;

Die Objekte der Klasse B, deren Art a ist, sollen wegen der Verwendung der Standardfunktion areAreas (vgl. Kapitel 3.14, “Funktionen”) ein Flächennetz bilden. Alle Flächen (gemäss Unterstruktur Flächen) der Objekte der Klasse C bilden eine Gebietseinteilung.

Weitergehende Konsistenzbedingungen müssen mittels Sichten (z.B. Sicht, die eine bestimmte Klasse mit sich selbst verbindet und damit beliebige Attributkombinationen mit allen anderen Objekten der Klasse vergleichbar machen) definiert werden. Solche Sichten müssen zwingend innerhalb des Datenmodells definiert werden.

Konsistenzbedingungen, die sich auf eine Vielzahl von Objekten erstrecken (insbesondere Eindeutigkeitsbedingungen), sind nicht immer vollständig prüfbar, weil die Prüfung nur mit den lokal verfügbaren Behältern durchgeführt werden kann. Konzeptionell gelten sie aber (ausser bei Metamodellen) dennoch global (vgl. Anhang G Eindeutigkeit von Benutzerschlüsseln).

※

Syntaxregeln:

ConstraintDef = ( MandatoryConstraint
                | PlausibilityConstraint
                | ExistenceConstraint
                | UniquenessConstraint
                | SetConstraint ).

MandatoryConstraint = 'MANDATORY' 'CONSTRAINT' [ Constraint-Name ':' ]
                         Logical-Expression ';'.

PlausibilityConstraint = 'CONSTRAINT' [ Constraint-Name ':' ]
                           ( '<=' | '>=' ) Percentage-Dec '%'
                             Logical-Expression ';'.

ExistenceConstraint = 'EXISTENCE' 'CONSTRAINT' [ Constraint-Name ':' ]
                         AttributePath 'REQUIRED' 'IN'
                           ViewableRef ':' AttributePath
                             { 'OR' ViewableRef ':' AttributePath } ';'.

UniquenessConstraint = 'UNIQUE' [ '(' 'BASKET' ')' ]
                         [ Constraint-Name ':' ]
                         [ 'WHERE' Logical-Expression ':' ]
                           ( GlobalUniqueness | LocalUniqueness ) ';'.

GlobalUniqueness = UniqueEl.

UniqueEl = ObjectOrAttributePath { ',' ObjectOrAttributePath }.

LocalUniqueness = '(' 'LOCAL' ')'
                    StructureAttribute-Name
                      { '->' StructureAttribute-Name } ':'
                               Attribute-Name { ',' Attribute-Name }.

SetConstraint = 'SET' 'CONSTRAINT' [ '(' 'BASKET' ')' ]
                  [ Constraint-Name ':' ]
                  [ 'WHERE' Logical-Expression ':' ]
                    Logical-Expression ';'.

Konsistenzbedingungen für eine bestimmte Klasse oder Assoziation können auch erst nachträglich, aber innerhalb desselben TOPIC (typischerweise nach der Definition einer Assoziation), definiert werden.

※

Syntaxregel:

ConstraintsDef = 'CONSTRAINTS' 'OF' ViewableRef '='
                   { ConstraintDef }
                 'END' ';'.

3.13. Ausdrücke

Ausdrücke (Expression) werden z.B. als Argument von Funktionen oder in Konsistenz- und Selektionsbedingungen verwendet. Bei einem logischen Ausdruck (Logical-Expression) muss der Ergebnistyp Boolean sein. Ausdrücke beziehen sich auf ein Kontextobjekt, d.h. das Objekt, für das man die Bedingung formuliert. Ausgehend von diesem kann ein Attribut, ein Strukturelement, eine Funktion, etc. angesprochen werden. Solche Gegenstände sowie Vergleichsgrössen wie Konstanten und Laufzeitparameter fliessen als Faktoren in Prädikate ein. Prädikate können mittels Operatoren zu einem Ausdruck verknüpft werden.

※

Syntaxregeln:

Expression = Term.

Term = Term0 [ '=>' Term0 ].

Term0 = Term1 { ( 'OR' | '+' | '-' ) Term1 }.

Term1 = Term2 { ( 'AND' | '*' | '/' ) Term2 }.

Term2 = Predicate [ Relation Predicate ].

Predicate = ( Factor
            | [ 'NOT' ] '(' Logical-Expression ')'
            | 'DEFINED' '(' Factor ')' ).

Relation = ( '==' | '!=' | '<>' | '<=' | '>=' | '<' | '>' ).

Bemerkungen zur Bedeutung der Syntaxregeln:

Entsprechend der Syntaxregeln für die Terme bindet der Vergleich (Relation) am stärksten, dann AND bzw. * und /, dann OR bzw. + und -, dann die Implikation (=>). AND und OR können nur mit boolschen Prädikaten, +, -, * und / können nur mit numerischen Prädikaten verwendet werden.
Mit NOT und dem darauf in Klammer folgenden logischen Ausdruck wird die Verneinung dieses Ausdrucks verlangt.
Vergleich von Faktoren. Je nach Typ des Faktors sind einzelne Vergleiche ausgeschlossen:
- Bei Zeichenkettentypen sind nur Gleichheit (==) und Ungleichheit (!=, <>) zulässig. Weitergehende Vergleiche sind mittels Funktionen zu realisieren. Dabei muss insbesondere genau definiert werden, wie regionale, sprachliche Besonderheiten wie Umlaute und Akzente behandelt werden.
- Bei numerischen Datentypen und strukturierten Wertebereichen sind die Vergleiche im üblichen Sinn definiert. Grösser- und Kleiner-Vergleiche sind bei zirkulären Datentypen nicht zweckmässig.
- Koordinaten können als Ganzes nur auf Gleichheit oder Ungleichheit geprüft werden. Die anderen Vergleiche stehen nur für die einzelnen Komponenten zur Verfügung (s. untenstehenden Kommentar zu Syntaxregel Factor).
- Bei Aufzählungen sind Grösser- und Kleiner-Vergleiche nur zulässig, wenn die Aufzählung als geordnet definiert wurde. Mit Gleichheit ist exakte Gleichheit gemeint. Sind auch alle Unterelemente eines Knotens gemeint, ist die Funktion isEnumSubVal zu verwenden.
- Bei Linien kann nur geprüft werden, ob sie undefiniert (== UNDEFINED) sind.
- Ein Faktor kann auch ein Objekt bezeichnen. Dann kann auf Definiertheit und Gleichheit bzw. Ungleichheit geprüft werden.
Besteht ein Faktor nicht nur aus dem unmittelbaren Gegenstand sondern auch aus dem Pfad, der zu diesem führt, gilt der Gegenstand immer als undefiniert, wenn irgendein Attribut des Pfades nicht definiert ist. Die eingebaute Funktion DEFINED (a.b) ist damit gleichwertig mit (a.b != UNDEFINED).
Ein Ausdruck wird von links nach rechts nur soweit ausgewertet bis dessen Resultatwert klar ist. Mit OR verbundene Folgeterme werden also nur ausgewertet, wenn der bisherige Wert falsch ist. Mit AND verbundene Folgeterme werden dementsprechend nur ausgewertet, wenn der bisherige Wert wahr ist.
Numerische Ausdrücke (inkl. Koordinaten) sollen immer mit voller numerischer Genauigkeit (gemäss Norm IEEE-754) berechnet werden. Erst die resultierenden Werte sollen allenfalls gerundet werden (vgl. Kapitel 2.8, “Umgang mit Rundung von numerischen Werten und Koordinaten”).

Die Implikation (=>) ist nur dann false, wenn der erste Term true und der zweite Term false ist. a => b ist identisch mit folgender Formulierung: NOT(a) OR b. Das wird typischerweise verwendet, um bedingte Einschränkungen zu formulieren. Zum Beispiel: Die Geometrie ist nur bei einem bestimmten Status obligatorisch.

Beispiel:

CLASS A =
  Status: (gueltig, projektiert);
  Geometrie: SURFACE ...;
MANDATORY CONSTRAINT Status == #gueltig => DEFINED(Geometrie);
END A;

Faktoren können gemäss den folgenden Syntaxregeln gebildet werden:

※

Syntaxregeln:

Factor = ( ObjectOrAttributePath
         | ( Inspection | 'INSPECTION' Inspection-ViewableRef )
             [ 'OF' ObjectOrAttributePath ]
         | FunctionCall
         | 'PARAMETER' [ Model-Name '.' ] RunTimeParameter-Name
         | Constant ).

ObjectOrAttributePath = PathEl { '->' PathEl }.

AttributePath = ObjectOrAttributePath.

PathEl = ( 'THIS'
         | 'THISAREA' | 'THATAREA'
         | 'PARENT'
         | ReferenceAttribute-Name
         | AssociationPath
         | Role-Name [ '[' Association-Name ']' ]
         | Base-Name
         | AttributeRef ).

AssociationPath = [ '\' ] AssociationAccess-Name.

AttributeRef = ( Attribute-Name ( [ '[' ( 'FIRST'
                                        | 'LAST'
                                        | AxisListIndex-PosNumber ) ']' ] )
               | 'AGGREGATES' ).

FunctionCall = [ Model-Name '.' [ Topic-Name '.' ] ] Function-Name
                   '(' [ Argument { ',' Argument } ] ')'.

Argument = ( Expression
           | 'ALL' [ '(' RestrictedClassOrAssRef | ViewableRef ')' ] ).

Faktoren können sich auf Objekte und ihre Attribute beziehen. Dabei können schrittweise ganze Objektpfade gebildet werden. Jedes Konstrukt eröffnet den Weg vom jeweils aktuellen Objekt zum nächsten. Das erste aktuelle Objekt ergibt sich aus dem Kontext, z.B. ein Objekt der Klasse, für die eine Konsistenzbedingung definiert wird.

THIS: Bezeichnet das so genannte Kontextobjekt, d.h. das aktuelle Objekt einer Klasse, einer Sicht oder einer Grafikdefinition, in dem ein Objektpfad verlangt wird. THIS ist z.B. beim Aufruf einer Funktion als Argument anzugeben, die ANYCLASS oder ANYSTRUCTURE als Parameter hat.
THISAREA und THATAREA: Bezeichnen die beiden Gebietsobjekte, auf dessen gemeinsamen Rand sich das aktuelle Linienzugsobjekt befindet. Der Einsatz von THISAREA und THATAREA ist nur möglich im Rahmen der Inspektion einer Gebietseinteilung (vgl. Kapitel 3.15, “Sichten”).
PARENT: Bezeichnet das Ober-Strukturelement oder Ober-Objekt des aktuellen Strukturelementes oder Objektes. Die Sicht muss dazu eine gewöhnliche Inspektion (keine Gebietsinspektion) sein (vgl. Kapitel 3.15, “Sichten”).
Referenzattribut-Angabe: Bezeichnet das Objekt, das vom aktuellen Objekt bzw. von der aktuellen Struktur aus über das gegebene Referenzattribut zugeordnet ist.
Rollenangabe: Die Rollenangabe ist gültig, wenn nur eine einzige entsprechende Rolle existiert. Die Rollenangabe kann dabei sowohl eine Ausgangsrolle (gemäss der das aktuelle Objekt mit der Beziehungsinstanz verbunden ist) wie eine Zielrolle (gemäss der die Beziehungsinstanz mit dem Bezugsobjekt verbunden ist) ansprechen. Ist die Rollenangabe durch den Beziehungsnamen ergänzt, kann sie nur Ausgangsrollen ansprechen. Je nach Stellung des Pfadelementes im Pfad werden die Rollen unterschiedlich gesucht. Ist die Rollenangabe das erste Pfadelement eines Pfades, wird die Rolle in allen Beziehungszugängen der Klasse gesucht, in deren Kontext der Pfad Anwendung findet. Ist die Rollenangabe ein Folgelement des Pfades, wird die Rolle in allen Assoziationen gesucht, die im Thema verfügbar sind, in dem die Klasse definiert ist, in deren Kontext der Pfad Anwendung findet. Dabei kommen nur diejenigen Assoziationen in Frage, die über Rollen mit der Klasse des Vorgängerobjektes des Pfades in Bezug stehen.
Basis-Sicht-Angabe: Mit dem (lokalen) Namen der Basis-Sicht wird in der aktuellen Sicht bzw. in der aktuellen abgeleiteten Beziehung das entsprechende (virtuelle) Objekt der Basis-Sicht bezeichnet.

Beim Bezug auf ein Attribut, meint man den Wert des Attributes des Kontextobjekts oder des durch den Pfad bezeichneten Objekts. Zusätzlich werden Pfade, die mit einem Attribut enden, als Attributpfade bezeichnet und auch unabhängig von Faktoren in verschiedenen Syntaxregeln verwendet.

Im Normalfall genügt die Angabe des Attributnamens.
Handelt es sich um ein Koordinatenattribut bezeichnet man durch Angabe der Nummer der Achse die entsprechende Komponente der Koordinate. Die erste Komponente hat den Index 1.
Das implizite Attribut AGGREGATES ist in Aggregationssichten (vgl. Kapitel 3.15, “Sichten”) definiert und bezeichnet den Satz (BAG OF) der aggregierten Basisobjekte.

Bei geordneten Unterstrukturen (LIST OF) können einzelne Elemente angesprochen werden. Zulässige Indizes sind:

FIRST: das erste Element.
LAST: das letzte Element.
Index-Nummer: Der angegebene Index muss kleiner oder gleich der in der Kardinalität festgelegten maximalen Anzahl sein. Das erste Element hat den Index 1. Ist er kleiner oder gleich der in der Kardinalität festgelegten minimalen Anzahl, existiert immer ein entsprechendes Element; ist er grösser ist die Existenz des Elementes nicht gewährleistet. Der Faktor kann als Folge undefiniert werden.

Ein Faktor kann auch eine Inspection sein (vgl. Kapitel 3.15, “Sichten”). Ist ihr ein Objektpfad vorangestellt, muss die damit gegebene Objektklasse mit derjenigen der Inspection übereinstimmen oder eine Erweiterung von dieser sein. Zur Menge der durch die Inspection gelieferten Strukturelemente gehören dann nur diejenigen, die zum Objekt gehören, das mit dem Objektpfad definiert ist.

Faktoren können auch Funktionsaufrufe sein. Als ihre Argumente kommen in Frage:

Ausdrücke: Der Typ des Ergebnisses des Ausdrucks muss mit dem Argumenttyp kompatibel sein.
Wird mit dem Ausdruck eine Rollenangabe gemacht, bezeichnet der Ausdruck die Menge der über die Rolle verbundenen Zielobjekte. Beim formalen Parameter muss OBJECT OF oder OBJECTS OF (nur wenn auf Grund der Modellbeschreibung klar ist, dass nur ein Zielobjekt möglich ist) verlangt sein (vgl. Kapitel 3.14, “Funktionen”).
Alle Objekte (ALL) der Klasse in deren Kontext der Funktionsaufruf erfolgt oder alle Objekte der angegebenen Klasse. Beim formalen Parameter muss OBJECTS OF verlangt sein (vgl. Kapitel 3.14, “Funktionen”). Damit sind immer alle Objekte gemeint, die dieser Klasse oder ihren Erweiterungen entsprechen.

Als Vergleichswerte kommen Funktionsaufrufe, Laufzeitparameter (vgl. Kapitel 3.16, “Darstellungsbeschreibungen”) und Konstanten in Frage.

3.14. Funktionen

Eine Funktion wird mittels ihrem Namen, den formalen Parametern sowie einer kurzen Funktionsbeschreibung als Erläuterung definiert. Die Namen der Parameter haben nur dokumentarischen Wert.

Als formale Parameter und Funktionsresultat kommen in Frage:

Die für Attribute zulässigen Typen, insbesondere auch Strukturen. Als Argumente (d.h. aktuelle Parameter) kommen entsprechende Ausdrücke (Regel Expression) in Frage.
Wird dabei eine Struktur angegeben, kommen als Argumente primär Strukturelemente in Frage. Es können aber auch Objektpfade angegeben werden, die zu Objekten führen, die eine Erweiterung der Struktur ist. Insbesondere können bei ANYSTRUCTURE beliebige Objektpfade angegeben werden.
Wird OBJECT OF angegeben, kommen als Argumente die mittels eines Objektpfads erreichbaren Objekte in Frage, die der Definition entsprechen. Insbesondere können bei OBJECT OF ANYCLASS beliebige Objektpfade angegeben werden. Ähnlich wie bei den Bezügen zu anderen Objekten (vgl. Kapitel 3.6.3, “Referenzattribute”) können die zulässige Basisklasse und allfällige Einschränkungen definiert und in Erweiterungen spezialisiert werden.
Wird OBJECTS OF angegeben, kommen als Argumente Mengen von Objekten einer Klasse in Frage. Alle Objekte der Menge müssen die beim formalen Argument gemachten Anforderungen bereits auf Grund der Modellbeschreibung erfüllen (die beim formalen Argument gemachte Anforderung wirkt also nicht als nachträglicher Filter).
Wird ENUMVAL angegeben, kommen als Argumente Attribute und Konstanten in Frage, die ein Blatt einer beliebigen Aufzählung (vgl. Kapitel 3.8.2, “Aufzählungen”) bezeichnen.
Wird ENUMTREEVAL angegeben, kommen als Argumente Attribute und Konstante in Frage, die einen Knoten oder ein Blatt einer beliebigen Aufzählung bezeichnen.

※

Syntaxregeln:

FunctionDef = 'FUNCTION' Function-Name
                '(' [ Argument-Name ':' ArgumentType
                { ';' Argument-Name ':' ArgumentType } ] ')'
                ':' ArgumentType [ Explanation ] ';'.

ArgumentType = ( AttrTypeDef
               | ( 'OBJECT' | 'OBJECTS' )
                     'OF' ( RestrictedClassOrAssRef | ViewRef )
               | 'ENUMVAL'
               | 'ENUMTREEVAL' ).

Es sind folgende Standardfunktionen definiert:

FUNCTION myClass (Object: ANYSTRUCTURE): STRUCTURE;

liefert die Klasse des Objektes.

FUNCTION isSubClass (potSubClass: STRUCTURE; potSuperClass: STRUCTURE): BOOLEAN;

liefert true, wenn die Klasse des ersten Argumentes der Klasse oder einer Unterklasse des zweiten Argumentes entspricht.

FUNCTION isOfClass (Object: ANYSTRUCTURE; Class: STRUCTURE): BOOLEAN;

liefert true, wenn das Objekt des ersten Argumentes zur Klasse oder zu einer Unterklasse des zweiten Argumentes gehört.

FUNCTION elementCount (bag: BAG OF ANYSTRUCTURE): NUMERIC;

liefert die Anzahl Elemente, die der Bag (oder die Liste) enthält.

FUNCTION objectCount (Objects: OBJECTS OF ANYCLASS): NUMERIC;

liefert die Anzahl Objekte, welche die gegebene Objektmenge enthält.

FUNCTION len (TextVal: TEXT): NUMERIC;
FUNCTION lenM (TextVal: MTEXT): NUMERIC;

liefert die Länge des Textes als Anzahl Zeichen.

FUNCTION trim (TextVal: TEXT): TEXT;
FUNCTION trimM (TextVal: MTEXT): MTEXT;

liefert den um Leerzeichen am Anfang und Ende befreiten Text.

FUNCTION isEnumSubVal (SubVal: ENUMTREEVAL; NodeVal: ENUMTREEVAL): BOOLEAN;

liefert true, wenn SubVal ein Unterelement, also ein Unterknoten oder ein Blatt, des Knotens NodeVal ist.

FUNCTION inEnumRange (Enum: ENUMVAL;
                      MinVal: ENUMTREEVAL;
                      MaxVal: ENUMTREEVAL): BOOLEAN;

liefert true, wenn die Aufzählung zu der Enum gehört, geordnet ist und im Bereich von MinVal und MaxVal liegt. Unterelemente von MinVal oder MaxVal gelten als dazu gehörig.

FUNCTION convertUnit (from: NUMERIC): NUMERIC;

rechnet den numerischen Wert des Parameters "from" in den numerischen Rückgabewert um und berücksichtigt dabei die Einheiten, die mit dem Parameter und mit der Verwendung des Resultatwertes (typischerweise mit dem Attribut, dem das Resultat zugewiesen wird) verbunden sind. Diese Funktion darf nur angewendet werden, wenn die Argumente von "from" und vom Rückgabeparameter verträglich sind, d.h. wenn ihre Einheiten von einer gemeinsamen Einheit abgeleitet werden.

FUNCTION length (geom: POLYLINE): NUMERIC;
FUNCTION multilength (geom: MULTIPOLYLINE): NUMERIC;

berechnet die Länge der Linie gemäss Parameter "geom".

FUNCTION surface (geom: SURFACE): NUMERIC;
FUNCTION multisurface (geom: MULTISURFACE): NUMERIC;

berechnet den Inhalt der Fläche gemäss Parameter "geom" (SURFACE oder AREA).

FUNCTION areAreas (Objects: OBJECTS OF ANYCLASS;
                   SurfaceBag: ATTRIBUTE OF @ Objects
                                         RESTRICTION (BAG OF ANYSTRUCTURE);
                   SurfaceAttr: ATTRIBUTE OF @ SurfaceBag
                                          RESTRICTION (SURFACE)): BOOLEAN;

prüft, ob die Flächen gemäss Objektmenge (erster Parameter) und Attribut (dritter Parameter) eine Gebietseinteilung bilden. Ist das Flächenattribut direkt Teil der Objektklasse, soll für SurfaceBag UNDEFINED angegeben werden, ansonsten das Strukturattribut, welche das Flächenattribut enthält.

FUNCTION areAreas2 (Objects: OBJECTS OF ANYCLASS;
                    SurfaceBag: TEXT;
                    SurfaceAttr: TEXT): BOOLEAN;

prüft, ob die Flächen gemäss Objektmenge (erster Parameter) und Attribut (dritter Parameter) eine Gebietseinteilung bilden. Ist das Flächenattribut direkt Teil der Objektklasse, soll für Surface-Bag UNDEFINED angegeben werden, ansonsten der Pfad zum Strukturattribut mit der Struktur, welche das Flächenattribut enthält. Der Attribut-Pfad soll dabei als TEXT-Konstante, aber in INTERLIS-Syntax, angegeben werden.

Beispiel:

SET CONSTRAINT areAreas2 (ALL,"Geometry->Surfaces","Surface");

FUNCTION areAreasWithoutGaps (Objects: OBJECTS OF ANYCLASS;
                              SurfaceBag: ATTRIBUTE OF @ Objects
                                         RESTRICTION (BAG OF ANYSTRUCTURE);
                              SurfaceAttr: ATTRIBUTE OF @ SurfaceBag
                                          RESTRICTION (SURFACE)): BOOLEAN;

FUNCTION areAreasWithoutGaps2 (Objects: OBJECTS OF ANYCLASS;
                               SurfaceBag: TEXT;
                               SurfaceAttr: TEXT): BOOLEAN;

prüft, ob die Gebietseinteilung lückenlos ist, d.h. ob jeder Fläche der Gebietseinteilung (ausser der Restfläche) ein Objekt zugeordnet ist. Parameter wie bei areAreas bzw. areAreas2.

3.15. Sichten

Sichten (Views) sind Klassen und Strukturen, deren Objekte nicht originär sondern virtuell sind, da sie aus Objekten anderer Sichten oder Klassen bzw. Strukturen abgeleitet werden. Sichten werden unter anderem dazu verwendet, die Grundlagen für Grafiken und spezielle Konsistenzbedingungen zu formulieren. Eine weitere Anwendung ist die Weitergabe der Daten an Empfängersysteme in einer abgeleiteten, in der Regel vereinfachten Form.

Sichten werden nur transferiert, wenn sie in einem VIEW TOPIC definiert sind. In diesem Fall erfolgt ihre Übertragung wie der vollständige Transfer (Schlüsselwort FULL) von normalen Klassen, so dass sich ein Datenempfänger (vgl. Kapitel 4, Sequentieller Transfer) nicht darum zu kümmern braucht, wie die (virtuellen) Objekte erzeugt wurden. Sichten können auch explizit vom Transfer ausgeschlossen werden (TRANSIENT), wenn sie nur lokale Bedeutung haben, d.h. wenn sie nur als Basis für andere Sichten dienen. Die inkrementelle Nachlieferung von Sichten ist ausgeschlossen, da Sichtobjekten keine Objektidentifikation zugeordnet wird.

Sichten können abstrakt (ABSTRACT) oder konkret sein. Konkrete Sichten können auch auf abstrakten Grundlagen beruhen. Dabei können aber nur diejenigen Grundlagenattribute angesprochen werden, die konkret sind. Ist dies nicht der Fall, muss die Sicht selbst als abstrakt erklärt werden.

Sichten können auch erweitert werden (EXTENDED oder EXTENDS). Dabei ist es allerdings nicht möglich das Bildungsgesetz zu verändern. Die Erweiterung dient dazu, Erweiterungen der Sichten, Klassen und Strukturen, auf der die Sicht aufbaut, so zur Kenntnis zu nehmen, dass weitere Selektionen, Attribute und Konsistenzbedingungen formuliert werden können.

※

Syntaxregeln:

(1)

ViewDef = 'VIEW' View-Name
            Properties<ABSTRACT,EXTENDED,FINAL,TRANSIENT>
            [ FormationDef | 'EXTENDS' ViewRef ]
                { BaseExtensionDef }
                { Selection }
            '='
            [ ViewAttributes ]
            { ConstraintDef }
          'END' View-Name ';'.

ViewRef = [ Model-Name '.' [ Topic-Name '.' ] ] View-Name.

1	Im PDF-Dokument des Referenzhandbuchs (Version 2.1.0) ist an dieser Stelle die Regel ViewAttributes abgebildet. Diese befindet sich jedoch bereits weiter hinten im Dokument und wird deshalb nicht erneut aufgeführt. Siehe dazu auch dieses Issue.

In den einfachen Fällen, wo sich ein Attribut aus der Basis ergibt, genügt es den Attributnamen und nötigen Ausdruck (mit Verwendung von Basisattributen) anzugeben.

Obiger Satz erscheint in leicht abgeänderter Form doppelt im Referenzhandbuch (Version 2.1.0). Die andere Stelle befindet sich hier.

Mit dem Bildungsgesetz (FormationDef) einer Sicht wird definiert, wie und aus welchen Grundlagen die virtuellen Objekte der Sicht gebildet werden.

Die Sicht-Projektion (Schlüsselwort PROJECTION OF) ist die einfachste Sicht. Mit ihr wird die Basis-Klasse (Klasse, Struktur oder Sicht) in veränderten Form (z.B. Attribute nur teilweise und in veränderter Reihenfolge) gesehen.

Mit der Verbindung (Schlüsselwort JOIN OF) wird das kartesische Produkt (oder Kreuzprodukt) der Basis-Klassen (Klasse oder Sicht) gebildet, d.h. es gibt so viele Objekte der Verbindungs-Klasse wie es Kombinationen von Objekten der verschiedenen Basis-Klassen gibt. Es können auch so genannte «Outer-Joins», also Verbindungen von Objekten der ersten Basisklasse mit (an sich inexistenten) Leerobjekten der weiteren Basisklassen definiert werden (Angabe “(OR NULL)”). Solche Leerobjekte werden beigefügt, wenn zu einer bestimmten Kombination der vorangegangenen Objekte kein Objekt der gewünschten weiteren Klasse gefunden wird. Alle Attribute des Leerobjektes sind undefiniert. Die entsprechenden Sicht-Attribute dürfen darum nicht obligatorisch sein.

Die Vereinigung (Schlüsselwort UNION OF) ermöglicht die Verschmelzung verschiedener Basis-Klassen zu einer einzigen Klasse. Einem Attribut der Vereinigungs-Sicht werden typischerweise die Attribute der verschiedenen Basis-Klassen zugewiesen. Der Attributtyp der Basis-Klasse muss mit demjenigen der Vereinigungs-Sicht verträglich sein (gleicher Typ oder Erweiterung davon).

Mit der Zusammenfassung (Schlüsselwort AGGREGATION OF) werden alle oder diejenigen Instanzen einer Basismenge zu einer Instanz zusammengefasst, bei denen die verlangte Attributkombination identisch ist. Innerhalb der Aggregationssicht steht mittels dem impliziten Attribut AGGREGATES (vgl. Kapitel 3.13, “Ausdrücke”) der zugehörige Satz von Originalobjekten als BAG zur Verfügung. Dieses implizite Attribut gehört nicht zu den eigentlichen Attributen der Sicht und wird darum auch dann nicht transferiert, wenn ein Transfer verlangt ist. Es kann z.B. einem entsprechenden Attribut der Aggregationssicht zugewiesen oder als Argument einer Funktion übergeben werden.

Mit der Aufschlüsselung (Schlüsselwort INSPECTION OF) erhält man die Menge aller Strukturelemente (mit BAG OF oder LIST OF oder gemäss Linie, Einzelfläche oder Gebietseinteilung definierte), die zu einem (direkten oder indirekten) Unterstrukturattribut einer Objekt-Klasse gehören.

Die normale Inspection auf ein Gebietseinteilungsattribut bzw. die Inspection eines Flächenattributs liefert die Ränder aller Gebiete bzw. Flächen dieser Klasse (Struktur SurfaceBoundary). Die Linienzüge jedes Randes (Struktur SurfaceEdge) werden dabei so gebildet, dass ihre Anzahl minimal ist. Aufeinanderfolgende Linienzüge werden also zu einem Linienzug zusammengefasst. Wird eine weitere Inspection auf das Attribut Lines gemacht, erhält man ebenfalls alle Linienzüge (Struktur SurfaceEdge). Auf diese Art kommen sie aber im Falle der Gebietseinteilung doppelt vor (einmal für jedes beteiligte Gebietsobjekt).

Mit der Inspection einer Gebietseinteilung (Schlüsselwort AREA INSPECTION OF) erhält man die Linienzüge der Ränder der zur Gebietseinteilung gehörenden Gebiete genau einmal (als Struktur SurfaceEdge). Die beiden Gebiete, die von einem gemeinsamen Linienzug berandet werden, können mit THISAREA bzw. THATAREA angesprochen werden (vgl. Kapitel 3.13, “Ausdrücke”). Die Linienzüge (Struktur SurfaceEdge) werden wie bei der normalen Inspection möglichst zusammengefasst geliefert.

STRUCTURE SurfaceEdge =
  Geometry: DIRECTED POLYLINE;
END SurfaceEdge;

STRUCTURE SurfaceBoundary =
  Lines: LIST OF SurfaceEdge;
END SurfaceBoundary;

Die Inspection eines Linienattributes (POLYLINE) liefert in folgender Struktur alle Kurvenstücke (LineSegments), aus denen die Linienzugsobjekte dieser Klasse zusammengesetzt sind:

STRUCTURE LineGeometry =
  Segments: LIST OF LineSegment;
MANDATORY CONSTRAINT isOfClass (Segments[FIRST],INTERLIS.StartSegment);
END LineGeometry;

Dies heisst, dass das erste Kurvenstück ein so genanntes StartSegment der Länge 0 darstellt und alle übrigen, als so genannte LineSegments, entweder Strecken, Kreisbogen oder Kurvenstücke eines anderen Typs sind, gemäss der in der Struktur festgelegten Definition.

Mit INTERLIS wird nur eine konzeptionelle Beschreibung der Sicht gemacht. Es wird ausdrücklich nichts unternommen, um eine effiziente Realisierung der Sichten zu unterstützen. Sichten generieren gehört deshalb auch zu einer speziellen Erfüllungsstufe.

※

Syntaxregeln:

FormationDef = ( Projection
               | Join
               | Union
               | Aggregation
               | Inspection ) ';'.

Projection = 'PROJECTION' 'OF' RenamedViewableRef.

Join = 'JOIN' 'OF' RenamedViewableRef
         (* ',' RenamedViewableRef
              [ '(' 'OR' 'NULL' ')' ] *).

Union = 'UNION' 'OF' RenamedViewableRef
          (* ',' RenamedViewableRef *).

Aggregation = 'AGGREGATION' 'OF' RenamedViewableRef
                ( 'ALL' | 'EQUAL' '(' UniqueEl ')' ).

Inspection = [ 'AREA' ] 'INSPECTION' 'OF' RenamedViewableRef
                 '->' StructureOrLineAttribute-Name
                      { '->' StructureOrLineAttribute-Name }.

Alle in einer Sicht verwendeten Basissichten erhalten innerhalb der verwendenden Sicht einen Namen, unter dem sie angesprochen werden können. Dieser Name entspricht dem Namen der Basissicht, sofern keine Umbenennung mittels eines expliziten (lokalen) Base-Namens definiert wird. Eine solche Umbenennung ist insbesondere nötig, wenn Verbindungen definiert werden, bei denen mehrmals die gleiche Basisklasse angesprochen wird.

※

Syntaxregeln:

RenamedViewableRef = [ Base-Name '~' ] ViewableRef.

ViewableRef = [ Model-Name '.' [ Topic-Name '.' ] ]
              ( Structure-Name
              | Class-Name
              | Association-Name
              | View-Name ).

Will man in einer Sicht bzw. einer Sichterweiterung Erweiterungen von Basisklassen berücksichtigen und damit zusätzliche Attribute, Selektionen oder Konsistenzbedingungen formulieren, muss eine entsprechende Erweiterungsdefinition (BaseExtensionDef) aufgeführt werden. Sie geht von einer bereits definierten Basissicht aus und beschreibt die Erweiterungen (müssen Erweiterungen der bisherigen Basissicht sein) selbst wieder als Basissichten. Wird eine solche Sichterweiterung innerhalb von Ausdrücken verwendet, liefert sie den Wert "UNDEFINED", wenn das zum virtuellen Objekt gehörige Basisobjekt nicht zu dieser Sichterweiterung passt.

※

Syntaxregel:

BaseExtensionDef = 'BASE' Base-Name 'EXTENDED' 'BY'
                     RenamedViewableRef { ',' RenamedViewableRef }.

Die durch das Bildungsgesetz definierte Menge der Sichtobjekte kann mittels Bedingungen (Schlüsselwort WHERE) zusätzlich eingeschränkt werden.

※

Syntaxregel:

Selection = 'WHERE' Logical-Expression ';'.

Was die Attribute (und damit die Empfängersicht) und die Konsistenzbedingungen betrifft, sind Sichten grundsätzlich gleich aufgebaut, wie Klassen und Strukturen. Im Sinne einer Schreiberleichterung wird zusätzlich die Möglichkeit angeboten, alle Attribute und Rollen einer Sichtbasis in der gleichen Reihenfolge zu übernehmen (ALL OF). Dies ist bei Vereinigungen und bei AREA-Inspektionen unsinnig und darum auch unzulässig.

※

Syntaxregel:

ViewAttributes = [ 'ATTRIBUTE' ]
                     { 'ALL' 'OF' Base-Name ';'
                     | AttributeDef
                     | Attribute-Name
                         Properties <ABSTRACT,EXTENDED,FINAL,TRANSIENT>
                           ':=' Expression ';' }.

In den einfachen Fällen, wo ein Attribut einer Basissicht übernommen wird, genügt es den Attributnamen und die Zuordnung des Basisattributes anzugeben. Solche Definitionen sind immer final, können also nicht mehr erweitert werden.

Obiger Satz erscheint in leicht abgeänderter Form doppelt im Referenzhandbuch (Version 2.1.0). Die andere Stelle befindet sich hier.

Bei Vereinigungen muss für jedes Attribut vollständig angegeben werden, aus welchen Attributen der Basis-Klassen es abgeleitet wird. Ein Attribut muss sich aber nicht auf alle Basis-Klassen beziehen, sofern der Attributtyp undefinierte Werte zulässt. Für die fehlenden Basis-Objekte gilt es als undefiniert.

Das folgende Beispiel zeigt, wie eine Sicht beschrieben werden kann, die ermöglicht, mit Hilfe des Konstrukts DERIVED FROM eine eigentliche Beziehung zu definieren (vgl. Kapitel 3.7, “Eigentliche Beziehungen”).

DOMAIN
  CHSurface = ... ;

FUNCTION Intersect (Surface1: CHSurface;
                    Surface2: CHSurface): BOOLEAN;

CLASS A =
  a1: CHSurface;
END A;

CLASS B =
  b1: CHSurface;
END B;

VIEW ABIntersection
  JOIN OF A,B;
  WHERE Intersect (A.a1,B.b1);
  =
END ABIntersection;

ASSOCIATION IntersectedAB
  DERIVED FROM ABIntersection =
  ARole –- A := ABIntersection -> A;
  BRole –- B := ABIntersection -> B;
END IntersectedAB;

3.16. Darstellungsbeschreibungen

Eine Darstellungsbeschreibung besteht aus Grafikdefinitionen, die immer auf einer Sicht oder einer Klasse basieren (Schlüsselwort BASED ON). Mit einer Grafikdefinition wird konzeptionell versucht, jedem Objekt dieser Sicht oder Klasse – sofern es nicht mit einer Selektion (Schlüsselwort WHERE), die sich auf die Sicht oder Klasse bezieht, noch ausgefiltert wurde – durch eine oder mehrere Zeichnungsregeln (Regel DrawingRule) je eine Grafiksignatur zuzuordnen (Punktsymbol, Linie, Flächenfüllung, Textanschrift) und damit ein oder mehrere Grafikobjekte zu erzeugen, welche die entsprechende Darstellung auslösen (siehe Abbildung 5). Dazu muss jede Zeichnungsregel eine Grafiksignatur (mit Metaobjekt-Namen) auswählen und Argumente festlegen für die dazugehörigen Parameter.

In runden Klammern (Regel Properties) können die Vererbungseigenschaften definiert werden. Ist eine Grafikdefinition abstrakt, entstehen aus ihr keine Grafikobjekte. Die Erweiterung einer Grafikdefinition muss auf der gleichen Klasse basieren wie die Basisgrafikdefinition (BASED ON fehlt) oder auf einer ihrer Erweiterungen.

Die Zeichnungsregel wird mit einem Namen identifiziert, der innerhalb der Darstellungsbeschreibung eindeutig ist, damit sie in Erweiterungen aufgegriffen und verfeinert werden kann (Anmerkung: verfeinert im Sinne der Spezialisierung aber auch zusätzlicher Parameterwerte). Existieren zu einer Zeichnungsregel Erweiterungen (in erweiternden Darstellungsbeschreibungen), erzeugen diese keine neuen Grafikobjekte, sondern beeinflussen nur die Signaturparameter des durch die Basisdefinition vorgegebenen Grafikobjektes. Es ist zulässig zu einer Grafikdefinition mehrere Erweiterungen zu definieren. Sie werden alle (in der Reihenfolge ihrer Definition) ausgewertet. Dies kann insbesondere genutzt werden, um für verschiedene Aspekte (z.B. die verschiedenen Zeichnungsregeln) verschiedene Erweiterungsstapel vorzusehen. Anschliessend werden die verschiedenen Signaturparameter bestimmt. Die Definition kann dabei in mehreren Schritten erfolgen. Für jeden Parameter gilt derjenige Wert, der als letztes definiert wurde. Dabei wird zuerst die primäre Definition ausgewertet, dann allfällige Erweiterungen. Parameter-Zuweisungen können zudem noch an eine Bedingung (Regel CondSignParamAssignment) geknüpft werden, d.h. die Zuweisung erfolgt nur, wenn die Bedingung erfüllt ist. Wird die Selektionsbedingung nicht erfüllt, fallen auch allfällige Untererweiterungen ausser Betracht. Innerhalb von Zuweisungsregeln (Syntaxregel CondSignParamAssignment) gilt für Attribut- und Rollennamen der Namensraum der Basisklasse oder -Sicht und für Metaobjekt-, Funktions- und Laufzeitparameternamen der Namensraum der Grafikdefinition.

Sobald Zeichnungsregeln konkret sind, muss definiert sein, zu welcher Klasse die zuzuordnenden Grafiksignaturen gehören. In Erweiterungen von Zeichnungsregeln kann diese Klasse von Grafiksignaturen durch eine Klasse ersetzt werden, welche eine Erweiterung der bisherigen ist. "Verantwortliche" Klasse von Grafiksignaturen ist zunächst diejenige, zu der die zugeordnete Grafiksignatur-Objekt (ein Metaobjekt) gehört. Den in der "verantwortlichen" Klasse eingeführten Parameter müssen die konkreten Werte zugewiesen werden. Entsprechen die angegebenen Parameter einer erweiterten Klasse von Grafiksignaturen, wird diese zur "verantwortlichen" Klasse, sofern die Klasse der Grafiksignatur der Zeichnungsregel mit ihr übereinstimmt oder eine Erweiterung von ihr ist.

In den erwähnten Bedingungen dürfen Objekt-Attribute (s. AttributePath in Regel SignParamAssignment) auch mit Laufzeit-Parametern verglichen werden (vgl. Kapitel 3.11, “Laufzeitparameter”). Laufzeitparameter, die für die Grafik relevant sind (z.B. der Massstab der gewünschten Grafik), werden typischerweise in Symbologiemodellen definiert, da sie wie die Parameter der Signaturen die von einem System erwarteten Grafikfähigkeiten beschreiben. Für einen Parameter einer Grafiksignatur, der ein Metaobjekt verlangt, muss eine Metaobjekt-Referenz angegeben werden (vgl. Kapitel 3.10, “Umgang mit Metaobjekten”).

Der Wert eines gewöhnlichen Parameters einer Grafiksignatur wird als Konstante oder als Verweis auf ein Objekt-Attribut angegeben (s. Factor in Regel SignParamAssignment). Dabei wird immer auf das Attribut eines Objektes aus der Basis-Klasse oder Basis-Sicht verwiesen, welches mit Hilfe von BASED ON spezifiziert wurde.

Da die Darstellung häufig von Attributen abhängt, die mittels Aufzählungen definiert sind, wird dafür ein spezielles Konstrukt angeboten: Der Aufzählbereich. Ein Aufzählbereich ist entweder ein einzelner Knoten des Aufzähltyp-Baums oder ein Intervall von Knoten definiert durch zwei Knoten der gleichen Stufe. Intervalldefinitionen sind allerdings nur zulässig, wenn es sich um einen geordneten Aufzähltyp handelt. Wenn der Attributwert in einem der angegebenen Aufzählbereiche liegt, wird der entsprechende Parameter-Wert gesetzt. Die konkreten Signaturen ergeben sich aus dem Signaturenmodell. Dort werden die Signaturklassen samt den für ihre Anwendung nötigen Laufzeitparametern (Schlüsselwort PARAMETER) definiert. Es ist zulässig, dass numerische Datentypen nur abstrakt definiert sind.

※

Syntaxregeln:

GraphicDef = 'GRAPHIC' Graphic-Name Properties<ABSTRACT,FINAL>
               [ 'EXTENDS' GraphicRef ]
               [ 'BASED' 'ON' ViewableRef ] '='
               { Selection }
               { DrawingRule }
             'END' Graphic-Name ';'.

GraphicRef = [ Model-Name '.' [ Topic-Name '.' ] ] Graphic-Name.

DrawingRule = DrawingRule-Name Properties<ABSTRACT,EXTENDED,FINAL>
                [ 'OF' Sign-ClassRef ]
                    ':' CondSignParamAssignment
                        { ',' CondSignParamAssignment } ';'.

CondSignParamAssignment = [ 'WHERE' Logical-Expression ]
                          '(' SignParamAssignment
                              { ';' SignParamAssignment } ')'.

SignParamAssignment = SignParameter-Name
                        ':=' ( '{' MetaObjectRef '}'
                             | Factor
                             | 'ACCORDING' Enum-AttributePath
                                 '(' EnumAssignment
                                     { ',' EnumAssignment } ')' ).

EnumAssignment = ( '{' MetaObjectRef '}' | Constant )
                   'WHEN' 'IN' EnumRange.

EnumRange = EnumerationConst [ '..' EnumerationConst ].

Für die Verwendung in Signaturenmodellen ist die Klasse SIGN durch INTERLIS vordefiniert:

CLASS SIGN (ABSTRACT) EXTENDS METAOBJECT =
  PARAMETER
    Sign: METAOBJECT;
END SIGN;

Für konkrete Signaturenklassen ist diese Basis-Klasse zu erweitern. Dabei werden einerseits die konkreten Daten, andererseits die Parameter definiert.

Das folgende Beispiel skizziert, wie aus einer Punktklasse mit Koordinaten, Zeichenkette und einer Aufzählung als Attribute die entsprechenden Grafiken (Punktsymbole und Textanschriften) definiert werden.

Das Signaturenmodell sei wie folgt definiert:

SYMBOLOGY MODEL SimpleSignsSymbology (en) AT "http://www.interlis.ch/"
  VERSION "2005-06-16" =

  DOMAIN
    S_COORD2 (ABSTRACT) = COORD NUMERIC, NUMERIC;

  TOPIC SignsTopic =

    CLASS Symbol EXTENDS INTERLIS.SIGN =
      PARAMETER
        Pos: MANDATORY S_COORD2;
    END Symbol;

    CLASS Textlabel EXTENDS INTERLIS.SIGN =
      PARAMETER
        Pos: MANDATORY S_COORD2;
        Text: MANDATORY TEXT;
    END Textlabel;

  END SignsTopic;

END SimpleSignsSymbology.

Zu diesem Signaturenmodell seien konkrete (Signaturen-)Objekte erfasst und unter dem Signaturenbibliotheks-Namen (d.h. Behälter-Namen) SimpleSignsBasket abgelegt worden. Die erfassten Signaturobjekte (Klasse Symbol) heissen Punktsignatur, Quadratsignatur und Kreissignatur, die Schriftarten (Klasse Textlabel) Schrift1 und Schrift2.

MODEL DatenModell (de) AT "http://www.interlis.ch/"
  VERSION "2005-06-16" =

  DOMAIN
    LKoord = COORD
      0.000 .. 200.000 [m],
      0.000 .. 200.000 [m],
      ROTATION 2 -> 1;

  TOPIC PunktThema =

    DOMAIN
      Punktart = (Stein
                   (gross,
                    klein),
                  Bolzen,
                  Rohr,
                  Kreuz,
                  unvermarkt) ORDERED;

    CLASS Punkt =
      Lage: LKoord;      !! LKoord sei ein Koordinaten-Wertebereich
      Art: Punktart;
      PunktName: TEXT*12;
    END Punkt;

  END PunktThema;

END DatenModell.


MODEL SimpleGrafik (de) AT "http://www.interlis.ch/"
  VERSION "2005-06-16" =

  IMPORTS DatenModell;
  IMPORTS SimpleSignsSymbology;

  SIGN BASKET SimpleSignsBasket ~ SimpleSignsSymbology.SignsTopic;

  TOPIC PunktGrafikenThema =
    DEPENDS ON DatenModell.PunktThema;

    GRAPHIC SimplePunktGrafik BASED ON DatenModell.PunktThema.Punkt =

      Symbol OF SimpleSignsSymbology.SignsTopic.Symbol: (
        Sign := {Punktsignatur};
        Pos := Lage
      );

    END SimplePunktGrafik;

  END PunktGrafikenThema;

END SimpleGrafik.

Mit dieser Grafik (basierend auf dem Symbologiemodell SimpleSignsSymbology und auf der Darstellungsbeschreibung SimpleGrafik) werden für alle Punkte aus Klasse Punkt einfache Punktsignaturen (dots) gezeichnet.

Nun kann man sich auch vorstellen, dass jemand eine verbesserte Grafik wünscht. Die Verbesserung kann dabei in verschiedener Hinsicht erfolgen, zum Beispiel:

Es soll zusätzliche Signaturen geben (Punktsignaturen Kreuzsignatur, Dreiecksignatur). Dafür braucht es eine zusätzliche Signaturenbibliothek mit dem Namen SimpleSignsPlusBasket. Da sie die Bibliothek SimpleSignsBasket erweitert, werden die Signaturobjekte (bzw. Metaobjekte) in beiden Bibliotheken gesucht. Würde man die Bibliothek SimpleSignsBasket direkt erweitern (EXTENDED) würde für alle im Modell GrafikPlus erzeugten Grafiken — inklusive derjenigen, die vom Modell SimpleGrafik geerbt wurden — die Signaturen zuerst in der erweiterten Bibliothek, dann in der Basisbibliothek (SimpleSignsBasket) gesucht.
Die Signaturen sollen skalierbar sein, damit z.B. grosse und kleine Quadrate mit der gleichen Punktsignatur erstellt werden können. Dafür braucht es ein erweitertes Signaturenmodell, in dem der Skalierungsmassstab der Signaturen als Parameter definiert ist. Da die Signaturklassen keine zusätzlichen Attribute aufweisen, müssen nicht notwendigerweise entsprechende Bibliotheken existieren.
Je nach Punktart sollen verschiedene Punktsignaturen gezeichnet werden: Steine als grosse bzw. kleine Quadrate, Bolzen als Kreise und Kreuze und Rohre mit der Kreuzsignatur. Die eigentliche Punktsignatur kann direkt aus der Punktart abgeleitet werden. Der Skalierungsfaktor für kleine Quadrate zur Darstellung von kleinen Steinen, wird mit einer zusätzlichen Zuweisung erreicht. Unvermarkte Punkte werden weiterhin als einfache Punktsignaturen gezeichnet. Darum braucht es für diesen Fall keine neue Zuweisung.

SYMBOLOGY MODEL ScalableSignsSymbology (en) AT "http://www.interlis.ch/"
  VERSION "2005-06-16" =

  IMPORTS SimpleSignsSymbology;

  TOPIC ScalableSignsTopic EXTENDS SimpleSignsSymbology.SignsTopic =

    CLASS Symbol (EXTENDED) =
      PARAMETER
        ScaleFactor: 0.1 .. 10.0;  !! Default 1.0
    END Symbol;

  END ScalableSignsTopic;

END ScalableSignsSymbology.


MODEL GrafikPlus (de) AT "http://www.interlis.ch/"
  VERSION "2005-06-16" =

  IMPORTS SimpleGrafik;
  IMPORTS SimpleSignsSymbology;
  IMPORTS ScalableSignsSymbology;

  SIGN BASKET SimpleSignsPlusBasket EXTENDS
    SimpleGrafik.SimpleSignsBasket ~ ScalableSignsSymbology.ScalableSignsTopic;

  TOPIC PunktGrafikenPlusTop EXTENDS SimpleGrafik.PunktGrafikenThema =

    GRAPHIC PunktGrafikPlus EXTENDS SimplePunktGrafik =

      Symbol (EXTENDED) OF ScalableSignsSymbology.ScalableSignsTopic.Symbol: (
        Sign := ACCORDING Art (
          {Quadratsignatur} WHEN IN #Stein,
          {Kreissignatur} WHEN IN #Bolzen,
          {Kreuzsignatur} WHEN IN #Rohr .. #Kreuz
        )
      ),
      WHERE Art == #Stein.klein (
          ScaleFactor := 0.5
      );

      Text OF SimpleSignsSymbology.Signs.Textlabel: (
        Sign := {Schrift1};
        Pos := Lage;
        Text := PunktName
      );

    END PunktGrafikPlus;

  END PunktGrafikenPlusTop;

END GrafikPlus.

4. Sequentieller Transfer

4.1. Einleitung

In diesem Kapitel wird der sequentielle INTERLIS-Transferdienst beschrieben. Damit können Datenbestände zwischen verschiedenen Systemen systemneutral ausgetauscht werden. Der INTERLIS-Transferdienst unterstützt den vollständigen wie auch den inkrementellen (bzw. differenziellen) Austausch von Datenbeständen (Replikation). Der Transferdienst kann auf jedes INTERLIS-Modell angewendet werden. Damit ist es z.B. möglich Daten (Datenmodell) und Signaturobjekte (Signaturenmodell) mit dem gleichen Mechanismus zu transferieren.

Im Moment ist der INTERLIS-Transferdienst als Austausch von XML-Dateien definiert (www.w3.org/XML/). Zur breiteren Nutzung dieser INTERLIS-XML-Dateien ist es unter anderem auch möglich, XML-Schema-Dokumente (www.w3.org/XML/Schema) zu erzeugen. In Zukunft ist es jedoch denkbar, dass weitere INTERLIS-Transferdienste definiert werden (z.B. auf Basis Webservices oder CORBA). Aus diesem Grund ist die Beschreibung des INTERLIS-Transferdienstes in die Unterabschnitte Allgemeine Regeln und XML-Codierung unterteilt. Die allgemeinen Regeln gelten für jeden sequentiellen INTERLIS-Transferdienst, unabhängig von der konkreten Codierung oder Übermittlung. Die Regeln unter XML-Codierung gelten speziell für XML-formatierte INTERLIS-Transferdateien.

4.2. Allgemeine Regeln für den sequentiellen Transfer

4.2.1. Ableitbarkeit aus dem Datenmodell

Jeder INTERLIS-Transfer kann aus dem dazugehörigen INTERLIS-Datenmodell durch die Anwendung von Regeln abgeleitet werden (modell-basierter Datentransfer).

4.2.2. Aufbau eines Transfers: Vorspann

Ein INTERLIS-Transfer ist ein sequentieller Objektstrom. Der Objektstrom ist in die Teile Vorspann und Datenbereich unterteilt.

Im Vorspann sind mindestens folgende Angaben zum Transfer enthalten:

Angabe der aktuellen INTERLIS-Versionsnummer (vgl. Kapitel 3.3, “Hauptregel”).
Verweis auf das/die zugehörige(n) Datenmodell(e).
Bezeichnung des Absenders (SENDER).

Optional können im Vorspann Angaben zum Herausgeber des Objektidentifikatoren-Aufbaus erfolgen.

Optional können im Vorspann Kommentare enthalten sein.

Der Aufbau des Datenbereichs ist in den folgenden Abschnitten näher beschrieben.

4.2.3. Transferierbare Objekte

Im Datenbereich können Objekte (d.h. Objektinstanzen) von konkreten Klassen, Beziehungen, Sichten und Grafikdefinitionen transferiert werden. Objekte von Sichten werden auf dem Transfer wie Objekte von konkreten Klassen behandelt. Die inkrementelle Nachlieferung von Sichten ist vorläufig nicht möglich. Objekte von Sichten werden nur transferiert, wenn die zugehörigen Sichten innerhalb eines VIEW TOPIC deklariert wurden, sonst werden sie nicht übermittelt. Ausserdem werden Sichten nicht übermittelt, wenn sie mit TRANSIENT markiert wurden.

4.2.4. Reihenfolge der Objekte im Datenbereich

Der Datenbereich besteht aus einer Folge von Behältern (Themen-Instanzen). Behälter können nur vollständig übertragen werden. Bei inkrementeller Nachlieferung werden nur die geänderten bzw. gelöschten Objekte übertragen. Zusammen mit der Vorgeschichte wird jedoch auch bei der inkrementellen Nachlieferung konzeptionell der ganze Behälter übertragen. Es ist grundsätzlich möglich, dass ein Transfer Behälter aus verschiedenen Modellen enthält. Ein Behälter enthält wiederum alle seine Objekte. Die Reihenfolge der Objekte im Transfer ist beliebig, insbesondere müssen die Objekte innerhalb eines Behälters nicht unbedingt nach Beziehungen geordnet oder nach Klassen gruppiert sein (im Gegensatz zu INTERLIS 1). Leere Behälter müssen nicht übertragen werden.

4.2.5. Codierung der Objekte

Im Objektstrom erhält jeder Behälter und jedes Objekt eine Identifikation. Die Identifikationen von Behältern und Objekten müssen über den gesamten Transfer eindeutig sein. Zu jedem Objekt wird ausserdem die Behälter-Identifikation mitgeliefert, in dem das Objekt ursprünglich erzeugt wurde (Originalbehälter). Bei inkrementeller Nachlieferung, bzw. beim initialen Transfer, muss die Identifikation des Behälters und der Objektinstanz generell und stabil sein, d.h. ein Objektidentifikator (vgl. Anhang F Aufbau von Objektidentifikatoren (OID)).

Alle Objektattribute (inkl. COORD, SURFACE, AREA, POLYLINE, STRUCTURE, BAG OF, LIST OF, etc.) werden unmittelbar zum Objekt gespeichert. Attribute vom Typ AREA werden wie Attribute vom Typ SURFACE codiert. Attribute vom Typ BAG werden wie Attribute vom Typ LIST codiert. STRUCTURE wird wie LIST {1} codiert.

Als Zeichenvorrat für die Übermittlung von Attributwerten stehen standardmässig nur die druckbaren Zeichen des US-ASCII Zeichensatzes (32 bis 126) und die Zeichen gemäss Anhang D Zeichentabelle zur Verfügung.

4.2.6. Transferarten

Zu jedem Behälter müssen folgende Angaben geliefert werden:

Angaben zur Art (KIND) des Transfers: FULL, INITIAL oder UPDATE.
Angaben zum Anfangs- (STARTSTATE) bzw. Endzustand (ENDSTATE) der Nachlieferung (nur bei Transferart INITIAL (ENDSTATE) oder UPDATE (STARTSTATE und ENDSTATE)).
Angaben zur Konsistenz des Inhaltes: COMPLETE, INCOMPLETE.

Es ist zulässig, dass im gleichen Transfer Behälter mit verschiedenen Transferarten (FULL, INTIAL und/oder UPDATE) vorkommen. Die Transferarten haben folgende Bedeutung:

FULL – Vollständiger Transfer. Beim Erhalt eines FULL-Behälters muss der Empfänger einen neuen Behälter zuerst initialisieren und dann alle Objekte mit INSERT in den Behälter einfügen. FULL ist als Basis für Nachlieferungen ungeeignet, da die Objektidentifikationen nur für diesen Transfer gültig sind. Transferdateien gemäss INTERLIS 1 entsprechen FULL. In der Transferart FULL kann nur die Operation INSERT vorkommen.
INITIAL – Erstlieferung. Entspricht der Transferart FULL mit dem Unterschied, dass der Behälter und die darin enthaltenen Objekte generelle und stabile OID besitzen müssen. In der Transferart INITIAL kann ebenfalls nur die Operation INSERT vorkommen.
UPDATE – Nachlieferung. Ein UPDATE-Behälter enthält Objekte mit INSERT-, UPDATE- oder DELETE-Operationen. Alle Objekte und der Behälter besitzen generelle und stabile OID. UPDATE-Behälter dürfen vom Zielsystem nur verarbeitet werden, wenn der Anfangszustand (STARTSTATE) des Behälters bereits mit INITIAL oder UPDATE empfangen wurde.

Für die Transferart UPDATE gelten ausserdem folgende zusätzlichen Transferregeln:

Das Empfängersystem kann davon ausgehen, dass nach der vollständigen Verarbeitung aller Daten eines UPDATE-Behälters wieder ein konsistenter Zustand herrscht, d.h. ein UPDATE-Behälter führt einen Behälter von einem konsistenten Zustand STARTSTATE in einen anderen konsistenten Zustand ENDSTATE über.
Ein UPDATE-Behälter ist für sich allein gesehen nicht konsistent, da Beziehungen meist nur zusammen mit der Vorgeschichte aufgelöst werden können.

Ausserdem muss zu jedem Objekt die Nachlieferungsoperation angegeben werden (vgl. Kapitel 2.4.5, “Behälter, Replikation und Datentransfer”). Die Operationen INSERT, UPDATE und DELETE bedeuten folgendes:

Die Operation INSERT hat die Bedeutung von «neues Objekt einfügen» (insert object).
Die Operation UPDATE bedeutet «Objektattributwerte aufdatieren» (update object). Es müssen alle Attribute (nicht nur die geänderten) geliefert werden.
Die Operation DELETE bedeutet «Objekt löschen» (delete object). Es sollen alle Attribute (nicht nur der OID) geliefert werden.

In vielen Fällen muss nicht ein ganzer Datenbestand, sondern nur ein Ausschnitt daraus transferiert werden. Als Folge der Ausschnittbildung können Geometrien (Polylinien und Flächen) unvollständig sein. Damit dies ohne ein zusätzliches Modell möglich ist, sollen Objekte (und als Folge der jeweilige Behälter) als INCOMPLETE markiert werden können.

4.2.7. Normative Referenzen

In der nachfolgenden XML-Codierung bzw. Herleitung des XML-Schema wird auf diverse externe Dokumentationen verwiesen, welche hier zusammengefasst sind:

{1} W3C: XML 1.0 Spezifikation, Ausgabe 2008

{2} W3C: XML Schema 1.1 Spezifikation, Ausgabe 2012

{3} IETF: RFC 3629, UTF-8 Spezifikation

{4} IETF: RFC 2045, Abschnitt 6.8 (Base64 Codierung)

4.3. XML-Codierung

4.3.1. Einleitung

Im Gegensatz zu den Regeln in Kapitel 4.2, “Allgemeine Regeln für den sequentiellen Transfer” gelten die Regeln unter XML-Codierung nur für gemäss XML-1.0 Standard formatierte Transferdateien {1}. Für die Formalisierung der Transferformat-Ableitungsregeln wird die in Kapitel 3.1, “Verwendete Syntax” eingeführte EBNF-Notation benutzt. Folgende Regeln werden hier bereits vordefiniert:

※

XML-Any = beliebige XML-Elemente (wohlgeformtes XML).
XML-base64Binary = beliebige in Base64 codierterte binäre Daten \{4\}.
XML-String = beliebiger Text ohne Tags (inkl. carriage return
             (Wagenrücklauf) (#xD), line feed (Zeilenvorschub) (#xA)
             und Tabulatorzeichen (#x9)).
XML-NormalizedString = beliebiger einzeiliger Text.
XML-NcName = ( Letter | '_' ) { Letter | Digit | '_' | '-' | '.' }.
XML-ID = [ XML-NcName ':' ] ( Letter | Digit | '_' )
         { Letter | Digit | '_' | '-' | '.' }.

4.3.2. Zeichencodierung

Als Zeichenvorrat für XML-String bzw. XML-NormalizedString stehen standardmässig nur die ASCII Zeichen von 32 bis 126 bzw. die Zeichen aus Anhang D Zeichentabelle zur Verfügung. Die Zeichen werden gemäss der Codierungsregel UTF-8 {3} oder als XML Character Reference codiert.

Eine XML Entity Reference ist nur für wenige Spezialzeichen erlaubt. Der Wert ist eine ASCII-Zeichenfolge, welche genau so im Transfer verwendet werden muss. Bemerkung: XML-Entities wie ü (für Zeichen ü) sind in einer INTERLIS 2-Transferdatei nicht erlaubt, weil von einer INTERLIS 2-Transferdatei keine Dokumenttypdefinition (DTD) referenziert wird.

Die benutzbaren XML Entities sind durch die XML 1.0 Spezifikation vordefiniert:

'&' muss durch die Zeichenfolge '&' ersetzt werden.
'<' muss durch die Zeichenfolge '<' ersetzt werden.
'>' muss durch die Zeichenfolge '>' ersetzt werden.
''' muss durch die Zeichenfolge ''' ersetzt werden.
'"' muss durch die Zeichenfolge '"' ersetzt werden.

Eine vollständige Zusammenfassung der Zeichencodierung mit allen möglichen Codierungsformen pro Zeichen ist in Anhang D Zeichentabelle enthalten. Ein INTERLIS 2 Schreibprogramm kann bei mehreren Codierungsformen pro Zeichen eine geeignete Form frei auswählen. Ein INTERLIS 2-Leseprogramm muss alle Codierungsformen erkennen. Kommen im Transfer Zeichen vor, die nicht im beim Modell definierten Zeichensatz (vgl. Kapitel 3.5, “Modelle, Themen, Klassen”) vorkommen (oder gemäss Anhang D, wenn die Angabe des Zeichensatzes beim Modell fehlt), ist es der Software überlassen, wie sie damit umgeht (z.B. stillschweigend ignorieren oder mit Hinweis durch ein Ersatzzeichen ersetzen).

Bemerkung: Mehrere Codierungsformen pro Zeichen und Zeichen ausserhalb des evtl. eingeschränkten Zeichensatzes werden zugelassen um maximale Kompatibilität mit bestehenden XML-Werkzeugen zu erreichen.

4.3.3. Allgemeiner Aufbau der Transferdatei

Eine INTERLIS-Transferdatei ist gemäss folgender EBNF-Hauptregel aufgebaut:

※

Transfer =
  <?xml version="1.0" encoding="UTF-8"?>
  <%ili%:transfer
    { NameSpaceDef }
    xmlns:%ili%="http://www.interlis.ch/xtf/2.4/INTERLIS"
    [ xmlns:%geom%="http://www.interlis.ch/geometry/1.0" ]
    [ xmlns:%xsi%="http://www.w3.org/2001/XMLSchema-instance" ] >
    HeaderSection
    DataSection
  </%ili%:transfer>.

NameSpaceDef =
  xmlns="%XMLNS%" | xmlns="http://www.interlis.ch/xtf/2.4/%ModelName%".

Die Regel HeaderSection erzeugt den Vorspann der Transferdatei und die Regel DataSection den Datenbereich.

Eine durch die Transferregel erzeugte INTERLIS-Transferdatei ist immer auch eine wohlgeformte (well formed) XML 1.0-Transferdatei {1}. In einer INTERLIS-Transferdatei können daher auch beliebig viele Kommentarzeilen der Form

<!-- %Comment% -->

an den in XML 1.0 dafür vorgesehenen Stellen vorkommen. Der Inhalt der Kommentarzeilen %Comment% darf von der Transfersoftware jedoch nicht interpretiert werden.

Grundsätzlich ist ein INTERLIS 2 Schreibprogramm frei, welcher Prefix (%ili%, %geom%, %ns%) für welchen XML-Namespace verwendet wird, bzw. welcher XML-Namespace als default XML-Namespace verwendet wird. Mit %ns% ist der jeweilige XML-Namespace des INTERLIS-Modells gemeint, in dem das entsprechende Modellelement definiert wurde.

Das XML-Schema für den Namespace "http://www.interlis.ch/xtf/2.4/INTERLIS" wird im Anhang B definiert und für "http://www.interlis.ch/geometry/1.0" im Anhang C. Alle anderen XML-Schemas ergeben sich aus den Regeln gemäss Kapitel 4.4, “Herleitung des XML-Schema aus dem Datenmodell”.

Die Daten werden als XML-Objekte übertragen. Die Tagnamen der XML-Objekte werden jeweils aus den Objektnamen im INTERLIS-Datenmodell abgeleitet. Für übersetzte Datenmodelle (TRANSLATION OF) bleiben die Tagnamen in der Ursprungs-Sprache, d.h. das Transferformat ändert sich nicht.

Enthält das Modell eine explizite Namespace Definition (XMLNS; vgl. Regel ModelDef), wird diese übernommen. Andernfalls wird der Namespace aus "http://www.interlis.ch/xtf/2.4/" und dem ModelName gebildet.

Hinweis: Um die Lesbarkeit zu erhöhen und die Verarbeitbarkeit mit diversen Texteditoren zu verbessern, wird empfohlen die XML-Daten formatiert in die Transferdatei zu schreiben.

4.3.4. Vorspann

Der Vorspann ist wie folgt aufgebaut:

※

HeaderSection =
  <%ili%:headersection>
    <%ili%:models> (* Model *) </%ili%:models>
    [ <%ili%:sender>%Sender%</%ili%:sender> ]
    [ <%ili%:comment>%Comment%</%ili%:comment> ]
    </ili:headersection>.

*Model* =
  <%ili%:model>
    %ModelName%
  </%ili%:model>.

Unter models müssen die Hauptmodelle eingetragen werden zu welchen Objekte im Transfer vorkommen können. In %Comment% kann (optional) ein Kommentar angegeben werden, in dem der Transfer näher beschrieben wird.

4.3.5. Datenbereich

Der Datenbereich ist wie folgt aufgebaut:

※

DataSection =
  <%ili%:datasection>
    { Basket }
  </%ili%:datasection>.

4.3.6. Codierung von Themen

Behälter sind Instanzen eines konkreten TOPIC bzw. VIEW TOPIC. Behälter werden wie folgt codiert:

※

Basket =
  <%ns%:%TopicName% %ili%:bid="%BasketId%"
    [ %ili%:kind="%TransferKind%"
    %ili%:startstate="%StartState%" %ili%:endstate="%EndState%" ] >
    [ %ili%:domains="%Domain-Assignments%" ]
    [ %ili%:consistency="%Consistency%" ]
    { Object | Link | DeleteObject }
  </%ns%:%TopicName%>.

Der Wert %ns%:%TopicName% muss für jedes konkrete Topic entsprechend substituiert werden (z.B. Fixpunkte). Die XML-Attribute des Behälters haben folgende Bedeutung:

%BasketId%. In %BasketId% muss die Behälteridentifikation eingetragen werden. Die Behälteridentifikation ist wie eine XML-ID formatiert und muss bei inkrementeller Nachlieferung zusätzlich eine OID sein.
%TransferKind%. Transferart (mögliche Werte: FULL, UPDATE, INITIAL). Falls das Attribut fehlt, wird FULL angenommen.
%StartState%. Anfangszustand des Behälters vor dem Transfer (nur bei inkrementeller Nachlieferung).
%EndState%. Endzustand des Behälters nach dem Transfer (nur bei inkrementeller Nachlieferung).
Werden in einem TOPIC direkt oder indirekt generische Wertebereichsdefinitionen (GENERIC) verwendet, muss in %Domain-Assignments% dem generischen Wertebereich ein konkreter Wertebereich zugeordnet werden. Werden mehrere generische Wertebereiche verwendet, müssen die einzelnen Zuordnungen durch Leerzeichen getrennt werden. Eine Zuordnung besteht aus den beiden voll qualifizierten Wertebereichsnamen (%ModelName%[.%TopicName%].%GenericDomainName%=%ModelName%[.%TopicName%].%ConcreteDomainName%).
Wird nur ein geographischer Ausschnitt aus einem Datenbestand übertragen, muss man das in %Consistency% mit dem Wert INCOMPLETE vermerken. Ohne Angabe gilt für %Consistency% der Wert COMPLETE (= vollständiger Datenbestand). In einem Datenbestand-Ausschnitt kann anstelle von POLYLINE auch MULTIPOLYLINE bzw. für SURFACE auch MULTISURFACE vorkommen.

4.3.7. Codierung von Klassen und Beziehungen

Die Objektinstanzen einer konkreten Klasse bzw. einer nicht eingebetteten Beziehung werden wie folgt codiert:

※

Object =
  <[ %ns%: ] [ %TopicName%. ] %ClassName%
    %ili%:tid="%Tid%" [ %ili%:operation="%Operation%" ] >
    [ { Attribute | EmbeddedLink } ]
  </[ %ns%: ][ %TopicName%. ] ClassName%>.

Link =
  <[ %ns%: ] [ %TopicName%. ] %AssociationName%
    [ %ili%:tid=”%Tid%” ] [ %ili%:operation="%Operation%" ] >
    [ { Role | Attribute | EmbeddedLink } ]
  </[ %ns%: ] [ %TopicName%. ] %AssociationName%>.

DeleteObject =
  <%ili%:delete [ %ili%:tid= "%Tid%" ] )
    { <[ %ns%: ] %RoleName% %ili%:ref="%Tid%"/> }
   </%ili%:delete>.

Der Wert %ClassName% muss für jede konkrete Klasse entsprechend substituiert werden (z.B. LFP). Jede Klasse – und damit jede Objektinstanz – erhält zusätzlich zu den im Modell definierten Attributen implizit eine Transferidentifikation (XML-Attribut tid). Die %Tid% muss wie eine XML-ID formatiert sein.

%TopicName% muss nur für Klassen / Beziehungen angeben werden, für welche ein Namenskonflikt mit Klassen / Beziehungen / Strukturen aus anderen Topics des gleichen Modells besteht.

Instanzen von Beziehungen (Link) haben nur eine Transferidentifikation, wenn diese im Rahmen der Definition mit dem Property OID gefordert wurde (vgl. Kapitel 3.7.1, “Beschreibung von Beziehungen”).

In der Transferart FULL müssen alle %Tid% innerhalb des gesamten Transfers eindeutig sein. In der Transferart INITIAL oder UPDATE müssen die %Tid% global eindeutige OID’s sein. Zudem erhält jedes Objekt in den Transferarten INITIAL und UPDATE ein Attribut für die Nachlieferungsoperation (XML-Attribut operation). Das XML-Attribut operation kann die Werte INSERT, UPDATE oder DELETE annehmen. Ohne Angabe von operation wird der Wert INSERT angenommen.

Mit DeleteObject kann bei inkrementeller Nachlieferung die Löschung eines bestimmten Objekts des Baskets über seine OID verlangt werden. Bei Beziehungen ohne OID wird die Instanz (Link) durch die Kombination der OIDs der bezeigten Objekte identifiziert. Bei DeleteObject müssen im Gegensatz zu operation="DELETE" keine weiteren Attribute des Objekts geliefert werden.

Für die Reihenfolge der Rollen, Attribute, Referenzattribute und eingebetteten Beziehungen innerhalb der Klasse gilt: Zuerst werden alle Rollen der Basisklasse, dann alle Attribute/Referenzattribute der Basisklasse, dann alle eingebetteten Beziehungen der Basisklasse, dann alle Attribute/Referenzattribute der Erweiterung, dann alle eingebetteten Beziehungen der Erweiterung codiert, etc. (Zwiebelprinzip). Innerhalb der gleichen Erweiterungsstufe werden die Attribute/Referenzattribute und Rollen gemäss ihrer Definitionsreihenfolge in der Modelldatei codiert. Die eingebetteten Beziehungen werden innerhalb der gleichen Erweiterungsstufe alphabetisch aufsteigend sortiert.

Parameter werden mit einer Ausnahme, wie sie im Kapitel 4.3.10, “Codierung von Grafikdefinitionen” angegeben ist, nicht übertragen.

4.3.8. Codierung von Sichten

Zur Codierung von Sichten vgl. Kapitel 4.2.3, “Transferierbare Objekte”. Es wird das XML-Attribut tid, nicht aber operation übermittelt. Als Attribute des Sichtobjekts werden nur diejenigen Attribute übertragen, welche in der Sicht explizit unter ATTRIBUTE bzw. implizit mit ALL OF angegeben wurden.

4.3.9. Codierung von Beziehungen

Beziehungen werden auf zwei Arten codiert: eingebettet oder nicht eingebettet. Eine eingebettete Beziehung wird als Sub-Element von einer, an der Assoziation beteiligten, Klasse codiert. Die Instanz einer nicht eingebetteten Beziehung (Link) wird wie eine Instanz einer Klasse codiert.

Beziehungen werden immer eingebettet, ausser

wenn sie mehr als zwei Rollen haben oder
wenn bei beiden (Basis-)Rollen die maximale Kardinalität grösser 1 ist oder
wenn für die Beziehung eine OID gefordert wird oder
bei gewissen themenübergreifenden Beziehungen (s. unten).

Falls bei einer der beiden (Basis-)Rollen die maximale Kardinalität grösser 1 ist, wird bei der Ziel-Klasse dieser Rolle eingebettet. Wenn diese Ziel-Klasse in einem anderen Topic definiert ist als die (Basis-)Assoziation, kann nicht eingebettet werden.

Falls bei beiden (Basis-)Rollen die maximale Kardinalität kleiner gleich 1 ist, wird bei der Ziel-Klasse der zweiten Rolle eingebettet. Wenn diese Ziel-Klasse in einem anderen Topic definiert ist als die (Basis-)Assoziation und die Ziel-Klasse der ersten Rolle im selben Topic definiert ist wie die (Basis-)Assoziation, wird bei der Ziel-Klasse der ersten Rolle eingebettet (d.h., wenn die Ziel-Klassen der beiden Rollen in einem anderen Topic definiert sind als die (Basis-)Assoziation, kann nicht eingebettet werden).

4.3.9.1. Eingebettete Beziehungen

Eingebettete Beziehungen werden wie ein Strukturattribut der Klasse, bei der die Beziehung eingebettet wird, übertragen.

Die Unterstruktur hat folgenden Aufbau:

※

EmbeddedLink =
  <[ %ns%: ] %RoleName% %ili%:ref="%Tid%"
    [ %ili%:order_pos=”%PosNumber%” ]>
    [ EmbeddedLinkStruct ]
  </[ %ns%: ] %RoleName%>.

EmbeddedLinkStruct =
  <[ %ns%: ] [ %TopicName%. ] %AssociationName%>
    (* Attribute *)
  </[ %ns%: ] [ TopicName%. ] %AssociationName%>.

Für %RoleName% muss der Name der Rolle angegeben werden, welche auf das gegenüberliegende Objekt verweist (die andere Rolle wird nicht codiert). In EmbeddedLinkStruct werden allfällige Attribute der Beziehung codiert. Die XML-Attribute ref und order_pos haben die gleiche Bedeutung wie bei nicht eingebetteten Beziehungen. %TopicName% muss nur angegeben werden, wenn es mit Klassen / Assoziationen oder Strukturen aus anderen Topics des gleichen Modells einen Namenskonflikt gibt.

4.3.9.2. Nicht eingebettete Beziehungen

Nicht eingebettete Beziehungen werden wie Objektinstanzen von Klassen übertragen.

Hinweis: Für Beziehungen ohne expliziten Namen wird der (Klassen)Name durch zusammenhängen der einzelnen Rollennamen gebildet (d.h. z.B. %RoleName1RoleName2%).

Rollen werden wie Attribute behandelt. Die Rollen selbst werden wie folgt codiert:

※

Role =
  <[ %ns%: ] %RoleName% %ili%:ref="%Tid%"
    [ %ili%:order_pos="%PosNumber%" ]>
  </[ %ns% ] %RoleName%>.

In ref wird dabei die Transferidentifikation des referenzierten Objekts eingetragen.

In geordneten Beziehungen definiert das Attribut order_pos (Wert > 0!) die innerhalb des Transferbehälters absolute Position in der geordneten Liste der Beziehungsobjekte.

4.3.10. Codierung von Grafikdefinitionen

Für jede Grafikdefinition werden im Transfer die von der Grafikdefinition referenzierten Signaturklassen (Sign-ClassRef) übertragen. Die Objektinstanzen der Signaturklassen werden durch das Ausführen der Grafikdefinitionen auf einem konkreten Inputdatensatz erzeugt. Parameter werden dabei wie Attribute codiert.

4.3.11. Codierung von Attributen

4.3.11.1. Allgemeine Regeln für die Codierung von Attributen

Jedes Attribut einer Objektinstanz (einschliesslich komplexer Attribute wie (MULTI)COORD, (MULTI)POLYLINE, (MULTI)SURFACE, (MULTI)AREA, STRUCTURE, LIST OF, BAG OF, etc.) wird wie folgt codiert:

※

Attribute = {
    <[ %ns%:  ]%AttributeName%>
      AttributeValue
    </[%ns%:]%AttributeName%>
  }
  | ReferenceAttribute.

AttributeValue = (
    TextValue | MTextValue | EnumValue | NumericValue |
    FormattedValue | DateValue | TimeValue | DateTimeValue |
    BlackboxValue | ClassTypeValue |
    AttributePathTypeValue | StructureValue |
    CoordValue | MultiCoordValue | PolylineValue | MultiPolylineValue |
    SurfaceValue | MultiSurfaceValue | OIDAttributeValue
  ).

Bei undefiniertem Attributwert wird das Attribut nicht übertragen. Die Masseinheit des Attributwerts wird nicht codiert. Beispiel für ein einfaches Attribut:

<Nummer>12345</Nummer>

Bei LIST und BAG kann das Attributtag mehrfach angegeben werden. Beispiel für eine einfache Liste von Nummern:

<Nummer>12345</Nummer>
<Nummer>23456</Nummer>
<Nummer>34567</Nummer>

4.3.11.2. Codierung von Zeichenketten

Attribute vom Basistyp TEXT bzw. MTEXT (und damit auch NAME und URI) werden wie folgt codiert:

※

TextValue = XML-NormalizedString.
MTextValue = XML-String.

4.3.11.3. Codierung von Aufzählungen

Aufzählungen werden wie folgt codiert:

※

EnumValue = ( EnumElement-Name { '.' EnumElement-Name } ) | 'OTHERS'.

Für die Codierung von Aufzählungen (unabhängig davon, ob der Wertebereich nur die Blätter oder auch die Knoten umfasst) wird die Syntax für Aufzählungskonstanten angewendet (Regel EnumValue). Das Zeichen # wird dabei weggelassen. Die vordefinierten Textausrichtungstypen HALIGNMENT und VALIGNMENT werden wie Aufzählungen codiert. Ebenso wird der Typ BOOLEAN wie eine Aufzählung übertragen.

4.3.11.4. Codierung von numerischen Datentypen

Numerische Werte werden wie folgt codiert:

※

NumericValue = NumericConst.

Der Wert wird in der Form gemäss der Wertebereichdefinition codiert (Ausnahme: Zwischenpunkte von Kreispunkte dürfen eine höhere Genauigkeit aufweisen).

Bemerkung: Float-Zahlen können in verschiedenen Darstellungen übertragen werden (mit oder ohne Mantisse). Sie können mit höherer Genauigkeit transferiert werden als durch den Wertebereich verlangt. Wesentlich ist dann lediglich, dass der Wert der Float-Zahl den verlangten Wertebereich nicht verletzt. Damit kann z.B. 100 (bei einem angenommenen Wertebereich von 0..999) als 100, 100.0000001, 10.0e1 oder 1.0e2 übertragen werden.

Der Empfänger ist gehalten, die Werte, ausser bei Zwischenpunkten von Kreisbogen (vgl. Kapitel 4.3.11.14, “Codierung von Linienzügen”), entsprechend dem numerischen Wertebereich zu runden.

4.3.11.5. Codierung von formatierten Wertebereichen

Formatierte Wertebereiche werden entsprechend der Formatdefinition codiert:

※

FormattedValue = XML-NormalizedString.

4.3.11.6. Codierung von Datum

Der Typ DATE wird wie folgt codiert:

※

DateValue = JJJJ-MM-TT.

JJJJ steht für das Jahr, MM für den Monat (01 .. 12), TT für den Tag (01 .. 31). Der 1. Dezember 1997 wird also mit 1997-12-01 übertragen.

4.3.11.7. Codierung von Zeit

Der Typ TIME wird wie folgt codiert:

※

TimeValue = HH:MM:SS.

Für Stunde (HH), Minute (MM) und Sekunde (SS) müssen immer zweistellige Werte angegeben werden (z.B. 01:13:00).

4.3.11.8. Codierung von Datum mit Zeit

Der Typ DATETIME wird wie folgt codiert:

※

DateTimeValue = DateValueTTimeValue.

Zwischen Datum und Zeit steht der Buchstabe T (z.B. 1997-12-01T01:13:00).

4.3.11.9. Codierung von Gefässen

Attributwerte vom Typ BLACKBOX werden wie folgt codiert:

※

BlackboxValue = XML-Any | XML-base64Binary.

Die XML-Variante des Typs BLACKBOX wird als XML-Any codiert, die binäre Variante als XML-base64Binary.

4.3.11.10. Codierung von Klassentypen

Attributwerte vom Typ CLASS oder STRUCTURE werden wie folgt codiert:

※

ClassTypeValue = XML-NormalizedString.

Der XML-NormalizedString enthält den vollständig qualifizierten Klassen-, Struktur- oder Assoziationsnamen (z.B. DM01AVCH24D.FixpunkteKategorie1.LFP1).

4.3.11.11. Codierung von Attributpfadtypen

Attributwerte vom Typ ATTRIBUTE werden wie folgt codiert:

※

AttributePathTypeValue = XML-NormalizedString.

Der XML-NormalizedString enthält den vollständig qualifizierten Klassennamen gefolgt vom durch einen Punkt abgetrennten Attributnamen (z.B. Grunddatensatz.Fixpunkte.LFP.Nummer).

4.3.11.12. Codierung von Strukturattributen

Strukturelemente vom Typ STRUCTURE werden wie folgt codiert:

※

StructureValue =
  <[ %ns%: ] [ %TopicName%. ] %StructureName%>
    (* Attribute *)
  </[ %ns%: ] [ %TopicName%. ] %StructureName%>.

%TopicName% muss nur für Strukturen angegeben werden, für welche ein Namenskonflikt mit Klassen / Beziehungen / Strukturen aus anderen Topics des gleichen Modells besteht.

4.3.11.13. Codierung von Koordinaten

Attributwerte vom Typ COORD werden wie folgt codiert:

※

CoordValue =
  <geom:coord>
    <geom:c1>NumericConst</geom:c1>
    <geom:c2>NumericConst</geom:c2>
    [ <geom:c3>NumericConst</geom:c3> ]
  </geom:coord>.

Die einzelnen XML-Unterobjekte müssen wie folgt gefüllt werden:

c1. Erste Komponente der Koordinate (codiert wie numerischer Wert).
c2. Zweite Komponente der Koordinate (nur bei 2D- und 3D-Koordinaten, codiert wie numerischer Wert).
c3. Dritte Komponente der Koordinate (nur bei 3D-Koordinaten, codiert wie numerischer Wert).

Attributwerte vom Typ MULTICOORD werden wie folgt codiert:

※

MultiCoordValue =
  <geom:multicoord>
    (* CoordValue *)
  </geom:multicoord>.

4.3.11.14. Codierung von Linienzügen

Attributwerte vom Typ POLYLINE werden wie folgt codiert:

※

PolylineValue =
  <geom:polyline>
    SegmentSequence
  </geom:polyline>.

StartSegment = CoordValue.

StraightSegment = CoordValue.

ArcSegment =
  <geom:arc>
    <geom:c1>NumericConst</geom:c1>
    <geom:c2>NumericConst</geom:c2>
    [ <geom:c3>NumericConst</geom:c3> ]
    <geom:a1>NumericConst</geom:a1>
    <geom:a2>NumericConst</geom:a2>
    [ <geom:r>NumericConst</geom:r> ]
  </geom:arc>.

LineFormSegment = StructureValue.

SegmentSequence = StartSegment (* StraightSegment
                               | ArcSegment
                               | LineFormSegment *).

Gerade Kurvenstücke eines Linienzugs werden gemäss Regel StraightSegment codiert, für kreisbogenförmige Segmente gilt die Regel ArcSegment. Mit LINE FORM definierte Liniensegmente werden wie eine Struktur (LineStructure) codiert.

Bemerkungen: Für Kreisbogensegmente (Regel ArcSegment) kann der Radius (optionales XML-Attribut r) zusätzlich zur Zwischenpunktkoordinate (a1/a2) übermittelt werden. Er ist immer positiv. Der Zwischenpunkt eines Kreisbogens ist nur für die Lage von Bedeutung. Bei Differenzen zwischen Radius und Koordinatenwerten gilt der Radius (vgl. Kapitel 3.8.12.2, “Linienzug mit Strecken und Kreisbogen als vordefinierte Kurvenstücke”). Damit bei fehlendem Radius die systeminternen Kreisbogenattribute möglichst präzis bestimmt werden können, sollen die Koordinatenwerte des Zwischenpunktes nicht gemäss Wertebereichsdefinition gerundet werden. Wenn der Radius definiert ist, darf der Zwischenpunkt um höchstens 1 Genauigkeitseinheit (der Wert 1 der hintersten Stelle gemäss Wertebereichsdefinition) multipliziert mit der Hälfte der Quadratwurzel von 2 von der Spur des aus dem Radius gerechneten Kreisbogens abweichen. Die Stützpunkthöhe (c3) muss nur bei 3D-Polylines übertragen werden.

Attributwerte vom Typ MULTIPOLYLINE (und auch für POLYLINE im Falle von einem Datenbestands-Ausschnitt) werden wie folgt codiert:

※

MultiPolylineValue =
  <geom:multipolyline>
   (* PolylineValue *)
  </geom:multipolyline>.

4.3.11.15. Codierung von Einzelflächen und Gebietseinteilungen

SURFACE und AREA werden wie folgt codiert:

※

SurfaceValue =
  <geom:surface>
    Boundaries
  </geom:surface>.

Boundaries = OuterBoundary { InnerBoundary }.

OuterBoundary =
  <geom:exterior>
    PolylineValue
  </geom:exterior>.

InnerBoundary =
  <geom:interior>
    PolylineValue
  </geom:interior>.

Flächen werden als Folge von Rändern (Boundaries) übertragen.

Ein Rand ist eine Folge von Randlinien, wobei jeweils die nächste Randlinie mit dem Endpunkt der vorhergehenden Randlinie beginnt. Der Endpunkt der letzten Randlinie ist identisch mit dem Anfangspunkt der ersten Randlinie. Die Randlinien eines Randes bilden also zusammen einen geschlossenen Linienzug (Polygon). Bei diesem müssen alle Punkte (ausser Anfangs-/Endpunkt) disjunkt sein (vgl. Kapitel 3.8.12.2, “Linienzug mit Strecken und Kreisbogen als vordefinierte Kurvenstücke” und Abbildung 22). Ein Rand darf bei beliebigen Stützpunkten in Randlinien aufgeteilt werden. Die Aufteilung in Randlinien darf bei jedem Transfer – insbesondere auch bei inkrementeller Nachlieferung – unterschiedlich sein.

Der erste Rand einer Fläche (OuterBoundary) ist der äussere Rand der Fläche. Die allenfalls folgenden inneren Ränder (InnerBoundary) der Fläche begrenzen die Inseln der Fläche. Sie dürfen gemeinsame Stützpunkte mit anderen Rändern aufweisen, soweit die Bedingungen gemäss Kapitel 3.8.13.1, “Geometrie von Flächen” erfüllt sind. Liegen auf beiden Seiten einer Randlinie definierte Gebietsobjekte (AREA), müssen die beiden Randlinien deckungsgleich sein. Dies ist der Fall, wenn alle Stützpunkte identisch aber in umgekehrter Reihenfolge angeordnet sind und alle weiteren Werte deckungsgleicher Linienstücke (Zwischenpunktkoordinaten, Radius) identisch sind.

Attributwerte vom Typ MULTISURFACE (und auch für SURFACE im Falle von einem Datenbestands-Ausschnitt) werden wie folgt codiert:

※

MultiSurfaceValue =
   <geom:multisurface>
    (* SurfaceValue *)
  </geom:multisurface>.

4.3.11.16. Codierung von Referenzen

Attribute vom Typ REFERENCE TO werden wie folgt codiert:

※

ReferenceAttribute =
  <[ %ns%: ] %AttributeName% %ili%:ref="%Tid%">
  </[ %ns%: ] %AttributeName%>.

Das XML-Attribut ref hat die gleiche Bedeutung wie bei eigentlichen Beziehungen.

4.3.11.17. Codierung von Metaobjekten

Attribute vom Typ METAOBJECT (vgl. Anhang A Das interne INTERLIS-Datenmodell) werden wie LIST OF oder BAG OF codiert. Parameter vom Typ METAOBJECT (Syntaxregel ParameterDef) werden jedoch nicht übermittelt. Parameter vom Typ METAOBJECT OF werden wie Attribute vom Typ NAME übertragen.

4.3.11.18. Codierung von OIDType

Attributwerte vom Typ OIDType werden wie eine XML-ID inkl. Oid-Werteraum codiert. Ist OIDType ein NumericType gelten ausserdem für den Wert (ohne den Oid-Werteraum) die Regeln für die Codierung von numerischen Typen.

※

OIDAttributeValue = XML-ID.

4.4. Herleitung des XML-Schema aus dem Datenmodell

4.4.1. Einleitung

Jede XML-Schema Datei (XSD) muss den Regeln gemäss {2} genügen. Ausserdem hat jede aus einem INTERLIS 2.4 Datenmodell abgeleitete XSD-Datei folgende Grundstruktur:

※

XSDDef =
  <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns="http://www.interlis.ch/xtf/2.4/%ModelName%"
    targetNamespace="http://www.interlis.ch/xtf/2.4/%ModelName%"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified"
    xmlns:ili="http://www.interlis.ch/xtf/2.4/INTERLIS"
    xmlns:geom="http://www.interlis.ch/geometry/1.0"
    >

    { TypeDef | ClassTypeDef | ObjectDef }
    { BasketDef }

  </xsd:schema>

Die XSD-Datei besteht aus einem Header mit Angaben zum Modell (ModelName). Danach folgen die Deklarationen für Typen (TypeDef) und Klassen (ClassTypeDef) und schliesslich die Basketdefinitionen (BasketDef). Jedes XML-Schema für ein Interlis Modell importiert die externen XML-Schemas "http://www.interlis.ch/xtf/2.4/INTERLIS" (INTERLIS 2.4 Basisdefinitionen, s.a. Anhang B) und "http://www.interlis.ch/geometry/1.0" (INTERLIS Geometrieschema, s.a. Anhang C).

Das generierte XML-Schema kann beliebig viele Kommentare () oder zusätzliche xsd:annotation-Elemente enthalten. Das generierte XML-Schema darf das INTERLIS-Modell exakter, d.h. mit zusätzlichen «facets», umsetzen.

4.4.2. Typdeklarationen

Alle Typen eines Modells (global oder auf Stufe Thema) werden wie folgt definiert:

※

TypeDef = SimpleTypeDef | ComplexTypeDef

SimpleTypeDef =
  <xsd:simpleType name=" [ %TopicName%. ] %TypeName%Type">
    SimpleTypeRestriction
  </xsd:simpleType>

ComplexTypeDef =
  <xsd:complexType name=" [ %TopicName%. ] %TypeName%Type">
    ComplexTypeContent
  </xsd:complexType>

Für alle Typen muss am Ende des Namen "Type" angehängt werden (z.B. LKoordType für den INTERLIS Typ LKoord). Für Typdeklarationen auf Stufe Thema muss den Typnamen zusätzlich %TopicName% vorangestellt werden (z.B. Bodenbedeckung.BBArtType), falls der Typname bereits auf Stufe Modell verwendet wurde.

4.4.3. Einfache Typen (SimpleTypeRestriction)

4.4.3.1. Numerische Typen

Numerische Typen ohne Skalierung (Längen, Flächen, Volumen, Winkel, Bereiche) werden wie folgt übersetzt:

※

<xsd:restriction base="xsd:decimal">
  [ <xsd:minInclusive value="%min-Dez%">
  <xsd:maxInclusive value="%max-Dez%"> ]
</xsd:restriction>

Die Einschränkung des Bereichs erfolgt nur, wenn der Typ im Modell als FINAL gekennzeichnet ist.

Numerische Typen mit Dezimalpunkt und Skalierung (Längen, Flächen, Volumen, Winkel, Bereiche) werden wie folgt übersetzt:

※

<xsd:restriction base="xsd:double">
  [ <xsd:minInclusive value="%min-Dez%">
  <xsd:maxInclusive value="%max-Dez%"> ]
</xsd:restriction>

Die Einschränkung des Bereichs erfolgt nur, wenn der Typ im Modell als FINAL gekennzeichnet ist.

Numerische Typen ohne Dezimalpunkt (Längen, Flächen, Volumen, Winkel, Bereiche), die im Modell als FINAL genkennzeichnet sind, werden wie folgt übersetzt:

※

<xsd:restriction base="xsd:integer">
  <xsd:minInclusive value="%min-Dez%">
  <xsd:maxInclusive value="%max-Dez%">
</xsd:restriction>

4.4.3.2. Text

Der Typ TEXT*n wird wie folgt übersetzt:

※

<xsd:restriction base="xsd:normalizedString">
  <xsd:maxLength value="%N%">
</xsd:restriction>

4.4.3.3. MText

Der Typ MTEXT*n wird wie folgt übersetzt:

※

<xsd:restriction base="xsd:string">
  <xsd:maxLength value="%N%">
</xsd:restriction>

4.4.3.4. OIDType, formatierte Wertebereiche, Klassentypen, Attributpfade

OIDType, formatierte Wertebereiche, Klassentypen und Attributpfade werden wie folgt übersetzt:

※

<xsd:restriction base="xsd:NCName"/>

4.4.3.5. XML-Gefässe

Der Typ BLACKBOX XML wird wie folgt übersetzt:

※

<xsd:restriction base="xsd:anyType"/>

4.4.3.6. Binäre Gefässe

Der Typ BLACKBOX BINARY wird wie folgt übersetzt:

※

<xsd:restriction base="xsd:base64Binary"/>

4.4.3.7. Datum

Der Typ DATE wird wie folgt übersetzt:

※

<xsd:restriction base="xsd:date"/>

4.4.3.8. Zeit

Der Typ TIMEOFDAY wird wie folgt übersetzt:

※

<xsd:restriction base="xsd:time"/>

4.4.3.9. Datum mit Zeit

Der Typ DATETIME wird wie folgt übersetzt:

※

<xsd:restriction base="xsd:dateTime"/>

4.4.3.10. Aufzählungen

Aufzählungen inkl. Textausrichtungen werden wie folgt übersetzt:

※

<xsd:restriction base="xsd:normalizedString">
  { EnumerationValue }
</xsd:restriction>

EnumerationValue =
  <xsd:enumeration value="%EnumerationValue%"/>

Die Auflistung der %EnumerationValue% erfolgt nur, wenn der Typ im Modell als FINAL gekennzeichnet ist. Für %EnumerationValue% müssen dann alle gültigen Werte des Aufzähltyps angegeben werden. Ist der Typ im Modell nicht FINAL, erfolgt keine Auflistung.

4.4.4. Komplexe Typen (ComplexTypeContent)

4.4.4.1. Koordinaten

COORD2 bzw. COORD3 werden wie folgt übersetzt:

※

<xsd:sequcence>
  <xsd:element ref="geom:coord" minOccurs="1" maxOccurs="1"/> (1)
</xsd:sequcence>

1	Im PDF-Dokument des Referenzhandbuchs (Version 2.1.0) fehlt der abschliessende Schrägstrich. Siehe dazu auch dieses Issue. Zudem ist die Beschränkung `minOccurs="1" maxOccurs="1"` überflüssig, da dies die Default-Werte sind (siehe XML-Spezifikation).

4.4.4.2. Multi-Koordinaten

MULTICOORD2 bzw. MULTICOORD3 werden wie folgt übersetzt:

※

<xsd:sequcence>
  <xsd:element ref="geom:multicoord" minOccurs="1" maxOccurs="1"/> (1)
</xsd:sequcence>

1	Im PDF-Dokument des Referenzhandbuchs (Version 2.1.0) fehlt der abschliessende Schrägstrich. Siehe dazu auch dieses Issue. Zudem ist die Beschränkung `minOccurs="1" maxOccurs="1"` überflüssig, da dies die Default-Werte sind (siehe XML-Spezifikation).

4.4.4.3. Polylinien

Der Typ POLYLINE wird wie folgt übersetzt:

※

<xsd:sequcence>
  <xsd:element ref="geom:polyline" minOccurs="1" maxOccurs="1"/> (1)
</xsd:sequcence>

1	Im PDF-Dokument des Referenzhandbuchs (Version 2.1.0) fehlt der abschliessende Schrägstrich. Siehe dazu auch dieses Issue. Zudem ist die Beschränkung `minOccurs="1" maxOccurs="1"` überflüssig, da dies die Default-Werte sind (siehe XML-Spezifikation).

4.4.4.4. Multi-Polylinien

Der Typ MULTIPOLYLINE wird wie folgt übersetzt:

※

<xsd:sequcence>
  <xsd:element ref="geom:multipolyline" minOccurs="1" maxOccurs="1"/> (1)
</xsd:sequcence>

1	Im PDF-Dokument des Referenzhandbuchs (Version 2.1.0) fehlt der abschliessende Schrägstrich. Siehe dazu auch dieses Issue. Zudem ist die Beschränkung `minOccurs="1" maxOccurs="1"` überflüssig, da dies die Default-Werte sind (siehe XML-Spezifikation).

4.4.4.5. Flächen

Der Typ SURFACE wird wie folgt übersetzt:

※

<xsd:sequcence>
  <xsd:element ref="geom:surface" minOccurs="1" maxOccurs="1"/> (1)
</xsd:sequcence>

1	Im PDF-Dokument des Referenzhandbuchs (Version 2.1.0) fehlt der abschliessende Schrägstrich. Siehe dazu auch dieses Issue. Zudem ist die Beschränkung `minOccurs="1" maxOccurs="1"` überflüssig, da dies die Default-Werte sind (siehe XML-Spezifikation).

4.4.4.6. Multi-Flächen

Der Typ MULTISURFACE wird wie folgt übersetzt:

※

<xsd:sequcence>
  <xsd:element ref="geom:multisurface" minOccurs="1" maxOccurs="1"/> (1)
</xsd:sequcence>

1	Im PDF-Dokument des Referenzhandbuchs (Version 2.1.0) fehlt der abschliessende Schrägstrich. Siehe dazu auch dieses Issue. Zudem ist die Beschränkung `minOccurs="1" maxOccurs="1"` überflüssig, da dies die Default-Werte sind (siehe XML-Spezifikation).

4.4.4.7. Rollen

Rollen werden wie folgt übersetzt:

※

<xsd:attribute ref="ili:ref" use="required"/>
<xsd:attribute ref="ili:order_pos"/>

4.4.4.8. Referenzattribute

Referenzattribute werden wie folgt übersetzt:

※

<xsd:attribute ref="ili:ref" use="required"/>

4.4.5. Klassen, Strukturen und Beziehungen

Klassen, Strukturen und eigenständige Beziehungen werden wie folgt übersetzt:

※

ClassTypeDef = RootClassTypeDef | ExtendedClassTypeDef

RootClassTypeDef =
  <xsd:complexType name=" [ %TopicName%. ] %ClassName%Type">
    <xsd:sequence>
      <xsd:element ref="ili:extensions" minOccurs="0"/>
      (* AttributeDef | EmbeddedLinkDef | RoleDef *)
    </xsd:sequence>
    <xsd:anyAttribute processContents="lax"/>
    [ <xsd:attribute ref="ili:tid"/> ]
    [ <xsd:attribute ref="ili:operation"/> ]
  </xsd:complexType>

ExtendedClassTypeDef =
  <xsd:complexType name=" [ %TopicName%. ] %ClassName%Type">
    <xsd:complexContent>
      <xsd:extension base=" [ %TopicName%. ] %ClassName%Type">
        <xsd:sequence>
          (* AttributeDef | EmbeddedLinkDef | RoleDef *)
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>

ObjectDef =
  <xsd:element name= [ %TopicName%. ] "%ClassName%" type="%ClassName%Type"
   [ substitutionGroup=" [ %TopicName%. ] "%ClassName%" ] />

Bei Klassen ist die Angabe des XML-Attributs TID obligatorisch. In Strukturen dürfen die Attribute TID und OPERATION nicht vorkommen.

※

AttributeDef =
  AttributeWithNamedTypeDef | AttributeWithLocalTypeDef

AttributeWithNamedTypeDef =
  <xsd:element name="%Attribut-Name%"
      minOccurs="%MinCard%" maxOccurs="%MaxCard%"
      type="%NamedTypeRef%"/>

AttributeWithLocalTypeDef =
  <xsd:element name="%Attribut-Name%"
      minOccurs="%MinCard%" maxOccurs="%MaxCard%">
    TypeDef
  </xsd:element>

EmbeddedLinkDef =
  <xsd:element name="%Role-Name%">
    <xsd:complexType>
      [ <xsd:sequence>
          <xsd:element ref=" [ %TopicName%. ] %ClassName%" minOccurs="0"/>
        </xsd:sequence> ]
      <xsd:attribute ref="ili:ref" use="required"/>
      [ <xsd:attribute ref="ili:order_pos" /> ]
      <xsd:anyAttribute processContents="lax"/>
    </xsd:complexType>
  </xsd:element>

RoleDef =
  <xsd:element name="%Role-Name%">
    <xsd:complexType>
      <xsd:attribute ref="ili:ref" use="required"/>
      [ <xsd:attribute ref="ili:order_pos" /> ]
      <xsd:anyAttribute processContents="lax"/>
    </xsd:complexType>
  </xsd:element>

Für die Reihenfolge der Attribute, Rollen und EmbeddedLink innerhalb der Klasse gilt: Die Attribute/Referenzattribute und Rollen werden gemäss ihrer Definitionsreihenfolge in der Modelldatei codiert. Die EmbeddedLink werden innerhalb der gleichen Erweiterungsstufe alphabetisch aufsteigend sortiert. Die Rollen, Attribute und EmbeddedLink, die von einer Basisklasse geerbt werden, werden nicht wiederholt.

Für Listen- und Bag-Attribute muss für %MinCard% die minimale bzw. für %MaxCard% die maximale Kardinalität eingegetragen werden.

Für alle übrigen Attribute ist %MaxCard% gleich 1. Für MANDATORY Attribute beträgt %MinCard% ebenfalls 1, sonst 0.

Eingebettete Beziehungen werden gemäss der Regel EmbeddedLinkDef definiert.

TypeDef für Attribute mit lokaler Typdeklaration werden ohne XSD-Attribut name ausgegeben.

4.4.6. BasketDef

Pro Thema wird folgende Definition ausgegeben:

※

BasketDef =
  <xsd:element name="%Thema-Name%">
    <xsd:complexType>
      <xsd:choice minOccurs="0" maxOccurs="unbounded">
        <xsd:element ref="ili:extensions"/>
        { <xsd:element ref=" [ %TopicName%. ] %ClassName%"
            minoccurs="0" maxOccurs="unbounded"/> }
      </xsd:choice>
      <xsd:attribute ref="ili:bid" use="required"/>
      <xsd:attribute ref="ili:consistency"/>
      [ <xsd:attribute ref="ili:domains"/> ]
      [ <xsd:attribute ref="ili:kind"/>
        <xsd:attribute ref="ili:startstate"/>
        <xsd:attribute ref="ili:endstate"/> ]
      <xsd:anyAttribute processContents="lax"/>
    </xsd:complexType>
  </xsd:element>

Für Elementdefinitionen der Klassen innerhalb der BasketDef gilt: Zuerst werden alle Klassen der Basistopics, dann alle Klassen des Erweiterungstopics codiert, etc. (Zwiebelprinzip). Wobei Klassen des Erweiterungstopics nur codiert werden, wenn die Basisklasse nicht als Teil des Basistopics bereits codiert wurde.

Themen müssen in der XSD-Datei in der gleichen Reihenfolge wie im Datenmodell definiert werden.

5. Haftungsausschluss / Hinweise auf Rechte Dritter

eCH-Standards, welche der Verein eCH dem Benutzer zur unentgeltlichen Nutzung zur Verfügung stellen oder welche eCH referenzieren, haben nur den Status von Empfehlungen. Der Verein eCH haftet in keinem Fall für Entscheidungen oder Massnahmen, welche die Benutzenden auf Grund dieser Dokumente trifft und / oder ergreift. Die Benutzenden sind verpflichtet, die Dokumente vor deren Nutzung selbst zu überprüfen und sich gegebenenfalls beraten zu lassen. eCH-Standards können und sollen die technische, organisatorische oder juristische Beratung im konkreten Einzelfall nicht ersetzen.

In eCH-Standards referenzierte Dokumente, Verfahren, Methoden, Produkte und Standards sind unter Umständen markenrechtlich, urheberrechtlich oder patentrechtlich geschützt. Es liegt in der ausschliesslichen Verantwortlichkeit der Benutzenden, sich die allenfalls erforderlichen Rechte bei den jeweils berechtigten Personen und/oder Organisationen zu beschaffen.

Obwohl der Verein eCH all seine Sorgfalt darauf verwendet, die eCH-Standards sorgfältig auszuarbeiten, kann keine Zusicherung oder Garantie auf Aktualität, Vollständigkeit, Richtigkeit bzw. Fehlerfreiheit der zur Verfügung gestellten Informationen und Dokumente gegeben werden. Der Inhalt von eCH-Standards kann jederzeit und ohne Ankündigung geändert werden.

Jede Haftung für Schäden, welche dem Benutzer aus dem Gebrauch der eCH-Standards entstehen ist, soweit gesetzlich zulässig, wegbedungen.

6. Urheberrechte

Wer eCH-Standards erarbeitet, behält das geistige Eigentum an diesen. Allerdings verpflichten sich die Erarbeitenden, ihr betreffendes geistiges Eigentum oder ihre Rechte an geistigem Eigentum anderer, sofern möglich, den jeweiligen Fachgruppen und dem Verein eCH kostenlos zur uneingeschränkten Nutzung und Weiterentwicklung im Rahmen des Vereinszweckes zur Verfügung zu stellen.

Die von den Fachgruppen erarbeiteten Standards können unter Nennung der jeweiligen urhebenden Person von eCH unentgeltlich und uneingeschränkt genutzt, weiterverbreitet und weiterentwickelt werden.

eCH-Standards sind vollständig dokumentiert und frei von lizenz- und/oder patentrechtlichen Einschränkungen. Die dazugehörige Dokumentation kann unentgeltlich bezogen werden.

Diese Bestimmungen gelten ausschliesslich für die von eCH erarbeiteten Standards, nicht jedoch für Standards oder Produkte Dritter, auf welche in den eCH-Standards Bezug genommen wird. Die Standards enthalten die entsprechenden Hinweise auf die Rechte Dritter.

Appendix A: Das interne INTERLIS-Datenmodell (normativ)

Im Folgenden ist das gesamte interne Datenmodell nochmals zusammenfassend abgebildet.Dieses Modell dient nur zur Illustration und ist nicht kompilierbar (weil zum Beispiel Namen verwendet werden, die gemäss Sprachdefinition Schlüsselwörter sind (vgl. Kapitel 3.2.7, “Sonderzeichen und reservierte Wörter”). Einer INTERLIS verarbeitenden Software, z.B. dem von KOGIS zur Verfügung gestellten INTERLIS-Compiler, müssen die Elemente des Modells bekannt sein.

INTERLIS 2.4;

TYPE MODEL INTERLIS (en) AT "http://www.interlis.ch/"
  VERSION "2014-07-09" =

  LINE FORM
    STRAIGHTS;
    ARCS;
  END LINE FORM;

  UNIT
    ANYUNIT (ABSTRACT);
    DIMENSIONLESS (ABSTRACT);
    LENGTH (ABSTRACT);
    MASS (ABSTRACT);
    TIME (ABSTRACT);
    ELECTRIC_CURRENT (ABSTRACT);
    TEMPERATURE (ABSTRACT);
    AMOUNT_OF_MATTER (ABSTRACT);
    ANGLE (ABSTRACT);
    SOLID_ANGLE (ABSTRACT);
    LUMINOUS_INTENSITY (ABSTRACT);
    MONEY (ABSTRACT);

    METER [m] EXTENDS LENGTH;
    KILOGRAM [kg] EXTENDS MASS;
    SECOND [s] EXTENDS TIME;
    AMPERE [A] EXTENDS ELECTRIC_CURRENT;
    DEGREE_KELVIN [K] EXTENDS TEMPERATURE;
    MOLE [mol] EXTENDS AMOUNT_OF_MATTER;
    RADIAN [rad] EXTENDS ANGLE;
    STERADIAN [sr] EXTENDS SOLID_ANGLE;
    CANDELA [cd] EXTENDS LUMINOUS_INTENSITY;
  END UNIT;

  DOMAIN
    URI (FINAL) = TEXT*1023;
    NAME (FINAL) = TEXT*255;
    INTERLIS_1_DATE (FINAL) = TEXT*8;

    BOOLEAN (FINAL) = (
      false,
      true
    ) ORDERED;

    HALIGNMENT (FINAL) = (
      Left,
      Center,
      Right
    ) ORDERED;

    VALIGNMENT (FINAL) = (
      Top,
      Cap,
      Half,
      Base,
      Bottom
    ) ORDERED;

    NOOID = OID ANY;
    ANYOID (ABSTRACT) EXTENDS NOOID = OID ANY;
    I32OID EXTENDS ANYOID = OID 0 .. 2147483647;
    STANDARDOID EXTENDS ANYOID = OID TEXT*16;
    UUIDOID EXTENDS ANYOID = OID TEXT*36;

    LineCoord (ABSTRACT) = COORD NUMERIC, NUMERIC;
  END DOMAIN;

  FUNCTION myClass (Object: ANYSTRUCTURE): STRUCTURE;
  FUNCTION isSubClass (
    potSubClass: STRUCTURE;
    potSuperClass: STRUCTURE
  ): BOOLEAN;
  FUNCTION isOfClass (Object: ANYSTRUCTURE; Class: STRUCTURE): BOOLEAN;
  FUNCTION elementCount (bag: BAG OF ANYSTRUCTURE): NUMERIC;
  FUNCTION objectCount (Objects: OBJECTS OF ANYCLASS): NUMERIC;
  FUNCTION len (TextVal: TEXT): NUMERIC;
  FUNCTION lenM (TextVal: MTEXT): NUMERIC;
  FUNCTION trim (TextVal: TEXT): TEXT;
  FUNCTION trimM (TextVal: MTEXT): MTEXT;
  FUNCTION isEnumSubVal (SubVal: ENUMTREEVAL; NodeVal: ENUMTREEVAL): BOOLEAN;
  FUNCTION inEnumRange (
    Enum: ENUMVAL;
    MinVal: ENUMTREEVAL;
    MaxVal: ENUMTREEVAL
  ): BOOLEAN;
  FUNCTION convertUnit (from: NUMERIC): NUMERIC;
  FUNCTION length (geom: POLYLINE): NUMERIC;
  FUNCTION multilength (geom: MULTIPOLYLINE): NUMERIC;
  FUNCTION surface (geom: SURFACE): NUMERIC;
  FUNCTION multisurface (geom: MULTISURFACE): NUMERIC;
  FUNCTION areAreas (
    Objects: OBJECTS OF ANYCLASS;
    SurfaceBag: ATTRIBUTE OF @ Objects RESTRICTION (BAG OF ANYSTRUCTURE);
    SurfaceAttr: ATTRIBUTE OF @ SurfaceBag RESTRICTION (SURFACE)
  ): BOOLEAN;
  FUNCTION areAreas2 (Object: OBJECT OF ANYCLASS; SurfaceBag: TEXT; SurfaceAttr: TEXT): BOOLEAN;
  FUNCTION areAreas3 (Objects: OBJECTS OF ANYCLASS; SurfaceBag: TEXT; SurfaceAttr: TEXT): BOOLEAN;

  CLASS METAOBJECT (ABSTRACT) =
    Name: MANDATORY NAME;
    UNIQUE Name;
  END METAOBJECT;

  CLASS METAOBJECT_TRANSLATION =
    Name: MANDATORY NAME;
    NameInBaseLanguage: MANDATORY NAME;
    UNIQUE Name;
    UNIQUE NameInBaseLanguage;
  END METAOBJECT_TRANSLATION;

  STRUCTURE AXIS =
    PARAMETER
      Unit: NUMERIC [ANYUNIT];
  END AXIS;

  CLASS REFSYSTEM (ABSTRACT) EXTENDS METAOBJECT =
  END REFSYSTEM;

  CLASS COORDSYSTEM (ABSTRACT) EXTENDS REFSYSTEM =
    ATTRIBUTE
      Axis: LIST {1..3} OF AXIS;
  END COORDSYSTEM;

  CLASS SCALSYSTEM (ABSTRACT) EXTENDS REFSYSTEM =
    PARAMETER
      Unit: NUMERIC [ANYUNIT];
  END SCALSYSTEM;

  CLASS SIGN (ABSTRACT) EXTENDS METAOBJECT =
    PARAMETER
      Sign: METAOBJECT;
  END SIGN;

  TOPIC TIMESYSTEMS =
    CLASS CALENDAR EXTENDS INTERLIS.SCALSYSTEM =
      PARAMETER
        Unit(EXTENDED): NUMERIC [TIME];
    END CALENDAR;

    CLASS TIMEOFDAYSYS EXTENDS INTERLIS.SCALSYSTEM =
      PARAMETER
        Unit(EXTENDED): NUMERIC [TIME];
    END TIMEOFDAYSYS;
  END TIMESYSTEMS;

  UNIT
    Minute [min] = 60 [INTERLIS.s];
    Hour [h] = 60 [min];
    Day [d] = 24 [h];
    Month [M] EXTENDS INTERLIS.TIME;
    Year [Y] EXTENDS INTERLIS.TIME;
  END UNIT;

  REFSYSTEM BASKET BaseTimeSystems ~ TIMESYSTEMS =
    OBJECTS OF CALENDAR: GregorianCalendar;
    OBJECTS OF TIMEOFDAYSYS: UTC;
  END BaseTimeSystems;

  STRUCTURE TimeOfDay (ABSTRACT) =
    Hours: 0 .. 23 CIRCULAR [h];
    CONTINUOUS SUBDIVISION Minutes: 0 .. 59 CIRCULAR [min];
    CONTINUOUS SUBDIVISION Seconds: 0.000 .. 59.999 CIRCULAR [INTERLIS.s];
  END TimeOfDay;

  STRUCTURE UTC EXTENDS TimeOfDay =
    Hours(EXTENDED): 0 .. 23 {UTC};
  END UTC;

  DOMAIN
    GregorianYear = 1582 .. 2999 [Y] {GregorianCalendar};
  END DOMAIN;

  STRUCTURE GregorianDate =
    Year: GregorianYear;
    SUBDIVISION Month: 1 .. 12 [M];
    SUBDIVISION Day: 1 .. 31 [d];
  END GregorianDate;

  STRUCTURE GregorianDateTime EXTENDS GregorianDate =
    SUBDIVISION Hours: 0 .. 23 CIRCULAR [h] {UTC};
    CONTINUOUS SUBDIVISION Minutes: 0 .. 59 CIRCULAR [min];
    CONTINUOUS SUBDIVISION Seconds: 0.000 .. 59.999 CIRCULAR [INTERLIS.s];
  END GregorianDateTime;

  DOMAIN
    XMLTime = FORMAT BASED ON UTC ( Hours/2 ":" Minutes/2 ":" Seconds/2 );
    XMLDate = FORMAT BASED ON GregorianDate ( Year/4 "-" Month/2 "-" Day/2 );
    XMLDateTime EXTENDS XMLDate = FORMAT BASED ON GregorianDateTime
      ( INHERITANCE "T" Hours/2 ":" Minutes/2 ":" Seconds/2 );
  END DOMAIN;

  STRUCTURE LineSegment (ABSTRACT) =
    SegmentEndPoint: MANDATORY LineCoord;
  END LineSegment;

  STRUCTURE StartSegment (FINAL) EXTENDS LineSegment =
  END StartSegment;

  STRUCTURE StraightSegment (FINAL) EXTENDS LineSegment =
  END StraightSegment;

  STRUCTURE ArcSegment (FINAL) EXTENDS LineSegment =
    ArcPoint: MANDATORY LineCoord;
    Radius: NUMERIC [LENGTH];
  END ArcSegment;

  STRUCTURE SurfaceEdge =
    Geometry: DIRECTED POLYLINE;
  END SurfaceEdge;

  STRUCTURE SurfaceBoundary =
    Lines: LIST OF SurfaceEdge;
  END SurfaceBoundary;

  STRUCTURE LineGeometry =
    Segments: LIST OF LineSegment;
    MANDATORY CONSTRAINT isOfClass (Segments[FIRST], StartSegment);
  END LineGeometry;

END INTERLIS.

Appendix B: Das XML-Schema für das Modell INTERLIS (normativ)

Das folgende XML-Schema definiert Basistypen für die Schemagenerierungsregeln gemäss Kapitel 4.4, “Herleitung des XML-Schema aus dem Datenmodell” und das Modell INTERLIS gemäss Appendix A, Das interne INTERLIS-Datenmodell (normativ).

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.interlis.ch/xtf/2.4/INTERLIS" xmlns:geom="http://www.interlis.ch/geometry/1.0" targetNamespace="http://www.interlis.ch/xtf/2.4/INTERLIS" elementFormDefault="qualified" attributeFormDefault="unqualified" version="2014-08-05">
  <xsd:import namespace="http://www.interlis.ch/geometry/1.0"/>
  <xsd:element name="extensions">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:attribute name="tid" type="tidType"/>
  <xsd:attribute name="ref" type="tidType"/>
  <xsd:attribute name="operation" type="operationType"/>
  <xsd:attribute name="order_pos" type="orderposType"/>
  <xsd:attribute name="bid" type="bidType"/>
  <xsd:attribute name="consistency" type="consistencyType"/>
  <xsd:attribute name="domains" type="domainsType"/>
  <xsd:attribute name="kind" type="transferKindType"/>
  <xsd:attribute name="startstate" type="basketStateType"/>
  <xsd:attribute name="endstate" type="basketStateType"/>
  <xsd:simpleType name="tidType">
    <xsd:restriction base="xsd:token"/>
  </xsd:simpleType>
  <xsd:simpleType name="refType">
    <xsd:restriction base="xsd:token"/>
  </xsd:simpleType>
  <xsd:simpleType name="orderposType">
    <xsd:restriction base="xsd:positiveInteger"/>
  </xsd:simpleType>
  <xsd:simpleType name="bidType">
    <xsd:restriction base="xsd:token"/>
  </xsd:simpleType>
  <xsd:simpleType name="consistencyType">
    <xsd:restriction base="xsd:token">
      <xsd:enumeration value="COMPLETE"/>
      <xsd:enumeration value="INCOMPLETE"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="domainsType">
    <xsd:restriction base="xsd:NMTOKENS"/>
  </xsd:simpleType>
  <xsd:simpleType name="transferKindType">
    <xsd:restriction base="xsd:token">
      <xsd:enumeration value="FULL"/>
      <xsd:enumeration value="UPDATE"/>
      <xsd:enumeration value="INITIAL"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="operationType">
    <xsd:restriction base="xsd:token">
      <xsd:enumeration value="INSERT"/>
      <xsd:enumeration value="UPDATE"/>
      <xsd:enumeration value="DELETE"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="basketStateType">
    <xsd:restriction base="xsd:token"/>
  </xsd:simpleType>
  <xsd:element name="transfer" type="TransferType"/>
  <xsd:complexType name="TransferType">
    <xsd:sequence>
      <xsd:element name="headersection">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="models">
              <xsd:complexType>
                <xsd:sequence>
                  <xsd:element name="model" type="xsd:token" maxOccurs="unbounded"/>
                </xsd:sequence>
              </xsd:complexType>
            </xsd:element>
            <xsd:element name="sender" type="xsd:string" minOccurs="0"/>
            <xsd:element name="comment" type="xsd:string" minOccurs="0"/>
            <xsd:element ref="extensions" minOccurs="0"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
      <xsd:element name="datasection">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:any minOccurs="0" maxOccurs="unbounded" processContents="strict"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:simpleType name="HALIGNMENT">
    <xsd:restriction base="xsd:string">
      <xsd:enumeration value="Left"/>
      <xsd:enumeration value="Center"/>
      <xsd:enumeration value="Right"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="VALIGNMENT">
    <xsd:restriction base="xsd:string">
      <xsd:enumeration value="Top"/>
      <xsd:enumeration value="Cap"/>
      <xsd:enumeration value="Half"/>
      <xsd:enumeration value="Base"/>
      <xsd:enumeration value="Bottom"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="I32OID">
    <xsd:restriction base="xsd:int">
      <xsd:minInclusive value="0"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="STANDARDOID">
    <xsd:restriction base="xsd:token">
      <xsd:length value="16"/>
      <xsd:pattern value="[a-zA-Z][a-zA-Z0-9]*"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:simpleType name="UUIDOID">
    <xsd:restriction base="xsd:token">
      <xsd:length value="36"/>
      <xsd:pattern value="[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}"/>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:element name="METAOBJECT" type="METAOBJECTType"/>
  <xsd:complexType name="METAOBJECTType">
    <xsd:sequence>
      <xsd:element ref="extensions" minOccurs="0"/>
      <xsd:element name="Name">
        <xsd:simpleType>
          <xsd:restriction base="xsd:token">
            <xsd:maxLength value="255"/>
            <xsd:pattern value="[a-zA-Z][a-zA-Z0-9_]*"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:element>
    </xsd:sequence>
    <xsd:attribute ref="tid" use="required"/>
    <xsd:anyAttribute processContents="lax"/>
  </xsd:complexType>
  <xsd:element name="METAOBJECT_TRANSLATION" type="METAOBJECT_TRANSLATIONType"/>
  <xsd:complexType name="METAOBJECT_TRANSLATIONType">
    <xsd:sequence>
      <xsd:element ref="extensions" minOccurs="0"/>
      <xsd:element name="Name">
        <xsd:simpleType>
          <xsd:restriction base="xsd:token">
            <xsd:maxLength value="255"/>
            <xsd:pattern value="[a-zA-Z][a-zA-Z0-9_]*"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:element>
      <xsd:element name="NameInBaseLanguage">
        <xsd:simpleType>
          <xsd:restriction base="xsd:token">
            <xsd:maxLength value="255"/>
            <xsd:pattern value="[a-zA-Z][a-zA-Z0-9_]*"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:element>
    </xsd:sequence>
    <xsd:attribute ref="tid" use="required"/>
    <xsd:anyAttribute processContents="lax"/>
  </xsd:complexType>
  <xsd:element name="AXIS" type="AXISType"/>
  <xsd:complexType name="AXISType">
    <xsd:sequence/>
  </xsd:complexType>
  <xsd:element name="REFSYSTEM" type="REFSYSTEMType" substitutionGroup="METAOBJECT"/>
  <xsd:complexType name="REFSYSTEMType">
    <xsd:complexContent>
      <xsd:extension base="METAOBJECTType">
        <xsd:sequence/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="COORDSYSTEM" type="COORDSYSTEMType" substitutionGroup="REFSYSTEM"/>
  <xsd:complexType name="COORDSYSTEMType">
    <xsd:complexContent>
      <xsd:extension base="REFSYSTEMType">
        <xsd:sequence>
          <xsd:element name="Axis" maxOccurs="3">
            <xsd:complexType>
              <xsd:sequence>
                <xsd:element ref="AXIS"/>
              </xsd:sequence>
            </xsd:complexType>
          </xsd:element>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="SCALSYSTEM" type="SCALSYSTEMType" substitutionGroup="REFSYSTEM"/>
  <xsd:complexType name="SCALSYSTEMType">
    <xsd:complexContent>
      <xsd:extension base="REFSYSTEMType">
        <xsd:sequence/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="SIGN" type="SIGNType" substitutionGroup="METAOBJECT"/>
  <xsd:complexType name="SIGNType">
    <xsd:complexContent>
      <xsd:extension base="METAOBJECTType">
        <xsd:sequence/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="CALENDAR" type="CALENDARType" substitutionGroup="SCALSYSTEM"/>
  <xsd:complexType name="CALENDARType">
    <xsd:complexContent>
      <xsd:extension base="SCALSYSTEMType">
        <xsd:sequence/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TIMEOFDAYSYS" type="TIMEOFDAYSYSType" substitutionGroup="SCALSYSTEM"/>
  <xsd:complexType name="TIMEOFDAYSYSType">
    <xsd:complexContent>
      <xsd:extension base="SCALSYSTEMType">
        <xsd:sequence/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="TIMESYSTEMS" type="TIMESYSTEMSType"/>
  <xsd:complexType name="TIMESYSTEMSType">
    <xsd:sequence>
      <xsd:choice>
        <xsd:element ref="CALENDAR"/>
        <xsd:element ref="TIMEOFDAYSYS"/>
      </xsd:choice>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="TimeOfDay" type="TimeOfDayType"/>
  <xsd:complexType name="TimeOfDayType">
    <xsd:sequence>
      <xsd:element ref="extensions" minOccurs="0"/>
      <xsd:element name="Hours" minOccurs="0">
        <xsd:simpleType>
          <xsd:restriction base="xsd:integer">
            <xsd:minInclusive value="0"/>
            <xsd:maxInclusive value="23"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:element>
      <xsd:element name="Minutes" minOccurs="0">
        <xsd:simpleType>
          <xsd:restriction base="xsd:integer">
            <xsd:minInclusive value="0"/>
            <xsd:maxInclusive value="59"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:element>
      <xsd:element name="Seconds" minOccurs="0">
        <xsd:simpleType>
          <xsd:restriction base="xsd:decimal">
            <xsd:minInclusive value="0.0"/>
            <xsd:maxInclusive value="59.999"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:element>
    </xsd:sequence>
    <xsd:anyAttribute processContents="lax"/>
  </xsd:complexType>
  <xsd:element name="UTC" type="UTCType" substitutionGroup="TimeOfDay"/>
  <xsd:complexType name="UTCType">
    <xsd:complexContent>
      <xsd:extension base="TimeOfDayType">
        <xsd:sequence/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="GregorianDate" type="GregorianDateType"/>
  <xsd:complexType name="GregorianDateType">
    <xsd:sequence>
      <xsd:element ref="extensions" minOccurs="0"/>
      <xsd:element name="Year" type="xsd:gYear" minOccurs="0"/>
      <xsd:element name="Month" minOccurs="0">
        <xsd:simpleType>
          <xsd:restriction base="xsd:integer">
            <xsd:minInclusive value="1"/>
            <xsd:maxInclusive value="12"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:element>
      <xsd:element name="Day" minOccurs="0">
        <xsd:simpleType>
          <xsd:restriction base="xsd:integer">
            <xsd:minInclusive value="1"/>
            <xsd:maxInclusive value="31"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:element>
    </xsd:sequence>
    <xsd:anyAttribute processContents="lax"/>
  </xsd:complexType>
  <xsd:element name="GregorianDateTime" type="GregorianDateTimeType" substitutionGroup="GregorianDate"/>
  <xsd:complexType name="GregorianDateTimeType">
    <xsd:complexContent>
      <xsd:extension base="GregorianDateType">
        <xsd:sequence>
          <xsd:element name="Hours" minOccurs="0">
            <xsd:simpleType>
              <xsd:restriction base="xsd:integer">
                <xsd:minInclusive value="0"/>
                <xsd:maxInclusive value="23"/>
              </xsd:restriction>
            </xsd:simpleType>
          </xsd:element>
          <xsd:element name="Minutes" minOccurs="0">
            <xsd:simpleType>
              <xsd:restriction base="xsd:integer">
                <xsd:minInclusive value="0"/>
                <xsd:maxInclusive value="59"/>
              </xsd:restriction>
            </xsd:simpleType>
          </xsd:element>
          <xsd:element name="Seconds" minOccurs="0">
            <xsd:simpleType>
              <xsd:restriction base="xsd:decimal">
                <xsd:minInclusive value="0.0"/>
                <xsd:maxInclusive value="59.999"/>
              </xsd:restriction>
            </xsd:simpleType>
          </xsd:element>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="LineSegment" type="LineSegmentType" substitutionGroup="geom:customLineSegment"/>
  <xsd:complexType name="LineSegmentType">
    <xsd:complexContent>
      <xsd:extension base="geom:LineSegmentType"/>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="SurfaceEdge" type="SurfaceEdgeType"/>
  <xsd:complexType name="SurfaceEdgeType">
    <xsd:sequence>
      <xsd:element ref="extensions" minOccurs="0"/>
      <xsd:element name="Geometry" minOccurs="0" type="geom:PolylineType"/>
    </xsd:sequence>
    <xsd:anyAttribute processContents="lax"/>
  </xsd:complexType>
  <xsd:element name="SurfaceBoundary" type="SurfaceBoundaryType"/>
  <xsd:complexType name="SurfaceBoundaryType">
    <xsd:sequence>
      <xsd:element ref="extensions" minOccurs="0"/>
      <xsd:element name="Lines" maxOccurs="unbounded">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element ref="SurfaceEdge"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
    </xsd:sequence>
    <xsd:anyAttribute processContents="lax"/>
  </xsd:complexType>
  <xsd:element name="LineGeometry" type="LineGeometryType"/>
  <xsd:complexType name="LineGeometryType">
    <xsd:sequence>
      <xsd:element ref="extensions" minOccurs="0"/>
      <xsd:element name="Segments" type="geom:LineSegmentType" maxOccurs="unbounded"/>
    </xsd:sequence>
    <xsd:anyAttribute processContents="lax"/>
  </xsd:complexType>
</xsd:schema>

Appendix C: Das XML-Schema für Geometrie-Typen (normativ)

Das folgende XML-Schema definiert Basistypen für Geometrie-Typen.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.interlis.ch/geometry/1.0" targetNamespace="http://www.interlis.ch/geometry/1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="2014-08-15">
  <xsd:element name="extensions">
    <xsd:annotation>
      <xsd:documentation>any vendor specifics</xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:attribute name="epsg" type="xsd:string"/>
  <xsd:element name="geometry" type="GeometryType"/>
  <xsd:complexType name="GeometryType" abstract="true">
    <xsd:sequence>
      <xsd:element ref="extensions" minOccurs="0"/>
    </xsd:sequence>
    <xsd:attribute ref="epsg" use="optional"/>
    <xsd:anyAttribute processContents="lax"/>
  </xsd:complexType>
  <xsd:element name="coord" type="CoordType" substitutionGroup="geometry"/>
  <xsd:complexType name="CoordType">
    <xsd:complexContent>
      <xsd:extension base="GeometryType">
        <xsd:sequence>
          <xsd:element name="c1" type="xsd:double" minOccurs="1" maxOccurs="1"/>
          <xsd:element name="c2" type="xsd:double" minOccurs="1" maxOccurs="1"/>
          <xsd:element name="c3" type="xsd:double" minOccurs="0" maxOccurs="1"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="multicoord" type="MultiCoordType"/>
  <xsd:complexType name="MultiCoordType">
    <xsd:sequence>
      <xsd:element ref="coord" minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="customLineSegment" type="LineSegmentType"/>
  <xsd:complexType name="LineSegmentType" abstract="true">
    <xsd:sequence>
      <xsd:element ref="extensions" minOccurs="0"/>
      <xsd:element name="c1" type="xsd:double" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="c2" type="xsd:double" minOccurs="1" maxOccurs="1"/>
      <xsd:element name="c3" type="xsd:double" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>
    <xsd:anyAttribute processContents="lax"/>
  </xsd:complexType>
  <xsd:complexType name="StartSegmentType">
    <xsd:complexContent>
      <xsd:extension base="LineSegmentType">
        <xsd:sequence> </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:complexType name="StraightSegmentType">
    <xsd:complexContent>
      <xsd:extension base="LineSegmentType">
        <xsd:sequence> </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:complexType name="ArcSegmentType">
    <xsd:complexContent>
      <xsd:extension base="LineSegmentType">
        <xsd:sequence>
          <xsd:element name="a1" type="xsd:double" minOccurs="1" maxOccurs="1"/>
          <xsd:element name="a2" type="xsd:double" minOccurs="1" maxOccurs="1"/>
          <xsd:element name="r" type="xsd:double" minOccurs="0" maxOccurs="1"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="polyline" type="PolylineType" substitutionGroup="geometry"/>
  <xsd:complexType name="PolylineType">
    <xsd:complexContent>
      <xsd:extension base="GeometryType">
        <xsd:sequence>
          <xsd:element ref="coord" minOccurs="1" maxOccurs="1"/>
          <xsd:choice minOccurs="1" maxOccurs="unbounded">
            <xsd:element ref="coord" minOccurs="1" maxOccurs="1"/>
            <xsd:element name="arc" type="ArcSegmentType" minOccurs="1" maxOccurs="1"/>
            <xsd:element ref="customLineSegment" minOccurs="1" maxOccurs="1"/>
          </xsd:choice>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="multipolyline" type="MultiPolylineType"/>
  <xsd:complexType name="MultiPolylineType">
    <xsd:sequence>
      <xsd:element ref="polyline" minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="BoundaryType">
    <xsd:sequence>
      <xsd:element ref="polyline" minOccurs="1"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="surface" type="SurfaceType" substitutionGroup="geometry"/>
  <xsd:complexType name="SurfaceType">
    <xsd:complexContent>
      <xsd:extension base="GeometryType">
        <xsd:sequence>
          <xsd:element name="exterior" type="BoundaryType" minOccurs="1" maxOccurs="unbounded"/>
          <xsd:element name="interior" type="BoundaryType" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <xsd:element name="multisurface" type="MultiSurfaceType"/>
  <xsd:complexType name="MultiSurfaceType">
    <xsd:sequence>
      <xsd:element ref="surface" minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>

Appendix D: Zeichentabelle (normativ)

Mit der hier aufgeführten Tabelle werden alle Zeichen genannt, die eine Software verarbeiten können muss (wie z.B. speichern, suchen, sortieren, ausdrucken), sofern beim Modell keine explizite Angabe erfolgt (vgl. Kapitel 3.5 Modelle, Themen, Klassen). Kommen im Transfer Zeichen vor, die nicht im beim Modell definierten Zeichensatz vorkommen, werden diese durch die Software stillschweigend (oder mit Hinweis; aber ohne Fehlermeldung) durch ein Ersatzzeichen ersetzt.

Für einige Zeichen stehen in XML mehrere Codierungsformen zur Verfügung. In diesem Fall sind die gängigen Codierungsformen des Zeichens angegeben. Bei mehreren Codierungsmöglichkeiten pro Zeichen kann ein INTERLIS 2 Schreibprogramm eine der möglichen Codierungsformen frei auswählen. Ein INTERLIS 2-Leseprogramm muss alle Zeichen und alle möglichen Codierungsformen eines Zeichens erkennen.

Die Tabelle gilt nur für XML-Content (d.h. XML-String, XML-NormalizedString bzw. XML-Value). XML-Tags werden ausschliesslich als ASCII-codierte Zeichen gemäss Syntax aus Kapitel 4, Sequentieller Transfer übertragen.

Tabulator (TAB, #x9), Wagenrücklauf (CR, #xD) und Zeilenvorschub (LF, #xA) sind die einzigen zugelassenen Steuerzeichen. Sie dürfen allerdings nur im Rahmen der Codierung von MTEXT (vgl. Kapitel 3.2.3, “Zeichenketten” und Kapitel 4.3.11.2, “Codierung von Zeichenketten”) vorkommen.

Tabelle 2. In INTERLIS 2 standardmässig zu unterstützende UCS/Unicode-Zeichen und deren Codierung.
UCS Hex	UCS Dez	UTF-8 Codierung (Octet Hex)	XML Char Ref Dez	XML Char Ref Hex	XML Entity Ref	Darstellung
0020	32	20				[space]
0021	33	21				!
0022	34	22	"	"	"	"
0023	35	23				#
0024	36	24				$
0025	37	25				%
0026	38	26	&	&	&	&
0027	39	27	'	'	'	'
0028	40	28				(
0029	41	29				)
002A	42	2A				*
002B	43	2B				+
002C	44	2C				,
002D	45	2D				-
002E	46	2E				.
002F	47	2F				/
0030	48	30				0
0031	49	31				1
0032	50	32				2
0033	51	33				3
0034	52	34				4
0035	53	35				5
0036	54	36				6
0037	55	37				7
0038	56	38				8
0039	57	39				9
003A	58	3A				:
003B	59	3B				;
003C	60	3C	<	<	<	<
003D	61	3D				=
003E	62	3E	>	>	>	>
003F	63	3F				?
0040	64	40				@
0041	65	41				A
0042	66	42				B
0043	67	43				C
0044	68	44				D
0045	69	45				E
0046	70	46				F
0047	71	47				G
0048	72	48				H
0049	73	49				I
004A	74	4A				J
004B	75	4B				K
004C	76	4C				L
004D	77	4D				M
004E	78	4E				N
004F	79	4F				O
0050	80	50				P
0051	81	51				Q
0052	82	52				R
0053	83	53				S
0054	84	54				T
0055	85	55				U
0056	86	56				V
0057	87	57				W
0058	88	58				X
0059	89	59				Y
005A	90	5A				Z
005B	91	5B				[
005C	92	5C				\
005D	93	5D				]
005E	94	5E				^
005F	95	5F				_
0060	96	60				`
0061	97	61				a
0062	98	62				b
0063	99	63				c
0064	100	64				d
0065	101	65				e
0066	102	66				f
0067	103	67				g
0068	104	68				h
0069	105	69				i
006A	106	6A				j
006B	107	6B				k
006C	108	6C				l
006D	109	6D				m
006E	110	6E				n
006F	111	6F				o
0070	112	70				p
0071	113	71				q
0072	114	72				r
0073	115	73				s
0074	116	74				t
0075	117	75				u
0076	118	76				v
0077	119	77				w
0078	120	78				x
0079	121	79				y
007A	122	7A				z
007B	123	7B				{
007C	124	7C				\|
007D	125	7D				}
007E	126	7E				~
00A3	163	C2 A3	£	£		£
00A7	167	C2 A7	§	§		§
00AB	171	C2 AB	«	«		«
00BB	187	C2 BB	»	»		»
00C0	192	C3 80	À	À		À
00C1	193	C3 81	Á	Á		Á
00C2	194	C3 82	Â	Â		Â
00C3	195	C3 83	Ã	Ã		Ã
00C4	196	C3 84	Ä	Ä		Ä
00C5	197	C3 85	Å	Å		Å
00C6	198	C3 86	Æ	Æ		Æ
00C7	199	C3 87	Ç	Ç		Ç
00C8	200	C3 88	È	È		È
00C9	201	C3 89	É	É		É
00CA	202	C3 8A	Ê	Ê		Ê
00CB	203	C3 8B	Ë	Ë		Ë
00CC	204	C3 8C	Ì	Ì		Ì
00CD	205	C3 8D	Í	Í		Í
00CE	206	C3 8E	Î	Î		Î
00CF	207	C3 8F	Ï	Ï		Ï
00D0	208	C3 90	Ð	Ð		Ð
00D1	209	C3 91	Ñ	Ñ		Ñ
00D2	210	C3 92	Ò	Ò		Ò
00D3	211	C3 93	Ó	Ó		Ó
00D4	212	C3 94	Ô	Ô		Ô
00D5	213	C3 95	Õ	Õ		Õ
00D6	214	C3 96	Ö	Ö		Ö
00D8	216	C3 98	Ø	Ø		Ø
00D9	217	C3 99	Ù	Ù		Ù
00DA	218	C3 9A	Ú	Ú		Ú
00DB	219	C3 9B	Û	Û		Û
00DC	220	C3 9C	Ü	Ü		Ü
00DD	221	C3 9D	Ý	Ý		Ý
00DE	222	C3 9E	Þ	Þ		Þ
00DF	223	C3 9F	ß	ß		ß
00E0	224	C3 A0	à	à		à
00E1	225	C3 A1	á	á		á
00E2	226	C3 A2	â	â		â
00E3	227	C3 A3	ã	ã		ã
00E4	228	C3 A4	ä	ä		ä
00E5	229	C3 A5	å	å		å
00E6	230	C3 A6	æ	æ		æ
00E7	231	C3 A7	ç	ç		ç
00E8	232	C3 A8	è	è		è
00E9	233	C3 A9	é	é		é
00EA	234	C3 AA	ê	ê		ê
00EB	235	C3 AB	ë	ë		ë
00EC	236	C3 AC	ì	ì		ì
00ED	237	C3 AD	í	í		í
00EE	238	C3 AE	î	î		î
00EF	239	C3 AF	ï	ï		ï
00F0	240	C3 B0	ð	ð		ð
00F1	241	C3 B1	ñ	ñ		ñ
00F2	242	C3 B2	ò	ò		ò
00F3	243	C3 B3	ó	ó		ó
00F4	244	C3 B4	ô	ô		ô
00F5	245	C3 B5	õ	õ		õ
00F6	246	C3 B6	ö	ö		ö
00F8	248	C3 B8	ø	ø		ø
00F9	249	C3 B9	ù	ù		ù
00FA	250	C3 BA	ú	ú		ú
00FB	251	C3 BB	û	û		û
00FC	252	C3 BC	ü	ü		ü
00FD	253	C3 BD	ý	ý		ý
00FE	254	C3 BE	þ	þ		þ
00FF	255	C3 BF	ÿ	ÿ		ÿ
20AC	8364	E2 82 AC	€	€		€

Bemerkungen:

In den Kolonnen UCS/Hex bzw. UCS/Dezimal ist der UCS (bzw. Unicode) Code des Zeichens angegeben (hexadezimal bzw. dezimal).
In der Kolonne UTF-8 Codierung ist die Codierung des Zeichens nach UTF-8 als 8bit Bytes (Octet) in hexadezimaler Schreibweise angegeben. Die Zeichen >= Hex 80 werden als Mehrbytefolgen codiert. Bemerkung: Die hexadezimale Schreibweise wird hier nur für die Erläuterung der Codierung benutzt. Auf dem Transfer werden nur die binär codierten Octete übertragen.
In der Kolonnen XML Codierung Character Reference (Dez) bzw. Character Reference (Hex) ist die Codierung des Zeichens als XML Character Reference angegeben (dezimale bzw. hexadezimale Variante). Der Wert ist eine ASCII-Zeichenfolge und muss genau so im Transfer verwendet werden. Falls möglich, sollte ein Schreibprogramm die Character Reference Codierung für das Zeichen wählen. Die Character Reference Codierung hat den Vorteil, dass sie auf allen Plattformen (Unix, PC, etc.) bzw. mit einfachen ASCII-Editoren angezeigt bzw. editiert werden kann. Bemerkung: Bei der hexadezimalen Codierungsvariante können die Buchstaben a-f in Gross- oder Kleinschrift angegeben werden (das x in der hexadezimalen Variante muss jedoch immer klein sein).
Die XML Codierung (Entity Reference) ist nur für wenige Spezialzeichen erlaubt. Der Wert ist eine ASCII-Zeichenfolge, welche genau so im Transfer verwendet werden muss. Bemerkung: XML-Entities wie ü (für Zeichen ü) sind in einer INTERLIS 2-Transferdatei nicht erlaubt, weil von einer INTERLIS 2-Transferdatei kein DTD referenziert wird (die benutzbaren Entities wie z.B.: & sind durch die XML 1.0 Spezifikation vordefiniert).
In der Kolonne Darstellung ist die Darstellung des Zeichens in einem UCS- bzw. Unicode kompatiblen Editor angegeben.

Appendix E: Das kleine Beispiel Roads (informativ)

Einleitung

Zum leichteren Einstieg in INTERLIS 2 ist hier ein kleines aber vollständiges Beispiel zusammengestellt. Dieses Beispiel beschreibt einen Datensatz, der für einen vollständigen Datentransfer (FULL) ausgelegt worden ist. Für Anwendungsbeispiele mit inkrementeller Nachlieferung (inkl. OID) werden entsprechende Beispieldatensätze und Benutzerhandbücher zur Verfügung gestellt.

Das Beispiel besteht aus folgenden Teilen:

Den Datenmodellen RoadsExdm2ben und RoadsExdm2ien.
Dem XML-Datensatz RoadsExdm2ien (Datei RoadsExdm2ien.xtf) welcher Objekte gemäss dem Datenmodell RoadsExdm2ien enthält.
Dem Grafikmodell RoadsExgm2ien. Im Grafikmodell ist eine mögliche Darstellung zum Datenmodell RoadsExdm2ien definiert (Bemerkung: zum gleichen Datenmodell sind beliebig viele Darstellungen möglich).
Einer Sammlung von Signaturobjekten (Signaturenbibliothek) in RoadsExgm2ien_Symbols (Datei RoadsExgm2ien_Symbols.xtf). Die Signaturenbibliothek ist ein XML-Datensatz gemäss dem Signaturenmodell StandardSymbology (vgl. Anhang L Signaturenmodelle). Die Signaturenbibliothek wird im Grafikmodell RoadsExgm2ien für die Darstellung der Beispieldaten aus dem RoadsExdm2ien.xtf-Datensatz benutzt. Der Name "RoadsExdm2ben" ist eine Abkürzung von «Roads Example, data model, INTERLIS 2, basic model, english». Die einzelnen Teile sind im Folgenden näher beschrieben.

Abbildung 26. UML-Klassendiagramm der Datenmodelle

Datenmodelle RoadsExdm2ben und RoadsExdm2ien

Im Datenmodell RoadsExdm2ben sind die Objekte LandCover (Bodenbedeckungsflächen), StreetAxis (Strassenachsen), StreetName (Strassennamen) und PointObject (Punktobjekte) enthalten. Das Datenmodell RoadsExdm2ien ist eine Erweiterung von RoadsExdm2ben. Die Datenmodelle sind im UML-Klassendiagramm übersichtsmässig zusammengestellt.

Bemerkung: Das Beispiel ist bewusst sehr einfach gehalten und erhebt daher keinerlei Anspruch auf Vollständigkeit. Die zugehörigen in INTERLIS 2 beschriebenen Modelle lauten wie folgt:

!! File RoadsExdm2ben.ili Release 2014-07-09
INTERLIS 2.4;

MODEL RoadsExdm2ben (en) AT "http://www.interlis.ch/models/refhb24"
  VERSION "2014-07-09" =

  UNIT
    Angle_Degree = 180 / PI [INTERLIS.rad];
  END UNIT;

  DOMAIN
    Point2D = COORD
      0.000 .. 200.000 [INTERLIS.m], !! Min_East Max_East
      0.000 .. 200.000 [INTERLIS.m]  !! Min_North Max_North
      ROTATION 2 -> 1;

    Orientation = 0.0 .. 359.9 CIRCULAR [Angle_Degree];
  END DOMAIN;

  TOPIC Roads =

    CLASS LandCover =
      Type: MANDATORY (
        building,
        street,
        water,
        other
      );

      Geometry: MANDATORY SURFACE WITH (STRAIGHTS)
        VERTEX Point2D WITHOUT OVERLAPS > 0.100;
    END LandCover;

    CLASS Street =
      Name: MANDATORY TEXT*32;
    END Street;

    CLASS StreetAxis =
      Geometry: MANDATORY POLYLINE WITH (STRAIGHTS)
        VERTEX Point2D;
    END StreetAxis;

    ASSOCIATION StreetAxisAssoc =
      Street -- {1} Street;
      StreetAxis -- StreetAxis;
    END StreetAxisAssoc;

    CLASS StreetNamePosition =
      NamPos: MANDATORY Point2D;
      NamOri: MANDATORY Orientation;
    END StreetNamePosition;

    ASSOCIATION StreetNamePositionAssoc =
      Street -- {0..1} Street;
      StreetNamePosition -- StreetNamePosition;
    END StreetNamePositionAssoc;

    CLASS RoadSign =
      Type: MANDATORY (
        prohibition,
        indication,
        danger,
        velocity
      );
      Position: MANDATORY Point2D;
    END RoadSign;

  END Roads; !! of TOPIC

END RoadsExdm2ben. !! of MODEL


!! File RoadsExdm2ien.ili Release 2014-07-09
INTERLIS 2.4;

MODEL RoadsExdm2ien (en) AT "http://www.interlis.ch/models/refhb24"
  VERSION "2014-07-09" =

  IMPORTS RoadsExdm2ben;

  TOPIC RoadsExtended EXTENDS RoadsExdm2ben.Roads =

    CLASS StreetAxis (EXTENDED) =
      Precision: MANDATORY (
        precise,
        unprecise
      );
    END StreetAxis;

    CLASS RoadSign (EXTENDED) =
      Type (EXTENDED): (
        prohibition (
          noentry,
          noparking,
          other
        )
      );
    END RoadSign;

  END RoadsExtended; !! of TOPIC

END RoadsExdm2ien. !! of MODEL

Datensatz RoadsExdm2ien gemäss Datenmodell RoadsExdm2ien

Nachfolgend ist ein Beispieldatensatz zum Datenmodell RoadsExdm2ien angegeben. Die XML-Formatierung wurde über die Regeln gemäss Kapitel 4, Sequentieller Transfer aus dem Datenmodell RoadsExdm2ien hergeleitet.

<?xml version="1.0" encoding="UTF-8"?>
<ili:transfer xmlns:ili="http://www.interlis.ch/xtf/2.4/INTERLIS" xmlns:geom="http://www.interlis.ch/geometry/1.0" xmlns:roads="http://www.interlis.ch/xtf/2.4/RoadsExdm2ben" xmlns="http://www.interlis.ch/xtf/2.4/RoadsExdm2ien" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <ili:headersection>
    <ili:models>
      <ili:model>RoadsExdm2ien</ili:model>
    </ili:models>
    <ili:sender>KOGIS</ili:sender>
    <ili:comment>example dataset ili2 refmanual appendix C</ili:comment>
  </ili:headersection>
  <ili:datasection>
    <RoadsExtended ili:bid="REFHANDB00000001">
      <!-- === LandCover === -->
      <roads:LandCover ili:tid="16">
        <roads:Type>water</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>39.038</geom:c1>
                  <geom:c2>60.315</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>41.200</geom:c1>
                  <geom:c2>59.302</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>43.362</geom:c1>
                  <geom:c2>60.315</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>44.713</geom:c1>
                  <geom:c2>66.268</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>45.794</geom:c1>
                  <geom:c2>67.662</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>48.766</geom:c1>
                  <geom:c2>67.408</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>53.360</geom:c1>
                  <geom:c2>64.115</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>56.197</geom:c1>
                  <geom:c2>62.595</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>57.818</geom:c1>
                  <geom:c2>63.862</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>58.899</geom:c1>
                  <geom:c2>68.928</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>55.927</geom:c1>
                  <geom:c2>72.348</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>47.955</geom:c1>
                  <geom:c2>75.515</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>42.281</geom:c1>
                  <geom:c2>75.388</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>39.308</geom:c1>
                  <geom:c2>73.235</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>36.741</geom:c1>
                  <geom:c2>69.688</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>35.525</geom:c1>
                  <geom:c2>66.268</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>35.661</geom:c1>
                  <geom:c2>63.735</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>37.957</geom:c1>
                  <geom:c2>61.455</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>39.038</geom:c1>
                  <geom:c2>60.315</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <roads:LandCover ili:tid="18">
        <roads:Type>building</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>101.459</geom:c1>
                  <geom:c2>65.485</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>108.186</geom:c1>
                  <geom:c2>69.369</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>102.086</geom:c1>
                  <geom:c2>79.936</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>95.359</geom:c1>
                  <geom:c2>76.053</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>101.459</geom:c1>
                  <geom:c2>65.485</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <roads:LandCover ili:tid="20">
        <roads:Type>building</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>60.489</geom:c1>
                  <geom:c2>49.608</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>79.900</geom:c1>
                  <geom:c2>55.839</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>75.351</geom:c1>
                  <geom:c2>70.932</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>67.678</geom:c1>
                  <geom:c2>68.781</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>69.938</geom:c1>
                  <geom:c2>61.721</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>57.582</geom:c1>
                  <geom:c2>58.029</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>60.489</geom:c1>
                  <geom:c2>49.608</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <roads:LandCover ili:tid="22">
        <roads:Type>street</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>45.067</geom:c1>
                  <geom:c2>58.655</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>50.669</geom:c1>
                  <geom:c2>42.579</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>57.060</geom:c1>
                  <geom:c2>44.638</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>51.432</geom:c1>
                  <geom:c2>60.469</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>45.067</geom:c1>
                  <geom:c2>58.655</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <roads:LandCover ili:tid="24">
        <roads:Type>other</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>114.027</geom:c1>
                  <geom:c2>99.314</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>31.351</geom:c1>
                  <geom:c2>99.314</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>31.140</geom:c1>
                  <geom:c2>92.530</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>70.419</geom:c1>
                  <geom:c2>86.177</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>86.481</geom:c1>
                  <geom:c2>79.710</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>114.027</geom:c1>
                  <geom:c2>99.314</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <roads:LandCover ili:tid="26">
        <roads:Type>other</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>113.559</geom:c1>
                  <geom:c2>62.880</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>114.027</geom:c1>
                  <geom:c2>99.314</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>86.481</geom:c1>
                  <geom:c2>79.710</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>94.381</geom:c1>
                  <geom:c2>66.289</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>96.779</geom:c1>
                  <geom:c2>57.177</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>113.559</geom:c1>
                  <geom:c2>62.880</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
            <geom:interior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>108.186</geom:c1>
                  <geom:c2>69.369</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>101.459</geom:c1>
                  <geom:c2>65.485</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>95.359</geom:c1>
                  <geom:c2>76.053</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>102.086</geom:c1>
                  <geom:c2>79.936</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>108.186</geom:c1>
                  <geom:c2>69.369</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:interior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <roads:LandCover ili:tid="29">
        <roads:Type>street</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>100.621</geom:c1>
                  <geom:c2>24.239</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>109.729</geom:c1>
                  <geom:c2>24.239</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>105.640</geom:c1>
                  <geom:c2>48.068</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>96.779</geom:c1>
                  <geom:c2>45.088</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>100.621</geom:c1>
                  <geom:c2>24.239</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <roads:LandCover ili:tid="31">
        <roads:Type>other</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>30.900</geom:c1>
                  <geom:c2>24.478</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>100.621</geom:c1>
                  <geom:c2>24.239</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>96.779</geom:c1>
                  <geom:c2>45.088</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>30.900</geom:c1>
                  <geom:c2>24.478</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <roads:LandCover ili:tid="33">
        <roads:Type>other</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>31.110</geom:c1>
                  <geom:c2>83.750</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>31.140</geom:c1>
                  <geom:c2>36.458</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>50.669</geom:c1>
                  <geom:c2>42.579</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>45.067</geom:c1>
                  <geom:c2>58.655</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>51.432</geom:c1>
                  <geom:c2>60.469</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>57.060</geom:c1>
                  <geom:c2>44.638</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>87.839</geom:c1>
                  <geom:c2>54.138</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>85.282</geom:c1>
                  <geom:c2>63.410</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>78.847</geom:c1>
                  <geom:c2>73.433</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>67.549</geom:c1>
                  <geom:c2>77.788</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>31.110</geom:c1>
                  <geom:c2>83.750</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
            <geom:interior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>41.200</geom:c1>
                  <geom:c2>59.302</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>39.038</geom:c1>
                  <geom:c2>60.315</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>37.957</geom:c1>
                  <geom:c2>61.455</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>35.661</geom:c1>
                  <geom:c2>63.735</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>35.525</geom:c1>
                  <geom:c2>66.268</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>36.741</geom:c1>
                  <geom:c2>69.688</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>39.308</geom:c1>
                  <geom:c2>73.235</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>42.281</geom:c1>
                  <geom:c2>75.388</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>47.955</geom:c1>
                  <geom:c2>75.515</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>55.927</geom:c1>
                  <geom:c2>72.348</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>58.899</geom:c1>
                  <geom:c2>68.928</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>57.818</geom:c1>
                  <geom:c2>63.862</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>56.197</geom:c1>
                  <geom:c2>62.595</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>53.360</geom:c1>
                  <geom:c2>64.115</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>48.766</geom:c1>
                  <geom:c2>67.408</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>45.794</geom:c1>
                  <geom:c2>67.662</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>44.713</geom:c1>
                  <geom:c2>66.268</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>43.362</geom:c1>
                  <geom:c2>60.315</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>41.200</geom:c1>
                  <geom:c2>59.302</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:interior>
            <geom:interior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>79.900</geom:c1>
                  <geom:c2>55.839</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>60.489</geom:c1>
                  <geom:c2>49.608</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>57.582</geom:c1>
                  <geom:c2>58.029</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>69.938</geom:c1>
                  <geom:c2>61.721</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>67.678</geom:c1>
                  <geom:c2>68.781</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>75.351</geom:c1>
                  <geom:c2>70.932</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>79.900</geom:c1>
                  <geom:c2>55.839</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:interior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <roads:LandCover ili:tid="37">
        <roads:Type>street</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>31.140</geom:c1>
                  <geom:c2>92.530</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>31.110</geom:c1>
                  <geom:c2>83.750</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>67.549</geom:c1>
                  <geom:c2>77.788</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>78.847</geom:c1>
                  <geom:c2>73.433</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>85.282</geom:c1>
                  <geom:c2>63.410</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>87.839</geom:c1>
                  <geom:c2>54.138</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>96.779</geom:c1>
                  <geom:c2>57.177</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>94.381</geom:c1>
                  <geom:c2>66.289</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>86.481</geom:c1>
                  <geom:c2>79.710</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>70.419</geom:c1>
                  <geom:c2>86.177</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>31.140</geom:c1>
                  <geom:c2>92.530</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <roads:LandCover ili:tid="39">
        <roads:Type>other</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>113.811</geom:c1>
                  <geom:c2>51.168</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>105.640</geom:c1>
                  <geom:c2>48.068</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>109.729</geom:c1>
                  <geom:c2>24.239</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>114.269</geom:c1>
                  <geom:c2>24.017</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>113.811</geom:c1>
                  <geom:c2>51.168</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <roads:LandCover ili:tid="41">
        <roads:Type>street</roads:Type>
        <roads:Geometry>
          <geom:surface>
            <geom:exterior>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>105.640</geom:c1>
                  <geom:c2>48.068</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>113.811</geom:c1>
                  <geom:c2>51.168</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>113.559</geom:c1>
                  <geom:c2>62.880</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>96.779</geom:c1>
                  <geom:c2>57.177</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>87.839</geom:c1>
                  <geom:c2>54.138</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>57.060</geom:c1>
                  <geom:c2>44.638</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>50.669</geom:c1>
                  <geom:c2>42.579</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>31.140</geom:c1>
                  <geom:c2>36.458</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>30.900</geom:c1>
                  <geom:c2>24.478</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>96.779</geom:c1>
                  <geom:c2>45.088</geom:c2>
                </geom:coord>
                <geom:coord>
                  <geom:c1>105.640</geom:c1>
                  <geom:c2>48.068</geom:c2>
                </geom:coord>
              </geom:polyline>
            </geom:exterior>
          </geom:surface>
        </roads:Geometry>
      </roads:LandCover>
      <!-- === Street === -->
      <roads:Street ili:tid="1">
        <roads:Name>Austrasse</roads:Name>
      </roads:Street>
      <roads:Street ili:tid="2">
        <roads:Name>Eymattstrasse</roads:Name>
      </roads:Street>
      <roads:Street ili:tid="3">
        <roads:Name>Feldweg</roads:Name>
      </roads:Street>
      <roads:Street ili:tid="4">
        <roads:Name>Seeweg</roads:Name>
      </roads:Street>
      <!-- === StreetAxis / StreetAxisAssoc === -->
      <StreetAxis ili:tid="8">
        <roads:Geometry>
          <geom:polyline>
            <geom:coord>
              <geom:c1>55.600</geom:c1>
              <geom:c2>37.649</geom:c2>
            </geom:coord>
            <geom:coord>
              <geom:c1>15.573</geom:c1>
              <geom:c2>25.785</geom:c2>
            </geom:coord>
          </geom:polyline>
        </roads:Geometry>
        <roads:Street ili:ref="1"/>
        <Precision>precise</Precision>
      </StreetAxis>
      <StreetAxis ili:tid="9">
        <roads:Geometry>
          <geom:polyline>
            <geom:coord>
              <geom:c1>55.600</geom:c1>
              <geom:c2>37.649</geom:c2>
            </geom:coord>
            <geom:coord>
              <geom:c1>94.990</geom:c1>
              <geom:c2>50.109</geom:c2>
            </geom:coord>
          </geom:polyline>
        </roads:Geometry>
        <roads:Street ili:ref="1"/>
        <Precision>precise</Precision>
      </StreetAxis>
      <StreetAxis ili:tid="10">
        <roads:Geometry>
          <geom:polyline>
            <geom:coord>
              <geom:c1>94.990</geom:c1>
              <geom:c2>50.109</geom:c2>
            </geom:coord>
            <geom:coord>
              <geom:c1>101.099</geom:c1>
              <geom:c2>52.279</geom:c2>
            </geom:coord>
          </geom:polyline>
        </roads:Geometry>
        <roads:Street ili:ref="1"/>
        <Precision>precise</Precision>
      </StreetAxis>
      <StreetAxis ili:tid="11">
        <roads:Geometry>
          <geom:polyline>
            <geom:coord>
              <geom:c1>101.099</geom:c1>
              <geom:c2>52.279</geom:c2>
            </geom:coord>
            <geom:coord>
              <geom:c1>126.100</geom:c1>
              <geom:c2>62.279</geom:c2>
            </geom:coord>
          </geom:polyline>
        </roads:Geometry>
        <roads:Street ili:ref="1"/>
        <Precision>precise</Precision>
      </StreetAxis>
      <StreetAxis ili:tid="12">
        <roads:Geometry>
          <geom:polyline>
            <geom:coord>
              <geom:c1>94.990</geom:c1>
              <geom:c2>50.109</geom:c2>
            </geom:coord>
            <geom:coord>
              <geom:c1>89.504</geom:c1>
              <geom:c2>65.795</geom:c2>
            </geom:coord>
            <geom:coord>
              <geom:c1>83.594</geom:c1>
              <geom:c2>75.598</geom:c2>
            </geom:coord>
            <geom:coord>
              <geom:c1>71.774</geom:c1>
              <geom:c2>80.712</geom:c2>
            </geom:coord>
            <geom:coord>
              <geom:c1>11.423</geom:c1>
              <geom:c2>91.154</geom:c2>
            </geom:coord>
          </geom:polyline>
        </roads:Geometry>
        <roads:Street ili:ref="2"/>
        <Precision>precise</Precision>
      </StreetAxis>
      <StreetAxis ili:tid="13">
        <roads:Geometry>
          <geom:polyline>
            <geom:coord>
              <geom:c1>101.099</geom:c1>
              <geom:c2>52.279</geom:c2>
            </geom:coord>
            <geom:coord>
              <geom:c1>107.400</geom:c1>
              <geom:c2>14.603</geom:c2>
            </geom:coord>
          </geom:polyline>
        </roads:Geometry>
        <roads:Street ili:ref="3"/>
        <Precision>unprecise</Precision>
      </StreetAxis>
      <StreetAxis ili:tid="15">
        <roads:Geometry>
          <geom:polyline>
            <geom:coord>
              <geom:c1>55.600</geom:c1>
              <geom:c2>37.649</geom:c2>
            </geom:coord>
            <geom:coord>
              <geom:c1>49.359</geom:c1>
              <geom:c2>56.752</geom:c2>
            </geom:coord>
          </geom:polyline>
        </roads:Geometry>
        <roads:Street ili:ref="4"/>
        <Precision>unprecise</Precision>
      </StreetAxis>
      <!-- === StreetNamePosition / StreetNamePositionAssoc === -->
      <roads:StreetNamePosition ili:tid="5">
        <roads:NamPos>
          <geom:coord>
            <geom:c1>71.660</geom:c1>
            <geom:c2>45.231</geom:c2>
          </geom:coord>
        </roads:NamPos>
        <roads:NamOri>15.0</roads:NamOri>
        <roads:Street ili:ref="1"/>
      </roads:StreetNamePosition>
      <roads:StreetNamePosition ili:tid="6">
        <roads:NamPos>
          <geom:coord>
            <geom:c1>58.249</geom:c1>
            <geom:c2>85.081</geom:c2>
          </geom:coord>
        </roads:NamPos>
        <roads:NamOri>351.0</roads:NamOri>
        <roads:Street ili:ref="2"/>
      </roads:StreetNamePosition>
      <roads:StreetNamePosition ili:tid="7">
        <roads:NamPos>
          <geom:coord>
            <geom:c1>106.095</geom:c1>
            <geom:c2>33.554</geom:c2>
          </geom:coord>
        </roads:NamPos>
        <roads:NamOri>280.0</roads:NamOri>
        <roads:Street ili:ref="3"/>
      </roads:StreetNamePosition>
      <roads:StreetNamePosition ili:tid="14">
        <roads:NamPos>
          <geom:coord>
            <geom:c1>53.031</geom:c1>
            <geom:c2>51.367</geom:c2>
          </geom:coord>
        </roads:NamPos>
        <roads:NamOri>291.3</roads:NamOri>
        <roads:Street ili:ref="4"/>
      </roads:StreetNamePosition>
      <!-- === RoadSign === -->
      <RoadSign ili:tid="501">
        <roads:Type>prohibition.noparking</roads:Type>
        <roads:Position>
          <geom:coord>
            <geom:c1>69.389</geom:c1>
            <geom:c2>92.056</geom:c2>
          </geom:coord>
        </roads:Position>
      </RoadSign>
      <RoadSign ili:tid="502">
        <roads:Type>prohibition.noparking</roads:Type>
        <roads:Position>
          <geom:coord>
            <geom:c1>80.608</geom:c1>
            <geom:c2>88.623</geom:c2>
          </geom:coord>
        </roads:Position>
      </RoadSign>
      <RoadSign ili:tid="503">
        <roads:Type>prohibition.noparking</roads:Type>
        <roads:Position>
          <geom:coord>
            <geom:c1>58.059</geom:c1>
            <geom:c2>93.667</geom:c2>
          </geom:coord>
        </roads:Position>
      </RoadSign>
      <RoadSign ili:tid="504">
        <roads:Type>danger</roads:Type>
        <roads:Position>
          <geom:coord>
            <geom:c1>92.741</geom:c1>
            <geom:c2>38.295</geom:c2>
          </geom:coord>
        </roads:Position>
      </RoadSign>
    </RoadsExtended>
    <!-- end of basket REFHANDB00000001 -->
  </ili:datasection>
</ili:transfer>

Grafikbeschreibung RoadsExgm2ien

Zum Datenmodell wird eine Darstellung mit Hilfe der Grafikbeschreibung RoadsExgm2ien definiert. Das Grafikmodell lautet wie folgt:

!! File RoadsExgm2ien.ili Release 2014-07-09
INTERLIS 2.4;

MODEL RoadsExgm2ien (en) AT "http://www.interlis.ch/models/refhb24"
  VERSION "2014-07-09" = !! Roads graphics

  IMPORTS RoadsExdm2ben;
  IMPORTS RoadsExdm2ien;
  IMPORTS StandardSymbology;

  SIGN BASKET StandardSymbology ~ StandardSymbology.StandardSigns =
    OBJECTS OF SurfaceSign: Building, Street, Water, Other;
    OBJECTS OF PolylineSign: continuous, dotted;
    OBJECTS OF TextSign: Linefont_18;
    OBJECTS OF SymbolSign: NoParking, GP;
  END StandardSymbology;

  TOPIC Graphics =
    DEPENDS ON RoadsExdm2ben.Roads, RoadsExdm2ien.RoadsExtended;

    GRAPHIC Surface_Graphics
      BASED ON RoadsExdm2ien.RoadsExtended.LandCover =

        Building OF StandardSymbology.StandardSigns.SurfaceSign:
          WHERE Type == #building (
            Sign := {Building};
            Geometry := Geometry;
            Priority := 100
          );

        Street OF StandardSymbology.StandardSigns.SurfaceSign:
          WHERE Type == #street (
            Sign := {Street};
            Geometry := Geometry;
            Priority := 100
          );

        Water OF StandardSymbology.StandardSigns.SurfaceSign:
          WHERE Type == #water (
            Sign := {Water};
            Geometry := Geometry;
            Priority := 100
          );

        Other OF StandardSymbology.StandardSigns.SurfaceSign:
          WHERE Type == #other (
            Sign := {Other};
            Geometry := Geometry;
            Priority := 100
          );

    END Surface_Graphics;

    VIEW Surface_Boundary
      INSPECTION OF RoadsExdm2ien.RoadsExtended.LandCover -> Geometry;
    =
      ATTRIBUTE
        ALL OF LandCover;
    END Surface_Boundary;

    VIEW Surface_Boundary2
      INSPECTION OF Base ~ Surface_Boundary -> Lines;
    =
      ATTRIBUTE
        Geometry := Base -> Geometry;
    END Surface_Boundary2;

    GRAPHIC SurfaceBoundary_Graphics
      BASED ON Surface_Boundary2 =

        Boundary OF StandardSymbology.StandardSigns.PolylineSign: (
          Sign := {continuous};
          Geometry := Geometry;
          Priority := 101
        );

    END SurfaceBoundary_Graphics;

    GRAPHIC Polyline_Graphics
      BASED ON RoadsExdm2ien.RoadsExtended.StreetAxis =

        Street_precise OF StandardSymbology.StandardSigns.PolylineSign:
          WHERE Precision == #precise (
            Sign := {continuous};
            Geometry := Geometry;
            Priority := 110
          );

        Street_unprecise OF StandardSymbology.StandardSigns.PolylineSign:
          WHERE Precision == #unprecise (
            Sign := {dotted};
            Geometry := Geometry;
            Priority := 110
          );

    END Polyline_Graphics;

    GRAPHIC Text_Graphics
      BASED ON RoadsExdm2ien.RoadsExtended.StreetNamePosition =

        StreetName OF StandardSymbology.StandardSigns.TextSign: (
          Sign := {Linefont_18};
          Txt := Street -> Name;
          Geometry := NamPos;
          Rotation := NamOri;
          Priority := 120
        );

    END Text_Graphics;

    GRAPHIC Point_Graphics
      BASED ON RoadsExdm2ien.RoadsExtended.RoadSign =

        Tree OF StandardSymbology.StandardSigns.SymbolSign:
          WHERE Type == #prohibition.noparking (
            Sign := {NoParking};
            Geometry := Position;
            Priority := 130
          );

        GP OF StandardSymbology.StandardSigns.SymbolSign:
          WHERE Type == #danger (
            Sign := {GP};
            Geometry := Position;
            Priority := 130
          );

    END Point_Graphics;

  END Graphics;

END RoadsExgm2ien.

Das Grafikmodell RoadsExgm2ien greift auf Signaturen in der Signaturenbibliothek RoadsExgm2ien_Symbols (Datei RoadsExgm2ien_Symbols.xtf) zurück. Die Signaturenbibliothek ist im folgenden Abschnitt beschrieben.

Signaturenbibliothek RoadsExgm2ien_Symbols.xtf

Nachfolgend ist die Signaturenbibliothek RoadsExgm2ien_Symbols als XML-Datensatz dargestellt (Datei RoadsExgm2ien_Symbols.xtf). Die Signaturenbibliothek enthält Symboldefinitionen für Fixpunkte und Bäume, sowie Linien-, Textanschrift- und Flächensignaturen. Das zugehörige Signaturen-Datenmodell (StandardSymbology) ist im Appendix L, Signaturenmodelle (Standard-Erweiterungsvorschlag) enthalten.

<?xml version="1.0" encoding="UTF-8"?>
<ili:transfer xmlns:ili="http://www.interlis.ch/xtf/2.4/INTERLIS" xmlns:geom="http://www.interlis.ch/geometry/1.0" xmlns="http://www.interlis.ch/xtf/2.4/StandardSymbology" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <ili:headersection>
    <ili:models>
      <ili:model>StandardSymbology</ili:model>
    </ili:models>
    <ili:sender>KOGIS</ili:sender>
    <ili:comment>example symbology dataset ili2 refmanual appendix C</ili:comment>
  </ili:headersection>
  <ili:datasection>
    <StandardSigns ili:bid="REFHANDB00000002">
      <!-- Color Library -->
      <Color ili:tid="1">
        <Name>red</Name>
        <L>40.0</L>
        <C>70.0</C>
        <H>0.0</H>
        <T>1.0</T>
      </Color>
      <Color ili:tid="2">
        <Name>green</Name>
        <L>49.4</L>
        <C>48.5</C>
        <H>153.36</H>
        <T>1.0</T>
      </Color>
      <Color ili:tid="3">
        <Name>light_gray</Name>
        <L>75.0</L>
        <C>0.0</C>
        <H>0.0</H>
        <T>1.0</T>
      </Color>
      <Color ili:tid="4">
        <Name>dark_grey</Name>
        <L>25.0</L>
        <C>0.0</C>
        <H>0.0</H>
        <T>1.0</T>
      </Color>
      <Color ili:tid="5">
        <Name>dark_blue</Name>
        <L>50.3</L>
        <C>43.5</C>
        <H>261.1</H>
        <T>1.0</T>
      </Color>
      <Color ili:tid="6">
        <Name>black</Name>
        <L>0.0</L>
        <C>0.0</C>
        <H>0.0</H>
        <T>1.0</T>
      </Color>
      <Color ili:tid="7">
        <Name>white</Name>
        <L>100.0</L>
        <C>0.0</C>
        <H>0.0</H>
        <T>1.0</T>
      </Color>
      <PolylineAttrs ili:tid="4001">
        <Width>0.01</Width>
        <Join>round</Join>
        <Caps>butt</Caps>
      </PolylineAttrs>
      <PolylineAttrs ili:tid="4002">
        <Width>0.01</Width>
        <Join>miter</Join>
        <MiterLimit>2.0</MiterLimit>
        <Caps>butt</Caps>
      </PolylineAttrs>
      <!-- Font/Symbol Library -->
      <FontSymbol ili:tid="101">
        <Name>Triangle</Name>
        <Geometry>
          <FontSymbol_Surface>
            <Geometry>
              <geom:surface>
                <geom:exterior>
                  <geom:polyline>
                    <geom:coord>
                      <geom:c1>-0.5</geom:c1>
                      <geom:c2>-0.5</geom:c2>
                    </geom:coord>
                    <geom:coord>
                      <geom:c1>0.0</geom:c1>
                      <geom:c2>0.5</geom:c2>
                    </geom:coord>
                    <geom:coord>
                      <geom:c1>0.5</geom:c1>
                      <geom:c2>-0.5</geom:c2>
                    </geom:coord>
                    <geom:coord>
                      <geom:c1>-0.5</geom:c1>
                      <geom:c2>-0.5</geom:c2>
                    </geom:coord>
                  </geom:polyline>
                </geom:exterior>
              </geom:surface>
            </Geometry>
          </FontSymbol_Surface>
        </Geometry>
        <Geometry>
          <FontSymbol_Polyline>
            <Color ili:ref="6"/>
            <Geometry>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>-0.5</geom:c1>
                  <geom:c2>0.0</geom:c2>
                </geom:coord>
                <geom:arc>
                  <geom:c1>0.5</geom:c1>
                  <geom:c2>0.0</geom:c2>
                  <geom:a1>0.0</geom:a1>
                  <geom:a2>0.5</geom:a2>
                  <geom:r>0.5</geom:r>
                </geom:arc>
                <geom:arc>
                  <geom:c1>-0.5</geom:c1>
                  <geom:c2>0.0</geom:c2>
                  <geom:a1>0.0</geom:a1>
                  <geom:a2>-0.5</geom:a2>
                  <geom:r>0.5</geom:r>
                </geom:arc>
              </geom:polyline>
            </Geometry>
          </FontSymbol_Polyline>
        </Geometry>
        <Font ili:ref="10"/>
      </FontSymbol>
      <FontSymbol ili:tid="102">
        <Name>NoParking</Name>
        <Geometry>
          <FontSymbol_Polyline>
            <Color ili:ref="6"/>
            <Geometry>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>-0.5</geom:c1>
                  <geom:c2>0.0</geom:c2>
                </geom:coord>
                <geom:arc>
                  <geom:c1>0.5</geom:c1>
                  <geom:c2>0.0</geom:c2>
                  <geom:a1>0.0</geom:a1>
                  <geom:a2>0.5</geom:a2>
                  <geom:r>0.5</geom:r>
                </geom:arc>
                <geom:arc>
                  <geom:c1>-0.5</geom:c1>
                  <geom:c2>0.0</geom:c2>
                  <geom:a1>0.0</geom:a1>
                  <geom:a2>-0.5</geom:a2>
                  <geom:r>0.5</geom:r>
                </geom:arc>
              </geom:polyline>
            </Geometry>
          </FontSymbol_Polyline>
        </Geometry>
        <Geometry>
          <FontSymbol_Surface>
            <FillColor ili:ref="1"/>
            <Geometry>
              <geom:surface>
                <geom:exterior>
                  <geom:polyline>
                    <geom:coord>
                      <geom:c1>-0.233</geom:c1>
                      <geom:c2>0.325</geom:c2>
                    </geom:coord>
                    <geom:arc>
                      <geom:c1>0.325</geom:c1>
                      <geom:c2>-0.233</geom:c2>
                      <geom:a1>0.283</geom:a1>
                      <geom:a2>0.283</geom:a2>
                      <geom:r>0.4</geom:r>
                    </geom:arc>
                    <geom:coord>
                      <geom:c1>-0.233</geom:c1>
                      <geom:c2>0.325</geom:c2>
                    </geom:coord>
                  </geom:polyline>
                </geom:exterior>
              </geom:surface>
            </Geometry>
          </FontSymbol_Surface>
        </Geometry>
        <Geometry>
          <FontSymbol_Surface>
            <FillColor ili:ref="1"/>
            <Geometry>
              <geom:surface>
                <geom:exterior>
                  <geom:polyline>
                    <geom:coord>
                      <geom:c1>0.228</geom:c1>
                      <geom:c2>-0.324</geom:c2>
                    </geom:coord>
                    <geom:arc>
                      <geom:c1>-0.327</geom:c1>
                      <geom:c2>0.238</geom:c2>
                      <geom:a1>-0.283</geom:a1>
                      <geom:a2>-0.283</geom:a2>
                      <geom:r>0.4</geom:r>
                    </geom:arc>
                    <geom:coord>
                      <geom:c1>0.228</geom:c1>
                      <geom:c2>-0.324</geom:c2>
                    </geom:coord>
                  </geom:polyline>
                </geom:exterior>
              </geom:surface>
            </Geometry>
          </FontSymbol_Surface>
        </Geometry>
        <Geometry>
          <FontSymbol_Surface>
            <FillColor ili:ref="5"/>
            <Geometry>
              <geom:surface>
                <geom:exterior>
                  <geom:polyline>
                    <geom:coord>
                      <geom:c1>-0.5</geom:c1>
                      <geom:c2>0.0</geom:c2>
                    </geom:coord>
                    <geom:arc>
                      <geom:c1>0.5</geom:c1>
                      <geom:c2>0.0</geom:c2>
                      <geom:a1>0.0</geom:a1>
                      <geom:a2>0.5</geom:a2>
                      <geom:r>0.5</geom:r>
                    </geom:arc>
                    <geom:arc>
                      <geom:c1>-0.5</geom:c1>
                      <geom:c2>0.0</geom:c2>
                      <geom:a1>0.0</geom:a1>
                      <geom:a2>-0.5</geom:a2>
                      <geom:r>0.5</geom:r>
                    </geom:arc>
                  </geom:polyline>
                </geom:exterior>
                <geom:interior>
                  <geom:polyline>
                    <geom:coord>
                      <geom:c1>-0.233</geom:c1>
                      <geom:c2>0.325</geom:c2>
                    </geom:coord>
                    <geom:arc>
                      <geom:c1>0.325</geom:c1>
                      <geom:c2>-0.233</geom:c2>
                      <geom:a1>0.283</geom:a1>
                      <geom:a2>0.283</geom:a2>
                      <geom:r>0.4</geom:r>
                    </geom:arc>
                    <geom:coord>
                      <geom:c1>-0.233</geom:c1>
                      <geom:c2>0.325</geom:c2>
                    </geom:coord>
                  </geom:polyline>
                </geom:interior>
                <geom:interior>
                  <geom:polyline>
                    <geom:coord>
                      <geom:c1>0.228</geom:c1>
                      <geom:c2>-0.324</geom:c2>
                    </geom:coord>
                    <geom:arc>
                      <geom:c1>-0.327</geom:c1>
                      <geom:c2>0.238</geom:c2>
                      <geom:a1>-0.283</geom:a1>
                      <geom:a2>-0.283</geom:a2>
                      <geom:r>0.4</geom:r>
                    </geom:arc>
                    <geom:coord>
                      <geom:c1>0.228</geom:c1>
                      <geom:c2>-0.324</geom:c2>
                    </geom:coord>
                  </geom:polyline>
                </geom:interior>
              </geom:surface>
            </Geometry>
          </FontSymbol_Surface>
        </Geometry>
        <Geometry>
          <FontSymbol_Polyline>
            <Color ili:ref="7"/>
            <Geometry>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>-0.233</geom:c1>
                  <geom:c2>0.325</geom:c2>
                </geom:coord>
                <geom:arc>
                  <geom:c1>0.325</geom:c1>
                  <geom:c2>-0.233</geom:c2>
                  <geom:a1>0.283</geom:a1>
                  <geom:a2>0.283</geom:a2>
                  <geom:r>0.4</geom:r>
                </geom:arc>
                <geom:coord>
                  <geom:c1>-0.233</geom:c1>
                  <geom:c2>0.325</geom:c2>
                </geom:coord>
              </geom:polyline>
            </Geometry>
          </FontSymbol_Polyline>
        </Geometry>
        <Geometry>
          <FontSymbol_Polyline>
            <Color ili:ref="7"/>
            <Geometry>
              <geom:polyline>
                <geom:coord>
                  <geom:c1>0.228</geom:c1>
                  <geom:c2>-0.324</geom:c2>
                </geom:coord>
                <geom:arc>
                  <geom:c1>-0.327</geom:c1>
                  <geom:c2>0.238</geom:c2>
                  <geom:a1>-0.283</geom:a1>
                  <geom:a2>-0.283</geom:a2>
                  <geom:r>0.4</geom:r>
                </geom:arc>
                <geom:coord>
                  <geom:c1>0.228</geom:c1>
                  <geom:c2>-0.324</geom:c2>
                </geom:coord>
              </geom:polyline>
            </Geometry>
          </FontSymbol_Polyline>
        </Geometry>
        <Font ili:ref="10"/>
      </FontSymbol>
      <!-- Internal Symbol Font "Symbols" -->
      <Font ili:tid="10">
        <Name>Symbols</Name>
        <Internal>true</Internal>
        <Type>symbol</Type>
      </Font>
      <!-- External Text Font "Leroy" -->
      <Font ili:tid="11">
        <Name>Leroy</Name>
        <Internal>false</Internal>
        <Type>text</Type>
        <BottomBase>0.3</BottomBase>
      </Font>
      <!-- Line Styles -->
      <LineStyle_Solid ili:tid="21">
        <Name>LineSolid_01</Name>
        <Color ili:ref="6"/>
      </LineStyle_Solid>
      <LineStyle_Dashed ili:tid="22">
        <Name>LineDashed_01</Name>
        <Dashes>
          <DashRec>
            <DLength>0.1</DLength>
          </DashRec>
        </Dashes>
        <Dashes>
          <DashRec>
            <DLength>0.1</DLength>
          </DashRec>
        </Dashes>
        <Color ili:ref="6"/>
      </LineStyle_Dashed>
      <!-- Text Signs -->
      <TextSign ili:tid="1001">
        <ili:Name>Linefont_18</ili:Name>
        <Height>1.8</Height>
        <Font ili:ref="11"/>
      </TextSign>
      <!-- Symbol Signs -->
      <SymbolSign ili:tid="2001">
        <ili:Name>GP</ili:Name>
        <Scale>1.0</Scale>
        <Color ili:ref="2"/>
        <Symbol ili:ref="101"/>
      </SymbolSign>
      <SymbolSign ili:tid="2002">
        <ili:Name>NoParking</ili:Name>
        <Scale>1.0</Scale>
        <Symbol ili:ref="102"/>
      </SymbolSign>
      <!-- Polyline Signs -->
      <PolylineSign ili:tid="3001">
        <ili:Name>continuous</ili:Name>
        <Style ili:ref="21">
          <PolylineSignLineStyleAssoc>
            <Offset>0.0</Offset>
          </PolylineSignLineStyleAssoc>
        </Style>
      </PolylineSign>
      <PolylineSign ili:tid="3002">
        <ili:Name>dotted</ili:Name>
        <Style ili:ref="22">
          <PolylineSignLineStyleAssoc>
            <Offset>0.0</Offset>
          </PolylineSignLineStyleAssoc>
        </Style>
      </PolylineSign>
      <!-- Surface Signs -->
      <SurfaceSign ili:tid="5001">
        <ili:Name>Building</ili:Name>
        <FillColor ili:ref="4"/>
      </SurfaceSign>
      <SurfaceSign ili:tid="5002">
        <ili:Name>Street</ili:Name>
        <FillColor ili:ref="3"/>
      </SurfaceSign>
      <SurfaceSign ili:tid="5003">
        <ili:Name>Water</ili:Name>
        <FillColor ili:ref="5"/>
      </SurfaceSign>
      <SurfaceSign ili:tid="5005">
        <ili:Name>Other</ili:Name>
        <FillColor ili:ref="2"/>
      </SurfaceSign>
    </StandardSigns>
    <!-- end of basket REFHANDB00000002 -->
  </ili:datasection>
</ili:transfer>

Grafische Darstellung des Beispiels

Aus dem Datensatz RoadsExdm2ien (Datei RoadsExdm2ien.xtf), den Beschreibungen im Grafikmodell RoadsExgm2ien (Datei RoadsExgm2ien.ili) und der Signaturenbibliothek RoadsExgm2ien_Symbols (Datei RoadsExgm2ien_Symbols.xtf) erzeugt ein INTERLIS 2-Grafikprozessor folgende Grafik:

Abbildung 27. Grafik, erzeugt aus den Daten- und Grafikbeschreibungen.

Appendix F: Aufbau von Objektidentifikatoren (OID) (Standard-Erweiterungsvorschlag)

Vorbemerkung

Die folgende Spezifikation ist nicht normativer Bestandteil von INTERLIS. Dies ist ein Standard-Erweiterungsvorschlag auf der Basis des INTERLIS 2-Referenzhandbuches im Sinne einer Empfehlung. Es ist geplant, diesen Vorschlag nach einer breiten Diskussion in eine definitive Regelung umzuwandeln. Für Anwendungsbeispiele siehe auch die entsprechenden INTERLIS 2-Benutzerhandbücher.

Einleitung

Mit der immer grösseren Verfügbarkeit von Geodaten wird vermehrt auch deren Nachführung (Fortführung) und Integration in verschiedene Datenbanken verlangt. Dies sind einige Gründe für den Bedarf nach einer einheitlichen Regelung von Objektidentifikatoren (OID): Ein OID identifiziert eine Objektinstanz von deren Entstehung bis zu ihrem Untergang auch wenn die Attributwerte sich ändern. Im Gegensatz zu den Benutzerschlüsseln (vgl. Anhang G Eindeutigkeit von Benutzerschlüsseln im INTERLIS 2-Referenzhandbuch) ist der OID vom Anwender als «nicht-sprechendes» («opaques») Attribut zu betrachten, das typischerweise über Systemfunktionen verwaltet wird.

Ein OID muss zumindest innerhalb einer Transfergemeinschaft eindeutig, einmalig und unveränderbar sein.

An die Vergabe und die Nutzung von OID werden unter anderem folgende Anforderungen ge- stellt:

Der OID ist ein genereller und stabiler Identifikator, auch bei grossen Datenmengen. Als Identifikator ist er ein Attribut, dessen Wert ein Objekt in seiner Klasse eindeutig kennzeichnet Als genereller Identifikator hat sein Wert ein Objekt nicht nur in seiner Klasse, sondern innerhalb aller Klassen einer Transfergemeinschaft eindeutig zu kennzeichnen. Als stabiler Identifikator ist er ferner zeitunabhängig, d.h. während des Lebenszyklus eines Objektes darf er nicht verändert und der OID eines gelöschten Objektes nicht mehr verwendet werden.
Unabhängig von Hardware- und Softwareproduzenten.
Unabhängig von Plattformen.
Im Mehrplatz- als auch im Einzelplatz-Betrieb, bzw. in autonomen Systemen nutzbar (z.B. im Felde).
Wenig Platzbedarf und nach Bedarf optimierbar.
Einfach implementierbar.

Weitere Anforderungen sind nicht unbedingt technischer Art, wie z.B.: möglichst wenig Organisationsaufwand, Vergabe unter eigener (nationaler) Kontrolle, nutzbar auch mit älteren Systemen und Akzeptanz bei den Systemherstellern. Dies sind anspruchsvolle, teilweise entgegengesetzte Anforderungen. Eine spezielle Vorgabe ist, dass ein OID von einem Produzentensystem mindestens zehn Millionen Mal vergeben werden kann. Als weitere Vorgabe gelte, dass er eine feste Länge hat damit die Handhabung erleichtert wird (dies schliesst andere bekannte Verfahren, z.B. eine so genannte URI als Präfix aus). Eine Prüfziffer ist nicht vorzusehen: es wird angenommen, dass tiefere Kommunikationsebenen entsprechende Mittel bereitstellen.

Grundsätzlich wird die Eindeutigkeit eines OID immer über einen zentralen Mechanismus erreicht. Die zwei Extreme – d.h. die zentrale Vergabe jedes einzelnen OID auf der einen und die vollständig dezentrale, autonome Generierung von OID auf der anderen Seite – führen zu unbefriedigenden Lösungen. Einen OID, der z.B. über eine Netzwerkkartennummer und einen Zeitstempel vergeben wird, wird für nicht praktikabel und zukunftsweisend gehalten, zumal dann jedes Gerät eine Netzwerkkarte besitzen muss und nicht abzusehen ist, ob diese Technologie in den nächsten Jahren nicht durch andere Entwicklungen überholt wird.

Die Entstehung dieser Spezifikation hat eine lange Vorgeschichte. Es wurden über mehrere Jahre verschiedene Vernehmlassungen, Studien und Sitzungen durchgeführt. Ein Teil der dabei entstandenen Dokumente kann Interessierten abgegeben werden (Bestellung unter anderem auf www.interlis.ch, bzw. info@interlis.ch).

Aufbau des Objektidentifikators (OID)

Ein Objektidentifikator (OID) besteht aus einem Präfix- und einem Postfix-Anteil und hat als Gesamtheit eine Länge von 16 alphanumerischen Stellen in seiner darstellbaren Form. Der OID wird namentlich auf der Datenschnittstelle oder dem Anwender gegenüber immer als Einheit behandelt. Der OID-Wertebereich STANDARDOID des INTERLIS-Modells entspricht dieser Definition. Er definiert aber nur die Gesamtlänge und nicht den detaillierten Aufbau.

OIDDef = Prefix Postfix.

Präfix

Das Präfix wird von einer zentralen Stelle vergeben. Damit wird die Eindeutigkeit innerhalb einer Transfergemeinschaft gegeben. Typischerweise ist für jeden Behälter (z.B. ein Datenbank-Prozess, der Daten eines konkreten Themas verwaltet) ein neues Präfix erforderlich. Als Bestimmungsort für das Präfix gilt das Land des Präfix-erzeugenden Prozesses. Dieser Prozess ist nicht unbedingt am gleichen Ort wie das Produzentensystem, das den gesamten OID erzeugt.

Das Präfix besteht aus einer Folge von 8 Zeichen mit folgendem zulässigen Zeichenvorrat:

Prefix = Letter { Letter | Digit }. !! Folge von 8 Zeichen
Letter = ( 'A' | .. | 'Z' | 'a' | .. | 'z' ).
Digit = ( '0' | '1' | .. | '9' ).

Ein Präfix ist demnach definiert als eine Folge von Buchstaben und Ziffern, wobei das erste Zeichen ein Buchstabe sein muss (s. auch den Aufbau von XML-Tag-Namen oder das Kapitel Na- men im INTERLIS 2-Referenzhandbuch).

Weiter gilt die Regelung, dass die ersten zwei Präfix-Stellen gemäss der ISO-Norm 3166 festgelegt werden. Für in Deutschland, in Österreich oder der Schweiz erzeugte Präfixe sind dort z.B. die Buchstaben «de", «at» und «ch» festgelegt. Für die Erzeugung eines Präfixes stehen damit pro Stelle insgesamt 62 verschiedene Varianten zur Verfügung (0..9: ASCII 48 bis 57; A..Z: ASCII 65 bis 90; a..z: ASCII 97 bis 122). Die Kombination der 62 Zeichen mit der Anzahl Stellen ergibt eine Menge von OIDs, die wahrscheinlich grösser ist, als die meisten Anwendungen jemals benötigen.

Postfix

Ein Postfix wird durch den Datenproduzenten, bzw. das Produzentensystem selber verwaltet. Er besteht seinerseits aus einer Folge von 8 Zeichen. Durch den ASCII-kompatiblen, kolonnenorientierten Ansatz wird verlangt, dass die allenfalls "freien" Stellen links mit Nullen ("0") besetzt werden (siehe das erste und dritte Beispiel eines OID’s unten). Der kleinstmögliche Ordinalwert des Postfix-Anteils wird damit als "00000000" repräsentiert.

Postfix = { Letter | Digit }. !! Folge von 8 Zeichen

Weitere Einschränkungen des Präfix- oder Postfix-Anteils sind bei Bedarf in zusätzlichen Spezifikationen zu regeln.

Zusammenfassung und Anwendungsbeispiele

OID	Länge	Bedeutung	Bemerkungen
Präfix	2 + 6 Char.	Länderkennung + ein von einer zuständigen, zentralen Stelle einmalig vergebener „globaler“ Identifikations-Anteil	Weltweit eindeutige Länderkennung, z.B. de (Deutschland), at (Österreich), ch (Schweiz), entsprechend ISO-Norm 3166. Weitere Einschränkungen sind in zusätzlichen Spezifikationen zu regeln.
Postfix	8 Char.	Sequenz (numerisch oder alphanumerisch) des Produzentensystems als „lokaler“ Identifikations-Anteil	Weitere Einschränkungen, wie z.B. Zeitstempel mit Sequenznummer, sind in zusätzlichen Spezifikationen zu regeln.

OID

Länge

Bedeutung

Bemerkungen

Präfix

2 + 6 Char.

Länderkennung + ein von einer zuständigen, zentralen Stelle einmalig vergebener „globaler“ Identifikations-Anteil

Weltweit eindeutige Länderkennung, z.B. de (Deutschland), at (Österreich), ch (Schweiz), entsprechend ISO-Norm 3166. Weitere Einschränkungen sind in zusätzlichen Spezifikationen zu regeln.

Postfix

8 Char.

Sequenz (numerisch oder alphanumerisch) des Produzentensystems als „lokaler“ Identifikations-Anteil

Weitere Einschränkungen, wie z.B. Zeitstempel mit Sequenznummer, sind in zusätzlichen Spezifikationen zu regeln.

Beispiele von Formel-Ausdrücken:

A000000000000000    Theoretisch kleinstmöglicher OID
zwzzzzzzzzzzzzzz    Grösstmöglicher OID, mit zw für Zimbabwe
deg5mQXX2000004a    Willkürlich gewählter OID aus Deutschland (de)
chgAAAAAAAAA0azD    Willkürlich gewählter OID aus der Schweiz (ch)

Organisation

Eine zentrale Stelle (etwa eine Bundesstelle), die von der Transfergemeinschaft anerkannt wird, unterhält einen zentralen Dienst für die Vergabe von OID’s. Die Datenproduzenten können von dort einen oder mehrere Präfix-Anteile über geeignete Kommunikationskanäle beziehen. Dies könnte zum Beispiel eine Internet-Seite sein, die mit einem E-Mail-Dienst verbunden ist. Ein solcher Dienst kann relativ sicher gemacht und gegen Missbrauch geschützt werden.

Es ist den Implementationen in den Sender- und Empfängersystemen überlassen, die in dieser Spezifikation ausdrücklich genannten Eigenschaften auszunutzen und den OID z.B. zu Sortierzwecken zu verwenden oder um interne Optimierungen vorzunehmen. Eine solche Optimierung könnte z.B. darin bestehen, dass der Präfix-Anteil im System an einem zentralen Ort verwaltet wird und die verschiedenen Objekte nur den Postfix-Anteil enthalten und sich zusätzlich auf einen (gemeinsamen) Präfix-Anteil beziehen. Eine andere Sparmassnahme ist die systeminterne Speicherung des Postfix-Anteils in Binärcodierung.

Für Übungszwecke sind zu verwenden:

bei OID für Baskets der OID-Präfix "chB00000".
für alle andern OID der OID-Präfix "ch100000".

Appendix G: Eindeutigkeit von Benutzerschlüsseln (Standard-Erweiterungsvorschlag)

Bemerkung

Die folgende Spezifikation ist nicht normativer Bestandteil von INTERLIS. Dies ist ein Standard-Erweiterungsvorschlag auf der Basis des INTERLIS 2-Referenzhandbuches im Sinne einer Empfehlung. Es ist geplant, diesen Vorschlag nach einer breiten Diskussion in eine definitive Regelung umzuwandeln. Für Anwendungsbeispiele siehe auch die entsprechenden INTERLIS 2-Benutzerhandbücher.

Modellierungs-Alternativen

Wird von Benutzerschlüsseln verlangt, dass sie eindeutig sind, stellt sich immer Frage, in welchem Rahmen die Eindeutigkeit gilt. Rein technisch gesehen ist es häufig klar, dass die Eindeutigkeit nur innerhalb eines bestimmten Behälters garantiert werden kann, weil auf die anderen Behälter gar kein Zugriff besteht. Vom Modellierungsstandpunkt aus ist der Behälter aber bedeutungslos, da nichts über seinen Umfang ausgesagt werden kann.

Zunächst einmal ist zu fragen, ob in einem Basismodell wirklich eine Eindeutigkeit verlangt werden muss. Aus Sicht der übergeordneten Stelle (z.B. Bund) ist es durchaus denkbar, dass die Eindeutigkeit nicht für alle gilt, sondern zum Beispiel nur für das (Bundes-) interne Datenmodell.

Im Weiteren werden zwei Varianten vorgestellt, die das gegebene Problem der eindeutigen Benutzerschlüssel lösen:

Variante Zentrale Regelung.
Variante Dezentrale Regelung (Delegationsprinzip).

Variante Zentrale Regelung

Ohne weitergehende Überlegungen wird eine zentrale Regelung im Vordergrund stehen. Dabei legt eine zentrale Stelle für alle Objekte einer Klasse fest, dass ein bestimmter Benutzerschlüssel über das gesamte Gebiet eindeutig sein muss. Dies kann mit organisatorischen Massnahmen geschehen oder alle Beteiligten greifen auf eine zentrale Datenbank zu.

TOPIC Grundeigentum =
  CLASS Parzelle =
    Nummer: 1 .. 99999;
    Geometrie: AREA WITH (STRAIGHTS, ARCS) VERTEX CHKoord WITHOUT OVERLAPS > 0.005;
    UNIQUE Nummer;
  END Parzelle;
END Grundeigentum.

Oft legt die zentrale Stelle eine Gebietseinteilung fest, bei der alle Gebietsnummern über das gesamte Gebiet eindeutig sind. Sollen die Parzellen, die sich ja wiederum innerhalb dieser Gebiete befinden, über das Gesamte eindeutig sein, dann muss der Benutzerschlüssel aus der Kombination von Gebietsnummern und Parzellennummer bestehen:

CLASS Parzelle =
  Gebietsnummer: 1 .. 9999;
  Nummer: 1 .. 99999;
  Geometrie: AREA WITH (STRAIGHTS, ARCS) VERTEX CHKoord WITHOUT OVERLAPS > 0.005;
  UNIQUE Gebietsnummer, Nummer; !! Benutzerschluessel
END Parzelle;

Variante Dezentrale Regelung (Delegationsprinzip)

Wenn entsprechende Datenstrukturen in einem Datenmodell vorgesehen sind, ist es möglich, dass Objekte primär in kleineren Behältern (z.B. ein Behälter pro Gemeinde) erfasst werden, um sie dann ohne Probleme zu grösseren Behältern (z.B. einen für einen ganzen Kanton) zusammenzufassen. Nimmt man weiter an, dass der Bund festlegt, dass Parzellennummern fünfstellige Zahlen sein sollen, aber offen lässt, in welchem Rahmen sie eindeutig sein sollen, während ein Kanton zusätzlich festlegt, dass sie im Rahmen einer Gemeinde eindeutig sein sollen, ist folgende Modellierung möglich:

INTERLIS 2.4;

MODEL Bund (de) AT "http://www.interlis.ch/"
  VERSION "2005-06-16" =

  DOMAIN
    CHKoord = COORD
      0.000 .. 200.000 [INTERLIS.m], !! Min_Ost Max_Ost
      0.000 .. 200.000 [INTERLIS.m]  !! Min_Nord Max_Nord
      ROTATION 2 -> 1;
  END DOMAIN;

  TOPIC Grundeigentum =

    CLASS Parzelle =
      Nummer: 1 .. 99999;
      Geometrie: AREA WITH (STRAIGHTS, ARCS)
        VERTEX CHKoord WITHOUT OVERLAPS > 0.005;
    END Parzelle;

  END Grundeigentum;

END Bund.


INTERLIS 2.4;

MODEL KantonA (de) AT "http://www.interlis.ch/"
  VERSION "2005-06-16" =

  IMPORTS Bund;

  TOPIC OrgStruktur =

    CLASS Gemeinde =
      Name: TEXT*30;
      UNIQUE
        Name;
    END Gemeinde;

  END OrgStruktur;

  TOPIC Grundeigentum EXTENDS Bund.Grundeigentum =
    DEPENDS ON OrgStruktur;

    ASSOCIATION GdeParzelle =
      Gemeinde (EXTERNAL) -- {1} KantonA.OrgStruktur.Gemeinde;
      Parzelle -- {0..*} Parzelle;
    END GdeParzelle;

    CONSTRAINTS OF Parzelle =
      UNIQUE
        Nummer, Gemeinde;
    END;

  END Grundeigentum;

END KantonA.

Die Namen der Gemeinden müssen gemäss Definition im Rahmen aller Objekte der Klasse eindeutig sein. Es ist dabei irrelevant, ob diese Bedingung auf Grund der Aufteilung in konkrete Behälter wirklich überprüfbar ist. Sachlich gesehen gilt die Anforderung.

Um festzulegen, dass die Parzellennummer im Rahmen einer Gemeinde eindeutig sein muss, wird zwischen Parzelle und Gemeinde eine Beziehung erstellt und verlangt, dass die Kombination von Gemeinde und Nummer eindeutig ist. Dabei ist es wiederum nicht relevant, ob ein Behälter einen Teil einer Gemeinde, eine ganze Gemeinde oder mehrere Gemeinden umfasst. Vom Modellierungstandpunkt aus gilt die Anforderung.

Geht man z.B. davon aus, dass ein System die Parzellen einer bestimmten Gemeinde enthält, ist es durchaus möglich, dass bei den Parzellen systemintern auf die Beziehung zur Gemeinde verzichtet wird und diese nur für die Datenübergabe an andere Systeme beigefügt wird.

Appendix H: Einheiten-Definitionen (Standard-Erweiterungsvorschlag)

Bemerkung

Die folgende Spezifikation ist nicht normativer Bestandteil von INTERLIS. Dies ist ein Standard-Erweiterungsvorschlag auf der Basis des INTERLIS 2-Referenzhandbuches im Sinne einer Empfehlung. Es ist geplant, diesen Vorschlag nach einer breiten Diskussion in eine definitive Regelung umzuwandeln. Für Anwendungsbeispiele siehe auch die entsprechenden INTERLIS 2-Benutzerhandbücher.

Das Typen-Modell

Das folgende Typen-Modell fasst die gebräuchlichsten Einheiten zusammen. Es erweitert die durch INTERLIS direkt definierten Einheiten (vgl. Appendix A, Das interne INTERLIS-Datenmodell (normativ)).

!! File Units.ili Release 2014-07-09
INTERLIS 2.4;

TYPE MODEL Units (en) AT "http://www.interlis.ch/models/refhb24"
  VERSION "2014-07-09" =

  UNIT
    !! abstract Units
    Area (ABSTRACT) = (INTERLIS.LENGTH*INTERLIS.LENGTH);
    Volume (ABSTRACT) = (INTERLIS.LENGTH*INTERLIS.LENGTH*INTERLIS.LENGTH);
    Velocity (ABSTRACT) = (INTERLIS.LENGTH/INTERLIS.TIME);
    Acceleration (ABSTRACT) = (Velocity/INTERLIS.TIME);
    Force (ABSTRACT) = (INTERLIS.MASS*INTERLIS.LENGTH/INTERLIS.TIME/INTERLIS.TIME);
    Pressure (ABSTRACT) = (Force/Area);
    Energy (ABSTRACT) = (Force*INTERLIS.LENGTH);
    Power (ABSTRACT) = (Energy/INTERLIS.TIME);
    Electric_Potential (ABSTRACT) = (Power/INTERLIS.ELECTRIC_CURRENT);
    Frequency (ABSTRACT) = (INTERLIS.DIMENSIONLESS/INTERLIS.TIME);

    Millimeter [mm] = 0.001 [INTERLIS.m];
    Centimeter [cm] = 0.01 [INTERLIS.m];
    Decimeter [dm] = 0.1 [INTERLIS.m];
    Kilometer [km] = 1000 [INTERLIS.m];

    Square_Meter [m2] EXTENDS Area = (INTERLIS.m*INTERLIS.m);
    Cubic_Meter [m3] EXTENDS Volume = (INTERLIS.m*INTERLIS.m*INTERLIS.m);

    Minute [min] = 60 [INTERLIS.s];
    Hour [h] = 60 [min];
    Day [d] = 24 [h];

    Kilometer_per_Hour [kmh] EXTENDS Velocity = (km/h);
    Meter_per_Second [ms] = 3.6 [kmh];

    Newton [N] EXTENDS Force = (INTERLIS.kg*INTERLIS.m/INTERLIS.s/INTERLIS.s);
    Pascal [Pa] EXTENDS Pressure = (N/m2);
    Joule [J] EXTENDS Energy = (N*INTERLIS.m);
    Watt [W] EXTENDS Power = (J/INTERLIS.s);
    Volt [V] EXTENDS Electric_Potential = (W/INTERLIS.A);

    Inch [in] = 2.54 [cm];
    Foot [ft] = 0.3048 [INTERLIS.m];
    Mile [mi] = 1.609344 [km];

    Are [a] = 100 [m2];
    Hectare [ha] = 100 [a];
    Square_Kilometer [km2] = 100 [ha];
    Acre [acre] = 4046.873 [m2];

    Liter [L] = 1 / 1000 [m3];
    US_Gallon [USgal] = 3.785412 [L];

    Angle_Degree = 180 / PI [INTERLIS.rad];
    Angle_Minute = 1 / 60 [Angle_Degree];
    Angle_Second = 1 / 60 [Angle_Minute];
    Gon = 200 / PI [INTERLIS.rad];

    Gram [g] = 1 / 1000 [INTERLIS.kg];
    Ton [t] = 1000 [INTERLIS.kg];
    Pound [lb] = 0.4535924 [INTERLIS.kg];

    Calorie [cal] = 4.1868 [J];
    Kilowatt_Hour [kWh] = 0.36E7 [J];
    Horsepower = 746 [W];

    Techn_Atmosphere [at] = 98066.5 [Pa];
    Atmosphere [atm] = 101325 [Pa];
    Bar [bar] = 100000 [Pa];
    Millimeter_Mercury [mmHg] = 133.3224 [Pa];
    Torr = 133.3224 [Pa]; !! Torr = [mmHg]

    Decibel [dB] = FUNCTION // 10**(dB/20) * 0.00002 // [Pa];
    Degree_Celsius [oC] = FUNCTION // oC+273.15 // [INTERLIS.K];
    Degree_Fahrenheit [oF] = FUNCTION // (oF+459.67)/1.8 // [INTERLIS.K];

    CountedObjects EXTENDS INTERLIS.DIMENSIONLESS;

    Hertz [Hz] EXTENDS Frequency = (CountedObjects/INTERLIS.s);
    KiloHertz [KHz] = 1000 [Hz];
    MegaHertz [MHz] = 1000 [KHz];

    Percent = 0.01 [CountedObjects];
    Permille = 0.001 [CountedObjects];

    !! ISO 4217 Currency Abbreviation
    USDollar [USD] EXTENDS INTERLIS.MONEY;
    Euro [EUR] EXTENDS INTERLIS.MONEY;
    SwissFrancs [CHF] EXTENDS INTERLIS.MONEY;
  END UNIT;

END Units.

Beispiele

Vgl. Kapitel 3.9.1, “Basiseinheiten”

Appendix I: Zeit-Definitionen (Standard-Erweiterungsvorschlag)

Bemerkung

Die folgende Spezifikation ist nicht normativer Bestandteil von INTERLIS. Dies ist ein Standard-Erweiterungsvorschlag auf der Basis des INTERLIS 2-Referenzhandbuches im Sinne einer Empfehlung. Es ist geplant, diesen Vorschlag nach einer breiten Diskussion in eine definitive Regelung umzuwandeln. Für Anwendungsbeispiele siehe auch die entsprechenden INTERLIS 2-Benutzerhandbücher.

Das Zeit-Modell

!! File Time.ili Release 2014-07-09
INTERLIS 2.4;

REFSYSTEM MODEL Time (en) AT "http://www.interlis.ch/models/refhb24"
  VERSION "2014-07-09" =

  IMPORTS Units;

  STRUCTURE DayOfYear =
    Month: 1 .. 12 [INTERLIS.M];
    SUBDIVISION Day: 1 .. 31 [INTERLIS.d];
  END DayOfYear;

  STRUCTURE HMDiffWithinDay =
    Hours: -23 .. 23 CIRCULAR [INTERLIS.h];
    CONTINUOUS SUBDIVISION Minutes: 0 .. 59 [INTERLIS.min];
  END HMDiffWithinDay;

  DOMAIN
    WeekDay = (
      WorkingDay (
        Monday,
        Tuesday,
        Wednesday,
        Thursday,
        Friday,
        Saturday
      ),
      Sunday
    ) CIRCULAR;

    HMDiffWDay = FORMAT BASED ON HMDiffWithinDay (Hours ":" Minutes);

    DifferenceToUTC EXTENDS HMDiffWDay = MANDATORY "-13:00" .. "13:00";
    !! UTC := LocTime + Diff
  END DOMAIN;

  FUNCTION DayInCurrentYear (
    dayOfYear: MANDATORY DayOfYear;
    weekDay: WeekDay
  ): DayOfYear
  /* returns first parameter if second is undefined,
  returns first day from (incl) first parameter being the
  requested weekday within the current year */;

  FUNCTION DSTOrdered (day1: DayOfYear; day2: DayOfYear): BOOLEAN
  /* returns TRUE if the second parameter comes after the
  first parameter or if both parameters are equal */;

  STRUCTURE DSTransition =
    TransitionDSTime: MANDATORY HMDiffWDay;
    FirstDate: MANDATORY DayOfYear;
    DayOfWeek: WeekDay;
  END DSTransition;

  STRUCTURE DaylightSavingPeriod =
    DSToUTC: DifferenceToUTC;
    From: MANDATORY INTERLIS.GregorianYear;
    To: MANDATORY INTERLIS.GregorianYear;
    DSStart: MANDATORY DSTransition;
    DSEnd: MANDATORY DSTransition;

    MANDATORY CONSTRAINT
      DSTOrdered (DSStart.FirstDate, DSEnd.FirstDate);

    MANDATORY CONSTRAINT
      To >= From;
  END DaylightSavingPeriod;

  FUNCTION DSPOverlaps (periods: BAG {1..*} OF DaylightSavingPeriod): BOOLEAN
  /* returns TRUE if any one of the periods overlap */;

  TOPIC TimeZone =

    CLASS TimeZone (ABSTRACT) EXTENDS INTERLIS.SCALSYSTEM =
      PARAMETER
        Unit (EXTENDED): NUMERIC [INTERLIS.TIME];
    END TimeZone;

    CLASS BaseTimeZone EXTENDS INTERLIS.TIMESYSTEMS.TIMEOFDAYSYS =
      !! TimeZone without daylight saving
      DiffToUTC: DifferenceToUTC;
    END BaseTimeZone;

    CLASS DaylightSavingTZ EXTENDS INTERLIS.TIMESYSTEMS.TIMEOFDAYSYS =
      Periods: BAG {1..*} OF DaylightSavingPeriod;

      MANDATORY CONSTRAINT
        NOT (DSPOverlaps (Periods));
    END DaylightSavingTZ;

    ASSOCIATION DaylightSavingTZOf =
      BaseTZ -<> BaseTimeZone;
      DSTZ -- DaylightSavingTZ;
    END DaylightSavingTZOf;

  END TimeZone;

END Time.

Beispieldaten zum Zeit-Modell

Das folgende Beispiel passt zum vorhergehenden Zeit-Modell.

<?xml version="1.0" encoding="UTF-8"?>
<ili:transfer xmlns:ili="http://www.interlis.ch/xtf/2.4/INTERLIS" xmlns:geom="http://www.interlis.ch/geometry/1.0" xmlns="http://www.interlis.ch/xtf/2.4/Time" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <ili:headersection>
    <ili:models>
      <ili:model>Time</ili:model>
    </ili:models>
    <ili:comment>example dataset ili2 refmanual appendix G</ili:comment>
  </ili:headersection>
  <ili:datasection>
    <TimeZone ili:bid="BTimeZones">
      <BaseTimeZone ili:tid="BTimeZones.MEZ">
        <ili:Name>MEZ</ili:Name>
        <DiffToUTC>-1:00</DiffToUTC>
      </BaseTimeZone>
      <DaylightSavingTZ ili:tid="BTimeZones.MESZ">
        <ili:Name>MESZ</ili:Name>
        <Periods>
          <DaylightSavingPeriod>
            <DSToUTC>-2:00</DSToUTC>
            <From>1983</From>
            <To>1995</To>
            <DSStart>
              <DSTransition>
                <TransitionDSTime>3:00</TransitionDSTime>
                <FirstDate>
                  <DayOfYear>
                    <Month>3</Month>
                    <Day>25</Day>
                  </DayOfYear>
                </FirstDate>
                <DayOfWeek>Sunday</DayOfWeek>
              </DSTransition>
            </DSStart>
            <DSEnd>
              <DSTransition>
                <TransitionDSTime>3:00</TransitionDSTime>
                <FirstDate>
                  <DayOfYear>
                    <Month>9</Month>
                    <Day>24</Day>
                  </DayOfYear>
                </FirstDate>
                <DayOfWeek>Sunday</DayOfWeek>
              </DSTransition>
            </DSEnd>
          </DaylightSavingPeriod>
        </Periods>
        <Periods>
          <DaylightSavingPeriod>
            <DSToUTC>-2:00</DSToUTC>
            <From>1996</From>
            <To>2999</To>
            <DSStart>
              <DSTransition>
                <TransitionDSTime>3:00</TransitionDSTime>
                <FirstDate>
                  <DayOfYear>
                    <Month>3</Month>
                    <Day>25</Day>
                  </DayOfYear>
                </FirstDate>
                <DayOfWeek>Sunday</DayOfWeek>
              </DSTransition>
            </DSStart>
            <DSEnd>
              <DSTransition>
                <TransitionDSTime>3:00</TransitionDSTime>
                <FirstDate>
                  <DayOfYear>
                    <Month>10</Month>
                    <Day>25</Day>
                  </DayOfYear>
                </FirstDate>
                <DayOfWeek>Sunday</DayOfWeek>
              </DSTransition>
            </DSEnd>
          </DaylightSavingPeriod>
        </Periods>
      </DaylightSavingTZ>
      <DaylightSavingTZOf>
        <BaseTZ ili:ref="BTimeZones.MEZ"/>
        <DSTZ ili:ref="BTimeZones.MESZ"/>
      </DaylightSavingTZOf>
    </TimeZone>
  </ili:datasection>
</ili:transfer>

Appendix J: Farben-Definitionen (Standard-Erweiterungsvorschlag)

Bemerkung

Die folgende Spezifikation ist nicht normativer Bestandteil von INTERLIS. Dies ist ein Standard-Erweiterungsvorschlag auf der Basis des INTERLIS 2-Referenzhandbuches im Sinne einer Empfehlung. Es ist geplant, diesen Vorschlag nach einer breiten Diskussion in eine definitive Regelung umzuwandeln. Für Anwendungsbeispiele siehe auch die entsprechenden INTERLIS 2-Benutzerhandbücher.

Einleitung

Diese Spezifikation begründet detailliert, dass sich ein L* C*_ab h*_ab genannter Farbraum am besten für Farben-Definitionen eignet. Es stellt diesen Farbraum ausführlich vor, zitiert Umrechnungsformeln zu anderen Farbräumen und gibt Hinweise darauf, wie eine Transformation von L* C*_ab h*_ab-Koordinaten in das Farb-Koordinatensystem eines konkreten Bildschirms oder Druckers implementiert werden kann. Zudem begründet es die nachfolgend gewählten Wertebereiche und Genauigkeiten und gibt die Koordinaten ausgewählter Beispielwerte an.

Da es INTERLIS 2 unter anderem ermöglicht, Grafiken zu beschreiben, muss es möglich sein, Farben zu spezifizieren. Eine system- und geräteneutrale Definition von "Farbe" ist jedoch erstaunlich komplex und setzt das Verständnis von Konzepten voraus, die nicht allgemein bekannt sind.

Farbe ist ein Produkt aus Licht (= Farbreiz), Auge (= Farbvalenz) und Gehirnfunktion (= Sinneseindruck). Farben lassen sich eigentlich mit Zahlen nicht exakt beschreiben, sodass zwei Menschen darunter dasselbe verstehen. Es ist aber möglich, Farbwerte zu messen und sich auf eine Messung zu einigen, sodass eine präzise Verständigung unter Fachleuten möglich ist.

Ein Weg zur Spezifikation von Farben als Zeichenkette sollte mehreren Anforderungen genügen:

Geräteunabhängigkeit — Es sollte klar definiert sein, welche Farbe mit einer bestimmten Angabe tatsächlich gemeint ist. Nur so kann sichergestellt werden, dass das Ergebnis auf allen Geräten den Erwartungen entspricht.
Ausdrucksstärke — Es sollte möglich sein, alle Farben zu spezifizieren, die ein „normales“ Gerät (insbesondere auch qualitativ gute Drucker und Plotter) darstellen kann. Das Spektrum spezifizierbarer Farben sollte also möglichst gross sein. Idealerweise umfasst es alle Farben, die ein Mensch wahrnehmen kann.
Intuitivität — Beim Lesen einer Farbangabe sollte ein Mensch intuitiv eine ungefähre Vorstellung davon erhalten, was für eine Farbe gemeint ist. Ein INTERLIS-Modell besitzt immer auch Dokumentationscharakter und sollte für Menschen ohne grösseren Aufwand verständlich sein.
Systemneutralität — Die Art und Weise der Farbangabe sollte kein System (GIS, Betriebssystem, Hardware) bevorzugen oder gar die Anschaffung besonderer Hilfsmittel bedingen.

Farbraum

Die untenstehende Tabelle fasst die Eignung verschiedener Farbräume für die Anwendung in INTERLIS-Darstellungsbeschreibungen zusammen:

Abbildung 28. Eignung verschiedener Farbräume für die Zwecke von INTERLIS.

Der letzte der in Abbildung 28 erwähnten Farbräume L* C*_ab h*_ab (d.h. L* a* b* mit Polarkoordinaten) erfüllt die oben postulierten Anforderungen am besten.

L* a* b*

In der grafischen Branche recht verbreitet ist der Farbraum L* a* b* (manchmal auch CIELAB genannt), der über die in Abbildung 29 beschriebene Transformation aus XYZ ableitbar ist.

Abbildung 29. Die Umrechnung von XYZ zu L* a* b*.

In die Berechnung von Abbildung 29 fliesst mit ‹Xn, Yn, Zn› ein "Referenzweiss" ein, um eine allfällige Färbung des Lichts zu kompensieren. Häufig werden die Werte von CIE-Standardlichtquellen (meist D50, gelegentlich D65) eingesetzt. Die XYZ-Koordinaten dieser Lichtquellen finden sich beispielsweise in [Sangwine/Horne89], Tabelle 3.1.

Dieser Raum besitzt eine Reihe von nützlichen Eigenschaften:

Geräteunabhängigkeit — L* a* b* ist von XYZ abgeleitet und hängt damit nicht von einem bestimmten Gerät ab. Es ist eindeutig definiert, welche Farbe zu einem L* a* b*-Tripel gehört.
Ausdrucksstärke — Jeder Farbe, die eine reflektierende Fläche abgeben kann, ist in L* a* b* ein Punkt zugeordnet.
Intuitive Verständlichkeit — L* ist die Helligkeit, wobei eine vollkommen schwarze Fläche (die keinerlei Licht reflektiert) ein L* von 0 und ein perfekter Reflektor (der alles Licht reflektiert) ein L* von 100 besitzt. Ein menschlicher Betrachter empfindet eine Farbe mit L* = 50 als mittlere Helligkeit. a* ist die Rot-Grün-Achse: Farben mit a* = 0 werden als weder rot noch grün empfunden, Farben mit negativem a* sind grün, Farben mit positivem a* rot. Analog ist b* die Blau-Gelb-Achse. Je weiter eine Farbe in der durch a* und b* aufgespannten Ebene vom Nullpunkt entfernt ist, umso gesättigter ist sie.
Systemneutralität — L* a* b* ist vollkommen systemneutral; als internationaler Standard ist der Farbraum unabhängig von einer bestimmten Firma.
Zunehmende Verbreitung — L* a* b* findet im professionellen Druck zunehmende Verbreitung. Programme wie Adobe Photoshop oder Acrobat (PDF) unterstützen den L* a* b*-Farbraum.
Leichte Transformierbarkeit zu RGB — L* a* b*-Tripel sind durch Multiplikation mit einer 3×3-Matrix, gefolgt von einer Potenzierung (Gammakorrektur), die effizient mittels einer Tabelle erfolgen kann, in die RGB-Werte eines beliebigen Bildschirms transformierbar (s. [Adobe92], Kapitel 23). Der Aufwand für Systemimplementierer ist somit sehr gering.
Gute Komprimierbarkeit — Nur am Rande erwähnt sei, dass sich L* a* b* besser als RGB für verlustbehaftete Verfahren zum Komprimieren von Bildern eignet. Im Zusammenhang mit INTERLIS ist dies jedoch irrelevant.

Abbildung 30. Umrechnung vom kartesischen L* a* b*-Raum in die polare Form L* C*_ab h*_ab (nach [Sangwine/Horne98]).

L* C_ab h_ab

Wie oben beschrieben, entsprechen im L* a* b*-Raum die einzelnen Achsen L* (dunkel — hell), a* (grün — rot) und b* (blau — gelb unmittelbar wahrnehmbaren Eigenschaften der Farben. Die intuitive Verständlichkeit kann jedoch noch gesteigert werden, wenn die Farbkoordinaten nicht über ein kartesisches, sondern über ein polares System angegeben werden (siehe Abbildung 31).

Abbildung 31. Der Farbraum L* C*_ab h*_ab arbeitet mit polaren Koordinaten auf L* a* b*.

Die Formel in Abbildung H.3 für h*_ab trifft nur für positive a* und b* zu; eine korrekte Version würde Fallunterscheidungen für die einzelnen Quadranten enthalten. Dieses polare System verbindet die intuitive Verständlichkeit von HLS und HSV mit den oben beschriebenen zahlreichen Vorteilen von L* a* b*, da nun die Achsen L* (Helligkeit, engl. Luminance), C* (Farbsättigung, engl. Chroma) und h* (Farbton, engl. hue) separat verfügbar sind.

Sind präzise Farben-Angaben gewünscht, dann sollen diese in INTERLIS-Modellen auf der Basis dieses Farb-Koordinatensystems gemacht werden.

Nötige Genauigkeit

Teil eines INTERLIS-Modells ist die Angabe, mit welcher Genauigkeit numerische Grössen festzuhalten sind. Nun ist der L* a* b*-Raum so definiert, dass der Unterschied zwischen zwei Farben gerade noch wahrnehmbar ist, wenn der gemäss Abbildung 32 berechnete Wert gleich 1 ist.

Bemerkung: [Has/Newman] weist darauf hin, dass die Wahrnehmbarkeit von Farbunterschieden auch davon abhängt, wie viel Zeit zum Vergleich zur Verfügung steht. Der Artikel zitiert ein Experiment, bei dem gemessen wurde, wie lange ein unerfahrener Betrachter benötigt, bis er den Unterschied bemerkt. Es werden Zahlen von 5 Sekunden für ΔE_ab = 15, 10 Sekunden für ΔE_ab = 10 und 15 Sekunden für ΔE_ab = 5 genannt.

Abbildung 32. Berechnung des Farbunterschieds im kartesischen L* a* b*-Raum.

Genauigkeit der L*-Achse: Für die Helligkeit reicht damit eine Genauigkeit von einer Nachkommastelle aus.

Genauigkeit der C*_ab- und h*_ab-Achsen: Zwar sind a* und b* theoretisch unbeschränkt, aber in der Praxis werden Grenzen von ±128, auf ganze Zahlen gerundet, als mehr als ausreichend betrachtet (siehe [Adobe92]). Welche Genauigkeit ist damit für C*_ab und h*_ab nötig, damit die Ungenauigkeit in der a*/b*-Ebene nicht grösser als 1 wird?

Die durch die Winkelangabe eingeführte Ungenauigkeit steigt mit zunehmender Distanz vom Nullpunkt. Damit kann eine Genauigkeit als ausreichend erachtet werden, wenn ⟨127, 128⟩ und ⟨128, 128⟩ in der a*/b*-Ebene noch unterscheidbar sind. Wie aus Abbildung 30 ersichtlich ist, reicht für diesen extremen Fall eine Nachkommastelle aus. Es handelt sich dort um zwei gerade noch unterscheidbare Orangetöne, die allerdings so stark gesättigt sind, dass sie von kaum einem Gerät darstellbar sein dürften.

Abbildung 33. Kartesische und polare Koordinaten einer sehr weit vom Nullpunkt entfernten Farbe (zur Umrechnung siehe Abbildung 30)

Kombination mit Namen

Farbnamen sind einfacher als Farbcodes (d.h. Zahlen) zu benutzen, besitzen aber den Nachteil, dass nur eine beschränkte Menge von Farben verwendet werden kann. In INTERLIS sind nun Namen mit einer numerischen Spezifikation verbindbar, so dass die Benutzer ihre eigenen Farbnamen definieren und untereinander mit den üblichen INTERLIS-Mitteln austauschen können.

Mit dieser Definition ist es auch möglich, dass bei Bedarf existierende Farbnamensysteme und Farbmustekataloge — wie das Pantone- oder HKS-System — mit INTERLIS dokumentiert und genutzt werden können.

Dies erfolgt durch die Definition einer Metaklasse (vgl. Kapitel 2.4.3, “Meta-Modelle und Meta-Objekte”). Deren Instanzen, so genannte Meta-Objekte, werden in einer besonderen Transferdatei festgehalten und vom INTERLIS-2-Compiler eingelesen. Sie stehen für INTERLIS-Datenmodelle zur Verfügung und können daher in Grafik-Definitionen benutzt werden, um beispielsweise die Farbe einer Signatur zu bestimmen.

Einsatzbeispiel in INTERLIS-Modellen

!! Bestandteil des Signaturenmodells
INTERLIS 2.4;

SYMBOLOGY MODEL SymbologyExample AT "http://www.interlis.ch/"
  VERSION "2014-07-09" =

  TOPIC Signs =

    CLASS LChColor EXTENDS INTERLIS.METAOBJECT =
      !! Attribut "Name" ererbt von INTERLIS.METAOBJECT
      Luminance: MANDATORY 0.0 .. 100.0;
      Chroma: MANDATORY 0.0 .. 181.1;
      Hue: MANDATORY 0.0 .. 359.9 CIRCULAR [DEGREE] COUNTERCLOCKWISE;
    END LChColor;
    ...

    !! Bestandteil der Signatur-Klassen-Definition im Signaturenmodell
    CLASS BunteSignatur EXTENDS SIGN =
      ...

      PARAMETER
        Farbe: METAOBJECT OF SymbologyExample.Signs.LChColor;
      END PARAMETER;

    END BunteSignatur;
    ...
  END Signs;
  ...
END SymbologyExample.

In einer benutzerdefinierten Darstellungsanweisung (hier SimplePunktGr genannt) könnte dann z.B. die Farbe einer benutzerdefinierten bunten Signatur wie folgt angegeben werden (vgl. Kapitel 3.16, “Darstellungsbeschreibungen”):

INTERLIS 2.4;

MODEL SimpleGrafik AT "http://www.interlis.ch/"
  VERSION "2014-07-09" =

  IMPORTS SymbologyExample, Daten;

  SIGN BASKET SimpleSigns ~ SymbologyExample.Signs =
    OBJECTS OF Farbe: Braun;
    OBJECTS OF BunteSignatur: Punkt;
  END SimpleSigns;

  TOPIC BuntePunktGrafik =
    DEPENDS ON Daten.Punkte;

    GRAPHIC SimpleBuntePunktGr
      BASED ON Daten.Punkte.Punkt =

      Symbol OF SymbologyExample.Signs.BunteSignatur: (
        Sign := {Punkt};
        Pos := Lage;
        Farbe := {Braun};
      );

    END SimpleBuntePunktGr;

  END BuntePunktGrafik;

END SimpleGrafik.

Auf die Angabe eines kompletten Beispiels wie auch die Anzeige der nötigen Metatabelle wird hier verzichtet; es sei stattdessen auf Appendix E, Das kleine Beispiel Roads (informativ) verwiesen.

Abbildung 34 nennt einige Farben mitsamt ihren Koordinaten. Da unsicher ist, ob dieses Dokument auf einem System geschrieben (und wohl auch gedruckt) wurde, das in der Lage ist, Farben korrekt wiederzugeben, muss an dieser Stelle leider darauf verzichtet werden, die Farben bunt darzustellen.

Abbildung 34. Kartesische und polare Koordinaten einiger Farben.

Ein konkretes Anwendungsbeispiel mit Farben-Definitionen ist im Appendix E, Das kleine Beispiel Roads (informativ) zu finden.

Hinweise für Systemimplementierer

Den Implementierern von INTERLIS-konformen Systemen stellt sich die Frage, wie die Farbwerte aus dem geräteunabhängigen L* C*_ab h*_ab-System in das Farb-Koordinatensystem eines konkreten Bildschirms oder Druckers zu transformieren sind.

Ein standardisiertes Dateiformat ermöglicht es, die Farbverzerrung eines bestimmten Gerätes in Form so genannter Geräte- oder Farbprofile festzuhalten (so genanntes ICC-Profil-Format). Unter anderem enthalten diese Dateien Parameter, welche in die Umrechnung von einem geräteunabhängigen Farbraum zum gerätespezifischen Farb-Koordinatensystem einfliessen. Ersteres ist entweder XYZ oder L* a* b*, Letzteres typischerweise RGB oder CMYK. Das Format und die nötigen Umrechnungsfunktionen werden durch [ICC96] definiert.

Ein Systemimplementierer kann nun in seinem Produkt direkt ICC-Profile unterstützen. Das Dateiformat ist relativ einfach aufgebaut, und die Umrechnungsfunktionen sind schnell implementiert. Für einige Plattformen stehen fertige Programmbibliotheken (wie Apple ColorSync oder Kodak KCMS) zur Verfügung.

Es sei in diesem Zusammenhang darauf hingewiesen, dass PDF den Farbraum L* a* b* direkt unterstützt. PostScript ermöglicht es sogar, eigene Farbräume als beliebige Transformationen aus XYZ zu definieren. Die Umkehrfunktion der in Abbildung 29 angegebenen Formel findet sich als Beispiel 4.11 in [Adobe90]. Es ist relativ einfach, eine analoge Funktion in PostScript zu programmieren, welche direkt L* C*_ab h*_ab entgegennimmt.

Literaturhinweise

[Adobe, 1990] Adobe Systems: PostScript Language Reference Manual. 2nd Ed., 1990. ISBN 0-201-18127-4. 764 Seiten.

Das Referenzhandbuch für PostScript unter anderem auch mit Hinweisen auf die Behandlung von Farben und verschiedene Umrechnungsmethoden, die in PostScript verfügbar sind. Beispiel 4.11 auf Seite 191 definiert den L* a* b*-Farbraum in PostScript.
[Adobe, 1992] Adobe Developers Association: TIFF Revision 6.0.

https://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf

Kapitel 23 definiert eine Variante des TIFF-Formats für Bilder im L* a* b*-Farbraum und nennt eine Anzahl von Vorteilen gegenüber RGB. Ausserdem wird eine schnelle Methode zur Umrechnung von L* a* b* zu RGB skizziert.
[Apple, 2005] Apple Computer, Inc.: Introduction to Color and Color Management Systems. In: Inside Macintosh — Managing Color with ColorSync.

https://developer.apple.com/library/mac/documentation/GraphicsImaging/Conceptual/csintro/csintro_intro/csintro_intro.html

Allgemein verständliche Einführung in verschiedene Farbräume, mit illustrativen Grafiken.
[Apple, 2005] Apple Computer, Inc.: A Brief Overview Of Color.

https://developer.apple.com/library/mac/documentation/GraphicsImaging/Conceptual/csintro/csintro_ovrvw/csintro_ovrvw.html

Sehr kurz gehaltene, allgemein verständliche Grobeinführung in verschiedene Konzepte im Zusammenhang mit Farben. An Laien gerichtet.
[Has/Newman, o.D.] Michael Has, Todd Newman: Color Management: Current Practice and the Adoption of a New Standard.

http://www.color.org/wpaper1.html

Nennt Messdaten für den Rot-, Grün- und Blaureferenzpunkt von zwei typischen Computermonitoren und zeigt, dass sie stark von den häufig zitierten xy-Werten der NTSC-Standard-Phosphorfarben abweichen. Gibt eine Transformation von XYZ zum RGB-Raum eines bestimmten Bildschirms an.
[ICC, 1996] International Color Consortium: ICC Profile Format Specification.

http://www.color.org/profile.html

Definiert ein Dateiformat, mit dem beliebige Geräte im Hinblick auf ihre Farbwiedergabe charakterisiert werden können. Anhang A diskutiert verschiedene Farbräume.
[Poynton, 1997] Charles A. Poynton: Frequently Asked Questions about Color.

http://www.poyn
[Sangwine/Horne, 1989] S. J. Sangwine, R. E. N. Horne: (Angabe gemäss Originalquelle; in deinem Text referenziert: Tabelle 3.1).
[Sangwine/Horne, 1998] S. J. Sangwine, R. E. N. Horne: (Angabe gemäss Originalquelle; in deinem Text referenziert: Umrechnung in Abb. J.3).

Appendix K: Koordinatensysteme und Koordinaten-Referenzsysteme (Standard-Erweiterungsvorschlag)

Bemerkung

Die folgende Spezifikation ist nicht normativer Bestandteil von INTERLIS. Dies ist ein Standard-Erweiterungsvorschlag auf der Basis des INTERLIS-2-Referenzhandbuches im Sinne einer Empfehlung. Es ist geplant, diesen Vorschlag nach einer breiten Diskussion in eine definitive Regelung umzuwandeln. Für Anwendungsbeispiele siehe auch die entsprechenden INTERLIS-2-Benutzerhandbücher.

Einleitung

Koordinaten beschreiben die Position eines Punktes in einem Raum, für den ein Koordinatensystem eingeführt ist. Ist ein Koordinatensystem bezüglich der Erde fest positioniert – man sagt auch: gelagert – dann nennt man es ein Koordinaten-Referenzsystem. Durch Koordinaten werden aber nicht nur Positionen festgehalten, sondern auch metrische Grössen, die aus Koordinaten ableitbar sind. Dazu gehören unter anderem Distanzen, Flächen, Volumen, Winkel und Richtungen, sowie weitere Eigenschaften wie Steigungen und Krümmungen.

Es gibt eine Vielzahl von Klassen (Typen) von Koordinatensystemen, und eine noch viel grössere Anzahl von Objekten, d.h. von Realisierungen (Instanzen) von Koordinatensystemen (siehe z.B. [Voser99]). Die schweizerischen Landeskoordinaten beispielsweise stützen sich auf eine besondere Instanz (Objekt) eines Koordinaten-Referenzsystems [Gubler96], das über eine Kartenprojektion aus einem geodätischen Referenzsystem hergeleitet werden kann [Snyder87], [Bugayevskiy95]. Diese geodätischen Referenzsysteme bilden eine eigene Kategorie von Koordinaten-Referenzsystemen, welche die Geometrie eines Erdmodells beschreiben. Dabei wird z.B. zur Beschreibung der 2-dimensionalen Lage eine Kugel oder ein Ellipsoid zu Hilfe genommen und auf deren Oberfläche werden geografische Koordinaten definiert. Etwas komplizierter sieht es für die Höhe aus: Als geometrisch-physikalisches Erdmodell wird das Geoid [Marti97] bzw. ein Schweremodell [Torge75] verwendet, welches orthometrische bzw. normale Höhen definiert. Doch oft sind in der Praxis nur Gebrauchshöhen in Verwendung.

Da Geodaten von Geomatik-Anwendungen einen Raumbezug aufweisen, muss jedem Geodatensatz ein Koordinatensystem zu Grunde liegen. Da sich einzelne Koordinatensysteme wesentlich voneinander unterscheiden, so ist es notwendig, entsprechende Referenzdaten mit den Geodaten mitzuliefern. Aus diesem Grund ermöglicht auch INTERLIS, diese Daten zum Koordinatensystem zu beschreiben.

Erst durch die Kenntnis des zu Grunde liegenden Koordinatensystems wird es möglich, die darin beschriebenen Geodaten in ein anderes Koordinatensystem überzuführen. Dies wiederum ist notwendig, um Geodaten, welche in unterschiedlichen Koordinatensystemen vorliegen, gemeinsam nutzen zu können [Voser96].

Wir betrachten zuerst Koordinatensysteme allgemeiner Art, dann die Beziehungen (Abbildungen) zwischen (allgemeinen) Koordinatensystemen, und anschliessend führen wir die Koordinaten-Referenzsysteme ein und beschäftigen uns damit.

Koordinatensysteme

Ein Koordinatensystem ermöglicht es, einen metrischen Raum «auszumessen». Ein Koordinatensystem hat einen Ursprung, Koordinatenachsen (deren Anzahl der Dimension des aufgespannten Raumes entspricht), sowie Masseinheiten, die den Achsen zugeordnet sind. Je nachdem es sich bei dem aufgespannten Raum um einen 1-, 2- oder 3-dimensionalen Raum handelt, wird durch das Koordinatensystem jedem Punkt des Raumes eine Einzelzahl, ein Zahlenpaar oder ein Zahlentripel als Koordinate(n) zugeordnet.

Der Euklidische 1-, 2- bzw. 3-dimensionale Raum ist definiert durch seine 1, 2 bzw. 3 geraden Achsen. Gekrümmte Räume brauchen zusätzliche Parameter zur Definition der Einbettung ihrer gekrümmten Achsen in einen Euklidischen Raum. Für geodätische Zwecke braucht man neben den Euklidischen Räumen verschiedener Dimension noch die 2-dimensionalen ellipsoidischen Räume sowie verschiedene Höhensysteme, welche als spezielle 1-dimensionale Euklidische Räume behandelt werden. Für diese braucht man das Schweremodell oder das Geoid.

Etwas abweichend vom bisherigen Gebrauch in der Geodäsie verwenden wir den Begriff geodätisches Datum als Synonym für geodätisches Referenzsystem und bezeichnen damit nichts anderes als ein besonderes Koordinatensystem, nämlich ein 3-dimensionales kartesisches Koordinatensystem, das bezüglich der Erde positioniert ist. Das kann auf zwei Arten geschehen:

Man definiert das mittlere Gravitationszentrum der Erde als Nullpunkt des Koordinatensystems, die erste Achse durch die mittlere Rotationsachse der Erde, die zweite Achse senkrecht dazu durch den mittleren Meridian von Greenwich, und die dritte Achse senkrecht zu den beiden ersten, so dass insgesamt ein rechtsdrehendes System entsteht. So wird z.B. das Koordinatensystem WGS84 definiert.
Die Erdoberfläche eines bestimmten Gebietes (meist eines Landes) wird optimal angenähert durch eine Kugel oder ein Rotationsellipsoid, dessen Drehachse parallel zur mittleren Rotationsachse der Erde verläuft. Dieses Rotationsellipsoid definiert ein kartesisches Koordinatensystem durch seine kleine Halbachse parallel zur Drehachse, durch eine seiner grossen Halbachsen und durch eine dritte Achse senkrecht zu den beiden ersten, so dass wiederum ein rechtsdrehendes System entsteht.

Ein gemäss (a) oder (b) auf der Erde positioniertes 3-dimensionales kartesisches Koordinatensystem nennen wir geodätisches Datum oder geodätisches Referenzsystem.

Unterschiedliche Herkunft von Koordinatensystemen in der Geomatik

Sehr unterschiedliche Gründe führen zur Definition von Koordinatensystemen in der Geomatik:

Sensorik: Die Datenerfassung der klassischen Geodäsie (z.B. mit dem Theodolit) aber auch Photogrammetrie und Fernerkundung verwenden in ihren Erfassungssensoren das der jeweiligen Methode entsprechende (lokale) Koordinatensystem für die Erfassung.
Geopositionierung: Die Positionsbeschreibung auf der Erde mit Hilfe eines (geodätischen) Erdmodells. Es gibt dabei drei Arten von (geodätischen) Erdmodellen [Voser99]:
- physikalisch: Das Erdmodell wird durch das Schwerefeld beschrieben oder durch das Geoid.
- mathematisch: Das Erdmodell ist ein symmetrischer Körper (z.B. eine Kugel oder ein Ellipsoid).
- topografisch: Das Erdmodell berücksichtigt auch Gebirge und Täler (Geländeoberflächenmodell).

Den genannten Erdmodellen entsprechen unterschiedliche Koordinatensysteme.

Kartenpositionierung: Da die Oberflächen der genannten Erdmodelle gekrümmte oder noch komplexere Gestalt annehmen, wird die Berechnung von Distanzen, Winkeln etc. sehr schwierig. Aus diesem Grund verwendet man Kartenprojektionen, welche die 2-dimensionale Fläche in eine Ebene abbilden. Eine Kartenprojektion ist eine geometrisch klar definierte Abbildungsvorschrift von der Oberfläche eines mathematischen Erdmodells in die Ebene. Bei diesem Vorgang treten Verzerrungen auf. Diese sind jedoch im Voraus bestimmbar und kontrollierbar.

Abbildungen zwischen Koordinatensystemen

Da viele Geodaten in unterschiedlichen Koordinatensystemen erfasst werden, oder von unterschiedlichen Institutionen in anderen Systemen verwaltet werden, ist es notwendig, die Methoden zu kennen, um die in einem Ausgangs-Koordinatensystem A vorliegenden Daten in ein gewünschtes Ziel-Koordinatensystem Z umzurechnen. Diese Umrechnung nennt man Abbildung des Koordinatensystems A bzw. des durch A definierten Raumes ins Koordinatensystem Z bzw. in den durch Z definierten Raum. Die Abbildung zwischen zwei Koordinatensystemen bzw. zwischen den beiden durch sie definierten Räumen ist bestimmt durch die Klassen der beiden Koordinatensysteme.

Es sind zwei wesentlich verschiedene Abbildungen von Koordinatensystemen zu unterscheiden, wenn man die Herkunft der Formeln und ihrer Parameter in Betracht zieht, nämlich Konversionen und Transformationen.

Eine Konversion ist eine durch Formeln und deren Parameter fest definierte Abbildung zwischen zwei Koordinatensystemen. Die Formeln und vor allem die Werte der notwendigen Parameter sind im Voraus festgelegt [Voser99]. Zu den Konversionen gehören beispielsweise die Kartenprojektionen, das heisst z.B. die Abbildungen von der Ellipsoidoberfläche in die Ebene. Ebenfalls in die Kategorie der Konversionen fällt die Umrechnung von ellipsoidischen Koordinaten in die zugehörigen kartesischen Koordinaten mit dem Ursprung im Ellipsoidzentrum oder umgekehrt.

Als Transformation bezeichnet man eine Abbildung zwischen zwei Koordinatensystemen, wenn die Abbildungsvorschrift (Formel) auf Grund von Annahmen (Hypothesen) festgelegt wird und die Parameter durch statistische Analyse von Messungen in beiden Koordinatensystemen ermittelt werden [Voser99]. Typische Transformationen werden beim Übergang zwischen unterschiedlichen geodätischen Erdmodellen vorgenommen (geodätische Datumstransformationen), oder bei der Einpassung lokaler Koordinaten in übergeordnete Systeme, wie beispielsweise beim Digitalisieren die Umrechnung von Blatt- oder Digitalisiertisch-Koordinaten in Projektionskoordinaten.

Koordinaten-Referenzsysteme

Koordinaten-Referenzsystem heisst ein Koordinatensystem, das über eine Folge von Zwischen-Koordinatensystemen durch Konversionen aus einem geodätischen Referenzsystem (d.h. aus einem geodätischen Datum) hergeleitet werden kann.

Die geodätischen Referenzsysteme (oder geodätischen Datums) sind selbst die wichtigsten Koordinaten-Referenzsysteme. Diese beziehen sich auf ein geodätisches Erdmodell (siehe oben).

Übersicht wichtiger Koordinaten-Referenzsysteme

In der Abbildung 35 unten sind einige wichtige geodätische und kartografische Ausprägungen von Koordinaten-Referenzsystemen dargestellt. Am Anfang der Folge von Koordinatensystemen und Abbildungen steht die Erde. Man versucht dieser ein geometrisches Erdmodell zuzuweisen, um damit Positionen auf ihr zu beschreiben. Zunächst kann man der Erde als Ganzes ein 3-dimensionales kartesisches Koordinatensystem zuordnen mit Nullpunkt im Gravitationszentrum der Erde (siehe Methode (a) im Kapitel Koordinatensysteme weiter oben). In der Folge bearbeitet man allerdings die Lage und die Höhe eines Punktes unabhängig voneinander. Betrachten wir zunächst nur, was zur Bestimmung der Lage zu unternehmen ist: Aus geodätischen Messungen werden die Grösse und die Form eines Rotationsellipsoides bestimmt, das die Erdoberfläche lokal optimal annähert. Diesem Rotationsellipsoid kann nach der Methode (b) im Kapitel Koordinatensysteme ein geodätisches Datum zugeordnet werden. Viele der für nationale Landesvermessungen ausgewählten Erdmodelle sind «lokal» gelagert, d.h. so, dass der Mittelpunkt des Ellipsoides nicht mit dem Gravitationszentrum der Erde (Schwerpunkt, physikalischer Erdmittelpunkt) zusammenfällt. Nun gibt es aber, wie wir oben ((a) im Kapitel Koordinatensysteme) gesehen haben, geodätische Referenzsysteme, welche im Schwerpunkt gelagert sind. Aus diesem Grund ist es heutzutage relativ einfach möglich, die Parameter der Datums-Transformation zu einem solch übergeordneten System zu bestimmen. Hat man sich für ein lokales Rotationsellipsoid entschieden, so kann andererseits dessen Oberfläche je nach Anforderung durch eine geeignete Kartenprojektion in eine Ebene abgebildet werden.

Abbildung 35. Von der Erdoberfläche zu zweidimensionalen Lagekoordinaten.

Datenstruktur für Koordinatensysteme und Abbildungen zwischen diesen

Das vorgeschlagene konzeptionelle Schema für die Daten, welche zur Beschreibung von Koordinatensystemen und von Abbildungen zwischen diesen benötigt werden, beschränkt sich bewusst nicht auf Koordinaten-Referenzsysteme sondern ist allgemein für Koordinatensysteme konzipiert. Denn auch beispielsweise Digitalisiertisch- und Bildschirm-Koordinatensysteme oder Signaturen-Koordinatensysteme ohne expliziten Bezug zur Erdoberfläche sollen beschrieben werden können.

Koordinatensysteme und Abbildungen zwischen diesen sind die beiden Schlüsselkonzepte für die exakte Charakterisierung der räumlichen Referenzierung von Geodaten. Entsprechend weist das konzeptionelle Modell (oder konzeptionelle Schema) der Datenstruktur zwei Hauptgruppen von Klassen auf, nämlich «Coordinate systems for geodetic purposes» und «Mappings between coordinate systems». Die dritte Dimension, Höhe, wird wie folgt bearbeitet: In einem 3-dimensionalen kartesischen Koordinatensystem ist die Höhe implizit integriert als dritte Koordinate. Aber Koordinatensysteme des täglichen Gebrauchs sind normalerweise die Kombination eines 2-dimensionalen Lage-Koordinatensystems und eines zusätzlichen 1-dimensionalen Höhensystems. Die Daten von Koordinatensystemen dieses Typs werden beschrieben durch zwei unabhängige Datensätze, zunächst durch die Daten eines 2-dimensionalen Koordinatensystems (2-dimensional kartesisch oder ellipsoidisch) und zusätzlich durch die Daten eines Höhensystems von passendem Typ (normal, orthometrisch oder ellipsoidisch).

Wie werden mit Hilfe der vorgeschlagenen Datenstrukturen Abbildungen zwischen Koordinatensystemen realisiert? Auf die folgende Art: Koordinatensysteme bilden die Knoten und Abbildungen zwischen ihnen bilden die Kanten in einer Graphenstruktur. Im DOMAIN-Abschnitt eines Anwendungsmodells (Anwendungsschemas) findet man den Namen des verwendeten Koordinatensystems. Sollen nun die gegebenen Koordinaten auf ein anderes Koordinatensystem abgebildet werden oder sind beispielsweise GeoTIFF-Parameter zu berechnen, die einer solchen Abbildung entsprechen, dann hat ein geeignetes Programm in der Graphenstruktur von Koordinatensystemen und Abbildungen den kürzesten Weg zu finden vom Knoten des gegebenen Koordinatensystems (gemäss DOMAIN) zum Knoten des Zielsystems und dann die nötigen Abbildungen zu berechnen, vom Ausgangssystem über evtl. Zwischen-Koordinatensysteme bis zum Zielsystem.

Für die Beschreibung von Koordinatensystemen stellt INTERLIS zwei interne Klassen und Schlüsselwörter zur Verfügung, nämlich: AXIS und COORDSYSTEM. Diese kommen im konzeptionellen Datenmodell (dem Koordinatensystem-Modell oder Koordinatensystem-Schema) "CoordSys" zum Einsatz (siehe unten). Details dazu sind zu finden im Kapitel 3.10.3, “Referenzsysteme”.

Literaturhinweise

[Bugayevskiy 1995] Bugayevskiy, Lev M.; Snyder, John P.: Map Projections, A Reference Manual. Taylor & Francis, London, Bristol, 1995.
[Gubler et al. 1996] Gubler, E.; Gutknecht, D.; Marti, U.; Schneider, D.; Signer, Th.; Vogel, B.; Wiget, A.: Die neue Landesvermessung der Schweiz LV95. VPK 2/96.
[Marti 1997] Marti, Urs: Geoid der Schweiz 1997. Geodätisch-geophysikalische Arbeiten in der Schweiz, Schweizerische Geodätische Kommission, Volume 56, Zürich, 1997.
[Torge 1975] Torge, Wolfgang: Geodäsie. Sammlung Göschen 2163, de Gruyter, Berlin – New York, 1975.
[Snyder 1987] Snyder, John P.: Map Projections – A Working Manual. U.S. Geological Survey Professional Paper 1395, Washington, 1987.
[Voser 1996] Voser, Stefan A.: Anforderungen an die Geometrie zur gemeinsamen Nutzung unterschiedlicher Datenquellen. 4. deutsche Arc/Info-Anwender-Konferenz, Proceedings, März 1996, Freising.
[Voser 1999] Voser, Stefan A.: MapRef – The Internet Collection of Map Projections and Reference Systems for Europe. 14. ESRI European User Conference, Presentation and Proceedings, 15.–17. Nov. 1999, Munich.

https://www.mapref.org/

Das Referenzsystem-Modell

Datenstruktur für Koordinatensysteme und Koordinaten-Referenzsysteme sowie Abbildungen zwischen ihnen. Konzeptionelles Datenmodell (konzeptionelles Schema) mit INTERLIS.

!! File CoordSys.ili Release 2014-07-09
INTERLIS 2.4;

REFSYSTEM MODEL CoordSys (en) AT "http://www.interlis.ch/models/refhb24"
  VERSION "2014-07-09" =

  UNIT
    Angle_Degree = 180 / PI [INTERLIS.rad];
    Angle_Minute = 1 / 60 [Angle_Degree];
    Angle_Second = 1 / 60 [Angle_Minute];
  END UNIT;

  STRUCTURE Angle_DMS_S =
    Degrees: -180 .. 180 CIRCULAR [Angle_Degree];
    CONTINUOUS SUBDIVISION Minutes: 0 .. 59 CIRCULAR [Angle_Minute];
    CONTINUOUS SUBDIVISION Seconds: 0.000 .. 59.999 CIRCULAR [Angle_Second];
  END Angle_DMS_S;

  DOMAIN
    Angle_DMS = FORMAT BASED ON Angle_DMS_S (Degrees ":" Minutes ":" Seconds);
    Angle_DMS_90 EXTENDS Angle_DMS = "-90:00:00.000" .. "90:00:00.000";
  END DOMAIN;

  TOPIC CoordsysTopic =

    !! Special space aspects to be referenced
    !! **************************************

    CLASS Ellipsoid EXTENDS INTERLIS.REFSYSTEM =
      EllipsoidAlias: TEXT*70;
      SemiMajorAxis: MANDATORY 6360000.0000 .. 6390000.0000 [INTERLIS.m];
      InverseFlattening: MANDATORY 0.00000000 .. 350.00000000;
      !! The inverse flattening 0 characterizes the 2-dim sphere
      Remarks: TEXT*70;
    END Ellipsoid;

    CLASS GravityModel EXTENDS INTERLIS.REFSYSTEM =
      GravityModAlias: TEXT*70;
      Definition: TEXT*70;
    END GravityModel;

    CLASS GeoidModel EXTENDS INTERLIS.REFSYSTEM =
      GeoidModAlias: TEXT*70;
      Definition: TEXT*70;
    END GeoidModel;

    !! Coordinate systems for geodetic purposes
    !! ****************************************

    STRUCTURE LengthAXIS EXTENDS INTERLIS.AXIS =
      ShortName: TEXT*12;
      Description: TEXT*255;
      PARAMETER
        Unit (EXTENDED): NUMERIC [INTERLIS.LENGTH];
      END PARAMETER;
    END LengthAXIS;

    STRUCTURE AngleAXIS EXTENDS INTERLIS.AXIS =
      ShortName: TEXT*12;
      Description: TEXT*255;
      PARAMETER
        Unit (EXTENDED): NUMERIC [INTERLIS.ANGLE];
      END PARAMETER;
    END AngleAXIS;

    CLASS GeoCartesian1D EXTENDS INTERLIS.COORDSYSTEM =
      Axis (EXTENDED): LIST {1} OF LengthAXIS;
    END GeoCartesian1D;

    CLASS GeoHeight EXTENDS GeoCartesian1D =
      System: MANDATORY (
        normal,
        orthometric,
        ellipsoidal,
        other
      );
      ReferenceHeight: MANDATORY -10000.000 .. +10000.000 [INTERLIS.m];
      ReferenceHeightDescr: TEXT*70;
    END GeoHeight;

    ASSOCIATION HeightEllips =
      GeoHeightRef -- {*} GeoHeight;
      EllipsoidRef -- {1} Ellipsoid;
    END HeightEllips;

    ASSOCIATION HeightGravit =
      GeoHeightRef -- {*} GeoHeight;
      GravityRef -- {1} GravityModel;
    END HeightGravit;

    ASSOCIATION HeightGeoid =
      GeoHeightRef -- {*} GeoHeight;
      GeoidRef -- {1} GeoIdModel;
    END HeightGeoid;

    CLASS GeoCartesian2D EXTENDS INTERLIS.COORDSYSTEM =
      Definition: TEXT*70;
      Axis (EXTENDED): LIST {2} OF LengthAXIS;
    END GeoCartesian2D;

    CLASS GeoCartesian3D EXTENDS INTERLIS.COORDSYSTEM =
      Definition: TEXT*70;
      Axis (EXTENDED): LIST {3} OF LengthAXIS;
    END GeoCartesian3D;

    CLASS GeoEllipsoidal EXTENDS INTERLIS.COORDSYSTEM =
      Definition: TEXT*70;
      Axis (EXTENDED): LIST {2} OF AngleAXIS;
    END GeoEllipsoidal;

    ASSOCIATION EllCSEllips =
      GeoEllipsoidalRef -- {*} GeoEllipsoidal;
      EllipsoidRef -- {1} Ellipsoid;
    END EllCSEllips;

    !! Mappings between coordinate systems
    !! ***********************************

    ASSOCIATION ToGeoEllipsoidal =
      From -- {0..*} GeoCartesian3D;
      To -- {0..*} GeoEllipsoidal;
      ToHeight -- {0..*} GeoHeight;

      MANDATORY CONSTRAINT
        ToHeight -> System == #ellipsoidal;

      MANDATORY CONSTRAINT
        To -> EllipsoidRef -> Name == ToHeight -> EllipsoidRef -> Name;
    END ToGeoEllipsoidal;

    ASSOCIATION ToGeoCartesian3D =
      From2 -- {0..*} GeoEllipsoidal;
      FromHeight -- {0..*} GeoHeight;
      To3 -- {0..*} GeoCartesian3D;

      MANDATORY CONSTRAINT
        FromHeight -> System == #ellipsoidal;

      MANDATORY CONSTRAINT
        From2 -> EllipsoidRef -> Name == FromHeight -> EllipsoidRef -> Name;
    END ToGeoCartesian3D;

    ASSOCIATION BidirectGeoCartesian2D =
      From -- {0..*} GeoCartesian2D;
      To -- {0..*} GeoCartesian2D;
    END BidirectGeoCartesian2D;

    ASSOCIATION BidirectGeoCartesian3D =
      From -- {0..*} GeoCartesian3D;
      To2 -- {0..*} GeoCartesian3D;
      Precision: MANDATORY (
        exact,
        measure_based
      );
      ShiftAxis1: MANDATORY -10000.000 .. 10000.000 [INTERLIS.m];
      ShiftAxis2: MANDATORY -10000.000 .. 10000.000 [INTERLIS.m];
      ShiftAxis3: MANDATORY -10000.000 .. 10000.000 [INTERLIS.m];
      RotationAxis1: Angle_DMS_90;
      RotationAxis2: Angle_DMS_90;
      RotationAxis3: Angle_DMS_90;
      NewScale: 0.000001 .. 1000000.000000;
    END BidirectGeoCartesian3D;

    ASSOCIATION BidirectGeoEllipsoidal =
      From4 -- {0..*} GeoEllipsoidal;
      To4 -- {0..*} GeoEllipsoidal;
    END BidirectGeoEllipsoidal;

    ASSOCIATION MapProjection (ABSTRACT) =
      From5 -- {0..*} GeoEllipsoidal;
      To5 -- {0..*} GeoCartesian2D;
      FromCo1_FundPt: MANDATORY Angle_DMS_90;
      FromCo2_FundPt: MANDATORY Angle_DMS_90;
      ToCoord1_FundPt: MANDATORY -10000000 .. +10000000 [INTERLIS.m];
      ToCoord2_FundPt: MANDATORY -10000000 .. +10000000 [INTERLIS.m];
    END MapProjection;

    ASSOCIATION TransverseMercator EXTENDS MapProjection =
    END TransverseMercator;

    ASSOCIATION SwissProjection EXTENDS MapProjection =
      IntermFundP1: MANDATORY Angle_DMS_90;
      IntermFundP2: MANDATORY Angle_DMS_90;
    END SwissProjection;

    ASSOCIATION Mercator EXTENDS MapProjection =
    END Mercator;

    ASSOCIATION ObliqueMercator EXTENDS MapProjection =
    END ObliqueMercator;

    ASSOCIATION Lambert EXTENDS MapProjection =
    END Lambert;

    ASSOCIATION Polyconic EXTENDS MapProjection =
    END Polyconic;

    ASSOCIATION Albus EXTENDS MapProjection =
    END Albus;

    ASSOCIATION Azimutal EXTENDS MapProjection =
    END Azimutal;

    ASSOCIATION Stereographic EXTENDS MapProjection =
    END Stereographic;

    ASSOCIATION HeightConversion =
      FromHeight -- {0..*} GeoHeight;
      ToHeight -- {0..*} GeoHeight;
      Definition: TEXT*70;
    END HeightConversion;

  END CoordsysTopic;

END CoordSys.

Die Datei MiniCoordSysData, deren Namen in MetadataBasketDef vorkommen kann, enthält die folgenden Daten im INTERLIS 2-Transferformat.

<?xml version="1.0" encoding="UTF-8"?>
<ili:transfer xmlns:ili="http://www.interlis.ch/xtf/2.4/INTERLIS" xmlns:geom="http://www.interlis.ch/geometry/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.interlis.ch/xtf/2.4/CoordSys">
  <ili:headersection>
    <ili:models>
      <ili:model>CoordSys</ili:model>
    </ili:models>
    <ili:sender>KOGIS</ili:sender>
    <ili:comment>example dataset ili2 refmanual appendix K</ili:comment>
  </ili:headersection>
  <ili:datasection>
    <CoordsysTopic ili:bid="BCoordSys">
      <Ellipsoid ili:tid="BCoordSys.Bessel">
        <ili:Name>Bessel</ili:Name>
        <EllipsoidAlias>Bessel (1841)</EllipsoidAlias>
        <SemiMajorAxis>6377397.1550</SemiMajorAxis>
        <InverseFlattening>299.1528128</InverseFlattening>
        <Remarks>Documentation swisstopo 19031266</Remarks>
      </Ellipsoid>
      <Ellipsoid ili:tid="BCoordSys.ETRS">
        <ili:Name>ETRS</ili:Name>
        <EllipsoidAlias>ETRS 89</EllipsoidAlias>
        <SemiMajorAxis>6378137.000</SemiMajorAxis>
        <InverseFlattening>298.2572235</InverseFlattening>
        <Remarks>EUREF documentation</Remarks>
      </Ellipsoid>
      <GravityModel ili:tid="BCoordSys.SwissGravityNetwork2004">
        <ili:Name>SwissGravityNetwork2004</ili:Name>
        <Definition>See documentation swisstopo Landesschwerenetz</Definition>
      </GravityModel>
      <GravityModel ili:tid="BCoordSys.UEGN2002">
        <ili:Name>UEGN2002</ili:Name>
        <Definition>EGG07 documentation IAG Symposium Series Vol 133</Definition>
      </GravityModel>
      <GeoidModel ili:tid="BCoordSys.CHGeoid2004">
        <ili:Name>CHGeoid2004</ili:Name>
        <Definition>See new Swiss Geoid swisstopo</Definition>
      </GeoidModel>
      <GeoidModel ili:tid="BCoordSys.EGG">
        <ili:Name>EGG</ili:Name>
        <Definition>EGG07 documentation IAG Symposium Series Vol 133</Definition>
      </GeoidModel>
      <GeoHeight ili:tid="BCoordSys.SwissOrthometricAlt">
        <ili:Name>SwissOrthometricAlt</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>h</ShortName>
            <Description>Swiss Orthometric Altitude</Description>
          </LengthAXIS>
        </ili:Axis>
        <System>orthometric</System>
        <ReferenceHeight>373.600</ReferenceHeight>
        <ReferenceHeightDescr>Pierre du Niton</ReferenceHeightDescr>
        <EllipsoidRef ili:ref="BCoordSys.Bessel"/>
        <GeoidRef ili:ref="BCoordSys.CHGeoid2004"/>
        <GravityRef ili:ref="BCoordSys.SwissGravityNetwork2004"/>
      </GeoHeight>
      <GeoHeight ili:tid="BCoordSys.SwissEllipsoidalAlt">
        <ili:Name>SwissEllipsoidalAlt</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>H</ShortName>
            <Description>Swiss Ellipsoidal Altitude</Description>
          </LengthAXIS>
        </ili:Axis>
        <System>ellipsoidal</System>
        <ReferenceHeight>0.000</ReferenceHeight>
        <ReferenceHeightDescr>Sea level</ReferenceHeightDescr>
        <EllipsoidRef ili:ref="BCoordSys.Bessel"/>
        <GeoidRef ili:ref="BCoordSys.CHGeoid2004"/>
        <GravityRef ili:ref="BCoordSys.SwissGravityNetwork2004"/>
      </GeoHeight>
      <GeoHeight ili:tid="BCoordSys.SwissUsualAlt">
        <ili:Name>SwissUsualAlt</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>H</ShortName>
            <Description>Swiss Usual Altitude</Description>
          </LengthAXIS>
        </ili:Axis>
        <System>other</System>
        <ReferenceHeight>373.600</ReferenceHeight>
        <ReferenceHeightDescr>Pierre du Niton</ReferenceHeightDescr>
        <EllipsoidRef ili:ref="BCoordSys.Bessel"/>
        <GeoidRef ili:ref="BCoordSys.CHGeoid2004"/>
        <GravityRef ili:ref="BCoordSys.SwissGravityNetwork2004"/>
      </GeoHeight>
      <GeoHeight ili:tid="BCoordSys.EuropeanNormalAlt">
        <ili:Name>EuropeanNormalAlt</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>H</ShortName>
            <Description>European Normal Altitude</Description>
          </LengthAXIS>
        </ili:Axis>
        <System>normal</System>
        <ReferenceHeight>0</ReferenceHeight>
        <ReferenceHeightDescr>Normaal Amsterdam Peil</ReferenceHeightDescr>
        <EllipsoidRef ili:ref="BCoordSys.ETRS"/>
        <GeoidRef ili:ref="BCoordSys.EGG"/>
        <GravityRef ili:ref="BCoordSys.UEGN2002"/>
      </GeoHeight>
      <GeoCartesian2D ili:tid="BCoordSys.COORD2">
        <ili:Name>COORD2</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>X</ShortName>
            <Description>X-axis</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>Y</ShortName>
            <Description>Y-axis</Description>
          </LengthAXIS>
        </ili:Axis>
        <Definition>Mathematical Cartesian 2D Refsystem</Definition>
      </GeoCartesian2D>
      <GeoCartesian2D ili:tid="BCoordSys.CHLV03">
        <ili:Name>CHLV03</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>Y</ShortName>
            <Description>East-value</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>X</ShortName>
            <Description>North-value</Description>
          </LengthAXIS>
        </ili:Axis>
        <Definition>Swiss Geodetic Cartesian 2D Refsystem 1903</Definition>
      </GeoCartesian2D>
      <GeoCartesian2D ili:tid="BCoordSys.CHLV95">
        <ili:Name>CHLV95</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>Y</ShortName>
            <Description>East-value</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>X</ShortName>
            <Description>North-value</Description>
          </LengthAXIS>
        </ili:Axis>
        <Definition>Swiss Geodetic Cartesian 2D Refsystem 1995</Definition>
      </GeoCartesian2D>
      <GeoCartesian3D ili:tid="BCoordSys.COORD3">
        <ili:Name>COORD3</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>X</ShortName>
            <Description>X-axis</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>Y</ShortName>
            <Description>Y-axis</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>Z</ShortName>
            <Description>Z-axis</Description>
          </LengthAXIS>
        </ili:Axis>
        <Definition>Mathematical Cartesian 3D Refsystem</Definition>
      </GeoCartesian3D>
      <GeoCartesian3D ili:tid="BCoordSys.CH1903">
        <ili:Name>CH1903</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>XC</ShortName>
            <Description>Equator Greenwich</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>YC</ShortName>
            <Description>Equator East</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>ZC</ShortName>
            <Description>North</Description>
          </LengthAXIS>
        </ili:Axis>
        <Definition>Swiss Geodetic Cartesian 3D Refsystem 1903</Definition>
      </GeoCartesian3D>
      <GeoCartesian3D ili:tid="BCoordSys.CH1903+">
        <ili:Name>CH1903+</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>XC</ShortName>
            <Description>Equator Greenwich</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>YC</ShortName>
            <Description>Equator East</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>ZC</ShortName>
            <Description>North</Description>
          </LengthAXIS>
        </ili:Axis>
        <Definition>Swiss Geodetic Cartesian 3D Refsystem 1995</Definition>
      </GeoCartesian3D>
      <GeoCartesian3D ili:tid="BCoordSys.WGS84">
        <ili:Name>WGS84</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>XW</ShortName>
            <Description>Equator Greenwich</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>YW</ShortName>
            <Description>Equator East</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>ZW</ShortName>
            <Description>North</Description>
          </LengthAXIS>
        </ili:Axis>
        <Definition>World Geodetic System 1984</Definition>
      </GeoCartesian3D>
      <GeoCartesian3D ili:tid="BCoordSys.ETRS89">
        <ili:Name>ETRS89</ili:Name>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>XW</ShortName>
            <Description>Equator Greenwich</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>YW</ShortName>
            <Description>Equator East</Description>
          </LengthAXIS>
        </ili:Axis>
        <ili:Axis>
          <LengthAXIS>
            <ShortName>ZW</ShortName>
            <Description>North</Description>
          </LengthAXIS>
        </ili:Axis>
        <Definition>European Terrestrial Reference System 1989</Definition>
      </GeoCartesian3D>
      <GeoEllipsoidal ili:tid="BCoordSys.Switzerland">
        <ili:Name>Switzerland</ili:Name>
        <ili:Axis>
          <AngleAXIS>
            <ShortName>Lat</ShortName>
            <Description>Latitude</Description>
          </AngleAXIS>
        </ili:Axis>
        <ili:Axis>
          <AngleAXIS>
            <ShortName>Long</ShortName>
            <Description>Longitude</Description>
          </AngleAXIS>
        </ili:Axis>
        <Definition>Coordinates on the Swiss Ellipsoid 1903</Definition>
        <EllipsoidRef ili:ref="BCoordSys.Bessel"/>
      </GeoEllipsoidal>
      <ToGeoEllipsoidal>
        <From ili:ref="BCoordSys.CH1903"/>
        <To ili:ref="BCoordSys.Switzerland"/>
        <ToHeight ili:ref="BCoordSys.SwissEllipsoidalAlt"/>
      </ToGeoEllipsoidal>
      <ToGeoCartesian3D>
        <From2 ili:ref="BCoordSys.Switzerland"/>
        <FromHeight ili:ref="BCoordSys.SwissEllipsoidalAlt"/>
        <To3 ili:ref="BCoordSys.CH1903"/>
      </ToGeoCartesian3D>
      <BidirectGeoCartesian3D>
        <From ili:ref="BCoordSys.CH1903"/>
        <To2 ili:ref="BCoordSys.WGS84"/>
        <Precision>measure_based</Precision>
        <ShiftAxis1>674.374</ShiftAxis1>
        <ShiftAxis2>15.056</ShiftAxis2>
        <ShiftAxis3>405.346</ShiftAxis3>
        <RotationAxis1>0:0:0</RotationAxis1>
        <RotationAxis2>0:0:0</RotationAxis2>
        <RotationAxis3>0:0:0</RotationAxis3>
        <NewScale>1.00</NewScale>
      </BidirectGeoCartesian3D>
      <BidirectGeoCartesian3D>
        <From ili:ref="BCoordSys.WGS84"/>
        <To2 ili:ref="BCoordSys.CH1903"/>
        <Precision>measure_based</Precision>
        <ShiftAxis1>-674.374</ShiftAxis1>
        <ShiftAxis2>-15.056</ShiftAxis2>
        <ShiftAxis3>-405.346</ShiftAxis3>
        <RotationAxis1>-0:0:0</RotationAxis1>
        <RotationAxis2>-0:0:0</RotationAxis2>
        <RotationAxis3>-0:0:0</RotationAxis3>
        <NewScale>1.0</NewScale>
      </BidirectGeoCartesian3D>
      <BidirectGeoCartesian3D>
        <From ili:ref="BCoordSys.CH1903+"/>
        <To2 ili:ref="BCoordSys.WGS84"/>
        <Precision>measure_based</Precision>
        <ShiftAxis1>674.374</ShiftAxis1>
        <ShiftAxis2>15.056</ShiftAxis2>
        <ShiftAxis3>405.346</ShiftAxis3>
        <RotationAxis1>0:0:0</RotationAxis1>
        <RotationAxis2>0:0:0</RotationAxis2>
        <RotationAxis3>0:0:0</RotationAxis3>
        <NewScale>1.00</NewScale>
      </BidirectGeoCartesian3D>
      <BidirectGeoCartesian3D>
        <From ili:ref="BCoordSys.WGS84"/>
        <To2 ili:ref="BCoordSys.CH1903+"/>
        <Precision>measure_based</Precision>
        <ShiftAxis1>-674.374</ShiftAxis1>
        <ShiftAxis2>-15.056</ShiftAxis2>
        <ShiftAxis3>-405.346</ShiftAxis3>
        <RotationAxis1>-0:0:0</RotationAxis1>
        <RotationAxis2>-0:0:0</RotationAxis2>
        <RotationAxis3>-0:0:0</RotationAxis3>
        <NewScale>1.0</NewScale>
      </BidirectGeoCartesian3D>
      <BidirectGeoCartesian3D>
        <From ili:ref="BCoordSys.CH1903"/>
        <To2 ili:ref="BCoordSys.ETRS89"/>
        <Precision>measure_based</Precision>
        <ShiftAxis1>674.374</ShiftAxis1>
        <ShiftAxis2>15.056</ShiftAxis2>
        <ShiftAxis3>405.346</ShiftAxis3>
        <RotationAxis1>0:0:0</RotationAxis1>
        <RotationAxis2>0:0:0</RotationAxis2>
        <RotationAxis3>0:0:0</RotationAxis3>
        <NewScale>1.00</NewScale>
      </BidirectGeoCartesian3D>
      <BidirectGeoCartesian3D>
        <From ili:ref="BCoordSys.ETRS89"/>
        <To2 ili:ref="BCoordSys.CH1903"/>
        <Precision>measure_based</Precision>
        <ShiftAxis1>-674.374</ShiftAxis1>
        <ShiftAxis2>-15.056</ShiftAxis2>
        <ShiftAxis3>-405.346</ShiftAxis3>
        <RotationAxis1>-0:0:0</RotationAxis1>
        <RotationAxis2>-0:0:0</RotationAxis2>
        <RotationAxis3>-0:0:0</RotationAxis3>
        <NewScale>1.0</NewScale>
      </BidirectGeoCartesian3D>
      <BidirectGeoCartesian3D>
        <From ili:ref="BCoordSys.CH1903+"/>
        <To2 ili:ref="BCoordSys.ETRS89"/>
        <Precision>measure_based</Precision>
        <ShiftAxis1>674.374</ShiftAxis1>
        <ShiftAxis2>15.056</ShiftAxis2>
        <ShiftAxis3>405.346</ShiftAxis3>
        <RotationAxis1>0:0:0</RotationAxis1>
        <RotationAxis2>0:0:0</RotationAxis2>
        <RotationAxis3>0:0:0</RotationAxis3>
        <NewScale>1.00</NewScale>
      </BidirectGeoCartesian3D>
      <BidirectGeoCartesian3D>
        <From ili:ref="BCoordSys.ETRS89"/>
        <To2 ili:ref="BCoordSys.CH1903+"/>
        <Precision>measure_based</Precision>
        <ShiftAxis1>-674.374</ShiftAxis1>
        <ShiftAxis2>-15.056</ShiftAxis2>
        <ShiftAxis3>-405.346</ShiftAxis3>
        <RotationAxis1>-0:0:0</RotationAxis1>
        <RotationAxis2>-0:0:0</RotationAxis2>
        <RotationAxis3>-0:0:0</RotationAxis3>
        <NewScale>1.0</NewScale>
      </BidirectGeoCartesian3D>
      <TransverseMercator>
        <From5 ili:ref="BCoordSys.Switzerland"/>
        <To5 ili:ref="BCoordSys.CHLV03"/>
        <FromCo1_FundPt>46:57:08.66</FromCo1_FundPt>
        <FromCo2_FundPt>7:26:22.50</FromCo2_FundPt>
        <ToCoord1_FundPt>600000</ToCoord1_FundPt>
        <ToCoord2_FundPt>200000</ToCoord2_FundPt>
      </TransverseMercator>
      <TransverseMercator>
        <From5 ili:ref="BCoordSys.Switzerland"/>
        <To5 ili:ref="BCoordSys.CHLV95"/>
        <FromCo1_FundPt>46:57:08.66</FromCo1_FundPt>
        <FromCo2_FundPt>7:26:22.50</FromCo2_FundPt>
        <ToCoord1_FundPt>2600000</ToCoord1_FundPt>
        <ToCoord2_FundPt>1200000</ToCoord2_FundPt>
      </TransverseMercator>
      <HeightConversion>
        <FromHeight ili:ref="BCoordSys.SwissEllipsoidalAlt"/>
        <ToHeight ili:ref="BCoordSys.SwissOrthometricAlt"/>
      </HeightConversion>
      <HeightConversion>
        <FromHeight ili:ref="BCoordSys.SwissOrthometricAlt"/>
        <ToHeight ili:ref="BCoordSys.SwissEllipsoidalAlt"/>
      </HeightConversion>
    </CoordsysTopic>
  </ili:datasection>
</ili:transfer>

Beispiel

Was müsste innerhalb eines Applikationsmodells (bzw. Applikationsschemas) angegeben werden, um das verwendete Koordinatensystem, bzw. Koordinaten-Referenzsystem eindeutig zu identifizieren?

INTERLIS 2.4;

MODEL Beispiel (de) AT "http://www.interlis.ch/"
  VERSION "2014-08-05" =

  IMPORTS CoordSys;

  REFSYSTEM BASKET BCoordSys ~ CoordSys.CoordsysTopic =
    OBJECTS OF GeoCartesian2D: CHLV03;
    OBJECTS OF GeoHeight: SwissNormalAlt;
  END BCoordSys;

  DOMAIN
    LKoord = COORD
      480000.000 .. 850000.000 [INTERLIS.m] {CHLV03[1]},
      60000.000 .. 320000.000 [INTERLIS.m] {CHLV03[2]}
      ROTATION 2 -> 1;

    Hoehe = COORD
      -200.000 .. 5000.000 [INTERLIS.m] {SwissNormalAlt[1]};

    HKoord = COORD
      480000.000 .. 850000.000 [INTERLIS.m] {CHLV03[1]},
      60000.000 .. 320000.000 [INTERLIS.m] {CHLV03[2]},
      -200.000 .. 5000.000 [INTERLIS.m] {SwissNormalAlt[1]}
      ROTATION 2 -> 1;
  END DOMAIN;

  TOPIC T =

    CLASS Fixpunkt =
      Name: TEXT*20;
      Position: LKoord;
    END Fixpunkt;

  END T;

END Beispiel.

Appendix L: Signaturenmodelle (Standard-Erweiterungsvorschlag)

Bemerkung

Die folgende Spezifikation ist nicht normativer Bestandteil von INTERLIS. Dies ist ein Standard-Erweiterungsvorschlag auf der Basis des INTERLIS 2-Referenzhandbuches im Sinne einer Empfehlung. Es ist geplant, diesen Vorschlag nach einer breiten Diskussion in eine definitive Regelung umzuwandeln. Für Anwendungsbeispiele siehe auch die entsprechenden INTERLIS 2-Benutzerhandbücher.

Abstraktes Signaturenmodell

Beschreibung des abstrakten Signaturenmodells.

!! File AbstractSymbology.ili Release 2014-07-09
INTERLIS 2.4;

SYMBOLOGY MODEL AbstractSymbology (en)
  AT "http://www.interlis.ch/models/refhb24"
  VERSION "2014-07-09" =

  UNIT
    Millimeter [mm] = 0.001 [INTERLIS.m];
    Angle_Degree = 180 / PI [INTERLIS.rad];
  END UNIT;

  DOMAIN
    Style_COORD2 (ABSTRACT) = COORD NUMERIC, NUMERIC;
    Style_COORD3 (ABSTRACT) = COORD NUMERIC, NUMERIC, NUMERIC;

    Style_POLYLINE (ABSTRACT) = POLYLINE WITH (STRAIGHTS, ARCS)
      VERTEX Style_COORD2; !! {Planar}?

    Style_SURFACE (ABSTRACT) = SURFACE WITH (STRAIGHTS, ARCS)
      VERTEX Style_COORD2;

    Style_INT (ABSTRACT) = NUMERIC;  !! [Units?]
    Style_FLOAT (ABSTRACT) = NUMERIC; !! [Units?]

    Style_ANGLE (ABSTRACT) = 0.000 .. 359.999 CIRCULAR [Angle_Degree]
      COUNTERCLOCKWISE; !! RefSystem?
  END DOMAIN;

  TOPIC Signs =

    !! Graphic interface

    CLASS TextSign (ABSTRACT) EXTENDS INTERLIS.SIGN =
      PARAMETER
        Txt: MANDATORY TEXT;
        Geometry: MANDATORY Style_COORD2;
        Rotation: Style_ANGLE;  !! Default 0.0
        HAli: HALIGNMENT;       !! Default Center
        VAli: VALIGNMENT;       !! Default Half
      END PARAMETER;
    END TextSign;

    CLASS SymbolSign (ABSTRACT) EXTENDS INTERLIS.SIGN =
      PARAMETER
        Geometry: MANDATORY Style_COORD2;
        Scale: Style_FLOAT;
        Rotation: Style_ANGLE;  !! Default 0.0
      END PARAMETER;
    END SymbolSign;

    CLASS PolylineSign (ABSTRACT) EXTENDS INTERLIS.SIGN =
      PARAMETER
        Geometry: MANDATORY Style_POLYLINE;
      END PARAMETER;
    END PolylineSign;

    CLASS SurfaceSign (ABSTRACT) EXTENDS INTERLIS.SIGN =
      PARAMETER
        Geometry: MANDATORY Style_SURFACE;
      END PARAMETER;
    END SurfaceSign;

  END Signs;

END AbstractSymbology.

Standard-Signaturenmodell

Beschreibung des auf dem abstrakten Signaturenmodell aufbauenden, erweiterten Standard-Signaturenmodells.

!! File StandardSymbology.ili Release 2016-01-21
INTERLIS 2.4;

SYMBOLOGY MODEL StandardSymbology (en)
  AT "http://www.interlis.ch/models/refhb24"
  VERSION "2016-01-21" =

  !! Extended symbology model with symbol libraries and priorities.
  IMPORTS AbstractSymbology;

  UNIT
    Angle_Degree = 180 / PI [INTERLIS.rad];
  END UNIT;

  DOMAIN
    SS_Priority = 0 .. 9999;
    SS_Float = -2000000000.000 .. 2000000000.000;

    SS_Angle = 0.000 .. 359.999
      CIRCULAR [Angle_Degree] COUNTERCLOCKWISE;

    SS_Coord2 = COORD
      -2000000000.000 .. 2000000000.000 [INTERLIS.m],
      -2000000000.000 .. 2000000000.000 [INTERLIS.m]
      ROTATION 2 -> 1;

    SS_Polyline = POLYLINE WITH (STRAIGHTS, ARCS)
      VERTEX SS_Coord2;

    SS_Surface = SURFACE WITH (STRAIGHTS, ARCS)
      VERTEX SS_Coord2 WITHOUT OVERLAPS > 0.001;
  END DOMAIN;

  TOPIC StandardSigns EXTENDS AbstractSymbology.Signs =

    !! StandardSigns contains symbol libraries and symbol interfaces.
    !! The libraries (colors, fonts/symbols and line patterns) form the
    !! base for the construction of concrete symbols. The symbol interfaces
    !! extend the symbol interfaces of AbstractSymbology by priorites.

    !! Library section
    !! +++++++++++++++
    !! Color library
    !! =============
    !! Colors are defined by LCh values with transparency.

    CLASS Color =
      Name: TEXT*40; !! name of color, i.e. "light green"
      L: MANDATORY 0.0 .. 100.0; !! Luminance
      C: MANDATORY 0.0 .. 181.1; !! Chroma
      H: MANDATORY 0.0 .. 359.9 CIRCULAR [Angle_Degree] COUNTERCLOCKWISE; !! Hue
      T: MANDATORY 0.000 .. 1.000; !! Transparency: 0=totally transparent, 1=opaque
    END Color;

    !! Polyline attributes
    !! +++++++++++++++++++
    !! Presentation parameters for simple continuous lines. Polyline attributes
    !! are used by all other polyline definitions (see below).

    CLASS PolylineAttrs =
      Width: SS_Float;
      Join: ( !! connection form for line segments
        bevel,
        round,
        miter
      );
      MiterLimit: 1.0 .. 1000.0; !! only for Join = miter
      Caps: ( !! termination form at end of line
        round,
        butt
      );
    END PolylineAttrs;

    !! Font- and symbol library
    !! ========================
    !! Symbols are a collection of lines and surfaces. Symbols are
    !! organized in fonts. A font can be either a text font or a symbol
    !! font. If the font is a text font (Type = #text), every symbol
    !! (Character) has an UCS4 code (Unicode) and a spacing parameter assigned.

    STRUCTURE FontSymbol_Geometry (ABSTRACT) =
      !! Basic structure for uniform treatment of all symbol geometries.
    END FontSymbol_Geometry;

    STRUCTURE FontSymbol_Polyline EXTENDS FontSymbol_Geometry =
      Color: REFERENCE TO Color; !! only for symbols
      LineAttrs: REFERENCE TO PolylineAttrs;
      Geometry: MANDATORY SS_Polyline;
    END FontSymbol_Polyline;

    STRUCTURE FontSymbol_Surface EXTENDS FontSymbol_Geometry =
      FillColor: REFERENCE TO Color; !! only for symbols
      Geometry: MANDATORY SS_Surface;
      !! Remark: Has no line symbology, because the boundary is *not* part
      !! of the surface. With FillColor you define only the color of the
      !! surface filling.
    END FontSymbol_Surface;

    CLASS FontSymbol =
      !! All font symbols are defined for size 1.0 and scale 1.0.
      !! The value is measured in user units (i.e. normally [m]).
      Name: TEXT*40; !! Symbol name, if known
      UCS4: 0 .. 4000000000; !! only for text symbols (characters)
      Spacing: SS_Float; !! only for text symbols (characters)
      Geometry: LIST OF FontSymbol_Geometry
        RESTRICTION (FontSymbol_Polyline; FontSymbol_Surface);
    END FontSymbol;

    CLASS Font =
      Name: MANDATORY TEXT*40; !! Font name or name of external font
      Internal: MANDATORY BOOLEAN; !! Internal or external font
      !! Only for internal fonts the geometric
      !! definitions of the symbols is contained
      !! in FontSymbol.
      Type: MANDATORY (
        symbol,
        text
      );
      BottomBase: SS_Float; !! Only for text fonts, measured relative to text
      !! height 1.0
    END Font;

    ASSOCIATION FontAssoc =
      Font -<#> {1} Font;
      Symbol -- {0..*} FontSymbol;
    END FontAssoc;

    !! Line symbology library
    !! ======================
    !! With the line sybology library the user can define continuous, dashed or
    !! patterned lines. It is also possible to define multi line symbologies.
    !! Each line in a multi line symbology can be continuous, dashed or patterned
    !! for itself. The offset indicates the distance from the middle axis. All
    !! are stored in the library relative to the width 1.0. The width can be over
    !! written by the symbology parameter Width in the symbology interface. For
    !! continuous lines the Width parameter defines the total width of the line,
    !! for multi lines the parameter Width scales the attribute value offset.

    CLASS LineStyle (ABSTRACT) =
      Name: MANDATORY TEXT*40;
    END LineStyle;

    CLASS LineStyle_Solid EXTENDS LineStyle =
    END LineStyle_Solid;

    ASSOCIATION LineStyle_SolidColorAssoc =
      Color -- {0..1} Color;
      LineStyle -- {0..*} LineStyle_Solid;
    END LineStyle_SolidColorAssoc;

    ASSOCIATION LineStyle_SolidPolylineAttrsAssoc =
      LineAttrs -- {0..1} PolylineAttrs;
      LineStyle -- {0..*} LineStyle_Solid;
    END LineStyle_SolidPolylineAttrsAssoc;

    STRUCTURE DashRec =
      DLength: SS_Float; !! Length of dash
    END DashRec;

    CLASS LineStyle_Dashed EXTENDS LineStyle =
      Dashes: LIST OF DashRec; !! 1. dash is continuous
      !! 2. dash is not visible
      !! 3. dash is continuous
      !! etc.
    END LineStyle_Dashed;

    ASSOCIATION LineStyle_DashedColorAssoc =
      Color -- {0..1} Color;
      LineStyle_Dashed -- {0..*} LineStyle_Dashed;
    END LineStyle_DashedColorAssoc;

    ASSOCIATION LineStyle_DashedLineAttrsAssoc =
      LineAttrs -- {0..1} PolylineAttrs;
      LineStyle_Dashed -- {0..*} LineStyle_Dashed;
    END LineStyle_DashedLineAttrsAssoc;

    STRUCTURE Pattern_Symbol =
      FontSymbRef: MANDATORY REFERENCE TO FontSymbol;
      ColorRef: REFERENCE TO Color;
      Weight: SS_Float; !! Width for symbol lines
      Scale: SS_Float;  !! Default: 1.0
      Dist: MANDATORY SS_Float; !! Distance along polyline
      Offset: MANDATORY SS_Float; !! Vertical distance to polyline axis
    END Pattern_Symbol;

    CLASS LineStyle_Pattern EXTENDS LineStyle =
      PLength: MANDATORY SS_Float;
      Symbols: LIST OF Pattern_Symbol;
      !! after PLength the pattern is repeated
    END LineStyle_Pattern;

    !! Symbology interface
    !! +++++++++++++++++++
    !! Text interface
    !! ==============

    CLASS TextSign (EXTENDED) =
      Height: MANDATORY SS_Float;
      Weight: SS_Float; !! line width for line fonts
      Slanted: BOOLEAN;
      Underlined: BOOLEAN;
      Striked: BOOLEAN;
      ClipBox: SS_Float; !! Defines a rectangular surface around the text
      !! with distance ClipBox from text.
      PARAMETER
        Priority: MANDATORY SS_Priority;
      END PARAMETER;
    END TextSign;

    ASSOCIATION TextSignFontAssoc =
      Font -<#> {1} Font;
      TextSign -- {0..*} TextSign;

      MANDATORY CONSTRAINT
        Font -> Type == #text;
    END TextSignFontAssoc;

    ASSOCIATION TextSignColorAssoc =
      Color -- {0..1} Color;
      TextSign -- {0..*} TextSign;
    END TextSignColorAssoc;

    ASSOCIATION TextSignClipFontAssoc =
      ClipFont -- {0..1} Font;
      TextSign2 -- {0..*} TextSign;
    END TextSignClipFontAssoc;

    !! Symbol interface
    !! ================

    CLASS SymbolSign (EXTENDED) =
      Scale: SS_Float;
      Rotation: SS_Angle;
      PARAMETER
        Priority: MANDATORY SS_Priority;
      END PARAMETER;
    END SymbolSign;

    ASSOCIATION SymbolSignSymbolAssoc =
      Symbol -- {1} FontSymbol;
      SymbolSign -- {0..*} SymbolSign;
    END SymbolSignSymbolAssoc;

    ASSOCIATION SymbolSignClipSymbolAssoc =
      ClipSymbol -- {0..1} FontSymbol;
      SymbolSign2 -- {0..*} SymbolSign;
    END SymbolSignClipSymbolAssoc;

    ASSOCIATION SymbolSignColorAssoc =
      Color -- {0..1} Color;
      SymbolSign -- {0..*} SymbolSign;
    END SymbolSignColorAssoc;

    !! Polyline interface
    !! ==================

    CLASS PolylineSign (EXTENDED) =
      !! The parameter Width of the interface influences the width *and*
      !! the scale of start- and endsymbols.
      PARAMETER
        Priority: MANDATORY SS_Priority;
        Width: SS_Float; !! Width of line symbology, default = 1.0
      END PARAMETER;
    END PolylineSign;

    ASSOCIATION PolylineSignLineStyleAssoc =
      Style -- {1} LineStyle;
      PolylineSign -- {0..*} PolylineSign;
      ATTRIBUTE
        Offset: SS_Float; !! Default 0.0
      END ATTRIBUTE;
    END PolylineSignLineStyleAssoc;

    ASSOCIATION PolylineSignColorAssoc =
      Color -- {0..1} Color;
      PolylineSign -- {0..*} PolylineSign;
    END PolylineSignColorAssoc;

    ASSOCIATION PolylineSignClipStyleAssoc =
      ClipStyle -- {0..1} LineStyle; !! Used as a mask for clipping
      PolylineSign2 -- {0..*} PolylineSign;
    END PolylineSignClipStyleAssoc;

    ASSOCIATION PolylineSignStartSymbolAssoc =
      StartSymbol -- {0..1} SymbolSign; !! Symbol at start of line in opposite
      !! direction of line
      PolylineSign -- {0..*} PolylineSign;
    END PolylineSignStartSymbolAssoc;

    ASSOCIATION PolylineSignEndSymbolAssoc =
      EndSymbol -- {0..1} SymbolSign; !! Symbol at end of line in same
      !! direction as line
      PolylineSign3 -- {0..*} PolylineSign;
    END PolylineSignEndSymbolAssoc;

    !! Surface interface
    !! =================

    CLASS SurfaceSign (EXTENDED) =
      Clip: (
        inside,
        outside
      );
      HatchOffset: SS_Float;
      PARAMETER
        Priority: MANDATORY SS_Priority;
        HatchAng: SS_Angle;  !! Default 0.0
        HatchOrg: SS_Coord2; !! Default 0.0/0.0, Anchor point for hatching
        !! or filling
      END PARAMETER;
    END SurfaceSign;

    ASSOCIATION SurfaceSignColorAssoc =
      FillColor -- {0..1} Color; !! Fill color
      SurfaceSign -- {0..*} SurfaceSign;
    END SurfaceSignColorAssoc;

    ASSOCIATION SurfaceSignBorderAssoc =
      Border -- {0..1} PolylineSign; !! Border symbology
      SurfaceSign -- {0..*} SurfaceSign;
    END SurfaceSignBorderAssoc;

    ASSOCIATION SurfaceSignHatchSymbAssoc =
      HatchSymb -- {0..1} PolylineSign; !! Hatch symbology
      SurfaceSign2 -- {0..*} SurfaceSign;
    END SurfaceSignHatchSymbAssoc;

  END StandardSigns;

END StandardSymbology.

Beispiel

Vgl. Appendix E, Das kleine Beispiel Roads (informativ).

INTERLIS Referenzhandbuch

Vorwort

1. Einleitung

1.1. Status

1.2. Vorwort

Erweiterungen von INTERLIS 2.4 gegenüber INTERLIS 2.3

Erweiterungen von INTERLIS 2 gegenüber INTERLIS 1

Ausblick

Anmerkung zur Version 2.1.0

2. Grundprinzipien

2.1. Übersicht

2.2. Nutzung von Modellen

2.3. Gliederung in Modelle und Thema

2.4. Objekt-Konzept

2.4.1. Objekte und Klassen

2.4.2. Klassenerweiterung

2.4.3. Meta-Modelle und Meta-Objekte

2.4.4. Beziehungen zwischen Objekten

2.4.5. Behälter, Replikation und Datentransfer

2.5. Sichten-Konzept

2.6. Grafik-Konzept

2.7. Dienste, Werkzeugfähigkeit und Konformität

2.8. Umgang mit Rundung von numerischen Werten und Koordinaten

2.9. Das kleine Beispiel Roads als Einstieg

2.10. Weitere Gliederung des Referenzhandbuchs

3. Beschreibungssprache

3.1. Verwendete Syntax

3.2. Grundsymbole der Sprache

3.2.1. Zeichenvorrat, Zwischenräume und Zeilenenden

3.2.2. Namen

3.2.3. Zeichenketten

3.2.4. Zahlen

3.2.5. Eigenschaftsmengen

3.2.6. Erläuterungen

3.2.7. Sonderzeichen und reservierte Wörter

3.2.8. Kommentare

3.2.8.1. Zeilenkommentar

3.2.8.2. Blockkommentar

3.3. Hauptregel

3.4. Vererbung

3.5. Modelle, Themen, Klassen

3.5.1. Modelle

3.5.2. Themen

3.5.3. Klassen und Strukturen

3.5.4. Namensräume

3.6. Attribute

3.6.1. Allgemeine Aussagen zu Attributen

3.6.2. Attribute mit Wertebereichen als Typ

3.6.3. Referenzattribute

3.6.4. Strukturattribute

3.7. Eigentliche Beziehungen

3.7.1. Beschreibung von Beziehungen

3.7.2. Stärke der Beziehung

3.7.3. Kardinalität

3.7.4. Geordnete Beziehungen

3.7.5. Beziehungszugänge

3.8. Wertebereiche und Konstanten

3.8.1. Zeichenketten

3.8.2. Aufzählungen

3.8.3. Textausrichtungen

3.8.4. Boolean

3.8.5. Numerische Datentypen

3.8.6. Formatierte Wertebereiche

3.8.7. Datum und Zeit

3.8.8. Koordinaten

3.8.9. Wertebereiche von Objektidentifikationen

3.8.10. Gefässe

3.8.11. Wertebereiche von Klassen und Attributpfaden

3.8.12. Linienzüge

3.8.12.1. Geometrie des Linienzugs

3.8.12.2. Linienzug mit Strecken und Kreisbogen als vordefinierte Kurvenstücke

3.8.12.3. Weitere Kurvenstück-Formen

3.8.13. Einzelflächen und Gebietseinteilungen

3.8.13.1. Geometrie von Flächen

3.8.13.2. Einzelflächen

3.8.13.3. Flächen einer Gebietseinteilung

3.8.13.4. Erweiterbarkeit

3.9. Einheiten

3.9.1. Basiseinheiten

3.9.2. Abgeleitete Einheiten