Map Integration and Customization Framework

Design a Service Oriented Customizable Framework to Manipulate GIS Data “Map Integration and Customization Framework” P.A.G. Nonis and D.D. Karunaratne University of Colombo School of Computing, No. 35, Reid Avenue, Colombo 00700, Sri Lanka. [email protected], [email protected]

Abstract Whole activities in the World Wide Web have been dramatically inspired and enhanced by the concept of Service Oriented Architecture. This concept has influenced the GIS world also. More and more sophisticated Service Oriented GIS applications are developed by various interested groups around the world. Though, still there is no a satisfactory framework for the sake of building geo-spatial services as web services. We propose the design of a Service Oriented customizable GIS framework, where the capabilities of both proprietary and open source GIS tools and utilities are wrapped into geo-spatial web service methods. These geo-spatial web services are published in a localized web service registry implemented in the framework. In addition we intend to develop an AJAX library for customizing the services in the registry to create interactive web mapping applications. Free and Open Source Software will be used in the technical design of the framework. Index Terms—GIS, SOA

1. Introduction eographical Information Systems are found in all over the world. The services provided by each of these systems may vary according to the purpose of service providers and as well as the community they intend to serve. In most of these services there is an underlying mechanism of manipulating geographic data and presenting the processed information over those data to outside world. There are numerous kinds of frameworks and services designed by various interested groups around the world to

G

support geo-spatial data. These frameworks may vary from white box frameworks to black box frameworks. In white box frameworks, it's essential to understand very well the mechanism behind those and user should program them in order to come with a product. And in black box frameworks, the framework users do not need to learn about the framework internals in detail [5]. When concerning the existing GIS frameworks, most of them are provided by proprietary organizations. Further, these proprietary frameworks are expensive, have various limitations are capable in utilizing only the products belong to corresponding organization. On the other hand even there are frameworks designed by open source communities, dealing with those software is quite hard. Hence users have to get over a lot of difficulties, when customizing existing functions to be suited to their needs. Further, still there is no a satisfactory framework for the sake of building geo-spatial services as web services, to enable geo-spatial services to be integrated with large array of web services available over the Internet. Therefore, it is clear that there is a need of a customizable framework which can be used with both proprietary and open source GIS products to manipulate GIS data and exposing those facilities by mean of a web service. The main objective of this project is to design a customizable framework to: • Promote users to build Web Services over GIS functionality. • Allow users to build customized user interface by integrating available Web Services. Hence the opportunity of utilizing these functions is offered to users via web instead of working with a standalone application. User will be able to sort out the most appropriate services out of the available services and

customize his/her applications in an easier manner. In addition to above, service could be further extended as a business service. By making the framework service oriented, the available facilities could be combined to make large number of business applications and on the top of available services by searching a directory service in which, users could deploy and publish their own GIS business services. In this paper, it is basically focused on the Server-side components of the “Map Integration and Customization Framework”. There the requirement analysis and design is also focused on the Server-side components. The remainder of this of this paper is structured as follows. Section 2 contains the literature review and information about the background work related to the project. Section 3 lists identified requirements and Section 4 explains our design architecture in detail. Section 5 discusses our framework implementation. Section 6 describes the testing strategies used to test the framework and next the Section 7 derives the conclusion of the project by explaining its contributions and future enhancements.

2. Literature Review 2.1. Service Oriented Architecture (SOA) & GIS Service Oriented Architecture was developed for the sake of supporting to build applications that integrate existing computing technologies into solutions based systems. In the service oriented architecture web services are bundled together with the purpose of communicating with each other by simple data passing or coordinating supposed activities [1]. According to the model developed by IBM, Service Oriented Architecture can be simply demonstrated as three entities; web service provider, web services requester and web service broker. As described in the previous section the bond between service requester and service provider is loosely coupled. When it comes to the geo-spatial domain, GIS services can be offered as web services. These GIS services could be categorized into three groups as Data Services, Processing Services and Registry and Catalog Service [4], [3]. If above services are bundled together as three entities according to the normal SOA definition, the representation of those services with their main functionalities, is shown in the diagram in Figure 1.

