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.