NAS Konverter

Der NAS-Konverter ist ein lizenzpflichtiges Tool. Bitte sprechen Sie uns an! Der NAS-Konverter ist ein kommandozeilenbasiertes Programm und dient dem Import der NAS Dateien in die Datenbank.

 

Download NAS Konverter

Den NAS Konverter können Sie unter folgendem Link (32 bit) oder (64 bit) herunter laden.

Hilfe innerhalb des NAS Konverters

Sollten Sie während der Nutzung des NAS-Konverters Hilfe benötigen, dann können Sie den Befehl "help" eingeben und mit der ENTER-Taste bestätigen.

Es erscheint eine Liste mit allen verfügbaren Befehlen. Wenn Sie einen dieser Befehle eingeben und mit ENTER bestätigen, werden alle zugehörigen Parameter mit einer kurzen Erklärung ihrer Bedeutung angezeigt.

Technische Umsetzung

Die Generierung des Datenbankmodells und Teile des Programm-Codes erfolgt direkt aus dem XML-Schema. Dabei werden die Definitionsdateien für Listenwerte übernommen. Beim Einlesen der XML-Dateien in die generierte Tabellenstruktur erfolgt eine Validierung des XML-Schemas. Im Anschluss werden Datenbanksichten für den Zugriff der Anwendungen angelegt.

  • Für jede Zeile in jeder Tabelle wird ein Import-Tag erstellt, daher ergeben sich auch beim mehrfachen Konvertieren keine doppelten Datensätze.
  • Zudem weist die Anwendung einen hohen Datendurchsatz auf. Bspw. dauerte der Import von etwa 135.000 Flurstücken für den Landkreis Heidekreis nur circa 1 Stunde.
  • Die Geometrien können direkt auch im ESRI Shape gespeichert werden.
  • Die Verwendung als Batch ist möglich.
  • Zur Zeit erfolgt die Ausführung als CLI- (Command-Line Interface/ Kommandozeilen-) Anwendung.

Diese Herangehensweise stellt sicher, dass der Inhalt vollständig aus den XML-Daten in die Datenbank übertragen wird und dabei technisch valide ist. Zudem sind zukünftige Änderungen/Erweiterungen am Standard theoretisch relativ einfach zu übernehmen. Der NAS-Konverter kann dank seines Aufbaus auch für ähnliche Formate (wie ATKIS und XPlanung) relativ einfach genutzt werden.

NAS Import im Detail

Bitte ersetzen Sie die Parameter entsprechend. Die hier aufgeführten Bezeichnungen sind Platzhalter und sollen nur die Syntax der Abfragen verdeutlichen.

Beim ersten Aufruf des Konverters werden Sie zur Angabe der Adresse Ihres cardo-Servers gefragt. Dies dient dem Abruf der Lizenz-Informationen für die verfügbaren Import-Module (ALKIS, ATKIS, XPlan). Der Lizenzstatus kann jederzeit mit dem Befehl "LicState renew:true" aktualisiert werden. Dies ist z. B. dann nötig, wenn nur eine zeitlich beschränkte Testlizenz ausgestellt wurde.

Hinweise für XPlan - Import:
Die Option XPlan beim Connect wurde zu XPlan40 und XPlan41 umgeändert.  Im Options-Namen steckt die zu importierende Version. Xplan41 = Xplan 4.1.x, XPlan40 = Xplan 4.0.x.

Import in Einzelschritten (mit Historie - nur für ALKIS)

  1. connect to:"host=PostgreServerName dbname=dev_alkis port=5432 user=postgres" schema:ZielSchemaName mode:Alkis enableHistory:true  (Anlegen der Tabellen, Views, Schema...)
  2. LoadAlkisGml source:e:\Quelle\*.xml writers:8 autoindex:true postproc:true importTag:erst importTagTitle:"Erstdaten (Juli 2015)" (Einspielen der Daten)
  3. ImportAlkisLayers cardoSrv:http://IhreServer:Port user:CardoBenutzer pwd:IhrKennwort style:default epsgCode:epsg (Importiert Layer ins cardo) (Angabe von Nutzer und Passwort, wenn keine Windows Authentifizierung verwendet wird)

Wichtiger Hinweis: Schritt 3 sollte nur bei einem Import neuer Alkis NAS Daten durchgeführt werden oder wenn Sie durch die IDU dazu aufgefordert werden (im Zusammenhang mit einem Update). Wenn Sie bereits Änderungen an den Ebenen durchgeführt haben, sollte dieser Schritt NICHT durchgeführt werden, da sonst alle bestehenden Einstellungen überschrieben werden.

Der Konverter verarbeitet XML-Text-Dateien und Gz-komprimierte Einzeldateien.

Ab der Version 1.3.2.2 werden die Metadaten aus dem XML-Dateien ausgelesen. Dabei werden die Dateien sortiert nach der Portionskennung verarbeitet. Werden Differenzdaten (Update,Delete,Replace) erkannt, wird die Anzahl der Writer automatisch auf 1 reduziert. Ebenso wird auf die Vollständigkeit aller Dateien für die jeweilige Abgabe geachtet.

Das Anlegen/Aktualisieren des Datenbankschema wird durch den Konverter automatisch durchgeführt.

Während der Konvertierung wird eine Schätzung der Restdauer angezeigt. Die Ergebnisse werden in einer Logdatei {datum}-nas.html gespeichert.

Ergänzung zu LoadAlkisGml:

  • IngoreDiffErrors: bei Fehlern, meldet sich das Programm mit einer entsprechenden Meldung
  • allowIncompleteSource: (false), das System prüft, ob alle Dateien aus der Abgabe enthalten sind und bricht im Fehlerfall ab.
GeoInfoDok 7.1

Der NAS-Konverter ab Version 4.0 unterstützt jetzt auch NAS-Daten im GeoInfoDok 7.1 - Format. Für Nutzer des alten Formats (GeoInfoDok 6) ändert sich dabei nichts.

Nutzer, die Daten im neuen Format erhalten, müssen beim Connect einen neuen Modus angeben: ALKIS7 bzw. ATKIS7 (bisher nur ALKIS bzw. ATKIS).
Bitte beachten Sie: die neuen Modi erfordern ein Lizenz-Upgrade des NAS-Konverters.
Alle auf den Connect folgenden Befehle des Konverters sind unverändert. D.h. bspw. LoadAlkisGml, ImportAlkisLayers oder CreateAlkisHtmlReport funktionieren wie bisher.

Allerdings ist die Datenstruktur der neuen NAS-Daten nicht 100%ig kompatibel zur bisherigen Datenstruktur. D.h. Daten im GeoInfoDok 7.1 sind immer in ein neues Datenbank-Schema zu importieren. Beim ersten Connect mit den neuen Modus auf ein nicht vorhandenes Datenbank-Schema wird die neue Datenbankstruktur angelegt. Ein Connect auf ein vorhandenes Datenbankschema, welches in mit einem alten Modus erzeugt wurde, schlägt fehl.
Sie erhalten vom Vermessungsamt bei Differenzabgaben immer neue Erstdaten, wenn dort die GeoInfoDok 7.1 eingeführt wurde. Sodass Sie dann im neuen DB-Schema mit der neuen Abgabeserie beginnen können.

Die Tabellenstrukturen im Postgres aus den Objektarten im GeoInfoDok 6 und 7.1 Format sind sehr ähnlich. Dadurch kann auch die bisherige ALKISpro-Anwendung mit dem neuen Datenbankschema betrieben werden. Die größten Unterschiede gibt es bei den Bodenschätzungs-Objektarten.
Die durch den Konverter angelegten (materialisierten) Views sind entsprechend angepasst, wurden aber teilweise auch in der Struktur verändert.
Bitte beachten Sie: Sollten Sie eigene Views / Postprocessing-Scripte / Ebenen verwenden, die auf den Daten aus dem ALKIS/ATKIS-Datenbankschema aufbauen, prüfen Sie bitte, in wieweit diese noch kompatibel sind!

Im Zuge des neuen NAS-Datenformats wurden auch die Ebenen angepasst, die der NAS-Konverter mit dem Befehl ImportAlkisLayers im cardo anlegt. Speziell bei der Bodenschätzungen gab es einige Änderungen an der Ebenenstruktur. Zudem werden die ALKIS-Ebenen jetzt als IWAN7 - PostgreSL - Ebenen angelegt. Die ATKIS-Ebenen wurden noch nicht überarbeitet. Es ist aber nicht zwingend erforderlich, die Ebenen mit ImportAlkisLayers neu anzulegen / zu überschreiben.
Die neuen Ebenen verwenden die gleichen UIDs wie die bisherigen Ebenen (sofern diese 1:1 übertragbar waren - bei Bodenschätzung nur teilweise). D.h. wenn Sie den ImportAlkisLayers-Befehl aufrufen und Sie den alten DB-Schemanamen verwenden oder die Ebenen ohne Schemapräfix importieren, werden die bisherigen Ebenen im cardo überschrieben - es entstehen IWAN7 - Ebenen. Dabei werden allerdings alle etwaigen individuellen Anpassungen an den Ebenen überschrieben! Vorteil dieses Vorgehens ist im Gegenzug, dass die bisherigen Ebenen-Ids erhalten bleiben und die Ebenen den aktuellen IWAN7 - Ebenentyp verwenden.
Wir empfehlen: Vor Überschreibung der vorhandenen Ebenen sollten Sie über einen (zumindest temporären) neuen Schema-Namen und die Verwendung des Schema-Präfix beim ImportAlkisLayers-Befehl erstmal neue Ebenen erzeugen und einen Vergleich zwischen neuen und alten Ebenen durchzuführen.

Verwendung einer Historie für ALKIS-Daten

Erste Version 3 des NAS Konverter