2.2. GIS frameworks examples Note: A more detailed analysis of existing GIS

Fig. 1. Service oriented architecture with geographical information services. frameworks could be found at [2]. 2.2.1. p.mapper. p.mapper is a free map server template system which is implemented with PHP MapScript, and offers an attractive user interface. PHP is the main implementation language and framework has the clientserverside architecture. UMN MapServer and PHP/MapScript are the prerequisites of p.mapper 2.2.2. Google Maps. GoogleMaps is a JavaScript API for the integration of dynamic maps into any web site. GoogleMaps has purely client-side architecture and implemented by using JavaScript. 2.2.3. ka-Map. ka-Map intends to provide a JavaScript API for the development of highly interactive web mapping interfaces. It has been implemented mainly by using both JavaScript and PHP. ka-Map follows clientserver side architectural design and UMN MapServer and PHP/MapScript are prerequisites.

2.3. Available SOA & GIS Related Work 2.3.1. GeoNetwork opensource. GeoNetwork opensource is a standardized and decentralized spatial information management environment, designed to enable access to geo-referenced databases, cartographic products and related metadata from a variety of sources, enhancing the spatial information exchange and sharing between organizations and their audience, using the capacities of the internet. It implements both the Portal component and the Catalog database of a Spatial Data Infrastructure (SDI) defined in the OGC Reference Architecture. It provides tools for managing and publishing metadata on spatial data and related services [13], [14]. 2.3.2. MapBuilder. MapBuilder is a powerful, standards compliant geographic mapping client which runs in a web browser.[15] Supporting the OGC standards, Supporting editing map features to Transactional Web Feature Services (WFS-T) and Allowing users to build their own maps, then save and share them, using Web Map Context

(WMC) and Open Web Services Context are some of the key functionalities offered by MapBuilder [15]. 2.3.3. OpenLayers. OpenLayers is a pure JavaScript library for displaying map data in most modern web browsers, with no server-side dependencies. OpenLayers implements a JavaScript API for building rich web-based geographic applications, similar to the Google Maps and MSN Virtual Earth APIs, with one important difference. Furthermore, OpenLayers implements industry-standard methods for geographic data access, such as the OGC WMS and WFS protocols [16]. Supporting for a variety of data sources, Supporting for displaying geographic features, with markers and popups and the easiness of building and configuring framework into other applications can be considered as the key features of OpenLayers.

3. Requirements Analysis As discussed in the Introduction, the scope of this project is to design the Server-side components of the “Map Integration and Customization Framework”. Therefore, first of all we have to focus on the functional and non-functional requirements at the Server-side. • • •

• • •

•

Geo-spatial functions should be exposed as geospatial web services. Different geo-spatial web services should be integrated in order to accomplish a task. Both geo-spatial web services and general web services should be mashed up in order to accomplish a task. These geo-spatial web services should provide GIS information retrieving as well as storing facilities. These geo-spatial web services should comply with OGC geo-spatial service standards. There should be a web service registry to publish those web services and that web service registry should provide an API to publish and inquiry web services. The operations of the web service registry should be UDDI standards compliant as well as localized to GIS domain.

4. Design According to the requirements identified in the previous chapter, now we are going to analyze the Server-side design aspects of the “Map Integration and Customization Framework”. Even though the Server-side components are loosely coupled with the Client-side components or the

AJAX library, the technical interfaces of the Server-side components should be mutually connectable with those of Client-side components. In order to achieve this objective, we maintained the system design in conformity with the OGC standards. The overall system architecture of the “Map Integration and Customization Framework” is depicted in Figure 2. Each component of the architecture and its functionality will be demonstrated in the latter sections.

