Recovery Observatory Infrastructure Proposal 1. Contents Recovery Observatory Infrastructure Proposal 2 Context Application Objectives Development plan.

Recovery Observatory Infrastructure Proposal1

Recovery Observatory Infrastructure Proposal

Conten

ts

Recovery Observatory Infrastructure Proposal2

• Context • Application Objectives• Development plan• Data types, ingestion & access• Result displays, home page• Provided Services• User profile, access grants• Data license management• Architecture, Performance, Flexibility

3 Recovery Observatory Infrastructure Proposal

Context

The International Charter Space and Major Disasters has clearly demonstrated the interest of using satellite-based EO for disaster response. However, the large volumes of data collected during the response phase are rarely available to those supporting recovery.

Furthermore, while research shows that EO can be a valuable tool for recovery, DRM stakeholders do not have a clear example of how EO can be used to support Recovery efforts and an optimal scenario for data collection and sharing has not been put forward for any major catastrophes.

A generic concept of ‘Recovery Observatory’ is proposed by the CEOS DRM group to demonstrate these benefits .


CNES experience

CNES led the creation of a platform to gather and make available Earth observation data following the devastating Haiti earthquake of January 2010. This project, the KalHaïti project, has made great progress over the past three years, and has allowed CNES to learn some lessons.

Among those, the importance of a collective work between data providers and end-users has been underscored. But also being prepared before a catastrophic event takes place would offer much greater impact for this kind of project.

The Recovery Observatory proposal extends this kind of initiative with the support of the community of CEOS members.


Application functionalities

The goals of the RO are detailed in the presentation of the proposal. Here we focus on the functionalities which would be necessary for implementing the RO.

To offer a collaborative access to databases

To develop networks of users

CEOS agencies will essentially provide data to the Observatory

Mechanisms must be established to allow participation of partners who can provide value-added products and services


Development plan

CNES has already provisioned resources for the development of a new Kal-Haïti server

Instead of developing a dedicated tool, CNES propose to develop a more generic tool for the recovery observatory

Involving all the CEOS agencies for the specification

» Everything in this document will be discussed, amended by WGDisasters / WGISS

Reusing existing pieces of software or resources (if applicable) already available from CEOS agencies

First basic version : October 2014 (that could be usable with minimal functionalities, should the Recovery Observatory be triggered before availability of the full version)

Full version : mid 2015


Which users communities ?

International users (or stakeholders)

International organizations (either governmental like WB or NGOs like the Red Cross) with a mandate tied to the recovery of major disasters and a major stake in supporting recovery efforts

Local authorities

Local organizations and volunteers


Which implementation ?

Three approaches are possible:

A dedicated Recovery Observatory per triggered disaster

A unique and shared Recovery Observatory for all the triggered disasters

A unique and shared Recovery Observatory for a subset (e.g. for one agency) of triggered disasters


Features towards users communities

Communities animation

Multidirectional exchanges: each user is a peer, supplier and consumer

Easy handling of processing (allow instantiation of multiple version of processing chains as well as datasets)

Dataset providers can choose the grant access policy to the data they provide


User benefits

Access to a single repository of data sources related to user needs with standardized access means:

access to these data sources from standard GIS applications

visualize and interact with this data (e.g. to build a context definition, to create a synthesis document, etc.)

share information on a given context to work in a collaborative way with other partners

export a map context for an offline use on the field, and to sync information back to the repository when network is reachable


Example of accessible data types

EO data (typically provided by agencies) : high resolution and very high resolution optical imagery; high and very high resolution radar imagery (X, C, L-bands). airborne data

In situ Data, ground truth

User Products (typically data provided and uploaded by end users) It is clear that the Observatory can only be successful if relationships

are established to enable the generation of products from the contributed data.

Reports, publications

Maps (reference layers, thematic maps etc.)

Public data …


Data ingestion

Ingestion service supports multiple data types (e.g. images, documents, service endpoints, etc. ).

The services provided to users on these data will depend on their types

Visualization service for optical imagery (full resolution through WMS)

Full text search for documents» When a document is uploaded (e.g. PDF), the content is indexed for search purpose

