Adding Temporal GIS Functions to ArcInfo Version 7

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.


Introduction

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.


The Data Model

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)
Item Purpose
tgis-idTrack all feature versions. TGIS keeps this unique for each feature version (BUT can have multiple instances due to line feature splitting).
fcodeLink to any related tables for non-time varying attributes.
fdb-in Store feature version database time in.
fdb-outStore feature version database time out (or 0).
fev-inStore feature version event time in.
fev-outStore feature version event time out (or 0).
prev-idStore 'tgis-id' of previous feature version (or 0).
next-idStore 'tgis-id' of next feature version (or 0).
fa-idLink related temporal attribute table(s).
Arc Attribute Tables have the following additional items.

(values are 0 for current features)
f-idStore 'from-node' 'user-id' number.
t-idStore 'to-node' 'user-id' number.
l-idStore 'left-polygon' 'tgis-id' number.
r-idStore 'right-polygon' 'tgis-id' number.


Arc TGIS topology example

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.

Diagram of an example TGIS ArcInfo line theme data set

Figure 1. An example TGIS ArcInfo line theme data set

TGIS Implementation

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.



Diagram of the relationships between the TGIS user and the TGIS
components

Figure 2. The relationships between the TGIS user and the TGIS components.

Examples of the TGIS Tools

The TGIS Function to Update an Existing TGIS Feature

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.

Diagram of the feature update procedure

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 TGIS Function for spatial, temporal and attribute feature selection

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').

Diagram of the main TGIS version menu

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.

Diagram of the TGIS feature versions second menu

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.

Diagram of An example use of the TGIS versions function

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.

Diagram of examples of previous polygon versions

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.

Summary

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.

References

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.


Jonathan Candy
GIS Department
British Columbia Institute of Technology
3700 Willingdon Avenue
Burnaby, B.C. V5G 3H2
Canada
Telephone: (604) 432-8378
Fax: (604) 435-3561