OSCAR_MidTermProgressReport.doc - University of Otago

mexicanmorningData Management

Dec 16, 2012 (4 years and 6 months ago)



Architecture and Function of a Free/Libre Open Source Software Shell for Cadastral
Records Management

Project Report,
Thursday, June 26, 2008

Dr. Brent Hall, Geoff Hay, Michael Leahy, Dr. David Goodwin, Don McKinnon,

School of Surveying,

University of Otago, Dunedin, New Zealand


This report summarizes activities undertaken in the
School of Surveying

at the University of Otago,
New Zealand
to develop a robust and extensible ‘shell’ or software tool to manage cadastral records
and land parcel mapping using open source geospatial (OSG) software components. The project
extends work already funded and undertaken by the United Nations
Food and Agricultural
Organization (FAO)

to develop a supporting data model and software and complements an
independent data model developed by van Oosterom, Lemmen, Ingvarsson, van der Molen, Ploeger,
Quak e
t al. (2006).

The report details a data model and software architecture that complements the approach proposed
by van Oosterom et al. in that the approach presented here is event
driven rather than state
The model uses aspects of the van Oosterom a
t al. approach as a starting point and utilizes relevant
components. The end point is essentially the same in that it forms the framework for the
development of working software. However, we would argue that it is conceptually and
architecturally much simp
ler and more flexible in its design than the former. It also specifies a
prototype application developed using OSG components in support of the data model. The model
and operational prototype are both shown to be suitable for further open source implementa
tion to
support the ultimate objective of a freely distributed cadastral management software package. While
only the cadastral mapping functions are shown in this report, efforts are underway to extend this to
include the workflow of land title registratio

The data model and architecture specification presented here include support for a sharable ontology
for cadastral administration, a spatio
temporal data model based on events that allow the storage and
retrieval of historical data, and a plug
in archi
tecture for highly configurable deployment and
distributed independent development that can be adapted to the specific circumstances and cadastral
data management needs of any given country. It is hoped that this specification will encourage the
t of a simple and flexible open source solution that supports a wide user and contributor
base and that comprises a self
sustaining solution for land administration


Less developed and developing nations need software and expertise to implement o
r upgrade
cadastral and land administration systems (Törhönen, 2004). Currently, the World Bank requires
countries to go through a formal request for proposals and evaluation process before low interest
loans are made available for national
level projects
that are intended to support the creation of global
goals such as good governance and democratic participation, as well as achieving sound financial and
human resource management in the development effort. Reaching these goals typically takes a long
time a
nd is often interrupted along the way. In the information technology (IT) sector, for example,
solutions to financial and human resource management problems that are both strategic and national
in focus tend to attract enterprise
level technology solutions

that are dominated by the large,
proprietary software industry.


Countries that have engaged the use of enterprise
level, proprietary IT solutions typically have to pay
level prices and customize generic software that is typically complex to ma
nage. This
process often results in systems that cost significant annual licensing and maintenance fees, contain
more software than is required, offer little or no cooperation or sharing between different countries,
and that run only through interfaces in
English, that not all users are fully fluent in. Also, proprietary
software often requires extensions and additional modules to be developed to meet requirements,
and this adds to already high start
up costs.

To remedy aspects of this dominance of and rel
iance on proprietary solutions that may not fit local
needs, the FAO has funded an effort to develop a Free/Libre and Open Source software (FLOSS)
data model and software in the area of land records (parcel
level) management. This venture takes
the land ad
ministration domain model developed by van Oosterom et al. as a starting point.

Land Administration Domain Model (LADM)

The LADM proposed by van Oosterom et al. (2006) uses time stamps to store event history. While
this will work, it is not ideal in terms