and the document is geolocalized. If possible, text indexing is linked to a thesaurus in order to generate linked data description (RDF description associated to keywords). Upon upload, detected keywords with proposed links are displayed to the user for validation

Automatic harvesting of external catalogs (e.g. CSW endpoints)


Data access (1/2)

Case 1 – “google like”A catalogue of data and services is put in place : i.e. full text search that yield to a textual search result with service

endpoints to access the data (open search service, WMS, WFS, WPS) Related use-case : a user will add this service endpoint to his GIS

application .

Case 2 – “google map like”A web application based on a map is developed : All data and services are visible on the map User can build his own map context (i.e. using layers, adding objects,

…) and can share it with other users through an URL (public access or group protected)

The context can also be downloaded as a geopackage for an offline usage on the field.

Question : are there other main usecases?


Data access (2/2)

Data will be sorted :

On search results with implicit search criteria : more recent first, less cloudy first (for optical images)

Using user feedbacks (“star” like ranking, frequency of access, user comments, etc.)


Data search and result display Cartographic display

“Google maps” like Search and results tabs Sortable result list Sub-selection (faceted search) Bookmarked data, bookmarked search criteria Semantic search Full text search Mail alert on recorded search Tag management on objects (on data, users, ROI, etc.)


Information displayed on the Home Page

Map-centered display (with enlargeable text panes)

Map showing the current activity (“Waze” like) : the new products that match the user profile Online users

Trends given from current user searches,

New public and private messages, new comments

Direct links to most used content and services (within the portal)

Etc.


Provided Services Processing on demand

WPS services (e.g. vector manipulation [buffer on a river for flood impact], reprojection, ROI cropping)

Data description improvement based on Systematic tagging from exogenous data (e.g. ECVs : land cover ;

location, …) User input : crowdsourcing approach Data ranking based on ‘human subjective quality’ (comments,

popularity, …)

Notification Service news , mailings Multiple notification subscription (content type, location, etc)

Events management & collaborative work calendar Gathering of publications, presentations, … current status of projects


Users and access grants

Centralized user management for all features

Access grant management based on :

Functionalities (e.g. to publish news),

Region of interest

Datatypes

Usergroups privileges

“tags”

The user can grant access to his own published data (like in Facebook)

User authentication through the local web server or via SSO (preferred)


User profile content

Regions of interest Thematic of interest Bookmarked data search Own published webcontent (“like Facebook wall” and blog

entries) Published files and data Linked users, linked groups Project and corporate information Subscriptions Configuration of items to be displayed upon login

The user profile content shall allow browsing based on members, groups, entities, locations …


Data licenses management (for data provided by agencies)

Multiple license management.

Each data within the repository may be attached to zero, one or many licenses Is zero a good solution ? Should at least one license be applied by

default (e.g. creative commons)

A license has the following attributes : Title, multilingual description (to be endorsed by end user) Agreement modes by user : upon user registration («once and for

all»), upon 1st download, before every single download Usage restriction :

» For Public Service authorities only» For users belonging to a list of eligible user nationalities or user countries» Limited to a region of interest,» Limited to a time span» Etc.


Architecture & Performances

Architecture based on a web server (or a set of web servers)

Scalable/elastic architecture (number of servers)

Localization to be defined: public or private cloud, dedicated hosts…

Load balancing of web server and processing servers (as well as session-based admission control, downloads management…)

Performances to be specified GUI, data searches Network Processing Display

Data Volumes to be specified


Flexibility

Allow the ability for granted operators : to add new data types within the system without software

modifications to implement and declare new processing chains with related inputs

and outputs to add new search criteria related to these datatypes within the web

application

« plug-in » declaration in order to handle new data types metadata parsing, quick-look production, multiple scale map overlays ...

Use of standards in order to ensure data access interoperability

Ability to have a Recovery Observatory instance adapted to a specific disaster type (flood, earthquake, tsunami, …)

Recovery Observatory Infrastructure Proposal 1. Contents Recovery Observatory Infrastructure Proposal 2 Context Application Objectives Development plan.

Documents

recovery observatory

observatory mechanisms

recovery efforts

recovery of major disasters

international users

data providers

data collection

ceos drm group