[PostNAS] Relationen-Spalten, Vereinheitlichen der Entwicklungs-Zweige

[Jürgen E. Fischer]

Moin Frank,

On Wed, 27. Aug 2014 at 16:41:59 +0000, Jäger, Frank (KRZ) wrote:
> Allerdings war das nun lange Zeit der Stand der Dinge und somit basieren alle
> bisher entstandenen Views und Programme auf dieser Tabelle. Eine komplette
> Überarbeitung des gesamten ALKIS-PostNAS-Umfeldes wird also notwendig.

> Wenn man nun schon alles überarbeiten muss, dann kann man eine andere Aufgabe
> dabei gleich mit ins Auge fassen:
 
> Die Erweiterungen der Firma Norbit arbeiten oft anders, als die Teile des
> Projektes, die von mir und anderen im SVN bereit gestellt wurden. Um nicht
> für QGIS und Web-GIS zwei ganz verschiedene Datenbank-Versionen laden zu
> müssen, sollte das wieder zu einer gemeinsamen Lösung zusammen geführt
> werden.

Wir benutzen die Datenbanken doch schon für QGIS, webGIS und CAD.  Viele der
Änderungen sind genau darin begründet. ;)


> Skizze der Unterschiede:
 
> krz:
> - Konvertierung per Shellscript
> - Nur aktueller Bestand (Trigger-Function "delete_feature_kill", "ended IS NULL")
> - Postprozessing mit Shell/SQL speziell für Muster-Mapfile und PHP-Auskunft
> - Auskunft über Feature-Info und PHP-Script basiert auf dieser Struktur
> - Mapfile aus Muster basiert auf dieser Struktur
 
> Norbit:
> - Konvertierung über Python-Oberfläche
> - Historisierter Bestand (Trigger-Function "delete_feature_hist")
> - Postprozessing für QGIS und QGIS-Export-Mapfile (ganz andere Tabellen)
> - Auskunft über QGIS-Plugin
> - Mapfile aus QGIS-Export

Ein Shellskript gibt's bei uns doch auch.


> Um zu einer Annäherung zu kommen habe ich mal "unten angefangen": Beim Einbau
> der Relations-Spalten in das Datenbank-Schema habe ich einen kompletten
> Abgleich mit dem Norbit-Datenbank-Schema vorgenommen, das von der
> Python-Oberfläche von Norbit generiert wird.

Den umgekehrten Weg habe ich auch schon einige Male durchgeführt.  Dabei aber
natürlich auch einige Aktualisierungen weggelassen, die wir nicht benutzen -
z.B. die neue import-Tabelle und damit auch den kill-Trigger.

> Zwei Probleme, die mir daraus entwachsen sind, will ich hier erwähnen, damit
> man sieht, wie sehr hier mal wieder der ALKIS-Teufel im Detail steckt:
 
> 1. Die "gml_id" ist die Standard-Objektkennung bei Relationen. Sie wird auch
> als Parameter beim Aufruf der PHP-Scripte (Auskunft, Mapbender-Navigation)
> häufig benutzt. Dieses Feld war in allen Tabellen im krz-Schema bisher
> "character (16)", hatte also immer eine feste Länge.  Die Objekt-Kennung
> passte hinein, ein angehängter Zeitstempel bei Fortführungen wurde
> abgeschnitten. Wenn zu jedem Objekt nur die aktuelle Version vorhanden ist,
> braucht man das nicht.  Im Norbit-Schema ist dies Feld durchgängig formatiert
> als "character varying" ohne Längenbegrenzung.  Bei Aktualisierungen
> entstehen dann Objekte mit einer gml_id, die aus Kennung *und* Zeitstempel
> bestehen (lange ID).
 
> Die Verlängerung der gml_id auf "character varying" führte bei ersten Tests
> zu Fehlern bei der Aktualisierung. Objekte waren danach doppelt. Das liegt
> daran, dass der Trigger "delete_feature_kill" bisher davon ausgeht, dass die
> alten und neuen Versionen eines Objektes die gleichen 16stelligen IDs haben.
> Der Trigger muss überarbeitet werden, wenn zukünftig mehr als 16 Zeichen
> vorkommen. (Übrigens: Die kill-Function in den Norbit-DBs ist eine veraltete
> Version).
 
