[gdal-dev] GDAL WCS driver

[Even Rouault]

> Shouldn't it be able to retain this information?  As it is, clients won't
> be able to utilize the Alpha channel.  It looks like it's thrown away in
> the inforation being cached in the <WCS_GDAL> file:
> 
>   <PreferredFormat>GeoTIFF</PreferredFormat>
>   <BandCount>4</BandCount>
>   <BandType>Byte</BandType>
> 
> There's no band description other than the count and data type and
> it doesn't attempt to retain the 2x2 sample GeoTIFF image, which is
> relatively small.

Patch welcome :-)

> 
> There's also an oddity with the sample image requested.  The request from
> GDAL in my http log is:
> 
> base_url?datastore=cwtile&SERVICE=WCS&VERSION=1.0.0&REQUEST=GetCoverage&COV
> ERAGE=terrapixel&FORMAT=GeoTIFF&BBOX=260489,3667254,260490,3667255&WIDTH=2&
> HEIGHT=2&CRS=EPSG:26915
> 
> As you can see in the gdalinfo of the WCS itself, the pixel resolution
> is 0.5m, but this request is for 1.0m, since WCS BBOX= coordinates use
> pixel-is-point sematics rather than pixel-is-area, this is requesting a
> different resolution from the native resolution and is going outside of
> the source-data area, which is advertised in the WCS DescribeCoverage as:
> 
> <gml:Envelope srsName="EPSG:26915">
>   <gml:pos dimension="2">260489.25 3652963.25</gml:pos>
>   <gml:pos dimension="2">313516.75 3667254.75</gml:pos>
> </gml:Envelope>

Jukka gave the answer, and my quick look at the code confirms it. See the 
following comments in WCSDataset::GetCoverage() implementation :

// WCS 1.0 extents are the outer edges of outer pixels.
// WCS 1.1 extents are centers of outer pixels.

I cannot really comment on the correctness of this, but the arguments given by 
Jukka make sense to me. In WCS 1.0, as there was no precise definition of what 
the request extents really mean, some WCS servers have taken the "classic" 
pixel-is-area approach.

I've indeed seen this in mapwcs.c implementation of MapServer :

        /* NOTE: WCS 1.1 boundingbox is center of pixel oriented, not edge
           like in WCS 1.0.  So bbox semantics are wonky till this is fixed
           later in the GetCoverage processing. */
        params->bbox.minx = atof(tokens[0]);
        params->bbox.miny = atof(tokens[1]);
        params->bbox.maxx = atof(tokens[2]);
        params->bbox.maxy = atof(tokens[3]);

and later :

    /* WCS 1.1 boundbox is center of pixel oriented. */
    if( strncasecmp(params->version,"1.1",3) == 0 ) {
      params->bbox.minx += cm->geotransform[1]/2 + cm->geotransform[2]/2;
      params->bbox.maxx -= cm->geotransform[1]/2 + cm->geotransform[2]/2;
      params->bbox.maxy += cm->geotransform[4]/2 + cm->geotransform[5]/2;
      params->bbox.miny -= cm->geotransform[4]/2 + cm->geotransform[5]/2;
    }

> 
> The gdalinfo interprets this (and the equivalent <RectifiedGrid>)
> information from the WCS correctly with the pixel-is-point semantic and
> converts it properly to GDAL's pixel-is-area semantic and displays:

Yes indeed, I can see that GDALParseGMLCoverage() converts from pixel-is-point 
semantic to pixel-is-area semantic, which is a bit inconsistant with what has 
been seen above with the logic of WCS 1.0.

I'm not familiar enough with MapServer code to be 100% sure, but my 
understanding of the code that generates RectifiedGrid would be that it uses 
pixel-is-area convention for WCS 1.0, so there might be an inconsistency there 
with what GDAL WCS 1.0 client expecs (and I'm not sure if the bug would belong 
in GDAL or MapServer...)

Best regards,

Even