IMPLEMENTING AN ARCHIVAL GIS TEMPLATE UTILIZING ARCMAP GIS SOFTWARE AND THE PERSONAL GEODATABASE

A THESIS PRESENTED TO THE DEPARTMENT OF GEOLOGY AND GEOGRAPHY

IN CANDIDACY FOR THE DEGREE OF MASTER OF SCIENCE

By ROBERT BRUNDAGE

NORTHWEST MISSOURI STATE UNIVERSITY MARYVILLE, MISSOURI

NOVEMBER 2006

IMPLEMENTING AN ARCHIVAL GIS TEMPLATE

IMPLEMENTING AN ARCHIVAL GIS TEMPLATE UTILIZING ARCMAP GIS

SOFTWARE AND THE PERSONAL GEODATABASE

ROBERT BRUNDAGE

Northwest Missouri State University

THESIS APPROVED

Thesis Advisor Date

Dean of Graduate School Date

iii

IMPLEMENTING AN ARCHIVAL GIS TEMPLATE UTILIZING ARCMAP GIS

SOFTWARE AND THE PERSONAL GEODATABASE

Abstract

Despite research and literature about temporal GIS (Geographic

Information Systems), there is little actual application. Traditionally, the quantity

and value of temporal queries made on a GIS have not justified the excessive

time and effort required to maintain temporal attributes. Thus, the temporality of

many a GIS has been ignored. The recent maturation of GIS software, of GIS

databases, and of computer operating systems has dramatically reduced the

once onerous overhead of managing a temporal GIS.

The research objective for this thesis is to develop a generic temporal

template for geo-objects using available commercial GIS software and apply it to

facility management for Fort Campbell Army Base. The archiving methods use

the extensibility of the ESRI ArcGIS suite of software and the personal

geodatabase to create a ‘supersede-not-delete’ editing environment which

establishes a geo-object archival record. A database schema has been

developed that involves a series of attributes that are established and maintained

through automated methods within the personal geodatabase feature class.

These attributes manage archival information. The geo-object archiving template

(tGIS Extension) was developed to support Fort Campbell Army Base use of GIS

in managing facilities and infrastructure.

iv

Table of Contents Abstract ................................................................................................................ iii

Table of Contents .................................................................................................iv

List of Figures.......................................................................................................vi

List of Tables .......................................................................................................vii

1 Introduction........................................................................................................ 1

2 Literature Review............................................................................................... 5

2.1 Development of Temporal Concepts ........................................................... 5

2.2 Applied Temporal Concepts ........................................................................ 7

2.3 Conclusion................................................................................................. 12

3 Framework and Methodology ......................................................................... 13

3.1 Archival Database Schema ....................................................................... 14

3.2 Database Implementation ......................................................................... 20

3.3 Database Display...................................................................................... 28

3.4 Database Query........................................................................................ 30

3.5 Fort Campbell GIS Datasets and the tGIS Extension ................................ 31

4 Results and Discussion ................................................................................... 35

4.1 Database Schema Attributes .................................................................... 35

4.2 Analysis of Implementation ....................................................................... 35

4.3 Analysis of Display.................................................................................... 46

v

4.4 Analysis of Query...................................................................................... 51

4.5 Summary................................................................................................... 55

5 Conclusion....................................................................................................... 58

Appendix A: Code implementing ‘Supersede-not-delete’ ................................... 62

References ......................................................................................................... 67

vi

List of Figures Figure 1: Location: Fort Campbell Army Base................................................... 31

Figure 2: Training Area and Cantonment Area.................................................. 32

Figure 3: Nine Attributes that Make Up the Database Schema ......................... 35

Figure 4: Geo-object has been Created ............................................................ 36

Figure 5: Geo-object has been Deleted.............................................................. 37

Figure 6: Geo-object has been Moved ............................................................... 38

Figure 7: Geo-object’s Shape has been Modified.............................................. 39

Figure 8: Geo-object has been Reshaped......................................................... 40

Figure 9: Geo-object has been Split into Two Geo-objects ............................... 41

Figure 10: Geo-object has been Created by Auto-Complete Polygon ............... 42

Figure 11: Two Geo-objects have been Merged into One Geo-object............... 43

Figure 12: Layer Files Used to Access GIS Data ............................................... 47

Figure 13: Geodatabase Stored at Separate Location to Control Rendering ..... 48

Figure 14: User Display of Archival Data Controlled by Layer File ..................... 49

Figure 15: Display showing Archived Geo-objects ............................................. 50

Figure 16: Temporal GIS Toolbar and Query Tool ............................................. 51

Figure 17: Archival Layers are showing the ‘Active’ Geo-objects ....................... 52

Figure 18: Display with Definition Query set to Date .......................................... 53

vii

List of Tables Table 1: Effect on Geo-object Archiving on Buildings Feature Class................. 56

1

1 Introduction

As GIS manager for a military installation, it is not uncommon for the

author to be asked to “look back in time” using the installation GIS to answer

current questions. In the Army installation master planning process, before a site

can be selected for development its previous use must be reviewed for

environmental, archaeological and cultural concerns. The archival methods used

within the installation GIS did not provide timely or accurate answers to the

questions asked. Decisions to construct new infrastructure, tear down existing

infrastructure, rename street networks, and renumber addressing were not

properly documented nor archived for future reference. The dynamic nature of

changes occurring on the installation’s infrastructure demonstrated a need for

temporality within the GIS to track these changes. The placing of new

infrastructure and the proper management of existing infrastructure require this

historical information to be accessible and accurate within the GIS. For example,

it is not uncommon to question why there are abandoned utilities at certain

locations or to ask what existed in a specific area over a period of time. The

answer to these questions could be holding up current construction projects or

aiding environmental restoration. Federal and local regulations require tracking

of environmentally sensitive materials and the management of restoration

programs for areas where environmentally sensitive materials have been used

(Army Pamphlet 200-1 2002). An easily implemented and manageable archival

2

GIS will increase the usefulness of the installation’s GIS and provide significantly

better infrastructure management to answer these historical queries.

The research objective for this thesis is to develop a generic temporal

template for geo-objects using available commercial GIS software and apply it to

facility management for Fort Campbell Army Base. Despite research and

literature about temporal GIS (Geographic Information System), there is very little

real employment (Freelan 2003). GIS industries, such as transportation,

emergency management, and location based services, address temporal GIS

issues within the context of those industries’ specific needs. There are a few

software extensions such as Environmental Systems Research Institute’s (ESRI)

Tracking Analyst and DHI Software’s ArcMap Temporal Analyst that are geared

toward specific temporal GIS data. There exist a few computer code libraries,

such as ‘Terrlib: an open source GIS library for spatial-temporal databases’, that

implement a temporal GIS structure but do not utilize mainstream GIS software

or data formats. Examples of applied temporal GIS usage are rare. ESRI’s

literature on its upcoming release of ArcGIS 9.2 (ESRI 2006b) promises

advancements in historic (archival) GIS, but until applied and tested, it cannot be

relied upon to solve basic problems of temporal GIS management.

The relative newness of digital spatial data, digital networks, computers

and GIS software has led to a focus on digital data creation, acquisition and

updating. Unless time was a specific element of the data which was captured,

such as with bus scheduling and GPS tracking, the filiations and/or life span of

the captured geo-objects have been of no concern. Traditionally, the number

3

(and value) of temporal queries on a GIS has not been enough to justify the

amount of manual interaction required to maintain the temporal GIS. This

situation has resulted in the forgoing of temporality with many GIS geo-objects.

The recent maturation of GIS software, of GIS databases and of computer

operating systems has the capability to reduce the amount of manual editing that

has traditionally been required to maintain a temporal GIS.

Any GIS will have added value if said GIS can provide basic historical

data. The following are very useful, valid queries:

• Show me the database at time “A.”

• Show me how feature “Y” has changed through time.

• Show me what was in the space of feature “Z” at time “B.” (ESRI 2002)

This research addresses the development of an archival GIS template for

facilities and infrastructure on Fort Campbell Army Base. The template allows

archiving of geo-objects and the query and display of archived geo-objects. The

archival GIS template will utilize ESRI’s personal geodatabase storage model,

ESRI’s ArcMap GIS software and ESRI’s ArcObjects programming classes. The

template is called the ‘tGIS Extension’; it has been implemented upon Fort

Campbell Army Base’s building and street network infrastructure. The template

uses personal geodatabase extensibility capabilities to create an editing

environment that archives geo-objects when changes occur. To manage the

historic GIS a series of attributes are established and maintained through

automated methods within the feature class to allow tracking of when and why

4

change has occurred. Display and query tools have been developed to allow

proper access, display and viewing of the historic geodatabase. The personal

geodatabase is limited by storage (2 gigabytes total/250 megabytes practical)

and access, with a single user write environment and Microsoft Jet Engine

limitations of concurrent read access. The methods and tools developed in this

thesis may transfer to the ESRI Arc Spatial Database Engine (ArcSDE/RDBMS*)

environment easily, but these systems for larger GIS management are not within

the scope of this research.

*Relational Database Management Systems

5

2 Literature Review

In searching the Internet and ESRI’s ArcScripts website (ESRI 2006a), the

author could not find a generic implementation of a temporal GIS that did not

involve RDBMS database versioning techniques. A data model and case study

that utilized RDBMS and database versioning was found (ESRI 2004) but the

larger GIS requiring RDBMS is not within the scope of this thesis. An example

was found that time tagged existing geo-objects (Thoms 2005) but did not

archive geo-objects. The development of an archival GIS template for the non-

