[mapserver-dev] What would be needed for adding SUBSET=time into WCS?

[Even Rouault]

Jukka,

It appears I looked at the issue about 2 years ago. Some of it might be a bit outdated, but I 
guess most must still be relevant:
Copying a few email exchanges between me and Stefan Meissl about that


me:
"""
Hi Stephan,

I'm being asked if time support could be added in Mapserver for WCS 2.0. As 
far as I can see there's no support for that right now. What puzzles me a bit 
is that the WCS 2.0 spec itself is rather silent on the time dimension, 
contrary to WCS 1.0. Do you know if there's a theoretical obstacle for 
implementing WCS 2.0 time ? It looks like a <gml:EnvelopeWithTimePeriod> 
element could be used instead of <gml:Envelope> in the <gml:boundedBy> element 
of a DescribeCoverage response.
I see there's also WCS-EO. Looking at the examples of
http://docs.geoserver.org/latest/en/user/extensions/wcs20eo/index.html it 
seems to have better built-in support for EO. So I guess that for a MapServer 
user, using EOxServer would be more appropriate for that ? The use case would 
be for weather datasets (so that's not always earth observations)

One question I'm also wondering is what happens if the user requests in a 
GetCoverage a range of datetimes or a list of datetimes. What is returned 
exactly ? Let's say for example this is GeoTIFF output. Is it multiple GeoTIFF 
or one GeoTIFF with a band for each time ? Currently MapServer WCS 1.0 
supports only one single time value.
"""

Stefan:
"""
You're right, we didn't add time support in Mapserver WCS 2.0 but are
rather using EOxServer and EO-WCS if needed.

WCS 2.0 tries to be generic for the DomainSet but inherits some
limitations and difficulties due to the usage of GML.

Your DomainSet has 3 dimensions and as long as you perform no slicing
you need to use a format that supports these 3 dimensions and the
current GeoTIFF mapping is only defined for 2 dimensions. So strictly
speaking and following the standard you can use GeoTIFF only if you
apply a slicing in one dimension, e.g. time, where you'd end up with a
single time value. Said this, we're also sometimes "misusing" GeoTIFF in
that we're storing the 3rd dimension like height as bands. Of course
this works only properly for data with one band in the RangeType and
your client needs to understand what you're doing and to get the right
metadata to correctly interpret the GeoTIFF.
"""

me:
"""
What would be your gut feeling about having pure WCS (without WCS-EO) 2.0 time 
in MapServer ? It looks it is technical doable, but perhaps not so usable ? Or 
that would perhaps require extending the DescribeCoverage response with at 
least some metadata from the EO-WCS schema.

Regarding GeoTIFF and multiple images for different time values, one option 
would be also to create multiple IFDs (subdatasets in GDAL parlance).
"""

me:
"""
Interestingly Rasdaman supports time dimension with 'pure' WCS 2.0, using a
compound CRS approach and using a GML 3.3 gmlrgrid:ReferenceableGridByVectors to deal 
with irregular time values:

http://ows.rasdaman.org/rasdaman/ows?
&SERVICE=WCS&VERSION=2.0.1&REQUEST=DescribeCoverage&COVERAGEID=test_irr_cube
_2

The GetCoverage without slicing doesn't work with TIFF, but works with netCDF (and the
impractical pure GML GetCoverage response)
"""

Stefan (about Rasdaman output):
"""
Right, in CIS 1.0 (formerly GMLCOV) all axes need to be treated equally.
The ReferenceableGridCoverage Extension add support for some of the GML
3.3 ReferenceableGrid types. In CIS 1.1 it is possible to combine
rectified with referenceable axes. Support for CIS 1.1 would be added in
WCS 2.1 but there is some confusion about this document and its current
status at OGC.
"""

So my temporary conclusion was that there was no universal unambiguous proper way of 
supporting time dimension in WCS 2.0. Different servers come with different ideas on how to 
do that.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20201001/281b2b3f/attachment.html>