GISdevelopment.net ---> Application ---> Land Information System



Geospatial Interoperability via the Web: Supporting Land Administration in Kuala Lumpur


Mr Sanphet Chunithipaisan
Sanphet.Chunithipaisan@ncl.ac.uk

Mr Philip James
Philip.James@ncl.ac.uk

Prof David Parker
David.Parker@ncl.ac.uk

Mr Zainal Abdul Majeed
Mr Zainal Abdul Majeed
Zainal.Abdul-Majeed@ncl.ac.uk

Mr Simon Abele
Simon.Abele@ncl.ac.uk School of Civil Engineering and Geosciences
University of Newcastle upon Tyne
Newcastle upon Tyne, UK


Abstract
This paper highlights a number of issues currently facing the access, delivery and use of geospatial information (GI) via the World Wide Web (WWW, Web). Taking a practical, rather than conceptual approach, particular focus has been placed on the need for the identification and application of existing geospatial interoperable standards in addressing some of these issues. Therefore a range of solutions have been developed around the provision of land information and administration within Kuala Lumpur, Malaysia. As widely as possible existing geospatial interoperable standards, protocols and technologies have been used to develop solutions to the problems discussed in this paper. The research also highlights some of the problems encountered in implementing current geospatial standards.

Background and Motivation
There are a number of GIS used in organisations to manage, maintain and distribute their data. Organisations maintain and provide specialised data according to their functions, however in many cases users or even organisations themselves need other datasets for a particular application. The data integration between different systems is not straightforward and time consuming [1]. Likewise proprietary data formats are a major obstruction for data integration. Moreover, the addition and integration of data into existing databases poses many additional challenges.

The growth of Internet access and use coupled with advancements in web based technologies over the past decade has provided new possibilities for the access, delivery and use of GI [6]. In recent years the GI sector has begun to recognise the importance and role of the web for the dissemination of spatial information, with many GI technology vendors now offering extended systems of Internet Map Server (IMS) to their desktop products e.g. ArcIMS, Geomedia, GE Smallworld IMS. The development of such systems has introduced and highlighted issues pertinent to the use of GI via the web. However, such systems still require data in their own proprietary formats. Proprietary IMS also typically disseminate these data in a proprietary format. In many cases we need to combine and distribute data from multiple heterogeneous systems. This requirement is hard to achieve using existing GIS.

Several organisations are now actively involved in addressing the problems of geospatial interoperability. The most prominent of these being the Open GIS Consortium (OGC) which has developed and put forward a number of specifications and standards, aimed at promoting data sharing and dissemination amongst the GI community. Increasingly OGC specifications [5] are being adopted and implemented by GI technology vendors and users to provide solutions to the problems of web based GI dissemination. In particular; the Geographic Markup Language (GML) and web map services (e.g. Web Map Server (WMS), Web Feature Server (WFS)) looks set to play an increasingly crucial role in the future distribution of GI and services. The basic operation of requesting and retrieving data are performed via Uniform Resource Locators (URLs) and uses the Common Gateway Interface (CGI) protocol to pass the request details.

Aims and objectives
The aim of this research is to use current interoperable standards among other common technologies to develop a solution for data interoperability and resolve the issues of proprietary systems and data integration from multiple heterogeneous data sources. The objectives can be given as follows.
  • To investigate the current open standards, protocols and technologies capable of resolving the issue of data integration and dissemination.
  • To investigate and test existing open geospatial web service e.g. Minnesota WMS.
  • To use GML for vector online data format.
  • To implement WFS for GML server to serve GML online.
  • To design a common ad hoc database for data import/export in order to manage the data before dissemination
  • To develop intelligent middleware capable to get the user requests for query vector/raster data from various different geospatial data web server, to retrieve the data as user requires, to combine those data together and finally to hand it back to the client user.
  • To develop a web based GIS application that supports data request, retrieval, integration and presentation.
Kuala Lumpur Test Case
The Department of Survey and Mapping Malaysia (JUPEM) is among the main government organizations providing high quality spatial data, survey and mapping products and services to the government, business, public and individuals for the purpose of national development, security and defence.

