Geo Data Integration on UNHCR GeoPortal
& Geo Data Collection on Mobile Devices
Goma, Eastern Democratic Republic of Congo (DRC)
9-18 March 2010
A data management mission took place from 9th to 18th March to Goma, DRC. The objectives were: first to
explore new solutions to improve field data collection mechanism and second to help integrate currently
available information to the UNHCR GeoPortal.
1. Team composition
FICSS/DPSM was represented by Edouard Legoupil, Data Management Officer, who joined a delegation of
Google made of:
 Divon Lan, Product Manager, Sub Saharan Africa, Tel Aviv. divon@google.com
 Evans Arabu, Geo/ODK specialist from Nairobi. earabu@google.com
 Sean Askay, Google Earth Outreach, MTV alchemist@google.com
 France Lamy, Program Manager, Partnership. Google.org. flamy@google.com
The mission coordinated the work with the UNHCR Operation Data Manager for Eastern Congo, (Colince Guedje
Ngatsi); the UNHCR Regional Officer, based in Kinshasa (Alicia Ortega-Gonzales) and the UNOPS Associate GIS
Officer (Jean-Laurent Martin) from the IDP Data Center project. The mission reported to the UNHCR Coordinator
for Eastern Congo (Karl Steinacker) and the Head of Goma Sub-Office (Matsi Notz).
2. Advantage of mobile data collection and comparison with existing
systems
Mobile data collection systems are more and more used by various organizations in the field.
Strengths
- Powerful questionnaire language (skip logic, value constraint…);
- Integrated photo/navigation system (GPS)/barcode/fingerprint collection (depending on the device);
- Easier submission of data – data collection and data entry at the same time;
- Enforces data standards through XML format.
Weaknesses
- Cost, durability, training needs;
- Creating electronic forms is more complicated than paper forms;
- Battery usage should be monitored (possibility to use solar charger or car battery);
- Updating existing data in an offline environment is complex;
- Susceptible to physical damage of smart phones, computers crash too common.
During the mission we had to opportunity to assess the mobile data collection system used currently by the WFP
“Vulnerability Assessment Mapping” Section (SuperWaba). The table below describes the differences between
the two systems. The Android/ODK system is judged more flexible than the Windows/SuperWaba as it offers
more ways to collect, format and transmit data.
Application
SuperWaba: http://www.superwaba.com.br
Operating System
Open Data Kit:
http://code.google.com/p/open-data-kit
Google Android
Data Standard
Xforms standard + Java Rosa
Device
Connectivity
Replaces several devices: a PDA+
Video
Wifi, GSM, Sd Card
XML outputted is not attached to a schema, ca not be
used as an interchange format
Few PDA fully integrate: PDA+ GPS + Video
Robustness of the
application
Forms deployment
Some minor bugs have been observed – cf
annex 1
Easy deployment of new forms through Wifi
Windows mobile
GPS +
Sd Card only
1
No information. WFP has already the system deployed in
6 countries.
Needs install on Sd card
3. Activities of the mission
1. Integration of the three current databases (“évaluation rapide”, IDP registration and GIS) and data
consistency analysis
2. Training for UNOPS and UNHCR Data management unit technical staff on advanced data management
tools
3. Installation of local replication of the UNHCR GeopPortal in Goma Sub Office
4. Installation of an analysis system on the IDP registration system currently managed by UNOPS
5. Transcription of different forms used in the field in the standard format used by Open Data Kit
6. Preparation of a short video presenting the test organized by the mission
7. Preparation of action items to start piloting the system – cf. annex 3
4. Findings
Separation of data collection and project implementation
Data collection is better managed as a specific project in an operation than as a subcomponent of a
programme. It allows then to separate the information collected neutrally in the field, the information
provided by partners implementing a project and the information from UNHCR officers evaluating a project.
The UNOPS IDP data center prevents conflict of interest in data management and is a good example of this
good practice.
Positive reaction from field staff to mobile data collection system
As shown in the video produced by the PI Unit of UNHCR Goma Office, the staff who tried the system was
enthusiastic. Field staffs are all from a generation that is keen on technology and feel gratified to use such
technology. It was impressing to see how quickly they did understand how to use the phones and the forms.
Google current soft commitment
Google foundation has totally changed its scope in 2009. It skipped from grant funding to technology
support1. Google strategy is to serve the public with the biggest amount of information. The major goal of
Google for this mission is not to support UNHCR operation to establish contracts for the supply of licensed
content (cf in annex 2, the example of contract sent by the Google mission leader). On our three main
requests, Google’s response, at this stage, remains limited:
 ODK support: ODK is originally a project from the University of Washington. The Google delegation
