Delete-Befehl

Der delete Befehl löscht oder terminiert Features in der VCDB v5. Er verwendet die entsprechenden Datenbankfunktionen, um diese Operationen durchzuführen.

Seien Sie vorsichtig beim Verwenden des delete Befehls, da der Löschvorgang sofort gestartet wird. Es erfolgt keine Rückfrage wie "Sind Sie sicher?". Sie können den Befehl zunächst im Vorschaumodus ausführen – dabei bleibt die Datenbank unverändert.

Synopsis

vcdb delete [OPTIONS]

Optionen

Der delete Befehl erbt globale Optionen vom Hauptbefehl vcdb. Zusätzlich definiert er allgemeine Lösch-, Abfrage-, Filter- und Metadatenoptionen.

Globale Optionen

Option Beschreibung Standardwert

Option	Beschreibung	Standardwert
`[@<filename>…]`	Eine oder mehrere Argumentdateien mit Optionen.
`-h`, `--help`	Hilfenachricht anzeigen und beenden.
`-V`, `--version`	Versionsinformationen ausgeben und beenden.
`--config-file=<file>`	Konfiguration aus dieser Datei laden.
`-L`, `--log-level=<level>`	Log-Level: `fatal`, `error`, `warn`, `info`, `debug`, `trace`.	`info`
`--log-file=<file>`	Log-Nachrichten in diese Datei schreiben.
`--quiet`	Deaktiviert Log-Nachrichten auf der Konsole.
`--pid-file=<file>`	Datei mit der Prozess-ID erstellen.
`--plugins=<dir>`	Plugins aus diesem Verzeichnis laden.
`--use-plugin=<plugin[=true\|false]> [,<plugin[=true\|false]>…]`	Plugins mit passendem vollqualifiziertem Klassennamen aktivieren oder deaktivieren.	`true`

[@<filename>…]

Eine oder mehrere Argumentdateien mit Optionen.

-h, --help

Hilfenachricht anzeigen und beenden.

-V, --version

Versionsinformationen ausgeben und beenden.

--config-file=<file>

Konfiguration aus dieser Datei laden.

-L, --log-level=<level>

Log-Level: fatal, error, warn, info, debug, trace.

info

--log-file=<file>

Log-Nachrichten in diese Datei schreiben.

--quiet

Deaktiviert Log-Nachrichten auf der Konsole.

--pid-file=<file>

Datei mit der Prozess-ID erstellen.

--plugins=<dir>

Plugins aus diesem Verzeichnis laden.

--use-plugin=<plugin[=true|false]> [,<plugin[=true|false]>…]

Plugins mit passendem vollqualifiziertem Klassennamen aktivieren oder deaktivieren.

true

Weitere Informationen zu den globalen Optionen und Nutzungshinweise siehe hier.

Löschoptionen

Option Beschreibung Standardwert

Option	Beschreibung	Standardwert
`--temp-dir=<dir>`	Temporäre Dateien in diesem Verzeichnis speichern.
`-m`, `--delete-mode=<mode>`	Löschmodus: `delete`, `terminate`.	`terminate`
`--[no-]terminate-all`	Auch untergeordnete Features terminieren.	`true`
`--index-mode=<mode>`	Indexmodus: keep, drop, drop_create. Bei der Verarbeitung großer Datenmengen kann das Deaktivieren der Indizes sinnvoll sein.	`keep`
`--preview`	Im Vorschau-Modus ausführen. Features werden nicht gelöscht.
`-c`, `--commit=<number>`	Änderungen nach dem Löschen dieser Anzahl von Features in der Datenbank festschreiben.

--temp-dir=<dir>

Temporäre Dateien in diesem Verzeichnis speichern.

-m, --delete-mode=<mode>

Löschmodus: delete, terminate.

terminate

--[no-]terminate-all

Auch untergeordnete Features terminieren.

true

--index-mode=<mode>

Indexmodus: keep, drop, drop_create. Bei der Verarbeitung großer Datenmengen kann das Deaktivieren der Indizes sinnvoll sein.

keep

--preview

Im Vorschau-Modus ausführen. Features werden nicht gelöscht.

-c, --commit=<number>

Änderungen nach dem Löschen dieser Anzahl von Features in der Datenbank festschreiben.

Metadatenoptionen für Terminate-Operationen

Option Beschreibung Standardwert

