validate_selected_features

validate_selected_features.md

Subset-Validierung in Model Baker

Ausgangslage

ili2db (-validate) soll man mit einem Parameter die OIDs mitgeben können. Im QGIS Model Baker würde sich also eine Validierung einese Subsets der Daten anbieten.

Komponenten

1. Ermitteln des Subsets

Welche OIDs des ili2db übergeben werden, hängt von der Implementierung ab. Oft ergibt sich der Use Case: Benutzer:in ändert Features - Benutzer:in möchte genau diese Features validieren.

a. anhand von selektierten Features

Es werden nur die selektierten Features validiert.

• Checkbox: "Validate selected features."
• und/ oder Checkbox: "Validate selected features on current layer."

Selektierte Features werden geparst und die OIDs (t_ili_tids) dem ili2db übergeben.

Pros

• Straightforeward und leicht verständliche Lösung.
• Kann auch als Validierung des Layers (wenn alles selektiert ist) benutzt werden.

Cons

• Man muss den Überblick über alle Selektionen behalten. Man muss evtl. durch alle Layer gehen und die Selektion überprüfen. Vielleicht wär auch noch eine Option "Deselect all on all layers" hilfreich.
• Auch erfasst man vielleicht Features auf Kind-Layer, die dann mühsam zu finden sind für die Selektion. Ein automatisches Ermitteln und Hinzufügen von referenzierten Features aber kann zu Loops und grossen Datenmengen führen, weshalb darauf verzichtet wird.

b. anhand von zuletzt gespeicherten Änderungen

Bei einer Speicherung der Daten sollen die OIDs (t_ili_tids) der Features gesammelt werden und dem Validierungs-GUI zur Verfügung stehen.

Pros

• Es braucht keine manuelle Selektion.

Cons

• Wenn man dann weitere Anpassungen macht und erneut speichert, verliert man die ursprünglichen "zuletzt gespeicherten" Features.

Dieser Ansatz wird nicht weiter verfolgt und keine Zeitschätzung dafür gemacht.

c. anhand von "Recorded Changes"

Man kan eine Recording Session starten (oder sie wird automatisch gestartet beim öffnen eines Projektes). Die OIDs (t_ili_tids) aller Features, die geändert / hinzugefügt werden, sollen gesammelt werden und dem Validator zur Verfügung stehen.

Pros

• Es braucht keine manuelle Selektion.
• Man behält die OIDs der geänderten Features über mehrere "Speicherungen".

Cons

• Komplexere Implementierungen wegen Undo-Funktion etc. oder erneutem Löschen (es müssten viele Use Cases berücksichtigt werden).
• Eine komplett neue Komponente im Plugin bedeutet auch mehr Maintanance etc.

2. Ermitteln der Nachbarn

Sofern die Features Geometrien haben, sollen (optional) auch die OIDs der Nachbars-Features ermittelt und übergeben werden.

Je nach Menge muss auf die Performance geachtet werden. Evtl. braucht es einen zusätzlichen Panel: "Collect neighbours" -> wenn man sieht es geht viel zu lange, soll man auch abbrechen können.

Aufwandschätzungen

Es werden Zeitschätzungen gemacht für:

• \1.a. Ermitteln des Subsets anhand von selektierten Features
• \1.b. Ermitteln des Subsets anhand von "Recorded Changes"
• \2. Ermitteln der Nachbarn

(1.a. oder 1.b. können auch koexistieren)

Umsetzungs-Konzept auf Seite ili2db / iox-ili

• ili2db soll so erweitert werden, dass unter Angabe eines neuen Parameters eine Liste von Objektidentifikatoren (t_ili_tid) übergeben werden können.
• Auf der Basis der bereits existierenden Iox-Filterungen (u.a. für Baskets, etc.) werden die zu validierenden Objekte herausgefiltert und validiert.
• Die Validierung umfasst den kompletten, sogenannten "first pass" inklusive Mandatory Constraints. Ausgenommen sind dabei in einer ersten Version Referenzprüfungen oder alle weiteren Constraints.

Aufwandschätzung

• Ramp-Up, Testdaten
• ili2db: Neuer Parameter, Integration Ioxfilter, Erg. Testsuite
• iox-ili: Ergänzung Test-Suite / Konfiguration partielle Validierung