Die Verwendung einer Historie für ALKIS Daten ist nun möglich.
Dazu kann beim "Connect" das neue Argument "enableHistory:true|false" übergeben werden.
Es wird dann ein weiteres Schema angelegt. Der Name entspricht dem Namen des Ziel-Schemas, erweitert um "_sys_hist".
In diesem Schema werden alle NAS Tabellen angelegt und einige spezielle Views, die eine Sitzungsvariable "alkispro.histDate" auswerten.
Zudem enthalten alles NAS Tabellen die Spalte "HIST_OP".

Hinweis:
Falls Sie die Historie der ALKIS-Daten verwenden wollen, müssen Sie darauf achten, dass Sie beim Vermessungsamt fortführungsfallbezogene NBA - Daten (Nutzerbezogene Bestandsdatenaktualisierung) mit Historie beziehen!
Dann sollten in den NAS-Daten auch keine Delete-Datensätze vorkommen. Bei NBA-Daten ohne Historie sind Deletes enthalten (siehe dazu auch die Hinweise zur Aktion "Delete"), die keinen vollständigen Historienaufbau zulassen.

Ablauf des Datenimports von NAS-Daten mit Historie

Die Einspielung von Erstdaten erfolgt wie gehabt.

Wenn Differenzdaten importiert werden, werden beim ersten mal alle Daten aus dem Basis-Schema in das History-Schema kopiert.Dieser Vorgang kann recht lange dauern. Zudem werden die GML_ID umgeschrieben und um den Zeitstempel "BeginntAm" für jedes Objekt erweitert, die Spalte Hist_op wird mit "INITIAL" belegt.
Beim folgenden Import werden die Daten entsprechend separat behandelt.
Der Importvorgang dauert damit deutlich länger. 

Folgende Schritte werden, ja nach Aktionsart, durchgeführt:

  • Aktion Insert
    Einfügen der Objekt-Daten in das Basisschema
    Einfügen der Objekt-Daten in das History Schema, Hist_Op auf "INSERT" setzen
    Anpassen der Gml_id des Objektes und der evtl. vorhandenen Beziehungen in der Tabelle NAS_REFERENCES
  • Aktion Replace
    Löschen des "Alten" Objektes aus dem Basis-Schema, Löschen aller Beziehungen in der Tabelle NAS_REFERENCES zu dem "Alten" Objekt
    Einfügen des aktualiserten Objektes in das Basis-Schema
    Aktualisieren des EndetAm des alten Eintrags auf BeginntAm des Neuen
    Einfügen der Objekt-Daten in das History Schema,  HIST_OP des neuen Objektes auf "REPLACE" setzen
    kopieren der Refernzen die das Alte Objekt zum Ziel haben in der Tabelle NAS_REFERENCES mit der neuen Gml-Id
    Einfügen der neuen Referenzen in NAS_REFERENCES mit der neuen Gml-Id
  • Aktion Update
    - Wenn EndetAm aktualisiert wird:
    Update der EndetAm Spalte für zum "Löschen" des Eintrags in dem Basis-Schema (und aller Referenzen)
    Update der EndetAm Spalte im Objekt in der History-Tabelle, aktualisieren des HIST_OP auf "ENDET"
    Andere aktualisierte Spalten werden z.Z. *nicht* ausgewertet
    - Wenn nicht EndetAm aktualisiert wird:
    Aktualisieren der Attribute im Basis-Schema
    Z.Z. keine Aktion im History-Schema
  • Aktion Delete
    Delete-Datensätze dürfen bei der Verwendung der Historie nicht auftreten!
    Ansonsten kann der Konverter das Datum des Untergangs eines Datensatzes nicht ermitteln und belegen. Damit blieben die Datensätze in der Historie ewig bestehen.

Hinweis:
Es gibt auch grundsätzlich die Möglichkeit rückwirkende Differenzdaten zu beziehen. Also ein Abgabeverfahren auszulösen, dessen Startzeitpunkt der in der Vergangenheit liegt. Und bei dem dann Differenzdaten bis zum aktuellen Zeitpunkt erstellt werden können..
Falls Sie eine solche Abgabe verwenden wollen, achten Sie darauf, dass die Erstdaten ohne jegliche Differenz als eigenständiger Stand exportiert werden. Und Sie dann eine oder mehrere Differenzstände dazu erhalten. (Der Zeitpunkt der Erstdatenabgabe muss dabei nach dem Zeitpunkt der ALKIS-Einführung liegen.)
Andernfalls, also wenn die Erstdaten zusammen mit den Differenzen in einem Stand enthalten sind, lassen sich diese Daten nicht mit dem NAS-Konverter importieren. Der Import startet zwar, wird dann aber immer langsamer, bis kein Fortschritt mehr erkennbar ist.

Erweiterungen

Ab der Version 3.1.0.15 wurde das Feature der Erweiterungen oder Extensions in den NAS-Konverter integriert.