Option	Beschreibung	Standardwert
`--termination-date=<time>`	Zeitangabe im Format `<YYYY-MM-DD>` oder `<YYYY-MM-DDThh:mm:ss[(+\|-)hh:mm]>`, die für das Termination-Date verwendet wird.	`now`
`--lineage=<lineage>`	Datenabstammung oder Ursprung der Features.
`--updating-person=<name>`	Name des Benutzers, der für das Löschen verantwortlich ist.	Datenbankbenutzer
`--reason-for-update=<reason>`	Grund für das Löschen der Daten.

--termination-date=<time>

Zeitangabe im Format <YYYY-MM-DD> oder <YYYY-MM-DDThh:mm:ss[(+|-)hh:mm]>, die für das Termination-Date verwendet wird.

now

--lineage=<lineage>

Datenabstammung oder Ursprung der Features.

--updating-person=<name>

Name des Benutzers, der für das Löschen verantwortlich ist.

Datenbankbenutzer

--reason-for-update=<reason>

Grund für das Löschen der Daten.

Abfrage- und Filteroptionen

-t, --type-name=<[prefix:]name> [,<[prefix:]name>…]

Namen der zu verarbeitenden Features.

-f, --filter=<cql2-text>

Filter zum Abrufen von Features. Verwenden Sie die erweiterte CQL2-Filtersprache der VCDB.

--filter-crs=<crs>

SRID oder Identifier des CRS, das für Geometrien im Filterausdruck verwendet wird.

VCDB CRS

--sql-filter=<sql>

SQL-Query, die als Filter verwendet wird.

--limit=<count>

Maximale Anzahl der zu verarbeitenden Features.

--start-index=<index>

Index innerhalb der Eingabemenge, ab dem Features verarbeitet werden.

Zeitbasierte Objekt-Historie-Optionen

Option Beschreibung Standardwert

Option	Beschreibung	Standardwert
`-M`, `--validity=<mode>`	Verarbeitung von Feature basierend auf ihrer Gültigkeit: `valid`, `invalid`, `all`.	`valid`
`-T`, `--validity-at=<time>`	Gültigkeit zu einem bestimmten Zeitpunkt prüfen. Das Zeitformat muss `<YYYY-MM-DD>` oder `<YYYY-MM-DDThh:mm:ss[(+\|-)hh:mm]>` sein.
`--validity-reference=<source>`	Referenz für die Gültigkeitszeit: `database`, `real_world`	`database`
`--lenient-validity`	Unvollständige Gültigkeitsintervalle von Features ignorieren.

-M, --validity=<mode>

Verarbeitung von Feature basierend auf ihrer Gültigkeit: valid, invalid, all.

valid

-T, --validity-at=<time>

Gültigkeit zu einem bestimmten Zeitpunkt prüfen. Das Zeitformat muss <YYYY-MM-DD> oder <YYYY-MM-DDThh:mm:ss[(+|-)hh:mm]> sein.

--validity-reference=<source>

Referenz für die Gültigkeitszeit: database, real_world

database

--lenient-validity

Unvollständige Gültigkeitsintervalle von Features ignorieren.

Datenbank-Verbindungsoptionen

Option Beschreibung Standardwert

Option	Beschreibung	Standardwert
`-H`, `--db-host=<host>`	Hostname des VCDB Datenbankservers.
`-P`, `--db-port=<port>`	Port des VCDB Datenbankservers.	5432
`-d`, `--db-name=<database>`	Name der VCDB-Instanz, zu eine Verbindung hergestellt werden soll.
`-S`, `--db-schema=<schema>`	Schema, das beim Verbinden zur VCDB verwendet werden soll.	`citydb` oder Benutzername
`-u`, `--db-username=<user>`	Benutzername für die Verbidung zur VCDB.
`-p`, `--db-password [=<password>]`	Passwort für die Verbidung zur VCDB. Leer lassen, um zur Eingabe aufgefordert zu werden.
`--db-property=<property=value> [,<proeprty=value>…]`	Datenbankspezifische Verbindungsparameter.

-H, --db-host=<host>

Hostname des VCDB Datenbankservers.

-P, --db-port=<port>

Port des VCDB Datenbankservers.

5432

-d, --db-name=<database>

Name der VCDB-Instanz, zu eine Verbindung hergestellt werden soll.

-S, --db-schema=<schema>

Schema, das beim Verbinden zur VCDB verwendet werden soll.

citydb oder Benutzername

-u, --db-username=<user>

Benutzername für die Verbidung zur VCDB.

-p, --db-password [=<password>]

Passwort für die Verbidung zur VCDB. Leer lassen, um zur Eingabe aufgefordert zu werden.

--db-property=<property=value> [,<proeprty=value>…]

Datenbankspezifische Verbindungsparameter.

