Create layouts for printing

Many developers have used custom code to access the Layout object of the map service, specifically for putting high-quality printing functionality in their web app. They previously used ArcObjects to work with maps with quality and their surrounding elements, generate printable documents in large formats, and so on.

As an alternative, you can now use the arcpy.mp (for ArcGIS Pro) Python module to script your layout construction and map printing. Then, you can expose the script through a geoprocessing service or a web tool. With ArcPy, you can manipulate map documents to a very fine degree: you can add layers dynamically to the map, update their symbology, and more. You can also access the layout of the map, manipulating elements such as text and images.

The Share additional layouts for printing with ArcGIS Pro tutorial shows you how to share custom printing layouts.

Change symbols and renderers

Another reason developers needed custom code in the past was to change the symbology of a particular layer in a map service. This workflow often required the use of non-pooled services, limiting the scalability of applications. Some developers managed to do this with pooled services, although switching the state of a service back and forth to satisfy requests from multiple users often resulted in poor performance and required the developer to keep a healthy state on the map instance itself.

The ArcGIS web APIs allow you to symbolize features using a client-side feature layer or graphics layer, whose rendering properties can be changed at any time. The idea is that the geometry and the attributes of visible features are all downloaded to the client, so the client can draw the features using any colors, widths, or class breaks defined by the app developer.

The feature layer technique is particularly effective for thematic mapping, interacting with and highlighting features, and so on, but it falls short when you are working with thousands of features or very complex polygon features. In those cases, the best approach is to request symbology changes at the service level and have the map service render the map image. This previously required ArcObjects.

Now, you can alter the contents and symbology of a map service at runtime. You no longer need to use fine-grained custom code to change symbology on your map service layers. Instead, you can decide, on a per request basis, the contents or symbology to be used in the map you want to create.

Defining the symbology of your layers in the map service at runtime is done by including the renderer information in your web service request to draw the map, along with the typical information of visibility of layers, extent, and so on. The ArcGIS web APIs include utility classes so you can define content, renderers, class breaks, symbology, and so on.

To learn more about changing contents and symbology in real time in a map service, see Dynamic layers.

Web editing

In the early releases of ArcGIS Server, editing data over the web had to be accomplished through custom code leveraging local (DCOM) connections. The introduction of the feature service eliminated the need to write extensions for this.

The REST API allows you to edit features of your feature services on the web and customize them because many common editing methods, such as cut, trim, extend, autocomplete polygons, and reshape are exposed through the REST implementation of the geometry service. Versioned editing is also supported in feature services.

Performing business logic with geoprocessing

Some GIS applications run a specific series of tools to perform advanced GIS business logic. These tools might predict timber yield from a forest, identify suitable sites for a restaurant, or estimate where a toxic cloud could spread. Many developers have used custom code to accommodate this.

In many cases, these processes can be expressed in ModelBuilder, where you can graphically "chain" tools together. These geoprocessing models can be exposed as web services and consumed from your web applications. The benefits of this are obvious: Using a geoprocessing service can save you a lot of coding. Also, you can take advantage of the asynchronous execution of geoprocessing services, which is challenging to achieve by writing your own SOE code.

Aside from the flexibility of having thousands of out-of-the-box tools that you can combine in ModelBuilder, geoprocessing allows you to develop custom tools. For example, you can create Python scripts that can run either on their own or in combination with other tools within a model. This topic described an example of this earlier with the use of ArcPy to create high-quality maps over the web.

Whether you use Python or another language, the advantage of creating custom tools is that you can reuse them in other workflows, since they behave like any other out-of-the-box tool. Additionally, your custom code can run within the asynchronous model of geoprocessing services, which is handy for long-running processes.

Performing geometric calculations

Geoprocessing services are useful but are no longer necessary to perform geometry operations.

Esri client SDKs—such as the ArcGIS Maps SDK for JavaScript, ArcGIS Maps SDKs for Native Apps, and ArcGIS Maps SDKs for Game Engines—offer extensive local geometry libraries that allow you to perform operations such as reprojecting geometries and distance calculations.

If you don't intend to use these client APIs, the SOAP- or REST-based geometry service may offer the methods that you need. A geometry service can perform basic GIS operations such as buffering, determining spatial relationships, and measuring lengths and areas. Calling a series of methods on a geometry service and combining that with the query capabilities of map services and client-side logic can be simpler and faster than using a geoprocessing service.