4.1. System Architecture Components Since our main development objective is towards the Server-side aspect of the framework, the Client-side components such as Thin Client and Rich Client are described relatively in brief. 4.1.1. Services. These are the OGC compliant geo-spatial services which are invoked through CGI (Common Gateway Interface) parameters (E.g. WMS, WFS and WCS). In our framework these services are hosted primarily by using the GIS software like UMN MapServer. 4.1.2. Map Service. Map Service is one of the most important Server-side components of the system architecture. The basic task of this component is transforming the functions of above mentioned CGI geospatial services to general web service methods. For an instance consider the WMS GetCapabilities function. Normally this method is invoked by setting parameters through HTTP GET or POST and sending to the GIS server. In the Map Service layer, a wrapper is introduced to that function and that wrapper act as a web service method. In other words the Client-side components call the WMS GetCapabilities method through a SOAP message instead of preparing explicitly the statement to be executed at the GIS server. Most of the complicated tasks are handled inside the corresponding wrapper. 4.1.3. Map Client. There may be situations where a certain Map Service wrapper is still complicated to be manipulated by some Client-side components such as Thin Clients. Here the Map Client acts as an intermediate layer which prepare and processes the SOAP messages on behalf of the Thin Client. In brief, the purpose of this component is to manipulate Map Services through simple HTML clients instead of complex AJAX clients.

4.1.4. phpUDDI. phpUDDI is another one of the most important Server-side components of the system architecture. This acts as the registry in which all the business and technical information about the Map Services are published. phpUDDI was designed by

going to have an in depth analysis of the design concerns and technical implementations of both these components.

5.1. Map Service layer Implementation According to the definition given in the previous section, the main objective of the Map Service layer is converting the CGI geo-spatial services to general web service methods. Let us consider the WMS GetCapabilities CGI example again. The ordinary way of invoking this method will be in the following form. http://localhost:88/cgi-bin/mapserv.exe?MAP=/ms4w/apps/gmap /htdocs/gmap75_wms.map&SERVICE=WMS&VERSION=1.0.0&R EQUEST=GetCapabilities&FORMAT=text/xml

Fig. 2. The system architecture. deriving and localizing the essential features that a UDDI registry must have, according to standard UDDI specifications. 4.1.5. Configuration Interface. This component is developed as the interface to publish and manipulate Map Services in the phpUDDI registry. Some portion of this interface is supposed to be merged with Client-side AJAX library.

After implementing a wrapper in the Map Service layer for WMS GetCapabilities CGI method, it would be invoked as in Figure 3. The explanation in Figure 3 may be a considerable evidence to assert that the Map Service layer can be used to establish a consensus of XML messaging for OGC CGI geo-spatial services. In the Map Service layer, the wrappers for these CGI geo-spatial services are implemented using PHP 5 scripting. These wrappers are then converted to web service methods using the WSO2 Web Service Framework for PHP (WSO2 WSF PHP) [17]. The published services have to be consumed by service clients. These service clients should be capable of creating SOAP messages. According to WSO2 WSF PHP technical specification it can be done in two ways. First one is the PHP implementation and the second in the AJAX implementation. Rich Client-side components could

4.1.6. Rich Client. The Rich Client component contains an AJAX library, which supports the main functionalities of web map browsing and capable of consuming Map Services directly. Fig. 3. GetCapabilities xml. 4.1.7. Thin Client. This component is developed to support web map browsing with basic HTML interfaces. Thin Client component and Map Client component can be integrated accordingly in order to develop effective simple web mapping applications.

5. Implementation As discussed in the above section, the Server-side implementation basically consists two important parts i.e. Map Service layer & phpUDDI registry. Now we are

invoke the services directly with the AJAX service clients. Nevertheless, there would be situations that the Client-side components are simple and unable to use AJAX. There the Map Client which is implemented using PHP service client is used as an intermediate layer between Thin Clients and the Map Service layer. At the moment we have implemented certain geospatial methods defined by OGC such as Web Map Service [7], Web Feature Service [8] and Web Coverage Service [9]. In addition we introduce a new service called

