6 ili2db Schema Import - geostandards-ch/ili2db_ilivalidator_de GitHub Wiki
Dieses Kapitel beschreibt das Schema-Import Tool von ili2db. Dieses Tool wird hauptsächlich verwendet, um ein INTERLIS Schema in eine Datenbank zu importieren.
Die konkreten Beispiele werden mit dem Tool ili2gpkg illustriert, d. h. bezüglich des Imports von Schema im Geopackage-Format. Eventuelle Besonderheiten der beiden anderen Werkzeuge (ili2gdb, ili2pg) werden in speziellen Hinweisen erläutert.
Der Inhalt und Komplexitätsgrad des Modelles entscheidet ob ein einfacher Import genügt oder ein komplexer Import nötig ist.
Unter einem “Einfachen Import” verstehen wir hier, dass das Schema-Import-Tool mit allen Standardeinstellungen verwendet wird.
Der einfachste Schema-Import liest das INTERLIS Modell und erstellt auf dessen Grundlage die Tabellen in der (Geo-)Datenbank. Falls die Geodatabase noch nicht besteht, wird diese vorher erzeugt. Das Tool braucht neben dem INTERLIS Modell noch die zwei folgenden Parameter:
--schemaimport: Dieser Parameter veranlasst, dass ein Schema in der Datenbank erstellt wird --dbfile: Dieser Parameter enthält den Pfad zur (Geo-)Datenbank
Konkretes Beispiel: öffnen Sie die Kommandozeile und passen Sie die Pfade im folgenden Code an. In diesem Kapitel wird das Modell ili Level 1 verwendet:
java -jar ili2gpkg-4.6.0.jar --schemaimport --dbfile <path/geodatabase.gdb> <path/ilimodel.ili>
Führe den Code aus
Das Tool wird die Tabellen erstellen, wenn sie noch nicht existieren.
| Quelle | Resultat |
|---|---|
INTERLIS Modell Auengebiete_KB1. Wir haben hier zwei Domänen, zwei Klassen sowie eine Assoziation. 
|
Öffne die Database und kontrolliere das Resultat Die verschiedenen Tabellen können z.B. in QGIS geöffnet werden. In diesem Fall wurden zwei Tabellen kreiert. Die Tabellen Auengebiet_Teilobjekt_KB1 und Auengebiet_KB1 entsprechen den Klassen aus dem INTERLIS Modell. Tabellen generiert im gpkg File für ili Level 1: 
Die Tabellen T_ILI2DB* wurden automatisch kreiert und dienen dazu INTERLIS Metadaten zu speichern. |
Es gibt eine Besonderheit, die nur für PostGIS gilt. Wenn das Tool ili2pg verwendet wird, müssen der Benutzer und das Passwort der Datenbank angegeben werden. Dafür werden die folgenden Parameter verwendet:
--dbusr und --dbpwd
Ferner muss anstelle der Zieldatei die Postgres-Datenbank angegeben werden, dies geschieht mit dem Parameter --dbdatabase.
Beispiel:
java -jar ili2pg.jar --schemaimport --dbdatabase <dbName> --dbusr <User> --dbpwd <Passwort> <path/ilimodel.ili>
Unter einem komplexen Import verstehen wir hier, wenn nicht nur Tabellen importiert werden müssen, sondern auch weitere INTERLIS-Elemente wie Domainen, Strukturen, Beziehungen etc. Der Import erfolgt auf ähnliche Weise wie beim einfachen Beispiel (siehe oben). Zuerst ist es immer noch der einfachste Weg, ein Schema zu importieren (ohne Parameter), aber das Schema ist komplexer.
Konkretes Beispiel: öffnen Sie wenn nötig die Kommandozeile und passen Sie die Pfade im folgenden Code an. In diesem Kapitel wird das Modell ili Level 2 verwendet:
java -jar ili2gpkg-4.6.0.jar --schemaimport --dbfile <path/geodatabase.gpkg> <path/ilimodel.ili>
Das Import-Log sollte mit "…done" enden.
| Quelle | Resultat |
|---|---|
|
Das Ergebnis wird in die geopackage importiert. Tabellen werden generiert im gpkg File für ili Level 2: 
|
Hinweis: Wenn die gpkg nicht vorhanden war, wird sie erstellt. Wenn sie existierte, wird sie ergänzt; in einer bereits bestehenden Datenbank werden somit keine Daten gelöscht.
Wir sehen im Ergebnis, dass mehr Tabellen erstellt worden sind als im einfachen Beispiel weiter oben. Diese Tabellen stammen zum einen beispielsweise aus einem Modell, welches wegen seinen Wertelisten mitimportiert wurde. Im Beispiel weiter unten wird beispielsweise die Codeliste für Auengebiete importiert:
Die Herkunft dieser neuen Tabellen wird hier erklärt:
| Tabelle | Herkunft |
|---|---|
multilingualtext |
Model LocalisationCH_V1 |
localisedtext |
Struktur Element in LocalisationCH_V1 |
typ_catalogue |
Klasse definiert im Model Auengebiete_Codelisten_V1_1, erweitert CatalogueObjects_V1.Catalogues.Item |
typ_catref |
Klasse definiert im Model Auengebiete_Codelisten_V1_1, referenziert typ_catalogue |
multilingualmtext |
Benutzt im Objekt BasisObjekt.Mutationsgrund. Im Modell LocalisationCH_V1 definiert. |
localisedMText |
Ist benutzt im multilingualmtext. Im Modell LocalisationCH_V1 definiert. |
polygonstructure |
Struktur ist definiert im Model Auengebiete_KB2, ist basiert auf polygon von Model GeometryCHLV95_V1 |
amultipolygon |
Diese Tabelle repräsentiert ein Multipolygon. Sie ist ein Zwischending zwischen der Tabelle polygonstructure und auengebiet_teilobjekt_kb2. |
Zum anderen stammen zusätzliche Tabellen beispielsweise aus Ergänzungen/Erweiterungen des Beispielmodelles weiter oben. Dies ist der Fall für die Klasse BasisObjekt, die durch die Klasse Auengebiet_KB2 erweitert wird.
Beim Schema-Import besteht die Option neben dem Datenbank Schema auch noch zusätzliche Tabellen zu importieren, welche Domänen enthalten. Im Folgenden werden wir ein einfaches Beispiel eines Domänen-Importes vorstellten und verweisen für weiterführende Information zum Importieren von Domänen auf die ausführliche Dokumentation: https://github.com/claeis/ili2db/blob/master/docs/ili2db.rst#aufz%C3%A4hlungen
Mit der folgenden Option kann eine Tabelle pro Domäne erstellt werden:
--createEnumTabs
Zum Beispiel:
java -jar ili2gpkg.jar --schemaimport --createEnumTabs --dbfile Level1_auengebiete_enumT.gpkg Auengebiete_KB1.ili
| Quelle | Resultat |
|---|---|
Die Werten von DesignationType und IUCNCategory: 
|
"designationtype" und "iucncategory" sind Domäne im ili File und werden als Tabelle modeliert: 
Diese Tabellen werden mit Werten aus den Domänen gefüllt. Resulat im GPKG für DesignationType: 
|
Die Übertragung von Domänen von INTERLIS in die ESRI-Welt kann nicht direkt erfolgen, sondern muss über Tabellen geschehen, die anschliessend in ArcGIS zu Domänen konvertiert werden. Die Option Domänen-Import des Tool ili2fgdb erstellt somit einzig Tabellen, die anschliessend für die Arbeit in ArcGIS z. B. für die Erzeugung von Domänen verwendet werden können (siehe https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/table-to-domain.htm).
Beim Schema-Import besteht die Option neben dem Datenbank Schema auch noch Beziehungen zwischen Objekten von Tabellen zu definieren. Solche Beziehungen werden ebenfalls im INTERLIS-Modell definiert. Im folgenden Beispiel ist die Kardinalität zwischen Auengebiet_Teilobjekt und Auengebiet_Teilobjet_KB1 1:n:
Es ist interessant zu sehen, wie es in der gpkg mit einem Fremdschlüssel Auengebiet modelliert wird:
Wenn die Kardinalität vom Typus n:m wäre, erstellt das Tool ili2gpkg automatisch eine Zwischentabelle.
Die vollständige Dokumentation zum Thema Association finden unter folgendem Link: https://github.com/claeis/ili2db/blob/master/docs/ili2db.rst#beziehungen
Da in INTERLIS die Vererbung zwischen Klassen von unterschiedlichem Typ möglich ist, können die ili2db-Tools die Klassen auf unterschiedliche Arten importieren.
Die vollständige Dokumentation ist hier verfügbar: https://github.com/claeis/ili2db/blob/master/docs/ili2db.rst#vererbung
Wenn eine Klasse von einer anderen Klasse erben soll, kann mit dem Option “noSmartMapping” definiert werden, ob sowohl von der erbende als auch von der vererbenden Klasse eine Tabelle erstellt werden soll.
Erweitert beispielsweise die Klasse B die Klasse A, so bewirkt das Setzen des Parameters “noSmartMapping”, dass für jede Klasse eine Tabelle erstellt wird, also eine Tabelle A und eine Tabelle B. Entfällt hingegen dieser Parameter, so wird nur die Tabelle B erstellt.
Alle strukturellen Abbildungsoptimierungen werden ausgeschaltet. Deswegen werden alle Strukturen erstellt.
Zum Beispiel:
java -jar ili2gpkg.jar --schemaimport --noSmartMapping --dbfile Level2_noSmartM.gpkg Auengebiete_KB2.ili
| Quelle | Resultat |
|---|---|
Die Klasse BasisObjekt ist in der ili-Datei vorhanden und wird durch die Klasse Auengebiet_KB2 erweitert. 
|
Der links genannte Aufruf erstellt das Schema, ohne die "Extends" zu berücksichtigen. Die Tabelle BasisObjekt wird erstellt. 
Attribute von Tabelle BasisObjekt: 
|
Wenn eine Klasse von einer anderen Klasse erben soll, kann mit den Optionen smart1Inheritance bzw. smart2Inheritance präzisiert werden, wie dies geschehen sollen.
Folgendes sind die vereinfacht erklärten Unterschiede zwischen den beiden Optionen:
-
smart1Inheritance: Mit der Wahl der Option smart1Inheritance wird von jeder Elternklasse eine Klasse erstellt, ausser wenn es sich um eine abstrakte Elternklasse handelt. In diesem Fall wird/werden die Kindklasse(n) erstellt.
-
smart2Inheritance: Mit der Wahl der Option smart2Inheritance werden nur Kindklassen erstellt, ausser wenn die Elternklasse nicht abstrakt sind.
Die Art und Weise, wie die Vererbung modelliert und entsprechend in der Modelldatei beschrieben wurde, entscheidet darüber, welche Option gewählt wird. Die vollständige Dokumentation diesbezüglich ist hier einsehbar: https://github.com/claeis/ili2db/blob/master/docs/ili2db.rst#vererbung
In unserem Beispiel kann smart1Inheritance verwendet werden:
java -jar ili2gpkg.jar --schemaimport --smart1Inheritance --dbfile Level2_smart1I.gpkg Auengebiete_KB2.ili
| Quelle | Resultat |
|---|---|
Die Klasse BasisObjekt ist abstrakt. Auengebiet_KB2 erbt von der Klasse BasisObjekt (mittels EXTENDS).
|
Das Tool erstellt keine eigenständige Tabelle der Klasse BasisObjekt, weil diese abstrakt ist. Hingegen werden in der Klasse Auengebiet_KB2 die Attribute von BasisObjekt übernommen. Hier zeigt sich, dass eine Tabelle einer übergeordneten Klasse nur angelegt wird, wenn diese nicht abstrakt ist. 
Attribute von auengebiet_kb2: 
|
Die CHBase-Modellierungsbausteine ermöglichen es, Attribute als multilingual, also in mehreren Sprachen zu definieren.
Im folgenden Beispiel wird das Werkzeug ili2gpkg standardmässig (ohne besondere Einstellungen) auf dem INTERLIS Level 2 Modell (siehe Kapitel 4) verwendet, das ein Attribut multilingual enthält.
Das INTERLIS-Glossar kann hilfreich sein, um bestimmte Begriffe zu erklären.:
java -jar ili2gpkg.jar --schemaimport --dbfile Level2_auengebiete_multilingual.gpkg Auengebiete_KB2.ili
| Quelle | Resultat |
|---|---|
Das Modell LokalisierungCH_V1 enthält unter anderem die INTERLIS-Struktur MultilingualText: 
Diese Struktur besteht aus einem BAG OF der INTERLIS-Struktur LocalisedText: 
|
Resultat im GPKG für das Attribut Mutationsgrund: Standardmässig generieren das Tool ili2db zwei zusätzliche Tabellen multilingualtext und localisedtext. 
Die Tabelle localisedtext enthält die Werte (Attribut atext) in den verschiedenen Sprachen (Attribut alanguage): 
|
Darüber hinaus wird die Verwendung des Tools mit Standardeinstellungen (siehe oben) auch eine Vereinfachung dieser komplexen Modellierung generieren. Die Klasse Auengebiet_KB2 enthält ausserdem zusätzliche Spalten für die verschiedenen Sprachen des Attributs Mutationsgrund:
Es gibt zwei Möglichkeiten, diese Vereinfachung zu aktivieren: standardmässig wird smart1inheritance angewendet oder mithilfe des folgenden Parameters:
--expandMultilingual
Zum Beispiel mit dem folgenden Kommando:
java -jar ili2gpkg.jar --schemaimport --expandMultilingual --dbfile Level2_auengebiete_expM.gpkg Auengebiete_KB2.ili
Wenn die Geometrie als MultiLine oder MultiSurface definiert ist, wird eine Multipart-Klasse in der Datenbank erstellt.
Im folgenden Beispiel wird das Tool ili2gpkg standardmässig (ohne besondere Einstellungen) auf dem INTERLIS Level 2 Modell verwendet, welches ein Attribut MultiSurface names Geo_Obj enthält.
java -jar ili2gpkg.jar --schemaimport --dbfile Level2_auengebiete_MultiSurf.gpkg Auengebiete_KB2.ili
| Quelle | Resultat |
|---|---|
Wir sehen hier, dass die Klasse Auengebiet_Teilobjekt_KB2 als Multipart definiert ist: 
Im CH-Base Modell GeometryCHLV95_V1 sehen wir, dass die Struktur besteht aus einem BAG OF der INTERLIS-Struktur SurfaceStructure besteht: 
|
Standardmässig erstellt das ili2gpkg-Tool diese Elemente separat: die Tabelle multisurface und die Polygonklasse surfacestructure, die die single part-Geometrien enthalten wird. 
Attribute von multisurface: 
Attribute von surfacestructure: 
Mithilfe von Primär- und Fremdschlüsseln stellt das Tool Beziehungen zwischen Objekten. |
Es ist jedoch wichtig zu erwähnen, dass während des Schema Importes auch wieder eine Vereinfachung stattgefunden hat: die Klasse Auengebiet_Teilobjekt_KB2 ist selbst eine Polygonklasse. Dies ermöglicht es, Multipart-Objekte direkt hier zu speichern, ohne die Klassen multisurface und surfacestructure zu verwenden:
Es gibt zwei Möglichkeiten, diese Vereinfachung zu aktivieren: standardmässig wird smart1inheritance angewendet oder mithilfe des folgenden Parameters:
--coalesceMultiSurface
Zum Beispiel mit dem folgenden Kommando:
java -jar ili2gpkg.jar --schemaimport --coalesceMultiSurface --dbfile Level2_auengebiete_coalMultiSrf.gpkg Auengebiete_KB2.ili
Wenn der Wert eines Attributs auf eine Liste von Codes beschränkt ist, wird häufig ein Katalog verwendet. Kataloge ermöglichen, die zu verwendenden Codes sowie ihre Bedeutungen in mehreren Sprachen zu definieren. Kataloge werden meistens in einer XML-Datei geliefert, die an das INTERLIS-Modell angehängt ist.
Im folgenden Beispiel wird das Werkzeug ili2gpkg standardmässig (ohne besondere Einstellungen) auf dem INTERLIS Level 2 Modell verwendet, bei welchem das Attribut Typ eine CatalogueReference enthält.
java -jar ili2gpkg.jar --schemaimport --dbfile Level2_auengebiete_CatRef.gpkg Auengebiete_KB2.ili
| Quelle | Resultat |
|---|---|
Wir sehen hier, dass das Attribut Typ der Klasse Auengebiet_Teilobjekt_KB2 als Catalogue (TYP_CatRef) definiert ist: 
Der Katalog TYP_CatRef wird im Modell CatalogueObjects_V1 definiert. Der Katalog verweist auf die Klasse TYP_Catalogue, die die beiden Attribute Code und Description enthält: 
Die Klasse TYP_Catalogue ist eine Erweiterung der Klasse Item, die aus dem Modell CH Basis CatalogueObjects_V1 stammt. Ausserdem fällt auf, dass das Attribut Description vom Typ multilingual ist (siehe Kapitel Multilingual). |
Standardmässig erstellt das ili2gpkg-Tool diese Elemente separat: zwei Tabellen typ_catalogue und typ_catref werden erstellt, um der INTERLIS-Modellierung zu entsprechen. 
Attribute von typ_catref: 
Attribute von typ_catalog: 
Mithilfe von Primär- (T_Id) und Fremdschlüsseln (areference) können Beziehungen zwischen Objekten hergestellt werden. |
Die Standardverwendung (ohne besondere Einstellung), bei der die Strategie smart1Inheritance angewendet wird, sowie das folgende Parameter…
--coalesceCatalogueRef
…ermöglicht eine Vereinfachung der Modellierung. Es wird nur die zusätzliche Tabelle typ_catalogue verwendet. Sie ist direkt mit dem entsprechenden Attribut typ in der Klasse Auengebiet_KB2 verknüpft.