Geodatenabgabe: Unterschied zwischen den Versionen
Aus Geoinformation HSR
Stefan (Diskussion | Beiträge) K |
Stefan (Diskussion | Beiträge) K |
||
| Zeile 14: | Zeile 14: | ||
# [[DXF]] (das Format für Architekten und Planer): Ein Text-/ASCII-Format nur mit "farbiger" Geometrie (höchstens mit Layerangaben). Nachteil: Nur Geometrie. | # [[DXF]] (das Format für Architekten und Planer): Ein Text-/ASCII-Format nur mit "farbiger" Geometrie (höchstens mit Layerangaben). Nachteil: Nur Geometrie. | ||
# [[Spatialite]] (das Format für "alle"): Ein binäres Format mit mehreren Tabellen mit Attributen und Geometrie in einer einzigen Datei. Ein SQLite-"Profil". Open Source. [http://de.wikipedia.org/wiki/SpatiaLite]. Nachteile: Wird noch nicht von allen GIS unterstützt. | # [[Spatialite]] (das Format für "alle"): Ein binäres Format mit mehreren Tabellen mit Attributen und Geometrie in einer einzigen Datei. Ein SQLite-"Profil". Open Source. [http://de.wikipedia.org/wiki/SpatiaLite]. Nachteile: Wird noch nicht von allen GIS unterstützt. | ||
| − | # [[INTERLIS]] (das Format für "GIS-Spezialisten"): Nicht nur ein ASCII-Format in einer Datei, sondern | + | # [[INTERLIS]] (das Format für "GIS-Spezialisten"): Nicht nur ein ASCII-Format in einer Datei, sondern lässt sich direkt aus einer eigenen Datenbankschema-Beschreibung herleiten. Publiziert vom Schweizer Standard-Verein eCH: [http://www.ech.ch/vechweb/page?p=page&site=/Gremien/Fachgruppen/interli] . Es gibt zurzeit zwei Formate: die INTERLIS 1 (ITF) und INTERLIS 2 (XTF/XML). Nachteile: Auf die Schweiz beschränkt. |
# [[CSV]] (das Format für den IT Mainstream): Bekanntes Format als kleinster gemeinsamer Nenner. Braucht bestimmte Regeln für Feldtrennzeichen und Encoding; Geometrien sollten im sog. WKT-Format codiert werden: [http://en.wikipedia.org/wiki/Well-known_text]. Nachteil: eine Datei pro Tabelle. | # [[CSV]] (das Format für den IT Mainstream): Bekanntes Format als kleinster gemeinsamer Nenner. Braucht bestimmte Regeln für Feldtrennzeichen und Encoding; Geometrien sollten im sog. WKT-Format codiert werden: [http://en.wikipedia.org/wiki/Well-known_text]. Nachteil: eine Datei pro Tabelle. | ||
| − | In Zukunft ist ev. mit einem neuen | + | In Zukunft ist ev. mit einem neuen Format zu INTERLIS 2 zu rechnen, das einfacher und XML-konformer ist. |
| − | Diskussion weiterer | + | Diskussion weiterer Formate: |
| − | * [[GeoJSON]] (ev. GeoBSON) als weboptimierte Formate nicht zu | + | * [[GeoJSON]] (ev. GeoBSON) empfehlen sich als weboptimierte Formate und eignen sich für nicht zu grosse Geodaten-Mengen. |
| + | * Mit Vorbehalten ist das [[GML]]/XML zu erwähnen. Dies ist zwar ein Geodaten-Austauschformat gemäss OGC-Industriestandard und eng mit [[WFS]] verbunden. Doch ist es sehr umfangreich, komplex (viele Namepaces), nicht ganz XML-konform und an einigen Stellen unterspezifiziert. | ||
* Recht veraltet ist das GIS-Format "Esri [[Shapefile]]". Dies ist ein beschränktes Format, z.B. besteht es aus vielen zusammengehörenden Dateien und es werden Attributnamen abgeschnitten. | * Recht veraltet ist das GIS-Format "Esri [[Shapefile]]". Dies ist ein beschränktes Format, z.B. besteht es aus vielen zusammengehörenden Dateien und es werden Attributnamen abgeschnitten. | ||
[[Kategorie:Dateiformat]] | [[Kategorie:Dateiformat]] | ||
Version vom 15. Oktober 2012, 16:07 Uhr
<<Diese Seite ist Work-in-Progress; beachten Sie das Bearbeitungsdatum unten>>
Für die Geodatenabgabe und aus einer zukunftsgerichteten Sicht kommen folgende Webservices und Geodatenformate (Standards, Geostandards) in Frage:
Webservices für die Geodatenabgabe:
- HTTP
- ftp
WFS ist nur bedingt zu empfehlen, da dieser Industriestandard nicht primär für die Datenabgabe entworfen worden ist und u.a. bei grossen Dateien Timeout-Probleme hat.
In Zukunft könnten ev. folgende Webservices relevant werden: WMS:getFeatureInfo, WMS:getFeatureInfoById mit einem HTTP-URL- und einem SOAP-Binding.
Geodatenformate für die Geodatenabgabe:
- DXF (das Format für Architekten und Planer): Ein Text-/ASCII-Format nur mit "farbiger" Geometrie (höchstens mit Layerangaben). Nachteil: Nur Geometrie.
- Spatialite (das Format für "alle"): Ein binäres Format mit mehreren Tabellen mit Attributen und Geometrie in einer einzigen Datei. Ein SQLite-"Profil". Open Source. [1]. Nachteile: Wird noch nicht von allen GIS unterstützt.
- INTERLIS (das Format für "GIS-Spezialisten"): Nicht nur ein ASCII-Format in einer Datei, sondern lässt sich direkt aus einer eigenen Datenbankschema-Beschreibung herleiten. Publiziert vom Schweizer Standard-Verein eCH: [2] . Es gibt zurzeit zwei Formate: die INTERLIS 1 (ITF) und INTERLIS 2 (XTF/XML). Nachteile: Auf die Schweiz beschränkt.
- CSV (das Format für den IT Mainstream): Bekanntes Format als kleinster gemeinsamer Nenner. Braucht bestimmte Regeln für Feldtrennzeichen und Encoding; Geometrien sollten im sog. WKT-Format codiert werden: [3]. Nachteil: eine Datei pro Tabelle.
In Zukunft ist ev. mit einem neuen Format zu INTERLIS 2 zu rechnen, das einfacher und XML-konformer ist.
Diskussion weiterer Formate:
- GeoJSON (ev. GeoBSON) empfehlen sich als weboptimierte Formate und eignen sich für nicht zu grosse Geodaten-Mengen.
- Mit Vorbehalten ist das GML/XML zu erwähnen. Dies ist zwar ein Geodaten-Austauschformat gemäss OGC-Industriestandard und eng mit WFS verbunden. Doch ist es sehr umfangreich, komplex (viele Namepaces), nicht ganz XML-konform und an einigen Stellen unterspezifiziert.
- Recht veraltet ist das GIS-Format "Esri Shapefile". Dies ist ein beschränktes Format, z.B. besteht es aus vielen zusammengehörenden Dateien und es werden Attributnamen abgeschnitten.
