Die Vielfalt von ArcObjects und die Aufgabe, einen Web-Service zu kodieren, können die Verwendung von Serverobjekterweiterungen (SOEs) für Anfänger schwierig gestalten. In diesem Thema werden einige allgemeine Web-GIS-Tasks erläutert, für die Entwickler gewöhnlich ArcObjects-Code geschrieben haben, und alternative Methoden vorgestellt, bei denen es nicht erforderlich ist, eine SOE zu schreiben oder mit ArcObjects vertraut zu sein.
Erstellen von Layouts für den Druck
Viele Entwickler haben mithilfe von ArcObjects auf das Layout-Objekt des Karten-Service zugegriffen, insbesondere um die Webanwendungen mit Funktionen für hohe Druckqualität zu versehen. Sie bearbeiten mithilfe von ArcObjects hochwertige Karten z. B. in ArcMap sowie die umgebenden Elemente, generieren druckbare Dokumente in großen Formaten usw.
In ArcGIS 10.0 wurde das Python-Modul "arcpy.mapping" eingeführt, das die Layout-Konstruktion und den Kartendruck per Skript ermöglicht. Anschließend können Sie das Skript über einen Geoverarbeitungs-Service verfügbar machen. Mit dem Modul "arcpy.mapping" können Sie Kartendokumente bis ins Detail bearbeiten: Sie können Layer dynamisch zur Karte hinzufügen, die Symbologie aktualisieren und vieles mehr. Sie können auch auf das Layout der Karte zugreifen und Elemente, wie z. B. Text und Bilder, bearbeiten.
In ArcGIS 10.1 wurden die arcpy.mapping-Optionen verbessert. Mit dem Modul "arcpy.mapping" ist es insbesondere einfacher, den Inhalt einer Web Mapping-Anwendung (einschließlich Karten-Services und Grafiken) dynamisch in ein Kartendokument zu laden.
Ändern von Symbolen und Renderern
Entwickler haben ArcObjects in der Vergangenheit auch verwendet, um die Symbologie eines bestimmten Layers in einem Karten-Service zu ändern. Dieser Workflow erforderte oft die Verwendung von nicht in einem Pool befindlichen Services, wodurch die Skalierbarkeit von Anwendungen beschränkt war. Einige Entwickler erreichten dies mit in einem Pool befindlichen Services. Der ständige Wechsel des Service-Status in Reaktion auf Anforderungen von mehreren Benutzern führte jedoch häufig zu Beeinträchtigungen der Performance und bürdete den Entwicklern einen großen Teil der Verantwortung für die Bewahrung der Stabilität der Karteninstanz auf.
Die ArcGIS-Web-APIs bieten eine einfache Möglichkeit für das Symbolisieren von Features mit einem clientseitigen Feature-Layer oder Grafik-Layer, dessen Rendering-Eigenschaften jederzeit geändert werden können. Die Geometrie und die Attribute sichtbarer Features werden alle auf den Client heruntergeladen, damit das Zeichnen von Features auf dem Client mit beliebigen, vom Anwendungsentwickler definierten Farben, Breiten oder Klassengrenzen auf einfache Weise durchgeführt werden kann.
Die Feature-Layer-Technik ist besonders effektiv für die thematische Kartenerstellung, bei der u. a. mit Features interagiert und Features hervorgehoben werden. Die Technik ist jedoch nicht geeignet, wenn Sie mit Tausenden von Features oder sehr komplexen Polygon-Features arbeiten. In solchen Fällen empfiehlt es sich, Symbologieänderungen auf Serviceebene anzufordern und das Kartenbild vom Karten-Service rendern zu lassen. In der Vergangenheit war dafür ArcObjects erforderlich.
In ArcGIS 10.1 wurde der Karten-Service insofern verbessert, als Sie den Inhalt und die Symbologie der Karte während der Laufzeit ändern können (wie mit ArcIMS). Es ist nicht mehr erforderlich, in einem Pool befindliche Services und komplexe ArcObjects zu verwenden, um die Symbologie für die Karten-Service-Layer zu ändern. Stattdessen können Sie bei jeder Anforderung den Inhalt oder die Symbologie festlegen, der bzw. die in der zu erstellenden Karte verwendet werden soll.
Durch diese Erweiterung werden Ihre Anwendungen deutlich skalierbarer, während gleichzeitig die Entwicklung und Wartung vereinfacht wird. Die Symbologie der Layer im Karten-Service wird zur Laufzeit definiert, indem neben den typischen Informationen zur Sichtbarkeit von Layern, Ausdehnung usw. die Renderer-Informationen in der Web-Service-Anforderung zum Zeichnen der Karte enthalten sind. Die 3.0-Versionen der ArcGIS-Web-APIs umfassen Dienstprogrammklassen, damit Sie Inhalt, Renderer, Klassengrenzen, Symbologie usw. auf einfache Weise definieren können.
Weitere Informationen zum Ändern von Inhalt und Symbologie in einem Karten-Service "on-the-fly" finden Sie unter Dynamische Layer.
Web-Editing
In den frühen Versionen von ArcGIS Server konnten Daten über das Web ausschließlich über die Nutzung lokaler (DCOM-) Verbindungen durch benutzerdefinierten ArcObjects-Code bearbeitet werden. In Version 9.2 wurde ein Editor-Task in Web ADF eingeführt, wodurch einfache Bearbeitungsoptionen, z. B. das Erstellen, Bewegen und Löschen von Features, ermöglicht wurden. Jede Anpassung dieses Tasks oder die Erstellung von Editierwerkzeugen von Grund auf erfordert weiterhin eine umfassende ArcObjects-Programmierung.
Die REST-basierten APIs haben am Anfang kein Web-Editing ermöglicht, aber mit der Einführung des Feature-Service in ArcGIS 10 wurde die Bearbeitung durch diese APIs möglich. Es ist nicht nur möglich, die Bearbeitung über REST durchzuführen, sondern die Anpassung kann auch auf einfache Weise durchgeführt werden, da viele allgemeine Bearbeitungsmethoden, z. B. Polygone ausschneiden, kürzen, erweitern und automatisch vervollständigen sowie das Umformen durch die REST-Implementierung des Geometrie-Services verfügbar gemacht werden. Wenn Sie die Bearbeitung mit REST durchführen, können Sie zudem in einem Pool befindliche Services verwenden. Dadurch wird die Performance beträchtlich verbessert.
Es gibt einen Workflow, der in ArcGIS 10.1 nicht mehr unterstützt wird: lange Transaktionen. In Web ADF konnten nicht in einem Pool befindliche Services für die Durchführung von Änderungen nach einem langen Transaktionsmodell genutzt werden. Im Wesentlichen konnten Sie das Aktualisieren von Features starten und den Vorgang jederzeit zurücksetzen. Im Feature-Service sind alle Vorgänge statusunabhängig, sodass es nicht möglich ist, einen Vorgang auf Datenbankebene zurückzusetzen (auch wenn das mit der Geschäftslogik der Anwendung möglich war). Ein langes Transaktionsmodell für Web-Editing gehört zu den wenigen Workflows, für die die neue Serverarchitektur in ArcGIS 10.1 keine Alternativen bietet.
Dabei muss jedoch betont werden, dass Sie trotz der fehlenden Unterstützung für lange Transaktionen Vorgänge rückgängig machen/wiederherstellen können. Die ArcGIS-Web Mapping-APIs ermöglichen tatsächlich das Rückgängigmachen/Wiederherstellen von Vorgängen auf Anwendungsebene direkt von der API.
Eine andere einzigartige Funktion, die nicht in einem Pool befindliche Services bieten, ist das Ändern von Versionen während der Bearbeitung. Dies ermöglicht z. B. Webbenutzern, ihre Änderungen in verschiedenen Versionen zu speichern, die später mit ArcGIS Desktop abgeglichen werden können. ArcGIS 10.1 bietet verbesserte Feature-Services, damit Sie während der Laufzeit eine Version für die Änderungen von jeder Webanwendung zielgerichtet auswählen können.
Ausführen der Geschäftslogik mit der Geoverarbeitung
In einigen GIS-Anwendungen werden bestimmte Werkzeuge für die Durchführung der erweiterten GIS-Geschäftslogik ausgeführt. Diese Werkzeuge können verwendet werden, um den Holzertrag aus einem Wald vorherzusagen, geeignete Standorte für ein Restaurant zu bestimmen oder die mögliche Ausbreitung einer Giftwolke abzuschätzen. Viele Entwickler haben zu diesem Zweck ArcObjects verwendet.
In vielen Fällen können diese Prozesse in ArcGIS ModelBuilder ausgedrückt werden, indem Werkzeuge grafisch verknüpft werden. Diese Geoverarbeitungsmodelle können als Web-Services verfügbar gemacht werden und in den Webanwendungen verwendet werden. Die Vorteile sind offensichtlich: Die Verwendung eines Geoverarbeitungs-Service kann den Codierungsaufwand deutlich reduzieren. Außerdem können Sie die asynchrone Ausführung von Geoverarbeitungs-Services nutzen. Durch das Schreiben von eigenem ArcObjects-Code lässt sich das nur schwer erreichen.
Neben der Flexibilität, die Hunderte von Standardwerkzeugen, die Sie in ModelBuilder kombinieren können, bieten, ermöglicht die Geoverarbeitung auch die Entwicklung benutzerdefinierter Werkzeuge. Die einfachste Methode besteht darin, Python-Skripte zu erstellen, die eigenständig oder in Verbindung mit anderen Werkzeugen in einem Modell ausgeführt werden können. In diesem Thema wurde weiter oben ein Beispiel anhand der Erstellung von hochwertigen Karten über das Internet mit dem Modul "arcpy.mapping" beschrieben.
Um noch mehr Kontrolle zu erhalten, können Sie ein benutzerdefiniertes Geoverarbeitungswerkzeug mit C#, Visual Basic .NET, C++ oder Java statt mit Python erstellen. Auf diese Weise können Sie eine eigene komplexe ArcObjects-Logik innerhalb der Modelle einbetten.
Unabhängig davon, ob Sie Python oder eine andere Skriptsprache verwenden, bietet die Erstellung von benutzerdefinierten Werkzeugen den Vorteil, dass diese in unterschiedlichen Workflows wiederverwendet werden können, da sie sich wie jedes andere Standardwerkzeug verhalten. Darüber hinaus kann der ArcObjects- oder Python-Code innerhalb des asynchronen Ausführungsmodells von Geoverarbeitungs-Services ausgeführt werden, und das ist für Prozesse mit langer Laufzeit sehr praktisch.
Durchführen von geometrischen Berechnungen
Geoverarbeitungs-Services sind nützlich, aber genauso, wie die ArcObjects-Entwicklung nicht empfehlenswert ist, wenn das gleiche Ergebnis mit der Geoverarbeitung auf einfache Weise erreicht werden kann, ist es besser, nicht die Geoverarbeitung zu verwenden, wenn stattdessen Standard-Services verwendet werden können. Stellen Sie fest, ob der SOAP- oder REST-basierte Geometrie-Service die Methoden bietet, die Sie benötigen. Mit einem Geometrie-Service können einfache GIS-Vorgänge, z. B. das Puffern, das Bestimmen räumlicher Beziehungen und das Messen von Längen und Flächen, ausgeführt werden. Es ist möglicherweise einfacher und schneller, eine Reihe von Methoden in einem Geometrie-Service aufzurufen und mit den Abfragefunktionen von Karten-Services und clientseitiger Logik zu kombinieren, als einen Geoverarbeitungs-Service zu verwenden.