9.1 Introduction

This chapter builds on the material on geographicrepresentation presented in Chapter 3. By way ofintroduction it should be noted that the termsrepresentation and model describe essentiallythe same thing. Representation is more widelyused to describe the conceptual and scientificissues, whereas model is used in practical anddatabase circles. In this chapter the term‘‘model’’ will be used, given the practicalapproach. This chapter focuses on howgeographic reality is modeled (abstracted orsimplified) in a GIS, with particular emphasis onchoosing one particular style of data model overanother.

9.1.1 What is a data model?

The heart of any GIS is the data model, which is aset of constructs for representing objects andprocesses in the digital environment of thecomputer (Figure 9.1). People (GIS users) interactwith operational GIS in order to perform tasks likemaking maps, querying databases, andperforming site suitability analyses. Because thetypes of analyses that can be undertaken arestrongly influenced by the way the real world ismodeled, decisions about the type of model to beadopted are vital to the success of a GIS project.

A data model is a set of constructs fordescribing and representing selectedaspects of the real world in a computer.

As described in Chapter 3, geographic reality isinfinitely complex, but computers are finite.Therefore, difficult choices have to be made

about what and how things are modeled usingGIS. Because different types of people use GIS fordifferent purposes, and the type of phenomenapeople study have different characteristics, thereis no single type of GIS data model that is best forall circumstances.

9.1.2 Levels of data model abstraction

When representing the real world in a computer, itis helpful to think in terms of the four differentlevels of abstraction (levels of generalization orsimplification) that are shown in Figure 9.2. First,reality is made up of real-world phenomena(buildings, streets, wells, lakes, people, etc.), andincludes all aspects that may or may not beperceived by individuals, or deemed relevant to aparticular application. Second, the conceptualmodel is a human-oriented, often partiallystructured, model of selected objects andprocesses that are thought relevant to a particularproblem domain. Third, the logical model is animplementation-oriented representation of realitythat is often expressed in the form of diagramsand lists. Fourth, the physical model portrays theactual application in a GIS, and often comprisestables stored as files or databases (see Chapter11). Use of the term physical here is actuallymisleading because the models are not physical,they only exist digitally in computers.

In data modeling, users and system developersparticipate in a process that successively engageswith each of these levels. The first phase ofmodeling begins with definition of the main typesof objects to be represented in the GIS andconcludes with a conceptual description of themain types of objects and relationships between

T E C H N I Q U E S

184

GIS Data ModelDescription andRepresentation Operational GIS

Analysis andPresentation

PeopleInterpretation and

Explanation

Real World

Figure 9.1 The role of a data model in GIS

Reality

Conceptual Model

Logical Model

Physical Model

IncreasingAbstraction

Human - oriented

Computer - oriented

Figure 9.2 Levels of abstraction relevant to GIS datamodels

them. Once this phase is complete, further workwill lead to the creation of diagrams and listsdescribing the names of objects, their behavior,and the type of interaction between objects. Thistype of logical data model is very valuable fordefining what a GIS will do and the type ofdomain over which it will extend. Logical modelsare implementation independent, and can becreated in any GIS with appropriate capabilities.The final data modeling phase involves creating amodel showing how the objects under study can bedigitally implemented in a GIS. Physical modelsdescribe the exact files or database tables usedto store data, the relationships between objecttypes, and the precise operations that can beperformed. For more details about the practicalsteps involved in data modeling see Sections 9.3and 9.4.

A data model provides system developers andusers with a common understanding and referencepoint. For developers a data model is the means torepresent an application domain in terms that maybe translated into a design and implementation ofa system. For users, it provides a description of thestructure of the system, independent of specificitems of data or details of the particular applica-tion (Worboys 1995).

The discussion of geographic representation inChapter 3 introduced discrete objects and fields,the two fundamental conceptual models forrepresenting real-world objects geographically. Inthe same chapter the raster and vector logicalmodels were also introduced. Figure 9.3 showstwo representations of raster and vector objectsin a GIS. Notice the difference in the objects

represented. Major roads, in false color green,and areas cleared of vegetation in false color red,are more clearly visible in the vector represen-tation, whereas smaller roads and built-up areascan best be seen on the scanned raster aerialphotograph. The next sections in this chapterfocus on the logical and physical representationof raster, vector, and related models in GISsoftware systems.

9.2 GIS Data Models

In the past half-century many GIS data models havebeen developed and deployed in GIS softwaresystems. The key types of geographic datamodels and their main areas of application arelisted in Table 9.1. All are based in some way onthe conceptual discrete object/field and logicalvector/raster geographic data models.

All GIS software systems include a core datamodel that is built on one or more of the GIS datamodels described below. As discussed earlier, thesystem data model is the means to representgeographic aspects of the real world and definesthe type of geographic operations that can beperformed. It is the responsibility of the GISimplementation team to populate this genericmodel with information about a particularproblem (e.g. utility outage management, militarymapping, or natural resource planning). Some GISsoftware packages come with a fixed data model,while others have models that can be easilyextended. Those that can easily be extended are

G E O G R A P H I C D A T A M O D E L I N G

185

Figure 9.3 Representations of the same area (San Diego, California): (A) panchromatic SPOT raster satellite imagecollected in 1990 at 10 m resolution (Courtesy: ERDAS); (B) vector objects digitized from the image (Courtesy: ERDAS)

(A) (B)

better able to model the richness of geographicdomains, and in general are the easiest to useand are the most productive systems.

When modeling the real world forrepresentation inside a GIS it is convenient togroup entities of the same geometric typetogether (for example, all point entities such aslights, garbage cans, dumpsters, etc. might bestored together). A collection of entities of thesame geometric type (dimensionality) is referredto as a class or layer. It should also be noted thatthe term layer is quite widely used in GIS as ageneral term for a distinct dataset. It derivedfrom the process of entering different types ofdata into a GIS from paper maps, which wasundertaken one plate at a time (all entities of thesame type were represented in the same color and,using printing technology, were reproducedtogether on film or printing plates). Groupingentities of the same geographic type togethermakes the storage of geographic databases moreefficient (for further discussion of this see Section11.3). It also makes it much easier to implementrules for validating edit operations (e.g. additionof a new building or census administrative area)and for building relationships between entities.All of the data models discussed below use layersin some way to handle geographic entities.

A layer is a collection of geographic entitiesof the same geometric type (e.g. points,lines, or polygons). Grouped layers maycombine layers of different geometric types.

