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

Thu Oct 1 11:52:15 PDT 2020

Hi Even,

This is how Geoserver supports time in WCS 2.0. The service should be open for everybody now but it will disappear someday so I copy most relevant parts also as text.

https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS&version=2.0.1&request=DescribeCoverage&coverageID=ortokuva__ortokuva

BoundedBy is 3 dimensional

<gml:boundedBy>
<gml:EnvelopeWithTimePeriod srsName="http://www.opengis.net/def/crs/EPSG/0/3067" axisLabels="E N time" uomLabels="m m s" srsDimension="2">
<gml:lowerCorner>61254.6580619824 6623749.72946716</gml:lowerCorner>
<gml:upperCorner>735433.573091962 7782000.0</gml:upperCorner>
<gml:beginPosition>1985-12-31T00:00:00.000Z</gml:beginPosition>
<gml:endPosition>2020-12-31T00:00:00.000Z</gml:endPosition>
</gml:EnvelopeWithTimePeriod>
</gml:boundedBy>

Time positions are also listed in DescribeFeatureType

<gmlcov:metadata>
<gmlcov:Extension>
<wcsgs:TimeDomain default="2020-12-31T00:00:00.000Z">
<gml:TimeInstant gml:id="ortokuva__ortokuva_td_0">
<gml:timePosition>1985-12-31T00:00:00.000Z</gml:timePosition>
</gml:TimeInstant>
<gml:TimeInstant gml:id="ortokuva__ortokuva_td_1">
<gml:timePosition>1986-12-31T00:00:00.000Z</gml:timePosition>
</gml:TimeInstant>
<gml:TimeInstant gml:id="ortokuva__ortokuva_td_2">
<gml:timePosition>1988-12-31T00:00:00.000Z</gml:timePosition>

This information is enough for clients to know what label to use in SUBSET, and what timePositions are available.

Slice with one timePosition suits for CIS, for GeoTIFF, and for users.
https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS&version=2.0.1&request=GetCoverage&CoverageID=ortokuva__ortokuva&SUBSET=E(393450,393650)&SUBSET=N(7495450,7495650)&format=image/tiff&SUBSET=time(%222010-12-31T00:00:00.000Z%22)

This far I suppose there is nothing that is against the standard. However, if user requests time range that contains several timePositions Geoserver does care that it can't write 3D data cube into GeoTIFF. If just writes out two dimensional GeoTIFF that is sliced to contain data from newest timePosition within the range. Selection criteria may be something else if the tile index is sorted differently. It may not be right according to CIS, but it is rather practical. If I remember right this is also what  Mapserver does with WMS https://www.mapserver.org/ogc/wms_time.html.

We deal with orthophotos and that we have orthophotos from year 1988 does not mean that we have them from the whole country. Often users want image with half-open range "GeoTIFF from year 1988, or from newest image that exists before". Geoserver does that with time subset. We are doing the same also with Mapserver but for that we had to add startTime and endTime columns into tileindex and client must use &startTime=...&endTime=... instead of &SUBSET=time(...) and only self-tailored browser clients know how to do that.

-Jukka-

Lähettäjä: Even Rouault <even.rouault at spatialys.com>
Lähetetty: torstai 1. lokakuuta 2020 19.59
Vastaanottaja: mapserver-dev at lists.osgeo.org
Kopio: Rahkonen Jukka (MML) <jukka.rahkonen at maanmittauslaitos.fi>
Aihe: Re: [mapserver-dev] What would be needed for adding SUBSET=time into WCS?

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/22b59c22/attachment-0001.html>