Folgende Ziele wurden damit verfolgt:

  • Möglichkeit zum individuellen Postprozessieren der Daten, ja nach genutzter Erweiterung
  • direkte Integration des Postprozessings der Erweiterungen in das Standard-Postprozessing - kein extra Aufruf mehr
  • Vermeidung ständig neuer Konverter-Befehle bei Bereitstellung neuer Erweiterungen

Registrierung von Erweiterungen

Die Registrierung der Erweiterungen erfolgt immer für ein Datenschema. Als erstes muss also immer ein Connect durchgeführt werden.

Zur Registrierung einer Erweiterung ist der Befehl RegisterExtension mit dem Parameter extension und dahinter dem Namen der jeweiligen Extension aufzurufen.
Ist die Erweiterung schon registriert, erfolgt eine Warnung und es passiert nichts.

Bspw.: registerExtension extension:alkisgrenzgenauigkeit

Zum Entfernen einer Erweiterung ist analog der Befehl UnRegisterExtension mit der jeweiligen Extension als Parameter zu verwenden.
Ist eine Erweiterung nicht registriert, erfolgt auch hier eine Warnung ohne weitere Konsequenzen.

Zum Auflisten aller derzeit im Schema registrierten Erweiterungen dient der Befehl GetRegisteredExtensions ohne Parameter.

Mit der Registrierung einer Erweiterung wird diese für das allgemeine Postprocessing (also RefreshALKISMatViews bzw. postproc:true im LoadAlkisGml) vorgemerkt. In diesem Standard-Postprozessing werden am Ende die Postprocessings der Erweiterungen (also bspw. die Bestimmung der Bodenschätzungsgrenzen oder die Ermittlung der Genauigkeit der Flurstücksgrenzen) direkt aufgerufen, ohne extra Befehl. Man muss also nicht mehr daran denken, weitere Postprocessings zu starten.

Wichtiger Hinweis: Falls Sie via connect ein neues DB-Schema erstellen, müssen Sie auch die Extensions neu registrieren, da die Information über die registrierten Extensions im Schema gespeichert werden.

Hinzufügen von Ebenen der Erweiterungen

In der Regel bringen Erweiterungen auch zusätzliche cardo-Ebenen mit. Um diese im cardo anzulegen, gibt es den neuen Befehl ImportAlkisLayersForExtension.

Parameter:

  • cardoSrv: Url zum cardo
  • user: Login-Name, wenn leer, dann wird NTLM verwendet
  • pwd: Kennwort für user
  • useSchemaPrefix: Das Schema-Prefix in die Unique-Ids integrieren (true)
  • epsgCode: Der Epsg Code der Ebenen (wird als theProjection-Angabe für die Ebenen verwendet)
  • style: Der Ebenen-Stil, verwende Default oder IWAN7 oder ... (Default)

    Die möglichen Optionen für den Stil sind abhängig von der jeweiligen Erweiterung. Ein Default-Style ist immer vorhanden.

  • extension: Für welche Extension die Layer registriert bzw. aktualisiert werden sollen
    Gegenüber den anderen ImportLayers-Befehlen gibt es nur den zusätzlichen Parameter der Extension, für die die Layer angefügt bzw. geupdated werden sollen. Eine Extension muss vorher im Schema registriert werden, bevor die Ebenen dazu ins cardo importiert werden können.

Im Unterschied zum Postprocessing wurde das Anfügen und Updaten von Erweiterungs-Ebenen nicht in die Standard-Funktion ImportAlkisLayers für die Standard-Ebenen integriert. Damit hat der Nutzer die Möglichkeit, auch nur die Ebenen für eine bestimmte Erweiterung zu aktualisieren, ohne die Einstellungen aller Ebenen zu überschreiben.

Derzeit sind folgende Erweiterungen verfügbar:

Genauigkeit von Flurstücksgrenzen (ALKIS): "AlkisGrenzgenauigkeit"

Die Tabelle nas_tab_flurstueck_linien wird gefüllt. Diese beinhaltet Flurstücksgrenzen zwischen zwei Grenzpunkten mit der Eigenschaft 'typ', die die Genauigkeit der Linie wiederspiegelt. Relevant ist dabei immer der ungenauste Grenzpunkt.

  • Typ = 0: Der Grenzpunkt ist durch Katasternachweis, der nach dem 31. August 2003 bestimmt wurde, nachgewiesen.
  • Typ = 1: Der Grenzpunkt ist durch einen älteren Katasternachweis nachgewiesen.
  • Typ = 2: Für den Grenzpunkt liegen keine Vermessungskoordinaten vor.

Der Konverter bietet weiterhin die Möglichkeit, zwei zusätzliche Ebenen ins cardo zu importieren. Zum einen die Flurstücksgrenzen. Zum anderen die Längen dieser Grenzen als Text.
Linien und Texte werden je nach Genauigkeitstyp eingefärbt: (0 -> grün, 1 -> blau, 2 -> rot). Die Längen werden für die Typen 0 und 1 auf Zentimeter, für den Typ 2 auf Dezimeter gerundet.

