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.


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.


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.


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.


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.


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


  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:


    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.

  5. mkoneya says:

    We have been discussing the performance of Image vs. Cached service at our office so this I see this was very informative. I see that it was written in 2010, so I was wondering if this information still applies to ArcGIS Server 10.2x or 10.3x Thanks

  6. naeemalig says:

    I have satellite images of approx. 3 TB covering full country.
    What could be the best way to server them in ArcGIS viewer for flex without having Image server extension?

  7. mchilcott says:

    One can have a cached maps service, but one can also have a cached image service. To make this a little more complex, one can also create a skeleton map service.

    We started out in 2012 using cached image services, mainly as we required WMS capability on the service, and cached map services did not support this. Generally the way we created this was to create a tile cache, then in ArcCatalog you right click the cache (which appears as a raster dataset) and publish. When you publish the service through Server, you cache it. This creates the directory structure for the cache of the raster. At this point, you can copy the tile cache to the cache – or you can use symbolic links. Bottom line is you have a cached image service – so when a rest call is made to the service, the tiles are returned. That is roughly what we do.

    However, we have found that esri generally do not test cached image services to the level of cached map services – so we seem to come across a number of bugs that trip us up. Things like printing from ArcMap, how ArcGIS Online and collector interact with the cached image service – bugs there to etc.

    Therefore – I would recommend people use cached map services over cached image services. Less bugs, same performance.

    Specifically – skeleton map services are probably the way to go.


    • azin.sharaf says:

      Hi Mark,

      Thanks for your useful comment. Do you have bug numbers related to cached image service so I can dig into them. I would prefer to use cashed image service unless I find those bugs a show stopper.