Full text: Geoinformation for practice

  
that allows the handling of temporal data. Within the last years 
a range of temporal models were also developed in the field of 
object-relational (OR) and object-oriented (OO) databases. 
GIS are more and more based on a DBMS with spatial and 
temporal extensions. The design and implementation of modern 
GIS systems for cadastre should pay special attention to the 
temporal aspects and include long transaction, versioning, 
lineage and querying multiple spatio-temporal datasets. 
In GIS environment, database is highly shared resource that is 
accessed concurrently by many applications programs and 
interactive users. This demands a control component that 
governs the access to shared data in order to avoid undesired 
interference between concurrently executing processes. The 
basic concept of this control component is transaction. The 
properties of the classical transaction lead not only to the 
concurrency control concepts required in order to avoid the 
unwanted interference but also to the recovery concepts 
required to diminish the harm of failures. Transaction is a group 
of operations against database. In traditional DBMSs, 
transactions serve three distinct purposes: (1) They are logical 
units that group together operations comprising a complete task; 
(2) they are atomicity units whose execution preserves the 
consistency of the database; and (3) they are recovery units that 
ensure that either all the steps enclosed within them are 
executed or none are. It is thus by definition that if database is 
in consistent state before a transaction starts executing, it will 
be in a consistent state when the transaction terminates. In a 
multi-user system, users execute their transactions concurrently. 
The DBMS must provide a concurrency control mechanism to 
guarantee that consistency of data is maintained in spite of 
concurrent accesses by different users. The conventional model 
of transactions in DBMS is based on the notions of 
serializability and atomicity. This transaction model has served 
quite well in conventional data-processing applications, where 
transactions typically terminate within a few seconds. 
Transactions and concurrency control in GIS are different from 
those in conventional database applications; in particular, there 
is a need to support nonserializable cooperation among users 
whose transactions are long-lived and interactive and to 
integrate concurrency control mechanisms with version control. 
The specific purpose of this paper is to propose a standard way 
of designing and implementing temporal GIS for cadastre in 
specific, standard and commercially available DBMS/GIS 
environment. It presents related work in Section 1.1. The 
temporal framework and long-transaction support is introduced 
in Section 2. The database model and overall system 
architecture is presented in Section 3. The paper ends with a 
conclusion and a list of references. 
1.1 Related work 
Time is probably one of the most essential and paradoxical 
concepts that human beings face. It is very difficult concept to 
describe and formalise, as it has no obvious physical 
characteristics and properties. The relationship between time 
and space is a consequence of the observation of changes as the 
perception of spatial alterations denotes the existence of time. 
Since more and more spatial functionality is available within 
DBMSs (IBM Inc., 2002, Oracle Inc, 2003), a more generic 
GIS approach is required, which can work with spatio-temporal 
data in a model not controlled by the GIS. Over the past years, 
the representation of spatio-temporal data has been extensively 
106 
discussed by different research communities such as the 
Artificial Intelligence domain that provides a mathematical 
foundation to the representation of changes in space (Allen, 
1983), temporal database approaches that develop database 
models and query languages for the description and 
manipulation of temporal objects (Al-Taha, 1992; Snodgrass, 
1995; Skjellaug, 1996, Bohlen, Jensen and Skjellaug, 1998; 
Jensen and Snodgrass, 1999) and studies oriented to the 
temporal extension of current spatial data models within GIS 
(Claramunt and Thériault, 1995; Wachowicz, 1999; Horsby and 
Egenhofer, 2000). 
Quite a lot of attention has been paid to methods of modelling, 
storing, indexing, editing, manipulating, analysing and 
visualizing spatio-temporal data. Good overviews of handling 
spatio-temporal data can be found in (CHOROCHRONOS: A 
Research Network for Spatiotemporal database Systems, 1996- 
2000; Claramunt and Thériault, 1995; Skjellaug, 1996; Jensen 
et aL, 1998). Some papers specifically focus on temporal 
aspects in the cadastral domain (Chen and Jiang, 1998; Galic, 
2002; Hartmannn, 2002; van Oosterom, 1997; van Oosterom 
and Lemmen, 2002a; van Oosterom et al., 2002b). 
Concurrency control has been thoroughly studied in the context 
of traditional database applications such as banking, airline 
reservation systems, and successfully implemented in cadastre 
(legal and other administrative data related to parcels) as well. 
A GIS for cadastre requires a significantly different model of 
transaction form. Early proposals attempted to define a model of 
CAD transactions (Korth et al., 1988) and engineering design 
databases (Kim et al., 1984). An overview of the characteristics 
of data and operations in some advanced database applications, 
including concurrency control requirements and the surveys of 
the mechanisms to address these requirements can be found in 
(Barghouti and Kaiser, 1991). The version mechanism for GIS 
is described in (Medeiros and Jomier, 1994), and concepts of 
transaction processing in the Internet are described in (Mohan, 
1998). 
2. TEMPORAL FRAMEWORK 
2.1 Notions of time 
For temporal databases, the existence of more than one time line 
was proposed in order to capture different aspects of the 
relationship between time and data. The following subsections 
introduce different notions of time denoting different time lines. 
These are then used to distinguish different forms of temporal 
databases in terms of their ability to model the various forms of 
temporal properties of data. 
User-defined Time: A distinction can be made whether or not 
the timestamp added to data is interpreted by the DBMS. An 
uninterpreted timestamp, for example, a value in an attribute 
day of surveying, is called user-defined time, because the 
user himself interprets the given time information, whereas 
DBMS treats this temporal data as just another attribute. User- 
defined time is an uninterpreted time value. Data models 
support user-defined time by offering, for example, a type date 
or timestamp. User-defined time values are supplied by the 
user/application and may be updated. 
Valid Time: when a fact was true with respect to the real 
world. A valid-time interval thus records the time period when a 
fact is true. It is interpreted by a DBMS supporting valid time, 
for exar 
Valid ti 
adding © 
Transac 
Besides 
is also n 
are store 
changes 
can also 
database 
transacti 
constraii 
timestan 
These k 
with nc 
Underst: 
present 
Unfortui 
only foi 
whatsoe 
2.2 Ta 
Accordi 
categori 
the val 
(Snodgr 
Snapshe 
world, u 
is done 
update, 
support. 
valid tir 
current s 
denoted 
successf 
state. 
Valid 
À 
now 
  
Historic 
the real 
axis. Pa: 
This car 
With res 
where e 
historica 
leads to 
time of {
	        
Waiting...

Note to user

Dear user,

In response to current developments in the web technology used by the Goobi viewer, the software no longer supports your browser.

Please use one of the following browsers to display this page correctly.

Thank you.