WCS request to THREDDS server fails due to inverted min/max in bbox

[rprinceley]

Attempting to open a service on the THREDDS server fails due to bbox order.

Input:

<WCS_GDAL>
  <ServiceURL>http://motherlode.ucar.edu:8080/thredds/wcs/fmrc/NCEP/GFS/Alaska_191km/runs/NCEP-GFS-Alaska_191km_RUN_2011-06-09T12:00:00Z?</ServiceURL>
  <CoverageName>Absolute_vorticity</CoverageName>
  <GetCoverageExtra>&time=2011-03-22T00:00:00Z</GetCoverageExtra>
</WCS_GDAL>

Fails with response:

<?xml version="1.0" encoding="UTF-8"?>
<ServiceExceptionReport xmlns="http://www.opengis.net/ogc" version="1.2.0">
  <ServiceException code="InvalidParameterValue" locator="BBOX">BBOX [-5048.12470181713,-6572.23975281449,-4667.12470181713,-6953.23975281449] minimum point larger than maximum point.</ServiceException>
</ServiceExceptionReport>

[warmerdam]

Reviewing the THREDDS server - it is a disaster!

One particularly frustrating point is that the RectifiedGrid is the fake EPSG:-3 while the only supported request SRS is OGC:CRS84.

Section 8.3.4.1 of OGC 05-076 (the WCS 1.0.0 Corrigendum) states:

"For georectified images or grids , when this CRS references an EPSG or AUTO coordi- nate reference system, it designates the base ground CRS for the georectified image or grid -- not the internal image CRS. Each referenced CRS must be the same as referenced by the srsName attribute of one of the RectifiedGrid elements defined in Subclause 8.2.1.1"

We depend on using the position information in the RectifiedGrid to make requests but it is in an arbitrary coordinate system that we can't use for requests. Per the spec it must match up with the supportedCRSs.

Also with regard to the BBOX ordering the problem seems to be that the "y" offsetVector is 0 190.5 0 indicating a south up image. I have manually edited the coverageOffering to to make it "0 -190.5 0" to get past this issue.

Note some servers do offer "south up" images and I think we need to be able to request them with a BBOX with the first y coordinate being greater than the second.

I have made some changes in trunk to try and use the same name as the server uses to describe a coordinate system (ie. OGC:CRS84 instead of normalizing it to EPSG:4326 as we were) and to report errors even when the response code is 400 which was supressing message reports. I *think* it is a bad practice for the servers to return http 400 when they are returning an xml exception report but I'm not positive. Anyways, GDAL WCS will make more of an effort now to report the exception in this case.

Changes are in trunk (r22534).

Tomorrow I will dig further into trying to handle the time dimension even if I need to doctor the coverage offering of the server to get back some core problems.

Let me know if you really think we ought to be supporting this THREDDS server "out of the box".

[rprinceley]

Frank,

Testing with latest trunk, I still get a "minimum point larger than maximum point" exception (during EstablishRasterDetails()).

GET /thredds/wcs/fmrc/NCEP/GFS/Alaska_191km/runs/NCEP-GFS-Alaska_191km_RUN_2011-06-09T12:00:00Z?SERVICE=WCS&VERSION=1.0.0&REQUEST=GetCoverage&COVERAGE=Absolute_vorticity&FORMAT=GeoTIFF&BBOX=-5048.12470181713,-6572.23975281449,-4667.12470181713,-6953.23975281449&WIDTH=2&HEIGHT=2&CRS=OGC:CRS84&time=2011-06-14T12:00:00Z HTTP/1.1
Host: motherlode.ucar.edu:8080
Accept: */*
Accept-Encoding: gzip
Connection: Keep-Alive

HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
Content-Type: application/vnd.ogc.se_xml
Date: Tue, 21 Jun 2011 09:02:53 GMT
Connection: close
Content-Length: 350

<?xml version="1.0" encoding="UTF-8"?>
<ServiceExceptionReport xmlns="http://www.opengis.net/ogc" version="1.2.0">
  <ServiceException code="InvalidParameterValue" locator="BBOX">BBOX [-5048.12470181713,-6572.23975281449,-4667.12470181713,-6953.23975281449] minimum point larger than maximum point.</ServiceException>
</ServiceExceptionReport>

[rprinceley]

Frank,

We do need to support THREDDS, NOAA and other organizations seem to be using this implementation.

[dneufeld]

Frank,

Regarding the bbox and offset vector issue, perhaps a simpler example is available here:

​http://www.ngdc.noaa.gov/thredds/wcs/relief/ETOPO1/thredds/ETOPO1_Ice_g_gmt4.nc?service=WCS&version=1.0.0&request=DescribeCoverage

<gml:origin><gml:pos>-180.0 -90.0</gml:pos></gml:origin><gml:offsetVector>0.016666666666666666 0.0</gml:offsetVector><gml:offsetVector>0.0 0.016666666666666666</gml:offsetVector>

Even though offset vector for y is positive because the origin is lower left this would appear to indicate a north up image. Is there a way for GDAL to support this DescribeCoverage response?

Thanks, Dave

[hsumanto]

I just encountered the exact same problem when trying access THREDDS WCS dataset using gdal_translate -of WCS wcs.xml dataset.tif

hsumanto@dev ~/enki/hsumanto_temporary $ gdal_translate -of WCS wcs.xml wcs.tif
ERROR 1: BBOX [144.496170150548,-38.4365222179274,144.496790965031,-38.4371430324099] minimum point larger than maximum point.
GDALOpen failed - 1
BBOX [144.496170150548,-38.4365222179274,144.496790965031,-38.4371430324099] minimum point larger than maximum point.

I am wondering if there has been progress made on this issue.

GDAL does in fact fetch the coverage description and added into wcs.xml but still not able to get geotiff file as the above error pops up.

[lpinner]

Same problem with this THREDDS WCS:

<WCS_GDAL>
  <ServiceURL>http://eos.ga.gov.au/thredds/wcs/LANDSAT/2008/10/LS7_ETM_NBAR_P54_GANBAR01-002_115_079_20081021_BX.nc?</ServiceURL>
  <CoverageName>Band4</CoverageName>
</WCS_GDAL>

[lhethert]

I'm encountering the same issue with this one:

<WCS_GDAL>

<ServiceUrl>​http://motherlode.ucar.edu:8080/thredds/wcs/galeon/testdata/RUC.nc?</ServiceUrl> <CoverageName>u_wind_height_above_ground</CoverageName>

</WCS_GDAL>

Are there any plans to resolve this in the near term?

[Jukka Rahkonen]

Most links in the ticket are dead but this one does answer:

​http://www.ngdc.noaa.gov/thredds/wcs/relief/ETOPO1/thredds/ETOPO1_Ice_g_gmt4.nc?service=WCS&version=1.0.0&request=DescribeCoverage&coverage=z

I feel that Frank was wrong 4 years ago when he wrote that

"y" offsetVector is 0 190.5 0 indicating a south up image.

If we look the rectified grid a bit wider we notice that the grid is defined to have origin at lower left corner and then positive y offset makes it north-up. I suppose that it is OK, but then the server should send image pixels in the same order from bottom to top and I doubt it really does that.

<origin>

<pos>-180.0 -90.0</pos>

</origin> <offsetVector>0.016666666666666666 0.0</offsetVector> <offsetVector>0.0 0.016666666666666666</offsetVector>

I feel also that the WCS in THREDDS is a disaster but project seems to be still alive ​https://github.com/Unidata/thredds.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.