Map Integration and Customization Service (MIC) which contains four localized geo-spatial methods. The MIC GetMap method which inputs dynamic parameters like zooming values, pointing coordinates at once and returns a web map template containing the references to all required image components such as reference map, legend graphics, scale bar etc. generated at the GIS server. Three other methods (MIC Transaction_Insert, Transaction_Update & Transaction_Delete) are implemented by considering OGC WFS Transaction operations. These operations support inserting, updating and deleting geo-spatial information reside at GIS databases like PostGIS server and MySQL server with spatial extensions.

5.2. phpUDDI registry Implementation Simply, phpUDDI is a localized version of the standard UDDI registry. During the design of the phpUDDI, four out of five major data entities in the standard UDDI specification [11] are concerned i.e. businessEntity, businessService, bindingTemplate and tModel. In addition two more secondary data structures named authToken and publisher are also considered. 5.2.1. Database design. The tables and their attributes of the phpUDDI database are listed below. ƒ businessEntity {businessKey, authorizedName, operator, discoveryURLs, name, description, identiferBag, categoryBag, LUT} ƒ businessService {serviceKey, businessKey, name, description, bindingTemplates, categoryBag, LUT} ƒ bindingTemplate {bindingKey, serviceKey, description, accesspoint, hostingRedirector, tModelInstance, LUT} ƒ tModel {tModelKey, authorizedName, operator, name, description, overviewDoc, identifierBag, categoryBag, LUT} ƒ authToken {authToken, publisherId, created, lastUsed, tokenState} ƒ publisher {publisherId, publisherName, email, isAdmin, isEnabled} The phpUDDI database is implemented using MySQL server. Service Interface design. In order to be compliance with the UDDI standards, the API functions of the phpUDDI have to be implemented with SOAP messaging support [10], [12]. In other words all those functions should be exposed as web services. First and foremost the phpUDDI API functions are categorized into three categories:

publish, inquiry and phpuddi. At the moment we have implemented 22 most important operations in the phpUDDI.

5.3. Technology Stack “Map Integration and Customization Framework” is primarily developed using Open Source software. The overall stack of technologies used in the development is listed below. ƒ UMN MapServer 2.2.4 ƒ Apache 2.2.6 Web Server ƒ PHP 5.2.4 ƒ WSO2 PHP Web Service Framework 1.2 ƒ AJAX ƒ MySQL 5.0/PostGIS 1.2.1 for PostgresSQL 8.2 Figure 4 demonstrates the way that the technologies are integrated in the system architecture.

6. Testing & Evaluation Service layer and the phpUDDI are the main components of the system design. In the process of testing, both these components were tested separately.

Fig. 4. Technology stack.

6.1. Testing Map Service layer The basic requirement of the Map Service layer is just creating web service methods for OGC geo-spatial CGI functions. The integration of these functions in a web mapping scenario has to be handled by the Client-side components. Hence, assuring the correctness of the each individual method's functionality would be sufficient. The Map Service layer was tested by following unit testing approach. OGC geo-spatial CGI functions were entirely tested on UMN MapServer environment.

ƒ

6.2. Testing phpUDDI • Since the phpUDDI is a localized version of the UDDI specification, it is not essential to test whether the API functions follows strict and more detailed UDDI standards. Hence the main concern was testing whether API functions were manipulated as web service methods and basic UDDI data structures have been implemented. This objective can be achieved by following unit testing approach. In addition, testing of the overall functionality was also concerned in order to ensure that the phpUDDI can be utilized as a geo-spatial service registry by the Client-side components.

6.3. Evaluation During the development of both Map Service layer and phpUDDI, most of their components were informally tested while coding from the scratch. Therefore in the process of testing each of these major components, no severe bugs were found except a fistful number of trivial coding errors which were fixed on the spot. As a whole, the initial testing process of the Sever-side components of the “Map Integration and Customization Framework” was conducted successfully and the Server-side functionality can be evaluated as satisfactory.

7. Conclusion & Future Work Promoting users to build Web Services over GIS functionality and allowing users to build customized user interface by integrating available Web Services were the main objectives of this project as stated in the beginning of the thesis. Because of the project scope was then narrowed down to the design of Server-side components, our main focus was to achieve the first objective.

