Wer sich mehr in die Thematik vertiefen will, dem sei die Lektüre von “Umsetzung des Katasters der öffentlich-rechtlichen Eigen-tumsbeschränkungen im Kanton Bern“, der Masterarbeit meines Amtschefs im AGI empfohlen.

Dieses Jahr hat sich natürlich alles um das bevorstehende ArcGIS 10 gedreht. Es hat sich auch gezeigt, dass die Umbenennung von ArcGIS 10 auf 9.4 doch berechtigt war. Es ändert sich doch so einiges.

ArcGIS Server

Obwohl angekündigt wurde, dass eigentlich 9.3.1 das Server-Release war, gibt es doch auch im Server-Bereich einige sehr interessante Neuerungen:

• neue Versionen (2.0) aller Web APIs (Flex, Javascript, Silverlight) mit vielen neuen Möglichkeiten.
• Über die REST API kann neu auch editiert werden (Feature Layers). Das ist ein wichtiger Fortschritt. Noch nicht sicher bin ich, auf welchem Lizenzlevel dieses Editieren verfügbar sein wird.
• In der REST API sind nun auch Informationen über Legenden und Symbologie verfügbar.
• Die SOAP und die REST API können über eigene Mechanismen erweitert werden.
• ein neuer Extract Service, mit dem Geodaten extrahiert, in das passende Format umgewandelt und auch gleich gezippt werden können.
• Im WMS-Bereich werden nun alle SLD-Funktionen unterstützt, v.a. auch der Befehl GetLegendGraphic.

Aufgefallen ist mir die Tatsache, dass praktisch nichts über das Web ADF zu hören war. Ich gehe davon aus, dass ESRI die Zukunft im Server-Bereich eher bei den neuen Web APIs sieht, als beim Web ADF. Ich habe das Gefühl, dass das Web ADF etwas auf dem Abstellgleis steht.

Was auch erwähnt wurde, ist die Tatsache, dass der Server auch in ArcGIS 10 kein 64bit-Produkt sein wird. ESRI hat jedoch bestätigt, dass an einer solchen Version entwickelt wird (development project). Es besteht also Hoffnung.

ArcGIS Mobile

Hier ist sehr vieles im Umbruch. Bisher basierte ArcGIS Mobile auf Windows Mobile. Das wird sich ändern. ESRI wird neu auch aktuelle Plattformen wie iPhone, Android oder Windows Phone 7 unterstützen. Als erste Plattform startet das iPhone. Hier bietet ESRI eine out of the box-App (via Apples App Store) sowie ein SDK zur Entwicklung eigener Applikationen. Die weiteren Plattformen folgen später.

ArcGIS Desktop

Hier sind die interessantesten Neuerungen zu finden:

• überarbeitete GUI, d.h. dockable windows (die sich verschieben lassen, ohne dass die Karte refreshed wird), ArcCatalog als dockable window in ArcMap etc.
• die Python-Integration wurde komplett überabeitet. Das Python-Fenster in ArcMap ist nun mit Intellisense (automat. Befehlsvervollständigung sowie Online-Hilfe) ausgestattet. Geoprocessing-Befehle (Scripts, Models oder Tools) können nun im Hintergrund ablaufen, so dass der Anwender weiterarbeiten kann. Und mit arcpy.mapping wird eine der bislang grössten Limitationen von ArcGIS beseitigt: das Manipulieren von MXD-Dokumenten. Bisher ging das nur mit ArcObjects und war sehr mühsam. Neu können MXDs (inkl. Inhalte wie Layer, Tables, Layout-Elemente etc.) angesprochen und manipuliert werden. Es wird also möglich sein, die Datenquellen von Layern automatisiert ändern zu lassen. Das ist eine sehr wichtige Hilfe gerade in Migrations-Szenarien. Da jedoch Python auch weiterhin kein ArcObjects-Ersatz sein soll (coarse grained), gibt es auch hier noch einige mehr oder weniger bedauernswerte Lücken. So können Layer-Einstellungen wie Symbologie oder Massstabsbereiche (scale dependent rendering) nicht manipuliert werden. Nichtsdestotrotz ist arcpy.mapping ein grosser Schritt nach vorne.
• Es gibt eine neue Art von Erweiterungen: die Add-Ins. Diese können in .NET oder Java (später vielleicht auch in Python) programmiert werden. Die Erweiterung können wie bisher die gesamte Bandbreite der ArcObjects nutzen. Die Installation ist vereinfacht worden. Die Add-Ins bestehen aus einer einzigen Datei (eine gezippte Datei), die nur ins richtige Verzeichnis kopiert werden kann. ArcGIS überwacht dieses Verzeichnis und lädt bei Bedarf die Applikation. Es sind somit für die Installation keinerlei Adminrechte mehr oder Einträge in die Registry mehr nötig. Das Add-In-Verzeichnis kann auf dem lokalen Filesystem aber auch auf einem Netzwerk-Laufwerk sein. In letzterem Falle übernimmt dieses Netzwerklaufwerk sozusagen die Software-Verteilung.