> 2. Das Feld "identifier" halte ich für entbehrlich. Es ist redundant zur
> "gml_id". Der ID-Teil in Stelle 1-16 der gml_id wiederholt sich ab Stelle 13
> des Identifiers. Davor steht immer nur die Zungenbrecher-Konstante
> "urn:adv:oid:".  Da das Feld "identifier" aber im Trigger
> "delete_feature_hist" verwendet wird - den wir nicht benutzen-  habe ich es
> nun zunächst drin gelassen.  Frage: Könnte man im Trigger nicht statt dessen
> die redundante gml_id verwenden?  Dann könnten wir "identifier" entsorgen?

Das hängt davon ab, ob sich Fortführungen auf das eine oder andere Feld
beziehen.  identifier und gml_id sind nicht immer identisch und Replace, Delete
auf Update beziehen sich auf einen der beiden Schlüssel.  Wenn ich mich recht
entsinne sind mir schon verschiedene Kombinationen untergekommen.  Die Güte der
Testdaten in denen das vorkam ist allerdings nicht klar.  Bei uns ist
Fortführung immer noch die Ausnahme.

 
> Viele dieser Relationen-Felder sind Arrays. Der JOIN muss die ANY-Funktion
> verwenden. Ich bin mir nicht sicher, ob das performant verabeitet und
> ordentlich indiziert wird.  Die postgresql-Doku sagt dazu
> (http://www.postgresql.org/docs/9.1/static/arrays.html): "Arrays are not
> sets; searching for specific array elements can be a sign of database
> misdesign.  Consider using a separate table with a row for each item that
> would be an array element.  This will be easier to search, and is likely to
> scale better for a large number of elements."

GIN-Indizes und der @< Operator sind meiner Erfahrung nach schneller als ANY
(zumindest wenn workmem nicht zu klein ist).

> Frage an die PostNAS-Entwickler: Kann man bei 1:N-Relationen nicht generell
> auf der Seite referenzieren, wo es kein Array ergibt, also performanter zu
> Joinen ist. Bisher scheint sich das eher an Invers/nicht-Invers zu
> entscheiden, wo die Relation abgelegt wird.

Der NAS-Treiber ist ziemlich "dumm".  Die Hauptarbeit macht der GML-Treiber und
der NAS-Treiber behandelt nur einige NAS-Spezialitäten, hat aber keinen
Überblick über das große Ganze, sondern arbeitet sich nur stumpf an dem ab, was
in den XML-Daten vorkommt.   Was für Elemente zu erwarten ist, weiß er nicht
und wozwischen Relationen existieren oder existieren könnten auch nicht.

Er stellt nur eine Layerliste anhand der vorkommenden Elemente zusammen und
anhand der vorkommenden Subelemente ein Attributeliste zu jedem Layer.
Zusätzlich zu den Elemente wird auch noch die Tabelle alkis_beziehungen für die
Links und delete für Delete/Replace/Update für die Fortführungen ergänzt.

Die Layerliste geht ogr2ogr dann layerweise ab und arbeitet die NAS-Datei dann
jeweils nochmal durch und filtert dann aber nach dem zum Layer gehörenden
Elementen und erzeugt Features aus den vorkommenden Attributen.  Kommt ein
Attribute mehrfach vor wird ein Array erzeugt.  Für alkis_beziehungen wird die
Datei dann nochmal durchlaufen nur diesmal nach xlink:href gefiltert und daraus
Features gebildet.  Für delete dann erneut mit Filter auf
Delete/Replace/Update.

Bei Durchlauf werden die entstehenden Features an den PostgreSQL-Treiber
übergeben, damit der sich in die Datenbank schreibt.   Von NAS weiß der
überhaupt nichts.  Es werden also nur versucht die Attribute des Features auf
das dazugehörige Feld der Datenbanktabelle abzubilden.  Attribute zu denen es
kein Feld gibt fallen unter den Tisch, zu lange Werte werden gekürzt und
Zeichenketten ggf. in Zahlen umgewandelt.

Langer Rede kurzer Sinn: große Logik gibt es nicht, was in den Feldern steht
ergibt sich aus den Daten.

Aber viel mehr Logik läßt sich da auch mE nicht reinbringen, wenn wir bei
ogr2ogr zum Import bleiben wollen.


> Das überarbeitete Datenbank-Script habe ich noch nicht veröffentlicht, weil
> das Gesamtsystem damit noch nicht fehlerfrei funktioniert.  Wer mit helfen
> möchte, die divergenten Versionen wieder zusammen zu bringen, kann gerne
> meinen aktuellen Zwischenstand bekommen.

Die zwischenzeitlichen Änderungen würden mich schon interessieren.


Jürgen

-- 
Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden             http://www.norbit.de
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20140827/bf1d6d39/attachment.pgp>