Beispiel Aufruf der Extension:

Bitte beachten Sie, dass Sie die fettgedruckten  Angaben durch Ihre spez. Angaben ersetzen. 

ImportAlkisLayersForExtension  cardoSrv:"Url zum cardo" user:IhrUsername pwd:IhrKennwort extension:"AlkisGrenzgenauigkeit"

Bodenschätzung (ALKIS): "AlkisBodenschaetzung"

Eine ganze Reihe von zusätzlichen Ebenen mit den Daten der Bodenschätzung werden im cardo bereitgestellt. Enthalten sind Grablöcher mit Boden- oder Grünlandzahl, Muster- und Vergleichsstücke sowie die Bodenschätzungsergebnisse.
Eine Besonderheit ist, dass die Grenzen zwischen Klassen, Klassenabschnitten und Sonderflächen aus den Bodenschätzungsflächen der NAS-Daten im Zuge der Konvertierung ermittelt werden. Diese stehen dann auch als Ebene im cardo zur Verfügung.
Für eine bessere Qualität der Beschriftungen steht der Style 'IWAN7' zur Verfügung. Mit diesem werden die Text- und eine Reihe von Punkt-Ebenen mit der neuen IWAN-Version gezeichnet.

Beispiel Aufruf der Extension:

Bitte beachten Sie, dass Sie die fettgedruckten  Angaben durch Ihre spez. Angaben ersetzen. 

ImportAlkisLayersForExtension  cardoSrv:"Url zum cardo" user:IhrUsername pwd:IhrKennwort epsgCode:XXXXX  style:IWAN7 extension:"AlkisBodenschaetzung"

NAS-Import mit Bodenschätzung

Ab der Version 3.1.0 können Daten der Bodenschätung im cardo dargestellt werden.

Vorgehensweise:

1.Datenimport der Alkisdaten, wenn ein neuer Datenbenstand vorliegt.

  • - Beispiel für einen typischen NAS - Import

Wichtiger Hinweis: Wenn Sie bereits Daten importiert haben, welche bereits die Informationen zur Bodenschätzung enthalten, ist es  nicht notwendig, den selben Datenbestand noch einmal zu importieren, Sie können gleich mit dem Punkt 2 fortfahren.

2. Berechnung der Grenzlinien für die Bodenschätzung - Aufruf ohne Parameter

  • RefreshALKISBodenschaetzung

3. Erstellung der Ebenen zu Darstellung der Bodenschätzung

Dieser Befehl ist nur einmalig auszuführen. Die Ebenen werden im Root-Ordner des Admin-Baums ihres cardo-Systems angelegt  und können anschließend per Drag und Drop in den gewünschten Ordner verschoben werden.

  •  ImportAlkisBodenschaetzungLayers cardoSrv:"IhrServer" epsgCode:XXXXX user:IhrUsername pwd:IhrKennwort 

Wichtiger Hinweis: Zur richtigen Darstellung der Symbolik (Punktsymbole) wurde der TrueTypeFont ALKIS.ttf erweitert, dieser muss auf Ihrem Server aktualisiert werden. Damit dieser anschließend wieder vom IWAN verwendet wird, ist ein Neustart des Servers notwendig.
Bitte fordern Sie den TrueTypeFont unter der Adresse: Support@idu.de an.

Ab Version 3.1.0.12 steht für ImportAlkisBodenschaetzungLayers der zusätzliche Stil "IWAN7" zur Verfügung. Wird dieser verwendet, werden einige Ebenen als IWAN7 - Ebene umgesetzt. Dadurch wird eine verbesserte Darstellung erreicht (betrifft v.a. die Texte und deren Ausrichtung).
Achten Sie darauf, dass IWAN7 dann auch auf Ihrem cardo-Server installiert ist!

Wichtiger Hinweis: Nach dem Import der Daten zur Bodenschätzung ist es notwendig, den cardo - cache (Managementcenter / Systemstatus / Cache / cache leeren) zu leeren und anschließend den Administrativen Baum neu zu laden. Die neuen Ebenen sind anschließend im Rootverzeichnis des Administrativen Baums zu sehen.

Wichtiger Hinweis: Ab Version 3.1.0.15 ist die Bodenschätzung auch als Erweiterung registrierbar. Damit entfällt die Notwendigkeit des Aufrufs von RefreshALKISBodenschaetzung und die Funktion von ImportAlkisBodenschaetzungLayers kann über ImportAlkisLayersForExtension realsisert werden.
Es wird empfohlen, auf die Verwendung der Erweiterung umzustellen, da in einer späteren Version diese beiden Sonder-Komandos entfallen werden.
(Erweiterung registrieren)

 

Beispiel für einen typischen NAS-Import

Bei Import von Alkis Daten kann in Source auch ein Platzhalter für Verzeichnisse angegeben werden. Es kann in Verwendung mit Differnzdaten verwendet werden.
Das System arbeitet diese dann nach Datum ab, bereits importierte Diffs werden übersprungen.

