[Gdal-dev] Mishandled "pixel is point" in geotiff

[Frank Warmerdam]

Tim Beckmann wrote:
> Hi all (and Frank),
> 
> I sent an email to the list a few weeks ago about geotiff files with the 
> "Pixel is point" option not being handled properly by gdal.  I only 
> received a reply from one person off the list stating that it was a known 
> problem. 
> 
> I did figure out how to pass the "-mo AREA_OR_POINT=POINT" parameter to 
> gdal_translate to tell it to include the pixel is point indication in the 
> output geotiff file.  So, my command line looks like:
> 
>         gdal_translate -mo AREA_OR_POINT=POINT -co INTERLEAVE=PIXEL \
>                 -a_srs "+proj=utm +zone=15 +datum=WGS84"  \
>                 -a_ullr 753600 3462900 801900 3260100 \
>                 'HDF4_SDS:UNKNOWN:"EO1H0220392005002110P0_HDF.L1T":0' 
> testit_b001.tif
> 
> This results in the geotiff file properly indicating "pixel is point". 
> However, the reported pixel size is incorrect.  It is being calculated 
> incorrectly from the provided corners like it was still "pixel is area" 
> (so instead of being 30 meters, it is just a little less than 30 meters). 
> The hack at the bottom of the email works around it by rescaling the pixel 
> size for the "pixel is point" case.  But it doesn't do anything for 
> properly fixing the issue throughout gdal... (but it looks like the "pixel 
> is point" support itself is a hack...)

Tim,

I'm not completely out of denial about PixelIsPoint.  At some point I will
finally cave in and fix it, but it will need to be addressed in a variety
of places in the software.  In the meantime you need to specify -a_ullr based
on the implicit pixel-is-area assumption of GDAL.

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 OSGF, http://osgeo.org