Moin Frank,
biete gerne Unterstüzung zum Testen an, bin aber erst nächste Woche mit neuer Testumgebung am Start. Super Job...
Andreas
--
Dipl.-Geol. Andreas Borgardt
Landkreis Cuxhaven
06 - GIS-Service
Tel.: (0 47 21) 66 23 68
Mail: a.borgardt at landkreis-cuxhaven.de
Internet: www.landkreis-cuxhaven.de
--
> -----Original Message-----
> From: Jäger, Frank (KRZ) [mailto:F.Jaeger at KRZ.DE]
> Sent: Wednesday, September 10, 2014 3:45 PM
> To: Mailingliste (nas at lists.osgeo.org)
> Subject: [PostNAS] PotNAS 0.8 - Datenbank-Schema
>
> Hallo PostNAS-Freunde,
> Astrid hat den bisherigen Stand in den Branch 0.7 kopiert [1].
> Somit konnte ich meine Arbeiten der letzten zwei Wochen in
> den Trunk hochladen [2].
> Der SVN-Zweig "Version-0.8" wird noch gelöscht. Die nun
> aktuelle Version 0.8 wird im Trunk weiter geführt.
>
>
> *** Das PostgreSQL/PostGIS-Datenbank-Schema für PostNAS
> Version 0.8 ***
>
> Die wichtigste Änderung von Version 0.7 auf 0.8 betrifft die
> Beziehungen (Relationen) zwischen den Objekten. Bisher wurde
> dazu eine eigene Tabelle geführt, die "alkis_beziehungen".
> Diese war für fast alle Relationen zuständig, Ausnahmen davon
> waren reine Schlüsseltabellen z.B. die Verbindung von Lage
> (Hausnummer) zu Lagebezeichnung-Katalogeintrag
> (Straßentabelle). Das Zwischenschalten diese
> Beziehungen-Tabelle zwischen jeweils zwei Objekt-Tabellen
> machte die Views unnötig lang.
> Das Aktualisieren der Beziehungen-Tabelle beim Konvertieren
> von Differenzdaten aus dem NBA-Verfahren (Delete, Update,
> Replace) war kompliziert.
>
> Diese Tabelle "alkis_beziehungen" wird nun ersetzt durch
> Relationen-Spalten direkt in den Objekt-Tabellen. Diese
> Änderung ist so durchschlagend, dass alle Teile des Projektes
> gleichzeitig umgestellt werden müssen. Auswerteprogramme der
> Version 0.7 funktionieren nicht mit einer Datenbank der
> Version 0.8 und umgekehrt.
> Da also sowieso eine komplette Überarbeitung notwendig war,
> habe ich noch einige weitere Verbesserungen eingearbeitet.
> Die Schema-Version von NorBIT (QGIS) und der
> ALKIS-Objektartenkatalog wurden mit in diese Überarbeitung einbezogen.
>
> Rückschau zum Verständnis: Das ursprüngliche Schema wurde zu
> Beginn des Projektes PostNAS ganz pragmatisch erzeugt, indem
> man PostNAS (ogr2ogr) eine NAS-Datei in eine leere Datenbank
> konvertieren ließ. Wenn eine Zieltabelle noch nicht vorhanden
> ist, dann legt ogr2ogr diese Tabelle selbst an. Die
> Eingabe-Daten werden dazu analysiert.
> Beim NAS-Datenformat ist dies aber für den dauerhaften
> produktiven Einsatz keine brauchbare Lösung. Die NAS-Dateien
> können lokal unterschiedliche Inhalte haben, so dass dann
> jede von PostNAS selbst erzeugte Datenbank anders aussieht.
> Auch ist die Abgabe eines Gebietes mit dem NBA-Verfahren auf
> mehrere Dateien aufgeteilt. Die erste Datei (Randlage) würde
> die Datenstruktur festlegen. Auf dieser Basis kann man
> schlecht Programme machen.
> Daher wurde aus verschiedenen Konvertierungen und unter
> Einbeziehung der Dokumentation manuell und iterativ das
> aktuelle Datenbank-Schema 0.7 entwickelt. Kommentare und
> Indices wurden hinzugefügt.
>
> Aus dem ursprünglichen, von PostNAS selbst erzeugten Schema,
> waren bis zur Version 0.7 immer noch einige "Relikte" enthalten:
> 1. Die Sortierung nach Tabellen-Namen
> 2. Datenspalten, in denen nur numerische Inhalte gefunden
> wurden, wurden von PostNAS als Integer-Werte angelegt.
>
> - Zu 1. Sortierung:
> In der Version 0.7 war begonnen worden, die Tabellen
> innerhalb der Schema-SQL-Datei nach Objektbereich und
> Objektartengruppe zu ordnen. Dies war aber nicht fertig
> geworden. Ich habe dieses nun zu Ende geführt: Die Version
> 0.8 ist nun komplett nach dem ALKIS-Objektartenkatalog
> sortiert und gegliedert. Dies ist aber nur rein formal und
> hat keinen Einfluss auf die daraus generierte Datenbank.
> Beim Abgleich mit dem ALKIS-Objektartenkatalog wurden auch
> die Beschreibungen der Objektarten in die Kommentare der
> Tabellen übernommen.
> Der Kommentar zur Tabelle ist nun einheitlich so aufgebaut:
> '[Objektartengruppe]: ([N]REO|ZUSO) "Objektname" ist [Beschreibung]'.
> Die Kommentare zu Spalten sind (noch) nicht vollständig.
>
> - Zu 2. Numerische Spalten
> Ein Teil dieser Felder war in der Version von NorBIT von
> "Integer" nach "Character Varying" geändert worden. Um die
> beiden Versionen anzugleichen wurde das übernommen.
> Der Abgleich mit dem Objektartenkatalog zeigte weitere
> Felder, die dort als "Character" (Zeichenkette) dokumentiert
> sind, die aber im Datenbank-Schema bisher als Integer
> definiert sind. Diese Felder wurden ebenfalls geändert - wenn
> nicht jetzt, wann dann.
> Betroffen sind hauptsächlich die Schlüsselfelder von Land,
> Regierungsbezirk, Kreis, Gemeinde usw. in Tabellen zum Thema
> Flurstück, Flurstückshistorie und Lagebezeichnung.
> Integer macht da keinen Sinn, weil niemand aus einem
> Gemeindeschlüssel etwas berechnen will. Andererseits gehen im
> Integer-Format möglicherweise führende Nullen verloren, die
> in einem Character-String beibehalten werden.
> Auf die Views und Programme hatte diese Änderung erstaunlich
> wenig Auswirkungen. Da die Änderung in allen Tabellen
> gleichartig stattfindet ist ein JOIN weiterhin gültig, z.B.:
> SELECT ...
> FROM ax_lagebezeichnungmithausnummer l
> JOIN ax_gemeinde g ON l.kreis=g.kreis AND
> l.gemeinde=g.gemeinde ... ; Die Spalten "kreis" und
> "gemeinde" wurden auf beiden Seiten gleichartig von Integer
> auch Character geändert, daher ändert sich der View nicht.
>
> In den Programmen für Mapbender-Navigation und Buchauskunft
> kann der Gemeindeschlüssel per Konfiguration als
> Filterkriterium verwendet werden. Hier muss der
> Konfigurationswert nun in Hochkomma gesetzt werden: ...
> WHERE gemeinde = '99';
> Beachten sie dies, wenn sie Views verwenden, die
> Regionalschlüssel mit eigenen Werten filtern.
>
> Der Wegfall von "alkis_beziehungen" im Datenbank-Schema
> machte eine Überarbeitung fast aller Komponenten notwendig:
> Views, Navigation (Mapbender) und Buchauskunft.
> Die "Joins", die den Beziehungen der Objekte folgen, mussten
> angepasst werden. Aktueller Status: Stabil aber noch nicht
> komplett ausgetestet.
>
> Im Datenbank-Schema von Norbit waren *alle* ALKIS-Beziehungen
> als Spalten in den Objekttabellen angelegt worden, auch die
> sogenannte "inverse Relationsrichtung", also Rückverweise. In
> der Praxis werden diese Spalten von PostNAS (noch) nicht gefüllt.
> Ich habe diese leeren inversen Relationen und ihre Indices
> daher im Schema auskommentiert. Sie sind nicht benutzbar und
> verwirren daher. Wenn sie gefüllt wären, wären sie redundant.
>
> Einige der Relationen-Spalten sind Arrays, die gleich auf
> mehrere gml_id's einer anderen Tabelle verweisen. Dies ist
> nicht optimal.
> Die angepasste Version des Post-Prozessing (Nachverarbeitung
> nach dem Konvertieren) braucht für das Füllen der Tabelle
> "pp_flurstueck_nr" nun mehrere Minuten statt etwa 20 Sek. wie
> bisher. Die Ursache vermute ich darin, dass die Relation
> "ap_pto > dientZurDarstellungVon > ax_flurstueck" nun ein
> Array ist, dass mit der Function ANY() gejoint werden muss.
> Vielleicht ist das aber nur ein Problem meiner veralteten
> Datenbank-Version.
>
> Eine weitere "durchschlagende" Anpassung betrifft die Länge
> des Haupt-Schlüssels "gml_id" in allen Tabellen.
> In der bisherigen Version 0.7 war die Länge auf 16 Zeichen
> beschränkt. Diese 16 Zeichen enthalten die einheitliche
> Kennung des Objektes in einem Bestand ohne Historie ("es kann
> nur einen geben").
>
> In der Norbit-Version ist die Länge nicht limitiert. Bei
> Aktualisierungen entstehen so Objekte, die nach der
> Objekt-Kennung noch einen Zeitstempel der Entstehung
> enthalten. Diese längere Version der "gml_id" ist dann der
> Objektschlüssel. Für Sekundär-Bestände mit Historie mag dies
> nützlich sein. Vielleicht ist das sogar für den historischen
> Trigger unentbehrlich. In meinem Bestreben, zu einem
> einheitlichen Datenbank-Schema zu kommen, habe ich diese
> Anpassung also übernommen.
>
> Heute habe ich allerdings bemerkt, dass die Objekt-Verweise
> aus den Relationen-Spalten den angehängten Zeitstempel nicht
> enthalten. Die üblichen Equivalenzen können also nicht mehr
> verwendet werden.
> Beispiel: Die Relation "ax_flurstueck >IstGebucht>
> ax_buchungsstelle" lautete bisher in SQL: ".. ON
> flurstueck.istgebucht = ax_buchungsstelle.gml_id"
> Da "istgebucht" immer nur die kurze ID enthält, aber die
> gml_id nun auch verlängerte IDs enthalten kann, muss nun bei
> allen Relationen generell eine Substring-Function verwendet
> werden: ".. ON flurstueck.istgebucht =
> substring(ax_buchungsstelle.gml_id,1,16)".
> Diese Änderung an den Programmen habe ich begonnen, ist aber
> noch nicht vollständig.
>
> Um die Buchauskunft evtl. auch mal auf einer Datenbank "mit
> Historie" einsetzen zu können, habe ich nun vermehrt "endet
> IS NULL" in die Where-Klauseln der Abfragen eingebaut. Auch
> dies ist noch nicht durchgängig und bisher ungetestet. Ich
> habe keinen Datenbestand mit Historie.
>
> Wenn die beschriebenen Anpassungen durchgängig realisiert
> wurden, werden die Programme für Buchauskunft und Navigation
> flexibler sein. Sie sind dann in Datenbanken mit und ohne
> Historie und mit kurzen oder langen gml_id's einsetzbar.
> Die 0.7er-Versionen funktionierten nur mit 16-Zeichen-gml_id
> und ohne beendete Objekte.
>
> Den aktuellen Zwischen-Stand habe ich vor 2 Stunden hoch geladen: [3]
>
> Ich bitte um Unterstützung beim Testen der Version 0.8.
>
> Links:
>
> [1] http://trac.wheregroup.com/PostNAS/browser/branches/0.7
>
> [2] http://trac.wheregroup.com/PostNAS/browser/trunk
>
> [3] http://trac.wheregroup.com/PostNAS/changeset/330
>
>
> Mit freundlichen Grüßen
> Frank Jäger
>
> Kommunales Rechenzentrum
> Minden-Ravensberg/Lippe
> Tel.: 05261 / 252 - 185
>
> mailto:f.jaeger at krz.de
> http://www.krz.de/
>