Derived mosaic datasets

Derived mosaic datasets are used to merge multiple source mosaic datasets, primarily to enable different collections of imagery to be accessed via one source. The steps to create a derived mosaic dataset are similar to those for a source mosaic dataset.

Create mosaic dataset

Ensure the data type of the derived mosaic dataset is explicitly set to 1 band, and pixel type is 32_BIT_FLOAT.

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. There are also advantages to using Web Mercator as a default spatial reference system since the computation of aspect is not affected by the Web Mercator projection. ArcGIS also includes a specific adjustment for the latitude-based scale factor in Web Mercator to ensure slopes are computed correctly even at larger latitudes. Web Mercator is not suitable for users working primarily in polar latitudes, in which case a more suitable projection should be used. Note that when a client application makes a request to an image service, the client application can define the projection to be used and the system will transform the pixels to the required projection prior to performing the functions. This enables applications to make requests that are pixel aligned with the source and not perform any reprojection. Additionally, when working in maps that use a projection such as UTM, the computations will be performed in the appropriate units.

Add rasters

As described in the Standard Workflow, all data ingested into the derived mosaic datasets should be contained within the source mosaic datasets (no individual rasters should be added to the derived mosaic dataset), and the TABLE raster type should be used.

Ensure the Calculate Cell Sizes option is not on (when adding rasters, or at any other time) for the derived mosaic dataset.

Ensure the Update Boundary option is on, so any source mosaic datasets outside the current boundary will update the boundary. 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, and not recalculated for the derived mosaic dataset.

Metadata

One use of the metadata is to help define the default display order of the elevation data.

As defined in the Mosaic dataset design section, the Best value to be used for ordering elevation needs to be computed. The simplest way to do this is to use a calculation such as Best = 10*[LowPS]. In this way higher-resolution data appears on top of lower-resolution data. Depending on the types and validity of the metadata that you have, you may be able to extend this, such as to use [CE90] instead of [LowPS]. Additionally, if there are other metadata fields such as [Year] that should be taken into consideration, then they can also be included. Example: Best=10*[LowPS]-([YEAR]-2000)/100) could be used to ensure that elevation data that is later is displayed on top.

There is a special case in which the type of the source may also be included in such computation. An example of this is the creation of services that represent digital surface models. In many cases DSM models are not available for all areas and all scales. For such areas, there are two options:

1. Define these areas as NoData, in which case representations in these areas will be blank.
2. Approximate the DSM by the DTM, in which case representations such as slope and aspect will appear the same as the DSM when there is no DTM, and the surface height (computed as DTM-DSM) will return 0.

Case 1 is created by excluding DTMs from the creation of the DSM-derived mosaic datasets.

Case 2 can be obtained by including the DTM in the DSM, but changing the Best computation to include the DEM_Type, for example, Best = 10*[LowPS] + [DEM_Type]. This ensures that in the case of a data collection with both DSM and DEM datasets at the same resolution, the DSM will have a lower value, and thus higher priority, than the DEM.

Footprints and NoData

NoData values should have been correctly defined within the source mosaic datasets by specifying the NoData pixel value (or range of values). The source mosaic datasets should also all have footprints already defined, and the derived mosaic dataset properties should be set to Clip the raster to its footprint: NO.

When the source mosaic datasets are combined in the derived mosaic dataset, any NoData pixels will be filled with valid data from a lower dataset (lower priority, typically lower resolution).

This feature can be used to create the different surface types.

• DTMs with 0 for oceans—If the derived mosaic dataset is to represent land areas only (no bathymetric data included), oceans should be represented with an elevation value of 0. Typically, datasets such as SRTM have 0 for sea areas. If using datasets that represent oceans as NoData, it is best to add to the derived mosaic dataset a small raster (ZeroElevation) that covers the complete data extent and is given a lower priority (large Best value) but has only 0 values. This way NoData values such as sea will get 0. Areas that are not sea would typically be covered by datasets such as SRTM. In the ArcGIS Online World Elevation this Oceans=0 concept is applied.
• DTMs with NoData for sea (or other no data area)—In this case, do not include a ZeroElevation raster, and for datasets such as SRTM, set 0 to be NoData by adding a mask function to each raster.

Refine radiometry

This section refers to changing the data values. This may be necessary in the following situations:

• Converting units, for example, State Plane feet to meters—Typically source mosaic datasets are defined in their source spatial reference. When adding them to a derived mosaic dataset (usually in Web Mercator or metric projection), it is necessary to add a raster function that converts feet to meters. This can be done by including an arithmetic function with multiply by 0.3048 as an additional function during the add raster process.
• Converting between different vertical datums—ArcGIS includes a number of vertical datums, but it does not automatically convert between them. Conversions need to be implemented individually using arithmetic functions as noted above. Refer to the Appendix for further discussion on Managing vertical datums.

Seamline

(Note that seamline blending of elevation has known issues at ArcGIS 10.1, so this is only recommended when using 10.2.)