9.2.1 CAD, graphical, and image GIS datamodels

The earliest GIS were based on very simple modelsderived from work in the fields of CAD (computer-

aided design), computer cartography, and imageanalysis. In a CAD system real-world entities arerepresented symbolically as simple point, line,and polygon vectors. This basic CAD data modelnever became widely popular in GIS because ofthree severe problems for most applications atgeographic scales. First, because CAD modelstypically use local drawing coordinates instead ofreal-world coordinates for representing objectsthey are of little use for map-centric applications.Second, because individual objects do not haveunique identifiers it is difficult to tag them withattributes. As the following discussion shows thisis a key requirement for GIS applications. Third,because CAD data models are focused ongraphical representation of objects they do notstore details of any relationships between objects(e.g. topology), the type of information essential inmany spatial analytical operations.

A second type of simple GIS geometry modelwas derived from work in the field of computercartography. The main requirement for this fieldin the 1960s was the automated reproduction ofpaper maps and the creation of simple thematicmaps. Techniques were developed to digitizemaps and store them in a computer for subse-quent plotting and printing. All paper mapentities were stored as points, lines, andpolygons, with annotation used for placenames.Like CAD systems there was no requirement totag objects with attributes or to work with objectrelationships.

At about the same time that CAD and computercartography systems were being developed, a thirdtype of data model emerged in the field of imageprocessing. Because the main data source forgeographic image processing is scanned aerialphotographs and digital satellite images it wasnatural that these systems would use rasters orgrids to represent the patterning of real-world

T E C H N I Q U E S

186

Table 9.1 Geographic data models used in GIS

Data Model Application

Computer-aided design (CAD) Engineering designGraphical (non-topologic) Simple mappingImage Image processing and simple grid analysisRaster/grid Spatial analysis and modeling especially in environmental

and natural resources applicationsVector/geo-relational topologic Many operations on vector geometric features in

cartography, socio-economic and resource analysis, andmodeling

Network Network analysis in transportation, hydrology, andautomated mapping/facilities management (AM/FM)

Triangulated irregular network (TIN) Surface/terrain analysis and modelingObject Many operations on all types of entities in all types of

applications

objects on the Earth surface. The image data modelis also well suited to working with pictures of real-world objects, such as photographs of water valvesand scanned building floor plans that are held asattributes of geographically referenced entities in adatabase (Figure 9.4).

In spite of their many limitations GIS still existbased on these simple data models. This is partlyfor historical reasons – the GIS may have been

purchased before newer, more advanced modelsbecame available – but also because of lack ofknowledge about the newer approachesdescribed below.

9.2.2 Raster data model

The raster data model uses an array of cells, orpixels, to represent real-world objects (Figure3.7). The cells can hold any attribute values basedon one of several encoding schemes includingcategories, and integer and floating pointnumbers (see Box 3.3 for details). In the simplestcase a binary representation is used (for examplepresence or absence of vegetation), but in moreadvanced cases floating point values arepreferred (for example, height of terrain abovesea level in meters). In some systems multipleattributes can be stored for each cell in a type ofvalue attribute table where each column is anattribute and each row either a pixel, or a pixelclass (Figure 9.5).

Raster data are usually stored as an array ofgrid values, with metadata about the array heldin a file header. Typical metadata include thegeographic coordinate of the upper-left corner of

G E O G R A P H I C D A T A M O D E L I N G

187

Figure 9.4 An image of a hydrant used as an objectattribute in a water facility system

Figure 9.5 Raster data of the Olympic Peninsula, Washington State, USA, with associated value attribute table. Bands4, 3, 2 from Landsat 5 satellite with land cover classification overlain (ERDAS Imagine: screenshot courtesy of ERDAS Inc.;data courtesy of EROS Data Center)

T E C H N I Q U E S

188

Box 9.1 Raster compression techniques

Although the raster data model has many uses in GIS, one of the main operational problems associatedwith it is the sheer amount of raw data that must be stored. To improve storage efficiency many types ofraster compression technique have been developed such as run-length encoding, block encoding,wavelet compression, and quadtrees (see Section 11.7.2.2 for another use of quadtrees as a meansto index geographic data). Table 9.2 presents a comparison of file sizes and compression rates for threecompression techniques based on the image in Figure 9.6. It can be seen that even the comparativelysimple run-length encoding technique (Figure 3.11) compresses the file size by a factor of 5. The moresophisticated wavelet compression technique results in a compression rate of almost 40, reducing thefile from 90.5 to 2.3 MB.

Figure 9.6 Shaded digital elevation model of North America used for comparisonof image compression techniques in Table 9.2. Original image is 8726 by 10619 pixels,8 bits per pixel. The inset shows part of the image at a zoom factor of 1000 for the SanFrancisco Bay area (Source: ESRI)

Table 9.2 Comparison of file sizes and compression rates for raster compres-sion techniques (using image shown in Figure 9.6)

Compression technique File size (MB) Compression rate

Uncompressed original 90.5Run-length 17.7 5.1Wavelet 2.3 39.3

the grid, the cell size, and the number of row andcolumn elements. The array itself is usually storedas a compressed file or as a record in a databasemanagement system (see Section 11.3).Techniques are described in Box 9.1 (see alsoSection 3.6.2 for the general principles involved).

Data encoded using the raster data model areparticularly useful as a backdrop map displaybecause they look like conventional maps and cancommunicate a lot of information quickly. They arealso widely used for analytical applications such asdisease dispersion modeling, surface water flowanalysis, and store location modeling.

9.2.3 Vector data model

The raster data model discussed above is mostcommonly associated with the field conceptualdata model. The vector data model on the otherhand is closely linked with the discrete objectview. Both of these conceptual perspectives wereintroduced in Section 3.5. To date, the vector datamodel has been very widely implemented in GIS.This is because of the precise nature of its

representation method, its storage efficiency, thequality of its cartographic output, and theavailability of functional tools for operations likemap projection, overlay, and analysis.

In the vector data model each object in the realworld is first classified into a geometric type: point,line, or polygon (Figure 9.7). Points (e.g. wells, soilpits, and retail stores) are recoded as singlecoordinate pairs, lines (e.g. roads, streams, andgeologic faults) as a series of ordered coordinatepairs, and polygons (e.g. census tracts, soil areas,and oil license areas) as one or more line segmentsthat close to form an area. The coordinates thatdefine the geometry of each object may have 2,3, or 4 dimensions: 2 (x, y: row and column, orlatitude and longitude), 3 (x, y, z: the addition ofa height value), or 4 (x, y, z, m: the addition ofanother value to represent time or some otherproperty — perhaps the offset of road signs froma road centerline).

