Digital Terrain Modeling: Principles and Methodology - Chapter 10 ppsx

10.1 STRATEGIES FOR MANAGEMENT OF DTM DATA Spatial data, including DTM data, must be managed efficiently and database ogy plays an important role.. Currently, themainstream practice is t

Management of DTM Data

In Chapter 9, it was discussed that DTM data have become part of an NSDI andone usually produced at the national level with multi-scales For large countries likeBrazil, Canada, China, India, and the United States, the volume of DTM data could

be huge Therefore, efficient management of DTM data in a computerized system is

an important task at national or provincial geospatial information centers Therefore,this chapter is devoted to management of DTM data

10.1 STRATEGIES FOR MANAGEMENT OF DTM DATA

Spatial data, including DTM data, must be managed efficiently and database ogy plays an important role There are different strategies to deal with the problems

technol-in the management of DTM data

10.1.1 Strategy for Making DTM Data Management Operational

To make the management of spatial data operational, spatial data sets are partitionedaccording to five attributes, horizontal or vertical positions, time, theme, and scale

In the management of DTM data, scale and horizontal positions are used The use ofscale was discussed in Chapter 9 and, therefore, only the use of horizontal positionwill be described in this section

If the area to be modeled is large such as a nation or a province, one is concernedwith the arrangement of the huge volume of DTM data Questions such as “shoulddistributed or centralized databases be used,” or “how can the data of the whole area

be split into small pieces so that they can be managed efficiently” are the concern here

As contour maps have been widely used for DTM production, DTMs at a nationalscale are usually arranged in a way similar to map sheets Figure 10.1 showsthe arrangement for the 1:1,000,000-scale topographic maps of China Table 10.1shows the size of each map sheet at different scales, ranging from 1:1,000,000 to

211

Figure 10.1 The tiling system of China’s map sheets at 1:1,000,000 scale (Courtesy of the

National Geomatics Center of China.)

Table 10.1 The Sizes of China’s Map Sheets From 1:1,000,000 to 1:10,000 Scales

Scale 1:1,000,000 1:500,000 1:250,000 1:100,000 1:50,000 1:25,000 1:10,000

Size 6 ◦ × 4 ◦ 3◦ × 2 ◦ 1.5◦ × 1 ◦ 30 × 20  15 × 10  7.5 × 5  345 × 2 30 (long/lat)

1:10,000 Taking the DTM of China at 1:1,000,000 as an example, it is in a gridform and there are a total of 25,000,000 data points (at grid nodes) The heights

