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 applications. 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 following tutorial shows you how to share custom printing layouts:

• Tutorial: Share additional layouts for printing with ArcGIS Pro

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 left a great deal of responsibility to the developer to keep a healthy state on the map instance itself.

The ArcGIS web APIs give you an easy way 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 it's easy for the client to draw the features using any colors, widths, or class breaks defined by the application 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 easily 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 About dynamic layers.

Web editing

In the early releases of ArcGIS Server, editing data over the web had to be accomplished purely 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. Not only is editing possible through REST, it's convenient to customize 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 gives you the ability to develop custom tools. The simplest way is to 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 different workflows, since they behave just like any other out-of-the-box tool. Additionally, your custom code can execute within the asynchronous execution 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 APIs, such as the ArcGIS Maps SDK for JavaScript and the ArcGIS Runtime SDKs, offer extensive local geometry libraries that allow you to perform projections, calculate distances, and so on.

If you don't intend to use these client APIs, check to see if the SOAP- or REST-based geometry service offers 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.