For completeness it should also be said thatin some data models linear features can be repre-sented not only as a series of ordered coordinates,but also as curves defined by a mathematicalfunction (e.g. a spline or Bezier curve). These are

G E O G R A P H I C D A T A M O D E L I N G

189

Run-length encodingRun-length encoding is perhaps the simplest compression method, and for this reason it has alreadybeen used to introduce the concept of raster data compression (see Section 3.6.2 and Figure 3.11). Itinvolves encoding row cells that have the same value, with a pair of values indicating the number of cellswith the same value, and the actual value.

Block encodingBlock encoding is a little like a two-dimensional version of run-length encoding in which the array isdefined as a series of square blocks of the largest size possible. Recursively, the array is divided usingblocks of smaller and smaller size. It is sometimes described as a quadtree data structure.

WaveletWavelet compression techniques invoke principles similar to those discussed in our treatment offractals, as discussed in Section 5.8. They remove information by recursively examining patterns indatasets at different scales. A useful by-product of this for geographic applications is that wavelet-compressed raster layers can be quickly viewed at different scales with appropriate amounts of detail.MrSID (Multiresolution Seamless Image Database) from LizardTech is an example of a waveletcompression technique that is widely used in geographic applications, especially for compressingaerial photographs. Similar wavelet compression algorithms are available from other public andprivate sources.

Run-length and block encoding both result in lossless compression of raster layers, that is, a layer canbe compressed and decompressed without loss of detail. In contrast, the MrSID wavelet compressiontechnique is lossy since information is irrevocably discarded during compression. Although MrSIDcompression results in very high compression ratios, because information is lost its use is limited toapplications that do not need to use the raw digital numbers for processing or analysis. It is notappropriate for compressing DEMs for example, but many organizations use it to compress scannedmaps and aerial photographs when access to the original data is not necessary.

Box 9.1 Continued

particularly useful for repre-senting artificialentities like road curbs and some buildings.

9.2.3.1 Simple features

Geographic entities encoded using the vector datamodel are often called features and this will be theconvention adopted here. Features of the samegeometric type are stored in a geographicdatabase as a feature class, or when speakingabout the physical (database) representation theterm feature table is preferred. Here each featureoccupies a row and each property of the featureoccupies a column. GIS commonly deal with twotypes of feature: simple and topologic. Thestructure of simple feature line and polygondatasets is sometimes called spaghetti because,like a plate of cooked spaghetti, lines andpolygons (strands of spaghetti) can overlap andthere are no relationships between any of theobjects.

Features are vector objects of type point,line, or polygon.

Simple feature datasets are useful in GISapplications because they are easy to create andstore, and because they can be retrieved andrendered on screen very quickly. On the otherhand the lack of any connectivity relationshipsbetween the features means that operations likeshortest-path network analysis and polygonadjacency cannot be performed withoutadditional time-consuming calculations. Simplefeature polygon layers are also inefficient formodeling phenomena conceptualized as fields

because the boundary between adjacent features(for example, two potato fields) must be digitizedand stored twice. They are also inflexible, as it isnot easy to dissolve common boundaries whenamalgamating zones. Furthermore, becausesimple feature polygons can overlap this limitstheir use in certain applications. For example, inland ownership applications land parcels cannotoverlap, for otherwise two people could own thesame piece of land (land ownership isconceptualized as a field that necessarily has oneowner at every point)!

9.2.3.2 Topologic features

Topologic features are essentially simple featuresstructured using topologic rules. Topology is thescience and mathematics of relationships. In GIStopology is used to validate the geometry ofvector datasets (e.g. check that polygons closeand that all lines in a network are joinedtogether), and for certain types of operations(e.g. network tracing and tests of polygonadjacency). Topologic structuring of vector layersintroduces some interesting and very usefulproperties, especially for line (also called 1-cell,arc, edge, and link) and polygon (also called 2-cell, area, and face) data. Topological structuringof line layers forces all line ends that are within auser-defined distance to be snapped together sothat they are given exactly the same coordinatevalue (see also Section 6.3.3). A node is placedwherever the ends of lines meet. Following onfrom the earlier analogy this type of data model issometimes referred to as spaghetti with meatballs(the nodes being the meatballs on the spaghettilines).

Topology is the science and mathematics ofrelationships used to validate the geometryof vector entities, and for operations such asnetwork tracing and tests of polygonadjacency.

In a topologically structured polygon data layereach polygon is defined as a collection of lines,that in turn are made up of an ordered list ofcoordinates (vertices). The list of lines that makeup a polygon is stored with the geometry data.Figure 9.8 shows an example of a polygondataset comprising six polygons (including the‘‘outside world’’: polygon 1). A number in a circleidentifies a polygon. The lines that make up thepolygons are shown in the polygon-line list. Forexample, polygon 2 can be assembled from lines4, 6, 7, 10, and 8. In this particular implementationexample the 0 before the 8 is used to indicate thatline 8 actually defines an ‘‘island’’ inside polygon

T E C H N I Q U E S

190

Points Point number (x,y) coordinates

(x,y) coordinatesLine number

Polygon number

Lines

Polygons

1234

12

12

1+3+

2+ 4+

1

1

2

2

(2,4)(3,2)(5,3)(6,2)

(1,5) (3,6) (6,5) (7,6)(1,1) (3,3) (6,2) (7,3)

(x,y) coordinates

(2,4) (2,5) (3,6) (4,5) (3,4) (2,4)(3,2) (3,3) (4,3) (5,4) (6,2) (5,1)

Figure 9.7 Representation of point, line, and polygonobjects using the vector data model

2. The list of coordinates for each line is also shownin Figure 9.8. For example, line 5 begins withcoordinates 7,4 and 6,3 — other coordinateshave been omitted for brevity. A line may appearin the polygon-line list more than once (forexample, line 6 is used in the definition of bothpolygons 2 and 5), but the actual coordinates foreach line are only stored once in the line-coordinate list. Storing common boundariesbetween adjacent polygons avoids the potentialproblems of gaps (slivers) or overlaps betweenadjacent polygons. It has the added bonus thatthere are fewer coordinates in a topologicallystructured polygon feature layer compared with asimple feature layer representation of the sameentities. The downside, however, is that drawing apolygon requires that multiple lines must beretrieved from the database and the boundaryassembled, a process that can be time consumingwhen repeated for each polygon in a large dataset.

