OPEN SOURCE GEO-WEB SERVICES FOR MOBILE DATA CAPTURE IN CADASTRAL

OPEN SOURCE GEO-WEBSERVICES FOR MOBILE DATACAPTURE IN CADASTRALAPPLICATIONS

ERVIN RAMONLLARIFebruary, 2011

SUPERVISORS:

B. J. Kobben MScDr. J. M. Morales

OPEN SOURCE GEO-WEBSERVICES FOR MOBILE DATACAPTURE IN CADASTRALAPPLICATIONS

ERVIN RAMONLLARIEnschede, The Netherlands, February, 2011

Thesis submitted to the Faculty of Geo-information Science and EarthObservation of the University of Twente in partial fulfilment of the requirementsfor the degree of Master of Science in Geo-information Science and EarthObservation.Specialization: Geoinformatics

SUPERVISORS:

B. J. Kobben MScDr. J. M. Morales

THESIS ASSESSMENT BOARD:

Dr.Ir. R. A. de By (chair)Ir. C. H. J. Lemmen

DisclaimerThis document describes work undertaken as part of a programme of study at the Faculty of Geo-information Science and EarthObservation of the University of Twente. All views and opinions expressed therein remain the sole responsibility of the author, anddo not necessarily represent those of the Faculty.

ABSTRACT

Nowadays mobile devices equipped with GPS receivers are being used worldwide for field datacollection. Cadastre information systems can benefit from using mobile device technology whereboth spatial and non-spatial data can be collected in the field. However, the mobile devices suf-fer from technological limitations such as small screen size, small memory and processing power,and furthermore they use wireless networks for communication which are unreliable and costlycompared to wired networks. Therefore, the design of a mobile data collection system requiresspecial attention. In this research we designed a mobile system for cadastral data collection whichcontains two components, a mobile device and an SDI node for mobile client – SDImobile com-ponent. The mobile device is used to capture cadastral data while SDImobile handles the commu-nication of the mobile device with other SDI nodes which offer resources (data/services). Further-more, SDImobile processes the input data from the mobile device and sends them into the cadastreSDI node. Although the design is based on a cadastre use case, this research aimed at designing ageneric and interoperable SDI node. For the purpose, we used service orientation paradigm to de-sign reusable and generic web services for the SDI node. By using open web standards we aimed atdesigning an interoperable SDI node. A proof-of-concept prototype was implemented and tested,using free and open source software. We believe that the use of a mobile device, supported bya generic and interoperable SDI node, is very promising and offers great potential for field datacollection applications.

Keywords

mobile device, SDI node, generic, interoperability, open standards, cadastre

i

TABLE OF CONTENTS

Abstract i

Acknowledgements vii

1 Introduction 11.1 Motivation and problem statement . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Research identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Research objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.3 Innovation aimed at . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.4 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Project set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.1 Method adopted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 User requirements for cadastral data collection 72.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Cadastre concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Cadastre systems in different countries . . . . . . . . . . . . . . . . . . . . . . . 82.4 Use scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.1 Business constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5.2 Quality attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.3 Technical constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.4 Accuracy constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Analyzing requirements for cadastre data collection 153.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Modeling and designing approaches . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 Development approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.2 The Unified Modeling Language . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Analyzing user requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.1 System in context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.2 Defining use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.3 Defining system architecture . . . . . . . . . . . . . . . . . . . . . . . . 213.3.4 Domain model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4 Designing the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.1 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

ii

4 SDI node for mobile client – SDImobile 334.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 SDImobile’s role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3 Analysis and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3.1 Service orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3.2 Service-orientation design principles . . . . . . . . . . . . . . . . . . . . 364.3.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5 Prototype implementation and testing 475.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2 Technology and tools for implementing mobile device client . . . . . . . . . . . 475.3 Technology and tools for implementing SDImobile node . . . . . . . . . . . . . 485.4 Prototype implementation and testing . . . . . . . . . . . . . . . . . . . . . . . 48

5.4.1 Mobile client implementation . . . . . . . . . . . . . . . . . . . . . . . 495.4.2 SDImobile implementation . . . . . . . . . . . . . . . . . . . . . . . . 505.4.3 Prototype testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Discussion, conclusions and future recommendations 556.1 Discussion on research questions . . . . . . . . . . . . . . . . . . . . . . . . . . 556.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.3 Recommendations for future work . . . . . . . . . . . . . . . . . . . . . . . . . 58

Bibliography 61

A Web Service design 67A.1 Schema definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.2 Interface definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

B Prototype implementation 83B.1 Mobile client GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83B.2 SDImobile implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

B.2.1 OGC Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86B.2.2 SDImobile functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 88

iii

LIST OF FIGURES

2.1 Field survey scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Mobile Data Collection System, Context Diagram . . . . . . . . . . . . . . . . 193.2 Survey Parcel Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Mobile Data Collection System, Logical Architecture . . . . . . . . . . . . . . . 243.5 Activity Diagram Refined to Include SDImobile Component . . . . . . . . . . 263.6 Domain Model, representing the conceptual classes in the problem domain . . . 273.7 Sequence Diagram showing the sequence of messages between objects . . . . . . 283.8 Class Diagram showing the design classes, their attributes, methods, and relation-

ships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 SDI node stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2 Service Candidates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3 Service Composition Representing Cadastral Survey Process . . . . . . . . . . . 414.4 Conceptual view of the service composition process in WS-BPEL . . . . . . . . 45

5.1 Measured points with Mobile Client . . . . . . . . . . . . . . . . . . . . . . . . 52

iv

LIST OF TABLES

3.1 Survey Parcel use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

v

LIST OF LISTINGS

4.1 Cadastral Property XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 435.1 WFS-T Request Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50A.1 Property Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.2 Address Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.3 Person Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70A.4 Utility Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70A.5 Surveyor Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71A.6 User Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71A.7 ProcessFeature Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72A.8 CadastralProperty Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75A.9 UserSession Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76A.10 SearchResources Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78A.11 CadastralSurvey Composite Service . . . . . . . . . . . . . . . . . . . . . . . . 79B.1 Mobile client GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83B.2 Web Feature Service configuration, Utility Lines . . . . . . . . . . . . . . . . . 86B.3 Web Map Service configuration, Cadastral Parcels . . . . . . . . . . . . . . . . . 87B.4 SDImobile functionality implementation - ASP/Python . . . . . . . . . . . . . 88

vi

ACKNOWLEDGEMENTS

This research thesis is the final result of my studies in Geoinformatics at the Faculty of Geo-information Science and Earth Observation (ITC) of the University of Twente. I would like toexpress my sincere gratitude to ITC and NUFFIC for giving me the opportunity to follow thisMaster of Science course. A special thank to ITC staff for creating such a warm environment andmaking the studies easier.

Special thanks to my first supervisor, MSc. Barend Köbben, for sharing his enthusiasm andpatiently guiding me throughout the research period. I would like to thank my second supervisor,Dr. Javier Morales, for discussing and sharing his ideas with me. Another person I would like tothank is Dr. Rolf de By for his useful pep talks and for making the thesis writing much easier.

This study period has been tough and intensive. The presence of my ITC friends has made iteasier for me and definitely a more enjoyable experience. I would like to thank here all my GFMclassmates and other ITC fellows.

Finally, I would like to thank my family for the support and encouragement: my parents, mygrandmother, and my brother and his wife. Especially, I would like to thank my wife:

– thank you my darling for being always there for me! –

vii

viii

OPEN SOURCE GEO-WEB SERVICES FOR MOBILE DATA CAPTURE IN CADASTRAL APPLICATIONS

Chapter 1

Introduction

1.1 MOTIVATION AND PROBLEM STATEMENT

The development of Information Technology (IT) has influenced the evolvement of GIS technol-ogy from traditional GIS towards distributed GIS, part of which is mobile GIS (Peng and Tsou,2003). The emergence of Mobile GIS brought new ways of geospatial data collection, processing,maintenance and dissemination (Mensah-Okantey, 2007). Nowadays, mobile GIS is being widelyused in field data collection, both in governmental and private enterprises. Cadastral applicationis one of the fields that can benefit from mobile GIS especially in developing countries wherethere are technical and financial difficulties in creating digital cadastral data acquisition systems(Mensah-Okantey and Köbben, 2008).

Land administration and cadastral systems are the foundation of the economic growth ofmany countries as they register the information on land. A cadastre system involves cadastralmapping (the spatial information) and land registration (the non-spatial information) (Lemmenand van Oosterom, 2004). While in developed countries information technology has been usedin cadastral systems during the last 2 decades, in developing countries, although there is need forsuch technology, there are financial and operational restrictions (Steudler et al., 2010).

Cadastral data acquisition requires field work and as such it is labour intensive, time con-suming and expensive. Existing methods of cadastral data capture are used to collect spatial andattribute data separately in the field. Spatial cadastral data are collected using traditional methodslike total stations, GPS, aerial photography, or other field measurements. On the other hand,the attribute data are recorded manually, using paper and pen. Later, both spatial and attributedata are processed and integrated in the cadastral office and then loaded into a database. But, thisapproach is time consuming, prone to errors and requires careful processing of gathered data.

As the GPS, internet, and wireless communication technology is evolving, mobile GIS offersgood possibilities for spatial and non-spatial data collection in the field (Peng and Tsou, 2003).In this respect, mobile GIS has the potential to facilitate cadastral data collection by integratingspatial and attribute data collection directly in the field. Further, as stated by Pundt (2002), mo-bile GIS tools can be designed in such a way that they can control the quality of captured datain the field. However, as any other technology, mobile GIS has few technological limitations.Such limitations are related to communication network, low bandwidth (Farkas et al., 2006), andmobile device limitations such as small screen size and processing resources (Biuk-Aghai, 2004;Casademont et al., 2004; Wilson et al., 2010). Despite these technological limitations, the mobiletechnology is widely used in location-based services (LBS) like real-time traffic information, rout-ing, finding the nearest attraction locations, and mobile GIS applications for communication andfacility management (Peng and Tsou, 2003).

An example of mobile GIS implementation in cadastral data collection is given by Mensah-Okantey (2007) who developed a prototype mobile GIS application for cadastral data collectionin Ghana. However, the mobile prototype has its own limitations. Firstly, it is built using propri-etary software and is platform-dependent (the mobile client application runs on mobile devices

1


equipped with Windows CE operating system), which means there are some license costs relatedto it. Nowadays, more and more countries are implementing and developing their own SDIs,which employ open standards and OGC-compatible geo-web services to ensure interoperability.Unfortunately, the prototype was not based on open standards and OGC services and interfaces,and as such it lacks the interoperability with other SDIs. Secondly, the research was more focusedon the cadastral processes in Ghana. Thus the prototype was built to support the cadastral dataacquisition in Ghana and offers no possibility for use in other countries.

1.2 RESEARCH IDENTIFICATION

1.2.1 Research objectives

The main objective of this research is to design a generic Spatial Data Infrastructure (SDI) nodewhich offers services that facilitate mobile data collection in a cadastral context. From the mainobjective of the research the following sub-objectives are derived:

• To study the user requirements for a cadastre data collection system;

• To design a generic SDI node following the user requirements;

• To study the existing free and open source technology that can be used to implement aprototype of the system;

• To build an interoperable and OGC-compliant prototype of the system, using the appro-priate technology;

• To test the functionality of the system’s prototype.

The group of users that can benefit from the proposed system are the field surveyors whocollect cadastral data and other interested actors in cadastral organizations.

1.2.2 Research questions

The following research questions are posed to guide this research and meet the objectives:

1. What are the user requirements for a cadastral data collection system?

2. What methods and techniques can be used to design a generic system that satisfies the user’srequirements?

3. Which free and open source technologies and tools can be used to build an interoperable,OGC-compliant prototype of the mobile system?

4. How to combine different technologies and tools to build a prototype of the system?

5. Does the prototype contain the required functionality for a cadastral application?

1.2.3 Innovation aimed at

This research aims at designing an interoperable and platform-independent SDI node, that offersgeneric functionality for facilitating mobile cadastral data capture. The generic nature of theSDI node and its interoperability with other SDIs is achieved by using OGC-compliant geo-webservices and open standards. Moreover, free and open source software (FOSS) are used to build aprototype of the SDI node, which also includes a mobile device client.

2


1.2.4 Related work

The use of mobile GIS for field data collection has attracted many researchers. Casademont et al.(2004) present an overview of the wireless technology — mobile devices and wireless networks— and positioning technology — GPS and differential GPS — that can be used in GIS. Theauthors also give an example of a wireless GIS platform (client and server components) created byintegrating the reviewed technology.

Hall and Gray (2004) developed a mobile system for field data collection with the main objec-tive to facilitate collaboration and coordination of surveyors in large field surveys. CoMPASS isanother mobile GIS application that offers the user GIS functionality such as navigation, spatialquerying and manipulation of vector-based spatial data (Doyle et al., 2010). The authors wereparticularly concerned with the interaction methods between the user and the mobile device.For that purpose they developed a multimodal interface for the mobile client and evaluated itsefficiency. Wagtendonk et al. (2004) developed a mobile GIS application for assisting the field sur-veyors in mapping crops in The Netherlands. The mobile application was built using proprietarysoftware (ESRI’s ArcPad).

Other researches are focused on the formats that can be used to display data in mobile GIS ap-plications. An example is MacauMap map application intended for tourism purposes (Biuk-Aghai,2004). The main concern of its design was the format used for map display in mobile deviceswith constraint resources such as limited memory and processing power. As a result the authorproposed a custom data format for use in the MacauMap application. Brinkhoff and Weitkämper(2005) studied the XML-based, Scalable Vector Graphics (SVG) format for representation of vec-tor data in maps. SVG format is complex and contains features that are not needed for GIS data,but on the other side, it is lacking some features needed in GIS. Therefore, the authors proposea format that is a restriction/extension of the SVG, which can fulfill GIS requirements for vectordata representation in Location-Based Services (LBS). In this context, another research proposesa format conversion algorithm which can be used to reduce the size of the map, making it moresuitable for use in mobile devices (Kim et al., 2004). Shi et al. (2009) have designed and tested adynamic data model for mobile GIS. This data model was implemented into a database whichprovided up to date information, relevant to the position of the mobile device. According to theauthors, the response time of the dynamic database was reduced to one-third as compared with aconventional database.

MAPPER (MAP PERsonalization) is a prototype GIS that implements an approach of pro-viding personalized information to the user (Wilson et al., 2010). Basically, it monitors the userinteraction with the map, and based on the gathered information, provides only the necessaryinformation to the user. According to the authors, this approach avoids information overload andincreases efficiency of interactive map applications.

Another research shows the possibilities of integrating Spatial Data Infrastructures (SDIs) andmobile technology for disaster management (Brinkhoff, 2008). In this research a three-tier archi-tecture was developed. The architecture’s components provide personalized map contents basedon the mobile device characteristics, the user profile, and the current location.

Shea and Cao (2010) have developed a software foundation package as a set of pre-compileddynamic link libraries (DLLs) that can be used for developing GIS applications on mobile devices.To create the package, named libMobileGIS, the authors have used only free and open sourcesoftwares, but it is only intended for mobile devices that run on Microsoft Windows operatingsystems.

A prototype mobile application was created by Mensah-Okantey (2007) to support the cadas-tral data collection in Ghana. However, more effort was put on modelling the cadastral processesin Ghana and a proof-of-concept prototype was created using proprietary software.

3


The proposed mobile system is also intended to support cadastral data collection, but the aimis to create a generic and interoperable SDI node using OGC-compliant services and interfaces.In this research project, a prototype of the system is created using free and open source software.

1.3 PROJECT SET-UP

The research questions raised above require adequate answers. The approach and methods thatwere adopted during this research for answering the research questions are described below.

1.3.1 Method adopted

