MOBILE SOFTWARE FOR GATHERING AND MANAGING GEOREFERENCED INFORMATION FROM CRISIS AREAS

MOBILE SOFTWARE FOR GATHERING AND

MANAGING GEOREFERENCED INFORMATION FROM

CRISIS AREAS

Luis Gens1, Hugo Alves

1, Hugo Paredes

1, Paulo Martins

2, Benjamim Fonseca

2,

Elfneh Bariso3, Leonie Ramondt

4, Yishay Mor

5, Leonel Morgado

1

1University of Trás-os-Montes e Alto Douro, Vila Real, Portugal

[email protected], [email protected], [email protected],

[email protected] 2CETAV – Centro de Estudos Tecnológicos, Ambientais e da Vida/UTAD, Vila Real,

Portugal [email protected], [email protected]

3 AHEAD – Action for Health, Education, And Development, London, UK

[email protected] 4 Ultralab, Anglia-Ruskin University, Chelmsford, UK

[email protected] 5 Institute of Education, University of London, London, UK

[email protected]

ABSTRACT

Gathering field data from crisis areas requires overcoming a major technical hurdle: infrastructures and

terminals for Internet access are non-existent or unreliable. Teams of professionals acting on the field

lack a cost-effective, convenient way to provide their data to central management headquarters and the

worldwide public in a timely manner. Cell-phone software can be leveraged to bridge this. Using cell-

phone applications, people living or working in low-tech areas can provide their knowledge worldwide,

taking full advantage of georeferenced functionalities. In this paper we present the prototype of a

platform based on a wiki+map server backbone for direct information entry, query, and editing, by

people on the field using cell-phones, with strong version management. This georeferenced information

can then be visualized centrally for tackling development/crisis issues, such as drought problems,

outbreaks of diseases, etc. – giving NGOs and governments a better framework upon which to act.

KEYWORDS

Mobile devices, georeferenced data, wiki, maps, crisis areas, rural development.

1. INTRODUCTION

Throughout the globe, one finds various crisis areas, due to both natural and human causes. In

many cases, information and telecommunication systems in those areas are also seriously

lacking. And yet, such systems form a critical basis for fast, fair, and effective community

development, support, and crisis relief. Only by receiving correct information from the field,

from communities in crisis areas, and making it reach those who can act upon it, can measures

be taken and solutions found. Georeferenced information, in particular, is of major importance

in order for organization to achieve the greatest possible impact within a population.

Currently, information supporting field activities in such areas is frequently incomplete and not

entirely up-to-date. Consequently, direct contributions of those in the field (local citizens &

relief professionals) are often partially or entirely ignored.. Our platform aims to provide a

means to help solve this problem, so that locals and professionals can contribute with their

knowledge on the spot or as soon as possible, and both governmental and non-governmental

organizations dealing with crisis issues can benefit from that information to get a global

perspective of events.

2. TECHNOLOGICAL OVERVIEW

In general, in the areas we are addressing, Internet-access and even computers can be hard to

get, carry, and power, or even non-existent. Our platform is based on central servers for

information processing and storage, with which geographically-dispersed user terminals

communicate (vd. Figure 1), using various forms of mobile communication, such as GPRS,

GSM/satellite dial-up, or automated transmission of SMS messages, for occasional connectivity

scenarios. Our prototype system, for now, uses only GPRS packets, but other connectivity

solutions are a priority for future development.

Figure 1. Operational design of the proposed system.

At the server level, a first requirement was that the software provided multi-user collaboration

features. Several technological options exist for this, commonly known as groupware –

implementations of the scientific field known as Computer-Supported Cooperative Work

(CSCW) [1]. Generically, such technologies allow people to break geographic barriers, form on-

line communities and collaborate. This collaboration can be either synchronous or

asynchronous, depending on the simultaneous or non-simultaneous presence of the

collaborators. Typical synchronous collaboration scenarios are electronically supported

meetings and group awareness systems; examples of asynchronous scenarios are workflow

management, collaborative editing and shared information workspaces [2]. The system we

present in this paper fits in the latter category. A well-known example of such systems is the

collaborative on-line encyclopedia, Wikipedia [3], based on a technology known as wiki. Wikis

are tools that allow a group of people, with few technological resources and in a short time, to

collaboratively create and edit content available on a web server. The wiki system running on

that server provides an automated registry and version control for collaboratively-edited

documents [4]. The flexibility, robustness, and popularity of wiki technology motivated its

adoption in our platform as a technological component at the server level.

Another server-level component in our platform is a maps server, in order for users to enter and

visualize georeferenced information. Data entry on the mobile device is done by directly

pointing out on a map the place to enter or edit data. For least-capable devices, we could also

develop a list-based interface, for selecting the data-entry location. Internet users or the public at

large can access the server through the Web and see displayed on a map the result of the

information being provided by the mobile users: a combination of the wiki server data with the

maps server data.

For the operation of both servers to be independent of the actual mobile devices used,

interposing software layers (Interface Layers) provide a common interface for mobile devices.

Their function is to convert requests native to each device into requests native to the servers.

3. SYSTEM CONFIGURATION

In our platform, mobile devices are the front-end for data entry. While the currenty prototype is

only using cell phones, further development could allow the system to be used by other mobile

devices such as PDAs, or even the OLPC computer – now called XO [5]. The mobile device

application has a map-based interface (although it could also be a plain list-based interface),

with navigation menus, and options for searching, editing, and entering georeferenced

information (vd. figures 2 and 3).

The front-end mobile devices are to perform as little data processing as necessary for the user to

employ the application. All major logic processing takes place at the server, i.e. map

manipulation and vector-to-bitmap conversions. Thus, we avoid burdening of the scarce

processing power of mobile devices. As a future development, we believe that maps could even

be preloaded into the mobile device, in order to be simply selected and displayed by the

application running on the device, thus avoiding the need for transmitting graphic data. Also,

the application should adapt itself to the features of each mobile device, in order to run on

devices with different levels of hardware resources. Beyond the prototype phase, we plan that

minimum equipment requirements for use of the system by a mobile device should be: ability to

connect to the Internet directly or use SMS; ability to download and run applications; and

enough display resolution for presenting maps (for selecting locations on a list, this last

requirement can be avoided). More detailed requirements specifications are provided ahead in

section 4.3.

Centralized content storage and access control are done at a wiki server and at a maps server, as

mentioned. These were developed specifically for use in our prototype, and implement the basic

required functionalities of each kind of server. Beyond the current prototype phase, in a

production environment, the current server software will evolve into the “Interface Layers” of

Figure 1, and the actual wiki server and maps server software can be one of those readily

available for free use (for instance, the wiki server could be Tikiwiki [6]).

4. RELEVANT TECHNOLOGIES

4.1. Wikis

In recent years, use of free (as in “free speech”) open-source software and the development of

collaborative work projects have experienced a large growth [7,8]. Some of these collaborative

projects, where a cooperation is sustained among several people for project development and

maintenance, often without organizational structure, are known as wikis. Several studies show

that in spite of wikis being disentailed of a defined hierarchy, in the which a person or company

centralizes and/or controls the whole process, wiki projects have been producing reliable results

that sometimes equal those from projects following a proprietary model [9,10]. Our

implementation, like many others available on the net, was entirely developed using PHP code

and a MySQL database, an entirely open-source platform.

4.2. Maps servers

Maps are one of the many types of information found on the Internet. Or, more generically,

geospatial information, with the potential for analysis under different areas of the knowledge

[11,12]. For some companies, universities and other organizations, a central goal is the

placement of georeferenced data on the Web [12, 13].

A maps server makes available online maps and/or satellite images for a specific area requested

by client software, establishing a link with real topographical data. Web applications based on

online maps from maps server typically allow users to attach information to a geographic place

(i.e., produce georeferenced information) and/or browse and query that information. Several

examples are readily found on the Web, mostly involving the Google Maps service and different

aggregations of georeferenced thematic information, developed with a free-to-use API, and are

usually called mashups. For instance, Wikimapia [14] is a service where anyone can input and

edit geospatial notes; HEALTHmap [15] contains health-related information; and NEWSMap

[16] provides georeferenced news.

4.3. Java

Java is an innovative programming language that has become the language of choice for

programs that need to run on a variety of different computer systems. The version specifically

developed for mobile devices is called J2ME (Java 2 Platform Micro Edition), and this was the

programming technology we employ for developing and running the mobile device interface.

J2ME is defined in terms of profiles, configurations and optional APIs (Application Program

Interfaces) [17]. A configuration, defined for a group of similar devices, is a set of basic APIs

(also known as framework) for the interaction with the equipment resources. It defines [18]:-

