INTERLIS Transformer — Referenz
Vorwort
Die vorliegende Referenz dokumentiert den INTERLIS Transformer vollständig. Sie beschreibt alle CLI-Befehle, die ilimap-DSL, das YAML-Mapping-Format, die Ausdruckssprache, die unterstützten Formate sowie sämtliche Diagnostic-Codes.
Zielgruppe
Die Referenz richtet sich an alle, die mit dem INTERLIS Transformer arbeiten — vom Einsteiger, der das erste Mapping schreibt, bis zur erfahrenen Person, die eine komplexe Transformation mit YAML und verlinkten ilimap-Dateien konfiguriert. Sie setzt Grundkenntnisse in INTERLIS und der Arbeit mit der Kommandozeile voraus.
Aufbau
-
[_einfuhrung] erklärt die Konzepte und die Architektur.
-
Kapitel 2, CLI-Referenz beschreibt sämtliche CLI-Befehle mit allen Optionen.
-
Kapitel 3, ilimap-DSL-Referenz dokumentiert die ilimap-Sprache vollständig.
-
Kapitel 4, YAML-Mapping-Referenz dokumentiert das YAML-Mapping-Format.
-
Kapitel 5, Ausdruckssprache-Referenz listet alle Built-in-Funktionen auf.
-
Kapitel 6, Format-Referenz beschreibt die unterstützten Ein- und Ausgabeformate.
-
Die Anhänge enthalten Diagnostic-Codes, OID-/Basket-Strategien, Beispiele und die formale Grammatik.
Konventionen
In dieser Referenz werden folgende typografische Mittel verwendet:
-
feste Breite— CLI-Befehle, Dateinamen, ilimap-Schlüsselwörter, Code -
kursiv — Platzhalter, die durch eigene Werte zu ersetzen sind
-
[IMPORTANT] — wichtige Hinweise
-
[TIP] — Tipps und Best Practices
-
[WARNING] — Warnungen vor häufigen Fehlern
1. Einführung
1.1. Konzepte
Der INTERLIS Transformer überführt INTERLIS-Daten kontrolliert von einer Form in eine andere. Er trennt bewusst zwischen technischer Repräsentation (Format) und fachlicher Bedeutung (Modell).
1.1.1. Formatumbau und Datenumbau
Formatumbau ändert die technische Repräsentation bei gleichbleibender fachlicher Bedeutung — zum Beispiel XTF nach GeoPackage oder JDBC-Tabelle.
Datenumbau ändert die fachliche Struktur: Klassen, Attribute, Werte, Einheiten oder Beziehungen werden neu abgebildet — zum Beispiel bei der Migration von einem Datenmodell in ein anderes.
1.1.2. Drei Bausteine
-
I/O-Provider lesen und schreiben Formate wie XTF, ITF, CSV, GeoPackage, JDBC und Shapefile.
-
IOM / iox-ili stellt die gemeinsame, modellbewusste Objektwelt bereit.
-
ilimap beschreibt deklarativ, wie aus Quellobjekten Zielobjekte entstehen.
1.1.3. Mapping-Formate
Ein Mapping kann auf zwei Arten beschrieben werden:
-
Als .ilimap-Datei — eine eigene DSL mit Syntax-Highlighting, Autovervollständigung und Validierung in VS Code.
-
Als YAML-Datei — geeignet für umfangreiche Transformationen. YAML-Dateien können auf .ilimap-Dateien verweisen, um Regeln auszulagern.
Beide Formate werden vom selben Compiler verarbeitet und sind funktional äquivalent.
1.2. Architektur
Das folgende Diagramm zeigt den Datenfluss vom CLI-Aufruf bis zur Ausgabe:
flowchart LR
CLI["CLI (picocli)"] --> JR[JobRunner]
JR --> ML[MappingLoader]
ML --> MC[MappingCompiler]
MC --> TE[TransformationEngine]
TE --> OM[OutputManager]
ML --> IMS[IliModelService]
IMS --> TSF[TypeSystemFacade]
TSF --> ILI[ili2c]
ML --> IR[IoxReaders]
TE --> IW[IoxWriters]
TE --> EE[ExpressionEngine]
EE --> FR[FunctionRegistry]
TE --> SS[StateStore]
subgraph " "
IR
IW
end
Das System arbeitet in zwei Phasen:
-
Compile-Phase: Der
MappingLoaderliest die Mapping-Datei (YAML oder .ilimap). DerMappingCompilervalidiert sie gegen die INTERLIS-Modelle und erzeugt einen ausführbaren Plan. -
Runtime-Phase: Die
TransformationEngineführt den Plan aus: Quellobjekte werden gelesen, Ausdrücke evaluiert, Zielobjekte aufgebaut und geschrieben.
1.2.1. Komponenten
| Komponente | Aufgabe |
|---|---|
|
|
Einstiegspunkt: lädt das Mapping und orchestriert die Transformation |
|
|
Liest YAML- und .ilimap-Dateien, löst |
|
|
Validiert das Mapping gegen die Modelle, erzeugt Diagnosemeldungen |
|
|
Führt die Regeln aus: liest Quellen, evaluiert Ausdrücke, schreibt Ziele |
|
|
Evaluiert ilimap-Ausdrücke mit lazy Evaluation und Typprüfung |
|
|
Registriert alle Built-in-Funktionen (String, Math, Enum, Date, Lookup, Geometry) |
|
|
Fassade für ili2c: kompiliert INTERLIS-Modelle, stellt Typinformationen bereit |
|
|
Lesen und schreiben die unterstützten Formate (XTF, ITF, CSV, GPKG, JDBC, SHP) |
|
|
Hält den Zustand während der Transformation (OID-Registry, Basket-Zuordnung) |
1.3. Schnelleinstieg
Dieser Abschnitt zeigt einen minimalen Transformationslauf vom geklonten Repository bis zur Ausgabe.
1.3.2. Build
git clone https://github.com/edigonzales/ilitransformer.git
cd ilitransformer
./gradlew installDist
1.3.3. Erstes Mapping
Die Demo-Suite enthält ein minimales Beispiel (Hello Copy), das zwei Objekte kopiert und dabei Namen trimmt und in Grossbuchstaben umwandelt.
./build/install/ilitransformer/bin/ilitransformer validate-mapping \
-m demo/01-hello-copy/profile.ilimap
./build/install/ilitransformer/bin/ilitransformer transform \
-m demo/01-hello-copy/profile.ilimap
./build/install/ilitransformer/bin/ilitransformer transform \
-m demo/01-hello-copy/profile.ilimap --validate
Das Ergebnis (output.xtf) enthält zwei Target-Objekte mit bereinigten Namen.
1.3.4. Nächste Schritte
Die vollständige Demo-Suite (demo/) enthält neun Beispiele, die sich von einfachen Kopierregeln bis zu Referenzen, BAG OF STRUCTURE und OID-Strategien steigern. Siehe Anhang C für die kompletten Listings.
2. CLI-Referenz
2.1. transform
Führt eine Transformation aus: liest Eingabedaten, wendet die Mapping-Regeln an und schreibt die Ausgabedatei.
2.1.2. Optionen
| Option | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
file |
ja |
Pfad zur Mapping-Datei (YAML oder .ilimap) |
|
|
dir |
nein |
Zusätzliches Modellverzeichnis (wiederholbar) |
|
|
flag |
nein |
Ausgabe nach der Transformation mit ilivalidator prüfen |
|
|
dir |
nein |
Verzeichnis für Reports (JSON + Markdown) |
|
|
enum |
nein |
|
|
|
flag |
nein |
Temporäre Dateien bei Fehler nicht löschen |
2.1.3. Fail-Policy
| Wert | Verhalten |
|---|---|
|
|
Abbruch bei jedem Fehler (Default) |
|
|
Fehler sammeln, Ausgabe trotzdem schreiben |
|
|
Fehler nur reportieren, keine Ausgabe schreiben |
2.1.4. Beispiele
ilitransformer transform -m mapping.ilimap
ilitransformer transform \
-m profile.ilimap \
--modeldir models/ \
--validate
ilitransformer transform \
-m mapping.yml \
--report reports/ \
--fail-policy lenient
2.2. validate-mapping
Prüft eine Mapping-Datei auf syntaktische und semantische Korrektheit, ohne eine Transformation auszuführen.
2.2.2. Optionen
| Option | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
file |
ja |
Pfad zur Mapping-Datei (YAML oder .ilimap) |
|
|
dir |
nein |
Zusätzliches Modellverzeichnis (wiederholbar) |
2.2.3. Verhalten
Ohne --modeldir: Nur strukturelle Validierung (Syntax, Duplikate, unbekannte Referenzen innerhalb der Mapping-Datei).
Mit --modeldir: Vollständige modellbewusste Validierung. Die referenzierten INTERLIS-Modelle werden kompiliert. Klassen-, Attribut- und Typreferenzen werden gegen die Modelle geprüft.
|
Für .ilimap-Dateien, die |
2.3. validate-transfer
Validiert eine INTERLIS-Transferdatei (ITF oder XTF) mit ilivalidator.
2.3.1. Signatur
ilitransformer validate-transfer -f <file> --modeldir <dir>... --model <model>... [options]
2.4. convert-mapping
Konvertiert eine YAML-Mapping-Datei in das .ilimap-Format.
2.5. inspect-model
Exportiert die Struktur eines INTERLIS-Modells als JSON und/oder Markdown. Nützlich, um verfügbare Klassen, Attribute und Typen zu erkunden.
2.6. run-bundle
Führt ein vordefiniertes Transformations-Bundle aus, das in einer Manifest-YAML-Datei beschrieben ist.
2.6.2. Optionen
| Option | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
file |
ja |
Bundle-Manifest (YAML) |
|
|
file |
nein |
Eingabedatei überschreiben |
|
|
dir |
nein |
Report-Verzeichnis |
|
|
file |
nein |
Ausgabedatei überschreiben |
|
|
dir |
nein |
Repository-Wurzel für relative Pfade |
|
|
flag |
nein |
Ausgabe validieren |
|
|
flag |
nein |
Validierung deaktivieren |
|
Ohne |
2.7. Globale Optionen
Diese Optionen sind für alle Befehle verfügbar.
2.7.1. --help
Zeigt die Hilfe für einen Befehl an:
ilitransformer --help # Befehlsübersicht
ilitransformer transform --help # Hilfe für transform
ilitransformer validate-mapping --help # Hilfe für validate-mapping
2.7.2. --version
Zeigt die Build-Version und den Git-Commit-Hash an:
ilitransformer --version
# ilitransformer 0.1.0 (commit: a1b2c3d)
2.7.4. Gradle-Tasks
Neben den CLI-Befehlen stehen Gradle-Tasks für spezielle Anwendungsfälle zur Verfügung:
| Task | Beschreibung |
|---|---|
|
|
Transferdatei validieren ( |
|
|
DM01/DMAV-Korrelation importieren |
|
|
DM01-BB-ITF erzeugen |
|
|
Vollständigen DM01→DMAV-Lauf ausführen |
|
|
Ausdrucksreferenz generieren |
./gradlew validateTransfer -Ptransfer=output.xtf -Pmodel=MyModel
3. ilimap-DSL-Referenz
3.1. Dateistruktur
Eine .ilimap-Datei hat folgenden Aufbau:
mapping v2 ["Profilname"] {
job { ... } // 0..1
input <id> { ... } // 1..n
output <id> { ... } // 1..n
oid <strategie> { ... } // 0..1
basket <strategie>; // 0..1
enum <name> { ... } // 0..n
defaults { ... } // 0..1
rule <id> { ... } // 1..n
}
3.1.1. Top-Level-Elemente
| Element | Kardinalität | Beschreibung |
|---|---|---|
|
|
1 |
Dateikopf mit optionalem Profilnamen in Anführungszeichen |
|
|
0..1 |
Metadaten (Name, Beschreibung, modeldir, Fail-Policy) |
|
|
1..n |
Eingabedateien mit Format, Modell und Optionen |
|
|
1..n |
Ausgabedateien mit Format, Modell und Optionen |
|
|
0..1 |
OID-Strategie (preserve, integer, uuid, deterministicUuid) |
|
|
0..1 |
Basket-Strategie (preserve, generateUuid, preserveOrGenerateUuid, byTopic) |
|
|
0..n |
Enum-Mapping-Tabellen (benannte Zuordnungen |
|
|
0..1 |
Default-Werte für Zielattribute (top-level, gilt für alle Regeln) |
|
|
1..n |
Transformationsregeln |
3.1.2. Minimales Beispiel
mapping v2 {
input src {
path "input.xtf";
model "HelloDemo";
}
output tgt {
path "output.xtf";
model "HelloDemo";
}
oid uuid;
rule copy {
target tgt class "HelloDemo.Persons.Target";
source s from src class "HelloDemo.Persons.Source";
assign {
Name = s.Name;
}
}
}
|
Die .ilimap-Datei kann mit der VS-Code-Erweiterung |
3.2. job-Block
Der job-Block enthält Metadaten und globale Einstellungen.
3.2.1. Syntax
job {
name "Mein Mapping";
description "Beschreibung des Mappings";
direction dm01_to_dmav;
failPolicy strict;
compileMode strict;
modeldir "https://models.interlis.ch/";
modeldir "models/";
}
3.2.2. Felder
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
string |
nein |
Name des Mappings |
|
|
string |
nein |
Freitext-Beschreibung |
|
|
identifier |
nein |
Transformationsrichtung (z.B. |
|
|
identifier |
nein |
|
|
|
identifier |
nein |
|
|
|
string |
nein |
Modellverzeichnis (URL oder Pfad, wiederholbar) |
3.2.3. Fail-Policy
Siehe transform für die Beschreibung der Fail-Policy-Werte.
3.3. input und output
input und output deklarieren Ein- und Ausgabedateien mit Format, Modell und formatspezifischen Optionen.
3.3.1. Syntax input
input <id> {
path "datei.xtf";
model "Model.Topic";
format xtf;
option <key> <value>;
connection { ... } // nur JDBC
query <id> { ... } // nur JDBC, wiederholbar
}
3.3.2. Syntax output
output <id> {
path "ausgabe.xtf";
model "Model.Topic";
format xtf;
option <key> <value>;
}
3.3.3. Gemeinsame Felder
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
string |
ja* |
Dateipfad (* ausser bei JDBC) |
|
|
string |
ja |
INTERLIS-Modellname |
|
|
identifier |
nein |
|
|
|
id + literal |
nein |
Formatspezifische Option (wiederholbar) |
Wird kein format angegeben, errät der Transformer das Format anhand der Dateiendung: .xtf → XTF, .itf → ITF, *.xml → XML. Bei CSV, GPKG, JDBC und SHP ist format immer erforderlich.
3.3.4. JDBC-spezifische Blöcke
Siehe Format-Referenz: JDBC für connection und query.
3.3.5. Beispiele
input src {
path "daten/input.xtf";
model "HelloDemo";
}
input csv_data {
path "daten/input.csv";
model "HelloData";
format csv;
option separator ";";
option encoding "ISO-8859-1";
}
output shp_out {
path "output/gebaeude.shp";
model "LV95_Gebaeude";
format shp;
option dbfEncoding "UTF-8";
option fieldNameStrategy truncate;
}
3.4. Formatoptionen
Jedes Format unterstützt spezifische Optionen, die mit option <key> <value> gesetzt werden.
3.4.1. CSV (nur Eingabe)
| Option | Default | Beschreibung |
|---|---|---|
|
|
|
Erste Zeile als Spaltenkopf interpretieren |
|
|
|
Trennzeichen |
|
|
|
Textbegrenzungszeichen |
|
|
|
Dateikodierung |
3.4.2. GeoPackage (nur Eingabe)
| Option | Default | Beschreibung |
|---|---|---|
|
|
(Pflicht) |
Tabellenname |
|
|
|
Zeilen pro Fetch-Roundtrip |
3.4.3. JDBC (nur Eingabe)
Für JDBC siehe die Blöcke connection und query in Format-Referenz: JDBC.
3.4.4. Shapefile (Eingabe)
| Option | Default | Beschreibung |
|---|---|---|
|
|
(Pflicht) |
Qualifizierter Quellklassenname |
|
|
aus |
Basket-Topic |
|
|
|
Basket-ID |
|
|
|
OID-DBF-Feld |
|
|
inferiert |
Geometrieattribut |
|
|
aus Shape-Typ |
|
|
|
|
DBF-Kodierung |
|
|
(opt.) |
DBF-Feld → INTERLIS-Attribut |
|
|
|
|
|
|
|
|
3.4.5. Shapefile (Ausgabe)
| Option | Default | Beschreibung |
|---|---|---|
|
|
erste geschriebene Klasse |
IOX-Klasse |
|
|
inferiert |
Geometrieattribut für |
|
|
aus Geometrie |
|
|
|
|
DBF-Kodierung |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(leer) |
WKT für |
|
|
|
Mehrere Baskets ablehnen |
3.5. oid und basket
Steuern, wie Objekt-Identifikatoren (OID) und Baskets im Zielmodell vergeben werden.
3.5.1. oid
// Einfache Form
oid uuid;
// Mit Namespace
oid deterministicUuid {
namespace "ch.admin.geo";
}
Strategien:
| Strategie | Beschreibung |
|---|---|
|
|
OID aus der Quelle übernehmen |
|
|
Fortlaufende Ganzzahlen vergeben |
|
|
Zufällige UUIDs generieren |
|
|
UUIDs aus OID + Namespace ableiten (reproduzierbar) |
|
|
Reserviert, nicht implementiert |
Der deterministicUuid-Namespace ist ein optionaler String. Ist er gesetzt, werden UUIDs aus namespace + Quell-OID abgeleitet, sodass sie über mehrere Läufe hinweg stabil bleiben.
|
Die Strategie |
3.5.2. basket
basket preserve;
Strategien:
| Strategie | Beschreibung |
|---|---|
|
|
Basket-IDs aus der Quelle übernehmen |
|
|
Neue UUID-Baskets generieren |
|
|
Quelle übernehmen, sonst UUID generieren |
|
|
Baskets nach Topic gruppieren |
|
|
Reserviert, nicht implementiert |
|
Die Strategie |
3.6. enum und defaults
3.6.1. enum — Enum-Mapping-Tabellen
enum meine_enum_map {
#aktiv => #aktiv;
#inaktiv => #inaktiv;
#unbekannt => #andere;
_ => #andere; // Default-Wert
}
Enum-Blöcke definieren benannte Zuordnungstabellen, die in Ausdrücken mit enumMap(), enumMapDefault() und enumMapStrict() verwendet werden (siehe Ausdruckssprache: Enum-Funktionen).
| Element | Beschreibung |
|---|---|
|
|
Enum-Wert der Quelle auf Enum-Wert des Ziels abbilden |
|
|
Hash-Literale für Enum-Werte |
|
|
Wildcard / Default-Zweig |
|
Enum-Maps werden über ihren Bezeichner referenziert — nicht über ihren Dateinamen. Der Bezeichner |
3.6.2. defaults — Default-Werte
defaults-Blöcke können auf zwei Ebenen erscheinen:
Top-Level (gilt für alle Regeln):
defaults {
Beschreibung = "Standardtext";
Status = #aktiv;
}
Rule-Level (gilt nur für diese Regel):
rule copy {
defaults {
Beschreibung = "Kopiert von " + s.Name;
}
...
}
Rule-Level-Defaults überschreiben Top-Level-Defaults für dasselbe Attribut. Defaults kommen nur zum Zug, wenn das Zielattribut in keiner assign-Anweisung gesetzt wurde.
3.7. rule-Block
Eine Regel beschreibt, wie aus einer oder mehreren Quellklassen eine Zielklasse befüllt wird.
3.7.1. Syntax
rule <id> {
target <outputId> class "<Model.Topic.Class>";
source <alias> from <inputId>[, <inputId>...] class "<Model.Topic.Class>" [where <expr>];
[where <expression>;]
[join (inner|left) <alias> to <alias> on <expression>;]
[identity <alias.attr>, ...;]
assign {
<targetAttr> = <expression>;
...
}
[defaults { ... }]
[bag <name> { ... }]
[ref <name> { ... }]
[create class "..." { ... }]
[loss { ... }]
[metadata { ... }]
}
3.7.2. Felder
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
aliasId |
ja |
Eindeutiger Regelbezeichner (keine Bindestriche) |
|
|
block |
ja |
Zielklasse mit Output-ID |
|
|
block |
ja* |
Quellklasse mit Alias und Input-ID (1..n pro Regel) |
|
|
expression |
nein |
Filterbedingung für Quellobjekte (nur Objekte, die |
|
|
block |
nein |
Join zwischen zwei Quellen (experimentell, max. 1 pro Regel) |
|
|
list |
nein |
Business-Key-Felder (z.B. |
|
|
block |
nein |
Attributzuweisungen |
|
|
block |
nein |
Regel-spezifische Defaults |
|
|
block |
nein |
BAG OF STRUCTURE (wiederholbar) |
|
|
block |
nein |
Referenz-Mapping (wiederholbar) |
|
|
block |
nein |
Zusätzliche Zielobjekte erzeugen (experimentell) |
|
|
block |
nein |
Dokumentierter Informationsverlust (wiederholbar) |
|
|
block |
nein |
Metadaten zur Regel (direction, roundtrip, lossiness) |
3.7.3. target
target tgt class "HelloDemo.Persons.Target";
-
tgt— Output-ID, muss alsoutputim Mapping deklariert sein -
"HelloDemo.Persons.Target"— vollqualifizierter INTERLIS-Klassenname
3.7.4. source
source s from src class "HelloDemo.Persons.Source";
source s from src, other class "Shared.Info" where s.Status == #aktiv;
-
s— Alias (in Ausdrücken alss.Attributverwendet) -
from src— Input-ID (eine oder mehrere, kommagetrennt) -
where— optionale Filterbedingung
|
Mehrere |
3.8. assign und Ausdrücke
Der assign-Block enthält die eigentlichen Attributzuweisungen.
3.8.1. Syntax
assign {
<zielAttribut> = <expression>;
...
}
Jede Zuweisung besteht aus einem Zielattribut (links) und einem Ausdruck (rechts), abgeschlossen mit ;.
3.8.2. Einfache Zuweisungen
assign {
Name = s.Name; // Direkt übernehmen
Beschreibung = "Standard"; // Konstanter String
Anzahl = 42; // Konstanter Zahlenwert
Aktiv = true; // Boolescher Wert
Status = #aktiv; // Enum-Wert
}
3.8.3. Ausdrücke mit Funktionen
assign {
Name = trim(s.Name); // String trimmen
NameGross = upper(trim(s.Name)); // Verschachtelte Aufrufe
Wert = round(s.Wert, 2); // Auf 2 Stellen runden
Datum = toXmlDateTime(s.Datum); // Typkonvertierung
StatusNeu = enumMap(s.StatusAlt, // Enum-Mapping
meine_map);
Bezug = if(defined(s.Referenz), // Bedingung
s.Referenz, null);
}
3.8.4. Pfade und Aliase
-
alias.attribut— Attribut eines Quellobjekts (z.B.s.Name) -
alias.rolle.attribut— Attribut über eine Rolle (z.B.s.Adresse.Ort)
Die vollständige Ausdruckssprache ist in Kapitel 5 dokumentiert.
3.9. bag, ref und create
3.9.1. bag — BAG OF STRUCTURE
bag adressen {
from a in src class "Source.Adresse" where a.PersonId == p.OID;
target Adressen;
structure "Target.Adresse";
mode embed;
maxItems 5;
parentRef attribute "PersonId" parent p;
assign {
Strasse = a.Strasse;
PLZ = a.PLZ;
Ort = a.Ort;
}
bag dokumente { // verschachtelter Bag
...
}
}
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
block |
ja |
Quelle für Bag-Einträge (alias, inputId, class, where) |
|
|
identifier |
nein |
Zielattributname (Default: Bag-Name) |
|
|
string |
ja |
Strukturklasse für Bag-Einträge |
|
|
enum |
nein |
|
|
|
number |
nein |
Maximale Anzahl Einträge |
|
|
block |
nein |
Rückwärts-Referenz zum Parent (attribute oder role) |
|
|
expression |
nein |
Zusätzliche Filterbedingung |
|
|
block |
nein |
Attributzuweisungen für die Struktur |
|
|
block |
nein |
Verschachtelte Bags (rekursiv) |
3.9.2. ref — Referenz-Mapping
ref gebaeude_ref {
association "Target.GebaeudeRef";
role "Gebaeude";
required;
target rule gebaeude_rule sourceRef s.GebaeudeRef;
}
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
string |
nein |
Qualifizierter Assoziationsname |
|
|
string |
nein |
Rollenname |
|
|
flag |
nein |
Referenz ist zwingend |
|
|
block |
ja |
Ziel: |
|
Referenzen werden über den |
3.10. loss und metadata
3.10.1. loss — Dokumentierter Informationsverlust
loss {
sourcePath s.AlteGeometrie;
reasonCode "GEOM_VEREINFACHT";
description "Die Geometrie wurde für das Zielmodell vereinfacht. " +
"Detailsiehe Transformationsbericht.";
when defined(s.AlteGeometrie);
}
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
expression |
ja |
Quellattribut, das verloren geht |
|
|
string |
ja |
Kategorie/Grund des Verlusts |
|
|
string |
ja |
Beschreibung des Verlusts (String-Konkatenation mit |
|
|
expression |
nein |
Bedingung, unter der der Verlust eintritt |
loss-Blöcke dokumentieren, welche Quelldaten in der Transformation verloren gehen — etwa weil das Zielmodell sie nicht abbilden kann. Sie verhindern keine Transformation, sondern dienen der Nachvollziehbarkeit.
3.10.2. metadata — Regel-Metadaten
metadata {
direction dm01_to_dmav;
roundtrip lossy;
lossiness partial;
}
| Feld | Typ | Beschreibung |
|---|---|---|
|
|
identifier |
Transformationsrichtung |
|
|
identifier |
Roundtrip-Fähigkeit (z.B. |
|
|
identifier |
Verlustgrad (z.B. |
Die Werte sind frei wählbare Bezeichner — sie werden nicht validiert, sondern dienen der Dokumentation.
3.11. Lexikalische Regeln
3.11.3. Bezeichner
-
symbolId:[a-zA-Z][a-zA-Z0-9_-]*— für Regelnamen, Input-/Output-IDs, Enum-Namen Bindestriche sind erlaubt (z.B.meine-regel) -
aliasId:[a-zA-Z][a-zA-Z0-9_]*— für Source-Aliase in Ausdrücken Keine Bindestriche (z.B.s,quelle1)
3.11.7. Reservierte Wörter
Die folgenden Wörter sind reserviert und können nicht als Bezeichner verwendet werden:
mapping, job, input, output, oid, basket, enum, rule, target, source, from, where, join, identity, assign, defaults, bag, ref, create, loss, metadata, class, inner, left, mode, structure, maxItems, parentRef, association, role, required, sourcePath, reasonCode, description, when, direction, roundtrip, lossiness, option, true, false, null
4. YAML-Mapping-Referenz
4.1. Gesamtstruktur
Eine YAML-Mapping-Datei hat drei Top-Level-Sektionen:
version: 1
job:
name: "Meine Transformation"
description: "Beschreibung"
direction: dm01-to-dmav
failPolicy: strict
modeldir:
- "https://models.interlis.ch/"
- "models/"
inputs: [...]
outputs: [...]
mapping:
oidStrategy: ...
basketStrategy: ...
enums: {...}
defaults: {...}
compileMode: strict
rules: [...]
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
int |
ja |
DSL-Version (aktuell |
|
|
JobSection |
ja |
Job-Metadaten und I/O-Deklarationen |
|
|
MappingSection |
ja |
Mapping-Regeln und Strategien |
|
Der YAML-Mapping-Compiler validiert die Version. Nur |
4.1.1. Vergleich YAML vs. ilimap
| Aspekt | YAML | ilimap |
|---|---|---|
|
Verwendung |
Umfangreiche Transformationen mit vielen Dateien |
Einzelne Mapping-Dateien |
|
Tooling |
Allgemeine YAML-Editoren |
VS-Code-Erweiterung mit LSP |
|
Modularisierung |
Verlinkungen auf .ilimap-Dateien |
Alles-in-einer-Datei |
|
Syntax-Prüfung |
Durch YAML-Parser + Compiler |
Durch LSP in Echtzeit |
|
Konvertierung |
|
— |
4.2. JobSection
Die job-Sektion deklariert Metadaten und sämtliche Ein- und Ausgabedateien.
4.2.1. Felder
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
string |
nein |
Job-Name |
|
|
string |
nein |
Beschreibung |
|
|
string |
nein |
Transformationsrichtung |
|
|
string |
nein |
|
|
|
list[string] |
nein |
Modellverzeichnisse (URLs oder Pfade) |
|
|
list[InputSpec] |
ja |
Eingabedateien (>= 1) |
|
|
list[OutputSpec] |
ja |
Ausgabedateien (>= 1) |
4.2.2. Beispiel
job:
name: "DM01 nach DMAV"
description: "Vollständige Transformation"
direction: dm01-to-dmav
failPolicy: strict
modeldir:
- "https://models.interlis.ch/"
- "./lokale-modelle/"
inputs:
- id: dm01
path: "eingabe.xtf"
model: "DM01"
outputs:
- id: dmav
path: "ausgabe.xtf"
model: "DMAV"
4.3. InputSpec
Beschreibt eine Eingabedatei mit Format, Modell und formatspezifischen Details.
4.3.1. Felder
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
string |
ja |
Eindeutige ID (in Regeln als |
|
|
string |
ja* |
Dateipfad (* ausser bei JDBC) |
|
|
string |
ja |
INTERLIS-Modellname |
|
|
string |
nein |
|
|
|
map |
nein |
Formatspezifische Optionen |
|
|
block |
nein* |
JDBC-Verbindung (* Pflicht für JDBC) |
|
|
block |
nein* |
JDBC-Queries (* Pflicht für JDBC) |
4.3.2. CSV
inputs:
- id: csv_data
path: "daten/input.csv"
model: "MyModel"
format: csv
options:
firstLineIsHeader: true
separator: ";"
delimiter: '"'
encoding: "UTF-8"
4.3.3. GeoPackage
inputs:
- id: gpkg_data
path: "daten/gebaeude.gpkg"
model: "MyModel"
format: gpkg
options:
table: "gebaeude"
fetchSize: 5000
4.3.4. JDBC (siehe auch Format-Referenz: JDBC)
inputs:
- id: db_data
model: "MyModel"
format: jdbc
connection:
url: "jdbc:postgresql://localhost/mydb"
driver: "org.postgresql.Driver"
user: "app"
password: "secret"
queries:
- class: "MyModel.Topic.MyClass"
sql: "SELECT * FROM my_table"
topic: "Topic"
basketId: "b1"
oidColumn: "t_id"
columns:
attr1: "col_a"
attr2: "col_b"
geometry:
geom_attr:
column: "geom_col"
type: "surface"
srid: 2056
4.4. OutputSpec
Beschreibt eine Ausgabedatei.
4.4.1. Felder
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
string |
ja |
Eindeutige ID (in Regeln als |
|
|
string |
ja |
Ausgabedatei |
|
|
string |
ja |
INTERLIS-Modellname |
|
|
string |
nein |
|
|
|
map |
nein |
Formatspezifische Optionen |
4.4.2. Beispiele
outputs:
- id: out
path: "output.xtf"
model: "TargetModel"
format: xtf
outputs:
- id: out
path: "output.xtf"
model: "TargetModel"
format: xtf
options:
pretty: true
outputs:
- id: shp_out
path: "output/gebaeude.shp"
model: "TargetModel"
format: shp
options:
dbfEncoding: "UTF-8"
fieldNameStrategy: "truncate"
prj: "PROJCS[\"CH1903+ / LV95\",...]"
4.5. MappingSection
Die mapping-Sektion enthält die globalen Strategien und die Transformationsregeln.
4.5.1. Felder
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
OidStrategySpec |
nein |
OID-Strategie |
|
|
BasketStrategySpec |
nein |
Basket-Strategie |
|
|
map[string, map] |
nein |
Enum-Mapping-Tabellen |
|
|
map[string, string] |
nein |
Default-Werte (top-level) |
|
|
string |
nein |
|
|
|
list[RuleSpec] |
ja |
Transformationsregeln (>= 1) |
4.5.2. OID-Strategie
mapping:
oidStrategy:
type: uuid
mapping:
oidStrategy:
type: deterministicUuid
namespace: "ch.admin.geo"
Unterstützte type-Werte: preserve, integer, uuid, deterministicUuid.
4.6. RuleSpec
Eine Regel in der YAML-DSL.
4.6.1. Felder
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
string |
ja |
Eindeutige Regel-ID |
|
|
TargetSpec |
ja |
Zielklasse und Output |
|
|
list[SourceSpec] |
ja |
Quellklassen (>= 1) |
|
|
string |
nein |
Filter-Ausdruck (betrifft alle Quellen) |
|
|
IdentitySpec |
nein |
Business-Key |
|
|
map[string, string] |
nein |
Attributzuweisungen |
|
|
list[RefMapping] |
nein |
Referenz-Mappings |
|
|
map[string, BagSpec] |
nein |
BAG OF STRUCTURE |
|
|
list[JoinSpec] |
nein |
Joins (experimentell, max. 1) |
|
|
list[CreateSpec] |
nein |
Zusätzliche Zielobjekte (experimentell) |
|
|
list[LossSpec] |
nein |
Informationsverlust |
|
|
MetadataSpec |
nein |
Metadaten |
|
|
map[string, string] |
nein |
Regel-Defaults |
4.6.3. SourceSpec
sources:
- input: src
alias: s
class: "SourceModel.Topic.SourceClass"
where: "s.Status == #aktiv"
4.6.4. Beispiel
rules:
- id: "copy_gebaeude"
target:
output: out
class: "LV95.Gebaeude"
sources:
- input: src
alias: g
class: "AV.Gebaeude"
assign:
Name: "trim(g.Name)"
Nummer: "g.Nummer"
Geometrie: "ref g.Geometrie"
bags:
adressen:
from:
input: src
alias: a
class: "AV.Adresse"
where: "a.GebaeudeId == g.OID"
target: "Adressen"
structure: "LV95.Adresse"
assign:
Strasse: "a.Strasse"
Ort: "a.Ort"
refs:
- association: "LV95.GebaeudeRef"
role: "Gebaeude"
sourceRef: "g.RefOID"
targetRule: "gebaeude_rule"
loss:
- sourcePath: "g.AlteGeometrie"
reasonCode: "GEOM_VEREINFACHT"
description: "Geometrie vereinfacht"
when: "defined(g.AlteGeometrie)"
metadata:
direction: "av_to_lv95"
roundtrip: "lossy"
lossiness: "minimal"
4.7. BagSpec
bags definieren BAG OF STRUCTURE — strukturierte Listen innerhalb eines Zielobjekts.
4.7.1. Felder
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
BagFromSpec |
ja |
Quelle für Bag-Einträge |
|
|
string |
ja |
Strukturklasse |
|
|
string |
nein |
|
|
|
int |
nein |
Maximale Anzahl Einträge |
|
|
ParentRefSpec |
nein |
Rückwärts-Referenz |
|
|
string |
nein |
Zusätzlicher Filter |
|
|
map[string, string] |
nein |
Attributzuweisungen |
|
|
map[string, BagSpec] |
nein |
Verschachtelte Bags |
4.7.2. BagFromSpec
from:
input: src # Input-ID
alias: a # Alias
class: "Model.Topic.SourceClass"
where: "a.ParentId == p.OID"
4.7.4. Vollständiges Beispiel
bags:
adressen:
from:
input: src
alias: a
class: "AV.Adresse"
where: "a.GebaeudeId == g.OID"
structure: "LV95.Adresse"
mode: embed
maxItems: 10
parentRef:
attribute: "GebaeudeId"
parent: g
assign:
Strasse: "a.Strasse"
Hausnummer: "a.Hausnummer"
PLZ: "a.PLZ"
Ort: "a.Ort"
bag:
dokumente:
from:
input: src
alias: d
class: "AV.Dokument"
where: "d.AdresseId == a.OID"
structure: "LV95.Dokument"
assign:
Dateiname: "d.Dateiname"
Typ: "d.Typ"
4.8. RefMapping, CreateSpec, LossSpec, MetadataSpec
4.8.1. RefMapping
refs:
- association: "TargetModel.Topic.AssocRef"
role: "ZielRolle"
sourceRef: "s.RefOID"
targetRule: "ziel_regel"
| Feld | Pflicht | Beschreibung |
|---|---|---|
|
|
nein |
Qualifizierter Assoziationsname |
|
|
nein |
Rollenname |
|
|
ja |
Ausdruck, der die Referenz-OID liefert |
|
|
ja |
ID der Zielregel, die das referenzierte Objekt erzeugt |
4.8.2. CreateSpec (experimentell)
create:
- class: "TargetModel.Topic.Metadaten"
assign:
Quelle: '"ilitransformer"'
Timestamp: "now()"
4.8.3. LossSpec
loss:
- sourcePath: "s.AlteGeometrie"
reasonCode: "GEOM_VEREINFACHT"
description: "Geometrie wurde vereinfacht"
when: "defined(s.AlteGeometrie)"
| Feld | Pflicht | Beschreibung |
|---|---|---|
|
|
ja |
Quellattribut, das verloren geht |
|
|
ja |
Kategorie des Verlusts |
|
|
ja |
Beschreibung |
|
|
nein |
Bedingung |
4.9. YAML mit ilimap verknüpfen
Für umfangreiche Transformationen können YAML-Dateien auf .ilimap-Dateien verweisen, anstatt alle Regeln inline zu definieren. Das ermöglicht eine modulare Struktur:
version: 1
job:
name: "DM01 nach DMAV"
description: "Modulare Transformation"
modeldir:
- "https://models.interlis.ch/"
inputs:
- id: dm01
path: "eingabe.xtf"
model: "DM01"
outputs:
- id: dmav
path: "ausgabe.xtf"
model: "DMAV"
mapping:
rules: [] # Keine Regeln direkt hier
Die Regeln stehen in separaten .ilimap-Dateien — eine pro Topic oder Klasse:
profiles/dm01-to-dmav/
mapping.yml ← YAML-Datei mit job.inputs/outputs
lfp3.ilimap ← Regeldatei für LFP3
bb.ilimap ← Regeldatei für BB
eo.ilimap ← Regeldatei für EO
gs.ilimap ← Regeldatei für GS
...
4.9.1. Wie die Verlinkung funktioniert
Jede .ilimap-Datei deklariert ihre eigenen input und output mit denselben IDs wie die YAML-Datei:
job:
inputs:
- id: dm01
path: "eingabe.xtf"
model: "DM01"
outputs:
- id: dmav
path: "ausgabe.xtf"
model: "DMAV"
mapping v2 {
input dm01 {
path "eingabe.xtf";
model "DM01";
}
output dmav {
path "ausgabe.xtf";
model "DMAV";
}
rule lfp3 {
target dmav class "DMAV.LFP3";
source s from dm01 class "DM01.LFP3";
...
}
}
4.9.2. Ausführung
Die Transformation wird über die YAML-Datei gestartet. Der Transformer lädt die .ilimap-Dateien aus den in modeldir deklarierten Verzeichnissen:
ilitransformer transform -m profiles/dm01-to-dmav/mapping.yml
|
Die .ilimap-Dateien profitieren von der VS-Code-Erweiterung mit Syntax-Highlighting, Autovervollständigung und Validierung, während die YAML-Datei als schlanker Orchestrator dient. |
5. Ausdruckssprache-Referenz
5.1. Werttypen
Die Ausdruckssprache arbeitet mit einem strengen Typsystem. Jeder Ausdruck evaluiert zu genau einem der folgenden Typen:
| Typ | Beschreibung | Beispiel-Literal |
|---|---|---|
|
|
Zeichenkette |
|
|
|
Numerischer Wert (Ganzzahl oder Fliesskomma) |
|
|
|
Boolescher Wert |
|
|
|
INTERLIS-Datum |
Ergebnis von |
|
|
INTERLIS XML-DateTime |
Ergebnis von |
|
|
INTERLIS-Enumeration |
|
|
|
INTERLIS-Koordinate |
Ergebnis von |
|
|
INTERLIS-Geometrieobjekt |
Quellgeometrie |
|
|
INTERLIS-Referenz |
Ergebnis von |
|
|
Null / nicht gesetzt |
|
5.1.1. null-Behandlung
null verhält sich "ansteckend": Die meisten Funktionen geben null zurück, wenn ein Argument null ist. Ausnahmen:
-
coalesce(a, b, …)— ignoriert null-Argumente -
defined(x)/notDefined(x)— prüfen explizit auf null -
default(x, fallback)— gibtfallbackzurück, wennxnull ist
5.1.2. Typkonvertierung
Die Engine führt keine impliziten Konvertierungen durch. Explizite Konvertierungsfunktionen:
-
toNumber(text)— String → Number -
toXmlDateTime(value)— Date/Text → XMLDateTime -
toDate(value)— XMLDateTime/Text → Date -
toInterlis1Date(value)— Date/XMLDateTime → Text (BASIC_ISO_DATE) -
enumName(value)— Enum → Text
5.2. Grundfunktionen und Operatoren
5.2.1. Grundfunktionen
| Funktion | Signatur | Beschreibung |
|---|---|---|
|
|
|
Erstes nicht-null-Argument (variadisch, lazy) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bedingte Auswertung (lazy: nur der gewählte Zweig wird evaluiert) |
5.2.2. Vergleichsoperatoren
Die Operatoren werden zu den entsprechenden Funktionen desugared:
| Operator | Desugaring | Bedeutung |
|---|---|---|
|
|
|
Gleichheit |
|
|
|
Spezialfall: null-Prüfung |
|
|
|
Ungleichheit |
|
|
|
Spezialfall: nicht-null-Prüfung |
|
|
|
Kleiner als |
|
|
|
Kleiner oder gleich |
|
|
|
Grösser als |
|
|
|
Grösser oder gleich |
5.2.3. Logische Operatoren
| Operator | Desugaring | Bedeutung |
|---|---|---|
|
|
|
Logisches UND (lazy) |
|
|
|
Logisches ODER (lazy) |
|
|
|
Logisches NICHT |
5.2.4. Beispiele
assign {
// coalesce: erstes nicht-null
Name = coalesce(s.Name1, s.Name2, "Unbekannt");
// defined / default
Optional = default(s.Optional, "Kein Wert");
// Bedingung
Status = if(s.Aktiv == true, #aktiv, #inaktiv);
// Logische Verknüpfung
Gueltig = defined(s.Name) and defined(s.Geometrie);
// Vergleich
Gross = s.Anzahl > 100;
}
5.3. String-Funktionen
| Funktion | Signatur | Beschreibung |
|---|---|---|
|
|
|
Strings verketten (variadisch) |
|
|
|
Teilstring extrahieren (1-basiert) |
|
|
|
Whitespace an beiden Enden entfernen |
|
|
|
In Grossbuchstaben umwandeln |
|
|
|
In Kleinbuchstaben umwandeln |
|
|
|
|
|
|
|
Auf maximale Länge kürzen |
5.3.1. Beispiele
assign {
// Trimmen und Grossschreibung
Name = upper(trim(s.Rohname));
// Substring: erstes Zeichen
Initial = substring(s.Name, 1, 1);
// Ersetzung
Bereinigt = replace(s.Text, " ", " ");
// Kürzen auf 60 Zeichen
Kurz = truncate(s.Langtext, 60);
// Verkettung
FullName = concat(s.Vorname, " ", s.Nachname);
}
5.4. Math-Funktionen
| Funktion | Signatur | Beschreibung |
|---|---|---|
|
|
|
Division; |
|
|
|
Multiplikation |
|
|
|
Addition |
|
|
|
Subtraktion |
|
|
|
Runden auf Dezimalstellen (HALF_UP) |
|
|
|
Absolutwert |
|
|
|
Kleinerer von zwei Werten |
|
|
|
Grösserer von zwei Werten |
|
|
|
Text in Zahl umwandeln |
5.5. Date-Funktionen
| Funktion | Signatur | Beschreibung |
|---|---|---|
|
|
|
DATE oder TEXT in INTERLIS.XMLDateTime umwandeln |
|
|
|
XMLDateTime oder TEXT in INTERLIS.Date umwandeln |
|
|
|
In INTERLIS-1-Datumsformat umwandeln (BASIC_ISO_DATE: |
|
|
|
Aktueller Zeitstempel (nicht-deterministisch) |
|
|
5.6. Enum-Funktionen
| Funktion | Signatur | Beschreibung |
|---|---|---|
|
|
|
Wert über benannte Enum-Map abbilden; WARNING bei fehlendem Eintrag |
|
|
|
Wie |
|
|
|
Wie |
|
|
|
Fallback-Wert wenn |
|
|
|
Text-Name eines Enum-Werts |
5.6.1. Beispiele
// enum-Block im Mapping:
enum status_map {
#aktiv => #aktiv;
#inaktiv => #inaktiv;
_ => #unbekannt;
}
assign {
// Standard-Mapping
StatusNeu = enumMap(s.StatusAlt, status_map);
// Mit Fallback
StatusNeu = enumMapDefault(s.StatusAlt, status_map, #unbekannt);
// Strikt (Fehler bei unbekanntem Wert)
StatusNeu = enumMapStrict(s.StatusAlt, status_map);
// Optional mit Default
Status = enumDefault(s.Status, #aktiv);
// Enum-Name als Text
StatusText = enumName(s.Status);
}
5.7. Referenz-Funktionen
| Funktion | Signatur | Beschreibung |
|---|---|---|
|
|
|
OID eines Referenz-Objekts extrahieren |
|
|
|
Prüfen, ob zwei Referenzen auf dasselbe Objekt zeigen |
5.8. Lookup-Funktionen
Lookup-Funktionen suchen Werte in anderen Quellklassen — auch input-übergreifend.
| Funktion | Signatur | Beschreibung |
|---|---|---|
|
|
|
OID des Quellobjekts |
|
|
|
Erstes Attribut aus einem BAG-Attribut |
|
|
|
Unscoped Lookup über alle Inputs; WARNING bei keinem Treffer |
|
|
|
Wie |
|
|
|
Scoped Lookup (nur in |
|
|
|
Existenz-Prüfung mit mehreren Key/Value-Paaren |
5.8.1. Beispiele
assign {
// OID des Quellobjekts
SourceOid = oid(s);
// Erstes Element aus einem Bag
ErsteAdresse = bagFirst(g, Adressen, Strasse);
// Lookup über alle Inputs
Ort = lookup("AV.Ortschaft", "PLZ", s.PLZ, "Ortsname");
// Leiser Lookup (keine Warnung)
Ort = lookupOptional("AV.Ortschaft", "PLZ", s.PLZ, "Ortsname");
// Lookup in bestimmtem Input
Region = lookupIn(src, "AV.Region", "BFS_Nr", s.BFS, "Name");
// Existenz-Prüfung
HatAdresse = existsIn(src, "AV.Adresse", "GebaeudeId", oid(g));
}
5.9. Geometry-Funktionen
| Funktion | Signatur | Beschreibung |
|---|---|---|
|
|
|
Zwei Koordinaten innerhalb einer Toleranz gleich? |
|
|
|
Deterministischer Punkt auf einer SURFACE/MULTISURFACE |
|
|
5.10. Präzedenz und Desugaring
5.10.1. Operatoren-Präzedenz
Von niedrigster zu höchster Bindungsstärke:
| Stufe | Operatoren | Assoziativität |
|---|---|---|
|
1 (niedrigste) |
|
links |
|
2 |
|
links |
|
3 |
|
links |
|
4 |
|
links |
|
5 |
|
rechts |
|
6 (höchste) |
|
— |
5.10.2. Beispiele zur Präzedenz
// a and b or c → (a and b) or c
// a and not b → a and (not b)
// a == b and c > d → (a == b) and (c > d)
// not a and b → (not a) and b
5.10.3. Vollständiges Desugaring
Jeder Operator wird vor der Ausführung in einen Funktionsaufruf umgewandelt:
| Ausdruck | Desugaring |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Lazy-Evaluation von |
6. Format-Referenz
6.1. XTF und ITF
XTF (XML Transfer Format) und ITF (INTERLIS Transfer Format) sind die primären INTERLIS-Austauschformate.
6.1.1. XTF
| Eigenschaft | Unterstützung |
|---|---|
|
Eingabe |
Vollständig |
|
Ausgabe |
Vollständig |
|
Geometrien |
Alle INTERLIS-Geometrietypen |
|
Structures |
Ja |
|
References |
Ja (bidirektionale Auflösung) |
6.1.2. ITF
| Eigenschaft | Unterstützung |
|---|---|
|
Eingabe |
Vollständig |
|
Ausgabe |
Vollständig |
|
Geometrien |
Eingeschränkt (modellabhängig) |
|
Structures |
Modellabhängig |
|
References |
Modellabhängig |
6.1.3. Verwendung
input src {
path "daten/input.xtf";
model "MyModel";
// format xtf; ← optional, wird aus Endung erraten
}
output tgt {
path "daten/output.xtf";
model "MyModel";
format xtf;
option pretty true;
}
|
Bei XTF/ITF wird das Format aus der Dateiendung erraten. Die explizite Angabe von |
6.2. CSV
CSV wird nur als Eingabeformat unterstützt. Jede Zeile entspricht einem Objekt, jede Spalte einem Attribut.
| Eigenschaft | Unterstützung |
|---|---|
|
Eingabe |
Ja |
|
Ausgabe |
Nein |
|
Geometrien |
Nein |
|
Structures |
Nein |
|
References |
Nein |
6.2.1. Optionen
Siehe ilimap-DSL: Formatoptionen für die vollständige Liste der CSV-Optionen.
6.2.2. Beispiel
input csv_src {
path "daten/gebaeude.csv";
model "MyModel";
format csv;
option separator ";";
option firstLineIsHeader true;
option encoding "UTF-8";
}
|
Ohne |
6.3. GeoPackage
GeoPackage wird nur als Eingabeformat unterstützt. Geometrien werden als Simple Features gelesen.
| Eigenschaft | Unterstützung |
|---|---|
|
Eingabe |
Ja |
|
Ausgabe |
Nein |
|
Geometrien |
Simple Features (Point, LineString, Polygon, Multi*) |
|
Structures |
Nein |
|
References |
Nein |
6.4. JDBC
JDBC wird nur als Eingabeformat unterstützt. Es erlaubt das Lesen aus beliebigen relationalen Datenbanken.
| Eigenschaft | Unterstützung |
|---|---|
|
Eingabe |
Ja |
|
Ausgabe |
Nein |
|
Geometrien |
POINT über WKT/WKB; SURFACE über WKT |
|
Structures |
Nein |
|
References |
Nein |
6.4.1. connection-Block
connection {
driver "org.postgresql.Driver";
url "jdbc:postgresql://localhost/mydb";
user "app";
password "secret"; // Klartext
userEnv "DB_USER"; // Umgebungsvariable
passwordEnv "DB_PASS"; // Umgebungsvariable
property "key" "value";
}
|
|
6.4.2. query-Block
query gebauede_query {
topic "Gebaeude";
class "MyModel.Topic.Gebaeude";
basketId "b1";
oidColumn "t_id";
sql "SELECT t_id, name, nummer, geom FROM gebaeude";
column "t_id" "OID";
column "name" "Name";
column "nummer" "Nummer";
geometry geom_attr {
column "geom";
encoding wkb;
type surface;
srid 2056;
}
}
6.4.3. query-Felder
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
|
|
string |
ja |
INTERLIS-Klassenname |
|
|
string |
ja |
SQL-Query |
|
|
string |
nein |
Basket-Topic |
|
|
string |
nein |
Basket-ID |
|
|
string |
nein |
Spalte für OID |
|
|
block |
nein |
DB-Spalte → INTERLIS-Attribut (wiederholbar) |
|
|
block |
nein |
Geometrie-Spalte |
6.5. Shapefile
Shapefile wird als Ein- und Ausgabeformat unterstützt. Es besteht aus mindestens drei Dateien: .shp (Geometrie), .dbf (Attribute) und .shx (Index).
| Eigenschaft | Unterstützung |
|---|---|
|
Eingabe |
Ja |
|
Ausgabe |
Ja |
|
Geometrien |
Point, MultiPoint, Polyline, Polygon (2D) |
|
Structures |
Nein |
|
References |
Nein |
6.5.1. Eingabe-Optionen
| Option | Default | Beschreibung |
|---|---|---|
|
|
(Pflicht) |
INTERLIS-Klassenname |
|
|
aus |
Basket-Topic |
|
|
|
Basket-ID |
|
|
|
DBF-Feld für OID |
|
|
inferiert |
Name des Geometrieattributs |
|
|
aus Shape-Typ |
|
|
|
|
DBF-Kodierung |
|
|
(opt.) |
DBF-Spalte → INTERLIS-Attribut |
|
|
|
|
|
|
|
|
6.5.2. Ausgabe-Optionen
| Option | Default | Beschreibung |
|---|---|---|
|
|
erste geschriebene |
IOX-Klasse |
|
|
inferiert |
Geometrieattribut für |
|
|
aus Geometrie |
|
|
|
|
DBF-Kodierung |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(leer) |
WKT-String für |
|
|
|
Fehler bei mehreren Baskets |
|
DBF-Feldnamen sind auf 10 Zeichen begrenzt. |
6.6. Unterstützungsmatrix
| Format | Eingabe | Ausgabe | Geometrien | Structures | References |
|---|---|---|---|---|---|
|
XTF |
✓ |
✓ |
Alle |
✓ |
✓ |
|
ITF |
✓ |
✓ |
Eingeschränkt |
Modellabhängig |
Modellabhängig |
|
XML |
✓ |
✓ |
Eingeschränkt |
Modellabhängig |
Modellabhängig |
|
CSV |
✓ |
✗ |
✗ |
✗ |
✗ |
|
GeoPackage |
✓ |
✗ |
Simple Features |
✗ |
✗ |
|
JDBC |
✓ |
✗ |
WKT/WKB POINT |
✗ |
✗ |
|
Shapefile |
✓ |
✓ |
Point/MultiPoint/Polyline/Polygon (2D) |
✗ |
✗ |
6.6.1. Format-Erkennung
| Dateiendung / Option | Erkannt als |
|---|---|
|
|
XTF |
|
|
ITF |
|
|
XML |
|
|
CSV (zwingend) |
|
|
GeoPackage (zwingend) |
|
|
JDBC (zwingend, kein |
|
|
Shapefile (zwingend) |
6.6.2. Formate im YAML-Mapping
inputs:
- id: xtf_in
path: "input.xtf"
model: "MyModel"
format: xtf
- id: csv_in
path: "input.csv"
model: "MyModel"
format: csv
options:
separator: ";"
- id: jdbc_in
model: "MyModel"
format: jdbc
connection:
url: "jdbc:postgresql://localhost/db"
userEnv: "DB_USER"
passwordEnv: "DB_PASS"
queries:
- class: "MyModel.Topic.MyClass"
sql: "SELECT * FROM my_table"
Appendix A: Diagnostic-Codes
Jede Diagnosemeldung hat einen Code der Form ILITRF-KATEGORIE-NAME. Die Codes sind hierarchisch nach Kategorie gruppiert.
ILITRF-MAP — Mapping/Compiler
| Code | Severity | Beschreibung |
|---|---|---|
|
|
ERROR |
version-Feld fehlt oder < 1 |
|
|
ERROR |
Regel ohne id |
|
|
ERROR |
Regel-id nicht eindeutig |
|
|
ERROR |
Zielklasse fehlt |
|
|
ERROR |
Output-ID unbekannt |
|
|
ERROR |
Quellklasse fehlt |
|
|
ERROR |
Source-Alias fehlt |
|
|
ERROR |
Source-Alias nicht eindeutig |
|
|
ERROR |
Input-ID unbekannt |
|
|
ERROR |
Source-Input-Feld fehlt |
|
|
ERROR |
Zielklasse nicht im Modell |
|
|
ERROR |
Quellklasse nicht im Modell |
|
|
ERROR |
Zielklasse ist abstrakt |
|
|
ERROR |
Zielattribut nicht im Modell |
|
|
WARNING |
Quellattribut nicht im Modell |
|
|
WARNING |
Rolle nicht in Zielklasse |
|
|
WARNING |
Typ des Ausdrucks passt nicht |
|
|
WARNING |
Pflichtattribut nicht gesetzt |
|
|
ERROR |
Zielattribut doppelt zugewiesen |
|
|
ERROR |
Zyklische Regel-Abhängigkeit |
|
|
WARNING |
Zielklasse ist View |
|
|
ERROR |
OID-Strategie inkompatibel |
ILITRF-MODEL — Modell
| Code | Severity | Beschreibung |
|---|---|---|
|
|
ERROR |
Modellkompilierung fehlgeschlagen |
ILITRF-RUN — Laufzeit
| Code | Severity | Beschreibung |
|---|---|---|
|
|
WARNING / ERROR |
Referenz nicht auflösbar |
|
|
ERROR |
Referenz mehrdeutig |
|
|
WARNING / ERROR |
Falsche Zielklasse |
|
|
WARNING / ERROR |
Pflicht-Referenz fehlt |
|
|
WARNING |
Kardinalität verletzt |
|
|
ERROR |
OID-Kollision |
|
|
ERROR |
Basket-Zuordnung fehlgeschlagen |
|
|
ERROR |
Quelle nicht lesbar |
|
|
ERROR |
Ziel nicht schreibbar |
|
|
ERROR |
Ausdrucks-Evaluierung fehlgeschlagen |
|
|
ERROR |
Kardinalität verletzt |
ILITRF-EXPR — Ausdrücke
| Code | Severity | Beschreibung |
|---|---|---|
|
|
ERROR |
Syntaxfehler im Ausdruck |
|
|
ERROR |
Unbekannte Funktion |
|
|
ERROR |
Typfehler |
|
|
WARNING |
Nicht-deterministische Funktion verwendet |
|
|
WARNING |
Feature noch nicht unterstützt |
Appendix B: OID- und Basket-Strategien
OID-Strategien
| Strategie | Verhalten | Namespace |
|---|---|---|
|
|
OID unverändert aus der Quelle übernehmen |
— |
|
|
Fortlaufende Ganzzahlen (1, 2, 3, …) |
— |
|
|
Zufällige UUIDv4 generieren |
— |
|
|
UUIDv5 aus Namespace + Quell-OID ableiten |
Pflicht |
|
|
Reserviert, nicht implementiert |
— |
deterministicUuid im Detail
deterministicUuid verwendet UUIDv5 (SHA-1-basiert) mit einem konfigurierbaren Namespace. Die resultierende UUID ist nur vom Namespace und der Quell-OID abhängig — sie bleibt über mehrere Transformationsläufe hinweg stabil.
oid deterministicUuid {
namespace "ch.admin.geo";
}
|
Ändern Sie den Namespace nicht nach der ersten Transformation. Ein neuer Namespace erzeugt andere UUIDs und bricht bestehende Referenzen. |
Basket-Strategien
| Strategie | Verhalten |
|---|---|
|
|
Basket-ID unverändert aus der Quelle übernehmen |
|
|
Für jedes Zielobjekt einen neuen UUID-Basket generieren |
|
|
Quelle übernehmen wenn vorhanden, sonst UUID generieren |
|
|
Objekte nach INTERLIS-Topic in separate Baskets gruppieren |
|
|
Reserviert, nicht implementiert |
Matrix: Strategie pro Anwendungsfall
| Anwendungsfall | Empfohlene OID | Empfohlener Basket | Begründung |
|---|---|---|---|
|
1:1-Kopie |
|
|
Identität erhalten |
|
Neue Objekte |
|
|
Eindeutigkeit + Herkunft |
|
Wiederholbare Migration |
|
|
Reproduzierbarkeit |
|
Modell-Merge |
|
|
Trennung nach Thema |
Appendix C: Beispiele
Dieser Anhang enthält vollständige, lauffähige Minimalbeispiele. Alle Beispiele sind im Repository unter demo/ verfügbar.
Demo 01 — Hello Copy (ilimap)
models/hello.ili)
INTERLIS 2.4;
MODEL HelloDemo (en)
AT "https://demo.ilinexus.ch" VERSION "2026-06-22" =
TOPIC Persons =
BASKET OID AS INTERLIS.UUIDOID;
OID AS INTERLIS.UUIDOID;
CLASS Source =
Name: MANDATORY TEXT*60;
Anzahl: 0 .. 9999;
Aktiv: BOOLEAN;
END Source;
CLASS Target =
Label: MANDATORY TEXT*60;
LabelGross: TEXT*60;
Anzahl: 0 .. 9999;
Aktiv: BOOLEAN;
END Target;
END Persons;
END HelloDemo.
data/input.xtf)
<?xml version="1.0" encoding="UTF-8"?>
<ili:transfer xmlns:ili="http://www.interlis.ch/xtf/2.4/INTERLIS"
xmlns:HelloDemo="http://www.interlis.ch/xtf/2.4/HelloDemo">
<ili:headersection>
<ili:models>
<ili:model>HelloDemo</ili:model>
</ili:models>
<ili:sender>demo</ili:sender>
</ili:headersection>
<ili:datasection>
<HelloDemo:Persons ili:bid="b1">
<HelloDemo:Source ili:tid="001">
<HelloDemo:Name> Alice Mueller </HelloDemo:Name>
<HelloDemo:Anzahl>42</HelloDemo:Anzahl>
<HelloDemo:Aktiv>true</HelloDemo:Aktiv>
</HelloDemo:Source>
</HelloDemo:Persons>
</ili:datasection>
</ili:transfer>
profile.ilimap)
mapping v2 "demo-01-hello-copy" {
job {
description "1:1-Kopie mit String-Expressions";
modeldir "models/";
}
input src {
path "data/input.xtf";
model "HelloDemo";
}
output tgt {
path "output.xtf";
model "HelloDemo";
}
oid uuid;
rule copy {
target tgt class "HelloDemo.Persons.Target";
source s from src class "HelloDemo.Persons.Source";
assign {
Label = trim(s.Name);
LabelGross = upper(trim(s.Name));
Anzahl = s.Anzahl;
Aktiv = s.Aktiv;
}
}
}
ilitransformer validate-mapping -m profile.ilimap
ilitransformer transform -m profile.ilimap --validate
Demo 01 — Hello Copy (YAML)
mapping.yml)
version: 1
job:
description: "1:1-Kopie mit String-Expressions"
modeldir:
- "models/"
inputs:
- id: src
path: "data/input.xtf"
model: "HelloDemo"
outputs:
- id: tgt
path: "output.xtf"
model: "HelloDemo"
mapping:
oidStrategy:
type: uuid
rules:
- id: "copy"
target:
output: tgt
class: "HelloDemo.Persons.Target"
sources:
- input: src
alias: s
class: "HelloDemo.Persons.Source"
assign:
Label: "trim(s.Name)"
LabelGross: "upper(trim(s.Name))"
Anzahl: "s.Anzahl"
Aktiv: "s.Aktiv"
Demo 05 — Bedingungen (ilimap)
mapping v2 {
job {
modeldir "models/";
}
input src {
path "input.xtf";
model "HelloDemo";
}
output tgt {
path "output.xtf";
model "HelloDemo";
}
oid uuid;
rule conditional {
target tgt class "HelloDemo.Persons.Target";
source s from src class "HelloDemo.Persons.Source";
assign {
// if, defined, coalesce
Label = if(defined(s.Name), trim(s.Name), "Unbekannt");
Status = coalesce(s.StatusA, s.StatusB, #inaktiv);
Gross = s.Anzahl > 50;
Kategorie = if(s.Anzahl < 10, "Klein",
if(s.Anzahl < 100, "Mittel", "Gross"));
}
}
}
|
Die vollständige Demo-Suite mit allen 9 Beispielen — von einfachen Kopien über BAG OF STRUCTURE bis zu OID-Strategien — finden Sie im Repository unter |
Appendix D: ilimap-Grammatik (EBNF)
Diese Grammatik beschreibt die vollständige Syntax der ilimap-DSL in erweiterter Backus-Naur-Form.
Top-Level
mapping = "mapping" "v2" [STRING] "{" {job} {input} {output}
{oid} {basket} {enumBlock} {defaults} {rule} "}"
job = "job" "{" {stmt} "}"
stmt = name | description | direction | failPolicy
| compileMode | modeldir
input = "input" ID "{" {path | model | format | option
| connection | query} "}"
output = "output" ID "{" {path | model | format | option} "}"
oid = "oid" ID ["{" [namespace] "}"] ";"
basket = "basket" ID ";"
enumBlock = "enum" ID "{" {entry} "}"
entry = literal "=>" literal ";"
defaults = "defaults" "{" {assign} "}"
rule = "rule" ID "{" target source [{source}] [where]
[join] [identity] [assignBlock] [defaults]
{bag} {ref} [{create}] {loss} [metadata] "}"
rule-Elemente
target = "target" ID "class" STRING ";"
source = "source" ID "from" ID {"," ID} "class" STRING
["where" expr] ";"
where = "where" expr ";"
join = "join" ("inner" | "left") ID "to" ID "on" expr ";"
identity = "identity" expr {"," expr} ";"
assignBlock = "assign" "{" {assign} "}"
assign = ID "=" expr ";"
bag und ref
bag = "bag" ID "{" [from] [target] structure [mode]
[maxItems] [parentRef] [where] [assignBlock]
{bag} "}"
ref = "ref" ID "{" [association] [role] [required]
targetRef "}"
create = "create" "class" STRING "{" assignBlock "}"
loss = "loss" "{" sourcePath reasonCode description [when] "}"
metadata = "metadata" "{" {direction | roundtrip | lossiness} "}"
Lexikalische Tokens
ID = [a-zA-Z][a-zA-Z0-9_-]* // symbolId
ALIAS = [a-zA-Z][a-zA-Z0-9_]* // aliasId (ohne '-')
STRING = '"' {char} '"'
INT = [0-9]+
FLOAT = [0-9]+ "." [0-9]+
BOOL = "true" | "false"
NULL = "null"
HASH = "#" ID // Enum-Literal
COMMENT = "//" {char} "\n" // Zeilenkommentar
| "/*" {char} "*/" // Block-Kommentar
RESERVED = "mapping" | "job" | "input" | "output" | "oid"
| "basket" | "enum" | "rule" | "target" | "source"
| "from" | "where" | "join" | "identity" | "assign"
| "defaults" | "bag" | "ref" | "create" | "loss"
| "metadata" | "class" | "inner" | "left" | "mode"
| "structure" | "maxItems" | "parentRef"
| "association" | "role" | "required" | "sourcePath"
| "reasonCode" | "description" | "when" | "direction"
| "roundtrip" | "lossiness" | "option"
| "true" | "false" | "null"
Ausdrücke
Die Ausdrucksgrammatik ist in Kapitel 5.10 dokumentiert.