Geodatabase

Auch die Geodatabase wird nicht verschont:

• Query Layers sind Tabellen in einer Datenbank, die einen spatial type kennt (Oracle Spatial, PostGIS, SQL Server). Solche räumliche Tabellen können in ArcGIS angezeigt werden, ohne dass ArcSDE installiert und lizenziert werden muss!
• Für den Zugriff auf die File Geodatabase von ausserhalb von ArcGIS wird es eine API geben. Diese ist C++-basiert und unterstützt nur Simple Features also nicht den gesamten Geodatabase-Umfang. Das dürfte also noch nicht der erwartete Shapefile-Ersatz werden.
• Für Rasterdaten gibt es ein neues Mosaic Dataset, das eine Kreuzung zwischen Rasterkatalog und Mosaik mit Cache-ähnlicher Performance sein soll. Da bin ich gespannt, ob es die Performance-Versprechen einhalten kann.
• Schlussendlich erhält die Geodatabase in ArcSDE ein neues, einfacheres Schema.

Cloud

Das buzz word schlechthin war die Cloud. Was auch immer darunter verstanden wird, ESRI bewegt sich stark in diese Richtung. Dies belegen drei neue Angebote von ESRI:

• Für ArcGIS Server wird es demnächst auch vorgefertigte Images (AMI) für Amazons Wolkendienst EC2 geben. Zuerst für Besitzer eines Enterprise License Agreement (ELA) und danach auch für alle Anwender (inkl. stundenbasierter Abrechnung).
• ArcGIS Explorer wird es neu auch als Browser-Anwendung geben auf Basis von Silverlight. Und das ganze auch noch kostenfrei. Damit wird ein recht brauchbarer, vorkonfigurierter Webviewer auf den Markt treten, gegen den bestehende Produkte antreten müssen.
• ESRI baut ein neues Portal namens ArcGIS.com auf, das es erlaubt, Karten, Dienste und Applikationen hochzuladen und mit anderen Anwendern zu teilen. Da fehlt eigentlich nicht mehr viel bis zu einem GDI-Portal.

Fazit

ArcGIS 10 ist wohl zu Recht ein Major Release. Die vielen interessanten Neuerungen dürften einen Umstieg wohl rechtfertigen. Der Releasetermin ist der Juni (vor der ESRI User Conference). Bereits diese Woche (1. April) soll ein Prerelease erscheinen. Ich bin gespannt.