• the components of the Java language supported by the device;

• the supported components of the Java virtual machine;

• the supported components of the Java language libraries.

Currently only two different types of configurations exist:

• CDC (Connected Device Configuration) - defined for fixed equipment, such as car

navigation services, television sets, TV set-top boxes, etc.

• CLDC (Connected, Limited Device Configuration) - defined for mobile personal

equipment, such as cell phones, pagers, PDAs, etc.

Obviously, the CLDC configuration is the most suited to our purposes. A common feature of its

target devices is that they have very limited hardware resources. The basic features for a device

to support CLDC are simply [19]:-

• at least 192 kB of available memory for the Java platform;

• a 16-bit or 32-bit processor;

• low energy consumption;

• network connectivity.

Regarding profiles, they are basically a set of “vertical” APIs, sitting on top of a configuration

and defining a set of specific characteristics for a type of equipment. The profile applied in the

majority of the mobile devices (cell phones) is called MIDP (Mobile Information Device

Profile). It defines further requirements beyond those assumed by the CLDC configuration [20,

21]:

Screen:

• minimum resolution of 96x54;

• 1-bit depth

• pixel-shape (aspect ratio): approximately 1:1

Input:

• one or more than one of the following: one-handed keyboard, two-handed

keyboard or touch-screen

Memory:

• 128 kB of non-volatile memory for the MIDP components

• 8 kB of non-volatile memory for the application data

• 32 kB of non-volatile memory for Java

Network:

• possibly intermittent bidirectional wireless connection.

5. IMPLEMENTED PROTOTYPE

Our main objective was to develop a platform to serve as layer between mobile devices and

geospatial data services. This platform needed to be device-independent: able to run in any kind

of mobile device, be it a cell phone or a PDA.

The choice of Java as a development platform, came naturally. Java code, once developed, is

readily used in different devices without large changes to the code.

The system we developed has three different modules, as mentioned above: an interface

application for mobile devices (in this case, a J2ME-compliant mobile phone), a maps server

and a wiki server (in effect a database providing the basic wiki features required: to hold and

manage information, access control, and version management).

5.1. Mobile application

The cell-phone application is composed of a module for presenting maps to the user, providing

means for navigation (zoom, directional movement) and visualization of previously-entered

information (points of interest and associated information). The second module has the

necessary tools to allow data entry by the user. This module consists of a series of fields (check

boxes, radio buttons, dropdown menus, text, etc.) designed to optimize the user experience and

minimize time and effort.

5.2. Maps Server

The maps server is currently a simple database providing bitmap images for maps. Since our

system is intended to support a wide range of devices, with very different displays, the current

prototype maps server also adapts the image to the specific requirements of the mobile device

requesting it. In a production environment, the actual maps server in fact provides two services:

the technical map-access operation, and the legal rights to employ the image data for the maps.

Since we envisage our system as software layer usable with different map-data providers and

different maps server software, the cost of using full-fledged map-use rights wasn’t deemed

necessary at this stage. A simple database, restricted to local imagery, enabled us to initiate and

develop the prototype and can then be further developed into a Maps Server Layer, as shown on

Figure 1.

5.3. Wiki Server

The control of the information entered in the application is managed by a database with the

required wiki features. Namely, user login control, version control and concurrency control.

User login control – only a authorized user can change or add information to the wiki server.

This control is provided by a system of login and password with central administration.

Version control – our system implements a basic but still efficient level of this feature. All the

information related with a specific image is provided to the application, but only the latest

version is presented to the mobile device user.

Concurrency control – Since this system is intended for collaborative work, it may happen that

two people try to modify the same data at the same time. To prevent anyone from modifying

something without being aware that it isn't the latest version of the information, changes to the

data are accepted only if the data version on which changes by the user were made to is the

latest version in the database, when the user tries to upload the information. In others words, if a

user tries to modify some information, and meanwhile someone else changes the original

information. then the update executed by the first user will not be successful.

5.4. Application Features

Initialization

The application in the mobile device, the moment that it initializes, tries to access the maps

server and the wiki server.

Image Request

When the mobile device needs a image, it sends a request with the following format to the maps

server:

h – mobile device screen height;

w – mobile device screen width;

img – image id requested by the mobile device.

The server verifies the validity of the parameters and in the case that problems do not occur, the

image is obtained and processed to adapt the result to the size of the visible area of the cell

