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

Mi Aug 27 16:13:11 PDT 2014

Moin!

Ich weiß nicht obs bei der Umstellung der Datenbankabfragen was hilft, 
aber wir haben unsere Abfragen in kvwmap schon auf das neue 
Norbit-Schema umgestellt. Und damit meine ich nur das Grundschema, also 
die um die Relationenspalten erweiterten ax_... Tabellen, nicht die 
Ableitungstabellen. Die Abfragen sind hier zu finden: 
https://github.com/srahn/kvwmap/blob/develop/class/postgresql.php (nicht 
wundern, in der Datei gibt es noch eine Menge anderer Funktionen, 
einfach mal nach alkis suchen).
Da wir in kvwmap die ALKIS-Daten mit Vollhistorie vorhalten wollen, wird 
an jede Abfrage über die Funktion build_temporal_filter() ein zeitlicher 
Filter angehängt, wodurch die Abfrage entweder den aktuellen 
Datenbestand liefert (endet IS NULL) oder den Datenbestand zu einem 
beliebigen Zeitpunkt.

Das SQL-Skript sichten_wms.sql habe ich auch so angepasst, dass 
alkis_beziehungen nicht mehr verwendet wird. Das ist hier zu finden: 
http://www.kvwmap.de/index.php/Installation_von_PostNAS_und_Zugriff_mit_kvwmap

Gruß,
Stefan Rahn

GDI-Service
Joachim-Jungius-Str. 9
18059 Rostock
Tel: 0381 40344445
E-Mail: stefan.rahn at gdi-service.de
www.gdi-service.de

Am 27.08.2014 18:41, schrieb Jäger, Frank (KRZ):
> Moin!
> Nachdem PostNAS nun die Relationen direkt in den Objekt-Tabellen ablegt, wird die Tabelle "alkis_beziehungen" hyperliquid.
>
> Die Aktualisierung dieser Tabelle über Datenbank-Trigger hat sich als schwierig erwiesen, es hat lange gebraucht bis das halbwegs fehlerfrei lief (ganz sicher bin ich mir immer noch nicht).
> Außerdem waren SQL-Abfragen, die mehrere Tabellen verbinden, durch das Zwischenschalten dieser ausgelagerten Relation immer viel aufwändiger zu codieren; aus jedem JOIN wurden zwei.
>
> Somit denke ich, dass die neue Lösung über direkte Relationen zwischen den Tabellen, ein wichtiger Schritt ist.
>
> 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.
>
> 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
>
> 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.
>
> 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?
>
>
> Des Weiteren haben die ersten Tests mit dem überarbeiteten Schema gezeigt:
>
> Hin-Relationen werden gefüllt. Inverse Relationen hingegen nicht. Das ist auch nicht notwendig, weil das auch redundant wäre.
> Allerdings könnten alle leeren Spalten wieder entfernt werden, die ausschließlich für inverse Relationen vorgesehen sind (und ihre Indices).
>
> 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."
>
> 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.
>
> Im nächsten Schritt werde ich alle SQL-Scripte überarbeiten mit dem Ziel die "alkis_beziehungen" nicht mehr zu verwenden. Dann die PHP-Scripte für Auskunft usw.
>
> 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.
>
> PS.
> Bei den Arbeiten habe ich noch das Post-Processing verbessert, das die Straßennamen für das Mapfile aufbereitet.
> Einerseits gab es darin einen Fehler beim Zusammenführen von "Standard-Schreibweise" und "Schreibweise an dieser Stelle der Karte" (Grüße an Cuxhaven), anderseits tauchen in unseren Beständen nun auch Präsentationsobjekte auf, die auf einer Linie positioniert sind statt mit Punkt und Drehwinkel. Das hat Auswirkungen bis ins Mapfile (neuer Layer).
>
>
> 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

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.osgeo.org/pipermail/nas/attachments/20140828/e64a6648/attachment.html>