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

[Ari Jolma]

Peter Baumann kirjoitti 03.11.2017 klo 10:54:
>
> On 11/03/2017 08:57 AM, Ari Jolma wrote:
>> 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)
> that is correct, Ari
>
>> in the dataset definition (WCS_GDAL XML). Thus GDAL needs to show the coverage
>> bbox to its users in that CRS.
> no, it's just one bbox; WGS84 is common. Otherwise you'd have to advertise
> sometimes thousands of bbox variants, which is not feasible.

What I mean here is that the GDAL dataset object, once initialized and 
being a real one (i.e., usable for accessing data , not a kind of path 
to subdatasets that are real ones), has a CRS, GeoTransform, and also 
the raster size (nr of cells). And the CRS of the GDAL dataset may be 
the native CRS of the server, or something the user sets. That then 
dictates also the GeoTransform (since a GeoTransform contains a point 
and distances in the CRS). I hope I'm being clear here. It is true that 
there may be thousands of bbox variants (for example GeoServer says it 
supports ~5800 CRSs, they are all listed in the Capabilities XML), but 
only one bbox is eventually shown to the user in the dataset object, and 
it must be in the CRS of the dataset object.

Another thing, the raster size. Since the real raster, whose size is 
given in GridEnvelope in CoverageDescription, may be rotated relative to 
the GDAL dataset, the GDAL dataset size is in general case not the size 
of the real raster. It's just a computation but the result is that the 
size of the WCS dataset raster may be an approximation.

Ari

> -Peter
>
>> 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
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev