[PostNAS] Antw: Re: Problem beim Update

[Karsten Bleßmann]

Hallo allerseits, 

erstmal allerbesten Dank für die Bereitstellung der Scripts und Tipps
... bin dabei das umzusetzen und informier dann über die Ergebnisse ...


aber vorneweg:
Die ALKIS-Daten sind welche mit Vollhistorie (es gibt wohl vier Arten,
bin noch am Recherchieren, welche genau wir hier haben, aber an sich
sollte das die "Voll-Variante" mit voller Historie sein).

Erstabgabe einspielen funktionierte, beim Einspielen des ersten Updates
dann:

- Einspielen mit *-kill ergab keine Fehler in der
postnas_err_alkis_DATENBANK.prot, aber die alten Flurstücke ware noch da
(auch kein Eintrag bei "endet")
- Einspielen mit *-hist ergab folgende  Fehler in der
postnas_err_alkis_DATENBANK.prot, und die alten Flurstücke waren auch
noch da

Command: INSERT INTO "delete" ("typename", "featureid", "context",
"safetoignore", "replacedby") VALUES ('AX_Flurstueck',
'DEBBAL510004ZqKQ20130531T174210Z', 'Replace', 'false',
'DEBBAL510004ZqKQ20130531T174210Z') RETURNING "ogc_fid"
ERROR 1: INSERT command for new feature failed.
ERROR:  DEBBAL510004ZqKh20130531T174210Z: Untergangsdatum von 0
Objekten statt nur einem auf 2013-06-05T17:05:00Z gesetzt - Abbruch

Vielleicht kommt das ja jemandem bekannt vor? ...

Von wegen alten/historischen Objekten: Man kann die doch daran
erkennen, dass die einen Eintrag bei "endet" haben ... oder? Bei *kill
sind die dann komplett raus ... oder?

Ach so: Ich hab die Brandenburger ALKIS-Demo-Daten mal durchlaufen
lassen (Erstabgabe & Folgeabgabe) ... da gabs leider gar keine Fehler
(eine der seltenen Gelegenheiten, das ich mich ärgere, wenns KEINE
Fehler gibt) ;-)

ansonsten bau ich mal die Scripts um und schau mal obs hilft.

Beste Dank & beste Grüße
KBL


>>> Jäger, Frank (KRZ)<F.Jaeger at KRZ.DE> schrieb am 30.01.2014 um 09:27
in Nachricht
<F2176AE4E9FFAF45BEA8D84DD6F4AF1A0C3E9173 at skrzmxmbx02>:
> Hallo Marvin,
> da haben wir etwas bessere Erfahrungen gemacht.
> 
> Für eine Gemeinde konvertieren wir ein NBA-Verfahren der Abgabeart
3100 
> (fallbezogen mit Historie) über die Kill-Variante. Mir sind dabei
keine 
> Probleme aufgefallen.
> 
> Einschränkend muss ich allerdings sagen, dass wir seit einigen
Monaten immer 
> wieder eine neue Erstabgabe verarbeiten und keine Aktualisierung.
Grund dafür 
> sind aber keine PostNAS-Probleme sondern Fehler in der abgebenden 
> ALKIS-Software.
> Davor haben wir eine Zeit lang dieses NBA-Verfahren auch wöchentlich

> aktualisiert. Ich kann mich an keine PostNAS-Probleme erinnern.
> 
> Es wird die Abgabeart 3100 ausgegeben weil ein zweiter
Sekundärbestand mit 
> Historie damit versorgt wird. Für unser Web-GIS ist das aber nicht
notwendig 
> bzw. sogar schädlich da die SQL-Abfragen in Navigation und Auskunft
nicht auf 
> "WHERE  .. ended IS NULL" filtern um die historischen Objekte
auszublenden. 
> Diese Anwendungen gehen von einer Datenbank aus, die nur aktuelle
Objekte 
> enthält.
> 
> MfG
> F. Jäger
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: nas-bounces at lists.osgeo.org
[mailto:nas-bounces at lists.osgeo.org] Im
>> Auftrag von Brandt, Marvin
>> Gesendet: Mittwoch, 29. Januar 2014 14:07
>> An: NAS Schnittstelle via ogr2ogr
>> Betreff: Re: [PostNAS] Problem beim Update
> ...
>> Hier ist es total wichtig, die Datenbank entsprechend der Abgabeart

> anzulegen.
>> 
>> Bei Abgabearten mit Vollhistorie ist immer die Variante *hist zu
wählen.
>> Hingeben ist bei der Abgabeart ohne Historie immer die Variante
*kill zu
>> wählen.
>> 
>> Wenn die NBA-Dateien nicht zum angelegtem Schema passen, dann läuft
alles
>> drunter und drüber. Man kann NBA-Daten mit Vollhistorie nicht in
eine
>> Datenbank mit *kill laden.
> ...
>> Marvin Brandt
>> 
>> Kreis Unna - Der Landrat