[PostNAS] Historie, Update/Replace

["Jäger, Frank (KRZ)"]

Hallo,
ich möchte die Liste über eine Diskussion informieren, die heute telefonisch geführt wurde.

Ausgangspunkt war:

Die Verarbeitung von "<wfs:Update>"- und "<wfsext:Replace>"-Sätzen aus NAS funktioniert noch nicht korrekt, weil sie wie "<wfs:Delete>" verabeitet werden. Dabei gehen die Beziehungen verloren.
Diese Fälle müssen daher besser unterschieden werden.

Dies Ticket soll nun durch den ogr-Entwickler abgearbeitet werden: http://trac.wheregroup.com/PostNAS/ticket/16 

Dazu musste geklärt werden, wann das vorkommt und ob die Vorgaben im Ticket korrekt sind.


Generell sieht ALKIS folgende Abgabearten vor:

 1000 stichtagsbezogen (ohne Historie)  
 1100 stichtagsbezogen (mit Historie)
 3000 fallbezogen (ohne Historie)
 3100 fallbezogen (mit Historie) 

Praktisch relavant sind 1000 und 3100.

Die Abgabeart 3100 ist derzeit keine Option für PostNAS!
Fallbezogen bedeutet, dass jeder Zwischenstand (auch mehrere am gleichen Objekt zwischen zwei Abgabeterminen) übertragen werden.
Diese Abgabeart dient z.B. dazu, innerhalb des ALKIS-Verfahrens eine sekundäre und eine primäre DHK (DatenHaltungsKomponente) zu synchronisieren.
Die sekundäre DHK wird damit in die Lage versetzt, ihrerseits "kaskadierend" weitere NBA abzugeben.
Dazu ist es notwendig, jeden zeitlichen Zwischenstand reproduzieren zu können.

Ein solcher Sekundärbestand enthält dann auch Objekte, die bereits nicht mehr gültig sind.
Für die Darstellung müssten diese dann aber auch ständig heraus gefiltert werden.
D.h. bei *jeder* SQL-Afrage auf die Datenbank muss bei *allen* Tabellen *immer* auch nach Zeitpunkt gefiltert werden.

Zielrichtung von PostNAS ist aber der Aufbau eines *aktuellen* Sekundärbestandes für performante Präsentation und Auskunft. Dies wird durch die Abgabeart 1000 ausreichend gewährleistet.
Bei Folgeabgaben (Aktualisierung) enthalten die NAS-Daten Sätze mit Operator "Replace" und "Update". 

Die weiter verarbeitenden Programme (UMN-Mapfile, Buschauskunft, Navigation) filtern derzeit nicht die bereits wieder ungültigen Objekte heraus. Das SQL-Datenbankschema enthält nicht einmal das Feld für den Zeitstempel für das Ende des Lebenszeit-Intervalls eines Objektes. Das Objekt wird aus der sekundären Datenbank komplett entfernt, wenn es nicht mehr gültig ist (Operator "delete").

Daraus folgt: Beim derzeitigen Entwicklungsstand kann PostNAS NAS-Daten der Abgabeart "1000" fast korrekt verarbeiten, aber NAS-Daten der Abgabeart "3100" nicht.

Die Diskutierenden waren sich einig, dass es auf absehbare Zeit auch nicht angestrebt wird, eine Vollhistorie wie in einer ALKIS-DHK über PostNAS zu führen.

Die wenigen Fälle, wo eine auf einen bestimmten Zeitpunkt bezogene Auswertung notwendig ist, können mit dem amtlichen Auskunft-System der ALKIS-Hersteller vom Katasteramt abgedeckt werden.

PostNAS soll eine Ergänzung sein, um ALKIS/NAS-Daten in einem GIS-Umfeld möglichst einfach und performant darstellen und auswerten zu können.
Die Einbeziehung von Abgabeart "3100" und der darin enthaltenen Vollhistorie würde nicht nur auf Seiten des Konverters sondern auch bei den auswertenden Programmen den Aufwand beträchtlich erhöhen. Die Performance der Programm würde sinken. Entwicklung und Bedienung würden (noch) komplizierter. 

Wir hoffen, dass dies mit der Meinung der schweigenden Mehrheit konform ist. 
Sonst: Feuer frei ...


Einen Begriff gilt es in dem Zusammenhang noch zu abzugrenzen:

Die "Flurstückshistorie" bildet das Verhältnis Vorgänger-/Nachfolger-Flurstück ab. Diese ist enthalten in der Objektart (= Tabelle) "ax_HistorischesFlurstück" (aus ALKIS) und "ax_HistorischesFlurstückOhneRaumbezug" (migriert aus ALB).

Um diese Flurstückshistorie zu bekommen, müssen die genannten Objektarten in den Selektionskriterien bei der NBA-Abgabe eingeschaltet werden.

Dies ist *nicht* gemeint mit dem Begriff "mit/ohne Historie" bei der Abgabeart.

Auch eine Abgabeart 1000 kann also eine komplette Flurstückshistorie enthalten.


Fazit:

Für Verwendung mit PostNAS beim Katasteramt bitte bestellen:  Abgabeart = 1000 stichtagsbezogen (ohne Historie)   

Die Restfehler bei Verarbeitung von Replace/Update-Sätzen bei der Aktualisierung werden angegangen.

Die Verarbeitung von NAS-Daten der Abgabeart "3100 fallbezogen (mit Historie)" ist derzeit nicht vorgesehen und würde von den Auswerteprogrammen derzeit nicht korrekt angezeigt.


Mit freundlichen Grüßen
Frank Jäger