[PostNAS] PostNAS-Fortführungen

[Stefan Rahn]

Hallo Herr Jäger,

erstmal vielen Dank für Ihre ausführliche Antwort.
So langsam klärt sich die Sache auf. Wie sich jetzt herausgestellt hat, 
gibt es hier bei uns doch auch NAS-Fortführungsdateien mit langen 
gml_ids also gml_id + Zeitstempel.
Es gibt aber auch welche mit kurzen gml_ids. Ich nehme an, dass die 
kurzen gml_ids dann verwendet werden, wenn ein Objekt in einer NAS-Datei 
nur einmal fortgeführt wird, ansonsten werden die langen gml_ids verwendet.
Außerdem war uns nicht klar, das die Tabelle "delete" vor jeder 
Fortführung geleert werden muss.
Unterm Strich macht das UNIQUE-Constraint auf der Spalte "featureid" 
dann also doch Sinn. Das haben wir jetzt auch verstanden :-)

Gruß,
Stefan Rahn

  
GDI-Service
Joachim-Jungius-Str. 9
18059 Rostock
Tel: 0381 40344445
E-Mail: stefan.rahn at gdi-service.de
www.gdi-service.de
  

Am 05.02.2015 um 18:59 schrieb 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
>
>
> _______________________________________________
> NAS mailing list
> NAS at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/nas

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.osgeo.org/pipermail/nas/attachments/20150206/014f6ac9/attachment.html>