<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hallo Herr Jäger,<br>
      <br>
      erstmal vielen Dank für Ihre ausführliche Antwort.<br>
      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.<br>
      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.<br>
      Außerdem war uns nicht klar, das die Tabelle "delete" vor jeder
      Fortführung geleert werden muss.<br>
      Unterm Strich macht das UNIQUE-Constraint auf der Spalte
      "featureid" dann also doch Sinn. Das haben wir jetzt auch
      verstanden :-)<br>
      <br>
      Gruß,<br>
      Stefan Rahn<br>
      <pre class="moz-signature" cols="72"> 
GDI-Service
Joachim-Jungius-Str. 9
18059 Rostock
Tel: 0381 40344445
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:stefan.rahn@gdi-service.de">stefan.rahn@gdi-service.de</a>
<a class="moz-txt-link-abbreviated" href="http://www.gdi-service.de">www.gdi-service.de</a>
 </pre>
      Am 05.02.2015 um 18:59 schrieb Jäger, Frank (KRZ):<br>
    </div>
    <blockquote
      cite="mid:F2176AE4E9FFAF45BEA8D84DD6F4AF1A104B54E1@skrzmxmbx01"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">-----Ursprüngliche Nachricht-----
Von: <a class="moz-txt-link-abbreviated" href="mailto:nas-bounces@lists.osgeo.org">nas-bounces@lists.osgeo.org</a> [<a class="moz-txt-link-freetext" href="mailto:nas-bounces@lists.osgeo.org">mailto:nas-bounces@lists.osgeo.org</a>] Im
Auftrag von Stefan Rahn
Gesendet: Donnerstag, 5. Februar 2015 15:21
An: nas Schnittstelle via ogr2ogr
Betreff: [PostNAS] PostNAS-Fortführungen
</pre>
      </blockquote>
      <pre wrap="">..
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">

Willkommen im Club!


</pre>
      <blockquote type="cite">
        <pre wrap="">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?
</pre>
      </blockquote>
      <pre wrap="">

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.


</pre>
      <blockquote type="cite">
        <pre wrap="">Gruß,
Stefan Rahn
</pre>
      </blockquote>
      <pre wrap="">

MfG
F. Jäger</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
NAS mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NAS@lists.osgeo.org">NAS@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/nas">http://lists.osgeo.org/mailman/listinfo/nas</a></pre>
    </blockquote>
    <br>
  </body>
</html>