of accurately capturing land administration workflow and
processes. Nor is it ideal for queries on historical processes (such as winding back database events
dynamically to reveal the state of the data at a specific point in time). In the model, objects a
assigned time
stamps associating the valid time period for an object, and this process makes retrieval
of historical states of the system under consideration cumbersome. Maintaining the integrity of an
object’s state is also difficult especially where t
he historical state might be stored across various
attributes in the system, i.e. since various objects may be involved in a single change in state, the
timestamp is applied to all involved objects and this must be maintained with full integrity otherwise
the system will fail. Hence, the relationship between versions of an object must be explicitly stored to
allow the tracing of an object’s history since changes may involve the removal of an object from the
active database (Pelekis, Theodoulidis, Kopanakis,

& Theodoridis, 2004).

To overcome the state
oriented restrictions of the LADM, a complementary, event
driven, data
model for cadastral records management has been developed through this project at the University
of Otago, in Dunedin, New Zealand. The pro
posed data model and architecture specification include
support for a sharable ontology for cadastral administration, a spatio
temporal data model approach
that is based on events that allow the efficient storage and retrieval of historical data, and a plu
architecture for highly configurable deployment and distributed independent development by a
community of FLOSS developers world
wide. With this FLOSS
based approach, the intention is to
overcome the restrictions of the proprietary, enterprise
level a
pproaches noted above and to develop
a highly customizable and responsive solution to cadastral records management needs in developing

Free/Libre Open Source Software

FLOSS may be categorised into one of three broad types, namely (1) software t
hat is, for all intents
and purposes, ‘free’ and that is useable ‘off the shelf’ to perform specific tasks. Database software,
such as MySQL or PostgreSQL, falls into this category. In general this software is typically not
modified by the majority of user
s and source code modification is generally not required; (2) software
that is less mature and which often requires modification or enhancement to be useful but which
does not explicitly provide support for enhancement (through plug
in, externalization, or

other such
mechanisms other than inheritance and polymorphism) will tend to result in ‘forked’ codebases that
are unable to support a wide contributor or support base; (3) software that provides an architecture
that supports enhancement without endangerin
g the code
base may result in more complex code

which may require relatively higher skill levels of contributors. This need may be offset
by the large support base that projects in this category may provide. In the OSG world the Eclipse
Rich C
lient Platform (RCP) fall

into this last category.



Time is an essential element in the administration of land ownership and its associated rights,
responsibilities and restrictions. Modifications to the physical dimensions of land parcels (such as
division or amalgamation) and processes involving land administration (such as the issuance of
titles or plans of subdivision) are typically ordered
. In the land administration
domain, a central interest is in changes in the state of spa
tial and thematic attributes associated with
land over time. Historic data associated with land including changes in the spatial extent of parcels
and their ownership is of central interest among other factors in terms of being able to query the
history of

a land
related object and also to model and manage the processes associated with changes
in the state and properties of objects temporally, spatially and thematically.

While there are many well
developed and widely used models of spatial data in use, the
re is no one
standardized solution to modeling time within a spatial data model that captures all needs across all
possible domains. Reviews of various solutions to this problem in the cadastral domain can be found
Pelekis et al. (2004)

Renolen (1997)
. Database vendors implement varying generic solutions
but these do not adhere to any standard and typically involve attribute time
stamping solutions of
sort proposed in the LADM of van Oosterom et al. (2006).

In contrast to the state
based, time
stamping approach proposed in the LADM, an event based
model for implementing time explicitly models events (changes in the state of the system under
igation) as first class objects, allowing an efficient storage of history
(Peuquet & Duan, 1995
ramunt & Thriault, 1995
Chen, Jiang, & Yeh, 2004
Chen & Jiang, 2000)
. This kind of model
allows queries such as “what was the state of object

at time
?” and “what changes have been made
to object

up until times
?” An event
model supports a wide range of possible changes
to objects but does not explicitly handle duration (where a change takes time to complete), lifespan
(where a change has a life span after which it reverts to a previous state), or cyclical or periodic
s (where a change occurs and reoccurs in a periodic manner). These types of changes require
explicit implementation but are possible in an event
based model. Since these and other aspects of
change are clearly important in the context of cadastral records
management, they need to be
modeled at the database level in any design.

