Show Navigation | Hide Navigation
You are here:
Data support in ArcGIS > Terrains > Designing and managing terrain datasets

Modifying terrains in a geodatabase

Release 9.2
Last modified March 12, 2008
E-mail This Topic Printable Version Give Us Feedback

Print all topics in : "Designing and managing terrain datasets"

Terrains can be edited to fix problems, make improvements, and increase or decrease their extent.

Edits fall into three broad categories:

  1. Edits to the terrain schema
  2. Edits to measurements residing in regular feature classes
  3. Edits to measurements residing in embedded feature classes
From the application perspective, there are some common editing needs.

Basic forms of terrain editing

Common Terrain Editing Tasks
Task Examples

Expanding area of coverage over time
  • Appending new measurements as they become available (data acquisition is often staged over time with multiple data deliveries from a data provider)
  • The data extent is expanded

Quality assurance
  • Identifying and removing errors
  • Removing blunders representing individual measurements
  • Replacing areas containing systemic errors with corrected measurements

  • Keeping the definition of terrain up to date
  • Replacing areas with new or updated information (e.g., changes to landscape as a result of construction or natural forces)
  • Replacing data with data of higher quality/accuracy

What-if scenarios
  • Modeling proposed changes on the landscape (e.g., related to drainage or viewshed)
  • Replacing existing measurements with new ones
  • May be temporary
  • May be permanent

Multiuser editing
  • Operators perhaps responsible for edits to all data layers within constrained areas (e.g., all data per tile or map sheet)
  • Operators perhaps responsible for edits to individual layers for unconstrained areas (e.g., all LIDAR data)
  • Unusual for operators to modify same data layer for same area, although potential exists for conflict near common boundaries of assigned areas

Editing terrain properties

Terrain schema are properties you set when creating a terrain. These include the participating feature classes, the pyramid level definitions, and the tile size (which is derived from the average point spacing). Some of these can be modified without requiring the terrain to be rebuilt; others will require a build.

Properties that can be edited without a rebuild

Properties that require a rebuild

Terrain schema are modified via terrain-specific geoprocessing tools. These can be found in the Terrain toolset inside the 3D Analyst toolbox. Use of these tools requires a 3D Analyst license.

When a terrain has been invalidated because of a schema edit, it will not display. To confirm the reason for the lack of display, look on the Source tab of the Terrain Layer Properties dialog box. It indicates whether the terrain needs to be built. This information is also reported on the General tab of the Terrain Properties dialog box in ArcCatalog.

When a terrain needs to be rebuilt, you can use the Build button on the Update tab of the Terrain Properties dialog box in ArcCatalog or the Build Terrain tool in the 3D Analyst Terrain toolset. Building a terrain requires a 3D Analyst license.

Editing terrain measurements

Measurements reside in feature classes that participate in a terrain. These are the points, lines, and polygons that define the surface geometry. Feature classes can be referenced by the terrain, or, for multipoint feature classes, can be embedded in the terrain. Editing of measurements is distinctly different between regular and embedded feature classes.

Editing measurements in regular feature classes
Most feature classes are simply referenced by a terrain. This reference is a relationship that's established for a number of reasons:

To edit the measurements, use standard feature editing tools. Terrain is notified about feature edits and keeps a record of areas where edits have taken place. To sync the terrain with these edits, execute a build operation. When a terrain needs to be rebuilt, you can use the Build button on the Update tab of the Terrain Properties dialog box in ArcCatalog or the Build Terrain tool in the 3D Analyst Terrain toolset. Building a terrain requires a 3D Analyst license.

Editing measurements in embedded feature classes
You can embed a large multipoint feature class in a terrain when it's created. This allows you to delete the source feature class after the terrain is built and recover the storage space. Embedded feature classes are contained by the terrain, and access to them is made through terrain operators. You can add, remove, and replace points using the Add Terrain Points and Remove Terrain Points geoprocessing tools in the Terrain toolset inside the 3D Analyst toolbox. These tools operate on collections of points by area rather than at the individual point level. To get the terrain in sync with the modifications to the embedded features, execute a build operation. To do this use the Build button on the Update tab of the Terrain Properties dialog box in ArcCatalog or the Build Terrain tool in the 3D Analyst Terrain toolset.

