<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.E-MailFormatvorlage17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.E-MailFormatvorlage18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Hallo,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">> </span>Da wir unseren Kunden kein zweites Datenbanksystem „zumuten“ wollten …<o:p></o:p></p>
<p class="MsoNormal">Die Ablösung des SQL-Server durch PostgreSQL würde das gleiche erreichen ;-)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">> </span>Hat vielleicht schon einmal jemand anders den Import nach SQL Server probiert<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Das Problem mit den Umlauten bzw. der Kodierung erscheint mir lösbar. Danach kommen aber möglicherweise weitere aufwändige Probleme:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">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. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Mehrfach-Beziehungen (1:N) werden als Arrays abgelegt, im JOIN wird die Function „any()“ verwendet um auf ein Array-Element zu JOINen.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">SQLite kann das nicht, kann der SQL-Server das?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Ein Teil der Fortführungslogik findet nicht im PostNAS-Konverter (ogr2ogr) statt sondern ist durch Trigger in PostgreSQL gelöst.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Der NAS-Befehl INSERT wird von PostNAS direkt in die Objekt-Tabellen geschrieben. Bei NBA-Verfahren kommen aber auch DELETE und REPLACE vor.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Ist das auch mit SQL-Server lösbar?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">MfG<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">F. Jäger<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-language:DE">Von:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-language:DE"> NAS [mailto:nas-bounces@lists.osgeo.org]
<b>Im Auftrag von </b>Gunter Becker<br>
<b>Gesendet:</b> Mittwoch, 7. September 2016 10:22<br>
<b>An:</b> nas@lists.osgeo.org<br>
<b>Betreff:</b> [PostNAS Suite] NAS Import nach SQL Server<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hallo zusammen,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Ich bin für jeden Hinweis dankbar!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Danke schon einmal,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Gunter Becker<o:p></o:p></p>
<p class="MsoNormal">CSO GmbH<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>