[PostNAS] alte Einträge in der alkis_beziehungen vorhanden

Brandt, Marvin Marvin.Brandt at kreis-unna.de
Di Feb 19 07:44:30 PST 2013


Hallo Herr Jäger,

vielen Dank erst einmal für ihre Hilfe.
Es ist genau wie von ihnen beschrieben. Wir wollen die Variante 2 benutzen. 
Baum Aufbau der Datenbank hat sich wohl damals ein Fehler eingeschlichen. Der Trigger war wirklich aus Versehen auf der Tabelle alkis_beziehungen angelegt.
Ich habe diese nun gelöscht und lade gerade einmal unsere Daten neu. Nach dem Import werde ich Tests durchführen und berichten, ob es daran lag.

Aber vielleicht können Sie mir noch kurz eine Frage beantworten. An welcher Stelle werden die Beziehungen aktualisiert, wenn im replace Datensatz in der NAS-Datei eine neue ID für die Verknüpfte Buchungsstelle eingetragen ist.

Also kurz gesagt, es gibt bereits ein Flurstück. Dieses wird durch NAS von einer Buchungsstelle auf eine andere Buchungsstelle zugeordnet. Die alte Buchungsstelle bleibt in der Datenbank noch bestehen, da noch weitere Flurstücke auf dieser gebucht sind. Die neue Buchungsstelle wurde vorher durch die selbe NAS-Datei angelegt. Nun muss ja die Beziehung zwischen Flurstück und Buchungsstelle aktualisiert werden. Quasi von Flurstück -> alte Buchungsstelle zu Flurstück -> neue Buchungsstelle. Beide haben die Buchungsart "istGebucht".
Die neue Verbindung wird nun durch ogr2ogr in die Datenbank eingetragen. Wird dabei die alte Verbindung überschrieben oder fügt ogr2ogr einen neuen Eintrag in die alkis_beziehungen ein?
Wenn dieser nicht überschrieben wird, wer kümmert sich um das Löschen des alten Eintrages? Macht dieses ebenfalls ogr2ogr oder wird dieses durch das Schema oder dem PostProcessing abgehandelt?

Vielleicht wird mir der Ablauf dann etwas klarer.

Mit freundlichen Grüßen
Im Auftrag

Marvin Brandt

Kreis Unna - Der Landrat
Zentrale Datenverarbeitung
DV-Verfahren 
Friedrich-Ebert-Straße 17
59425 Unna

Fon 0 23 03 / 27-14 16
Fax 0 23 03 / 27-28 96
marvin.brandt at kreis-unna.de
www.kreis-unna.de

-----Ursprüngliche Nachricht-----
Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Jäger, Frank (KRZ)
Gesendet: Dienstag, 19. Februar 2013 16:02
An: 'NAS Schnittstelle via ogr2ogr'
Betreff: Re: [PostNAS]alte Einträge in der alkis_beziehungen vorhanden

Hallo,
puh .... kompliziert!
Ich habe das Problem noch nicht komplett durchdrungen, aber ich habe einen Verdacht ....

Also, es gibt grundsätzlich zwei Arten, wie man einen Sekundärbestand fortführen kann.

1.) -hist: Abgelaufene Objekte werden "historisiert" indem sie ein Ende-Datum bekommen.

2.) -kill: Abgelaufene Objekte werden aus dem Sekundärbestand heraus gelöscht.


Meine Erfahrungen basieren ausschließlich auf Variante 2 (-kill!).
Die von mir gemachten Programme für Buchauskunft und Mapbender-Navigation versuchen *nicht*, alle historischen Objekte über zusätzliche Where-Klauseln im SQL heraus zu filtern (".. AND endet is NULL").
Diese Programme erwarten, dass der Sekundärbestand nur noch aktuelle Objekte enthält.
Wenn man diese Auskunft-Programm auf einem Sekundärbestand verwendet, der abgelaufene Objekte enthält (endet = zeitstempel), dann arbeiten sie falsch.
Wir brauchen diesen Sekundärbestand als Kartenhintergrund für Kommunale Anwendungen und als (nicht amtliche) Eigentümerauskunft.
Eine Objekt-Vollhistorie ("Womit war die Buchung letzten Donnerstag um 11 Uhr verknüpft?") brauchen wir nicht.
Die Flurstücks-Historie (Vorgänger-/Nachfolger-Flurstückskennzeichen) ist ausreichend. Diese wird in eigenen Tabellen geführt und ist somit unabhängig von der Vollhistorie der ALKIS-Objekte.

<spekulation>
Die Verwendung von Abgabeart 1000 deutet darauf hin, dass sie das auch möchten.
Wenn sie eine Historie im Sekundärbestand aufbauen wollten, würden sie wohl "Fortführungsfallbezogen mit Historie" als Abgabeart wählen. 
</spekulation>

Der erwähnte Trigger "insert_beziehung_trigger" befindet sich nun aber in der Datei "alkis-trigger-hist.sql" und nicht in "alkis-trigger-kill.sql", gehört also zur 1. Variante. Der dürfte also gar nicht zur Anwendung kommen.

Die Auswahl zwischen den beiden Varianten erfolgt (etwas versteckt) über einen Symlink "alkis-trigger.sql", der auf eine dieser beiden SQL-Dateien zeigt.
Im Datenbankschema "alkis_PostNAS_0.7_schema.sql" ist das dann über die Zeile 179 "\i alkis-trigger.sql" der Symlink und somit eine der beiden Varianten einbezogen. Lesen sie die Kommentarzeilen davor.

Im Script "datenbank_anlegen.sh" findet sich folgender Abschnitt:

if ! [ -e alkis-trigger.sql ]; then
	if ln -s alkis-trigger-kill.sql alkis-trigger.sql; then
		echo "** Symlink zu alkis-trigger-kill.sql (KEINE HISTORIE) angelegt"
	else
		echo "** alkis-trigger.sql FEHLT!"
		exit 1
	fi
fi


Wenn sie dieses Script verwenden und zuvor keinen Symlink gesetzt hatten, dann müsste automatisch die Kill-Variante gesetzt worden sein.


Kommen sie so der Lösung des Problems etwas näher?
Haben sie vielleicht den Symlink falsch gesetzt?

Mfg
F. Jäger


Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Brandt, Marvin
Gesendet: Montag, 18. Februar 2013 14:48
An: nas at lists.osgeo.org
Betreff: [PostNAS] alte Einträge in der alkis_beziehungen vorhanden

.
Die Beziehungen werden einmal über den Trigger insert_beziehung_trigger und einmal durch die pp_laden.sql gelöscht. Dort aber nur, wenn vom alten Eintrag und von neuen Eintrag die Felder beziehung_von, beziehung_zu und beziehungsart übereinstimmen. Dieses ist jedoch in diesem Fall nicht gegeben.
Hier stimmen lediglich die Felder beziehung_von und beziehungsart überein. Daher bleiben beide Einträge in der alkis_beziehungen vorhanden.
..
Mit freundlichen Grüßen
Im Auftrag
Marvin Brandt

_______________________________________________
NAS mailing list
NAS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/nas
Denken Sie an die Umwelt. Pruefen Sie deshalb bitte, 
ob der Ausdruck dieser E-Mail wirklich notwendig ist.
 
 
Diese E-Mail wurde beim Ausgang auf Viren geprueft. Wegen der 
potentiellen Gefahr auf den Uebertragungswegen wird zu einer 
Vireneingangskontrolle geraten. Eine Haftung für Virenfreiheit
wird ausgeschlossen.





More information about the NAS mailing list