Group Title: object-oriented approach for tracking cadastral data in the spatio-temporal domain
Title: An object-oriented approach for tracking cadastral data in the spatio-temporal domain
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00100842/00001
 Material Information
Title: An object-oriented approach for tracking cadastral data in the spatio-temporal domain
Physical Description: Book
Language: English
Creator: Leslie, Christine, 1975-
Publisher: University of Florida
Place of Publication: Gainesville Fla
Gainesville, Fla
Publication Date: 2001
Copyright Date: 2001
 Subjects
Subject: Civil and Coastal Engineering thesis, M.S   ( lcsh )
Dissertations, Academic -- Civil and Coastal Engineering -- UF   ( lcsh )
Genre: government publication (state, provincial, terriorial, dependent)   ( marcgt )
bibliography   ( marcgt )
theses   ( marcgt )
non-fiction   ( marcgt )
 Notes
Summary: ABSTRACT: Since 1980 there has been an increasing interest, both commercially and academically, in the development of spatio-temporal data models. Such data models are designed not only to facilitate information extraction about data objects and the relationships between these objects but also to support the analysis of data in a time series from varying perspectives. I will describe the design of a spatio-temporal data model for a NASA-funded research project. This project investigates how land ownership practices and land cover influence changes in carbon storage dynamics in forested ecosystems in the southeastern United States. The spatio-temporal data model designed will facilitate time-series analyses of land ownership histories allowing future studies to determine to what extent ownership changes have affected land-use/land-cover and whether these changes have in turn influenced carbon dynamics over the past 25 years.
Summary: KEYWORDS: spatio-temporal data modeling, Geographic Information Systems, land parcels
Thesis: Thesis (M.S.)--University of Florida, 2001.
Bibliography: Includes bibliographical references (p. 103-105).
System Details: System requirements: World Wide Web browser and PDF reader.
System Details: Mode of access: World Wide Web.
Statement of Responsibility: by Christine Leslie.
General Note: Title from first page of PDF file.
General Note: Document formatted into pages; contains vii, 106 p.; also contains graphics.
General Note: Vita.
 Record Information
Bibliographic ID: UF00100842
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: oclc - 48991554
alephbibnum - 002766027
notis - ANP4066

Downloads

This item has the following downloads:

cleslie ( PDF )


Full Text











AN OBJECT-ORIENTED APPROACH FOR TRACKING CADASTRAL DATA IN
THE SPATIO-TEMPORAL DOMAIN

















By

CHRISTINE LESLIE


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2001




























Copyright 2001

by

Christine Leslie















ACKNOWLEDGMENTS

I would like to thank all the members of my supervisory committee for their

guidance throughout this project. Dr. Grenville Barnes, my committee chair, and Dr.

Scot Smith have provided invaluable insight to addressing the research issues in this

project. Through Dr. Joachim Hammer's coursework and advice, I not only gained the

technical expertise required for the implementation of this project, but also gained

valuable marketable skills. I am extremely grateful to Dr. Grenville Barnes and his

family and Dr. Scot Smith for their overall support throughout this master's degree

program.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ......... .................................................................................... iii

ABSTRACT ............... ................... ........ .............. vii

CHAPTERS

1 IN TRODU CTION .................................. ....... ... ........ .... ............. .

P u rp o se o f S tu d y ............................................................................................................. 1
R research Q questions ..................................... .......... ............. ... 2
Spatio-Tem poral D ata M odeling ............................................ ............................ 3

2 SPATIO-TEMPORAL DATA MODELING ................. .........................................5

In tro d u ctio n ....................................................................... 5
Spatial O objects ................................................................................................................ 6
Components of Spatio-Temporal Data ................................. ........................ 9

3 REVIEW OF SPATIO-TEMPORAL MODELING...................... .....................17

In tro d u ctio n ........................................................................... ............... 17
Tem poral M odeling in G IS ........................................................................ 22

4 DATABASE DESIGN CONCEPTS ........................................ ......................... 32

Introduction....................... ............... ..... ............. 32
Data M modeling .......................... ...... .. .. .......................... ........ 33
Relational Versus Object-Oriented Database Models .............................. .............. 36
The Relational D database M odel.................................................... ................... 36
The Object-Oriented Database Model ............. ........................ ........... 37
Comparing Relational Models with Object-Oriented Models.......................... 38
The O bject-R elational M odel .............. .......................................................... 39
Tem poral D database Concepts ............................................... ............................ 40

5 ACQUISITION, COMPILATION AND REFORMATTING OF DATA.....................43

Data Extraction ........................................... 43
Data Formatting ............................................ 45









6 DESIGN AND IMPLEMENTATION OF THE SPATIO-TEMPORAL MODEL .......53

In tro d u ctio n ................ .. ... .. .............................................................. ............ 5 3
Requirem ents Collection and Analysis.......................... ............................. ...... 55
C conceptual D design ........ . ...... ...................... ................................ ...... .......... 55
Formal Representation of Objects and their Dynamics ................ .................. 55
T he E ntity-R relationship M odel....................................................... ... ................. 57
Logical Design ............. ........ ..... ............................. 60
Querying and Application Development .............. ................. ................................... 62
M ulti-P erspectiv e Q u series ........................................................................................ 62
Tim e-O oriented Queries .. .......................................................................... 62
O bject-O oriented Q ueries ...................... .. .. ......... .. ........................ .............. 62
Process-O oriented Queries........................................................ .......................... 62
Location-Oriented Queries........................................................ 63
Dynamic SQL Transaction and Application Development ............................... 63
Linking W ith the G IS............ .... ...... .. ........................ .... .............................. 65

7 CONCLUSIONS AND RECOMMENDATIONS ............................... ................ 66

APPENDIX A DATA FORMATTING SCRIPTS................................. ...............71

S ect T w n R n g ............. .. ............ ..................................................................... 7 1
OwnerType ......................................... 71
C hangeD etect ..................................................... 72
Id Set ........................................ .................... 74
Parcel ID ....................................................... 75
O bj_ T rack ..................................................... 7 6
D D E C reateSpreadsheet ............................................................................. ..... ........ 77

APPENDIX B DESIGN AND TRANSLATION OF THE DATABASE MODEL .........79

Definition of Relationships in the ER-model ........................ ..................... ........... 79
Translation of the ER-Model to the Relational Schema ................. ..... ......... 81
Translation of Entities............................. .............. 81
Translation of Entity Relationships ........................................ .. .......... 82

APPENDIX C CREATING THE DATABASE SCHEMA ...........................................85

S Q L S cripts ..................................................... 8 5
Loading of the D ata .............................................................................. 87


APPENDIX D QUERYING AND APPLICATION DEVELOPMENT .......................91

SQL Queries...................................................... 91
Time-Oriented Queries .. ......... .............................................. ...... .............. 91
Obj ect-Oriented Queries ......... ........ ............ .. .............. ....... ....... 91



v









Process-O oriented Queries........................................................ .......................... 92
Location-O oriented Queries....................................................... ........... .............. 92
A application D evelopm ent ......................................................... ....... ................. 92
Embedded SQL-C Application Program: parcel_search.c ..................................... 92
H TM L Source Code.................................. ... ........ ........ ........ .............. 100

LIST OF REFEREN CES ........................................................... .. ............... 103

BIOGRAPHICAL SKETCH ................................ ......... .................... 106















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

AN OBJECT-ORIENTED APPROACH FOR TRACKING CADASTRAL DATA IN
THE SPATIO-TEMPORAL DOMAIN

By

Christine Leslie

August 2001


Chairperson: Dr. Grenville Barnes
Major Department: Civil and Coastal Engineering

Since 1980 there has been an increasing interest, both commercially and

academically, in the development of spatio-temporal data models. Such data models are

designed not only to facilitate information extraction about data objects and the

relationships between these objects but also to support the analysis of data in a time series

from varying perspectives. I will describe the design of a spatio-temporal data model for

a NASA-funded research project. This project investigates how land ownership practices

and land cover influence changes in carbon storage dynamics in forested ecosystems in

the southeastern United States. The spatio-temporal data model designed will facilitate

time-series analyses of land ownership histories allowing future studies to determine to

what extent ownership changes have affected land-use/land-cover and whether these

changes have in turn influenced carbon dynamics over the past 25 years.














CHAPTER 1
INTRODUCTION


Purpose of Study

The study of carbon dynamics in the atmosphere is significant in exploring the

patterns of human and natural disturbances to ecosystems and the responses of

ecosystems to these disturbances. Changes in land-cover have implications for soil

quality, water runoff and sedimentation rates, earth-atmosphere interactions, the

hydrological cycle, biodiversity and for the biogeochemical cycling of carbon, nitrogen

and other elements at regional to global scales. Land-use and land-cover relationships

form a complex and interactive system. The impact of land tenure on forest management

has received increasing attention in the USA, where interest in who owns forestland and

other vital ecosystems has increased significantly (Heasley and Guries, 1998). This is

because the type of forest ownership greatly affects how the forested land is managed and

thus affects patterns and land-cover changes occurring in that forested area (Binford et

al., 2000).

NASA's Land Cover Land Use Change Program

The effect of human activities on carbon dynamics is one of the focuses of

NASA's Land Cover Land Use Change Program (LCLUC) within its Earth Science

Enterprise (ESE). One of the primary goals of LCLUC is to ". . further the

understanding of the consequences of land-cover and land-use change on environmental

goods and









services, the carbon and water cycles and the management of natural resources"

