Recovery Observatory Infrastructure Proposal 1

Contents Recovery Observatory Infrastructure Proposal 2 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.

4 Recovery Observatory Infrastructure Proposal CNES experience  CNES led the creation of a platform to gather and make available Earth observation data following the devastating Haiti earthquake of January 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.

5 Recovery Observatory Infrastructure Proposal 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

6 Recovery Observatory Infrastructure Proposal 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

7 Recovery Observatory Infrastructure Proposal 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

8 Recovery Observatory Infrastructure Proposal 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

9 Recovery Observatory Infrastructure Proposal 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

10 Recovery Observatory Infrastructure Proposal 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

11 Recovery Observatory Infrastructure Proposal 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 ……

12 Recovery Observatory Infrastructure Proposal 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)

13 Recovery Observatory Infrastructure Proposal 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?

14 Recovery Observatory Infrastructure Proposal 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.)

15 Recovery Observatory Infrastructure Proposal 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.)

16 Recovery Observatory Infrastructure Proposal 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.

17 Recovery Observatory Infrastructure Proposal 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

18 Recovery Observatory Infrastructure Proposal 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)

19 Recovery Observatory Infrastructure Proposal 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 …

20 Recovery Observatory Infrastructure Proposal 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 1 st 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.

21 Recovery Observatory Infrastructure Proposal 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

22 Recovery Observatory Infrastructure Proposal 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, …)