GIS users would like to store incremental feature and attribute
change and perform temporal queries such as, "Where was this
feature at time T?" or "Did these selected linear features
ever intersect?". The purpose of this paper is to highlight
some prototype ArcTools temporal GIS functions as well as to
review an ArcInfo temporal GIS data model design.
ArcTools has been extended to support basic temporal GIS functions.
The command tools are designed to create temporal coverages and
attribute tables which can store multiple feature versions and
multiple attribute versions. Edit tools allow feature and attribute
version editing, and place superseded features in archives with
links for historical data access. The Map tools can retrieve,
query and display vector feature versions by combinations of date
and topological criteria.
The primary objective of the research described in this paper
was to create a prototype Temporal GIS (TGIS) based upon ArcInfo
workstation software. Table 1 summarizes the TGIS objectives.
The prototype would be able to create, store and update TGIS data
sets and perform display and analysis operations. The working
system would have a menu-driven user interface to a set of temporal
data management, editing and query functions . Standard ArcInfo
GIS would remain unaffected and available to the TGIS user at
any time; the TGIS would simply be an overlay to ArcInfo. The
data model would be selected and designed to minimize data volume
but also to retain the necessary information for temporal analysis.
Table 1 The primary objectives for the operational system.
1. | Store multiple feature versions and multiple feature attribute versions with minimum data redundancy. |
2. | Use a data model that supports data query, display, and analysis by time and space constraints. |
3. | Ensure that the standard 2D GIS operations are unaffected--TGIS is an 'add-on' component. |
4. | Have the TGIS execute within ArcInfo GIS--no 'export/import' to external data formats, no external software. |
5. | Provide the user with a 'simple' menu interface to a set of data entry/edit, data management and data display/query functions. |
Previous researchers have suggested data models for TGIS and these
will not be discussed here (Hazelton & al. 1990, Langran
and Chrisman 1988, Langran 1993, Ross 1985 ) . The ideal TGIS
might have a true 4-dimensional vector data structure, but this
cannot be implemented without a major software engineering effort.
Therefore the update data model (also named "base state with
amendments" ) was used as it can be implemented on top of
the current ArcInfo data structure. The main advantage of this
model is that feature objects are traceable over time. The main
disadvantage is that there is no easy way to store spatial topology
changes over time (Hazelton, 1992). For example, to answer the
question, "When was it fastest to travel from A to B ?"
all possible network combinations must be retrieved, topology
built and all routes tested and compared. Similarly any spatial
join operations such as, "When was this forest area traversed
by a road ?" requires overlay operations of all possible
data combinations. In spite of these formidable processing requirements
this model can at least use the feature and attribute time stamps
to answer simple spatio-temporal queries and perform some analysis
(Candy, 1995).
In practice this TGIS model can best be implemented in 'reverse'.
The base state is always the current database. Feature updates
are added to the base state layer, with the old versions of any
modified features being moved into an archive layer. This method
has two advantages over keeping updates separate from some fixed
base state. Firstly, the current data set is usable for normal
GIS functions and secondly, deleted features (features that have
ceased to exist), and any previous versions of deleted features,
can be found and traced using the archive layer(s). Table 2 shows
the various items that must be added to the ArcInfo feature attribute
tables to support the TGIS.
Table 2 Items to add to FAT for the TGIS design
Item Name (user defined) | |
tgis-id | Track all feature versions. TGIS keeps this unique for each feature version (BUT can have multiple instances due to line feature splitting). |
fcode | Link to any related tables for non-time varying attributes. |
fdb-in | Store feature version database time in. |
fdb-out | Store feature version database time out (or 0). |
fev-in | Store feature version event time in. |
fev-out | Store feature version event time out (or 0). |
prev-id | Store 'tgis-id' of previous feature version (or 0). |
next-id | Store 'tgis-id' of next feature version (or 0). |
fa-id | Link related temporal attribute table(s). |
| |
f-id | Store 'from-node' 'user-id' number. |
t-id | Store 'to-node' 'user-id' number. |
l-id | Store 'left-polygon' 'tgis-id' number. |
r-id | Store 'right-polygon' 'tgis-id' number. |
Figure 1 shows an instance of the ArcInfo TGIS vector update
data model for a simple 'line theme' data set. There are two coverages,
one storing the current data for a fictitious 'rivers' data set
(named 'rivers') and the other storing any archive 'rivers' data
(named 'rivers1'). Each coverage has a feature attribute table
with the same TGIS item definitions. An old feature version points
at the next feature version using the 'next-id' value and a current
feature points at an old feature using the 'prev-id' value. In
the example, feature 'tgis-id's 7 and 8 point at each other. Note
that feature 'tgis-id' 5 is an archive feature which does not
point at a newer version, indicating that the feature 'died' (disappeared
at some point in time).
Line and node topology are up to date for the current coverage.
Current topology ensures that the items for 'fnode#' and 'tnode#'
are correct in the AAT and each unique node has a 'user-id' in
the NAT. Topology is not correct for the archive coverage as features
are placed in the coverage at random without line intersection
formation (indeed line intersection would often be incorrect as
features cannot intersect with their previous versions and features
may not exist during the same time period as other features).
Instead archive topology is stored in the TGIS items 'f-id' and
't-id'. These items will contain the node user id values at the
time the feature was archived. For example, archive feature 'tgis-id'
5 has a 'f-id' value of 3, which will be one of feature 'tgis-id'
9 node's 'user-id' values.
The temporal attribute table 'rivers.ard' stores user defined
items for 'Width' and 'Flow'. Many features in the current or
archive coverages may point to the same attribute records using
the 'fa-id' item.
Figure 1. An example TGIS ArcInfo line theme data set
The TGIS is implemented as a set of extra functions which are
integrated into the ArcTools user interface (figure 2). Each TGIS
function consists of one tool. Each tool is made up of one or
more menus which the user can interact with, one AML program which
performs data processing, and one help file which the user can
read.
Figure 2. The relationships between the TGIS user and the TGIS
components.
This function updates a feature position or shape, places the
old feature in the archive coverage and sets the appropriate TGIS
FAT item values that are needed for feature version retrieval.
The function is started by the TGIS replace feature button or
by feature selection followed by any menu option that causes
a change in the position of the feature. In the second case, the
TGIS software notifies the user that an update operation should
be performed and waits for confirmation. Versioning operations
follow unless the user overrides the TGIS function, as may be
the case if a recent data entry error needs correction (figure 3).
The user must enter the new feature version's event time and opt
to either keep the current attribute record or to create a new
attribute record. The FAT and temporal attribute table records
can be viewed and modified at any time after digitizing a new
feature or modifying an existing feature's position. The general
procedure for replacing an existing feature is shown in figure
3. Feature deletion follows the same procedure except that a replacement
feature is not added.
Figure 3. Feature update procedure.
The function is implemented within a "tgis-arc"
tool and takes care of feature deletion, simple feature replacement,
feature merges and feature splits. The sequence of software actions
is explained below.
The software copies the selected feature into the archive coverage and adds the feature event time-out and database time-out values (these are equal to the time-in values for the new feature). Extra software processing is needed for Arcs and Polygons as feature topology values must be stored over time. The TGIS 't-id' and 'f-id' item values are set to the Arc 'to-node' and 'from-node' user id values if an arc is being replaced. In addition, the 'l-id' and 'r-id' items values are set to the Arc left and right polygon 'tgis-id' values if the coverage has polygon topology. The next highest unique 'tgis-id' value is found. The 'next-id' value is set equal to the unique 'tgis-id' value unless an arc or polygon is being split, in which case the 'next-id' is set to a value of -1.
The original feature is deleted if a completely new version is
being added, or left in place for operations such as partial modification,
rotation, movement etc. The modified or new feature is given the
unique 'tgis-id' value. The 'prev-id' value is set to the replaced
feature's 'tgis-id' unless arcs or polygons are being merged,
in which case the 'prev-id' value is set to -1. The 'fa-id' value
can either be left unchanged (in which case the new feature points
to the same attribute record as the old version), or is assigned
a unique value (in which case a new related attribute record is
created). Feature deletion is handled identically to feature replacement
except no new feature is added.
The search can start by using all the coverage features or just
the currently selected features. Figure 4 shows the main TGIS
query menu (a modified ArcTools menu). The user can find TGIS
features by temporal attribute values (such as 'width > 5'),
dates, and by event criteria (such as 'within the polluted event
area').
Figure 4 The main TGIS version menu
The search can be restricted to current features or apply to past
feature versions. Past feature versions (including 'dead' features)
are searched using the TGIS versions second menu shown in figure
5. All versions or a user-defined number of versions can be queried.
The versions can be restricted to those within two dates, or those
closest to some fixed dates. Dates may be typed in, retrieved
from a file, or from an 'event table' record. Line feature version
intersection or polygon neighbourliness criteria can be applied.
Feature and attribute interpolation and generalization options
are included, but not yet implemented.
Figure 5 TGIS feature versions second menu
The results of the search are a text report (to display or print)
and a new theme which contains the feature versions. There may
be multiple new themes if the search was performed on a polygon
coverage (each polygon found is placed in a new theme to avoid
the problem of overlapping polygons that exist at different points
in time). If required, the user can change the new theme's properties,
such as symbology , which are initially the same as the original
search theme's properties. An example search is shown in figure
6.
Figure 6 An example use of the TGIS versions function
The TGIS feature version function is made up of a "tgissel"
tool in the TGISTools "viewlib" directory.
The actual process of recreating a polygon version is much more
complex than simply retrieving the component polygon boundary
lines and label point that make up the previous version. Figure
7 shows three possibilities that might create a new polygon version
and the resultant archive features--one or more of the polygon
exterior or interior arcs may be updated, the label position may
change, or an arc deletion may cause two or more polygons to merge
together.
Figure 7 Examples of previous polygon versions
Processing starts by building a list of currently selected polygon
labels. Then a list of previous polygon labels is formed. Each
label version must be examined in turn and a list of all arcs
belonging to each polygon label version generated. Some arcs will
have many versions, so each one is part of a different polygon
version for the label version. Other difficulties include arc
and label split and merge operations which reduce or expand the
possible number of versions as the processing continues. The final
step is to reassemble all the previous polygon versions with
the correct polygon arc and label.
The many arcs and single label that make up each polygon version
must be extracted from their relevant coverages and placed in
a new coverage so that polygon topology can be built. Each new
coverage is attached to a new theme. The entire procedure is slow,
though functional.
This paper describes some of the components of a simple ArcInfo
based TGIS. The software consists of about 6000 lines of AML code
and menus incorporated into the standard ArcTools library. The
prototype TGIS can give users the opportunity to experiment with
spatio-temporal data via a menu-driven user interface. Eventually
GIS software products will have to fully incorporate the time
dimension. The user interface will be a challenging problem even
after the 4-dimensional data model GIS software has been developed.
Candy, J., 1995, Development of a Prototype Temporal Geographic
Information System, Unpublished Master's Thesis, Simon Fraser
University, Burnaby, B.C., Canada.
Hazelton, N. W. J., Leahy, F. J., and Williamson, I. P., 1990,
On the Design of Temporally Referenced 3-D Geographical Information
Systems: Development of Four-Dimensional GIS. In Proceedings
of GIS/LIS '90, Anaheim, CA., USA (Bethesda, MD: American
Congress on Surveying and Mapping), pp. 357-372.
Hazelton, N. W. J., 1992, Beyond the 2-D Map: A New Metaphor for
Multi-Temporal 4-D GIS. In Proceedings of GIS/LIS '92
. San Jose, CA USA (Bethesda, MD: American Congress on Surveying
and Mapping), pp. 303-313.
Langran, G. and Chrisman, N., 1988, A Framework for Temporal Geographic
Information, Cartographica, 25, pp. 1-14.
Langran, G., 1993, Manipulation and Analysis of Temporal Geographic
Information. In Proceedings of Canadian Conference on GIS,
Ottawa, Canada (Ottawa: The Canadian Institute of Geomatics),
pp. 869-879.
Ross, J., 1985, Detecting Land Use Change on Omaha's Urban Fringe
using a Geographic Information System. In Proceedings of Auto
Carto 7 Washington D.C. USA (Falls Church, Va: American Congress
on Surveying and Mapping), pp. 463-471.