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.

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!

So weit so gut. Etwas komplizierter war die zweite Aufgabe. Für jeden der oben erwähnten Punkte musste ich berechnen, wieviele Kilometer Gewässernetz oberhalb liegen. Hierfür gibt es im ITraceFlowSolver2-Interface die Funktion FindAccumulation. Diese gibt als Resultat alle jene Gewässerabschnitte zurück, die oberhalb eines Punktes liegen. Hier begannen nun die Probleme. Im Prinzip ging es nun nur noch darum, die Länge aller jener Gewässerabschnitte zu berechnen. Die FindAccumulation-Funktion gibt nicht die normale Feature-ID der Gewässerabschnitte zurück sondern die Network-ID, welche nicht identisch zu sein braucht. Nun habe ich nach kurzer Durchsicht des Objektmodells eine vielversprechende Funktion gefunden. Das IGeometricNetwork-Interface bietet die Funktion GeometryForEdgeID, welche mir für jede Network-ID die dazugehörige Geometrie und damit auch die Länge zurückgibt. Und tatsächlich, damit konnte ich die gesuchte Gewässernetzlänge berechnen. Doch bei Punkten die relativ weit unten im Netzwerk liegen (z.B. am Unterlauf von Rhein, Aare oder Rhone) und somit eine sehr grosse Gewässernetzlänge oberhalb aufweisen, dauerte die Berechnung ziemlich lange (bis zu einer Stunde) oder ArcMap stürzte gar ohne Fehlermeldung ab. Zuerst vermutete ich das Probleme in der FindAccumulation-Funktion, da ich mir schon vorstellen konnte, dass auf dem recht detaillierten Gewässernetz eine solche Funktion recht viel Zeit in Anspruch nehmen konnte. In der “Utility Network Analyst Toolbar” gibt es jedoch den Task “Find Upstream Accumulation”, mit dem ich ein paar dieser problematischen Berechnungen von Hand durchführte. Und dort dauerte dies jeweils nur wenige Sekunden, also konnte die Tracing-Funktion nicht das Problem sein. Damit wendete ich mich der GeometryForEdgeID-Funktion zu, die nun der Übeltäter zu sein schien. Als Ersatz fand ich das IEIDHelper-Interface, mit dem man für jede Network-ID ein IEIDInfo-Interface holen kann, welches das gesuchte Geometry-Attribut aufweist. Ein kurzer Test zeigte mir, dass auf diese Weise die Berechnung der Gewässernetzlänge nur wenige Sekunden dauerte. Dieser Weg war also der deutlich schnellere. Wahrscheinlich liegt es daran, dass die ursprünglich gebrauchte GeometryForEdgeID-Funktion im ganzen Netzwerk nach der übergebenen Network-ID sucht (keine Ahnung, ob hier ein Index existiert) — immerhin besteht das Netzwerk aus mehreren Hunderttausend Abschnitten –, was deutlich langsamer ist als der Weg über das IEIDInfo-Interface.

Langer Rede kurzer Sinn: es lohnt sich, das Arcobjects-Objektmodell sehr genau zu studieren, und nicht immer die erstbeste Lösung zu verwenden. Meistens gibt es in ArcObjects immer mehrere Wege zum Ziel, die Herausforderung ist dann jeweils, den geeignetsten zu finden.