of these points are divided into tiles, which follow the 1:500,000-scale topographicmaps (http://nfgis.nsdi.gov.cn/) In other words, each tile covers an area of 3◦× 2◦

(longitude/latitude) This kind of partition is the operational strategy for DTM data

management Such a strategy is equally applicable for any project with a relativelylarge area to be modeled

10.1.2 Strategy for Using Databases for DTM Data Management

The second strategy is about the use of databases to store DTM data The traditionaldatabase is good at managing of event (or attribute) data but it is not good for geometricdata On the other hand, all spatial data, including DTM data, have two components,

which have only one component Therefore, special arrangements for spatial datamust be made according to the characteristics of these two components Currently, themainstream practice is to use files to store geometric data and to use relational tables

to store attribute data (and relational data if any) in a traditional relational database.The files for geometric data are then managed by a computer system The geometricand attribute data are then linked by pointers This is also common for DTM datamanagement Files are cataloged and indexed so that efficient retrieval is possible.This is helped by metadata, or “data about data.” Metadata contain the informationdescribing the contents, quality, status, and other characteristics Metadata can also

be indexed using files However, if complicated, metadata can also be managed

by databases In this way, databases do now come into the area of geometric datamanagement, but indirectly

Current development is toward object-relational databases In such databases,geometric data (mainly the coordinates) are also organized into tables and stored andmanaged by the relational database management system This has become popularfor the management of large-volume DTM data In practice, when data volume isnot very large, a file system is still commonly used due to its convenience and thehigh cost of object-relational databases Purely object-oriented databases have alsobeen under development However, there is still a long way to go before they will becommonly used

10.2 MANAGEMENT OF DTM DATA WITH FILES

In the previous section, it was discussed that file systems are still commonly usedfor the management of DTM data The structure of such files will be discussed inthis section

10.2.1 File Structure for Grid DTM

When the DTM is in a grid form, it can be represented by point matrix (Figure 10.2),

or raster format The topology between a grid point and its adjacent grid points isimplicitly built in the rows and columns of the matrix

The coordinates of a grid node can be computed based on the coordinates(x0,y0)

of the origin of the area and the square grid intervalsd Suppose the lower-left corner

62 66 68

62

66 68 70

64

58 63 59

57

56 60

Figure 10.2 Matrix representation of grid DTM data.

Table 10.2 Typical File Structure for Grid DTM

Header Coordinates of the origin;

coordinate data type;

height range; height data type;

grid interval; numbers of rows and columns; order of rows and columns, position (in the file) where the body starts; position (in the file) where the footer starts;

use of compression or not; etc.

The information in the footer can also be recorded here

Body Height values of grid nodes Row by row and column by

column in blocks Footer Data describing the general

characteristics of DTM, e.g., name, boundary, producer, projection parameters, version, accuracy, date of production, date of revision, linage, etc.

is also needed so that each grid node can be assigned a height value In a typical file ofraster data, such additional information is recorded as the header and the matrix is thefile body In the body, heights are recorded row by row and then column by column,

or column by column and then row by row, or block by block Some other relevantinformation may also be recorded, either in the header or in a footer Therefore, thetypical file structure for a grid DTM is as shown in Table 10.2

10.2.2 File Structure for TIN DTM

The TIN model represents a surface comprising a series of contiguous triangles,hence triangulated A triangle has three vertices, which can be arbitrarily located,here irregular in shape This contrasts with the grid model where points are spacedregularly in a lattice The big difference between the management of TINs and grids

is that, for the TIN model, apart from elevation values, the coordinates(x i,y i ) of

each vertex (sayith) and the information describing the topological relations among

the three vertices need to be recorded The topological relationship between trianglesalso needs to be recorded in most cases

II III IV 1

VI

Figure 10.3 A triangulated irregular network (TIN).

Table 10.3 A List of Coordinates of

.

.

.

.

Table 10.4 A List of Triangles

No Vertex 1 Vertex 2 Vertex 3

The recording of geometric information is illustrated in Figure 10.3 and Table 10.3and Table 10.4, that is, a table of points containing all their coordinates and a table oftriangles with their corresponding three vertices Apart from geometric information,the topological information is recorded for efficient retrieval of data.Table 10.5liststhe adjacent relations between these triangles

The file structure for a TIN DTM is simply the list of points with their coordinates,with some metadata also included in the header The file structure is like that given

inTable 10.6.The topological information about these triangles is stored either in

a database or in a file.Table 10.7illustrates a possible arrangement of such topologicalinformation in a file

Table 10.5 Adjacent Relations of

Triangles Triangle Edge Neighbors

Table 10.6 Typical File Structure for TIN Point Coordinates

Header The coordinates of the points on the

boundary (convex hull); ranges of X , Y , and

Z coordinates; coordinate data type; data types;

numbers of points; position (in the file) where the body starts; position (in the file) where the footer starts; use of

compression or not; etc.

The information in the footer can also be recorded here

Body X , Y , and Z coordinates of points in sequence May also be in blocks Footer Data describing the general characteristics

of DTM, e.g., name, producer, projection parameters, version, accuracy, date of production,

date of revision, linage, the null points code, etc.

Metadata

Table 10.7 Typical File Structure for TIN Topology

Header Number of triangles,

the bytes of data for Table 10.4 or Table 10.5, data types, etc.

The information in the footer can also be recorded here

Body Information in Table 10.4 or

information in Table 10.5

Adjacent triangular topology is not always necessary Footer Other relevant information Metadata

10.2.3 File Structure for Additional Terrain Feature Data

As discussed inChapter 4, a hybrid DTM network may be generated if data fromcomposite sampling (i.e., grid plus feature points and lines) are used In normalpractice, the grid and feature data are stored in separate files When modeling orinterpolation is needed, grids are split into triangles and feature points and lines areadded to the regular triangular network to update local triangles(Figure 10.4)

Figure 10.4 Hybrid of regular grid and TIN.

···

···

···

···

1(line ID), N1 (No.of points on line 1)

2(line ID), N2 (No.of points on line 2)

Figure 10.5 The body of vector file structure for terrain feature data.

Feature data may be stored in one or two files, one for points and the other forlines The file structure for terrain feature points is similar to that for the points

of TINs However, for lines, it is slightly different In the header, the number of lines

is specified and in the body the data could be organized as shown in Figure 10.5

10.3 MANAGEMENT OF DTM DATA WITH SPATIAL DATABASES

In the previous section, the file structures for both grid and TIN DTMs were discussed.These files are managed using an indexing system, which can be organized into files

or into tables and managed by a database if the indexing is rather complex In thiscase, an ordinary relational database will serve for the purpose On the other hand,

the DTM data can also be organized into tables in an object-relational database,

in which DTM data are stored in block as a field

10.3.1 Organization of Tables for Grid DTM Data

A large area (e.g., a country) may be divided into a number of smaller regions(e.g., provinces) and each region can be further divided into a number of smallerunits called tiles Each tile may also be further divided into a number of small units.This is a hierarchical structure and can be indexed efficiently for the management ofDTM in a grid form Figure 10.6 shows an indexing system for the hierarchy in threelevels, region, tile, and block It is not necessary to have rectangular shapes for thetiles For example, the boundaries will be irregular if the DTM data of a nation ismanaged based on drainage area or administrative region

In some commercial systems, the block is the basic unit for access and retrieval.Each block comprises many rows and columns Through the structural index for

“region–tile–block–row–column,” the height of any location within the databasecan be uniquely determined The spatial index formed by the region–block–unithierarchy ensures fast retrieval of and seamless access to DTM data The arrange-ment of tables for a regional DTM in an object-relational database is shown inTable 10.8, Table 10.9, and Table 10.10, which are created by the authors forillustration purposes only

The above data organization method may also apply to TINs for large areas As theTIN boundary of each region is irregular, to avoid the edge-matching problem betweenadjacent blocks, a certain degree of overlapping is necessary in block partitioning.Suppose each region is organized into a database There are only four fields in

a record This is illustrated in Table 10.8

In Table 10.8, the field Region-table-name is the name of the table containingDTM data (see Table 10.9); the field Region-DTM-info is an abstract data typeusing database BLOB field (variable length), that is, a data stream, and has a

Standard Block 13

10

22 21

13 12

Standard tile 11 Column 3

Row 5 Grid cell 1*6

Figure 10.6 Hierarchical structure based on region–tile–block (Modified from ESRI, 1992).

Table 10.8 An Index Table for a Regional DTM

Region-ID Region-Table-Name Region-DTM-info Range-of-region

1 GridDEM50000_1 GridDTM50000_1_INFO GridDTM50000_1_ENVELOPE

2 GridDEM50000_2 GridDEM50000_2_INFO GridDTM50000_2_ENVELOPE

.

.

.

.

structure that contains the information about the region For example, the ture GridDTM50000_1_INFO contains all the tile and block information about thisregion The following is an example:

struc-* GridDTM50000_1_INFO

{

direction, e.g., four in

Figure 10.6//

direction, e.g., three inFigure 10.6//

in column direction, e.g.,five in Figure 10.6//

in row direction, e.g., five

in Figure 10.6//

e.g., seven in Figure 10.6//

block, e.g., eight inFigure 10.6//

e.g., 25.0 for 25.0 m//

e.g., 50,000 for 1 : 50,000//

updated, e.g., TRUE

if original//

compression isused, e.g., FALSE if

no compression//

};

In Table 10.8, the field Range-of-region is also the abstract data type BLOB,that is, a pointer to a structure that contains the coordinates of the four corners of theregion For example, the structure GridDTM50000_1_ENVELOPE may contain:

In Table 10.9, the Block-ID is the main key, which is unique to each block.Each Block-ID consists of four numbers The first two indicate the location of thecorresponding tile (which contains this block) in the region, one for the numbering

Table 10.9 Organization of DTM Height Data for Region GridDEM50000_1

in Block

0000 112 h0,0h0,1 h0,6h1,0 h6,7(of Block 0000)

.

.

.

1113 112 h0,0h0,1 h0,6h1,0 h6,7(of Block 1133)

.

.

.

2344 112 h0,0h0,1 h0,6h1,0 h6,7(of Block 2344)

Table 10.10 Organization of DTM Height Data

for Region GridDEM50000_1 in Tiles

00 DTMINFO00 Heights at tile 00

01 DTMINFO01 Heights at tile 01

.

.

.

23 ∗DTMINFO23 Heights at tile 23

the location of the current block in the corresponding tile, one for block numbering

in row direction and the other in column direction For example, the block labeled

inFigure 10.6is assigned an ID of 1113 The first two digits, that is, “11” indicate

a location of the second tile in row direction and second tile in column directions inthe region The last two digits, that is, “13,” indicate the location of the block withintile 11, that is, the second in row and the fourth in column directions The data typefor block-data is BLOB InFigure 10.8, the size of each block is a 7× 8 matrix

The 7× 8 height for each block is then recorded in this field In this table, as the

number of bytes for each block is 112, a float (or integer) of two bytes is used for eachheight value.h0,0h0,1 h0,6h1,0 h6,7are the heights of the respective 7× 8 data

blocks

In fact, it is also possible to organize the DTM data file using tile as the basic unit.That is, one file is used for each tile In this case, the file format of each tile may notnecessarily be the same.Table 10.10shows the organization of tables using tile as thebasic unit

The file-ID in this table is the tile number The data types for the fields DTM-Infoand DTM-Data are both BLOB, which is a data stream The former is a structure asfollows (using DTMINFO00 as an example):

DTMINFO00

{

tile 00//

the coordinates of thefour corners//

bytes//

};

In the DTM-Info field, a file name is included to refer to the height data block

in the DTM-Data field of the corresponding record This is for the convenience ofretrieval The height values in each tile form a data stream and are stored in the fieldDTM-data The data may be stored in separate files (i.e., not as a field in the table)

In this case,Table 10.9simply stores the logical information for the management ofDTM files

10.3.2 Organization of Tables for TIN DTM Data

As was done for the region–tile–block hierarchical structure of grid DTM, similararrangements can also be made for TIN DTM A region can be divided into anumber of (e.g., M × N) blocks for the TIN.Table 10.11shows the indexing ofTIN blocks