Deutsch Français English Italiano
GEOWebforum Header
www.sogi.ch www.swisstopo.ch www.sik-gis.ch www.kkgeo.ch Logos Founders
Anmeldestatus: nicht angemeldet


Diskussion «Warum Downloaddienste unterschieden werden müssen und warum WFS nicht der einzige Download-Dienst ist»
Artikel 1-10 von 10



Claude Eisenhut
29. April 13 (15:29 Uhr)
Beitragsnummer: 2728
Man sollte organisationsinterne und organisationsübergreifende Dienste unterscheiden, weil die Anforderungen und Gestaltungsmöglichkeiten sehr unterschiedlich sind.

Was ein Downloaddienst ist, ist im GeoIV (Erläuternder Bericht) sehr offen formuliert: "...werden die Geobasisdaten auf das System des Anfragers übertragen".

Es gibt m.E. im Kontext der organisationsübergreifenden Dienste drei grundsätzliche Motivationen, um Daten von Maschine zu Maschine zu transferieren:
- Auskunftsdienste, z.B. Bezug eines Grundbuchauszugs
- Geschäftsverkehrdienste für Prozesse, die organisationsübergreifend stattfinden. Z.B. eine Handänderung (alter, neuer Eigentümer, alte,neue Bank, Notar und Grundbuch als am Prozess beteiligte "Organisationen")
- Notifikationsdienste, Mitteilungen an Stellen, die nicht direkt am Prozess beteiligt sind. Z.B. das Steueramt möchte erfahren, dass eine Handänderung erfolgt ist

Alle diese Arten von Downloaddiensten kann man mit WFS realisieren, aber es ist sehr aufwändig, weil der WFS eine Schnittstelle pro Datenobjekt definiert. Um aber z.B. einen performanten Auskunftsdienst zu erhalten, muss man ein Geflecht von Datenobjekten transferieren können (z.B. Grundstück inkl. Gebäude und inkl. Textpositionen). Das muss man zusätzlich spezifizieren und implementieren und ergibt sich nicht von selbst. Und bei Abfragen will man typischerweise auch Kriterien über ein Geflecht von Datenobjekten - z.B. eine Abfrage nach Grundstücken (Liegenschaft und SDRd) an einer bestimmten Gebäudeeingangsadresse. Machbar, aber aufwändig.

Auch Geschäftsverkehrdienste oder Notifikationsdienste sind mit WFS machbar, aber bedingen auch individuellen Spezifikations- und Implementierungsaufwand.


Angelo Quaglia
26. April 13 (16:21 Uhr)
Beitragsnummer: 2721
Hi,

I would like to mention that it is currently under discussion in INSPIRE the possibility to augment the already defined INSPIRE Extended Capabilities for WFS 2.0 capabilities documents in order to inform service clients about the availability of "whole" datasets not through the dynamic WFS interface but through static resources in order not to overload the service instance.

Stefan Keller
25. März 13 (01:53 Uhr)
Beitragsnummer: 2703
Hoi Stephan, Danke für deine Kommentare.

Da sind wir uns einig. Wichtig schient mir einfach, dass erkannt wird, dass es aus Sicht eines Nutzers von Webdiensten des Bunds oder eines Kantons nicht nur WFS sondern verschiedene "Feature Level Access- (Direkt-Zugriffs-) Dienste" und "Datei-Downloaddienste" gibt.

Und ja: Das Fact-Sheet und das "eCH-0056: Profil Geo Webservices" sind nützliche Dokumente. Ich wollte unten nur darauf hinweisen, dass beide in wichtigen Fragen noch nicht vollständig sind, wenn es darum geht, Geodatenabgabe (-Formate) und Downloaddienste zu realisieren.

Inzwischen habe ich einen weiteren Anwendungsfall von Downloaddiensten angetroffen: die sog. "Aggregation von Geodiensten". Auch hier scheint mir wieder angebracht, nicht den WFS nicht unbesehen zu wählen ("weil er ja sowieso realisiert werden muss"). Wenn das aggregierte Geoportal eine WFS-Anfrage ("kaskadierend") weitergibt, sind Performance- und Kompatibilitäts-Probleme vorprogrammiert. Hier könnte man m.E. einen Datei-Download (mit/ohne Caching, bzw. Harvesting) in Betracht ziehen. Dieser Ansatz ist an einingen Orten schon seit Jahren in Betrieb.