Beispiel:

source:+D:\XX\klipphausen\diff*\*.xml => diff* = Alle Ordner, die mit Diff beginnen.".

Ein Typischer Import kann wie folgt aussehen:

  • Verbindung zur Datenbank herstellen

connect to:"host=dbServer dbname=dev_alkis port=5432 user=postgres" schema:MeinAlkis mode:Alkis enableHistory:true<br/>

  • Erstdaten importieren:

LoadAlkisGml source:D:\NAS\GemeindeX\ErstDaten\*.xml writers:8 validate:false postproc:false autoindex:true

  • Diff-Daten

LoadAlkisGml source:+D:\NAS\GemeindeX\diff_*\*.xml writers:8 ignoredifferrors:true importTag:Diff

Generelle Empfehlungen für den Import mit Historie

autoindex:true immer beim Import der Erstdaten machen
postProc:true nur beim letzen Import angeben
beim Einspielen von Differenz-Daten *nicht* autoIndex:true angeben

Vorgehen mit Differenzdaten

Vorgehensweise ist identisch mit der im Punkt NAS Import im Detail beschriebenen.

Führen Sie die Schritte 1 und 2 durch:

  1. connect to:"host=PostgreServerName dbname=dev_alkis port=5432 user=postgres" schema:ZielSchemaName mode:Alkis enableHistory:true (Anlegen der Tabellen, Views, Schema...)
  2. LoadAlkisGml source:e:\Quelle\*.xml writers:8 autoindex:true postproc:true (Einspielen der Daten)
  • allowIncompleteSource: false
  • ignoreDiffErrors: true
Erstellen von Protokollen

Es besteht die Möglichkeit mit dem Konverter (ab Version 3.0.0.33) -  Protokolle zu erstellen:

Mit den neuen Befehl CreateAlkisHtmlReport kann ein Bericht über den letzen ALKIS/ATKIS Importvorgang erstellt werden (versandt per Mail oder in Datei)

Befehl Protokoll als Datei erstellen:

CreateAlkisHtmlReport targets:file filename:Laufwerksbuchstabe:\Verzeichnisname\report.html

Beispiel:

CreateAlkisHtmlReport targets:file filename:D:\ALKIS\report.html

Befehl Protokoll als E-Mail versenden:

CreateAlkisHtmlReport targets:email servername:MeinServer  sender:Senderemailadresse to:Empfängeremailadresse

Beispiel:

CreateAlkisHtmlReport targets:email servername:leela sender:von@iduit.local to:zu@iduit.local

 

Durchführen von Konsistenzprüfungen

Der NAS-Konverter beinhaltet ab Version 3.2.8 eine Konsistenzprüfungs-Funkion.

Nach dem Import und der Aufbereitung von NAS-Daten kann somit der Datenbestand hinsichtlich verschiedener Kritierien auf Vollständigkeit und Fehlerfreiheit überprüft werden. Der Befehl dazu lautet "CreateAlkisHtmlConsistencyCheck". Im Ergenis der Prüfung werden die durchgeführten Tests aufgelistet. Fehlerhafte Datensätze werden mit einigen Details aufgelistet.

Fehler in den Tests können verschiedene Ursachen haben:

  • Fehlerhafte Datenbestände beim Vermessungsamt
  • Fehler beim Generieren der NAS-Daten - also Fehler im laufenden Abgabeverfahren
  • Fehler beim Einspielen der NAS-Daten (Differenzabgabe vergessen oder falsche Reihenfolge der Differenzen)
  • Fehler im NAS-Konverter
  • Fehler in den Tests der Konsistenzprüfung

Eine pauschale Ursache zu benennen ist schwierig. Abhängig von der Ursache sind dann auch unterschiedliche Maßnahmen zur Fehlerbehebung zu ergreifen:

  • Information des Vermessungsamts
  • Neueinspielung der Daten
  • Information an IDU

Unabhängig von der Ursache und von der Fehlerbehebung ist es sicherlich sinnvoll die direkten ALKIS-Anwender in Ihrer Institution über Fehler zu informieren. Somit können sie diese bei der Nutzung der Daten berücksichtigen.

Die zur Zeit implementierten Prüfungen sind Anregungen unserer Kunden. Sollten Sie weitere Ideen für Tests haben, können Sie sich gerne an uns wenden.

Wir haben die Tests nach besten Wissen implementiert. Dennoch können wir keine Fehler in den Tests ausschließen - das ALKIS-Objektmodell ist doch recht komplex. Sollten Ihnen Testergebnisse unplausibel oder gar fehlerhaft erscheinen, sind wir und die anderen Anwender des Konverters Ihnen für eine Rückmeldung sehr dankbar!

 

Verwendung