7.1. Contribution The main contribution of this project is listed as below. • Map Service layer was introduced to wrap the OGC geo-spatial functions as geo-spatial web services. The following objectives were accomplished by this component. ƒ Exposing geo-spatial functions as geospatial web services. ƒ Integrating different geo-spatial web services in order to accomplish a task. ƒ Providing the facilities of GIS information retrieving as well as storing, through geospatial web services.

Creating OGC geo-spatial standards compliant geo-spatial web services. phpUDDI was introduced as the web service registry. This component fulfills the following requirements. ƒ Acting as the web service registry to publish geo-spatial web services. ƒ Providing an API to publish and inquiry web services. ƒ Being compliant with UDDI standards.

7.2. Future Work Though the most important requirements have already been fulfilled, the expected functionality of the Serverside components could be enhanced by concerning following aspects. • Developing an Object Oriented wrapper library by which, the geo-spatial web services can be created in an easier manner. • Implementing all the other OGC geo-spatial functions in the Map Service layer. • Continuing the development of phpUDDI as an alternative PHP implementation of the UDDI registry. • Extending the geo-spatial web service support for mobile applications (PDAs and Palmtops).

8. References [1] E. Cerami. (February 2002) Web Services Essentials (2nd ed.), O'Reilly. [2] E. Schtze, Current state of technology and potential of Smart Map Browsing in web browsers, 01 June 2007. [3] Z.R. Peng, Services-Oriented Architecture in Internet GIS, GIS Development, [Online] Available: http://www.gisdevelopment.net/magazine/years/2005/oct/w ebgis1.htm, October 2005 [4] GIS Service Oriented Architecture, [Online] Available: http://complexity.ucs.indiana.edu/asayar/gisgrids/docs/gissoa.pdf, 09 November 2007. [5] M.E. Markiewicz, C.J.P. Lucena, Object Oriented Framework Development, [Online] Available: http://www.acm.org/crossroads/xrds7-4/frameworks.html, 17 October 2007. [6] Geographic Information System, Wikipedia (30 June 2008), [Online] Available: http://en.wikipedia.org/wiki/Geographic information system.htm , [7] J.D.L. Beaujardiere, OpenGIS Web Map Server Implementation Specification, Open Geospatial Consortium Inc, 15 March 2006.

[8] P.A. Vretanos, Web Feature Service Implementation Specification, Open Geospatial Consortium Inc, 03 May 2006. [9] A. Whiteside, J.D. Evans, Web Coverage Service (WCS) Implementation Specification, Open Geospatial Consortium Inc, 17 October 2006. [10] T. Bellwood, UDDI Version 2.04 API Specification, UDDI Committee Speci_cation, [Online] Available: http://uddi.org/pubs/ProgrammersAPI-V2.04-Published20020719.htm, 19 July 2002. [11] C.V. Riegen, UDDI Version 2.03 Data Structure Reference, UDDI Committee Specification, [Online] Available: http://uddi.org/pubs/DataStructure-V2.03-Published20020719.htm, 19 July 2002. [12] L. Clment, UDDI Version 2.01 Operator's Specification, UDDI Committee Speci_cation , [Online] Available: http://uddi.org/pubs/Operators-V2.01-Published20020719.htm, 19 July 2002. [13] GeoNetwork opensource Community website, [Online] Available: http://geonetwork-opensource.org/, 26 March 2008. [14] GeoNetwork opensource Project Info Sheet, OSGeo , [Online] Available: http://www.osgeo.org/geonetwork.htm, 03 April 2008. [15] B. McWhirter, A. Hocevar, Mapbuilder Home, [Online] Available: http://communitymapbuilder.osgeo.org/display/MAP/Home - Codehaus.htm, 26 December 2007. [16] OpenLayers Info Sheet, OSGeo, [Online] Available: http://www.osgeo.org/geonetwork.htm, 03 April 2008. [17] WSO2 WSF/PHP API documentation, WSO2 Inc, [Online] Available: http://wso2.org/project/wsf/php/1.2.0/docs/api.html, 2008.