Tiling/Caching and Me

[ChadHall]

I have some complaints from those consuming my web services that the ArcGIS tiling structure isn't suitable.  More specifically, they want to zoom in closer than allowed with the standard Street/Aerial/Topo mashups.  I have an raster catalog that I'm about to cache but I will cache it at more acceptable scales for them but this will essentially render the mashups null and void correct?

Or can I just extend the scales from say 1:4,000 being the closest I can get with ESRI data on down to 1:3,000, 1:2,000, 1:1,000, etc?

I really like the ability to mashup but our company uses the the webservices on practically a household scale level which is not currently available.

Any help would be greatly appreciated.

Thanks,
Chad

[BjornSvensson]

If you are using the API, check out the CustomLODS sample
http://help.arcgis.com/en/webapi/flex/samples/index.html?sample=CustomLODS

If you are using the Viewer, either wait for the next version, or look at earlier forum posts.  I vaguely recall someone asking this earlier.

[ChadHall]

If by API you mean uncompiled and Viewer you mean compiled, then I will have to wait since I'm using the compiled sample viewer to push my services out to the client.  I did run a test cache and it took 50 minutes to do 4 MrSid tiles.  I have a total of 1942 tiles to cache which estimating will take at least 17 days at my current scales.  But when analyzing my service, it popped up with 4 warnings saying "Layer's data source uses wavelet compression".  I thought SID's were good for imagery.  Is there a better solution to decrease the cache time but keep the imagery quality?

[SterlingQuinn]

This article on the wavelet compression error has some good insights: http://help.arcgis.com/en/arcgisdesktop/10.0/help/00sq/00sq0000000t000000.htm   What you did with building the test cache is the right approach. But as long as you stay with the SIDs, it will probably take 17 days.

Depending on how much space and imagery you're dealing with, a faster alternative might be to create JPEG or TIFF copies of your imagery and then cache that (as JPEG). Although JPEG is a lossy format, the loss cannot be easily spotted by the untrained eye if the compression quality is high enough. (In our experience, you can get away with a quality down to even about JPEG 55 before you really start seeing a difference- but if you're caching a JPEG of a source JPEG, you should run your own tests on quality to find the most acceptable level).

If the imagery copies are going to be for visualization only, then some loss of data doesn't matter. If you're going to do some kind of analysis or processing on the imagery, you can go back to the source SIDs.

Sterling