Eine Protokollier-Aktion mit Fiddler im HTTP-Verkehr hat folgendes ergeben. Auf den GetCapabilites-Request erhalte ich das GetCapabilities-Dokument zurück. Der Client nimmt sich dann die dort definierte URL für den GetRecords-Befehl (http://www.geocat.ch/geonetwork/srv/en/csw) und schickt den POST-Request dorthin. Als Antwort erhält er jedoch den HTTP-Status 302, d.h. eine Umleitung (moved temporarily) auf eine andere Adresse (http://www.geocat.ch/geonetwork/srv/eng/csw). Der Client holt sich diese neue Adresse und schickt einen Request dorthin, jedoch keinen korrekten (ohne Parameter), so dass es zu einem Fehler kommt. Entweder der Client kann nicht korrekt mit dem Redirect umgehen oder mit den Geocat-URLs stimmt etwas nicht. Das Fiddler-Log habe ich mal hier angehängt:

fiddler_protokoll

Hat jemand den CSW-Dienst von Geocat schon erfolgreich testen können?

[Update]: Ich habe noch etwas weitergetestet (u.a. mit handgemachten Requests). Der Dienst hat tadellos funktioniert. Der Fehler liegt somit wohl beim ArcGIS-Client, der nicht korrekt mit dem Redirect umgehen kann.

Alles in allem sehr interessante Perspektiven. Der Erfolg der SuisseID ist jedoch noch nicht garantiert. Zunächst braucht es Anwendungen, die die SuisseID unterstützen. Der Bund (SECO) sucht da natürlich Pionierprojekte. Auf der anderen Seite müssen natürlich auch AnwenderInnen da sein, die eine SuisseID besitzen. Da ist der Preis entscheidend. Die definitiven Preise sind noch nicht publiziert, der Bund wird jedoch im Jahre 2010 SuisseIDs mit 65 Franken subventionieren. Das zeigt wahrscheinlich auch, dass eine SuisseID nicht ganz billig ist. Daher wird die Durchdringung nicht allzu schnell vonstatten gehen. Am eGovernment Forum habe ich auch die Vermutung gehört, dass die Verbreitung der SuisseID eher über Arbeitgeber gehen wird, die ihren Mitarbeitern eine SuisseID zur Verfügung stellen werden. Deshalb wäre es doch keine schlechte Idee, wenn die öffentliche Verwaltung, sei es der Bund oder z.B. der Kanton Bern, ihren Angestellten eine SuisseID ausstellen würden.

Ich bin schon gespannt, welche Anwendungen ab 1. Mai 2010 die SuisseID unterstützen und werde mir dann vielleicht auch eine SuisseID zulegen.

Ich bin über diese Ankündigung doch ziemlich enttäuscht. Ich hätte von ESRI erwartet, dass die mit ArcGIS 9.2 eingeführte Aufwärtskompatibilität beibehalten wird. Diese Pflicht zu identischen Software-Versionen auf der Datenbank und auf Client-Seite ist sehr störend und bei anderen Software-Systemen auch nicht unbedingt üblich. ESRI, bitte nachbessern!

Ich durfte auch feststellen, dass trotzdem schon einiges im Tun ist. So gibt es eine eGovernment-Strategie Schweiz, die der Bund zusammen mit Kantonen und Gemeinden erarbeitet hat. Ausserdem gibt es einen Katalog priorisierter Vorhaben, in dem auch einige Punkte aus der GIS-Welt vertreten sind:

• A1.14: Zugang zu Geobasisdaten, Geodiensten und interaktiven Kartenanwendungen (Zuständigkeit: e-geo.ch)
• B1.10: Organisation zur Erarbeitung einer nationalen Geodateninfrastruktur NGDI (Zuständigkeit: e-geo.ch)

Erfreulich, dass auch GIS-Belange in diesen Gesamtrahmen eingebunden sind. Die verschiedenen im Katalog aufgeführten Vorhaben sind natürlich unterschiedlich weit gediehen. Ein wichtiger Pfeiler bei der Umsetzung sind sicherlich die Standards. Hierzu gibt es den Verein eCH, der verschiedenste Standards im eGovernment-Bereich fördert und erarbeitet. Auf seiner Homepage sind diese alle aufgelistet. Auch hier gibt es Standards aus dem Bereich Geoinformation:

• eCH-0022: Standards Geoinformation
• eCH-0031: Geoinformation: INTERLIS 2 – Referenzhandbuch
• eCH-0056: Profil Geo Webservices

Als Fazit meines Forumsbesuchs nehme ich v.a. mit, das Thema eGovernment stärker zu beachten und zwar nicht nur die obenerwähnten GIS-Themen sondern auch andere Themen und Vorhaben, so z.B. die SuisseID, die ich für sehr erfolgsversprechend halte; dazu mehr in einem späteren Artikel. Wer an den einzelnen Vorträgen des Forums interessiert ist, kann diese auf der Homepage nachlesen und nachhören.

• Geopole: In diesem Verzeichnis sind bereits 400′000 Layer aufgelistet. Es kann über eine Volltextsuche, eine Tag-Cloud oder geographisch gesucht werden. Die Suchtreffer können selbstverständlich in einer Karte betrachtet werden. Es gibt auch einen RSS-Feed mit allen neuen WMS-Diensten. Das Verzeichnis durchforstet das Netz selbstständig nach neuen Diensten. Ich habe jedenfalls kein Formular gefunden, mit dem neue Dienste gemeldet werden können. Über geopole können auch WMS-Dienste überwacht und die Verfügbarkeit und Performance über die Zeit beobachtet werden.
• mapmatters.org: Dieses Verzeichnis ist ähnlich aufgebaut wie geopole. Es enthält z.Zt. 111′768 Layer. Auch hier können WMS-Dienste überwacht werden.
• GeoMonitoring: Ein Angebot im Rahmen der Geodateninfrastruktur Deutschland (GDI-DE). Es ist ziemlich ähnlich wie die beiden obigen Verzeichnisse, einzig die Suchfunktion ist etwas weniger ausgebaut. Neue Dienste werden jedoch nicht automatisch eingefügt, dies geschieht manuell durch die Mitarbeiter.
• geometa.info: Schon seit längerem ist die Suchmaschine der HSR Rapperswil dabei. Sie ist ganz einfach strukturiert. Die Stärke dieses Verzeichnisses ist sicherlich die Vielfalt. Es kann nicht nur nach Geodiensten sondern auch nach Geodaten gesucht werden.
• Geocat 2: Auch der Schweizer Metadatenkatalog Geocat kann mit Version 2 Metadaten zu Geodiensten aller Art aufnehmen. So ist z.B. der WMS-Dienst des Geoportals der BGDI dokumentiert.

Diese Entwicklung ist sicherlich erfreulich. Meiner Meinung nach gibt es noch ein Problem im Bereich der Metadaten. Ein kurzes Browsen in verschiedenen Einträgen hat gezeigt, dass nur sehr selten informative und aussagekräftige Metadaten zu den Diensten vorliegen. Meistens sind nur die automatisch ableitbaren Metadaten im GetCapabilities-Dokument verfügbar. Irgendwelche Angaben zu Nutzungsbedingungen, den enthaltenen Daten etc. sind in der Regel nicht zu finden. Das ist natürlich nicht das Problem der WMS-Verzeichnisse. Ich frage mich, ob das GetCapabilities-Dokument der richtige Ort ist, wo die Metadaten beschrieben werden sollen, weil es erstens keine vernünftigen Editoren für diese Metadaten gibt und das GetCapabilities-Dokument häufig (je nach verwendeter WMS-Version) im Browser nicht angezeigt wird, sondern als kryptischer Dateityp zum Download angeboten wird. Das alles ist nicht wirklich befriedigend.

Interessanter ist da der Ansatz von Geocat. Hier werden die Dienste-Metadaten normiert abgelegt (GM03? ISO 19119?) und zwar in derselben Applikation wie die Metadaten zu den Geodaten. D.h. man verwendet dieselbe Oberfläche, die Terminologie ist ähnlich und man kann ausserdem einen Link von den Geodaten zu den Geodiensten herstellen. Erst damit werden vollständige und aussagekräftige Dienste-Metadaten möglich. Dienste-Metadaten ohne einen Link zu den darin enthaltenen Geometadaten machen aus meiner Sicht keinen Sinn. Bei Geocat fehlt allerdings jedoch (noch?) die Monitoring-Komponente. Ich bin der Ansicht, dass der Ansatz von Geocat, sich auf die Normen zu stützen und Metadaten von Diensten und Daten am gleichen Ort mit dem gleichen Werkzeug zu verwalten, die momentan bessere Variante ist.

Aber auch das löst das Metadatenproblem nicht vollständig. Wenn einfach keine Metadaten abgefüllt werden, nützt auch die beste Metadatenlösung nichts. Die öffentliche Verwaltung sollte hier eine Vorbildrolle einnehmen und ihre Geodienste mit Metadaten beschreiben, v.a. da sie auch durch die Geoinformationsgesetzgebung dazu aufgefordert werden.