[PostNAS] RE: Antworten zu Delete/Replace

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

Hallo,
da mir niemand antworten mag habe ich mich durchgewühlt und antworte mir selbst.

(weiter: unten)


> -----Original Message-----
> From: nas-bounces at lists.osgeo.org 
> [mailto:nas-bounces at lists.osgeo.org] On Behalf Of "Jäger, Frank (KRZ)"
> Sent: Monday, April 23, 2012 1:50 PM
> To: NAS Schnittstelle via ogr2ogr
> Subject: [PostNAS] Fragen zu Delete/Replace
> 

...
> Nach erfolgreichemn Test werde ich die gepatchten Versionen 
> ins PostNAS-SVN hochladen.


Ich habe das 'postnas.diff', welches dem gdal-Patch #5444 angehängt war, in das svn von PostNAS eingearbeitet.
Zweig http://trac.wheregroup.com/PostNAS/browser/trunk/data/konvert/postnas_0.7

'alkis-funktions.sql' aus dem diff habe ich dabei in 'alkis_PostNAS_0.7_schema.sql' integriert.

(Das '\i'  funktioniert hier nicht. Include?)

Die 'gml_id' ist in einer Datenbank, die auch 'Historie' enthalten kann, nun nicht mehr der (unique) Primary Key.
Dies wurde durch den Patch in allen Tabellen geändert.
Dies hat auch Auswirkungen auf die Nachverarbeitung, z.B. auf das Zusammenfassen der Nutzungsarten in einer Tabelle.
Somit mussten weitere Scripte angepasst werden.

Eigentlich möchte ich gar keine beendeten Objekte führen. Daher war die Einschränkung bisher eine willkommene Qualitäts-Sicherung. Um beide Aktualisierungs-Varianten zu ermöglichen, muss die Eindeutigkeit der gml_id für einen 'aktuellen' Bestand nun anders überwacht werden.


> (1)
> Bisher werden im Script "konv_batch.sh" (Version 0.6) die 
> Delete-Sätze so verarbeitet [2]:


Das Script habe ich angepasst. Bei der Aktualisierung wird die NAS-Datei mit PostNAS 0.7 nun nur noch einmal durchlaufen.
'delete' und 'replace' werden dabei in die Tabelle 'delete' eingetragen. Das Einfügen eines neuen Satzes löst dort einen Trigger aus, der das Löschen übernehmen soll. 
Die Doku muss noch angepasst werden:
 http://trac.wheregroup.com/PostNAS/wiki/SchrittfuerSchritt#L%C3%B6schenderinderTabelledeletevermerktenDatens%C3%A4tze


Die Tests waren noch nicht ganz erfolgreich. Siehe unten.

Nach dem Lauf kann (muss aber nicht) die Tabelle 'delete' wieder geleert werden.


> (2)
> Was muss ich tun, damit ich nur den aktuellen Stand bekomme? 
> Ein "historisierter" Bestand mit "geendeten" Objekten ist 
> nicht gewünscht. 


Die Mail vom 23.03.2012 habe ich gleich mit im Schema verbaut:

Varianten:

1.
Verbindet man im Schema den "delete_feature_trigger" mit "delete_feature_kill", dann sollen die alten Objekte gleich gelöscht werden.

2.
Verbindet man "delete_feature_trigger" dagegen mit "delete_feature_hist" dann bekommen die alten Objekte während der Konvertierung nur einen Eintrag im Feld "endet".

2a.
Wenn man "delete_feature_hist" verwendet, aber die alten Objekte nach einer Weile dann doch loswerden will, kann man 
  "SELECT alkis_delete_all_endet();"
     dazu verwenden.


TEST:

Variante 2/2a
 .. funktioniert mit meinen Daten NICHT bei 'replace'.
Die Zeile

sql := 'SELECT beginnt FROM ' || NEW.typename || ' WHERE identifier=''urn:adv:oid:' || NEW.replacedBy || '''';

 in "delete_feature_hist" sucht nach Identifier, der aus Konstante, gml_id und Zeitstempel besteht.
In meiner Datenbank bestehen die aber nur aus Konstante und gml_id, dahinter sind die 44 Byte mit Leerzeichen aufgefüllt.

Das war der Grund, warum ich das Feld 'identifier' aus allen Tabellen verbannt hatte.
'gml_id' haben wir schon und die Konstante davor kann man sich denken; also redundant, also sinnlos.
Durch den Patch bekommen alle Tabellen wieder den 'identifier'.

Als Folge sind die Replace-Objekte nach der Aktualisierung doppelt in der Datenbank.

Wo liegt der Fehler?

Beispiel:

FEHLER:    DENW17AL00002Qhe20080522T194608Z: 
Nachfolger DENW17AL00002Qhe20080522T194608Z nicht gefunden

Command: INSERT INTO "delete" ("typename", "featureid", "context", "safetoignore", "replacedby") 
VALUES ('AX_Strassenverkehr', 'DENW17AL00002Qhe20080522T194608Z', 'Replace', 'false', 'DENW17AL00002Qhe20080522T194608Z')  

In allen Fällen sind "featureid" und "replacedby" identisch.


Variante 1 - Der Test läuft noch. Bericht später.


Mit freundlichen Grüßen
Frank Jäger