Should I store ServiceOverviews inside the Geodatabase or keep them in filesystem?

[philippenn]

Currently migrating some v9.3.1 Image Server services into Mosaic Datasets. It seems like the default is to store ServiceOverviews inside the Geodatabase, rather than in the filesystem, alongside the source images.

I feel torn as to whether this default behavior is a good idea. On the one hand, I can see storing all mosaic dataset info in one place as being a good idea. On the other hand, I don't want to obscure the serviceoverviews by placing them into the GDB. I also don't like increasing my GDB size with images. And I'm not sure about the idea of having some images "here" and others "there". So I'm leaning towards the latter.

Is there a Best Practice for this?

TIA

Phil

[EricRice]

Hi Phil,

If you're migrating from stand-alone Image Server and you have source images and SO's already built (in an ISDef), then no images will get loaded into the geodatabase.  Load the MD's using the ISDef file.  The MD will reference both the source and the SO's that already exist.

The default behavior for mosaic dataset overviews changes depending on the type of geodatabase.  I can assume you plan on using an enterprise geodatabase if the overviews are going directly to the gdb.  FGDB mosaic datasets do not load overviews into the FGDB - they create a folder at the same location as the FGDB with the same name, but with a .overviews added to the folder name.

This is a great starting place.
Migrating an .ISDef to a mosaic dataset

This is also a must read if you're going to work with mosaic datasets.
Imagery: Data management patterns and recommendations

Pertinent information for your question.
Mosaic dataset overviews

My personal preference is to not load overviews into my sde geodatabase.  I define them so they go to my file system, where they will reside as tiff files and can be easily managed with OS tools.

Hope this helps!

Regards,
Eric

[philippenn]

Thanks for the full reply & links. Looks like I'll leave them out of the database going forwards (when creating new services, as opposed to migrated ones).

cheers


Phil

[JTessier]

Did this approach work out for you?