5 Die Geodienste: ein bisschen Technik, Cédric Moullet, swisstopo

Transkript

1 25 Inhalt Oktober Editorial, René Sonney, e-geo.ch 4 Die Geodienste im Allgemeinen, Francis Grin, HEIG-VD 5 Die Geodienste: ein bisschen Technik, Cédric Moullet, swisstopo 6 Standards und Profile Beispiel ech-0056 Anwendungsprofil Geodienste, Peter Staub, swisstopo 7 Web Map Services (WMS), Horst Düster, SO!GIS Für Dummies? Nicht wirklich! 8 Ein Geodienst: Web Map Tile Service (WMTS), Cédric Moullet, swisstopo 10 API Programmierschnittstellen, David Oesch, swisstopo 12 Der Geosuchdienst Die Schatzkarte des Piraten Jack Rackham gehört uns! André Schneider, swisstopo Schwerpunkt: Geowebdienste für Dummies 13 Cloud Computing, Hanspeter Christ, swisstopo 15 Innovation trifft Geschichte: 8. e-geo.ch Forum zu Gast in Zürich, René Sonney, e-geo.ch

2 2 Newsletter e-geo.ch 25 10/2010

3 Editorial 3 René Sonney, e-geo.ch Liebe Leserinnen, liebe Leser, Ich nehme an, dass Sie diese berühmte Reihe, die den Namen «aaaaa für Dummies» trägt, bereits gesehen oder von dieser bereits gehört haben, wobei «aaaaa» je nach Fall durch Excel, Word, Office usw. aber auch durch Fotografie, Kochen oder Gitarre ersetzt werden kann. Die Reihe strebt danach, die Fragen der unerfahrenen Anwender, die das Bedürfnis haben, einfache Erklärungen zu ihren Problemen, ob informatischer oder jeglicher anderer Art, zu finden, zu beantworten. Liebe Leserinnen und liebe Leser, eine große Anzahl von uns hat bestimmt von Begriffen, Techniken, Programmen oder von Geodiensten gehört, ohne genau zu wissen worum es sich dabei handelt oder wie das Ganze tatsächlich funktioniert. Beim Konzipieren dieses e-geo.ch Bulletins, das Sie in Ihren Händen halten, hatte ich daher das Bedürfnis, ohne mir jedoch einen solchen Professionalismus anmaßen zu können, eine Art «die Webgeodienste für Dummies» zu machen. Die Verbreitung der Geoinformation durch modernste elektronische Mittel ist zu einer al l - täglichen Realität geworden und die Verbrei - tungs methoden passen sich unaufhörlich den steigenden Bedürfnissen der Anwender an. Die Einführung des Geoportals der Bundes verwaltung im Laufe des Sommers ist Ihnen zweifellos nicht entgangen. Dieses Geoportal lässt erahnen, was unser nationales Geoportal, das dazu bestimmt ist, dem Artikel 10 des Bundesgesetzes über Geo information, welcher besagt, dass «Geobasisdaten des Bundesrechts öffentlich zugänglich sind» zu entsprechen, sein wird. Die Teilnehmer des e-geo.ch-forums, welches am 12. November in Zürich stattfinden wird, werden die Gelegenheit haben, näher betrachten zu können, wie dieses Geoportal aussehen wird und an seiner endgültigen Ausarbeitung teilzunehmen, da dessen Modell anlässlich eines der Workshops am Nachmittag vorgestellt und darüber diskutiert wird. Heute Morgen, auf dem Weg zur Arbeit, hörte ich ein Interview des Polizeikommandanten des Kantons Neuenburg, welcher von Geo lokalisierung, Georeferenzierung und Geoinformation sprach. Als ich hörte, wie dieser Polizeibeamte dem Journalisten erklärte, wo der Unterschied zwischen Geolokalisierung und Geo referenzierung liegt, konnte ich nachempfinden, welchen Weg diese neuen Technologien zur Verfügungs stellung der Geoinformation innerhalb weniger Jahre zurückgelegt haben. Wie man es in unserem täglichen Leben sehen kann, gehört die Geoinformation jetzt zu unserem täglichen Leben und darauf verzichten zu wollen, ist ein Ding der Unmöglichkeit. Während dieses Interviews erklärte der Kom mandant unter anderem, wie die Georeferenzierungs - werkzeuge jetzt in den Werkzeugen, über die die Polizei für ihre tägliche Arbeit verfügt, inte - griert sind und wie diese ihre tägliche Arbeit revolutioniert haben. Natürlich bedient sich nicht nur die Polizei solcher Instrumente und die Liste der Fachleute, die sich bei ihrer täglichen Arbeit der Geolokalisation bedienen, wird immer länger. Im vorigen Winter hatte ich am Ende eines Skitages die Gelegenheit, das Cockpit einer Pistenraupe zu besichtigen. Wenn man die Schwierigkeiten betrachtet, die wir am helllichten Tag haben, uns im Nebel zurechtzufinden, war es daher nicht verwunderlich, dort ein GPS vorzufinden, da diese Pistengeräte die meiste Zeit in der Nacht arbeiten. Ich hatte jedoch nicht erwartet, dort ein Informationssystem über die Gegend vorzufinden, welches der Verwaltung der gesamten Pisten des Skigebietes, der Schneedicke an jeder Stelle der Pisten, der Schneereserven, usw., dient. Kurz gesagt, wie man es in unserem täglichen Leben sehen kann, gehört die Geoinformation jetzt zu unserem täglichen Leben und darauf verzichten zu wollen, ist ein Ding der Unmöglichkeit. Unter den verschiedenen Methoden und Mitteln, die uns ermöglichen, Geodaten zu erhalten und zu Verfügung zu stellen, muss man an erster Stelle die Web-Geodienste nennen. Man spricht ständig darüber, man erwähnt sie lang und breit aber weiß man wirklich, was sich hinter diesen Geodiensten verbirgt. Jedenfalls gehöre ich zu jenen, die nur einen zu vagen Begriff haben über das, was diese Geodienste sind und machen. Ich danke daher den Autoren, die es mir ermöglicht haben, nachdem ich ihre Beiträge gelesen habe, mich ein bisschen weniger «dumm» zu fühlen. Viel Spaß beim Lesen!