Essentially, an event must be created whenever a change is made to an object (e.g. a parcel changes
its ownership and/or its boundary locations and dimensions) and this event links t
he instrument of
change to the object. In the case where several objects are changed by the same instrument, an event
for each object is created. The event contains links to the new state which may be the new spatial
extent of a parcel or polygon record, a
dded spatial detail to the polygon record, or additional
thematic attribute information added to the record. Inclusion of these needs was central to the
development of the Open Source Cadastral and Registry (OSCAR) data model. This working
prototype was de
veloped in relation to the needs outlined earlier in this report. The high level or
conceptual architecture of the model is described below.

OSCAR Data Model

The central feature of the OSCAR conceptual data model (OCDM) is an ‘Instrument’, which is some
ind of

of change associated with land registration administration and land surveying. An
Instrument associates ‘agents’ such as people, banks, government etc, with land and changes to the
division of land into ownership parcels and the rights, res
ponsibilities and restrictions that are
associated with ownership. An Instrument in this context might be a document such as a deed of
e, or it might be a peg in the ground with some kind of associated detail such as coordinates and
bearings. It may be

an inscription on a rock, a verbal agreement or something that is ‘known’ through
shared wisdom that can be recorded and stored in a database. In short, an instrument records some
kind of change that affects land and/or people. Instruments record details
about the creation, state,


and change in state of the phenomenon of interest, in this case land parcels. All
nstruments used
within a country therefore record and define the ontology of land administration for that country.

Classes of Instrument vary acr
oss internal and external political and national boundaries. Within a
single class of Instrument (for example a Title Document) there may be variations (in the detail
recorded) within national boundaries, and certainly between countries. With all this poss
ible variation
it is unlikely that a single definition will suffice for even the simplest class of Instrument. Therefore,
it is unlikely that a single data model will capture requirements to suit all users. In this context, the
data model must be simple en
ough to be useable, robust enough to be extensible, flexible enough be
easily applied to varying conditions, and complex enough to handle the complexities of land records
administration. These requirements are each significant yet not impossible to conside
r in a single

The OCDM proposes that documents (Instruments) be defined and implemented externally from
software or database implementations and in such a way that their definition may be used by various
software (including stand alone workstation
s, Internet and
ntranet servers and browsers, databases,
cadastral administration software) independently of software type or implementation, and in a way
that promotes reuse and sharing of data and metadata between countries. It is proposed that a defaul
document class for each use
case (see below) be defined (XML schema) that may be extended by
more country
specific schema, and that software tools be included that allow users to create and
extend their own documents.

The external definition and manage
ment of Instruments effectively removes this aspect of land
administration from the global data model and therefore removes the need to define these aspects
before an implementation of database or software is attempted. In this case, users would define the
own documents according to local conditions and data by inheriting base implementations from a
shared repository. Software would automatically reconfigure to use the new specification.