(Online: http://lcluc.gsfc.nasa.gov/index.asp, 2001).

As mentioned above, to further the understanding of carbon cycles, the LCLUC

program will focus on land cover and the effects of land cover on the carbon cycle. Land

cover, however, is in most cases, influenced by who currently owns the land. Land cover

will change in response to the type of ownership (industry or residential) and the human

activities occurring on the land surface. If relationships can be established between land

cover patterns and ownership changes, the effects of specific land management activities

on long term carbon storage and sequestration rates can be ultimately determined. This

thesis proposes a data model for tracking ownership histories of land parcels and, in

doing so, will support analyses between land cover data and ownership data. Ultimately it

will provide a platform for the management and integration of satellite imagery, land

ownership data and carbon data.

The research proposed in this thesis will contribute to studies being carried out by

the Department of Geography, the Department of Forestry and the Geomatics Program in

response to an LCLUC project grant awarded jointly to these departments by NASA in

May 2000.


Research Questions

To determine links between changes in land ownership, land-use/land-cover and

carbon storage patterns, two key questions for this project need to be answered:

How much carbon has been lost or gained from the SE Forests as a
consequence of long term ownership patterns?

How can we model future changes in carbon storage if we know how
ownership and land-use/land-cover will change?









In answering these questions, we, as the project team are studying land-

cover/land-use change over the past 25 years in four randomly selected study areas in

Northern Florida (Online: http://www.surv.ufl.edu/nasa/study areas.htm, 2001). Within

these study areas, we will estimate how carbon storage patterns have been altered by

observed changes in land-use/land-cover and will identify relationships between the kinds

of changes occurring in land ownership over these areas (for example, state to private

ownership). In addressing land ownership issues, I have proposed a spatio-temporal data

model adapted from object-oriented and temporal concepts, for monitoring land

ownership histories. In this thesis I will deal only with the storage and management of

ownership data in this model. However, the model will be extended to store both land

cover (satellite imagery) and carbon related data in order to achieve successful integration

of these three data components. If the model provides an effective means of monitoring

ownership data, correlation analyses between ownership changes and land cover change

will thus be easily facilitated. Once relationships are established between ownership data

and land cover, the effects of land management trends on carbon flux can be determined.


Spatio-Temporal Data Modeling

The model I have proposed needs to handle data in both the spatial (land parcel)

and temporal (ownership history) domains. The use of conventional GIS systems is

inadequate for this application since current GIS systems are unable to effectively handle

temporal data. The spatio-temporal data model is designed to anticipate queries in both

the spatial and temporal domains, and the results of these queries are formatted such that

they can be easily incorporated or linked with data in a GIS system. Thus, analyses that a

conventional GIS is unable to perform, is now facilitated by linking it to the spatio-









temporal data model. In this manner a complete spatio-temporal system can be created

where spatio-temporal queries are supported by the data model and more rigorous spatial

analysis is supported by the GIS.

Several issues arise in the process of designing spatio-temporal data models.

Firstly, limited attention has been focused on spatio-temporal modeling in the literature

(See Yuan, 2000). Spatio-temporal models have been designed specifically for a

particular application such as fire hazard monitoring (Environmental Systems Research

Institute, 1999) and there is no accepted generic or standard data model for dealing with

data of this nature. Secondly, the data often needs to be pre-processed and formatted for

input into such a model.

After having reviewed current spatio-temporal data models and the issues

involved in designing such models, I have designed and modified a spatio-temporal

model for this application by incorporating and adapting the most appropriate features of

the various models in the literature.

The second chapter of this thesis introduces fundamental concepts of spatio-

temporal data modeling before reviewing current spatio-temporal data models and their

applications in GIS systems in the third chapter. The fourth chapter discusses the

acquisition and necessary preprocessing of data to be used in the model. After a review of

database modeling in chapter 5, the complete design and implementation of the model is

presented in Chapter 6 where the model is tested and examples of the types of queries

supported by the model are discussed in detail. The final chapter discusses future research

and possible improvements to the model.

















CHAPTER 2
SPATIO-TEMPORAL DATA MODELING


Introduction

A common characteristic of conventional GIS data models is their representation

of objects at a specific point in time. However, when attempting to model phenomena in

the real world that changes with time, conventional GIS data models become inadequate.

This inadequacy has been considered a major shortcoming of conventional models when

being applied to dynamic data (Yuan, 2000; Cheng, 1999; Puequet, 1994). A more

desirable approach to modeling dynamic geographic data is to model, as closely as

possible, the data as it exists in reality. Such a model is capable of representing, analyzing

and predicting changes of spatial information over time rather than dealing with the data

as snapshots of time. Furthermore, spatio-temporal data should be stored in such a way to

conform to both human conceptualizations of the world and to technical demands for

accuracy, flexibility in analysis and visual presentation (Puequet, 1994).

Essentially, a temporal data model should facilitate

An understanding of the rules that govern changes observed in the real
world

An explanation of the state of the world at a previous time;

Predictions of the state of the world in the future;

A planning of a sequence of actions that will lead to a desirable future

(Cheng, 1999)









As previously mentioned, the core elements of the project involve an investigation

of landuse/landcover and land ownership changes over a study period of twenty-five

years. Since we are dealing here with the same spatial objects at varying points in time,

we need to ensure that no ambiguities appear in the datasets. Data for this investigation

thus needs to be handled and stored such that historical analysis and modeling of the data

can be accurately and unambiguously performed. In order to adequately store the data for

such an investigation I will propose, design and implement a spatio-temporal database

model capable of handling and storing the data such that accurate analyses and modeling

can be performed.

Since 1980 there has been an increasing interest in the development of temporal

data models where time has been incorporated into data models such as entity-

relationship models, semantic data models, knowledge-based data models, deductive data

models and object-oriented data models (Cheng, 1999; Yuan, 2000; Bagg and Ryan,

2000; Hermosilla, 2001). In the next section I will introduce key concepts of temporal

data models and before reviewing current progress in spatio temporal models and some

applications of these models in GIS systems.


Spatial Objects

Objects in a data model represent an abstract description of an entity in reality.

The abstraction is based upon the principle that entities have common attributes (Cheng,

1999). In an object-oriented model, all entities having common attributes belong to the

same class, which defines both the description and functionality of the entities within that

class. Each separate entity within a class is represented as an object and each object in

that class will have the same set of attributes as each other object within the class, but the









values of the attributes for each object will differ. As represented by Figure 2.1, a class

defines the attributes and the objects within the class have different values for the

attributes by the class. For example, in my data model, I have introduced the Ownership

Class with its set of attributes being, Owner Name, OwnerType, ParcelId, etc. I have

created three objects in this class; the Private Owner, the Commercial Owner and the

Government Owner. Each of these objects of class Ownership will have different values

for the attributes defined for the Ownership class. This relationship between objects,

classes and attributes is illustrated in Figure 2.1


CLASS A1 A2 ....... An


Ai are the attributes defined for

Object a, a2 ........ an


a, are the values of attributes Ai

Figure 2.1 Relationship between objects, classes and attributes (adapted from Cheng,
1999)



In the case of spatial objects, an object needs a geometric definition in addition to

an attribute description to represent its location, size and shape (Cheng, 1999). For

example, in our spatial model, an owner of a parcel of land needs to be spatially

referenced if we are to determine how the owner's activities are affecting land-use/land

cover. Thus for a complete representation of an object in a spatial data model, the object

needs to be defined by both a thematic (attribute) component and a geometric component.

In the model, these two components are linked together through unique identifiers of the

object. Thus each owner object is spatially referenced by a unique parcel identifying









number. For the purposes of this model, new owner objects are coming into existence

and existing owner objects are terminating while the parcel itself remains static.

If the parcel undergoes a change in ownership, a new owner object will come into

existence with a new object ID, but the parcel ID number will remain the same. In this

way, the ownership history of a parcel can be tracked by referring to its parcel ID in the

database. In the database therefore, there will exist two separate owners, both being

referenced by the same parcel ID number. Since this database does not deal with the

tracking of spatial change in parcel boundaries, if a parcel is subdivided or consolidated,

the current owner object ceases to exist in the database while new owner objects come

into existence in response to the subdivision or consolidation. Thus if one queried the

history of a newly subdivided parcel, the results will produce a set of owners from that

point in time that the subdivided parcel was created.

If the database were to facilitate the tracking of spatial change in parcels, the

parcel ID would need to be numbered such that consolidations and subdivisions could be

referenced to the parent or original parcels. Since the datasets did not maintain links

between the original and consolidated/subdivided parcels through the parcel ID's, a

complete reworking of the parcel ID's would be required in this study if spatial changes

were to be tracked in the database. An alternative approach to handling spatial data in a

dynamic environment is proposed by Cheng et al., 1995, in their design of a unified

spatio-temporal data model for a 4-D GIS. In this model, the spatial world is decomposed

into several levels representing classes. In this case, a land parcel under the land parcel

class would be decomposed into a polygon object with line and point sub-objects. In this

model, each spatial feature composing a land parcel is represented separately as









individual objects in the model and can thus be manipulated separately. Designing such a

model is beyond the scope and complexity of this thesis.


Components of Spatio-Temporal Data

As mentioned above, an object in a conventional spatial data model is comprised

of two components, the aspatial (attribute) component and the spatial (geometric)

component. In a spatio-temporal data model, there exists the third temporal component.

An object in a spatio-temporal model thus consists of three components to form a spatio-

temporal object:

The spatial (geometric) component

The non spatio-temporal or aspatial (attribute) component

The temporal component

To represent an object in a spatio-temporal data model, we therefore need to

define these three components for each object. This means we have to identify the

"What", "Where" and "When" for each object. These three interrelated components as

shown diagrammatically in Figure 2.2 form the Triad framework (Puequet, 1994; Cheng

1999) in which information is stored relating to where (the location-based view), what

(the object-based view) and when (the time-based view).


Figure 2.2. The Triad Framework









The temporal component in a spatio-temporal data model is the most significant

of the three components: When examining changes occurring in spatial data, we are

essentially examining the non-temporal components of an object, such as geometry,

topology (spatial relationships) and attribute data. However, these attributes and

geometric relationships in the data are influenced by time. Time defines:

What attributes currently exist for a spatio-temporal object

What geometric relationships are present

Determines when changes have occurred to the object

No object is fixed with the passage of time and it is clear that when examining

objects and their attributes, time needs to be incorporated in the analysis if we are to

model these objects as accurately as possible. Incorporating time achieves a closer

representation of the objects as they exist in reality where time is an influential factor. If

time is incorporated as a component of a geographical data, the possibilities of analyzing

the data over time and keeping track of historical data is greatly increased. In our

application, the history of a land parcel and the underlying land use needs to be tracked

and analyzed in order to correlate these changes with carbon storage. Thus the time of a

transfer of ownership of land is as significant as the current spatial attributes of the land

parcel and the time of change of any particular land-use classification.

While time is the most important component of a spatio-temporal model, the main

challenge facing the design and implementation of a spatio-temporal database is the

capture and representation of this temporal component. This is because the temporal

component is not as explicitly represented as spatial (geometry) and aspatial (attributes)

information. The temporal component of data is only obvious when datasets are









compared over time and consistent and reliable datasets are often not available for

different periods in time.

Changes occurring in geo-referenced objects need to be captured and sufficiently

represented in the temporal database. Initially, it is necessary to identify which are the

most desirable changes to capture, as often many changes will occur in a geographical

data entity. The types of changes captured will vary with the type of application being

designed. For example, one application such as a tax-related database might involve

capturing the aspatial changes of an object such as attribute data (owner name, owner

type) and another application such as a cadastral system might involve capturing the

spatial changes of an object such as geometric data (area of a land parcel). In our

application we are interested in capturing both aspatial and spatial changes. Attribute

data, such as land ownership and changes in land use, will need to be captured as well as

geometric changes in land parcels, such as consolidations and subdivisions. This study

however, concentrates primarily on capturing changes occurring in attribute data with the

spatial, parcel data being treated as a constant.

Object Identification

Another important issue to be dealt with in the design of the spatio-temporal

database is the unique identity of the object at a particular time. When a change, either

spatial or aspatial occurs to an object, it becomes a new object with a new object identity

in the data model (See Figure 2.3 and Figure 2.4). Since both owner objects will have the

same unique parcel ID number attribute, the ownership history of a land parcel can be

tracked by referring to its parcel ID number. Thus for a single geographic entity (spatial

and aspatial components) in the database, there will exist a parcel ID number and a list of

owner object identifiers. Figure 2.3 shows the effect of changes and the creation of new









owner objects in the database with new parcel ID numbers alongside with the previous

owner object and parcel ID number. Future improvements of the data model could

investigate linking subdivided parcels with the parent parcel through the parcel ID

number.


200


Figure 2.3. Attribute changes through time causing the creation of new owner objects


Figure 2.4 Spatial changes in time causing the creation of new owner objects



In this manner we are capturing the temporal component of the data model, which

is comprised of irregular changes in time. In our application we are dealing with irregular

changes to spatial objects through time, which are easier to represent in a data model.

Representing continuous changes to spatial data through time, however, is a far more

complex task.









In a spatio-temporal database where objects are changing over time, it is

important to identify the events causing the creation of a new spatially referenced object.

Any activity causing a change to occur in an object is considered an event. As mentioned

above, many changes will occur to a single object and it is necessary to capture only

those changes significant to the application. In the same manner, we need to focus on

only those events causing the changes we would wish to capture in the data model (ESRI,

1999). Once these events have been identified, this would indicate which of the three

components of the object would carry the unique identifier. In our application, an event

causing change may be a transferal of ownership between cadastral parcels, an alteration

in cadastral parcel boundaries, or a change in land cover or a change in land use

classification. This indicates that both spatial and aspatial components of our objects need

unique identifiers. The aspatial components are the attribute data of ownership

information, and the classification values of pixels for land use or land cover, and the

spatial components are the arcs and polygons that make up cadastral boundaries. An

example of both a spatial and an aspatial change is the subdivision of a cadastral parcel.

In this case two new owner objects will have been created on the two new polygons

where the two new owner objects are linked to each other through the unique unchanged

parcel ID number. The two new polygons also need a spatial identifier that both keeps

them unique and ties them to their parent parcel, thus introducing parcel objects as well

as owner objects. Tracking parcel objects would be a topic of possible future research in

this application.
































Figure 2.5. The structure required for defining spatial objects in a temporal data model
(Roshannejad and Kainz, 1995).



Figure 2.5 illustrates an object-oriented structure used for a defining complete

geographical entity. This structure facilitates the manipulation of the components of a

geographical object separately in relation to each other. In object-oriented terms, the

aspatial Component inherits from a class called attribute class, which contains a list of all

possible attributes that could possibly be attached to the object. The Spatial Component

maintains the geometric properties of the object and inherits from a geometric class,

which defines all possible geometric features that could be attached to the object. The

temporal Component, inheriting from a time class and an event class (multiple

inheritance), defines the status of the object in terms of both its spatial and aspatial

components. The time class maintains a list of all possible times the status of the object









could become current, basically defining a time resolution for the object. The Event class

defines all the possible events that could cause a change in the status of the object.

To summarize, a geographical entity has a main body defined by the concept of

the object. It has two primary components, the aspatial and the spatial component. The

third temporal component defines the status of the object and determines what attributes

in the attribute list are currently attached to the object and what geometric features and

spatial relationships are present.

There are certain difficulties in modeling a reality in the spatio-temporal domain.

Current GIS models become inadequate when processing temporal data and the capture

and representation of the temporal component within the current constraints of GIS and

database systems remains a challenging task. Spatio-temporal modeling within the Triad

Framework however has significant advantages. Firstly, the Triad framework provides a

powerful tool for uncovering potential spatial-temporal patterns in an environment

through which models can be easily developed and understood (Puequet, 1994).

Secondly, the Triad framework corresponds closely with the way in which humans view

the world (what, where and when scenario) and facilitates meaningful identifications of

spatio-temporal patterns and the recurrences of these patterns in space-time (Puequet,

1994). Object-Oriented tools have greatly facilitated the modeling and representation of

spatio-temporal data within the constraints of current systems (Claramunt and Theriault,

1996; Puequet, 1994). Object-oriented concepts, such as multiple inheritance and

abstraction, are used in dealing with the representations of object identification and the

occurrence of multiple change in spatially referenced objects.






16


Having introduced key concepts of spatio-temporal data modeling, I will review

current spatio-temporal models and examine the usefulness of these models in the design

of my application in the next chapter. I will also review the application of spatio-temporal

models to current GIS systems and how, in specific cases, these models have been

integrated with GIS systems to overcome the challenge of representing time.















CHAPTER 3
REVIEW OF SPATIO-TEMPORAL MODELING


Introduction

Since 1980, there has been increasing academic interest in the development of

data models that incorporate time. Time has since been added to many data models such

as the entity-relationship model, semantic data models, knowledge-based data models,

deductive data models and object-oriented data models (Yuan, 2000; Hermossila, 2001).

Because of their abilities to predict possible future outcomes, temporal or dynamic

modeling has become a major component of decision support systems (Hazelton, 1991).

Decision support systems such as the GIS are often still mostly used in an exploratory

mode although these systems were in principle, designed to provide an integrated and

flexible set of tools for analyzing large volumes of spatial data (Puequet, 1994).

Enhancing GIS systems with spatio-temporal capabilities would ultimately provide a GIS

that does fulfill its intended role as a decision support system (Hazelton, 1991).

Depending on the application, different spatio-temporal models have been

integrated into a GIS. Four basic spatio-temporal models exist at the conceptual level and

these four models have been adapted to generate designs of several other spatio-temporal

models.

The Space-Time Cube is a three-dimensional cube representing one time

dimension and two space dimensions. Accessing information in the cube requires

referencing points, tracing vectors, slicing cross sections and extracting smaller cubes out









of the larger cube. As the cube increases its data volume, however, each of these

operations becomes more and more complex. More intuitive representations of time than

the Space-Time cube are those spatio-temporal models that have incorporated time

through time-stamping of layers (Cheng, 1999; Yuan, 2000).

The Snapshot Model applies time-stamps to layers, the Space-Time Composites

time-stamps attributes and the Spatiotemporal Object Model time-stamps spatial objects.

The Snapshot Model shows the states of geographic distributions and different

times without indicating whether any changes have taken place in the time lag between

the representations of any two geographic states. Each snapshot of a geographic state

describes what exists in time at time Ti but does not record any changes that may have

occurred from one snapshot state to the next. Since no changes are recorded however,

large amounts of duplicated data are present in the model, which results in data

redundancy and can lead to data inconsistencies in the model (Cheng, 1999; Yuan, 2000).

The Space-Time Composites (ST-composites) describes the change of a spatial

object through a period of time and can be derived from temporal overlays of time-

stamped layers from the Snapshot Model. The model represents the world as a set of

spatially homogeneous and temporally uniform objects in a 2-D space. Attribute changes

are recorded at discrete points and thus the model fails to capture continuous motion or

movement. Since each change causes an object to break from its parent object and to

become its own distinct object, updating a ST-Composites database requires the

reconstruction of STC units which results in the updating of both spatial objects and

attribute tables (Cheng, 1999; Yuan, 2000).









The Spatio-temporal Object Model was developed using an object-oriented

approach. The model represents the world as a set of discrete objects consisting of spatio-

temporal atoms that can be referenced as spatio-temporal objects or non-spatio-temporal

objects. A spatio-temporal object can record changes in both space and time, while no

change occurs within each of its spatio-temporal atoms. In this way, the ST Object Model

is able to record changes in the attributes of a ST-object in both the spatial and the

temporal dimensions, together or separately, by projecting a ST-atom to the spatial and/or

temporal space. Gradual or continuous changes cannot be represented in the model since

the ST-atoms are discrete (Bagg and Ryan, 2000).

The four basic models described above have been adapted to facilitate various

kinds of analysis and case studies through the years (Cheng, 1999). Location-based and

feature-based representations are not well suited for the analysis of overall temporal

relationships of events and patterns of changes through time such as the analysis of raster

data.

The development of the Triad Model (Puequet, 1994), as previously referred to in

Chapter 2, was considered a major step forward in the handling of spatio-temporal data

(Cheng, 1999; Puequet, 1994). The Triad model represents three spatio-temporal

perspectives: feature based (what), location-based (where) and event-based (when). The

feature-based representation is the primary component of the model and the locational

and temporal/event-based features are treated as secondary components or as attributes of

the primary component. The power of the model lies in its separate treatment of these

components and thus changes relating to these individual components can be separately

captured and modeled. The Triad model however expresses little about the relationships









between these attributes and the primary component and thus complex querying of data

within the model is not be easily facilitated (Cheng, 1999).

The ESTDM (Event-based Spatio-Temporal Data Model) is an example of a

model developed to facilitate the analysis of raster-based data. The ESTDM model

groups time-stamped layers to show temporal observations of a single event in a temporal

sequence. Changes in relation to previous states are stored rather than snapshots of

instances in time. A header file contains thematic information, a pointer to a base map

and pointers to the first and last event lists. The base map is an initial snapshot of a single

theme of interest in a geographic area and the event list is a series of events consisting of

the spatio-temporal dynamics and of the thematic domain in a geographic area. Each

event in this list is time-stamped and associated with a list of event components to

indicate where changes have occurred to a predefined location, such as a raster cell, at a

particular point in time. The most significant feature of the ESTDM model is its

capabilities to support both spatial and temporal manipulations on data. However, since

the ESTDM is based on raster data, modeling a vector-based system using this model will

be difficult since changes stored by the model are based on grid cells, not spatial

topology. Our application requires the storage of both raster and vector temporal data.

While land-use data can be classified from raster data in satellite imagery, data pertaining

to ownership type (commercial, residential) cannot be distinguished through raster data or

any other spatial data source. This data is present in attribute form and is spatially

referenced to vector-based dataset. Concepts presented in the ESTDM model will

however be useful in the design and implementation of our spatio-temporal database

(Cheng, 1999; Yuan, 2000; Bagg and Ryan, 2000).









There have been various other notable adaptations of the four basic models

described above. Object-oriented concepts are used in the 4-D geomorphic information

system, Oogeomorph, which models and represents the dynamics of geomorphologic

system such as a coastal system (Cheng, 2000). The Three Domain Model (an adaptation

of the Triad Model) was proposed to manage wildfire information in a GIS environment

(Bagg and Ryan, 2000). The model defines semantical, temporal and spatial objects in

three separate domains where time is modeled as an independent concept instead of being

treated as an attribute of location. One such adaptation of the models discussed, is an

event-based system for forest management history proposed by ESRI (1999). Since the

design of this model is more closely related to this application, I will discuss some of its

features.

"An Area Event System for Forest Management History" is a spatio-temporal

model which introduces the concept of an area event (ESRI, 1999). An area event

represents an area on the ground where an event has occurred that has some effect on

forest management. An example is a harvest or forest fire. The area event is the boundary

of the forest or the extent of the forest fire. An area event consists of three components;

an event location, which represents the shape and location of the event; an event time,

which represents temporal information common to all events; and an event attribute;

which represents information specific to the type of event. The goal of this system is to

define a data structure that maintains the times events occurred and allows historical

queries. In this model, the area event is treated as an object where all area features, for

example, forest fire extent, harvest site, are maintained under the same object class

definition, which facilitates the maintenance, display and query of area events. Similarly









in my model, owner objects are maintained under the same object class definition, which

facilitates the historical tracking and querying of ownership change.

In summary, the research and development of temporal data models in the

computer sciences has significantly influenced the trends of temporal modeling in GIS.

Most of these models, however, treat time as snapshots of states (Snapshot Model) or as

differences between states (ST-Composites, ST-Objects). These models do not

adequately model interactions between natural phenomena such as merge and split and

processes causing changes in geometric and thematic aspects of an object at the same

time. In order to sufficiently model land ownership (thematic) histories, parcel

(geometric) histories and land use/ land cover change (natural phenomena), I propose to

adopt a spatio-temporal model using and adapting the concepts presented in the models

described above. In adaptation of the model, I will focus on concepts presented in the

Triad Model, The Spatio-temporal Object model and Space-Time Composites. Before

adapting such a model, it is necessary to examine how spatio-temporal models have been

adapted and incorporated into GIS systems. I will review how spatio-temporal models

have been used in GIS by referring to specific examples where GIS systems have been

extended to support dynamic/temporal modeling in response to the needs of particular

applications.


Temporal Modeling in GIS

GIS systems were designed to provide more functionality than just a "smart

mapping system" (Hazelton, 1991). The intended role of a GIS is to be that of decision

support where complex analysis of spatial data is supported, providing an efficient tool

for long term planning. Successful long term planning however, is achieved through an









understanding of the consequences of a course of actions and this understanding is gained

through an analysis of historical data and an ability to predict future outcomes (Hazelton,

1991). Current GIS systems have limited capabilities in dealing with time and dynamic

modeling and thus do not fulfill their roles as decision support systems. GIS systems will

only realize their decision support capabilities once time and dynamic modeling have

successfully been integrated into these systems (Hazelton, 1991; Puequet, 1994).

Hazelton (1991) further concludes that the need for people is an essential part of any GIS

decision support system. Since many human factors such as changing political

relationships and management activities cannot be modeled, people are essential for

providing an understanding of the data being modeled to the extent that GIS becomes a

people-oriented technology.

Different Spatio-temporal data models have been integrated into GIS systems to

suit the needs of different applications. I will review some of the more relevant

applications where spatio-temporal data models have been incorporated into GIS systems

to support the analysis of land management activities.

Spery et al. (1999) propose a "lineage metadata model" that supports the

management of geographical changes in corporate cadastre applications. In this

application, a metadata model is designed to support the management of successive

versions of a geographical database rather than managing the database through spatio-

temporal modeling. The term "lineage" is derived from the fact that there are successive

versions of the database. Spery et al. (1999) have used a "data warehousing" approach in

the implementation of their metadata model. In this approach, a source of the data exists

such as land management records and whenever change is detected between the source









and the current geographical database, the users receive a new version of the database

that corresponds to an updated situation (see Figure 3.1).





Produce 1. Pooulates the
s and Metadata Dataset


Clearinghouse 2. Detects Chanaes

eographi
Database


3. Gets new data

Figure 3.1 Refresh and update of the geographic database (Spery et al., 1999).



While current metadata models give limited information about actual geographic

changes in the data (Spery et al., 1999), this metadata model identifies geographic

features that have been changed (created, deleted, modified) and also maintains links

between the original features and the new created or modified features. Land parcels are

treated as objects and the source data are legal documents and land records in the French

cadastre system. These land records are all entered into the metadata model and whenever

a change is detected between the metadata and the source, the database is updated.

In order for such a system to be successful, data needs to be easily obtained from

a fully digital and accurate source. In the case of the French cadastre system land records

are digitally entered into a database as soon as they are created. Through this system,

links between parent and subdivided/consolidated parcels can be maintained thus

allowing for tracking of land parcel boundary changes. While tracking in the spatial









changes of land boundaries is facilitated, a system of tracking land parcel ownership does

not appear to be in effect as the data being used are land records and no attribute dataset

pertaining to ownership appears to have been built on top on the land parcels. Ownership

data can still be tracked through this system, but not as effectively as would be the case

with attribute datasets. Referring to the Triad model, in this application, aspatial data is

not maintained separately from the spatial data thus decreasing the potential for complex

and powerful querying and analysis of the ownership data.

Raza et al. (1998) implemented a Temporal GIS (TGIS) for the monitoring of

both formal and informal urban land use change. The TGIS was implemented to provide

a simple and easy to handle tool for urban planners to store and analyze spatio-temporal

land use data. Raza et al. (1998) notes that while change in land use in existing cities are

occurring in response to demands for existing urban space, large tracts of rural land in

developing countries are also being rapidly converted, on an informal basis, to urban use.

In order for urban planners to gain improved insights into development trends and land

markets within such cities, the ability to store, retrieve and analyze change data relating

to both formal and informal land use change is of great significance.

Raza et al. (1998) have developed a spatio-temporal data model based upon

Space-Time Composites to handle both formal and informal land use change. Four types

of land uses were classified in this model (Residential: subcategories unplanned and

planned; Recreational; Commercial and Industrial) where each land use is represented as

a spatio-temporal attribute object (STAO) in the model. This STAO is further

decomposed into a spatio-temporal object (STO) and an attribute-temporal object (ATO).

Properties of land use are associated with the ATO and area, perimeter and spatial









neighbors were is associated with the STO. In describing their change capture processes;

the authors note that incorporating changes into STO is significantly more complex than

incorporating changes in an ATO. Change capture is thus based on attributes where,

based on object-oreinted concepts, any change in land use property indicates the birth of

a new STAO or the death of an existing STAO. Tracking of change in urban parcel

boundaries is thus not facilitated in this application.

Incorporation of the spatio-temporal data model into the GIS was done by

implementing the model in the form of versioned attribute tables in PC Arc-Info.

The application I have developed in this thesis corresponds closely with the work

done by Raza et al. (1998). A Space-Time Composites approach is used where a change

causes an object to break from its parent object and become its own distinct object. Land

parcel ownership is treated as an object where changes in land ownership are tracked

through the aspatial component of the object.

The applications I have reviewed thus far have implemented spatio-temporal data

models in GIS systems by incorporating the temporal component as an additional

attribute in the spatio-temporal data models. In the case of vector data, the temporal

information being captured (such as land use change) is generally treated as discrete

objects changing and disappearing in time (Raza et al., 1998; Claramunt and Theriault,

2001; Hazelton, 1991; Bagg and Ryan, 2000; Yuan, 2000). The structure of these objects

reflect the Triad framework where each object has a spatial, aspatial and temporal

component. The spatial component of the object defines the object as a 2D (x, y) or 3D

(x, y, z) object in a GIS system with the aspatial and temporal components being treated

as attributes of the object. Similar frameworks can be seen in applications dealing with









raster data where individual pixels in a classification area are treated as sub-objects of the

larger object, which represents the type of classification. The temporal component of the

application is captured by attaching an additional time-stamped value to each pixel

(Cheng, 1999; ESRI, 1999).

An alternative approach is to incorporate the temporal component in a spatio-

temporal model as a fourth dimension rather than as an additional attribute. Since current

GIS systems can only support 3-dimensional data, the incorporation of a fourth

dimension would require the definition a new data structure which could support a 4-D

GIS. Hazelton (1991) examined the development of a potential data structure to support a

4-D GIS. He presented a theoretical discussion of the requirements for such a system

while noting that such a system would currently be impossible to implement, since there

was no operational platform at that time, for such a system. Since 1991 however, there

have been further attempts to design an operational 4-D GIS. The Oogeomorph is one

such system designed to handle geomorphic information where objects are referenced by

a 3-dimensional location (x, y, z) and a 1-dimensional time (t) where the spatial

dimensions (x,y,z) are maintained separately from the temporal dimension (t) (Cheng,

1999; Yuan, 2000). However the Oogeomorph data model does not completely satisfy the

requirements for a 4-D GIS. Although it handles point-based information sufficiently, it

has difficulty in processing area-related data and topological relationships in 4

dimensions. Hazelton (1991) argued that treating dimensions separately (as is the case in

the Oogeomorph where the (t) is a separate dimension), is unsatisfactory as it allows the

fourth dimension to be ignored where convenient. Hazelton stressed the inescapability of

the fourth dimension and further stresses that a new data structure is required for the









handling of 4-D topology. He further noted the lack of even a theoretical basis for the

design of such a data structure and until such a structure is implemented, a fully

operational 4-D GIS would be impossible.

In developing a data structure for a 4-D GIS, Hazelton (1991) began by

examining basic topological interactions between 1-D, 2-D, 3-D and 4-D objects and

presented a discussion on temporal topology. He concluded, however, that the 4-D

topology in GIS is extremely limited and requires further research.

Hazelton (1991) mentioned two possible approaches for developing a data

structure for a 4-D GIS. The first approach is to present the data structure by

implementation of the structure through a relational data model and the second approach

is to present the data structure by implementation of the structure through a computer

programming language such as C. In the first approach, a relational data model is

developed that treats component parts of the objects as they exist in the 4-D GIS without

considering the linkages between the component parts. The highest level of this data

model is the domain table where a 'domain' corresponds to a single scenario and several

domains may share parts of other domains. The domain table contains a list of coverages

which could be included in any particular domain. A coverage contains a collection of

objects which represent a specific theme over a period of time. Unlike a 2-D or 3-D GIS

where the coverage spans the entire coverage space, in a 4-D GIS the coverage may be

segmented over time. The coverage contains the highest-dimensional objects which have

'pointers' to the linked lower-dimensional objects. Although the relational model is able

to represent the 4-D objects required in the data structure, it is impractical to implement.

All the intelligence of the data structure is 'flattened' into the database and complex,









tedious querying is required to obtain and link higher dimensional objects with their

attached lower dimensional objects.

The second approach is a more intelligent and flexible approach to designing the

data structure. In this approach, through object-oriented concepts, higher-dimensional

objects can point to all other objects to which they are attached. This allows for an

algorithm to find related objects rather than exhaustive querying of a database. Thus

Hazelton defined a 4-D GIS data structure based on objects of varying dimensions,

pointing to related objects of varying dimensions. An in-depth discussion of this structure

is continued in Hazelton (1991, pp 273-310)

Hazelton (1991) concluded that designing a 4-D data structure is easier using the

flexibility and power of object-oriented programming. The networked nature of the data

structure, where objects are pointing to other related objects, allows any given type of

object to have many instantiations, each with different attributes. As the number of

networked objects in the GIS increases through the use of spatial indexing, which is the

ability to rapidly locate spatial information, the efficiency of the GIS will be maintained.

Figure 3.2 shows the basic data structure for this networked approach where higher

dimensional objects point to related lower dimensional objects.















v Stores information about
COVERAGE linked sequences of polytopes



Stores lists of polyhedra which
POLYTOPEFAMILY constitute the boundaries of the
polytopes


POLYTOPE Stores polyhedra and list of
(shared by many domains) polygons which constitute the
boundaries of the polyhedra


POLYHEDRON Stores polygons and list of lines
(3D Polygon) bounding polygons




POLYGON




LINE




From To
Node Node


Figure 3.2. Multidimensional, networked data structure proposed by Hazelton (1991)



Designing and implementing a 4-D GIS for the purposes of this application is

beyond the scope of this thesis. Implementing GIS through spatio-temporal data models









where time is incorporated as an attribute, is sufficient for this study. Similar applications

involving the monitoring of land-use change through time have been discussed (Cheng,

1999; Raza et al., 1998) and the concepts and design strategies in these applications are

very similar to the concepts and design strategies presented in this application. However,

the use of a 4-D GIS should not be ignored. As more and more data is captured, more

sophisticated data models will be needed for modeling a data rich environment in the

temporal domain. The linked snapshot approach used in current applications will become

insufficient and more sophisticated data models, such as that presented by Hazelton, will

become necessary in response to more complex data modeling applications.

I have chosen to implement my adopted data model through a database. I have

used the Entity-Relationship data-modeling tool to design the data model and have

translated the model into a database model, which in this case is the relational model.

Before introducing the data model adopted for this application, a discussion on data

modeling is necessary to familiarize the reader with data modeling tools and concepts.

This discussion is presented in the next chapter along with a comparison of potential

database models that could be used for this type of application.















CHAPTER 4
DATABASE DESIGN CONCEPTS


Introduction

A database is designed to represent a situation that exists in the real world as

closely as possible. The first step in the database design process is thus an understanding

of the reality or "miniworld" one is attempting to model. Through the use of data

modeling tools such as the Entity-Relationship diagram, this reality is captured and

conceptualized and once the design of the model is complete it is translated into the

database in the implementation phase. The ER diagram is an object-oriented tool for

representing data models. Once the design of the data model is complete, it can be

implemented through a database. Several translation procedures are necessary to shift the

model from its representation in the ER diagram to the database being used. Before

translation, it is therefore necessary to identify the database software to be used, as this

will effect how the data model is translated and implemented through the database. The

database software being used is significant as it either provides the user with relational

database tools or object-oriented database tools. Relational and object-oriented databases

are based on different database models. Thus, the ER-diagram is a tool for modeling

data, while there are a number of possible database models (relational, object-oriented)

through which a data model can be implemented. The process of designing a data model

in an ER-diagram and then translating the data model into a database is known as

database design.









It is also necessary to determine which database model will implement the data

model most effectively. In addition, since my model is time-based, it is necessary to

understand how the database being used manages and implements the temporal

component of a data model.


Data Modeling

Data modeling occurs during the important phase of designing a successful

database application. A database application refers to a particular database such as a bank

database, keeping track of customer accounts, or an airline database, keeping track of

reservations and availability. Part of a database application thus requires the design,

implementation and testing of the database application programs. The Entity-Relationship

(ER) model is a popular, high-level tool used for conceptualizing a data model where

data is described through entities, attributes and relationships between entities (Elmasri

and Navathe, 2000). Before a model is conceptualized in an ER schema diagram

however, several pre-design steps need to be carried out such as the type of data to be

used and the output expected from the database.

Conceptualizing Spatio-Temporal Modeling

The design and implementation of spatial (3D) GIS and Temporal models has

been discussed separately in the literature from the design and implementation of

standard database models, through past years (Cheng, 1999). However an increasing

number of data models now require 3-dimensional spatial data and/or temporal data

handling capabilities and conceptualizing spatio-temporal modeling has become a new

aspect in the Conceptual Design phase of database design to consider. It has become









necessary to combine the features of a spatial model and the features of a temporal model

with standard data models to form a unified spatio-temporal model (Cheng et al., 1995).

In integrating these models, two approaches have been proposed and implemented

in the literature. One approach is to adapt a 2-dimensional data model to include the third

vertical dimension (Z) and a fourth temporal dimension (T) to form a 4-dimensional data

model. Another approach is to build a DBMS designed to realize the fundamentals of a

spatio-temporal data model while linking the DBMS with an existing GIS. The two

above-mentioned approaches require the implementation of the following two

methodologies respectively:

1) 4-dimensional model (Hazelton, 1991):

Add the third vertical dimension by constructing 3-D geometry based
on the existing 2-D geometry

Add a fourth temporal dimension where 4-D topology can exist

Add spatial/temporal query and analysis functionality

Explore 3-D visualization to represent different views of reality at one
time

2) Extending a DBMS (Cheng et al., 1995; Yuan, 2000; Raza et al., 1998):

