Appendix

This appendix includes useful background information for this workflow not included in the discussion above.

Design considerations regarding multiple elevation surfaces

1. As noted in Mosaic dataset design above, it is assumed that the fundamental layer for an elevation service is a bare earth digital elevation model (DEM). However, if the system must support other surface models, such as a first return digital surface model (DSM) (including tree canopy, buildings, and so on) or a hydrologically enforced DEM (see ArcGIS Help), the design for various mosaic datasets is somewhat more complicated.
2. It is generally recommended to manage fundamentally different surfaces in separate derived mosaic datasets, for example, DEM for bare earth, DSM for top surface, hydro DEM, and bathymetry. After the multiple surfaces have been created, they may reference each other if composite products are desired (for example, calculation of SurfaceHeight = DSM minus digital terrain model [DTM]).
3. If your system includes a derived mosaic dataset representing the DSM, areas lacking unique DSM data may be managed in two ways:
   • To eliminate NoData areas in the DSM, it is typically recommended to include all records from the DTM. Do this by ingesting the DTM into the DSM using the TABLE raster type to fill in DSM NoData areas with elevation from the underlying DTM. Use the DEM_Type field to identify DSM versus DTM records.
   • Alternatively, if usage of the DSM explicitly accommodates NoData areas, the DSM can include only pixels with unique DSM data, with large areas of NoData. In this case, it is recommended that the DSM NoData areas be bounded by footprints, and where NoData holes are required, fill with a specific pixel value (for example, -9999), and use LZW compression to minimize data storage.
4. If ellipsoidal heights are desired (for example, for orthorectification of satellite imagery), a unique derived mosaic dataset is not necessary. The conversion from orthometric to ellipsoidal height may be implemented as a simple arithmetic function:
   • Create a referenced mosaic dataset based on the DTM, then insert an arithmetic function and add the appropriate geoids.
   • Or, include the arithmetic function as a server raster function (*.rft.xml file) applied on the DTM image service. Refer to the Referenced mosaic datasets topic above for a discussion of advantages of these two different methods.
   • Refer to this link for a general discussion of converting between ellipsoidal and orthometric height, or see this ArcGIS Resources blog post specific to EGM2008: Converting from orthometric to ellipsoidal heights using EGM2008
   • If only one global geoid is required to support ellipsoidal height (EGM2008), it may be simplest to use this as a single worldwide image. However, if the user organization requires use of multiple geoids, a source mosaic dataset is recommended to manage different geoid corrections in different regions.
5. Different methods are available for how to represent large water bodies. Options include oceans & seas are considered NoData, ocean is elevation = 0, or oceans & seas are represented with bathymetric data. The proper choice will depend on the applications the data must support.
   • For most applications, it is best to represent any sea level regions with 0. If the sea is defined as NoData, then some processes (for example, orthorectification) that access NoData areas will fail.
   • If datasets exist with oceans represented with NoData, a simple method to fill in with zero values is to add a very low-resolution "dummy image" with height = 0 everywhere, with extents to cover the whole earth and set this dummy image as lowest priority for display. If any areas of NoData remain, 0 will appear from the dummy image.
   • If the system will include bathymetric data, note that elevation values in the oceans will be negative, but visualizations of the ocean floor can be generated.

Managing vertical datums

1. ArcGIS does not have built-in methods for managing different vertical datums. This design assumes all data is orthometric height, and that the VerticalDatum field is populated for all datasets. Within the boundaries of any individual data collection, the elevation values may be used for analysis since they are referenced to a single datum.
2. If a user wants to compare elevation values from data collections referenced to different datums, any offsets between their datums must be considered within the analysis. If it is necessary to align data from two or more vertical datums, arithmetic functions may be used to transform all datasets to the most appropriate common datum.

Terminology

1. Data collection as used in this document refers to all data from a common source that may be considered contiguous and consistent, for example, National Elevation Dataset (NED) 1/3 arcsecond data from the U.S. Geological Survey (USGS) that is a single collection, or a new lidar collection received from a data provider or alternatively received from a government agency that paid for the data. Dataset typically refers to a single data file, so the NED 1/3 arcsecond data collection is composed of many datasets.
2. DTM versus DEM: Esri recommends that readers refer to this text for an official definition of the terms DTM, DEM, and DSM:
   • Maune, David F., ed., Digital Elevation Model Technologies and Applications: The DEM Users Manual, 2nd ed. (Bethesda, Maryland: American Society for Photogrammetry and Remote Sensing [ASPRS], 2007). ISBN#: 1-57083-082-7

   Within this workflow, we refer to the composite bare earth elevation model as a DTM, based on the following logic. Since the derived mosaic dataset references multiple sources in different projections, the worldwide elevation data does not use one single coordinate system, and by strict definition cannot be a DEM. However, note that in most cases, the individual source files are regularly gridded DEMs, and also that any export of data out of the derived mosaic dataset will be presented as a regularly gridded DEM in a single coordinate system.

3. Data download and export: For those users requiring access to the numeric data values within a region of interest (ROI), note that ArcGIS provides two methods for client software to request the data: download and export...
   • Download refers to transmitting the original (full resolution, nonresampled) data values, typically within a user-specified ROI. Note that any sampling of elevation data will change the data values, so any users seeking access to the data values must be informed of the difference. If resampled using export, the data values will be altered, and this can include oversampling an elevation dataset, for example, requesting data within an ROI with resolution greater than the original cell size.
   • Export refers to transmitting data values within a user-specified ROI, resampled to the resolution and coordinate system of the ROI.

Note that either method has the potential to transfer a very large data volume from server to client, so appropriate constraints are recommended to either limit the data transfer size, or ensure the user and system are prepared for large requests. Refer to the Publishing section for more details.

Also note that an intelligent export tool will be available soon on the ArcGIS Resources website. This tool will allow users to extract an area of interest that is pixel-aligned with the original data.