Geodatenabgabe: Unterschied zwischen den Versionen

Aus Geoinformation HSR
Wechseln zu: Navigation, Suche
K (Geodatenformate für die Geodatenabgabe)
K
 
(30 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
''>> Diese Seite ist Work-in-Progress als Notizen mit Blick auf 'Best-Practices'. Man beachte auch das Bearbeitungsdatum unten. <<''
+
Für die Abgabe von Geodaten sind aus technischer Sicht a) Webservices und b) Geodatenformate (inkl. Encoding) zu regeln.  
  
Für die Abgabe von Geodaten sind aus technischer Sicht 1. Webservices und 2. Geodatenformate (inkl. Encoding) zu regeln.
+
(Geo-)Dienste sollen:
 
 
Diese sollen  
 
 
* einfach, möglichst knapp und implementierbar (d.h. getestet) sein
 
* einfach, möglichst knapp und implementierbar (d.h. getestet) sein
 
* die (schweiz.) Gesetze, Verordnungen und Vorgaben berücksichtigen  
 
* die (schweiz.) Gesetze, Verordnungen und Vorgaben berücksichtigen  
 
* und wenn möglich auf Standards beruhen.
 
* und wenn möglich auf Standards beruhen.
  
Man unterscheide Download-Dienste zur Abgabe von Geodaten und Onlinezugriffs-Dienste! Bei Letzterem greifen verteilte - meist lokale (Desktop) GIS direkt auf den Onlinezugriffs-Dienst zu. WFS und WCS passen hier gut hinein und hingegen.  
+
Zu Geodaten gehören auch [[Datenmodelle]] und [[Darstellungsmodelle]].
 +
 
 +
Der Begriff Downloaddienste scheint sehr missverständlich, bzw. erklärungsbedürftig und wird kaum hinterfragt. So werden Downloaddienste oft reflexartig mit WFS gleichgesetzt und es wird kaum gefragt, wann synchroner und wann asynchroner Zugriff nötig ist. Im GeoIV der Scheiz z.B. ist in diesem Zusammenhang auch nur von einem Download-Dienst die Rede (vgl. auch [[GDI]]).
 +
 
 +
Effektiv unterteilt '''[http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_3.0.pdf dieser INSPIRE-Guide]''' zwei Arten (Seite 21):
 +
* "Pre-defined dataset download services": "... provides for the simple download of predefined datasets (or pre-defined parts of a dataset) with no ability to query datasets or select user-defined subsets of datasets. A pre-defined dataset or a pre-defined part of a dataset could be (for example) a file stored in a dataset repository, which can be downloaded as a complete unity with no possibility to change content, whether encoding, the CRS of the coordinates, etc.
 +
* "Direct access download services": "... extends the functionality of a pre-defined dataset download service to include the ability to query and download subsets of datasets."
 +
 
 +
Sinngemäss sprechen wir hier daher auch von zwei Arten '''Download-Diensten''', nämlich
 +
# "Direkt-Zugriffs-Download-Dienste" ("Direct oder Feature level access download services").
 +
# "(Vordefinierte) Datei-Download-Dienste" ("Pre-defined dataset download services") und
 +
 
 +
Leider steht im besagten INSPIRE-Guide nur etwas zu WFS jedoch nichts weiter zu den Datei-Download-Dienste (inbesonders asynchrone Zugriff), was nachfolgend genauer erläutert werden soll.
 +
 
 +
== Direkt-Zugriffs-Download-Dienste ==
  