In line with the government's effort to push Malaysia to achieve developed nation status by the year 2020, there are various initiatives that have been drawn up to bring the country closer to that objective. One of this is the e-government initiative of using technology for the improvement of many services and sale of various products rendered by JUPEM.

JUPEM has about 1.9 Terabytes (TB) of digital spatial data which are available for government, business, and public and individual’s consumption [2]. Basically, three datasets from JUPEM pertaining to the above types of digital spatial data were utilised for the implementation of the research task. The followings explain the data supported by JUPEM.
  1. Cadastral data or land parcel data are handled by the states JUPEM. The data are produced and stored in the form of continuous database and raster file data. The data are produced from field survey in the form of vector point, line and polygon geometry. Raster data are scanned images of the certified plan stored in the database for Internet browsing. Land parcel data were produced using ESRI’s ArcView and Geomedia. The coordinate system applied to the vector data is the local Cassini-Solder.
  2. Topographical mapping data are handled by a section at JUPEM Head-Quarters called CAMS (Computer Assisted Mapping System). The data are produced and stored in the form of vector file namely DST and DXF. The production process used the Norwegian GINIS software to digitise hardcopy map and aerial photograph, and to produce vector map from field topographical survey. The Rectified Skew Orthomorphic (RSO) coordinate system is applied to topographical mapping data.
  3. Aerial/Orthophoto images are produced and stored in digital and hardcopy form by the Aerial Photography Section in JUPEM.
As mentioned these datasets are collected, stored, and maintained in several sections as well as in different systems. These datasets have been chosen for use in this research due to their heterogeneous and proprietary nature in terms of format, resolution, and source, amongst others. The combination of these heterogeneous and proprietary factors offers good examples of the problems regarding geospatial interoperability [3]. The implementation undertaken in this research uses current interoperability standards to serve to a standard web browser both JUPEMs’ raster and vector data.

Facilitating this, a range of datasets, pertaining to land and map information from JUPEM within the Federal Territory of Kuala Lumpur (FTKL), a state of Malaysia, has been used. As mentioned, this research used three types of spatial data namely, land parcel data, topographic data and aerial images. These data are chosen to highlight issues and provide a basis for exemplifying possible solutions to the problems of GI distribution via the web.


Figure 1: Context diagram of the single portal access of the various data

Methodologies
We approached development of a web based Land Information System (LIS) through the construction of a 3-tier web service architecture, comprising a client, middleware and server. Freely available, open, interoperable specifications, standards and technologies have been implemented as widely as possible at each level of this architecture. This research mainly focused on the construction of middleware providing the bridge between client and server tiers to support raster and vector geospatial data request, retrieval, integration and presentation. The methodology of this research can be broken down into three stages corresponding to the 3-tier web service architecture previously described.
  1. Server – In order to serve raster and vector geospatial data from multiple sources via the web we have implemented the OGC WMS and WFS specifications. Basically WMS and WFS enable users to request the geospatial data and retrieve the results in various formats. WMS produces the requested geospatial data in a variety of raster formats (e.g. GIF, JPG, PNG), whilst WFS produces vector data, typically, in GML. Due to the resulting data type returned from the server, WMS is sometimes called an image server, and WFS is called a GML server. This research has im3plemented an example of both specifications to deliver geospatial data as requested. We utilised the Minnesota map server [4] for the image server. This map server provided the mechanism to create and render image maps from Shapefile data (ESRI data format). We also developed the GML server in order to provide the vector data in the form of GML.
  2. Middleware – The middleware enables the application to retrieve the geospatial data from different servers. It utilised Java servlet [7] supporting CGI. This servlet enables the server to communicate with the client via the URL. There are four main functions that the servlet middleware performs:
    • getting the user request;
    • connecting and retrieving data from map servers;
    • combining the requested data;
    • delivering the resultant data back to the client application.
  3. Client – A client map viewer has been developed to render the data requested by the servlet. This application typically provides several common GIS functions e.g. pan/zoom, querying and rendering. This application was developed using Java technology. The applet is an application that is able to run on a web browser.
Additionally a relational database (RDB) was used to create an ad hoc database in order to integrate data into a single source to ease data management. The RDB structure to store the geospatial data has been adopted and adapted from [1] (Figure 4). This type of RDB is often referred to as a Spatial Relational Database (SRDB).

