Time dimension(s) handling in Petascope

The incoming rasdaman 8.4 release will represent a watershed-release with respect to how Petascope handles time and more generally on how Petascope manages the coordinate reference systems of the coverages. That said, two separate sections are provided here to give guidance from both client and server viewpoint before and after the 8.4 release.

NOTE: No improvements or feature changes will be applied for maintenance of the 8.4 release.

How rasdaman_8.4 handles time

A temporal dimension is used to integrate time into the ​coverage model in case of series of spatial datasets.
Dates in WCS GetCoverage subsettings are currently supported in the format "t(YYYY-MM-DD[, YYYY-MM-DD])" on a temporal axis.

Finer temporal resolutions (hour, minutes, etc.) or irregular time spacing are not supported, however N-days resolution are accepted.

A KVP GetCoverage example:

...&service=WCS&request=GetCoverage&subset=t(2010-06-19)&...

A temporal axis is thus recognized by Petascope by its "t" label (binding the label in the request subset and the value in petascopedb::ps_domain.name), on which it assumes its coordinates are ​ANSI date numbers.
The gml:RectifiedGridCoverage of a response including a time-dimension fills temporal coordinates with ANSI integers at the domain "external CRS" level (e.g. gml:offsetVector, gml:boundedBy), and rasdaman indexes at the grid level (gml:GridEnvelope).
Direct grid indexes can as well be directly set in the WCS request by forcing the "CRS:1" coordinate system (the current label for the internal grid-CRS of a coverage), like: "...subset=t, CRS:1(0, 10)...)" #298.

The recommended setup for enabling such behavior in Petascope is to:

• have a regular time axis labeled t;
• set the CRS associated with the temporal axis to some CRS≠"CRS:1" (the current label for the internal grid-CRS of a coverage);
• set proper ANSI bounds in petascopedb::ps_domain: the ratio between these bounds and the sdom along the temporal dimension in rasdaman will determine the resolution.

Alternatively, a user could define own out of band time management by either:

• publishing temporal metadata inside the gmlcov:metadata of a WCS DescribeCoverage response;
• manage time entirely "in house".

The features in future releases are going to provide custom temporal resolutions with regular/irregular spacing, by implementing a new design for the management of spatiotemporal CRSs, and supporting the new GML 3.3 ​referenceable grids. See next section for further insight.

Ongoing development (towards rasdaman_9.0)

See slides​ for first concepts and examples.