Permalink
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
727 lines (585 sloc) 32.9 KB

gretl

Das Datenmanagement-Tool GRETL ist ein Werkzeug, das für Datenimports, Datenumbauten (Modellumbau) und Datenexports eingesetzt wird. GRETL führt Jobs aus, wobei ein Job aus mehreren atomaren Tasks besteht. Damit ein Job als vollständig ausgeführt gilt, muss jeder zum Job gehörende Task vollständig ausgeführt worden sein. Schlägt ein Task fehl, gilt auch der Job als fehlgeschlagen.

Ein Job besteht aus einem oder mehreren Tasks, die gemäss einem gerichteten Graphen (Directed Acyclic Graph; DAG) miteinander verknüpft sind.

Ein Job kann aus z.B. aus einer linearen Kette von Tasks bestehen:

Task 1 – Task 2 – Task 3 – Task n

Beispiel: Datenimport aus INTERLIS-Datei – Datenumbau – Datenexport nach Shapefile.

Ein Job kann sich nach einem Task aber auch auf zwei oder mehr verschiedene weitere Tasks verzweigen:

      - Task 2 – Task 3 – Task n
Task 1 –
      – Task 4 – Task 5 – Task m

Beispiel: Datenimport aus INTERLIS-Datei – Datenumbau in Zielschema 1 und ein zweiter Datenumbau in Zielschema 2.

Es ist auch möglich, dass zuerst zwei oder mehr Tasks unabhängig voneinander ausgeführt werden müssen, bevor ein einzelner weiterer Task ausgeführt wird.

Task 1 –
       – Task 3 – Task 4 – Task n
Task 2 –

Die Tasks eines Jobs werden per Konfigurationsfile konfiguriert.

Kleines Beispiel

Erstellen sie in einem neuen Verzeichnis gretldemo eine neue Datei build.gradle:

import ch.so.agi.gretl.tasks.*
import ch.so.agi.gretl.api.*

apply plugin: 'ch.so.agi.gretl'

buildscript {
	repositories {
		maven {
			url "http://jars.interlis.ch"
		}
		maven {
			url "http://jars.umleditor.org"
		}
		maven {
			url "http://download.osgeo.org/webdav/geotools/"
		}
		mavenCentral()
	}
	dependencies {
		classpath group: 'ch.so.agi', name: 'gretl',  version: '1.0.+'
	}
}

defaultTasks 'validate'


task validate(type: IliValidator){
    dataFiles = ["BeispielA.xtf"]
}

Die Datei build.gradle ist die Job-Konfiguration. Dieser kleine Beispiel-Job besteht nur aus einem einzigen Task: validate.

Erstellen Sie nun noch die Datei BeispielA.xtf (damit danach der Job erfolgreich ausgeführt werden kann).

<?xml version="1.0" encoding="UTF-8"?>
<TRANSFER xmlns="http://www.interlis.ch/INTERLIS2.3">
	<HEADERSECTION SENDER="gretldemo" VERSION="2.3">
	</HEADERSECTION>
	<DATASECTION>
		<OeREBKRMtrsfr_V1_1.Transferstruktur BID="B01">
		</OeREBKRMtrsfr_V1_1.Transferstruktur>
	</DATASECTION>
</TRANSFER>

Um den Job auszuführen, wechseln Sie ins Verzeichnis mit der Job-Konfiguration, und geben da das Kommando gradle ohne Argument ein:

cd gretldemo
gradle

Sie sollten etwa folgende Ausgabe erhalten:

Starting a Gradle Daemon, 1 incompatible and 1 stopped Daemons could not be reused, use --status for details
Download http://jars.umleditor.org/ch/so/agi/gretl/maven-metadata.xml
Download http://jars.umleditor.org/ch/so/agi/gretl/1.0.4-SNAPSHOT/maven-metadata.xml
Download http://jars.umleditor.org/ch/so/agi/gretl/1.0.4-SNAPSHOT/gretl-1.0.4-20180104.152357-34.jar

BUILD SUCCESSFUL in 21s

BUILD SUCCESSFUL zeigt an, dass der Job (die Validierung der Datei BeispielA.xtf) erfolgreich ausgeführt wurde.

Um dieselbe Job-Konfiguration für verschiedene Datensätze verwenden zu können, muss es parametrisierbar sein. Die Jobs/Tasks können so generisch konfiguriert werden, dass dieselbe Konfiguration z.B. für Daten aus verschiedenen Gemeinden benutzt werden kann. Parameter für die Job Konfiguration können z.B. mittels gradle-Properties (Gradle properties and system properties) dem Job mitgegeben werden, also z.B.

cd gretldemo
gradle -Pdataset=Olten

System Anforderungen

Um die aktuelle Version von gretl auszuführen, muss

  • die JAVA-Laufzeitumgebung (JRE), Version 1.8 oder neuer, und
  • gradle, Version 3.4 oder neuer, auf Ihrem System installiert sein.

Die JAVA-Laufzeitumgebung (JRE) kann auf der Website http://www.java.com/ gratis bezogen werden.

Die gradle-Software kann auf der Website http://www.gradle.org/ gratis bezogen werden.

Um GRETL laufen zu lassen, benötigen sie typischerweise eine Internetverbindung (Ein Installation, die keine Internetverbindung benötigt ist auch möglich, aber aufwendig).

Installation

GRETL selbst muss nicht explizit installiert werden, sondern wird dynamisch durch das Internet bezogen.

Ausführen

Um gretl auszuführen, geben Sie auf der Kommandozeile folgendes Kommando ein (wobei jobfolder der absolute Pfad zu ihrem Verzeichnis mit der Job Konfiguration ist.)

gradle --project-dir jobfolder

Alternativ können Sie auch ins Verzeichnis mit der Job Konfiguration wechseln, und da das Kommando gradle ohne Argument verwenden:

cd jobfolder
gradle

Tasks

CsvExport

Daten aus einer bestehenden Datenbanktabelle werden in eine CSV-Datei exportiert.

Beispiel:

def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task csvexport(type: CsvExport){
    database = [db_uri, db_user, db_pass]
    schemaName = "csvexport"
    tableName = "exportdata"
    firstLineIsHeader=true
    attributes = [ "t_id","Aint"]
    dataFile = "data.csv"
}
Parameter Beschreibung
database Datenbank aus der exportiert werden soll.
dataFile Name der CSV-Datei, die erstellt werden soll.
tableName Name der DB-Tabelle, die exportiert werden soll
schemaName Name des DB-Schemas, in dem die DB-Tabelle ist.
firstLineIsHeader Definiert, ob eine Headerzeile geschrieben werden soll, oder nicht. Default: true
valueDelimiter Zeichen, das am Anfang und Ende jeden Wertes geschrieben werden soll. Default "
valueSeparator Zeichen, das als Trennzeichen zwischen den Werten verwendet werden soll. Default: ,
attributes Spalten der DB-Tabelle, die exportiert werden sollen. Definiert die Reihenfolge der Spalten in der CSV-Datei. Default: alle Spalten
encoding Zeichencodierung der CSV-Datei, z.B. "UTF-8". Default: Systemeinstellung

Geometriespalten können nicht exportiert werden.

CsvImport

Daten aus einer CSV-Datei werden in eine bestehende Datenbanktabelle importiert.

Beispiel:

def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task csvimport(type: CsvImport){
    database = [db_uri, db_user, db_pass]
    schemaName = "csvimport"
    tableName = "importdata"
    firstLineIsHeader=true
    dataFile = "data1.csv"
}
Parameter Beschreibung
database Datenbank in die importiert werden soll
dataFile Name der CSV-Datei, die gelesen werden soll
tableName Name der DB-Tabelle, in die importiert werden soll
schemaName Name des DB-Schemas, in dem die DB-Tabelle ist.
firstLineIsHeader Definiert, ob die CSV-Datei einer Headerzeile hat, oder nicht. Default: true
valueDelimiter Zeichen, das am Anfang und Ende jeden Wertes vorhanden ist. Default "
valueSeparator Zeichen, das als Trennzeichen zwischen den Werten interpretiert werden soll. Default: ,
encoding Zeichencodierung der CSV-Datei, z.B. "UTF-8". Default: Systemeinstellung
batchSize Anzahl der Records, die pro Batch in die Ziel-Datenbank geschrieben werden (Standard: 5000).

Die Tabelle kann weitere Spalten enthalten, die in der CSV-Datei nicht vorkommen. Sie müssen aber NULLable sein, oder einen Default-Wert definiert haben.

Geometriepalten können nicht importiert werden.

Die Gross-/Kleinschreibung der CSV-Spaltennamen wird für die Zuordnung zu den DB-Spalten ignoriert.

CsvValidator

Prüft eine CSV-Datei gegenüber einem INTERLIS-Modell. Basiert auf dem ilivalidator.

Beispiel:

task validate(type: CsvValidator){
    models = "CsvModel"
    firstLineIsHeader=true
    dataFiles = ["data1.csv"]
}
Parameter Beschreibung
dataFiles Liste der CSV-Dateien, die validiert werden sollen. Eine leere Liste ist kein Fehler.
models INTERLIS-Modell, gegen das die Dateien geprüft werden sollen (mehrere Modellnamen durch Semikolon trennen). Default: Der Name der CSV-Datei.
modeldir 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: %XTF_DIR;http://models.interlis.ch/. %XTF_DIR ist ein Platzhalter für das Verzeichnis mit der CSV-Datei.
configFile Konfiguriert die Datenprüfung mit Hilfe einer TOML-Datei (um z.B. die Prüfung von einzelnen Constraints auszuschalten). siehe https://github.com/claeis/ilivalidator/blob/master/docs/ilivalidator.rst#konfiguration
forceTypeValidation Ignoriert die Konfiguration der Typprüfung aus der TOML-Datei, d.h. es kann nur die Multiplizität aufgeweicht werden. Default: false
disableAreaValidation Schaltet die AREA-Topologieprüfung aus. Default: false
multiplicityOff Schaltet die Prüfung der Multiplizität generell aus. Default: false
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. Default: false
skipPolygonBuilding Schaltet die Bildung der Polygone aus (nur ITF). Default: false
logFile Schreibt die log-Meldungen der Validierung in eine Text-Datei.
xtflogFile Schreibt die log-Meldungen in eine INTERLIS 2-Datei. Die Datei result.xtf entspricht dem Modell IliVErrors.
pluginFolder Verzeichnis mit JAR-Dateien, die Zusatzfunktionen enthalten.
proxy Proxy Server für den Zugriff auf Modell Repositories
proxyPort Proxy Port für den Zugriff auf Modell Repositories
failOnError Steuert, ob der Task bei einem Validierungsfehler fehlschlägt. Default: true
validationOk OUTPUT: Ergebnis der Validierung. Nur falls failOnError=false
firstLineIsHeader Definiert, ob die CSV-Datei einer Headerzeile hat, oder nicht. Default: true
valueDelimiter Zeichen, das am Anfang und Ende jeden Wertes vorhanden ist. Default "
valueSeparator Zeichen, das als Trennzeichen zwischen den Werten interpretiert werden soll. Default: ,
encoding Zeichencodierung der CSV-Datei, z.B. "UTF-8". Default: Systemeinstellung

Falls die CSV-Datei eine Header-Zeile enthält (mit den Spaltennamen), wird im gegebenen Modell eine Klasse gesucht, die genau diese Attribute (wobei die Gross-/Kleinschreibung ignoriert wird) enthält. Wird keine solche Klasse gefunden, gilt das als Validierungsfehler.

Falls die CSV-Datei keine Header-Zeile enthält (mit den Spaltennamen), wird im gegebenen Modell eine Klasse gesucht, die die selbe Anzahl Attribute hat. Wird keine solche Klasse gefunden, gilt das als Validierungsfehler.

Db2Db

Dies ist prinzipiell ein 1:1-Datenkopie, d.h. es findet kein Datenumbau statt, die Quell- und die Ziel- Tabelle hat jeweils identische Attribute. Es werden auf Seite Quelle in der Regel also simple SELECT-Queries ausgeführt und die Resultate dieser Queries in Tabellen der Ziel-DB eingefügt. Unter bestimmten Bedingungen (insbesondere wenn es sich um einen wenig komplexen Datenumbau handelt), kann dieser Task aber auch zum Datenumbau benutzt werden.

Die Queries können auf mehrere .sql-Dateien verteilt werden, d.h. der Task muss die Queries mehrerer .sql-Dateien zu einer Transaktion kombinieren können. Jede .sql-Datei gibt genau eine Resultset (RAM-Tabelle) zurück. Das Resultset wird in die konfigurierte Zieltabelle geschrieben. Die Beziehungen sind: Eine bis mehrere Quelltabellen ergeben ein Resultset; das Resultset entspricht bezüglich den Attributen genau der Zieltabelle und wird 1:1 in diese geschrieben. Der Db2Db- Task verarbeitet innerhalb einer Transaktion 1-n Resultsets und wird entsprechend auch mit 1-n SQL-Dateien konfiguriert.

Die Reihenfolge der .sql-Dateien ist relevant. Dies bedeutet, dass die SQL-Befehle der zuerst angegebenen .sql-Datei zuerst ausgeführt werden müssen, danach die SQL-Befehle der an zweiter Stelle angegebenen .sql-Datei, usw.