Stephan Heuel
19. März 13 (22:16 Uhr)
Beitragsnummer: 2700
Hallo Stefan, Deine ursprüngliche Unterscheidung kann ich nachvollziehen. Im nachfolgenden eine Kommentare von meiner Seite:

Direct Access == Feature Level Access

Ich würde bei "direct access download services" nicht von "subsets" sprechen. ich schlage vor, dass wir dort von der kleinstmöglichen Ebene ausgehen, also Abfragen auf "feature-level" spezifizieren und implementieren. Das kann aufgrund einer Query in der Tat eine oder mehrere Features eines Datensatzes sein (entschuldige mein "denglisch").

Praxissicht

Die Downloadmöglichkeiten von (allfällig vorproduzierten) Dateien in der Tat sinnvoll und notwendig. Ich möchte die Unterscheidung zum "Direct Access" aus Praxissicht beschreiben:

- Wenn man beispielsweise für einen eGov-Dienst sporadisch die Features eines Geodatensatzes abfragt, reicht ein WFS vollkommen aus (und ich brauche mich nicht um Updates etc. zu kümmern). Beispiel: Einzelne Gebäude der AV.
- Wenn man jedoch räumliche Analysen oder Prozessierung durchführen möchte, benötigt man den Datensatz weiterhin als "Ganzes", um effizient Berechnungen durchführen zu können. Beispiel: Der gesamte AV-Datensatz mit ausgewählten Attributen für Kanton SZ. Daher ist ein einfacher Downloaddienst einer Gesamtdatei sinnvoll - wohl nicht als WFS, sondern als ZIP-Archiv mit einem kompakten Geodatenformat (bitte nur nicht ein Shapefile).

Bedürfnisse aus der Praxis

Aus Anwender (und auch Entwickler) ist das Format des einfachen und des "feature-level" Downloaddienstes nicht so wichtig, solange meine Software (oder meine API) das Format unterstützt. Viel wichtiger sind u.A. folgende Merkmale des Downloaddienstes:

- Antwort und Downloadzeiten
- Verfügbarkeit
- Allfällige Kosten
- Lizenz
- Letztes Update

Andere Formate ausser WFS?

Kuno, Danke für den Link zum Fact-Sheet. Eine sehr gute Idee, die Grundlagen zusammenzufassen. Ich kann jedoch nicht nachvollziehen, warum ein Downloaddienst gemäss eCH-0056 nur mittels WFS erfolgen muss. Im eCH-0056 gibt es m.E. keinen direkten Hinweis auf Downloaddienste, nur allgemein auf Geodienste.

Ich stimme Stefan zu, dass WFS nicht als einziges Format für einen "feature-level" Downloaddienst gleichgesetzt werden sollte. Spannend wird es, ob der OGC Standard Kandidat "GeoServices REST API" auch als möglicher Downloaddienst in Frage kommt, vgl. [www.opengeospatial.org/standards/requests/89] (Part 4: Feature Service).

Existierende Lösungen für Downloaddienste

Schliesslich lohnt es sich zu schauen, welche Lösungen für Downloaddienste in der Praxis existieren. Mir fallen neben den bereits bekannten Portalen in der Schweiz spontan ein:

- FME Server: Unterstützung praktisch aller Formate, Aufbauende Geoshoplösungen wie weogeo.com existieren)

- OpenStreetMap mit nichtstandardisierten Formaten: Dateidownloads beispielsweise auf [www.geofabrik.de/data/download.html], Download auf feature-level durch XAPI, [wiki.openstreetmap.org/wiki/Xapi]).

Neben INSPIRE sollten wir auch schauen, was wir von existierenden Downloaddiensten lernen können.

Schliesslich gibt es noch sehr entwicklernahe Downloadmöglichkeiten, wie [radar.oreilly.com/2013/03/the-city-of-chicago-wants-you-to-fork-its-data-on-github.html] beschreibt: Warum nicht auch Daten in ein Versionsmanagementsystem hochladen?

