Das vorliegende Dokument ist eine Kopie des Standards eCH-0031 INTERLIS 2-Referenzhanduch Version 2.0. 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.

Hinweis
Als Ergänzung zu den Ankern vor den Kapitel und Unterkapiteln wurden, wo sinnvoll, zusätzliche Anker bei den Codeblöcken (EBNF) eingearbeitet. Diese sind durch das Zeichen ※ gekennzeichnet.

1. Grundprinzipien

Kapitel 1 steht, bis auf die verwendeten Grafiken, noch nicht online zur Verfügung.

refhb24 fig1
Figur 1. Datentransfer zwischen verschiedenen Datenbanken über gemeinsames Datenmodell (Datenschema) beschrieben mit gemeinsamer Datenbeschreibungssprache.
refhb24 fig2
Figur 2. Spezialisierung der Modellierung eines Konzepts von Stufe Bund über kantonale (länderspezifische) bis lokale Stufe.
refhb24 fig3
Figur 3. Vererbungs-Hierarchie von Adresse, Person und Gebäude.
refhb24 fig4
Figur 4. Nachführung in der Primär-Datenbank und anschliessende Nachlieferung an Sekundär-Datenbanken (ein doppelter Pfeil bedeutet inkrementelle Nachlieferung).
refhb24 fig5
Figur 5. Grafikdefinitionen, die einerseits auf Daten und Sichten und andererseits auf Signaturen aufbauen, um da-raus eine Grafik zu erzeugen (abstrahierte Darstellung).
refhb24 fig6
Figur 6. Die verschiedenen Einsatzgebiete von INTERLIS (ein doppelter Pfeil bedeutet inkrementelle Nachlieferung).
refhb24 fig7
Figur 7. Das kleine Beispiel Roads.

2. Beschreibungssprache

2.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 2.2.2 Namen). Von der Bedeutung her ist der Name jedoch ein Klassenname. "Class" wird damit quasi zu einem Kommentar.

2.2. Grundsymbole der Sprache

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

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

2.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 2.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 2.5.4 Namensräume beschrieben.

2.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
             } '"'.

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

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

2.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 // '//'.

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

2.2.8. Kommentare

Es werden zwei Kommentarformen angeboten:

2.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
2.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 */

2.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 }.

2.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 2.2.5 Eigenschaftsmengen).

2.5. Modelle, Themen, Klassen

2.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 2.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 2.16 Darstellungsbeschreibungen und Kapitel 2.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 3 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 2.8.1 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 3.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 3 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 3.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.

2.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 2.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 2.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 2.8.8 Koordinaten).

2.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 2.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 2.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 2.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 2.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' ClassOrStructureRef ] '='
             [ ( '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 ).

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

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

2.6. Attribute

2.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 2.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
                     [ ':=' Factor { ',' Factor } ] ';'.

Wird der Attributwert mittels eines Faktors (vgl. Kapitel 2.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 2.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 } ')' ].

RestrictedClassOrStructureRef = ( ClassOrStructureRef | 'ANYSTRUCTURE' )
                                    [ 'RESTRICTION' '(' ClassOrStructureRef
                                      { ';' ClassOrStructureRef } ')' ].

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.

2.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 2.8 Wertebereiche und Konstanten aufgeführt.

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

2.6.4. Strukturattribute

Die Werte von Strukturattributen bestehen aus einem oder mehreren Strukturelementen (Instanzen von Strukturen; vgl. Kapitel 2.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 (vgl. Kapitel 2.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 2.7.3 Kardinalität).

2.7. Eigentliche Beziehungen

2.7.1. Beschreibung von Beziehungen

Eigentliche Beziehungen (im Gegensatz zu Referenzattributen; vgl. Kapitel 2.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 2.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 2.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 2.15 Sichten).

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

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

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

2.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 2.7.1 Beschreibung von Beziehungen und Kapitel 2.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 2.13 Ausdrücke).

2.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 2.8.5 Numerische Datentypen).

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

2.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 2.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 2.10.3 Referenzsysteme und Kapitel 2.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.

2.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
refhb24 fig8
Figur 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 2.13 Ausdrücke, Kapitel 2.14 Funktionen und Kapitel 2.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

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.

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

refhb24 fig9
Figur 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' ).

2.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'.

2.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 2.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. Man beachte dabei folgende Situation:

DOMAIN
  Normal = 0.00 .. 7.99;
  Genau EXTENDS Normal = 0.0000 .. 7.9949;    !! richtig, da auch
                                              !! Normal darstellbar
  Genau EXTENDS Normal = 0.0000 .. 7.9999;    !! falsch, da gerundet
                                              !! ausserhalb Normal

Um die Bedeutung des Wertes genauer zu erklären kann eine Masseinheit angegeben werden (vgl. Kapitel 2.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 2.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 2.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 ']' ].

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

2.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;

2.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 2.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 3.3.6 Codierung von Themen). Die Tatsache, dass die Festlegung aufgeschoben ist, muss beim Thema angemerkt werden (vgl. Kapitel 2.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;

2.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 2.5.2 Themen und Kapitel 2.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 3.3.1 erfüllen: erstes Zeichen muss ein Buchstabe, eine Ziffer oder ein Unterstrich sein, dann folgen Buchstaben, Ziffern, Punkte, Minuszeichen, Unterstriche; keine Doppelpunkte (!).

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

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

2.8.12. Linienzüge

2.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 Figuren 10 und 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.

refhb24 fig10
Figur 10. Beispiele von ebenen Kurvenstücken.
refhb24 fig11
Figur 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 Figuren 12 und 13). Ein einfacher Linienzug weist keinerlei Selbst-Schnittpunkte auf (siehe Figur 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.

refhb24 fig12
Figur 12. Beispiele von (ebenen) Linienzügen.
refhb24 fig13
Figur 13. Beispiele von ebenen Mengen, die nicht Linienzüge sind (ein doppelter Kreis bedeutet hier "nicht stetig" und der Rhombus "nicht Bild eines Intervalls").
refhb24 fig14
Figur 14. Beispiele von (ebenen) einfachen Linienzügen.
2.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 3.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 2.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 2.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 beschrieben. Dieser ist nur in der Lage von Bedeutung. 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. Der Zwischenpunkt ist kein Stützpunkt des Linienzuges. Er soll möglichst exakt in der Mitte zwischen Anfangs- und Endpunkt liegen. Der Zwischenpunkt wird mindestens in der gleichen Genauigkeit angegeben (Anzahl Nachkommastellen) wie die Stützpunkte. Um numerische Probleme (vgl. unten) zu vermeiden, sollen Stützpunkte möglichst mit zusätzlicher Genauigkeit transferiert werden. Dennoch kann der berechnete Radius erheblich vom effektiven Radius abweichen. 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. Der Zwischenpunkt darf aber auch in diesem Fall um höchstens 1 Genauigkeitseinheit (der Wert 1 der hintersten Stelle gemäss Wertebereichsdefinition; z.B. 0.001 bei Koordinaten mit 3 Nachkommastellen) von der Spur des aus dem Radius gerechneten Kreisbogens abweichen. Aus fachlicher Sicht soll oft ausgedrückt werden, dass es sich bei einem Linienzug um einen einfachen Linienzug handelt, d.h. anschaulich, dass er sich nicht mit sich selbst schneiden darf und insbesondere mehrfache Benützung desselben Kurvenstücks ausgeschlossen ist (Schlüsselwort WITHOUT OVERLAPS). Dieses Anliegen wird auch durch verschiedene konkrete Systeme unterstützt. Dabei besteht allerdings das technische Problem, dass in Grenzsituationen (insbesondere im Zusammenhang mit Kreisbogen) unterschiedliche Systeme auf Grund unterschiedlicher Rechengenauigkeiten und unterschiedlicher Berechnungsweisen zu unterschiedlichen Resultaten bezüglich Überschneidung kommen. Es muss also damit gerechnet werden, dass ein System kleine Überlappungen akzeptiert oder umgekehrt Überlappungen reklamiert, obwohl ein anderes System zu anderen Schlüssen kommt. "Klein" heisst dabei, dass die potentielle Überlappung 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].

Aus fachlicher Sicht kann es vor allem bei der Übernahme von Daten, die ursprünglich grafisch erfasst wurden, auch Sinn machen, grössere Überlappungen (z.B. einige Zentimeter) zu tolerieren, um einen enormen Nachbearbeitungsaufwand zu vermeiden.

Um beide Anliegen zu unterstützen, wird die Überlappungsfreiheit wie folgt geregelt:

Wenn ein Kreisbogen und eine Strecke (bzw. ein anderer Kreisbogen) als aufeinander folgende Kurvenstücke eines Linienzuges neben dem gemeinsamen Stützpunkt auch noch einen inneren Punkt (keinen Stützpunkt) gemeinsam haben, so ist das auch bei einem einfachen Linienzug erlaubt, 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 Bedeutung wie diejenige der Stützpunktkoordinaten erfolgen und einen Wert grösser Null aufweisen.

refhb24 fig15
Figur 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.

Bei Einzelflächen und Gebietseinteilung ist die Überlappungsfreiheit zwingend. Bei Verwendung der impliziten Toleranz kann deshalb auf WITHOUT OVERLAPS verzichtet werden.

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 2.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. Mittels der Existenzbedingung REQUIRED IN (vgl. Kapitel 2.12 Konsistenzbedingungen und Kapitel 2.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;
2.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 2.8.12.2 Linienzug mit Strecken und Kreisbogen als vordefinierte Kurvenstücke).

