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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Ari Jolma-2
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


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS 2.0, getting (multidimensional) data

Ari Jolma-2
one detail forgotten

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.

There is also the coverageFunction, which contains, in the case of
grids, a GridFunction. GridFunction may contain non-Linear sequenceRules
but they are probably too exotic to be supported by the GDAL WCS driver.

>
> 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
>
>

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS 2.0, getting (multidimensional) data

Peter Baumann
In reply to this post by Ari Jolma-2


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.
-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
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

--
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: [hidden email]
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: [hidden email]
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS 2.0, getting (multidimensional) data

Even Rouault-2
In reply to this post by Ari Jolma-2

 

> 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.

 

For me the "native" CRS (as much as a client can see) is the one of the CoverageDescription.boundedBy.Envelope@srsName attribute. If the server advertizes it as EPSG:4326, but the native data is in something else, this is an implementation detail of the server. That said, as you mention, the user could then decide to request in that alternative CRS if it has knowledge of that.

 

> 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.

 

You should be able to retrieve the rotation/shearing terms in the domainSet.RectifiedGrid.offsetVector 's element similarly to other WCS versions

 

Regarding GridFunction, there was a thread about this some time ago:

https://lists.osgeo.org/pipermail/gdal-dev/2017-April/thread.html#46366

 

>

> 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?

 

Yes, one could image a user specifying something like

WCS:http://blaba&CRS=something to ask for server reprojection, and the geotransform exposed to the user should be in that CRS for consistency.

 

>

> 2) [...]

> In the WCS there could/should be a similar default behavior but that

> should be changeable by options (-oo t=some_timestamp).

 

Sounds reasonable.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS 2.0, getting (multidimensional) data

Ari Jolma-2
In reply to this post by Peter Baumann
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
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS 2.0, getting (multidimensional) data

Ari Jolma-2
In reply to this post by Even Rouault-2
Even Rouault kirjoitti 03.11.2017 klo 11:07:

 

> 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.

 

For me the "native" CRS (as much as a client can see) is the one of the CoverageDescription.boundedBy.Envelope@srsName attribute


exactly

. If the server advertizes it as EPSG:4326, but the native data is in something else, this is an implementation detail of the server. That said, as you mention, the user could then decide to request in that alternative CRS if it has knowledge of that.

 

> 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.

 

You should be able to retrieve the rotation/shearing terms in the domainSet.RectifiedGrid.offsetVector 's element similarly to other WCS versions


yes, and that is needed to compute (approximate) the size of the GDAL dataset raster, as I just wrote in another reply to this thread.

Ari


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS 2.0, getting (multidimensional) data

Even Rouault-2
In reply to this post by Ari Jolma-2

> 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.

 

Ah, i think I see your point

 

If the grid offsetVector express a rotation. WCSParseGMLCoverage() currently expose as dimension the value of limits.GridEnvelope.high[] - limits.GridEnvelope.low[] + 1 and the offsetVector's in the geotransform. So this is consistant.

But when you do a RasterIO() request which translates to a WCS GetCoverage request you express a BBOX, and not something in grid/image coordinates. Wondering what kind of response a server would return then... Would it be a "straigth" grid our would it keep the rotation exposed in the CoverageDescription

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS 2.0, getting (multidimensional) data

Ari Jolma-2
In reply to this post by Ari Jolma-2
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
>
>

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS 2.0, getting (multidimensional) data

Peter Baumann
Ari-


On 11/07/2017 09:56 AM, Ari Jolma wrote:

> 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'.

did you try putting the time string in double quotes? As the string can have any
syntax it needs to be escaped.

>
> 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.

syntactically, you are slicing because you have only one time coordinate;
trimming needs lower + upper bound.

-Peter


>
> 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
>>
>>
>
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

--
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: [hidden email]
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: [hidden email]
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: WCS 2.0, getting (multidimensional) data

Ari Jolma-2
Peter Baumann kirjoitti 07.11.2017 klo 16:29:

> Ari-
>
>
> On 11/07/2017 09:56 AM, Ari Jolma wrote:
>> 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'.
> did you try putting the time string in double quotes? As the string can have any
> syntax it needs to be escaped.

ok, thanks, that works.

Ari

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev