Web maps often contain a base map, which provides a geographic frame of reference, and operational (or thematic) layers, which show a focused item of interest on top of the base map. A familiar example might be an online mapping service that provides real time traffic information on top of a city street map. The street map is the base map. It doesn’t change much and can be used for many purposes. The traffic information is the operational layer because it frequently changes and has a specific purpose and audience. This article describes different patterns for building Web applications that overlay base map and operational layers.
Base maps and operational layers often require separate strategies for effective maintenance and display in Web maps. When creating a Web map, it’s a good practice to separate the base map from the operational layers. Base maps generally require little maintenance and should almost always be cached, whereas operational layers may require creative strategies to present the most current data in a high-performance way.
Separating your base map and operational layers requires that you create at least two map documents (.mxd’s), which you subsequently publish as two distinct map services. Each becomes a map service layer in the overall Web map. A map service layer originates from a map document that may itself contain many layers.
This may seem strange to you if you’re new to Web mapping; perhaps your company has one map document with dozens of layers that they’ve used for years. For performance and flexibility reasons, it may be time to break up that monolithic map document. When you create multiple map documents, each containing a logical group of layers such as base map features, cadastral features, and so on, you can publish them as separate services and target your display strategies for each.
Strategies for displaying the base map
To provide the rapid performance expected by Web users, the base map should be a cached map service. The cache consists of a pre-generated set of map images that the server can distribute to clients. Base maps and their accompanying map caches are generally easy to maintain because the data does not change frequently. When the data does change, you can update the cache.
Here’s an example of a cached base map of imagery. Your base map could also contain street networks, terrain, or any type of features that provide a context for the operational layers.
Your base map cache can come from an existing online map service, or it can come from your own map. Examples of existing cached base maps include the street maps, imagery, and shaded relief layers available on ArcGIS Online. Google Maps and Microsoft Virtual Earth also provide base map layers which you can access through ESRI JavaScript extensions to their APIs.
If an existing base map doesn’t fit your needs, you can author your own high quality map in ArcMap and use tools included with ArcGIS Server to create a cache. You’ll get the best performance in your web applications if you choose to fuse all of the layers in your base map when building the cache for the base map service. You won’t be able to turn layers within the base map layer in the Web map on and off, but you will see exceptional performance. If there are some layers that users must have the ability to turn on and off, separate them out into a separate base map service with its own fused cache, or treat them as operational layers.
A good caching strategy is to create tiles for only the area that you need. By default, the caching tools create tiles for a rectangular extent (the Full Extent of the map in ArcMap), but using the ArcGIS Server 9.3 caching tools you can specify a feature class whose boundaries determine where cache gets created. For example, you could use a feature class of the state of Florida, which is shaped like a rotated L, to create tiles only covering land in Florida. This way you avoid caching large areas of water in the Gulf of Mexico which fall within the rectangular extent of Florida.
If you have a large geographic area to cover and limited server resources to create and store the tiles, you might consider caching some of the area on demand. Using the cache by feature class strategy, you can pre-generate cache tiles for popular areas and leave the less-popular areas to be created as visited by users, with the first visitor incurring a performance penalty.
If you edit data in your base map, you’ll need to update the cache tiles in order for users to see the edits. You can save time by limiting the update to just the areas that have changed. Remember that if you’ve created some tiles on demand, you’ll need to include those in the update. You might just delete any tiles that have been created on demand, letting them be created again if a user decides to visit the area.
You can script cache updates and schedule them to run on nights or weekends to minimize interference with normal server traffic.
Strategies for displaying operational layers
Operational layers, such as vehicle locations, cadastral features, utility networks, and weather data, can be more challenging to represent because of their constantly changing nature. Following are several strategies you can use to represent operational layers in your Web map.
Display the operational layer as client-side graphics
As the user zooms, pans, or clicks the map, you can query the operational layer for features in the visible extent and display them in the browser as client side graphics. This “query on demand” pattern offers several advantages:
- It ensures that you are only loading the features that you need.
- It takes advantage of the CPUs available on your users’ machines, thereby lightening the load on your server’s CPU.
- If you’ve made edits to the data they will show up right away the next time the user navigates.
- You can easily expose display options and symbology to users through JavaScript. This is useful for thematic mapping applications like this one, and for turning layers on and off.
Here’s an example of a map that displays land parcels as an operational layer using client-side graphics. Notice that you cannot see the parcels until you zoom in to the second-to-last layer. This ensures that you won’t exceed the number of maximum returnable records. The parcels are not labeled but if you click one you can immediately get its information in an info window.
You might even choose not to display any features until they are requested by clients through events such as clicking the map. For example, this application invites the user to click a location on some high resolution imagery and shows the parcel at that point using a graphic.
Labeling can be a challenge with client-side graphics. Although you can display text symbols with your graphics, there is no labeling engine determining the best placement of the text to avoid label overlap. Fortunately, with client-side graphics the attribute information is usually already loaded and can quickly be displayed in an informational window when the user clicks or hovers the mouse on the feature. You can also use grids, charts, and other widgets to show information in response to map events.
When using the “query on demand” technique, you need to guard against the scenario of users requesting too many features. It is possible to overwhelm the browser and the network by fetching large amounts of features into the client and you need to design your user experience and application so that this is dealt with gracefully.
All map services have a MaxRecordCount property, which determines how many features they will return on a query. By default it is set to 500. You need to either adjust this value or ensure that users will not be able to pan or zoom to a level in your map where they would be requesting more than 500 features.
The ArcGIS Server REST and SOAP Web service interfaces allow applications to query map services using the QueryFeatures, Identify and Find operations.
The ArcGIS Javascript APIs and the ArcGIS Server Web ADFs expose this ability through their QueryTasks.
Display the operational layer as a dynamic map service
A second option is to use a dynamic map service to represent the operational layers. In a dynamic map service, the server draws the map image at the requested extent. This image is then overlayed on the cached image from the base map. The overlay usually occurs on the browser.
This example shows a dynamic map service of zoning and parcels overlaid on a cached base map of imagery.
Although dynamic map services have been the traditional approach to Web mapping, they put more load on the server than on-demand queries or cached map services. If you need to use a dynamic map service, you can optimize performance by paring down your map to display the minimum number of needed layers with the simplest symbology that would be appropriate.
Dynamic map services show users all the data in the current extent for each visible layer including, in some cases, data that may not necessarily be used in making decisions. In other cases seeing the “complete spatial fabric” is important. For example, users may want to always see the complete electrical network in the view for context as opposed to just specific transformers and service lines. Querying all these features into a browser and rendering them on the client side would be impractical, so a dynamic or cached map might be the best choice. A dynamic service gives the advantage of users being able to turn any layer on or off.
The ArcGIS Javascript API exposes dynamic mapping through the ArcGISDynamicMapServiceLayer. The ArcGIS Server Web ADFs expose this ability via the ArcGIS Server map resource, which draws a dynamic map if a cache is not available. The ArcGIS Server REST and SOAP Web service interfaces provide applications with dynamic mapping via the ExportMapImage operation.
Display the operational layer as a cached map service
A third option is to display your operational layer as a cached map service. Caching is appropriate if your operational dataset changes infrequently, covers a limited area, or does not cover large scales.
This example shows a cached operational layer of zoning and parcels overlaying a cached base map of imagery. Notice that the operational layer loads quickly, but is not available at the two largest scales. For demonstration purposes, we did not build the cache at those levels. This reveals one weakness of using a cached service for your operational layer: cached services can take large amounts of resources to generate, store, and update at large scales.
Out of the three techniques in this article, caching gives the best performance because the application only needs to get an image from the server. When you navigate a cached map, you don’t have to wait for any map drawing or data transfer operations. Cached map services also offer the best cartographic potential because you don’t have to worry about cartographic embellishments slowing your map navigation (although they will slow cache generation.)
When you create a cache for your operational layer, it’s a good idea to match the tiling scheme of the base map. The tiling scheme includes the tile dimensions and potential scales used by the cache. Matching tiling schemes are required for some clients, such as the ArcGIS JavaScript API, to successfully perform the overlay. A matching tiling scheme implies that the coordinate systems used by the data frames match; however, the coordinate systems of the source datasets do not have to match.
It’s recommended that you use PNG 8 image format when you cache any layer that will be displayed over a base map. PNG 24 is not a good choice because Internet Explorer versions 6 and earlier have limitations with displaying transparency in this image format. JPG is not an option because it does not support transparency. If you’re trying to match a tiling scheme from another service, you don’t have to match its image format in order for the services to overlay successfully.
You can script and schedule updates to the cache, just as you can with the base map. With operational layers you may need to update more frequently, depending on the nature of the datasets. When you first build the cache, note how long it takes so you know how much time to allot for an update. You can reduce your update time by separating your operational layers from the base map, limiting the number of scales at which the data is visible, and using simple symbology and labeling.
The ArcGIS Javascript API exposes cached map services through the ArcGISTiledMapServiceLayer. The ArcGIS Server Web ADFs expose this ability via the ArcGIS Server map resource, which uses cache tiles if it detects they are available. The ArcGIS Server REST and SOAP Web service interfaces also provide ways to retrieve tiles from a cache.
Contributed by Sterling Quinn, Jeremy Bartley, and Sud Menon of the ArcGIS Server development team.