phone.

Upon receiving the image, the cell phone presents it on the display (Figure 2) and superimposes

on it a grid with nine cells. The purpose of this grid is to supply to the user an easy visual

delimitation of the areas in which he will be able to place information or make zoom.

The division of the area in nine cells is not an ad hoc decision: the cells allow fast navigation by

the user, for they are matched to the numerical keys of the cell phone.

Figure 2. Cell phone showing a map with and without points-of-interest symbols.

Information request

After the image request and display is concluded, another request is made by the cell phone, to

get the information associated with the image cells (data present in the wiki server database).

This request is processed by the wiki server, and consists of only one parameter: img. This

parameter indicates which image the cell phone is using and is used as a database query to

gather information, returned as a matrix of nine elements, indicating the existence or absence of

information. This matrix is processed by the mobile application and one point-of-interest

symbol (POI) is added to each image cell containing information.

The final result is an image divided in nine sections and where a pin is visible in each section

with information available (Figure 2).

Visualization

For a user to move over the map in the cell-phone application, all one has to do is select the

zoom option on menu and press one of the number keys of the cell phone. The keys * and #

provide Zoom In and Zoom Out operations.

Data reading and entry

To allow the visualization of available information, the user selects the “Poi” option (Figure 3).

Afterwards, if the user selects an image section containing a POI symbol, the application will go

to the PoiView screen, in which it will be possible to see the information associated with that

section of the image. This information can be edited in the PoiEdit window (Figure 3). The

edited information is updated to the wiki server through the Upload option. The server does the

concurrency management: if, while the user was editing the POI data, no other user updated it,

only then the data is updated in the database.

Creating a new point-of-interest and its information

As for data entry and editing, the user accesses the “Poi” menu option, and if no data is

associated with the selected image section, new data can be entered. The different is only at the

level of server-processing. When the data is uploaded, the server first verifies if the user has

permission to enter information, by requesting a login and password.

Figure 3. Accessing the POI menu (left), editing a POI (center) and uploading (right).

6. APPLICATION SCENARIO

We envision a scenario where medical doctors working on crisis areas are using out system to

provide a central management headquarters with up-to-date, georeferenced information on field

conditions. This is an hypothetical situation where our solution could save lives:

• A contagious disease outbreak is detected in SomeCountry;

• Qualified personnel is sent to the region (field survey and logistics);

• The personnel inspect several Tuberculosis outbreak locations, registering on the

application their current position on the map and filling specific forms for fast data-

entry of the situation, and also providing their assessment regarding the necessary

resources to cope with the situation;

• Whenever they have cell-phone network coverage, their data is sent to the wiki server.

In case of communication failure, data is stored on the device for later transmission;

• Operators at the headquarters check out the information introduced in the wiki while

preparing an action plan;

• A coordinator dispatches an team for each area where field survey operatives are

providing data;

• The team operates at the designated locations, also using the application to publish

notes as the situation unfolds;

• Whenever a team member has cell-phone coverage, the data is sent to the wiki server.

In case of communication failure, data is be stored on the device for later transmission;

• Operators at the headquarters check out the information on the wiki, watching the

evolution of the scenario and looking for new data;

• A coordinator makes adequate changes to personnel and resource allocations, according

to the information now more readily available than before.

7. FINAL THOUGHTS: ON SOCIAL SOFTWARE

“(…) many users benefit from other users acting in sociable and community-oriented ways. This

stems from the belief that a whole can be greater than sum of its parts – that the concerted

social actions of strangers benefit us all.” [22].

The range of uses for this proposal is not limited to crisis scenarios: its use can be envisaged for

any situation where data harvesting is necessary under low Internet-connectivity situations. So

we can think of disease outbreaks, and droughts, but also on collection of soil data, environment

data, ethnographic data on local customs and traditions, etc.

This kind of software would be used by and for all, its importance residing in allowing a group

of people to communicate amongst themselves and with global partners, publishing experiences

and knowledge, and developing with this exchange of information: developing themselves and

developing their integration within the global community. For instance, the deficiencies of

information infrastructures in many developing countries deny that integration, preventing

people from obtaining the benefits that can be achieved through contact with other people from

different towns, regions, and even countries. At length, the ability to publish and retrieve local

information could be used by local people to share local news, events, history and traditions,

contributing to the preservation of ancient local knowledge and customs, making it available to