Der Befehl "CreateAlkisHtmlConsistencyCheck" ist angelehnt an den Befehl "CreateAlkisHtmlReport". Eine Ausgabe als HTML und ein Versand als EMail sind möglich. Abhängig vom target sind dann die weiteren Einstellungen zu übergeben.

Abweichende Argumente sind "topics" und "gebietsfilter".

Mit "topics" können die durchzuführenden Tests eingegrenzt werden (speziell die Geometrie-Tests dauern - abhängig von der Gebietsgröße - relativ lange - somit können diese ausgelassen werden). Jeder Test ist genau einem Topic, also einem Thema zugeordnet. Derzeit gibt es folgende Themen:

  • Katalog: ob zu hinterlegten Schlüsseln auch die Katalog-Einträge vorhanden sind
  • Grundbuch: Zusammenhänge zwischen Flurstück - Buchung - Eigentümer
  • Geometrie: Geometrien von Datensätzen

Es können mehrere Themen angegeben werden, diese sind dann mit Komma zu trennen. Mit der Option "Alle" werden alle Tests durchgeführt. Wird der Parameter weggelassen, werden ebenfalls alle Tests durchgeführt.

Über den "gebietsfilter" kann der zu testende Datenbestand über den Gemeindeschlüssel gefiltert werden. Das macht bspw. Sinn, wenn die Datenabgabe viele Daten aus Nachbargemeinden oder Nachbarkreisen umfasst, die für die eigene Nutzung uninterssant sind. Schlüssel wird via like verglichen. Dadurch können auch ganze Kreise als Filter verwendet werden.

Flurstücke werden dabei über die Gemarkungen der Gemeinde gefiltert, Buchungen über Buchungsblattbezirke. Bei Geometrieprüfungen werden die aggregierten Gemeindegeometrien, die dem Filter entsprechen, zu einer Gesamtgeometrie zusammengefast. Lücken in den Daten werden dann nur ausgegeben, wenn sie sich innerhalb dieses Gebiets befinden.

Befehl vollständiger Test als Datei erstellen:

CreateAlkisHtmlConsistencyCheck targets:file filename:Laufwerksbuchstabe:\Verzeichnisname\check.html

Beispiel:

CreateAlkisHtmlConsistencyCheck targets:file filename:D:\ALKIS\check.html

Befehl Geometrie-Tests als E-Mail versenden:

CreateAlkisHtmlReport targets:email servername:MeinServer sender:Senderemailadresse to:Empfängeremailadresse topics:topic

Beispiel:

CreateAlkisHtmlReport targets:email servername:leela sender:von@iduit.local to:zu@iduit.local topics:Geometrie

Befehl Katalog- und Grundbuchtests nur für das Gebiet der Gemeinde als Datei erstellen:

CreateAlkisHtmlConsistencyCheck targets:file filename:Laufwerksbuchstabe:\Verzeichnisname\check.html topics:topic gebietsfilter:gemeindeschluessel

Beispiel:

CreateAlkisHtmlConsistencyCheck targets:file filename:D:\ALKIS\check.html topics:Katalog,Grundbuch gebietsfilter:14987654

Export als shape

ALKIS-NAS-Daten können mit dem NAS: Konverter als shape Files ausgegeben werden. Der Befehl lautet: LoadAlkisGmlToShape.

 Argumente:

  • targetEpsgCode : Ziel-Epsg-Code
  • OneFilePerType : Pro Type eine Shape-Datei erstellen, sonst nur eine (Pro Geom-Type)
  • validate: Schema-Validierung beim Lesen (false)
  • TypeNameFilter: Liste der Type-Name, die beachtet (Standard) oder ausgeschlossen werden sollen, es kann % oder ? als Platzhalter verwendet werden (null), z.B. AX_GemeindeType.
  • source: Dateiquelle(n), vorangestelltes + durchsucht rekursiv.
  • target: Ziel-Pfad (muss vorhanden sein)
  • TypeNameFilterIsExclude: Die in TypeNameFilter sollte als Ausschluss betrachtet werden (false).

Beispiel:

LoadAlkisGmlToShape source:C:\*.xml targetEpsgCode:31469 OneFilePerType:true validate:true target:C:\shape
 

Hinweis: z.Z. werden nur die gml-Id und der Type-Name als Sachdatum exportiert.

 

Einstellungen für den Batch Betrieb

Der Batch-Betrieb erlaubt den Aufruf der Einzelbefehle und stellt auch einfache Konstrukte zu Parametrisierung bereit. Zudem sind einige neue Befehle hinzugekommen, mit denen Nach/Vorbearbeitungen durchgeführt werden können.
                         

  • DbCopy: Kopiert Tabellen(Daten) von einer Datenbank in eine andere (ink. Geometrie-Unterstützung), z.Z. Support für PostgreSql, Oracle, Access
  • CreateConnection: Stellt die Verbindung zu einer weiteren Datenbank her
  • SendReport: Versendet eine E-Mail mit dem HTML Protokoll (wird immer am Ende des Vorgangs ausgeführt)
  • LogMsg: Schreibt benutzerdefinierte Ausgaben in das Protokoll

