Database support for terrain datasets
Terrain datasets, and the data used to define them, are stored in a geodatabase. This maintains consistency with how all your other GIS data is stored. Terrain datasets don't need to be treated as something special that can only reside outside the database in files. Therefore, data management is more straightforward and productive. Terrains inherit the benefits geodatabases offer in terms of their data management capabilities.
ArcSDE, personal, and file geodatabases are supported. This accommodates large organizations needing advanced multiuser access to a centralized database as well as smaller shops with individual users accessing project data. Personal geodatabases are the least capable and should be restricted to terrains involving 20 million points or less. File geodatabases can be used for terrains with billions of points. ArcSDE is the most capable and appropriate for terrains whose point sets may grow into the billions.
Database technology applied to the original vector source data provides a superior solution for managing a topographic or bathymetric base over time. Source measurements are stored, not derivative rasters. The measurements themselves can be edited to remove blunders. They can be replaced with more current or accurate data. Updates can be performed on subareas. Raster and TIN surfaces, commonly used for day-to-day analysis, are easily produced. It's therefore appropriate to consider terrains as a data management tool. They enable you to own and manage the source data and produce end-user products (for example, DEMs) as needed.
Geodatabase considerations
Terrain datasets are supported in all geodatabase formats supported by ArcGIS. These storage mechanisms have inherent differences in capabilities. Personal geodatabases are limited to 2 GB in size, and coordinates are not compressed. Because of these constraints, terrains stored in personal geodatabases should not exceed 20 million points. File geodatabases can support larger datasets. If you need to edit and maintain a terrain over time, ArcSDE provides the best solution, particularly with larger datasets.
Storing large point collections in the geodatabase
Automated sensors have a tendency to produce very large collections of points. Lidar and multibeam sonar technologies are examples. Dedicating a database row for each point is expensive. The access time and storage space required for this would be prohibitive. To overcome this hurdle, Terrain datasets and related import and storage tools group points into multipoint shapes.
A multipoint is a geometry type that can be used to represent multiple points. Thousands of points can be grouped into an individual shape. The geodatabase supports a multipoint feature class type to store them. Thus, a few thousand records can store millions of points. You can't easily maintain attributes per point this way, but points of this nature typically do not represent specific geographic features that would require this. They simply record x,y,z coordinates for the sake of sampling surface geometry. There are exceptions, though.
Lidar data may carry information per point. While this type of information is typically more useful for data providers than data consumers, there may be a requirement to store this information in a GIS database. For this purpose, lidar attributes from LAS format files can be packed into arrays of values that are maintained as binary large objects (BLOBs). So even attribution can be stored if need be, but because the information is in BLOB form, terrain-specific tools are required to access it.
Organizing terrain data in a geodatabase
A key organizing principle is that terrains reside inside feature datasets and get their measurements from feature classes that also reside inside these datasets. Therefore, you'll need a feature dataset with a properly defined spatial reference including tolerance and resolution.
The spatial reference for the dataset should be defined using a projected coordinate system. Triangulation, interpolation, slope analysis, and visibility all assume the x,y coordinates are in a Cartesian coordinate system. Use of geographic coordinates is not supported.
After you've created a feature dataset, you'll need to add your terrain measurements into one or more feature classes. There are many types of 3D-enabled data that can populate terrain datasets.
The following are common examples of source data:
- Photogrammetric spot heights and mass points: 3D points compiled from stereo imagery at surface-specific high and low points as well as points collected within some approximate minimal spacing to provide coverage and control
- Photogrammetric breaklines: 3D lines, without vertical segments, compiled from stereo imagery representing linear features across which there is a distinct break in slope (for example, lake shorelines and roadsides)
- Lidar: Points derived from airborne laser systems mounted on helicopters or airplanes, that measure height of ground, vegetation, and buildings, often filtered to include only ground points to define bare earth surface models
- Sonar: Points derived from systems, mounted on boats or submarines, that use sound waves, which measure depth and are used for bathymetric mapping
If your data resides in ASCII format files, use the ASCII 3D To Feature Class geoprocessing tool to import them. If your data resides in LAS format files, use the LAS To Multipoint tool to import them.