An edit operation on embedded points looks for an existing edit session to piggyback on. This supports undo if the edit session was initialized to support undo (e.g., using the editor inside ArcMap). If there's no edit session, it starts and stops a session itself; therefore, there is no chance for an undo. While undo support may be desirable, there's a cost when using file or personal geodatabases. For these, it's more efficient to edit embedded points outside an edit session. It's not an issue when using ArcSDE.

Dirty areas
The editing of measurements, regardless of whether they reside in regular or embedded feature classes, may result in dirty areas. These are used to indicate what portions of the terrain are invalid and need to be rebuilt. Dirty areas result except when editing attributes that are unrelated to z-values or when editing features that are not included in the highest resolution pyramid level. The benefit of dirty areas is the support of partial build processing. A modification to part of a terrain does not require it to be rebuilt in its entirety from scratch.

The dirty areas of terrains are tile based. An edit within a tile invalidates the entire tile. Rebuilding a terrain will process its dirty tiles and the tiles adjacent to them. The adjacent tiles need to be included because edits to measurements may have an impact, in terms of how they influence the surface, that extends across tiles.

You can view dirty areas of a terrain using the terrain layer's dirty area renderer. To do this, add a dirty area renderer from the terrain layer's Symbology tab.

dirty areas

Geoprocessing tools for editing terrain datasets

A set of geoprocessing tools for editing existing terrains is available in the 3D Analyst toolbox. To ensure the toolbox is available, make sure 3D Analyst is installed and have it enabled via the Tools > Extensions dialog box.

gp terrain tools

Geoprocessing tools can edit properties of a terrain as well as embedded multipoint feature classes. Editable properties include pyramid definitions and information about participating feature classes. Changes other than those specifically associated with pyramid reference scales require a rebuild of the terrain. You can make multiple edits followed by one call to Build Terrain. This is more efficicient than running build after every edit operation.

Edits to features in regular feature classes that participate in a terrain should be made using feature edit tools. There are no terrain-specific tools for editing these features. Once edits are made, call Build Terrain to get it in sync with the changes made to the features.

Tools used to modify an existing terrain

Multiuser editing and versioning of terrains

Terrains inside an SDE database support versioned editing. The benefits are similar to versioned editing of features. Complex workflow scenarios are supported that enable a terrain to be modified over time, by multiple groups, with rollback capability. What-if scenarios can be performed.

Rules for setting up a versioned terrain

Reconciling a database containing a terrain

Terrains can be composed of two different types of feature data: those in regular feature classes and those in embedded feature classes. Reconciliation of features in regular feature classes works normally, as if they didn't participate in a terrain. You do nothing different. Terrain simply keeps a record of where it needs to be rebuilt, locally, to keep in sync with changes that have taken place due to the reconcile process. Embedded feature classes are different, though. They exhibit behavior unique to terrain.

The supported types of edit operations on embedded multipoint feature classes include add, delete, and replace. They work on areas of points rather than individual points, because there are typically so many of them. Any of these edit operations is a potential source of conflict if performed in the same area in parent and child versions. This is because conflicts of embedded features are based on the terrain's tile system rather than at the individual feature level. An edit within a tile is treated as if the entire tile has been modified. During reconciliation, a comparison is made between tiles. If the same tile has been modified between versions, there's a conflict. To resolve a conflict, one version's set of points for a tile will be selected. The conflicts are resolved automatically by applying the preference set in favor of either the target or edit version when starting the reconcile process.

Regardless of whether you modify data in regular or embedded feature classes, you might need to rebuild the terrain after reconciling. Look at the Terrain Properties dialog box in ArcCatalog or the Terrain Layer Properties dialog box in ArcMap to determine if a rebuild is necessary. The build can be performed using the geoprocessing Build Terrain tool or from the Update tab of the Terrain Properties dialog box in ArcCatalog.

Please visit the Feedback page to comment or give suggestions on ArcGIS Desktop Help.
Copyright © Environmental Systems Research Institute, Inc.