Skip to end of metadata
  • Created by Former user (Deleted), last modified on 2015-06-25
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Target releaseS3TBX 3.0
Epic SIIITBX-25 - Getting issue details... STATUS
Document statusDRAFT
Document owner

Former user (Deleted)

DesignerFormer user (Deleted), Olivier Sardou (Unlicensed), Philippe Garnesson (Unlicensed)
DevelopersFormer user (Deleted), Olivier Sardou (Unlicensed),  Philippe Garnesson (Unlicensed) 
QAOlga Faber (Unlicensed)

Goals

  • From ESA S3TBX SoW: The S-3 Toolbox via a Web Application Server shall connect to on-line in-situ data collections such as e.g. GHRSST co-located satellite and in-situ SST data allowing to extract useful knowledge through multidimensional interactive display functions (time series, scatterplots, histograms, maps) from these data collections.

Background and strategic fit

Starting from BEAM 4.10, correlative data, such as in-situ data, can be imported and used for various analyses in conjunction with raster data. Correlative data is facilitated in the Correlative Plot tool, the Profile Plot tool, and the Time-Series tool plug-in (installable from module manager). Until now, BEAM can only import correlative data from CSV/plain text or ESRI Shapefiles with point geometries. Internally, in-situ data is stored in attributes as part of so called features. BEAM, uses an OGC-compliant model of a Simple Feature (from GeoTools library) which is basically a data structure that comprises some geometry (such as a point, line or polygon) and a number of attributes (key-value pairs). 

Assumptions

  • Users will primarily access this feature from the SNAP Desktop's main menu.
  • The feature is just another source for correlative data. This means that whereever correlative data is used in SNAP/S3TBX 2.0, it should be possible to use the data ingested from the remote in-situ data service.
  • The feature is assumed to be a demonstrator for a limited number of services, number of datasets, and nukmber of concurrent users.

Requirements

#TitleUser StoryImportanceNotes
1State-of-the art anaylsis

Before a final desihgn for the feature is dervied, a state-of-the-art analyis shall be performed:

  • look into existing standards in this domain such as the OGC Sensor Observation Service (SOS)
  • look at similar systems such as Felyx, an approach to harmonise various in-situ data sources, combine them with satellite data and to make the data and data match-ups searchable in a scalable way
  • consider candidate providers such as GHRSST MDB, MERMAID, CORIOLIS, MyOcean In-Situ TAC database, CEOS CalValPortal, Aeronet, NASA SeaBAS, CNES SAD database, OC-CCI Phase 2 in-situ database
Must have 
2Developer guideCreate new "How to" wiki pages describing (a) how to implement a new service, and (b) how to use the web service's RESTful API on the client side.Desired 
3Data policyPay attention to legal conditions regarding the publication of the data (intellectual property rights, ownership, copyrights, licensing). Published data shall always be correctly cited. Must have 
4MetadataIn-situ data must be attached by metzadata and made visible to users so they know how to correlate the remote data with their EO data.  

User interaction and design

Client Tool

The client tool will have a GUI similar to the OPeNDAP client included since BEAM 4.11. Users will be able to use the tool to select subsets of in-situ data. The client tool shall also make intelligent use of the current context the user is working in. For example, a function will be provided that performs a query based on the current scene the user is working with: Spatial region and temporal range are determined, so the user could use a one-click action that would download and display all in-situ data found for that particular scene. Uses can select the web service name / URI they wish to get the in-situ data from.

Web Service

For the server-side, a web service will be developed which translates a request coming from the Toolbox into the query language understood by the in-situ database. The data retrieved from the database in translated back into the response understood by the client tool in the Toolbox.  We will provide at least an in-situ service for the MERMAID database focusing on MERIS / Sentinel-3 data. A second service for SLSTR SST data is very desireable (see GHRSST SST in-site data). The NASA OBPG might contribute a service for the SeaBASS database as well.

Web Service API and Exchange Format

The web service API shall be based on a RESTful design. The API shall be as simple as possible, so that it is made easy to implement new compatible services and made easy to develop clients for the services. The in-situ data exchange format shall be XML or JSON. Any existing standards (e.g. OGC SOS) shall be adopted as far as possible given the budget and time constraints.

Questions

Below is a list of questions to be addressed as a result of this requirements document:

QuestionOutcome

Not Doing

  • On-the-fly transformation of in-situ data so that it matches the geophysical units of the target EO data to be compared with
  • Provide an operational 24/7 service for e.g. 100 simultaneously operating users.
  • No labels