International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004
Storing source data may seem, at the first glance, unacceptable,
as source terrain data are not suitable for surface visualization
and analysis in GIS. Close examination, however, has led to a
new conclusion. First, both TIN and GRID DTMs are results
derived from source terrain data by applying certain topological
and spatial rules. This is done due to their advantage in
computer analysis and terrain relief visualization, not because
they can provide better data quality, or are easier to manage and
update. In fact, if source terrain data are properly arranged and
stored (to be discussed in the next two sections), a GIS can
always generate a DTM using these data dynamically, with high
performance. This will allow users to take the advantage of both
TIN and GRID without being burdened by TIN’s storage
overhead or GRID's precision problem.
Second, source terrain data often have many uses. For instance,
road networks provide critical data for transportation and
planning applications. They also play an important role in DTM
construction. Drainage systems are another typical example.
Even with mass point data (such as LiDAR), there may be
attributes associated with each point that may serve other
applications (e.g., vegetation analysis). Storing terrain data
separately as a DTM would mean an increase in storage space,
extra work in data management and updating, and extra
complexity and difficulty in keeping data synchronized. In other
words, storing source data would allow the same data to be
shared by different applications, minimize storage space, and
eliminate or reduce the work in data synchronization.
Third, when it comes to multi-resolution queries, source vector
terrain data allow structure lines to be generalized according to
a user specified target resolution (Weibel, 1992; Peng et al.,
1996). Whereas in a GRID DTM the original skeleton
information may have already been distorted or lost. In a TIN
DTM, although skeleton information may be preserved as
constraints in the triangulation, attributes associated with each
structure line still need to be handled. Kidner and colleagues
(Kidner et al., 2000) also provide some good arguments against
storing (explicit) TINs.
Finally, storing source data is flexible. One can always modify
or redefine the rules, change source data and their combination,
and create different DTMs accordingly, which is useful for
research projects. Trying to find a better triangulation criterion
for TIN DTM construction, or a better interpolation method for
GRID DTM generation, are good examples.
2.2 Where to Store
GIS applications often require a database environment that
supports (among others) 1) geometric and thematic description
ul spatial objects. 2) topological relationships at a geometric
saimitive level and object level, 3) versioning, 4) multi-user
access and editing, and 5) seamless, scalable, multi-resolution,
and high performance spatial queries.
The approach described is based on ESRI's geo-database
framework defined in ArcGIS (Zeiler, 1999), as it has the
potential to meet the requirements listed above. As shown in
Figure 1, a geo-database (or database for short) contains one or
more feature datasets; a feature dataset contains one or more
feature classes; a feature class contains one or more features of
the same geometric type (point, line, or area). A feature dataset
defines a conceptual entity for those feature classes that share
the same spatial reference, cover the same geographic extent,
and are often thematically related to each other.
82
Under this framework, it is clear that source terrain data should
be grouped into different feature classes, according to their
geometric type, source, and thematic description. Typical
examples include drainage systems, mass points (e.g., LIDAR
data), road networks, ridgelines, and ground control points.
Those feature classes that contribute to the same ground area are
then put into the same feature dataset.
Feature
Class
Feature
Dataset
Geo-database p
Figure 1: A geo-database structure.
»- ;
Terrain
Measurement
Feature
Dataset :
Me b Terrain
> Rules
Figure 2: Terrain in geo-database.
2.3 How to Store
Feature classes of terrain data do not themselves have much
meaning in terrain application. A higher level of abstraction is
necessary in order to support users to properly model their
terrain data and applications. This is achieved by introducing
Terrain into the geo-database framework described in section
2.2. A Terrain is defined as a special type living inside a feature
dataset, consisting of one or more feature classes within the
dataset and a set of rules (Figure 2). Feature classes constituting
a terrain dataset are called terrain measurements.
Terrain measurements can be stored as point, line, or area
feature classes. They may participate in more than one Terrain
within the same feature dataset. Terrain measurements are also
regular feature classes that can be used for other purposes,
allowing 2D data and terrain data to be integrated into the same
database.
Internal
The set
constru
of spa
measur
mass el
clippin,
measur
whethe
result i
one un
resolut
necess:
accomi
(to be ¢
The in
manag
DTM.
reques!
data (r
philos
2.4 T
Terrait
throug
relief |
terrair
In ord
require
is also
for su
spatial
which
includ
To ir
techn!
index
Altho
large
built-
to su
DTM
