Thanks heaps for the reply and for clarifying - This is really about the notorious pixel vs grid line registration issue i.e. interpretation of pixels and great that it has been addressed.<div><br></div><div>Just one point of clarification, the new bounding box seems to have all corner values rounded to three decimal places. Do you think that is significant?</div>
<div><br></div><div>Anyway, I'll update our unit tests to take this into account.</div><div><br></div><div>Cheers and thanks</div><div>Ole <br><br><div class="gmail_quote">On Sat, Sep 3, 2011 at 5:30 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Le samedi 03 septembre 2011 12:23:55, Ole Nielsen a écrit :<br>
<div class="im">> Dear all!<br>
><br>
> This may be related to my recent posting about SetField behaving<br>
> differently in different gdal versions.<br>
> In any case I find that the bounding box of this test geotif<br>
</div>> file<<a href="http://www.keepandshare.com/doc/3116689/population-2010-clip-tif-septe" target="_blank">http://www.keepandshare.com/doc/3116689/population-2010-clip-tif-septe</a><br>
> mber-3-2011-5-20-pm-162k?da=y> is<br>
<div class="im">> different on the two installations (details below).<br>
><br>
> In brief, the bounding box using gdal 1.6 is<br>
><br>
> Upper Left ( 99.3641696, -0.0041806) ( 99d21'51.01"E, 0d 0'15.05"S)<br>
> Lower Left ( 99.3641696, -2.2031806) ( 99d21'51.01"E, 2d12'11.45"S)<br>
> Upper Right ( 102.2411696, -0.0041806) (102d14'28.21"E, 0d 0'15.05"S)<br>
> Lower Right ( 102.2411696, -2.2031806) (102d14'28.21"E, 2d12'11.45"S)<br>
> Center ( 100.8026696, -1.1036806) (100d48'9.61"E, 1d 6'13.25"S)<br>
><br>
><br>
> whereas using gdal 1.8 it is<br>
><br>
> Upper Left ( 99.3600000, 0.0000000) ( 99d21'36.00"E, 0d 0' 0.01"N)<br>
> Lower Left ( 99.3600000, -2.1990000) ( 99d21'36.00"E, 2d11'56.40"S)<br>
> Upper Right ( 102.2370000, 0.0000000) (102d14'13.20"E, 0d 0' 0.01"N)<br>
> Lower Right ( 102.2370000, -2.1990000) (102d14'13.20"E, 2d11'56.40"S)<br>
> Center ( 100.7985000, -1.0995000) (100d47'54.60"E, 1d 5'58.20"S)<br>
><br>
> It'd be great if someone can<br>
><br>
</div>> 1. Reproduce this using the test file (download using link above)<br>
> 2. Let us know which bounding box is correct<br>
> 3. Raise this as a ticket if it is a genuine bug<br>
<br>
Ole,<br>
<br>
I've not tried with your file but the output of gdalinfo is sufficient to explain<br>
the difference you see.<br>
<br>
It is due to a fix done in GDAL 1.8.0 that changes the way the<br>
AREA_OR_POINT=Point metadata is interpreted w.r.t geotransform.<br>
<br>
It is mentionned in the GDAL 1.8.0 NEWS :<br>
<br>
== Backward compatibility issues ==<br>
[...]<br>
* RFC 33 changes the way PixelIsPoint is handled for GeoTIFF (#3838,#3837)<br>
<br>
You will find more information here :<br>
<br>
<a href="http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint" target="_blank">http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint</a><br>
<br>
Best regards,<br>
<font color="#888888"><br>
Even<br>
</font></blockquote></div><br></div>