Es ist auch möglich, in den .sql-Dateien mehr als nur ein SELECT-Query zu formulieren, z.B. ein vorgängiges DELETE.

Alle SELECT-Statements werden in einer Transaktion ausgeführt werden, damit ein konsistenter Datenstand gelesen wird. Alle INSERT-Statements werden in einer Transaktion ausgeführt werden, damit bei einem Fehler der bisherige Datenstand bestehen bleibt und also kein unvollständiger Import zurückgelassen wird.

Damit dieselbe .sql-Datei für verschiedene Datensätze benutzt werden kann, ist es möglich innerhalb der .sql-Datei Parameter zu verwenden und diesen Parametern beim Task einen konkreten Wert zuzuweisen. Innerhalb der .sql-Datei werden Paramter mit folgender Syntax verwendet: ${paramName}.

def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task transferSomeData(type: Db2Db) {
    sourceDb = [db_uri, db_user, db_pass]
    targetDb = ['jdbc:sqlite:gretldemo.sqlite',null,null]
    sqlParameters = [dataset:'Olten']
    transferSets = [
        new TransferSet('some.sql', 'albums_dest', true)
    ];
}
Parameter Beschreibung
sourceDb Datenbank aus der gelesen werden soll
targetDb Datenbank in die geschrieben werden soll
transferSets Eine Liste von TransferSets.
sqlParameters Eine Map mit Paaren von Parameter-Name und Parameter-Wert.
batchSize Anzahl der Records, die pro Batch in die Ziel-Datenbank geschrieben werden (Standard: 5000). Für sehr grosse Tabellen muss ein kleinerer Wert gewählt werden.
fetchSize Anzahl der Records, die auf einmal vom Datenbank-Cursor von der Quell-Datenbank zurückgeliefert werden (Standard: 5000). Für sehr grosse Tabellen muss ein kleinerer Wert gewählt werden.

Eine TransferSet ist

  • eine SQL-Datei (mit SQL-Anweisungen zum Lesen der Daten aus der sourceDb),
  • dem Namen der Ziel-Tabelle in der targetDb, und
  • der Angabe ob in der Ziel-Tabelle vor dem INSERT zuerst alle Records gelöscht werden sollen.

Unterstützte Datenbanken: PostgreSQL, SQLite und Oracle. Der Oracle-JDBC-Treiber muss jedoch selber installiert werden (Ausgenommen vom Docker-Image).

Ili2pgExport

Exportiert Daten aus der PostgreSQL-Datenbank in eine INTERLIS-Transferdatei.

Mit dem Parameter models, topics, baskets oder dataset wird definiert, welche Daten exportiert werden.

Ob die Daten im INTERLIS 1-, INTERLIS 2- oder GML-Format geschrieben werden, ergibt sich aus der Dateinamenserweiterung der Ausgabedatei. Für eine INTERLIS 1-Transferdatei muss die Erweiterung .itf verwendet werden. Für eine GML-Transferdatei muss die Erweiterung .gml verwendet werden.

Beispiel:

def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task exportData(type: Ili2pgExport){
    database = [db_uri, db_user, db_pass]
    dataFile = "lv03_254900-out.itf"
    dataset = "254900"
    logFile = "ili2pg.log"
}
Parameter Beschreibung
database Datenbank aus der exportiert werden soll
dataFile Name der XTF-/ITF-Datei, die erstellt werden soll
dbschema Entspricht der ili2pg Option --dbschema
proxy Entspricht der ili2pg Option --proxy
proxyPort Entspricht der ili2pg Option --proxyPort
modeldir Entspricht der ili2pg Option --modeldir
models Entspricht der ili2pg Option --models
dataset Entspricht der ili2pg Option --dataset
baskets Entspricht der ili2pg Option --baskets
topics Entspricht der ili2pg Option --topics
preScript Entspricht der ili2pg Option --preScript
postScript Entspricht der ili2pg Option --postScript
deleteData Entspricht der ili2pg Option --deleteData
logFile Entspricht der ili2pg Option --logFile
validConfigFile Entspricht der ili2pg Option --validConfigFile
disableValidation Entspricht der ili2pg Option --disableValidation
disableAreaValidation Entspricht der ili2pg Option --disableAreaValidation
forceTypeValidation Entspricht der ili2pg Option --forceTypeValidation
strokeArcs Entspricht der ili2pg Option --strokeArcs
skipPolygonBuilding Entspricht der ili2pg Option --skipPolygonBuilding
skipGeometryErrors Entspricht der ili2pg Option --skipGeometryErrors
iligml20 Entspricht der ili2pg Option --iligml20

Für die Beschreibung der einzenen ili2pg Optionen: https://github.com/claeis/ili2db/blob/master/docs/ili2db.rst#aufruf-syntax

Ili2pgImport

Importiert Daten aus einer INTERLIS-Transferdatei in die PostgreSQL-Datenbank.

Die Tabellen werden implizit auch angelegt, falls sie noch nicht vorhanden sind. Falls die Tabellen in der Datenbank schon vorhanden sind, können sie zusätzliche Spalten enthalten (z.B. bfsnr, datum etc.), welche beim Import leer bleiben.

Falls beim Import ein Datensatz-Identifikator (dataset) definiert wird, darf dieser Datensatz-Identifikator in der Datenbank noch nicht vorhanden sein.

Um die bestehenden (früher importierten) Daten zu ersetzen, kann der Task Ili2pgReplace verwendet werden.

Beispiel:

def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task importData(type: Ili2pgImport){
    database = [db_uri, db_user, db_pass]
    dataFile = "lv03_254900.itf"
    logFile = "ili2pg.log"
}
Parameter Beschreibung
database Datenbank in die importiert werden soll
dataFile Name der XTF-/ITF-Datei, die gelesen werden soll
dbschema Entspricht der ili2pg Option --dbschema
proxy Entspricht der ili2pg Option --proxy
proxyPort Entspricht der ili2pg Option --proxyPort
modeldir Entspricht der ili2pg Option --modeldir
models Entspricht der ili2pg Option --models
dataset Entspricht der ili2pg Option --dataset
baskets Entspricht der ili2pg Option --baskets
topics Entspricht der ili2pg Option --topics
preScript Entspricht der ili2pg Option --preScript
postScript Entspricht der ili2pg Option --postScript
deleteData Entspricht der ili2pg Option --deleteData
logFile Entspricht der ili2pg Option --logFile
validConfigFile Entspricht der ili2pg Option --validConfigFile
disableValidation Entspricht der ili2pg Option --disableValidation
disableAreaValidation Entspricht der ili2pg Option --disableAreaValidation
forceTypeValidation Entspricht der ili2pg Option --forceTypeValidation
strokeArcs Entspricht der ili2pg Option --strokeArcs
skipPolygonBuilding Entspricht der ili2pg Option --skipPolygonBuilding
skipGeometryErrors Entspricht der ili2pg Option --skipGeometryErrors
iligml20 Entspricht der ili2pg Option --iligml20

Für die Beschreibung der einzenen ili2pg Optionen: https://github.com/claeis/ili2db/blob/master/docs/ili2db.rst#aufruf-syntax

Ili2pgImportSchema

Erstellt die Tabellenstruktur in der PostgreSQL-Datenbank anhand eines INTERLIS-Modells.

Der Parameter iliFile oder models muss gesetzt werden.

Beispiel:

def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task importSchema(type: Ili2pgImportSchema){
    database = [db_uri, db_user, db_pass]
    models = "DM01AVSO24"
    dbschema = "gretldemo"
    logFile = "ili2pg.log"
}
Parameter Beschreibung
database Datenbank in die importiert werden soll
iliFile Name der ili-Datei die gelesen werden soll
models Name des ili-Modells, das gelesen werden soll
dbschema Entspricht der ili2pg Option --dbschema
proxy Entspricht der ili2pg Option --proxy
proxyPort Entspricht der ili2pg Option --proxyPort
modeldir Entspricht der ili2pg Option --modeldir
dataset Entspricht der ili2pg Option --dataset
baskets Entspricht der ili2pg Option --baskets
topics Entspricht der ili2pg Option --topics
preScript Entspricht der ili2pg Option --preScript
postScript Entspricht der ili2pg Option --postScript
logFile Entspricht der ili2pg Option --logFile
strokeArcs Entspricht der ili2pg Option --strokeArcs
oneGeomPerTable Entspricht der ili2pg Option --oneGeomPerTable
setupPgExt Entspricht der ili2pg Option --setupPgExt
dropscript Entspricht der ili2pg Option --dropscript
createscript Entspricht der ili2pg Option --createscript
defaultSrsAuth Entspricht der ili2pg Option --defaultSrsAuth
defaultSrsCode Entspricht der ili2pg Option --defaultSrsCode
createSingleEnumTab Entspricht der ili2pg Option --createSingleEnumTab
createEnumTabs Entspricht der ili2pg Option --createEnumTabs
createEnumTxtCol Entspricht der ili2pg Option --createEnumTxtCol
createEnumColAsItfCode Entspricht der ili2pg Option --createEnumColAsItfCode
beautifyEnumDispName Entspricht der ili2pg Option --beautifyEnumDispName
noSmartMapping Entspricht der ili2pg Option --noSmartMapping
smart1Inheritance Entspricht der ili2pg Option --smart1Inheritance
smart2Inheritance Entspricht der ili2pg Option --smart2Inheritance
coalesceCatalogueRef Entspricht der ili2pg Option --coalesceCatalogueRef
coalesceMultiSurface Entspricht der ili2pg Option --coalesceMultiSurface
coalesceMultiLine Entspricht der ili2pg Option --coalesceMultiLine
expandMultilingual Entspricht der ili2pg Option --expandMultilingual
createFk Entspricht der ili2pg Option --createFk
createFkIdx Entspricht der ili2pg Option --createFkIdx
createUnique Entspricht der ili2pg Option --createUnique
createNumChecks Entspricht der ili2pg Option --createNumChecks
createStdCols Entspricht der ili2pg Option --createStdCols
t_id_Name Entspricht der ili2pg Option --t_id_Name
idSeqMin Entspricht der ili2pg Option --idSeqMin
idSeqMax Entspricht der ili2pg Option --idSeqMax
createTypeDiscriminator Entspricht der ili2pg Option --createTypeDiscriminator
createGeomIdx Entspricht der ili2pg Option --createGeomIdx
disableNameOptimization Entspricht der ili2pg Option --disableNameOptimization
nameByTopic Entspricht der ili2pg Option --nameByTopic
maxNameLength Entspricht der ili2pg Option --maxNameLength
sqlEnableNull Entspricht der ili2pg Option --sqlEnableNull
keepAreaRef Entspricht der ili2pg Option --keepAreaRef
importTid Entspricht der ili2pg Option --importTid
createBasketCol Entspricht der ili2pg Option --createBasketCol
createDatasetCol Entspricht der ili2pg Option --createDatasetCol
ver4_translation Entspricht der ili2pg Option --ver4_translation
translation Entspricht der ili2pg Option --translation
createMetaInfo Entspricht der ili2pg Option --createMetaInfo

Für die Beschreibung der einzenen ili2pg Optionen: https://github.com/claeis/ili2db/blob/master/docs/ili2db.rst#aufruf-syntax

Ili2pgReplace

Ersetzt die Daten in der PostgreSQL-Datenbank anhand eines Datensatz-Identifikators (dataset) mit den Daten aus einer INTERLIS-Transferdatei. Diese Funktion bedingt, dass das Datenbankschema mit der Option createBasketCol erstellt wurde (via Task Ili2pgImportSchema).

Beispiel:

def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task replaceData(type: Ili2pgReplace){
    database = [db_uri, db_user, db_pass]
    dataFile = "lv03_254900.itf"
    dataset = "254900"
    logFile = "ili2pg.log"
}

Die Parameter sind analog wie bei Ili2pgImport.

Ili2pgUpdate

Aktualisiert die Daten in der PostgreSQL-Datenbank anhand einer INTERLIS-Transferdatei, d.h. neue Objekte werden eingefügt, bestehende Objekte werden aktualisiert und in der Transferdatei nicht mehr vorhandene Objekte werden gelöscht.

Diese Funktion bedingt, dass das Datenbankschema mit der Option createBasketCol erstellt wurde (via Task Ili2pgImportSchema), und dass die Klassen und Topics eine stabile OID haben.

Beispiel:

def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task updateData(type: Ili2pgUpdate){
    database = [db_uri, db_user, db_pass]
    dataFile = "lv03_254900.itf"
    dataset = "254900"
    logFile = "ili2pg.log"
}

Die Parameter sind analog wie bei Ili2pgImport.

IliValidator

Prüft eine INTERLIS-Datei (.itf oder .xtf) gegenüber einem INTERLIS-Modell (.ili). Basiert auf dem ilivalidator.

Beispiel:

task validate(type: IliValidator){
    dataFiles = ["Beispiel2a.xtf"]
    logFile = "ilivalidator.log"
}
Parameter Beschreibung
dataFiles Liste der XTF- oder ITF-Dateien, die validiert werden sollen. Eine leere Liste ist kein Fehler.
models INTERLIS-Modell, gegen das die die Dateien geprüft werden sollen (mehrere Modellnamen durch Semikolon trennen). Default: Wird anhand der dataFiles ermittelt.
modeldir 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: %XTF_DIR;http://models.interlis.ch/. %XTF_DIR ist ein Platzhalter für das Verzeichnis mit der CSV-Datei.
configFile Konfiguriert die Datenprüfung mit Hilfe einer TOML-Datei (um z.B. die Prüfung von einzelnen Constraints auszuschalten). siehe https://github.com/claeis/ilivalidator/blob/master/docs/ilivalidator.rst#konfiguration
forceTypeValidation Ignoriert die Konfiguration der Typprüfung aus der TOML-Datei, d.h. es kann nur die Multiplizität aufgeweicht werden. Default: false
disableAreaValidation Schaltet die AREA Topologieprüfung aus. Default: false
multiplicityOff Schaltet die Prüfung der Multiplizität generell aus. Default: false
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. Default: false
skipPolygonBuilding Schaltet die Bildung der Polygone aus (nur ITF). Default: false
logFile Schreibt die log-Meldungen der Validierung in eine Text-Datei.
xtflogFile Schreibt die log-Meldungen in eine INTERLIS 2-Datei. Die Datei result.xtf entspricht dem Modell IliVErrors.
pluginFolder erzeichnis mit JAR-Dateien, die Zusatzfunktionen enthalten.
proxy Proxy Server für den Zugriff auf Modell Repositories
proxyPort Proxy Port für den Zugriff auf Modell Repositories
failOnError Steuert, ob der Task bei einem Validierungsfehler fehlschlägt. Default: true
validationOk OUTPUT: Ergebnis der Validierung. Nur falls failOnError=false

ShpExport

Daten aus einer bestehenden Datenbanktabelle werden in eine Shp-Datei exportiert.

Beispiel:

def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task shpexport(type: ShpExport){
    database = [db_uri, db_user, db_pass]
    schemaName = "shpexport"
    tableName = "exportdata"
    dataFile = "data.shp"
}
Parameter Beschreibung
database Datenbank aus der exportiert werden soll
dataFile Name der SHP Datei, die erstellt werden soll
tableName Name der DB-Tabelle, die exportiert werden soll
schemaName Name des DB-Schemas, in dem die DB-Tabelle ist.
firstLineIsHeader Definiert, ob eine Headerzeile geschrieben werden soll, oder nicht. Default: true
encoding Zeichencodierung der SHP-Datei, z.B. "UTF-8". Default: Systemeinstellung

Die Tabelle darf eine Geometriespalte enthalten.

ShpImport

Daten aus einer Shp-Datei in eine bestehende Datenbanktabelle importieren.

Beispiel:

def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task shpimport(type: ShpImport){
    database = [db_uri, db_user, db_pass]
    schemaName = "shpimport"
    tableName = "importdata"
    dataFile = "data.shp"
}
Parameter Beschreibung
database Datenbank in die importiert werden soll
dataFile Name der SHP-Datei, die gelesen werden soll
tableName Name der DB-Tabelle, in die importiert werden soll
schemaName Name des DB-Schemas, in dem die DB-Tabelle ist.
encoding Zeichencodierung der SHP-Datei, z.B. "UTF-8". Default: Systemeinstellung
batchSize Anzahl der Records, die pro Batch in die Ziel-Datenbank geschrieben werden (Standard: 5000).

Die Tabelle kann weitere Spalten enthalten, die in der Shp-Datei nicht vorkommen. Sie müssen aber NULLable sein, oder einen Default-Wert definiert haben.

Die Tabelle muss eine Geometriespalte enthalten. Der Name der Geometriespalte kann beliebig gewählt werden.

Die Gross-/Kleinschreibung der Shp-Spaltennamen wird für die Zuordnung zu den DB-Spalten ignoriert.

ShpValidator

Prüft eine SHP-Datei gegenüber einem INTERLIS-Modell. Basiert auf dem ilivalidator.

Beispiel:

task validate(type: ShpValidator){
    models = "ShpModel"
    dataFiles = ["data.shp"]
}
Parameter Beschreibung
dataFiles Liste der SHP-Dateien, die validiert werden sollen. Eine leere Liste ist kein Fehler.
models INTERLIS-Modell, gegen das die die Dateien geprüft werden sollen (mehrere Modellnamen durch Semikolon trennen). Default: Der Name der CSV-Datei.
modeldir 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: %XTF_DIR;http://models.interlis.ch/. %XTF_DIR ist ein Platzhalter für das Verzeichnis mit der SHP-Datei.
configFile Konfiguriert die Datenprüfung mit Hilfe einer TOML-Datei (um z.B. die Prüfung von einzelnen Constraints auszuschalten). siehe https://github.com/claeis/ilivalidator/blob/master/docs/ilivalidator.rst#konfiguration
forceTypeValidation Ignoriert die Konfiguration der Typprüfung aus der TOML-Datei, d.h. es kann nur die Multiplizität aufgeweicht werden. Default: false
disableAreaValidation Schaltet die AREA Topologieprüfung aus. Default: false
multiplicityOff Schaltet die Prüfung der Multiplizität generell aus. Default: false
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. Default: false
logFile Schreibt die log-Meldungen der Validierung in eine Text-Datei.
xtflogFile Schreibt die log-Meldungen in eine INTERLIS 2-Datei. Die Datei result.xtf entspricht dem Modell IliVErrors.
pluginFolder erzeichnis mit JAR-Dateien, die Zusatzfunktionen enthalten.
proxy Proxy Server für den Zugriff auf Modell Repositories
proxyPort Proxy Port für den Zugriff auf Modell Repositories
failOnError Steuert, ob der Task bei einem Validierungsfehler fehlschlägt. Default: true
validationOk OUTPUT: Ergebnis der Validierung. Nur falls failOnError=false
encoding Zeichencodierung der SHP-Datei, z.B. "UTF-8". Default: Systemeinstellung

Im gegebenen Modell wird eine Klasse gesucht, die genau die Attributenamen wie in der Shp-Datei enthält (wobei die Gross-/Kleinschreibung ignoriert wird); die Attributtypen werden ignoriert. Wird keine solche Klasse gefunden, gilt das als Validierungsfehler.

SqlExecutor

Der SqlExecutor-Task dient dazu, Datenumbauten auszuführen.

Er wird im Allgemeinen dann benutzt, wenn

  1. der Datenumbau komplex ist und deshalb nicht im Db2Db-Task erledigt werden kann
  2. oder wenn die Quell-DB keine PostgreSQL-DB ist (weil bei komplexen Queries für den Datenumbau möglicherweise fremdsystemspezifische SQL-Syntax verwendet werden müsste)
  3. oder wenn Quell- und Zielschema in derselben Datenbank liegen

In den Fällen 1 und 2 werden Stagingtabellen bzw. ein Stagingschema benötigt, in welche der Db2Db-Task die Daten zuerst 1:1 hineinschreibt. Der SqlExecutor-Task liest danach die Daten von dort, baut sie um und schreibt sie dann ins Zielschema. Die Queries für den SqlExecutor-Task können alle in einem einzelnen .sql-File sein oder (z.B. aus Gründen der Strukturierung oder Organisation) auf mehrere .sql-Dateien verteilt sein. Die Reihenfolge der .sql-Dateien ist relevant. Dies bedeutet, dass die SQL-Befehle des zuerst angegebenen .sql-Datei zuerst ausgeführt werden müssen, danach dies SQL-Befehle des an zweiter Stelle angegebenen .sql-Datei, usw.

Der SqlExecutor-Task muss neben Updates ganzer Tabellen (d.h. Löschen des gesamten Inhalts einer Tabelle und gesamter neuer Stand in die Tabelle schreiben) auch Updates von Teilen von Tabellen zulassen. D.h. es muss z.B. möglich sein, innerhalb einer Tabelle nur die Objekte einer bestimmten Gemeinde zu aktualisieren. Darum ist es möglich innerhalb der .sql-Datei Paramater zu verwenden und diesen Parametern beim Task einen konkreten Wert zuzuweisen. Innerhalb der .sql-Datei werden Paramter mit folgender Syntax verwendet: ${paramName}.

def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task executeSomeSql(type: SqlExecutor){
    database = [db_uri, db_user, db_pass]
    sqlParameters = [dataset:'Olten']
    sqlFiles = ['demo.sql']
}
Parameter Beschreibung
database Datenbank in die importiert werden soll
sqlFiles Name der SQL-Datei aus der SQL-Statements gelesen und ausgeführt werden
sqlParameters Eine Map mit Paaren von Parameter-Name und Parameter-Wert.

Unterstützte Datenbanken: PostgreSQL, SQLite und Oracle. Der Oracle-JDBC-Treiber muss jedoch selber installiert werden (Ausgenommen vom Docker-Image).