Solutions for open land administration

		Neil Pullar NRC Land Tenure Team, Food & Agriculture Organization, Rome
		Andrew McDowell NRC Land Tenure Team, Food & Agriculture Organization, Rome
		Alexander Solovov NRC Land Tenure Team, Food & Agriculture Organization, Rome
		Elton Manoku NRC Land Tenure Team, Food & Agriculture Organization, Rome
		Maria Paola Rizzo NRC Land Tenure Team, Food & Agriculture Organization, Rome

The Solutions for Open Land Administration (SOLA) Open Source Software project is a 3 year trust fund project, funded through the Government of Finland and implemented by a project team within the UN FAO.

Its aim is to make computerized cadastre and registration systems based on open source software more affordable and more sustainable in developing countries.

A “customization” version of the SOLA software was released in March 2012 (www.flossola.org).

Software architecture

At a summary level, the SOLA software architecture (McDowell 2012) focuses on delivering a set of loosely coupled interoperable and extensible services consistent with the principles of Service Oriented Architecture (SOA).

The reason a web services based architecture has been selected is to provide the best alignment with the constraints, customization and integration needs the SOLA software will likely be subject to in the diverse environments it will operate in. Figure 1, the Component Model diagram, illustrates the layered architecture of the SOLA software along with the main components and their key dependencies. A two dimensional layering approach has been used for the SOLA software to structure the software ?? rstly by responsibility and secondly for reuse.

Presentation layer of SOLA software

The Presentation Layer of the SOLA software includes two Java SWING desktop applications; SOLA Desktop and SOLA Admin. The SOLA Desktop is the primary client application of SOLA and provides case management and support for front and back office tasks that would normally be associated with cadastre and registration processes. It also includes the SOLA GIS map viewer which has been built around the Geotools open source GIS toolkit. Other open source tools that are also used by the SOLA Desktop include Jasper Reports, Java Help and Hibernate Validator which is a bean validation framework.

SOLA Admin is the second client application and it provides user management and general system administration capability.

Both client applications are deployed to end users with Java Web Start technology. Java Web Start is bundled with the Java Runtime Environment (JRE) and supports the deployment and one click installation of java applications via the web. It also includes automatic update capability minimising the overall deployment and configuration overhead needed to support future releases of the software.

Web services

The SOLA software includes eight SOAP (Simple Object Application Protocol) based web services implemented using the Java JAX-WS technology backed by Enterprise Java Beans (EJBs) hosted using Glassfish application server and Metro framework.

All of the services are designed to be interoperable and available for reuse by other systems. Using the Metro framework makes the SOLA software compatible with WS-* standards and hence interoperable with Microsoft .NET Windows Communication Foundation (WCF) technology.

The EJBs contain the main business logic for the SOLA software and have been implemented using the EJB 3.1 specification. This specification provides several improvements over earlier EJB speci?? cations and is intended to be light weight and functional. Declarative security is also used on each EJB method to provide ?? ne grained role based access control to the SOLA’s functions.

Although not illustrated on the Component Model View diagram, a Repository layer has been implemented using the MyBatis data mapper framework to separate data access logic from business logic and to consolidate and generalize database access routines. The Repository can be easily substituted with a mock implementation to allow targeted unit testing of business logic. It also ensures flexibility in the database technology used by the SOLA software. The open source PostgreSQL database is the preferred database technology for the SOLA software, however the Repository could be customized to support other database technologies.

A simple SQL based rules engine is also supported by the Services Layer. This engine allows selected business rules to be defined as SQL statements and supports updating the rules without the need to redeploy the application. Another feature of the SOLA Rules Engine is that rules can define the time frame they are applicable for. Land Administration, like many government functions, is closely tied to legislation and changes to legislation are often enacted on a specific day. Updated versions of rules can be loaded into the SOLA database along with the date they become applicable ahead of time so that SOLA can automatically reflect the changed legislation from the appropriate date without the need to deploy a new version of the software on the night before implementation.

There are also a number of base classes that have been implemented to simplify development of new web services, EJB’s and entities and to ensure the services code base remains consistent.

