Caching vs Image Service - performance question

THayes2000

I have 9GB of .tif files. They are all rectangular, adjacent, and are a series of separate .tif files.

I have ArcGIS Server 10.1 Advanced. I do not have the Image Service Extension.

Here is my current set up, with regards to imagery:

- I have mosaiced the.tifs into a .sid file. I have published it from an MXD as a Map Service. I then cached it with 5 scales; 1:288, 1:750, 1:1000, 1:2500, and 1:5000. It works fine, but as is usual, my users want something faster and better.

- The imagery is 3in res RGB.

- Without Caching, the image is very slow; all the users of our Map Viewer complain how slow it is. But, with caching, they need to see down to 25 scale, which they cannot do at the moment. That means I need to create a 11GB Cache. Something that does not seem to be an option since ArcGIS Server does not process caches this large. I have tried only to see the caching process stop after 5 days.


My question:

Will creating a File Geodatabase and building a Raster Catalog and/or Raster Mosaic from the .tif files; then publishing as an Image Service improve performance without the need for Caching?

I have tried setting up a Raster Catalog and Raster Mosaic in a File Geodatabase from Desktop 10.1 and it appears to refresh much faster than the original .tifs and the .sid file.

larryzhang

Timothy,This is a very common question Image Service verses Image Cache. The answer very much depends on your final product. If it is a static image back drop then cache is faster but if image processing is required then image services are better. For a good discussion on this topic see the following blog http://blogs.esri.com/esri/arcgis/2010/05/04/imagery-in-web-applications-should-i-use-a-cached-map-service-or-an-image-service/In either case I can say you should use a mosaic dataset it will display the image faster in ArcMap than you currently see it displaying. You only need image extension to serve the mosaic dataset. However there is a tool at 10.1 which converts an image service to cache which you will also find useful.RegardsGordon

Hi, Gordon,

At UC 2012 (San Diego), we saw the demo of that tool at 10.1 which converts an image service to caches and feel it is exactly what our customer�??s need (a breakthrough implementation of 10.1). Yes, users should have more flexibility to choose either image service (for analysis) or caches (for performance), even both at same time, from image server.

However, after several trials, which are using massive images (3 TB 0.5-m GeoEye covering about 200,000 sqr KM) located at �??dedicated�?? NAS storage over 2-Gigabit corporate network, it takes forever (after weeks, the process still running) to create caches (up to the scale at 1:1000). Obviously, it still can�??t create cache tiles in operation, �??dynamically and effectively�??.

Personally, that tool algorithm is highly required to further improve for efficiency.

Regards,


__________________
Note,

On NAS storage against Mosaic Datasets & caching operation, we would like to share our hands-on thoughts:

1. With 10.0, it looks that the mosaic dataset model couldn�??t deal with massive sources located at above NAS over the 1-2 Gigabit corporate network for creation of mosaic datasets (currently, we are using 10 Gigabit SAN network for image server, which is not manageable for IT storage group, when data is growing daily);
2. With 10.1, however, it can create Mosaic Dataset;

Besides, on the cache operation with ArcGIS Server 10.1 (if focusing on efficiency when dealing with NAS storages), it looks still not very functional and effective, no matter how to conduct caches (either via �??dynamically�?? cache from image service, or �??directly�?? cache onto images, raster catalogs & mosaic datasets with ArcGIS Server).

The above comparison gives us some indications that the algorithms of the mosaic dataset model 10.1 have been significantly improved, but the cache algorithms in 10.1 have not.