Den NAS Konverter können Sie unter folgendem Link (32 bit) oder (64 bit) herunter laden.
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.
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.
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.
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.
connect to:"host=PostgreServerName dbname=dev_alkis port=5432 user=postgres" schema:ZielSchemaName mode:Alkis enableHistory:true (Anlegen der Tabellen, Views, Schema...)
LoadAlkisGml source:e:\Quelle\*.xml writers:8 autoindex:true postproc:true importTag:erst importTagTitle:"Erstdaten (Juli 2015)" (Einspielen der Daten)
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.
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.
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.
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:
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.
Ab der Version 3.1.0.15 wurde das Feature der Erweiterungen oder Extensions in den NAS-Konverter integriert.
Folgende Ziele wurden damit verfolgt:
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.
In der Regel bringen Erweiterungen auch zusätzliche cardo-Ebenen mit. Um diese im cardo anzulegen, gibt es den neuen Befehl ImportAlkisLayersForExtension.
Parameter:
Die möglichen Optionen für den Stil sind abhängig von der jeweiligen Erweiterung. Ein Default-Style ist immer vorhanden.
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.
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.
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"
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"
Ab der Version 3.1.0 können Daten der Bodenschätung im cardo dargestellt werden.
1.Datenimport der Alkisdaten, wenn ein neuer Datenbenstand vorliegt.
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
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.
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)
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.".
connect to:"host=dbServer dbname=dev_alkis port=5432 user=postgres" schema:MeinAlkis mode:Alkis enableHistory:true<br/>
LoadAlkisGml source:D:\NAS\GemeindeX\ErstDaten\*.xml writers:8 validate:false postproc:false autoindex:true
LoadAlkisGml source:+D:\NAS\GemeindeX\diff_*\*.xml writers:8 ignoredifferrors:true importTag:Diff
autoindex:true immer beim Import der Erstdaten machen
postProc:true nur beim letzen Import angeben
beim Einspielen von Differenz-Daten *nicht* autoIndex:true angeben
Vorgehensweise ist identisch mit der im Punkt NAS Import im Detail beschriebenen.
Führen Sie die Schritte 1 und 2 durch:
connect to:"host=PostgreServerName dbname=dev_alkis port=5432 user=postgres" schema:ZielSchemaName mode:Alkis enableHistory:true (Anlegen der Tabellen, Views, Schema...)
LoadAlkisGml source:e:\Quelle\*.xml writers:8 autoindex:true postproc:true (Einspielen der Daten)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
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:
Eine pauschale Ursache zu benennen ist schwierig. Abhängig von der Ursache sind dann auch unterschiedliche Maßnahmen zur Fehlerbehebung zu ergreifen:
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:
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
ALKIS-NAS-Daten können mit dem NAS: Konverter als shape Files ausgegeben werden. Der Befehl lautet: LoadAlkisGmlToShape.
Argumente:
Beispiel:
LoadAlkisGmlToShape source:C:\*.xml targetEpsgCode:31469 OneFilePerType:true validate:true target:C:\shape
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.
Zeilen-Kommentare können mit # oder // oder REM eingefügt werden.
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:
Die Vergleiche mit n im Namen sind die Verneinungsformen (ifndef => 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
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