Weitere Informationen zu den Datenbank-Verbindungsoptionen und Nutzungshinweise siehe hier.

Verwendung

Löschmodus

Der Löschmodus, definiert über die Option --delete-mode, legt fest, wie Features in der Datenbank gelöscht werden. Die verfügbaren Modi sind:

delete: Features werden physisch aus der Datenbank entfernt. Dies hält die Datenbank schlank, indem nur die aktuellsten Versionen der Stadtobjekte gespeichert bleiben.
terminate: Features werden nicht physisch gelöscht, sondern als "terminiert" markiert, indem ihr termination_date Attribut auf den Ausführungszeitpunkt der Operation gesetzt wird. Dadurch verbleiben die Features in der Datenbank und ihre Objekt-Historie wird erhalten. Dies ist der Standardmodus.

Beide Modi löschen ein Feature zusammen mit seinen "enthaltenen" (contained) Subfeatures, die als Teil des Features betrachtet werden. Die Option --no-terminate-all ändert dieses Standardverhalten im terminate Modus. Das Terminieren aller Subfeatures kann deutlich mehr Zeit in Anspruch nehmen, als wenn nur das Feature selbst terminiert wird. Es muss daher geprüft werden, ob eine kaskadierende Ausführung für die angedachten Anwendungsfälle und Szenarien erforderlich ist.

Der delete Befehl ignoriert standardmäßig Features, die bereits terminiert wurden, sofern nicht anders angegeben. Siehe unten für Anweisungen zum Löschen historischer Versionen.
Bereits terminierte Features können nicht erneut terminiert werden – sie können nur physisch gelöscht werden.
Im Gegensatz zu "enthaltenen" Subfeatures, werden Subfeatures, die nur "in Beziehung stehen" (related), nicht mitgelöscht. Der Unterschied zwischen beiden Varianten wird in diesem Abschnitt erläutert.

Löschvorgang festschreiben

Standardmäßig wird der Löschvorgang erst dann in der Datenbank festgeschrieben (committed), wenn er vollständig und erfolgreich abgeschlossen ist. Tritt ein Fehler auf oder wird der Vorgang vorzeitig abgebrochen, werden keine Features gelöscht – die Datenbank bleibt unverändert.

Alternativ kann die Option --commit verwendet werden, um festzulegen, dass der Löschvorgang bereits nach einer bestimmten Anzahl gelöschter Features festgeschrieben werden soll. Dadurch wird die Operation in kleinere Pakete (Batches) unterteilt, die jeweils einzeln nach ihrer Verarbeitung committed werden. In diesem Fall gilt die Alles-oder-Nichts-Strategie (all-or-nothing) für jeden Batch und nicht für den gesamten Löschvorgang.

In seltenen Fällen kann das Löschen einer sehr großen Anzahl von Features in einer einzigen Operation mehr SQL-Befehle erfordern, als die Datenbank pro Transaktion erlaubt. Die Option --commit hilft auch dabei, solche Fehler zu vermeiden. Für PostgreSQL liegt das Limit bei maximal 2³² SQL-Befehlen pro Transaktion.

Löschvorschau

Die Option --preview führt den Löschvorgang im Vorschau-Modus aus. Der delete Befehl wird so verarbeitet, als ob die Löschung tatsächlich stattfinden würde – jedoch werden keine Änderungen an der Datenbank vorgenommen. Dieser Modus hilft dabei, potenzielle Probleme wie Konflikte oder Fehler im Vorfeld zu erkennen, bevor sie Auswirkungen auf die Datenbank haben. So lässt sich sicherstellen, dass die eigentliche Löschoperation wie erwartet durchgeführt werden kann

Filterung von Features

Der delete Befehl bietet verschiedene Filteroptionen, mit denen kontrolliert werden kann, welche Features aus der VCDB v5 Instanz gelöscht werden.

Feature-Typ Filter

Über die Option --type-name können eine oder mehrere Feature-Typen angegeben werden, die gelöscht werden sollen. Für jeden Feature-Typ ist der Typname wie in der Tabelle OBJECTCLASS der VCDB v5 anzugeben. Um Mehrdeutigkeit zu vermeiden, kann der Namespace-Alias aus der NAMESPACE Tabelle als Präfix im Format prefix:name hinzugefügt werden. Es werden nur Features gelöscht, die einem der angegebenen Typen entsprechen.

CQL2-basierte Filterung

