[PostNAS] PostNAS-Fortführungen

[Jäger, Frank (KRZ)]

> -----Ursprüngliche Nachricht-----
> Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im
> Auftrag von Stefan Rahn
> Gesendet: Donnerstag, 5. Februar 2015 15:21
> An: nas Schnittstelle via ogr2ogr
> Betreff: [PostNAS] PostNAS-Fortführungen
..
> bei uns in Meckenburg-Vorpommern ist ALKIS nun auch eingeführt worden und
> in den Katasterämtern laufen die ersten NBA-Fortführungen auf dem PostNAS-
> Schema.


Willkommen im Club!


> Was uns dabei wundert ist der UNIQUE INDEX (und damit auch
> UNIQUE-Constraint) auf der Spalte "featureid" der Tabelle "delete":
> 
> CREATE UNIQUE INDEX delete_fid ON "delete"(featureid);
> 
> In die Spalte "featureid" werden ja die gml_ids der fortgeführten Objekte
> eingetragen. Und durch diesen Index wird doch verhindert, dass ein Objekt
> mehrmals fortgeführt wird (das kann auch innerhalb einer Fortführung
> passieren).
> Warum hat das bisher bei keinem anderen PostNAS-Nutzer zu einem Fehler
> geführt? Oder haben alle anderen gml_ids mit Zeitstempel hinten dran?


Ja, so sollte es sein!
Der Kommentar zu der Spalte lautet:

  featureid character varying, -- Zusammen gesetzt aus GML-ID (16) und Zeitstempel.

Die Inhalte sind hier in der Delete-Tabelle 32 Stellen lang, während die gml_id in den Objekt-Tabellen ohne Zeitstempel geführt wird:
  gml_id character(16) NOT NULL,

Hier müssen sie auch nur zusammen mit dem Entstehungszeitpunkt eindeutig sein:
  CREATE UNIQUE INDEX ax_flurstueck_gml ON ax_flurstueck USING btree (gml_id, beginnt);

Die lange "featureid", die aus "gml_id" und Zeitstempel zusammen gesetzt ist, wird vom Datenbank-Trigger benötigt:

CREATE OR REPLACE FUNCTION delete_feature_kill()
....
IF length(NEW.featureid)=32 THEN
		-- beginnt-Zeit der zu löschenden Vorgaenger-Version des Objektes
		vbeginnt := substr(NEW.featureid, 17, 4) || '-'   ....

- ODER -

CREATE OR REPLACE FUNCTION delete_feature_hist()
...
IF length(NEW.featureid)=32 THEN
		-- beginnt-Zeit der zu ersetzenden Vorgaenger-Version des Objektes


In den Objekt-Tabellen war dagegen die Erweiterung der gml_id um den Zeitstempel eher störend (zwischenzeitlicher Irrtum der Evolution).
Die "Relationen" verweisen nämlich nur auf IDs und nicht auf ID-Zeitversionen. In allen SQL-JOIN-Klauseln zu ALKIS-Relationen musste darum auf einen Substring gejoint werden statt von Feld zu Feld. Da war sehr umständlich und hat die Indices ausgehebelt. Da das zu nichts nützlich war, ist die gml_id wieder auf 16 gestutzt worden.

Ich hoffe, ich verrate hier kein Geheimnis: PostNAS, also ogr2ogr, kann eigentlich gar keine "Fortführungen" verarbeiten und kennt kein NBA-Verfahren.
Ogr2ogr ist eigentlich ein 1:1-Konverter für Geo-Formate. Die Besonderheit des PostNAS-Treibers in OGR ist, das er weiß, dass DELETE, REPLACE und UPDATE auch in die Tabelle "delete" eingetragen werden.
Dort läuft dann einer der beiden alternativen Trigger und der enthält die eigentliche Fortführungslogik und kümmert sich um die Entsorgung nutzloser Alt-Objekte.

Der NAS-Treiber auf der Eingabe-Seite von ogr2ogr funktioniert - für NBA-Aktualisierungen - also nur im Zusammenspiel mit PostgreSQL und dem Trigger auf der Ausgabeseite. Ausgabeformate, die diese interne Logik nicht haben, lassen sich nicht korrekt fortführen.

Im Trigger ist aber auch vorgesehen, dass der Zeitstempel mal fehlen darf:
	ELSIF length(NEW.featureid)=16 THEN
		-- Ältestes nicht gelöschtes Objekt

Wann solche kurzen featureid vorkommen dürfen, weiß ich nicht.

Am Trigger ist lange gefeilt worden. Das ist in "alkis-functions.sql" ausführlich dokumentiert.
Zum Verständnis der Funktionsweise ist z.B. wichtig zu wissen:

--
Jede dieser NAS-Dateien wird von PostNAS in mehreren Durchläufen verarbeitet.
1. Im ersten Durchlauf wird die 1:1-Konvertierung der Daten vorgenommen. 
   Die Feldinhalte der NAS-Datei werden in neue Zeilen in die Objekttabellen der Datenbank übertragen. 
2. Dann werden in einem weiteren Durchlauf die Operationen "delete", "update" und "replace" verarbeitet.
   Diese werden von PostNAS in die Tabelle "delete" eingetragen, dies löst den Trigger aus.
--

Wenn der Trigger aufgerufen wird, sind also alle weiteren Zeit-Versionen des Objekts (ältere und ggf. auch neuere) aus der NAS-Datei schon vorhanden. Er muss fein unterscheiden, welche davon er ins Nirvana schickt.


> Gruß,
> Stefan Rahn


MfG
F. Jäger
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 7599 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20150205/76d2a330/attachment.bin>