[PostNAS Suite] Fragen zum norGIS ALKIS-Import

[Jäger, Frank (KRZ)]

Hallo,
wenn das NBA-Verfahren aus ibR-ALKIS mit der Option "NBA-Modellschwäche ausgleichen" ausgegeben wurde, dann kommen auch massenhaft Replace/Update zu genau den gleichen Objekten, die bereits in der Datenbank enthalten sind.

Wenn dann im Konverter die Option "Historie führen" AUSgeschaltet wurde, dann wurde beim Anlegen der Datenbank eine Trigger-Function verwendet, der damit nicht zurechtkommt ( delete_feature_kill() ).
Uns liegen Meldungen vor, dass Personen (Eigentümer) fälschlicherweise gelöscht wurden.

Nach ersten Tests ist es besser, die Option "Historie führen" EINzuschalten, dann wird intern die Trigger-Function "delete_feature_hist()" verwendet.
Ggf. sind dann nach der Konvertierung die historischen Objekte mit der Function "alkis_delete_all_endet()" zu entfernen wenn nicht in den Anwendungen konsequent auf "endet IS NULL" gefiltert wird.

Der Fall muss noch eingehend untersucht werden was aber einige Zeit dauern wird. Ziel ist es, dass auch die Trigger-Function "delete_feature_kill()" den Modus "NBA-Modellschwäche ausgleichen" verarbeiten kann.

Hat jemand ähnliche Erfahrungen gemacht?


MfG
Frank Jäger



> -----Ursprüngliche Nachricht-----
> Von: NAS [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Jäger, Frank
> (KRZ)
> Gesendet: Donnerstag, 4. Juli 2019 12:36
> An: 'nas at lists.osgeo.org'
> Betreff: Re: [PostNAS Suite] Fragen zum norGIS ALKIS-Import
> 
> Moin!
> 
> User Verdacht konzentriert sich auf eine neue Option im abgebenden ALKIS der
> Firma ibR.
> Für das betroffene NBA-Verfahren ist dort erstmalig die Option "NBA-
> Modellschwäche ausgleichen" eingeschaltet worden.
> 
> Kurzfassung der Erläuterungen dazu:
> 
> - Objekte, die sich im NBA-Abgabeintervall nicht geändert haben, sollen
> trotzdem abgegeben werden, wenn sich ein Objekt in der Relationskette des
> Filters über das Abgabeintervall qualifiziert.
> 
> - Durch die Nutzung des Parameters werden i.d.R. mehr Objekte
> zurückgeliefert.
> 
> - Die zusätzlich ausgegebenen Objekte werden immer mit <Replace> geliefert.
> Der Filter wird dabei immer ohne Zeitstempel ausgegeben. Aufnehmende
> Systeme sollten ein Replace auch akzeptieren, wenn das Objekt vorher noch
> nicht angeliefert wurde.
> 
> - Eine Objektversion kann mit gleichem Lebenszeitbeginn in unterschiedlichen
> Folgeabgaben auftauchen. Das aufnehmende System muss identische
> Versionen bei der Übernahme erkennen und ignorieren.
> 
> 
> Die Objekte aus den Logeinträgen wurden (Stichprobe) tatsächlich mit Replace
> geliefert.
> 
> "Das aufnehmende System muss identische Versionen  ... ignorieren"
>   Das ist mit PostNAS gegeben, allerdings hatte uns die Flut von zusätzlichen
> Logeinträgen zunächst ein wenig erschreckt.
> 
> 
> Beispiel zur "Modellschwäche":
> 
> Aus einem Katasterbezirk wird nur ein Teil gefiltert, z.B. ein Stadtgebiet.
> Zum Zeitpunkt der Erstabgabe ist ein Grundbuch nicht betroffen, weil kein
> Flurstück aus der Stadt darauf gebucht ist. Es wird nicht mit ausgeliefert.
> Später wir eine neue Buchung eingetragen, die ein Flurstück aus der Stadt mit
> dem Grundbuch verbindet.
> Bei der nächsten NBA-Aktualisierung wird die Buchung ausgeliefert - sie ist im
> Aktualisierungszeitraum geändert worden.
> Das Grundbuch wird nicht ausgeliefert denn es ist ja nicht geändert worden.
> Die Relation läuft ins Leere, denn das verknüpfte Grundbuch fehlt im
> Sekundärbestand.
> 
> Die neue Option "NBA-Modellschwäche ausgleichen" liefert dieses Grundbuch
> jetzt mit aus.
> Aber leider auch Tausende, die eigentlich nicht von der Modellschwäche
> betroffen waren.
> 
> MfG
> Frank
> 
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: NAS [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Anders,
> > Birte
> > (krz)
> > Gesendet: Dienstag, 2. Juli 2019 11:30
> > An: 'nas at lists.osgeo.org'
> > Betreff: [PostNAS Suite] Fragen zum norGIS ALKIS-Import
> >
> > Hallo zusammen,
> >
> > wir haben gestern mit dem norGIS ALKIS-Import 3.0-18 eine neue
> > Datenbank mit einer Erstabgabe gefüllt. Schon bei der danach
> > importierten ersten Fortführung kamen auffällig viele Fehlermeldungen,
> > die sich auf Unique- Constraints in Tabellen wie "ap_lto" und "ax_person"
> beziehen.
> >
> > Zum Beispiel:
> >
> > ERROR 1: FEHLER:  doppelter Schlüsselwert verletzt Unique-Constraint
> > »ap_lto_gml«|
> > FEHLER:  doppelter Schlüsselwert verletzt Unique-Constraint
> > »ap_lto_gml«|
> >  Command: INSERT INTO "ap_lto" ("wkb_geometry" , "gml_id", "anlass",
> > "beginnt", "sonstigesmodell", "zeigtaufexternes_art",
> > "zeigtaufexternes_uri", "art", "fontsperrung",
> > "horizontaleausrichtung", "skalierung", "vertikaleausrichtung",
> "dientzurdarstellungvon") VALUES ('..
> >
> > Müssen wir uns Sorgen machen?
> >
> >
> > Die Fehlermeldungen zur Tabelle "ap_lto" erschienen im
> > Protokollfenster des Importers, Fehlermeldungen zur Tabelle
> > "ax_person" und weiteren waren nur in der Tabelle "alkis_importlog" zu
> sehen.
> >
> >
> > Mit freundlichen Grüßen
> > Birte Anders
> >
> > Kommunales Rechenzentrum
> > Minden-Ravensberg/Lippe
> > Bismarckstr. 23
> > 32657 Lemgo
> >
> > Tel.:         05261 252-161
> > E-Mail:     b.anders at krz.de
> > <http://www.krz.de>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 2411 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20190722/479568ac/attachment.bin>