Moving on from the one-dimensional case oflines to the two-dimensional case of polygonsrequires introduction of the concept of planarenforcement. In simple terms planar enforcementmeans that all the space on a map must be filledand that any point must fall in one polygon alone,that is, polygons must not overlap. Planarenforcement implies that the phenomenon isconceptualized as a field.

The contiguity (adjacency) relationship betweenpolygons is also defined during the process oftopologic structuring. This information is usuallystored as a list of the polygons on the left- andright-hand side of each line, in the directiondefined by the list of coordinates (Figure 9.9). InFigure 9.9 polygon 2 is on the left of line 6 andpolygon 5 is on the right. Thus we can deduce

from a simple look-up operation that polygons 2and 5 are adjacent.

Software systems based on the vector topologicfeature data model, also called the geo-relationalmodel, have become popular over the years. Theterm geo-relational derives from the way thetopologic feature model is implemented. In thismodel, the geometry and associated topologicinformation is stored in regular computer files,whereas the associated attribute information isheld in relational database management system(RDBMS) tables. The GIS software maintains theintimate linkage between the geometry, topology,and attribute information. This hybrid datamanagement solution was developed to takeadvantage of RDBMS to store and manipulateattribute information. Geometry and topologywere not placed in RDBMS because, until relativelyrecently, RDBMS were unable to store and retrievegeographic data efficiently. Figure 9.10 is an

G E O G R A P H I C D A T A M O D E L I N G

191

POLY LINE

Polygon-line list

23456

4,6,7,10,0,83,10,97,5,2,91,5,68

LINE (x, y) coordinates

Line coordinate list

12345678910

(5,3) (5,5) (8,5)(8,5) (20,5) ...(20,4)(20,1)...(18,1)(5,1) (5,3)(7,4) (8,5)(7,4) (6,3) ...

6

2

4

8

2

3 3

4

1

6

5

5

1

79

10

Polygon-line topology

Figure 9.8 A topologically structured polygon datalayer. The polygons are made up of the lines shown inthe polygon-line list. The lines are made up of the coordi-nates shown in the line coordinate list (Source: after ESRI1997)

Line# LPoly RPoly

Left-right list

12345678910

1111522243

5432454632

LINE# X, Y Pairs

Line coordinate list

12345678910

5,3 5,5 8,58,5 20,5 ...20,4 20,1 ...18,1 5,1 5,37,4 8,57,4 6,3 ...

6

2

4

8

2

3 3

4

1

6

55

1

79

10

Left-right topology

Figure 9.9 The contiguity of a topologically structuredpolygon data layer. For each line the left and right polygonis stored with the geometry data (Source: after ESRI 1997)

1234567

A3C6B7B13Z22A6A1

113952122018677117

HIGH

LOW

MODERATE

MODERATE

LOW

HIGH

LOW

+1 +5

+2

+4

+6

+3

+7

label point

polygon

node

ticSoils layer

line

ID Soil Class Suitability

Soils attributes

Figure 9.10 An example of a geo-relational polygondataset. Each of the polygons is linked to a row in anRDBMS table. The table has multiple attributes, one ineach column (Source: after ESRI 1997)

example of a geo-relational or coverage polygondataset showing file-based geometry andtopology information linked to attributes in anRDBMS table. The ID (identifier) of the polygon,the label point, is linked (related or joined) to theID column in the attribute table (see also Chapter11). Thus in this soils dataset polygon 3 is soil B7,of class 212, and its suitability is moderate.

The topologic feature geographic data modelhas been extensively used in GIS applicationsover the last 20 years, especially in governmentand natural resources applications based onpolygon representations (see Sections 2.3.2 and2.3.4). Typical government applications include:cadastral management, tax assessment, parcelmanagement, zoning, planning, and buildingcontrol. In the areas of natural resources andenvironment key applications include sitesuitability analysis, integrated land use modeling,license mapping, natural resource management,and conservation.

The tax appraisal case study discussed inSection 2.3.2.2 is an example of a GIS based onthe topologic feature data model. Because thedevelopers of this system wanted to avoidoverlaps and gaps in tax parcels (polygons), toensure that all parcel boundaries closed (werevalidated), and that they were stored in anefficient way, they chose this model. This is inspite of the fact that there is an overhead increating and maintaining parcel topology, as wellas a slight degradation in draw and query per-formance for large databases.

9.2.3.3 Network data model

The network data model is really a special typeof topologic feature model. It is discussed hereseparately because it raises several new issuesand has been widely applied in GIS studies.

Networks can be used to model the flow ofgoods and services. There are two primary types

T E C H N I Q U E S

192

Figure 9.11 An example of a street network

of networks: radial and looped. In radial or treenetworks flow always has an upstream and down-stream direction. Stream and storm drainagesystems are examples of radial networks. Inlooped networks self-intersections are commonoccurrences. Water distribution networks arelooped by design to ensure that service inter-ruptions affect the fewest customers.

In GIS software systems networks are modeledas points (for example, street intersections, fuses,switches, water valves, and the confluence ofstream reaches: usually referred to as nodes intopologic models), and lines (for example,streets, transmission lines, pipes, and streamreaches). Network topologic relationships definehow lines connect with each other at nodes. Forthe purpose of network analysis it is also usefulto define rules about how flows can movethrough a network. For example, in a sewernetwork, flow is directional from a customer(source) to a treatment plant (sink), but in apressurized gas network flow can be in anydirection. The rate of flow is modeled asimpedances on the nodes and lines. Figure 9.11shows an example of a street network. Thenetwork comprises a collection of nodes (types ofstreet intersection) and lines (types of street). Thetopologic relationship between the features ismaintained in a connectivity table. By consultinginformation stored in the connectivity table it ispossible to trace the flow of traffic through thenetwork and to examine the impact of streetclosures. The impedance on the intersections andstreets determines the speed at which traffic flows.Typically, the rate of flow is proportional to thestreet speed limit and number of lanes, and thetiming of stoplights at intersections. Althoughthis example relates to streets, the same basicprinciples also apply to, for example, electric,water, and railroad networks.

In geo-relational implementations of thetopologic feature model, the geometry andtopologic information is typically held in ordinarycomputer files and the attributes in a linkeddatabase. The GIS software tools are responsiblefor creating and maintaining the topologicinformation each time there is a change in thefeature geometry.