RDBMS GIS environment is the objective of this research. From the literature

review, the author has defined the concepts and terms that establish a database

schema and methodology to create an archival GIS template.

2.1 Development of Temporal Concepts

The need to include time along with spatial information was identified early

in the development of GIS. Berry (1964) defined geographic data as being

composed of times, places, and attributes. Sinton (1978) identified data as

consisting of location, time, and attribute. Depending on the type of data (i.e.

soils and census data), each element of data (location, time, and attribute) was

either held fixed, controlled, or measured such as with elevation data. The time

of collection would be fixed, the values of the elevation attribute would be

controlled to a range, and the location of the value would be measured.

6

Basoglu and Morrison (1978) designed a structure to manage US county

boundaries. The structure allowed ‘snapshots’ of county boundaries as

requested by date. This ‘requested date’ type query is basic to temporal

information. Corson-Rikert (1987) presented methods for adding changed data

through graphic aids provided by the GIS and then adding these changes to

existing files. Calkins and Dickinson (1987) suggested that the complexity of

spatio-temporal data demands special tools for management and display.

Langran (1992) published a book addressing the concepts, problems and

issues with implementing spatio-temporal GIS. According to Freelan (2003),

“Langran’s work continues to provide not only the initial, but frequently the most

recent, word on many of the basic issues that arise with the attempt to add time

to a GIS.” Langran brought a somewhat new insight into temporal GIS. Langran

had practical experience dealing with a temporal GIS. ‘Notice to Mariners’ is a

system used to update nautical charts after they have been published. The

updated notices could consist of adding or subtracting information to a nautical

chart or could be a textural notice about an area. The notice is time and location

tagged. Langran was involved in the development of techniques to use GIS in

the ‘Notice to Mariners’ system and the automating of nautical charts. This

experience gave Langran a deeper insight into the problems of implementing

time within a GIS.

Earlier works on applied temporal GIS (Langran 1992, Halls and Miller

1996, Lester 1990) were influenced by technical issues (older GIS storage

formats that enforced topology) and the limitation of computer processing at the

7

time when they were written. Even with the frenetic pace of technology

advancement, some of the more recent papers (Freelan 2003, Berman 2003)

were also somewhat limited in scope by the software and GIS storage at time of

publication. During the development of this research, ESRI announced a new

storage format that handles the archiving of geo-objects (ESRI 2006b). ESRI

has not published any details of the new storage format or any details about the

type of data archiving or how data archiving would be supported. Freelan (2003)

was aware that the advent of ESRI’s geodatabase would affect his research.

Likewise, the author is aware that ESRI has proposed changes to database

storage, but without technical documentation or possession of what is currently

promised, the author is proceeding with his research.

2.2 Applied Temporal Concepts This research examines temporal GIS as it applies to developing an

archival GIS template using ESRI’s ArcGIS environment. The resulting historic

GIS manages relatively static geo-objects within a military installation’s

infrastructure. A number of issues, technical and conceptual, must first be

addressed in order to implement this historic GIS.

When examining temporal geo-objects, there are two types: static geo-

objects and dynamic geo-objects (Nadi and Delavar 2003). Static geo-objects

are defined as “not varying” in location or over time. Examples of static geo-

objects are road features, utilities and similar in-situ infrastructure, and historical

cartographic maps and geophysical data such as elevation rasters. Static geo-

objects, though seemingly unchanging in location and attribute values, do

8

experience change over time, just not at a rate experienced by dynamic geo-

objects. Static geo-objects have a basic relationship to time. There was a time

when the static geo-object did not exist, and then a time when the geo-object

came into existence. Dynamic geo-objects can vary spatially and in attribution

through time. Examples of dynamic geo-objects are traffic volumes, urban

expansion and GPS tracking. These geo-objects have an inherent time-

dependent notion and have received most of the attention in temporal GIS

applications. Though the majority of GIS data managed in community

infrastructure is temporally static in nature, the capability to query and display the

GIS data based on time will improve the usefulness of the GIS. The static geo-

objects are the focus of this thesis.

Temporal GIS research seems to have split time into two different camps,

conceptual time and applied time (Freelan 2003). The conceptual temporal

research is based upon time’s integration in the GIS using the object-oriented

database model (Raza 2001). The applied temporal GIS research uses current

relational database models, storing time as an attribute of the geo-object

(Freelan 2003). In the conceptual temporal model, time is the fourth dimension

within a GIS, changing the spatial component of the GIS to a spatio-temporal

component. An (X,Y,Z) spatial location becomes an (X,Y,Z,T) location in space

and time. Not only does a geo-object have a space and attribute filiation (change

history), but a location also has a filiation based on the range of time covered by

the temporal GIS database. The relatively new object-oriented database model

shows promise in being able to store a truly temporal GIS (Barrera, Frank, and

9

Al-Taha 1991). The conceptual model is still moving toward applied practical

application (Raza 2001).

Current relational database storage used in the majority of GIS software

does not support the time-as-dimension concept (Freelan 2003, and Raza 2001).

In the relational database structure, time is included as an attribute or series of

attributes that is queried as any other attribute. The capability to perform a

spatial dimension function such as ‘nearest neighbor’ (where a start location is

defined and searched as if a pebble were dropped in a pond, with the nearest

neighbor found by the expanding ripple) cannot be duplicated using time. When

time is an attribute of the geo-object, all geo-objects must be queried and time

attribute values compared. Freelan (2003) defines the relational database time

model as a ‘quasi-temporal GIS’ model due to the lack of true time integration

within the GIS. This thesis is concerned with the practical application of quasi-

temporal GIS using the current relational database storage schema with time

stored as attributes of the geo-object instead of as an inherent dimension of a

temporal-geo-object.

There are two types of time to consider in a practical application quasi-

temporal GIS: linear time and cyclical time (Worboys 1990). Linear time can be

more easily understood when viewed as if one were viewing a time line. Time

has a past and present, as seen on the time line. Cyclical time can be defined as

repeating-events based time. Seasons of the year, bus schedules, and rain

events are examples of cyclical time. Because the majority of data in a

10

community infrastructure GIS is relatively static and non-cyclical, this thesis is

concerned with the storage and use of linear time within its GIS template.

In previous research (Freelan 2003), there have been four base methods

of quantifying time within a GIS. The “Snapshot” method archives the GIS

database at time intervals or time events. All geo-objects within the GIS are

archived, whether a change occurred to the geo-object or not. This method is

data redundant and storage intensive. Querying, analysis and displaying of the

snapshot model of archived databases can be cumbersome, due to the

exponentially multiplying size of information.

The “Time Cube” method stores a time series (series of snapshots) that

adds the capability of location “‘drill down”’ of stored database layers. The ability

to “drill down” (through time) at a location to get changes is valid but this method

has the same inherent problems of the Snapshot method (the redundant storage

of information).

The “Base State with Amendments” method uses a dated baseline

database. Time-tagged changes that occur to the baseline database are

recorded. A database state for a specified time can be retrieved by applying the

recorded changes to the baseline database until the state of the database at the

queried time is achieved. This method is called “versioning” within the relational

database management system (RDBMS) industry. ESRI has a published paper

(ESRI 2002) that details the use of this method with accompanying scripts to use

within an RDBMS. This method is also cumbersome, requiring reconstruction

from baseline databases to get to the time of interest.

11

The “Space-Time Composite” model stores spatio-temporal topological

geo-objects in one database. No geo-object is ever deleted or removed. When

a geo-object has a change event, the geo-object is superseded by a new geo-

object. Geo-object attributes that are tagged with the time of the change allow

query and display. Though storage is not optimized due to the “supersede-not-

delete” (Kucera, Kucera and Ressler 2006) approach, modern computer

resources and storage should allow handling of small to mid-sized static geo-

object GIS databases. The current non-topological GIS formats, such as

shapefiles and geodatabases, allow the concept of space-time composite model

to function without the overhead of topology management (Freelan 2003).

Langran (1992) concluded that the space-time composite model has greatest

potential for success in current GIS technology environments. This research

takes advantage of the supersede-not-delete concept of the space-time

composite model.

In a quasi-temporal GIS where time is stored in geo-object attributes,

there are three time states to consider: world time, database time, and

institutional time (Lester 1990). World time is defined as the time that the geo-

object or event occurred. Database time is defined as the time the geo-

object/event is recorded in the database. Institutional time is dimensions of time

for an entity that has a relation to the geo-object, such as inception of the plan for

the geo-object, partial completion of the geo-object, and abandonment of the

geo-object (Lester 1990). World time and database time are implemented in the

archival GIS template. Database time is handled in an automated fashion, as

12

explained in Chapter 3. World time, if considered to be different than database

time, must be manually entered into the database.

2.3 Conclusion In summation, this thesis addresses the construction of an archival GIS

template for the archiving of geo-objects. This template will use a quasi-temporal

supersede-not-delete database model to track static geo-objects using database

time and elements of world time using the linear time definition.

13

3 Framework and Methodology

This research addresses the construction of software tools that allow the

creation and implementation of a historic (archival) GIS. The historic GIS is

implemented through the ESRI personal geodatabase storage format and ESRI

ArcMap software environment. The archival GIS tools are collectively called

“tGIS Extension.” As defined by the research literature, the tGIS Extension uses

a quasi-temporal supersede-not-delete database model to track static geo-

objects using database time and elements of world time which uses linear time

definition. There are four components that make up the tGIS Extension:

1. Archival Database Schema – The attributes created to manage

temporal changes were developed from the literature research.

2. Database Implementation – The ideas and concepts of the

“supersede-not-delete” environment were taken from the literature

