[Gdal-dev] Does gdalinfo Bounding Box Information really match DTED / SRTM ?

[Frank Warmerdam]

Michael84 wrote:
> I use gdalinfo to extract bounding box information of DTED L0&L1 (dt0, dt1)
> as well as SRTM (hgt over bil+hdr+proj solution) data.
> In both cases the reported corner points are not integer values as supposed. 
> 
> Corner Coordinates: (DTED)
> Upper Left  (  -0.0041667,  49.0041667) (  0d 0'15.00"W, 49d 0'15.00"N)
> Lower Left  (  -0.0041667,  47.9958333) (  0d 0'15.00"W, 47d59'45.00"N)
> Upper Right (   1.0041667,  49.0041667) (  1d 0'15.00"E, 49d 0'15.00"N)
> Lower Right (   1.0041667,  47.9958333) (  1d 0'15.00"E, 47d59'45.00"N)
> Center      (   0.5000000,  48.5000000) (  0d30'0.00"E, 48d30'0.00"N)
> 
> Is this is a roundig bug of gdal or are the data sources just coded like
> this ?

Michael,

GDAL treats pixels are representing an area, and the bounds of a raster
are the bounds of the outer edges of the pixel region.

DTEDs however are normally thought of as samples at points (with a pixel
sometimes drawn around that point to represent it).  When thought of as
point data DTED corners are right on 1 degree cell boundaries.

So this is the class "pixel as area" vs. "pixel as point" discrepency
which results in an off-by-one-half-pixel difference under various
circumstances.

So, there is no bug, only differences in interpretation of what the
bounds of a raster are.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org