Database support for terrain datasets
Last modified April 28, 2009
Print all topics in : "Understanding terrain datasets"
Terrains, 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 hundreds of millions 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 (e.g., DEMs) as needed.
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. A terrain of several hundred million points is not unreasonable. Anything larger should be maintained in an ArcSDE geodatabase. If you need to edit and maintain a terrain over time, ArcSDE provides the best solution, particularly with larger datasets.
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.
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.
Common examples of source data include