Before managing your lidar data, a few initial considerations must be noted.
These recommendations assume the input is lidar data that has been professionally processed and is formatted as follows:
- Stored in LAS format, or alternatively Esri’s optimized LAS format (zLAS). (LAS Optimizer 1.2 provides free tools for creating zLAS files.)
- LAS or zLAS files are typically organized by tiles, or sometimes as flight strips. Tiles may overlap, or they may be edgematched with no overlap. Flight strips typically overlap and may also include cross-strips.
- Lidar data must be properly classified as follows:
- With classification of ground and nonground at a minimum
- Preferably including multiple class codes, for example, Ground, Low/Medium/High Vegetation, Buildings, Water, Noise, and Model Key
- The coordinate system should either be in a well-known projection (for example, UTM or State Plane) or, if horizontal coordinates are GCS (latitude-longitude), the vertical coordinates should be linear (feet or meters).
Data storage
Recommendations for storing your lidar data on disk are generally the same as the best practices for creating mosaic datasets. There are three classes of data to be considered:
- Project-specific metadata
- Original source data in 3D point format (LAS or zLAS files)
- Derived datasets such as the DSM and DTM rasters
It is typically recommended that data from each project be stored in its own directory. This normally includes project metadata and the derived rasters, and it may or may not include the original LAS or zLAS files.
Since the 3D lidar points represent a very large data volume, if users do not have a frequent need to access this original data, some organizations choose to store it in separate, less expensive storage. In this case, when users need to access the original LAS or zLAS data, workflows are provided in Share 3D point files for user download to expose the lidar data files for download.