A secure document server would be used to supply documents to the a
dministration software and
Web servers (if deemed necessary or desirable) and this would be separate from the spatial data
storage. In the future, documents, document attribute metadata (types and names), and schema may
be defined by Uniform Resource Ident
ifiers (URI) that map to a shared repository. The Resource
Description Framework (RDF), an open XML standard developed by the World Wide Web
Consortium (http://w3.org/RDF), would allow definitions for attributes and the schema to be
reused and shared. This

approach also contributes to the future creation of a common shared
understanding (ontology) that includes semantic relationships and mappings between documents,
document attributes, and schema across software implementations, national boundaries, and
guages. Standards developed by ISO TC
211 and the Open Geospatial Consortium (OGC) may
be an appropriate, long term solution to accommodate these needs.

The high
level OCDM is shown in Figure 1. The
class links agents to objects (such as a
el of land or a building) via events or processes which implement the temporal aspects of land
administration. The Instrument class would ideally map to a database table that contains minimal
attribute fields that provide links (using URI) to the Instrumen
t type and definition, as well as the
actual digital document. Various other attributes (such as unique parcel identifier, current owner’s
name etc) may be included at the database level for efficiency.


class Conceptual Model
Obj ect
Spati al

Figure 1: High
level design of the OSCAR Conceptua
l Data Model (OCDM)

When a document instance is accessed for editing, viewing, or is created, the XML schema for that
Instrument can be used by the software to form the required input, edit, or view form. This means
that a single form can be used to view
or edit any kind of document

making the software
implementation relatively straightforward.

Constraints for attributes or operations that define allowable values or operations may be
implemented by software plug
ins. They may also form part of a workf
low process, as noted below.
A software executable class may be associated with a document’s type (via its XML schema and/or
in properties) and become the document’s ‘handler’ for constraints and any other computational
aspects of the document’s defin
ition or use. This class may be loaded as required via a software plug
in or configuration mechanism.

An Instrument also contains temporal information (such as valid time) and therefore details an

that defines some kind of change to land and/or its
relationship with
. The use of an explicit
event class (which would map to a database table) models the temporal aspects of land
administration in a way that captures the history of objects (such as land). The history of an object is
therefore its ti
me ordered list of events/processes.

Events associate an Instrument with the various objects that are affected in some way by that
Instrument. An event also relates the changed aspects of the object (such as its new spatial extent or
changed attribute) to

the object. Effectively, an object links to its current state via its current events
and does not explicitly store its own state. Objects (such as a parcel of land, a building area or
footprint, a right of way, an easement or some other entity) may includ
e thematic attributes and other
properties but this would be limited to those not applied by Instruments via events (and therefore
not temporal).

Ordered compositions of events (processes) may implement a workflow and be associated with rules
and constra
ints. Processes (such as a parcel creation and registration workflow), could be
implemented by users as software plug
ins which would require at least one plug
in for each process.
A more ideal implementation in the future might use a complete workflow eng
ine to manage

OSCAR platform


As described above, OSCAR is a platform that allows dynamic loading of meta
information about a
data model including its externally defined types (Instruments, forms, workflow, attributes etc). Users
may configure (
via XML) or extend (via plug
ins) the implementation to meet local requirements and
conditions. Equally, users may share configurations and extensions via a shared ontology server and
the open source model that is at the heart of the approach. The OSCAR pl
atform may be built or
configured as a client

or server
side suite of application tools (called OSCAR Tools) to meet
different usage requirements.

The proposed platform is based on the Open Source Eclipse Rich Client Platform (RCP) in which
users c
ontribute to the functionality via plug
ins (small software modules). The RCP supports
dynamic loading of plug
ins and therefore allows various configurations of plug
ins to be deployed
supporting the production and deployment of sets of independent target
ed tools from the same
codebase. The notion of OSCAR Tools is derived from this to comprise a set of functions that cover
various usage scenarios and that are configurable for and by various end
users. Hence, the OSCAR
platform defines a set of extensible
basic tools (detailed below) that are available via published
extension points.

Users may choose to contribute to this overall project in various ways, such as by extending a tool or
tools, by creating a new plug
in that extends a default tool via extens
ion points (and which might
publish new extension points), or by submitting new classes and functions for inclusion in the
OSCAR code base. The RCP allows the deployment of a fully capable development environment and
OSCAR development kit (i.e. a ‘ready to

run’ OSCAR system development environment) for users to
develop their own solutions and plug
ins. The Java programming language is proposed and this
offers a number of advantages including platform independence (write once

run anywhere);


support using externally defined language files; and large code libraries
including geospatial and imaging (and as used by U
ig and GeoTools). Oscar may also make use of
future plug
ins defined for U

such as

polygon edit tools.

he following proposed standard plug
ins are defined for OSCAR based on work underway as well
as from the outcome of discussion during the recent seminar held in Dunedin. The plug
represent core required functionality for OSCAR and the extension points
represent expected
additional functionality that may be required to suit various users.

Proposed standard extensible plug


The Instrument plug
in defines extension points that allow different types of Instrument to be
implemented, includin
g associated metadata, types, attributes, forms etc. The default functionality
could be one that loads externally defined document types and schemas (URI, XML schema) and
constructs a viewer (user interface). Further extensions could implement a data edito
r form, schema
and metadata editors, etc.


The workflow plug
in defines extension points that allow, at the simplest level, constraints on event
types to be implemented, or more completely through to a full workflow process engine
Other extensions could implement such things as periodic events, event durations,
and lifespans.


The ontology plug
in provides extension points for the maintenance of meta
configuration information, and ontology sharing.




The map plug
in provides extension points for mapping operations and/or third party GIS software
and tools (e.g. PostGIS, uDig, GeoTools) to be included within the software. It is proposed that the
PostGIS and
open source projects be used
as a plug
in for GIS and spatial data aspects of
OSCAR respectively at the database and the end
user (interface) levels of implementation. These
projects have in fact been deployed in the OSCAR prototype, which is shown later in this report.


rity will include mechanisms for user authentication as well as record and object locking where
the database is configured to operate in a multi
user environment. All data transmission will use the
secure socket protocol and encryption where necessary.


Database tool extension points for implementing connections and database maintenance tools will be


User defined tools that are not included above, including editing tools, spatial and attribute querying
tools, display tools, and
reporting tools etc.


Views that are read
only will be implemented. A standard view might be a “history view” that allows
viewing and navigation of the history of a parcel including its spatial history. This will allow a user to
roll backwards or for
wards a parcel’s event history and define display points to examine changes in
the object and associated documents and Instruments.


Extension points for Documentation and Help will be implemented.

OSCAR Core design

Fundamental characte
ristics of the core OSCAR shell design are described in the following
discussion, prior to presentation of screens that show aspects of the implemented functionality in the
prototype. Generic use
case scenarios are described first as a background.

Use Cases

Some typical, generic examples of use
cases can be described as follows:


View parcel e.g. map, rights, restrictions, responsibilities, coordinates, bearings, associated
documents, etc.


Create a new parcel where none previously existed such as th
e use of coordinate and bearing
geometry from field survey.


Creation of a new parcel by subdivision of a previously existing parcel where the previous
parcel(s) cease to exist or not.



of two (or more) parcels that result in the creation of a new pa
rcel (and retirement
of previous parcels from the active database

although these will remain passive in the
event database for recall if required).


Mutation of parcel boundaries that involves one or more parcels such as refinement of
shared boundary plac
ement or conveyencing of a part of a parcel where this does not
involve creation of a new parcel.



Addition of an easement, right, restriction, responsibility, mortgage, change of owner, or any
notation that affects a parcel. This may involve additions or
alterations to map annotations
and boundaries. This will not cause the creation/deletion of parcels. It could also include the
addition of building objects but there is a special case where buildings may be owned
separately from the land (or apportionments

of buildings such as ownership flats or
condominiums). The question is whether a part building (e.g. a flat, apartment or
is treated as a

parcel. If so then this should be modeled as
a parcel contains other
rather than as a subtype or

an annotation that contains apportionment information
(see 7).


Creation of a part
parcel (apportionment) within an existing parcel or building, such as
where separate titles are issued for parts of a parcel or building. Existing parent parcel
and/or build
ing information is retained. This is a
relationship. Child parcels and/or
apportionments can access parents or siblings via the creation event/document.


View history of a parcel.

States associated with use cases


View parcel e.g. map, rights, restrict
ions, responsibilities, coordinates, bearings etc.

Select parcel, select current coordinates from events, select all ‘current’ events that annotate
the map etc.


Creation of a new parcel where none previously existed.

Create document, create event (add ref
erence to spatial coordinates and bearings
, and


Creation of a new parcel by partitioning a previously existing parcel.

Select old parcel, create subdivision document, create removal event, create events for each
new parcel, create parcels.


rger of two (or more) parcels that result in the creation of a new parcel (and
removal of previous from the active database).

Create document, create removal events, create new parcel event.


Mutation of parcel boundaries that involves one or more parcels
such as refinement
of shared boundary placement or conveyencing of a part of a parcel where this does
not involve creation of a new parcel.

Create document, create events and link to parcels, view affected parcels and modify
boundaries, update events with

new spatial data, set parcel current spatial event.


Addition of an easement, right, restriction, responsibility, mortgage, change of
owner, or any notation that affects a parcel(s). May involve additions or alterations to
map annotations but not boundar
ies. Does not cause creation/deletion of parcels.

Create document, create event(s), set parcel(s), create map annotations.


Creation of a part
parcel within an existing parcel, such as where separate titles are
issued for parts of a parcel such as buildin
g or apartment. Existing parent parcel is
retained. This is a


Create parcel as child of parent parcel, same as for create parcel.


View history of a parcel.

Select events by parcel ID.

There are potentially many such use cases that can
be added to those noted above, and the discussion
should be regarded as a starting point in the development of the OSCAR model rather than as a mid
point or and end
point. Using the model and its basic FLOSS components as well as the Eclipse
RCP as initial

building blocks, a prototype application was developed quickly using a combination of
the PostgreSQL open source object relational database, the PostGIS spatial extension for Postgre
which allows spatial operations to be performed on database objects, and

graphical user
interface as a plug
in for a desktop application. It is important to note that
also facilitates use of
a Web Map and Web Feature Service (WFS) model that has the potential to allow the application to
be served to
hin an organization or to users internal and external to the organization via
the Internet.

Several plug
ins to contribute OSCAR functionality and which ‘use’
where added. Figure 2
shows the basic OSCAR interface with cadastral parcels displayed on
the right hand map panel (the
software being used as a plug
in). The information tab, on the left shows parcel information
and is a
view. Below, in the Parcel View tab, is the OSCAR data (a view plug
in) where it can
be seen that the selected pa
rcel has a number of documents and associated events displayed.
Navigation of these document and event links is essentially navigation of the history of the parcel
and can be achieved by clicking on an event to show the state of the current parcel after t
application of the selected event.

Several screens have been included below showing the basic OSCAR environment to highlight
aspects of its current functionality. It is important to note that these screens reveal only aspects of
interactions between t
he OSCAR database, as described above, and essentially an unmodified
in. In the next stage of development of the application the user interface will be substantially
modified and the functions and operations described above will be implemented us
ing the Eclipse
RCP. The main purpose of the screens that are included is to show the results of using an event
driven approach to modeling cadastral records management on the one hand, and the relative
simplicity of the user’s interaction environment with

the database model on the other hand.

Figure 3 shows a zoom of the parcel map layer with a slightly modified toolbar and a project
management tab open as well as layer management and active bookmarks (reference points in the
database for later recall). T
his illustrates the flexibility of modifying the user interface for specific
cases or needs in different national contexts.

Figure 4 shows a parcel object selected and locked at the layer level pending changes for editing
through the result of a new surve
y or a change to a document or Instrument relating to the subject

Figure 5 reveals the result of a dual subdivision of the subject parcel through a new survey. The old
parcel is retained in the passive database (i.e. it is not physically deleted as

it remains in the database)
but it is removed from active view and modification. The old
parcel identifier (

similarly be retired, yet retained, as would all associated documents and Instruments and new

would be issued along wi
th new documents and Instruments. Through inheritance, all
associations between this object and previous ‘states’ are retained using the event sequencing or
process that has initiated changes.


Figure 6 shows the new parcels created in the previous operati
on similarly locked at a later time, as a
result of a new event. In this instance the parcels will be merged in a subsequent survey, the outcome
of which is shown in Figure 7.

Figure 8 shows the addition of an easement between the two newly created parcel
s. This easement is
dynamically linked to the subject parcels through the related easement document or Instrument and
the events that created the easement object in the database.

Figure 9 shows the result of a dynamic query of the prior parcels that were
merged to form the new
parcel from a past state (i.e. prior to the merge in Figure 7).

Figure 10 shows all parcels (in the both the passive (historical) and active (present) database) included
in a map layer along with query results in the far right panel

from the location where several changes
have occurred. As can be seen information on the attributes, feature and geometries can be quickly
accessed in the information tab.

Figure 11 shows all of the related records in the PostgreSQL OSCAR database for do
parcels and events
that relate to

the above example

Finally, Figure

and 13
show the SQL statements executed at the database level that produced the
results shown
for Figure 5, and their resulting output. The statements in Figure 12 reveal t
he use of
procedural programming within the PostgreSQL database environment, allowing abstraction of more
complex operations (e.g., the create_parcel() and delete_parcel() functions, which alter the parcels
table, and return the resulting event records as
they are generated)
. It is important to note that in the
deployed version of OSCAR such queries, as well as others, will be automated to run using a natural
language interface that will operate in the language current in the country of application (i.e. th
application will run through an interface that can be switched to multiple languages rather than
offered only in English).


This report has summarized work undertaken to date at the University of Otago, Dunedin, New
Zealand under the auspices

of funding from the United Nations Food and Agriculture Organization
(FAO) to produced a Free/Libre Open Source ‘shell’ that is capable of providing management of
cadastral land and registry data in developing countries. The database design differs from t
hat used in
the LADM developed by van Oosterom and Lemman (2006) in that it uses a event
drive architecture
that is capable of capturing both cadastral and land registry ‘states’ at given points in time as well as
the events or process that lead to them. T
he database and indeed the software shell that integrates
with the database are designed around the principles of flexibility, robustness, extensibility and ease
of deployment and modification. The basic design is highly modular and subscribes to a plug
play approach, where new modules or plug
ins can be added given national contexts, as dictated by
local conditions and land management needs. In this regard, the initial objectives of the project have
been met and it is suggested that not only the design

but also the early rapid prototyping hold great
promise for future development within the open source software community.

The next steps of the project were discussed at the recent seminar hosted at the University of Otago.
These include the need to enha
nce further the basic data model as well as build new functions into
the software that interacts with the database. It is desirable, yet not essential, that this new
development use a subset of live data from one or two test case countries where local need
s can be
better understood and built into the prototyping exercise.


Figure 2

Figure 3


Figure 4


Figure 5

Figure 6


Figure 7

Figure 8


Figure 9

Figure 10


Figure 11


Figure 12

Figure 13



Chen, J.,

& Jiang, J. (2000). An Event
Based Approach to Spatio
Temporal Data Modeling in Land
Subdivision Systems

Chen, J., Jiang, J., & Yeh, G.
o. (2004). Designing a GIS
based CSCW system for development
control with an event
driven approac
Photogrammetric engineering and remote sensing,

Claramunt, C., & Thriault, M. (1995). Managing Time in GIS: An Event
Oriented Approach.
Proceedings of the International Workshop on Temporal Databases: Recent Advances in
Temporal Databases: Sprin

Pelekis, N., Theodoulidis, B., Kopanakis, I., & Theodoridis, Y. (2004). Literature review of spatio
temporal database models.
The Knowledge Engineering Review,
19, 235

Peuquet, D. J., & Duan, N. (1995). An event
based spatiotemporal data m
odel (ESTDM) for
temporal analysis of geographical data.
International Journal of Geographical Information Science,
9(1), 7


Renolen, A. (1997). Temporal Maps and Temporal Geographical Information Systems (Review of
Dept. of Surveying and M
apping (IKO) The Norwegian Institute of Technology

Törhönen, M.
P. (2004). Sustainable land tenure and land registration in developing countries,
including a historical comparison with an industrialised country.
Computers, Environment and Urban
8(5), 545

van Oosterom, P., Lemmen, C., Ingvarsson, T., van der Molen, P., Ploeger, H., Quak, W., et al.
(2006). The core cadastral domain model.
Computers, Environment and Urban Systems,
30(5), 627