Mosaic Raster Imagery for Multiple Years

LanceCole

I have always used multiple mosaic datasets in a file or enterprise geodatabase to store our aerial imagery by reference.  I  create a mosaic dataset for each new flight and users can access the different years by selecting the appropriate dataset.  As I was preparing to add a new dataset, I reviewed the documentation and recommended process.  Apparently, I should be taking this a step further and building a "master mosaic dataset" by adding each years mosaic dataset to this master and making the dataset time aware by adding date information.  Over all this makes sense; however, I have several questions.

1) How is there an advantage when you would need to filter the data to render each year individually?  We do not do any temporal analysis on the data but only display the data for the end user by year.

2) An ESRI video (Managing Imagery Using Mosaic Datasets and Image Services - 43:58) recommended having only one mosaic dataset per geodatabase.  We have never really had any issues with the seven datasets we currently use and are were planning to add an eighth.  Should we expect to see a performance improvement creating a master dataset?

3) The recommended workflow in Creating a mosaic dataset containing raster data from multiple dates indicates that "This design is optimal when you have less than eight rows added to your master mosaic dataset."  It does not go on to explain why or provide an alternative for larger collections.  What are our options as we are reaching this point?

Cody Benkelman

Lance 

Sorry I didn't respond soonr.  The single best resource for these questions about "What is recommended?" is our Imagery Workflows site at http://esriurl.com/ImageryWorkflows.  Specific sections I would recommend are the overview topic of Image Management starting at https://doc.arcgis.com/en/imagery/workflows/best-practices/what-are-best-practices.htm (continue with the rest of the section on Image Management) and a specific discussion of the multi-year case in  https://doc.arcgis.com/en/imagery/workflows/resources/managing-preprocessed-orthophotos.htm 

Regarding that post that you found from 2016 - and I regret that I did not discuss this more deeply at that time.  My caution about the 'pitfalls' focuses on which raster type is used when adding a mosaic dataset (MD) as input to another mosaic dataset.  

Briefly:

• I recommend *against* using the default "Raster Dataset" raster type which is recommended in the post you reference  Creating a mosaic dataset containing raster data from multiple dates  If you have 3 input MDs and use that raster type, your master MD will only have 3 records.  That may seem convenient and in some limited cases I'd say "Yes go ahead" but it can lead to performannce problems if you have 8 or 10 or more MDs and especially if you 'nest' them further in another layer of hierarchy because you've embedded database tables as single records inside other tables.
• What I *do* recommend in most cases is to use the Table raster type.  In my last statement, if you have 3 MDs with 100 records each as source data, your master MD will have all 300 records.  This avoids performance problems but it does (generally) require the additional step of defining one or more custom fields e.g. "Year" or "Date" as you note, and I also recommend adding a field (we typically call it "Dataset_ID") into each source MD so that the master MD will clearly show the source MD for each of the 300 records. 
  • Hoping to avoid confusion, I should note that some of our documentation refers to the master MD as a "Derived" mosaic dataset - but this name is simply a convention, not a formally defined term.
• You also asked "How is there an advantage when you would need to filter the data to render each year individually?"  If you only have a small number of image collections (years or separate projects) this is not a major concern, but if you share each as a separate image service, those services will consume resources on the server even if nobody is using them.  If many collections are shared in a single image service, your use of server resources is more efficient (better performance).  The Landsat service is a good example - millions of individual records and it performs very well.   But yes, you do have to provide users with the ability to select images by date (or other attributes as necessary) - see the Time Selector tool in the Landsat Explorer app.
• Last, re: the Esri video in your 2nd reference, I do not agree that you need to create a new GDB for every MD.  I've never attempted nor felt a need for hundreds of MDs - and there probably is some reasonable limit - but multiple MDs in a single geodatabase should not be a problem.

Cody B.