Implement the spatio-temporal data model in a Relational Database
Management System (RDBMS) or an Object-Oriented Database
Management System (OODBMS) environment

Link the new DBMS with the existing GIS

Explore spatial and temporal query and analysis

I chose to implement the second approach in dealing with the design and

implementation of the spatio-temporal model (see Figure 4.1). I am focusing on the

aspatial aspects of the data where time is treated as an additional attribute, rather than the









spatial aspects of the data which is the emphasis of the first approach. In the second

approach as described by Figure 4.1, the DBMS is designed to support temporal and

spatial transactions and is linked to the existing parcel GIS where the results of the

temporal/spatial queries can be linked to a parcel geometry graphic in the GIS. As

mentioned above, the type of environment used in the second approach can either be a

Relational Database Management System (RDBMS), or an Object-Oriented Database

Management System (OODBMS) or both and it is important to decide, based upon a

number of factors, which environment is most appropriate for the application.










I I
DA-Satellite imagery
DATA INPUT ... -Digital parcel data
S-Parcel Maps

Image I
)reprocessing DATA PROCESSING
Digitizing of map DTPOE I

I Decision Support System
II -Definition of the
DBMS I
Database Management Problem
_I System -Identify issues
S -Generate optimal
S solutions
I -Evaluation of policy
=orrelation Analysis I I .---______
correlation Analysis Spatial Analysis and -------
Modeling
Investigate

I I -Reports
Visualization DATA OUTPUT ......J -Imagery
-Maps
I -Charts
I ------------- -Tables


Figure 4.1. Structure of extended DBMS working platform (adapted from Cheng et al.,
1995).




Relational Versus Object-Oriented Database Models

The Relational Database Model

The relational data model represents a database as a collection of relations, which

is database terminology for "tables". Each row in the table represents a collection of

related data values; for example, in a land ownership table, a row might contain data on

the first and last names of the owner and various other parcel-related information. The

row consists of columns with each column containing data of the same type (Elmasri and

Navathe, 2000). In the Entity-Relationship model, we introduce entities and relationships









between entities, for modeling real world data. Entities can be defined as real world

abstractions of existing features and objects are an entities' database representation

(Claramunt and Theriault, 1996). An ER-model is represented in a relational database

through tables/relations where each relation represents each entity. The fields or columns

in the table are the entity attributes and linking primary keys between the tables captures

relationships between entities. In relational model terminology, a row is called a tuple, a

column or field name is called an attribute and the table itself is called a relation (Elmasri

and Navathe, 2000).

The Object-Oriented Database Model

The term Object-Oriented typically abbreviated as 00, has its origins in object-

oriented programming languages such as C++. However today, object-oriented concepts

have been introduced to many other fields such as 00-databases, software engineering,

modeling, knowledge bases and Artificial Intelligence (Elmasri and Navathe, 2000).

Object-oriented methodology aims at modeling the real world as closely as possible by

incorporating behavior abstraction, inheritance and object identification (Cheng et al.,

1995).

Unlike in object-oriented programming languages, where objects only come into

existence during the execution of the program, an OODB stores objects permanently

where they can be retrieved and shared with other programs (Elmasri and Navathe,

2000). Since the primary goal of an object-oriented system is to maintain a close

relationship with the database object and the real world, objects in an OODB must be

easily and uniquely identified and must not lose their integrity. OODB facilitate this by

providing a unique object identifier for each object in the database. This can be compared

with the primary key attribute of each relation in a relational database model.









Relationships between objects in the database are created by placing OIDs (Object

Identity Numbers) within the OIDs of the related objects thus maintaining referential

integrity in the database.

Comparing Relational Models with Object-Oriented Models

There are number of advantages to using a relational database model

It is flexible and easy to use

Since inter-record relationships do not have to be predefined, it is
easily extensible

The relational join operator allows the user to relate records
dynamically based on attribute values

It has intuitive use of tabular data

(Hesse et al., 1993)

The disadvantage of a relational system is that it becomes awkward when dealing

with information comprised of complex, hierarchical data structures that have to be

'flattened' into relations causing a loss in complexity (Hesse et al., 1993). Alternatively,

OODBMSs represent information as closely as the information exists in reality and is

able to manage large, complex pieces of unstructured data more efficiently than would be

the case in a relational model (Hesse et al., 1993). Thus the advantages to using an

OODB would be:

Greater manipulation and control of objects

Greater expressive and query power

Complex design components are represented more effectively through the
use of objects

Object-oriented databases however, are not as intuitive and easy to use as

relational database systems. Greater technical skill and understanding of 00 concepts is









required when dealing with 00 databases. Relational databases on the other hand, have a

robust infrastructure and are flexible and easy to use. As a result there are a number of

different RDBMS software brands to choose from each, as technology advances, offering

more powerful and diverse tools for enhancing current applications. Since there are more

RDBMSs available than OODBMSs, there is a wider availability of technical support and

training and RDBMSs are cheaper (Elmasri and Navathe, 2000). For these reasons

relational DBMSs have maintained their lead over OODBMS in the DBMS industry.

The Object-Relational Model

The object-relational model, which has evolved from a combination of features

from the object-oriented and relational model, is proving to be a popular, practical and

more 'natural' alternative (Hesse et al., 1993; Navathe and Elmasri, 2000). This model

combines objects, classes and methods from the object-oriented model with the concept

of relations and attributes from the relational model. An example of an Object-Relational

model is The Informix Universal Server which combines relational technologies from the

existing Informix RDBMS and object database technologies from Illustra (Elmasri and

Navathe, 2000). The use of an Object Relational database such as the Informix Universal

Server, would be ideal for this application as the expressiveness of object-oriented data

modeling, which is significant and most prolifically used in spatio-temporal modeling

(Puequet, 1994), would not be lost in the relational database structure. An object-

relational database was not available at the time this application was implemented.

Although I am not using an Object-Relational database model, I have adopted

object-oriented techniques to represent information in the relational database. 00-

concepts not only facilitate an effective platform for the design of the spatio-temporal

model, 00-concepts also provide an effective means of storing and representing temporal









information in relations in the relational database. In conclusion, I have found that when

00-techniques are implemented through the intuitive and flexible concepts of relations in

a relational database, a practical and effective system is implemented. The details of this

implementation will be discussed in chapter 6.


Temporal Database Concepts

A temporal database can be defined as a database maintaining past, present and

possibly the future of objects existing in the database (Tansel and Tin, 1997).

Maintaining temporal data within traditional relational databases is not straightforward as

there are complex issues surrounding the integration of temporal functionality into a

database. The following are examples of the type of challenges facing the implementation

