[gdal-dev] WCS 2.0, getting (multidimensional) data

Ari Jolma ari.jolma at gmail.com
Tue Nov 7 00:56:07 PST 2017


Thanks for the replies before. I believe I'm getting closer, but slowly.

In my earlier question I was referring to three CRSs. I now believe that 
it is only two since I had overlooked requirement 23, which to my 
understanding requires that the CRS of the coverage (top level boundedBy 
element) is the same as the CRS of the grid (in domainSet element). Thus 
GDAL can and should set the dataset size and geotransform by what's in 
domainSet and there's no such ambiguity in the grid size as I thought.

To get multidimensional data into GDAL 2D domain, one may need to slice 
the data at some point in the non x/y dimensions. I'm testing this with 
the Rasdaman server. My code currently creates a KVP 
"SUBSET=unix(2008-01-08T00:02:58.000Z)" in an attempt to slice the time 
dimension. The whole test URL is

http://ows.rasdaman.org/rasdaman/ows?SERVICE=WCS&REQUEST=GetCoverage&VERSION=2.0.1&COVERAGEID=test_irr_cube_2&FORMAT=application%2Foctet-stream&SUBSET=E(75042.7273594,95042.7273593873)&SUBSET=N(5434865.55794,5454865.55794)&SUBSET=unix(2008-01-08T00:02:58.000Z)&RANGESUBSET=b1

which replies

Trimming subset in WCS must follow this syntax 'lowerBound,upperBound', 
given '2008-01-08T00:02:58.000Z'.

I don't understand why. I'm trying to slice, not trim. I don't know of 
other servers serving >2D data so I can't test with other brands.

With a MapServer instance I have a problem setting the rangesubset, it 
does not seem to work with field names, only indexes.

http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&REQUEST=GetCoverage&VERSION=2.0.1&COVERAGEID=BGS_EMODNET_CentralMed-MCol&FORMAT=image%2Ftiff&SUBSET=long(9.83125,9.83958334)&SUBSET=lat(46.18124999,46.18958333)&RANGESUBSET=band1

does not work although band1 is given as name in coverage description, but

http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?SERVICE=WCS&REQUEST=GetCoverage&VERSION=2.0.1&COVERAGEID=BGS_EMODNET_CentralMed-MCol&FORMAT=image%2Ftiff&SUBSET=long(9.83125,9.83958334)&SUBSET=lat(46.18124999,46.18958333)&RANGESUBSET=1

works.

Ari


Ari Jolma kirjoitti 03.11.2017 klo 09:57:
> I have two things that I need to ask/discuss regarding WCS 2.0
>
> 1) My understanding is that there are potentially three CRS in 
> operation: the CRS of the bbox of the coverage (the native CRS of the 
> server); the CRS of the grid; and the CRS where the user wants the 
> data. I can imagine that it is perfectly possible for a server to 
> advertise data from an area bounded by geographic coordinates, and 
> that the data is in some specific projected coordinate system. Also, 
> the data could be regular but not east-north (it is rotated for 
> example). This would be described in a CoverageDescription. Despite 
> the rotation, GDAL would show the data east-nort (without rotation), 
> since only the bbox of the coverage is given.
>
> Again, it is perfectly possible that the user wants the data in some 
> CRS that is not the native CRS of the WCS. The GetCoverage request can 
> contain an instruction for the server to serve the data in the CRS the 
> user wants the data (this is an extension in 2.0). User can set this 
> (it must be one of those supported by the server) in the dataset 
> definition (WCS_GDAL XML). Thus GDAL needs to show the coverage bbox 
> to its users in that CRS. And, as above, the GeoTransform is east-north.
>
> Is this correct analysis?
>
> BTW, the coordinate transformation of the bbox is not done in WCS 
> driver at the moment in the case of user CRS != server native CRS.
>
>
> 2) WCS can offer multidimensional data with complex data records. I 
> want the GDAL user to have a control on how the data is organized into 
> (current) GDAL. For example the server may offer spatio-temporal 
> (x/y/t) data with about wave heights in a sea (to link this to what 
> I'm getting paid for now :)) that are described as average and max. 
> Obviously I want x/y bands, but I may want either the temporal data or 
> the wave height data into bands, depending on the application. The 
> workflow would go
>
> 1. gdalinfo to the server, see this data as a layer with name 
> "VHM0_year_meanmax", gdalinfo reports that layer as a subdataset
>
> 2. gdalinfo into the layer, now it reports that there is an additional 
> dimension (t) and that the datarecord consists of two values mean and 
> max; it also reports information about the time (begin, end, step)
>
> 3. I decide to use a specific time and start using datasets with two 
> bands (mean and max)
>
> I have such data as NetCDF and I don't think I can follow that 
> workflow with it since the driver puts the mean and max wave heights 
> right away into subdatasets and time into bands.
>
> In the WCS there could/should be a similar default behavior but that 
> should be changeable by options (-oo t=some_timestamp).
>
> Thoughts?
>
> Ari
>
>



More information about the gdal-dev mailing list