OGR

Aus Geoinformation HSR
Wechseln zu: Navigation, Suche

OGR Simple Feature Library:

OGR ist eine ansehnliche Sammlung von Werkzeugen, namentlich OGR2OGR, die Lese- und manchmal Schreib-Zugriffe zu einer Vielzahl von Vektor-Dateiformaten, Datenbanken und übers Internet anbieten. OGR ist Teil der GDAL-Rasterformate-Bibliothek, die wiederum in den FWTools (C++ Open Source-Programme von Frank Warmerdam) zusammengefasst sind und typischerweise über die Kommandozeile gesteuert werden.

Siehe auch:

OGR2OGR
OGR2OGR ist ein sog. 'starrer' Konverter (1:1-Mapping), der auch Funktionen bzw. SQL-Befehle interpretieren kann - auch ohne Datenbank. SQL-Anfragen an SQL-fähige Treiber (z.B. PostgreSQL, Personal Geodatabase) werden direkt weitergeleitet, so dass die ganze Funktionalität des beteiligten Datenbank-Treibers zugänglich ist.
Hilfe/Community
Die Dokumentation von OGR geht etwas in GDAL/FWTools unter (Link siehe unten). Wer Hilfe braucht, sollte sich zuerst diese anschauen und kann sich dann an die FWTools-Mailingliste wenden, die sich auch mit OGR befasst und an GDAL/Maptools anlehnt. Hilft das nicht weiter, steht das GISpunkt HSR-Team gerne zur Seite.

Software

OGR wird als Teil GDAL und diese als Teil der FWTools verteilt (Linux und Windows-Version)).

Immer mehr Open Source-Software (darunter bald auch OGR) wird auch über die OSGeo Binary Distribution verteilt.

Installation

OGR wird vorwiegend von Programmierern entwickelt, die Linux als Entwicklungsumgebung verwenden. Die Unterstützung von Windows steht daher etwas zurück. Wir helfen gerne bei Fragen.

Installation unter Windows:

  • Schritt 1: FWTools in ein (temporäres) Verzeichnis downloaden und installieren, z.B. in C:\Program Files\FWTools1.3.9
  • Schritt 2: Arbeitsverzeichnis anlegen, z.B. C:\work\OGR\
  • Schritt 3: setfw.bat von "C:\Program Files\FWTools1.3.9\" hineinkopieren (Alternative: PATH-Environment-Variable ergänzen). Hinweis: setfw.bat enthält einen lokalen Pfad. Das Batchfile muss allenfalls editiert und der Pfad mit Anführungszeichen unklammert werden, wie folgt:
 @echo off
 SET FWTOOLS_DIR=C:\Program Files\FWTools1.3.9
 call "%FWTOOLS_DIR%\bin\setfwenv.bat"
  • Schritt 4: INTERLIS-Compiler 'ili2c.jar' herunterladen (interlis.ch > "Compiler für INTERLIS 2.3") und ili2c.jar in das Arbeitsverzeichnis kopieren (Java muss installiert sein).
  • Abschluss: Test ob Installation bereit ist: 
 > cd C:\work\OGR\>
 > setfw.bat
 > gdalinfo --version
 GDAL 1.5dev, FWTools 1.3.9, released 2007/10/11
  • Jetzt sollte OGR - und die anderen FWTools - bereit sein. Einige Beispiele sind unten angegeben.

Dokumentation

Dateiformate

Übersicht

Tabelle: OGR-Driver (Quelle: OGR-Website)
Driver-Name File-Ext. Reader/Writer Beispiel Beschreibung
Interlis 1 .ITF,.ILI Reader s.unten INTERLIS 1; Datei ili2c.jar zusätzlich installieren (vgl. INTERLIS). In ITF-Datei darf keine Zeile 'TOPI Topic' stehen (mit Editor abändern). In ILI-Datei dürfen Attributnamen nicht res. INTERLIS-Schlüsselwörtersein, z.B. nicht TYPE oder NAME.
Interlis 1 .ITF Writer s.unten INTERLIS 1 (ITF/ILI); schreibt fälschlicherweise noch 'TOPI Topic' ins ITF.
Interlis 2 .XML,.ILI Reader s.unten INTERLIS 2; ili2c.jar zusätzlich installieren
Interlis 2 .XML,.ILI Writer s.unten INTERLIS 2; z.Zt. nur beschränkt benutzbar (u.a. wegen ILI Version 2.2!)
CSV .CSV,(.vrt) Reader s.unten Comma Separated Value (vgl. auch VRT und die OGR SQL unten)
CSV .CSV,(.vrt) Writer s.unten Comma Separated Value (vgl. auch VRT und die OGR SQL unten)
ESRI Shapefile .SHP,.DBF,.shx Reader s.unten Shapefile (SHP)
ESRI Shapefile .SHP,.DBF,.shx Writer s.unten Shapefile (SHP)
GML .GML Reader s.unten Geographic Markup Language GML v.2.0(!)
GML .GML Writer s.unten Geographic Markup Language GML v.2.0(!)
GPX .GPX Reader s.unten GPS Exchange Format GPX; ACHTUNG: ab FWTools 2.0.1 auf Windows (expat-Problem)
GPX .GPX Writer s.unten GPS Exchange Format GPX; ab FWTools 2.0.1 auf Windows;
KML .KML Writer s.unten Keyhole Markup Language KML. Kein Reader vorhanden.
MapInfo File .MIF,.MID Reader s.unten MapInfo Interchange File (MIF), textbasiert mit .MIF (Schema/Geometrie) und .MID (Sachdaten) plus .TAB (binär).
MapInfo File .MIF,.MID Writer s.unten MapInfo Interchange File (MIF), textbasiert mit .MIF (Schema/Geometrie) und .MID (Sachdaten) plus .TAB (binär).

Weitere Dateiformate

Informationen zu weiteren Dateiformaten (alphabetisch):

  • ASCII-Formate:
    • DXF/DWG Writer (*) (.dxf/.dwg) - AutoCAD DXF/DWG-Format v.12/13/14/15/18. (*) Writer nur verfügbar, wenn neu mit zusätzlicher Library kompiliert (ACHTUNG: daher z.Zt. nicht in der Windows-Distribution enthalten)
    • VRT Reader (VRT, .vrt) - Virtual Datasource; nützlich z.B. für CSV mit Geometrien!
    • GeoJSON Reader (GeoJSON, .js) - Textuelles Format => (NEU!)
  • Binäre Dateiformate:
    • Microstation (DGN)
  • Datenbanken:

HowTo...

INTERLIS 1-Reader und -Writer

Vorbereitungen:

  • Unter Windows ev. setfw.bat ausführen, damit die Programme im System-Pfad sind und gefunden werden.
  • Fehlt die .ili-Datei, muss diese zuerst erstellt, bzw. organisiert werden. Ev. muss diese "erraten" (d.h. "reverse engineered") werden, z.B. mit Hilfe von OGRINFO.

INTERLIS 1 nach Shapefile

Konvertieren von INTERLIS 1-Dateien (.itf und .ili) nach Shapefile.

  • Input-Dateien: ili-bsp.itf und ili-bsp.ili
  • Resultat.....: Für jede INTERLIS 1-Tabelle wird im Output-Verzeichnis shpdir/ ein Shapefile (.shp, .dbf und .shx) erzeugt. 
 > ogr2ogr -f "ESRI Shapefile" shpdir ili-bsp.itf,ili-bsp.ili

Hinweise:

  • Allfällige Warnung "Info: Folder D:\daten_eigene2\OGR\demo\standard doesn't exist; ignored" ignorieren.
  • Es wird immer ein .dbf erzeugt, auch wenn keine Sachdaten vorhanden sind.
  • Speziell: Beschriftungen werden in separaten Tabellen verwaltet. Das bedingt eine nachträgliche Bearbeitung (Konverter wie FME machen das im Rahmen des Konvertierung-Schrittes). Die Erzeugung von Sichten (JOINs) aufgrund von Beziehungen zwischen Tabellen sind nicht Bestandteil einer Datenbeschreibung und der Daten (einfaches SQL schon; siehe unten).
  • Problem behoben (Behandlung von INTERLIS-Referenzattributen (->), die aus anderen Tabellen auf das Input-Shapefile "zeigen").

Shapefile nach INTERLIS 1

Konvertieren von Shapefile nach INTERLIS 1-Dateien (.itf).

  • Input: bahnhoefe.itf und bahnhoefe.ili
  • Resultat: Eine INTERLIS 1-Datei Bahnhoefe.itf mit vom Programm generierten Transfer-Identifikatoren (TID).
 > ogr2ogr -f "INTERLIS 1" Bahnhoefe.itf Bahnhoefe.shp

Hinweise:

  • Schreibt fälschlicherweise noch 'TOPI Topic' (ca. Zeile 6) ins ITF. Unbedingt mit Editor abändern.
  • Sollte in Zukunft auch ein .ILI generieren, denn die Informationen aus dem Shapefile (DBF) sind bekannt; siehe ogrinfo.

INTERLIS 2-Reader und -Writer

Vorbereitungen: siehe INTERLIS 1-Reader und -Writer.

Shape to INTERLIS 2 (xml) mit .ili-file:

  • Input.: one Shape including shp-, shx- and dbf-file
  • Output: one INTERLIS 2.2 xml-file
 > ogr2ogr -f "INTERLIS 2" Bahnhoefe.xml,Bahnhoefe.ili Bahnhoefe.shp

INTERLIS 2 (.xml) to Shape without INTERLIS model ***

  • Input.: zpl_k23.xml
  • shapefiles in shpdir2/
 > ogr2ogr -f "ESRI Shapefile" shpdir2 zpl_k23.xml

KML-Writer mit SQL- und BBox-Optionen

KML ist ein Mix von Formattierung und Geometrie-/Sachdaten. Es gibt keinen KML-Reader.

Konvertiere Shapefile nach KML 

 > ogr2ogr -f KML Bahnhoefe.kml Bahnhoefe.shp

Konvertiere Shapefile nach KML mit den dsco-Optionen NameField (setzt das Namensfeld des Markers) und AltitudeMode, das im GE die Höhe gemäss Intputdaten (und nicht Geländemodell-anschmiegend) anzeigen lässt (Hinweis: eine einzige Zeile ohne Zeilenumbruch). 

 > ogr2ogr -f KML Bahnhoefe.kml Bahnhoefe.shp -dsco NameField=Name -dsco AltitudeMode=absolute

Shapefile nach KML mit SQL ohne Geometrie (selektiere alle Bahnhöfe der Ostschweiz): 

 > ogr2ogr -f KML bahnhoefe.kml bahnhoefe.shp -sql "SELECT name,type,level,
   cntryname,prov1name from bahnhoefe where prov1name = 'Ostschweiz'"

Shapefile nach KML mit BBox-Option (Region Zürich): 

 > ogr2ogr -spat 8.38 47.81 8.83 47.30 -f KML output.kml input.shp

PostgreSQL/PostGIS-Reader und -Writer

PostgreSQL-DB nach Shapefile konvertieren:

  • Input: PostgreSQL/PostGIS-Datenbank gisdb
  • Resultat: out.gml-Datei
 > ogr2ogr -f gml out.gml PG:"host=localhost dbname=gisdb"
 Warning 1: Multi-column primary key in 'towns' detected but not supported.

Hinweis: Diese Warnung ist offensichtlich falsch, denn es gibt keinen primary key in dieser DB(?)

PostgreSQL-DB nach KML konvertieren und dabei Linien vereinfachen (simplify): 

 > ogr2ogr -sql "select admin, case when area(the_geom) > 3000000000 then 
   transform(simplify(the_geom, 4), 4030) else transform(simplify(the_geom, 
   0.01), 4030) end from utlanduse" -f kml out.kml PG:"host=localhost 
   dbname=statewide user=xxx password=xxx"

Hinweis: user und password müssen noch gesetzt werden.

CSV-Reader und Writer (mit/ohne WKT)

Dokumentation: 

 > ogr2ogr -f CSV out Bahnhoefe.shp -sql "select *,OGR_GEOM_WKT from Bahnhoefe"

Variante mit lat/lon-Punktgeometrie

Angenommen folgende CSV-Datei sample1.csv existiere: 

 lon,lat,value
 -81.0,32.0,13
 -82.0,33.0,14
 -83.0,34.0,15
  • Erzeuge Shapefile layer1 aus der sample1.dbf mit Hilfe der Konfigurationsdatei sample1.vrt (VRT).
 % ogr2ogr -f "ESRI Shapefile" sample1_dir sample1.vrt
  • sample1.vrt-Datei (Erzeugt layer1.dbf, layer1.shp, layer1.shx und layer1.prj):
 <OGRVRTDataSource>
   <OGRVRTLayer name="layer1">
     <SrcDataSource relativeToVRT="1">sample1_dir</SrcDataSource>
     <SrcLayer>sample1</SrcLayer>
     <GeometryType>wkbPoint</GeometryType>
     <LayerSRS>WGS84</LayerSRS>
     <GeometryField encoding="PointFromColumns" x="lon" y="lat"/>
   </OGRVRTLayer> 
 </OGRVRTDataSource>

Variante mit Geometrieattribut im WKT-Format

Gegeben Datei sample2.csv (CSV) mit Geometrien codiert in WKT: 

 ID,VALUE,THEGEOM
 1, Wert 1, "POINT(12.375 49.618)"
 2, Wert 3, "POINT(16.198 50.431)"
 3, Wert 3, "POINT(19.628 51.389)"

Konvertiere CSV zu ESRI Shapefile: 

 > ogr2ogr -f "ESRI Shapefile" sample2_dir sample2.vrt

wobei die VRT-Definition sample2.vrt wie folgt ist: 

 <OGRVRTDataSource>
     <OGRVRTLayer name="sample2">
         <SrcDataSource relativeToVRT="0">sample2.csv</SrcDataSource>
         <SrcLayer>sample2</SrcLayer>
         <GeometryType>wkbPoint</GeometryType>
         <GeometryField encoding="WKT" field="THEGEOM" />
         <LayerSRS>epsg:4326</LayerSRS>
     </OGRVRTLayer>
 </OGRVRTDataSource>

Variante mit LineString:

.csv: 

 ID,THEGEOM
 1,"LINESTRING(12.375 49.618, 12.380 49.61, 12.474 49.634)"
 2,"LINESTRING(16.198 50.431, 16.205 50.434, 16.334 50.405)"
 3,"LINESTRING(19.628 51.389, 20.278 51.782, 20.350 51.840)"

.vrt: 

         <GeometryType>wkbLineString</GeometryType>

Zeige alle Attribute eines Shapefiles

Mit dem Tool ogrinfo kann man Schema-Informationen über die unterstützten Formate abfragen.

Zeige alle Attribute: 

 > ogrinfo -so -al Bahnhoefe.shp

Zeige alle Bahnhöfe mit Namen Rapperswil 

 > ogrinfo -al -ro out.shp -sql "SELECT * from out WHERE name='Rapperswil'"

Transformiere Shapefile im CH1903- nach WGS84-CRS

Dokumentation:

  • EPSG:4326 steht für WGS84, also GPS-Koordinaten
  • Eine Liste aller EPSG-Codes befindet sich in der Datei gcs.csv im data-Verzeichnis der FWToos (z.B. ).
  • EPSG
  • PRJ
 > ogr2ogr out.shp Bahnhoefe.shp -t_srs EPSG:4326

SQL

Erzeuge Spatial Index (.qix): 

 > ogrinfo -sql "CREATE SPATIAL INDEX ON Bahnhoefe" Bahnhoefe.shp

