Ilivalidator ist ein in Java erstelltes Programm, das eine Interlis-Transferdatei (itf oder xtf) gemäss einem Interlis-Modell (ili) überprüft.
Es bestehen u.a. folgende Konfigurationsmöglichkeiten:
- einzelne Prüfungen ein oder auszuschalten
- eigene Fehlermeldungen inkl. Attributwerte zu definieren
- zusätzliche Bedingung zu definieren
- zusätzliche INTERLIS-Funktionen zu implementieren
- Modellnamen zu setzen
Zusätzlich umfasst der IliValidator Hilfsfunktionen betrf. Daten (z.B. Kataloge) in einem Repository.
Die Log-Meldungen sollen dem Benutzer zeigen, was das Programm macht. Am Anfang erscheinen Angaben zur Programm-Version. Falls das Programm ohne Fehler durchläuft, wird das am Ende ausgegeben.:
Info: ilivalidator-1.0.0 ... Info: compile models... ... Info: ...validation done
Bei einem Fehler wird das am Ende des Programms vermerkt. Der eigentliche Fehler wird aber in der Regel schon früher ausgegeben.:
Info: ilivalidator-1.0.0 ... Info: compile models... ... Error: DM01.Bodenbedeckung.BoFlaeche_Geometrie: intersection tids 48, 48 ... Error: ...validation failed
Das Programm setzt Java 1.6 voraus.
Zur Validierung wird RAM benötigt. Für eine typische Transferdatei sollten
ca. 2 GB RAM ausreichen. Am Anfang des Logs steht, wieviel RAM (heapspace)
dem Programm zur Verfügung steht. Sollte das Programm mit einer Heapspace
Fehlermeldung abbrechen, kann mittels Java-Option versucht werden, mehr RAM
bereitzustellen (Für 3 GB z.B. java -Xmx3072m -jar ilivalidator.jar data.xtf).
Grundsätzlich ist nicht die Grösse der Datei kritisch, sondern andere Dinge
z.B. wieviele Objekte miteinander in Beziehung stehen, oder wieviele
Objekte bei UNIQUE Bedingungen geprüft werden müssen, aus wievielen
Rändern die Polygone bestehen, usw.
Der ilivalidator wird auch von anderen Programmen verwendet (z.B. ili2fgdb). Für die Validierung wird im ilivalidator und im anderen Programm (z.B. ili2fgdb) der selbe Code verwendet. Der gemeisame Nenner ist iox-ili. Man muss also die Version von iox-ili vergleichen, um allenfalls die Validierung aufeinander abstimmen zu können (am Anfang des Logs zeigen beide Programme auch die Version von iox-ili, und sonst steht es normalerweise im changelog.txt des jeweiligen Programms.) z.B.
- ili2fgdb-4.4.5 benutzt iox-ili-1.21.4
- ilivalidator-1.11.9 benutzt iox-ili-1.21.4
Grundsätzlich sollten die Daten natürlich gültig sein gegenüber der Spezifikation (also dem INTERLIS-Referenzhandbuch und dem Minimalen Geodatenmodell).
GNU Lesser General Public License
In den folgenden Abschnitten wird die Funktionsweise anhand einzelner Anwendungsfälle beispielhaft beschrieben. Die detaillierte Beschreibung einzelner Funktionen ist im Kapitel „Referenz“ zu finden.
Je nach Betriebssystem kann das Programm auch einfach durch Doppelklick mit linker Maustaste
auf `ilivalidator.jar` gestartet werden.
Es wird eine INTERLIS 1-Datei validiert/geprüft.
java -jar ilivalidator.jar path/to/data.itf
Es wird eine INTERLIS 2-Datei inkl. den Referenzen auf den Katalog validiert/geprüft.
java -jar ilivalidator.jar --allObjectsAccessible ilidata:catalogDatasetId path/to/data.itf
Es wird eine INTERLIS 2-Datei mit einer spezifischen Konfiguration validiert/geprüft.
java -jar ilivalidator.jar --config config.ini path/to/data.xtf
In der Datei config.ini wird definiert, welche Prüfungen gar nicht durchzuführen oder bei Nichterfüllen nur als Warnung zu melden sind.
Es wird eine INTERLIS 2-Datei validiert/geprüft, wobei die Fehlermeldungen in eine Text-Datei geschrieben werden.
java -jar ilivalidator.jar --log result.log path/to/data.xtf
Die Fehlermeldungen inkl. Warnungen werden in die Datei result.log geschrieben.
Es wird eine INTERLIS 2-Datei validiert/geprüft, wobei die Fehlermeldungen als Daten in eine Xtf-Datei geschrieben werden.
java -jar ilivalidator.jar --xtflog result.xtf path/to/data.xtf
Die Fehlermeldungen inkl. Warnungen werden in die Datei result.xtf geschrieben. Die Datei result.xtf entspricht dem Modell IliVErrors und kann als normale INTERLIS 2-Transferdatei importiert werden. Dadurch können die Fehler visualisiert werden.
Es erscheint eine Bildschirmmaske, mit deren Hilfe die zu validierende Datei ausgewählt und die Validierung gestartet werden kann.
java -jar ilivalidator.jar
Es wird eine INTERLIS 2-Datei validiert/geprüft. Wobei spezifische Modelle gesetzt werden. Dazu wird der Pfad zu den spezifischen Modellen gesetzt.
java -jar ilivalidator.jar --models modelname1;modelname2 --modeldir path/to/data path/to/data.xtf
Es werden alle Dateien (ITF und XTF) im gegebenen Repository geprüft/validiert.
java -jar ilivalidator.jar --check-repo-data http://models.geo.admin.ch
Es werden alle Dateien (ITF und XTF) im gegebenen Verzeichnis folder analysiert
und dann ein neues newIlidata.xml mit den entsprechenden Metadaten erstellt.
java -jar ilivalidator.jar --createIliData --ilidata newIlidata.xml --repos folder
Es werden alle Dateien (ITF und XTF) gemäss Dateiliste files.txt
im Repository http://models.geo.admin.ch analysiert
und dann ein neues newIlidata.xml mit den entsprechenden Metadaten erstellt.
java -jar ilivalidator.jar --createIliData --ilidata newIlidata.xml --repos http://models.geo.admin.ch --srcfiles files.txt
Es wird die gegebene Datei newVersionOfData.xml (ITF oder XTF)
analysiert, und dann das ilidata.xml aus dem gegebenen Repository
http://models.geo.admin.ch mit einem neuen Eintrag für
den Datensatz mit der ID datasetId aktualisiert. Die neue Version des
ilidata.xml wird in die Datei updatedIlidata.xml geschrieben und muss
durch den Benutzer ins Repository übertragen werden.
java -jar ilivalidator.jar --updateIliData --ilidata updatedIlidata.xml --repos http://models.geo.admin.ch --datasetId datasetId newVersionOfData.xml
In den folgenden Abschnitten werden einzelne Aspekte detailliert, aber isoliert, beschrieben. Die Funktionsweise als Ganzes wird anhand einzelner Anwendungsfälle beispielhaft im Kapitel „Funktionsweise“ (weiter oben) beschrieben.
java -jar ilivalidator.jar [Options] [file]
file kann auch die Form ilidata:DatesetId oder ilidata:BasketId haben,
dann wird die entsprechende Datei aus den Repositories benutzt.
Ohne Kommandozeilenargumente erscheint die Bildschirmmaske, mit deren Hilfe die zu validierende Datei ausgewählt und die Validierung gestartet werden kann.
Der Rückgabewert ist wie folgt:
- 0 Validierung ok, keine Fehler festgestellt
- !0 Validierung nicht ok, Fehler festgestellt
Optionen:
| Option | Beschreibung |
|---|---|
--config filename |
Konfiguriert die Datenprüfung mit Hilfe einer INI-Datei.
<categories>
<DatasetIdx16.Code_>
<value>http://codes.interlis.ch/type/ilivalidatorconfig</value> <!-- Hinweis, dass es eine ilivalidator Config-Datei ist. -->
</DatasetIdx16.Code_>
<DatasetIdx16.Code_>
<value>http://codes.interlis.ch/model/Simple23</value> <!-- Hinweis auf des ili-Modell Simple23 -->
</DatasetIdx16.Code_>
</categories> |
--metaConfig filename |
Konfiguriert den Validator mit Hilfe einer INI-Datei.
<categories>
<DatasetIdx16.Code_>
<value>http://codes.interlis.ch/type/metaconfig</value> <!-- Hinweis, dass es eine Meta-Config-Datei ist. -->
</DatasetIdx16.Code_>
<DatasetIdx16.Code_>
<value>http://codes.interlis.ch/model/Simple23</value> <!-- Hinweis auf des ili-Modell Simple23 -->
</DatasetIdx16.Code_>
</categories> |
--forceTypeValidation |
Ignoriert die Konfiguration der Typprüfung aus der INI-Datei, d.h. es kann nur die Multiplizität aufgeweicht werden. |
--disableAreaValidation |
Schaltet die AREA Topologieprüfung aus (XTF). |
--disableConstraintValidation |
Schaltet die Constraint prüfung aus. |
--allObjectsAccessible |
Mit der Option nimmt der Validator an, dass er Zugriff auf alle Objekte hat. D.h. es wird z.B. auch die Multiplizität von Beziehungen auf externe Objekte geprüft. |
--multiplicityOff |
Schaltet die Prüfung der Multiplizität generell aus. |
--runtimeParams param=value |
Definiert Werte für Laufzeitparameter (RunTimeParameterDef). Mehrere Laufzeitparameter werden durch Semikolon ‚;‘ getrennt. Als Parametername muss der qualifizierte Namen verwendet werden.
Beispiel: --runtimeParams ModelA.Param1=testValue1;ModelB.Param2=testValue2 |
--singlePass |
Schaltet alle Prüfungen aus, die nicht unmittelbar beim Ersten Lesen der Objekte ausgeführt werden können. |
--skipPolygonBuilding |
Schaltet die Bildung der Polygone aus (nur ITF). |
--allowItfAreaHoles |
Lässt bei ITF AREA Attributen innere Ränder zu, die keinem Objekt zugeordnet sind. |
--models modelnames |
Setzt spezifische Modellnamen, welche sich innerhalb von ili-Dateien befinden. Mehrere Modellnamen können durch Semikolon ‚;‘ getrennt werden. Das Setzen des Pfades, der zu den Modellen führt, muss mittels '--modeldir path' angegeben werden. |
--modeldir path |
Dateipfade, die Modell-Dateien (ili-Dateien) enthalten. Mehrere Pfade können durch Semikolon ‚;‘ getrennt werden. Es sind auch URLs von Modell-Repositories möglich. Default ist %ITF_DIR;http://models.interlis.ch/;%JAR_DIR/ilimodels %ITF_DIR ist ein Platzhalter für das Verzeichnis mit der Transferdatei. %JAR_DIR ist ein Platzhalter für das Verzeichnis des ilivalidator Programms (ilivalidator.jar Datei). Der erste Modellname (Hauptmodell), zu dem ili2db die ili-Datei sucht, ist nicht von der INTERLIS-Sprachversion abhängig. Es wird in folgender Reihenfolge nach einer ili-Datei gesucht: zuerst INTERLIS 2.3, dann 1.0 und zuletzt 2.2. Beim Auflösen eines IMPORTs wird die INTERLIS Sprachversion des Hauptmodells berücksichtigt, so dass also z.B. das Modell Units für ili2.2 oder ili2.3 unterschieden wird. |
--check-repo-data repositoryUrl |
Es werden alle Daten (ITF und XTF) im gegebenen Repository geprüft/validiert. (Alle aktuellen Daten (gemäss precursorVersion)) |
--createIliData
--ilidata ilidata.xml
--repos repository |
Es werden alle Daten (ITF und XTF) im gegebenen Folder/Repository analysiert und dann ein neues ilidata.xml mit den entsprechenden Metadaten erstellt. Wenn repository ein remote Repository bezeichnet, muss mit --srcfiles die Liste der Dateien angegeben werden. |
--srcfiles files.txt |
Liste mit relativen Dateipfaden (relativ zum gegebenen Folder/Repository). Ein Pfad pro Zeile. |
--updateIliData
--ilidata updatedIlidata.xml
--repos repository
--dataset datasetId
newVersionOfData.xml |
Es wird die gegebene Datei newVersionOfData.xml (ITF oder XTF) analysiert, und dann das ilidata.xml aus dem gegebenen Repository repository mit einem neuen Eintrag für den Datensatz mit der ID datasetId aktualisiert. Die neue Version des ilidata.xml wird in die Datei updatedIlidata.xml geschrieben und muss durch den Benutzer ins Repository übertragen werden. |
--logtime |
Ergänzt die log-Meldungen in der Log-Datei mit Zeitstempeln. |
--log filename |
Schreibt die log-Meldungen in eine Text-Datei. |
--xtflog filename |
Schreibt die log-Meldungen in eine INTERLIS 2-Datei. Die Datei result.xtf entspricht dem Modell IliVErrors. |
--csvlog filename |
Schreibt die log-Meldungen in eine CSV-Datei. Die Spalten in der CSV-Datei entsprechen dem Modell IliVErrors. |
--plugins folder |
Verzeichnis mit JAR-Dateien, die Zusatzfunktionen enthalten. Die Zusatzfunktionen müssen das Java-Interface ch.interlis.iox_j.validator.InterlisFunction implementieren, und der Name der Java-Klasse muss mit IoxPlugin enden. |
--proxy host |
Proxy Server für den Zugriff auf Modell Repositories |
--proxyPort port |
Proxy Port für den Zugriff auf Modell Repositories |
--gui |
Es erscheint eine Bildschirmmaske, mit deren Hilfe die zu validierende Datei ausgewählt und die Validierung gestartet werden kann. Die Pfad der Modell-Dateien und die Proxyeinstellungen werden aus der Datei $HOME/.ilivalidator gelesen. |
--verbose |
Schreibt detailiertere validierungs log-Meldungen. |
--trace |
Erzeugt zusätzliche Log-Meldungen (wichtig für Programm-Fehleranalysen) |
--help |
Zeigt einen kurzen Hilfetext an. |
--version |
Zeigt die Version des Programmes an. |
In der Meta-Konfigurationsdatei werden die folgenden Parameter unterstützt (hier nicht aufgeführte Kommandozeilenargument werden in der Meta-Konfiguration nicht unterstützt).
| Konfiguration | Beispiel | Beschreibung |
|---|---|---|
| baseConfig | [CONFIGURATION]
baseConfig=ilidata:DatesetId
|
Basis-Meta-Konfiguration, auf der die aktuelle Meta-Konfiguration aufbaut.
Statt Mehrere Basiskonfigurationen werden mit einem Strichpunkt ";" getrennt. |
| org.interlis2.validator.config | [CONFIGURATION]
org.interlis2.validator.config=ilidata:DatesetId
|
Validierungs-Konfiguration, die benutzt werden soll.
Statt Mehrere Validierungs-Konfigurationen werden mit einem Strichpunkt ";" getrennt. |
| ch.interlis.referenceData | [CONFIGURATION]
ch.interlis.referenceData=ilidata:DatesetId
|
Basis-Daten (z.B. Kataloge), die benutzt werden sollen.
Statt Mehrere Basis-Daten werden mit einem Strichpunkt ";" getrennt. |
| models | [ch.ehi.ilivalidator]
models=Simple23
|
Entspricht dem Kommandozeilenargument --models |
| config | [ch.ehi.ilivalidator]
config=ilidata:DatesetId
|
Entspricht dem Kommandozeilenargument --config |
| forceTypeValidation | [ch.ehi.ilivalidator]
forceTypeValidation=true
|
Entspricht dem Kommandozeilenargument --forceTypeValidation |
| disableAreaValidation | [ch.ehi.ilivalidator]
disableAreaValidation=true
|
Entspricht dem Kommandozeilenargument --disableAreaValidation |
| disableConstraintValidation | [ch.ehi.ilivalidator]
disableConstraintValidation=true
|
Entspricht dem Kommandozeilenargument --disableConstraintValidation |
| multiplicityOff | [ch.ehi.ilivalidator]
multiplicityOff=true
|
Entspricht dem Kommandozeilenargument --multiplicityOff |
| allObjectsAccessible | [ch.ehi.ilivalidator]
allObjectsAccessible=true
|
Entspricht dem Kommandozeilenargument --allObjectsAccessible |
| allowItfAreaHoles | [ch.ehi.ilivalidator]
allowItfAreaHoles=true
|
Entspricht dem Kommandozeilenargument --allowItfAreaHoles |
| skipPolygonBuilding | [ch.ehi.ilivalidator]
skipPolygonBuilding=true
|
Entspricht dem Kommandozeilenargument --skipPolygonBuilding |
Die einzelnen Prüfungen können direkt im Modell über Metaaatribute konfiguriert werden oder in einer getrennten Konfigurations-Datei, so dass keine Änderung der ili-Datei notwendig ist.
Um z.B. bei einem Attribut den Mandatory Check ganz auszuschalten, schreibt man in der ili-Datei:
Um dieselbe Konfiguration ohne Änderung der ili-Datei vorzunehmen, schreibt man in der INI-Datei:
Zusätzlich erlaubt die INI Datei pauschale Konfigurationen im Abschnitt "PARAMETER". Um z.B. generell alle Prüfungen auszuschalten schreibt man in die INI-Datei:
| Konfiguration | Beispiel | Beschreibung |
|---|---|---|
| additionalModels | ["PARAMETER"] additionalModels="Model1;Modell2" | "Model1" und "Modell2" sind die Namen der Modelle mit Definitionen von zusätzlichen Validierungen (in Form von Interlis Konsistenbedingungen). Mehrere Zusatzmodelle werden mit einem Strichpunkt ";" getrennt. |
| validation | ["PARAMETER"] validation="off" | "off" schaltet generell alle Prüfungen aus. Mögliche Einstellungen sind: "off", "on". DEFAULT ist "on". |
| areaOverlapValidation | ["PARAMETER"] areaOverlapValidation="off" | "off" schaltet die AREA-Topology Prüfung aus. Mögliche Einstellungen sind: "off", "on". DEFAULT ist "on". |
| constraintValidation | ["PARAMETER"] constraintValidation="off" | "off" schaltet alle Prüfungen von Konsistenzbedingungen aus. Mögliche Einstellungen sind: "off", "on". DEFAULT ist "on". |
| defaultGeometryTypeValidation | ["PARAMETER"] defaultGeometryTypeValidation="off" | Der Default-Wert für die Datentypprüfung bei Geometrie-Attributen. Mögliche Einstellungen sind: "warning", "off", "on". DEFAULT ist "on". |
| allowOnlyMultiplicityReduction | ["PARAMETER"] allowOnlyMultiplicityReduction="true" | "true" ignoriert die Konfiguration der Typprüfungen aus der INI-Datei, d.h. es kann nur die Prüfung der Multiplizität konfiguriert werden. Mögliche Einstellungen sind: "true", "false". DEFAULT ist "false". |
| allObjectsAccessible | ["PARAMETER"] allObjectsAccessible="true" | "true" definiert, dass die mitgegebenen Dateien alle Objekte enthalten, d.h. dass alle Referenzen (insb. mit EXTERNAL) auflösbar sind. Mit false können bei Referenzen mit EXTERNAL nicht alle Prüfungen durchgeführt werden. Mögliche Einstellungen sind: "true", "false". DEFAULT ist "false". |
| multiplicity | ["PARAMETER"] multiplicity="off" | "off" schaltet die Multiplizitätsprüfung für alle Attribute und Rollen aus. Mögliche Einstellungen sind: "on", "warning", "off". DEFAULT ist "on". |
| disableRounding | ["PARAMETER"] disableRounding="true" | "true" schaltet das Runden vor der Validierung von numerischen Werten aus (inkl. Koordinaten). Mögliche Einstellungen sind: "true", "false". DEFAULT ist "false". |
| disableAreAreasMessages | ["PARAMETER"] disableAreAreasMessages="true" | "true" schaltet die Meldungen bei areAreas() Funktionen aus, d.h. die Funktion gibt keine Meldung aus, und liefert nur via den Funktioneswert, ob die Daten die AREA Bedingung erfüllen, oder nicht. Bei "false" gibt die areAreas() Funktionen zusätzlich zum Funktionswert Meldungen aus, wo die Daten die AREA Bedingung nicht erfüllen. Betrifft: INTERLIS.areAreas(), INTERLIS_ext.areAreas2(), INTERLIS_ext.areaAreas3() Mögliche Einstellungen sind: "true", "false". DEFAULT ist "false". |
| verifyModelVersion | ["PARAMETER"] verifyModelVersion="true" | "true" es wird geprüft, ob die VERSIONs Angabe zum Model in der HEADERSECTION der XTF-Datei mit der Angabe im Modell (.ili-Datei) übereinstimmt. Wenn die Angabe nicht übereinstimmt, erfolt eine Info-Meldung. Mögliche Einstellungen sind: "true", "false". DEFAULT ist "false". |
Die einzelnen Prüfungen können direkt im Modell über Metaaatribute konfiguriert werden.
Metaattribute stehen unmittelbar vor dem Modellelement das sie betreffen und beginnen mit !!@.
Falls der Wert (rechts von `=`) aus mehreren durch Leerstellen getrennten Wörtern besteht, muss er mit Gänsefüsschen eingerahmt werden (`"..."`).
| Modelelement | Metaattribut | Beschreibung |
|---|---|---|
| ClassDef | ilivalid.keymsg ilivalid.keymsg_de |
Zusätzlicher Text für die Objektidentifikation für alle Fehlermeldung die sich auf ein Objekt der diesem Metaattribut folgenden Klasse beziehen. Die TID und Zeilennummer erscheint immer, falls vorhanden. keymsg ist zusätzlich (eine Benutzerdefinierte/verständliche Identifikation). Bei Export aus/Check auf DB ist TID evtl. nicht vorhanden. Bei XML ist die Zeilennummer in der Regel nicht hilfreich. Inkl. Attributwerte in {}. Für irgendeine Sprache bzw. fuer DE. !!@ ilivalid.keymsg = "AssNr {AssNr}"
!!@ ilivalid.keymsg_de = "Assekuranz-Nr {AssNr}"
|
| AttributeDef | ilivalid.type |
Datentyppruefung ein/ausschalten bzw. nur als Hinweis. z.B. ob eine Zahlenwert innerhalb des Bereichs ist, oder ein Aufzählwert dem Modell entspricht oder die Flächen eine Gebietseinteilung sind usw. Werte sind on/warning/off !!@ ilivalid.type = off |
| AttributeDef | ilivalid.multiplicity |
Multiplizitätprüfung ein/ausschalten bzw. nur als Hinweis. z.B. ob bei MANDATORY ein Wert vorhanden ist, oder nicht bzw. bei BAG/LIST ob die entsprechende Anzahl Strukturelemente vorhanden ist Werte sind on/warning/off !!@ ilivalid.multiplicity = warning |
| AttributeDef | ilivalid.requiredIn |
Bei einem Referenz-Attribut oder Struktur-Attribut definieren, dass nur Objekte referenziert werden dürfen, die im Behälter mit der gegebenen BID vorkommen. Wenn das Metaattribut bei einem Struktur-Attribut benutzt wird, muss die Struktur ein Referenzattribut enthalten, und die Restriktion betrifft dann die von diesem Referenz-Attribut referenzierten Objekte. !!@ ilivalid.requiredIn = bid1 |
| RoleDef | ilivalid.target |
Zielobjekt-Prüfung ein/ausschalten bzw. nur als Hinweis. Prüft ob das referenzierte Objekt vorhanden ist und ob es von der gewünschten Klasse ist. Werte sind on/warning/off !!@ ilivalid.target = warning |
| RoleDef | ilivalid.multiplicity |
Multiplizitätprüfung ein/ausschalten bzw. nur als Hinweis. Prüfen ob die vom Modell geforderte Anzahl Objekte referenziert wird. Werte sind on/warning/off !!@ ilivalid.multiplicity = off |
| RoleDef | ilivalid.requiredIn |
Bei einer Rolle definieren, dass nur Objekte referenziert werden dürfen, die im Behälter mit der gegebenen BID vorkommen. !!@ ilivalid.requiredIn = bid1 |
| ConstraintDef | ilivalid.check |
Constraint-Prüfung ein/ausschalten bzw. nur als Hinweis. Prüfen ob die Konsistenzbedingung erfüllt ist oder nicht. Werte sind on/warning/off !!@ ilivalid.check = warning |
| ConstraintDef | ilivalid.msg ilivalid.msg_de |
Meldungstext, falls dieses Constraint nicht erfüllt ist. Wird ergänzt um Objektidentifikation und Name des Constraints. inkl. Attributwerte in {} !!@ ilivalid.msg_de = "AndereArt muss definiert sein" |
| ConstraintDef | name |
Name des Constraints (ili2.3 oder bei ili2.4 falls constraint kein name hat) Ergänzt die Fehlermeldung (ohne Name wird interne Id des Constraints verwendet) !!@ name = c1023 |
Wenn ein ConstraintDef keinen expliziten Namen hat, wird für die
Referenzierung eine Name aus der interne Id des Constraints erzeugt. Die
interne Id ist eine aufsteigende Zahl und beginnt pro Klasse mit 1. Das
erste Constraint einer Klasse heisst also Constraint1, das Zweite Constraint2 usw.
Das Interlis 1 Modell wird intern in ein Interlis 2 Modell übersetzt. Tabellen werden zu Klassen, Attribute bleiben Attribute. Referenzattribute werden zu Assoziationen. Für die Namen der Assoziation und Rollen gelten folgende Regeln.
Normalerweise ist ein Rollenname der Name des Referenzattributes und der andere ist der Tabellenname, der das Referenzattribut enthält. Und der Assoziationsname ist die Verkettung der beiden (falls dies nicht zu einem Namenskonflikt führt). Zum Beispiel folgendes Interlis 1 Modell:
MODEL M =
TOPIC T =
TABLE A =
AttrA1: TEXT*20;
END A;
TABLE B =
AttrB1: TEXT*10;
AttrB2: -> A;
AttrB3: -> A;
END B;
END T.
END M.
AttrB2 wird wie folgt übersetzt:
ASSOCIATION BAttrB2 =
B -- {0..*} B;
AttrB2 -- {1} A;
END BAttrB2;
Somit sind die qualifizierten Namen der Rollen (die sich aus dem Referenzattribut ergeben): M.T.BAttrB2.B und M.T.BAttrB2.AttrB2.
Wenn ein Namenskonflikt besteht (wie bei AttrB3 im Beispiel), wird der
Name um einen Index (beginnend bei 2 pro Tabelle) verlängert. AttrB3 führt also zu:
ASSOCIATION B2AttrB3 =
B2 -- {0..*} B;
AttrB3 -- {1} A;
END B2AttrB3;
Somit sind die qualifizierten Namen: M.T.B2AttrB3.B2 und M.T.B2AttrB3.AttrB3.
Die qualifizierten Rollennamen werden auch im Log aufgeführt. z.B.
Info: validate target of role ``M.T.BAttrB2.B``... Info: validate multiplicity of role ``M.T.BAttrB2.B``...
Die Fehlermeldung erscheint, wenn sich zwei Liniensegmente überlappen (also zwei Schnittpunkte haben):
Beispielmeldung:
Error: Model.Topic.Class: Intersection overlap 3.2508012350263016E-4, coord1 (2612419.901, 1248771.194), coord2 (2612428.532, 1248767.551), tids o1, o2
Das Mass der Überlappung (overlap 3.2508012350263016E-4), die beiden
Schnittpunkte (coord1 (2612419.901, 1248771.194), coord2 (2612428.532, 1248767.551))
und die TIDs/OIDs der betroffenen Objekte (tids o1, o2) werden aufgeführt.
Die Fehlermeldung erscheint, wenn sich zwei Liniensegmente schneiden (also einen Schnittpunkte haben):
Beispielmeldung:
Error: Model.Topic.Class: Intersection coord1 (2612419.220, 1248771.482), tids o1/attrA[1]/flaeche[1], o2/attrA[2]/flaeche[1]
Der Schnittpunkte (coord1 (2612419.220, 1248771.482))
und die TIDs/OIDs der betroffenen Objekte (tids o1/attrA[1]/flaeche[1], o2/attrA[2]/flaeche[1]) werden aufgeführt.
In diesem Fall sind die Geometrien innerhalb von Strukturen, darum wird der
ganze Pfad vom Objekt bis zur Geometrie aufgeführt (o1/attrA[1]/flaeche[1]:
im Objekt o1 das erste Strukturelement des Attributs attrA und darin das erste Element von flaeche)