There are many applications that utilizenetworks. Prominent examples include:calculating power load drops over an electricitynetwork; routing emergency response vehiclesover a street network; optimizing the route ofmail deliveries over a street network; and tracingpollution upstream to a source over a streamnetwork.

Network data models are also used to supportanother data model variant called linear

referencing (Section 4.4). The basic principle oflinear referencing is quite simple. Instead ofrecording the location of geographic entities asexplicit x, y, z coordinates, they are stored asdistances along a network (called a route system)from a point of origin. This is a very efficient way ofstoring information such as road pavement(surface) wear characteristics (e.g. the location ofpot holes and degraded asphalt), geologicalseismic data (e.g. shockwave measurements atsensors along seismic lines), and pipelinecorrosion data. An interesting aspect of this isthat a two-dimensional network is reduced to aone-dimensional linear route list. The location ofeach entity (often called an event) is simply adistance along the route from the origin. Offsetsare also often stored to indicate the distance froma network centerline. For example when recordingthe surface characteristics of a multi-carriagewayroad several readings may be taken for eachcarriageway at the same linear distance along theroute. The offset value will allow the data to berelated to the correct carriageway. Dynamicsegmentation is a special type of linearreferencing. The term derives from the fact thatevent data values are held separately from theactual network route in database tables (still aslinear distances and offsets) and then dynamicallyadded to the route (segmented) each time the userqueries the database. This approach is especiallyuseful in situations in which the event data changefrequently and need to be stored in a database dueto access from other applications (e.g. trafficvolumes or rate of pipe corrosion). For furtherdiscussion of linear referencing see Section 4.4.

9.2.3.4 TIN data model

The geographic data models discussed so farhave concentrated on one- and two-dimensionaldata. There are several ways to model three-dimensional data, such as terrain models, salescost surfaces, and geologic strata. Strictlyspeaking, surfaces are said to be 2.5D structures.A true 3D structure will contain multiple z values atthe same x, y location and thus is able to supportvolumetric calculations like cut and fill (a termderived from civil engineering applications thatdescribes cutting earth from high areas andplacing it in low areas to construct a flat surface,as is required in railroad construction). For furtherdiscussion of 2.5D see Box 3.5. Both grids andtriangulated irregular networks (TINs) are usedto create and represent surfaces in GIS. A regulargrid surface is really a type of raster dataset asdiscussed earlier in Section 9.2.2. Each grid cellstores the height of the surface at a givenlocation. The TIN structure, as the name

G E O G R A P H I C D A T A M O D E L I N G

193

suggests, represents a surface as contiguous non-overlapping triangular elements (Figure 9.12). ATIN is created from a set of mass points, that is,points with x, y, and z coordinate values. A keyadvantage of the TIN structure is that the densityof sampled points, and therefore the size oftriangles, can be adjusted to reflect the relief ofthe surface being modeled, with more pointssampled in areas of variable relief (see Section5.4). TIN surfaces are frequently created by per-forming what is called a Delaunay triangulation ofthe points to create a series of triangular areas(also called faces) that touch their neighbors ateach edge.

A TIN is a topologic data structure that managesinformation about the nodes that comprise eachtriangle and the neighbors of each triangle.Figure 9.13 shows the topology of a simple TIN.As with other topologic data structures,information about a TIN may be convenientlystored in a file or database table.

TINs offer many advantages for surfaceanalysis. First, they incorporate the originalsample points, providing a useful check on theaccuracy of the model. Second, the variabledensity of triangles means that a TIN is anefficient way of storing surface representations.Third, the data structure makes it easy tocalculate elevation, slope, aspect, and line-of-sight between points. The combination of thesefactors has led to the widespread use of the TINdata structure in applications such as volumetriccalculations for roadway design, drainage studiesfor land development, and visualization of urbanforms. Figure 9.14 shows two exampleapplications of TINs. Figure 9.14(A) is a shadedlandslide risk TIN of Pisa district, Italy withbuilding objects draped on top to give a sense oflandscape. Figure 9.14(B) is a TIN of the YangtseRiver, China greatly exaggerated in the zdimension. It shows how TINs draped with imagescan provide photo-realistic views of landscapes.

Like all 2.5D and 3D models TINs are only asgood as the input sample data. They areespecially susceptible to extreme high and lowvalues because there is no smoothing of originaldata. Given that many DEMs are provided as griddata structures, the usage of TINs is not as high asit might be.

9.2.4 Object data model

All the geographic data models described so farare geometry-centric, that is they model the worldas collections of points, lines, and polygons. Anyoperations to be performed on the geometry (and,in some cases, associated topology) are createdas separate procedures (programs or scripts).

T E C H N I Q U E S

194

(C)

Figure 9.12 TIN surface of Death Valley, California:(A) ‘‘wireframe’’ showing all triangles; (B) shaded by eleva-tion; (C) draped with satellite image

(A)

(B)

Unfortunately, this approach can present severallimitations for modeling geographic systems. Allbut the simplest of geographic systems containmany entities with large numbers of properties,complex relationships, and sophisticatedbehavior. Modeling such entities as simple point,line, and polygon geometry types is overlysimplistic and does not easily support thesophisticated characteristics required for modernanalysis. Additionally, separating the state of anentity (attributes or properties defining what it is)from the behavior of an entity (methods definingwhat it does) makes software and databasedevelopment tedious, time-consuming, and errorprone. To try to address these problemsgeographic object data models were developed.These allow the full richness of geographicsystems to be modeled in an integrated way in aGIS.

The central focus of an object data model is thecollection of geographic objects and the relation-ships between the objects (see Box 9.3). Eachgeographic object is an integrated package ofgeometry, properties, and methods. As such it isa software representation of the extent andfunction of the geographic individuals describedin Chapter 5. In the object data model geometryis treated like any other attribute of the objectand not as its primary characteristic. Geographicobjects of the same type are grouped together asobject classes, with individual objects in the classreferred to as instances. In modern GIS softwaresystems each object class is stored in the form ofa database table, with each row an object and eachproperty a column. The methods that apply areattached to the object instances when they arecreated in memory for use in the application.

An object is the basic atomic unit in an objectdata model and comprises all the propertiesthat define the state of an object, togetherwith the methods that define an object’sbehavior.

