Die Vielfalt an ArcGIS-Entwicklerwerkzeugen und die Aufgabe, einen Web-Service zu kodieren, können die Verwendung von Serverobjekt-Erweiterungen und -Interceptoren (SOEs und SOIs) für Anfänger schwierig gestalten. In diesem Thema werden einige allgemeine Web-GIS-Tasks erläutert, für die GIS-Entwickler gewöhnlich benutzerdefinierten Code geschrieben haben, und alternative Methoden vorgestellt, bei denen es nicht erforderlich ist, eine SOE oder einen SOI zu schreiben.
Erstellen von Layouts für den Druck
Viele Entwickler haben mithilfe von benutzerdefiniertem Code auf das Layout-Objekt des Kartenservice zugegriffen, insbesondere um die Webanwendungen mit Funktionen für hohe Druckqualität zu versehen. Zuvor kam für die Arbeit mit hochwertigen Karten und den umgebenden Elementen, zum Erstellen druckbarer Dokumente in großen Formaten usw. ArcObjects zum Einsatz.
Alternativ können Sie das Python-Modul "arcpy.mp" (für ArcGIS Pro) verwenden, um ein eigenes Skript für Layout-Konstruktion und Kartendruck zu erstellen. Anschließend können Sie das Skript über einen Geoverarbeitungsservice oder ein Web-Werkzeug verfügbar machen. Mit ArcPy können Sie Kartendokumente bis ins Detail bearbeiten: Sie können der Karte dynamisch Layer hinzufügen, die Symbolisierung aktualisieren und vieles mehr. Sie können auch auf das Layout der Karte zugreifen und Elemente, wie z. B. Text und Bilder, bearbeiten.
Das folgende Lernprogramm zeigt Ihnen, wie benutzerdefinierte Druck-Layouts freigegeben werden:
Ändern von Symbolen und Renderern
Entwickler haben in der Vergangenheit auch benutzerdefinierten Code verwendet, um die Symbolisierung eines bestimmten Layers in einem Kartenservice 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 Kartenservice rendern zu lassen. In der Vergangenheit war dafür ArcObjects erforderlich.
Sie können nun Inhalt und Symbolisierung eines Kartenservice zur Laufzeit ändern. Es ist nicht mehr erforderlich, komplexen benutzerdefinierten Code zu verwenden, um die Symbolisierung für die Kartenservice-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.
Die Symbolisierung der Layer im Kartenservice definieren Sie zur Laufzeit, indem Sie neben den typischen Informationen zur Layersichtbarkeit, Ausdehnung usw. die Renderer-Informationen in die Web-Service-Anforderung zum Zeichnen der Karte einbeziehen. Die ArcGIS-Web-APIs enthalten Dienstprogrammklassen, damit Sie Inhalt, Renderer, Klassengrenzen , Symbolisierung usw. auf einfache Weise definieren können.
Weitere Informationen zum Ändern von Inhalt und Symbolisierung in einem Kartenservice in Echtzeit finden Sie unter Dynamische Layer.
Web-Editing
In den frühen Versionen von ArcGIS Server erfolgte die Webbearbeitung von Daten ausschließlich über lokale (DCOM-)Verbindungen durch die Nutzung von benutzerdefiniertem Code. Seit der Einführung des Feature-Service ist es nicht mehr erforderlich, Erweiterungen dafür zu schreiben.
Mit der REST-API können Sie Features Ihrer Feature-Services im Web bearbeiten. Über REST ist nicht nur die Bearbeitung möglich, auch die Anpassung kann auf einfache Weise durchgeführt werden: Viele allgemeine Bearbeitungsmethoden, z. B. Polygone ausschneiden, kürzen, erweitern und automatisch vervollständigen sowie das Umformen werden durch die REST-Implementierung des Geometrieservice bereitgestellt. Die versionierte Bearbeitung wird in Feature-Services ebenfalls unterstützt.
Vorversion:
In ArcGIS-Versionen vor ArcGIS 10.1 konnten nicht in einem Pool befindliche Services für die Durchführung von Änderungen nach einem langen Transaktionsmodell genutzt werden. 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). Dies entbindet Sie nicht vom Implementieren von Operationen zum Rückgängigmachen/Wiederholen, wie mit den ArcGIS-Web-APIs.
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 benutzerdefinierten Code verwendet, um dies zu erreichen.
In vielen Fällen können diese Prozesse in 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 Geoverarbeitungsservice kann den Codierungsaufwand deutlich reduzieren. Außerdem können Sie die asynchrone Ausführung von Geoverarbeitungsservices nutzen. Durch das Schreiben von eigenem SOE-Code lässt sich das nur schwer erreichen.
Neben der Flexibilität, die Ihnen Tausende von sofort einsatzfähigen und in ModelBuilder kombinierbaren Werkzeugen 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 entsprechendes Beispiel beschrieben, in dem über das Internet hochwertige Karten mit ArcPy erstellt wurden.
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 Ihr benutzerdefinierter Code innerhalb des asynchronen Ausführungsmodells von Geoverarbeitungsservices ausgeführt werden, und das ist für Prozesse mit langer Laufzeit praktisch.
Durchführen von geometrischen Berechnungen
Geoverarbeitungsservices sind zwar nützlich, aber zum Durchführen von Geometrie-Operationen nicht mehr erforderlich.
Esri Client-APIs, wie zum Beispiel ArcGIS Maps SDK for JavaScript und die ArcGIS Runtime SDKs, enthalten umfangreiche Bibliotheken der lokalen Geometrien, mit deren Hilfe Sie zum Beispiel Projektionen durchführen und Entfernungen berechnen können.
Wenn Sie diese Client-APIs nicht verwenden möchten, dann stellen Sie fest, ob der SOAP- oder REST-basierte Geometrieservice die Methoden bietet, die Sie benötigen. Mit einem Geometrieservice 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 Geometrieservice aufzurufen und mit den Abfragefunktionen von Kartenservices und clientseitiger Logik zu kombinieren, als einen Geoverarbeitungsservice zu verwenden.