As defined in the Mosaic dataset design section above, mosaic datasets of elevation data typically contain sources of multiple resolutions, and a Best field is used to order the dataset. The question arises as to what happens at the edges between datasets. By default, ArcGIS does a merge of the datasets with no blend so that the best pixel is on top. This can result in artifacts in the form of jumps appearing along such edges. In many cases such artifacts are not incorrect and should be left as is.

There are cases where you may want to have the edges blended, and this is where seamlines can be used. The ArcGIS functions for seamline generation are written primarily for the blending of optical imagery and are not really applicable for elevation data. For elevation data, the higher-resolution (or accuracy) data should be used to the fullest extent possible, but a blend is required to remove sudden changes. This can be achieved by creating a seamline that falls along the extent of the higher-resolution dataset and defining an inside blend over a specified distance or number of pixels. This process involves the following:

• For the higher-resolution rasters that are to be blended, edit the footprints to make them fit closer with the extent of the NoData areas. This can be achieved using the Build Footprint tools, but increasing the number of allowed vertices. For highly irregular extents, it may be better to shrink the footprints a bit to ensure there are no gaps of NoData. In some cases the extents of the data are known from the data production process and can instead be imported as footprints.
• Run the Generate Seamlines function (using Copy Footprint) to copy the Footprint geometry into the seamline.
• Optionally, reset the footprints back to how they were originally by rerunning build footprints using previous parameters, or by using Import Footprints using a backup of the mosaic dataset before the footprints were refined.
• Edit the Seamline geometry attribute table to set the blend width for the seamline to an appropriate blend distance, in the units of the source mosaic dataset (for example, 5 to 10 pixels), and set the Blend Type to 2 (to blend inside the seamline).

The seamline blending will be seen when the mosaic method is set to Seamline and mosaic operator is set to Blend. Note that the Blend Distance in the Mosaic Dataset properties should generally be set to 0 so that blending does not take place for rasters that do not have seamlines.

There are some issues with the method: It does not work when the higher-resolution datasets have been tiled, since blending will also take place along the tile edges. The resolution to this is to do a merge of the tiles. (There are some known issues with Merge at 10.1, so it is better to use a single raster for the higher-resolution data prior to 10.1). There is a known issue with the seamline blending of elevation at 10.1 that becomes apparent as artifacts along more complex seamlines, but it does work for simpler polygons. It is therefore recommended that the seamline blending of elevation is only added at 10.2.

Mosaic dataset properties

For the derived mosaic dataset, the recommended settings for properties are as follows:

• Transmission compression settings
  • Set Default Method = LZ77.
  • For Mosaic Datasets serving visualizations (Slope Map, Hillshade), change to JPEG Q80.
• Default Resampling Method
  • Set to Bilinear Interpolation.
• Allowed mosaic methods
  • Set Default method to: By Attribute.
  • Order Field = “BEST”.
  • Enable lock raster as an alternative mosaic method.
  • It is generally recommended that other mosaic methods be disabled, since they were designed for optical imagery and are not applicable to elevation data.
• Maximum size of requests: The default is 15,000 by 4,100. The data manager may want to set smaller or larger limits. Recommended values are 4,000 by 4,000, which restricts users from downloading larger datasets.
• Download—Unless your users require the ability to download original source data (and your network bandwidth is adequate to support large data transfers), it is recommended to set Maximum Number of Downloadable Rasters to 0. (Disable download.)
• Set BlendWidth to 0. This is so that if blending is turned on, it is only applied to seamlines that have explicit blend widths.
• Set Always Clip the Raster to its Footprint to No. This is because footprints for elevation data are typically only approximate and could result in elevation data otherwise being clipped. As defined earlier, there are workflows when working with lidar or bathymetry data where you may want to use footprints to explicitly clip out pixels outside the footprints, in which case this should be set to Yes.
• Set Footprints May Contain NoData to Yes so that the system will look for other datasets underneath NoData values.
• Set Always Clip the mosaic dataset to its Boundary’ to No, unless you explicitly want to edit the boundary of the derived mosaic dataset and want to refine areas to be clipped out.
• Statistics—Statistics should not be calculated for the derived mosaic dataset. Nominal values for the elevation statistics covering the entire project area should be stored in a configuration file and imported into the derived mosaic dataset using the Set Raster Properties function.
• Under Raster Information, set Source Type = Elevation. (This is not a critically important setting, but it helps ensure proper rendering in the ArcMap display—see Help for more information.)

Overviews

As noted above under source mosaic datasets, generally a source mosaic dataset that includes lower-resolution data coving the entire areas is used; therefore, overviews are generally not required. For example, SRTM is available at 3 arcseconds (approximately 90 meters), and GMTED at resolutions from 7.5 arcseconds (approximately 250 meters). Typically, overviews are created for these source mosaic datasets and included in the derived mosaic dataset, removing the requirement for overview generation. If such source overviews do not exist, then overviews can be generated for the derived mosaic datasets. See overviews for source mosaic datasets for discussion on the appropriate settings.