Documentation

Das Datenmanagement-Tool GRETL ist ein Werkzeug, das für Datenimports, Datenumbauten (Modellumbau) und Datenexports eingesetzt wird. GRETL führt Jobs ausy, 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.

Systemanforderungen

Um die aktuelle Version von GRETL auszuführen, muss

  • die Java-Laufzeitumgebung (JRE), Version 1.8 oder neuer, und
  • Gradle, Version 5.1 oder neuer, auf dem System installiert sein.

Die Java-Laufzeitumgebung (JRE) kann z.B. hier gratis bezogen werden.

Die Gradle-Software kann auf der Website https://gradle.org/ gratis bezogen werden.

Installation

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

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

Av2ch

Transformiert eine INTERLIS1-Transferdatei im kantonalen AV-DM01-Modell in das Bundesmodell. Unterstützt werden die Sprachen Deutsch und Italienisch und der Bezugrahmen LV95. Getestet mit Daten aus den Kantonen Solothurn, Glarus und Tessin. Weitere Informationen sind in der Basisbibliothek zu finden: https://github.com/sogis/av2ch.

Das Bundes-ITF hat denselben Namen wie das Kantons-ITF.

Aufgrund der sehr vielen Logging-Messages einer verwendeten Bibliothek, wird der System.err-Ouput nach dev/null gemappt .

task transform(type: Av2ch) {
    inputFile = file("254900.itf")
    outputDirectory = file("output")
}
Parameter Datentyp Beschreibung
inputFile File Name der zu transformierenden ITF-Datei.
outputDirectory File Name des Verzeichnisses in das die zu erstellende Datei geschrieben wird.
modeldir String INTERLIS-Modellablage. String separiert mit Semikolon (analog ili2db, ilivalidator).
zip Boolean Die zu erstellende Datei wird gezippt (Default: false).

Av2geobau

Av2geobau konvertiert eine Interlis-Transferdatei (itf) in eine DXF-Geobau Datei. Av2geobau funktioniert ohne Datenbank.

Die ITF-Datei muss dem Modell DM01AVCH24LV95D entsprechen. Die Daten werden nicht validiert.

Die Datenstruktur der DXF-Datei ist im Prinzip sehr einfach: Die verschiedenen Informationen aus dem Datenmodell DM01 werden in verschiedene DXF-Layer abgebildet, z.B. die begehbaren LFP1 werden in den Layer “01111” abgebildet. Oder die Gebäude in den Layer “01211”.

Der Datenumbau ist nicht konfigurierbar.

task av2geobau(type: Av2geobau){
    itfFiles = "ch_254900.itf"
    dxfDirectory = "./out/"
}

Es können auch mehrere Dateien angegeben werden.

task av2geobau(type: Av2geobau){
    itfFiles = fileTree(".").matching {
        include"*.itf"
    }
    dxfDirectory = "./out/"
}
Parameter Beschreibung
itfFiles ITF-Datei, die nach DXF transformiert werden soll. Es können auch mehrere Dateien angegeben werden.
dxfDirectory Verzeichnis, in das die DXF-Dateien gespeichert werden.
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: %ITF_DIR;http://models.interlis.ch/. %ITF_DIR ist ein Platzhalter für das Verzeichnis mit der ITF-Datei.
logFile Schreibt die log-Meldungen der Konvertierung in eine Text-Datei.
proxy Proxy Server für den Zugriff auf Modell Repositories
proxyPort Proxy Port für den Zugriff auf Modell Repositories
zip Die zu erstellende Datei wird gezippt und es werden zusätzliche Dateien (Musterplan, Layerbeschreibung, Hinweise) hinzugefügt (Default: false).

Csv2Excel (incubating)

Konvertiert eine CSV-Datei in eine Excel-Datei (*.xlsx). Datentypen werden anhand eines INTERLIS-Modelles eruiert. Fehlt das Modell, wird alles als Text gespeichert. Die Daten werden vollständig im Speicher vorgehalten. Falls grosse Dateien geschrieben werden müssen, kann das zu Problemen führen. Dann müsste die Apache POI SXSSF Implementierung (Streaming) verwendet werden.

Beispiel:

task convertData(type: Csv2Excel) {
    csvFile = file("./20230124_sap_Gebaeude.csv")
    firstLineIsHeader = true
    valueDelimiter = null
    valueSeparator = ";"
    encoding = "ISO-8859-1";
    models = "SO_HBA_Gebaeude_20230111";
    outputDir = file(".");
}
Parameter Beschreibung
csvFile CSV-Datei, die konvertiert werden soll.
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: ,
encoding Zeichencodierung der CSV-Datei, z.B. "UTF-8". Default: Systemeinstellung
models INTERLIS-Modell für Definition der Datentypen in der Excel-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.
outputDir Verzeichnis, in das die Excel-Datei gespeichert wird. Default: Verzeichnis, in dem die CSV-Datei vorliegt.

Csv2Parquet (incubating)

Konvertiert eine CSV-Datei in eine Parquet-Datei. Datentypen werden anhand eines INTERLIS-Modelles eruiert. Fehlt das Modell, wird alles als Text gespeichert.

Beispiel:

task convertData(type: Csv2Parquet) {
    csvFile = file("./20230124_sap_Gebaeude.csv")
    firstLineIsHeader = true
    valueDelimiter = null
    valueSeparator = ";"
    encoding = "ISO-8859-1";
    models = "SO_HBA_Gebaeude_20230111";
    outputDir = file(".");
}
Parameter Beschreibung
csvFile CSV-Datei, die konvertiert werden soll.
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: ,
encoding Zeichencodierung der CSV-Datei, z.B. "UTF-8". Default: Systemeinstellung
models INTERLIS-Modell für Definition der Datentypen in der Parquet-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.
outputDir Verzeichnis, in das die Parquet-Datei gespeichert wird. Default: Verzeichnis, in dem die CSV-Datei vorliegt.

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. Das Datenmodell darf die OID nicht als UUID modellieren (OID AS INTERLIS.UUIDOID).

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, welche die Header-Spaltennamen enthält (Gross-/Kleinschreibung sowie optionale “Spalten” der Modell-Klasse werden ignoriert). 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.

Die Prüfung von gleichzeitig mehreren CSV-Dateien führt zu Fehlermeldungen wie OID o3158 of object <Modelname>.<Topicname>.<Klassenname> already exists in .... Beim Öffnen und Lesen einer CSV-Datei wird immer der Zähler, der die interne (in der CSV-Datei nicht vorhandene) OID generiert, zurückgesetzt. Somit kann immer nur eine CSV-Datei pro Task geprüft werden.

Curl

Simuliert mit einem HttpClient einige Curl-Befehle.

Beispiele:

import ch.so.agi.gretl.tasks.Curl.MethodType;

task uploadData(type: Curl) {
    serverUrl = "https://geodienste.ch/data_agg/interlis/import"
    method = MethodType.POST
    formData = ["topic": "npl_waldgrenzen", "lv95_file": file("./test.xtf.zip"), "publish": "true", "replace_all": "true"]
    user = "fooUser"
    password = "barPwd"
    expectedStatusCode = 200
    expectedBody = "\"success\":true"
}
import ch.so.agi.gretl.tasks.Curl.MethodType;

task uploadData(type: Curl) {
    serverUrl = "https://testweb.so.ch/typo3/api/digiplan"
    method = MethodType.POST
    headers = ["Content-Type": "application/xml", "Content-Encoding": "gzip"]
    dataBinary = file("./planregister.xml.gz")
    user = "fooUser"
    password = "barPwd"
    expectedStatusCode = 202
}
import ch.so.agi.gretl.tasks.Curl.MethodType;

task downloadData(type: Curl) {
    serverUrl = "https://raw.githubusercontent.com/sogis/gretl/master/README.md"
    method = MethodType.GET
    outputFile = file("./README.md")
    expectedStatusCode = 200
}
Parameter Beschreibung
serverUrl Die URL des Servers inklusive Pfad und Queryparameter.
method HTTP-Request-Methode. Unterstützt werden GET und POST.
expectedStatusCode Erwarteter Status Code, der vom Server zurückgeliefert wird.
expectedBody Erwarteter Text, der vom Server als Body zurückgelieferd wird. (optional)
formData Form data parameters. Entspricht curl [URL] -F key1=value1 -F file1=@my_file.xtf. (optional)
dataBinary Datei, die hochgeladen werden soll. Entspricht curl [URL] --data-binary. (optional)
headers Request-Header. Entspricht curl [URL] -H ... -H .... (optional)
user Benutzername. Wird zusammen mit password in einen Authorization-Header umgewandelt. Entspricht curl [URL] -u user:password. (optional)
password Passwort. Wird zusammen mit user in einen Authorization-Header umgewandelt. Entspricht curl [URL] -u user:password. (optional)
outputFile Datei, in die der Output gespeichert wird. Entspricht curl [URL] -o. (optional)

DatabaseDocumentExport (Experimental)

Speichert Dokumente, deren URL in einer Spalte einer Datenbanktabelle gespeichert sind, in einem lokalen Verzeichnis. Zukünftig und bei Bedarf kann der Task so erweitert werden, dass auch BLOBs aus der Datenbank gespeichert werden können.

Redirect von HTTP nach HTTPS funktionieren nicht. Dies korrekterweise (?) wegen der verwendeten Java-Bibliothek.

Wegen der vom Kanton Solothurn eingesetzten self-signed Zertifikate muss ein unschöner Handstand gemacht werden. Leider kann dieser Usecase schlecht getestet werden, da die Links nur in der privaten Zone verfügbar sind und die zudem noch häufig ändern können. Manuell getestet wurde es jedoch.

Als Dateiname wird der letzte Teil des URL-Pfades verwendet, z.B. https://artplus.verw.rootso.org/MpWeb-apSolothurnDenkmal/download/2W8v0qRZQBC0ahDnZGut3Q?mode=gis wird mit den Prefix und Extension zu ada_2W8v0qRZQBC0ahDnZGut3Q.pdf.

Es wird DISTINCT ON (<documentColumn>) und ein Filter WHERE <documentColumn> IS NOT NULL verwendet.

Beispiel:

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

task exportDocuments(type: DatabaseDocumentExport){
    database = [db_uri, db_user, db_pass]
    qualifiedTableName = "ada_denkmalschutz.fachapplikation_rechtsvorschrift_link"
    documentColumn = "multimedia_link"
    targetDir = file(".")
    fileNamePrefix = "ada_"
    fileNameExtension = "pdf"
}
Parameter Beschreibung
database Datenbank aus der die Dokumente exportiert werden sollen.
qualifiedTableName Qualifizierter Tabellenname
documentColumn DB-Tabellenspalte mit dem Dokument resp. der URL zum Dokument.
targetDir Verzeichnis in das die Dokumente exportiert werden sollen.
fileNamePrefix Prefix für Dateinamen (optional)
fileNameExtension Dateinamen-Extension (optional)

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)
    ];
}

Damit mit einer einzigen Task-Definition mehrere Datensätze verarbeitet werden können, kann auch eine Liste von Parametern angegeben werden.

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'],[dataset:'Grenchen']]
    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 (Map<String,String>). Oder eine Liste mit Paaren von Parameter-Name und Parameter-Wert (List<Map<String,String>>).
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.
  • einem optionalen vierten Parameter, der verwendet werden kann um den zu erzeugenden SQL-Insert-String zu beeinflussen, u.a. um einen WKT-Geometrie-String in eine PostGIS-Geometrie umzuwandeln

Beispiel, Umwandlung Rechtswert/Hochwertspalten in eine PostGIS-Geometrie (siehe auch Gretl-Job afu_onlinerisk_transfer der eine Punktgeometriespalten aus einer Nicht-Postgis-DB übernimmt):

new TransferSet('untersuchungseinheit.sql', 'afu_qrcat_v1.onlinerisk_untersuchungseinheit', true, (String[])["geom:wkt:2056"])

“geom” ist der Geometrie-Spalten-Name der verwendet wird.

Dazugehöriger Auszug aus SQL-Datei zur Erzeugung des WKT-Strings mit Hilfe von concatenation:

'Point(' || ue.koordinate_x::text || ' ' || ue.koordinate_y::text || ')' AS geom

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

FtpDelete

Löscht Daten auf einem FTP-Server.

Beispiel, löscht alle Daten in einem Verzeichnis:

task ftpdelete(type: FtpDelete) {
    server= "ftp.server.org"
    user= "Hans"
    password= "dummy"
    remoteDir = "\\dm01avso24lv95\\itf"
    remoteFile = fileTree(pathToTempFolder) { include '*.zip' } 
    //remoteFile = "*.zip"
}

Um bestimmte Dateien zu löschen:

task ftpdownload(type: FtpDownload){
    server= "ftp.server.org"
    user= "Hans"
    password= "dummy"
    remoteDir = "\\dm01avso24lv95\\itf"
    remoteFile = "*.zip"
}

Um heruntergeladene Daten zu löschen:

task ftpdownload(type: FtpDownload){
    server= "ftp.server.org"
    user= "Hans"
    password= "dummy"
    remoteDir = "\\dm01avso24lv95\\itf"
    remoteFile = fileTree(pathToDownloadFolder) { include '*.zip' } 
}
Parameter Beschreibung
server Name des Servers (ohne ftp://)
user Benutzername auf dem Server
password Passwort für den Zugriff auf dem Server
remoteDir Verzeichnis auf dem Server
remoteFile Dateiname oder Liste der Dateinamen auf dem Server (kann auch ein Muster sein (* oder ?)). Ohne diesen Parameter werden alle Dateien aus dem Remoteverzeichnis gelöscht.
systemType UNIX oder WINDOWS. Default ist UNIX.
fileSeparator Default ist ‘/’. (Falls systemType Windows ist, ist der Default ‘\’.
passiveMode Aktiv oder Passiv Verbindungsmodus. Default ist Passiv (true)
controlKeepAliveTimeout Timeout bis ein NOOP über den Kontroll-Kanal versendet wird. Default ist 300s (=5 Minuten)

FtpDownload

Lädt alle Dateien aus dem definierten Verzeichnis des Servers in ein lokales Verzeichnis herunter.

Beispiel:

task ftpdownload(type: FtpDownload){
    server= "ftp.server.org"
    user= "Hans"
    password= "dummy"
    localDir= "downloads"
    remoteDir= ""
}

Um eine bestimmte Datei herunterzuladen:

task ftpdownload(type: FtpDownload){
    server="ftp.infogrips.ch"
    user= "Hans"
    password= "dummy"
    systemType="WINDOWS"
    localDir= "downloads"
    remoteDir="\\dm01avso24lv95\\itf"
    remoteFile="240100.zip"
}
Parameter Beschreibung
server Name des Servers (ohne ftp://)
user Benutzername auf dem Server
password Passwort für den Zugriff auf dem Server
localDir Lokales Verzeichnis indem die Dateien gespeichert werden
remoteDir Verzeichnis auf dem Server
remoteFile Dateiname oder Liste der Dateinamen auf dem Server (kann auch ein Muster sein (* oder ?)). Ohne diesen Parameter werden alle Dateien aus dem Remoteverzeichnis heruntergeladen.
systemType UNIX oder WINDOWS. Default ist UNIX.
fileType ASCII oder BINARY. Default ist ASCII.
fileSeparator Default ist ‘/’. (Falls systemType Windows ist, ist der Default ‘\’.
passiveMode Aktiv oder Passiv Verbindungsmodus. Default ist Passiv (true)
controlKeepAliveTimeout Timeout bis ein NOOP über den Kontroll-Kanal versendet wird. Default ist 300s (=5 Minuten)

FtpList

Liefert eine Liste der Dateien aus dem definierten Verzeichnis des Servers.

Beispiel:

task ftplist(type: FtpList){
    server= "ftp.server.org"
    user= "Hans"
    password= "dummy"
    remoteDir= ""
    doLast {
        println files
    }
}
Parameter Beschreibung
server Name des Servers (ohne ftp://)
user Benutzername auf dem Server
password Passwort für den Zugriff auf dem Server
remoteDir Verzeichnis auf dem Server
files Liste der Dateinamen auf dem Server
systemType UNIX oder WINDOWS. Default ist UNIX.
fileSeparator Default ist ‘/’. (Falls systemType Windows ist, ist der Default ‘\’.
passiveMode Aktiv oder Passiv Verbindungsmodus. Default ist Passiv (true)
controlKeepAliveTimeout Timeout bis ein NOOP über den Kontroll-Kanal versendet wird. Default ist 300s (=5 Minuten)

Gpkg2Dxf

Exportiert alle Tabellen einer GeoPackage-Datei in DXF-Dateien. Als Input wird eine von ili2gpkg erzeugte GeoPackage-Datei benötigt.

Es werden alle INTERLIS-Klassen exportier (SELECT tablename FROM T_ILI2DB_TABLE_PROP WHERE setting = 'CLASS'). Der eigentliche SELECT-Befehl ist komplizierter weil für das Layern der einzelnen DXF-Objekte das INTERLIS-Metaattribut !!@dxflayer="true" ausgelesen wird. Gibt es kein solches Metaattribut wird alles in den gleichen DXF-Layer (default) geschrieben.

Encoding: Die DXF-Dateien sind ISO-8859-1 encodiert.

Achtung: Task sollte verbessert werden (siehe E-Mail Claude im Rahmen des Publisher-Projektes).

Beispiel:

task gpkg2dxf(type: Gpkg2Dxf) {
    dataFile = file("data.gpkg")
    outputDir = file("./out/")
}
Parameter Beschreibung
dataFile GeoPackage-Datei, die nach DXF transformiert werden soll.
outputDir Verzeichnis, in das die DXF-Dateien gespeichert werden.

GpkgExport

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

Beispiele:

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

task gpkgexport(type: GpkgExport){
    database = [db_uri, db_user, db_pass]
    schemaName = "gpkgexport"
    srcTableName = "exportdata"
    dataFile = "data.gpkg"
    dstTableName = "exportdata"
}
def db_uri = 'jdbc:postgresql://localhost/gretldemo'
def db_user = "dmluser"
def db_pass = "dmluser"

task gpkgexport(type: GpkgExport) {
    database = [db_uri, db_user, db_pass]
    schemaName = "gpkgexport"
    srcTableName = ["exportTable1", "exportTable2"]
    dataFile = "data.gpkg"
    dstTableName = ["exportTable1", "exportTable2"]
}
Parameter Beschreibung
database Datenbank aus der exportiert werden soll
dataFile Name der GeoPackage-Datei, die erstellt werden soll
srcTableName Name der DB-Tabelle(n), die exportiert werden soll(en). String oder List.
schemaName Name des DB-Schemas, in dem die DB-Tabelle ist.
dstTableName Name der Tabelle(n) in der GeoPackage-Datei. String oder List.
batchSize Anzahl der Records, die pro Batch in die Ziel-Datenbank (GeoPackage) geschrieben werden (Standard: 5000).
fetchSize Anzahl der Records, die pro Fetch aus der Quell-Datenbank gelesen werden (Standard: 5000).

GpkgImport

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

Beispiel:

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

task gpkgimport(type: GpkgImport){
    database = [db_uri, db_user, db_pass]
    schemaName = "gpkgimport"
    srcTableName = "Point"
    dstTableName = "importdata"
    dataFile = "point.gpkg"
}
Parameter Beschreibung
database Datenbank in die importiert werden soll
dataFile Name der GeoPackage-Datei, die gelesen werden soll
srcTableName Name der GeoPackage-Tabelle, die importiert werden soll
schemaName Name des DB-Schemas, in dem die DB-Tabelle ist.
dstTableName Name der DB-Tabelle, in die importiert werden soll
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).
fetchSize Anzahl der Records, die pro Fetch aus der Quell-Datenbank gelesen werden (Standard: 5000).

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

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

Gpkg2Shp

Exportiert alle Tabellen einer GeoPackage-Datei in Shapefiles. Als Input wird eine von ili2gpkg erzeugte GeoPackage-Datei benötigt.

Es werden alle INTERLIS-Klassen exportiert (SELECT tablename FROM T_ILI2DB_TABLE_PROP WHERE setting = 'CLASS'). Je nach, bei der Erstellung der GeoPackage-Datei, verwendeten Parametern, muss die Query angepasst werden. Es muss jedoch darauf geachtet werden, dass es nur eine Query gibt (für alle Datensätze). Für den vorgesehenen Anwendungsfall (sehr einfache, flache Modelle) dürfte das kein Problem darstellen.

Encoding: Die Shapefiles sind neu UTF-8 encodiert. Standard ist ISO-8859-1, scheint aber v.a. in QGIS nicht standardmässig zu funktionieren (keine Umlaute).

Achtung: Task sollte verbessert werden (siehe E-Mail Claude im Rahmen des Publisher-Projektes).

Beispiel:

task gpkg2shp(type: Gpkg2Shp) {
    dataFile = file("data.gpkg")
    outputDir = file("./out/")
}
Parameter Beschreibung
dataFile GeoPackage-Datei, die nach Shapefile transformiert werden soll.
outputDir Verzeichnis, in das die Shapefile gespeichert werden.

GpkgValidator

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

Beispiel:

task validate(type: GpkgValidator){
    models = "GpkgModel"
    dataFiles = ["attributes.gpkg"]
    tableName = "Attributes"
}
Parameter Beschreibung
dataFiles Liste der GeoPackage-Dateien, die validiert werden sollen. Eine leere Liste ist kein Fehler.
tableName Name der Tabelle in den GeoPackage-Dateien.
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 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

Gzip

Gzipped eine einzelne Datei. Es gibt einen eingebauten Tar-Task, der - nomen est omen - aber immer zuerst eine Tar-Datei erstellt.

Parameter Beschreibung
dataFile Datei, die gezipped werden soll.
gzipFile Output-Datei

Beispiel:

task compressFile(type: Gzip) {
    dataFile = file("./planregister.xml");
    gzipFile = file("./planregister.xml.gz");
}

Ili2gpkgImport

Importiert Daten aus einer INTERLIS-Transferdatei in eine GeoPackage-Datei.

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 Ili2gpkgReplace (not yet implemented) verwendet werden.

Die Option --doSchemaImport wird automatisch gesetzt.

Beispiel:

task importData(type: Ili2gpkgImport) {
    models = "SO_AGI_AV_GB_Administrative_Einteilungen_20180613"
    dataFile = file("data.xtf");
    dbfile = file("data.gpkg")    
}
Parameter Beschreibung
dbfile GeoPackage-Datei in die importiert werden soll
dataFile Name der XTF-/ITF-Datei, die gelesen werden soll. Es können auch mehrere Dateien sein.
proxy Entspricht der ili2gpkg Option --proxy
proxyPort Entspricht der ili2gpkg-Option --proxyPort
modeldir Entspricht der ili2gpkg-Option --modeldir
models Entspricht der ili2gpkg-Option --models
dataset Entspricht der ili2gpkg-Option --dataset
baskets Entspricht der ili2gpkg-Option --baskets
topics Entspricht der ili2gpkg-Option --topics
preScript Entspricht der ili2gpkg-Option --preScript
postScript Entspricht der ili2gpkg-Option --postScript
deleteData Entspricht der ili2gpkg-Option --deleteData
logFile Entspricht der ili2gpkg-Option --logFile
validConfigFile Entspricht der ili2gpkg-Option --validConfigFile
disableValidation Entspricht der ili2gpkg-Option --disableValidation
disableAreaValidation Entspricht der ili2gpkg-Option --disableAreaValidation
forceTypeValidation Entspricht der ili2gpkg-Option --forceTypeValidation
strokeArcs Entspricht der ili2gpkg-Option --strokeArcs
skipPolygonBuilding Entspricht der ili2gpkg-Option --skipPolygonBuilding
skipGeometryErrors Entspricht der ili2gpkg-Option --skipGeometryErrors
iligml20 Entspricht der ili2gpkg-Option --iligml20
coalesceJson Entspricht der ili2gpkg-Option --coalesceJson
nameByTopic Entspricht der ili2gpkg-Option --nameByTopic
defaultSrsCode Entspricht der ili2gpkg-Option --defaultSrsCode
createEnumTabs Entspricht der ili2gpkg-Option --createEnumTabs
createMetaInfo Entspricht der ili2gpkg-Option --createMetaInfo

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

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"
}

Damit mit einer einzigen Task-Definition mehrere Datensätze verarbeitet werden können, kann auch eine Liste von Dateinamen und Datensätzen angegeben werden.

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","lv03_255000-out.itf"]
    dataset = ["254900","255000"]
    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
export3 Entspricht der ili2pg-Option --export3
iligml20 Entspricht der ili2pg-Option --iligml20
disableRounding Entspricht der ili2pg-Option --disableRounding
failOnException Task wirft Exception, falls ili2db-Prozess fehlerhaft ist (= Ili2dbException). Default: true.

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.

Falls man mehrere Dateien importieren will, diese jedoch erst zur Laufzeit eruiert werden können, muss der Parameter dataFile eine Gradle FileCollection resp. eine implementierende Klasse (z.B. FileTree) sein. Gleiches gilt für den dataset-Parameter. Als einzelner Wert für das Dataset wird in diesem Fall der Name der Datei ohne Extension und ohne Pfad verwendet. Leider kann nicht bereits in der Task-Definition aus dem Filetree eine Liste gemacht werden, z.B. fileTree(pathToUnzipFolder) { include '*.itf' }.files.name. Diese Liste ist leer.

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

Ili2pgImport unterstützt den Import von Daten in einem ilidata-Repository. Der Dateinamen (dataFile) entspricht dem Identifikator der Datei im Repository. Dem Identifikator muss ilidata: vorangestellt werden.

Beispiel 1:

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"
}

Beispiel 2:

Import der AV-Daten. In der t_datasetname-Spalte soll die BFS-Nummer stehen. Die BFS-Nummer entspricht den ersten vier Zeichen des Filenamens.

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 = fileTree(pathToUnzipFolder) { include '*.itf' }
    dataset = dataFile
    datasetSubstring = 0..4
    logFile = "ili2pg.log"
}
Parameter Beschreibung
database Datenbank in die importiert werden soll
dataFile Name der XTF-/ITF-Datei, die gelesen werden soll. Es können auch mehrere Dateien sein.
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
datasetSubstring Range für das Extrahieren eines Substrings von Datasets
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
importTid Entspricht der ili2pg-Option --importTid
importBid Entspricht der lii2pg Option –importBid
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
disableRounding Entspricht der ili2pg-Option --disableRounding
failOnException Task wirft Exception, falls ili2db-Prozess fehlerhaft ist (= Ili2dbException). Default: true.

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
coalesceJson Entspricht der ili2pg-Option --coalesceJson
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
sqlColsAsText Entspricht der ili2pg-Option --sqlColsAsText
sqlExtRefCols Entspricht der ili2pg-Option --sqlExtRefCols
keepAreaRef Entspricht der ili2pg-Option --keepAreaRef
createTidCol Entspricht der ili2pg-Option --createTidCol
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
failOnException Task wirft Exception, falls ili2db-Prozess fehlerhaft ist (= Ili2dbException). Default: true.

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. Ili2pgReplace unterstützt den Import von Daten in einem ilidata-Repository. Der Dateinamen (dataFile) entspricht dem Identifikator der Datei im Repository. Dem Identifikator muss ilidata: vorangestellt werden.

Ili2pgDelete

Löscht einen Datensatz in der PostgreSQL-Datenbank anhand eines Datensatz-Identifikators. Diese Funktion bedingt, dass das Datenbankschema mit der Option createBasketCol erstellt wurde (via Task Ili2pgImportSchema). Der Parameter failOnException muss false sein, ansonsten bricht der Job ab.

Beispiel:

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

task deleteDataset(type: Ili2pgDelete){
    database = [db_uri, db_user, db_pass]
    models = "DM01AVSO24LV95"
    dbschema = "dm01"
    dataset = "kammersrohr"
}

Es können auch mehrere Datensätze pro Task gelöscht werden:

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

task deleteDataset(type: Ili2pgDelete){
    database = [db_uri, db_user, db_pass]
    dbschema = "dm01"
    dataset = ["Olten","Grenchen"]
}

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.

Ili2pgValidate

Prüft die Daten ohne diese in eine Datei zu exportieren. Der Task ist erfolgreich, wenn keine Fehler gefunden werden und ist nicht erfolgreich, wenn Fehler gefunden werden. Mit der Option failOnException=false ist der Task erfolgreich, auch wenn Fehler gefunden werden.

Beispiel:

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

tasks.register('validate', Ili2pgValidate) {
    database = [db_uri, db_user, db_pass]
    models = "SO_AGI_AV_GB_Administrative_Einteilungen_20180613"
    modeldir = rootProject.projectDir.toString() + ";http://models.interlis.ch"
    dbschema = "agi_av_gb_admin_einteilungen_fail"
    logFile = file("fubar.log")
}

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

Zusatzfunktionen (Custom Functions): Die pluginFolder-Option ist zum jetzigen Zeitpunkt ohne Wirkung. Die Zusatzfunktionen werden als normale Abhängigkeit definiert und in der ilivalidator-Task-Implementierung registriert. Das Laden der Klassen zur Laufzeit in iox-ili hat nicht funktioniert (NoClassDefFoundError…). Der Plugin-Mechanismus von ilivalidator wird momentan ohnehin geändert (“Ahead-Of-Time-tauglich” gemacht).

JsonImport

Daten aus einer Json-Datei in eine Datenbanktabelle importieren. Die gesamte Json-Datei (muss UTF-8 encoded sein) wird als Text in eine Spalte importiert. Ist das Json-Objekt in der Datei ein Top-Level-Array wird für jedes Element des Arrays ein Record in der Datenbanktabelle erzeugt.

Beispiel:

task importJson(type: JsonImport){
    database = [db_uri, db_user, db_pass]
    jsonFile = "data.json"
    qualifiedTableName = "jsonimport.jsonarray"
    columnName = "json_text_col"
}
Parameter Beschreibung
database Datenbank in die importiert werden soll
jsonFile Json-Datei, die importiert werden soll
qualifiedTableName Qualifizierter Tabellennamen (“schema.tabelle”) in die importiert werden soll
columnName Spaltenname der Tabelle in die importiert werden soll
deleteAllRows Inhalt der Tabelle vorgängig löschen?

MetaPublisher (incubating)

Der MetaPublisher dient zum Publizieren von Metadaten/-dateien. Er erstellt eine INTERLIS-Transferdatei mit Metadaten pro Themenpublikation für die Datensuche, das Datenblatt (die HTML-Datei detaillierten Meta-Infos), falls nötig eine GeoJSON-Datei und die Geocat-XML-Datei. Die GeoJSON-Datei ist entweder statisch (für Raster o.ä.) oder dynamisch (z.B. amtliche Vermessung). Bei einer dynamischen GeoJSON-Datei wird das Datum nachgeführt.

Pro Themenpublikation (also pro Publisher-Task) kann resp. muss es auch einen MetaPublisher-Task geben. Informationen zum Thema sind in einer TOML-Datei gespeichert. Diese dient auch zum Überschreiben von Klassen- und Attributbeschreibungen, die aus der Modelldatei gelesen werden. Die GeoJSON-Datei muss im gleichen Verzeichnis wie die TOML-Datei vorliegen.

Mit dem MetaPublisher können auch Daten resp. Datenthemen publiziert werden, die nicht im SIMI erfasst sind und/oder nicht als Kartendienst publiziert werden (z.B. ÖREB-Daten).

Beispiel einer TOML-Datei:

["meta"]
identifier = "ch.so.afu.abbaustellen"
title = "Abbaustellen"
description = """
Die Abbaustellen umfassen die Flächen folgender Objekte: <br/>
<ul>
<li>sämtliche grösseren Abbaugebiete (Kiesgruben, Kalksteinbrüche sowie Tongruben), für welche ein Gestaltungsplan vorliegt. Die dargestellten Flächen umfassen jeweils den gesamten Perimeter der genehmigten Gestaltungspläne, und nicht einzelne Abbauetappen.</li>
<li>Kleinabbaustellen. Es handelt sich üblicherweise um kleinere, gemeindeeigene Mergelgruben, in welchen Material für den Bau und Unterhalt von Wald- und Flurwegen abgebaut wird. Kleinabbaustellen erfordern keinen Gestaltungsplan. Die dargestellten Flächen umfassen hier jeweils den auf Stufe Bau-, bzw. Abbaubewilligung genehmigten Perimeter.</li>
<li>alle künftigen Erweiterungs- und Ersatzstandorte, welche im kantonalen Richtplan (Kap. E-3.1 bis E-3.4) enthalten sind.</li>
</ul>
<br>
Die Flächen wurden von verschiedenen Planvorlagen und bestehenden Flächendaten mit unterschiedlichem Massstab digitalisiert, bzw. übernommen.
"""
keywords = "unverschmutztes Aushubmaterial"
synonyms = "Abbaugebiet,Kiesabbau,Kiesgrube,Steinbruch,Kalksteinbruch,Kalksteinbrüche,Tongrube,Kleinabbaustelle,Mergelgrube"
model = "SO_AFU_ABBAUSTELLEN_Publikation_20221103"
owner = "ch.so.afu"
servicer = "ch.so.agi"
licence = "https://files.geo.so.ch/nutzungsbedingungen.html"
furtherInformation = "https://so.ch/verwaltung/bau-und-justizdepartement/amt-fuer-umwelt/boden-untergrund-geologie/rohstoffe-abbau/"
formats = ["XTF", "GPKG", "SHP", "DXF"]

["SO_AFU_ABBAUSTELLEN_Publikation_20221103.Abbaustelle.Abbaustelle"]
title = "Standorte Abbaustellen"
description = "Umfasst die Flächenobjekte der Abbaugebiete, Kleinabbaustellen und künftigen Standorte. Er enthält u.a. Angaben zum abgebauten Material und zur Abstimmungskategorie im Richtplan."

Die Struktur, die möglichen Attribute im TOML und die Auswertelogik können sich noch ändern.

Ämter (“owner” und “servicer”) und Formate werden im TOML nur verlinkt. Die Daten liegen in einer XTF-Datein als Resource in GRETL vor. Das hat heute den Nachteil, dass bei einer Änderung eine neue GRETL-Version installiert werden muss. Zukünft (Idee “Themenrepo”) wird das anders gelöst.

Es gibt Attribute (“identifier” und “model”), die redundant sind, wenn es auch einen Publisher-Task gibt. Weil es aber auch MetaPublisher-Tasks ohne einen Publisher-Task geben kann, ist das bis auf weiteres so. Vielleicht könnte man diese beiden Attribute als Task-Property exponieren und sie somit von aussen (über)steuern, wenn es sie gibt.

Momentan werden die erzeugen Meta-Dateien im jeweiligen Ordner der Themenpublikation im meta-Verzeichnis gespeichert und zusätzlich (damit es für die Datensuche leichter fällt) in einem übergeordneten config-Verzeichnis.

Die Informationen zu den Klassen/Tabellen und Attributen wird in erster Linie aus dem Datenmodell gelesen. Das Datenmodell muss in einem INTERLIS-Repo vorliegen oder im gleichen Verzeichnis wie die TOML-Datei gespeichert sein. Der Parser ist (noch) sehr einfach und es wird vor allem der Fokus auf flache Datenmodelle gelegte (keine Beziehungen). Bei Klassen wird das Metaattribut title ausgelesen und für den “schönen” Titel der Klasse verwendet. Für die Beschreibung der Klasse wird der Blockkommentar ausgewertet. Beide Informationen können im TOML-File überschrieben werden (siehe Beispiel). Bei Attributen gibt es kein Metaattribut, sondern der Name des Attributes und der Blockkommentar.

Das “gretlEnvironmement”-Property wird verwendet, um zu entscheiden in welche Geocat-Umgebung die Daten hochgeladen werden. Alles ausser production landet in der Geocat-Testumgebung. Die “files”- und “data”-URL, die in der XTF- und HTML-Datei (“Datenblatt”) landen, werden ebenfalls darüber gesteuert. Die umgebungsabhängigen URL sind hardodiert im MetaPublisherStep-Code.

Man kann die Herstellung der Klassen-/Tabellen-Metainformationen unterdrücken, in dem man in der Section ["config"] das Attribut printClassDescription auf false setzt. Dies ist zwingend notwendig für Rasterthemen und sinnvoll für Edit-Modelle.

Das Publikationsdatum kann in der TOML-Datei definiert werden. Fehlt es, wird das aktuelle Datum verwendet.

Regionen: Datenthemen, die in Regionen (Subunits, Datasets) unterteilt sind, benötigen eine GeoJSON-Datei, die Informationen über die einzelnen Regionen enthält (Geometrie, Name, Identifier, Nachführungs- resp. Publikationsdatum). Die GeoJSON-Datei wird vor der Datensuche-Anwendung direkt verwendet. Die GeoJSON-Datei ist entweder statisch oder dynamisch. Die statische GeoJSON-Datei muss nicht nachgeführt werden, bei dynamischen muss in der Regel das Publikationsdatum nachgeführt werden (z.B. amtliche Vermessung oder Nutzungsplanung). Im dynamischen Fall wird geprüft, ob die Datei bereits in der Datenablage publiziert wurde. Ist dies nicht der Fall, wird sie dorthin kopiert. Anschliessend werden die Publikationsdaten nachgeführt. Im statischen Fall wird ebenfalls geprüft, ob sie bereits bereitgestellt wird und gegebenenfalls dorthin kopiert. Ein Rückfluss in das Github-Repo findet nicht statt. D.h. die Datei im Repo ist eher als GeoJSON-Template zu betrachten und nicht als Daten-Master (im dynamischen Fall). Aus der GeoJSON-Datei werden beim Herstellen der XTF-Datei (für die Datensuche) Informationen gelesen.

Die verschiedenen Dateien, die während im Task hergestellt werden, werden zuerst immer lokal gespeichert und erst am ganz am Schluss (wenn alle Dateien vorhanden sind), werden sie an ihren Zielort kopiert.

Vollständige Dokumentation muss noch erfolgen.

Siehe auch die TOML-Beispiele im Quellcode.

Beispiele:

tasks.register('publishMetaFile', MetaPublisher) {
    metaConfigFile = file("meta.toml")
    target = ["sftp://foo.bar.ch", "user", "pwd"]      
    geocatTarget = [Paths.get(project.buildDir.getAbsolutePath(), "geocat").toFile()]
}
tasks.register('publishMetaFiles', MetaPublisher) {
    dependsOn 'publishFiles'
    metaConfigFile = file("meta-dm01_so.toml")
    target = [project.buildDir]  
    regions = publishFiles.publishedRegions
}

Im zweiten Beispiel werden die Regionen aus dem vorausgegangenen Publisher-Task als Input verwendet.

Parameter Beschreibung
metaConfigFile Toml-Datei mit Metainformationen zur Themenpublikation
target Zielverzeichnis der Metadateien (sftp oder Filesystem)
regions Liste (resp. ListProperty) mit den durch den PublisherTask publizierten Regionen.
geocatTarget Zielverzeichnis für Geocat-Output (sftp oder Filesystem)

OgdMetaPublisher (incubating)

Publiziert die Metadaten eines OGD-Datensatzes. Im Gegensatz zum “MetaPublisher” ist es weniger als Publisher (mit viel Konvention), sondern eher ein Generator, der aus dem Toml-File und der INTERLIS-Modelldatei die Metainfo-Datei erstellt. Beim Resultat handelt es sich um eine INTERLIS-Transferdatei (mit eigenem OgdMeta-Modell).

Mit dem “MetaPublisher” teilt er sich einiges an Copy/Paste-Code. Man könnte gewissen Aspekte wohl zusammenlegen (z.B. Infos aus INTERLIS-Modell lesen).

Die INTERLIS-Modelldatei muss entweder in einem (bekannten) Repo sein oder im Verzeichnis der Toml-Datei vorliegen.

Beispiel:

task publishMeta(type: OgdMetaPublisher) {
    configFile = file("./ch.so.hba.kantonale_gebaeude.toml")
    outputDir = file(".")
}
Parameter Beschreibung
configFile Toml-Datei mit Metainformationen zum Datensatz.
outputDir Verzeichnis, in das die Metainfo-Datei gespeichert wird.

PostgisRasterExport

Exportiert eine PostGIS-Raster-Spalte in eine Raster-Datei mittels SQL-Query. Die SQL-Query darf nur einen Record zurückliefern, d.h. es muss unter Umständen ST_Union() verwendet werden. Es angenommen, dass die erste bytea-Spalte des Resultsets die Rasterdaten enthält. Weitere bytea-Spalten werden ignoriert. Das Outputformat und die Formatoptionen müssen in der SQL-Datei (in der Select-Query) angegeben werden, z.B.:

SELECT
    1::int AS foo, ST_AsGDALRaster((ST_AsRaster(ST_Buffer(ST_Point(2607880,1228287),10),150, 150)), 'AAIGrid', ARRAY[''], 2056) AS raster
;

Beispiel:

task exportTiff(type: PostgisRasterExport) {
    database = [db_uri, db_user, db_pass]
    sqlFile = "raster.sql"
    dataFile = "export.tif"
}
Parameter Beschreibung
database Datenbank aus der exportiert werden soll.
sqlFile Name der SQL-Datei aus das SQL-Statement gelesen und ausgeführt wird.
sqlParameters Eine Map mit Paaren von Parameter-Name und Parameter-Wert.
dataFile Name der Rasterdatei, die erstellt werden soll.

Publisher

Stellt für Vektordaten die aktuellsten Geodaten-Dateien bereit und pflegt das Archiv der vorherigen Zeitstände.

Details

S3Download

Lädt eine Datei aus einem S3-Bucket herunter.

Beispiel:

task downloadFile(type: S3Download) {
    accessKey = abcdefg
    secretKey = hijklmnopqrstuvwxy
    downloadDir = file("./path/to/dir/")
    bucketName = "ch.so.ada.denkmalschutz"
    key = "foo.pdf"
    endPoint = "https://s3.eu-central-1.amazonaws.com" 
    region = "eu-central-1"
}
Parameter Beschreibung
accessKey AccessKey
secretKey SecretKey
downloadDir Verzeichnis in das die Datei heruntergeladen werden soll.
bucketName Name des Buckets, in dem die Datei gespeichert ist.
key Name der Datei
endPoint S3-Endpunkt (default: https://s3.eu-central-1.amazonaws.com/)
region S3-Region (default: eu-central-1).

S3Upload

Lädt ein Dokument (sourceFile) oder alle Dokumente in einem Verzeichnis (sourceDir) in einen S3-Bucket (bucketName) hoch.

Mit dem passenden Content-Typ kann man das Verhalten des Browsers steuern. Default ist ‘application/octect-stream’, was dazu führt, dass die Datei immer heruntergeladen wird. Soll z.B. ein PDF oder ein Bild im Browser direkt angezeigt werden, muss der korrekte Content-Typ gewählt werden.

Beispiel:

task uploadDirectory(type: S3Upload) {
    accessKey = abcdefg
    secretKey = hijklmnopqrstuvwxy
    sourceDir = file("./docs")
    bucketName = "ch.so.ada.denkmalschutz"
    endPoint = "https://s3.eu-central-1.amazonaws.com" 
    region = "eu-central-1"
    acl = "public-read"
    contentType = "application/pdf"
}
Parameter Beschreibung
accessKey AccessKey
secretKey SecretKey
sourceDir Verzeichnis mit den Dateien, die hochgeladen werden sollen.
sourceFile Datei, die hochgeladen werden soll.
sourceFiles FileCollection mit den Dateien, die hochgeladen werden sollen, z.B. fileTree("/path/to/directoy/") { include "*.itf" }
bucketName Name des Buckets, in dem die Dateien gespeichert werden sollen.
endPoint S3-Endpunkt (default: https://s3.eu-central-1.amazonaws.com/)
region S3-Region (default: eu-central-1).
acl Access Control Layer [private, public-read, public-read-write, authenticated-read, aws-exec-read, bucket-owner-read, bucket-owner-full-control]
contentType Content-Type
metaData Metadaten des Objektes resp. der Objekte, z.B. ["lastModified":"2020-08-28"].

S3Bucket2Bucket

Kopiert Objekte von einem Bucket in einen anderen. Die Buckets müssen in der gleichen Region sein. Die Permissions werden nicht mitkopiert und müssen explizit gesetzt werden.

Beispiel:

task copyFiles(type: S3Bucket2Bucket, dependsOn:'directoryupload') {
    accessKey = s3AccessKey
    secretKey = s3SecretKey
    sourceBucket = s3SourceBucket
    targetBucket = s3TargetBucket
    acl = "public-read"
}
Parameter Beschreibung
accessKey AccessKey
secretKey SecretKey
sourceBucket Bucket aus dem die Objekte kopiert werden.
targetBucket Bucket in den die Objekte kopiert werden.
acl Access Control Layer [private, public-read, public-read-write, authenticated-read, aws-exec-read, bucket-owner-read, bucket-owner-full-control]
metaData Metadaten des Objektes resp. der Objekte, z.B. ["lastModified":"2020-08-28"].

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 Dateien geprüft werden sollen (mehrere Modellnamen durch Semikolon trennen). Default: Der Name der SHP-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 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
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.

Die Prüfung von gleichzeitig mehreren Shapefiles führt zu Fehlermeldungen wie OID o3158 of object <Modelname>.<Topicname>.<Klassenname> already exists in .... Beim Öffnen und Lesen eines Shapefiles wird immer der Zähler, der die interne (im Shapefile nicht vorhandene) OID generiert, zurückgesetzt. Somit kann immer nur ein Shapefile pro Task geprüft werden.

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']
}

Damit mit einer einzigen Task-Definition mehrere Datensätze verarbeitet werden können, kann auch eine Liste von Parametern angegeben werden.

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'],[dataset:'Grenchen']]
    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 (Map<String,String>). Oder eine Liste mit Paaren von Parameter-Name und Parameter-Wert (List<Map<String,String>>).

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

XslTransformer (incubating)

Transformiert eine Datei mittels einer XSL-Transformation ein eine andere Datei. Ist der xslFile-Parameter ein String, wird erwartet, dass die Datei im GRETL-Verzeichnis im Ressourcenordner src/main/resources/xslt-Verzeichnis gespeichert ist. Falls der xslFile-Parameter ein File-Objekt ist, können lokale Dateien verwendet werden.

task transform(type: XslTransformer) {
    xslFile = "eCH0132_to_SO_AGI_SGV_Meldungen_20221109.xsl"
    xmlFile = file("MeldungAnGeometer_G-0111102_20221103_145001.xml")
    outDirectory = file(".")
}
task transform(type: XslTransformer) {
    xslFile = file("path/to/eCH0132_to_SO_AGI_SGV_Meldungen_20221109.xsl")
    xmlFile = file("MeldungAnGeometer_G-0111102_20221103_145001.xml")
    outDirectory = file(".")
}
task transform(type: XslTransformer) {
    xslFile = "eCH0132_to_SO_AGI_SGV_Meldungen_20221109.xsl"
    xmlFile = fileTree(".").matching {
        include "*.xml"
    }
    outDirectory = file(".")
}
Parameter Beschreibung
xslFile Name der XSLT-Datei, die im src/main/resources/xslt-Verzeichnis liegen muss oder File-Objekt (beliebier Pfad).
xmlFile Datei oder FileTree, die/der transformiert werden soll.
outDirectory Verzeichnis, in das die transformierte Datei gespeichert wird. Der Name der transformierten Datei entspricht dem Namen der Inpuzt-Datei mit Endung .xtf.