GPX-Reader und -Writer

Konvertiere GPX nach Shapefile: 

 > ogr2ogr -f "ESRI Shapefile" tmpdir t.gpx

Konvertiere Shapefile nach GPX: 

 > ogr2ogr -f "GPX" t2.gpx bahnhoefe.shp

Beispiel mit Attributen in <extensions>. 

 > ogr2ogr -f "GPX" t2.gpx -dsco GPX_USE_EXTENSIONS=YES bahnhoefe.shp

Hinweise zum GPX-Writer:

  • Falls "ERROR 6..." auftritt siehe GPX_USE_EXTENSIONS.
  • GPX_USE_EXTENSIONS=YES gibt Attribute in XML-Element extensions aus.
  • FORCE_GPX_TRACK=YES: Ändere das Mapping "LineString => GPX Routes" nach "LineString => GPX Tracks"
  • FORCE_GPX_ROUTE=YES: Ändere das Mapping "MultiLineString => GPX Tracks" nach "MultiLineString => GPX Routes" (falls MultiLineString nur eine einzige Linie sind)

Über GPX: GPX kennt WayPoints, Routes und Tracks. Weitere Attribute können in einem extensions-Attribut versorgt werden (GPX_USE_EXTENSIONS). Default Geometrie-Typen-Mapping OGR-intern nach GPX:

  • Point => GPX Waypoints (<wpt>)
  • LineString => GPX Routes (<rte>)
  • MultiLineString => GPX Tracks (<trk>).
  • Andere Geometrietpen sind nicht unterstützt.

GML-Reader und -Writer

Shapefile nach GML konvertieren: 

 > ogr2ogr -f GML bahnhoefe.gml bahnhoefe.shp

GML nach Shapefile konvertieren: 

 > ogr2ogr -f "ESRI Shapefile" tmpdir bahnhoefe.gml

Hinweis: Falls folgender Fehler auftritt "ERROR 1: XML Parsing Error: An exception occurred! Type:UTFDataFormatException, Message: invalid byte 2 (g) of a 4-byte sequence." dann ist die Datei nicht im UTF-8-Encoding gespeichert. Das kann ggf. mit einem Werkzeug (Editor) korrigiert werden.

MapInfo MIF/MID-Reader und -Writer

Konvertiere Shapefile nach MapInfo Files MIF/MID (erzeugt bahnhoefe.mif und bahnhoefe.mid im Unterverzeichnis .\tmp\). Wenn FORMAT=MIF fehlt, dann werden die binären TAB-Dateien erzeugt: 

 > ogr2ogr -f "MapInfo File" tmp -dsco FORMAT=MIF bahnhoefe.shp

Konvertiere alle MapInfo-Dateien MIF/MID im Unterverzeichnis .\tmp\ (z.B. die Dateien bahnhoefe.mif und bahnhoefe.mid) nach Shapefile im selben Unterverzeichnis: 

 > ogr2ogr -f "ESRI Shapefile" tmp tmp

Styles

Formate, die Styles unterstützen sind TAB, MIF und DGN. Der KML-Driver unterstützt leider noch keine Styles. Styles werden soweit möglich beibehalten beim Konvertieren (translating) zwischen Formaten.

Style-Konzept von OGR: Was sind die Gemeinsamkeiten und Unterschiede von SLD und ev. Mapfile?

The concept of assigning rendering rules to geometries is shared in both cases but that's about it. The terminology (pen/brush/etc vs symbolizers) and encoding (compact text strings vs verbose XML) are completely different.

SLD also supports building up classifications using filter encoding which is not part of the OGR style concept.

Why did OGR invent its own encoding instead of reusing SLD? Mostly because the OGR style encoding predates the days when SLD became well known (to me anyway) and widely used. But even if we were to do this again today I'm not sure if we would opt for a verbose XML encoding... we'd probably spend a lot of time debating the performance issues vs the benefits of interoperability with SLD.

Weblinks

Von «https://giswiki.hsr.ch/index.php?title=OGR&oldid=14048»