The approach that guided this research considered the sequence of the questions in chronologicalorder. First of all literature was studied for gathering and analyzing the user requirements fora cadastral data collection system. During that phase the requirements for the server, servicesand mobile client were gathered. Those user requirements were then used to model the system.From the modeling techniques and tools that were found in the literature, like object-orientedand formal methods (Hull et al., 2005), the most appropriate ones for modeling the proposedsystem were selected. After modeling the system, we implemented a proof-of-concept proto-type. Available free and open source technology and tools, like OpenLayers library (http://www.openlayers.org/) and gvSIG Mobile (http://www.gvsig.org/web/home/projects/gvsig-mobile), that could be used to build the mobile system were considered. One of the designrequirements for the proposed SDI node is that it should be interoperable and OGC-compliant.From this perspective, the focus during the implementation phase was put on the technology thatenables creating an SDI node that can communicate and consume OGC-compliant geo-web ser-vices. The selected tools and technology were then used to create the prototype of the mobilesystem, containing server-side functionality and a client for the mobile device.

The steps of the research described above were sequential as they logically followed each other,while trying to answer the questions (1) to (4). On the other hand, the system evaluation was runthroughout the system design in order to ensure that the system followed the user requirements.The evaluation also continued during the system implementation phase. The purpose was to testthe developed functionality of the prototype and make improvements where needed. At the endof the prototype implementation phase, a final evaluation was performed for testing the prototypeas a whole (earlier its functionalities were tested in isolation).

1.4 THESIS OUTLINE

The research conducted during this thesis is structured into 6 chapters, as described below:

Chapter 1 – Introduction gives an outline of this research, including the motivation and objec-tives, the underlying research questions, related work, and the methodology adapted.

Chapter 2 – User requirements for cadastral data collection describes the user requirementsfor cadastral data collection. Literature on experiences from different countries was studiedand a use case scenario was created. This use case scenario was adopted in the context ofusing a mobile device for field data collection.

Chapter 3 – Analyzing requirements for cadastre data collection analyses the user require-ments for field data collection. The literature was studied and appropriate methods wereused to analyze the user requirements and design the concept of the system.

4


Chapter 4 – SDI node for mobile client – SDImobile presents the analysis and design of theSDI node for mobile clients. Again, literature was studied to find the proper technologyand standards for designing generic and interoperable web services as part of the SDI node.

Chapter 5 – Prototype implementation and testing describes the implementation of a proof-of-concept prototype. We have used free and open source software to implement some ofthe SDImobile functions as well as a graphical user interface for the mobile client. At theend we tested the prototype functionality by simulating a field survey.

Chapter 6 – Discussion, conclusions and future recommendations draws the results of thisresearch. The results of the research are discussed in relation to the research objectives.Conclusions of the research are drawn in here, and some recommendations for future im-provements are made.

5


6


Chapter 2

User requirements for cadastral data collection

2.1 INTRODUCTION

This chapter describes the user requirements, in terms of functionality, for a field cadastral datacollection scenario, using a mobile device. Experience from different countries in cadastral datacollection is gathered and analyzed from which the functionality of the system will be derived.The system will not be tailored to a cadastre in a particular country because the aim is to create ageneric system that can work in different countries with different cadastral systems.

Before starting to model and implement the system there is need for user requirements. Theuser requirements are the basis of a system as they define what the users want the system to do inorder to fulfill their needs (Hull et al., 2005), rather than how to do it (Liu, 2002). The approachfollowed in this research for collecting user requirements considers a use scenario. Use scenarioscan be created by discussing with the users and are considered a very good way of modelling whatusers do or want to be able to do (Hull et al., 2005). Due to time constrains the use scenariowill not be built by discussing with the potential users. Instead, literature is studied and cadastralsystems of different countries are analyzed and a use scenario is created. Following such approachallows to create a generic system for field data collection, which can be used in different cadastralsystems.

2.2 CADASTRE CONCEPTS

Before creating the use scenario it is relevant to give some definitions of main concepts of thecadastre. Many definitions exist since each country has implemented its own cadastre, often quitedifferent from the others.

Henssen (1995) defines cadastre as:

“a methodically arranged public inventory of data concerning properties withina certain country or district, based on a survey of their boundaries. Such propertiesare systematically identified by means of some separate designation. The outlines ofthe property and the parcel identifier normally are shown on large-scale maps which,together with registers, may show for each separate property the nature, size, valueand legal rights associated with the parcel. It gives an answer to the question whereand how much.”

Henssen’s definition is extended by Kaufmann and Steudler (1998) in their vision for Cadastre2014, to include public and traditional law aspects of cadastre:

“Cadastre 2014 is a methodically arranged public inventory of data concerning alllegal land objects in a certain country or district, based on a survey of their bound-aries. Such legal land objects are systematically identified by means of some separatedesignation. They are defined either by private or by public law. The outlines of theproperty, the identifier together with descriptive data, may show for each separate

7


land object the nature, size, value and legal rights or restrictions associated with theland object”.

In this definition, the authors introduce the registration of the legal aspects of the land or therights on land, which is known as the land registration process (Henssen, 1995; UN/ECE, 1996).

The United Nations Economic Commission for Europe in its guidelines for land administra-tion (UN/ECE, 1996), describes cadastre as “an information system consisting of two parts: aseries of maps or plans showing the size and location of all land parcels together with text recordsthat describe the attributes of the land”.

An extended definition on cadastre, which includes also the land registration process and thepurposes the cadastre can serve, is given by the International Federation of Surveyors (FIG). In-ternational Federation of Surveyors (1995) describes the cadastre as:

“a parcel based, and up-to-date land information system containing a record ofinterests in land (e.g., rights, restrictions and responsibilities). It usually includes ageometric description of land parcels linked to other records describing the nature ofthe interests, the ownership or control of those interests, and often the value of theparcel and its improvements. It may be established for fiscal purposes (e.g., valuationand equitable taxation), legal purposes (conveyancing), to assist in the management ofland and land use (e.g., for planning and other administrative purposes), and enablessustainable development and environmental protection”.

If we make an attempt to summarize from the above definitions, we may simply define thecadastre as an information system that records spatial and non-spatial information on land. Fromthose definitions it is obvious that at the core of a cadastre is the land. A legal perspective of landis given by UN/ECE (1996) which describes land as “the volume of space that encompasses thesurface of the Earth, all things that are attached to it, and the rocks and minerals that are just belowit. Land includes areas covered by water such as seas and lakes, all building and construction, andall natural vegetation”. In this research we will use the concept of land parcel which is defined byHenssen (1995) as “a continuous area of land within which unique and homogeneous interests arerecognized”.

2.3 CADASTRE SYSTEMS IN DIFFERENT COUNTRIES

In this section we give an overview of the cadastral systems in five European countries, namelyAustria, Bulgaria, Croatia, Hungary, and The Netherlands, based on a publication of the Centerof Legal Competence (CLC, 2009). We also shortly describe the cadastral situation in Ghana andAlbania.

The history of cadastre is different in different countries. In Austria it was introduced in1817 as a cadastre for taxation purposes and by 1861 entire country was surveyed; but the landregistration concept dates back in 12th century when the property transfers and mortgages wererecorded in a public book (Sadjadi, 2009a). Nowadays, in Austria, there is an up-to-dated landinformation system which contains the Land Book, for recording the real properties and theirrights, and Cadastre, for recording technical data on parcels and buildings, such as boundaries andparcel identifier (Sadjadi, 2009a). Since the cadastre data covers the entire country, the land surveyis done when requested by the owner for the reason of property conveyancing, determination ofexact boundaries for personal reasons, or in case of property subdivision (Sadjadi, 2009a).

The situation is slightly different in Bulgaria which did not have a cadastre or land registrationuntil the beginning of 1900 (Petrova, 2009). In 2001 the Cadastre and Property Register Act came

8


in force which regulates the activity of cadastre and property register (Petrova, 2009). Accord-ing to Petrova (2009), cadastre contains the identification number, boundaries, area and buildinginformation of the immovable properties, while the property register contains the deeds, whichare documents used for transferring the ownership or any other legal right on land. The cadastredata does not cover entire country, thus the field survey is carried out to measure new propertyboundaries or to split/merge exiting ones after the request of the owners (Petrova, 2009).

In Croatia the land registration system was started in 1855 by the Croatian Land RegistrationOrder (Josipovic, 2009). During the time many changes have happened in the Land Registrationin Croatia, until the recent situation, where the cadastre and land registration are handled bytwo institutions (Josipovic, 2009). The cadastre contains information on parcels, buildings, thearea of parcel, the usage, etc., while the land register contains information about the owner, realencumbrances, construction rights, etc. (Josipovic, 2009). Josipovic (2009) states that the mainproblem in Croatian land administration system is that it does not reflect the real situation ofcadastral data and the rights on land. The field survey is initiated by interested private or publicactors and is carried out by private licensed surveyors (Josipovic, 2009).

In Hungary, what started in 1875 as cadastre with two parts, cadastre register and cadas-tre maps, is now integrated into a Unified Land Register System and stored in a computerizeddatabase (Sadjadi, 2009b). The cadastral component of the Unified Land Register System containsthe parcel boundaries, parcel number, buildings and other constructions on the parcel, etc; thelegal component contains: descriptive information on the parcel such as parcel number, address,area, status of the property, etc; ownership information such as owners name, address, etc; andencumbrances such as mortgages, servitudes, etc. (Sadjadi, 2009b). The field surveying is doneby private licensed surveyors to partition the properties, demarcate the boundaries, etc., uponrequest of the owners. The cadastre in Hungary covers the entire country (Sadjadi, 2009b).

In the Netherlands, the cadastre was first introduced in 1810 for fiscal purposes, and by 1832the entire country was covered (van der Molen, 2009). Today, there is one combined land registryand cadastre which covers the lands and territorial waters of the Netherlands, owned by the stateor the private owners (van der Molen, 2009). According to van der Molen (2009), it registers theowners’ information, like name, address, civil status, etc., and spatial information on parcels likeboundaries, parcel identification number, buildings, etc. Similar to Bulgaria, in the Netherlands,the so called public registers are used for registering the notarial deeds (van der Molen, 2009).A field survey is done by the cadastral agency’s employees to measure the boundaries of dividedland parcels or for reconstructing the exiting boundaries, upon request of the land owners (van derMolen, 2009).

In Ghana, the land registration is regulated by two laws since 1957 (Mensah-Okantey, 2007).Actually, the land registration in Ghana does not cover entire country, and sporadic surveys arecarried out to register the parcels and rights. Different survey methods, like GPS, total stationand aerial photography, are being used to survey parcel boundaries. Licensed private surveyorsand cadastral organization’s surveyors are employed for surveying the cadastral parcels (Mensah-Okantey, 2007).

In Albania, the history of the cadastre is relatively new. Before 1990s the land was owned bythe government. In 1991, with the creation of the new Land Law, the land was distributed toprivate owners (Jazoj et al., 1997). In this situation, it became necessary to develop the cadastralsystem that would register documents from different organizations such as rural cadastre, forestand pasture cadastre and so on (Jazoj et al., 1997). In the core of the new system was the cadastralmap which showed the property parcel (Jazoj et al., 1997). For the areas of the country wherethe cadastral maps did not exists, it was planned to use aerial photography and other field surveymethods like tachymetry (using theodolites and total stations) (Jazoj et al., 1997). Two methods

9


are being used for registering the information on land: sporadic registration – registration of theland parcel and ownership when the owner decides to transfer (sell, mortgage, etc); and systematicregistration – a systematic registration of the land parcels and rights for a defined area calledCadastral Zone (Stanfield, 2004). Nowadays, there are ongoing attempts to create a digital cadastrefor storing and managing the land information of the entire country.

2.4 USE SCENARIO

In many countries, cadastral field survey is carried out by expert surveyors, being them privatelicensed surveyors or cadastral organization’s employees. The main reasons for conducting a fieldsurvey are to delineate the boundaries of the properties, thus creating land parcels, or subdivi-sion/merge of existing land parcels. The latter situation is common in countries that have acadastre that covers the whole country. The former is found in countries where cadastre is notconsolidated yet. Other reasons for conducting a field survey are the resolution of the bound-ary disputes, redefinition of the boundaries in case of boundary loss, remeasuring of the parcelboundaries to improve accuracy an so on.

In any of the above mentioned situation the surveyor may use one of the surveying methodslike: metric tape, theodolite, total station, GPS, etc. The choice of the measuring techniquedepends on the purpose of measuring, the required accuracy, and the costs involved. After fieldsurvey, the measurement will be processed and stored into a cadastral database — if one exists —or in other forms of data storage, like paper maps and documentations.

In this section we will create/simulate a use scenario for field surveying using a mobile device(PDA, Smartphone, etc). This scenario is based partly on the cadastral survey experience in fiveEuropean countries, as described in section 2.3. To build the use scenario, we will follow theguidelines given by Hull et al. (2005).

The system shall allow a surveyor to use a mobile device for cadastral data collection in thefield. Although a field survey is carried out for different reasons, here, only for simplicity reasons,we will restrict the scope of the system for measuring only new land parcels. Thus, the systemshall allow the surveyor to measure a new land parcel, i.e., the boundaries will be measured for thefirst time and stored in a cadastral database. We are assuming that a cadastral database exists andthe information can be stored and retrieved from it. The measurements of the parcel boundarypoints shall be done by means of GPS, which is integrated into the mobile device or can be con-nected with a mobile device. For each measured parcel, the surveyor shall be able to collect somedescriptive information such as the municipality (administrative area), address, land use (agricul-ture, forest, pasture, construction), area, taxation value, and name of the owner or user. Besides,the system shall allow the surveyor to load the map of the neighboring properties (if they exist)from the cadastral database, and use the map during survey to aid the measurement.

In case there is a building on the land, the system shall allow the surveyor to measure theoutlines of the building and record some descriptive information such as identification number,built area, number of floors, purpose, and construction permission.

The system shall be able to convert the measured points of the boundary into a parcel polygonand store it in the cadastral database. Before entering the database, the newly created polygon shallbe checked for consistency with some existing rules. Such rules could be: the allowed topologicalrelationships between parcel polygons, the coordinates should be measured (or transformed) inthe reference system specified in the database, each cadastral parcel must have a unique identifier,and on. Similarly, there may exist constraints that regulate the spatial relationship between landparcels and the buildings they contain. However, the decision of which rules to implement intothe proposed system for mobile field data collection depends on the implementation of the exiting

10


cadastral database (some rules could already be implemented in the database).We are also assuming that there exists a utility database (which resides in municipality or any

other institution) which is accessible by cadastral surveyor in the field. The system shall allow thesurveyor to access the utility database and check if there is any overlay of the utility lines withthe boundary of the measured parcel. If there is overlay, the surveyor shall be able to record arestriction/servitude on the property.

We already mentioned that the surveyor should be able to record the address of the parcelbeing surveyed. Such information shall be retrieved from the municipality - being the responsibleorganization for assigning addresses - under the assumption that the addresses database exists inthe municipality and is accessible from the field.

The mobile device shall be able to communicate with the sources of information to send andreceive data. In absence of any communication network, the system shall allow the surveyorto store the surveyed information locally in the mobile device. It should be able to transfer thedata from mobile device storage into database in a later moment when the communication isestablished.

To summarize, the surveyor shall be able to carry a field survey using a mobile device. Thesystem shall allow the surveyor to access different sources of information during the field mea-surement. The cadastral database will be used to retrieve and store information while utility andaddresses databases will be only used to read information. Thus, the mobile device should beprovided with functionalities that allow the access and process of the information from thosedifferent sources.

The required capabilities of the system are presented hierarchically in Figure 2.1. At the top ofthe hierarchy is the main goal of the system, stating the capability of the system for field survey.Every node in the hierarchy expresses a required capability which may be achieved using someother capabilities, in the next level of the hierarchy.

The Survey new parcel capability is achieved through several capabilities, which translatedinto steps of the use scenario, are performed sequentially starting from the top. This is shownin the Figure 2.1 by the word sequential under the proper node. In other nodes the sequenceof operations is not important; this is the case with the node Collect descriptive data whose sub-nodes represent steps that can run in parallel. According to Hull et al. (2005) the time sequence isimportant because it simplifies the use scenario for the user and also helps to put the requirementsinto a context. However, this time sequence may change at the system implementation phase.

From Figure 2.1 can be seen that some capabilities like Create polygon, Survey boundary points,etc., are repeated several times throughout the use scenario. They do not represent different capa-bilities; instead they should be seen as the same capability needed by the user at different momentsduring the field measurement.

2.5 NON-FUNCTIONAL REQUIREMENTS

Beside the functional requirements for the mobile data collection system, there may be someconstraints to it as well. A constraint is a non-functional requirement (Liu, 2002) that controlsthe way in which the required capabilities should be delivered (Hull et al., 2005; Gorton, 2006).Some of the non-functional requirements are described in the following sections.

2.5.1 Business constraints

The proposed system should be generic and interoperable with SDIs as it will consume theirservices.

11


Figure 2.1: Field survey scenario

2.5.2 Quality attributes

One of the issues for the proposed mobile data capture system is the security. Due to the sensitiv-ity of the cadastral data, not every user equipped with a mobile device or a desktop computer isallowed to access and update the information. Thus, the system must provide access only to usersauthorized by the competent organization (e.g., the cadastral organization in charge of cadastraldata storage and maintenance). However, the intention here is not to provide security for thecadastral database, as that is out of the scope of this research. Instead the system should providea simple mechanism for user identification. Reliability is another non-functional requirement forthe system. When lacking the communication network, the system should be able to store thedata collected in the field, and at a later stage when communication is re-established, it should beable to synchronize with the cadastral database. Portability is another desired characteristic as itwill not tailor the system to any specific platform or device. Thus the system should be platform-

12


independent and also device-independent. In principle any type of mobile device (Smartphone,PDA, TabletPC, Notebook) running any operation system can be a potential candidate to dothe job. However, mobile devices range from Smartphones to Notebooks (Casademont et al.,2004), with different operating systems and characteristics and it is practically impossible to cre-ate an application that can be used in such wide range of devices. In this sense the platform-and device-independence constraint is a characteristic that can only be fulfilled up to some level.Nevertheless, a mobile device is eligible for the field survey scenario if it is equipped with GlobalPositioning System (GPS) receiver (or it is capable to connect to an external one), is able to runthird parties applications and also capable to use wireless networks for communication.

2.5.3 Technical constraints

It should be obvious by now that a mobile device (Smartphone, PDA, TabletPC) will be usedin field for cadastral data collection. The relatively small size of the mobile device makes it suit-able for the job as it is portable and lightweight. On the other hand, the mobile device hastechnological restrictions such as small display screen, small and slow memory, limited powerautonomy, limited processing capabilities, special input devices, and low communication band-width (Brinkhoff, 2008; Rabin and McCathieNevile, 2008). All these technological restrictionswill affect the design of the proposed mobile system for cadastral data collection.

2.5.4 Accuracy constraints

Within a cadastre organization the accuracy of the field survey may be a concern. Actually, basedon the importance of the measurement accuracy of the cadastral boundary, cadastral systems canbe grouped into fixed and general boundaries cadastral systems (UN/ECE, 1996). In the formergroup, the boundary is measured accurately and, if needed, can be restored in the field from themeasurements. In the case of the general boundaries system, there is no accurate measurementof the boundary line. Instead, it is defined by natural or man-made features, such as hedges andfences.

For the fixed boundaries system, the accuracy of the measurements of the mobile phones’GPS (several meters horizontal accuracy) may not satisfy the requirements. However, the mobilephone technology is developing in a fast pace. For instance, nowadays mobile phones are equippedwith Assisted GPS (A-GPS) technology. A-GPS uses a remote server which provides informationabout satellite orbits, clock information, the initial position and time estimate, etc, resulting infast time-to-first-fix (Zandbergen, 2009). In the coming years it is expected that more satelliteswill be available, which will improve the GPS accuracy of the mobile phones up to the level ofcentimeters (McLaren, 2010). Therefore, in this research, we will focus on the other requirementsand constraints.

2.6 SUMMARY

In this chapter we have given an overview of the cadastre and land information systems in differentcountries. The aim was to identify the process of field data acquisition and in that context a usescenario was created. The use scenario describes the user requirements for a mobile data capturesystem, in terms of what the system should provide rather than how. The user requirements arethe input of the analysis and design processes that follow in Chapter 3.

13


14


Chapter 3

Analyzing requirements for cadastre data collection

3.1 INTRODUCTION

In a system development process, the analysis and design are two logical steps that follow the userrequirements collection. We start with reviewing some of the modeling and design approachesand methods which can be used for analyzing and designing the system (section 3.2). In theanalysis phase, we transform the user requirements into a use case and create a first architectureof the system (section 3.3). We continue with the design step, by decomposing the system downinto components and assigning responsibilities to them (section 3.4).

3.2 MODELING AND DESIGNING APPROACHES

Different modelling styles and patterns are available for analyzing and designing a system. Beforereviewing some of the exist modelling approaches, we give some definitions of the main terminol-ogy used in those approaches.

• System: According to Hull et al. (2005), “a system is a:

· collection of components — machine, software and human —

· which cooperate in an organized way —

· to achieve some desired result — the requirements.”

Moreover a component of a system can be seen as a system itself, or further, a system canbe a component of a larger system (Morales, 2004).

• Model: A model is an abstraction of a system that captures some of the characteristics ofthe system, while the irrelevant ones are left out (Hull et al., 2005; Morales, 2004).

• Architecture: The Institute of Electrical and Electronics Engineers, Inc. (IEEE ComputerSociety, 2000) defines the architecture as “the fundamental organization of a system embod-ied in its components, their relationships to each other, and to the environment, and theprinciples guiding its design and evolution”.

3.2.1 Development approaches

In the design and development of systems in general, and softwares in particular, different ap-proaches are used. We have reviewed several approaches and describe them briefly in this section,trying to bring out their characteristics.

15


Waterfall and Iterative approaches

The waterfall method is one of the earliest of the development models, first described by WinstonRoyce in 1970 (Kruchten, 2004). In this strategy, the development of the system is conductedthrough several phases, where one phase starts after the previous is completed and approved(Morales, 2004; Sommerville, 2007). This approach is based on the assumption that the user re-quirements will not change during the development process (Morales, 2004), which makes it notsuitable in situations where requirements are changing during development process (Sommerville,2007). Nevertheless, the advantage of waterfall model relies in the fact that it is predictable andthe architecture of the system can be planned in detail which is important when developing largesystems (Petersen et al., 2009). To improve the waterfall model, a more iterative approach has beendeveloped. The development process is executed in iterations, where each iteration goes throughall development phases (Morales, 2004). The advantage of introducing iterations is that the systemis tested in every iteration and is improved (Morales, 2004).

Object model

In contrast with the structured design methods which use algorithms as their building blocks, theobject-oriented design methods use classes and objects as building blocks (Booch et al., 2007). Ba-sically, the object-oriented development has two phases, the analysis and design. During analysis,the requirements are examined from the perspective of objects as found in the problem domain.On the other hand, the design phase is led by the object-oriented decomposition process in whichthe system is decomposed into parts (objects). According to Booch et al. (2007), “the support forobject-oriented decomposition is what makes object-oriented design quite different from struc-tured design”.

Decomposition is a strategy to handle complex systems, during which the domain of interestis divided into conceptual classes (Larman, 2002). Larman (2002) defines the conceptual class asa “real-world concept or thing”. Arlow and Neustadt (2002) use another term for the conceptualclasses; they call them analysis classes which represent “real-world business concepts”.

The conceptual classes identified in the domain of interest, may have attributes. Larman (2002)defines an attribute as “a logical data value of an object”. Besides, the conceptual classes may beconnected to each other through associations. Associations are meaningful connections betweenclasses (Arlow and Neustadt, 2002), and define the visibility between objects. “Visibility is theability of an object to ‘see’ or have a reference to another object” (Larman, 2002). To supportthe associations, classes have responsibilities. “Responsibilities are the essential duties that haveto be performed [by an object]” (Hunt, 2000). The responsibilities of an object are of two types:knowing — about their attributes, other objects, or things that need to be calculated; and doing —an object does something like performing an action itself, initiating an action in another object,or controlling the activities in another object (Larman, 2002).

Because the object-orientation analysis and design is built on exiting methodologies, it is con-sidered an evolutionary development (Booch et al., 2007; Norman, 1996). The main benefit ofusing the object-oriented model is that it can be used to build complex systems, that are diffi-cult to build using other methods (Booch et al., 2007; Norman, 1996). Booch et al. (2007) givesome more benefits of using the object-oriented model. Some object-oriented approaches such asthe Booch Method, the Object Modeling Technique, the Objectory Method, the Fusion Method, etc, arereviewed by Hunt (2003).

16


Design patterns

In object-oriented design, a design pattern is a solution to a problem, which may also give adviceson how to be applied in a given context (Larman, 2002). The Controller is a design pattern whichstates that the responsibility to handle a system event is assigned to a class which, among others,“represents a receiver or handler of all system events of a use case scenario” (Larman, 2002). TheCreator is another one. It suggests assigning the responsibility for creating an instance of a class toan object that records the instance. These and other patterns such as, Expert, Low Coupling, andHigh Cohesion, are described in details by Larman (2002).

The Unified Process

The Unified Process “is a generic process framework [for software development] that can bespecialized for a very large class of software systems, for different application areas, different typesof organizations, different competence levels, and different project sizes” (Jacobson et al., 1999).It is based on components and their interactions, i.e., a software is made up of components thatinteract through their interfaces (Jacobson et al., 1999). What makes the Unified Process uniqueare its three aspects:

• Use-case driven: A use-case shows how the user interacts with a system to perform a task.Thus, a use-case captures the functionality required from the system. In the Unified Process,the use-cases are used throughout the development process; use cases are specified, designed,and at the end are used to create the test cases.

• Architecture-centric: The architecture captures the most important aspects of the system,leaving out those less important. It starts to grow from the need for the system and reflectsthe use cases. Then, it evolves at each step and is referred throughout the Unified Process.

• Iterative and Incremental: The Unified Process splits a software development into minipro-jects (iterations). Each iteration is built in such a way that it deals with those use cases thatextend the usability of the system being developed, and it also deals with the most impor-tant risks in the development process. At every iteration the design is based on the state ofthe previous iteration and continues through the development phases to create an improvedversion of the system, hence the process is incremental.

A more extended review of the Unified Process is given by Hunt (2003).

3.2.2 The Unified Modeling Language

The Unified Modeling Language (UML) is developed at Object Management Group (OMG) andbecame a standard in 1997 (Booch et al., 2007). It is “OMG’s most-used specification, and the waythe world models not only application structure, behavior, and architecture, but also businessprocess and data structure” (OMG, 2010).

An introduction to UML is given in (OMG, 2005). According to OMG (2005), UML is builton Object-Oriented fundamentals and as such it is suitable for modeling applications that willbe built using object-oriented languages and environments, but it can also be used to model non-object-oriented applications as well.

The UML has several diagrams which are combined into models that describe the systembeing developed from different perspectives (Hunt, 2003; Hull et al., 2005). The UML 2.0 version(released in July 2005), contains 13 diagrams, which are divided into three groups:

17


• Structure Diagrams: include the Class Diagram, Object Diagram, Component Diagram,Composite Structure Diagram, Package Diagram, and Deployment Diagram. This groupof diagrams is used to model the static structure of the system;

• Behavior Diagrams: include the Use Case Diagram, Activity Diagram, and State MachineDiagram. These behavior diagrams, together with the interaction diagrams, are used tomodel the dynamic behavior of the system;

• Interaction Diagrams: include the Sequence Diagram, Communication Diagram, TimingDiagram, and Interaction Overview Diagram (all derived from the more general BehaviorDiagram).

The UML is not a methodology or a process; indeed it is a notation that can be used to describethe models of a system under development and does not tell anything about how to design thesystem (Hunt, 2003). The widespread support for the UML derives from the fact that it does notdepend on any analysis and design approach, which means that UML can be used to represent theresult of any analysis and design approach (OMG, 2005).

A more complete review on UML, where diagrams are described in details, is given by Boochet al. (2007).

3.3 ANALYZING USER REQUIREMENTS

From the aforementioned development approaches, we use the Unified Process to guide an object-oriented analysis and design of the mobile data collection system. The reason for choosing thisapproach is related with the iterative and incremental nature of it. This characteristic of UnifiedProcess allows to develop the functionality of the system incrementally through several iterations.One of the benefits of applying such approach is that risks (technical, requirements, usability, etc)are found and addressed in early stages (Larman, 2002; Booch et al., 2007). The Unified ModelingLanguage will be used to draw the models derived during the Unified Process development.

3.3.1 System in context

During analysis phase a model of system’s behavior is created (Booch et al., 2007). This modelis about what the system does without showing how it does it. To model the system behavior,we start by first defining the environment in which the system will operate. Figure 3.1 shows thesystem boundary and the interacting actors—the field surveyors who will use the system,— andalso the SDI nodes which will provide services to the system. In other words, a field surveyor willuse the system to survey a cadastral parcel; the system, on the other hand, will consume servicesof SDI nodes (cadastral, municipality, utility) to fulfill the user’s needs.

3.3.2 Defining use cases

To identify the use cases of the proposed system we follow the guidelines given by Larman (2002),which introduces the idea of elementary business processes and goals as a framework for iden-tifying the use cases. Larman (2002) defines the elementary business process (EBP) as: “A taskperformed by one person in one place at one time, in response to a business event, which addsmeasurable business value and leaves the data in a consistent state”. Further in his reasoning,Larman (2002) refers to EBP-level use case as user goal-level use case, because a use case servesthe goals of the user. Thus, a use case for the proposed system is Survey Parcel. It represents atask performed by one person — the surveyor — in one place at one time, in response to a busi-ness event — the need to measure the parcel, — which adds measurable business value and leaves

18


Figure 3.1: Mobile Data Collection System, Context Diagram

data in a consistent state — updates the cadastral database whose consistency is guaranteed by itsconstraints. Thus, the Survey Parcel qualifies as a use case.

We write the use case for the mobile data capture system, using the template from Cockburn(1998). It comes in plain text and table forms, from which we use the latter as it offers a morestructured description. Table 3.1, describes the Survey Parcel use case. Although the use casetemplate contains many elements, in Table 3.1 we have used only those relevant to our use case.The use case may contain many branches and unsuccessful paths (many things may go wrongduring a field survey), but for the simplicity’s sake, we here represent only the successful path.

Table 3.1: Survey Parcel use case

USE CASE 1 Survey ParcelGoal in Context To survey a property parcel in the field.Preconditions Users are known and identifiable. Available and accessible wire-

less networks.Success End Condi-tion

Parcel is surveyed and stored in the cadastral database.

Primary Actor Surveyor.Secondary Actors Cadastral, Municipality and Utility SDI nodes which offer ser-

vices to the system.DESCRIPTION Action

1. Surveyor starts a communication with the system.2. Surveyor enters his/her authentication information.3. Surveyor requests the cadastral map of the area of interestfrom the Cadastral SDI node.4. Cadastral SDI node supplies the cadastral map.5. Surveyor measures the boundary points of the parcel.6. System stores measured boundary points.7. System converts the coordinates of the boundary points intothe reference system used by the cadastral organization.8. System creates parcel polygon from boundary points.9. System stores the parcel polygon.

19


Table 3.1: (continued)

10. Surveyor collects descriptive information on parcel suchas identification number, municipality, land use, area, taxationvalue, and owner’s name.11. System stores the descriptive information.12. System requests the address of the parcel from the Munici-pality SDI node.13. Municipality SDI node provides the parcel address to thesystem.14. System stores the address of the property.15. System requests utility data from the Utility SDI node.16. Utility SDI node provides utility data to the system.17. System overlays parcel boundary with utility data.18. Surveyor measures the boundary points of the building.19. System stores the measured boundary points.20. System converts the coordinates of the boundary points intothe reference system used by the cadastral organization.21. System creates building polygon from boundary points.22. System stores the building polygon.23. Surveyor collects descriptive information on building suchas identification number, built up area, number of floors, pur-pose, and construction permission.24. System stores descriptive information on building.25. System sends the surveyed data, of parcel and building, tothe cadastral SDI node.26. Surveyor ends the field surveying.

EXTENSIONS Branching Action17a. If parcel boundary overlays with utility data, the systemsends notification to the cadastral SDI node for putting restric-tion on the property.17b. If parcel boundary does not overlay with utility data, sys-tem takes no action.

RELATED INFORMATIONPerformance The surveyor should be able to survey a property within several

minutes (depends on the size of the property parcel).Frequency The system should be used any time there is need to survey a

parcel.Channels to prima-ry actors

Interactive graphical user interface.

Channels to secon-dary actors

Wireless internet communication channels.

The use case diagram in Figure 3.2, shows the interaction of the system with the actor (fieldsurveyor), and with the SDI nodes. The arrows of the connection lines show which one uses theother. For instance, the actor will use the system to perform a field survey. On the other hand,the system will invoke the SDI nodes’ services to fulfill the actor’s requirements.

Another way to specify a use case, besides using textual description, is the UML activity

20


Figure 3.2: Survey Parcel Use Case Diagram

diagram. The later is used because it can reveal potential problems that are not visible in thetextual specification representation (Booch et al., 2007). We created the activity diagram whichshows the flow of activities in the system (Figure 3.3).

3.3.3 Defining system architecture

So far we have created a use case, Survey Parcel, and have used UML use case and activity diagramsto explain it. The activity diagram, in Figure 3.3, shows that most of the activities are run on themobile device. Mainly, the activity diagram captures the functional requirements of the system,but also one non-functional requirement, namely, the one that controls the user access on thecadastral data. The SDI nodes column in Figure 3.3 represents the three SDI nodes we have alreadymentioned in the use case. They are outside of the mobile data collection system and are includedin the activity diagram only to show a complete view of the activities.

While developing the system, besides the functional requirements, we have to consider themobile device-related constraints. Mobile devices, because of their small size, suffer from lim-ited resources such as small screen, small battery, limited memory size and computing power,and limited keypad as compared to a desktop computer. Wireless networks are also slower andmore expensive compared to wired networks. Moreover, they are not stable (the device may losewireless connection).

Such limitations of the mobile device and wireless network impose some restrictions on thearchitecture of the system. In this situation, we introduce another component in the system,called SDI node for mobile client – SDImobile. We believe that this new element will allow us tobuild a system that minimizes the usage of the mobile device resources. The SDImobile elementwill serve as a “bridge” between the mobile device and the other SDI nodes. It will handle thecommunication between them and run some of the activities in support of the use case. Furtheranalysis will reveal the SDImobile’s full role. Therefore, we build the logical architecture of thesystem which includes the mobile device and the SDImobile component (Figure 3.4). Figure 3.4includes also the three SDI nodes which, as already mentioned, are not part of our system. Weinclude them here just to clarify the role of the SDImobile in the interaction of the system withthose SDI nodes. The mobile device communicates with the SDImobile through its interface(ISDImobile). Similarly, the SDImobile component interacts with the other SDI nodes throughtheir interfaces (ICadastre, IMunicipality, and IUtility).

21


22


Figure 3.3: Activity Diagram

We have rebuilt the activity diagram such that it includes the SDImobile component (Figure3.5). Although it seems like a lot of activities are still running on the mobile device, that isnot completely true. Most of them are requests asked by the user (using the mobile device) foractivities that will run on the SDImobile. Thus, they will not consume as much resources fromthe mobile device as opposed to the prior situation (Figure 3.3).

3.3.4 Domain model

In this section we identify the conceptual classes and represent them in a domain model. Toidentify conceptual classes in the domain of interest we use the noun/verb analysis (Arlow andNeustadt, 2002). According to this method, the noun and noun phrases in a use case specificationindicate classes or attributes of classes, while verbs and verb phrases indicate operations of classes(not identified in this phase). Another method for identifying conceptual classes is to use a listof conceptual class categories (Larman, 2002). In this method, as the name suggests, a list ofconceptual class categories is used to identify conceptual classes. Some common categories aregiven by Larman (2002, pg. 134-135). In our analysis, we combine both methods for identifyingthe classes in our domain of interest. For instance, using the noun/verb analysis, in the usecase action “5. Surveyor measures the boundary points of the parcel”, we can identify three nouns,Surveyor, boundary points, and parcel. Hence we have created three conceptual classes, Surveyor,BoundaryPoint, and Parcel. Similarly, we have identified the attributes (municipality, area, owner,etc.) of the class Parcel from the use case specification. By using the list of class categories we haveidentified classes like: MobileDevice, SDImobile — which belong to “physical or tangible objects”category; Survey — which belongs to “processes” category; and so on.

23


Figure 3.4: Mobile Data Collection System, Logical Architecture

After identifying the conceptual classes, we need to define the associations between them.One method for identifying them is to look in the use case for verbs and verb phrases between ob-jects (Hunt, 2000). According to Hunt (2000), such approach may identify relationships betweenobjects that:

• are physically contained in each other;

• communicate with each other;

• apply some operation to each other, and so on.

Using this method we have identified associations like: Building “ContainedBy” Parcel; MobileDe-vice “Communicates with” SDImobile; and so on. A similar method to identify associations be-tween classes in our domain of interest, is to use a common association list (Larman, 2002, pg.156-157). For instance, we have identified the associations: Surveyor “Uses” MobileDevice — whichbelongs to “A uses or manages B” category in the association list; MobileDevice “Stores” Parcel —which belongs to “B is recorded in A” category; and so on.

Some of the identified classes have attributes. Larman (2002) suggests to include in the domainmodel only those attributes that can store information as suggested in the user requirements. Sofar we have identified attributes for the Parcel and Building classes.

The identified conceptual classes and their attributes and relationships are presented into thedomain model, shown in Figure 3.6. Boxes in the diagram represent conceptual classes, eachhaving a name (in the top part of the box) and may or may not have attributes (listed in the bottompart of the box). Associations between conceptual classes are represented by lines between them.Associations have names and, in this diagram, should be read from top to bottom, or from left toright. The aim of the domain model is to aid understanding the domain of interest by capturingits conceptual classes, and their attributes and associations.

3.4 DESIGNING THE SYSTEM

The next step in system development process is the design. It follows the system analysis phaseby producing the elements of the system that provide system’s behavior identified during analysis(Booch et al., 2007). In the analysis phase, the emphasis was in defining what the system shoulddo, i.e., the behavior of the system.

During design, the emphasis is shifted towards the how of the system. This means to specifyhow objects of the system will collaborate to fulfill the user goals. Such collaboration is shown

24


25


Figure 3.5: Activity Diagram Refined to Include SDImobile Component

using the class diagrams and interaction diagrams (Larman, 2002). The interaction diagrams canbe built using design patterns, which guide the process of assigning responsibilities to objects(Larman, 2002). Actually, we use the design patterns to identify the classes of objects as well as toassign responsibilities to them.

One of the characteristics of the Unified Process is its use case oriented nature. Use cases drivethe entire process of the software development. In the analysis phase we created a use case andalso the domain model which visualizes the objects and their attributes and associations in thedomain of interest. During design we will identify the objects and collaborations in between thatsatisfy the user requirements captured in the use case. In the Unified Process this is called use caserealization (Arlow and Neustadt, 2002). Use case realization is necessary in this step to ensurethat design is based on and supports the use case (Hunt, 2003).

3.4.1 Sequence Diagram

To illustrate the collaborations between the objects, we use the UML sequence diagrams. A se-quence diagram shows the objects as lifelines and their interactions as messages that run from thesource to the target object. Actually, the messages in the sequence diagram reflect the responsibil-ities assigned to different objects. The UML sequence diagram, shown in Figure 3.7, representsthe collaborations between objects in terms of message exchange.

Through the sequence diagram in Figure 3.7 we try to explain the use case realization. Theuser — surveyor — uses the MobileDevice to start a communication with the system. S/he providesthe system with the user information (UserID), which is sent to the SDImobile object through the1.1: startCommunication(UserID) message. The user generates a system event which is associatedwith a system operation for handling the user request (Larman, 2002). The number before thename of the message is used to show the sequence of the messages in the sequence diagram. Themessage itself represents a responsibility which is assigned to the SDImobile object, i.e., this objectis responsible for starting the communication. As mentioned earlier, the objects are identified andresponsibilities are assigned to them using design patterns. We use the Controller pattern for iden-tifying the SDImobile object. In our use case the responsibility to handle the startCommunicationevent is assigned to the SDImobile class, hence the message is sent to it. The Creator is anotherdesign pattern that we use for creating objects and assign responsibilities. In Survey Parcel usecase, the mobile device will create and record the boundary coordinates. Therefore, we assignedMobileDevice class the responsibility to create the instances of the Coord class. Similarly, we havecreated and assigned the responsibilities to the other classes of objects.

The 4.1:createParcelPolygon(coord) message is used to send data (coord) and invoke an opera-

26


Figure 3.6: Domain Model, representing the conceptual classes in the problem domain

27


Figure 3.7: Sequence Diagram showing the sequence of messages between objects

tion (4.1.1:createParcelPolygon(coord)) on the SDImobile object. The 5.1:requestDataProcessing is another type of message that does not send data, but just invokes an operation (5.1.1:requestUtility-Data(coord)) on the SDImobile object. It is possible that an object sends messages to itself. Thatis the case with the 1.1.2: startSession(UserID) message that SDImobile object sends to itself. Be-sides the request messages, in the sequence diagram, there are also the response messages, denotedby broken lines (request messages are denoted by continuous lines). These messages may returndata (5.1.2:provideData(utility)) or just a confirmation message (5.1.7:confirmSendOperation) to theobject that invoked the request.

28


In the diagram, we can observe two communication models between the MobileDevice andSDImobile classes. The first situation is when one message sent from MobileDevice object, invokesonly one method in the SDImobile. For instance, if the message requestCadastralMap is sent tothe SDImobile, then the method named requestCadastralMap() is defined in the class. In the secondsituation, one message sent from MobileDevice invokes a group of methods in the SDImobile ob-ject. For instance, the requestDataProcessing message when sent to the SDImobile object invokesseveral methods (5.1.1, 5.1.3, 5.1.4, and so on). The second communication model is useful inorder to reduce the wireless communication between the mobile device and the SDImobile node.

The sequence diagram in Figure 3.7 reveals the responsibilities and importance of the SDImo-bile in the mobile system for field data collection. The SDImobile handles part of the communi-cations between the mobile device and SDI nodes, which in its absence would have to be handledby the mobile device. As we have mentioned earlier, the mobile device will use the wireless com-munication networks which are unreliable and costly. Therefore, having a SDImobile componentthat handles part of that communication, we believe, creates a more reliable and robust system.

3.4.2 Class Diagram

In parallel with the creation of the sequence diagram we have created the class diagram. The classdiagram (Figure 3.8) shows the objects, their attributes, methods, and relationships. In contrastto the classes in the domain model which represent real objects in the domain of interest, the classdiagram contains classes that will be implemented into software classes (Larman, 2002). We usedthe domain model to guide the design of our classes. However, not all the classes in the domainmodel are defined as design classes. In the class diagram we included all the classes identified duringthe design phase. For simplicity, only the important classes are shown in the sequence diagram.

We use UML stereotypes in order to distinguish between different class types. For instance,we use the «entity» stereotype to distinguish the entity classes. Similarly, the «SDI node» stereotypeis used to distinguish the SDI node classes and the «interface» to distinguish the mobile device class.

From Figure 3.8 we can see that two classes that contain methods are the MobileDevice andSDImobile. According to Larman (2002), methods are the implementation of the objects’ respon-sibilities. A method may also have parameters, but they are not shown in the class diagram inorder to keep it simple. Methods of the SDImobile object are mainly invoked by the messages sentfrom the MobileDevice object. They are used for different purposes such as authenticating the userand starting a user session, processing the data sent by the MobileDevice object, communicatingand retrieving data from the external SDI nodes and so on. The methods of the MobileDeviceobject provide the user with the functionality to collect data in the field and communicate withthe SDImobile class. They are provided to the user through a graphical user interface.

Besides the classes’ attributes and methods, the class diagram shows also the associations be-tween classes. In order for an object to send messages, it needs to have visibility (association) toother objects (Booch et al., 2007). Larman (2002) suggests three situations in the sequence diagramfor which an association from an object A to an object B should be specified:

• “A sends a message to B

• A creates an instance of B

• A needs to maintain connection to B”

With that in mind, we create the associations between objects that show the navigability — thedirection of visibility — in those associations. For instance, there is an association between Mo-bileDevice and Parcel objects since the former creates an instance of the latter. In this association,the MobileDevice class has visibility on Parcel which is shown in the class diagram by an open-head

29


Figure 3.8: Class Diagram showing the design classes, their attributes, methods, and relationships

30


arrow pointing on the Parcel class. Navigability on the inverse direction is not possible, i.e., theParcel class does not “know” about the MobileDevice class. Associations may also have names. Forinstance, the name of the association under discussion is Creates, inferring that the MobileDevicecreates instances of the Parcel class.

Other classes that contain methods are Cadastre, Municipality, and Utility. The Cadastre classrepresents the cadastral SDI node which provides the cadastral map and will also store the sur-veyed data. The Municipality class represents the municipality SDI node which provides the ad-dress for the measured property parcel. The Utility class represents the utility SDI node whichprovides the utility data. None of them is part of our system; we are assuming that they exist andoffer standard-compliant, interoperable services.

The class diagram brings out the set of operations/methods that we defined in the SDImobileclass. In the absence of that class, its operations had to be provided by the MobileDevice class.We believe that having the SDImobile class that can provide this set of operations, improves theperformance and reliability of the system.

Both diagrams created during design, the sequence and class diagram, are part of the DesignModel and will be used as input for the implementation phase.

3.5 SUMMARY

In this chapter we started by investigating some of the available approaches for developing oursystem. The Unified Process was chosen as the process to follow during object-oriented analy-sis and design. The Unified Modeling Language (UML) was used to draw the diagrams duringdevelopment process. In the analysis, the user requirements were analyzed for bringing out thebehavior of the system. A use case was created for capturing the user requirements. The firstabstract architecture of the system was created and a new element was introduced, called SDI nodefor mobile client — SDImobile. To create a better understanding of the problem domain, we createda domain model containing the conceptual classes. Later, during design, we refined and developedit further. Using design patterns, we have identified design classes and assigned responsibilities tothem. We created a sequence diagram to show how the objects collaborate in order to fulfill theuser goals (requirements). We also created a class diagram to show the classes’ attributes, methods,and relationships. Both diagrams, the sequence and class diagram, make up the Design Modelwhich will be the input of the implementation phase.

31


32


Chapter 4

SDI node for mobile client – SDImobile

4.1 INTRODUCTION

In this chapter we proceed by analyzing and designing the SDImobile in more details. The needfor the SDImobile and its role in the mobile data collection system is described in section 4.2. Thedesign paradigm and some design principles used in designing the SDImobile are given in sections4.3.1 and 4.3.2, respectively. The analysis process is described in section 4.3.3, followed by thedesign in section 4.3.4.

4.2 SDImobile’s ROLE

The development of the mobile data collection system is guided by the functional and non-functional requirements. While the functional requirements express what the system is requiredto do, the non-functional requirements influence the system’s performance. Some of the func-tional requirements, like the survey of the parcel and building, can be fulfilled by the mobiledevice. Others, like the overlay of the parcel polygon and utility data, due to the technologicalconstraints, may not be handled efficiently, or at all, by the mobile device. Furthermore, the mo-bile device will be used to survey cadastral data in the field and it needs to use wireless networks tocommunicate with the other SDI nodes. Wireless networks are usually unstable and more expen-sive, compared to wired networks. The mobile device should find the SDI nodes, consume theirservices and also provide some output for them (as may be needed). But, not all services providedby SDI nodes can be used by the mobile device. For instance, a Web Map Service (WMS) canbe consumed in a desktop computer through a web browser or stand-alone client. To be able toconsume the same WMS in a mobile device there is need for a client application which is designedfor a device which has limited screen size, limited communication bandwidth, and does not havea pointing device (mouse) and/or keyboard.

Thus, developing and implementing a system that deals with those drawbacks is a challenge.First of all we need to put as less as possible functionality on the mobile device in order to have aneffective system. Next, we would like to minimize the communication of the mobile device withthe SDI nodes due to reliability and cost issues of wireless networks.

To cope with such situation we proposed a solution that includes another component, theSDImobile (section 3.3.3). The SDImobile component, as the name suggests, is an SDI node thatconsumes services from other SDIs and also offers its own services for a specific group of devices(Smartphone, PDA, TabletPC), with limited resources (hence the SDImobile name). de By et al.(2009) define an SDI node as “a moderately to highly complex information system with usuallylong lifetime expectancy, in which geospatial resources feature rather prominently”.

The SDImobile “sits” in between the mobile device and other SDI nodes and acts as a media-tor. In this role, it should have the functionality to search and find the SDI nodes that offer theproper services. Then it will bind the services and if necessary will tailor them for the mobiledevice. For instance, the SDImobile can search for an SDI node that offers a Web Feature Ser-

33


Figure 4.1: SDI node stack (Köbben et al., 2010)

vice (WFS) and then creates a WMS that can be used by the mobile device. It should be notedhere that for our cadastral case study it is not necessary for the SDImobile to have the function-ality to search/find the SDI nodes. For a given use case (cadastral survey), the required servicescan be found beforehand and the SDImobile can be set up to bind those services. But, includingsuch functionality allows the SDImobile to be used for other applications. Although this is notcompletely true as other applications may require functionality quite different from the cadastralsurvey application, at least it contributes towards creating a generic SDImobile node.

Figure 4.1 presents an SDI node with all its components. In this research we focus only on thedesign of the SDImobile node’s functionality, expressed through services.

4.3 ANALYSIS AND DESIGN

We base the design of the SDImobile node on the requirements for the cadastral use scenario andaim at making it as generic and reusable as possible. In this respect, we divide the functionality ofthe SDImobile into two groups: generic functionality and specific functionality. In the first groupwe include functions that serve general purposes — which can also be reused in other situations.The specific functions are meant to fulfill the functional requirements of a specific use case suchas the Survey Parcel (Table 3.1). Such functions are offered through services, which form the coreof an SDI node (Morales et al., 2008).

We will base our design approach on the principle of separation of concerns, which helps man-aging the complexity of a design process by splitting it into phases that do not overlap (Moraleset al., 2008). In the context of a service, there are three levels of concern: the purpose (what theservice does); the boundary (the interface); and the inside (the internal structure of the service)(Morales et al., 2008).

In section 3.4 we identified the SDImobile object and assigned capabilities to it (as methods).We will now move the capabilities from the object into services. According to Erl (2007), a capa-bility represents a function of a service or it is equivalent to an operation of a service implemented

34


as web service. Booth et al. (2004) give this definition for a web service:

“A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web servicein a manner prescribed by its description using SOAP messages, typically conveyedusing HTTP with an XML serialization in conjunction with other Web-related stan-dards”.

In other words, a web service is an implementation of a service through the use of standards thatsupport interoperability (Josuttis, 2007). These standards will be discussed during the design step(section 4.3.4).

Here we will follow service orientation principles for designing web services of the SDImobilenode, which will encapsulate the required functionality.

4.3.1 Service orientation

Service orientation is a design paradigm based on a group of design principles. Erl (2007) describesthe eight design principles of service-orientation paradigm:

• Standardized Service Contract

• Service Reusability

• Service Autonomy

• Service Statelessness

• Service Discoverability

• Service Loose Coupling

• Service Abstraction

• Service Composability

When applying service-orientation and its principles, it results in services that support the re-quirements of the system under design (Erl, 2007). “A service is the IT realization of some self-contained business functionality” (Josuttis, 2007). It is an independent software program designedfor a specific functional context whose capabilities are published through its contract (Erl, 2007).According to OASIS (2006), service combines the following ideas:

• “The capability to perform work for another

• The specification of the work offered for another

• The offer to perform work for another”

Service orientation is different from other paradigms in the way it carries out the separation ofconcerns (breaking down a larger problem in order to solve it more effectively), and the way itcreates services (Erl, 2007).

Through the use of service-orientation paradigm, we can design and implement a genericSDImobile node, i.e., reusable in situations other than cadastral use case, and also interoperablewith other SDIs. Services implemented using service-orientation design paradigm encapsulatefunctionality that is not specific for any application, thus, fostering reuse of the services (Erl,2007). Having reusable services in the SDImobile, contributes towards a generic solution. Someof the service-orientation design principles that contribute in achieving our goals are describedbelow.

35


4.3.2 Service-orientation design principles

Services share standardized contracts – Before analyzing the principle, we will explain what is aservice contract. From the perspective of a service consumer, Josuttis (2007) defines a servicecontract as “everything you have to know when using this service”. “Everything” refers to awell defined interface that may include description of the input and output parameters, and othernon-functional attributes such as Quality of Service (QoS) and Service-Level Agreements (SLAs)(Josuttis, 2007). According to Erl (2007), a service contract describes the technical constraints andrequirements (the interface) and also non-technical documentation about the service. These non-technical aspects are consumer specific, and as such are out of the scope of this research. We onlyfocus on the design and implementation of the technical interface of the services.

One of the goals that is aimed by applying this design principle is to increase interoperabilitybetween services (Erl, 2007). For that purpose we can apply standardization, among others, toservice data representation level. Part of a service interface is a formal description of the input/out-put data required by the service. Standardization of the data definitions will allow services toexchange data without the need for transformation between different formats. One of the mainbenefits of such standardization is that it allows the efficient creation of service compositions(Erl, 2007). It should be mentioned here that service data standardization is increasing the inter-operability between services of one SDI node, since the other SDI nodes may use different dataformats. However, if that is the case, what is required in the SDImobile node is a data mappingservice which will transform the data only once. But, if common, widely accepted standards areused, we believe, interoperability between different SDI nodes can be increased as well.

Services are loosely coupled – Loosely coupled is a concept that relates to dependencies thatservices may have on each other and/or with service consumers. The decoupling of servicesfrom service consumers is achieved through well-designed service contracts. This principle aimsat designing services that are independent of their consumers. As a result, services can evolveindependently with minimized impact on each other and service consumers. This principle isconsidered during design step and is achieved by designing service contracts that are decoupledfrom the underlying logic and implementation technology.

Services are autonomous – According to Erl (2007), a service is autonomous if it has controlover needed resources during runtime execution. That means a service should have the control togovern itself during runtime. This self governance somehow makes a service independent of theenvironment (other services), thus fostering loose coupling. By adhering to this principle we candesign services that are predictable and reliable, which are important characteristics of reusableand composable services.

Services abstract underlying logic – The idea behind this principle is that the contract of theservice should be designed in such a way that it publishes to the consumers only the most neededinformation about the service (Erl, 2007). This means that the consumer will know only howto access and call a service, while the logic of the service and other implementation details arehidden. By abstracting implementation details we are able to change the service logic or theimplementation technology without affecting the interaction with the consumers.

These four principles are considered the most important ones and support the realization ofeach other as well as of other principles (usability, composability, statelessness, and discoverabil-ity) (Erl, 2005). These (and other) design principles can be used as guidelines for designing genericand reusable web services, but they can be only applied to some level (Erl, 2007).

36


4.3.3 Analysis

In the service-oriented analysis phase candidate services and operations are identified (Erl, 2005).Those candidate services and operations may or may not be implemented during design phase,hence the name candidate (Erl, 2005). In the analysis we may identify two types of services: task-centric business services and entity-centric business services (Erl, 2005). In the first group belongservices that encapsulate operations that are needed to execute a specific task (Erl, 2005). In thesecond group there are services that are build around entity models (Erl, 2005). Compared to task-centric services, entity-centric service are more generic (Erl, 2005). From the class diagram (Figure3.8) we can identify these entities (that have association with the SDImobile object): cadastral map,parcel, utility data, and address. The identification of candidate operations and services is donethrough several steps, as described in the following.

Decompose the business process

During this step the business processes are decomposed into smaller process steps (Erl, 2005).We have already decompose the cadastral survey process into smaller steps, when we created theSurvey Parcel use case and specified the proper actions needed to realize the underlying businessprocess.

Abstract orchestration logic

In this step, an orchestration service layer is created, which abstracts the part of the processinglogic that would potentially execute in a sequence of steps (Erl, 2005). We identify such processinglogic from the sequence diagram in Figure 3.7 and create one possible workflow as follows:

• Create the parcel polygon

• Request the utility data from the utility SDI node

• Perform overlay between parcel polygon and utility data

• Notify restriction to the cadastral SDI node if there is overlay

• Request the parcel address from the municipality SDI node

• Merge address with the other parcel data

• Send parcel data into the cadastral SDI node

Create business service candidates

In here, we logically group the business steps into candidate services based on the entities identifiedearlier. For instance, we group steps that logically relate to the entities and to each other such asthe Request cadastral map from the cadastral SDI node and Provide cadastral map to the mobile device,under a service named Cadastral map.

• Cadastral map service

· Request cadastral map from cadastral SDI node

· Provide cadastral map to the mobile device

Similarly, we group the other steps in the following candidate services.

37


• Property parcel service

· Convert coordinate system of the boundary points

· Create parcel polygon from boundary points

· Request address from municipality SDI node

· Merge address with other parcel data

· Send parcel data to cadastral SDI node

• Utility data service

· Request utility data from municipality SDI node

· Perform overlay between parcel polygon and utility data

· Notify restriction to cadastral SDI node if there is overlay

We define another candidate service which will group the user session actions as follows:

• User session service

· Authenticate user

· Start user session

· End user session

In this first attempt to identify the candidate services, we have used long names for their opera-tions, in order to keep them as self-descriptive as possible. We will refine those names (and servicenames as well) later on, during the remaining analysis and design steps.

Refine and apply principles of service-orientations

The candidate service operations found earlier will be refined in this step following the principlesof service-orientation. One of the principles is Reusability, which fosters the design of servicesthat are agnostic of the functional context (Erl, 2007). Hence, the focus in this step is to refinethe services and their operations such that they become as reusable as possible. In this respect,we try to refine the candidate services identified in the previous step. For instance, the Requestcadastral map from the cadastral SDI node operation is specific to the cadastral case study, as it ismeant to request a cadastral feature dataset. We can make it more generic by turning it into anoperation that requests a feature dataset from any SDI node. In the same way we can turn thenext operation of the Cadastral map service into an operation that takes as input the feature dataset from the previous operation and creates a map for a mobile device. Thus, we turned twooperations of the Cadastral map service into more generic, thus more reusable. We also give theservice a more general name, which denotes that the map is provided for a mobile device.

• Mobile Map service

· Request a feature dataset from SDI node

· Provide a map for a mobile device

In a similar analysis we consider the first two operations of the Property parcel service. They canboth be used for any situation that requires coordinate reference system transformation and cre-ation of a polygon from measured points. Furthermore, we can provide a more generic operationthat transforms not only the coordinate reference system of point feature, but of any feature data

38


type (Point, Linestring, Polygon1). To make the functionality more complete, another candidateoperation is proposed that creates a linestring feature from points. Therefore we create anothergeneric candidate service that contains the following operations:

• Feature Processing service

· Transform coordinate system of feature dataset

· Create polygon from point feature dataset

· Create linestring from point feature dataset

Here we have added one operation, but more could be added as well in order to make the servicemore general. The remaining operations of the Property parcel service can be made more generalas well. For instance, we can create an operation that requests the address of a given coordinate(not only for a parcel polygon) from an SDI node that offers such a service (not only from themunicipality SDI node). As a result we have:


· Request address from SDI node



Similarly, the first operation of the Utility data service can be made more general such that itrequests utility from any SDI node (not only from the utility SDI node). The second operation canalso be changed in such a way that it is used to performed an overlay between a polygon and a line.Actually, the overlay operation is a logical test derived from the user requirements, as a neededstep in the field survey of the cadastral data. We define it based on spatial relationship predicates(OGC, 2010a), specifically on the Intersect and Touch relationships between two features, a and b,as follows:

a.overlay(b) = a.Intersect(b) and not a.Touch(b)

For the cadastre use case, the overlay operation will be tested between the parcel polygon (a)and the utility linestring (b). However, aiming at designing a generic SDInode we have specified ageneric overlay operation that can be used to test spatial relationship between any feature type (forwhich the Intersect and Touch predicates are specified in the OGC implementation specification(OGC, 2010a)).

The last operation, notify restriction to cadastral SDI node if there is overlay, does not prop-erly fit into the Utility data service. It is an operation that is related with a specific scenario, i.e.,the cadastral data collection. Therefore we decided to move it into the Property parcel service.We have also added two more operations to Feature Processing service, namely Bounding Box andCentroid operations. Bounding Box operation is needed to create the bounding box of the mea-sured cadastral property. Then, this bounding box is used to request the utility data from an SDInode. Similarly, the Centroid operation is used to create the centroid (a location or point) of themeasured cadastral property, which is then used to request the address from the municipality SDInode. The resulting candidate services are given below:

• Feature Processing service

· Transform coordinate system of feature dataset1Point, Linestring, and Polygon feature data types are specified in the OGC (2010a)

39


· Create polygon from point feature dataset

· Create linestring from point feature dataset

· Perform overlay between two features

· Create Bounding Box of a polygon feature

· Create Centroid of a polygon feature

• Utility data service

· Request utility data from SDI node





· Notify restriction to cadastral SDI node if there is overlay

The cadastral survey use scenario includes also the measurement of the building data, if one existsin the cadastral property. The processing of the building data is done similarly to the parcel data,but in less steps. Those steps are: transform coordinate system, create polygon from point andsend data into the cadastral database. All these operations are already identified in the existingcandidate services. Therefore, it is unnecessary to design other services and operations, specificfor the processing of the building data.

During our analysis we turned some of the operations to be more generic so that they canrequest data from any SDI node, not only from cadastre and municipality. This brings the needto find these SDI nodes before asking their data. For this reason we propose another candidateservice which serves the purpose of finding SDI nodes that offer data/services. It is logical to putthe operation of requesting data/services to this newly created service candidate. Thus, insteadof having a request operation in both, Mobile Map and Utility data services, we can have onlyone. This last change leaves the Utility Data service without any operation candidate, thus wedecide not to keep it as a service candidate. In this rationale, we also move the request addressoperation from the Property Parcel service into the new service. But, because the latter requestsdata of a nature different from the former (which request feature datasets), we decide to keep itas a separate operation. As a result, this service encapsulates the candidate operations, as shownbelow.

• Search service

· Search for an SDI node that can offer data/services

· Request feature data from SDI node


Identify candidate service compositions

So far, we have identified candidate services and operations, and also refined them to be as genericand reusable as possible (Figure 4.2). Those services are also business-agnostic, meaning that theyknow nothing about the business process logic. Therefore, there is a need for some services thatcontrol and compose them according to a specific scenario. Such services are called business ser-vices and are primarily concerned with the business logic (Erl, 2005). For this purpose, we add

40


Figure 4.2: Service Candidates

Figure 4.3: Service Composition Representing Cadastral Survey Process

41


another service, Cadastral Survey, which is used to orchestrate candidate application services iden-tified earlier, and support the field cadastral data collection use case (Figure 4.3).

The steps used as guideline during the analysis, were chosen as appropriate to our use case. Erl(2005) provides a more detailed list of steps that can be followed to analyze more complex businesslogic.

4.3.4 Design

We proceed now with the design of the service interfaces. This is in compliance with the sep-aration of concerns as we separate the implementation of the services into three stages: servicelogic analysis, service interface design, and service logic implementation. Here we start by firstdescribing the web service standards and then how we make use of those standards to design theweb service interfaces.

Web services standards

The implementation of the SDImobile, specifically its services, will be realized through the use ofweb services technology. The reason is that web services are implemented through a set of openstandards which foster interoperability regardless of the operating platform and/or programminglanguage used (Fensel et al., 2007). The basic set of standards, referred to as first-generation webservices standards (Erl, 2005), are shortly described below.

eXtensible Markup Language (XML) is a text-based, self-descriptive, and platform-independentformat used for storing and transporting data over the web (Yergeau et al., 2008). XMLSchema Definition Language (XSD) (Fallside and Walmsley, 2004) is used to define the struc-ture of an XML file, i.e., the elements, their attributes and data types that appear in an XMLdocument. In the context of the web services, XSD is used to define the data types that willbe exchanged through messages and processed by services.

Hypertext Transfer Protocol (HTTP) is an application-level (low-level) protocol used for data trans-fer across the Internet (Fielding et al., 1999). It is one of the protocols that can be used tosend and receive data between web services.

Web Service Description Language (WSDL) (Christensen et al., 2001) is also XML-based language,used to describe service operations and how to access them. Specifically, it is used to definethe interface of the service which contains:

• definition of the data types used;

• messages sent and received;

• service operations;

• protocols used by the web service for communication.

Simple Object Access Protocol (SOAP) (Lafon et al., 2007) is a protocol used for communicationbetween web services. It provides a communication framework for exchanging XML-basedmessages between web services. Actually, SOAP provides a standardized envelope thatwraps some meta information—the header of the message,—the body of the message, andalso fault handling information used in case of an error during message transmission.

These standards are recommended by World Wide Web Consortium (W3C)2. Due to thenature of the XML, those standards that are based on XML, can be used to design extensible,

2http://www.w3.org/

42


self-descriptive, and platform-independent interfaces for web services. Although these are openstandards, still interoperability is hard to be achieved due to many versions of these standards(Josuttis, 2007). In such situation, Web Services Interoperability Organization (WS-I)3 has createdprofiles which provide guidelines on how to implement a set of web services standards (of specificversions). The current WS-I Basic Profile 2.0 specification provides guidelines on implementationof web services standards: XML 1.0, WSDL 1.1, SOAP 1.2, HTTP 1.1 (Chumbley et al., 2010).

Besides the first-generation web services standards, there are other recommended standards forweb services implementation, referred to as WS–* standards. One of them is Web Services BusinessProcess Execution Language (WS-BPEL) (OASIS, 2007). WS-BPEL is an XML-based language fordescribing complex business process using the WSDL web service descriptions (Fensel et al., 2007).Using WS-BPEL we can create business processes from the operations of other services, specifyingalso the sequence those operations have to follow.

XML Schema definitions

In the previous section we mentioned that the XSD is the language used for defining types of datathat will be used and exchanged between services. For our purpose we will need to define thosedata types, referred as schema from now on, before starting to design the service interfaces. Fromthe description of the problem domain it is obvious that we need to define schemas for point andpolygon data types. But, instead of creating the schema from scratch we can use the schema de-fined by standardization bodies such as Open Geospatial Consortium(OGC) 4. OGC has createdstandardized schema for storage and transport of geometry data types, using Geography MarkupLanguage (GML). GML is based on XML and used to encode data types that contain both spatialand non-spatial attributes. We use GML 3.1.1 encoding specification (OGC, 2004) for definingXML schemas for our services. We extend them further — since they are build in XML — fordefining new data types for the cadastral data (parcel, building, and their descriptive data) andutility data. Part of the XML schema definition for the cadastral property is shown in Listing 4.1.

Listing 4.1: Cadastral Property XML Schema1 <?xml version="1.0" encoding="UTF−8"?>2 <xs:schema xmlns:sdim="http://www.itc.nl/SDImobile" xmlns:xs="http://www.w3.org/2001/

XMLSchema" xmlns:gml="http://www.opengis.net/gml" targetNamespace="http://www.itc.nl/SDImobile" elementFormDefault="qualified" attributeFormDefault="unqualified">

3 <xs:import namespace="http://www.opengis.net/gml" schemaLocation="GML−3.1.1/base/geometryBasic2d.xsd"/>

It actually shows only the first three lines of the XML code. In the first line of the doc-ument is declared the XML version (1.0) and also the encoding type used in this file (UTF-8). Lines 2 and 3 are the most important in this example. Line 2 defines the namespaces ofthe XML file. Since the XML element names are user-defined, namespaces are used to avoidnaming conflicts when mixing different XML files (Fallside and Walmsley, 2004). Without go-ing into too much details, in our example there are three namespaces defined. The first oneis the namespace (xmlns:sdim="http://www.itc.nl/SDImobile") in which we have defined anddeclared elements of our data types. This is also the target namespace which means that alltypes and elements defined in this XML document belong to it. The elements in the instancedocument are qualified with the namespace prefix (elementFormDefault="qualified"), while at-tributes are not qualified (attributeFormDefault="unqualified"). For instance, a qualified elementin an instance XML document looks like this: <sdim:Parcel>, where sdim is the prefix and

3http://ws-i.org/4http://www.opengeospatial.org/

43


Parcel is the element name. Besides, in this schema definition, we use elements that are de-fined into the other two namespaces (xmlns:xs="http://www.w3.org/2001/XMLSchema" andxmlns:gml="http://www.opengis.net/gml").

The last line of code does nothing more than importing a namespace defined out of the cur-rent document. It also provides the location of the schema document, in which are specifiedelements and types that are needed in the current document. Simply, this line of code imports thenamespace and schema document which define the GML data types.

The schema definitions of the cadastral parcel and the other data types are given in the Ap-pendix A.

Service interface definitions

Having created the XML schemas that define data types, we proceed with creating the serviceinterfaces. We use WSDL 1.1 to specify service interfaces. Basically, what we specify in a WSDLdocument is the service (its location) and the operations it exposes. Besides, in the WSDL docu-ment are described the messages used to communicate with the web service and its binding, i.e.,the type of protocol used for the communication with the service. The type of messages are de-fined in the XSD documents as described in section 4.3.4. Another important element of theWSDL definition is the portType element which defines a set of abstract operations. For each op-eration, an input and an output message is defined, in case it is a request-response operation type,and optionally a fault message for any error that may happen when invoking the operation. Themessage types and protocol details for the operations defined in the portType element are specifiedin a binding (there may be any number of bindings for a portType, as needed). The binding typeused in definitions of web services for the SDImobile is SOAP 1.2 binding. The type of transportfor the SOAP format is HTTP 1.1.

There are two important attributes of the SOAP binding: style and use attributes. The styleattribute defines for each operation the style of messages being used: RPC or document style.If RPC (Remote Procedure Call) style is used then the messages contain parameters and returnvalues. On the other hand, the document style specifies that messages contain documents (forinstance, XML documents) (Christensen et al., 2001). In this research we chose the documentstyle. The use attribute is part of the body of the message and can be of type literal or encoded.We specify the literal type for the body of the message which means that each part of the messageis defined by a concrete schema definition (XSD types specified beforehand). Our choice for thedocument/literal model is based on the fact that it is WS-I compliant, but with a restriction: WS-Iallows only one child in the soap:body element of a message (Butek, 2005). For our services wehave defined operations (such as Overlay operation in ProcessFeature service) that takes a messagewith two parts as input, namely the property polygon and the utility lines. To avoid conformanceissues with WS-I basic profile, another style/use model is used, called document/literal wrapped.It is obviously based on document/literal model, and uses a “wrapper” element which wraps twoinput elements into one thus conforming with the WS-I basic profile. For instance, the Overalyoperation in ProcessFeature service, requires two input documents, a parcel polygon and a utilityline. In the types element of the WSDL document we define an element, called OverlayRequestwhich is a complexType element that contains two elements, a Parcel and a Utility. As a result,the body of the input message for the Overlay operation contains only one element of type Over-layRequest (Listing A.7).

Next, a port element is used to define the endpoint of the binding, by specifying an address. Itactually specifies the URL address where the web service can be reached. The WSDL definitionsof CadastralProperty, UserSession, SearchResources, and ProcessFeature web services are given inAppendix A.2. Names of the service are changed such that they are as self-descriptive as possible.

44


Figure 4.4: Conceptual view of the service composition process in WS-BPEL

The remaining service, MobileMap, is not defined here. We will use existing web map servers,such as UMN MapServer and GeoServer, in order to set up a Web Map Service (WMS) for themobile client. The focus will be on setting up the service with the proper parameters and creatinga client through which WMS can be consumed in a mobile device.

45


Service composition

To support the cadastral use case scenario we need to define a service composition using services/-operations defined in the previous section. We have identified in section 4.3.3 the CadastralSurveyas a candidate service composition. Here we design the service interface using WS-BPEL language.A conceptual representation of the service composition process is shown in Figure 4.4.

The process begins when the user sends the information of the measured parcel from themobile device. After receiving the input, the TransformCoordinate operation of ProcessFeature ser-vice is invoked. The next operation creates the parcel polygon from the parcel boundary points.The AssignProperty operation copies the created polygon to another variable of type PropertyType,which contains the cadastral property element. The assignment operations are used in order tomake possible the message exchange between services participating in the composition.

The execution of the activities is next split into branches, namely GetAddress and GetUtility,which execute in parallel. They are called sequences in WS-BPEL and contain other operationsthat execute sequentially. The GetUtility sequence contains an If control element which is usedto test the result of the Overlay operation and invoke the PutRestriction operation. After theexecution of both sequences, the cadastral property data is sent to cadastral SDI node and thecomposite process exits by replying an output message (for instance, a message that tells the userthat the process is finished). For the sake of simplicity, we are only considering the successful flowof the composite process. The complete WSDL code of the composite process is given in ListingA.11.

4.4 SUMMARY

In this chapter we analyzed and designed an SDI node for mobile clients (SDImobile) using ser-vice orientation design principles. During analysis, we have identified a set of candidate webservices and their operations. Then, during the design phase, we have designed the data types(XSD schemas) and service interfaces (WSDL). At the end, we have designed the interface of thecomposed service using the interface definitions of the other web services.

46


Chapter 5

Prototype implementation and testing

5.1 INTRODUCTION

In this chapter we complete the development process by implementing and testing a proof-of-concept prototype. The prototype contains some of the operations of SDImobile web services –the server side –, as well as a simple graphical user interface (GUI) for the mobile device – the clientside. We start by giving a short description of the free and open source technologies and tools forimplementing the client for the mobile device (section 5.2) and the functionality of SDImobilenode (section 5.3). The implementation and testing of the prototype is described in section 5.4.

5.2 TECHNOLOGY AND TOOLS FOR IMPLEMENTING MOBILE DEVICE CLIENT

The implementation of the client for the mobile device requires some attention due to the devicelimitations. We focus on tools that allow to implement OGC compliant clients, i.e can consumeOGC geo services such as WMS.

One of the free tools for mobile GIS is the gvSIG Mobile1. It offers functionality for access-ing different vector and raster formats, consume OGC services, zooming/panning, capture GPScoordinates, etc. However, it is only available for mobile device that run on Windows 5.0 and 6.0operating systems. Hence, the range of mobile devices that can use gvSIG is limited.

OpenLayers library2 is another alternative for building the mobile device client. It pro-vides an Open Source, JavaScript API which is used for viewing and interacting with dynamicmaps in a web browser. OpenLayers implements OGC standards for accessing geoinformationthrough web services such as the Web Map Service (WMS) (OGC, 2006) and Web Feature Ser-vice (WFS) (OGC, 2010b) standards. It offers functionality for creating graphical user interfaces(GUI) through which the user can pan, zoom in/out, switch layers on/off, get information fromthe map, and so on. The user can use these tools by means of input devices such as mouse andkeyboard. But most of the mobile devices do not have conventional mouse and keyboard, whichmakes the web client practically unusable by a mobile device. They usually have a touch screen(allows the user to interact with the device by touching the screen) and a small keyboard. Effortsare ongoing by the CampToCamp Geospatial Solutions team to adapt the OpenLayers libraryfor use with mobile devices (Quartier, 2010). Special attention is paid to the optimization of thelibrary (size and performance), having in mind the device limitations. Actually, the team has re-leased the first results as a demo, only for testing purposes (there is no code available to be usedfor implementation).

Another useful technology for implementing the mobile client is AJAX3 (AsynchronousJavaScript and XML). It is a technique that combines existing internet standards (JavaScript,XML, etc) which allows asynchronous exchange of data between the client and the server. That

1http://www.gvsig.org/web/projects/gvsig-mobile2http://www.openlayers.org/3http://www.w3schools.com/Ajax/Default.Asp

47


means the data exchange happens on the background without disturbing the user experience withthe main web page.

5.3 TECHNOLOGY AND TOOLS FOR IMPLEMENTING SDImobile NODE

The functionality on the server side is built using Active Server Pages (ASP) technology andPython4 programing language for the scripting of ASP. The ASP technology – first introducesby Microsoft5 – provides a server-side scripting platform for building and running dynamic webapplications. Among several scripting languages that can be used to code ASP, we choose Pythonas one of the most robust and powerful programming languages. Furthermore, to implement therequired functionality in SDImobile, we use built-in or third-party Python packages, such as:

• pyproj6: provides a Python interface for the PROJ.4 – Cartographic Projections Library7

which is used to perform spatial reference system coordinate transformation;

• shapely8 — a Python package used to perform analysis on planar geometries. It is based onGEOS9 (Geometry Engine - Open Source) and JTS10 ( Java Topology Suite) libraries. TheGEOS library is based on OpenGIS Simple feature access specification (OGC, 2010a).

• lxml11 — a library for working with XML and HTML in Python.

The Web Map Service (WMS) is created using the MapServer software (server) which wasoriginally developed at the University of Minnesota12. We also use MapServer to create two WebFeature Services (WFS), one for serving cadastral data and the other for the utility data. AnotherOGC compliant service that we create and use is a Transactional Web Service (WFS-T), used forstoring measured data in the cadastral database. For this purpose we use the GeoServer13 software(server), which like the MapServer, is an Open Source software which implements the OGCstandards.

We use PostgreSQL/PostGIS14 RDBMS as back-end for storing and managing cadastral andutility data.

5.4 PROTOTYPE IMPLEMENTATION AND TESTING

The functionalities of the proposed system implemented into the prototype are chosen to be asrepresentative as possible. The client is a simple web page that runs on the mobile device’s webbrowser. It provides the user a graphical interface for displaying a map and also some buttonsfor interaction. We also implement the functionality for capturing the position of the mobiledevice. The input data captured by the client during the field survey are sent into the server, theSDImobile component. We choose to build a web-based client as nowadays web browsers arepre-installed in the the mobile devices. This will increase the usage opportunities of the client.

4http://python.org/5http://msdn.microsoft.com/en-us/library/aa286483.aspx6http://code.google.com/p/pyproj/7http://trac.osgeo.org/proj/8http://pypi.python.org/pypi/Shapely9http://trac.osgeo.org/geos/

10http://www.vividsolutions.com/jts/jtshome.htm11http://codespeak.net/lxml/12http://mapserver.org/13http://geoserver.org/display/GEOS/Welcome14http://www.postgresql.org/

48


Furthermore, there is no need for installing the client in the mobile device, thus reducing thedeployment time and costs.

In the SDImobile we have chosen to implement some of the functionalities (operations) ofthe designed web services. The list of the functionalities contains: Web Map Service for themobile client; transform the measured coordinates from WGS84 into the Dutch reference system(RD_New); convert the measured points into a polygon which represents the cadastral parcelpolygon; retrieve the utility data from a Web Feature Service; perform an overlay (as defined insection 4.3.3) of the parcel polygon and utility data; and store the parcel polygon and the result ofthe overlay operation into the cadastral database.

The following sections provide more details of the implementation of the client and servercomponents.

5.4.1 Mobile client implementation

We use OpenLayers library and AJAX to implement a Graphical User Interface for the mobileclient, which can be accessed through any web browser. It is a thin, web-based, client which allowsthe user to display and interact with a map. To make our client usable for touch screen devices weuse a JavaScript script which provides support for touch gestures15. Basically, the script includestouching event handler to allow the user pan the map and touch (click) buttons and other mapcontrols.

The map displays three layers: OpenStreetMap16 layer, cadastral parcels layer, and measuredpoints layer. The first one is a base layer used by the user for orientation. The cadastral map layerdisplays the cadastral parcels, the existing and the measured ones. While the last one stores themeasured device location during field survey. The first two layers are displayed in image format,while the points layer is a vector format.

The mobile client will be used to capture cadastral parcels and buildings in the field, thus itis provided with functionality to capture the device location. To build such functionality we useGeolocation API (Popescu, 2010), which allows a web-based application to capture the locationof the device. The API uses different technologies for capturing the position such as GlobalPositioning System (GPS), IP address, WiFi and Bluetooth MAC addresses, GSM/CDMA celltower position, and so on, but without knowing which one is being used. However, API can beconfigured through the use of parameters in order to capture the location with the highest possibleaccuracy. It actually captures the device location as a pair of longitude/latitude coordinates inWGS84 reference system, and also gives an indication of the measurement accuracy.

We also provide the user with a function for deleting the incorrectly measured points. Thisfunction deletes the last measured point and does not allow the user to explicitly select the pointthat will be deleted.

After being surveyed, the boundary points of the cadastral parcel can be sent to SDImobile inan asynchronous call. This means the send operation is done without disturbing the user experi-ence and reloading the entire web page. The user will only see the response from the SDImobilecomponent (see next section), displayed in a text box, and based on that s/he may take otheractions (for example, delete and remeasure the boundary points). If the data processing in theSDImobile is successful and the measured parcel is stored in the cadastral database, then the usercan see the new parcel displayed in the map.

For more details on the mobile client implementation, refer to the HTML/JavaScript code inappendix B.1.

15The script is created by Anders Brownworth, http://anders.com/cms/352/OpenLayers/iPhone/Android/Touch.Gestures

16http://www.openstreetmap.org/

49


5.4.2 SDImobile implementation

The first call that the mobile client sends to SDImobile is a request for a Web Map Service. Thecadastral data are retrieved from a PostgreSQL/PostGIS back-end database. The database storescadastral parcel polygons of Enschede city, in The Netherlands. The WMS fetches the cadastraldata from the database and generates a map for the mobile client. From the many configurationoptions used to create the WMS, the output type is important to be mentioned here, since themap will be displayed by the mobile device. From the vector formats that MapServer offers wetested the Scalable Vector Graphics (SVG) and one of its extensions, the goSVG. goSVG formatis an extension of SVG Tiny, the recommended image format for use in mobile phones (Capin,2003). However, SVG is XML-based format and due to the high level of details in the cadastraldata, the layer size can grow up to several mega bytes. Loading and parsing such big layer reducesthe performance of the mobile device considerably and may even crash the web browser. Weconsider also the wireless communication bandwidth and costs and decide not to use a vectorformat for displaying the cadastral map. Instead, we use Portable Network Graphics17 (PNG),an image format supported by MapServer, for creating the cadastral map. It offers good qualityand small size of the output map, which reduces the load time in the mobile device (as comparedwith other image formats supported by MapServer). The WMS configuration code is shown inappendix B.2.

However there may be situations, such as updating a parcel’s boundary, when a vector layer isrequired. In such situation the amount of data that would be loaded is small (one or several parcelsat a time) and could be easily handled by the mobile device.

The other functions of the SDImobile are implemented using Active Server Pages and Python.In ASP, the input data (boundary points) are retrieved from the client. We use PROJ.4 libraryto implement the coordinate transformation function. That function is used to transform theboundary points from the WGS84 reference system into the Dutch reference system (RD_new),which is the reference system of the cadastral parcels of Enschede. Another function takes thetransformed points as input and creates a polygon, and also checks if it is a valid geometry (asdefined by OGC (2010a)). If the polygon is invalid, an informing message is send to the clientand the server operation is stopped. Otherwise, we call a WFS service of the utility lines. Oneof the parameters used in the service call is a bounding box, which tells the service to return onlythose features that fall within this bounding box. The bounding box, created from the measuredpolygon, is used to limit the number of features returned from WFS. Sending an unlimited requestto a server that stores the utility data of an entire city, may cause problems for the WFS serveras well as for SDImobile that will handle and process the result. The configuration of the utilityWFS is shown in appendix B.2.

The output of the WFS call is returned in GML format. We parse the GML and extract theline coordinates from it. From the extracted coordinates we create a Multilinestring geometry andperform the overlay operation with the cadastral parcel polygon. The output of the overlay isreported back to the mobile client and also sent to the cadastral database (as explained later).

We use a WFS-T (Transactional Web Feature Service) for storing the measured data into thecadastral database. While a WFS is a read-only service that retrieves features from a data source,a WFS-T is able to create, update and delete features of a data storage. We use the GeoServer forsetting up the WFS-T. The service accepts the call through a POST HTTP protocol. The body ofthe message that is sent to the WFS-T is given in Listing 5.1.

Listing 5.1: WFS-T Request Content<wfs:Transaction xmlns:wfs="http://www.opengis.net/wfs" version="1.0.0"

17http://www.libpng.org/pub/png/pngintro.html

50


xmlns:enscad="http://www.itc.nl" service="WFS"><wfs:Insert><enscad:enscadparcels xmlns:enscad="enscad"><enscad:geom><gml:MultiPolygon xmlns:gml="http://www.opengis.net/gml" gid="1" srsName="http://www

.opengis.net/gml/srs/epsg.xml#28992"><gml:polygonMember><gml:Polygon><gml:outerBoundaryIs><gml:LinearRing><gml:coordinates decimal="." cs="," ts=" ">

258884.72,468540.49 258880.77,468542.14 258888.30,468566.04 258893.84,468564.28258894.98,468562.06 258894.01,468558.99 258893.01,468555.8258889.08,468543.32 258884.72,468540.49

</gml:coordinates></gml:LinearRing></gml:outerBoundaryIs></gml:Polygon></gml:polygonMember></gml:MultiPolygon></enscad:geom><enscad:overlays>true</enscad:overlays></enscad:enscadparcels></wfs:Insert></wfs:Transaction>

Basically, it tells the server to perform a transaction using the Insert operation. The transactionis compliant with the WFS 1.0.0 version. The WFS server receives the transaction request andinserts the encoded data into the enscadparcels feature (the cadastral parcels feature). The data areinserted into the geom and overlays attributes of the enscadparcels feature. The geometry data areencoded in GML 2.1 format which is the supported format for the WFS 1.0.0. The XML contentof the transaction is created using the lxml module for Python. It is possible to parse the GML 2.1schema definition and generate from that the XML encoding of the geometry attribute includedin the transaction body. That would allow the SDImobile component to generate transactionsthat would insert data in any GML defined geometry attribute. However, due to the limited time,we only hard-coded the body of the transaction in a Python script.

After invoking the WFS-T insert operation, we get the server’s return status (successful trans-action or not) and report back to the mobile client. This is the last operation performed by theSDImobile component.

We created the WFS service of the utility lines to prove the ability of the SDImobile nodeto communicate with other SDI nodes which offer OGC compliant services. Furthermore, wecreated the WFS-T service and invoked it to prove that the SDImobile is able not only to retrievedata from other SDInodes but also to generate OGC compliant data and submit them using OGCcompliant services. Neither of these services is part of the SDImobile component; they shouldexist into other SDI nodes (cadastre, municipality or other) and should only be invoked by theSDImobile. We are implementing them only for testing our prototype.

For further details on SDImobile implementation, refer to appendix B.2.

5.4.3 Prototype testing

Testing is part of any system development process. We have implemented our prototype (bothclient and server components) in an iterative process in which bits of code were developed, tested,

51


improved, tested again, and so on. Besides, we compiled the code snippets together and performeda final test. The test was run on the parking lot of the ITC building without using any wirelessconnection. But prior to that, we loaded the client into the mobile device using the wirelessconnection inside ITC building. Since the client is JavaScript-based, after loading in the browser,it can run in offline mode. Actually it is cached by the mobile browser and can be used offline.Tests show that mobile phone browsers can cache JavaScripts of sizes up to 4MB (Grove, 2010).However, there is no indication of browser cache size limit (it may vary based on the device andweb browser type), thus we cannot determine the number of points that can be measured inoffline mode. Furthermore, the data are cached on memory and can be lost if the device is turnedoff or run out of battery.

Figure 5.1: Measured points with Mobile Client

The test showed that the mobile device can be used to measure points in offline mode. Besidesthe client JavaScript, the web browser could cache the background maps and the measured pointsas well. With this setup, we started to measure points. The mobile client was able to measurepoints instantly, but the accuracy was not good enough (about 200 meters) so we had to deleteand remeasure several times the same point. It seemed like the device was caching the measuredpoint and returned the same coordinate several time, although we had set it up to avoid that.Because of the low accuracy of the measurements, we suspected that the device was not using GPS

52


but some other technology (most probably the cell tower triangulation). But, the GeolocationAPI does not know which technology is being used so we had no clue about that. However,we removed the SIM card from the mobile phone and switched of the wireless connection. Thisway we were sure that the Geolocation API was calculating the position only using the GPS (if itcould).

So, we started to measure some point coordinates. In the beginning the device was not able toget accurate position (accuracy was in the range of 50 meters). We had to measure and delete pointscontinuously for about 3 to 4 minutes until the measured points were in the same position andthe indicated accuracy value was not changing. As it came out later, when we checked the resultsof the measurement, the reported accuracy was far from the real accuracy. The Geolocation APIwas reporting the accuracy not better than 9 meters, but we found that the residuals for one pointwere less than 1 meter (δx = −0.45m and δy = 0.99m).

After about 30 minutes of testing we could measure 7 points (Figure 5.1). At a later moment,when a wireless network was available, the measured data were sent into the server and processedfurther.

The test was performed using an Apple iPhone 3G device.

5.5 SUMMARY

In this chapter we implemented and tested a proof-of-concept prototype. We have used free andopen source software to implement both components, the client and server. To implement theclient, we have used OpenLayers library, JavaScript, and AJAX. On the server side we have usedASP coded in Python. We also used MapServer and GeoServer software to create OGC compliantgeo web services. Finally, we performed a test simulating a field data collection to check thefunctionality of the implemented prototype.

53


54


Chapter 6

Discussion, conclusions and futurerecommendations

In this chapter we give a summary of the research based on the objectives, methodology, analysesand design, and the prototype implementation. We discuss the research questions and how wehave tried to answer them in section 6.1. Then we draw some concussions of this research insection 6.2. Finally, we give some recommendations on what we think can be improved in thefuture (section 6.3)

6.1 DISCUSSION ON RESEARCH QUESTIONS

The objective of this research was to design a generic Spatial Data Infrastructure (SDI) node whichwould facilitate mobile field data collection in a cadastral application. Although, different meth-ods exist and are being used, we proposed to use a mobile device for collecting cadastral data inthe field. This new method will allow to collect in an integrated way both, spatial and non-spatialcadastral data. In this approach, the mobile device will communicate with SDI nodes and consumetheir services in order to complete its tasks.

Besides being suitable as lightweight and easy to use, the mobile device suffers from somelimitations. It has small screen size, small memory and processing power, and uses wireless net-works which are unreliable and more expensive as compared to wired networks (Rabin and Mc-CathieNevile, 2008). Therefore, we had to take into consideration these limitations while design-ing the field data collection system for cadastre.

To achieve the objective, we have studied different cadastral systems in developed and devel-oping countries, and created a field data collection scenario. Basing the use scenario in differentsystems (not tailored to one country) would allow us to create a generic mobile data collectionsystem. We also discussed the use scenario with experts in the Dutch cadastre system.

After creating the use scenario (section 2.4), we studied some of the possible methods fordesigning the system. There are different design methods in the information technology domainsuch as the waterfall method, iterative method, object-oriented method, etc. To analyze the userrequirements captured in the use scenario, we used the Unified Process as a guide for conductingan object-oriented analysis and design. The Unified Process was chosen because of its iterative anduse case oriented nature.

We analyzed the user requirements and created a use case as a set of actions (table 3.1). Then,we put these actions into an activity diagram which showed the flow of the activities in the pro-posed system. Looking at the use case and the activity diagram, it became obvious that using amobile device for performing such activities was not a good solution. The number of activitiesand communication load between the mobile device and the SDI nodes would have put the deviceinto real difficulties. Instead we proposed another component, named SDI node for mobile client– SDImobile, which will play the role of a middleware. It will sit between the mobile client andother SDI nodes and will handle the communication between them. Besides, it will perform someof the required activities for the mobile data collection use case.

55


We analyzed further the use case and its actions and separate them between the mobile deviceand the SDImobile component. In this separation, we assigned the mobile device only to collectthe cadastral data in the field and send them to SDImobile. It is the SDImobile that will receivethe input data, request more information from other SDI nodes, perform some data processing,and finally send the data into the cadastral SDI node. We believe that such separation of activitieswould allow the mobile device to perform efficiently while being supported by SDImobile.

The SDImobile component, being an SDI node, requires further analysis and design. We fo-cused on designing a generic and interoperable SDI node. By being generic, the SDImobile couldbe used in other situations as well. By being interoperable, the SDImobile could communicatewith other SDI nodes using OGC standards, consuming their services as well as offering its ser-vices to them. Since the services are the core of an SDI node (Morales et al., 2008), we focused ondesigning a set of generic services for SDImobile.

During our analysis we followed the principle of separation of concerns. Morales et al. (2008)identify three levels of concern in the context of a service: the purpose, the interface, and theinside. In this respect, we performed an analysis in which we defined the purpose of the servicesand then based on that, we designed the services’ interfaces. The inside — the logic behind theservices — is implemented in a later phase.

We considered the service orientation paradigm for analyzing and designing the SDImobile’sweb services. In order to create generic and reusable web services we followed some of the serviceorientation design principles. During a service orientation analysis we were able to identify aset of candidate services for SDImobile. These services should be designed and implemented asweb services in order to be accessed by a mobile device and other SDI nodes. In this respect, weselected web standards that would allow us to create interoperable web services. Some of the webservices standards that we used are:

• eXtensible Markup Language (XML);

• XML Schema Definition Language (XSD);

• Hypertext Transfer Protocol (HTTP);

• Web Service Description Language (WSDL);

• Simple Object Access Protocol (SOAP);

• Web Services Business Process Execution Language (WS-BPEL).

These are open standards that allow to build self-descriptive, extensible, and platform-independentweb service interfaces. However, because they exist in different formats, it may be difficult toachieve interoperability (Josuttis, 2007). To cope with this drawback, we followed the WS-I (WebServices Interoperability Organization) Basic Profile 2.0 specification which provides guidelineson which standards’ versions to use in order to design interoperable web services.

Using the right standards’ versions we designed the web services interfaces. The interface isimportant in designing web services because it provides the user with the right information aboutthe service. Basically, it is the only “point of contact” with the service which tells the user howto invoke the services, i.e., the input and output parameters and other technical details. There-fore, we started by first designing standardized input/output data formats (schemas). This wouldincrease the interoperability between services since there will be no need to convert between dif-ferent data formats during message exchange. In the context of the cadastre, there is a need tostore spatial and non-spatial information. We used Geography Markup Language (GML) schemarepresentation, defined by the Open Geospatial Consortium (OGC), and extended them to createschema definitions for the cadastral data types (parcel, building, etc).

56


Next, we defined the services’ interfaces. A service interface has the following information:

• definition of the data types used (schemas defined previously);

• messages send and received;

• service operations;

• protocols used by the web service for communication.

SOAP binding is important as it defines the type of messages being exchanged between ser-vices. It has two attributes: style and use. The style attribute specifies the message style for eachoperation, RPC or document style. The use attribute defines the body of the message to be literalor encoded. We chose document/literal combination for these attributes as it is WS-I compli-ant. However, some of the operations that we have defined require messages that have two parts,which does not comply with the WS-I profile. To deal with this compliance issue we have used a“wrapper” element to wrap the two parts into one, inside the message.

The last service we have designed is a composite of the others. Web services are agnostic of thecontext they are being used. Therefore, we have created a composite service which orchestrates theother services in support of the mobile cadastral data collection use case. To create the compositeservice we have used the WS-BPEL language.

We have continued with finding free and open source software that can be used to build aninteroperable and OGC-compliant prototype of the mobile data collection system. The prototypehas two components, a client for the mobile device and the server where we implemented someof the SDImobile services’ operations. In the client, there is a need for a map viewer and sometools for data collection. From the available software that could be used to implement the client,we chose the OpenLayers library for two reasons. First, it is OGC-compliant and second, itallows to create a client for web browsers. Being OGC compliant is one of our requirements, andthis contributes towards interoperability. As nowadays mobile devices are equipped with webbrowsers, by creating a client for the web browser we widen the range of the mobile devices thatcan be used for the field survey. Furthermore, modern web browsers implement GeolocationAPI, which provides the positional information of the device.

On the server side we have used Active Server Pages, scripted in Python programming lan-guage. Python is one of the most powerful and robust programming language. Furthermore,there are available third-party packages for Python that we have used to build the required func-tionalities for the server component. Such functionalities include: Web Map Service (WMS) forthe mobile client, reference coordinate system transformation, create polygon from the measuredboundary points, retrieve utility data from an SDI node and perform an overlay of the polygonand utility data, and finally store the data into the cadastral SDI node.

We have used the technology and created a proof-of-concept prototype. The OpenLayerslibrary does not have support for mobile devices with touch screens. Therefore, we have usedsome JavaScript scripts that provided us with the touch gestures for interacting with the map inthe mobile device. We also implemented functionalities for capturing point coordinates (longi-tude/latitude) and also deleting them. The functionality for sending measured coordinates to theserver was implemented by using AJAX (Asynchronous JavaScript and XML) technology whichallowed us to make asynchronous calls.

On the server, we have used MapServer and PostgreSQL/PostGIS for creating the map forthe mobile client. By using MapServer we retrieved the cadastral data of Enschede from thedatabase and created a map for the mobile client. MapServer is capable of providing both vectorand image formats. But, creating a vector map for a mobile device is not recommended, especially

57


when using detailed information such as cadastral parcels. Thus, we created an image map usingPortable Vector Graphics (PNG) format, because it offers good quality and small size of the map.

The measured point coordinates were retrieved and processed in the server. First, we used afunction that transformed them from the WGS84 into the Dutch (RD_New) spatial reference sys-tem. Then, another function creates a polygon using the transformed coordinates. We retrievedthe utility lines from a WFS and performed an overlay with the parcel polygon created earlier.Next, we sent the parcel polygon and the result of the overlay into the cadastral database using aTransactional Web Feature Service (WFS-T). This last operation concludes the workflow of themobile cadastral data acquisition using the prototype.

Finally we have performed a test to see if the prototype could be used to measure cadastraldata in the field. We have used an Apple iPhone 3G device and simulated a field survey in thesurroundings of ITC building. We loaded the client into the mobile device using the ITC wirelessnetwork. Later, in the field we were able to measure the points in offline mode. The mobile devicewas able to cache the client (JavaScript and maps) and the measured points and later, when thewireless network was available, sent them to the server. The test showed that the mobile devicewas able to measure point coordinates and send them to the server for further processing.

6.2 CONCLUSIONS

In this research we have proposed a system for mobile data capture in the context of a cadastreapplication. We were able to collect the user requirements for a cadastral data collection andcreated a use case where a mobile device could be used. Using adequate analysis and design meth-ods, we were able to design an OGC compliant, interoperable SDI node for supporting the fielddata collection. We used free and open source software to implement and test a proof-of-conceptprototype. Using the prototype we were able to simulate a field data collection.

We believe that the combination of a mobile device which is lightweight, practical, easy touse and equipped with a GPS receiver, and an SDI node that offers interoperable, platform-independent and OGC compliant web services, is very promising and has great potential to offerfor mobile field data collection.

In general, an SDI node such as SDImobile, is useful in mobile data capture applications be-cause it can assist a mobile application in two ways. First, it will handle the communication withother SDI nodes and request the needed resources for the given application. The mobile devicewill communicate with only one SDI node instead of communicating with many of them. Thisreduces the communication of the mobile device which is especially important due to the unre-liability of wireless networks. Secondly, in a mobile data collection application there may be aneed for data processing tasks. Such tasks can be handled easily by an SDI node, instead of askinga resource-constraint mobile device to perform them.

Such an SDI node can be designed to be as generic and interoperable as possible. The genericnature of the SDI node can be achieved by designing reusable web services which are based onopen web standards (for example OGC web service standards). The use of open standards, on theother hand, contributes towards achieving interoperability.

Furthermore, free and open source software can be used to implement the client for the mo-bile device and the functionalities of the SDI node.

6.3 RECOMMENDATIONS FOR FUTURE WORK

Although in this research we have answered the research questions adequately, there is still roomfor improvements and further research. We are giving in the following some recommendations

58


that, we believe, would contribute to some improvements on the usage of the mobile devices forfield data collection.

On the cadastre use case We have created a use scenario for cadastral data collection, but limitedonly to capture new parcels. In the cadastral domain, field surveying includes also the up-dates of the existing cadastral parcels. In this respect, the use scenario for field survey couldbe extended. Furthermore, we are considering only the survey of one cadastral parcel at atime. We are well aware that, especially in developing countries where consolidated cadastreinformation does not yet exist, there is a need to collect boundary points and descriptive in-formation for many parcels. In this situation there is a need for some mechanism to connectthe points into boundaries. Furthermore, depending on the cadastre system, there may bea need to collect boundary related information. In this context, further investigation andresearch could be done on how to extend the use scenario and provide functionality forhandling field data collection on a massive scale.

On the mobile device In the context of cadastre there are two types of data to be collected inthe field, spatial and non-spatial. In this research we have implemented a prototype thatcollects only the spatial data. It would be interesting to extend the mobile client such thatit provides the user with functionality to capture descriptive data as well. Furthermore, itis interesting to investigate on how to generate forms for data entry automatically from theschema definition of cadastral SDI nodes. This would contribute towards creating a moregeneric system for field data collection.

Another issue in the mobile device is the lack of the wireless networks in the field. Insuch situation the mobile device should be able to collect data and store them locally, andlater send them to the server when the wireless connection is reestablished again. In thisresearch we have used the web browser cache memory for storying the client scripts and thecaptured data. However, there is no information on the size of the cache memory, whichmay also vary from device to device. And, what is more important, the cache memory isnot persistent and data may be lost if the device is turned off. For those reasons we proposethat other solutions be investigated, such as storing data into a database inside the mobiledevice.

In this research we tested our prototype using an Apple iPhone 3G device. Other mobiledevices, running on different platforms and having different web browsers, should be usedto test the prototype.

On the SDImobile We aimed at designing a generic and interoperable SDI node for supportingthe field data collection. In this respect we have designed a set of web services with theirdata and interface definitions. However, we could only implement some of the designedoperations in an Active Server Pages script. It would be interesting to implement all thedesigned web services and test their functionality and especially their interoperability withother SDI nodes. Further, SDImobile could be extended with more web services and oper-ations. One of the functionalities that SDImobile could provide is a service for monitoringthe user activity. That could help the user with proper information on the processing inSDImobile, especially when there are errors or inconsistencies in the data that would stopthe processing.

59


60


Bibliography

Arlow, J. and Neustadt, I. (2002). UML and the Unified Process: Practical object-oriented analysisand design. Addison Wesley, Boston etc.

Biuk-Aghai, R. P. (2004). A Mobile GIS Application to Heavily Resource-Constrained Devices.Geo-Spatial Information Science, 7(1):50–57.

Booch, G., Maksimchuk, R. A., Engle, M. W., Young, B. J., Conallen, J., and Houston, K. A.(2007). Object – oriented analysis and design with applications. Addison Wesley, Upper SaddleRiver, third edition.

Booth, D., Haas, H., McCabe, F., Newcomer, E., Champion, M., Ferris, C., and Orchard, D.(2004). Web Services Architecture. Online. W3C Working Group Note. Accessed on Sept 23,2010, from http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/.

Brinkhoff, T. (2008). Supporting Mobile GIS Applications by Geospatial Web Services. In ISPRSCongress Beijing 2008, Proceedings of Commission IV, volume XXXVII, pages 865–870.

Brinkhoff, T. and Weitkämper, J. (2005). Mobile Viewers based on SVG±geo and XFormsGI. In8th AGILE Conference on Geographic Information Science, Estoril, Portugal, pages 599–604.

Butek, R. (2005). Which style of WSDL should I use? Online. Accessed on Dec 29, 2010, fromhttp://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/.

Capin, T. (2003). Mobile SVG Profiles: SVG Tiny and SVG Basic. Online.W3C Recommendation. Accessed on Jan 22, 2011, from http://www.w3.org/TR/2003/REC-SVGMobile-20030114/.

Casademont, J., Lopez-Aguilera, E., Paradells, J., Rojas, A., Calveras, A., Barceló, F., and Cotrina,J. (2004). Wireless technology applied to GIS. Computers & Geosciences, 30(6):671–682.

Christensen, E., Curbera, F., Meredith, G., and Weerawarana, S. (2001). Web Services DescriptionLanguage (WSDL) 1.1. Online. W3C Note. Accessed on Dec 15, 2010, from http://www.w3.org/TR/2001/NOTE-wsdl-20010315.

Chumbley, R., Durand, J., Pilz, G., and Rutt, T. (2010). Basic Profile Version 2.0. Online. WebServices Interoperability Organization. Accessed on Dec 27, 2010, from http://ws-i.org/Profiles/BasicProfile-2.0-2010-11-09.html.

CLC (2009). Land Registration and Cadastre in selected European Countries, CLC-series, volume 29.Neuer Wissenschaftlicher Verlag, Wien.

Cockburn, A. (1998). Basic use case template. Online. Accessed on Nov 15, 2010, from http://alistair.cockburn.us/Basic+use+case+template.

de By, R. A., Lemmens, R., and Morales, J. (2009). A skeleton design theory for spatial datainfrastructure. Earth Science Informatics, 2(4):299–313.

61


Doyle, J., Bertolotto, M., and Wilson, D. (2010). Evaluating the benefits of multimodal interfacedesign for CoMPASS – a mobile GIS. GeoInformatica, 14(2):135–162.

Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR.

Erl, T. (2007). SOA Principles of Service Design (Prentice Hall Service-Oriented Computing Seriesfrom Thomas ERL). Prentice Hall International.

Fallside, D. C. and Walmsley, P. (2004). XML Schema Part 0: Primer Second Edition. On-line. W3C Recommendation. Accessed on Dec 8, 2010, from http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/.

Farkas, K., Wellnitz, O., Dick, M., Gu, X., Busse, M., Effelsberg, W., Rebahi, Y., Sisalem, D.,Grigoras, D., Stefanidis, K., and Serpanos, D. (2006). Real-time service provisioning for mobileand wireless networks. Computer Communications, 29(5):540–550.

Fensel, D., Lausen, H., Bruijn, J., Stollberg, M., Roman, D., Polleres, A., and Domingue, J. (2007).Enabling Semantic Web Services. Springer Berlin Heidelberg.

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and Berners-Lee, T. (1999).Hypertext Transfer Protocol – HTTP/1.1. Online. Accessed on Dec 27, 2010, from http://www.ietf.org/rfc/rfc2616.

Gorton, I. (2006). Essential Software Architecture. Springer Berlin Heidelberg.

Grove, R. (2010). Mobile Browser Cache Limits, Revisited. Online. Ac-cessed on Feb 11, 2011 from http://www.yuiblog.com/blog/2010/07/12/mobile-browser-cache-limits-revisited/.

Hall, M. and Gray, P. (2004). Mobile Support for Team-Based Field Surveys. In Brewster, S. andDunlop, M., editors, Mobile Human-Computer Interaction – MobileHCI 2004, volume 3160 ofLecture Notes in Computer Science, pages 105–217. Springer Berlin /Heidelberg.

Henssen, J. (1995). Basic Principles of the Main Cadastral Systems in the World. In Proceedings ofthe One Day Seminar held during the Annual Meeting of Commission 7, Cadastre and Rural LandManagement, of the International Federation of Surveyors (FIG), May 16, Delft, The Netherlands.

Hull, E., Jackson, K., and Dick, J. (2005). Requirements Engineering. Springer London, secondedition.

Hunt, J. (2000). The Unified Process for Practitioners : Object - Oriented Design, UML and Java.Practitioner Series;*1. Springer, London etc.

Hunt, J. (2003). Guide to the Unified Process featuring UML, Java and Design Patterns. SpringerProfessional Computing. Springer London.

IEEE Computer Society (2000). IEEE Recommended Practice for Architectural Description ofSoftware-Intensive Systems. IEEE Std. 1471-2000.

International Federation of Surveyors (1995). The FIG statement on the cadastre. InternationalFederation of Surveyors (FIG), Belconnen, A.C.T.

Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process.Object Technology. Addison-Wesley, Boston etc.

62


Jazoj, A., Lamani, S., and Lira, L. (1997). Surveying and Mapping Strategy for Supporting theEmerging Land Market in Albania. Land Tenure Center, University of Winsconsin-Madison.Working Paper, No. 2.

Josipovic, T. (2009). Land Registration and Cadastre in Croatia. In Land Registration and Cadastrein selected European Countries, pages 97–119. Neuer Wissenschaftlicher Verlag, Wien.

Josuttis, N. M. (2007). SOA in Practice: The Art of Distributed System Design. O’Reilly Media,Beijing etc, first edition.

Kaufmann, J. and Steudler, D. (1998). Cadastre 2014 : A Vision for a Future Cadastral System.International Federation of Surveyors (FIG).

Kim, J.-W., Park, S.-S., Kim, C.-S., and Lee, Y. (2004). The Efficient Web-Based Mobile GISService System through Reduction of Digital Map. In Laganá, A., Gavrilova, M. L., Kumar, V.,Mun, Y., Tan, C. J. K., and Gervasi, O., editors, Computational Science and Its Applications –ICCSA 2004, volume 3043 of Lecture Notes in Computer Science, pages 410–417. Springer Berlin/Heidelberg.

Köbben, B., de By, R. A., Foerster, T., Huisman, O., Lemmens, R., and Morales, J. (2010). Usingthe SDIlight Approach in Teaching a Geoinformatics Master. Transactions in GIS, 14:25–37.

Kruchten, P. (2004). Going Over the Waterfall with the RUP. Online. Accessed on Feb 9, 2011,from http://www.ibm.com/developerworks/rational/library/4626.html.

Lafon, Y., Hadley, M., Gudgin, M., Mendelsohn, N., Moreau, J., Karmarkar, A., andNielsen, H. F. (2007). SOAP Version 1.2 Part 1: Messaging Framework (Second Edition).W3C Recommendation. Accessed on Dec 21, 2010, from http://www.w3.org/TR/2007/REC-soap12-part1-20070427/.

Larman, C. (2002). Applying UML and patterns : an introduction to object — oriented analysis anddesign. Prentice Hall, Upper Saddle River, second edition.

Lemmen, C. and van Oosterom, P. (2004). Cadastral systems III. Computers, Environment andUrban Systems, 28(5):435–442.

Liu, Z. (2002). Object-Oriented Software Development with UML. Technical report, The UnitedNations University/International Institute for SoftwareTechnology.

McLaren, R. (2010). Can the Innovative Use of Mobile Phones Support More Effective LandAdministration Services? In FIG Congress 2010, Sydney, Australia, 11-16 April.

Mensah-Okantey, E. (2007). Designing a Prototype Mobile GIS to Support Cadastral Data Col-lection in Ghana. M.Sc., ITC.

Mensah-Okantey, E. and Köbben, B. (2008). Mobile GIS for Cadastral Data Collection in Ghana.Geospatial crossroads @ GI_Forum ’08 : proceedings of the geoinformatics forum Salzburg : Geoin-formatics on stage, / ed. by A. Car, G. Griesebnerand D. Strobl - Heidelberg : Wichmann.

Morales, J. M. (2004). Model-driven Design of Geo-information Services. PhD thesis, InternationalInstitute for Geo-information Science and Earth Observation, Enschede, The Netherlands.

Morales, J. M., de By, R. A., and Lemmens, R. L. G. (2008). On the Design of sustainable SDIcomponents. Proceedings of the 2008 Geospatial Infrastructure Solutions Conference (GITA 2008),March 9-12, 2008, Seattle, Washington USA. 9 p.

63


Norman, R. J. (1996). Object oriented systems analysis and design. Prentice Hall, London etc.

OASIS (2006). Reference Model for Service Oriented Architecture 1.0. Online. OASIS Standard.Accessed on Dec 11, 2010, from http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.html.

OASIS (2007). Web Services Business Process Execution Language Version 2.0. Online. OA-SIS Standard. Accessed on Dec 27, 2010, from http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html.

OGC (2004). OpenGIS Geography Markup Language (GML) Implementation Specification.Online. OpenGIS Recommendation Paper, version 3.1.1. Accessed on Dec 10, 2010, fromhttp://portal.opengeospatial.org/files/?artifact_id=4700.

OGC (2006). OpenGIS Web Map Server Implementation Specification. Online. OpenGIS Im-plementation Specification, version 1.3.0. Accessed on Jan 10, 2011, from http://portal.opengeospatial.org/files/?artifact_id=14416.

OGC (2010a). OpenGIS Implementation Standard for Geographic information - Simple fea-ture access - Part1: Common architecture. Online. OpenGIS Implementation Standard, ver-sion 1.2.1. Accessed on Dec 4, 2010, from http://portal.opengeospatial.org/files/?artifact_id=25355.

OGC (2010b). OpenGIS Web Feature Service 2.0 Interface Standard. Online. OpenGISImplementation Standard, version 2.0.0. Accessed on Jan 15, 2011, from http://portal.opengeospatial.org/files/?artifact_id=39967.

OMG (2005). Introduction to OMG’s Unified Modeling Language (UML. Online. Accessed onNov 9, 2010, from http://www.omg.org/gettingstarted/what_is_uml.htm.

OMG (2010). Unified Modeling Language. Online. Accessed on Nov 9, 2010, from http://www.uml.org/.

Peng, Z.-R. and Tsou, M. H. (2003). Internet GIS: distributed geographic information services forthe internet and wireless networks. Wiley & Sons, Hoboken.

Petersen, K., Wohlin, C., and Baca, D. (2009). The Waterfall Model in Large-Scale Development.In Aalst, W., Mylopoulos, J., Sadeh, N. M., Shaw, M. J., Szyperski, C., Bomarius, F., Oivo,M., Jaring, P., and Abrahamsson, P., editors, Product-Focused Software Process Improvement,volume 32 of Lecture Notes in Business Information Processing, pages 386–400. Springer BerlinHeidelberg.

Petrova, D. (2009). Land Registration and Cadastre in Bulgaria. In Land Registration and Cadastrein selected European Countries, pages 63–96. Neuer Wissenschaftlicher Verlag, Wien.

Popescu, A. (2010). Geolocation API Specification. Online. W3C Candidate Recommen-dation (work in progress). Accessed on Feb 5, 2011, from http://www.w3.org/TR/2010/CR-geolocation-API-20100907/.

Pundt, H. (2002). Field Data Collection with Mobile GIS: Dependencies Between Semantics andData Quality. GeoInformatica, 6(4):363–380.

Quartier, B. (2010). Mobile Web GIS. Online. Assessed on February 11, 2011, from http://www.camptocamp.com/fr/blog/2010/12/mobile-web-gis.

64


Rabin, J. and McCathieNevile, C. (2008). Mobile Web Best Practices 1.0. Online.W3C Recommendation. Accessed on Jan 13, 2011, from http://www.w3.org/TR/2008/REC-mobile-bp-20080729.

Sadjadi, N. J. (2009a). Land Registration and Cadastre in Austria. In Land Registration andCadastre in selected European Countries, pages 27–61. Neuer Wissenschaftlicher Verlag, Wien.

Sadjadi, N. J. (2009b). Land Registration and Cadastre in Hungary. In Land Registration andCadastre in selected European Countries, pages 121–163. Neuer Wissenschaftlicher Verlag, Wien.

Shea, G. Y. and Cao, J. (2010). Use of Open Source Programs to Create a Foundation for De-veloping Serious GIS Application on Mobile Device. In Facing the Challenges – Building theCapacity, Sydney, Australia. FIG Congress 2010.

Shi, W., Kwan, K., Shea, G., and Cao, J. (2009). A dynamic data model for mobile GIS. Computers& Geosciences, 35(11):2210–2221.

Sommerville, I. (2007). Software Engineering. Pearson Education Limited.

Stanfield, J. D. (2004). The Creation of an Immovable Property Registration System in Albania.In The Symposium on Land Administration in Post Conflict Areas Organised by Commission7 (Cadastre and Land Management) of the International Federation of Surveyors FIG and UN–Habitat, 29–30 April, Geneva Switzerland.

Steudler, D., Törhönen, M., and Pieper, G. (2010). FLOSS in Cadastre and Land Registration:Opportunities and Risks. Technical report, Food and Agriculture Organization of the UnitedNations (FAO) and the International Federation of Surveyors (FIG).

UN/ECE (1996). Land Administration Guidelines : With Special Reference to Countries in Transi-tion. United Nations (UN), Geneva.

van der Molen, P. (2009). Land Registration and Cadastre in the Netherlands. In Land Registrationand Cadastre in selected European Countries, pages 165–189. Neuer Wissenschaftlicher Verlag,Wien.

Wagtendonk, A., de Reus, N., van Lammeren, R., and Molendijk, M. (2004). A mobile GISapplication for crop mapping development and evaluation. Technical report, Synoptics RemoteSensing & GIS Applications.

Wilson, D., Bertolotto, M., and Weakliam, J. (2010). Personalizing map content to improve taskcompletion efficiency. International Journal of Geographical Information Science, 24(5):741 –760.

Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C. M., and Bray, T. (2008). ExtensibleMarkup Language (XML) 1.0 (Fifth Edition). Online. W3C Recommendation. Accessed onDec 3, 2010, from http://www.w3.org/TR/2008/REC-xml-20081126/.

Zandbergen, P. A. (2009). Accuracy of iPhone Locations: A Comparison of Assisted GPS, WiFiand Cellular Positioning. Transactions in GIS, 13:5–25.

65


66


Appendix A

Web Service design

A.1 SCHEMA DEFINITIONS

Listing A.1: Property Schema<?xml version="1.0" encoding="UTF−8"?><xs:schema xmlns:sdim="http://www.itc.nl/SDImobile" xmlns:xs="http://www.w3.org/2001/


<xs:import namespace="http://www.opengis.net/gml" schemaLocation="GML−3.1.1\base\gml.xsd"/>

<xs:include schemaLocation="Person.xsd"/><xs:include schemaLocation="Address.xsd"/><xs:element name="Property" type="sdim:PropertyType"><xs:annotation><xs:documentation>Cadastral Property</xs:documentation></xs:annotation></xs:element><xs:element name="PolygonLinestring" type="sdim:PolygonLinestringType"><xs:annotation><xs:documentation>This is the message type for the Overlay operation</xs:documentation></xs:annotation></xs:element><xs:element name="Parcel" type="sdim:ParcelType"><xs:annotation><xs:documentation>Parcel element</xs:documentation></xs:annotation></xs:element><xs:element name="Building" type="sdim:BuildingType"><xs:annotation><xs:documentation>Building element</xs:documentation></xs:annotation></xs:element><xs:complexType name="ParcelType"><xs:annotation><xs:documentation>Complex data type for storing parcel data</xs:documentation></xs:annotation><xs:sequence><xs:element name="Polygon" type="gml:PolygonType"/><xs:element name="DescriptiveInfo" type="sdim:DescriptiveInfo"/></xs:sequence></xs:complexType><xs:complexType name="PropertyType"><xs:annotation><xs:documentation>Complex data type for storing cadastral property data</xs:documentation>

67


</xs:annotation><xs:sequence><xs:element ref="sdim:Parcel"/><xs:element ref="sdim:Building" minOccurs="0" maxOccurs="unbounded"/><xs:element name="Address" type="sdim:NL−Address"/><xs:element name="Restriction" type="xs:boolean"/></xs:sequence></xs:complexType><xs:complexType name="BuildingType"><xs:annotation><xs:documentation>Complex data type for storing building data</xs:documentation></xs:annotation><xs:sequence><xs:element name="Polygon" type="gml:PolygonType"/><xs:element name="ID" type="xs:long"/><xs:element name="NrFloors" type="xs:integer"/><xs:element name="Usage"><xs:simpleType><xs:restriction base="xs:string"><xs:enumeration value="Dwelling"/><xs:enumeration value="Business"/><xs:enumeration value="Eduaction"/><xs:enumeration value="Health Care"/><xs:enumeration value="Other"/></xs:restriction></xs:simpleType></xs:element><xs:element name="ConstrPermission"><xs:simpleType><xs:restriction base="xs:string"><xs:enumeration value="Dwelling"/><xs:enumeration value="Business"/><xs:enumeration value="Eduaction"/><xs:enumeration value="Health Care"/><xs:enumeration value="Other"/></xs:restriction></xs:simpleType></xs:element></xs:sequence></xs:complexType><xs:complexType name="PolygonLinestringType"><xs:annotation><xs:documentation>Complex type that contains a Polygon or a Linestring but not both</

xs:documentation></xs:annotation><xs:choice><xs:element name="Polygon" type="gml:PolygonType"/><xs:element name="Linestring" type="gml:LineStringType"/></xs:choice></xs:complexType><xs:element name="InsertAddressRequest" type="sdim:InsertAddressRequestType"><xs:annotation><xs:documentation>InsertAddress operation message type</xs:documentation></xs:annotation></xs:element>

68


<xs:complexType name="ParcelBoundary"><xs:annotation><xs:documentation>Parcel represented as a set of boundary points and descriptive information</

xs:documentation></xs:annotation><xs:sequence><xs:element name="BoundarySet"><xs:complexType><xs:sequence minOccurs="3" maxOccurs="unbounded"><xs:element name="BoundaryPoint" type="gml:PointType"/></xs:sequence></xs:complexType></xs:element><xs:element name="DescriptiveInfo" type="sdim:DescriptiveInfo"/></xs:sequence></xs:complexType><xs:complexType name="DescriptiveInfo"><xs:annotation><xs:documentation>Descriptive information on cadastral property</xs:documentation></xs:annotation><xs:sequence><xs:element name="ID" type="xs:long"/><xs:element name="Municipality" type="xs:string"/><xs:element name="LandUse" type="xs:string"/><xs:element name="TaxValue" type="xs:string"/><xs:element name="Owner" type="sdim:PersonType"/></xs:sequence></xs:complexType><xs:complexType name="InsertAddressRequestType"><xs:sequence><xs:element ref="sdim:Parcel"/><xs:element name="Address" type="sdim:NL−Address"/></xs:sequence></xs:complexType></xs:schema>

Listing A.2: Address Schema<?xml version="1.0" encoding="UTF−8"?><xs:schema xmlns:sdim="http://www.itc.nl/SDImobile" xmlns:xs="http://www.w3.org/2001/

XMLSchema" targetNamespace="http://www.itc.nl/SDImobile" elementFormDefault="qualified"attributeFormDefault="unqualified">

<xs:element name="Address"><xs:annotation><xs:documentation>Root element</xs:documentation></xs:annotation></xs:element><xs:complexType name="AddressType"><xs:sequence><xs:element name="Name" type="xs:string"/><xs:element name="Street" type="xs:string"/><xs:element name="City" type="xs:string"/></xs:sequence></xs:complexType><xs:complexType name="US−Address">

69


<xs:complexContent><xs:extension base="sdim:AddressType"><xs:sequence><xs:element name="Zip" type="xs:positiveInteger"/><xs:element name="State" type="sdim:US−State"/></xs:sequence></xs:extension></xs:complexContent></xs:complexType><xs:simpleType name="US−State"><xs:restriction base="xs:string"/></xs:simpleType><xs:complexType name="NL−Address"><xs:complexContent><xs:extension base="sdim:AddressType"><xs:sequence><xs:element name="PostCode"><xs:simpleType><xs:restriction base="xs:string"><xs:pattern value="[1−9][1−9][1−9][1−9] [A−Z][A−Z]"/></xs:restriction></xs:simpleType></xs:element></xs:sequence></xs:extension></xs:complexContent></xs:complexType></xs:schema>

Listing A.3: Person Schema<?xml version="1.0" encoding="UTF−8"?><xs:schema xmlns:sdim="http://www.itc.nl/SDImobile" xmlns:xs="http://www.w3.org/2001/


<xs:element name="Person" type="sdim:PersonType"><xs:annotation><xs:documentation>Comment describing your root element</xs:documentation></xs:annotation></xs:element><xs:complexType name="PersonType"><xs:sequence><xs:element name="First" type="xs:string"/><xs:element name="Last" type="xs:string"/></xs:sequence></xs:complexType></xs:schema>

Listing A.4: Utility Schema<?xml version="1.0" encoding="UTF−8"?><xs:schema xmlns:sdim="http://www.itc.nl/SDImobile" xmlns:xs="http://www.w3.org/2001/


<xs:import namespace="http://www.opengis.net/gml" schemaLocation="GML−3.1.1\base\gml.xsd"/>

70


<xs:element name="Utility"><xs:annotation><xs:documentation>Utility data, such as gas pipe, water pipe, sewerage pipe, and so on.</

xs:documentation></xs:annotation><xs:complexType><xs:sequence><xs:element name="UtilityLine" type="gml:LineStringType"/></xs:sequence></xs:complexType></xs:element></xs:schema>

Listing A.5: Surveyor Schema<?xml version="1.0" encoding="UTF−8"?><xs:schema xmlns:sdim="http://www.itc.nl/SDImobile" xmlns:xs="http://www.w3.org/2001/


<xs:include schemaLocation="Person.xsd"/><xs:element name="Surveyor"><xs:annotation><xs:documentation>Comment describing your root element</xs:documentation></xs:annotation><xs:complexType><xs:complexContent><xs:extension base="sdim:PersonType"><xs:sequence><xs:element name="ID" type="xs:integer"/></xs:sequence></xs:extension></xs:complexContent></xs:complexType></xs:element></xs:schema>

Listing A.6: User Schema<?xml version="1.0" encoding="UTF−8"?><xs:schema xmlns:sdim="http://www.itc.nl/SDImobile" xmlns:xs="http://www.w3.org/2001/


<xs:include schemaLocation="Person.xsd"/><xs:element name="User" type="sdim:UserType"><xs:annotation><xs:documentation>Comment describing your root element</xs:documentation></xs:annotation></xs:element><xs:complexType name="UserType"><xs:sequence><xs:element name="Person" type="sdim:PersonType"/><xs:element name="Password"><xs:simpleType><xs:restriction base="xs:string"><xs:pattern value="[a−zA−Z0−9]{8}"/></xs:restriction>

71


</xs:simpleType></xs:element></xs:sequence></xs:complexType></xs:schema>

A.2 INTERFACE DEFINITIONS

Listing A.7: ProcessFeature Service<?xml version="1.0" encoding="UTF−8"?><definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/

wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:y="http://www.itc.nl/SDImobile" xmlns:ns="http://www.opengis.net/gml" xmlns:ns1="http://www.w3.org/2001/SMIL20/"xmlns:ns2="http://www.w3.org/2001/SMIL20/Language" targetNamespace="http://www.itc.nl/SDImobile">

<types><xs:schema xmlns:sdim="http://www.itc.nl/SDImobile" targetNamespace="http://www.itc.nl/

SDImobile" elementFormDefault="qualified" attributeFormDefault="unqualified"><xs:import namespace="http://www.opengis.net/gml" schemaLocation="GML−3.1.1/base/

feature.xsd"/><xs:include schemaLocation="Property.xsd"/><xs:element name="OverlayRequest"><xs:complexType><xs:sequence><xs:element name="Parcel" type="sdim:PolygonLinestringType"/><xs:element name="Utility" type="sdim:PolygonLinestringType"/></xs:sequence></xs:complexType></xs:element><xs:complexType name="OverlayResponse"><xs:sequence><xs:element name="Overlay" type="xs:boolean"/></xs:sequence></xs:complexType><xs:element name="TransformRequest"><xs:complexType><xs:sequence><xs:element name="FeatureCollection" type="ns:FeatureCollectionType"/><xs:element name="SRS" type="xs:string"/></xs:sequence></xs:complexType></xs:element></xs:schema></types><message name="TransformCoordinateResponse"><part name="parameter" type="ns:FeatureCollectionType"/></message><message name="TransformCoordinateRequest"><part name="parameter" element="y:TransformRequest"/></message><message name="PointIn"><part name="parameter" type="ns:PointArrayPropertyType"/>

72


</message><message name="PolygonOut"><part name="parameter" type="ns:PolygonType"/></message><message name="PointIn2"><part name="parameter" type="ns:PointArrayPropertyType"/></message><message name="LinestringOut"><part name="parameter" type="ns:LineStringType"/></message><message name="OverlayRequest"><part name="parameter" element="y:OverlayRequest"/></message><message name="OverlayResponse"><part name="parameter" type="y:OverlayResponse"/></message><message name="CentroidRequest"><part name="parameter" type="ns:PolygonType"/></message><message name="CentroidResponse"><part name="parameter" type="ns:PointType"/></message><message name="BoundingBoxRequest"><part name="parameter" type="ns:PolygonType"/></message><message name="BoundingBoxResponse"><part name="parameter" type="ns:EnvelopeType"/></message><portType name="ProcessFeatureInterface"><operation name="BoundingBox"><input message="y:BoundingBoxRequest"/><output message="y:BoundingBoxResponse"/></operation><operation name="Centroid"><input message="y:CentroidRequest"/><output message="y:CentroidResponse"/></operation><operation name="TransformCoordinate"><input message="y:TransformCoordinateRequest"/><output message="y:TransformCoordinateResponse"/></operation><operation name="Overlay"><input message="y:OverlayRequest"/><output message="y:OverlayResponse"/></operation><operation name="PointToPolygon"><input message="y:PointIn"/><output message="y:PolygonOut"/></operation><operation name="PointToLinestring"><input message="y:PointIn2"/><output message="y:LinestringOut"/></operation></portType><binding name="ProcessFeatureSOAPBinding" type="y:ProcessFeatureInterface">

73


<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><operation name="BoundingBox"><soap:operation soapAction="BoundingBox"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation><operation name="Centroid"><soap:operation soapAction="Centroid"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation><operation name="TransformCoordinate"><soap:operation soapAction="TransformCoordinate"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation><operation name="Overlay"><soap:operation soapAction="Overlay"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation><operation name="PointToPolygon"><soap:operation soapAction="PointToPolygon"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation><operation name="PointToLinestring"><soap:operation soapAction="PointToLinestring"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation>

74


</binding><service name="ProcessFeature"><port name="ProcessFeaturePort" binding="y:ProcessFeatureSOAPBinding"><soap:address location="localhost"/></port></service></definitions>

Listing A.8: CadastralProperty Service<?xml version="1.0" encoding="UTF−8"?><definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/

wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:y="http://www.itc.nl/SDImobile" xmlns:ns="http://www.opengis.net/gml" xmlns:ns3="http://www.w3.org/2001/SMIL20/"xmlns:ns4="http://www.w3.org/2001/SMIL20/Language" targetNamespace="http://www.itc.nl/SDImobile">


SDImobile" elementFormDefault="qualified" attributeFormDefault="unqualified"><xs:include schemaLocation="Property.xsd"/></xs:schema></types><message name="messageName"/><message name="InsertAddressRequest"><part name="parameter" element="y:InsertAddressRequest" type=""/></message><message name="InsertAddressResponse"><part name="parameter" type="y:PropertyType"/></message><message name="PutRestrictionRequest"><part name="parameter" type="y:PropertyType"/></message><message name="PutRestrictionResponse"><part name="parameter" type="y:PropertyType"/></message><message name="SendPropertyRequest"><part name="parameter" type="y:PropertyType"/></message><portType name="CadastralPropertyInteface"><operation name="PutRestriction"><input message="y:PutRestrictionRequest"/><output message="y:PutRestrictionResponse"/></operation><operation name="InsertAddress"><input message="y:InsertAddressRequest"/><output message="y:InsertAddressResponse"/></operation><operation name="SendProperty"><input message="y:SendPropertyRequest"/></operation></portType><binding name="CadastralPropoertySOAPBinding" type="y:CadastralPropertyInteface"><soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

75


<operation name="PutRestriction"><soap:operation soapAction="PutRestriction"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation><operation name="InsertAddress"><soap:operation soapAction="InsertAddress"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation><operation name="SendProperty"><soap:operation soapAction="SendProperty"/><input><soap:body use="literal"/></input></operation></binding><service name="CadastralProperty"><port name="CadastralPropertyPort" binding="y:CadastralPropoertySOAPBinding"><soap:address location="localhost"/></port></service></definitions>

Listing A.9: UserSession Service<?xml version="1.0" encoding="UTF−8"?><definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/

wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:y="http://www.itc.nl/SDImobile" xmlns:ns="http://www.opengis.net/gml" targetNamespace="http://www.itc.nl/SDImobile">


SDImobile" elementFormDefault="qualified" attributeFormDefault="unqualified"><xs:include schemaLocation="User.xsd"/></xs:schema></types><message name="messageName"/><message name="AuthenticateUserRequest"><part name="parameter" element="y:User"/></message><message name="AuthenticateUserResponse"><part name="parameter" type="xs:boolean"/></message><message name="StartUserSessionRequest"><part name="parameter" type="xs:string"/>

76


</message><message name="StartUserSessionResponse"><part name="parameter" type="xs:boolean"/></message><message name="EndUserSessionRequest"><part name="parameter" type="xs:string"/></message><message name="EndUserSessionResponse"><part name="parameter" type="xs:boolean"/></message><portType name="UserSessionInterface"><operation name="AuthenticateUser"><input message="y:AuthenticateUserRequest"/><output message="y:AuthenticateUserResponse"/></operation><operation name="StartUserSession"><input message="y:StartUserSessionRequest"/><output message="y:StartUserSessionResponse"/></operation><operation name="EndUserSession"><input message="y:EndUserSessionRequest"/><output message="y:EndUserSessionResponse"/></operation></portType><binding name="UserSessionSOAPBinding" type="y:UserSessionInterface"><soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><operation name="AuthenticateUser"><soap:operation soapAction="AuthenticateUser"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation><operation name="StartUserSession"><soap:operation soapAction="StartUserSession"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation><operation name="EndUserSession"><soap:operation soapAction="EndUserSession"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation></binding><service name="UserSession">

77


<port name="UserSessionPort" binding="y:UserSessionSOAPBinding"><soap:address location="localhost"/></port></service></definitions>

Listing A.10: SearchResources Service<?xml version="1.0" encoding="UTF−8"?><definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/

wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:y="http://www.itc.nl/SDImobile" xmlns:ns="http://www.opengis.net/gml" targetNamespace="http://www.itc.nl/SDImobile">


SDImobile" elementFormDefault="qualified" attributeFormDefault="unqualified"><xs:import namespace="http://www.opengis.net/gml" schemaLocation="GML−3.1.1/base/

geometryBasic2d.xsd"/><xs:include schemaLocation="Address.xsd"/></xs:schema></types><message name="messageName"/><message name="SearchSDINodeRequest"><part name="parameter" type="xs:string"/></message><message name="SearchSDINodeResponse"><part name="parameter" type="xs:string"/></message><message name="GetAddressRequest"><part name="parameter" element="" type="ns:PointType"/></message><message name="GetAddressResponse"><part name="parameter" type="y:NL−Address"/></message><message name="GetUtilityRequest"><part name="parameter" element="" type="ns:EnvelopeType"/></message><message name="GetUtilityResponse"><part name="parameter" element="" type="ns:LineStringType"/></message><portType name="SearchResourceInteface"><operation name="SearchSDINode"><input message="y:SearchSDINodeRequest"/><output message="y:SearchSDINodeResponse"/></operation><operation name="GetUtility"><input message="y:GetUtilityRequest"/><output message="y:GetUtilityResponse"/></operation><operation name="GetAddress"><input message="y:GetAddressRequest"/><output message="y:GetAddressResponse"/></operation></portType>

78


<binding name="SearchResourcesSOAPBinding" type="y:SearchResourceInteface"><soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><operation name="SearchSDINode"><soap:operation soapAction="SearchSDINode"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation><operation name="GetUtility"><soap:operation soapAction="GetUtility"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation><operation name="GetAddress"><soap:operation soapAction="GetAddress"/><input><soap:body use="literal"/></input><output><soap:body use="literal"/></output></operation></binding><service name="SearchResources"><port name="SearchResourcesPort" binding="y:SearchResourcesSOAPBinding"><soap:address location="localhost"/></port></service></definitions>

Listing A.11: CadastralSurvey Composite Service<bpel:process name="CadastralSurvey"

targetNamespace="http://www.itc.nl/SDImobile"suppressJoinFailure="yes"xmlns:tns="http://www.itc.nl/SDImobile"xmlns:bpel="http://docs.oasis−open.org/wsbpel/2.0/process/abstract"xmlns:ns="http://www.opengis.net/gml">

<!−− Import the client WSDL −−><bpel:import namespace="http://www.itc.nl/SDImobile" location="Test_bpelArtifacts.wsdl"

importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import><bpel:import namespace="http://www.itc.nl/SDImobile" location="Property.xsd" importType="

http://www.w3.org/2001/XMLSchema"></bpel:import><bpel:import namespace="http://www.itc.nl/SDImobile" location="ProcessFeature.wsdl"

importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import><bpel:import namespace="http://www.opengis.net/gml" location="GML−3.1.1/base/feature.xsd"

importType="http://www.w3.org/2001/XMLSchema"></bpel:import>

79


<bpel:import namespace="http://www.itc.nl/SDImobile" location="bpelContent/CadastralSurveyArtifacts.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import>

<bpel:import namespace="http://www.itc.nl/SDImobile" location="file:/SearchResources.wsdl"importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import>

<bpel:import namespace="http://www.itc.nl/SDImobile" location="file:/Property.xsd"importType="http://www.w3.org/2001/XMLSchema"></bpel:import>

<bpel:import namespace="http://www.itc.nl/SDImobile" location="file:/CadastralProperty.wsdl"importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import>

<bpel:import namespace="http://www.itc.nl/SDImobile" location="file:/ProcessFeature.wsdl"importType="http://schemas.xmlsoap.org/wsdl/"></bpel:import>

<!−− PARTNERLINKS −−><!−− List of services participating in this BPEL process −−><bpel:partnerLinks><bpel:partnerLink name="TranformCoordinate" partnerLinkType="

tns:ProcessFeatureLinkType" partnerRole="TransformCoordinate"></bpel:partnerLink>

<bpel:partnerLink name="PointToPolygon" partnerLinkType="tns:PoinToPolygonLinkType"partnerRole="PointToPolygon"></bpel:partnerLink>

<bpel:partnerLink name="GetAddress" partnerLinkType="tns:SearchResourcesLinkType"partnerRole="SearchResources"></bpel:partnerLink>

<bpel:partnerLink name="InsertAddress" partnerLinkType="tns:InsertAddressLinkType"></bpel:partnerLink>

<bpel:partnerLink name="GetUtility" partnerLinkType="tns:GetUtilityLinkType"partnerRole="GetUtility"></bpel:partnerLink>

<bpel:partnerLink name="Overlay" partnerLinkType="tns:OverlayLinkType" partnerRole="Overlay"></bpel:partnerLink>

<bpel:partnerLink name="PutRestriction" partnerLinkType="tns:PutRestrictionLinkType"partnerRole="PutRestriction"></bpel:partnerLink>

<bpel:partnerLink name="BoundingBox" partnerLinkType="tns:BoundingBoxLinkType"partnerRole="BoundingBox"></bpel:partnerLink>

<bpel:partnerLink name="Centroid" partnerLinkType="tns:CentroidLinkType" partnerRole="Centroid"></bpel:partnerLink>

<bpel:partnerLink name="GetUtility" partnerLinkType="tns:GetUtilityLinkType"partnerRole="GetUtility"></bpel:partnerLink>

<bpel:partnerLink name="SendProperty" partnerLinkType="tns:SendPropertyLinkType"partnerRole="SendProperty"></bpel:partnerLink>

</bpel:partnerLinks><!−− VARIABLES −−><!−− List of messages and XML documents used within this BPEL process −−><bpel:variables><!−− Reference to the message passed as input during initiation −−><bpel:variable name="input" element="tns:ParcelBoundary"/><!−− Reference to the message that will be returned to the requester −−><bpel:variable name="output"

messageType="tns:CadastralPropertyResponseMessage"/><bpel:variable name="PointToPolygonResponse" messageType="tns:PolygonOut"></

bpel:variable><bpel:variable name="PointToPolygonRequest" messageType="tns:PointIn"></bpel:variable

><bpel:variable name="InsertAddressResponse" messageType="tns:InsertAddressResponse"><

/bpel:variable><bpel:variable name="InsertAddressRequest" messageType="tns:InsertAddressRequest"></

bpel:variable>

80


<bpel:variable name="GetAddressResponse" messageType="tns:GetAddressResponse"></bpel:variable>

<bpel:variable name="GetAddressRequest" messageType="tns:GetAddressRequest"></bpel:variable>

<bpel:variable name="GetUtilityResponse" messageType="tns:GetUtilityResponse"></bpel:variable>

<bpel:variable name="GetUtilityRequest" messageType="tns:GetUtilityRequest"></bpel:variable>

<bpel:variable name="OverlayResponse" messageType="tns:OverlayResponse"></bpel:variable>

<bpel:variable name="OverlayRequest" messageType="tns:OverlayRequest"></bpel:variable>

<bpel:variable name="BoundingBoxResponse" messageType="tns:BoundingBoxResponse"></bpel:variable>

<bpel:variable name="BoundingBoxRequest" messageType="tns:BoundingBoxRequest"></bpel:variable>

<bpel:variable name="CentroidResponse" messageType="tns:CentroidResponse"></bpel:variable>

<bpel:variable name="CentroidRequest" messageType="tns:CentroidRequest"></bpel:variable>

<bpel:variable name="FeatureCollection" type="ns:FeatureCollectionType"></bpel:variable>

<bpel:variable name="TransformCoordinateRequest" messageType="tns:TransformCoordinateRequest"></bpel:variable>

<bpel:variable name="TransformCoordinateResponse" messageType="tns:TransformCoordinateResponse"></bpel:variable>

<bpel:variable name="Property" type="tns:PropertyType"></bpel:variable><bpel:variable name="SendPropertyRequest" messageType="tns:SendPropertyRequest"></

bpel:variable><bpel:variable name="PutRestrictionResponse" messageType="tns:PutRestrictionResponse">

</bpel:variable><bpel:variable name="PutRestrictionRequest" messageType="tns:PutRestrictionRequest"></

bpel:variable></bpel:variables><!−− ORCHESTRATION LOGIC −−><!−− Set of activities coordinating the flow of messages across the −−><!−− services integrated within this business process −−><bpel:sequence name="main"><bpel:receive name="receiveInput" portType="tns:CadastralProperty" operation="process"

variable="input" createInstance="yes" /><bpel:invoke name="TransformCoordinate" partnerLink="TranformCoordinate" operation="

TransformCoordinate" portType="tns:ProcessFeatureInterface" inputVariable="TransformCoordinateRequest" outputVariable="TransformCoordinateResponse"> </bpel:invoke>

<bpel:invoke name="PointToPolygon" partnerLink="PointToPolygon" operation="PointToPolygon" portType="tns:ProcessFeatureInterface" inputVariable="PointToPolygonRequest" outputVariable="PointToPolygonResponse"></bpel:invoke>

<bpel:assign validate="yes" name="AssignProperty"><bpel:copy><bpel:from part="parameter" variable="PointToPolygonResponse"></bpel:from><bpel:to variable="Property"><bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><

![CDATA[tns:Parcel]]></bpel:query></bpel:to>

</bpel:copy>

81


</bpel:assign><bpel:flow name="Flow"><bpel:sequence name="GetAddress">

<bpel:invoke name="Centroid" partnerLink="Centroid" operation="Centroid"portType="tns:ProcessFeatureInterface" inputVariable="CentroidRequest"outputVariable="CentroidResponse"></bpel:invoke>

<bpel:invoke name="GetAddress" partnerLink="GetAddress" operation="GetAddress" portType="tns:SearchResourceInteface" inputVariable="GetAddressRequest" outputVariable="GetAddressResponse"></bpel:invoke>

<bpel:invoke name="InsertAddress" partnerLink="InsertAddress" portType="tns:CadastralPropertyInteface" operation="InsertAddress" inputVariable="InsertAddressRequest" outputVariable="InsertAddressResponse"></bpel:invoke>

</bpel:sequence><bpel:sequence name="GetUtility"><bpel:invoke name="BoundingBox" partnerLink="BoundingBox" operation="

BoundingBox" portType="tns:ProcessFeatureInterface" inputVariable="BoundingBoxRequest" outputVariable="BoundingBoxResponse"></bpel:invoke>

<bpel:invoke name="GetUtility" partnerLink="GetUtility" operation="GetUtility"portType="tns:SearchResourceInteface" inputVariable="GetUtilityRequest"outputVariable="GetUtilityResponse"></bpel:invoke>

<bpel:invoke name="Overlay" partnerLink="Overlay" operation="Overlay"portType="tns:ProcessFeatureInterface" inputVariable="OverlayRequest"outputVariable="OverlayResponse"></bpel:invoke>

<bpel:if name="If_Overlay" xmlns:bpel2="http://docs.oasis−open.org/wsbpel/2.0/process/executable"><bpel:condition><![CDATA[$OverlayResponse]]></bpel:condition>

<bpel:invoke name="PutRestriction" partnerLink="PutRestriction" operation="PutRestriction" portType="tns:CadastralPropertyInteface" inputVariable="PutRestrictionRequest" outputVariable="PutRestrictionResponse"></bpel:invoke><bpel:else><bpel:empty name="Empty"></bpel:empty>

</bpel:else></bpel:if>

</bpel:sequence></bpel:flow><bpel:invoke name="SendProperty" partnerLink="SendProperty" operation="SendProperty"

portType="tns:CadastralPropertyInteface" inputVariable="SendPropertyRequest"></bpel:invoke>

<bpel:reply name="replyOutput" portType="tns:CadastralProperty" operation="process"variable="output"/>

<bpel:documentation source="" xml:lang="English (United States)"><![CDATA[A service composition that handles and processes the cadastral property data

collected from the mobile device]]></bpel:documentation>

</bpel:sequence></bpel:process>

82


Appendix B

Prototype implementation

B.1 MOBILE CLIENT GUI

Listing B.1: Mobile client GUI<html xmlns="http://www.w3.org/1999/xhtml"><head><title>SDImobile</title><meta name="viewport" content="width=device−width; initial−scale=1.2; maximum−scale=1.2;

user−scalable=no" /><meta name="cadastral−mobile−survey−app" content="yes"><script src="OpenLayers/OpenLayers.js"></script><script type="text/javascript" src="OpenLayers/touch.js" ></script><link rel="stylesheet" type="text/css" href="iphone101−buttons/iphonestyle.css"/><link rel="stylesheet" type="text/css" href="OpenLayers/theme/default/style.css" /><script type="text/javascript">var map = null;var urlGeoserver = "http://geoserver.itc.nl/cgi−bin/mapserv.exe?map=D:/Inetpub/geoserver/

mapserver/config_ervin.map&";var parcelsWfs = null;var myBoundary = new Array();var pointsLayer = null;var translonlat = null;OpenLayers.IMAGE_RELOAD_ATTEMPTS = 3;OpenLayers.Util.onImageLoadErrorColor = "transparent";var wgs84, mercator;var lon, lat, accuracy;var xmlhttp = null;// initializes the map with its controls and layers

function init(){wgs84 = new OpenLayers.Projection("EPSG:4326");mercator = new OpenLayers.Projection("EPSG:900913");map = new OpenLayers.Map("map_canvas",{ controls:[new OpenLayers.Control.ZoomPanel() ,new OpenLayers.Control.LayerSwitcher()],

maxExtent: new OpenLayers.Bounds(751862, 6823302, 777644, 6856263),maxResolution: 156543.0339,units: ’m’,projection: mercator,displayProjection: wgs84,numZoomLevels: 20}

);// OpenStreetMap layerosmLayer = new OpenLayers.Layer.OSM(’OSM’);

83


// Cadastral Parcels WMS layerparcelsWfs = new OpenLayers.Layer.WMS("ParcelsWFS", urlGeoserver,{layers: "parcels_geoserver",format: "png",transparent: "true",}

);parcelsWfs.setVisibility(false);// Point layer −− stores the measured pointspointsLayer = new OpenLayers.Layer.Vector( "Boundary Points" );map.addLayers([osmLayer, parcelsWfs, pointsLayer]);// instantiate touch handler for the mapthis.touchhandler = new TouchHandler( map, 4 );// on map load, get device location and set the map center to it

if (navigator.geolocation) {navigator.geolocation.getCurrentPosition(function(position){

map.setCenter(new OpenLayers.LonLat(position.coords.longitude, position.coords.latitude).transform(wgs84,mercator), 15);

},function(){

alert(’Could not determine your location!’);mapbounds = new OpenLayers.Bounds(751862, 6823302, 777644, 6856263);map.zoomToExtent(mapbounds);},{timeout:60000} );}

else {alert("no position");mapbounds = new OpenLayers.Bounds(751862, 6823302, 777644, 6856263);map.zoomToExtent(mapbounds);}}// get the coordinates of the device and create a pointfunction getPoint() {// Ask user to allow API to get positionif (navigator.geolocation) {navigator.geolocation.getCurrentPosition(// position returnedfunction(position){

document.getElementById("queryresultsDiv").innerHTML = "Getting GPS signal";var pointlon = position.coords.longitude;var pointlat = position.coords.latitude;document.getElementById("queryresultsDiv").innerHTML = "Accuracy: "+position.coords.

accuracy.toPrecision(4) +" m!";translonlat = new OpenLayers.LonLat(pointlon, pointlat)

.transform(new OpenLayers.Projection("EPSG:4326"),new OpenLayers.Projection("EPSG:900913"));

map.setCenter(new OpenLayers.LonLat(translonlat.lon, translonlat.lat), 17);myBoundary.push(pointlon+"−"+pointlat);var point = new OpenLayers.Geometry.Point(translonlat.lon, translonlat.lat);var pointFeature = new OpenLayers.Feature.Vector(point, null);pointsLayer.addFeatures([pointFeature]);},// could not return the positionfunction(){

84


alert(’Could not determine your location!’);},// ask for the best possible accuracy measurement// and force a new measurement, do not use cached position{enableHighAccuracy : true, maximumAge: 0});

}// either user does not allow API to get positon or// the web browser does not support geolocationelse {alert("Your browser does not support geolocation!!!");}}// deletes the last measured pointfunction deletePoint(){

var point=pointsLayer.features;var lastPointIdx = point.length−1;if (lastPointIdx>=0) {

myBoundary.splice(myBoundary.length−1, 1);pointsLayer.removeFeatures(point[lastPointIdx]);document.getElementById("queryresultsDiv").innerHTML ="Point was deleted!";}else {

document.getElementById("queryresultsDiv").innerHTML ="No point to delete!";}}// send the boundary points to the server in an asynchronous callfunction sendBoundary(){

if (myBoundary.join().length > 0) {document.getElementById("queryresultsDiv").innerHTML = "Sending...";params = "str=" +myBoundary.join();// create an XMLHttpRequest object for the asynchronous callif (window.XMLHttpRequest){// code for IE7+, Firefox, Chrome, Opera, Safarixmlhttp=new XMLHttpRequest();}

else if (window.ActiveXObject){// code for IE6, IE5xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");}

if (xmlhttp != null){ // send measured points using a POST request

xmlhttp.onreadystatechange=getResponse;xmlhttp.open("POST","getBoundary_demo.asp",true);xmlhttp.setRequestHeader("Content−type", "application/x−www−form−urlencoded");xmlhttp.send(params);}}

else {alert (’No points to send!’);}}// get the response from the server and display in the clientfunction getResponse(){

if (xmlhttp.readyState==4 && xmlhttp.status==200){

document.getElementById("queryresultsDiv").innerHTML=xmlhttp.responseText;

85


// refresh the layer to see the new measured parcelparcelsWfs.mergeNewParams({’uniqueName’: Math.random()});}}</script></head><body onLoad="init()"><div class="toolbar"><h1>SDImobile</h1><a id="buttonAdd" href="#"><img src=’iphone101−buttons/i/add.png’></a>

<a id="buttonDelete" href="#"><img src=’iphone101−buttons/i/delete.png’></a><input type="button" id="buttonSend" value="Send">

</div><div id="map_canvas" style="width: 100%; height: 90%;"></div><div id="queryresultsDiv" style="width: 100%; height:10%; font−size: 12px;"> </div><script type=’text/javascript’>// Set the event handler for the Add buttonvar buttonAdd = $(’buttonAdd’);buttonAdd.addEventListener(’click’, function(e) {

getPoint();}, false);// Set the event handler for the Delete buttonvar buttonDelete = $(’buttonDelete’);buttonDelete.addEventListener(’click’, function(e) {

deletePoint();}, false);// Set the event handler for the Send buttonvar buttonSend = $(’buttonSend’);buttonSend.addEventListener(’click’, function(e) {

sendBoundary();}, false);</script></body></html>

B.2 SDImobile IMPLEMENTATION

B.2.1 OGC Web Services

Listing B.2: Web Feature Service configuration, Utility LinesMAP

NAME UtilityEXTENT 6.7541 52.1280 6.9857 52.3094PROJECTION

"init=EPSG:28992"ENDWEB

IMAGEPATH "/tmp/ms_tmp/"IMAGEURL "/ms_tmp/"METADATA

"wfs_title" "Enschede Utility WFS Server""wfs_schemas_location" "http://schemas.opengeospatial.net""wfs_onlineresource" "http://itcnt07.itc.nl/cgi−bin/mapserv.exe?map=//itcnt03/gfm/

ramonllari16359/www/cadastre/wfsutility.map&"

86


"wfs_srs" "EPSG:28992"END

END#−−−−−−−−−− L A Y E R S −−−−−−−−−−#−−−− Utility data retrieved from the PG database

LAYERNAME ’Utility’TYPE LINECONNECTIONTYPE postgis

CONNECTION "user=ervin dbname=enscad host=itcnt07.itc.nl password=∗∗∗∗∗∗∗∗∗"PROCESSING "CLOSE_CONNECTION=DEFER"DATA "geom FROM enscadutility USING UNIQUE gid USING srid=28992"

STATUS ONMETADATA

"wfs_title" "Utility WFS""gml_include_items" "all""gml_featureid" "gid""wfs_srs" "EPSG:28992"

ENDEND #layer Utility

END #of MAP

Listing B.3: Web Map Service configuration, Cadastral ParcelsMAP

NAME CadastreIMAGECOLOR 255 255 255SIZE 600 600OUTPUTFORMAT

NAME image/pngDRIVER AGG/PNGIMAGEMODE RGBFORMATOPTION "QUANTIZE_FORCE=ON"FORMATOPTION "QUANTIZE_DITHER=OFF"FORMATOPTION "QUANTIZE_COLORS=256"

ENDPROJECTION

"init=EPSG:900913"ENDEXTENT 257181.5 471441.5 257904.2 4711874.8WEB

IMAGEPATH "C:/tmp/ms_tmp/"IMAGEURL "/ms_tmp/"METADATA

"map" "D:/Inetpub/geoserver/mapserver/config_ervin.map""ows_schemas_location" "http://schemas.opengeospatial.net""ows_title" "Enschede Cadastre Parcels WMS""ows_onlineresource" "http://geoserver.itc.nl/cgi−bin/mapserv.exe?map=D:/Inetpub/geoserver

/mapserver/config_ervin.map&""wms_srs" "EPSG:900913""wms_feature_info_mime_type" "text/plain""wms_feature_info_mime_type" "text/html""wms_server_version" "1.1.1""wms_formatlist" "image/png,image/gif,image/jpeg, image/svg""wms_format" "image/svg"

