Opened 12 years ago

Closed 12 years ago

Last modified 8 years ago

#3090 closed defect (wontfix)

GDAL WCS driver can't open this service

Reported by: gaopeng Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.6.1
Severity: normal Keywords: WCS
Cc: Kyle Shannon

Change History (7)

comment:1 Changed 12 years ago by warmerdam

Owner: changed from warmderdam to warmerdam

comment:2 Changed 12 years ago by warmerdam

Status: newassigned


What XML control file do you use for this service?

comment:3 Changed 12 years ago by Kyle Shannon

Cc: Kyle Shannon added

comment:4 Changed 12 years ago by warmerdam

I tried investigating this service a bit, and issued:

but in response I got:

<?xml version="1.0" encoding="UTF-8"?>

<ServiceExceptionReport xmlns="" version="1.2.0">

  <ServiceException>Failed to open dataset, [/fmrc/NCEP/GFS/Alaska_191km/runs/NCEP-GFS-Alaska_191km_RUN_2009-07-28T12:00:00Z].</ServiceException>


I'm not sure if the old file is just no longer available, or if I am doing something wrong but there isn't much I can do about this ticket currently.

comment:5 Changed 12 years ago by gaopeng

Frank, The following is the XML control file used:


I looked at the return of DescribeCoverage?, listed below. I think the problem is the special SRS, "EPSG:-3[Stereographic]".

- <spatialDomain>
- <EnvelopeWithTimePeriod srsName="urn:ogc:def:crs:OGC:1.3:CRS84">
  <gml:pos dimension="2">114.61043998234297 18.285366597346187</gml:pos> 
  <gml:pos dimension="2">360.0 90.0</gml:pos> 
- <gml:RectifiedGrid srsName="EPSG:-3[Stereographic]" dimension="3">
- <gml:limits>
- <gml:GridEnvelope>
  <gml:low>0 0 0</gml:low> 
  <gml:high>44 38 3</gml:high> 
- <gml:origin>
  <gml:pos>-4952.874701817127 -6857.989752814494 850.0</gml:pos> 
  <gml:offsetVector>190.5 0.0 0.0</gml:offsetVector> 
  <gml:offsetVector>0.0 190.5 0.0</gml:offsetVector> 
  <gml:offsetVector>0.0 0.0 -200.0</gml:offsetVector> 
- <temporalDomain>
- <rangeSet>
- <RangeSet>
  <description xmlns="">Absolute_vorticity 1/s true Absolute_vorticity @ isobaric</description> 
  <label>Absolute_vorticity @ isobaric</label> 
- <axisDescription>
- <AxisDescription>
- <values>
- <nullValues>
- <supportedCRSs>
- <supportedFormats>
- <supportedInterpolations>

comment:6 Changed 12 years ago by warmerdam

Resolution: wontfix
Status: assignedclosed

I discovered that OGC:CRS84 was not being interpreted, and I have fixed this in trunk (r18544). However, it is not clear this was important. I was still getting this error:

<ServiceException? code="InvalidParameterValue?" locator="BBOX">BBOX [-5048.12470181713,-6572.23975281449,-4667.12470181713,-6953.23975281449] minimum point larger than maximum point.</ServiceException?>

Looking at the offset/vector from the RectifiedGrid? description I noticed things were 3D:

            <pos>-4952.874701817127 -6857.989752814494 850.0</pos>
          <offsetVector>190.5 0.0 0.0</offsetVector>
          <offsetVector>0.0 190.5 0.0</offsetVector>
          <offsetVector>0.0 0.0 -200.0</offsetVector>

so I tried a 3D BBOX but got an error indicating only 2D is allowed. The 2nd offset vector is normally negative in Y, but not for this server. This results in the first Y value in the BBOX being greater than the second as the BBOX is explicitly supposed to be lower left, upper right (not minx,miny,maxx,maxy), a point made clear in the specification OGC 05-076 Nevertheless, I tried switching the Y values and got somewhat further:

<ServiceException? code="InvalidParameterValue?" locator="CRS">Request CRS [EPSG:4326] not allowed [OGC:CRS84].</ServiceException?>

I'm not sure why the request is being made in EPSG:4326 instead of the SRS of the rectified grid (EPSG:-3[Stereographic]) so I tried using that as the SRS, but I got a similar error. It appears the only coordinate system allowed is OGC:CRS84 even though that is not the SRS in which the grid is described. I tried that with a BBOX in lat/long and adding a TIME parameter in the area and it worked to some extent. It produced a GeoTIFF file, but the georeferencing of that file was pretty screwy:,19,122,21&WIDTH=2&HEIGHT=2&CRS=OGC:CRS84

   Version: 1
   Key_Revision: 1.0
      ModelTiepointTag (2,3):
         0                0                0                
         -4952874.7018171310.2471855061594 0                
      ModelPixelScaleTag (1,3):
         0                190500           0                
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GeographicTypeGeoKey (Short,1): GCS_WGS_84
      ProjectedCSTypeGeoKey (Short,1): User-Defined
      PCSCitationGeoKey (Ascii,7): "Snyder"
      ProjectionGeoKey (Short,1): User-Defined
      ProjLinearUnitsGeoKey (Short,1): Linear_Meter
      ProjCoordTransGeoKey (Short,1): CT_Stereographic
      ProjCenterLongGeoKey (Double,1): 0                
      ProjNatOriginLatGeoKey (Double,1): 90               
      ProjScaleAtNatOriginGeoKey (Double,1): 1                
      ProjFalseEastingGeoKey (Double,1): 0                
      ProjFalseNorthingGeoKey (Double,1): 0                

In particular the 0 for ModelPixelScaleTag? makes the file degenerate. Also, oddly the file was returned in a sort of Polar Stereographic, instead of the CRS84 geographic coordinate system requested. At this point I'm reasonably convinced that the service is non-standard in so many ways that it would be damaging to the WCS driver to try and make it work with this service.

I don't think there is much else to do, unless there is a contact at ucar who would like to defend the compliance of this service.

comment:7 Changed 8 years ago by Even Rouault

Milestone: 1.6.4

Milestone 1.6.4 deleted

Note: See TracTickets for help on using tickets.