AnsweredAssumed Answered

Things to consider when creating raster proxies for the cloud

Question asked by nccgia on Aug 30, 2019
Latest reply on Aug 30, 2019 by pbecker-esristaff

We are in the process of moving from on-prem servers to AWS. We have several image services and underlying data that we need to migrate. We are converting source tif's to MRF and will be storing these in S3. As we go through this learning curve we've developed a few questions that hopefully aren't too ignorant. If someone could share their expertise, we would greatly appreciate it.

  • Why would one want to create overviews and then convert to raster proxies rather than letting the raster proxy cache be created dynamically?
  • Why would someone want to create external raster proxy files rather than having them embedded in the mosaic dataset?
  • How could we estimate the disk space needed for the raster proxy cache? Use the disk space needed for our on-prem overviews? Size of one of our cached image services?
  • What is the best practice, have mosaic datasets in individual FGDB's on each GIS server instance or in an enterprise geodatabase?
  • Is it best to set image compression, pyramid compression, and raster proxy compression to use the same type of compression for performance? All LERC, all JPEG, etc.
  • Historically, our imagery is primarily used for background contextual viewing and we have always used JPEG compression. We have always included a notice to users that because of the compression, it should not be used for any type of analysis. Would using LERC compression remove this caveat? If so, what are the recommended settings we should use?


Thanks again for any insight.