4 G e o w e b d i e n s t e f ü r D u m m i e s Die Geodienste im Allgemeinen Francis Grin, HEIG-VD Es gibt immer mehr Geodaten, und um diese effizient nutzen zu können, ohne Gigabytes von Daten zu kopieren (ganz zu schweigen von den Aktualisierungsproblemen bei den kopierten Datenbeständen), bieten Geodienste Lösungsmöglichkeiten, die noch zu wenig genutzt werden. Aber zuerst einige Begriffsbestimmungen: Geodaten sind raumbezogene Daten, die mit einem bestimmten Zeitbezug die Ausdehnung und Eigenschaften bestimmter Räume und Objekten beschreiben, insbesondere deren Lage, Beschaffenheit, Nutzung und Rechtsverhältnisse. (Quelle: GeoIG) Geodienste sind vernetzbare Anwendungen, welche die Nutzung von elektronischen Dienstleistungen im Bereich der Geodaten vereinfachen und Geodaten in strukturierter Form zugänglich machen. (Quelle: GeoIG) wie zum Beispiel die Geodienste WMS, WFS, usw. (vom Open Geospatial Consortium OGC genehmigte Spezifikationen), andere generel mit Bezug aufs Internet. Damit ist es möglich neue Anwendungen zu verwirklichen, welche über genormte Schnittstellen oder über Geodienste Geodaten aus verschiedenen Datenquellen nutzen. Geodaten aus verschiedenen Quellen können so in einem Geoportal integriert und visualisiert werden. Wie die Erklärungen und Beispiele der folgenden Artikel zeigen, ermöglicht der Stand der Technik die Realisierung vonanwendungen und Geoportalen, die für den Nutzer und Konsumenten von Geodaten sehr interessant und nützlich sind. Die Implementierung dieser Infrastrukturen verlangt natürlich viel Zeit und Geld, aber vor allem den Willen aller Partner zur Zusammenarbeit und zur Verfügungstellung ihrer Geodaten, welche noch zu oft abgeschottet sind. Das Potenzial der Geodienste ist riesig und alte Träume könnten sich erfüllen zumindest in technischer Hinsicht! Ein Geoportal ist ein spezialisiertes Webportal für die Suche und den Zugriff auf Geodaten und Geodienste mit Hilfe eines Webbrowsers. Das Potenzial der Geodienste ist riesig und alte Träume könnten sich erfüllen zumindest in technischer Hinsicht! Nehmen wir den Fall des Leitungskatasters mit Hilfe von Geodiensten ist es möglich, mit einigen Klicks alle Infrastrukturen (Trinkwasserleitungen, elektrische Leitungen, Gasleitungen, usw.) an einem bestimmten geografischen Ort in einer kartografischen Anwendung zusammenzuführen (auf dem Büro-PC oder einem Feldcomputer) und diese zusammen mit den Daten der Amtlichen Vermessung zu visualisieren. Alle diese Geodaten stammen natürlich von verschiedenen aktualisierten Datenbeständen! Anwendungsserver Anwender Privates Geoportal WEB Browser «Thin client» NGDI Bundesgeoportal Geoportale Regionales Geoportal Geodienste GIS Software «Thick client» Kantonales Geoportal Kommunales Geoportal Die NGDI hat zum Ziel, die diversen Geodatenbanken zwischen Anwendern und Geodatenanbietern im Internet zugänglich zu machen. Man muss daher Brücken schlagen, um die bestehenden, oft isolierten Lösungen auf der Basis von technischen und fachlichen Standards zu vernetzen. Die Dateneigentümer der verschiedenen hierarchischen Ebenen (Bund, Kantone, Gemeinden und Private) zu vernetzen, um deren Daten zugänglich zu machen, das ist die Herausforderung einer nationalen Geodaten-Infrastruktur! Eigentümer und Anbieter von Geodaten Bezug zwischen Anwendern, Geoportalen mit Geodiensten und Geodatenbanken (vereinfachtes Schema) Man spricht von Interoperabilität, das heisst von der Fähigkeit der Zusammenarbeit zwischen heterogenen Informatik-Systemen, dank der Verwendung von gemeinsamen Sprachen und Protokollen und sich gegenseitig Ihre Ressourcen zugänglich zu machen. Es ist bekannt, dass dazu Normen unbedingt notwendig sind. Eine Sammlung von Standards ist demzufolge anzuwenden, einige spezifisch auf die Geodaten ausgerichtet, 4 Newsletter e-geo.ch 25 10/2010