All geographic objects have some type ofrelationship to other objects in the same objectclass and, possibly, to objects in other objectclasses. Some of these relationships are inherentin the class definition (for example, a topologicpolygon dataset will not have overlappingpolygons) while other interclass relationships areuser-definable. Three types of relationships arecommonly used in geographic object datamodels: topologic, geographic, and general.

A class is a template for creating objects.

Topologic relationships are generally built intothe class definition. For example, modeling real-world entities as a network class will causenetwork topology to be built for the nodes andlines participating in the network. Similarly, real-world entities modeled as topologic polygonclasses will be structured using the node–linemodel described in Section 9.2.3.2.

Geographic relationships between objectclasses are based on geographic operators (suchas overlap, adjacency, inside, and touching) thatdetermine the interaction between objects. In amodel of an agricultural system, for example, itmight be useful to ensure that all farm buildingsare within a farm boundary using a test forgeographic containment.

Geographic relationships are useful to defineother types of relationship between objects. In a

G E O G R A P H I C D A T A M O D E L I N G

195

Triangle

A

B

C

D

E

F

G

H

Node list

1, 2, 3

2, 4, 3

4, 8, 3

1, 3, 5

1, 5, 6

3, 7, 5

3, 8, 7

5, 7, 6

Neighbours

-, B, D

-, C, A

-, G, B

A, F, E

D, H, -

G, H, D

C, -, F

F, -, E

AB

CDE

FG

H

1

2

3

4

5

6

7

8

A TIN is a topologic data structure that managesinformation about the nodes that comprise each triangle

and the neighbours to each triangle

Triangles always have three nodes and usually have three triangles. Triangles on the periphery of the TIN can have o

Figure 9.13 The topology of a TIN (Source: after Zeiler 1999)

A TIN is a topologic data structure that manages

information about the nodes that comprise each triangle

and the neighbors to each triangle

Triangles always have three nodes and usually have three neighboring

triangles. Triangles on the periphery of the TIN can have one or two neighbors.

T E C H N I Q U E S

196

Figure 9.14 Examples of applications that use the TIN data model: (A) Landslide risk map for Pisa, Italy (Courtesy: EarthScience Department, University of Siena, Italy); (B) Yangtse River, China (Courtesy: Human Settlements Research Center,Tsinghua University, China)

(A)

(B)

tax assessment system, for example, it is advan-tageous to define a relationship between landparcels (polygons) and ownership data that isstored in an associated DBMS table. Similarly, anelectric distribution system relating light poles(points) to text strings (called annotation) allowsdepiction of pole height and material ofconstruction on a map display. This type ofinformation is very valuable for creating workorders (requests for change) that alter thefacilities. Establishing relationships betweenobjects in this way is useful because if one object

ismoved then the otherwillmove aswell, or if one isdeleted then the other is also deleted. This makesmaintaining databases much easier and safer.

In addition to supporting relationships betweenobjects (strictly speaking, between object classes),object data models also allow several types of rulesto be defined. Rules are a valuable means ofmaintaining database integrity during editingtasks because they enforce validation constraints.Themost popular types of rules used in object datamodels are attribute, connectivity, relationship,and geographic.

G E O G R A P H I C D A T A M O D E L I N G

197

Box 9.2 Object-oriented concepts in GIS

An object is a self-contained package of information describing the characteristics and capabilities ofan entity under study. In a geographic object data model the real world is modeled as a collection ofobjects and the relationships between the objects. Each entity in the real world to be included in the GISis an object. A collection of objects of the same type is called a class. In actual fact classes are a morecentral concept than objects from the implementation point of view. A class can be thought of as atemplate for objects. When creating an object data model the data model designer specifies classes andthe relationships between classes. Only when the data model is used to create a database are objects(instances or examples of classes) actually created.

Examples of objects include oil wells, soil bodies, stream catchments, and aircraft flight paths. In thecase of an oil well’s class, each oil well object might include properties defining its state – annualproduction, owner name, date of construction, and type of geometry used for representation at agiven scale (perhaps a point on a small scale map and a polygon on a large-scale one). The well classcould have connectivity relationships with a pipeline class that represents the pipeline used to transferoil to a refinery. There could also be a relationship defining the fact that each well must be located on adrilling platform. Finally, each well object might also have methods or behavior defining what it can do.Example behavior might include how to draw itself on a computer screen, how to create and deleteitself, and editing rules about how the well snaps to pipelines.

There are three key facets of object data models that make them especially good for modelinggeographic systems: encapsulation, inheritance, and polymorphism. Encapsulation describes the factthat each object packages together a description of its state and behavior. The state of an object can bethought of as its properties or attributes (e.g. for a forest object it could be the dominant tree type,average tree age, and soil pH). The behavior is the methods or operations that can be performed on anobject (for a forest object these could be create, delete, draw, query, split, and merge). For example,when splitting a forest polygon into two parts, perhaps following a part sale, it is useful to get the GIS toautomatically calculate the areas of the two new parts. Combining the state and behavior of an objecttogether in a single package is a natural way to think of geographic entities, and a useful way to supportthe re-use of objects.

Inheritance is the ability to re-use some or all of the characteristics of one object in another object. Forexample, in a gas facility system a new type of gas valve could easily be created by overwriting or addinga few properties or methods to a similar existing type of valve. Inheritance provides an efficient way tocreatemodels of geographic systems by reusing objects and also amechanism to extendmodels easily.New object classes can be built to reuse parts of one or more existing object classes and add some newunique properties and methods. The example described in Section 9.3 below shows how inheritanceand other object characteristics can be used in practice.

Polymorphism describes the process whereby each object has its own specific implementation foroperations like draw, create, and delete. One example of the benefit of polymorphism is that ageographic database can have a generic object creation component that issues requests to beprocessed in a specific way by each type of object class (e.g. gas pipes, valves, and service lines).This mechanism will work for a new object class because the new class is responsible forimplementing the object creation method.

Attribute rules are used to define the possibleattribute values that can be entered for any object.Both range and coded value attribute rules arewidely employed. A range attribute rule definesthe range of valid values that can be entered.Examples of range rules include: highway trafficspeed must be in the range 25–70 miles (40–120km) per hour; forest compartment average treeheight must be in the range 0–50 meters. Codedattribute rules are used for categorical data types.Examples include: land use must be of typecommercial, residential, park, or other; or pipematerial must be of type steel, copper, lead, orconcrete.

Connectivity rules are based on the specifica-tion of valid combinations of features, derivedfrom the geometry, topology, and attribute prop-erties. For example, in an electric distributionsystem a 28.8 kV conductor can only connect to a14.4 kV conductor via a transformer. Similarly, in agas distribution system it should not be possible toadd pipes with free ends (that is, with no fitting orcap).

