Building software for land records administration is difficult at the best of times.
associated records of title that do not always change in tandem with each other;
such software has to accommodate a multiplicity of end user needs and settings.
These factors may result in highly specific software that is not easily transposable
between jurisdictions. Digital systems have the general goals of achieving greater
not well developed and data quality is often poor, there is a danger that complex
relative to manual approaches. In these contexts the reality is that no single “pre-
packaged” solution can realistically meet all needs. Hence, beyond the above
goals and the need for cost effective (affordable) solutions, land records manage-
ly responsive to changing conditions and local user knowledge and abilities.
ment while potentially making the process more fragile is difficult to reconcile.
One solution is to implement digital systems with coverage limited initially to
specific areas and with only basic functionality, leaving for future implementation
40
more complex issues such as customary rights and maintaining historical informa-
tion for an individual parcel or collections of parcels (Törhönen, 2004; Österberg,
2002). However, it is possible, using a carefully planned software development
cycle, to build generic and core land records management functions that are ap-
plicable to diverse application contexts (i. e. different countries as well as changing
conditions within a country). Customized functions, written for the particular cir-
cumstances of one or another location as needs dictate, can then be built around
this generic core. While proprietary software solutions are typically written with
generic needs in mind, they often carry substantial overhead of various forms (e. g.
high initial and on-going costs, unused and perhaps unusable functions, require-
ments for particular input formats, and limited opportunities for customization
etc.) that render their suitability questionable in developing countries. In contrast,
it is possible to build solutions using existing free / libre and open-source software
(FLOSS) that can be fused together with custom coding in flexible, yet modular
and robust designs that can meet generic and particular needs as well as satisfy-
ing the goals noted above.
FLOSS provides source code to a potentially open-ended community of devel-
opers with an open development license, forming a virtual workbench for devel-
opers that can be eventually expanded, in this case, beyond parcel mapping and
title registration to include multiple interests in the management of land (e. g. valu-
ation and taxation, planning, infrastructure such as roading and other utility
networks, natural resources and so on). In addition to the manifold advantages of
FLOSS adoption (Christl, 2008), this approach is particularly well suited to develop-
ing nations as the overheads of proprietary solutions can be substantially reduced,
while producing tools that are sensitive to local needs, conditions and languages.
However, while FLOSS projects are currently widely used and constantly grow-
ing in popularity in the geospatial domain worldwide (Ramsey, 2007; Hall and
Leahy, 2008; Steiniger and Boucher, 2009), there has been very little in the way of
concerted FLOSS development for land records management. This chapter de-
scribes efforts underway to remedy this absence with the development of an
open-source cadastral and registry (OSCAR) tools project. This project has moved
from an initial software prototyping exercise and international scoping workshop
held in May 2008
25
, through to an assessment of the suitability of three nations,
namely Ghana, Samoa and Nepal as initial development sites. Further, a proposal
seeking multi-year development funding and a high level conceptual software
design (Hay and Hall, 2009) have recently been produced. At the time of writing it
seems likely that the OSCAR project will commence in earnest in the first quarter
of 2010. The following sections describe the OSCAR approach and the results that
are expected from its implementation.
25
see
http://source.otago.ac.nz/oscar