of a temporal database:

Comparing database states at two different time points

Capturing concurrent events (Tansel and Tin, 1997)

Accessing times at various different periods in the database

Handling multi-valued attributes (Tansel and Tin, 1997)

Representing temporal data

Different temporal-relational models have been proposed in the literature in

response to these challenges. Temporal models are usually designed for specific

applications and no spatio-temporal model has yet been adopted as a generic model for

handling spatio-temporal data. I thus have incorporated only the most appropriate and

suitable features from the various models in the literature in the design of my spatio-

temporal database model.

There are, however, some fundamental requirements for a temporal database:









The data model should be capable of querying the data at any instance in
the data's time resolution (for example, if the data's time resolution is in
yearly intervals, querying the data by month would be impossible)

The data model should allow modeling and querying of the database at
two different time points

The data model should allow the same set of attributes to exist at different

periods in time. (Tansel and Tin, 1997)

The data model should allow multi-valued attributes

Four types of temporal databases can be classified; a static database is one that

supports one, uniform time, a historical database supports valid time, which is the time

that the fact was true, a rollback database supports transactional time, which is the time

the fact was entered into the database, and a bitemporal database supports both valid and

transactional time (Cheng et al., 1995). I will be implementing a historical database, as I

am concerned with only valid time in this application.

There are various options for storing tuples/records in a temporal table/relation in

a relational database. One option is to store all temporal information in one table while

another option would be to create two new tables; one for the currently valid information

and another for the historical information. A third option would be to create a whole new

version of a tuple/record each time the time-varying attribute is updated. However this

option would create redundancy and would be expensive to implement (Elmasri and

Navathe, 2000). In my database I have implemented the first option where all the time

varying information is stored in one relation in an effort to minimize redundancy. I have

also used object-oriented methods for storing temporal information in the database

through the methods of starting-time and ending-time of an object. For example, if the

owner of a uniquely identified parcel is in existence in the 1995 ownership dataset and if









this owner remains the owner of the parcel in the 2000 dataset, instead of repeating the

tuple twice in the relation with only the time field having a different attribute, the record

will exist only once with the attributes 0, 2000 under the field names start-time and end-

time respectively. Without more data, we do not know when the object came into

existence, but we do know that its existence did not terminate in the year 1995. On the

other hand, if the owner existed only in the 1995 dataset, (i.e. the parcel changed

ownership); this tuple will have the values 0, 1995 under the field names start-time and

end-time (i.e. this owner object terminated in 1995). A new tuple will also now exist in

the relation with the same parcel id as this tuple but with a different owner name and/or

type and will have the values 2000, 2000 under the headings start-time and end-time

respectively. This approach combines the feature of storing all temporal information in

one relation from the relational model with the method of attribute versioning (Elmasri

and Navathe, 2000) from the object-oriented model. Attribute versioning is where

attributes such as owner name and type are versioned over time by adding the temporal

periods start-time and end-time to the tuple.

Discussion on the actual database implementation for this application will

continue in chapter 6. Before discussing the design and implementation of the database

model, however, it is necessary to introduce and explore the datasets acquired for the

application and the reformatting procedures necessary for input of the data into the

database.















CHAPTER 5
ACQUISITION, COMPILATION AND REFORMATTING OF DATA

As mentioned in the first chapter, 4 study areas were delineated in four counties

for the project. To test the data model, it was necessary to acquire digital data for one of

the study areas for at least two time periods in the project, for example 1995 and 2000.

Acquisition of data involved field trips to each of the county seats. Digital data was

obtained for the years 1995 and 2000 in Alachua County and for the year 2000 in Clay

County. There was no digital data available in either Union or Hamilton counties and

digital data needs to be converted from paper maps and records for these counties. Since

data was available in digital format for two time periods in Alachua County, the model

could be tested with this data. Before loading the data into the database, several pre-

compilation and reformatting steps were necessary. Data had to be extracted from the

study area, projected and reformatted to be compatible with the data model.


Data Extraction

In each county, a 15 x 15 km study area was delineated. This study area box was

then aligned with the PLSS (Public Land Survey System) for the county so that

ownership data, which is referenced to the PLSS, could be easily extracted from the study

area box (Figure 5.1). In this manner, no parcels of land are "sliced up" by the boundaries

of the study area In Alachua county shown in Figure 5.1, the study area is not a regular

square box as is the case in the other three counties. This is due the fact that the PLSS

grid is not a regular grid in Alachua County as it is shifted to accommodate Spanish land











grants, which preceded the PLSS system.


W Tob
I,-_, To*
1. To.









-Alachua County ,o
r-i^ "'-IIIE l3- I"'11 hh - -' Ill m ^
S E 1 1- Y X
Alachua CounitIy
^s-^-^s-i~~~p~s~~i'L^ I[)s E [b f[ E -^^ --^ ^ .-
-3LS-;_^S 5_::_^53.jll ^ ^ sIjs .= I^ Ih S- E-I II 11:-a-S |S





