[NAS] Erfahrungen mit kreisweiter Datenbank

[Ralf Suhr]

Hallo Herr Jäger,

doppelte Einträge können Sie mit einem Datenbanktrigger verhindern. Damit gdal 
1.8.0 damit funktioniert muss der Schalter " --config OGR_PG_RETRIEVE_FID 
FALSE" gesetzt sein.

MfG
Ralf Suhr

Am Freitag 04 Februar 2011, 12:53:05 schrieb 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
> _______________________________________________
> NAS mailing list
> NAS at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/nas