|
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).
| # | 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 metzadata and made visible to users so they know how to correlate the remote data with their EO data. |
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 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.
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.
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
| (e.g. How we make users more aware of this feature?) | Communicate the decision reached |