:.__ ^ ?__.^ ^l; ^ ^ ^- ^L ^ y ^ ^- ."^ ^ ^ r_ __. '~ ^i^ '
'_*'_ /*_ ^ -^ ;_'> ,_ -^ _2 -^ .^ u ,> iJ j J .^ = L t ^ ^ E l
,_ahu ii __ _^ .^ L-L-i -E-^ -^L -'S i _^-rr .__.:rrE^^

r'^ZE^ ^BL^ =*^i^^ND~si-,-l- ^^l'l Eil[Z* ^[ i


nship: 8 Range:21
unship 8 Range:20
unship 9 Range:20
vns hip: Range: 21


Figure 5.1 Study Area of Alachua County aligned with the PLSS system




Before aligning the study area and PLSS datasets together for each county, these


two datasets needed to be projected to UTM Zone 17 coordinates since this was the


chosen projection for the project. The Section, Range and Town numbers were identified


in the study area for reference purposes when acquiring the ownership data from Alachua


County. As previously mentioned, two digital datasets on land ownership were obtained


for Alachua County where only the data in the study area polygon was extracted for the


two time periods 1995 and 2000. Before the two datasets could be loaded into the model,


several formatting and compilation steps were necessary.









Data Formatting

The digital ownership dataset consists of a unique parcel identity number, a

section, town and range number, an owner first and last name and various appraisal and

tax-related information about the parcel. Included are also a few fields on the area and

perimeter of the parcel. The section town and range number of the parcel links the parcel

dataset to the PLSS system. For purposes of input into the relational database model, the

PLSS dataset or table will be kept separately from the ownership and parcel tables. These

ownership and parcel datasets will be related to the PLSS data through a uniquely

generated id number which references a section town and range number in the PLSS

dataset (See Figure 5.2). I used Avenue scripting for generating the unique ID numbers

and for attaching this ID number to the parcel and ownership data. See script

secttwnrng in Appendix A.
OWNERSHIP

S ID
Last
First
Owner_type
N
PLSS SO id


SO id
Sect PARCEL
Town

Pa id
Area
N
SO id



Figure 5.2. Diagram showing the relating of tables in the database through the unique
identifier









For purposes of maintaining data consistency the model, the ownership data is separated

from the parcel data, as the spatial components need to be distinguished from the aspatial

components.

To monitor ownership land transactions, we need to first classify the owners in

the digital dataset by owner type, for example, commercial owners, private residential

owners or government owners. We are particular interested in any land transaction

involving commercial owners, such as timber companies and thus we would be interested

if a parcel changed owners from a commercial owner to a residential owner, a residential

owner to a commercial owner, a government owner to an industry owner and an industry

owner to a government owner. In the digital datasets of 1995 and 2000, the owners were

not classified according to the owner type and the next formatting procedure involved

writing a script to identify and classify owner type. The script owner type in Appendix A

creates a new field "ow type" and classifies industry owners and residential owners as

commercial and private respectively, based on whether there is a value in the owner first

name attribute. If the owner is a private residential owner, there will be an owner first

name value, if the owner is commercial, there is no value in the owner first name

attribute. The remaining owners were assumed to be of government ownership and a

quality assurance process was carried out to check and verify the classifications (See

Figure 5.3 and Figure 5.4).












I.. 1 1' EII jI
LC - - _. J-1































1995.... i
town and range reference number (So id).























I Inv -



Figure 5.4. Graphical representation of owner types for 1995 dataset




Once the owners had been classified into Commercial, Government and Private

owner types (the classification "no data" appears where no data has been entered in the

dataset as attributes for a parcel), the next step in the data reprocessing was to detect









changes in ownership and owner type in the two datasets. Since a parcel ID only changes

if the parcel is consolidated with another parcel or subdivided, it will remain the same

from year to year even if the ownership of the land parcel changes. The script

change detect (Appendix A) attempts to match a parcel ID in the 1995 dataset with the

same parcel ID in the 2000 dataset. If a match is found, the script them compares the

owner names and types and if a change has occurred in either the owner name or owner

type a value is inserted into the "change" field in both the 1995 and 200 datasets. This

value is a classification of the type of change that occurred and the possible

classifications are: CommtoComm (Commercial to Commercial), CommtoPriv

(Commercial to Private), PrivtoComm (Private to Commercial), PrivtoPriv (Private to

Private), CommtoGov (Commercial to Government), GovtoComm (Government to

Commercial), PrivtoGov (Private to Government) and GovtoPriv (Government to

Private) (See Figure 5.5 and Figure 5.6). Thus possible changes I would want to capture

would be a change in ownership with the type of ownership remaining the same (for

example, Commercial to Commercial) or a change in both ownership and type of

ownership (for example, Private to Commercial). Since any change in ownership (owner

name and/or owner type) means a change in attribute values and thus a change in the

status of an owner objects, a new owner object is created in the database and the

previous owner object is terminated.


















File Edit Table Feld Window Help


| Iof | 2183;electeI

. .S............. &. I.......... .. IS .Ix


PD ofl


































.1


6973-000-000
















. .. ..


,RAYONIERTIMBERLA


i_ ,- T :





i -


II-
_. 1 ,. _



. _- _, i



.L ,L .

:



, _ -, _


Figure 5.5. Change field flagging where ownership change has occurred in the digital

ownership dataset for 2000.












Change D
1995-2000 -



































Figure 5.6. Graphical representation of ownership change between the 1995 and 2000

datasets


11











ii iii











II


"'


'-' ' ~'~'









If a match in parcel IDs was not found between the datasets, this would indicate

that the parcel was either subdivided or consolidated. Distinguishing whether a parcel has

been subdivided or consolidated is a particularly complex task on its own, complex

enough to be the subject of another study. This is because it is often difficult to identify

the parent parcel of subdivisions and consolidations when the parcel geometry has

changed significantly from the dataset in 1995 in the 2000 dataset (Figure 5.7and 5.8).

Where consolidation or subdivision has been obvious, (i.e. the parent parcels are easily

identified and linked to subdivided and consolidated parcels) I have classified a change in

the parcel geometry under a separate field. Otherwise, I have treated subdivision or

consolidation as a change in ownership where, if the parcel ID disappears, the owner

object disappears. New owner objects will appear in the 2000 dataset having parcel IDs

that are not present in the 1995 dataset. These new owner objects are merely treated as

objects coming into existence in 2000. The owner objects of parcel IDs that disappear as

a result of subdivision or consolidation are treated as objects that terminate in 1995. Thus,

in the case of subdivisions and consolidations, we are reverting to a snapshot system and

a temporal component has not been captured.







51





^Ir nr--




I I - -


i l ..i






Figure 5.7. Parcel Geometry in 1995



. ..c.. E ll kl. I. I I..1 ".

l 'a a il 'l -
-' --...-- I -- -
1 I I -

J -









1 =1




Figure 5.8. Corresponding parcel geometry in 2000



Avenue scripts were written to add unique identifiers to the data for input into the

database schema. Id set, generates a set of unique identifiers for the owner objects under

column Sid. Script Pa id generates a set of reference identifiers for the parcels. Even









though a parcel has a unique id number already, the paid ID gives the parcels separate

identifiers distinguishing them from the different time periods in which they exist. Since

the 1995 dataset contained inconsistencies in the data, the script objtrack was written to

deal with these inconsistencies: Several parcels in the 1995 dataset have the same unique

parcel ID, which should not be the case. In the 2000 dataset, these parcels having the

same parcel ID, are consolidated as one parcel, removing the inconsistency. The script

objtrack, for consistency purposes in the database, links all these separate parcels with

the same unique ID to the single consolidated parcel in the 2000 dataset. In the database,

wherever the field "no_parcels" (number of parcels) appears, the numeric value in this

field indicates the number of parcels which have the same unique parcel identifier, and

thus the number of parcels in the 1995 dataset that will be involved in the transaction.

Various other less significant preprocessing avenue scripts were written for substituting

values and data sorting.

The data preprocessing described in this chapter was done primarily in response

to the design of the database schema. Once a database schema is created, it is often

necessary to format and preprocess the data to be compatible with the schema, for

example, generation of unique identifiers. In the next chapter, the database schema and

how data is handled in the schema, is described in detail. The datasets introduced in this

chapter will test the database model, where several transactions will be performed on the

data, the results of which indicating the success of the model or where possible

improvements could be added.














CHAPTER 6
DESIGN AND IMPLEMENTATION OF THE SPATIO-TEMPORAL MODEL


Introduction

In this chapter, I will discuss the design of the spatio-temporal model, its

representation in an Entity-Relationship diagram and the issues involved in building this

diagram. I will then explain the processes involved in translating the ER-model into a

relational schema where entities in the ER-model and relationships between these entities

are translated to become relations in the database. Once the relations are setup in the

database, the test data is loaded and SQL queries are performed on the data to test the

results as well as to test the integrity of the database. A dynamic application is then

created where, through a user interface on a web page, a user is able to perform queries

on the database and integrate the results with a GIS for further analysis. Figure 6.1

illustrates the main phases of database design.




















REQUIREMENTS Database Requirements
COLLECTION & ANALYSIS



I Conceptual Schema in a
CONCEPTUAL DESIGN high level model




LOGICAL DESIGN Data Model Mapping/
Translation to DBMS



APPLICATION PROGRAM Embeddded SQL
DESIGN



TRANSACTION
IMPLEMENTATION







Figure 6.1. Simplified diagram illustrating the main phases of database design (adapted
from Elmasri and Navathe, 2000)









Requirements Collection and Analysis

The first phase of database design is a requirements analysis of the database being

built. The questions one needs to ask are:

Who will be using the database?

What information do these users want from the database?

The users of this database are members of the project team and they will require

information from the database for analysis purposes. For example, changes occurring in

ownership where large tracts of land is involved is significant for correlation analyses

with changes in the carbon flux over these tracts of land. Thus the database needs to be

able to track historical cadastral data and output this data in a useable and understandable

form .The database therefore needs to handle data in the spatio-temporal domain and the

requirements for such a database are fully discusses in chapters 2 3 and 4.


Conceptual Design

Conceptualizing the data model to be implemented through the database is

completed in the second phase of database design. In this phase, the owner object and

relationships between the components of the ownerobject is formalized in the data

model.

Formal Representation of Objects and their Dynamics

As discussed in Chapter 2, an object in a spatio-temporal data model must be

defined by a geometric component, a non-spatial or attribute component and a temporal

or dynamic component. Thus the state of an object in a spatio-temporal model at any

point in time is completely defined by the three aspects of 'what', 'where' and 'when'. A

change or transition in the state of an object implies that the object has undergone a









process to reach its new state in the model. As presented previously, a predefined event

will trigger a process causing a change in the state of the object where the spatial

component of the object is affected, the non-spatial component is affected, or a

combination of both components are affected (See Figure 6.2). In this application, both

the aspatial and spatial component can be affected where an owner of a land parcel

subdivides and sells his/her land. The spatial component is affected through the

subdivision of the land parcel and the attribute/non-spatial component is affected through

the change in ownership and/or ownership type.


Figure 6.2. The transition of an object from one state to another through a process.
(Diagram adapted from Cheng, 1999)


Object:


Represents an owner of a parcel of land such as a commercial owner, a

government owner or a private owner,









State: Represents the state of an object at a specific time. The state also includes

what the current geometric and thematic properties of the object are at that

time,

Attribute: Represents the descriptive aspects of an object,

Event: Represents the event triggering a process causing the change in the

attribute aspects of the object

Time: Represents the time at which a particular state of an object exists.




The Entity-Relationship Model

From Figure 6.2, it can be observed that the dynamics of an object in a spatio-

temporal model can be described by five specific constructs; Object, Geometry, Attribute,

Event and Time. A spatially referenced object in a temporal model is described absolutely

by its attributes, geometry and its time of existence. An object undergoes a process,

triggered by an event that causes a change in the state of the object and a new object is

created. Thus to accurately represent and model the dynamics of an object in a spatio-

temporal model, these five constructs need to be treated separately from one other and

managed as individual, interrelated entities in the ER-model. For example, an object in

this model may be defined by geometry and attributes. These two features need to be

separated as a change can occur in geometry and not in attributes, or vice versa. This

change, causing a new object state and thus a new object, would not be captured if the

geometry of the object were not separated from the attributes. Similarly, an attribute of

the object may change through a process creating a new object and thus the process









feature needs to be introduced and separately maintained in the ER-model. Since each of

the components of the owner object, geometry and attributes are acting through time;

they both need to be related to the time entity in the ER-Model. The processes causing a

change in the state of the owner object also need to be related to time. Figure 6.3 shows

the Entity-Relationship Model designed for this application where the five interrelated

entities are represented alongside other 'outsider' entities, which are necessary to

describe other significant features or data entities to be used in the model. In the

relationships, the letters a, b, c, etc, are all part of the same relationship category labeling

the numbers these letters are assigned to. For example, la, lb, Ic, etc are all part of the

EXIST relationship category.






































3

5


HAS
HAPPENS AT
REFERENCED TO


Figure 6.3 Generalized Entity -Relationship model of the spatio-temporal database (adapted from Cheng, 1999).









The entities in Figure 6.3 are defined as follows (the primary key attribute/unique

idenifier for each entity is in bold):

1. Entity Owner Object with attributes O_id, Ownertype;

2. Entity Valid Time with attributes T_id, tear;

3. Entity Process with two subclasses: entity Aspatial with attributes P_id,

change, no_parcels; entity Spatial with attributes PP_id, id (parcelid),

no_parcels, pa_process;

4. Entity Attribute with attributes S_id, id (parcelid), lastname, firstnamel,

firstname2, other, taxable;

5. Entity Geometry with attributes Pa_id, area, id (parcelid);

6. Entity PLSS with attributes SO_id, section, township, range, RD.

The relationships between these entities are described in Appendix B.


Logical Design

Since each of the five constructs ownerobject, geometry, attribute, process and

validtime are maintained separately, a framework is set up to support query and

analysis from varying perspectives. Time-oriented, location-oriented, process-oriented

and object-oriented queries can now be performed on the database. In the logical design

phase, the data model is translated into the relational schema. The complete translation of

the ER-model (Figure 6.3) to the relational is schema is presented in Appendix B. Figure

6.4 is the complete schema diagram of the translated database.









































Figure 6.4.Relational Database Schema diagram









Once the translation process was complete, this schema was created in the Sybase

DBMS with the SQL script, create table.sql (see Appendix C). The data was then loaded

into the database using the bulk-copy Sybase SQL command. This allows the user to load

all the data, as a comma delimited text file, into each relation in the database at once as

opposed to manually entering the data. Tables C-l to C-6 in Appendix C are examples of

the data loaded into each of the relations created in Figure 6.4.


Querying and Application Development

Multi-Perspective Queries

As previously mentioned (page), this spatio-temporal database model is now able

to support time-oriented, location-oriented, process-oriented and object-oriented queries.

The following examples of SQL queries are now possible:

Time-Oriented Queries

"Which commercial owners existed in the years 1995 and 2000?"

"Which commercial owners only existed in the year 2000?"

Object-Oriented Queries

"Which Private Owner objects in 1995 changed to commercial owner objects in

2000?"

"Track the ownership history of parcel with parcel_id = 07604-000-000"

"Show all parcels held by North American Timber Corporation in 2000"

Process-Oriented Queries

"Which Commercial to Commercial land owner changes occurred between 1995

and 2000 where the size of the parcel was greater than 500 000 sq feet?"









Location-Oriented Queries

"Show all parcel ids in a section, township and range that were involved in a

change in ownership"

Dynamic SQL Transaction and Application Development

Dynamic SQL allows users to interact with and query a database during execution

of the database application interface. Through graphical user interfaces, an end-user can

specify values and the type of information he or she would like to retrieve without having

to input an entire SQL query. In this manner, end users who are totally unfamiliar with

the database schema or with SQL can interact with and query a database through a user

interface. Databases with dynamic SQL support accept sets of Embedded SQL statements

that a programmer submits to the database via an online application (Embedded SQL

Programmers Guide, Sybase Manual, 1999). A series of embedded SQL statements in a

C++ program, for example, connect to the database, establish variables and submit

transactions to the database. The results of embedded SQL transactions are stored in host

variables and the host programming language can be used to print the results stored in

these host variables in whatever format desired. The host programming language can be

used to design a graphical user interface where an end user can input certain information,

which is incorporated into the embedded SQL transactions and submitted to the database.

Through the use of CGI or PERL scripting, a web page can also serve as an interface

where information entered on the web page is passed to the embedded SQL application

program. This is a particularly powerful approach as any user with access to the web page

can access and query the database.

Since the data in this application needs to be available at different locations on

campus (Geography and Forestry) outside of the Geomatics department I have chosen to






64


use a web-based approach to facilitate end user access of the database. I used C as host

programming language and consulted Sybases' Embedded SQL/C Programmer's Guide

to code the embedded SQL statements and transactions. To make the application web-

based, I used CGI and HTML routines written in C that I downloaded from the

CGIHTML Documentation website (Kim, 1998). I slightly modified these routines to

create the web-based interface in Figure 6.5, which allows an end user to choose from

several database Queries. The complete Embedded SQLC application program and the

HTML source code for the web-based application interface can be found in Appendix D.


Plad- F Or nr hi Empoye ur -l|tsap

S.. ,.. ..... H rj r F. I
1i I I: :..... L :.:' : :'. '" :"- ." J_ -- I ,' r F-'i ,-j


Land Ownership Database Query Page




1995-111111 :



rF i -1.-II .i ",-


rI I II


Figure 65 Web-based application interface L
Figure 6.5. Web-based application interface









Linking With the GIS

When the application described above performs a query on the database, the

results are not only printed on the web page for the user to view, but they are also written

to a comma delimited text file which the user can access and download. The text file is

written in this format so that it can be imported into ArcView as a table, the commas

delineating the fields. An avenue script calls this table and joins the table with both the

1995 and 2000 parcel shape-files and highlights the common records and thus the parcels

appearing in the query results. The user is now able to view the parcels affected by the

query spatially, and can proceed with any other GIS analysis such as the overlay of

satellite imagery on the parcel datasets. In this example, an analyses of the underlying,

corresponding land cover of the parcels involved the query can be performed.














CHAPTER 7
CONCLUSIONS AND RECOMMENDATIONS

To determine how much carbon has been lost or gained from the SE Forests as a

consequence of long-term ownership patterns and management practices, temporal

analyses need to be performed upon cadastral data and classified satellite imagery. These

data need to be stored such that temporal queries and analyses can be easily facilitated.

Conventional geographic models become insufficient when attempting to model and

represent dynamic data. In this thesis I present the design of a spatio-temporal data

model, based upon the Star Model, where changes occurring to spatial objects over time

are stored and represented as processes occurring at different snapshots in time.

It was necessary to review the elements of temporal modeling in relation to spatial

modeling and existing spatio-temporal models before designing the spatio-temporal

model for this application. In the literature, spatio-temporal data models have been

designed in response to the needs of a particular application and there is thus no accepted

standard or generic spatio-temporal model. Different elements of temporal modeling have

been integrated with the spatial semantics in varying ways for each model, to facilitate

the needs of the different applications. I incorporated the most appropriate and suitable

features from the various models in the design of the spatio-temporal model for this

application, the most prominent features being those adapted from the Star Model

proposed by Cheng (1999).

The data used to test the model was acquired in digital format from Alachua

County for 1995 and 2000. Before loading and testing could begin, it was necessary to









format and preprocess the data to be compatible with the relational schema design.

Unique identifiers were generated and consistencies in the datasets were enforced. Data

also needed to be extracted from the datasets such as the land transactions and ownership

type classifications.

The spatio-temporal data model for this application was object-oriented in design.

The fundamentals of the model are based on dynamic object functionalities where,

triggered by an event, an object undergoes a process of change and a completely new

object emerges. The old object terminates and a new object comes into existence (see

Figure 5.1). Since a relational database model is used, the object-oriented model designed

in an ER diagram had to be translated into the relational schema. Once the translation was

complete, a relational database schema existed that could facilitate multi-perspective

several multi-perspective SQL queries:

Time-oriented queries such as querying of the existence of objects
(commercial owners) and processes;


Object-oriented queries such as tracking the owner objects history of a
parcel;


Process-oriented queries such as querying the number and occurrence of
commercial land ownership changes;


Location-oriented queries such as querying the location (section, township
range) of parcel ownership changes.


The results of these queries are formatted in an output, which can be incorporated

and joined with current data in ArcView. In this manner a user can graphically view the









parcels affected by the query and can perform spatial analysis such as the overlay of a

satellite image classified by land cover, as would be the case in this application.

The spatio-temporal model developed for this application successfully tracks

ownership history of land parcels. In answering the first question posed in chapter one, if

we are able to track ownership histories of land parcels and then correlate this ownership

history with carbon data, the amount of carbon that has been lost or gained in the SE

forests as a consequence of long-term ownership patterns can be determined. If the

effects of ownership change on land cover can be identified and correlated with carbon

data, we will be able to anticipate future changes in carbon flux in response to land

ownership changes.

Several aspects of the model could be improved through future research. While

the model does track ownership history, it does not facilitate the tracking of spatial

changes in parcel boundaries. This is a shortcoming since the subdivision and

consolidation of parcels could possibly have an effect on changes in land cover. The

complexity of tracking spatial geometric change is beyond the scope of this thesis and

would comprise a completely separate study alone. In this case, each spatial feature

comprising a land parcel would need to be treated separately in an object-oriented model

where two points would create a line, which would be part of a polygon (see Figure 7.1).

In a similar fashion to this thesis, each spatial feature could be time-stamped and treated

as sub-objects coming in and out of existence causing the change and creation of parcel

objects.









World

Object Object

Complex Complex
Complex Object
OObjectbject

Simple Simple Simple Simple
Object bect Object Object

Body

Poy n ol on on P on Polygon

Line Line Line Line Line Line

Poin Po Pont Point Point Point

Figure 7.1. An object Oriented Data Model for Spatial Data (Cheng et al., 1995)



In future research, the application could be interfaced with the GIS rather than

through the web. From a user point of view, it is more intuitive to work with the database

through the GIS interface, rather than separately querying data and then incorporating the

data into ArcView. A stronger link or relationship could be established between the GIS

and the database and the application interface could exist on the GIS-side. With the

current version of ArcView and ArcInfo, this would have been impossible or extremely

complex to implement, as the GIS scripting languages such as Avenue or AML are

limited and inflexible in dealing with external applications. However, with ArcGIS,

where programming languages such as C++ and Visual Basic are now supported,

communication between the GIS and external applications and databases can be easily

facilitated. Both Visual Basic and C++ application interfaces can be used in the GIS,

allowing direct interaction between the GIS and an external application or database. In









the case of this project, a more convenient and intuitive working environment would be

created for the user where he or she would be able to interact with the parcel graphic in

the GIS and with the data in the spatio-temporal model at the same time.

Although there are shortcomings to the model, a platform has been created for

future research and improvements. The model is flexible enough to be expanded upon

where both Carbon and Land Cover data can be included and related to the ownership

data through corresponding values in time. The database model can be easily

implemented through a user-friendlier DBMS, such as Microsoft Access, and the

application development can be interfaced with ArcGis creating a single, user-friendly

working environment for the project. However, interfacing the application through the

web allows any user from any location, with no expertise in a GIS, to access and use the

data for his or her own purposes. Furthermore, through technology such as Arc Internet

Map Server, the entire spatio-temporal system can be accessed through the web.

















APPENDIX A
DATA FORMATTING SCRIPTS

Sect Twn Rng

Generates a unique ID for each section, town and range number in the study area

thetable = av.FindDoc("soid")
theVtab = thetable.GetVtab
sectField = theVtab.FindField(" Section")
twnField = theVtab.FindField("Township")
rngField = thevTab.FindField("Range")
strField = thevTab.FindField("sectwnmg")
for each i in theVtab
sectval = theVtab.RetumValue(sectField, i)
twnval = theVtab.ReturnValue(twnField, i)
rngval = theVtab.ReturnValue(rngField,i)
thevTab.SetValue(strField, i, sectval+"-"+twnval+"-"+mgval)
end

Owner Type

Classifies parcel owners into commercial and private owner types.

thetable95 = av.FindDoc("pilot95")
theVtab95 = thetable95.GetVtab
thetable00 = av.FindDoc("pilot2000")
theVtab00 = thetable00.GetVtab
Last95Field = theVtab95.FindField("Olname")
Last00Field = theVtab00.FindField("Lastname")
First95Field = theVtab95.FindField("Ofname")
First00Field = theVtab00.FindField("Firstnamel ")
TypeField = theVtab00.FindField("OwType")
for each i in theVtabOO
firstval = theVtab00.ReturnValue(First00Field, i)
if(firstval = "") then
theVtabOO. SetValue(TypeField, i, "Commercial")
else
theVtab00. SetValue(TypeField, i, "Private")
end









end

Change Detect

Detects changes in ownership between the 1995 and 2000 parcel datasets.

thetable95 = av.FindDoc("cadl995")
theVtab95 = thetable95.GetVtab
thetable00 = av.FindDoc("cad2000")
theVtab00 = thetable00.GetVtab
p95Field = theVtab95.FindField("Parcelid")
p00Field = theVtab00.FindField("Id")
Change00Field = theVtab00.FindField("Change")
Change95Field = theVtab95.FindField("Change")
OType95Field = theVtab95.FindField("OwType")
OType00Field = theVtab00.FindField("OwType")
ProcessField = theVtab00.FindField("Process")
Last95Field = theVtab95.FindField("olname")
Last00Field = theVtab00.FindField ("Lastname")
for each i in theVtab95
p95val = theVtab95.ReturValue(p95Field,i)
last95val = theVtab95.ReturValue(Last95Field, i)
for each j in theVtab00
p00val = theVtab00.ReturnValue(p00Field, j)
last00val = theVtab00.ReturnValue(Last00Fieldj)
if (p95val = p00val) then
Owtype95 = theVtab95.ReturnValue(OType95Field, i)
Owtype00 = theVtab00.ReturnValue(OType00Field, j)
processval = theVtab00.ReturnValue(ProcessField, j)
if ((Owtype95 = "Commercial") and (Owtype00 = "Private")) then
theVtab00.SetValue(Change00Fieldj, "CommtoPriv")
theVtab95.SetValue(Change95Field,i, "CommtoPriv")
if (processval<> 0) then
theVtab00. setValue(ProcessField,j, processval+1)
else
theVtab00.setValue(ProcessField, j, 1)
end
elseif ((Owtype95 = "Commercial") and (Owtype00 =
"Commercial")) then
if (last95val <> Last00val) then
theVtab00.SetValue(Change00Fieldj, "CommtoComm")
theVtab95.SetValue(Change95Field,i, "CommtoComm")
if (processval<> 0) then
theVtab00. setValue(ProcessField,j, processval+1)
else
theVtab00.setValue(ProcessField, j, 1)
end









end
elseif ((Owtype95 = "Private") and (Owtype00 = "Commercial"))
then
theVtab00.SetValue(Change00Fieldj, "PrivtoComm")
theVtab95.SetValue(Change95Field,i, "PrivtoComm")
if (processval<> 0) then
theVtab00.setValue(ProcessFieldj, processval+1)
else
theVtab00.setValue(ProcessField, j, 1)
end
elseif ((Owtype95 = "Government") and (Owtype00 =
"Commercial")) then
theVtab00.SetValue(Change00Fieldj, "GovtoComm")
theVtab95.SetValue(Change95Field,i, "GovtoComm")
if (processval<> 0) then
theVtab00.setValue(ProcessFieldj, processval+1)
else
theVtab00.setValue(ProcessField, j, 1)
end
elseif ((Owtype95 = "Government") and (Owtype00 = "Private"))
then
theVtab00.SetValue(Change00Fieldj, "GovtoPriv")
theVtab95.SetValue(Change95Field,i, "GovtoPriv")
if (processval<> 0) then
theVtab00.setValue(ProcessFieldj, processval+1)
else
theVtab00.setValue(ProcessField, j, 1)
end

elseif ((Owtype95 = "Private") and (Owtype00 = "Government"))
then
theVtab00. SetValue(Change00Fieldj, "PrivtoGov")
theVtab95. SetValue(Change95Field,i, "PrivtoGov")
if (processval<> 0) then
theVtab00.setValue(ProcessFieldj, processval+1)
else
theVtab00.setValue(ProcessField, j, 1)
end

elseif ((Owtype95 = "Commercial") and (Owtype00 =
"Government")) then
theVtab00.SetValue(Change00Fieldj, "CommtoGov")
theVtab95. SetValue(Change95Field,i, "CommtoGov")
if (processval<> 0) then
theVtab00. setValue(ProcessField,j, processval+1)
else









theVtabOO.setValue(ProcessField, j, 1)
end
elseif((Owtype95 = "Private") and (Owtype00 = "Private")) then
if (last95val <> last00val) then
theVtabOO.SetValue(Change00Fieldj, "PrivtoPriv")
theVtab95. SetValue(Change95Field,i, "PrivtoPriv")
if (processval<> 0) then
theVtab00.setValue(ProcessFieldj, processval+1)
else
theVtab00.setValue(ProcessField, j, 1)
end
end
end
end
end
end


Id Set

Generates unique ID's for classified owners in the datasets for input into the

database as owner objects

thetable95 = av.FindDoc("cadl995")
theVtab95 = thetable95.GetVtab
etField = theVtab95.findField("Endtime")
sidField = theVtab95.findField("S_id")
p95Field = theVtab95.FindField("Parcel_id")
cField = theVtab95.FindField("check")
theBitmap = theVtab95.GetSelection

1 = 2626
k=0
s=2
for each i in theVtab95.GetSelection
p95val = theVtab95.ReturValue(p95Field, i)
for each j in theVtab95.GetSelection
p95val = theVtab95.ReturValue(p95Field, j)
if((i <> j) and (p95val = p95vall)) then
thevtab95. SetValue(sidField, j,l.AsString+"-"+s.AsString)
theVtab95. SetValue(sidField, i,l.AsString+"-"+l .AsString)
k=l
theBitmap.Clear(j)
theBitmap.Clear(i)
s = s+l









end
if(k=l) then
1 =1+1
end
k=0
s=2
end

Parcel ID

Three scripts generating a set of unique reference identifiers for the land parcels

in the datasets

Parcel ID1
thetable = av.FindDoc("cadl995")
theVtab = thetable.GetVtab
paidField = thevTab.FindField("paid")

s=2184
for each i in theVtab.GetSelection
paidval = theVtab.ReturnValue(paidField, i)
if(paidval = "") then
theVtab. SetValue(paidField, i, "pa"+s.AsString)
s=s+l
end
end

Parcel ID2
thetable00 = av.FindDoc("cad2000")
theVtab00 = thetable00.GetVtab
thetable95 = av.FindDoc("cadl995")
theVtab95 = thetable95.GetVtab
paidField00 = theVtab00.FindField("paid")
paidField95 = theVtab95.FindField("paid")
idField00 = theVtab00.FindField("id")
idField95 = theVtab95.FindField("Parcelid")

k=l
for each i in theVtab00.GetSelection
idval00 = theVtab00.ReturnValue(id Field00, i)
for each j in theVtab95.GetSelection
idval95 = theVtab95.RetumValue(id Field95, j)
if (idval95 = idvalOO) then
paidval = theVtab00.RetumValue(paidField00, i)
theVtab95. SetValue(paidField95, j, paidval+"-"+k.AsString)
k=k+l









end
end
k=l
end

Parcel ID3
thetable00 = av.FindDoc("cad2000")
theVtabOO = thetable00.GetVtab
thetable95 = av.FindDoc("cadl995")
theVtab95 = thetable95.GetVtab
paidField00 = theVtab00.FindField("paid")
paidField95 = theVtab95.FindField("paid")
idField00 = theVtab00.FindField("id")
idField95 = theVtab95.FindField("Parcelid")
flagField = theVtab95.FindField("Flag")

for each i in theVtabOO.GetSelection
idval00 = theVtab00.ReturnValue(id Field00, i)
idval00 = idval00.middle(0,5)
for each j in theVtab95.GetSelection
idval95 = theVtab95.RetumValue(id Field95, j)
idval95 = idval95.middle(0,5)
if (idval95 = idvalOO) then
theVtab95. SetValue(flagField, j 1)
end
end
end

ObjTrack

This script was written to deal with the inconsistency in the datasets where several

parcels had the same unique parcel_ID number.

thetable95 = av.FindDoc("cadl995")
theVtab95 = thetable95.GetVtab
thetable00 = av.FindDoc("cad2000")
theVtabOO = thetable00.GetVtab
p95Field = theVtab95.FindField("Parcelid")
p00Field = theVtab00.FindField("Id")
Change00Field = theVtab00.FindField("Change")
Change95Field = theVtab95.FindField("Change")
sid95Field = theVtab95.FindField("S_id")
sid00Field = theVtabOO.FindField("S_id")
ProcessField = theVtab00.FindField("Process")


for each i in theVtabOO









p00val = theVtab00.ReturValue(p00Field,i)
change00val = theVtab00.ReturnValue(change00Field,i)
processval = theVtab00.ReturnValue(ProcessField, i)
for each j in theVtab95
p95val = theVtab95.ReturnValue(p95Field, j)
if((p00val = p95val) and (change00val <> "")) then
sid95val = theVtab95.ReturnValue(sid95Fieldj)
sid00val = theVtab00.ReturnValue(sid00Field,i)
if (sid00val.count <= 4) then
theVtabOO.SetValue(sid00Field, i, sid95val.middle(0,4)+"-
"+sid00val)
end
end
end
end

DDECreateSpreadsheet

This is a script available in Arcview and can be used for transferring data from

ArcView tables to Microsoft Excel spreadsheets. This script was frequently used to

transfer all the formatted data from the datasets in Arcview to Excel Spreadsheets for

preparation for input into the database.

theTable = av.GetActiveDoc
systemClient = DDEClient.Make( "Excel", "System")
if (systemClient.HasError) then
MsgBox.error( systemClient.GetErrorMsg, "")
return nil
end

systemClient.Execute( "[NEW(1,0,FALSE)]")

selection = systemClient.Request( "Selection")
spreadsheet = selection.Left( selection.IndexOf("!"))

systemClient.Execute( "[Workspace(,,TRUE)]" )
systemClient. Close

ssClient = ddeClient.Make( "Excel", spreadsheet)

tableName = theTable.GetName
theVTab = theTable.GetVTab
theFields = theVTab.GetFields










row = 1
column = 1
ssClient.Poke( "R"+row.AsString+"C"+column.AsString, tableName)

fieldList = List.Make
while (true)
aField = MsgBox.List( theFields, "Choose fields to write to Excel:"+NL+
"(Cancel to stop)", "Excel")
if (aField = Nil) then
break
end
fieldList.Add( aField)
end

row = 2
column = 0
for each fin fieldList
column = column + 1
ssClient.Poke( "R"+row.AsString+"C"+column.AsString, f.GetName)
end

for each rec in theVTab.GetSelection
row = row + 1
column = 0
for each fin fieldList
column = column + 1
if (f.IsTypeShape) then
dataString = "Shape"
else
dataString = theVTab.ReturnValueString( f, rec)
end

ssClient.Poke( "R"+row.AsString+"C"+column.AsString, dataString)
end
end


ssClient.Close














APPENDIX B
DESIGN AND TRANSLATION OF THE DATABASE MODEL


Definition of Relationships in the ER-model

1. EXIST relationship

a) The N: 1 (many to one) relationship between Owner Object and Valid_Time

many owner objects can exist at the same point in time;

b) The M: N (many to many) relationship between Valid_Time and Geometry where

many parcels can exist at the same time and many time points can be applied to

the same geometric object (i.e. the same parcel can exist at many points in time);

c) The M: N (many to many) relationship between Valid_Time and Attribute where

many sets of attributes can exist at the same time point and many time points can

be applied to a single set of attribute (i.e. the same set of attributes can exist at

many points in time);

2. INVOLVEDIN relationship

a) The N: 1 relationship between Process and Owner Object where an owner object

can be involved in many processes of change;

b) The N: 1 relationship between Process and Geometry where a single parcel can be

involved in many processes of change;

c) The N: 1 relationship between Process and Attribute where a single set of

attributes can under go many processes of change;

3. HAS relationship









4.

a) The N: 1 relationship between Attribute and Owner object where many sets of

attributes can be referenced to the owner object of, for example, type commercial;

b) The M: N relationship between Owner Object and Geometry where many owner

objects (commercial or private owners) can be referenced to a uniquely identified

parcel and many parcels can be referenced to a particular owner object;

c) The N: 1 relationship between Attribute and Geometry where many sets of

attributes can be applied to a single parcel;

5. HAPPENSAT, N: 1 relationship between Process and Time where many

processes can occur at a single time point;

6. REFERENCED_TO relationship

a) The N: 1 relationship between Geometry and PLSS where many parcels can be

referenced to a single section, town and range number;

b) The N: 1 relationship between Attribute and PLSS where many sets of attributes

can be referenced to a single section, town and range number.

The relationship cardinalities (N: 1, M: N) described above are created to

represent the reality as closely as possible, as well as to manage and relate the datasets in

the simplest manner. These cardinalities are not necessarily completely true. For

example, in relationships 2c and 2b, many sets of attributes or parcels can be involved in

the same process, but to simplify data-management, I have chosen not to introduce these

relationships. The above relationships or facts can still be extracted from the database

through SQL query manipulation. Although, this thesis does not concentrating on spatial

processes(mainly subdivisions and consolidations), I have nevertheless introduced the









spatial process in the model for theoretical purposes and have, where possible, captured

processes of consolidation and subdivision. However, the spatial features undergoing

change should be introduced as new objects under a new class.


Translation of the ER-Model to the Relational Schema

Each of the individual entities in the ER-model (OwnerObject, Geometry, etc),

as well as the relationships between the entities, is translated into the relational schema.

Elmasri and Navathe, 1997 (Chapter 9, pg 290 296) present the rules involved in

translating individual entities and different relationship cardinality types to a relational

schema.

Translation of Entities

Entity Owner Object mapped to relation named Owner_Obj with primary key

0_id (0 id, ownertype);

Entity Geometry mapped to relation named Cad_Theme with primary key Paid

(Pa id, Area, id);

Entity Attribute mapped to relation Sect_Theme with primary key Sid (S id, id,

lastname, firstnamel, firstname2, other, taxable);

Entity Aspatial mapped to relation Pa_Process with primary key PPid (PP id,

id, no_parcels, pa_process);

Entity Spatial mapped to relation ThemeProcess with primary key P id (P id,

change, no_parcels);

Entity Valid Time mapped to relation ValidTime with primary key T id (T id,

yearr;









Entity PLSS mapped to relation Sect_Obj with primary key SOid (SO id,

Section, Township, Range, TD, RD).



Translation of Entity Relationships

1. Relationships with cardinality N: 1: Define a foreign key in the relation on

the N-side which corresponds to the primary key in the relation on the 1-side

Translate relationship 2a between Aspatial and Owner Object by adding

foreign keys oidl and o_id2 (both referencing Oid in the Owner Obj

relation) in the ThemeProcess relation;

Translate relationship 2b between Spatial and Geometry by adding foreign key

paid in the Cad_Theme relation;

Translate relationship 2c between Process and Attribute by adding foreign keys

s_idl and s_id2 (both referencing Sid in the SectTheme relation) in the

Theme Process relation;

Translate relationship 3a between attribute and Owner Object by adding

foreign key owtype in the SectTheme relation;

Translate relation 3c between Attribute and Geometry by adding foreign key

paid in the SectTheme relation;

Translate relationship 4 between Aspatial and Valid_Time by adding foreign

keys tidl and tid2 (both referencing T_id in the Valid_Time relation) in the

Theme Process relation;









Translate relationship 4 between Spatial and Valid_Time by adding foreign

keys starttime and endtime (both referencing T_id in Valid_Time) in the

Pa Process relation;

Translate relationship 5a between Geometry and PLSS by adding foreign key

so id in the Cad Theme relation;

Translate relationship 5b between Attribute and PLSS by adding foreign key

so id in the Sect Theme relation

2. Relationships with cardinality M: N: Create a whole new relation the

foreign keys of the two relation involved included as the primary key of the new

relation

Translate relationship lb between Valid_Time and Geometry by creating

relation Cad_StEt with foreign keys Pa id as the primary key and stparcel,

etparcel referencing T_id in Valid_Time (Paid, stparcel, etparcel);

Translate relationship Ic between Valid_Time and Attribute by creating

relation Theme_StEt with foreign keys Sid as the primary key and starttime,

endtime referencing T_id in Valid_Time (Sid, starttime, endtime).

I have not translated relationships la and 3b. In dealing with relationship la

between OwnerObject and Valid Time, since both Owner Object and Valid Time are

related to Process, the relationship between Owner Object and Valid_Time is more

efficiently represented through the translations of the relationships between Valid_Time

and Process and Owner Object and Process. In this manner, redundancy is minimized.

Similarly, the relationship 3b between Owner Object and Geometry is more effectively






84


represented through the relationships between Geometry and Attribute and

Owner Object and Attribute where redundancy is minimized.
















APPENDIX C
CREATING THE DATABASE SCHEMA


SQL Scripts

CreateTable.sql

This script creates the tables/relations in SYBASE and sets up referential integrity

between the tables (i.e. which primary keys are referenced as foreign keys in other

relations).

create table Sect Obj
(SOid int,
Section int,
Township int,
Range int,
TD varchar(5),
RD varchar(5),
primary key (SOid),
)
go

create table Cad Theme
(Paid varchar(50),
Area float,
id varchar(100),
so id int,
primary key (Paid),
foreign key (soid) references SectObj(SOid),
)
go

create table Valid Time
(Tid int,
year int,
primary key (T_id),
)










go

create table Owner Obj
(Oid int,
owner type varchar(100),
primary key (O_id),
)
go

create table Sect Theme
(Sid varchar(50),
id varchar(100),
lastname varchar(100) null,
firstnamel varchar(100) null,
firstname2 varchar(100) null,
so id int null,
other varchar(50) null,
owtype int null,
taxable float null,
paid varchar(50),
primary key (S_id),
foreign key (owtype) references OwnerObj(O_id),
foreign key (soid) references SectObj(SO_id),
foreign key (pa id) references Cad_Theme(Pa id),
)
go

create table Pa Process
(PPid int,
id varchar(100),
paid varchar(50),
no_parcels int,
pa_process varchar(100),
start time int,
end time int,
primary key (PPid),
foreign key (pa id) references Cad_Theme(Pa id),
foreign key (start time) references Valid_Time(T_id),
foreign key (end time) references Valid_Time(T_id),
)
go


create table Theme Process
(P id int,









change varchar(100),
no_parcels int null,
s_idl varchar(50),
s_id2 varchar(50),
o idl int,
o id2 int,
t idi int,
t id2 int,
primary key (P_id),
foreign key (sidl) references SectTheme(S_id),
foreign key (sid2) references SectTheme(S_id),
foreign key (tidl) references Valid_Time(Tid),
foreign key (tid2) references Valid_Time(Tid),
)
go

create table Theme StEt
(S_idt varchar(50),
start time int,
end time int,
primary key (S_id),
)
go

create table Cad StEt
(Paid varchar(50),
st_parcel int,
etparcel int,
primary key (Paid),
)
go


Loading of the Data

The bulk loading facility in SYBASE was used to load all the ASCII table files

into the database:

bcp TableName in TableName.txt -U -P -c -t, -r \\n

For example

bcp Cad_Theme in Cad_Theme.txt -U cleslie -P mypass -c -t, -r \\n

















Examples of the Data Loaded Into Each Relation


SectTheme
S_id Id Lastname Firstnamel Firstname2 Soid Other Owtype Taxable paid
14 07610-001-000 BURNSED BR AUDRY 8 2 111710pa14
15 07602-010-005 CHIVAS NC 7 1 6800 pa4
STATE OF
26 07836-002-003 FLA __8 DOT3 0 Pa394


Table C-l Example of data loaded into the SectTheme relation



CadTheme
Pa id Area Id So id
pal 312014.5907602-001-000 7
pa2 959304.88 07602-003-000 7
pa3 159649.5907602-010-004 7



Table C-2 Example of data loaded into Cad Theme relation


OwnerObj
O id Ownertype
1 Commercial
2 Private
3 Government
4 No Data


Table C-3 OwnerObj Table







89










Sect_Obj
SO id Section Township Range TD RD
103 08 21 S E
202 08 21 S E
301 08 21 S E
404 08 21 S E


Table C-4 Example of data loaded into Sect Obj table



ValidTime
T_id T_year
1 1975
2 1980
3 1985
4 1990
5 1995
6 2000



Table C-5 Valid Time Table



ThemeProcess
P_id Change S_idl No_Parcels Sid2 0_idl Oid2Tidl Tid2
1 CommtoComm 2631 2 1 1 1 5 6
2 CommtoComm 2203 9 1 1 5 6
3CommtoComm 2630 4 10 1 1 5 6


Table C-6 Example of data loaded into the ThemeProcess table


















PaProcess
pp_id Id -paid NoParcels PaProcess Tidl T_id2
107602-001-000 pal 2 consolidation 5 6
207602-003-000 pa2 Osubdivision 5 6
307602-010-004 pa3 Osubdivision 5 6



Table C-7. Example of the data loaded into the Pa Process table


Theme StEt
S id Start time End Time
1 6 6
2 6 6
3 6 6
4 6 6


Table C-8 Example of data loaded into Theme_StEt table


Cad StEt
Pa_id St_parcel Et_parcel
pal 6 6
pa2 6 6
pa3 6 6
pa4 6 6


Table C-9 Example of data loaded into the CadStEt table















APPENDIX D
QUERYING AND APPLICATION DEVELOPMENT


SQL Queries

Time-Oriented Queries

"Which commercial owners existed in the years 1995 and 2000?"

SELECTS idt, lastname FROM Theme StEt, Sect Theme WHERE S idt = S idAND

st time =0 AND ed time = 6

"Which commercial owners only existed in the year 2000?"

SELECT S idt, lastname FROM Theme StEt, Sect Theme WHERE S idt = S idAND

st time = 6 and ed time = 6

Object-Oriented Queries

"Which Private Owner objects in 1995 changed to commercial owner objects in

2000?"

SELECT s id], s id2 FROM Theme Process WHERE change = "PrivtoComm and t id]

5 AND t id2= 6

"Track the ownership history of parcel with parcel_id = 07604-000-000"

SELECT Lastname, owtype, st time, ed time FROM Sect Theme, Theme StEt WHERE id

= '07604-000-000'AND S id = S idt

"Show all parcels held by North American Timber Corporation in 2000"

SELECT id FROM Sect Theme, Theme StEt WHERE lastname = "North Americam

Timber Corp" AND starttime = "2000"











Process-Oriented Queries

"Which Commercial to Commercial land owner changes occurred between 1995

and 2000 where the size of the parcel was greater than 500 000 sq feet?"

SELECTP id, s id], s id2 FROM Theme Process WHERE change =

"CommtoComm "AND s id2 in (select S id FROM Sect Theme WHERE pa id in

(SELECTPa idFROM Cad Theme WHERE Area > 500000)

Location-Oriented Queries

"Show all parcel ids in a section, township and range that were involved in a

change in ownership"

SELECT id FROM Sect Theme WHERE S id in (SELECT s id2 from Theme Process)

AND so id = 8


Application Development

Embedded SQL-C Application Program: parcel search.c

#include
#include
#include "sybsqlex.h"
#include "sybsqlex.h"
#include "cgi-lib.h"
#include "html-lib.h"

void LandSearch_string(char *query_string, Ilist entries);

/* Declare the SQLCA */
EXEC SQL INCLUDE sqlca;

