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.
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.
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.
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.
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.
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.
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
Aufwandschätzung