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
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.
Top Related