2.8.13. Einzelflächen und Gebietseinteilungen

2.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 Figur 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 Figur 19). Soweit diese Bedingung nicht verletzt wird, dürfen sich Ränder in Stützpunkten berühren. In solchen Situationen kann man sich verschiedene Möglichkeiten vorstellen, wie die Umrandung der Fläche als Ganzes in einzelne Linienzüge aufgeteilt wird (siehe Figur 22). INTERLIS macht keine Vorschriften, welche Möglichkeit gewählt wird. Wird eine solche Fläche mehrmals transferiert, dürfen in den verschiedenen Übertragungen auch unterschiedliche Aufteilungen vorkommen.

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 Figuren 16 und 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 Figuren 18, 19 und 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 Figur 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 Figur 22).

refhb24 fig16
Figur 16. Beispiele von Flächenelementen.
refhb24 fig17
Figur 17. Beispiele von Punktmengen im Raum, die nicht Flächenelemente sind (ein doppelter Kreis bedeutet hier "nicht glatt").
refhb24 fig18
Figur 18. Beispiele von Flächen im Raum.
refhb24 fig19
Figur 19. Beispiele ebener Punktmengen, die nicht Flächen sind (ein doppelter Kreis bedeutet "singulärer Punkt").
refhb24 fig20
Figur 20. Ebene Fläche mit Rändern und Enklaven.
refhb24 fig21
Figur 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).
refhb24 fig22
Figur 22. Verschiedene mögliche Aufteilungen des Randes einer allgemeinen Fläche.

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.

refhb24 fig23
Figur 23. Nicht erlaubte Linien von Flächen.
2.8.13.2. Einzelflächen
refhb24 fig24
Figur 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 Figur 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.

2.8.13.3. Flächen einer Gebietseinteilung
refhb24 fig25
Figur 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 der geometrische Attributtyp AREA zur Verfügung.

Jedem Gebietsobjekt ist höchstens eine Fläche der Gebietseinteilung (oder genau eine mit Zusatz-Schlüsselwort MANDATORY), nicht aber die Restfläche, zugeordnet. Es ist nicht zulässig, dass zwei Flächen der Gebietseinteilung mit einem gemeinsamen Rand je keinem Gebietsobjekt entsprechen.

Jedes einzelne Gebietsobjekt entspricht damit einer Einzelfläche. Für Gebietsobjekte ergibt sich damit auch die gleiche implizite Struktur wie für Einzelflächen. Zusätzlich gelten aber Konsistenzbedingungen:

  • Linienzüge einer Gebietseinteilung müssen immer echte Grenzlinien sein. Es dürfen also keine Linienzüge existieren, bei denen auf beiden Seiten die gleiche Fläche liegt (siehe Figur 23). Dies ist auch durch die Definition der Fläche ausgeschlossen.

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

Gebietseinteilungen dürfen nicht innerhalb von Unterstrukturen vorkommen.

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

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

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

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

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

2.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 );
Syntaxtegeln
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.

2.10. Umgang mit Metaobjekten

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

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

2.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 2.8.5 Numerische Datentypen) oder eines Koordinatentyps (vgl. Kapitel 2.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 2.10.3 Referenzsysteme) verträglich ist.

2.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 2.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 ] ) ';'.

2.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 2.10.2 Parameter und Kapitel 2.5.3 Klassen und Strukturen). Die in einem Wertebereich definierte Einheit muss dann mit ihr verträglich sein (vgl. Kapitel 2.9 Einheiten).

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

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

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 2.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' ';'.

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

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

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 2.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 2.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 2.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 2.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 2.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 2.14 Funktionen). Damit sind immer alle Objekte gemeint, die dieser Klasse oder ihren Erweiterungen entsprechen.

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

2.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 Faktoren (Regel Factor) 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 2.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 2.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 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");

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

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 2.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 2.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>
                           ':=' Factor ';' }.

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.

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 2.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;

2.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 Figur 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 2.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 2.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.

3. Sequentieller Transfer

Kapitel 3 steht noch nicht online zur Verfügung.


1. Das ist keine konzeptionelle Festlegung, zur Vereinfachung wird sie hier aber ermöglicht.
2. (Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. http://www.iana.org/assignments/character-sets
3. Namespaces in XML 1.0 (Third Edition), Tim Bray et al., eds., W3C, 8 December 2009. http://www.w3.org/TR/REC-xml-names
4. Das ist keine konzeptionelle Festlegung, zur Vereinfachung wird sie hier aber ermöglicht.
5. EPSG Geodetic Parameter Dataset. https://epsg.org