Implementations

Data Preparation
For this research a test area was chosen covering commercial, industrial, forested and residential portions in the Mukim of Damansara, one of the province-like administrative regions of the state of FTKL. As mentioned previously, three types of JUPEM datasets relating to spatial data of land administration and geographic map features were selected wrapping the tested area i.e. land parcel data, topographic map data and aerial images.

Initially, five high resolution aerial photographs acquired from Aerial Photography Section were rectified using ground control point (GCP) from digital topographic features. After given a spatial reference, the five photographs were mosaicked producing a larger image of the test area. ERDAS IMAGINE software was utilised for these tasks. It was then gridded into small bounding rectangles covering the relevant area for the implementation of the application. During the process it has to be transformed from raster TIFF file to ERDAS IMAGINE (.img) format and finally to JPEG format file to achieve a lower resolution and compact file size image in order to distribute on the web.

The topographic vector data, in six map sheets, obtained from CAMS section was originally in DXF file format. It contained features of point, line and polygon geometry describing various dataset categories namely boundary, water, building, relief, transport, utility, vegetation and landuse.

The third data, being the land parcel data of the whole of FTKL was utilised as a land administration and survey data coverage. The spatial information in the land parcel data includes land parcels boundaries, boundary markers and coordinates of boundary markers. The attribute information includes unique parcel identifier, lot number, parcel area, surveyed bearings, and surveyed distances, type of boundary marker, date surveyed and date approved. Digital cadastral data is used by a variety of organizations for asset management, development planning and GIS. Since the data was in their local Cassini Soldner coordinate system, transformation of coordinates to an RSO coordinate system was carried out. The coordinate transformation was undertaken in ArcGIS.


Figure 2: The topographical data being overlay on an aerial images of the test area.



Figure 3: The land parcel data being overlay on an aerial images of the test area.

Land parcel features and topographical map features were converted into SRDB format. The conversion tools were developed to run either independently or on top of GIS (e.g. ArcView).

Designing the Spatial Relational Database
An SRDB was utilised as an ad hoc database for data interchange and management. The structure of SRDB was adopted and adapted from [1] (Figure 4). It provides the structure and associations for fundamental spatial objects e.g. point, chain and area. It contains seven predefined tables storing the geometrical object of point, chain and area.


Figure 4: Logical database model of SRDB

Figure 4 shows the logical database model of the SRDB. The structure of SRDB supports non-topological and topological data. Furthermore it also supports multi-geometry e.g. multi-point, multi-line and multi-polygon object. Thus it is widely used for any geospatial data structure and is straightforward to apply for GML geometry objects.

A relational database uses a common relational structure to organise data. Also, there are common standard tools widely provided for connecting to the database and querying data using Open Database Connection (ODBC) and Structured Query Language (SQL) respectively. Furthermore most GIS use relational database structures in their proprietary database. It is therefore relatively easy for system administrators to customise to provide data conversion tool between the proprietary database and other relational databases. Thus an SRDB was seen as a logical choice for database interchange, and conversion tools for ArcView and GE Smallworld have been developed and tested.

Implementing Feature Schema for Use with GML
GML has been used for online sharing data format. The simple feature schema was created regarding to common GIS database structure containing the feature attributes and geometry. The geometry object is encoded using GML geometry schema. Each feature object starts with the <Feature> element including XML attribute of fid to specify the feature unique identifier. The attribute elements are free depending on the attribute field or column in the database. The feature dataset starts with <RealworldFeature> element including attribute name and description to explain the description of feature. The elements for drawing the metadata and feature property were also designed. A sample of GML as used in this research is illustrated as follows.



Developing the Web Geospatial Server

WFS – GML server
The OGC WFS specification was implemented to develop the GML Server. It was developed using Java servlet technology. There have been two WFS operations implemented: GetCapabilities and GetFeature. The formats supported by the GML server include SRDB and Shapefile. The resultant GML from the server is as per the schema shown above.

WMS – image map server
A free map server, namely, the Minnesota MapServer was used as the image map server to service the map in raster format. This map server supports the ESRI Shapefile format and image data format. The CGI request is proprietary, but however it could be set to request in a compatible manner to OGC WMS specification [3].


Figure 5: The administrative area from GML server and Image Map Server

Developing Middleware for the Geospatial Data Connector
The intelligent geospatial data connector (GeoConnector) was developed using Java servlet technology. The capabilities of such GeoConnector include:
  • get the user request through the CGI protocol;
  • connect to other data server and retrieve the data via HTTP protocol as user required;
  • integrate the requested data and generate the final integrated objects;
  • deliver the required objects back to the client application.
The request data type can be either raster data or vector data in GML form. The protocol to retrieve data can be either the HTTP protocol if the dataset located on a different server or the FILE protocol when the dataset located in the same server as the GeoConnector. The working system of such geospatial data connector is illustrated as Figure 6.


Figure 6: The work model of GeoConnector

The GeoConnector enables users to request and retrieve the data in single GML or image from any single server through a URL. Additionally, it also supports the multiple data requests from multiple servers by sending a single request as so-called project request.

In order to retrieve data from many spatial servers and to combine those data by sending only one request, a project request is made. The project contains information which is required to be retrieved from the GeoConnector. The project request is encoded using XML. The sample of project is illustrated as follows.



The data requested can be retrieved from HTTP protocol located on different remote servers or FILE protocol whereby data is stored on the same server as the GeoConnector. HTTP address can be pointed directly to the file required or in a form of CGI request. The types of data supported include GML and image (PNG/GIF/JPEG).

Developing the Web Based GIS
An application was developed using Java technology. It provides common basic GIS tools e.g. pan/zoom, rendering and querying. User can open raster (image) or vector (GML) from any server by sending a request to the GeoConnector. This application also allows users to open GML or image data locally when running as signed/trusted application. When it runs as an applet, some application capabilities will be limited due to security reasons and problems imposed by the web.


Figure 7: The application GUI



Figure 8: Local and HTTP data open dialog



Figure 9: The rendering tool

Figure 7 shows the applications GUI. Several common GIS tools have been supported e.g. zoom/pan, query, rendering. Figure 8 shows the dialog offered to open data locally and remotely. An array of data formats are supported including image files, GML and Shapefile. Images and GML can also be retrieved using the HTTP protocol. Users can set a list of datasets in their own project and can open the project datasets in one request via HTTP. Figure 9 shows the rendering system which allows users to set the colour of features displayed by the system.


Figure 10: The sample of project in Kuala Lumpur area



Figure 11: The zoom-in area that contains lot parcel

Figure 10 shows the sample project datasets in the application. The project contains three main datasets: cadastre, topographic maps and aerial photograph images. These three datasets are stored in different servers and retrieved via the HTTP protocol.

Summary
This research has demonstrated the use of GI interoperable standards such GML and web service specification to facilitate data interoperability. Particularly in the case of JUPEM that requires data dissemination on the web from multiple different data sources, this clearly shows the possibility to retrieve and combine those data for visualisation and query over the web. With the GeoConnector tool, this enables the operating departments to keep using their existing proprietary IMS system without physical into all required data into a single IMS system. Additionally the SRDB is suggested for data interchange and also for ad hoc spatial database for manipulating and managing data. The research also demonstrates that is reasonably trivial to customise existing system to provide SRDB conversion tools.

Conclusion
This research has achieved the aims and objectives of implementing and utilising existing geospatial standards and technologies, e.g. OGC standards and specification (GML, WFS, WMS), HTTP, CGI, XML and RDB, to overcome the issue of data integration and dissemination from multiple heterogeneous systems. The application has clearly shown the successes of the concept of data integration on-the-fly from multiple heterogeneous GIS servers which supply the spatial web service. The SRDB was implemented and utilised to enable the construction of an ad hoc database capable of providing a solution to some of the issues of proprietary former discussed in this paper.

Acknowledgement
The authors would like to thank the Director-General of the Department of Surveying and Mapping Malaysia (JUPEM) in Jalan Semarak, Kuala Lumpur and the respective officers for preparing and supplying the useful datasets.

Reference:
© GISdevelopment.net. All rights reserved.