About operational layers

Each web GIS application requires a set of operational layers for use by a particular group of users. Typically, operational layer data is limited to a few focused layers and is only displayed when users zoom to a certain level. The data is streamed to the client and then rendered and managed by the client.

There are several reasons behind this pattern. First, operational layers are often dynamic, and thus generally should not be cached in advance. Second, users expect operational layers to be responsive, draw quickly, report details on a mouse click, and show links to certain functions. Third, operational layers must be in the same coordinate system as your basemap service. This is especially relevant, since coordinate system discrepancies can result in overlay issues, poor performance, and errors in the web GIS application.

The dynamic rendering and user interaction falling on the client side can be implemented using browser APIs, such as ArcGIS Web Mapping APIs for JavaScript, Flex, and Silverlight. However, operational layer data can occasionally be too large to be effectively rendered by the browser. In this case, operational layer data should be rendered by the server.

Three methods for publishing operational map layers

You have a few options when considering how you'll publish your operational map layers to the server:

• Using queries to select a subset of features that meet particular criteria, then displaying the query results using map graphics and text
• As a dynamic map service
• As a cached map service

Displaying query results as map graphics and text

One of the most efficient mechanisms for displaying operational information is to use the results of a query. You query the GIS server, which returns a set of feature results as a small record set. Query results that are returned from the server include a set of features, their coordinates, and a set of each feature's attributes. These results are displayed on the map as interactive graphics and descriptive information that can be worked with, charted, summarized, and used as hyperlinks that can be clicked to access more detailed information about each feature.

This approach requires application programming to create the map layer of results. Each ArcGIS Web Mapping API contains help on making queries and displaying results on the map as client-side graphics.

As a dynamic map service

One of the types of map services that you can publish is a dynamic map service. As the name implies, the map layer display is dynamically generated. In other words, the display is computed and served each time a client makes a request to the server to display the map service. The resulting map image is sent to the requesting application and overlaid on the basemap.

To create a dynamic map service, you first need to create an ArcMap document that contains a single or a few focused layers. Then you can publish it as a map service. The resulting map service will be consumed in your web GIS application, allowing users to work with the operational information.

Dynamic map services have the advantage of providing an up-to-date and accurate status for the operational layer. However, dynamic map layers are often the slowest way to draw a map on the web.

As a cached map service

Another alternative for serving operational map layers is to use a cached map service, where the map display is precomputed and stored in a map cache ahead of time. In these cases, there is no need to recompute the display of the operational map layer each time that a client requests a map from the server. Instead, the appropriate map tiles are retrieved from the server, which greatly increases performance and scalability.

In some cases, operational map layers are more static and change less frequently. This means that you can update them periodically by precomputing the map as opposed to computing a new map every time one is requested from the server. This way, everyone can access a faster, more efficient map service that they will work with.

Cached map services are also very scalable, meaning they respond well to many concurrent hits on your server. If you expect large amounts of user traffic, it may be worth it to cache your layer, even if you will need to make frequent updates to the cache.

If you do not have the time or disk space to create all the tiles for your caches, you may choose to precreate some tiles and create the rest on demand. When the first client accesses the web GIS application, the map cache is computed for the requested area (for a set of map tiles), and the cache is built. Anyone else who visits the same map tiles simply uses the new map cache. Each time a user makes a request, it retrieves that cached map tile if it exists. Otherwise, it computes the tile and caches it on disk. Only the first user needs to compute the map display, and then other users can access a cached map of the operational layer.

See the topic What is map caching? for more information on how to create cached map services.