Imagery in Web applications: Should I use a cached map service or an image service?

One of the most common questions we receive about Web map design is how to display imagery base layers. Specifically, is it better to use an image service, or a cached map service containing the imagery?

As with most Web map design questions, the answer is: “It depends on the purpose of your application”. In general, if the purpose of the imagery is only for visualization on the Web, putting the imagery in a cached map service is the most responsive and scalable solution. Other factors to consider include the required functionality, and maintainability of the application.

Speed

First, let’s address the responsiveness, or speed, of the imagery. Under any circumstance, it’s pretty hard to beat the responsiveness of a cached map service. In a head-to-head footrace to produce one view of the map, an image service may get close. This is especially true when using low-bandwidth Internet connections, because the cached tiles consist of multiple files whose imagery payload inevitably extends beyond the boundary of the screen. An image service, on the other hand, produces one image whose extent matches that of the current map view.

Cached services really hold the speed advantage when panning, largely due to browser caching. If a tile or a portion of a tile has already been fetched, it doesn’t have to be requested again from the server. An image service, in contrast, makes a new request on every pan.

Scalability

No matter how fast an image service can produce an image, ArcGIS Server (specifically, the Server Object Container) still has to do work to make it happen. The cached map service, on the other hand, does virtually no work on ArcGIS Server. After you make an initial “handshake” with ArcGIS Server to determine whether a cache is available, the Web server just hands you the tiles you want. This is decidedly more scalable than an image service once your application reaches a particular threshold of users. That threshold depends on the processing power of your server and the pattern of requests.

The aforementioned browser caching also reduces the work of your Web server and contributes to the superior scalability of cached services.

Functionality

An advantage of image services is that they are decidedly more functional than cached map services. When working with an image service, you can request a custom projection, image format, resampling technique, band combination, and so on. If your application requires one of these things, an image service may be a better choice.

Image services also let you specify a compression value that can be helpful over low bandwidth networks. You can set a very high compression for quick navigation; then, when you reach the imagery you want, you can reduce the compression to get a better quality image.

You can perform simple queries on either an image service or a cached map service. Queries are possible with cached services because the cache acts as a visualization mechanism only. The administrator can leave the back-end data on the server if end users will need to issue queries to the map service.

Maintainability

For all its performance benefits, caching comes with some overhead. You need time and server power to create the tiles, and hardware to store them. You also need to perform cache updates at some interval to prevent your imagery from becoming stale. If your application offers imagery for a vast area at large scales, you may decide that the excessive work required to build and maintain the cache outweighs the performance benefit.

If you find yourself in this situation, you should ideally perform load testing to understand if the performance of the image service is suitable for your purposes. If the image service is not going to work, you may consider only caching strategic places (such as urban areas) at the largest scales, and displaying uncached areas with a “Data not available” tile. This is the approach used by Bing Maps, Google Maps, and many other Web mapping services that offer large amounts of imagery.

Another option for filling uncached areas is to create tiles on demand. Beware that this requires you to keep the source imagery on the server, and it can introduce scalability issues if you have not sufficiently pre-cached the most popular areas of your map.

Summary

In summary, if the purpose of your imagery is only for visualization as a base layer and you expect moderate to high amounts of traffic on your site, you should attempt to use a cached map service for the imagery. If you want to expose analysis and manipulation of the imagery and you don’t feel that your server will be overwhelmed by concurrent requests, use an image service.

Contributed by Sterling Quinn of the ArcGIS Server development team

This entry was posted in Services and tagged , , , , . Bookmark the permalink.

Leave a Reply

4 Comments

  1. sterlingdq says:

    If users require high scalability for basemap imagery, then caching is the best approach. One useful workflow for generating this basemap cache is to first create an image service (or Mosaic Dataset at V10). Once the image service is created, you can add it to a map document (MXD) that you publish and cache. This way, users that require the more advanced capabilities or fastest update use the image service directly, but users that only need a basemap can use the cached map service. As a general best practice, is it better to keep imagery (using JPEG) and vector maps (using PNG) as separate layers in mashups, and this is one of the reasons that they are not included in MSDs.

  2. kjohn says:

    Sterling, is it possible to publish an mxd with an image service added? or just an mxd with images added that are being stored on the image server?

  3. kjohn says:

    Sterling, is it possible to publish an mxd with an image service added? or just an mxd with images added that are being stored on the image server?

  4. hlzhang525 says:

    Sterling,

    At UC 2012 (San Diego), we saw a tool at 10.1 which converts an image service to cache and feel that it is exactly what we need. In fact, users should have more flexibility to choose either image service (for analysis) or caches (for performance) from image server.

    However, after several trials dealling with massive images (3 TB 0.5-m GeoEye covering about 200,000 sqr KM) located at ‘dedicated’ NAS storage over 2-Gigabit corporate network, we still feel that tool is highly required to further improve as sooner as possible. In other word, it takes forever (after weeks, the process still running) to dynamically create caches up to the scale at 1:1000, so that it still can’t ‘dynamically and effectively’ create cache tiles ‘on request’ in operation.