Presentation given by Guido Lemoine EC-JRC-IPSC-SES-ISFEREA during UN-SPIDER Workshop, UN Campus Bonn, Germany 30 October 2007

1. Collaborative Geo-information Capturing
To Support Emergency Response
UN-SPIDER Workshop, UN Campus Bonn, Germany
30 October 2007
Guido Lemoine
EC-JRC-IPSC-SES-ISFEREA

2. Introduction
• JRC-Support to External Security (SES) Unit provides scientific
& technology advice to European Union’s Commission services
in external policy realm (DG RELEX, ECHO, AIDCO, JLS,
ENV/MIC)
• Extended to EU partners in international aid, development,
humanitarian affairs
• Ongoing collaborations with UN organisations (UN-OCHA, UN-
DPKO, UNOSAT), Worldbank, African Union, Red Cross

3. Introduction
• JRC-SES Unit focus on multi-stage crisis cycle,
including risk modelling, early warning, rapid response
and reconstruction & reconciliation
• Development and proto-typing as part of institutional
role and collaborative R&D with partners
• Service development under the Global Monitoring of
Environment and Security (GMES) programme

5. GDACS September 2007

6. GDACS September 2007

7. GMES Emergency response (FTS):
main information
reference maps available within 6 hours
over crisis area
damage maps available within 24 hours &
daily updated before 5 pm
forecasts of evolution of situations to be
made available
linking with other hazard management components beyond rapid response
(preparedness and alert) – service evolution in mid/long-term
integrating with remit of forecast and alert centers (met / hydro / seismic)
Applicable within & outside EU
(more information in WP 2)

8. Collaborative geo-information capturing
• Emergency response: rapid mapping + geospatial
analysis to support coordination and decision making
• Requires
– Situation assessment from a collation of existing data sets
– Impact assessment with post-event imagery and information
– Responding to specific geospatial questions
– Organisation of post-event peak workloads, contributors, etc.

9. IT Challenges
• Distributed access to geospatial data sets
• Distributed access to large very high resolution imagery
• Collection of distributed inputs (“feature capturing”), including field data
• Communication of distributed workloads
• Extensible architecture to interface to spatial querying, image processing
• Visualisation, for multiple end-users
• Must accommodate various roles (project manager, digitiser, geo-spatial
analyst, decision making end-user, etc.)
• Quality control, project organisation, authentication and access rules etc.

11. IT Components chosen
• Google Earth standard client (latest version supporting KML 2.2)
• (250+ Million downloads, comes with access to VHR data!)
• TOMCAT application server
• PostgreSQL/PostGIS spatial back end + versioning enabled
• Geoserver + geotools for application logic (data capture, data presentation)
• GDAL (FWTools) for data preparation; uDig, OpenJump for data control
• Java + JSP/JSTL server components
• KML standard (including SuperOverlays)
• Public (GE) and open source: zero install cost!
• GEO-spatial Repository for Google Earth (GEORGE)

12. GNEX’07 test case
• An emergency scenario simulation. Post-conflict disease control.
• Organised by the GMOSS Network of Excellence in Security
R&D (an FP6 GMES project)
• Under the management of DLR, contributions from 10+ GMOSS
partners, over 40+ people involved
• Use of EO data for situation assessment
• Geo-spatial analysis for population characterisation (density)
• Logistical information on routing, water resources, health care,
evacuation and quarantine measures
• Testing GEORGE parallel to “traditional” work methods

13. • Integration of full resolution imagery
• Both off-line and on-line
TerraSAR-X QuickBird

14. • Integration of archived geo-spatial features
(e.g. UN-GIST, user-generated)
• Integration of output of geo-spatial queries

15. • Integration of image processing outputs
• Integration of output from automated
image analysis routines
• Collection of manual digitisation outputs
Automated building SPOT-5 derived built-up
count (Z-GIS) index (JRC)

16. Conclusions
• Geo-spatial e-Collaboration in emergency response is
technically feasible, including “downstreaming” of large imagery
• Extensible to include elaborate spatial querying and image
processing
• Adaptable to regional and thematic specificity of typical
emergency response contexts
• Collaborative framework allows (rapid) collation of distributed
digitisation efforts with expert knowledge

17. Why does this matter for UN-SPIDER?
• Emergency response goes beyond data identification
• Needs to address formal description of deployable
services/expertise
• Needs to describe service interfaces, standards
• Needs to address QoS in emergency response context
• Management issues, project control, procedural workflow,
capacity brokerage, post-event evaluation
• Free and Open Source components benefit knowledge transfer
and capacity building

18. For more information, test cases, ideas, etc.
guido.lemoine@jrc.it
T. +39 0332 78 62 39
Thank you for your attention!