DGGS Subset Delivery Use Case
In the development of standards for Discrete Global Grid Systems it has been recognised that there is a need for an efficient method to transmit both data and queries/processes between different instances of DGGS (and to non-DGGS infrastructures). While it is likely that existing web service architectures such as Web Coverage Processing Services (WCPS), or even Web Processing Services (WPS) will be suitable for broadcasting and transmitting queries/processes between DGGS there is a distinct lack of an OGC architecture to directly transmit subsets (or structured summary data) extracted from a DGGS. Web Coverage Tile Services appears to be a promising architecture that could enable the delivery/transmission of a data subset from a DGGS whilst maintaining the inherent heirarchical structure of the DGGS.
Some more thought is needed on how a DGGS might interface with a WCTileS
server instance but I think something like a serialised stream of datacubes (rather than just flat coverages/layers) should be possible.
- 09 Jun 2015
- Authorised server supplying structured datacube subsets/query outputs from a DGGS (server may be sitting as a separate layer over the DGGS)
- another DGGS (or a number of DGGSs) receiving datacube tiles in response to a spatio-temporal query on the source DGGS
- Alternate, or additional, web client to display and/or deliver the requested datacube subset to a non-DGGS recipient.
- Server and Client need to be able to translate a generic spatio-temporal query into the context of a Coverage Tile Set (e.g. area, vertical extent, time period of interest)
- It is expected that a WPS/WCPS type service will be needed to dispatch queries to a DGGS - there needs to be a method of communicating and translating queries and return structures between WPS/WCPS -> DGGS -> WCTileS and vice-versa.
Main Success Scenario
- A spatio-temporal query can be submitted to a DGGS and a WCTileS datacube is successfully returned.
- The returned tile set should be able to be presented in either a web client of some sort or sent to another DGGS as part of a model simulation.
- The receiving DGGS might ingest the tile set, however, this action would be handled by the DGGS internal processes and is out of scope for the WCTileS standard.
- Given the hierarchical nature of DGGSs a WCTileS datacube must be able to accomodate multi-resolution data - possibly as separate tiles with different structural parameters.
- client service expires while waiting on data to be delivered from DGGS and must re-establish a new service that is aware of the unfinished request.
- The query made on the DGGS returns no data (or returns an error)
- The client is unable to handle the volume of data requested from the DGGS.
- The requested datacube tile sets remain in the web cache, unless the service enforces no caching.
There may be authentication required for access to different DGGS infrastructures. This should probably be in a separate layer but the WCTileS service may need to be aware of and negotiate with these external security authentication layers.
There may need to be a standardized schema developed for the structuring of WCTileS tile sets that is able to handle data layers of different spatio-temporal resolutions. This will be needed for a DGGS to properly (and systematically) prepare the output data from a query for delivery as a WCTileS datacube.
Some thought might be needed on the interactions between a WCTileS service and other OGC Web Services (e.g. WPS/WCPS) to negotiate how a client might construct and execute a query on a DGGS.
-- Main.clittle - 17 Jun 2015
- 23 Jun 2015