insisted on the fact that they will not be able to support formally an application that is not part of
the Google.org products (http://www.google.org/products.html);
 Contribution of phones: Google gave (OR LENT??) to UNHCR three G1 Android phones for a total
value of around 1000 USD (350 USD per phone);
 High resolution imagery: Although the release of high resolution imagery has been clearly
expressed during all the preparatory meeting (Google requested to delimit specific areas for the
procurement of HR imagery from UNOPS in North Kivu), the Google mission did not made any
announcement for such release.
1
“ When we reviewed our progress in early 2009, it became clear that while our partners were doing excellent work with our grant
funding, we could do more to effectively use Google's engineering talent by focusing on the technical contributions we could make. We
shifted our focus to engage in engineering projects at that time.” http://www.google.org/about.html
2
Need of a common strategy for geo data production and public data release
Many big NGO’s, who are not necessarily UNHCR IP, do have dedicated GIS staff based in the Kivus and do
collect information on their own. UNHCR, either directly or through the IDP Data Center, is collecting
different types of information, some of it being public domain data (Infrastructure and sectoral
assessments). It would be profitable for all actors to establish a true inventory of the data available within
the humanitarian community.
Although UNHCR has already its own web platform for geographic data dissemination, the UNHCR
GeoPortal, the collected public domain data need then to be published in a publicly available platform.
Google Map can be considered as one of the options to do so, Open Street map is another one (they have
furthermore a particular focus on humanitarian use2). This discussion must be initiated within the
humanitarian community while doing this inventory.
Expectation from local data management staff for more technical training
Despite the fact that providing training was not part of the initial ToR of the mission, it appears that there
was a strong need for more training on data management for (local) staff in French language.
5. Recommendations
1. The Google Team informed UNHCR that some “googlers” were ready to volunteer on the ODK project.
(Any Google employee is allowed to spend 20% of his time on personnal project). UNHCR should insist
on a more consistent commitment (i.e. ODK becoming a Google product). Publishing the video on the
UNHCR YouTube channel is a way to express this position.
2. Follow up with Google about the supply of high resolution imagery for the Kivus on Google Map
3. Contact mobile phone manufacturers to obtain alternative devices to further the testing phase. For
instance, Motorola has just launched one of the most advanced models of Android (called Milestone in
Europe or Droid in the US).
4. Clarify the vision of the local actors concerning the creation and the dissemination of public data in
Eastern DRC. This vision would be better established through a diagnostic from an external actor (i.e not
directly a UN agency).
5. Organize a follow-up training session in a upcoming pilot which should include the identification and
testing of alternative systems that could be available, favoring open source solutions.
2 http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags
3
Annex 1: List of improvement to ODK
Open Data Kit is an Open Source project. As such, there is a public list of feature request (called
“Enhancement”) or bug report (called “Defect”) in the Google code forge website:
http://code.google.com/p/open-data-kit/issues/list
During the mission, the following points were noticed:
1. Debugging. Some forms crash.
It is possibly related to this ticket: http://code.google.com/p/open-data-kit/issues/detail?id=115
2. Issues have been raised concerning the default langage of the form.
Cf also this ticket: http://code.google.com/p/open-data-kit/issues/detail?id=69
In general, ODK is not yet fully localized (i.e. the translation of the product into different
languages). The word “form” for example has not been translated.
3. Cascading selection is an intersting features for Admin level question.
Cf ticket: http://code.google.com/p/open-data-kit/issues/detail?id=103
4. ODK has not been created for data update. Some improvement should be made for data
reviewing:
a. Send the data back to the device and incomplete data;
b. Change the way XML files are stored in the device in order to make them searchable;
c. Build a search engine to find the xml files to be reviewed.
This may be linked to this ticket: http://code.google.com/p/open-data-kit/issues/detail?id=104
5. Improvement in the user interface for long questionnaires: Allow more than one question per
page.
No ticket in the forge yet.
6. Integration of ODK with a navigation application. The user should be able to visualize mapping
tiles offline
No ticket in the forge yet.
Using the 5 phones, officers in the field may define new tickets using the following template:
1. What steps will reproduce the problem?
2. What is the expected output?
3. What do you see instead?
4
Annex 2: GOOGLE SAMPLE LICENSED CONTENT
1.
Licensed Content:
a.
Licensor will provide to Google the following content, some of which is customized, according to the following technical
requirements and specifications (the “First Deliverables” and “Second Deliverables” collectively referred to as
“Deliverables”):
i. First Deliverables:
1. Geocoded datasets on health/education/water/etc service and product providers for integration into
Google Maps. Licensor annually collects information on X thousands of features (e.g, schools,
water points, health facilities) as part of its routine needs assessment. Licensor will make the
location and basic attributes such as the address and types of services of schools, water points,
health facilities publicly available and accessible through Google’s web-based mapping tools,
particularly for humanitarian organizations but also for the general public. Licensor already has a
number of datasets that are of interest to Google, including several thousands of schools, water
points, health facilities (others?). The inventory of schools, water points, health facilities for which
Licensor has the minimum data requirements for integration into Google Maps is listed under
Appendix 1. In total, up to about XX,000 schools, water points, health facilities in the Project
Countries will be provided under this phase.
ii. Second Deliverables:
1. Geocoded datasets on schools, water points, health facilities, as described above, for
approximately X,000 schools, water points, health facilities from DRC, and/or other countries.
iii. Technical Requirements and Specifications:
1. All points of interest will be uploaded into the Google Map database and will be publicly available.
Data transfer to Google will be done in “bulk” (e.g. Excel file of providers), or this can be done
directly by UNHCR. The ideal scenario would be where existing UNHCR datasets from the initial
countries and from other countries are provided in bulk to Google, whereas newly collected data
are uploaded directly by UNHCR (this can be done either centrally or by platforms), thus requiring
minimal input from Google. Google will provide guidance, at least initially, on the use of its mapping
tools.
2. The contents of the datasets that will be provided to Google include, at the minimum, the name and
type of health/education/water service/product provider, address, and geographic coordinates.
Specific attributes such as type of service provided may also be added. The detailed data scheme
is provided under Appendix 2.
b.
The Licensed Content will be delivered to Google according to the following schedule:
i. First Deliverables: Licensor will deliver to Google the First Deliverables listed above by no later than 30
calendar days from the Effective Date; and
ii. Second Deliverables: Licensor will deliver to Google the Second Deliverables listed above according to the
following schedule:
Country
Congo
Uganda
X country
2.
Number of Points
Interest (POIs)
XX
XX
XX
of Time period (BY THE FOLLOWING TIMELINES, OR AS
MUTUALLY AGREED UPON BY THE PARTIES)
(END
OF
)Q2
/
2010
Q2 / 2010
Q3 / 2010
Q3 / 2010
License Fees. In consideration of the Licensed Content licensed to Google hereunder, and subject to delivery and acceptance of
the Licensed Content in accordance with Section 3.4 of this Agreement, Google will pay to Licensor a total of US$ X 000 in fees
(“License Fees”), upon Google’s acceptance of the Deliverables.
The License Fees are for perpetual and irrevocable use of the Licensed Content by Google, as set forth in this agreement.
5
Annex 3: Open Data Kit Pilot project action Items.
Action items 1: Publication of the mission video
Lead: UNHCR Division for External Relations
Activity: Publication of the mission video on the UNHCR you tube channel- need first clearance
from Google and Premiere Urgence
Action items 2: Improvement of Open Data Kit
Lead: Google
Activity: Software development
Action items 3: Supply of high Resolution imagery for Kivu
Lead: Google.org
Activity: Publish high resolution imagery on Google Map (eventually premier accoubt only).
Action items 4: Finalisation of the forms and of the database connection
Lead: UNHCR Data Management Officer FICSS/BSC
Activity: XML configuration and jobs scripting
Action items 5: Enhancement request / bug report
Lead: UNHCR Data Management Officer Goma + UNOPS GIS Officer
Activity: Create specific ticket – cf annex1.
Action items 6: Test of different Android devices.
Lead: UNHCR Emergency ICT Unit
Activity: Choice of the most appropriated Android device
Different devices are available. Points to be considered are the following:
- Rugability vs cost of acquisition and operation
- Physical keyboard / virtual
- Adapted screen for high luminosity
Action items 7: Procurement of the devices and/or request for sample
Lead: UNHCR FICSS / DPSM
Activity: Procurement and shipment of the devices
Action items 8: Preparation of a deployment methodology.
Lead: UNHCR Data Management Officer Goma + UNOPS GIS Officer
Activity: Create a sharable document so that the system can be used in other operations.
Action items 9: Preparation of ToR for an IP to execute the pilot project
Lead: UNHCR Snr GIS Officer in coordination with Data Centre
6
Annex 4: Terms of Reference - GeoData Inventory and public Domain Data
Publication in Eastern DRC
Context
Numerous humanitarian actors do collect some information in Eastern DRC.
Currently there is no inventory of the types and the extents of the data collected by those
organisations
Objectives
The objectives (See action item 9 if Annex 3) of the study would be
 Meet with all partners that have GIS or DB capacities
 Prepare an inventory of the data available
 Initiate discussion about the exchange and publication of public domain data
Expected output

Populate a metadata data base, such as GeoNetwork http://geonetwork-opensource.org/, for
Kivu and train partners on how to maintain this GeoNetwork node.

Prepare a policy for public domain data publication

Elaborate a procedure for data publication (on Google MapMaker / Open Street Map)
7