[PostNAS] Antworten zu Delete/Replace

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

Hallo,
mit PostNAS 0.6 (gdal 1.9) war das so.

Die Delete-Sätze wurden wie ein Daten-Layer behandelt und  in die für diesen Layer zuständige Tabelle 'delete' einfach nur eingefügt.
1. Lauf: nur Layer delete
Dann wurde diese Tabelle abgearbeitet um die Objekte in den anderen Tabellen zu löschen.

Im 2. Durchlauf von PostNAS wurden dann "alle Layer" (insert) konvertiert.

Mit Einführung der Trigger sollte sich die doppelte Konvertierung eigentlich erledigt haben.

Sonst hätte man z.B. auch das Problem, dass im 2. Lauf auch wieder die Trigger ausgeführt werden, weil der "delete-Layer" auch in "alle Layer" enthalten ist.

Replace wurde mit PostNAS 0.6 noch nicht sauber verarbeitet, oder?

Es wäre einfacher wenn ein replace erst in die Delete-Tabelle einfügen würde (-> Trigger) und dann in die Layer-Tabelle, offensichtlich ist es aber umgekehrt.


PS
Die erste Gemeinde ist konvertiert: Die zuvor fehlenden Flurstücke sind nun da, ABER  ...

Alle Beziehungen zu replacten Objekten sind nun doppelt.
Bei der Buchauskunft wird z.B. 2mal das Grundbuch zum Flurstück angezeigt.

Also muss der Trigger auch noch alle redundanten Sätze in alkis_beziehungen bereinigen. Die Sätze unterscheiden sich nur durch das serial-Feld ogc_fid.

Frank

-----Ursprüngliche Nachricht-----
Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Astrid Emde
Gesendet: Montag, 29. Oktober 2012 10:58
An: nas at lists.osgeo.org
Betreff: Re: [PostNAS] Antworten zu Delete/Replace

Hallo Frank,

das NBA Verfahren war ja so gedacht, dass wir in mehreren Schritten vorgehen

1.) erst der Layer Delete geladen wird (Laden der Lösch- und
Replacedatensätze)
2.) dann werden die zu löschenden Datensätze gelöscht über den Trigger
3.) dann wird der Fortführungsdatensatz nochmals geladen und die Replacedatensätze dabei wieder angelegt

Siehe auch :
http://trac.wheregroup.com/PostNAS/wiki/SchrittfuerSchritt

Oder hatte ich hier etwas falsch verstanden?

Schönen Gruß

Astrid