Geographic rules define what happens to theproperties of objects when an editor splits ormerges them (Figure 9.15). In the case of a landparcel split following the sale of part of the parcelit is useful to define rules to determine the impacton properties like area, land use code, and owner.In this example, the original parcel area valueshould be divided in proportion to the size of thetwo new parcels, the land use code should betransferred to both parcels, and the owner nameshould remain for one parcel, but a new oneshould be added for the part that was sold off. Inthe case of a merge of two adjacent water pipes,decisions need to be made about what happens toattributes like material, length, and corrosion rate.In this example, the two pipe materials should bethe same, the lengths should be summed, and thenew corrosion rate determined by a weightedaverage of both pipes.

9.3 Example of a Water Facility ObjectData Model

The goal of this section is to describe an exampleof a geographic object model. It will discuss howmany of the concepts introduced earlier in thischapter are used in practice. The exampleselected is that of an urban water facility model.The types of issues raised in this example applyto all geographic object models, although ofcourse the actual objects, object classes, andrelationships under consideration will differ. Therole of data modeling, as discussed in Section9.1, is to represent the key aspects of the realworld inside the digital computer formanagement, analysis, and display purposes.

Figure 9.16 is a diagram of part of a waterdistribution system, a type of pressurizednetwork controlled by several devices. A pump isresponsible for moving water through pipes (mainsand laterals) connected together by fittings. Metersmeasure the rate of water consumption at houses.Valves and hydrants control the flow of water.

The purpose of the object model is to supportasset management, mapping, and networkanalysis applications. Based on this it is useful toclassify the objects into two types: the landbase

T E C H N I Q U E S

198

Area

10000

Property Tax

2500

Owner

Bob Smith

Area

4500

Property Tax

1125

Owner

Bob Smith

Area

5500

Property Tax

1375

Owner

Bob Smith

Property ofthe geometry

Geometryratio

Duplicate

Split

Area

12000

Property Tax

3000

Owner

Mary Jones

Area

10000

Property Tax

2500

Owner

Bob Smith

Area

22000

Property Tax

5500

Owner

Andy MacDonald

Property ofthe geometry

Addition Default value

Merge

Figure 9.15 Example of split and merge rules for parcelobjects: (A) split; (B) merge (Source: after MacDonald1999)

(A)

(B)

and the water facilities. Landbase is a general termfor objects like houses and streets that providegeographic context, but are not used in networkanalysis. The landbase object types are Pump-House, House, and Street. The water facilitiesobject types are: Main, Lateral (a smaller type ofWaterLine), Fitting (water line connectors), Meter,Valve, and Hydrant. All of these object types needto be modeled as a network in order to supportnetwork analysis operations like network isolationtraces and flow prediction. A network isolationtrace is used to find all parts of a network that areunconnected (isolated). Using the topologic con-nectivity of the network and information aboutwhether pipes and fittings support water flow it ispossible to determine connectivity. Flow predictionis used to estimate the flow of water through thenetwork based on network connectivity and dataabout water availability and consumption. Figure9.17 shows all the main object types and theimplicit geographic relationships to be incor-porated into the model. The arrows indicate thedirection of flow in the network. When digitizingthis network using a GIS editor it will be useful tospecify topologic connectivity and attribute rulesto control how objects can be connected (seeSection 9.2.3.3 above). Before this network canbe used for analysis it will also be necessary to

add flow impedances to each link (for example,pipe diameter).

Having identified the main object types, thenext step is to decide how objects relate to eachother and the most efficient way to implementthem. Figure 9.18 shows one possible objectmodel that uses the Unified Modeling Language(UML) to show objects and the relationshipsbetween them. Some additional color-coding hasbeen added to help interpret the model. UMLmodels are a type of tree structure where eachbox is an object class and the lines define howone class reuses (inherits) part of the class aboveit in the tree.

Object class names in an italic font are abstractclasses; those with regular font names are usedto create (instantiate) actual object instances.Abstract classes exist for efficiency reasons. It issometimes useful to have a class that implementssome capabilities once, so that several otherclasses can then be reused. For example, Mainand Lateral are both types of Line, as is Street.Because Main and Lateral share several things incommon – such as ConstructionMaterial,Diameter, and InstallDate properties, andconnectivity and draw behavior – it is efficient toimplement these in a separate abstract class,called WaterLine. The triangles indicate that oneclass is a type of another class. For example,PumpHouse and House are types of Building, andStreet and WaterLine are types of Line. Thediamonds indicate composition. For example, anetwork is composed of a collection of Line andNode objects. In the water facility object model,object classes without any geometry are coloredpink. The Equipment and OperationsRecordobject classes have their location determined bybeing associated with other objects (e.g. valvesand mains). The Equipment andOperationsRecord classes are useful places tostore properties common to many facilities, suchas EquipmentID, InstallDate, ModelNumber, andSerialNumber.

Once this logical geographic object model hasbeen created it can be used to generate a physicaldata model. One way to do this is to create themodel using a computer-aided software engineer-ing (CASE) tool. A CASE tool is a softwareapplication that has graphical tools to draw andspecify a logical model (Figure 9.19). A furtheradvantage of a CASE tool is that physical modelscan be generated directly from the logicalmodels, including all the database tables andmuch of the supporting code for implementingbehavior (Figure 9.20). Once a database structure(schema) has been created, it can be populatedwith objects and the intended applications putinto operation.

G E O G R A P H I C D A T A M O D E L I N G

199

Figure 9.17 Water distribution system network

Figure 9.16 Water distribution system water facilityobject types and geographic relationships

T E C H N I Q U E S

200

Figure 9.19 An example of a CASE tool (Microsoft Visio). The UML model is for a utility water system

Figure 9.18 A water facility object model

9.4 Geographic Data Modeling in Practice

Geographic information science is only as good asthe geographic database on which it is based and ageographic database is only as good as thegeographic data model from which it is derived.Geographic data modeling begins with a cleardefinition of the project goals and progressesthrough an understanding of user requirements,a definition of the objects and relationships,formulation of a logical model, and then creationof a physical model. These steps are a prelude todatabase creation and, finally, database use.

No step in data modeling is more importantthan understanding the purpose of the datamodeling exercise. This understanding can begained by collecting user requirements from themain users. Initially, user requirements will bevague and ill defined, but over time they willbecome clearer. Project goals and userrequirements should be precisely specified in alist or narrative.

