Solved! Go to Solution.
Jake Skinner wrote:
Mosaic Datasets were introduced at 10.0 and is the latest and greatest. A mosaic dataset will save you time and storage, perform the fastest, and also has the benefits of on-the-fly processing.
I'm also wondering if I should use a raster catalog or mosaic dataset. What I'm not understanding is how can Mosaic datasets save storage if only "pointers" to the images are stored?
I have approx 12000 TIF aerial images about 365GB in size. For a mosaic dataset then, It seems these images must be permanently stored in a folder (on the server) at zero compression. Where as, a "managed" raster catalog can load the images, using compression, then once loaded the "images folder" can be removed saving a lot of storage.
BTW This data will be stored in an Enterprise Geodatabase using SQL Server 2012
Please educate me! Thanks in advance.
Hi Bruce,
I haven't seen any customers delete the initial imagery after loading the data into a raster catalog or raster dataset. In my opinion, this won't be a good practice.
The mosaic dataset will perform MUCH faster than a raster catalog with this many images. This is due to the mosaic dataset's Overviews.
Take a look at this helpful thread.
Jake Skinner wrote:
I haven't seen any customers delete the initial imagery after loading the data into a raster catalog or raster dataset. In my opinion, this won't be a good practice.
Your reply contains some good information - thanks.
I didn't mean to imply my one and only copy of the original imagery would be deleted. That would be bad!
For the raster catalog, I would; (1) copy the uncompressed images from a USB backup drive to the server, (2) load the images into the catalog, (3) verify the results, (4) delete the uncompressed images.
That way, the uncompressed images are not taking up disk space (as they would for a mosaic dataset) and the raster catalog contains the images in a compressed form thereby saving space.
It seems you're working on the assumption that filling a database with raster tiles is a good thing. There are many reasons why this is not so. Back at 8.0, when this capability was first offered, it was the only way to achieve pyramids, so the high overhead in database transaction space and storage and backup complications could be forgiven. It's been a long time since service caches were added to ArcGIS Server, and integration of image server capabilities into mosaic datasets finally drove the stake into the heart of raster catalogs.
Yes, if your base imagery is uncompressed, you should compress it, and serve that instead, but you don't need to use a catalog to accomplish this. Experimentation has shown that files on disk outperform tiles stored in databases. Simple and fast is better than complex and slow.
The number of images you have could be a distraction that is preventing you from getting optimal performance. If you mosaic your uncompressed images into 3x3 compressed composites, you'll reduce the number of images by an order of magnitude. and probably improve overall performance.
- V
Isn't the Image Server Extension needed to serve out a mosaic dataset when some of your users do not have access to the file system location containing the mosaic and the imagery? Image Server Extension is pricey so we are still hosting imagery in SQL/SDE. Yes, we know it's not as fast and that we have to save a SQL backup of the data so it does takes basically double the disk space!
Mosaic Datasets were introduced at 10.0 and is the latest and greatest. A mosaic dataset will save you time and storage, perform the fastest, and also has the benefits of on-the-fly processing.