[PostNAS Suite] NAS Import nach SQL Server

[Jäger, Frank (KRZ)]

Hallo,

> Da wir unseren Kunden kein zweites Datenbanksystem "zumuten" wollten  ...
Die Ablösung des SQL-Server durch PostgreSQL würde das gleiche erreichen   ;-)

> Hat vielleicht schon einmal jemand anders den Import nach SQL Server probiert
Nein Sorry, ich habe das nicht probiert, da ich mit PostgreSQL/PostGIS zufrieden bin.  Ich möchte nur auf einen Reihe möglicher weiterer Probleme hinweisen.

Die PostNAS-Funktionalität ist im Laufe der Jahre an PostgreSQL/PostGIS gewachsen und erprobt. Das war von Anfang an das Projekt-Ziel, darum auch das "Post" im Projektnamen.
Das Problem mit den Umlauten bzw. der Kodierung erscheint mir lösbar. Danach kommen aber möglicherweise weitere aufwändige Probleme:

Ihre SQLite-Lösung setzt (soweit ich das beurteilen kann) noch auf der alten PostNAS-Struktur auf, die die Relationen zwischen den ALKIS-Objekten über die Tabelle "alkis_beziehungen" geregelt hat. Diese Tabelle wird noch immer gefüllt (eigentlich längst hyperliquid), die meisten Anwendungen verwenden inzwischen aber die Verweise in den Objekt-Tabellen (hat, istGebucht, zeigtAuf , beziehtSichAuf, verweistAuf, bestehtAus, istBestandteilVon, dientZurDarstellungVon, ...). Die JOIN-Anteile in den SQL-Befehlen haben sich dadurch halbiert.
Mehrfach-Beziehungen (1:N) werden als Arrays abgelegt, im JOIN wird die Function "any()" verwendet um auf ein Array-Element zu JOINen.
SQLite kann das nicht, kann der SQL-Server das?

Ein Teil der Fortführungslogik findet nicht im PostNAS-Konverter (ogr2ogr) statt sondern ist durch Trigger in PostgreSQL gelöst.
Der NAS-Befehl INSERT wird von PostNAS direkt in die Objekt-Tabellen geschrieben. Bei NBA-Verfahren kommen aber auch DELETE und REPLACE vor.
PostNAS schreibt die notwendigen Informationen in die "delete"-Tabelle wo sich dann PostgreSQL-Trigger um das Löschen bzw. Terminieren der Vorgänger-Objekte kümmern. Es hat damals eine Weile gebraucht, bis diese Trigger in allen Konstellationen sauber gearbeitet haben.
Ist das auch mit SQL-Server lösbar?

MfG
F. Jäger



Von: NAS [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Gunter Becker
Gesendet: Mittwoch, 7. September 2016 10:22
An: nas at lists.osgeo.org
Betreff: [PostNAS Suite] NAS Import nach SQL Server

Hallo zusammen,

als Dienstleister für Kommunen setzen wir aktuell den NAS-Konverter (via GDAL) zum Import der ALKIS Daten in unsere GIS-Anwendungen ein. Wir verwenden für unsere WebGIS-Anwendung als Datenbank-System ausschließlich den SQL Server, weswegen wir anfangs versucht haben die ALKIS-Daten via PostNAS in eben diesen zu importieren. Dies scheiterte in früheren GDAL Versionen gewöhnlich daran, dass Umlaute in den Zeichenketten durch "kryptische Zeichen" ersetzt wurden und die Zeichenketten dadurch länger wurden als per Definition erlaubt. Dies hatte dann schlussendlich ein Abschneiden der Zeichenketten beim Import zur Folge.

Da wir unseren Kunden kein zweites Datenbanksystem "zumuten" wollten, kam PostgreSQL bzw. PostGIS als DB nicht in Frage, weswegen wir auf SQLite ausgewichen sind. Hier erfolgte der Import einwandfrei. Auch die Performance von SQLite in unsere GIS-Anwendung lässt keine Wünsche übrig. Der große Nachteil von SQLite ist allerdings, dass das Weiterverarbeiten bzw. Aufbereiten der Daten durch fehlende Features wie Funktionen und Prozeduren sehr umständlich und extrem zeitaufwendig wird, was mit einem "kompletten" DB-System nicht der Fall sein würde.

Daher haben wir dem Import nach SQL Server ab der GDAL Version 2 erneut eine Chance gegeben. Allerdings erfolglos! Der oben beschriebene Importfehler ließ sich auf einen bekannten Bug in der GDAL Bibliothek zurückführen, der aber seit Version 2 gefixt ist.  Daher sind die Umlaute jetzt zwar richtig, dafür wird aber diesmal am Anfang einer jeden Zeichenkette ein "kryptisches" Zeichen angezeigt und am Ende der Zeichenkette fehlen dann jeweils 2 Zeichen. Dabei ist es unerheblich, ob es sich um eine Zeichenkette mit fester oder variabler Länge handelt.

Lange Rede (sorry) kurzer Sinn (kurze Frage): Hat vielleicht schon einmal jemand anders den Import nach SQL Server probiert und war erfolgreich. Oder hat vielleicht jemand noch eine Idee, wie man das Problem in den Griff bekommen kann? Evtl. eine andere Zeichenkodierung bei den NAS-Dateien verwenden oder etwaige zu setzende Optionen des ogr2ogr-Befehls, die für den Import noch eine Rolle spielen?

Ich bin für jeden Hinweis dankbar!

Danke schon einmal,

Gunter Becker
CSO GmbH


-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.osgeo.org/pipermail/nas/attachments/20160907/91c107e3/attachment-0001.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 4264 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20160907/91c107e3/attachment-0001.bin>