87


END #metadataEND #web#−−−−−− L A Y E R S −−−−−−# −−−− Cadastral parcels retrieved from the PG database−−−−LAYER

NAME "parcels_geoserver"TYPE POLYGONSTATUS OFFCONNECTIONTYPE postgis

CONNECTION "user=ervin dbname=enscad host=localhost password=∗∗∗∗∗∗∗∗∗"PROCESSING "CLOSE_CONNECTION=DEFER"DATA "geom FROM enscadparcels USING UNIQUE id USING srid=28992"

METADATA"wms_title" "Cadastral Parcels WMS"

"wms_srs" "EPSG:900913 EPSG:28992""wms_version" "1.1.1"

END #metadataPROJECTION

"init=EPSG:28992"ENDCLASS

STYLEOUTLINECOLOR 255 0 0

ENDEND #class

END #layerEND #map

B.2.2 SDImobile functionality

Listing B.4: SDImobile functionality implementation - ASP/Python<%@ Language = Python %><%import urllibimport httplibfrom xml.dom.minidom import parseStringfrom pyproj import transform, Projfrom shapely.geometry import ∗from shapely.validation import ∗from lxml.builder import ElementMakerfrom lxml import etree as ET#split the boundary points into a listboundaryList = str(Request.Form(’str’)).split(’,’)pointList=[]for point in boundaryList:

