topic Re: exploded or compact storage format for cached orthophotos? in ArcGIS Enterprise Questions

exploded or compact storage format for cached orthophotos?

FatinRimawi — Mon, 22 May 2017 12:17:35 GMT

Hi All,

I cached 2 map services.One of them was cached using exploded option and the other map was cached using compact.

The same scales were cached for both maps.

I am wondering about a method to calculate the performance / speed for each one, so I can choose which cached map can be used later.

Thank you in Advance

Best

Fatin

Re: exploded or compact storage format for cached orthophotos?

JayantaPoddar — Mon, 22 May 2017 12:55:20 GMT

Compact cache looks more promising according to Esri Documentation. Available map and image cache properties

Compact—In compact format, each file in the cache contains a bundle of tiles. The bundles are 128 tiles wide by 128 tiles high, containing a maximum of 16,384 tiles. Compact caches copy much faster than exploded caches, and they take less space on disk.
Exploded—In exploded format, each tile is stored as a file on disk. This makes it easier to see the tiles in your cache; however, it results in larger caches that take longer to create and can be cumbersome to copy.
The enormous number of files and folders in the cache can sometimes cause inefficiencies in copying utilities, including Windows Copy/Paste. For this reason, compact caches greatly reduce cache copying time. If you have an automatic cache update workflow that creates tiles on a staging server and copies them to a production server, it's recommended that you use compact caches. Additionally, if you have limited disk space available, you should use compact caches.

You could check the response time of the corresponding services in ArcGIS Server Statistics.

Re: exploded or compact storage format for cached orthophotos?

FatinRimawi — Mon, 22 May 2017 13:31:03 GMT

Thank you Jayanta for your kind reply.

I am also asking about performance.

I tried to zoom in and out for both cached maps (exploded map and compact map) but I notice no differences between speed of display.

Moreover, I notice that the legibility for both cached maps is the same.

Am I right?

What do you think?

All the Best,

Fatin

Re: exploded or compact storage format for cached orthophotos?

JayantaPoddar — Mon, 22 May 2017 13:40:49 GMT

For small cached images, the difference might be negligible. Moreover, I can already see the difference in size of tiles (which are 100% completed). Has the cache status completed 100% for all the scales?

Re: exploded or compact storage format for cached orthophotos?

FatinRimawi — Mon, 22 May 2017 13:59:32 GMT

I took a small area as a sample, but what happens if one take a large cached image? which storage format option would be better?

To answer you inquiry: all scales were cached with the percentage that appeared on the screenshot.

job status for both cached map was 100%

Best,

Fatin

Re: exploded or compact storage format for cached orthophotos?

RebeccaStrauch__GISP — Mon, 22 May 2017 14:12:26 GMT

Where you will save the most is disk space. But if you are testing speed on the same machine as the cache is stored, you may not see much of a difference. Try accessing and testing thru a web page or the rest endpoint from an external machine (using your web adaptor). Compact format will have to pass fewer files each time as you zoom in, so this throughout is where I think you will see the time saving.

If not being used as a base map and you have the Image Server (extension), using mosaic databases with an Image Server is another way to go. But if strictly base map, I still think caches are a better choice (my opinion). If I want the option to have as a base map, but still want the option to use the functions that are available with image services, I typically do two services in that case, one with a cache, one without...using the same mosaic dataset as the source.

Re: exploded or compact storage format for cached orthophotos?

FatinRimawi — Mon, 22 May 2017 16:03:51 GMT

Thank you Rebecca for you valuable reply.