[NAS] Erfahrungen mit kreisweiter Datenbank

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

Moin!

(english short-version at bottom)

Bisher hatte ich mit PostNAS die RLP-Musterdaten geladen und Daten aus NBAs, die jeweils nur für ein Stadtgebiet eingerichtet wurden (abgebende Software von AED/ESRI). Auf der Basis dieser Datenbanken hatte ich die "Auskunft" und die "Navigation" entwickelt. 

Nun habe ich Daten aus einem NBA für ein ganzes Kreisgebiet in eine Datenbank geladen, die abgebende Software stammte diesmal von ibR.

Zunächst war bei der anfallenden Datenmenge die Schmerzgrenze erreicht, wo man NAS noch unkomprimiert lagern kann.
Ich habe die Daten nun gezippt abgelegt und die Shellscripte zur Verarbeitung angepasst.

Ich bin mal davon ausgegangen, dass man die NAS-Daten nicht "pipen" kann ( unzip | ogr2ogr ), also von stdout des unzip direkt an stdin von ogr2ogr übergeben.
Es wird ja im Ordner der *.xml eine gleichnamige *.gfs angelegt. Dazu müssen die NAS-Daten wirklich als Datei verortet sein. Also lasse ich die Daten in einem Temp-Ordner auspacken.
Das birgt die Gefahr, das parallelle Prozesse darin ihre Daten durcheinander werfen. Wenn jemand andere Ideen hat ..... 

Dann habe ich versehentlich mal eine Handvoll NAS-Dateien noch einmal konvertiert. PostNAS hat sich als "geduldig" erwiesen und die Objekte, die alle schon in der Datenbank waren, noch ein zweites Mal "fehlerfrei" eingetragen.
Erst beim Zusammenfassen der Nutzungsarten für die Buchauskunft hat es gekracht.
So etwas müsste eigentlich danbanktechnisch unterbunden werden, sonst bemerkt man den Fehler nicht und kommt zu falschen Flächenbilanzen.

Das Problem ist, dass die "gml_id" eigentlich in ALKIS 'für alles und jedes' ein eindeutiges Kennzeichen ist, dies Feld in der Datenbank aber mehrfach vorkommen darf.
Als Primary Key wird statt dessen das serial "ogc_fid" erfunden, dass in den NAS-Daten gar nicht vorkommt.

Das sollte im Datenbankschema angepasst werden, z.B.: 

  CREATE UNIQUE INDEX ax_besondereflurstuecksgrenze_gml 
                   ON ax_besondereflurstuecksgrenze USING btree (gml_id);

Frage: Kann es sein, dass der Konverter bei Fortführungen (Aktualisierungen) Objekte (temporär) doppelt braucht?

Um den Fehler auszubügeln, wollte ich dann die doppelten Einträge wieder entfernen.
Mit der Logik "wenn ein gml_id mehrfach vorkommt, dann davon nur die letzte ogc_fid behalten" habe ich z.B. folgendes SQL abgeschickt:

DELETE 
  FROM ax_besondereflurstuecksgrenze AS dublette
WHERE EXISTS
   (SELECT solitaer.gml_id 
      FROM ax_besondereflurstuecksgrenze AS solitaer
     WHERE solitaer.gml_id  = dublette.gml_id 
       AND dublette.ogc_fid > solitaer.ogc_fid);

Bei kleineren Tabellen konnte das noch ausgeführt werden, aber bei Tabellen mit mehren hundertausend Zeilen ist der Server sehr lange seeeehr beschäftigt, solange noch kein Index auf gml_id liegt.
Der Index ist bisher nur dort vorhanden, wo in der Auskunft JOINs verwendet werden, wo also Einträge von "alkis_beziehungen" auf eine Tabelle verweisen.

Ich meine nun, jede Tabelle sollte einen Index auf gml_id haben!
Evtl. taugt das sogar als PrimaryKey wodurch ocg_fid überflüssig würde. Aber das greift dann wohl doch zu tief in die ogr-Logik ein.

Um nun die Kreis-Datenbank auch für einzelne Städte verwenden zu können müssen die Filter in Auskunft und Navigation noch verbessert werden.

Alle von mir angepassten Dateien stelle ich im svn des Projektes zur Verfügung.
http://trac.wheregroup.com/PostNAS/browser


@Frank W.
Hallo,

Can ogr2ogr read zipped NAS(XML)-Files?

If a NAS-file is konverted twice into the same Database, then PostNAS does this "without error".
But ...
 the column "gml_id" is a wold-wide-Unique-Key for every object in ALKIS.
Maybe this is also a great (UNIQUE) Primary Key for every table, and a serial becomes obsolete.

I try to change the database:   CREATE UNIQUE INDEX ... (gml_id);




Mit freundlichen Grüßen
Frank Jäger

Kommunales Rechenzentrum
Minden-Ravensberg/Lippe