OSCAR_MidTermProgressReport.doc - University of Otago

mexicanmorningΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 9 μήνες)

374 εμφανίσεις


1

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,
Gertrude
Pieper


School of Surveying,

University of Otago, Dunedin, New Zealand


Introduction

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
-
based.
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
n.

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
developmen
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
.

Rationale

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.


2

Countries that have engaged the use of enterprise
-
level, proprietary IT solutions typically have to pay
enterprise
-
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
re
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
g
-
in
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
countries.

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
development
,

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
s

into this last category.


3


Time

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
s
ub
-
division or amalgamation) and processes involving land administration (such as the issuance of
titles or plans of subdivision) are typically ordered
chronologically
. 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
in
Pelekis et al. (2004)

and
Renolen (1997)
. Database vendors implement varying generic solutions
but these do not adhere to any standard and typically involve attribute time
-
stamping solutions of
the
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
invest
igation) as first class objects, allowing an efficient storage of history
(Peuquet & Duan, 1995
:
Cla
ramunt & Thriault, 1995
;
Chen, Jiang, & Yeh, 2004
;
Chen & Jiang, 2000)
. This kind of model
allows queries such as “what was the state of object
x

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

up until times
t,..,t+n
?” An event
-
based
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
change
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
k
ind of
document

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
ti
tl
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,

4

and change in state of the phenomenon of interest, in this case land parcels. All
I
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
model.


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
i
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
t
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
ir
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
lan
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
Instrument
class links agents to objects (such as a
parc
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.



5


class Conceptual Model
Process
Agent
Instrument
Process::Event
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
plug
-
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
event

that defines some kind of change to land and/or its
relationship with
agents
. 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
processes.


OSCAR platform


6

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
-
side

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);
FLOSS
licensing
;

international
ization

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

such as

polygon edit tools.


T
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
-
ins
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
-
ins


Instrument

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.


Workflow

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
implementation.
Other extensions could implement such things as periodic events, event durations,
and lifespans.


Ontology

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



7

Map/spatial

operations

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
uDig
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.


Security

Secu
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.


Da
tabase

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


Tools

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


Views

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.


Documentation/Help

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.


Sample
Use Cases

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


1.

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

2.

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

3.

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

4.

Merg
ing

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

5.

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.


8

6.

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
condominium)
is treated as a

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

an annotation that contains apportionment information
(see 7).

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
has
-
a
relationship. Child parcels and/or
apportionments can access parents or siblings via the creation event/document.

8.

View history of a parcel.

States associated with use cases

1.

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.


2.

Creation of a new parcel where none previously existed.

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


3.

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.


4.

Me
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.


5.

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.


6.

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.


7.

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
has
-
a
relationship.


9

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


8.

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

the
uDig
graphical user
interface as a plug
-
in for a desktop application. It is important to note that
uDig
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
intranets
wit
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’
uDig
where added. Figure 2
shows the basic OSCAR interface with cadastral parcels displayed on
the right hand map panel (the
uDig
software being used as a plug
-
in). The information tab, on the left shows parcel information
and is a
uDig
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
he
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
uDig
plug
-
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
parcel.

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 (
parcel_id
)

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

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.



10

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
cuments,
parcels and events
that relate to

the above example
s
.


Finally, Figure
a

12
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
e
application will run through an interface that can be switched to multiple languages rather than
offered only in English).


Conclusion


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
-
an
d
-
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.



11


Figure 2



Figure 3


12



Figure 4




13

Figure 5



Figure 6



14

Figure 7



Figure 8



15

Figure 9



Figure 10

16


Figure 11

17



Figure 12




Figure 13


18

References


Chen, J.,

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

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

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
ger
-
Verlag.

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

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
-

24.

Renolen, A. (1997). Temporal Maps and Temporal Geographical Information Systems (Review of
Research).
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
Systems,
2
8(5), 545
-
586.

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
-
660.