== Webservices für die Geodatenabgabe ==
+
Hier greifen verteilte GIS direkt auf den Dienst zu und können ad-hoc Filter, Transformationen und Ausschnitte verlangen, bevor die Daten ausgegeben werden. Es sind dies fein-granulare, synchrone Webdienste im Gegensatz zum Datei-Download, der grob-granular ist (Quelle: WFS, Seite xiii, [http://www.opengeospatial.org/standards/wfs OpenGIS Web Feature Service 2.0 Interface Standard (also ISO 19142)]).
  
Empfehlung:
+
Beispiele:
# Synchroner Download (bis 100 MB)
+
* [[WFS]] mit GML aber auch mit anderen Formaten, wie z.B. INTERLIS oder GeoJSON (siehe unten).
## HTTP
+
* [[WCS]]
## ftp
 
# Asynchroner Download (von 0 bis 100 MB)
 
## E-Mail und Weblink zu HTTP
 
  
 
Diskussion:
 
Diskussion:
* Datenabgabe ist meist asynchron, auch wenn die Datei kleiner als z.B. 100 MB ist.  
+
* Für CH-Standards siehe [http://www.ech.ch/index.php?option=com_docman&task=cat_view&gid=183&Itemid=181&lang=de eCH-0056 d Profil GeoWebservices]
 +
* [[GeoJSON]] (ev. GeoBSON) empfehlen sich als weboptimierte Formate, eignen sich aber nicht für zu grosse Datenmengen.
 +
 
 +
== Datei-Download-Dienste ==
 +
 
 +
Datei-Download-Dienste (Webservices) für die Geodatenabgabe:
 +
# Hypertext Transfer Protocol (HTTP) (bis max. 100 MB)
 +
# File Transfer Protocoll (FTP)
 +
# Peer-to-peer File Sharing Protokolle, z.B. BitTorrent (mit Resume und Throttling)
 +
# weitere
 +
 
 +
Diskussion:
 +
* Datei-Download-Dienste können - im Gegensatz zu Direkt-Zugriffsdiensten - verschiedene zusätzliche Eigenschaften haben:
 +
** Resume-Funktion, d.h. Wiederanlauf ohne Verlust der bisher heruntergeladenen Daten.
 +
** Asynchroner Download, bei z.B. der dem Client eine URL per E-Mail geschickt wird, damit der Client die Daten beziehen kann, wann er möchte - auch wiederholt, d.h. mit Resume (z.B. ftp).
 +
** Die Datenabgabe grosser Datenmengen (> 100 MB) ist oft asynchron.  
 
* In Zukunft könnten für synchroner Download ev. folgende Webservices relevant werden: WMS:getFeatureInfo, WMS:getFeatureInfoById mit einem HTTP-URL- und einem SOAP-Binding.
 
* In Zukunft könnten für synchroner Download ev. folgende Webservices relevant werden: WMS:getFeatureInfo, WMS:getFeatureInfoById mit einem HTTP-URL- und einem SOAP-Binding.
* [[WFS]] ist nur bedingt zu empfehlen (und wenn dann nur für den synchronen Fall), da dieser Industriestandard nicht primär für die Datenabgabe entworfen worden ist und u.a. bei grossen Dateien Timeout-Probleme hat.
+
* [[WFS]] ist nur bedingt für Datei-Download-Dienste zu empfehlen, da es ein Standard für den fein-granularen Zugriff ist und u.a. bei grossen Dateien Timeout-Probleme hat, bei dem der Client keine Möglichkeit hat, den Download zu wiederholen (resume).
 +
 
 +
== Datenformate ==
  
== Geodatenformate für die Geodatenabgabe ==
+
Abgrenzung: Systemeigene Formate ('die Proprietären') zählen wir nicht zu den Standards, da sie darauf ausgerichtet sind, interne Strukturen optimal abzubilden. Es sind meist binäre Formate der Systeme (vgl. auch die Bemerkung zur unten).
  
 
Die "Formatpyramide" (von der Fa. Infogrips, angepasst und ergänzt):
 
Die "Formatpyramide" (von der Fa. Infogrips, angepasst und ergänzt):
# Systemeigene Formate ('die Proprietären'): Meist binäres Format der Systeme, z.B. File Geodatabase der Fa. [[Esri]] (vgl. auch [[OGR]]).
 
 
# [[GML]]/XML (das 'internationale') Dies ist zwar ein Geodaten-Austauschformat gemäss OGC-Industriestandard und eng mit [[WFS]] verbunden. Doch ist es sehr umfangreich, komplex (viele Namespaces) und an einigen Stellen unterspezifiziert (Umgang mit Geometrien).
 
# [[GML]]/XML (das 'internationale') Dies ist zwar ein Geodaten-Austauschformat gemäss OGC-Industriestandard und eng mit [[WFS]] verbunden. Doch ist es sehr umfangreich, komplex (viele Namespaces) und an einigen Stellen unterspezifiziert (Umgang mit Geometrien).
# [[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.
+
# [[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/IXML). Nachteile: Auf die Schweiz beschränkt.
 
# [[Spatialite]] (das Format für "alle"): Ein binäres Format mit mehreren Tabellen mit Attributen und Geometrie in einer einzigen Datei. Beziehungen in Views. 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. Beziehungen in Views. Ein SQLite-"Profil". Open Source. [http://de.wikipedia.org/wiki/SpatiaLite]. Nachteile: Wird noch nicht von allen GIS unterstützt.
 
# [[Shapefile]] ('das GIS-Format von Esri'). Dies ist ein verbreitetes aber auch eine veraltetes und beschränktes Format. Z.B. fehle Beziehungen, es besteht aus vielen zusammengehörenden Dateien und es werden Attributnamen abgeschnitten. Das "Personal Geodatabase" (vgl. [[Esri]] und [[OGR]]) ist nicht viel besser und wird von Esri selber nicht für den Austausch empfohlen.
 
# [[Shapefile]] ('das GIS-Format von Esri'). Dies ist ein verbreitetes aber auch eine veraltetes und beschränktes Format. Z.B. fehle Beziehungen, es besteht aus vielen zusammengehörenden Dateien und es werden Attributnamen abgeschnitten. Das "Personal Geodatabase" (vgl. [[Esri]] und [[OGR]]) ist nicht viel besser und wird von Esri selber nicht für den Austausch empfohlen.
Zeile 36: Zeile 61:
  
 
Diskussion:
 
Diskussion:
* In Zukunft ist ev. mit einem neuen Format zu INTERLIS 2 zu rechnen, das einfacher und XML-konformer ist.
+
* In Zukunft ist ev. mit einem neuen Format zu INTERLIS zu rechnen, das einfach und XML-konform ist.
* [[GeoJSON]] (ev. GeoBSON) empfehlen sich als weboptimierte Formate, eignen sich aber nicht für zu grosse Geodaten-Mengen.
+
* Zu beobachten ist auch die Entwicklung von Protocol Buffers, d.h. einer Art XML, nur sehr kompakt binär und Schema-getrieben ([http://de.wikipedia.org/wiki/Protocol_Buffers]).
 +
* Die Fa. [[Esri]] schlägt sozusagen als Ablösung ihres Shapefile-Formats die "File Geodatabase" (vgl. auch [[OGR]]), jedoch nicht als Format sondern als geschlossene Softwarebibliothek (API). Ein solches API widerspricht jedoch der Anforderung eines Austauschstandards insofern es naturgemäss nicht das Format selber normiert und zudem eingeschränkt ist auf die Programmiersprache und die unterstützten Betriebssysteme.
  
 
[[Kategorie:Dateiformat]]
 
[[Kategorie:Dateiformat]]

Aktuelle Version vom 25. März 2013, 01:28 Uhr

Für die Abgabe von Geodaten sind aus technischer Sicht a) Webservices und b) Geodatenformate (inkl. Encoding) zu regeln.

(Geo-)Dienste sollen:

  • einfach, möglichst knapp und implementierbar (d.h. getestet) sein
  • die (schweiz.) Gesetze, Verordnungen und Vorgaben berücksichtigen
  • und wenn möglich auf Standards beruhen.

Zu Geodaten gehören auch Datenmodelle und Darstellungsmodelle.

Der Begriff Downloaddienste scheint sehr missverständlich, bzw. erklärungsbedürftig und wird kaum hinterfragt. So werden Downloaddienste oft reflexartig mit WFS gleichgesetzt und es wird kaum gefragt, wann synchroner und wann asynchroner Zugriff nötig ist. Im GeoIV der Scheiz z.B. ist in diesem Zusammenhang auch nur von einem Download-Dienst die Rede (vgl. auch GDI).

Effektiv unterteilt dieser INSPIRE-Guide zwei Arten (Seite 21):

  • "Pre-defined dataset download services": "... provides for the simple download of predefined datasets (or pre-defined parts of a dataset) with no ability to query datasets or select user-defined subsets of datasets. A pre-defined dataset or a pre-defined part of a dataset could be (for example) a file stored in a dataset repository, which can be downloaded as a complete unity with no possibility to change content, whether encoding, the CRS of the coordinates, etc.
  • "Direct access download services": "... extends the functionality of a pre-defined dataset download service to include the ability to query and download subsets of datasets."

Sinngemäss sprechen wir hier daher auch von zwei Arten Download-Diensten, nämlich

  1. "Direkt-Zugriffs-Download-Dienste" ("Direct oder Feature level access download services").
  2. "(Vordefinierte) Datei-Download-Dienste" ("Pre-defined dataset download services") und

Leider steht im besagten INSPIRE-Guide nur etwas zu WFS jedoch nichts weiter zu den Datei-Download-Dienste (inbesonders asynchrone Zugriff), was nachfolgend genauer erläutert werden soll.

Direkt-Zugriffs-Download-Dienste

Hier greifen verteilte GIS direkt auf den Dienst zu und können ad-hoc Filter, Transformationen und Ausschnitte verlangen, bevor die Daten ausgegeben werden. Es sind dies fein-granulare, synchrone Webdienste im Gegensatz zum Datei-Download, der grob-granular ist (Quelle: WFS, Seite xiii, OpenGIS Web Feature Service 2.0 Interface Standard (also ISO 19142)).

Beispiele:

  • WFS mit GML aber auch mit anderen Formaten, wie z.B. INTERLIS oder GeoJSON (siehe unten).
  • WCS

Diskussion:

Datei-Download-Dienste

Datei-Download-Dienste (Webservices) für die Geodatenabgabe:

  1. Hypertext Transfer Protocol (HTTP) (bis max. 100 MB)
  2. File Transfer Protocoll (FTP)
  3. Peer-to-peer File Sharing Protokolle, z.B. BitTorrent (mit Resume und Throttling)
  4. weitere

Diskussion:

  • Datei-Download-Dienste können - im Gegensatz zu Direkt-Zugriffsdiensten - verschiedene zusätzliche Eigenschaften haben:
    • Resume-Funktion, d.h. Wiederanlauf ohne Verlust der bisher heruntergeladenen Daten.
    • Asynchroner Download, bei z.B. der dem Client eine URL per E-Mail geschickt wird, damit der Client die Daten beziehen kann, wann er möchte - auch wiederholt, d.h. mit Resume (z.B. ftp).
    • Die Datenabgabe grosser Datenmengen (> 100 MB) ist oft asynchron.
  • In Zukunft könnten für synchroner Download ev. folgende Webservices relevant werden: WMS:getFeatureInfo, WMS:getFeatureInfoById mit einem HTTP-URL- und einem SOAP-Binding.
  • WFS ist nur bedingt für Datei-Download-Dienste zu empfehlen, da es ein Standard für den fein-granularen Zugriff ist und u.a. bei grossen Dateien Timeout-Probleme hat, bei dem der Client keine Möglichkeit hat, den Download zu wiederholen (resume).

Datenformate

Abgrenzung: Systemeigene Formate ('die Proprietären') zählen wir nicht zu den Standards, da sie darauf ausgerichtet sind, interne Strukturen optimal abzubilden. Es sind meist binäre Formate der Systeme (vgl. auch die Bemerkung zur unten).

Die "Formatpyramide" (von der Fa. Infogrips, angepasst und ergänzt):

  1. GML/XML (das 'internationale') Dies ist zwar ein Geodaten-Austauschformat gemäss OGC-Industriestandard und eng mit WFS verbunden. Doch ist es sehr umfangreich, komplex (viele Namespaces) und an einigen Stellen unterspezifiziert (Umgang mit Geometrien).
  2. 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: [1] . Es gibt zurzeit zwei Formate: die INTERLIS 1 (ITF) und INTERLIS 2 (XTF/IXML). Nachteile: Auf die Schweiz beschränkt.
  3. Spatialite (das Format für "alle"): Ein binäres Format mit mehreren Tabellen mit Attributen und Geometrie in einer einzigen Datei. Beziehungen in Views. Ein SQLite-"Profil". Open Source. [2]. Nachteile: Wird noch nicht von allen GIS unterstützt.
  4. Shapefile ('das GIS-Format von Esri'). Dies ist ein verbreitetes aber auch eine veraltetes und beschränktes Format. Z.B. fehle Beziehungen, es besteht aus vielen zusammengehörenden Dateien und es werden Attributnamen abgeschnitten. Das "Personal Geodatabase" (vgl. Esri und OGR) ist nicht viel besser und wird von Esri selber nicht für den Austausch empfohlen.
  5. DXF (das Format für Architekten und Planer): Ein Text-/ASCII-Format nur mit "farbiger" Geometrie (höchstens mit Layerangaben). Nachteil: Nur Geometrie.
  6. 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.

Diskussion:

  • In Zukunft ist ev. mit einem neuen Format zu INTERLIS zu rechnen, das einfach und XML-konform ist.
  • Zu beobachten ist auch die Entwicklung von Protocol Buffers, d.h. einer Art XML, nur sehr kompakt binär und Schema-getrieben ([4]).
  • Die Fa. Esri schlägt sozusagen als Ablösung ihres Shapefile-Formats die "File Geodatabase" (vgl. auch OGR), jedoch nicht als Format sondern als geschlossene Softwarebibliothek (API). Ein solches API widerspricht jedoch der Anforderung eines Austauschstandards insofern es naturgemäss nicht das Format selber normiert und zudem eingeschränkt ist auf die Programmiersprache und die unterstützten Betriebssysteme.