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

[Tim Beckmann]

Frank,

I understand.  I went through the same denial and some confusion several 
years ago when I first ran into the issue.

Unfortunately, feeding the -a_ullr parameter corner points based on 
pixel-is-area results in an output file only works properly if you want 
the output geotiff to be pixel-is-area.  We typically create geotiff files 
using pixel-is-point and don't really have the freedom to change that. So, 
I'll probably have to maintain my little hack separately until you "cave 
in and fix it" ;).

I guess another option might be to change things to feed it pixel-is-area 
corner points and change the hack to instead adjust the ModelTiePointTag 
values written by 0.5 pixels if the pixel-is-point metadata tag is set.  I 
think that would allow the rest of gdal to work as expected, but still 
produce an output geotiff with accurate data for the pixel-is-point case. 
(probably wouldn't work for reading that geotiff back into gdal though). 
If you wanted to include something like that in gdal, I could be convinced 
to create a patch for it.  Not a complete solution by any means, but 
perhaps a step in the right direction.

Thanks
Tim

--------------------------------------------------------------------------
Tim Beckmann
Software Project Lead
Science Applications International Corporation (SAIC)
Contractor to the USGS/EROS
Sioux Falls, SD 57198
605-594-2521    Phone
605-594-6940    Fax
tbeckman at usgs.gov




Frank Warmerdam <warmerdam at pobox.com> 
Sent by: Frank Warmerdam <fwarmerdam at gmail.com>
03/21/2006 03:28 PM

To
Tim Beckmann <tbeckman at usgs.gov>
cc
gdal-dev at lists.maptools.org
Subject
Re: [Gdal-dev] Mishandled "pixel is point" in geotiff






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