Derived mosaic datasets
A derived mosaic dataset is used to merge multiple source mosaic datasets into one collection to simplify user access. The steps involved in creating a derived mosaic dataset are similar to those of a source mosaic dataset.
Creating mosaic datasets
The spatial reference for the derived mosaic dataset must cover the full extent of all project data, current and future. For compatibility with web maps, the WGS 1984 Web Mercator (Auxiliary Sphere) is generally recommended.
Ensure the data type of the derived mosaic dataset is set to accommodate all expected browse imagery. This is typically three bands, with pixel type = 8_BIT_SIGNED, but this should be verified based on the browse imagery available to you.
Adding rasters
As described in the Standard Workflow, all data ingested into the derived mosaic dataset should first be contained within source mosaic datasets (no individual rasters should be added to the derived mosaic dataset), and the Table raster type should then be used to ingest the source into the derived mosaic dataset.
Ensure the Update Boundary option is checked off so that the system does not attempt to regenerate the boundary based on the potentially millions of footprints. Typically, the boundary will also be approximated to an envelope.
Cell sizes
As noted above, the cell sizes should be properly set for each collection of data within their respective source mosaic dataset. Ensure the Calculate Cell Sizes option is not on (when adding rasters, or when you rerun at any other time) for the derived mosaic dataset.
Building boundaries
Set the boundary to the envelope of all the data by using the Build Boundary tool with simplification method set to ENVELOPE. Alternatively set the boundary to be an envelope that has an extent that covers all possible imagery to be added.
Setting properties
This step is important as it sets all the properties of the derived mosaic dataset that will be used for querying the imagery, either directly or, more commonly, as an image service. Most properties may be left to default values, but these are recommendations for nondefault settings:
Attribute | Value | Comments |
|---|---|---|
max_num_per_mosaic | 100 | To allow larger number of overlapping browse imagery to be displayed. |
rows_maximum_imagesize | 4000 | Sufficient for largest screens, but not for large plots. |
columns_maximum_imagesize | 4000 | Sufficient for largest screens, but not for large plots. |
default_compression_type | JPEG | |
JPEG_quality | 75 | |
resampling_type | Bilinear | |
clip_to_footprints | Yes | Important due to potential for large areas of NoData. |
clip_to_boundary | No | Boundary should be the full extent of all data. |
footprints_may_contain_nodata | No | Clip_to_footprints=yes will remove NoData. |
allowed_mosaic_methods | ByAttribute, LockRaster, Closest to Center | |
default_mosaic_method | ByAttribute | |
order_field | AcquisitionDate | |
order_base | 2050/1/1 | Set to a date in the future. |
blend_width | 0 | Not required (blending is intended to create a seamless mosaic). |
cell_size_tolerance | 10 | Such filtering is not required. |
minimum_pixel_contribution | 100 | To remove insignificant contributors. |
transmission_fields | TBD | Select those that are required. |
use_time | Yes | Time is a key part of such services. |
start_time_field, end_time_field | AcquisitionDate |
Indexing fields
As these browse mosaic datasets may contain very large numbers of images, optimizing search is very important. It is necessary to index the database on the fields that would typically be searched, such as AcquisitionDate, CloudCover, and possibly others.
Creating an index in a database table means to presort a key field which may be commonly used for searching. After building an index for key fields, the database can quickly search records based on any of those indexed fields. To do this, run the Add Attribute Index geoprocessing tool for all the fields considered to be important.
Overviews
Due to the dynamic nature of the mosaic dataset supporting browse imagery, generating overviews is not recommended. If reduced-resolution views are desired to provide users with geographic context, it is recommended that a contiguous and consistent dataset (for example, the Landsat NaturalVue data) is used in place of overviews. Users can also reference a basemap layer (accessed via ArcGIS Online) to provide geographic context while browsing. Ensure such added overview images have their category set to 3 (overview) in the attribute table, which will exclude them from most searches.