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
# | Title | User Story | Importance | Notes |
---|---|---|---|---|
1 | State-of-the art anaylsis | Before a final desihgn for the feature is dervied, a state-of-the-art analyis shall be performed:
| Must have | |
2 | Developer guide | Create 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 | |
3 | Data policy | Pay 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 | |
4 | Metadata | In-situ data must be attached by metadata 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.
For demonstration purpose, it is planed to use in-situ coming from MERMAID or from SeasideRendezvous (BIO-ARGOS from CORIOLIS).
The client tool is further documented in In-Situ Client Tool
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:
Question | Outcome |
---|---|
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.