Figure 1 – Component View Model – SOLA software

SOLA database design

The SOLA database design is based on the Land Administration Domain Model (LADM) currently in the final stages of being adopted as an international standard (DIS 19152) by the International Standards Organisation (ISO) (http://www.isotc211. org). The decision to use LADM as a basis for the SOLA database design was in order to profit from the considerable international domain knowledge in land administration that has resulted from the prolonged discussion and consultation associated with its formulation andconsideration by ISO. It has also been useful through creating a common vocabulary for the discussion of land administration concepts in the context of computerised land administration systems.

Adaption of existing LADM

The first adaption of LADM resulted from the need to port the UML Class Diagram definition of LADM (as it is defi ned), into a Relational Model in order to implement it in the most common form of current database technologies. For each package in LADM a schema is introduced in the SOLA database. The LADM Survey package was not ported because it was decided to directly use the Spatial Type extension provided by the relational database management system (in this case PostgreSQL with the PostGIS spatial extension).

Extensions

It became apparent at an early stage that the SOLA database would need further schema and data elements over and beyond LADM in order to support the generic cadastre and registration process and to meet the identified requirements for the SOLA software. These extensions include:

• Case Management

• Long Transaction Handling

• System Support

• Specialisation of LADM LA_SpatialUnit Object

GeoTools library (Spatial GIS components)

Handling of spatial information in SOLA software is required on both the server and client side. As with all spatial data within a GIS, it is necessary to be able to configure the visualisation of the SOLA spatial data and to be able to manipulate it (delete, insert, update). Figure 2 describes the overall handling of spatial information within the SOLA software.

Server side GIS services

Various options for server side GIS solutions were investigated including GeoServer which offers WMS for visualisation purposes and WFS-T for manipulating spatial data.

The GeoServer option was not adopted with the SOLA software because it would have necessitated an external means of manipulating the spatial dimension of objects and a different means, internal within the SOLA software, for manipulating the nonspatial attributes describing the same object. If the GeoServer option had been adopted it would have introduced a complex overhead in making sure the two means of data manipulation were synchronised in terms of data commits and data rollbacks especially in the case of an interrupted data manipulation transaction.

Figure 2 – Spatial Information Handling in SOLA software

In order to have one consistent way of handling information within the SOLA software, regardless of whether it was spatial or not, the spatial definition of objects is treated just like other attribute data belonging to an object. Through this approach it is possible to use the same elements within the SOLA software architecture to persist objects which have a spatial definition. Another advantage of this approach is that the business rules can utilise both alphanumeric and spatial conditions seamlessly when applied at the database level.

This decision meant that it was no longer necessary to utilise a WFS-T service external to the SOLA software to manipulate spatial information as this could more effectively be done within the SOLA software architecture.

Client side GIS

In investigating options for the client side GIS, it was decided the best solution was to use the open source Geotools library (www.geotools.org). This library offers a solution for rendering spatial data into images where it is applied to a de?? ned symbology. The Geotools library integrates with the Java Topology Suite package (http://www.vividsolutions. com/jts/JTSHome.htm) and hence can be used for spatial operations.

As far as GIS user interface libraries, a drawback with Geotools is that it only offers a very basic map control and only a few basic tools. Because this library uses raw data to translate into spatial objects and from there it can render them by applying an open geospatial standard symbology definition (http://www.opengeospatial.org/ standards/sld), the SOLA Client Side GIS (like the SOLA Server Side GIS) does not need external WMS services for rendering maps. The main extension to the Geotools routines made by the SOLA software deals with adding more sophisticated functionality to the user interface presentation of the map and a wider range of tools such as those for handling on-screen editing, snapping and creating a table of layers.

The SOLA Geotools based Client Side GIS could also be used to render WMS layers (in addition to spatial data sourced directly from the SOLA database) if the agency implementing the SOLA software chose to use WMS for rendering a range of spatial data including but not limited to the SOLA sourced data.

Customisation

Within the SOLA project, the SOLA software will be piloted in three FAO member countries: Ghana, Nepal and Samoa. This pilot activity will involve two stages. Firstly the initial generic SOLA software will be adapted by local teams of software developers in each of the pilot countries for use in their countries. These adaptions will modify and potentially extend the software to support the cadastre and registration processes in that country taking into account local land records, practices, laws and regulations. Secondly, the customised software will be implemented in at least one land office in each country and the SOLA project will support this implementation along with the local SOLA software support arrangements.

As of the first quarter of 2012, software customisation has begun in Nepal and Samoa with Ghana planned to start in the second quarter. Later in 2012, the locally customised versions of the SOLA software will be piloted in land offices within these three countries.

Extension mechanisms

The SOLA software architecture has been speci?? cally designed to enable the software customisation necessary in each country. Specific mechanisms in the SOLA software architecture which may be used in SOLA customisation work are:

• New web services can be added into the SOLA Services Layer to provide additional functionally.

• WS – * Interoperability Standards are supported to ensure compatibly with non java technologies. I.e. The SOLA Web Services can be integrated with .NET client applications while maintaining the SOLA security model.

• Enterprise Java Beans are used to implement the Entity, Control, Boundary (ECB) pattern within the web services.

• User Interface Localization is supported through use of Java Resource Bundles. This includes screen labels and all messages displayed as well as localization of reference data display values.

• Repository provides flexibility in the database technology used by the SOLA software allowing investments in existing database technologies to be used (instead of, or alongside of the SOLA PostgreSQL database).

• Database Schemas – Although the SOLA software utilises just one database, several schemas have been used to segment the data layer and ensure the separation of data based on the service that utilises the data. An example where this would be of benefit is where the organization has an existing Digital Archive. In such a situation, the Digital Archive Service could be updated to use the existing archive without impacting the other services provided by the SOLA software.

• Rules Engine – Business rules have been implemented using a custom SQL rules engine that allows the rules to be updated to change the behaviour of the application without requiring the compilation and redeployment of the entire SOLA software application.

• Workflow Processing – The SOLA software adopts the concept of services. Services are intended to identify broadly the actions the land office will take to process an application involving one or more land office services. It is possible for developers to create new screen flows for new services that “plug in” to the SOLA Desktop application management functions developed in the initial generic SOLA software. Similarly, new or modified business rules can be written to ensure applications only proceed through crucial stages when all the pre-requisites have been met.

Open source license

The SOLA software uses the open source “Modified Berkeley Software Distribution (BSD)” license. It is a very simple licence and one of the least restrictive in terms of what and how the software can be used. There are only three clauses:

• All source code must be redistributed with the original copyright notice

• All binaries must be redistributed with the original copyright notice in the accompanying documentation

• The names of the contributors and the copyright holder (in the case of the original software, this is FAO) cannot be used to endorse or promote products based on the software without prior written permission.

The reason for using a permissive open source licence is to encourage adoption of the SOLA software by both national land administration agencies and private software development companies.

Conclusion

In the publication “FLOSS in Cadastre and Land Registration” (Steudler et al, 2010), the comment is made that there was “little knowledge and experience yet available on the introduction of opensource systems in land registration and cadastral systems”. The release of the initial generic SOLA software means that this deficiency has now been addressed.

References

McDowell, A. (2011). Software Architecture Document – Initial “Solutions of Open Land Administration” Software, NRC L and Tenure Team, FAO.

Pullar, N., McDowell A., Manoku E., Solovov A., & Rizzo M.P (2012). Solutions for Open Land Administration (SOLA) Software – Customising Open Source Software to Support Land Administration Services and Responsible Land Governance, presented at the World Bank Land and Poverty Conference, April 2012.

Steudler, D., Törhönen, M. & Pieper, G. editors (2010). FLOSS in Cadastre and Land Registration – Opportunities and
Risks, published jointly by FAO and FIG.

This article is an abbreviated version of a paper with the same title presented at the “Annual world bank conference on land and poverty” The World Bank – Washington DC, DC, April 23-26, 2012.