vcdb-tool unterstützt die OGC Common Query Language (CQL2) als Standard-Abfragesprache für die Filterung von Features aus der VCDB v5. CQL2 erlaubt sowohl attributbasierte als auch räumliche Filter und bietet eine umfangreichen Satz an Vergleichsoperatoren, räumlichen Funktionen und logischen Operatoren. Nur Features, die die angegebenen Filterkriterien erfüllen, werden exportiert.

CQL2-Filterausdrücke werden dem delete Befehl über die Option --filter übergeben. Gegebenenfalls müssen sie in Anführungszeichen notiert werden. Bei räumlichen Filtern wird davon ausgegangen, dass die Filtergeometrien im gleichen Koordinatenreferenzsystem (CRS) vorliegen, das auch für die VCDB-Instanz definiert sind. Um ein anderes CRS anzugeben, kann die Option --filter-crs mit der entsprechenden SRID (z.B. 4326 für WGS84) verwendet werden.

Weitere Information zur Verwendung von CQL2 mit der VCDB v5 finden Sie in der CQL2-Dokumentation.

Das folgende Beispiel zeigt, wie Gebäude basierend auf ihrem height Attribut terminiert werden.

Linux
Windows CMD

./vcdb delete [...] \
    --type-name=bldg:Building \
    --filter="con:height > 15"

vcdb delete [...] ^
    --type-name=bldg:Building ^
    --filter="con:height > 15"

Um die envelope Eigenschaft von Features gegen einen Bounding-Box-Filter zu prüfen, kann der folgende CQL2-Filterausdruck verwendet werden.

Linux
Windows CMD

./vcdb delete [...] \
    --filter="s_intersects(core:envelope, bbox(13.369,52.506,13.405,52.520))" \
    --filter-crs=4326

vcdb delete [...] ^
    --filter="s_intersects(core:envelope, bbox(13.369,52.506,13.405,52.520))" ^
    --filter-crs=4326

SQL-basierte Filterung

Mit der Option --sql-filter können SQL SELECT Anweisungen als Filterausdrücke verwendet werden, mit denen alle Details des relationalen Schemas abgefragt werden können. Jede SELECT Statement, das vom zugrunde liegenden Datenbanksystem unterstützt wird, ist als Eingabe erlaubt, sofern es als Ergebnis eine Liste von id Werten aus der FEATURE Tabelle zurückliefert. Nur Features, die in der zurückgegebenen Liste enthalten sind, werden exportiert.

Das nachfolgende Beispiel zeigt die Filterung von Features anhand ihres Identifiers in der Spalte objectid der FEATURE Tabelle. Die SELECT Anweisung muss in Anführungszeichen gesetzt und Sonderzeichen gegebenenfalls maskiert werden.

Linux
Windows CMD

./vcdb delete [...] \
    --sql-filter="SELECT id FROM feature WHERE objectid IN ('ABC', 'DEF')"

vcdb delete [...] ^
    --sql-filter="SELECT id FROM feature WHERE objectid IN ('ABC', 'DEF')"

Count-Filter

Mit --limit wird die maximale Anzahl der zu löschenden Features festgelegt. Die --start-index Option definiert den 0-basierten Index des ersten Features in der Ergebnismenge, mit welchem der Löschvorgang beginnen soll. Beide Optionen können getrennt oder zusammen verwendet werden, um die Gesamtanzahl der zu exportierenden Features zu definieren.

Werden mehrerer Filter verwendet werden, müssen alle Bedingungen erfüllt sein, damit ein Feature gelöscht wird.
Komplexe Filterausdrücke können sehr komfortabl in Konfigurationsdaten oder Argumentdateien ausgelagert und einfach wiederverwendet werden.

Löschen historischer Versionen

Die bi-temporalen Intervalle [creation_date, termination_date) und [valid_from, valid_to) ermöglichen Objekt-Historien in der VCDB v5 (siehe hier). Das erste Intervall beschreibt die Lebensdauer des Features in der Datenbanke – also wann es eingefügt und terminiert wurde. Das zweite Intervall beschreibt die Lebensdauer des Features in der realen Welt.

Die Gültigkeit eines Features hängt davon ab, ob das entsprechende Zeitintervall beschränkt oder unbeschränkt ist:

Unbeschränkt (kein Enddatum): Das Feature ist derzeit gültig.
Beschränkt: Das Feature war nur während des angegebenen Intervalls gültig, ist aber aktuell nicht mehr gültig.

Die --validity Option steuert, welche Features in Abhängigkeit von ihrer Gültigkeit exportiert werden:

valid: Exportiert nur aktuell gültige Features. Dies ist der Standardmodus.
invalid: Exportiert nur historische, nicht mehr gülitge Features.
all: Exportiert alle Features – unabhängig von ihrer Gültigkeit.