5 G e o w e b d i e n s t e f ü r D u m m i e s Die Geodienste: ein bisschen Technik 5 Cédric Moullet, swisstopo Das Geoinformationsgesetz 1 gibt uns eine Definition der Geodienste; es handelt sich um vernetzbare Anwendungen, welche die Nutzung von elektronischen Dienstleistungen im Bereich der Geodaten vereinfachen und Geodaten in strukturierter Form zugänglich machen. Aus dieser Definition kann man den Begriff der Vernetzung herausgreifen: Wer Netz sagt, sagt Kommunikation zwischen Maschinen. Die Geodienste ermöglichen daher zwei Rechnern Geoinformationen auszutauschen. Ein anderer Punkt ist der Begriff der strukturierten Form: Darunter versteht man einen bestimmten Formalismus, der den Informationsaustausch beschreibt. Konkret handelt es sich dabei um Normen, die auf die Namen WMS, WFS, WMTS oder CSW lauten. Dieser Artikel hat zum Ziel, die allgemeinen Grundsätze der Geodienste vorzustellen. Diese werden dann in den folgenden Artikeln einzeln beschrieben. Wer Netz sagt, sagt Kommunika tion zwischen Maschinen. Kommunikation in den Netzen Um die nachfolgenden Ausführungen zu veranschaulichen, nehmen wir die Kommunikation zwischen zwei Menschen: Diese unterliegt einer gewissen Anzahl Grundregeln. Werden wir mündlich, schriftlich, über Chat, durch Zeichen, über Twitter, Blog oder durch Rauchzeichen kommunizieren? Nachdem diese Grundregeln festgelegt worden sind, geht es darum, eine Kommunikationssprache zu definieren. Bei der Kommunikation zwischen Maschinen findet man dieselben Aspekte. Die Grundregeln der Kommunikation im Internet werden durch das HTTP-Protokoll festgelegt. Dieses Protokoll kann in verschiedener Weise angewandt werden, so dass dadurch mehrere Sprachen entstanden sind. Was die Geodienste anbelangt, sind KVP, SOAP und REST die gängigsten Sprachen. Auf dieselbe Weise wie zwischen Menschen kann der Austausch von Inhalten (oder von Informationen) erst beginnen, nachdem die Grundregeln und die Sprache definiert worden sind. Die Normen (WMS, WFS, WMTS oder CSW), welche den Inhalt und die Bedeutung des Inhalts beschreiben, greifen auf dieser Ebene ein. Das HTTP-Protokoll Wenn es etwas gibt, was Sie jeden Tag verwenden (ach, Sie wussten es nicht? ;-) dann ist es das HTTP-Protokoll (Hypertext Transfer Protocol2). Jedes Mal, wenn Sie Ihren Navigator öffnen und eine Adresse eingeben ( verwenden Sie das HTTP-Protokoll um eine Seite des World Wide Web zu visualisieren. Damit nehmen Sie implizit die Ressource eines entfernten Servers in Anspruch und stellen eine Kommunikation zwischen Ihrem Computer und diesem Server her. Dieses Protokoll bietet mehrere Methoden an. Im Rahmen der Geodienste werden im Wesentlichen zwei Methoden angewandt: Die Methode GET: das ist die Standardmethode, die es ermöglicht, den Inhalt einer Ressource wie meineschoeneseite.html zu erhalten. In diesem Fall ersucht der Navigator den Server, ihm die Seite mabellepage.html zur Verfügung zu stellen. Die Methode POST: diese Methode ermöglicht es dem Server, eine Information zu übermitteln. Damit wird man eine Information an eine bestimmte Adresse «aufgeben», die dann vom Server bearbeitet werden wird. Die Sprachen KVP, SOAP und REST Die Sprachen verwenden das HTTP-Protokoll und legen fest, in welcher Weise die Informationen zwischen dem Server und dem Kunden ausgetauscht werden KVP KVP bedeutet Key-Value pair. Ein Übersetzungsversuch wäre «Schlüssel-Wert Paar». Tatsächlich geht es darum, einer Web-Adresse eine bestimmte Anzahl Parameter hinzuzufügen, wie zum Beispiel: meineschoeneseite.html?farbederseite=blau& Version=28 In diesem Beispiel definiert man zwei Schlüssel (FarbeDerSeite und Version) und ordnet diesen Schlüsseln Werte zu. Der Server wird so diese Informationen lesen und entsprechend dieser Informationen antworten können. In diesem Fall wird die Methode HTTP GET angewandt. Die Antwort kann verschiedene Formen haben. Es kann zum Beispiel ein Bild oder eine html-seite sein. SOAP SOAP3 bedeutet Simple Object Access Protocol. Der Grundgedanke besteht darin, XML- Anweisungen (XML bedeutet Extensible Markup Language. Es handelt sich um ein Textdateiformat, das mit Hilfe von Tags strukturiert wird) an einen Server zu übermitteln, der ebenfalls mit Hilfe des XML-Formats antworten wird. In diesem Fall wird die Methode HTTP POST angewandt, da man eine Datei übermittelt. REST REST4 bedeutet Representational State Transfer. In der Praxis kommt REST KVP nahe, doch anstatt Schlüssel zu verwenden, findet sich die gesamte Information in der dem Server erteilten Adresse wieder. Um eine Parallele mit dem Beispiel von KVP zu ziehen, würde sich eine REST-Adresse wir folgt darstellen: In der Tat findet man dieselben Informationen wieder, aber in einer anderen Anordnung. Wie beim KVP kann die Antwort verschiedene Formen haben. Die Ausführungen dieses Artikels dienen nicht dazu, diese Sprachen zu vergleichen. Es ist klar, dass jede Sprache ihre Vor- und Nachteile hat. Den Informatik-Architekten obliegt es, diese richtig anzuwenden. In der Welt der Geodienste basieren die meisten Normen auf dem HTTP-Protokoll und auf den Sprachen KVP, SOAP oder REST

6 G e o w e b d i e n s t e f ü r D u m m i e s Standards und Profile Beispiel ech-0056 Anwendungsprofil Geodienste Peter Staub, swisstopo Was ist ein Standard? In praktisch jedem Bereich privater und beruflicher Tätigkeiten wollen wir zusammenarbeiten. Zusammenarbeiten können Menschen oder Systeme, wenn sie ein gemeinsames, standardisiertes Verständnis von der betreffenden Angelegenheit haben. Im Falle der Fähigkeit von Systemen, zusammenzuarbeiten, spricht man von so genannter Interoperabilität. In der einfachsten Form ist ein Standard also die vereinbarte Art und Weise, etwas zu tun. Typischerweise ist ein Standard als Dokument publiziert, in welchem die entsprechenden (technischen) Spezifikationen und Regeln festgeschrieben sind.1 Heute werden Standards von nationalen oder internationalen Gremien definiert, die oft «industriegetrieben» sind. Standards sind nicht per se global. Regionale technische Entwicklungen und auch kulturelle Aspekte prägen die Ausgestaltung und die Anwendung von Standards. In Abbildung 1 ist diese Problematik am Beispiel von Stromsteckern dargestellt. Um die Hürde der unterschiedlichen Standards zu überwinden, müssen entweder die Standards angepasst und global abgestimmt werden oder es braucht Mittel, um zwischen den verschiedenen Systemen zu transformieren. Standards können für bestimmte Anwendungszwecke auch präzisiert werden: mit (Anwendungs-)Profilen. Was ist ein Anwendungsprofil? Standards können häufig nicht in sinnvoller Weise direkt angewendet werden. Sie sind oft zu abstrakt oder auch zu allgemein; sie sind oft zu umfangreich; sie lassen sich schlecht auf örtliche, spezifische Anforderungen anwenden. Standards müssen also «profiliert» werden, um in einem speziellen Umfeld optimal ange wendet werden zu können und damit wiederum eine bessere Interoperabilität zu ermöglichen. Ein Profil eines Standards bedeutet eine Einschränkung oder eine Erweiterung der Spezifikationen dieses Standards. Im Allgemeinen enthält ein Standard zwingende Elemente, die natürlich auch in einem Profil ein gehalten werden müssen. In jedem Fall müssen die Regeln des Standards für das Einschränken und Erweitern eingehalten werden.2 In Abbildung 2 sind die beiden Akteure über eingekommen, die spezielle Ausprägung des Stan dards für Stromstecker gemäss Schweizer Standard (oder Anwendungsprofil) zu verwenden. Geodienste erlauben es, Informationen zu Geodaten über das Internet zu beziehen und zu nutzen, ohne dass ein Nutzer die entsprechenden Geodaten selbst besitzen muss. Im nächsten Abschnitt wird ein Profil für die Implementierung und die Anwendung von Geo diensten in der Schweiz näher betrachtet. ech-0056 Anwendungsprofil Geodienste Geodienste erlauben es, Informationen zu Geo daten über das Internet zu beziehen und zu nutzen, ohne dass ein Nutzer die entsprechenden Geodaten selbst besitzen muss. Zu diesem Zweck wurde vom Open Geospatial Consortium (OGC) eine Reihe von Standards entwickelt, die Schnittstellen und Kommunikationsprotokolle für Geodienste spezifizieren.3 Die meisten GIS unterstützen mittlerweile OGC-Spezifikationen, wodurch die Nutzung von Geodiensten allmählich Verbreitung findet. Im Rahmen der Entstehung der «Nationalen Geodaten-Infrastruktur» der Schweiz ist es ein Ziel, die breite Nutzung von Geodaten und die Interoperabilität zu fördern. Dafür ist die Verwendung von Geo diensten eine mögliche Lösung. Die direkte Anwendung der OGC- Spezifikationen würde aber zu einer sehr heterogenen Dienste-Landschaft führen, wodurch das Ziel der optimalen Interoperabilität nicht erreicht werden könnte. Damit Geodienste in der Schweiz so einheitlich wie möglich implementiert und genutzt werden, wurde ein Anwendungsprofil für eine Reihe von OGC- Standards entwickelt: der Standard ech-0056: Anwendungsprofil Geodienste4 (momentan in Überarbeitung). Das Anwendungsprofil enthält einerseits Richt linien, die zwingend einzuhalten sind, und andererseits Empfehlungen. Die Richtlinien schreiben u.a. vor, welche Version einer Dienst- Spezifikation mindestens unterstützt werden muss (z.b. WFS 1.0.0) oder welche Raumbezugssysteme mindestens unterstützt werden müssen (LV03, WGS84). Die Empfehlungen zielen auf die Anwendung aktueller Spezifikationen ab, die u.u. noch wenig etabliert sind, etwa die Unterstützung von LV95-Koordinaten oder die WMS-Version Schliesslich erhält ech-0056 durch die explizite Verweisung auf den Standard in Art. 7 GeoIVswisstopo eine spezielle rechtliche Bedeutung. Die Geodienste für Geobasisdaten des Bundesrechts müssen demnach ech-0056-konform sein. Quellen: 1 British Standards Institution, BSI: Online > Standards > About Standards. Zugriff: Donaubauer A.: Interoperable Nutzung verteilter Geodatenbanken mittels standardisierter Geo Web Services. Dissertation, TU München, Open Geospatial Consortium, OGC: Online Zugriff: ech-0056: Anwendungsprofil Geodienste. Online > Standards. Zugriff: Abb. 1: Vom Gleichen sprechen heisst nicht das Gleiche meinen. Abb. 2: Ein Anwendungsprofil spezifiziert die Anwendung eines Standards genau. 6 Newsletter e-geo.ch 25 10/2010

7 G e o w e b d i e n s t e f ü r D u m m i e s Web Map Services (WMS) Horst Düster, SO!GIS Unter einem OGC-konformen WMS versteht man eine Schnittstellenspezifikation des Open Geospatial Consortiums (OGC), die sowohl das Format der Anfrageoperationen als auch die entsprechenden Antwortformen standardisiert. Das Ziel dieser Spezifikation ist die in eine Service-Architektur eingebettete Auslieferung von Kartenbildern auf der Basis geografischer Informationen über das HTTP-Protokoll. Die Kommunikation erfolgt über XML. Im Rahmen der Spezifikationen kann ein WMS Karten aus Rasterdaten und Vektordaten visualisieren, die auf einem Kartenserver verfügbar sind. Der Kartenserver arbeitet dabei in einem normalisierten Rahmen, der unabhängig von Betriebssystemen, Programmiersprachen sowie Entwicklungs- und Softwareumgebungen ist. Zur Darstellung der angeforderten Karten wird eine Software benötigt, die via HTTP kommunizieren kann. Im einfachsten Fall genügt ein Internet- Browser. Mit einem WMS können Geodaten aus einem definierten Raumausschnitt als Kartenbild visualisiert und ausgewählte Eigenschaften der Daten abgefragt werden. Eine Analyse der Geodaten kann nicht vorgenommen werden. Der Nutzer kann einen WMS über seinen Webbrowser ansprechen, in dem die vom WMS gelieferte Karte dann angezeigt wird. Die notwendigen Informationen wie die Karte angezeigt werden soll werden mit der URL über Key Value Pairs (KVP) an den WMS übergeben. Das Ergebnis der Abfrage, also die Karte, wird vom WMS als Raster-Bild zurückgegeben und im Browser visualisiert. Moderne WebGIS und Desktop-GIS-Systeme unterstützen WMS. Zur Kommunikation mit einem WMS stehen drei grundlegende Requests zur Verfügung: GetCapabilities: Hiermit werden die Metainformationen des WMS abgefragt. Als Antwort wird ein XML-Dokument an den Benutzer zurückgeschickt, das neben allgemeinen Angaben zum Anbieter des WMS die unterstützten Ausgabeformate, angebotenen räumlichen Referenzsysteme sowie die Layer für die Karte beinhaltet. Beispiel: Request=GetCapabilities&Service=WMS&Version=1.1.1 Moderne WebGIS und Desktop-GIS-Systeme unterstützen WMS. GetMap: Liefert ein Kartenbild der angeforderten Daten basierend auf Raumausschnitten, räumlichen Referenzsystemen, Daten und Symbolspezifikationen. Beispiel: service=wms&version=1.1.1&request=getmap&layers =Orthofoto07& STYLES=&SRS=EPSG:21781&BBOX= ,243000,636500,245000& WIDTH=720&HEIGHT=480 &FORMAT=image/gif GetFeatureInfo: Ein WMS-Dienst kann Informationen zu einem bestimmten Punkt im dargestellten Kartenausschnitt liefern. Dies ist allerdings eine optionale Funktion die nicht jeder Server bereit stellt. Ob und wenn ja für welche Layer diese Anfrage zur Verfügung steht darüber gibt das GetCapabilities-Dokument Auskunft. Als Ausgabe liefert sie festgelegte thematische Informationen der zugrunde liegenden Daten. Beispiel: REQUEST=GetFeatureInfo&SERVICE=WMS&VERSION= 1.0.0&SRS=EPSG:21781&BBOX=633500,243000,636500, &WIDTH=720&HEIGHT=480&LAYERS= bdbed&query_layers=bdbed&x=200&y=150&info_ FORMAT=text/plain GetFeatureInfo results: Layer "bdbed" Feature : text = "Strassen, Wege, Gebäudeerschliessung" oid = " " art = "11" gmde_name = "Olten" archive = "0" zeitstand = " " Beispiel: «GetMap» 7

8 G e o w e b d i e n s t e f ü r D u m m i e s Ein Geodienst: Web Map Tile Service (WMTS) Cédric Moullet, swisstopo Die WMTS Anfragen WMTS unterstützt drei Anfragen und zwar GetCapabilities, GetTile und GetFeatureInfo. Die beiden ersten sind obligatorisch, während GetFeatureInfo optional ist. GetCapabilities Ziel der GetCapabilities-Anfrage ist es, Auskunft über den Inhalt des WMTS-Dienstes zu geben. Man kann diese Anfrage in drei verschiedenen Sprachen vornehmen: GetCapabilities gemäss KVP Ein Anfragebeispiel gemäss KVP ist: &request=GetCapabilities Die Parameter service, version und request werden zum Server gesendet. Dieser sendet eine XML-Datei, welche die Informationen über den WMS-Dienst enthält. GetCapabilities gemäss SOAP Eine Anfrage gemäss SOAP für GetCapabilities wird im «POST»-Modus vorgenommen. Ein Beispiel einer gesendeten XML-Datei ist: <?xml version="1.0" encoding="utf-8"?> <soap: Envelope xml ns:soap=" soap-envelope"> <soap: Body> <GetCapabilities service="wmts" xmlns=" opengis.net/ows/1.1"> <AcceptVersions><Version>1.0.0 </Version> </AcceptVersions> <AcceptFormats> <OutputFormat>application/xml </OutputFormat> </AcceptFormats> </GetCapabilities> </soap: Body> </soap:envelope> Die Antwort auf diese Anfrage präsentiert sich in Form einer gemäss SOAP strukturierten XML-Datei, welche die Informationen über den WMTS-Dienst enthält. GetCapabilities gemäss REST Eine Anfrage gemäss REST für GetCapabilities wird im «GET»-Modus vorgenommen. Ein URL Beispiel ist: In dieser URL findet man eine Versionsnummer des Dienstes, eine Anfrage (WMTSCapabilities) und eine Extension, die das Rücksendeformat angibt. Die Antwort auf diese URL ist eine XML-Datei, welche die Informationen über den WMS-Dienst enthält. GetTile Die GetTile-Anfrage gestattet einem WMTS- Kunden, eine Kachel anzufordern für eine bestimmte Pyramide einer bestimmten Schicht und gemäss einem bestimmten Format. Der WMTS Dienst sendet die beantragte Kachel zurück. Die Anfrage GetTile kann in mehreren Sprachen erfolgen. Beispiel eines Visualisierers, der einen WMTS Dienst nutzt, um die Luftbilder zu übertragen. Die Bibliothek OpenLayers ermöglicht die Anzeige der Daten. GetTile gemäss KVP Mehrere Parameter können dem WMTS-Server gesendet werden: service: Der Name des Dienstes, im vorliegenden Fall WMTS. Obligatorischer Parameter. request: Der Name der Anfrage, im vorliegenden Fall GetTile. Obligatorischer Parameter. version: Die Nummer der Version. Zurzeit ist die Version gültig. Obligatorischer Parameter. layer: Der Name des betreffenden Layers. Obligatorischer Parameter. style: Ein vom WMTS-Dienst zur Verfügung gestellter vordefinierter style Name. Obligatorischer Parameter. format: Das zurückzusendende Bildformat. Obligatorischer Parameter. tilematrixset: Ein Kachelsatz für den vor definierten Layer. Es handelt sich um eine Referenz auf die Gesamtheit der Pyramide. Obligatorischer Parameter. tilematrix: eine einer Zoomstufe des TileMatricSet entsprechende Kachelmatrix. Obligatorischer Parameter. tilerow: die Nummer der Kachel, gemäss der Achse der Abszisse. Obligatorischer Parameter. tilecol: die Nummer der Kachel, gemäss der Achse der Ordinate. Obligatorischer Parameter. dimensions: Die WMTS-Norm bietet die Möglichkeit keine, eine oder mehrere Grössen zu definieren. Es handelt sich zum Beispiel um eine zeitliche Information, wie das Datum der Dateneingabe. Ein Beispiel einer Anfrage gemäss KVP ist: GetTile&version=1.0.0&layer=etopo2&style=default&format= image/png&tilematrixset=wholeworld CRS 84&TileMatrix= 10m&TileRow=1&TileCol=3 In dieser Anfrage findet man die verschiedenen zuvor definierten Parameter wieder. In diesem Fall wurde keine Grösse präzisiert. Die Antwort auf diese Anfrage ist eine Kachel im PNG-Format. GetTile gemäss SOAP In einem web Kontext macht diese Lösung nicht viel Sinn, da eine Antwort gemäss SOAP die Einkapselung der Bilddaten in einer XML-Datei impliziert, was wenig logisch und wenig effizient ist. Deshalb wird diese Möglichkeit hier nicht dargestellt. Der WMTS 1, für Web Map Tile Service, ist ein Standard, der die Art und Weise beschreibt, wie man kartografische Daten in Form von vor definierten Tiles (Kacheln) übermittelt. WMTS ist eine Ergänzung zu WMS 2. Der Haupt vorteil des WMTS gegenüber dem WMS liegt darin, dass er bessere Leistungen bei der Übermittlung von kartografischen Daten bietet. Die Kehrseite der Medaille ist die geringere Flexibilität des WMTS. Der WMTS wird daher nicht empfohlen, wenn die Daten sehr häufig aktualisiert werden, oder wenn es erforderlich ist, eine Symbolisierung nach Wunsch anzubieten. Die Vorgenerierung der Kacheln impliziert, dass die Zoomstufen und die Symbolisierung vorab definiert werden und nicht nach Wunsch geändert werden können. 8 Newsletter e-geo.ch 25 10/2010

9 Coarse resolution Highest scale denominator GetFeatureInfo gemäss KVP Zusätzlich zu den Parametern der Anfrage GetTile, erscheinen drei neue Parameter: I: Die Position des Pixels der Kachel, gemäss der Achse der Abszisse. J: Die Position des Pixels der Kachel, gemäss der Achse der Ordinate. InfoFormat: das Format, in welchem die Informationen über die Objekte zurückgesendet werden. Ein Beispiel einer Anfrage gemäss KVP ist: Detailed resolution Lowest scale denominator Darstellung eines Tile Matrix Set mit mehreren Tile Matrix. GetFeatureInfo&version=1.0.0&layer=coastlines&style=default& format=image/png&tilematrixset=wholeworld_crs_84& TileMatrix=10m&TileRow=1&TileCol=3&J=86&I=132& InfoFormat=application/gml+xml; version=3.1 Man stellt fest, dass man die Kachel sowie die Position eines Pixels innerhalb dieser Kachel definiert. Ein Beispiel einer Antwort ist: TopLeftCorner TileMatrixMaxY TileMatrixMinY TileMatrixMinX TileRow axis Tile indices (TileCol, TileRow) 0,0 1,0 MatrixWidth 1,0 0,1 1,1 MatrixWidth 1,1 0, MatrixHeight 1 1, MatrixHeight 1 Darstellung einer Tile Matrix mit ihrem Ursprung oben links. MatrixWidth 1, MatrixHeight 1 TileWidth (in pixels) TileMatrixMaxX TileCol axis TileHeigth (in pixels) GetTile gemäss REST Eine Anfrage gemäss REST für GetTile wird im «GET»-Modus vorgenommen. Ein Beispiel einer URL ist: CRS 84/ 10m/1/3.png Gegenüber einer Anfrage gemäss KVP werden die Parameter einfach in der URL eingeordnet. Diese Vorgangsweise entspricht genau den Grundsätzen des Webs, d.h. dem Zugang zu Ressourcen mittels URLs und ist somit die effizienteste Art, Kacheln zu übermitteln. <?xml version="1.0" encoding="utf-8"?> <ReguralGriddedElevations xmlns=" etopo2" xmlns:gml=" xmlns:xsi =" xsi:schemalocation=" GetFeatureInfoExampleSchema.xsd"> <featuremember> <GridPoint_etopo2> <elevation>503.0</elevation> <TileRow>1</TileRow> <TileCol>2</TileCol> <J>86</J> <I>132</I> </GridPoint_etopo2> </featuremember> </ReguralGriddedElevations> Diese Antwort gestattet es, die Höhe eines bestimmten Punktes der Kachel zu kennen. GetFeatureInfo gemäss SOAP Eine Anfrage gemäss SOAP für GetFeatureInfo wird im «POST»-Modus vorgenommen. Die Antwort auf diese Anfrage wird in Form einer gemäss SOAP strukturierten Datei dargestellt, welche die Informationen über die beantragte Position enthält. GetFeatureInfo gemäss REST Eine Anfrage gemäss REST für GetFeatureInfo wird im «GET»-Modus vorgenommen. Ein URL-Beispiel ist: 10m/1/3/86/132.xml Gegenüber der Anfrage GetTile wird diese URL mit den Informationen über die Position innerhalb der Kachel sowie über das Format, in welchem die Informationen zurückgesendet werden, vervollständigt. 9 GetFeatureInfo Die optionale Anfrage GetFeatureInfo gestattet es einem WMTS-Kunden, eine Information über ein sich an einer bestimmten Position innerhalb einer Kachel befindliches Objekt zu beantragen. Der WMTS-Dienst sendet die beantragten Informationen zurück. Die Anfrage GetFeatureInfo kann in mehreren Sprachen vorgenommen werden

10 G e o w e b d i e n s t e f ü r D u m m i e s API Programmierschnittstellen David Oesch, Projektleiter geo.admin.ch, KOGIS, swisstopo Wie in jeder Nachbarschaft werden von Zeit zu Zeit Dinge wie ein Rasenmäher ausgeliehen. Einleitung Daten mit Raumbezug werden immer öfter auf interaktiven Webseiten eingebunden, um diese visuell als Kommunikationsmittel zu nutzen. Kartendarstellungen haben ausserhalb des Internets (sozusagen in einer offline-version) eine historisch wichtig Bedeutung in der Informationsvermittlung: Sie stellen eine Art der Darstellung dar, die am schnellsten verstanden wird. Mit Hilfe von webbasierten Kartendarstellungen (z.b. map.geo.admin.ch) und entsprechenden zur Verfügung gestellten APIs (wie zum Beispiel API von map.geo.admin.ch1) ist es möglich, dynamische Karten auf der eigenen Webseite zu inte grieren: Konkret können Standorte damit einfach lokalisiert werden und mit weiteren georeferenzierten Daten überlagert werden. Was ist ein API? Die Abkürzung API (engl. application programming interface, dt. «Schnittstelle zur Anwendungsprogrammierung») steht für eine Programmierschnittstelle. Diese stellt einen eigentlichen Programmteil dar, der von einem Softwaresystem anderen Programmen zur Anbindung an ein System zur Verfügung gestellt wird.2 Aus konzeptioneller Sicht ist ein API eine abstrakte Beschreibung einer Schnittstelle mit vordefinierten Funktionen. Die Software selbst, die die Funktionen zur Verfügung stellt, wird als eine Implementierung des API bezeichnet. Der Begriff API kann verwendet werden, um eine Schnittstelle, eine einzelne Funktion oder eine Sammlung von APIs einer Organisation zu bezeichnen. Daher ist dessen Zweck normalerweise durch den Kontext, in welchem es genutzt wird, bestimmt. Eine ganz einfache Erklärung ist in Tabelle 1 aufgeführt. Wie funktioniert ein API? Bei Webanwendung besteht ein API aus Quellcode. Dieser erlaubt es dem Eigentümer einer Webseite seine eigene Anwendung aufzubauen: Der eingebaute Quellcode schickt eine Ansammlung vordefinierter Anfragen ab und die Rückgabeparameter werden entsprechend den Bedürfnissen weiterverarbeitet. Es gibt eine grosse Anzahl an Geodiensten, welche Informationen durch HTTP-Anfragen übermitteln. Ein «Web-API» wird häufig als Synonym für einen solchen Webdienst gebraucht: Der momentane Trend (auch «Web 2.0» genannt) bewegt sich weg von SOAP zu den direkteren REST basierten Diensten. Aus diesen (Geo)Diensten lassen sich dann interaktive (Karten)Anwendungen zusammenbauen. Ein API bietet in diesem Sinne als Funktion eine vereinfachte Nutzung von bestehenden Geodiensten an. API in Kürze3 Tab. 1: API in Kürze API eine Programmierschnittstelle ist ein weit dehnbarer Begriff, der von Entwicklern und Anbietern gleichermassen als Wundermittel für Probleme jeglicher Art verkauft wird. Trotzdem können APIs sehr einfach und leistungsstark sein. Sie sind in der täglichen Nutzung des Internets nicht mehr wegzudenken, und kommen meistens dort zum Einsatz, wo auf einen bestimmten Dienst (sei es WMS; REST, SOAP etc) zugegriffen wird. Generell bieten APIs weniger Flexibilität als offener Quellcode aber mehr als geschlossene Anwendungen an. Stellen Sie sich vor, Sie haben drei Nachbarn: «Geschlossener Gustav», «Offener Oskar» und «API Anna». Jeder von ihnen ist wie eine Computeranwendung. Wie in jeder Nachbarschaft werden von Zeit zu Zeit Dinge wie ein Rasenmäher ausgeliehen. Dies entspricht der Integration von Anwendungen. Geschlossener Gustav: Er wird Ihnen gar nichts auslehnen, mäht seinen eigenen Rasen hinter einem hohen Zaun. Sie können ihn nicht um etwas bitten, da es nicht einmal ein Gartentor in seinem Zaun gibt. Eine Anwendung wie Geschlossener Gustav stellt keinen Quellcode oder API zur Verfügung. Offener Oskar ist das Gegenteil: Er ist so offen, dass Sie seinen Garten und Mäher immer nutzen können, ja sogar den Mäher umkonfigurieren können. Wenn Sie diesen aber stärker abändern, als das Handbuch es zulässt, sind Sie später für dessen Unterhalt zuständig. Eine Anwendung wie Offener Oskar hat einen offenen Quellcode, Sie können damit machen was Sie wollen. API Anna lässt Sie ihren Mäher nutzen, wenn Sie in der richtigen Art und Weise fragen (mit dem Befehl «getmower» in der eigenen Anwendung). Sie können die Tür zu ihrem Garten ohne diese Anfrage nicht öffnen und können den Mäher nicht umkonfigurieren. Aber Sie können, wann immer Sie wollen rasenmähen. Anwendungen wie API Anna sind geschlossen, haben aber ein API und sind im Internet sehr häufig anzutreffen. 10 Newsletter e-geo.ch 25 10/2010

11 Abb. 1: Einfache Standortmarkierung auf Karten hintergrund (gelb). Abb. 2: Konfiguration für Beispiel in Abbildung 1. Der Nutzer muss dazu nur die Koordinaten in «easting: , northing: » anpassen und die Zoomstufe über «zoom: 8» setzen. Aus konzeptioneller Sicht ist ein API eine abstrakte Beschreibung einer Schnittstelle mit vordefinier ten Funktionen. Das API von geo.admin.ch zum Beispiel ist ein Javascript client API und verknüpft folgende Programmkomponenten: Openlayers für Kartendarstellung, ExtJs für die Benutzeroberfläche und GeoExt für Räumliche Suche und Verknüpfung der Komponenten selbst. Das API erlaubt Bundesbehörden nebst den Funktionen auch zusätzlich den Zugang zu allen räumlichen Daten von map.geo.admin.ch. Mit der bestehenden Lösung werden die Bundesstellen untereinander vernetzt. 11 Wie profitiert man von einem API? Für den konkreten Einsatz des API von geo.admin.ch beispielsweise sprechen folgende Punkte: Verfügbarkeit der Daten aus geo.admin.ch: homogene Daten über das gesamte Gebiet der Schweiz. Hochperformanter Kartenaufbau, wiederverwendbare komfortable Navigation/Benutzeroberfläche. Hohe Interoperabilität durch die Unterstützung von gängigen Standards und die Veröffentlichung des Quellcodes des API. Keine oder geringe Kosten für Infrastruktur, keine Kosten für die Aktualisierung der Daten. Grosses Weiterentwicklungspotenzial, angetrieben durch die OpenSource Community der verwendeten Komponenten OpenLayers, GeoExt, ExtJS etc. Praktisches Beispiel Bei Web APIs für Kartendarstellungen (Abbildung 1, Beispiel Standortmarkierung) muss in den meisten Fällen nur der HTML Quellcode einer Website (Abbildung 2,) editiert werden. Dies ist auch ohne Programmierkenntnisse möglich, da in den meisten Fällen die Anbieter von APIs «Kochbuchrezepte» zur Verfügung stellen, in denen nur noch gewünschte Werte angepasst werden müssen. Beim API von geo.admin.ch eröffnen sich mit simplen Standortmarkierungen (Abbildung 1) über Datensatzkombination bis zu Integration im Felde erfasster Daten mittels GPS fast unendlich viele Anwendungsmöglichkeiten. Weitere Beispiele finden Sie unter geo.admin.ch im Abschnitt API geoservices/display_services/api_services.html Programming_Interface?taxonomyId=11&pageNumber=2 4 geoservices/display_services/api_services.html

12 G e o w e b d i e n s t e f ü r D u m m i e s Der Geosuchdienst Die Schatzkarte des Piraten Jack Rackham gehört uns! André Schneider, swisstopo Die heroischen Zeiten, in denen tollkühne und beharrliche Abenteurer auf Schatzsuche gingen, sind längst vergangen. Es ist nicht mehr notwendig, unbesonnene Risiken einzugehen, um als Erster die Beute zu ergreifen! Heute steht der Schatz allen unbegrenzt zur Verfügung! In der Tat, ein Dienst stellt die so begehrten Schatzkarten im Internet gratis zu Verfügung! Der Schatz hat natürlich nichts mit goldenen Münzen zu tun, sondern mit Geodaten und die Schatzkarten mit Metadaten (das heisst die Beschreibung der Geodaten). Bei diesem friedlichen Dienst man muss ja nicht mehr gegen böse Piraten kämpfen handelt es sich um den CSW, «Catalog Service for the Web», einen OGC1- Standard. Der Katalogdienst wird gemeinhin auch Suchdienst genannt. Er taucht übrigens mit dieser letzteren Bezeichnung in der Verordnung über Geoinformation auf (GeoIV, Art. 2 h): Suchdienst: Internetdienst, mit dem nach Geo diens ten und, auf der Grundlage entsprechender Geometadaten, nach Geodatensätzen gesucht werden kann. Ein klassischer Anwendungsfall des CSW besteht aus den folgenden drei Anfragen (bei jedem Beispiel steht jeweils am Anfang die URL des Servers mit dem entsprechenden Suchdienst): 1. Bevor ich diesen neuen Geodienst auspacke, lese ich die Gebrauchsanweisung, welche ich mittels der Operation GetCapabilities erhalte. So kann ich unter anderem die allgemeine Beschreibung des Dienstes, die verwendbaren Operationen und Parameter, sowie die verfügbaren Suchkriterien in Erfahrung bringen. Beispiel für den Aufruf dieser Operation: request=getcapabilities&service=csw 2. Ich konzentriere mich dann auf die verfügbaren Schatzkarten mittels der Operation GetRecords, indem ich zum Beispiel folgende Frage stelle: Was hat Jack Rackham alles zur Verfügung gestellt? Beispiel: request=getrecords&service=csw&resulttype= results_with_summary&namespace=csw: opengis.net/cat/csw/2.0.2&typenames=csw:record &constraintlanguage=filter&constraint_language_ version=1.0.0&constraint= <ogc:filter xmlns:ogc=" <ogc:propertyisequalto> <ogc:propertyname>creator</ogc:propertyname> <ogc:literal>rackham</ogc:literal> </ogc:propertyisequalto> </ogc:filter> Als Antwort erhalte ich eine Liste aller Schatzkarten von Jack Rackham. Diese sind dort in Kurzform beschrieben, zum Beispiel mit dem Titel, einer kleinen Beschreibung und einem Identifikator. Wenn Sie unser Beispiel ausprobieren, werden Sie sehen, dass Jack Rackham bis heute nur einen einzigen seiner Schätze preis gegeben hat 3. Der Identifikator gestattet mir, die detaillierten Informationen zu erhalten, das heisst die besagte Schatzkarte von Jack Rackham. Dazu verwende ich die Operation GetRecordById, die mir den vollständigen entsprechenden Metadatensatz ausgeben wird. Beispiel: request=getrecordbyid &outputschema=gm03_2record2 &id=2dbf2179-1f51-463a-a1f0-bb9b4c43e7ae Konkret gesagt, die sinnvolle Anwendung dieses Geosuchdienstes besteht darin, diesen direkt vor einem Geodienst zur Darstellung (WMS, WMTS) oder zum Downloaden von Geodaten (WFS), zum Beispiel in der Implementierung eines Geoportals, zu nutzen. Dies gestattet dann den direkten Zugang zu der in unserer Schatzkarte eingezeichneten Beute. Im Rahmen eines Geoportals wird ein Geosuchdienst (Suche nach Geodaten) manchmal mit einem Geolokalisierungsdienst (Suche nach Standorten), verwechselt. In der Schweiz ist dieser Geosuchdienst via geocat.ch verfügbar, was durch die verschiedenen obigen Beispiele gut ersichtlich ist. Zurzeit sind dort ungefähr 3500 Schatzkarten verfügbar, aber viele mehr werden dort noch veröffentlicht werden, um eine optimale Nutzung des künftigen nationalen Geoportals zu gewährleisten. Die Vorteile eines Geodienstes gegenüber einer Such-Applikation sind vor allem folgende: Die Suche und die Verwaltung der Metadaten können direkt in den Prozessen, die Metadaten verwenden, integriert werden. Ein individuelles Layout kann für die Darstellung der Metadaten verwendet werden. Mit dem Geodienst CSW können wir uns nicht nur bereichern sondern auch unsere Werte in Bezug auf Grosszügigkeit und Teilungsbereitschaft in den Vordergrund stellen. Tatsächlich kann man dort seine eigenen Schatzkarten eingeben und editieren, damit diese für alle zugänglich sind. Dies kann direkt via Dienst, ohne Verwendung der Erfassungsapplikation geschehen. Die hierfür zuständige Operation lautet Transaction. Die Nutzung und Implementierung dieser Operation ist jedoch zurzeit noch sehr wenig verbreitet. Durch diese Funktionalität wird dann auch die Bezeichnung Katalogdienst («Catalog Services» nach OGC) passender als die Bezeichnung Suchdienst. «Il vaut mieux savoir tout chercher que chercher à tout savoir.» P. Mendelson 12 Newsletter e-geo.ch 25 10/2010

13 In diesem Artikel wurden nur die am häufigsten verwendeten Operationen veranschaulicht. Eine vollständigere Dokumentation, die auch die übrigen Operationen beleuchtet und erklärt, ist auf geocat.ch3 oder direkt in den Spezifikationen des OGC4 verfügbar. Technisch gesehen kann dieser Geodienst mit den Sprachen KVP, SOAP und REST5 verwendet werden. 1 Open Geospatial Consortium 2 Mit dem Schema «GM03Record» werden die Informationen im GM03-INTERLIS-XML-Format ausgegeben. Es sind allerdings noch weitere Formate möglich. Die vollständige Dokumentation finden Sie unter csw.html 3 csw.html siehe Artikel von Cédric Moullet «Die Geodienste: ein bisschen Technik», S. 5 Viel Freude bei Ihrer Suche! G e o w e b d i e n s t e f ü r D u m m i e s Cloud Computing 13 Hanspeter Christ, swisstopo Abb. 1: Gartner s Emerging Technologies Hype Cycle für das Jahr 2010 Spätestens seit Gartner, eines der renommiertesten Unternehmen in der Marktforschung und Analyse der weltweiten Technologie-Industrie, in seinem bekannten und jährlich erscheinenden Emerging Technologies Hype Cycle für das Jahr 2010 Cloud Computing zum Haupttreiber der IT-Industrie erklärt hat, führt an diesem Buzzword im IT-Sektor kein Weg mehr vorbei. Doch was ist überhaupt Cloud Computing? Cloud Computing ist in erster Linie eine neue Form der bedarfsgerechten und flexiblen Bereitstellung von IT-Leistungen. Es ist keine neue Technologie, sondern eine direkte Folge der konsequenten Weiterentwicklung bereits bestehen der etablierter Technologien, allen voran der Servervirtualisierung und der Webservices. Für den Nutzer von IT-Ressourcen ist diese Entwicklung insofern äusserst attraktiv, weil dieser die zur Befriedigung seiner Unternehmensanforderungen notwendigen Kapazitäten für Daten, Rechenleistung und Anwendungen nun sozusagen in Echtzeit als «Service aus dem Netz» beziehen kann und diese nicht mehr selbst über teils langwierige Prozesse anschaffen muss. Betriebswirtschaftlich gesehen führt das für die Verrechnung von Cloud Services übliche «pay as you go Abrechnungssystem» zu einer Umlagerung von Investitionskosten (CapEx) zu reinen Betriebskosten (OpEx), was sich auch auf die Innovationskraft des Unter nehmens äusserst positiv auswirken kann, da die in klassischen IT-Projekten häufig sehr hohen Vorab-Investitionskosten für IT-Infrastruktur wegfallen. Eine generell akzeptierte einheitliche Definition für Cloud Computing konnte sich bisher noch nicht etablieren. Nichtsdestotrotz scheinen sich aber in den letzten Monaten gewisse Klassifizierungsansätze fürs Cloud Computing durchzusetzen. Klassifizierung unter Betriebs- Eigentums- und Organisationsaspekten Unter Betriebs-, Eigentums- und Organisa tionsaspekten können Private Clouds (für eine geschlossene Nutzergruppe) und Public Clouds (für eine grosse Anzahl verschiedener Nutzer) unterschieden werden.1 Von sogennanten Hybrid Clouds spricht man, wenn eine Organisation zum Betrieb ihrer Businessapplikationen sowohl auf Public als auch Private Clouds zurückgreift, wobei sie zum Beispiel die Kernapplikationen mit schützenswerten Daten in der Private Cloud und weniger kritische Anwendungen in der Public Cloud betreibt. Klassifizierung unter Governanceaspekten2 Infrastructure as a Service (IaaS) Unter IaaS versteht man ein Geschäftsmodell, das entgegen dem klassischen Kaufen von Rechner infrastruktur («Mein Server steht in meinem Keller») vorsieht, diese on demand zu mieten. Daraus ergeben sich eine Vielzahl von Anwendungsmöglichkeiten, u.a.: Belastungsspitzen werden abgefangen plötzliches Wachstum ist ohne Probleme möglich (Skalierbarkeit) brachliegende Kapazitäten können sofort wieder freigegeben werden einmalige oder selten ausgeführte Anwendungen werden bezahlbar die vorhandene Virtualisierungstechnologie ermöglicht ein einfaches Softwaretesting auf den unterschiedlichsten Plattformen Die bekannteste Anwendung von IaaS ist wohl Amazon EC2.

14 Platform as a Service (PaaS) Unter PaaS versteht man den Ansatz, eine integrierte Laufzeit- und evtl. auch Entwicklungsumgebung als einen Dienst zur Verfügung zu stellen, für den der Nutzer on-demand zahlen muss. Ein bekanntes Beispiel dafür ist die Google App Engine. Software as a Service (SaaS) Unter SaaS versteht man ein Geschäftsmodell, Software nicht länger als Lizenz an einen Benutzer zu verkaufen, sondern lediglich die Benutzung selbiger als Service zur Verfügung zu stellen. Vergleichbar ist dieser Unterschied mit dem Unterschied zwischen einem Autokauf und einem Mietwagen, da dort ebenfalls eine Abrechnung «per use» erfolgt. Als Beispiele für Software as a Service wären Google Docs und der CRM-Anbieter Salesforce.com zu nennen. Insbesondere bei Infrastructure as a Service (IaaS) spricht man häufig auch von «Datacenter Abstraction». Konkret ist damit gemeint, dass dem Cloud Computing Benutzer via eine in der Regel über Internet verfügbare Programmierschnittstelle (API) jederzeit Zugriff auf die aus Benutzersicht praktisch unbegrenzt vorhandenen IT-Ressourcen der riesigen Rechenzentren global agierender Cloud Computing Anbieter wie Amazon, Microsoft oder Google gewährt wird. Es erstaunt wenig, dass bei diesem neuartigen globalen IT-Betriebsmodell nicht nur technische, sondern insbesondere bei grösseren Unternehmen und öffentlichen Verwaltungen auch juristische Herausforderungen betreffend Gerichtsstand, Datenschutz, Governance, Compliance, etc. zu meistern sind. Um erste Erfahrungen mit (Public) Cloud Computing zu sammeln, empfiehlt es sich also, einen Anwendungsfall zu wählen, der keine vertraulichen Unternehmensdaten oder sensiblen Kundendaten enthält, um nicht bereits bei der hausinternen Rechtsabteilung abzublitzen. Traditionelle IT-Organisation (On Premise) Abb. 2: Einfluss der verschiedenen Cloud Computing Modelle auf die Governance von IT-Organisationen 3 Clients Infrastructure as a Service (IaaS) Caching-Reverse-Proxy Applikationscluster geo.admin.ch (für dynamische Inhalte) EC2 Platform as a Service (PaaS) Management Server (Monitoring) Storage Cluster (für statische Karten-Tiles) HTTP Verschiedene Protokolle S3 Software as a Service (SaaS) Anwendungen/Services Anwendungen/Services Anwendungen Anwendungen Virtualisierung Virtualisierung Services Services Server Server Server Server Datenspeicher Datenspeicher Datenspeicher Datenspeicher Netzwerk Netzwerk Netzwerk Netzwerk IT-Organisation hat Kontrolle (Verantwortung) IT-Organisation teilt Kontrolle (Verantwortung) mit dem Cloud Computing Anbieter Cloud Computing Anbieter hat Kontrolle (Verantwortung) Tileforge (Datenintegration) swisstopo setzt in ihrer Rolle als GIS-Fachleistungserbringer des Bundes im Rahmen der Umsetzung des seit Juli 2008 in Kraft getretenen Geoinformationsgesetzes (GeoIG) bereits seit mehreren Monaten erfolgreich auf die Infra structure-services EC2 (Rechenleistung on-demand) und S3 (Speicherplatz on-demand) von Amazon Web Services (AWS). Die primär fürs Geoportal des Bundes geo.admin.ch in der Amazon-Cloud aufgebaute Infrastruktur ermöglicht es swisstopo, schnell und einfach zu skalieren und damit auf kurz- und langfristige Lastschwankungen (z.b. infolge von Pressemitteilungen oder saisonalen Fluktuationen) zu reagieren. Die hierfür anfallenden Kosten sind tief, da einerseits nur die effektiv benötigte Serverzeit verrechnet wird und andererseits aufgrund der konsequenten Verwendung von Open Source Software ohne kostenpflichtige Lizenzen beim Skalieren keine lizenzbedingten Abb. 3: Infrastruktur des Geoportals geo.admin.ch in der Amazon-Cloud Mehrkosten entstehen. Neben der geringen Kosten profitiert swisstopo auch vom Umstand, dass sie sich nicht mehr mit physikalischer Hardware im Internet herumzuschlagen braucht und die dadurch frei werdenden Personalressourcen in zukunftsorientierte Entwicklungen ihres Kerngeschäfts investieren kann. 1 Willy Müller/Uwe Heck, Vorstudie zu Cloud Computing in Schweizer Behörden, Version 1.0, 15. August Service_.28IaaS.29 3 Cloud Security and Privacy, by Tim Mather, Subra Kumaraswamy, and Shahed Latif, ISBN Newsletter e-geo.ch 25 10/2010

15 Innovation trifft Geschichte: 8. e-geo.ch Forum zu Gast in Zürich René Sonney, e-geo.ch Zum 8. Mal bietet das e-geo.ch Forum allen im Bereich der Geoinformation tätigen Akteuren eine ideale Plattform für ihren Erfahrungs- und Informationsaustausch. Die Stadt Zürich ist Gastgeberin für das am Freitag, dem 12. November 2010 stattfindende Forum. Auch wenn sich dieses Forum vor allem an die Charta-Unterzeichner richtet, steht es dennoch allen Interessierten offen. Die Teilnehmenden werden zudem die Gelegenheit haben, die beiden historischen Gebäude des Rathauses und des Zunfthauses zur Safran kennen zu lernen. Das Vormittagsprogramm findet im Zürcher Rathaus statt. Nach dem Empfang durch die Stadt Zürich werden die Teilnehmer über die wesentlichen Aktivitäten des e-geo.ch- Programms informiert, insbesondere über die zwischen dem Bund und den Kantonen abgeschlossene egovernment-sonder vereinbarung, das Projekt «Nationales Geodatenportal», das Projekt «Monitoring der NGDI». Nach der Verleihung des/der e-geo.ch Preise(s) werden unsere deutschen Kollegen ihre Erfahrungen mit der «GDI-DE», deren Struktur die obenerwähnte Vereinbarung stark inspiriert hat, mit uns teilen. Das Mittagessen wird im Zunfthaus zur Safran stattfinden und im Anschluss daran werden in denselben Lokalitäten zwei Workshops mit folgenden Themen angeboten: das nationale Geodatenportal die Modellisierung von Geodaten Sie finden das detaillierte Programm sowie das Anmeldeformular auf der Website e-geo.ch. Melden Sie sich doch bitte am besten gleich an, falls sie es nicht bereits getan haben, die Anmeldefrist läuft bis zum 30. des laufenden Monats. Ich freue mich, Sie bei dieser Gelegenheit zu treffen. Das Zunfthaus zur Safran Das Zürcher Rathaus 15

16 zum Einführung Sensibilisierung Initialisierung Realisierung Einführung minimales Geodatenmodell Sensibilisierung Initialisierung Realisierung Impressum Newsletter e-geo.ch 25 Oktober 2010 Auskünfte: e-geo.ch c/o Bundesamt für Landestopografie Seftigenstrasse 264, Postfach CH-3084 Wabern Telefon Fax Herausgeber: e-geo.ch Redaktion: René Sonney, e-geo.ch Konzept: MKR Consulting AG, Bern Gestaltung: Atelier Ursula Heilig SGD, Gümligen Druck: swisstopo Auflage: 2450 Exemplare (1800 deutsch, 650 franz.) Bilder: swisstopo, KOGIS, e-geo.ch, Autoren Antworttalon Sie können die Antwortkarte faxen ( ) oder Ihre Bestellung mailen an Immer aktuell informiert über das Programm e-geo.ch: Bitte senden Sie uns regelmässig den Newsletter e-geo.ch: Anzahl Exemplare deutsch Anzahl Exemplare französisch per Post per Bitte senden Sie uns die Broschüre «Das Umsetzungskonzept zur Strategie für Geoinformation beim Bund»: Anzahl Exemplare deutsch Anzahl Exemplare französisch Bitte senden Sie uns die Charta e-geo.ch: Anzahl Exemplare deutsch Anzahl Exemplare französisch Bitte senden Sie uns die Broschüre «Empfehlungen zum Vorgehen bei der Harmonisierung von Geobasisdaten»: Anzahl Exemplare deutsch Anzahl Exemplare französisch mit Checkliste Empfehlungen Vorgehen bei der Harmonisierung von Geobasisdaten in Fachinformationsgemeinschaften Organisation/Firma Name, Vorname Adresse