EXEC SQL BEGIN DECLARE SECTION;
/* Storage for login name and record */
CS_CHAR username[30], password[30];
CS_CHAR stmt[500], data buff[2000], char buff[255],
colname[20][33];
CSINT intbuff, descnt, cnt, coltype;









CS FLOAT float buff;
EXEC SQL END DECLARE SECTION;

/*Creating output files*/
FILE *outfile, *outfile2;
char ctc[] = "CommtoComm";
char tst[80];

/* Forward declarations of the error and message handlers and
other subroutines called from main().*/

void errorhandler();
void warning_handler();
void getcolnames();
void printdata();
void draw line();

int main(
{
Ilist entries;
char querybuffer[1000];
int was data = 0;

/* put sybase system environment*/
putenv("SYBASE=/local/sybase");
putenv("DSQUERY=CISE_DATASERVER_0");
putenv("LDLIBRARYPATH = /local/sybase/lib");

/* parse the form data and add it to the list */
read_cgiinput(&entries);

htmlheader();
printf(" QUERY RESULTS \n");
printf("");
printf(" QUERY RESULTS ");

LandSearch_string(querybuffer, entries);

strcpy(stmt, querybuffer);

EXEC SQL WHENEVER SQLERROR CALL errorhandler();
EXEC SQL WHENEVER SQLWARNING CALL warninghandler();
EXEC SQL WHENEVER NOT FOUND CONTINUE;

/*Copy the user name and password defined in sybsqlex.h to
the variables declared for them in the declare section.*/




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs