ingo@3661: \section{Geodatenimport} ingo@3661: aheinecke@5007: Der Geodaten Importer ist ein in der Programmiersprache Python aheinecke@5007: geschriebenes Kommandozeilen Werkzeug zum Import von Shapefiles in aheinecke@5007: eine Datenbank. tom@6750: Zum Lesen der Shapefiles und zum Schreiben der Geodaten tom@6750: in die Datenbank wird die GDAL-Bibliothek verwendet. aheinecke@5007: Um Daten in eine Oracle Datenbank zu importieren ist es nötig, dass tom@6750: GDAL und GDAL-Python-Bindings mit Oracle-Unterstützung installiert aheinecke@5007: sind. Bei der Verwendung von PostgreSQL entfällt dieser Schritt. aheinecke@5007: Weitere Details hierzu befinden sich im ingo@3661: Kapitel \ref{Systemanforderungen} und \ref{Installationsanleitung}. ingo@3661: ingo@3676: Der Importer kann mit einem Shellscript von der Kommandozeile gestartet werden ingo@3661: (siehe Kapitel \ref{Starten des Geodaten Importers}). Nach dem Start wird anhand der ingo@3661: Konfiguration festgestellt, welche Klassen von Shapefiles aus dem Dateisystem ingo@3676: importiert werden sollen. Für jede Klasse gibt es einen speziellen ingo@3680: Parser, der die speziellen Attribute eines Shapefiles liest und in die entsprechende ingo@3680: Relation der Datenbank schreibt. Die Parser sind speziell auf das aheinecke@5007: Dateisystem der BfG ausgerichtet. So wird beispielsweise erwartet, dass die Shapefiles der ingo@3661: Gewässerachse im Ordner $Geodaesie/Flussachse+km$ liegen. Weitere Informationen zu tom@6750: den einzelnen Parsern sind Kapitel \ref{Beschreibung der Parser} zu tom@6803: entnehmen. tom@6803: tom@6803: Damit die Geodaten eines Shapes später eindeutig in der Datenbank identifiziert tom@6803: werden können, wird für jede Geometrie der Pfad des Shapes im Dateisystem tom@6803: im Datenbankfeld 'path' gespeichert. Anwendungen, die auf der Datenbank tom@6803: aufbauen, können die Geodaten eines Shapefiles später anhand dieses Merkmals tom@6803: gruppieren und anzeigen. tom@6803: tom@6808: Bitte beachten Sie, dass der Geodaten Importer aufgrund der eingesetzten tom@6808: Technologien derzeit nicht in der Lage ist, lesend auf die Oracle-Datenbank tom@6808: zuzugreifen. Entsprechend kann beim Import nicht festgestellt werden, ob sich tom@6808: die Daten eines Shapefiles bereits in der Datenbank befinden, oder nicht. tom@6808: Ein erneuter Import der Geodaten würde also dazu führen, dass Geometrien doppelt in der tom@6808: Datenbank abgelegt werden. tom@6808: tom@6803: \subsection{Koordination-Transformation} tom@6803: Für die Transformation der Daten verwendet GDAL wiederum die PROJ4-Bibliothek. tom@6803: Die Daten werden vor dem Schreiben in die Datenbank alle tom@6803: in die Gauß-Krüger-Projektion Zone 3 (EPSG-Code 31467) transformiert. tom@6803: Ist für die zu importierenden Daten keine Projektion ersichtlich tom@6803: (fehlende \textit{*.prj}-Datei), so findet keine Transformation statt. tom@6803: Dies führt nur zu Problemen mit dem Fachdienst FLYS, falls die Daten nicht tom@6803: bereits in der genannten Projektion vorlagen. tom@6803: tom@6804: Im Falle der Digitalen Geländemodelle (DGM) findet keine Transformation statt, tom@6804: da zu diesen lediglich Metadaten in der Datenbank gespeichert werden tom@6804: (siehe Kapitel \ref{dgm_parser}), tom@6804: während die Daten selbst von der Anwendung Dive4Elements River tom@6804: aus dem Dateisystem geholt werden. tom@6804: Für Berechnungen mit den DGM werden die Geometrien aus der Datenbank tom@6804: in Dive4Elements River in die Projektion des jeweiligen DGM transformiert. tom@6804: Daher ist es besonders wichtig, dass die Angaben des EPSG-Codes tom@6804: in der Spalte SRID in DGMs.csv korrekt sind (siehe Kapitel \ref{dgm_parser}) tom@6804: tom@6803: \subsection{Logfile} tom@6803: Der Erfolg oder Misserfolg eines Shape-Imports wird tom@6750: im Logfile vermerkt. Folgende Einträge können dem Logfile ingo@3661: entnommen werden: ingo@3661: tom@6750: \textbf{INFO: Inserted \# features} tom@6750: \\Gibt die Anzahl der erfolgreich importierten Features an. ingo@3661: tom@6750: \textbf{INFO: Failed to create \# features} tom@6750: \\Gibt die Anzahl der Features an, die nicht importiert werden konnten. ingo@3661: tom@6750: \textbf{INFO: Found 3 unsupported features of type: '...'} ingo@3661: \\Gibt die Anzahl der Features an, die aufgrund ihres Datentyps nicht importiert aheinecke@5007: werden konnten. Wenn etwa Punkte erwartet wurden aber sich im Shapefile tom@6750: Polygone befanden. aheinecke@5007: tom@6750: \textbf{INFO: Did not import values from fields: '...' ...} tom@6750: \\Der Importer schreibt neben der geographischen Information weitere tom@6750: Attribut-Daten in die Datenbank. tom@6750: Attribut-Spalten die nicht importiert wurden (z.B. auf Grund tom@6750: von Tippfehlern oder unterschiedlicher Schreibweise), tom@6750: werden wie angegeben im Logfile aufgeführt. ingo@3661: ingo@3680: \textbf{ERROR: No source SRS given! No transformation possible!} ingo@3680: \\Das Shapefile enthält keine Information, in welcher Projektion die Geometrien ingo@3680: vorliegen. Es findet keine Transformation in die Zielprojektion statt. Bitte tom@6750: beachten Sie, dass FLYS diese Geometrien später ggf.\ nicht korrekt darstellen ingo@3680: kann. ingo@3680: ingo@3661: \textbf{ERROR: Unable to insert feature: DETAIL} tom@6750: \\Beim Lesen eines Features ist ein Fehler aufgetreten. tom@6750: Das Feature konnte nicht in die Datenbank geschrieben werden. ingo@3661: ingo@3661: \textbf{ERROR: Exception while committing transaction} ingo@3661: \\Beim Abschluss des Schreib-Vorgangs in die Datenbank ist ein unerwarteter tom@6750: Fehler aufgetreten. Die Features des Shapes sind nicht importiert worden. ingo@3661: ingo@3671: \textbf{ERROR 1: ORA-01017: invalid username/password; logon denied} ingo@3671: \\Es konnte keine Verbindung zur Oracle Datenbank hergestellt werden. Prüfen Sie ingo@3671: die Verbindungseinstellungen. ingo@3671: tom@6750: Weitere Fehler, die von der Oracle-Datenbank kommen, können ebenfalls im tom@6750: Logfile angezeigt werden. tom@6750: ingo@3661: ingo@3661: \subsection{Beschreibung der Parser} ingo@3661: \label{Beschreibung der Parser} ingo@3661: ingo@3661: Wie im letzten Kapitel beschrieben, sind die Parser speziell an das Dateisystem tom@6751: der BfG angepasst. Im Folgenden werden zu jedem Parser folgende Informationen ingo@3661: angegeben: ingo@3661: ingo@3661: \textbf{Pfad} tom@6751: \\Der Pfad, in dem die Shapefiles im Dateisystem abgelegt sein müssen (ausgehend tom@6751: vom Gewässer Verzeichnis). ingo@3661: ingo@3661: \textbf{Geometrie} ingo@3661: \\Der Geometrie Typ, der für diese Klasse von Shapefiles erwartet wird. ingo@3661: ingo@3661: \textbf{Attribute} ingo@3661: \\Eine Liste der Attribute, die vom Parser aus dem Shape gelesen werden. tom@6801: In Klammern als alternativ bezeichnete Attribut-Namen werden in tom@6801: das gleiche Datenbankfeld geschrieben, wie das vorgenannte Feld. tom@6801: Die alternativen Namen werden vom Importer zusätzlich unterstützt, tom@6801: um Dateien aus dem heterogenen Bestand der BfG unverändert tom@6801: importieren zu können. ingo@3661: tom@6751: Zudem werden Datenbank-Attribute beschrieben, die nicht direkt aus tom@6751: Attribut-Spalten des Shapefiles gelesen werden. ingo@3661: ingo@3661: \subsubsection{Achsen} tom@6800: \hspace{5mm} tom@6800: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} ingo@3661: Pfad & Geodaesie/Flussachse+km \\ tom@6751: Geometrie & LINESTRING, MULTILINESTRING \\ tom@6800: \end{tabular*} ingo@3661: tom@6751: Das Attribut 'name' wird auf den Namen des Shapefiles gesetzt. tom@6751: Zusätzlich wird das Attribut 'kind\_id' gesetzt, welches tom@6802: für die aktuelle Achse (\textit{achse.shp}) 1 ist tom@6802: und für sonstige Achsen (weitere Linien-Shapes) 2. ingo@3661: tom@6751: \subsubsection{Hydr. Grenzen} tom@6800: \hspace{5mm} tom@6800: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} tom@6751: Pfad & Hydrologie/Hydr.Grenzen \\ tom@6751: Geometrie & LINESTRING, MULTILINESTRING, POLYGON, MULTIPOLYGON \\ tom@6751: Attribute & SECTIE, STROVOER \\ tom@6800: \end{tabular*} ingo@3661: tom@6751: Das Attribut 'name' wird auf den Namen des Shapefiles gesetzt. tom@6751: Das Attribut 'kind' wird 1 gesetzt für Daten aus dem tom@6751: Unterverzeichnis \textit{Linien/BfG}, tom@6751: 2 für Daten aus \textit{Linien/Land}, tom@6751: 3 für Daten aus \textit{Sonstige} tom@6751: und für alle übrigen 0. tom@6751: Ausgenommen sind Dateien, in deren Namen 'Talaue' tom@6751: (Groß-Klein-Schreibung irrelevant) vorkommt. tom@6751: tom@6751: Linien und Polygone werden in der Datenbank in unterschiedlichen tom@6751: Tabellen gespeichert. tom@6751: ingo@3661: \subsubsection{Bauwerke} tom@6800: \hspace{5mm} tom@6800: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} ingo@3661: Pfad & Geodaesie/Bauwerke \\ ingo@3661: Geometrie & LINESTRING \\ tom@6751: Attribute & Name (alternativ: KWNAAM), tom@6751: km (alternativ: station, wsv-km), tom@6751: z (alternativ: Höhe, Hoehe, m+NHN)\\ tom@6800: \end{tabular*} ingo@3661: tom@6751: Das Attribut 'name' wird auf den Namen des Shapefiles gesetzt. tom@6751: Das Attribut 'kind\_id' ist 0 für Sonstige, tom@6751: 1 für Brücken, 2 für Wehre, 3 für Pegel. tom@6751: Es wird aus dem Dateinamen hergeleitet tom@6802: (\textit{bruecken.shp, wehre.shp, pegel.shp}, tom@6802: teilweise auch alternative Schreibweisen unterstützt) tom@6751: oder je Feature gesetzt, wenn in einer Attributspalte tom@6802: die Werte 'bruecke' und 'wehr' tom@6802: (teilweise auch alternative Schreibweisen unterstützt) vorkommen. tom@6751: Ausgenommen sind Dateien, in deren Namen 'Buhnen' tom@6751: (Groß-Klein-Schreibung irrelevant) vorkommt. ingo@3661: ingo@3661: \subsubsection{Querprofilspuren} tom@6800: \hspace{5mm} tom@6800: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} ingo@3661: Pfad & Geodaesie/Querprofile \\ ingo@3661: Geometrie & LINESTRING \\ tom@6751: Attribute & KILOMETER (alternativ: KM, STATION), ELEVATION \\ tom@6800: \end{tabular*} ingo@3661: tom@6751: Das Attribut 'kind\_id' wird 1 gesetzt für die Datei \textit{qps.shp} (aktuelle Querprofilspuren) tom@6751: und 0 für alle weiteren. ingo@3661: ingo@3661: \subsubsection{Festpunkte} tom@6800: \hspace{5mm} tom@6800: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} ingo@3661: Pfad & Geodaesie/Festpunkte \\ ingo@3661: Geometrie & POINT \\ tom@6751: Attribute & KM (alternativ: ELBE\_KM), X, Y, HPGP (alternativ: ART) \\ tom@6800: \end{tabular*} ingo@3661: tom@6751: Das Attribut 'name' wird auf den Namen des Shapefiles gesetzt. tom@6751: tom@6751: \subsubsection{Hochwassermarken} tom@6800: \hspace{5mm} tom@6800: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} tom@6751: Pfad & Hydrologie/HW-Marken/hw-marken.shp \\ tom@6751: Geometrie & POINT \\ tom@6751: Attribute & Ort (alternativ: Pegel), tom@6751: km (alternativ: station, wsv-km, FlussKm), tom@6751: z (alternativ: z mit anschließender Zahl, m+NHN)\\ tom@6800: \end{tabular*} tom@6751: tom@6751: Groß-Klein-Schreibung im Dateinamen ist irrelevant. tom@6802: Für das Attribut 'year' wird im Dateinamen nach einer Jahreszahl tom@6802: nach folgendem Muster gesucht: \textit{\_YYYY\_} oder \textit{-YYYY-}. tom@6802: Gelingt dies nicht, erscheint im Logfile die Warnung tom@6751: 'Could not extract year from filename: ...'. ingo@3661: ingo@3661: \subsubsection{Talaue} tom@6800: \hspace{5mm} tom@6800: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} ingo@3661: Pfad & Hydrologie/Hydr.Grenzen \\ ingo@3661: Geometrie & POLYGON, MULTIPOLYGON \\ tom@6800: \end{tabular*} ingo@3661: tom@6751: Es werden nur Dateien betrachtet, in deren Namen das Wort 'Talaue' tom@6751: (Groß-Klein-Schreibung irrelevant) vorkommt. tom@6751: Das Attribut 'name' wird auf den Namen des Shapefiles gesetzt. tom@6751: Das Attribut 'kind\_id' wird 1 gesetzt für die Datei \textit{talaue.shp} (aktuelle Talaue) tom@6751: und 0 für alle weiteren. ingo@3661: ingo@3661: \subsubsection{Hochwasserschutzanlagen} tom@6800: \hspace{5mm} tom@6800: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} ingo@3661: Pfad & Hydrologie/HW-Schutzanlagen \\ tom@6751: Geometrie & LINESTRING, MULTILINESTRING, POINT \\ tom@6751: Attribute & Name, Art, Quelle, Anmerkung, Stand, Verband, tom@6751: km (alternativ: Deich\_km), Bereich, tom@6751: Hoehe, Hoehe\_soll, WSP\_Bfg100, Bundesland tom@6751: (Teilweise auch alternative Schreibweisen unterstützt)\\ tom@6800: \end{tabular*} ingo@3661: tom@6751: Das Attribut 'name' wird auf den Namen des Shapefiles gesetzt, tom@6751: wenn kein Attribut 'Name' im Shapefile vorhanden ist. tom@6751: Das Feld 'kind\_id' wird per Default auf 2 (für Damm) gesetzt. tom@6751: Wird ein Attribut 'ART' im Shapefile gefunden, tom@6751: so wird 'kind\_id' entsprechend dieses Feldes gesetzt tom@6751: (1 für die Werte 'Durchlass', 'Rohr1', 'Rohr 1', 'Rohr 2', tom@6751: 2 für die Werte 'Damm', 'Deich', 'Hochufer', 'Hauptdeich', 'Sommerdeich', tom@6751: 3 für den Wert 'Graben'). tom@6751: Es wird versucht das Bundesland aus dem Dateinamen zu ermitteln, tom@6751: wenn das Shapefile kein Attribut 'Bundesland' enthält. tom@6751: tom@6751: Linien und Punkte werden in der Datenbank in unterschiedlichen tom@6751: Tabellen gespeichert. tom@6751: tom@6751: \subsubsection{Buhnen} tom@6800: \hspace{5mm} tom@6800: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} tom@6802: Pfad & Geodaesie/Bauwerke/Buhnen.shp \\ ingo@3661: Geometrie & POINT \\ tom@6802: Attribute & station (alternativ: km, wsv-km), tom@6802: z (alternativ: Hoehe, Höhe, m+NHN) \\ tom@6800: \end{tabular*} ingo@3661: tom@6802: Das Attribut 'kind\_id' wird für tom@6802: Buhnenkopf (\textit{bkl, bkr, bk}) 0, tom@6802: für Buhnenfuß (\textit{bfl, bfr, bf}) 1 und tom@6802: für Buhnenwurzel (\textit{bwl, bwr, bw}) 2 gesetzt, tom@6802: tom@6802: \subsubsection{Stationierung} tom@6802: \hspace{5mm} tom@6802: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} tom@6802: Pfad & Geodaesie/Flussachse+km/km.shp \\ tom@6802: Geometrie & POINT \\ tom@6802: Attribute & km (alternativ: KM), landkm \\ tom@6802: \end{tabular*} tom@6802: tom@6802: Das Attribut 'name' wird auf den Namen des Shapefiles gesetzt. ingo@3661: ingo@3661: \subsubsection{Überschwemmungsfläche} tom@6800: \hspace{5mm} tom@6800: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} tom@6802: Pfad & Hydrologie/UeSG \\ ingo@3661: Geometrie & POLYGON, MULTIPOLYGON \\ tom@6802: Attribut & diff, count, area, perimeter, GEWAESSER \\ tom@6800: \end{tabular*} ingo@3661: tom@6802: Das Attribut 'name' wird auf den Namen des Shapefiles gesetzt. tom@6802: Das Attribut 'kind' wird nach folgendem Schema gesetzt: tom@6802: tom@6802: \hspace{5mm} tom@6802: \begin{tabular}[t]{ll} tom@6802: Unterverzeichnis & Wert \\ tom@6802: \textit{Berechnungen/Aktuell/BfG} & 111 \\ tom@6802: \textit{Berechnungen/Aktuell/Bundesländer} & 112 \\ tom@6802: \textit{Berechnungen/Potentiell/BfG} & 121 \\ tom@6802: \textit{Berechnungen/Potentiell/Bundesländer} & 122 \\ tom@6802: \textit{Messungen} & 200 \\ tom@6802: \end{tabular} tom@6802: tom@6802: Das Attribut 'source' wird auf den Namen des Verzeichnisses gesetzt, tom@6802: indem sich das jeweilige Shapefile befindet. tom@6802: tom@6804: \subsubsection{Metadaten zu Digitalen Gelände-Modellen} tom@6804: \label{dgm_parser} tom@6804: \hspace{5mm} tom@6804: \begin{tabular*}{155mm}[t]{l@{\extracolsep\fill}p{125mm}} tom@6804: Pfad & ../DGMs.csv \\ tom@6804: Attribut & Projektion, Höhenstatus, Format, Bruchkanten, tom@6804: Auflösung, SRID, Pfad\_Bestand, tom@6804: km\_von, km\_bis, Jahr\_von, Jahr\_bis \\ tom@6804: \end{tabular*} tom@6804: tom@6804: Aus der Spalte 'Gewässer' in DGMs.csv wird entnommen, tom@6804: für welches Gewässer das angegebene DGM verwendet wird. tom@6804: Die Spalte muss daher den exakt gleichen Namen enthalten tom@6804: wie in der *.gew-Datei des Gewässers angegeben tom@6812: (siehe auch Kapitel \ref{start-hydr}). tom@6804: Die eigentlichen Geo-Daten der DGM werden nicht in die Datenbank importiert. tom@6935: Diese werden von der Anwendung Dive4Elements River aus dem Dateisystem geholt. tom@6751: ingo@3661: \subsection{Konfiguration} ingo@3661: \label{Konfiguration} tom@6807: Der Geodaten Importer kann über das Skript \textit{./run\_geo.sh} tom@6806: konfiguriert werden. Öffnen Sie die Datei mit einem Texteditor Ihrer Wahl tom@6806: und passen Sie ggf.\ folgende Variablen an: ingo@3661: ingo@3661: \textbf{HOST} ingo@3661: \\Der Host der Datenbank. ingo@3661: tom@7448: \textbf{BACKEND\_NAME} tom@7448: \\Der Name der Datenbank Instanz. tom@7448: Beispielsweise \textit{XE} bei einer Oracle XE Instanz. tom@7448: ingo@3661: \textbf{USER} ingo@3661: \\Der Nutzer, der zum Verbinden zur Datenbank verwendet wird. ingo@3661: ingo@3661: \textbf{PASS} ingo@3661: \\Das Passwort für USER zum Verbinden zur Datenbank. ingo@3661: tom@6806: In den weiteren Zeilen werden weitere Optionen definiert, die bei Bedarf angepasst ingo@3661: werden können. Falls nicht anders angegeben, können die Optionen mit den Werten ingo@3661: `0` und `1` belegt werden. ingo@3661: ingo@3661: \textbf{VERBOSE} ingo@3661: \\Dieser Wert gibt die Granularität der Log-Ausgaben während des ingo@3661: Imports an. Je höher der Wert, desto mehr Informationen werden ingo@3661: in das Logfile geschrieben. Aktuell sind die Werte `0`, `1` und ingo@3661: `2` definiert. Wird der Wert `0` gesetzt, werden nur Fehler und ingo@3661: Warnungen in das Logfile geschrieben. Bei `1` werden neben ingo@3661: Fehlern und Warnungen auch Infos in das Logfile geschrieben. Bei ingo@3661: `2` werden sämtliche Ausgaben des Programms geschrieben. Dieser ingo@3661: Modus ist hauptsächlich für die Entwicklung gedacht. ingo@3661: aheinecke@4871: \textbf{OGR\_CONNECTION} tom@6806: \\Hiermit kann direkt ein beliebiger Verbindungs-String angegegeben tom@6806: werden, welcher dann anstatt HOST, USER und PASS verwendet wird. tom@6806: Diese Option wird direkt an die OGR-Bibliothek weitergegeben und ermöglicht tom@6806: verbesserte Tests und Entwicklung mit verschiedenen Backends. aheinecke@4871: ingo@3661: \textbf{SKIP\_AXIS} ingo@3661: \\Bei gesetztem Wert `1` werden keine Flussachsen importiert. ingo@3661: ingo@3661: \textbf{SKIP\_KMS} tom@6806: \\Bei gesetztem Wert `1` werden keine Stationierungen importiert. ingo@3661: ingo@3661: \textbf{SKIP\_CROSSSECTIONS} ingo@3661: \\Bei gesetztem Wert `1` werden keine Querprofilespuren importiert. ingo@3661: ingo@3661: \textbf{SKIP\_FIXPOINTS} ingo@3661: \\Bei gesetztem Wert `1` werden keine Festpunkte importiert. ingo@3661: ingo@3661: \textbf{SKIP\_BUILDINGS} ingo@3661: \\Bei gesetztem Wert `1` werden keine Bauwerke importiert. ingo@3661: ingo@3661: \textbf{SKIP\_FLOODPLAINS} ingo@3661: \\Bei gesetztem Wert `1` werden keine Talauen importiert. ingo@3661: ingo@3661: \textbf{SKIP\_HYDR\_BOUNDARIES} ingo@3661: \\Bei gesetztem Wert `1` werden keine hydrologischen Grenzen importiert. ingo@3661: aheinecke@4880: \textbf{SKIP\_HWS\_LINES} tom@6806: \\Bei gesetztem Wert `1` werden kein Hochwasserschutzanlagen (Liniendaten) importiert. aheinecke@4880: aheinecke@4880: \textbf{SKIP\_HWS\_POINTS} tom@6806: \\Bei gesetztem Wert `1` werden kein Hochwasserschutzanlagen (Punktdaten) importiert. ingo@3661: ingo@3661: \textbf{SKIP\_UESG} ingo@3661: \\Bei gesetztem Wert `1` werden keine Überschwemmungsflächen importiert. ingo@3661: aheinecke@4971: \textbf{SKIP\_DGM} tom@6806: \\Bei gesetztem Wert `1` werden keine Metadaten zu Digitalen Geländemodellen importiert. aheinecke@4971: aheinecke@5353: \textbf{SKIP\_JETTIES} tom@6806: \\Bei gesetztem Wert `1` werden keine Buhnen importiert. ingo@3661: aheinecke@5545: \textbf{SKIP\_FLOODMARKS} tom@6806: \\Bei gesetztem Wert `1` werden keine HW-Marken importiert. aheinecke@5545: ingo@3661: \subsection{Starten des Geodaten Importers} ingo@3661: \label{Starten des Geodaten Importers} tom@6807: Der Geodaten Importer wird mittels des Shellskripts, tom@6807: dass auch für die Konfiguration verwendet wird, von einer Konsole ingo@3676: gestartet. Dazu führen Sie folgenden Befehl aus:\\ ingo@3661: ingo@3661: \begin{lstlisting} tom@6812: sh ./run_geo.sh pfad/zur/beispiel.gew > geo-import.log ingo@3661: \end{lstlisting} ingo@3676: tom@6812: Bezüglich des übergebenen Pfades siehe auch Kapitel \ref{start-hydr}. ingo@3661: Der Importer wird nun gestartet. Sämtliche Log-Ausgaben werden in die Datei ingo@3676: $geo-import.log$ geschrieben. ingo@3676: ingo@3676: