Topology.

Much of what we deal with in the lecture is covered in Longley et al., Chapter 9. Other
details may be found in Burrough and McDonnell, Chapter 3. Have a look also at the
ArcGIS help, and the help for the “clean” function in ArcToolbox.

What we consider here is how the data structure is set up to store topological
relationships. Topology is how we define the connectivity between geographic units,
areas and surfaces. In the GIS case, this is normally done to define spatial
relationships – e.g. what is the connectivity between two arcs along a street network?
In this case you can define rules about the volume of traffic each can cope with, the
time it would take to traverse the arc, whether an arc represents a one-way street (can
you turn into it?), times for left and right turns etc.

Spatial topological relationships might include “next to”, “near to”, “far from”, “is
surrounded by”, “surrounds” etc.

The key point from an implementation perspective is whether you have a raster or a
vector data structure.

Topology must be explicitly defined for a vector data structure. This is because it is
made up of a series of (geo-)graphic primitives, and invariably these are not stored next
to each other in the data file (can you store a set of points in a list so that they are all
close to their geographic neighbours?)

For the raster data structure, defining topology is somewhat easier. This is because the
raster structure uses a set of cells, and these are stored as an array within the computer.
Cells near to each other are easily referred to by calculating an offset from the cell of
interest. However, more complex relationships must be recalculated each time, or
converted to another data structure. For example, if you have a dataset describing how
difficult it is for a bushwalker to traverse the landscape (this might be based on a DEM
and vegetation data, with additional information about the quality of the view etc.),
then you will need to recalculate each and every possible pathway each time you want
to model bushwalker behaviour (albeit this may not be as much of an issue as storing
the thousands of possible paths as vectors…).

So, what are the components required for a classical topological data structure? This is
where the concepts of arc-node topology come in. Arcs are defined by a series of
points, and nodes are a special type of point used to define connection locations.
Polygons are made up of a series of arcs, with the connections defined by the nodes. A
node is inserted wherever there is an intersection between arcs, so two arcs crossing
will be converted into four arcs with a node at the junction. All of the information is
stored in a series of Relational Database Management System (RDBMS) files, with
additional tables to define what lines make up which polygons, which polygons are on
which side of each arc (there can only ever be two), which lines intersect at which node
etc. If you look at the files in the Arc data structure we use (using, for example,
Windows Explorer) then you will see a series of files with names like fred.aat, fred.pat
and fred.vat – each of these is an attribute table (aat=arc attr. table, pat=point or
polygon, vat=value and is used for integer grids). More detail can be obtained from
Longley et al. and Burrough and McDonnell.

An alternative to the classical arc-node topology is to use an object oriented approach.

This is still stored using an RDBMS. The object approach is perhaps less efficient in
some of the data storage, but does allow a greater degree of flexibility as far as
defining relationships is concerned. It also allows the storage of relationships between
different data structures in the one system – for example lines and polygons can be
used, and have relationships. An example might be the relationship between a stream
and its floodplain. The floodplain is a polygon and the stream is a line (each with
associated boundary uncertainty). With the arc-node approach these would need to be
stored as separate files with relationships rebuilt each time they are used, and would
result in a single output file having one data structure if needed. With the object
approach you can define behaviour between objects, each of which is inherited by
other associated objects according to some set of rules (if needed). In the catchment
case, one can then easily store the nested sub-catchments – eg first order catchments sit
in second order catchments, which in turn sit in third order catchments etc. One can
also define roads as objects, with increasing detail and special cases as required. The
access is easier (at least conceptually), as each road arc is an individual object rather
than a table entry that you need to edit.