2

We currently have all of our image data loaded into ArcGIS SDE/Oracle 9.3. There is a proposal to not load our 2015 orthoimagery into SDE/Oracle in order to save time and place it in a tile cache or gdb on a network drive. Historically the image data has been around 250GB in size. The orthoimagery would be used simultaneously (read only) by many ArcGIS 10.1 desktop users (I would estimate ~100 max, probably more like 30 on a normal day). Are we likely to have performance problems with this approach? If there is no big down side what would be the recommended format to keep the orthoimagery in?

I guess the other option would be to place it on the ArcGIS server's local drive and just let the users consume the data as a ArcGIS map service.

Improve this question
3
  • 1
    Keep in mind questions that ask 'best' are often closed as being too broad/opinion based. A better way to phrase your question might be 'is there a recommended format'.
    – Chris W
    Commented Sep 11, 2015 at 19:27
  • This would be primarily opinion-based if it weren't for the fact that Esri has been trying to get users to stop using ArcSDE-based rasters since tiled map services were added at 9.2, and especially since mosaic datasets were released at 10.0. You will need to edit the question to specify the version of ArcGIS in your clients (9.x has been retired for a while now).
    – Vince
    Commented Sep 11, 2015 at 19:27
  • To add to Chris W's point, questions that end in "Thoughts?" are much more likely to be closed as off topic as well. Please take the Tour for a better idea of how things work here at GIS SE.
    – Vince
    Commented Sep 11, 2015 at 19:55

1 Answer 1

Reset to default
1

Using databases to store rasters peaked in the ArcGIS 8.3-9.1 timeframe. Once ArcGIS Server 9.2 could fashion mapping caches, the need for a tiled basemap in the database waned. Modern raster support hinges around mosaic datasets, which are file-based, and are much faster and more flexible than database solutions. Mosaic datasets have the benefits of retaining the original images in their native format, provide overlays for tiled access, permit onthe-fly calculation of alternate forms (e.g, hillshade from a DEM and reclassification), and they don't fill your database transaction logs with terabytes of static data

So the suggestion is to move to Mosaic Dataset.

Improve this answer
6
  • 2
    You need to mention that Mosaic Datasets require an Image Server extension license to be served by ArcGIS Server.
    – Vince
    Commented Sep 11, 2015 at 19:32
  • Thanks Farid. Just to be clear, you would suggest that we make file geodatabases with mosaic datasets and let people use them right off the network drive. You feel this would be better then providing a service of the mosaics with ArcServer?
    – fallingdog
    Commented Sep 11, 2015 at 22:21
  • Considering you have an Image Server Extension license, I definitely suggest to go for mosaic dataset in a File Geodatabase. You will feel the performance gain as soon as you load all of your DBMS rasters into a mosaic dataset.
    – Farid Cheraghi
    Commented Sep 11, 2015 at 23:52
  • If you have the Image Server extension, then there's no reason not to serve the raster mosaics through AGS, and get the I/O benefit of not reading the FGDB over the LAN. If you don't have Image Server, then the question becomes whether a raster catalog in a map service out-performs a raster mosaic on a network share.
    – Vince
    Commented Sep 12, 2015 at 3:39
  • Thanks for the feedback everyone. So, we can get an image server extension; therefor, we could serve the mosaic dataset. However, would it not be better (faster) to build a tile cache off of the mosaic and serve that as a map service? This is currently what we have in place for our web map app, but the cache is made off of a raster dataset not a mosaic dataset. resources.arcgis.com/en/communities/imagery/… blogs.esri.com/esri/arcgis/2010/05/04/…
    – fallingdog
    Commented Sep 15, 2015 at 22:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.