Stefan Keller
18. März 13 (00:15 Uhr)
Beitragsnummer: 2696
Vielen Dank, Kuno, für den wichtigen Hinweis. Meine Aussage unten, dass Downloaddienste oft "reflexartig" mit WFS gleichgesetzt werden, gilt auch für dieses Fact-Sheet. Die Schlussfolgerung "Download-Dienst=WFS" ist wohl auf das Dokument eCH-0056 zurückzuführen, bzw. dessen Interpretation.

Es scheint mir offensichtlich, dass nebst WFS auch vordefinierte Datei-Downloaddienste nötig sind (wie von Christine Giger unten und bei INSPIRE beschrieben). Beides sind für mich Lösungen, die gleichberechtigt sind, wobei eine Behörde Datei-Downloaddienste sogar noch priorisieren und zeitlich vorziehen könnte, da sie einfacher zu realisieren sind als ein Webservice à la WFS.

Meiner Meinung nach sollte im eCH-0056 die Empfehlung "Download-Dienst=WFS" korrigiert und um vordefinierte Datei-Downloaddienste ergänzt werden. Bei dieser Gelegenheit liesse sich auch die Diskussion führen, u.a.
1. ob GML beim WFS wirklich das einzige obligatorische Format sein soll (und wenn ja welche Version genau), und
2. was wir von INSPIRE lernen und ggf. übernehmen könnten.