research. The tools created to implement and manage the

“supersede-not-delete” temporal environment were developed with

ESRIs ArcObject classes. Programming usage examples were taken

from “Developer Sample” tools distributed with ESRI ArcMap software.

3. Database Display - The method to control display of archival GIS data

is within existing capabilities of ESRI’s ArcMap.

14

4. Database Query – ESRI’s ArcObjects classes and Microsoft Visual

Basic 6.0 were used to create a toolbar and tool to query the archived

GIS data within ArcMap.

3.1 Archival Database Schema

The initial idea for the archival geodatabase schema was taken from an

article written by Mr. Al Butler (GeoWorld 2005) and entitled “Metadata

Freedom.” The topic of Butler’s article is that of freeing GIS data managers from

the laborious task of maintaining metadata. Butler asserted that the cost of data

exchange is greater than the cost of data duplication and that the benefit to the

data sharer is minimal. The author proposes maintaining feature level metadata.

An indirect benefit of his idea is, at least partially, temporally enabling the dataset

on the geo-object (feature) level. Butler proposed adding seven attributes to

each GIS layer to allow feature level metadata. These attributes temporally

enable the geo-object. The initial schema proposed by Butler was expanded by

two additional attributes. Some attribute names were modified to better track

geo-objects in a supersede-not-delete environment. The archival attributes,

when combined with the expanded geodatabase functionality of the tGIS

Extension, automatically keep a historical record of the creation, modification,

and retirement of geo-objects.

1. [TemporalID] - This attribute, of type TEXT(20), was defined by Butler as a

way to uniquely track geo-objects by the original public key and

recordDate. The development of this attribute is beyond the scope of this

research but has been left in place for future development. The use of this

15

type attribute is defined (Berman 2003, ESRI, 2002, Crissman and

Berman 2001, and Freelan, 2003) as how the database tracks geo-object

filiation (see discussion below) to implement spatio-temporal tracking of

geo-objects.

2. [recordDate] – This attribute, of type DATE, records the date/time when

the record was created in the database (database time). This attribute is

automatically populated by the tGIS Extension.

3. [Status] – This attribute, of type TEXT(20), records the geo-object’s state

of current existence in world time. The values that are automatically

assigned by the tGIS Extension are: ‘Active’, ‘Retired’ and ‘Deleted’. The

value of ‘Active’ represents that this geo-object currently exists as defined

by the geo-object shape and attributes. The value of ‘Retired’ represents

that this geo-object has been superseded by another geo-object, either by

change in shape or change in attribute value. The value of ‘Deleted’

represents the last state of this geo-object before it was removed from

existence, such as with a building that has finally been demolished. The

[Status] attribute can contain other values such as ‘Planned’, to indicate

future states, or ‘Replaced’, to indicate human error corrections. The only

[Status] values that are populated automatically are ‘Active’, ‘Retired’, and

‘Deleted’. The automated values can be changed for a period of time after

geo-object creation without firing new tGIS Extension recording events.

4. [createdDate] – This attribute, of type DATE, records the date/time

reflecting the beginning of existence of the geo-object. It automatically

16

gets assigned the current date and time by the tGIS Extension (such as

with the [recordDate]). It is recognized that the actual geo-object creation

date may not match the [recordDate]. The automated values can be

changed for a period of time after geo-object creation without firing new

tGIS Extension recording events.

5. [retiredDate] – This attribute, of type DATE, records the date/time

reflecting the end of [Status] =‘Active’ existence of the geo-object. This

attribute automatically gets assigned the current date and time by the tGIS

Extension. It has been recognized that the actual geo-object [Status]

=‘Retired’/’Deleted’ date may not match the [recordDate]. The automated

values can be changed for a period of time after geo-object creation

without firing new tGIS Extension recording events.

6. [createdBy] – This attribute, of type TEXT(30), records the Username of

the logged-in user who is editing the created geo-object and is populated

by the tGIS Extension.

7. [retiredBy] - This attribute, of type TEXT(30), records the Username of the

logged-in user who is editing the geo-object and is populated by the tGIS

Extension.

8. [createdReason] – This attribute, of type TEXT(30), records the type of

edit performed that created the geo-object. This attribute is populated by

the tGIS Extension. The number of GIS functions that can

create/modify/delete geo-objects is quite numerous. Not all GIS functions

have been tested for correct reporting of edit type within the tGIS

17

Extension. The type of edits tested for correct recording are the ‘Edit

Tasks’ and ‘Edit Commands’ found on the ‘Editor Toolbar’. The ‘Edit

Tasks’ are defined as editing events which require the use of an edit

sketch. The edit sketch is an object into which a feature is copied while

editing is performed. The sketch object is then submitted back into the

feature when editing is complete. The editing tasks are in four groups:

a. Create Tasks

i. Create New Feature

b. Modify Tasks

i. Reshape Feature

ii. Cut Polygon Feature

iii. Mirror Features

iv. Extend/Trim Features

v. Modify Feature

vi. Calibrate Route Feature

vii. Modify Portion of a Line

c. Topology Tasks

i. Modify Edge

ii. Reshape Edge

iii. Auto-Complete Polygon

d. Other Tasks

i. Create two-point Line Features

18

Edit commands are defined as events that work on a selected set of

features. The edit commands accessed from the Editor Toolbar are:

a. Move…

b. Split…

c. Divide…

d. Buffer…

e. Copy Parallel…

f. Merge…

g. Union…

h. Intersect…

i. Clip…

The [createdReason] values can be changed for a period of time after

geo-object creation without triggering new tGIS Extension recording

events.

9. [retiredReason] - This attribute of type TEXT(30), records the type of edit

performed that ‘Retired/Deleted’ the geo-object. This attribute is

populated by the tGIS Extension. The number of GIS functions that can

create/modify/delete geo-objects is quite numerous. Not all GIS functions

have been tested for correct reporting of edit type. The type of edits

tested for correct recording are the ‘Edit Tasks’ and ‘Edit Commands’

found on the ‘Editor Toolbar’. The [retiredReason] values can be changed

for a period of time after geo-object creation without triggering new tGIS

Extension recording events.

19

The database schema establishes attributes to record archival information

of geo-objects within a GIS. A method to track the lineage of the geo-objects has

not been established (Freelan 2003). An example of this would be the merging

of polygons to form one polygon. The polygons merged would be ‘Retired’ with

the date ([retiredDate]), who merged the polygons ([retiredBy]), and the type of

edit used for the merge ([retiredReason]), but the polygon into which they were

merged is not recorded for each ‘Retired’ polygon. The newly created polygon

(results of said merge) has the recorded date ([createdDate]), the type of edit

used for the merge ([createdReason]), and who merged the polygons

([createBy]), but the source polygons for the merge are not recorded. This

lineage is lost. Note that the polygons ‘Retired’ have a one-to-one relationship

with the resultant new polygon. This one-to-one change could be captured in a

field that then could be used for lineage tracking. The resultant new polygon has

a one-to-many relationship with the ‘Retired’ polygons. The problem not

addressed in this research is how to capture this one-to-many relationship in the

database schema.

Though not complete in its coverage of all temporal facets of geo-objects, the

database schema allows recording of geo-object state, when the state change

occurred, for what reason the change occurred and who made the change. The

above process, combined with the archiving of the geo-object, allows a history of

the geo-object to be maintained.

20

3.2 Database Implementation

To implement an archival method of storing changed and deleted geo-

objects within the personal geodatabase, the functionality of how the personal

geodatabase handles changes to geo-objects has been modified. The

maturation of the GIS data storage (personal geodatabase), specifically the

ability to extend the personal geodatabase functionality, allowed the capability to

create a supersede-not-delete geo-object environment along with automatic

attribute value updating. The tool developed to extend the personal

geodatabase functionality is the ‘tGIS Extension’. This class extension is a

dynamic linked library (DLL), which is referenced within the personal

geodatabase structure, thus tying archival management to the data.

The geodatabase is a Microsoft Access file made up of tables that define

the personal geodatabase. In the GDB_ObjectClasses table within the personal

geodatabase, each feature class is listed as a record. One of the fields in this

table is called [EXTCLSID] (Extension Class ID). This field can contain a

reference to a DLL that extends the functionality of the personal geodatabase

feature class. The extended functionality of the tGIS Extension DLL adds

archival management to the geo-object through feature editing events of

OnCreate, OnChange and OnDelete.

The tGIS Extension implements five classes to support archival

management of geo-objects within a feature class.

21

1. tGIS_OCDescription – Implements the ArcObjects

IObjectClassDescription interface to provide information to ArcCatalog

which allows the creation of custom objects. This adds selection

capability of a new custom object type within the ‘New Table’ creation

process.

2. tGIS_FCDescription – Implements the ArcObjects

IObjectClassDescription interface and the IFeatureClassDescription

interface (provides information to ArcCatalog which allows creation of

custom objects.) This adds selection capability of a new custom

feature class object type within the ‘New Feature Class’ creation

process. This class allows creation of a feature class that is

implemented with the archival attributes and supersede-not-delete

processing of the feature class’s geo-objects. This class supports the

ArcCatalog process of creating a new feature class.

3. tGIS_PropPage – Implements the ArcObjects IComPropertyPage

interface to provide ArcCatalog the ability to change the defined

archival attributes of an existing feature class.

4. tGIS_myFilter – Implements the ArcObjects ICustomizationFilter

interface to provide the ability to capture ArcMaps ‘Editor Toolbar’

editing commands for use in the archiving of [createdReason] and

[retiredReason] attributes.

5. tGIS_ClassExtension – This class is the workhorse of the tGIS