Mit der Option --validity-reference wird festgelegt, ob sich die Gültigkeit auf die Datenbankzeit (database, Standard) oder auf die Realzeit (real_world) bezieht.

Zusätzlich erlaubt die Option --validity-at die Prüfung der Gültigkeit zu einem bestimmten Zeitpunkt in der Vergangenheit. Dieser Zeitpunkt kann entweder als Datum (<YYYY-MM-DD>) oder als Zeitstempel mit optionalem UTC-Offset (<YYYY-MM-DDThh:mm:ss[(+|-)hh:mm]>) angegeben werden. Es werden nur Features exportiert, die zu diesem Zeitpunkt entweder valid oder invalid waren.

Das folgende Beispiel zeigt, wie alle Features physisch gelöscht werden können, die vor dem 01.07.2018 terminiert wurden und somit zu diesem Zeitpunkt bereits ungültig (invalid) waren:

Linux
Windows CMD

./vcdb delete [...] \
    --mode=delete \
    --validity=invalid \
    --validity-at=2018-07-01 \
    --validity-referene=database

vcdb delete [...] ^
    --mode=delete ^
    --validity=invalid ^
    --validity-at=2018-07-01 ^
    --validity-referene=database

Standardmäßig erfolgt eine strenge Prüfung der Zeitintervalle. Mit der Option --lenient-validity wird dies aufgelockert, indem auch Zeitintervalle als gültig betrachtet werden, deren Startdatum nicht gesetzt ist.

Verwaltung von Indizes während des Löschens

Beim Löschen von Daten werden Datenbankindizes in Echtzeit aktualisiert, was den Löschvorgang verlangsamen kann, insbesondere bei großen Datenmengen. Die Option --index-mode bietet die folgenden Modi zur Steuerung des Indexverhaltens:

keep: Die Indizes bleiben unverändert. Dies ist der Standardmodus.
drop: Die Indizes werden vor dem Löschvorgang deaktiviert, was die Lösch-Performance verbessert.
drop_create: Wie drop, aber die Indizes werden nach dem Löschvorgang automatisch wieder aktiviert. Die stellt sicher, dass sie für nachfolgende Abfragen verfügbar sind.

Das Deaktivieren und Wiederherstellen von Indizes kann je nach Datenbankgröße ebenfalls viel Zeit in Anspruch nehmen. Der drop_create Modus ist daher besonders beim Löschen großer Datenmengen sinnvoll. Je größer die Datenbank wird und je mehr Daten sie enthält, desto höher kann jedoch auch der Zeitaufwand für das Deaktivieren und Neuerstellen der Indizies sein. In diesem Fall kann der größere Zeitaufwand den Vorteil einer schnelleren Lösch-Performance zunichte machen – insbesondere wenn nur kleinere Datenmengen gelöscht werden.

Mit dem index Befehl können Indizes auch unabhängig von einem Löschvorgang verwaltet werden, was eine gezieltere Kontrolle ermöglicht.

Definition von Metadaten beim Terminieren

Bei der Ausführung im terminate-Modus können die Metadaten der betroffenen Features in der Datenbank aktualisiert werden, um Informationen über den Terminate-Prozess zu dokumentieren.

Mit den Optionen --lineage, --updating-person und --reason-for-update kann der Ursprung der Features, die für die Terminierung verantwortliche Person und der Grund für die Terminierung angegeben werden. Mit --termination-date kann ein bestimmter Terminierungszeitpunkt festgelegt werden, der entweder als Datum (<YYYY-MM-DD>) oder als Zeitstempel mit optionalem UTC-Offset (<YYYY-MM-DDThh:mm:ss[(+|-)hh:mm]>) übergeben werden muss.

Diese Metadaten sind spezifisch für die VCDB und nicht im CityGML-Standard definiert (siehe auch hier). Falls sie nicht explizit angegeben werden, wird automatisch der Zeitpunkt der Ausführung als Terminierungszeitpunkt verwendet. Ebenso wird der Benutzername, der für die Verbindung zur VCDB-Datenbank verwendet wird, als Standardwert für --updating-person übernommen.

Der mit --termination-date angegebene Zeitstempel wird auf alle Features angewendet. Wählen Sie diesen sorgfältig, da die Gültigkeit des Features in der Datenbank über das Zeitintervall [creation_date, termination_date) bestimmt wird. Zur Wahrung einer konsistenten Objekt-Historie dürfen sich diese Intervalle nicht überschneiden, wenn sie dasselbe Realwelt-Objekt betreffen.