UNIT 12 - RELATIONSHIPS AMONG SPATIAL OBJECTS

Compiled with assistance from Gerald White, California State University, Sacramento

A. INTRODUCTION

Three types of relationship

B. EXAMPLES OF SPATIAL RELATIONSHIPS

Point-point

Point-line

Point-area

Line-line

Line-area

Area-area

C. CODING RELATIONSHIPS AS ATTRIBUTES

Example - "flows into" relationship

Example - "is contained in" relationship

D. OBJECT PAIRS

E. CARTOGRAPHIC AND TOPOLOGICAL DATABASES

Strict definition of "topological"

Usage of "topological" in GIS

F. PLANAR ENFORCEMENT

Process

Objective

G. RELATIONSHIPS IN RASTER SYSTEMS

REFERENCES

EXAM AND DISCUSSION QUESTIONS

NOTES

This final unit in the spatial databases module looks at the complex issue of relationships and how they can be coded. The important concept of planar enforcement, introduced here, is referred to several times in later units.

UNIT 12 - RELATIONSHIPS AMONG SPATIAL OBJECTS

Compiled with assistance from Gerald White, California State University, Sacramento

A. INTRODUCTION

- there are a vast number of possible relationships in spatial data

- many are important in analysis

- e.g. "is contained in" relationship between a point and an area is important in relating objects to their surrounding environment

- e.g. "intersects" between two lines is important in analyzing routes through networks

- relationships can exist between entities of the same type or of different types

- e.g. for each shopping center, can find the nearest shopping center (same type)

- e.g. for each customer, can find the nearest shopping center (different types)

Three types of relationship

1. relationships which are used to construct complex objects from simple primitives

- e.g. relationship between a line (chain) and the ordered set of points which defines it

- e.g. relationship between an area (polygon) and the ordered set of lines which defines it

2. relationships which can be computed from the coordinates of the objects

- e.g. two lines can be examined to see if they cross - the "crosses" relationship can be computed

- e.g. areas can be examined to see which one encloses a given point - the "is contained in" relationship can be computed

- e.g. areas can be examined to see if they overlap - the "overlaps" relationship

3. relationships which cannot be computed from coordinates - these must be coded in the database during input

- e.g. we can compute if two lines cross, but not if the highways they represent intersect (may be an overpass)

- some databases allow an entity called a "complex object", composed of "simple objects", e.g. objects representing "house", "lot", "cable", with associated attributes might be grouped together logically as "account"

 

B. EXAMPLES OF SPATIAL RELATIONSHIPS

Point-point

- "is within", e.g. find all of the customer points within 1 km of this retail store point

- "is nearest to", e.g. find the hazardous waste site which is nearest to this groundwater well

Point-line

- "ends at", e.g. find the intersection at the end of this street

- "is nearest to", e.g. find the road nearest to this aircraft crash site

Point-area

- "is contained in", e.g. find all of the customers located in this ZIP code boundary

- "can be seen from", e.g. determine if any of this lake can be seen from this viewpoint

Line-line

- "crosses", e.g. determine if this road crosses this river

- "comes within", e.g. find all of the roads which come within 1 km of this railroad

- "flows into", e.g. find out if this stream flows into this river

Line-area

- "crosses", e.g. find all of the soil types crossed by this railroad

- "borders", e.g. find out if this road forms part of the boundary of this airfield

Area-area

- "overlaps", e.g. identify all overlaps between types of soil on this map and types of land use on this other map

- "is nearest to", e.g. find the nearest lake to this forest fire

- "is adjacent to", e.g. find out if these two areas share a common boundary

 

C. CODING RELATIONSHIPS AS ATTRIBUTES

- in the database model we can visualize relationships as additional attributes

Example - "flows into" relationship

overhead - Coding relationships as attributes I

- option A:

- each stream link in a stream network could be given the ID of the downstream link which it flows into

- flow could be traced from link to link by following pointers

- option B

- alternatively the network could be coded as two sets of entities - links and nodes

- the links could "point" to their downstream node

- the nodes could "point" to the next downstream link

Example - "is contained in" relationship

overhead - Coding relationships as attributes II

- given:

- locations of 4 wells, with attributes of depth and flow

- wells lie in two different counties with attributes of population

- we wish to determine how much flow is available in each county:

1. find the containing county of each well (compute the "is contained in" relationship)

- store the result as a new attribute, County, of each well

2. using this revised attribute table, total flow by county and add results to the county table

County Population Flow

A 20,000 4,500

B 35,000 5,500

 

D. OBJECT PAIRS

- distance is an attribute of a pair of objects

- there are other types of information which are similarly attributes of pairs of objects

- e.g. flow of commuters between a suburb and downtown

- e.g. trade between two countries

- e.g. flow of groundwater between a sink and a spring

- in some cases these attributes can be attached to an object linking the origin and destination objects

- e.g. on a map, trade can be an attribute of an arrow connecting the two countries

- thick arrows indicate strong trade

- however, such maps quickly become impossibly complex

- in general, it is necessary to allow for information which is not an attribute of any one object but of a pair of objects, including:

- distance

- connectedness - yes or no

- flow of goods, trade

- number of trips

- such attributes cannot necessarily be ascribed to any real object

- e.g. commuting flows between a suburb and downtown are not necessarily attributes of any set of links in the transport network

- e.g. flow of groundwater between a sink and a spring does not necessarily follow any aquifer or conduit

- these are attributes of object pairs

- object pairs are important in various kinds of spatial analysis using GIS

- attributes of object pairs can be thought of as tables which have one object as rows and the other object as columns with the values in each cell representing the value of the interaction between them

- are many different terms for the implementation of this concept - e.g. interaction matrix, turn table, Cartesian product

 

E. CARTOGRAPHIC AND TOPOLOGICAL DATABASES

Strict definition of "topological"

- if a map is stretched and distorted, some of its properties change, including:

- distances

- angles

- relative proximities

- other properties remain constant, including:

- adjacencies

- most other relationships, such as "is contained in", "crosses"

- types of spatial objects - areas remain areas, lines remain lines, points remain points

- strictly, topological properties are those which remain unchanged after distortion

Usage of "topological" in GIS

- a spatial database is often called "topological" if one or more of the following relationships have been computed and stored

- connectedness of links at intersections

- ordered set of lines (chains) forming each polygon boundary

- adjacency relationships between areas

- unfortunately the precise meaning of the term has become distorted by use

- in general, "topological" implies that certain relationships are stored, making the data more useful for various kinds of spatial analysis

- by contrast, a database is called "cartographic" if the above conditions are absent

- objects can be manipulated individually

- relationships between them are unavailable or are considered unimportant

- cartographic databases are less useful for analysis of spatial data

- however they are satisfactory for simple mapping of data

- many packages designed for mapping only use cartographic database models

- a cartographic database can usually be converted to a topological database by computing relationships - the process of "building topology" through planar enforcement

 

F. PLANAR ENFORCEMENT

- objects and their attributes are capable of describing the conditions existing on a map or in reality

- variation of a single property like soil type or elevation over a mapped area is achieved by including appropriate attributes for entity types

- e.g. elevation described by giving attributes to elevation points

- e.g. soil type described by giving attributes to areas

- in cases like soil type, the objects used to describe spatial variation must obey certain simple rules

- e.g. two areas cannot overlap

- e.g. every place must be within exactly one area, or on a boundary

- these rules are collectively referred to as planar enforcement

- a set of objects obeying these rules is said to be planar enforced

- planar enforcement is a very important operation in a vector GIS

Process

- begin with a number of unrelated line segments

- imagine a number of limp spaghetti noodles lying on a table

- the following elements are now defined (terminology from the US Census Bureau for development of digital spatial database concepts):

overhead - Planar enforcement

- a 0-cell (or node) is identified wherever two noodles cross or a noodle terminates

- i.e. all intersections are calculated

- 1-cell (or link, also "chain", "arc", "edge") is identified for each length of noodle between two consecutive 0-cells (nodes)

- a 2-cell (or area, also "face", "polygon") is defined for each group of consecutive 1-cells forming an enclosed area that does not contain any 1-cells that are not part of the boundary

- note that these definitions relate directly to the ordinary concept of dimensionality

- the results are:

- 0-cells are either isolated ("points") or adjacent to one or more 1-cells ("nodes")

- all 1-cells end in exactly two 0-cells

- each line segment (chain) between adjacent 0-cells is assigned to exactly one 1-cell

- all 1-cells lie between exactly two 2-cells

- every place on the "map" between noodles is assigned to a single 2-cell (the rest of the world is a 2-cell as well, often given the ID zero)

Objective

- planar enforcement is used to build objects out of digitized lines (hence the phrase "building topology")

- it is a consistent and precise approach to the problem of making meaningful objects out of groups of lines

- simple rules can be used to correct some digitizing errors:

- a very short 1-cell terminating in a 1-valent 0-cell indicates an overshoot

diagram

- a long 1-cell terminating in a 1-valent 0-cell very close to another 1-cell indicates an undershoot

diagram

- planar enforcement is often needed when a set of data is being imported from another system

- e.g. if the source is a cartographic database and needs to have relationships computed

- e.g. if the database models of the two systems are incompatible, data is transferred as unrelated noodles, then objects are rebuilt

- planar enforcement must be applied one layer at a time

- planar enforcement concepts are built into many systems

 

G. RELATIONSHIPS IN RASTER SYSTEMS

- in general, it is easier to work with relationships in vector systems

- the concept of object is not as natural for raster systems, which model the world as composed of pixels

- however, relationships can be handled in raster systems with simple techniques:

overhead - Relationships in raster systems

- e.g. a map of county boundaries

- in one layer each pixel has a county code attribute which is an ID pointing to an entry in a county attribute table

- in a second layer each well location is coded by giving the appropriate pixel an ID pointing to a well attribute table

- the "is contained in" relationship can be computed by an overlay operation and stored as an additional column in the well attribute table

- only a few raster systems contain this type of capability to extract relationships into attribute tables

- most do not handle relationships between spatial objects

REFERENCES

Burrough, P.A., 1986. Principles of Geographical Information Systems for Land Resources Assessment. Clarendon, Oxford. Chapter 2 describes objects, attribute tables and relationships.

Goodchild, M.F., 1988. "Towards an enumeration and classification of GIS functions," Proceedings, IGIS '87. NASA, Washington DC 2:67-77. Defines and discusses object pairs.

Keating, T., W. Phillips and K. Ingram, 1987. "An integrated topologic database design for geographic information systems," Photogrammetric Engineering and Remote Sensing Vol. 53. Good discussion of topological and cartographic database models.

EXAM AND DISCUSSION QUESTIONS

1. Discuss the use of planar enforcement for street networks, and the problems presented by overpasses and underpasses. Can you modify the basic rules to maintain consistency but allow for such instances?

2. What additional examples of relationships can you devise in each of the six categories used in section B?

3. Why have designers of raster GIS not commonly devised ways of coding spatial relationships between objects in their systems? Is this likely to change in the future, and if so, why?

4. "Topology is what distinguishes GIS from automated cartography". Discuss.