Kuno Epper
15. März 13 (16:14 Uhr)
Beitragsnummer: 2695
Als weiteren Diskussionsinput sei ein Fact-Sheet erwähnt, welches die gesetzlichen Grundlagen bezüglich Datenmodellierung und Datenaustauschformate zusammenfasst und über die IKGEO publiziert wird ([http://www.ikgeo.ch/] > Dokumentation > Modellkonformer Austausch von Gebasisdaten bzw. [www.ikgeo.ch/nc/dokumentation/modellkonformer-austausch-von-geobasisdaten.html?cid=298&did=510&sechash=726ee4ea]).

Das Dokument stellt die für die Geodienste relevanten Informationen aus den verschiedenen Grundlagendokumente (Botschaft zum GeoIG, GeoIG, GeoIV, GeoIV-swisstopo, eCH-0056, ...) zusammen und kommt unter anderem zum Schluss, dass:
- der Download-Dienst in Bezug auf die Geobasisdaten des Bundesrechts für Vektordaten mittels OGC-Standard Web Feature Service (WFS) und für Rasterdaten über einen Web Coverage Service (WCS) erfolgen muss.

Christine Giger
12. März 13 (16:04 Uhr)
Beitragsnummer: 2693
Die Masterarbeit von Herrn Weichand ist sehr umfassend und für Implementierer von INSPIRE-konformen Download-Diensten absolut empfehlenswert!

Eine Zusammenfassung der wichtigsten Unterschiede zwischen den gegenwärtigen Vorgaben für Geo-Web-Dienste in der Schweiz und bei INSPIRE (nicht nur auf Download-Dienste bezogen) findet sich hier: [www.giger-geoit.ch/sites/default/files/INSPIRE_Anforderungen_VergleichCH_0.pdf]

Wie im obigen Dokument dargestellt und auch bei Herrn Weichand richtig erwähnt, gibt es im INSPIRE-Kontext sehr wohl sehr genaue Vorgaben für den Datei-Download. Dagegen ist das in eCH-0056 (bis jetzt) noch nicht so ganz klar.

Der folgende Link zeigt ein komplettes Beispiel eines "Download Service of pre-defined datasets using the ATOM Implementation" wie in INSPIRE vorgesehen. [inspire-geoportal.ec.europa.eu/demos/ccm/codeview.html]

Bitte zu beachten, dass - zusätzlich zum Beschrieb der Technical Guidance (wie z.B. von Weichand zitiert) - das Beispiel auch noch den Nutzen von HTML illustriert, um den Feed in beliebigen Browsern einheitlicher anzeigen zu können.

Ich freue mich schon auf die Diskussionen und Beiträge am Spirgarten-Treffen ([2682])!

Stefan Keller
11. März 13 (01:56 Uhr)
Beitragsnummer: 2692
Hier noch eine Masterarbeit, die zum Thema Downloaddienste und INSPIRE passt:

"Entwicklung und Anwendung von Downloaddiensten im Kontext der europäischen Geodateninfrastruktur INSPIRE" von Jürgen Weichand, Institut für Geoinformation und Vermessung, Studiengang Geoinformationssysteme, Hochschule Anhalt (Januar 2013):

Download: [www.weichand.de/masterarbeit/Masterarbeit_Weichand.pdf]

Alain Buogo
4. März 13 (10:01 Uhr)
Beitragsnummer: 2690
Als Grundlage für die Diskussion hier wie es seit 5 Jahre in GeoIV (Erläuternder Bericht) steht :
[www.swisstopo.admin.ch/internet/swisstopo/de/home/swisstopo/legal_bases.parsys.86367.downloadList.96797.DownloadFile.tmp/erlbericht030608dtdef.pdf]

"Unter dem im Art. 13 des GeoIG erwähnten Abrufverfahren wird eine direkte elektronische Abfrage von Geobasisdaten verstanden. Diese Abfrage erfolgt online, (heute oft per Internet und durch spezielle Vertriebs-Geodienste) ohne dass die angefragte Stelle aktiv wird. Beim Abrufverfahren werden die Geobasisdaten auf das System des Anfragers übertragen, so dass die Daten gespeichert und anschliessend auch off-line (d.h. ohne weiter bestehende on-line Verbindung zur Datenquelle) weiter verwendet werden können. Diese Ausprägung des Abrufverfahrens wird durch den entsprechend der INSPIRE-Richtlinie der EU definierten Download-Dienst realisiert.

Im Weiteren können Download-Dienste, wenn dies durchführbar ist, den direkten Zugriff auf Kopien vollständiger Geodatensätze oder Teilen davon ermöglichen.

Diese Option ist insbesondere dann von Bedeutung, wenn die Datenmenge der angefragten Geobasisdaten so gross ist, dass ein eigentliches „Herunterladen“ zu lange dauern würde oder die Speicherkapazität des Abfragers übersteigt. Im Gegensatz zu den Darstellungsdiensten erlaubt ein Download-Dienst in diesem Fall die direkte Nutzung und Weiterbearbeitung auf dem System des Datenanbieters.
Die in der Begriffsbestimmung (Art. 2 Bst. k) enthaltene Funktionalität ist als Mindestanforderung zu betrachten. Die zuständige Stelle kann auch mehr Funktionalität anbieten."

In dem Sinne scheint das WAS (und wofür) klar genug definiert zu sein. Für das WIE stehen sicher noch offene technische und organisatorische Fragen offen!


Stefan Keller
4. März 13 (01:29 Uhr)
Beitragsnummer: 2689
Der Begriff Downloaddienst wird oft reflexartig mit WFS gleichgesetzt. Es wird kaum hinterfragt, ob nicht z.B. auch ein Datei-Download genügen würde. Auch im GeoIV z.B. ist nur von einem Downloaddienst ohne Differenzierung die Rede.

Bei der Vorbereitung des nächsten Spirgarten-Treffens'13 (siehe [2682]!) bin ich auf einen Abschnitt eines altbekannten INSPIRE-Guides gestossen (siehe den Hinweis vom Juni 2012 im Geowebforum hier [2538]), den offenbar viele bisher übersehen haben:

Dieser INSPIRE-Guide unterteilt zwei Arten von Downloaddiensten (vgl. Seite 21):
1. "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."
2. "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."

Ich schlage vor, dass wir ab sofort ebenfalls zwei Arten von Downloaddiensten unterscheiden, nämlich:
1. Vordefinierte Datei-Downloaddienste ("Pre-defined dataset download services") und
2. Direkt-Zugriffs-Downloaddienste ("Direct access download services").

Leider steht im besagten INSPIRE-Dokument sehr viel zum WFS jedoch kaum etwas zu den Datei-Downloaddiensten. Inbesonders fehlt eine Auflistung der Datei-Download-Protokolle (v.a. HTTP, FTP und Peer-to-peer File Sharing).

Auch fehlen die Erwähnung des asynchronen Zugriffs (versus synchron) sowie die Möglichkeit, nach einem Abbruch der Transaktion an einem bestimmten Punkt wieder anknüpfen zu können, ohne den Download von vorne beginnen zu müssen.

Ich freue mich auf eine angeregte Diskussion - spätestens am kommenden Spirtarten-Treffen!



  1