anyone, and benefiting from cooperation with similar projects in other towns, whether in their

own countries or abroad. This exchange of information would contribute to a better society, and

could lead to the creation of a more capable information-age generation. A generation holding

the potential to bring this world to a higher development standard. This is what we wish to

contribute to.

Concerning more immediate issues, we envisage the use of this system by healthcare

professionals or human rights activists, to provide a central management organization with

accurate, timely, and geospatially-referenced information. But these are mere glimpses of what

might become achievable.

REFERENCES

[1] Borghoff, U. M. & Schlichter, J. H. (1998). “Computer-Supported Cooperative Work”,

Germany: Springer-Verlag.

[2] Mackay, W. (1999). “Media Spaces: Environments for Informal Multimedia Interaction. In

Computer Supported Co-operative Work”, USA: John Wiley & Sons.

[3] Wikipedia (2006). Wikipedia, retrieved October 20th, 2006, from http://www.wikipedia.org/.

[4] Ebersbach, Anja; Glaser, Markus; Heigl, Richard (2005). “Wiki: Web Collaboration”, Germany:

Springer-Verlag.

[5] One Laptop Per Child (2006). One Laptop Per Child, retrieved October 20th, 2006, from

http://laptop.org/.

[6] Tikiwiki Community (2006). Tikiwiki Community Portal, retrieved October 20th, 2006, from

http://tikiwiki.org/.

[7] Puppy smoothies: Improving the reliability of open, collaborative wikis (2007). Puppy smoothies

retrieved January 7th, 2007, from http://www.firstmonday.org/issues/issue11_9/cross/index.html

[8] The Wealth of Networks (2007). The Wealth of Networks, retrieved January 7th, 2007, from

http://www.benkler.org/wealth_of_networks/index.php?title=Main_Page.

[9] Internet encyclopaedias go head to head (2007). Internet encyclopaedias, retrieved January 7th,

2007, from http://www.nature.com/nature/journal/v438/n7070/full/438900a.html.

[10] Can Wikipedia Ever Make the Grade? (2006). Can Wikipedia Ever Make the Grade, retrieved

January 7th, 2007, from

http://chronicle.com/temp/reprint.php?%20id=z6xht2rj60kqmsl8tlq5ltqcshc5y93y.

[11] Digital Spatial Data: Internet Data (2007). Digital Spatial Data: Internet Data, retrieved January

7th, 2007, from http://library.humboldt.edu/~rls/geospatial/intgis.htm.

[12] Online Spatial Data by Country (2007). Online Spatial Data by Country , retrieved January 7th,

2007, from http://libraries.mit.edu/gis/data/datalinks/countrydataweb.html.

[13] Data Sets for GIS Projects (2007). Data Sets for GIS Projects, retrieved January 7th, 2007, from

http://www.earthsensing.com/gis/resources/gishelp.html.

[14] WikiMapia (2007). WikiMapia retrieved January 7th, 2007, from http://wikimapia.org.

[15] HealthMaps (2007). HealthMaps retrieved January 7th, 2007, from http://www.healthmap.org .

[16] NewsMaps (2007). NewsMaps retrieved January 7th, 2007, from

http://livenewsmap.blogspot.com.

[17] Knudsen, J., (2003). “Wireless Java Developing with J2ME”, Secon Edition. USA: APress,

[18] Wilding-McBride, D., (2003). “Java Development on PDAs: Building Applications for

PocketPC and Palm Devices”, USA: Addison Wesley,

[19] Wilding-McBride, D., (2003). “Java Development on PDAs: Building Applications for

PocketPC and Palm Devices”. Addison Wesley.

[20] Connected, Limited Device Configuration (CLDC) 1.1. CLDC, retrieved January 7th, 2007,

from http://jcp.org/jsr/detail/139.jsp.

[21] Mobile Information Device Profile 1.0 (2007): MIDP January 7th, 2007, from

http://jcp.org/jsr/detail/37.jsp

[22] Owen, Martin; Grant, Lyndsay; Sayers, Steve; Facer, Keri (2006). “Social software and

learning”, UK: Futurelab.

MOBILE SOFTWARE FOR GATHERING AND MANAGING GEOREFERENCED INFORMATION FROM CRISIS AREAS

Documents

Transcript of MOBILE SOFTWARE FOR GATHERING AND MANAGING GEOREFERENCED INFORMATION FROM CRISIS AREAS