Extension. This class implements the ArcObjects IClassExtension

22

interface which is triggered and initializes the tGIS attributes for use

when the geodatabase feature class is loaded into ArcMap. This class

implements the IObjectClassExtension interface which allows the

geodatabase extension to acquire the ArcMap editing session and

retrieve archival attributes from a geo-object within the feature class.

This class implements the ArcObjects IObjectClassInfo2 interface

which allows geodatabase feature class edits to make edits (such as

attribute edits) outside of an ArcMap edit session. This class

implements the custom ItGIS_ClassExtension interface which allows

an interface to the archival attributes. This class implements the

ArcObjects IObjectClassEvents interface which allows the capture of

edits to the geodatabase feature class. The events implemented

within the interface are OnCreate, OnChange and OnDelete. These

events are used by the tGIS Extension to manage the archival

supersede-not-delete environment.

A GIS user who wishes to create a historic GIS installs the tGIS Extension

by registering the tGIS_PGDB.DLL on their computer. The GIS user then runs

the tGIS_PGDB.REG registration script to register the classes contained in the

tGIS_PGDB.DLL in their respective ArcGIS component categories. The GIS

user then can start ArcCatalog and create a new feature class. During the

feature class creation process, if the GIS user wishes to use the custom object

‘temporal Feature Class’, he/she can choose to do so. The feature class created

23

will contain the archival attributes and the functionality to manage supersede-not-

delete geo-objects. When the new feature class is loaded into ArcMap, the tGIS

Extension will be activated. Any edits done to the feature class will trigger the

editing events within the tGIS Extension.

As stated above, the tGIS Extension implements the ArcObjects

IObjectClassEvents interface. This class captures three types of editing events

(OnCreate, OnChange and OnDelete), passing the geo-object that has been

edited to the event. Within each event the author has added computer code to

create the supersede-not-delete geo-object environment. An initial problem in

the use of the IObjectClassEvents interface was that the geo-object passed to

the three events was the geo-object after it had been edited. For archival

purposes, the geo-object state before edits was needed.

In managing an archival GIS we are concerned with the pre-edit state of

the geo-object in order to archive that state. Two ArcObject classes allow us to

retrieve the state of the geo-object before the edit occurred. The IRowChanges

interface allows us to capture attribute changes to a geo-object. The

IFeatureChanges interface allows us to capture shape changes to a geo-object.

Without these two interfaces the archival GIS would not have been possible

within the Geodatabase Object Class.

The following text discusses the three editing events (OnDelete, OnChange

and OnCreate) where programming code has been added to support a

‘supersede-not-delete’ archival GIS.

24

1. OnDelete (see code Appendix A) – This event is triggered when an

existing geo-object has been marked for removal from the feature class.

The geo-object marked for deletion is passed to the OnDelete subroutine.

Since we are operating in a supersede-not-delete environment, the geo-

object to be deleted is copied into a new geo-object. The geo-object

marked for deletion is deleted. The copied geo-object’s [Status] attribute

value is set to ‘Deleted’. The copied geo-object is added back into the

feature class. This triggers the OnCreate event. The OnCreate event is

passed the copied geo-object. The [Status] attribute value is checked on

each geo-object passed to the OnCreate event. If the [Status] attribute

value is ‘Deleted’ then the archival attributes are set as follows:

[recordDate] = current date and time

[retiredDate] = current date and time

[retiredBy] = UserName

[retiredReason] = Captured edit type from Editor Toolbar

The delete edit is now complete with an archived geo-object in the feature

class.

2. OnCreate (see code Appendix A) – This event is triggered when a geo-

object is added to the feature class. As demonstrated when the OnDelete

event triggers the OnCreate event, the OnCreate event does not

necessarily mean a brand new geo-object, but can mean the archiving of

a ‘Retired’ or ‘Deleted’ geo-object. When the OnCreate event is

25

triggered, the geo-object that is being added to the feature class is passed

to the OnCreate event. The [Status] attribute value is then checked to see

if this new geo-object is being created from an OnDelete event ([Status] =

‘Deleted’) or an OnChange event ([Status] = ‘Retired’) or if it is actually a

brand new geo-object ([Status] = ‘’). If the geo-object is coming from the

OnDelete event, then the changes are as indicated in the OnDelete event.

If the geo-object is coming from an OnChange event, the attribute

changes are handled by the OnChange event, and the OnCreate event

adds the geo-object back into the feature class for archiving. If this is a

brand new geo-object then the archival attributes are set as follows:

[recordDate] = current date and time

[Status] = ‘Active’

[createdDate] = current date and time

[createdBy] = UserName

[createdReason] = Captured edit type from Editor Toolbar

The create edit is now complete with a new geo-object added to the

feature class.

3. OnChange (see code Appendix A) – This event is triggered either by an

attribute value change or a shape change of an existing geo-object.

A. Geometric Change

If the change is a shape change, then the original shape before the

change can be captured from the IFeatureChanges interface. A new geo-

26

object is created and assigned the original shape and attributes of the

changed geo-object. The new geo-object is the geo-object to be archived.

Its archival attributes are set as follows:

[Status] = ‘Retired’

[retiredDate] = current date and time

[retiredReason] = Captured edit type from Editor Toolbar

[retiredBy] = UserName

The new geo-object for archiving is then added to the feature class. This

triggers the OnCreate event, which recognizes the [Status] attribute value

of ‘Retired.’

The archived geo-object is passed to the feature class.

The geo-object with the changed shape has its archival attributes set to:

[recordDate] = current date and time

[Status] = ‘Active’

[createdDate] = current date and time

[createdBy] = UserName

[createdReason] = Captured edit type from Editor Toolbar

[retiredBy] = ‘’

[retiredReason] = ‘’

27

The ‘shape change’ edit is now complete with an archived geo-object in

the feature class.

B. Attribute Value Change

If the change is an attribute value change, then the original attribute

value can be retrieved form the IRowChanges interface. A new geo-

object is created and assigned the shape and attribute values before the

attribute value change. The new geo-object is the geo-object to be

archived. Its archival attributes are set as follows:

[Status] = ‘Retired’

[retiredDate] = current date and time

[retiredReason] = Name of attribute that had value change

[retiredBy] = UserName

The new geo-object for archiving is then added to the feature class. This

triggers the OnCreate event, which recognizes the [Status] attribute value

of ‘Retired.’

The geo-object with the changed attribute has its archival attributes set to:

[recordDate] = current date and time

[Status] = ‘Active’

[createdDate] = current date and time

[createdBy] = UserName

[createdReason] = Name of attribute that had value change

28

[retiredBy] = ‘’

[retiredReason] = ‘’

The ‘attribute change’ edit is now complete with an archived geo-object in

the feature class.

Once implemented, the tGIS Extension records change by archiving any

geo-object that experiences a change. The complexity of the real world will force

some edits to be made outside of the tGIS Extension (automatic archival

recording). An example might be a mistyped attribute value assigned to many

geo-objects at the time of their creation. The necessity to archive the correction

to the many geo-objects may not be relevant to the GIS. With the tGIS

Extension implemented, there is no way to correct the attribute value without

duplicating the geo-objects of concern. Documentation accompanying the tGIS

Extension addresses how to disable the tGIS Extension when necessary.

3.3 Database Display

The purpose of a historic GIS is to archive the geo-object changes to the

GIS so that instances in time of the GIS can be revisited at a later date.

However, the majority of GIS usage is viewing and/or analyzing real-time GIS

‘Active’ geo-objects. Archived geo-objects should only be evident to GIS users

and data managers when the objects are queried. The capability to keep

archived geo-objects hidden and a method to query the archived geo-objects is

needed.

29

From a data manager’s perspective, the rendering of GIS datasets to ease

the effort expended by GIS users is desirable. In the ArcMap environment, an

ArcMap data layer (.lyr) file is a way to store the rendering of a GIS data layer in

a separate location other than with or in the actual GIS data. The ability to do

this allows the data manager to control the loading of the GIS layer by the GIS

user. ArcMap data layers are utilized to allow loading of the archival GIS layers

without having to view or work with the archived geo-objects within the feature

class.

One of the properties of an ArcMap layer is its ‘Definition Query’. In a

definition query, the data user identifies specific features within a feature class to

display. The definition query uses Structured Query Language (SQL) type

queries made on the attributes of the data layer to define feature class geo-

objects of interest. The defined data definition is saved when the layer file is

saved. The layer file for each feature class within a geodatabase can be stored

in a location separate from the location of the personal geodatabase, as

mentioned above. This allows the control of the feature class geo-object’s

display and of the table record content of the archival data layers. The initial

definition query of a GIS data layer can be defined as [Status] = ‘Active’. When

the archival data layer is loaded into ArcMap, the only visible geo-objects

recognized in the map view and the table view are the geo-objects that meet the

query definition. This method keeps archived geo-objects transparent to the GIS

users and the GIS manager.

30

3.4 Database Query

Though most of GIS usage satisfies the need for viewing and/or analyzing

real-time GIS ‘Active’ geo-objects, the point of having a historic GIS is to permit

query of archived geo-objects when historical answers or displays are needed.

The capability to query, in a user-friendly manner, the archived geo-objects

needs development. Temporal controls could control the date and state of geo-

objects that are displayed within an ArcMap session or they could control a

specific set of geo-objects within one feature class layer. The author developed

a toolbar using Microsoft’s Visual Basic 6 and ESRI’s ArcObjects to support

temporal GIS tools. One tool, the ‘Set Date’ tool, has been developed and

placed on this toolbar. The tool is designed to accept a date in a text box. The

date is then applied to all archival feature layers in the active DataFrame Table of

Contents. The date is applied by establishing a new query definition for the

archival feature layer ([createdDate] < #date# AND [retiredDate] IS null OR

[retiredDate] >#date#). For example, if the user typed into the ‘Set Date’ tool

textbox the date of ‘July 1, 2004’, the query definition retrieves geo-objects that

were created before July 1, 2004, and that have a retired date later than July 1,

2004. The geo-objects retrieved could be currently active or they could have

been retired or deleted after July 1, 2004. The date applied to the archival

feature layer is appended to the feature layer name so a constant reminder is

visible that a geo-object archival request has been made and that the results are

displayed in the feature layer. Clearing the date text box will re-set the definition

query for each archival feature layer back to viewing the non-archived ([Status] =

31

‘Active’) geo-objects. In the execution of the ‘Set Date’ tool, each feature class

layer in the data frame is queried to establish whether the tGIS Extension is

enabled. If the tGIS Extension is enabled, the attributes being used for the

created date and retired date are retrieved and used in the date query. This

maintains the flexibility of archival attribute names established within the tGIS

Extension controls in ArcCatalog.

3.5 Fort Campbell GIS Datasets and the tGIS Extensi on

GIS and digital spatial data have been available on Fort Campbell Army

Base for several years now. The Fort Campbell Army Base Public Works

Engineering Division maintains the datasets used to test the tGIS Extension.

Fort Campbell Army Base is located on the Kentucky-Tennessee border in

Montgomery and Stewart counties in Tennessee and in Trig and Christian

counties in Kentucky. The two largest bordering towns are Clarksville,

Tennessee and Hopkinsville, Kentucky (Figure 1).

Figure 1: Location: Fort Campbell Army Base

Montgomery County, TN

Stewart County, TN

Trigg County, KY Christian County, KY

���I-24

���I-24

���I-24

tu79

tu41-A

tu79

tu41-A

tu79

tu79

tu41-A

��374��120

��49

��345

��107

Hopkinsville City Limit

Clarksville City Limits

Fort Campbell Army Base

State Line

32

Fort Campbell Army Base (training and cantonment areas) is 164 square

miles in size. The cantonment (non-training area), which is the working

community part of the installation, is 21.5 square miles (Figure 2).

Figure 2: Training Area and Cantonment Area

The cantonment area is a city within the Army Base, with approximately

28,000 soldiers stationed at the installation. There are more than 4000 homes

within the cantonment area, providing housing for officers, enlisted soldiers, and

their families. The garrison supports seven schools, a major hospital, childcare

facilities, numerous chapels, two banks, restaurants, post exchanges, service

stations, campgrounds, five swimming pools, and most other facilities that a

civilian city of that size would possess (U.S. Army Corps of Engineers 2006).

The cantonment area contains ~3100 buildings and ~170 miles of roads, with

associated utilities and infrastructure, to support a community of ~35,000 people.

Training Area

Fort Campbell Army Base

Cantonment Area

FR1901

FR2001

FR5101

FR

320

1

FR4401

FR

200

2

FR1702

East Colson Road

FR

110 1

FR

3 10 1

FR

230

1 FR

1 00

1

Parkertown Road

FR

170

1

State Line

CENTERLINE ROAD

DESTINY TRAIL

SUKCHON ROAD

MC

NA

IR R

OA

D

HELL CAT TRAILPHAN RANG

PATTON ROAD

KIL

LEB

RE

W R

OA

D

ANGELS ROAD

ROSE HILL ROAD

PERIMETER ROAD

MABRY ROAD MABRY ROAD

PA

TT

ON

RO

AD

33

Two infrastructure datasets were selected for archival tracking activation.

These datasets are a polygon feature class representing buildings and a polyline

feature class representing the centerline road network. Both datasets, which are

stored in personal geodatabases, are in the Tennessee State Plane Coordinate

System, NAD83, with units of Survey Feet.

One of these personal geodatabases is the Buildings.mdb personal

geodatabase maintained by Fort Campbell Public Works. The feature class of

interest is called Bldgs_Existing and contains ~3100 polygon features. Each

polygon feature represents a building’s footprint. About 15 different attributes are

defined for this feature class. The GIS manager spatially updates this feature

class as buildings are constructed, changed and demolished. The attributes of

this feature class also change based on the building’s tenant and its use. This

information is tracked by a different database but is synchronized to the

Bldgs_Existing feature class. The spatial and attribute changes of this feature

class are now managed by the archival GIS implementation. In the baseline

implementation of this feature class, an existing field [Year_Built] was used to

populate the [createdDate] attribute. Also, the [Status] attribute was set to

‘Active’ for all geo-objects in this feature class. Another feature class within the

Buildings geodatabase, Bldgs_Demolished, has been appended back into the

Bldgs_Existing feature class with its [dateDemolished] attribute transferred to the

[retiredDate] attribute and its [Status] attribute values set to ‘Deleted’. The

Bldgs_Existing feature class and Bldgs_Demolished feature class are now one

feature class called “Buildings.”

34

The second personal geodatabase featuring archival implementation is

the Roads.mdb personal geodatabase. The feature class of interest is the

FTC_Rds_Centerline. This feature class contains ~1500 polylines representing

~251 roads. Maintained in this feature class are six attributes. The GIS manager

maintains both the spatial component and attribute changes of this feature class.

There is also another feature class in Roads.mdb

(Deleted_FTC_Rds_Centerlines) which will be used to construct a baseline

temporal implementation as described for the Buildings feature class above.

For both feature classes, edits have been performed and tracked to test the

usability of the tGIS Extension.

35

4 Results and Discussion

4.1 Database Schema Attributes

The database schema is made up of nine attributes for tracking geo-object

changes within a feature class (Figure 3). The attribute schema archives the

who, what, and when of geo-object changes. The [TemporalID] attribute was not

utilized in this archival implementation but allows for the expansion of this

research from an archival GIS to a spatio-temporal GIS (Butler 2005).

Figure 3: Nine Attributes that Make Up the Databas e Schema

4.2 Analysis of Implementation

Below are a series of figures that describe basic GIS edits and what the

results look like in a supersede-not-delete feature class. The feature class

rendering of the [Status] attribute shows the archive state of the geo-object. The

changes to the archival attributes resulting from edits are also shown.

When a new feature has been created in the archive activated feature

class (Figure 4), it is rendered green to reflect a status of ‘Active’. The archival

36

attributes are automatically populated with information pulled from the operating

system (date/time, UserName) and the ArcMap Edit session (‘Create New

Feature’).

Figure 4: Geo-object has been Created

When a feature has been deleted in the archive activated feature class

(Figure 5), it is not removed but marked as deleted ([Status] =’Deleted’). This is

where the supersede-not-delete of information is achieved. The archival

attributes are automatically updated to reflect the archiving, and the feature is

rendered red to show its ‘Deleted’ status.

Create New

37

Figure 5: Geo-object has been Deleted

When a feature has been moved, a new feature is created to archive the

old location (Figure 6). The new feature is shaded orange to denote a Status of

‘Retired’. The archival attributes are updated to reflect the change.

Delete

38

Figure 6: Geo-object has been Moved

When a feature shape has been modified (Figure 7), the original geo-

object (attributes and shape) is archived (orange shading) and the modified

shape becomes ‘Active’. Editor commands such as ‘Modify Feature’ are applied

using the sketch environment (an environment where the geo-object is loaded

into a sketch object, modified and then saved back to the geo-object). The edit

OnChange event is not triggered until the sketch is saved. At this point the

original geo-object (attributes and shape) is archived (orange shading) and the

Move

39

modified shape becomes ‘Active’. The archival attributes are automatically

updated accordingly.

Figure 7: Geo-object’s shape has been Modified

Whereas the ‘Modify Shape’ editing task allows you to select a geo-object

(copying the feature into a sketch object) and then to modify its vertices to

change its shape, the ‘ReShape’ editing task allows you to draw a sketch object

that changes the shape of the selected geo-object where intersections between

the sketch and the geo-object occur. When the ‘Reshape’ edit task is performed

Modify Shape

40

(Figure 8), the original geo-object (attributes and shape) is archived (orange

shading) and the modified shape becomes ‘Active’. The archival attributes are

automatically updated accordingly. Note that the history is building with this geo-

object. There are now 3 geo-objects representing different states of existence.

Figure 8: Geo-object has been Reshaped

When a feature polygon has been split using ‘Cut Polygon Feature’

(Figure 9), there are three resultant polygons. The original polygon is archived

Re-Shape

41

and two new polygons are created. The archival attributes are recorded to reflect

the event that created and deleted these geo-objects.

Figure 9: Geo-object has been Split into Two Geo-ob jects

The ‘Auto-Complete Polygon’ operation allows the creation of a new

polygon that is adjacent to existing polygons. In the drawing of the sketch,

adjacent polygon boundaries are used to ‘auto-complete’ the polygon being

created. Note the archiving of the [createdReason] attribute of the ‘Auto-

Complete Polygon’ method (Figure 10).

Cut Polygon

42

Figure 10: Geo-object has been Created by Auto-Comp lete Polygon

The editor toolbar commands are on the ‘Editor’ drop down menu. Of the

nine editor toolbar commands only the ‘Merge.…’ command will be

demonstrated. The merge command works by joining two or more features

together. One feature is chosen as the ‘target‘ feature, into which the other

selected ‘source’ features will be merged. In Figure 11, two features are merged.

The result is one feature marked as deleted; the other marked as retired. Instead

of having the ‘target’ feature as the result of the merge, the supersede-not-delete

environment of the archival feature class creates a new feature instead.

Auto-Complete

43

Figure 11: Two Geo-objects have been Merged into On e Geo-object

Begin Merge

End Merge

44

From the above examples, we are assured that the basic logic and

archiving of geo-objects is taking place within the archive enabled feature class.

The three IObjectClassEvents (OnDelete, OnChange, and OnCreate) and the

programming logic within these events are managing the ‘supersede-not-delete’

enabled feature class. The archiving functionality is attached to the data through

the geodatabase construct and is not dependent on the ArcMap Editing

environment. This means that a series of different datasets can be loaded into

ArcMap and then edited. The archiving functionality will not be accessed unless

a feature class referencing the tGIS Extension is edited.

Implementing an archival feature class within the scope of the

IObjectClassEvents interface, though functional, is not as elegant as it could be.

Within each event, geo-objects are being recycled back into the feature class.

Viewing the feature class tables shows that the archived geo-objects are the new

geo-objects in the feature class (at the bottom of the table). The geo-object

archival process is being implemented “after the fact” of the edits instead of being

an integral part of the editing process. In the OnDelete event, the preferred

solution would be that the deleted object is filed away for future reference.

However, within the OnDelete event the deleted geo-object is copied to another

geo-object and added back into the feature class. The overhead of this extra

processing amounts to increased resource load on the computer and more wait

time for the operator. As in the OnDelete event, the OnCreate and OnChange

events are operating by retrieving edited information and loading it back into the

feature class.

45

The above methods are a ‘quasi-archival’ GIS. A truly archival GIS would

handle the archiving of geo-objects within the initial edit event. This author can

imagine a different storage structure for a historic GIS where there are three

feature tables representing a feature class in a storage unit, instead of one

personal geodatabase feature table representing the feature class. One feature

table tracks the [Status] = ‘Active’ features, another feature table tracks [Status] =

‘Retired’ features and the other feature table tracks [Status] = ‘Deleted’ features.

Since date fields are an inherent part of this structure, when a date type query is

made, the retired and deleted feature tables would automatically be called upon.

The rest of the time, these tables would sit seemingly dormant, but always

collecting and storing archived information.

While developing the tGIS extension to operate on the geodatabase, it

became apparent that there was at least one other ArcObject class where

archival methods could be implemented. This was in the IEditor and

IEditorEvents class. The IEditorEvents class supports onDelete, OnCreate,

OnChange and OnSelection events. Within the Edit environment we could also

create archival functionality that would manage the geo-objects. A limitation of

the IEditor class is that changes made outside of an edit session would not be

archived (as in a global attribute edit). The IObjectClass does allow archiving of

changes outside of an edit session. A hybrid solution using both classes may

lead to the most elegant solution. In the current tGIS Extension, the Editor

session (IEditor) is called upon to record [createdReason] and [retiredReason]

attribute values but the IEditor Events are not utilized.

46

As mentioned earlier in this thesis, geo-object filiation is not tracked in the

current tGIS Extension. In its current form, the tGIS Extension tracks the history

of the feature class and edits performed in the feature class. This partially

captures the geo-object history. To fully track the history of a geo-object, we

would need to track the lineage of that geo-object. As in the merge process

discussed, a geo-object could have many parents. What were the parent geo-

objects that the geo-object has superseded? Also, we are not capturing the

children of a geo-object in our current implementation. If a multi-part geo-object

is exploded into its non-contiguous elements, what are the child geo-objects that

were created from the geo-object?

4.3 Analysis of Display

As stated earlier, the display of archived geo-objects is the exception, not

the rule, in GIS use. A way to prevent the display of archived geo-objects when

not wanted by the user is needed. The tools to control archived geo-object

display are built into ArcMap functionality. ArcMap allows creation of a layer (.lyr)

file. The layer file points to a GIS dataset or series of GIS datasets. The layer

file also records how each GIS dataset will be rendered on the map. Within the

layer file the definition query property is used to control what geo-objects within

the feature class are displayed. We use the temporal attribute, [Status] =

‘Active’, to display only current geo-objects within the feature class. A GIS

manager usually allows access to GIS data for GIS users through a hierarchical

structure. If within this structure the GIS manager places the layer (.lyr) files, not

the actual GIS datasets, he can control the loading of the archival GIS datasets

47

so that on the initial load of the data only the ‘Active’ geo-objects are visible to

the GIS user. Storing the layer files in the defined hierarchical structure and the

actual datasets in a separate location allows the GIS manager to control access

to the archival data by the GIS users. Figures 12 and 13 illustrate that the layer

files are stored in a different location than that of the personal geodatabase. This

is shown by the different folder names for the location of these files.

Figure 12: Layer Files Used to Access GIS Data

48

Figure 13: Geodatabase Stored at Separate Location to Control Rendering

The display of the feature class using this method along with a rendering

of the [Status] attribute is shown below using the Fort Campbell Buildings and

Streets feature classes. The two feature classes have been geo-object archive

enabled with the tGIS Extension.

When the archival feature classes are loaded using a layer file with the

definition query set to [Status] = ‘Active’, the presentation of the GIS data shows

only ‘Active’ geo-objects (Figure 14).

49

Figure 14: User Display of Archival Data Controlled by Layer File

If the archival feature classes are loaded from a separate set of layer files

that display the archived geo-objects, the display of geo-objects will be different

(Figure 15). Note that the layer files point to the exact same feature classes in

Figure 14 and Figure 15. In Figure 14 the display of geo-objects is controlled by

the definition query ([Status] = ‘Active’). The geo-objects are rendered by road

type and building use. In Figure 15, all geo-objects for each feature class are

displayed (the definition query is blank). The feature class geo-objects are

50

rendered over the [Status] attribute so that the reader may see what is not

displayed when the definition query is set to [Status] = ‘Active’, as in Figure 14.

Figure 15: Display showing Archived Geo-objects

The management of the display, or non-display, of archival data is easily

managed within ArcMap functionality using ArcMap layer files to control data

access as demonstrated above.

51

4.4 Analysis of Query

The statement earlier on archival display applies to temporal query. In

everyday use of a GIS, the temporal query is an exceptional practice, not the

rule. A method to perform temporal queries has been developed by the author.

A toolbar called the ‘temporal GIS Toolbar’ has been established within the

ArcMap environment. Tools implemented with the tGIS Extension that allow

temporal querying of geo-objects can be placed on this toolbar. One tool has

been developed for this toolbar. The tool consists of a text box in which a date

may be entered (Figure 16). When a date is entered, the ArcMap Table of

Contents is then reviewed for any feature layers that have the tGIS Extension

implemented. If an archival layer is found, the date is applied to the feature layer

by defining a query definition on that layer which displays geo-objects that were

‘Active’ during the date entered. The date is appended to each archival feature

layer’s name to indicate that a date query has been made. Clearing the date tool

text box will reset all archival feature layers to show current ‘Active’ geo-objects.

Figure 16: Temporal GIS Toolbar and Query Tool

Shown below is a progression from ‘Active’ geo-objects (Figure 17) to the

results of a Date query made with the Date tool (Figure 18).

52

Figure 17: Archival Layers are showing the ‘Active’ Geo-Ob jects

In Figure 17, the ‘Date of Display:’ is blank. This indicates that all archival

layers are displaying the current “Active” geo-objects.

In Figure 18 the ‘Date of Display’ is set to October 10, 1961. The archival

layers display the geo-objects in existence for that date. Also, each archival

layer has this date appended to its layer name.

53

Figure 18: Display with Definition Query set to Dat e

The application of the query tool is straightforward, and the results and

management are easy to see and understand. The tool only works on archival

feature layers and leaves the others alone. If there are no archival feature

layers, the tool does not change the display environment. The ability to work with

an individual layer is left available, and the syntax of the definition query is within

the feature layer to allow easy modification. For example, assume that we want

to compare the same archival feature dataset on different dates. We can load

the same feature dataset into our ArcMap session multiple times. The ‘Set Date’

54

tool could be used to set the initial date of our data layers. Then each feature

layer’s properties could by accessed to modify the query definition. The proper

syntax for the definition query has been established by the ‘Set Date’ tool and all

we have to do is change the date to that date which is desired. By clearing the

text box we can reset all the archival data layers to the active geo-objects.

Like any GIS tool, the ‘Set Date’ tool can also cause some trouble. If you

have predefined query definitions on an archival feature layer, this tool, if used,

will change that query definition to the date used in the tool. This event could

cause inadvertent changes to the information the user wishes to be presented.

55

4.5 Summary

Four areas of development were defined to create an archival GIS

template. The database schema was developed from the literature review. The

database implementation was developed from Microsoft Visual Basic and ESRI

ArcObjects utilizing enhancements to the functionality of the personal

geodatabase. The temporal data display was organized from existing ESRI

ArcMap functionality. Temporal query capability was developed from the

extensibility of the ArcMap environment using Microsoft Visual Basic and ESRI

ArcObjects. The implementation of the supersede-not-delete data management

environment was the crux of the successful implementation. The maturation of

the personal geodatabase storage and the ArcObjects tools (which extend the

functionality of the personal geodatabase) allowed this environment to be

created. The maturation of the ArcMap display and query environment permitted

the rest of the archival implementation to proceed.

Traditionally, one of the important issues within temporal GIS research is

storage space when trying to keep track of the time dimension (Freeman 2003,

Raza 2001, Langran 1992, Halls and Miller 1996). The supersede-not-delete

method of geo-object management, which essentially records time by change

events, is one of the economic storage methods. A method was developed to

determine the effect of the supersede-not-delete geo-object implementation on

the Fort Campbell buildings feature class. The editing functions covered above

have been put in table form and the effects of the geo-object archiving have been

56

quantified (Table 1). An average number of edits per month on the buildings

feature class was determined by author experience.

Table 1: Effect on Geo-object Archiving on Building s Feature Class

Edit Type Non-Archival Feature Class Number of features created

Archival Feature Class Number of features created

Buildings Feature Class Number of edits per month

Features added non-archival Feature Class

Features added archival Feature Class

Create feature +1 +1 4 +4 +4 Delete feature -1 0 3 -3 0 Move feature 0 +1 3 0 +3 Modify feature 0 +1 3 0 +3 Reshape feature

0 +1 3 0 +3

Split feature 1 +2 1 +1 +2 Auto-Complete 1 +1 2 +2 +2 Change Attribute Value

0 +1 10 0 +10

Merge -(n*-1) +(n+1) 0 0 0 Total +4 +27

* n = number of features being merged.

From observing the number of features added monthly to the buildings

feature class in the non-archival and archival methods, it can be determined that

there is almost a 7 fold increase in the number of geo-objects stored per month.

To calculate estimated increase in storage, a new geodatabase was created.

The file size of the geodatabase was recorded from the operating system as 484

kilobytes. The archival buildings feature class was then copied into the new

geodatabase. The file size of the geodatabase increased to 3,132 kilobytes.

The buildings feature class contains 3,847 records. Subtracting the initial size of

the empty geodatabase from the size of the geodatabase containing the

buildings feature class and observing the size of the buildings feature class

versus the number of records, it was determined that 1 building geo-object is

equivalent to 0.89 kilobytes of storage within the geodatabase. Taking into

57

account the 27 new geo-objects per month and the 0.89 kilobyte record size, the

increase in storage for the archival feature class for one month would be 24.03

kilobytes. The storage increase for one year would be 288.36 kilobytes. The

current size of the geodatabase is 3,132 kilobytes. At the increased rate of

feature creation due to the supersede-not-delete method it would take 252,868 /

288.36 = 876.9 years to reach the practical limit (250MB) of the personal

geodatabase. Though this analysis is not complete in scope, the increase in

storage indicated is acceptable for the buildings feature class.

58

5 Conclusion

The premise of this thesis was that the maturation of GIS software, GIS

databases and computer operating systems would allow the development of an

archival GIS template to create and manage a historic GIS. The research

objective for this thesis is to develop a generic temporal template for geo-objects

using available commercial GIS software and apply it to facility management for

Fort Campbell Army Base. The objective as defined by the literature review was

to develop a quasi-temporal supersede-not-delete database model to track static

geo-objects using database time and elements of world time using the linear time

definition.

As defined by Freelan (2003), a quasi-archival GIS was developed. Time

is tracked as an attribute instead of a dimension. This concept is implemented in

the archival database schema. The archival GIS database model uses the

“supersede-not-delete” (Kucera, Kucera and Ressler 2006) concept of archiving

all changes of geo-objects. This concept is implemented within the personal

geodatabase by extending the database functionality through the

IObjectClassEvents interface.

The created archival GIS template is meant for small to medium sized GIS

which manage relatively static geo-objects. This constraint is due to the

limitations of the storage medium (personal geodatabase). The concepts of

database time and world time are handled within the database schema and the

59

database implementation. Database time is easily pulled from the computer’s

operating system and stored in an attribute defined in the database schema.

World time is most easily handled when it can be considered the same as

database time. If not, world time requires a manual edit to maintain if it is not

pulled in from a different information source, such as a separate database that is

itself maintained by another entity. The linear definition of time means that we

are dealing with a continuous timeline of past and present. This is necessary in

the tracking of static geo-objects and community infrastructure.

The thesis objective has been achieved with some caveats, limitations and

warnings. An easily installed Extension (tGIS) to ESRI’s ArcMap/ArcCatalog

software has been created that extends their functionality. The personal

geodatabase functionality has been extended to manage the archiving of geo-

objects within feature classes. For the archival implementation to work, it

requires a GIS manager who understands and has permissions to register a DLL

file and run a registration file. The GIS manager also needs to understand how

an ESRI layer file works and how to set up a directory structure where the users

reference a layer file instead of accessing the temporal feature class directly.

The GIS manager must also understand some inner workings of the personal

geodatabase MS Access file in order to enable or disable the tGIS functionality

when the need arises. Although the knowledge needed by the GIS manager is

not difficult to acquire, this setup and understanding does keep the archival GIS

template from being totally free of management overhead by the GIS manager.

It is possible to unnecessarily create many superfluous geo-objects if the GIS

60

manager forgets to disable the archival management when first enabling a

feature class with the tGIS Extension or through the making of attribute edits

outside of the ArcMap Editor environment.

Further development of the archival GIS template is needed for it to reach

its potential. The [temporalID], though a part of the database schema, has yet to

be implemented. The establishment of this spatio-temporal attribute to uniquely

identify a geo-object through its life-cycle within the geodatabase would allow the

expansion of the functionality of the archival template into a temporal template.

This would allow the expansion of the ‘temporal GIS Toolbar’. A tool to track the

filiation of a geo-object could then be developed. This would answer the second

temporal question posed in chapter 1: “How has feature ‘Y’ changed through

time?”. The implementation of the [tempporalID] attribute would also allow the

development of a tool to answer question 3: “What was in the space of feature ‘Z’

at time ‘B?’”. The author could see this question being answered in an

interactive manner. A polygon shape could be drawn on the map, a date entered

and the geo-objects meeting the criteria of the spatio-temporal query would be

displayed.

Currently the archival GIS template has been applied to buildings and

street centerlines in the Fort Campbell GIS. The usefulness of this archival

template can be applied to utility networks, land use designation, and many other

GIS layers maintained at Fort Campbell. The author plans on exploring its use

and usefulness for more layers within the Fort Campbell GIS.

61

It is also recognized that their can be other ways to implement archival

methods within the ArcGIS environment. The personal geodatabase supports

the creation of class tables to contain information. This capability has not been

utilized in the archival GIS template. Perhaps the creation of a new geo-object

when attribute changes occur can be avoided by using separate tables to track

attributes changes. It may be possible to actualize with ArcGIS ArcObjects the

concept presented earlier, that of having three feature tables to represent Active,

Retired, and Deleted geo-objects within a feature class. The feasibility of this

concept has not been explored. Expanding the current archival attainment to

ArcSDE RDBMS is probably easily achievable but it is outside the scope of this

author’s current GIS tools.

It is hoped that this actualization of an archival GIS template will be seen

as a step forward towards common use of historic GIS.

62

Appendix A: Code implementing ‘Supersede-not-delete ’ Private Sub IObjectClassEvents_OnDelete (ByVal obj As esriGeoDatabase.IObject)

Dim pFClass As IFeatureClass Set pFClass = obj.Class ' Get FeatureClass Dim pTable As ITable Dim pRow As IRow Dim newRow As IRow Dim i As Integer Set pRow = obj 'Get row of deleted geo-object Set pTable = pRow.Table 'Get Table of feature class that geo-object is from Set newRow = pTable.CreateRow 'Create a new row in the table For i = 0 To pRow.Fields.FieldCount - 1 If newRow.Fields.Field(i).Editable Then

If i = m_lStaField Then ' Mark the geo-object as deleted for archive newRow.Value(i) = "Deleted" Else newRow.Value(i) = pRow.Value(i) End If End If Next newRow.Store ' Create new geo-object that is being archived and marked 'Deleted' ‘Triggers OnCreate Event

End Sub

63

Private Sub IObjectClassEvents_OnCreate (ByVal obj As esriGeoDatabase.IObject) ' Set the creation date and user name ' NOTE: there is no need to call IRow::Store Dim Msg As String Msg = "" If CheckInstance Then 'Check to see if in Edit Environment Msg = m_pEditor.CurrentTask.Name ‘Capture Edit Type If Not (m_IApp.CurrentTool.Name = "Editor_SketchTool" Or m_IApp.CurrentTool.Name = "Editor_EditTool") Then Msg = g_Msg End If Dim pFeature As IFeature Set pFeature = obj 'Get Feature from geo-object Dim pFClass As IFeatureClass Set pFClass = pFeature.Class ' Get FeatureClass from feature If m_lStaField > -1 Then If pFeature.Value(m_lStaField) = "Deleted" Then 'Check to see if new geo-object is coming from 'OnDelete' event ' ***** geoObject coming from the OnDelete event: Set temporal Attributes If Msg = "" Then Msg = "Feature Removed" If m_lrecDtField > -1 Then pFeature.Value(m_lrecDtField) = Now If m_lrDtField > -1 Then pFeature.Value(m_lrDtField) = Now If m_lrByField > -1 Then pFeature.Value(m_lrByField) = m_sUsrName If m_lrRnField > -1 Then pFeature.Value(m_lrRnField) = Msg ElseIf pFeature.Value(m_lStaField) = "Retired" Then ' ***** geoObject coming from the OnChange event - Retired: Do nothing Else ' ***** geoObject is a brand new geo-object just Created: set temporal Attributes If Msg = "" Then Msg = "New Feature Created" If m_lrecDtField > -1 Then pFeature.Value(m_lrecDtField) = Now If m_lStaField > -1 Then pFeature.Value(m_lStaField) = "Active" If m_lcDtField > -1 Then pFeature.Value(m_lcDtField) = Now If m_lcByField > -1 Then pFeature.Value(m_lcByField) = m_sUsrName If m_lcRnField > -1 Then pFeature.Value(m_lcRnField) = Msg End If End If ' For Enterprise geodatabases, it is preferable to use the database ' date and username, but for simplicity this sample will just use the ' client OS date and username. End Sub

64

Private Sub IObjectClassEvents_OnChange (ByVal obj As esriGeoDatabase.IObject) Dim Msg As String Msg = "" If CheckInstance Then 'Check to see if in Edit Environment Msg = m_pEditor.CurrentTask.Name If Not (m_IApp.CurrentTool.Name = "Editor_SketchTool" Or m_IApp.CurrentTool.Name = "Editor_EditTool") Then Msg = g_Msg End If Dim pFClass As IFeatureClass Set pFClass = obj.Class ' Get Feature Class from geo-object Dim pRowChanges As IRowChanges Set pRowChanges = obj ' Get Feature attribute-change object Dim pFeatChanges As IFeatureChanges Set pFeatChanges = obj ' Get Feature Shape-change object If pFeatChanges.ShapeChanged And Msg = "Auto-Complete Polygon" Then Exit Sub Dim pTable As ITable Dim pRow As IRow Dim newRow As IRow Dim i As Integer Set pRow = obj ' Get Row of recorded geo-object Set pTable = pRow.Table ' Get feature class Table Set newRow = pTable.CreateRow ' Create new Row in Table ' ***** Check for shape change Dim featBool As Boolean featBool = pFeatChanges.ShapeChanged 'Check to see if shape-change occured If featBool Then ' If shape-changed occured do the following ' ***** Retire Old feature If Msg = "" Then Msg = "[Shape] Changed" For i = 0 To pRow.Fields.FieldCount - 1 If newRow.Fields.Field(i).Editable Then ' Set temporal attributes If newRow.Fields.Field(i).Name = "SHAPE" Then newRow.Value(i) = pFeatChanges.OriginalShape ElseIf i = m_lStaField Then newRow.Value(i) = "Retired" ElseIf i = m_lrDtField Then newRow.Value(i) = Now ElseIf i = m_lrRnField Then newRow.Value(i) = Msg ElseIf i = m_lrByField Then newRow.Value(i) = m_sUsrName Else newRow.Value(i) = pRow.Value(i)

65

End If End If Next newRow.Store ' Commit added geo-object which is archive of original geo-object ' ***** Set Time Attributes on New feature For i = 0 To obj.Fields.FieldCount - 1 If obj.Fields.Field(i).Editable Then ' Set temporal attributes If i = m_lrecDtField Then obj.Value(i) = Now ElseIf i = m_lStaField Then obj.Value(i) = "Active" ElseIf i = m_lcDtField Then obj.Value(i) = Now ElseIf i = m_lcByField Then obj.Value(i) = m_sUsrName ElseIf i = m_lcRnField Then obj.Value(i) = Msg ElseIf i = m_lrByField Then obj.Value(i) = "" ElseIf i = m_lrRnField Then obj.Value(i) = "" End If End If Next Else ' If No shape-change then it must be an attribute value change Dim bool As Boolean Dim msgEditReason As String msgEditReason = "" 'Msg to hold which Attribute changed, set to emptystring ' ***** Retire Old feature For i = 0 To pRow.Fields.FieldCount - 1 If newRow.Fields.Field(i).Editable Then ' Set temporal attributes bool = pRowChanges.ValueChanged(i) If bool Then ' If this is the attribute that changed set MSG newRow.Value(i) = pRowChanges.OriginalValue(i) msgEditReason = "[" & newRow.Fields.Field(i).Name & "]" & " Value Change" bool = False Else If i = m_lStaField Then newRow.Value(i) = "Retired" ElseIf i = m_lrDtField Then newRow.Value(i) = Now

66

Else newRow.Value(i) = pRow.Value(i) End If End If If m_lrRnField > -1 Then newRow.Value(m_lrRnField) = msgEditReason End If If m_lrByField > -1 Then newRow.Value(m_lrByField) = m_sUsrName End If End If Next newRow.Store ' Create new geo-object Row in table ' ***** Set Time Attributes on New feature For i = 0 To obj.Fields.FieldCount - 1 If obj.Fields.Field(i).Editable Then ' Set temporal attributes If i = m_lrecDtField Then obj.Value(i) = Now ElseIf i = m_lStaField Then obj.Value(i) = "Active" ElseIf i = m_lcDtField Then obj.Value(i) = Now ElseIf i = m_lcByField Then obj.Value(i) = m_sUsrName ElseIf i = m_lcRnField Then obj.Value(i) = msgEditReason ElseIf i = m_lrByField Then obj.Value(i) = "" ElseIf i = m_lrRnField Then obj.Value(i) = "" End If End If Next End If End Sub

67

References

Army Pamphlet 200-1, 2002, Environmental Quality – Environmental Protection and Enhancement, Headquarters Department of the Army, Washington, D.C.

Barrera, R., Frank, A. and Al-Taha, K., 1991, Temporal Relations in Geographic

Information Systems: A Workshop at the University of Maine, Orono, Oct. 12-13, 1991.

Basoglu, U. and Morrison J., 1978, The efficient hierarchical data structure for

the U.S. historical boundary file. In Harvard Papers on GIS, Volume 4, edited by G. Dutton, (Reading, Massachusetts: Addison-Wesley).

Berman, M.L., 2003, A Data Model for Historical GIS: The CHGIS Time Series,

Harvard Yenching Institute. Available online at: http://www.people.fas.harvard.edu/~chgis/work/design/v2_chgis_data_model.pdf (accessed 12 September 2006).

Berry, B., 1964, Approaches to regional analysis: a synthesis. Annals of the

Association of American Geographers, 54, pp.2-11. Butler, A., 2005, Metadata freedom: Exchange data without national standards.

GeoWorld, Aug. 2005, pp. 36-39. Calkins, H.W. and Dickinson, H.J., 1987, The effective use of color in

cartographic displays. In Proceedings of the International GIS Symposium, Volume 3, Virginia, (Washington DC: NASA), pp. 189-199.

Corson-Rikert, J., 1987, Updating multi-layer vector databases. In Proceedings

of the International GIS Symposium, Volume 2, (Falls Church, VA: IGU), pp. 165-174.

Crissman, L.W. and Berman, M.L., 2001, Solution to the ‘Parent-Child Multiples’

Problem in the Spatio-Temporal Database Design for the CHGIS Project, Presentation to the International Workshop on Historical GIS, Shangai, CH, 2001 Available online at: http://www.people.fax.harvard.edu/~chgis/meetings/papers/crissman_paper.doc(accessed 06 September 2006).

ESRI, 2002, Modeling and using history in ArcGIS. ESRI Technical Paper, May

2002.

68

ESRI, 2004, Archiving Data Model, An ESRI White Paper, Available online at: http://support.esri.com/index.cfm?fa=downloads.dataModels.filteredGateway&dmid=38 (accessed 10 June 2006).

ESRI, 2006a, ESRI Support Center, Search ArcScripts. Available online at:

http://arcscripts.esri.com (accessed 10 September 2006). ESRI, 2006b, What’s Coming in ArcGIS 9.2. Available online at:

http://www.esri.com/software/arcgis/about/whats-coming.html (accessed 16 September 2006).

Freelan, S., 2003, Developing a quasi-temporal GIS for archival map data.

Available online at: http://gis.esri.com/library/userconf/proc03/p0987.pdf (accessed 31 July 2006).

Halls, P. and Miller, P., 1996, Of todes and worms: An Experiment in bringing

Time to ArcInfo, Proceedings of the 11th ESRI European Conference, London. Available online at: http://gis.esri.com/library/userconf/europroc96/PAPERS/PN35/PN35F.HTM (accessed 31 July 2006).

Kucera, G., Kucera, H. and Ressler, J., 2006, Is time on your side? GeoWorld,

Mar. 2006, pp. 30-33. Langran, G., 1992, Time in Geographic Information Systems. (London, New

York, Bristol PA: Taylor & Francis). Lester, M., 1990, Tracking the temporal polygon: A conceptual model of

multidimensional time for geographic information systems. Paper. Department of Geography, DP 10. University of Washington. Available online at: http://ncgia.ucsb.edu/Publications/Tech_Reports/91/91-4.pdf (accessed 31 July 2006).

Nadi, S. and Delavar, M., 2003, Spatio-temporal modeling of dynamic

phenomena in GIS. Available online at: http://www.scangis.org/scangis2003/papers/11.pdf (accessed: 31 July 2006).

Raza, A., 2001, Object-Oriented Temporal GIS for Urban Applications,

Dissertation Number 79, Geoinformatics, Spatial Information Theory and Applied Computer Science International Institute of Aerospace Survey and Earth Sciences (ITC) P.O. Box 6, 7500 AA Enschede, The Netherlands.

Sinton, D., 1978, The inherent structure of information as a constraint to analysis:

mapped thematic data as a case study. In Harvard Papers on GIS,

69

Volume 7, edited by G. Dutton, (Reading, Massachusetts: Addison-Wesley).

Thoms, E., 2005, DateGUIDstamp.zip, Public Domain. Available online at:

http://arcscripts.esri.com/details.asp?dbid=14016 (accessed: 10 September 2006)

U.S. Army Corps of Engineers, 2006, Fort Campbell Installation Design Guide.

Louisville District. Worboys, M., 1990, Reasoning about GIS using temporal and dynamic logics.

Paper. Midlands Regional Research Laboratory and Department of Computing Studies. University of Leicester, Leicester LE1 7RH United Kingdom.