Zeilen-Kommentare können mit # oder // oder REM eingefügt werden.

Hinweis: Alle mit einem # beginnenden Funktionen stehen nur in der Batch-Datei zur Verfügung.

Alle Argumente der Cmd-Line werden als Variablen zur Verfügung gestellt, immer in Großschreibung. In den Zeilen können diese mit %NAME% verwendet werden, es erfolgt eine einfach Zeichenketten-Ersetzung. Weitere Argumente können mit <i>#define name value</i> definiert werden.

Bedingte Ausführung:

  • #if|#ifn NAME Argument in Cmd-Zeile, welches als Bool ausgewertet wird (MACHES:true)
  • #ifdef|#ifndef NAME Argument in Cmd-Zeile, welches nur auf Vorhandensein geprüft wird

Die Vergleiche mit n im Namen sind die Verneinungsformen (ifndef =&gt; if not defined). Dabei gilt: Einzeiler mit folgender Anweisung oder ein Block, der mit #endif geschlossen werden muss.

Allen Datenbank Operationen können From/To übergeben werden, dabei handelt es sich um eine Verbindungszeichefolge zur Datenbank, oder um einen Kurz-Namen einer mittels CreateConnection erstellten Verbindung

Aufruf: Nas.exe op:batch fileName:"file.txt" pgdb:"host=server port=5432 dbname=dev_alkis user=postgres" PG_SCHEMA:test

Beispiel für die Ausführung als Batch

REM  Batch-Datei für den ALKIS Daten-Import

REM  Zeilen-Kommentare können mit # oder // oder REM eingefügt werden

REM  Alle mit einem # beginnenden Funktionen stehen nur in der Batch-Datei zur Verfügung.

REM

REM  Alle Argumente der Cmd-Line werden als Variablen zur Verfügung gestellt, immer in Großschreibung

REM  In den Zeilen können diese mit %NAME% verwendet werden, es erfolgt eine einfach Zeichenketten-Ersetzung

REM  Weitere Argument können mit #define <name> <value> definiert werden.

REM

REM  Bedingte Ausführung:

REM      #if/#ifn NAME  => Argument in Cmd-Zeile, welches als Bool ausgewertet wird( MACHES:true)

REM      #ifdef/#ifndef NAME    => Argument in Cmd-Zeile, welches nur auf Vorhandensein geprüft wird

REM  Die Vergleiche mit n im Namen sind die Verneinungsformen (ifndef => if not defined)

REM  Dabei gilt: Einzeiler mit folgender Anweisung, oder ein Block, der mit #endif geschlossen werden muss.

REM

REM  Allen-Db Operationen können From/To übergeben werden, dabei handelt es sich um eine  Verbindungszeichefolge zur Datenbank, oder um einen Kurz-Namen einer mittels  CreateConnection erstellten Verbindung

REM

REM  Aufruf:

REM

REM  IDU.NAS.Cli.exe op:batch fileName:"alkisimp.txt"

REM

REM

REM --------------------------------------------------------------------------------

REM  Primäre Verbindung zu Pg herstellen, Modus ALKIS

REM  und Import der NAS Daten (nur wenn IMP_ALKIS übergeben wurde)

REM --------------------------------------------------------------------------------

 

#define TMP_SCHEMA alkis_temp

#define TARGET_SCHEMA alkis2

 

REM erst einmal in ein temp. Schema importieren

connect to:"host=localhost dbname=db user=usr port=5432" schema:%TMP_SCHEMA% mode:alkis

REM dann die ALKIS daten importieren

loadalkisgml writers:8 postproc:true targetEpsg:25833 autoindex:true source:"%NAS_FOLDER%"

REM Sollten weitere Daten in diesem Zuge importiert werden, dann statt dessen:

REM (beachte Option Postproc)

REM loadalkisgml writers:8 postproc:false targetEpsg:25833 autoindex:true source:"%NAS_FOLDER1%"

REM loadalkisgml writers:8 postproc:true targetEpsg:25833 autoindex:true source:"%NAS_FOLDER2%"

 

REM Das alte Schema löschen ...         

sqlnt DROP SCHEMA IF EXISTS %TARGET_SCHEMA%_LAST CASCADE

REM  Das aktuelle schema in _LAST umbenennen

sqlnt CREATE SCHEMA IF NOT EXISTS %TARGET_SCHEMA%

sqlnt ALTER SCHEMA %TARGET_SCHEMA% rename to %TARGET_SCHEMA%_LAST

REM  Das temp. Schema zu dem aktuellen machen               

sqlnt ALTER SCHEMA %TMP_SCHEMA% rename to %TARGET_SCHEMA%

REM --------------------------------------------------------------------------------

REM  Und das Ergebnis per Mail versenden ...

REM --------------------------------------------------------------------------------

#ifndef NO_MAIL

SendReport to:"test@test.de" sender:"test@test.de" serverName:"servername"

#endif