Am 29.10.2012 10:30, schrieb "Jäger, Frank (KRZ)":
> Moin!
>
>> Hat sich eigentlich mal jemand die Trigger angeschaut?
> Meine Frage vom Mai darf ich mir jetzt selbst mit "Nein" beantworten.
>
> Wir haben seit Monaten Probleme nach Aktualisierungen der NBA-Sekundärbestände. Nach einer NBA-Erstabgabe sieht das Kartenbild zunächst vollständig aus. Nach Aktualisierung mit Differenzdaten sind dann die Flurstücke nicht mehr flächendeckend, Grundbücher haben in der Auskunft keine Eigentümer mehr usw.
> Ich habe nun heraus gefunden, dass es an dem Trigger im Datenbankschema [1] liegt, der die "replace"-Sätze verarbeitet.
>
> CREATE .. FUNCTION delete_feature_kill() ..
> ..
>         ELSE
>                 -- replace
>                 query := 'DELETE FROM ' || NEW.typename || ' WHERE gml_id = ''' || gml_id || '''';
>                 EXECUTE query;
>                 -- alkis_beziehungen bleibt so
>         END IF;
>
> Es wird vom Konverter zunächst das neue Objekt eingefügt, dann erst der replace-Satz in die delete-Tabelle, der den Trigger auslöst.
> Zu dem Zeitpunkt stehen also altes und neues Objekt in der Objekt-Tabelle und beide haben dummerweise die gleiche "gml_id".
>
> Da über die "gml_id" das SQL delete qualifiziert wird, erwischt es auch den neuen Satz. Somit hat der NAS "replace" die Wirkung vom NAS "delete".
>
> Ich hatte die ganze Zeit vermutet, das wäre ein lokales Problem, denn niemand anderes hat von ähnlichen Problemen berichtet. 
> Wenn das Schema auf dem Trunk benutzt wurde, müssen aber eigentlich alle das gleiche Problem haben. Warum hat niemand etwas gemerkt?
>
> Der Trick ist nun, in dem Trigger den Datensatz zum alten Objekt zu löschen aber den neuen Datensatz drin zu lassen.
> Ich denke, ich habe eine Lösung gefunden, aber nicht sehr elegant: Das maximale "beginnt" zu einer gml_id wird zuvor ermittelt und beim SQL delete verschont. Hätte man diese Info in der delete-Tabelle wäre es schneller und sicherer.
>
> Bevor ich eine neue Version hoch lade, werde ich erst mal ein paar Gemeinden konvertieren und die Ergebnisse prüfen.
>
>
> Frank
>
> [1] 
> http://trac.wheregroup.com/PostNAS/browser/trunk/data/konvert/postnas_
> 0.7/alkis_PostNAS_0.7_schema.sql
>
>
> -----Ursprüngliche Nachricht-----
> Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] 
> Im Auftrag von Frank
> Gesendet: Mittwoch, 9. Mai 2012 07:51
> An: nas at lists.osgeo.org
> Betreff: Re: [PostNAS] RE: Antworten zu Delete/Replace
>
> Moin!
>
> Hat sich eigentlich mal jemand die Trigger angeschaut?
>
> Ich hatte den gdal-Patch und die Info aus einer Mail mit dem alten Schema zusammen gefügt und das ganze ins PostNAS-SVN gestellt.
>
> Ich habe aber noch nie mit PostgreSQL-Triggern und -Functions gearbeitet. Es könnte sein, dass ich dabei etwas Fundamentales falsch gemacht habe.
>
> Jedenfalls findet der Trigger nicht die zu löschenden alten Objekte.
> (ausführliche Beschreibung in meiner Mail vom 25.04.)
>
> Funktioniert das bei euch, oder nicht?
>
>
> Am 25.04.2012 13:55, schrieb Armin Retterath:
>> Hallo Frank,
>>
>> werde den Patch auch in den nächsten Tagen bei den ATKIS Daten aus RP 
>> ausprobieren. Gebe Bescheid wenn ich was herausbekomme.
>>
>> Gruss
>> Armin
>>
> ...
>>>> -----Original Message-----
>>>> From: nas-bounces at lists.osgeo.org
>>>> Sent: Monday, April 23, 2012 1:50 PM
>>>> Subject: [PostNAS] Fragen zu Delete/Replace
> ...
>>> Die Tests waren noch nicht ganz erfolgreich. Siehe unten.
> ...
>>> TEST:
>>> Variante 2/2a
>>>   .. funktioniert mit meinen Daten NICHT bei 'replace'.
> ...
>


-- 

Mit freundlichen Grüßen

Astrid Emde

********************************************
Where2B Konferenz 2012
13. Dezember 2012 in Bonn
www.where2b-conference.com
********************************************

 Astrid Emde
 WhereGroup GmbH & Co.KG
 Eifelstraße 7
 53119 Bonn
 Germany

 Fon: +49(0)228 90 90 38 - 19
 Fax: +49(0)228 90 90 38 - 11

 astrid.emde at wheregroup.com
 www.wheregroup.com

 Folgen Sie der WhereGroup auf twitter: http://twitter.com/WhereGroup_com

Amtsgericht Bonn, HRA 6788
-------------------------------
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Olaf Knopp, Peter Stamm
-------------------------------
 pgp-public key:
 http://pgp.mit.edu:11371/pks/lookup?search=0x06DA52D72D515284
  Signierte und/oder verschlüsselte Nachrichten sind sehr willkommen
  Signed and/or encrypted mail is highly appreciated

_______________________________________________
NAS mailing list
NAS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/nas