Formulation of a logical model necessitatesidentification of the objects and relationships tobe modeled. Both the attributes and behavior ofobjects are required for an object model. A usefulgraphic tool for creating logical data models is aCASE tool and a useful language for specifying

models is UML. It is not essential that all objectsand relationships be identified at the firstattempt, because logical models can be refinedover time. The key objects and relationships forthe water distribution system object model areshown in Figure 9.18 above.

Once an implementation-independent logicalmodel has been created, this model can beturned into a system–dependent physical model.A physical model will result in an empty databaseschema — a collection of database tables and therelationships between them. Sometimes, forperformance optimization reasons or because ofchanging requirements, it is necessary to alterthe physical data model. Even at this relatively latestage in the process, flexibility is still necessary.

It is important to realize that there is no suchthing as the correct geographic data model. Everyproblem can be represented with many possibledata models. Each data model is designed with aspecific purpose in mind and is sub-optimal forother purposes. A classic dilemma is whether todefine a general-purpose data model that haswide applicability, but that can, potentially, becomplex and inefficient, or to focus on anarrower highly optimized model. A smallprototype can often help resolve some of theseissues.

G E O G R A P H I C D A T A M O D E L I N G

201

Figure 9.20 Use of a CASE tool in geographic data modeling (Source: ESRI)

Geographic data modeling is both an art and ascience. It requires a scientific understanding of thekey geographic characteristics of real-worldsystems, including the state and behavior ofobjects, and the relationships between them.Geographic data models are of critical importancebecause they have a controlling influence over thetype of data that can be represented and theoperations that can be performed. As we haveseen, object models are the best type of datamodel for representing rich object types andrelationships in facility systems, whereas simplefeature models are sufficient for very elementaryapplications such as a map of the body. In asimilar vein raster models are good for field-baseddata such as soils, vegetation, pollution, andpopulation counts. There is further discussion ongeographic data modeling in the next chapter.

Questions for Further Study

1. Figure 9.21 is an oblique aerial photographof part of the city of Kfar-Saba, Israel. Take 10minutes to list all the object classes (includingtheir attributes and behavior) and the relation-ships between the classes that you can see inthis picture that would be appropriate for acity information system study.

2. Why are there so many GIS data models?3. Why is it useful to include the conceptual,

logical, and physical levels in geographic datamodeling?

4. Describe five key differences between thetopologic vector and raster geographic datamodels. It may be useful to consult Figure 9.3and Chapter 3.

5. Review the terms encapsulation, inheritance,and polymorphism and explain withgeographic examples why they make objectdata models superior for representinggeographic systems.

Online Resources

NCGIA Core Curricula (www.ncgia.ucsb.edu/pubs/core.html

Core Curriculum in GIScience, Sections 2.3.1(Information Organization and Data Structure,Albert Yeung), 2.3.2 (Non-Spatial DatabaseModels, Thomas Meyer), 2.4.1 (Rasters,Michael Goodchild), 2.4.2 (TINs), 2.4.3(Quadtrees and Scan Orders, MichaelGoodchild), 2.6 (Representing Networks,Benjamin Zhan), and 2.9.1 (TransportationNetworks, Val Noronha)Core Curriculum in GIS, 1990, Units 4 (TheRaster GIS), 11 (Spatial Objects and DatabaseModels), 12 (Relationships among SpatialObjects), 13 (The Vector or Object GIS), 21(The Raster/Vector Database Debate), 30(Storage of Complex Objects), 31 (EfficientStorage of Lines – Chain Codes), 35 (RasterStorage), 36 (Hierarchical Data Structures), 37(Quadtree Algorithms and Spatial Indexes), 38(Digital Elevation Models), 39 (The TIN Model),

T E C H N I Q U E S

202

Figure 9.21 Oblique aerial view of Kfar-Saba, Israel (Courtesy: ESRI)

42 (Temporal and Three-DimensionalRepresentations), 43 (Database Concepts I),and 44 (Database Concepts II)

ESRI Virtual Campus course on ESRI software(campus.esri.com):Introduction to ArcView GIS, by ESRI (especiallythe ‘‘Getting Data into ArcView’’ lesson of theModule ‘‘Basics of ArcView’’: see alsoEinfuhrung in ArcView GIS by ESRI and JosefStrobl, and Introduc� ao ao ArcView GIS by ESRIand Mirna Cortopassi Lobo)Understanding Geographic Data by DavidDiBiase

General:www.infogoal.com/dmc/dmcdmd.htm Generaldata modeling resourceswww.utexas.edu/cc/database/datamodeling/Introduction to data modelingwww.fairview-industries.com/intro.htmExample of cadastral data modelingwww.rational.com/university/index.jspRational University – e-University from acommercial vendorwww.innovativegis.com/education/primer/concepts.html Introduction to GIS data models

Reference Links

Maguire D J, Goodchild M F, and Rhind D W (eds)1991 Geographical Information Systems:Principles and applications. Harlow, UK:Longman (Text available online from ‘Links

to Big Book 1’ at www.wiley.com/gis andwww.wiley.co.uk/gis).Chapter 16, High-level spatial data structures

for GIS (Egenhofer M J, Herring J)Chapter 19, Digital terrain modeling (Weibel R,

Heller M)Longley P A, Goodchild M F, Maguire D J, and Rhind

D W (eds) 1999 Geographical InformationSystems: Principles, techniques, managementand applications. New York: John Wiley.Chapter 25, GIS customization (Maguire, D J)Chapter 26, Relational databases and beyond

(Warboys M F)Chapter 29, Principles of spatial database

design and analysis (Bedard, Y)Chapter 36: Spatial tessellations (Boots, B)

References

ESRI 1997 Understanding GIS: the ArcInfo Method.Redlands, California: ESRI Press.

ESRI 2000 Inside ArcFM Water. Redlands,California: ESRI Press.

Heywood I, Cornelius S, and Carver S 1998 AnIntroduction to Geographical InformationSystems. Harlow: Longman.

MacDonald A 1999 Building a Geodatabase.Redlands, California: ESRI Press.

Worboys M F 1995 GIS: A computing perspective.London: Taylor and Francis.

Zeiler M 1999 Modeling Our World: The ESRI guideto geodatabase design. Redlands, California:ESRI Press.

G E O G R A P H I C D A T A M O D E L I N G

203