pointList.append(point.split(’−’))## global variable declarations# url of the utility WFSurl = "http://itcnt07.itc.nl/cgi−bin/mapserv.exe?map= \//itcnt03/gfm/ramonllari16359/www/cadastre/wfsutility.map&SERVICE=\WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=Utility"# origin projection, WGS84wgs84 = Proj(init=’epsg:4326’)# destination projection, the Dutch reference system with some extra transformation parameters

88


rd_new = Proj(’+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs +towgs84=565.2369,50.0087,465.658,−0.406857330322398,0.350732676542563,−1.8703473836068,4.0812’)

# Generates the XML transaction content, coordinates and overlay result# uses the lxml element maker to create the elements of an XML treedef generateTransactionBody(coords, overlay):

wfs = ElementMaker(namespace ="http://www.opengis.net/wfs", nsmap={’wfs’ : "http://www.opengis.net/wfs", ’enscad’:"http://www.itc.nl/enscad"})

enscad = ElementMaker(namespace ="http://www.itc.nl/enscad", nsmap={’enscad’ : "enscad"})gml = ElementMaker(namespace ="http://www.opengis.net/gml", nsmap={’gml’ : "http://www.

opengis.net/gml"})Transaction = wfs.TransactionInsert = wfs.Insertenscadparcels = enscad.enscadparcelsbladnummer = enscad.bladnummeroverlays = enscad.overlaysgeom = enscad.geomMultiPolygon = gml.MultiPolygonpolygonMember = gml.polygonMemberPolygon = gml.PolygonouterBoundaryIs = gml.outerBoundaryIsLinearRing = gml.LinearRingcoordinates = gml.coordinatesmy_doc = Transaction(Insert(enscadparcels(geom(MultiPolygon\

(polygonMember(Polygon(outerBoundaryIs(LinearRing(\coordinates(coords, decimal=".", cs=",", ts=" "))))), gid=’1’, srsName="http://www.

opengis.net/gml/srs/epsg.xml#28992" )), overlays(overlay))))my_doc.set(’version’ , "1.0.0")my_doc.set(’service’ , "WFS")return my_doc

# WFS−T insert operation with HTTP POSTdef WFSTInsert(my_doc): #my_doc

xml=ET.tostring(my_doc)headers = {"Content−type": "application/xml", "Accept": "text/plain"}conn = httplib.HTTPConnection("geoserver.itc.nl:8080")conn.request("POST", "/geoserver/wfs?", xml, headers)response = conn.getresponse()conn.close()return response

# returns a WFS url which includes a bboxdef WFSurl(url, bbox=None):

if bbox ==None:return url

else:return url+"&BBOX="+str(bbox[0])+","+str(bbox[1])+","+str(bbox[2])+","+str(bbox[3])

# calls a WFS from MapServer using the urldef getWFS(url=WFSurl):

try:return parseString(urllib.urlopen(url).read())

except:return

# Gets the list of lines out of a GML document retrieved from a WFS calldef lineFromGML(gml):

strxml = gmlgmlLines = strxml.getElementsByTagName("gml:LineString")

89


lineList=[]lineStringList=[]xy=[]# get the elements named gml:coordinatesfor line in gmlLines:

coords = line.getElementsByTagName("gml:coordinates")#remove trailing spaces and put them in a listlineStringList = str(coords[0].firstChild.nodeValue).strip().split(’ ’)tempLineList=[]#get coordinate pair which are stored as one string,#split them in x,y coordinates and store in a list, one list per linestringfor coordpair in lineStringList:

xy=float(coordpair.split(’,’)[0]), float(coordpair.split(’,’)[1])tempLineList.append(xy)

#put every list of linestring coordinates in a listlineList.append(tempLineList)

return lineList# transforms x, y coordinates from one CRS to anotherdef transformCoord(lng, lat, fromCRS=wgs84, toCRS=rd_new):

return transform(fromCRS, toCRS, lng, lat)# transforms coordinates of a list of points (x,y)def transformListCoord(pointList, fromCRS=wgs84, toCRS=rd_new):

pointListTransformed=[]for point in pointList:

pointListTransformed.append(transformCoord(point[0], point[1], fromCRS, toCRS))return pointListTransformed

# creates a polygon from a list of pointsdef pointToPolygon(pointList):

return Polygon(pointList), explain_validity(Polygon(pointList))# creates a linestring from a list of pointsdef pointToLinestring(pointList):

return LineString(pointList)# takes a polygon, buffers it and returns the bounding boxdef BBox (polygon, size=20):

return polygon.buffer(size).bounds# creates a list of points (4 points) around a given point# used to create a rectangle polygondef pointToSquare(point, size=50):

return [[point[0]−size, point[1]−size],[point[0]+size, point[1]−size], [point[0]+size, point[1]+size], [point[0]−size, point[1]+size]]

# creates a string from the list of coordinate pairs (tuples)def listoftuplesToString(coords):

coordstr=’’for tpl in coords:

coordstr += ’,’.join([str(tpl[0]), str(tpl[1])])coordstr += ’ ’

return coordstr%><HTML><HEAD></HEAD><BODY><%# transform coordinate system from WGS84 to Dutch RD_NewpointListTransf = transformListCoord (pointList, wgs84, rd_new)# if there are less then 3 points measured, from the first point create a rectangle polygon

90


# needed only for demo, when taking coordinates inside a building.# normaly the processing should stop here and report back to userif len(pointListTransf) < 3:

polygon, validity = pointToPolygon(pointToSquare(pointListTransf[0]))else: # create a polygon from the measured points, and check its validity

polygon, validity = pointToPolygon(pointListTransf)if validity != ’Valid Geometry’: # if the polygon is not valid, stop here and report to user

Response.Write("The polgyon created from the measuremets is not a valid geometry!<br />")Response.Write(validity + "<br/>")Response.Write ("The process cannot continue !")

else: # if polygon is valid continue the processing# call a WFS of the utility lines and perform the intersection with the polygonoverlay=Falsebbox = BBox(polygon)wfsurl =WFSurl(url, bbox)gml=getWFS(wfsurl)if gml is not None: # if the WFS call was successful get the utility lines

lines = lineFromGML(gml)if len(lines) > 0:

multilines =MultiLineString(lines)overlay = polygon.intersects(multilines) and not polygon.touches(multilines)

# create a string from the coordinates of the polygon# used as input for the transaction bodycoords = listoftuplesToString(list(polygon.exterior.coords))# create the transaction body and send it to the serverinsertBody = generateTransactionBody(coords, str(overlay).lower())response =WFSTInsert(insertBody)# if the response from the server is 200=OK, the polygon was successfully inserted into the databaseif response.status == 200:

Response.Write("Polygon inserted into database!<br />")else: # the insert operation failed

Response.Write("Could not insert polygon into database!<br />")Response.Write("Response status: "+str(response.status)+"<br />")

if overlay: # report back to user the result of the overlayResponse.Write("Polygon overlays with utility lines!")

else:Response.Write("Polygon does not overlay with utility lines!")

%></BODY></HTML>

91

Documents

OPEN SOURCE GEO-WEB SERVICES FOR MOBILE DATA CAPTURE IN CADASTRAL