Best Practices - Raster Catalog > Image Service

2580
3
05-14-2014 01:19 PM
BugPie
by
Occasional Contributor III
Good afternoon gang!

I have been poking around all the ESRI resources, and didn't find exactly what I needed. We are looking at using the Image Server Extension to incorporate some topographic data sets as a basemap into our customized server site. Yes, I know there are already map services from ESRI and USGS etc that accomplish this. However, one of our requirements is that the SR of our basemap cannot be WGS 84,among other req's like owning our data etc. so there goes the cached service from ESRI

Currently, we have 5 Raster Catalogs each containing a specific geographic area of custom topo map images. Soon we will have 5 raster catalogs which contain imagery in this same geographic extent as the topos. These will both grow in data over the coming years 

Is it possible or recommended to store our data this way if we want to serve as a single  image service? I ask because I have not been able to figure out the best way to create a Referenced Mosaic using more than one Raster Catalog, hence why we only have a single image service for each Raster Catalog or ref mosaic. If our dataset will eventually grow to TB sizes, I would assume a single raster catalog would NOT be the way to go, but maybe I'm wrong?


What's the consensus out there? How should we attack this?
3 Replies
larryzhang1
New Contributor III
Good afternoon gang!

I have been poking around all the ESRI resources, and didn't find exactly what I needed. We are looking at using the Image Server Extension to incorporate some topographic data sets as a basemap into our customized server site. Yes, I know there are already map services from ESRI and USGS etc that accomplish this. However, one of our requirements is that the SR of our basemap cannot be WGS 84,among other req's like owning our data etc. so there goes the cached service from ESRI

Currently, we have 5 Raster Catalogs each containing a specific geographic area of custom topo map images. Soon we will have 5 raster catalogs which contain imagery in this same geographic extent as the topos. These will both grow in data over the coming years 

Is it possible or recommended to store our data this way if we want to serve as a single  image service? I ask because I have not been able to figure out the best way to create a Referenced Mosaic using more than one Raster Catalog, hence why we only have a single image service for each Raster Catalog or ref mosaic. If our dataset will eventually grow to TB sizes, I would assume a single raster catalog would NOT be the way to go, but maybe I'm wrong?


What's the consensus out there? How should we attack this?



Collin,

Firstly, there is not the best practice available to us.  Personally, how to organize image sources and manage image services are fully relied on your organization's applications and purposes.

However, some technical and operational factors should be considered, before taking actions�?�

On your description, it looks that your data are going to be �??time-serial�?? images covering different spatial areas (saying, area A, B, C�?�), which are geospatially located at different locations. If so, the following are listed for your reference:

#1. You can manage all into �??one�?? regular Mosaic Dataset by an additional field �??Year�?? via adding �??year-based�?? raster catalogs, and then create a �??Year-based�?? referenced Mosaic Dataset on selection of �??Year�??. In this way, you can achieve the purpose of raster management. However, you couldn�??t create overviews onto this referenced Mosaic Dataset, which is necessary to serve as image service�?�

#2. The �??year-based�?? regular Mosaic Dataset with its overviews, which contains all raster from different areas but 'single' year, is separately created and then combined into �??one�?? single �??time-serial�?? Mosaic Dataset (with an additional field �??Year�??). In this way, however, to properly visualize, you should use with �??Time Slider�?? function in clients like ArcGIS. Besides, the image service is not easily updated and also not flexible in diverse applications �?�

#3. The �??year-based�?? regular Mosaic Dataset with its overviews containing all areas is separately created and then directly served as time-serial image service (saying, *****2014; ******2015, etc.). In this way, the services are more flexible/easier to use and also can widely support many �??diverse�?? applications like �??change detection�?? analysis and image analysis�?� With this approach, it is also much easy to update (weekly, monthly �?�), without any interruption, meanwhile customers still can access those image services �?�

Finally, the use of datum/projection in 'single' Mosaic dataset mostly depends on your specific scenario, saying, those areas located in one continent/ one province /state /county, or your organization standard of spatial reference to be used in applications ... ?

Hope it is helpful to you. Pls also share your practice, once done...
0 Kudos
CodyBenkelman
Esri Regular Contributor

Collin

I apologize for the VERY long delay since you posted this question.  I'll keep my response very brief but if you still need  advice and information, please contact me.

We are building documentation focused on Best Practices regarding managing and serving imagery (including lidar and elevation data).  The starting point is this landing page http://esriurl.com/6550 which points you to detailed discussion in a Guidebook in ArcGIS Help, and also to an AGOL Group with downloadable tools to show examples for different types of data (elevation, preprocessed orthophotos, scanned maps, etc.).

Cody B.

RebeccaStrauch__GISP
MVP Emeritus

I'm adding these questions to this thread because I believe they fall under the heading of "best practices"

Cody Benkelman‌‌  re: your mention of the best practices guidebook above..... for caching from a Image Service extension service, the guidebook, help, and the tech session at the UC all mention that it is best to cache the largest scale (in my case, the source resolution) and let the other cache levels be built from that, which is opposite of the thought process I have used before.  In my situation, I am building the cache from a image service based on a mosaic dataset. This dataset has many gaps (i.e. data is still being collected, and some areas will not have data (ocean))

Questions:

- Should I specify area-of-interest to only those areas that I know there is data, and if so, is there a way of specifying this thru/from my mosaic dataset?  OR, is the image service smart enough to handle this (that is, I don't want a large no-data area.

- Is there anything special I need to check to have the other levels work off the first (L09) that I create? Update below

- If I plan to do one level at a time (due to network resources), should I run L08 complete, then L07, etc? Update below

Thanks

Update -- still have a question about specifying Area of Interest when caching, and whether it is necessary. However, the image service caching does seem to know to create the cache from L09 to L08 to L07, etc. on it's own. yea.

0 Kudos