[PostNAS] alte Einträge in der alkis_beziehungen vorhanden
Brandt, Marvin
Marvin.Brandt at kreis-unna.de
Mi Feb 20 06:31:47 PST 2013
Hallo zusammen,
ich habe nun noch einmal ein paar Tests durchgeführt. Leider funktioniert der Import der NAS Dateien immer noch nicht richtig. Ich habe nach der Aktualisierung noch wenige Fälle mit falschen Einträgen in der alkis_beziehungen.
Hier noch einmal ein Fall:
Das Flurstück mit der gml_id wird einer neuen Buchungsstelle über die NAS Datei zugeordnet. Vor der Aktualisierung stehen folgende Verknüpfungen in der alkis_beziehungen:
ogc_fid | beziehung_von | beziehungsart | beziehung_zu | dummy
-----------+------------------------------+-------------------+------------------------------+-------
761300 | DENWAL12000019aX | istGebucht | DENWAL1200001bvA |
Man siehst, dass vor der Aktualisierung nur eine Verknüpfung mit der beziehungsart "istGebucht" vorhanden ist.
Nun wird die Datenbank mit der folgenden NAS Datei aktualisiert:
<wfsext:Replace vendorId="AdV" safeToIgnore="false">
<AX_Flurstueck gml:id="DENWAL12000019aX20130219T094303Z">
<gml:identifier codeSpace="http://www.adv-online.de/">urn:adv:oid:DENWAL12000019aX</gml:identifier>
<lebenszeitintervall>
<AA_Lebenszeitintervall>
<beginnt>2013-02-19T09:43:03Z</beginnt>
</AA_Lebenszeitintervall>
</lebenszeitintervall>
<modellart>
<AA_Modellart>
<advStandardModell>DLKM</advStandardModell>
</AA_Modellart>
</modellart>
<anlass>060200</anlass>
<zeigtAufExternes>
<AA_Fachdatenverbindung>
<art>http://www.bezreg-koeln.nrw.de/extra/33alkis/art.htm#5200</art>
<fachdatenobjekt>
<AA_Fachdatenobjekt>
<name>2012/00001-11</name>
</AA_Fachdatenobjekt>
</fachdatenobjekt>
</AA_Fachdatenverbindung>
</zeigtAufExternes>
<position>
<gml:Surface gml:id="A1">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:Ring>
<gml:curveMember>
<gml:Curve gml:id="A2">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>408965.334 5704253.649 408967.844 5704269.444</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="A3">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>408967.844 5704269.444 408929.083 5704275.602</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="A4">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>408929.083 5704275.602 408934.069 5704258.616</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
<gml:curveMember>
<gml:Curve gml:id="A5">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>408934.069 5704258.616 408965.334 5704253.649</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
</gml:Ring>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</position>
<gemarkung>
<AX_Gemarkung_Schluessel>
<land>05</land>
<gemarkungsnummer>1353</gemarkungsnummer>
</AX_Gemarkung_Schluessel>
</gemarkung>
<flurstuecksnummer>
<AX_Flurstuecksnummer>
<zaehler>523</zaehler>
</AX_Flurstuecksnummer>
</flurstuecksnummer>
<flurstueckskennzeichen>05135300100523______</flurstueckskennzeichen>
<amtlicheFlaeche uom="urn:adv:uom:m2">567.00</amtlicheFlaeche>
<flurnummer>1</flurnummer>
<abweichenderRechtszustand>false</abweichenderRechtszustand>
<rechtsbehelfsverfahren>false</rechtsbehelfsverfahren>
<zeitpunktDerEntstehung>2012-01-01</zeitpunktDerEntstehung>
<gemeindezugehoerigkeit>
<AX_Gemeindekennzeichen>
<land>05</land>
<regierungsbezirk>9</regierungsbezirk>
<kreis>78</kreis>
<gemeinde>012</gemeinde>
</AX_Gemeindekennzeichen>
</gemeindezugehoerigkeit>
<istGebucht xlink:href="urn:adv:oid:DENWAL120000o3SM"/>
<zeigtAuf xlink:href="urn:adv:oid:DENWAL1200001b5c"/>
</AX_Flurstueck>
<ogc:Filter>
<ogc:FeatureId fid="DENWAL12000019aX20121002T132006Z" />
</ogc:Filter>
</wfsext:Replace>
<wfs:Insert>
<AX_Buchungsstelle gml:id="DENWAL120000o3SM">
<gml:identifier codeSpace="http://www.adv-online.de/">urn:adv:oid:DENWAL120000o3SM</gml:identifier>
<lebenszeitintervall>
<AA_Lebenszeitintervall>
<beginnt>2013-02-19T09:43:03Z</beginnt>
</AA_Lebenszeitintervall>
</lebenszeitintervall>
<modellart>
<AA_Modellart>
<advStandardModell>DLKM</advStandardModell>
</AA_Modellart>
</modellart>
<anlass>060200</anlass>
<buchungsart>1100</buchungsart>
<laufendeNummer>0132</laufendeNummer>
<istBestandteilVon xlink:href="urn:adv:oid:DENWAL1200001bzM"/>
</AX_Buchungsstelle>
</wfs:Insert>
Man sieht, dass dem Flurstück eine neue Buchungsstelle über "istGebucht" zugeordnet werden soll. Die gml_id der Buchungsstelle lautet DENWAL120000o3SM.
Nachdem ich die Datei verarbeitet habe und auch das PostProcessing komplett durchgelaufen ist, habe ich folgende Daten für das Flurstück in der alkis_beziehungen:
ogc_fid | beziehung_von | beziehungsart | beziehung_zu | dummy
------------+-----------------------------+-------------------+-------------------------------+-------
3621489 | DENWAL12000019aX | istGebucht | DENWAL120000o3SM |
761300 | DENWAL12000019aX | istGebucht | DENWAL1200001bvA |
Es sind nun zwei Verknüpfungen vorhanden. Einmal die alte verknüpfung zur DENWAL1200001bvA und die neue Verknüpfung zur DENWAL120000o3SM.
Irgendwo wir also die alte Verknüpfung nicht gelöscht. Dieses ist wirklich unpraktisch. Ich habe heraus bekommen, dass ein Flurstück wohl immer nur einer Buchungsstelle zugeordnet ist.
Daher habe ich mir folgenden SQL-Befehl gebaut und bekomme damit alle Flurstücke die mehr als eine Verknüpfung mit der Beziehungsart 'istGebucht' haben.
SELECT gml_id,anzahl FROM (SELECT f.*, (SELECT count(f2.gml_id) as anzahl FROM ax_flurstueck f2 JOIN alkis_beziehungen a1 ON f2.gml_id = a1.beziehung_von AND a1.beziehungsart = 'istGebucht' WHERE f2.gml_id = f.gml_id ) as anzahl FROM ax_flurstueck f) as sub WHERE sub.anzahl > 1
Vielleicht kann jemand mal prüfen, ob in seiner Datenbank auch solche Doppelungen vorhanden sind.
Ich wäre auch dankbar für andere Lösungsvorschläge. Derzeit habe ich mir einen Workaround gebaut, bei dem ich die Verknüpfung aus der alkis_beziehungen mit der kleineren ogc_fid nachträglich raus werfe. Jedoch denke ich, dass dieses nicht der optimalste Weg ist. Am besten wäre dort anzusetzen wo auch die neue Verknüpfung hinzugefügt wird.
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 17:48
An: 'NAS Schnittstelle via ogr2ogr'
Betreff: Re: [PostNAS]alte Einträge in der alkis_beziehungen vorhanden
Hallo,
wie eine Beziehung in die Datenbank kommt, habe ich noch nie analysiert. Aus dem Code des Konverters selbst habe ich mich bisher rausgehalten.
Aber zu Delete/Replace kann ich was sagen:
Alle aus NAS-Delete- und NAS-Replace-Anweisungen resultierenden SQL-Delete für die ALKIS-Objekte und ihre Beziehungen laufen über die Tabelle "delete" und ihre Trigger. Ich beschreibe die Variante -kill (siehe vorangegangene Mail).
NAS: DELETE
Ein NAS-Delete-Satz für ax_flurstueck wird von PostNAS per SQL in die Tabelle "delete" eingetragen.
Der Trigger löst dann die "FUNCTION delete_feature_kill()" aus und diese löscht sowohl die alte Version des Objektes als auch alle "alkis_beziehungen" von und zu der betroffenen gml_id.
Der Eintrag in der delete-Tabelle ist danach überflüssig, es sei denn man möchte dort nachsehen, ob eine bestimmte gml_id mal gelöscht worden ist.
Man kann die delete-Tabelle also nach der Konvertierung leeren. Allein der SQL-Insert in die delete-Tabelle ist wichtig, weil dies den Trigger auslöst.
Im Script "konv_batch.sh" wird am Ende die Anzahl der Zeilen ausgegeben.
echo 'SELECT COUNT(featureid) AS delete_zeilen FROM "delete";'
Vor Beginn des nächsten Laufes wird die Tabelle geleert:
TRUNCATE table "delete";
Zwischen zwei Läufen kann man nachsehen, was gelöscht worden ist.
NAS: REPLACE
Ein Replace-Satz für ax_flurstueck wird vom Konverter in ax_flurstück eingetragen *und* in die Tabelle "delete".
Der Trigger löst dann die gleiche "FUNCTION delete_feature_kill()" aus und die löscht die "alten Versionen" des Objektes.
Als Kriterium wird das "beginnt"-Datum verwendet. Das Objekt mit dem höchsten Datum in "beginnt" bleibt bestehen, alle mit gleicher gml_id aber älterem "beginnt" werden gelöscht.
Das habe ich mal als Hilfslösung so codiert, weil mir gerade nichts Besseres eingefallen ist. Wahrscheinlich wird das jetzt - wie alle Provisorien - jahrelang gute Dienste leisten.
Zuvor hatten wir ein paar Monate lang eine fehlerhafte Lösung. Es wurden in der Function alle Einträge mit der gml_id gelöscht in der irrigen Annahme, dass danach erst das neue Objekt eingefügt wird. Das neue Objekt ist aber schon da, wenn der Trigger durch Eintrag in "delete" ausgelöst wird. Es muss verschont werden. Diese Lösung geht davon aus, dass das Objekt mit dem spätesten beginn-Datum zur gml_id das einzig richtige ist.
Wenn die gml_id gleich geblieben ist (was offensichtlich immer der Fall ist) bleibt die Tabelle "alkis_beziehungen" beim Replace eines Objektes vom Trigger unberührt. Wenn sich die gml_id (replaced by ..) geändert hätte würde ein Fehler ausgeworfen, das habe ich noch nicht beobachtet.
In den Kommentaren im Trigger, nachzulesen in "alkis-functions.sql" ab Zeile 365, habe ich notiert, dass die Beziehungen dann doppelt eingetragen sind.
Die redundanten Zeilen werden derzeit nach der Konvertierung per SQL entfernt. Es wäre natürlich besser, wenn der Trigger sich bei jedem Objekt sofort darum kümmern würde. Dann wäre die Datenbank auch während der Konvertierung konsistent (Konverter und Benutzung parallel?).
Der Entwurf einer Lösung ist auch schon dort skizziert. Mir fehlte wohl die Zeit, dass auszutesten. Somit ist erst mal die Quick&Dirty-Lösung zum Einsatz gekommen.
Wer interessante Herausforderungen sucht, kann ja mal probieren, ob das ein gangbarer Lösungsweg wäre.
Mfg
Frank 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: Dienstag, 19. Februar 2013 16:45
An: NAS Schnittstelle via ogr2ogr
Betreff: Re: [PostNAS] alte Einträge in der alkis_beziehungen vorhanden
...
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.
...
Vielleicht wird mir der Ablauf dann etwas klarer.
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