<div dir="ltr"><br><div class="gmail_quote">On Mon, Oct 13, 2008 at 6:08 PM, Hamish <span dir="ltr"><<a href="mailto:hamish_b@yahoo.com" target="_blank">hamish_b@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Jamie Adams wrote:<br>
> In my case, the source GeoTiff had a geotransform of:<br>
> (-180.00000000012497, 0.0083333333333333297, 0.0, 90.0,<br>
> 0.0, -0.0083333333333333297)<br>
><br>
> One strange thing was, the original grass import (west coordinate of<br>
> 180E) had the same geotransform as the corrected raster I ran<br>
> r.region on.<br>
<br>
</div>It may have on the surface (ie what the program output reports: up to the<br>
programmer defined number of decimal places), but internally the stored<br>
value may be ever so slightly different.<br>
<br>
the actual value used for grass rasters is in $MAPSET/cellhd/$MAPNAME<br>
<br>
<br>
it is still not ok after r.region?</blockquote><div><br>My global 0.5 min grid is working, but I've discovered problems with other data sets<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
fyi, you can fix/reset the broken GeoTiff with gdal_translate -a_ullr</blockquote><div><br>Yes, I'm aware of that - just questioning what a broken file is (see below)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div><br>
<br>
> According to gdal, they were the same.</div></blockquote><div><br>Using python->gdal<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
<br>
</div>ie gdalinfo & <a href="http://r.info" target="_blank">r.info</a>? or python->gdal?<br>
<div><br>
> Looks like I need to file a bug report.</div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
<br>
</div>with QGIS?<br>
what is the problem besides a slightly-broken input file?</blockquote><div><br>I'm not sure why this is considered a broken input file. Yes it has a slight shift to the west, but all of the cell centers lie between 180w 90n 180e 90s. Yes, this amount of shift is trivial and can be easily fixed, but it could be considerably worse. Take for example some other raster data I have that is registered up to 180w, but has the pixel centers aligned to the grid (i think srtm is this way). I do a r.in.gdal, g.region rast=in.tif, r.out.gdal and end up with a completely different registration.<br>
<br>gdalinfo W180N10.tif<br><br>Driver: GTiff/GeoTIFF<br>Files: W180N10.tif<br>Size is 24001, 24001<br>Coordinate System is:<br>GEOGCS["WGS 84",<br> DATUM["WGS_1984",<br> SPHEROID["WGS 84",6378137,298.2572235630016,<br>
AUTHORITY["EPSG","7030"]],<br> AUTHORITY["EPSG","6326"]],<br> PRIMEM["Greenwich",0],<br> UNIT["degree",0.0174532925199433],<br> AUTHORITY["EPSG","4326"]]<br>
Origin = (-180.000416666999996,10.000416666700000)<br>Pixel Size = (0.000833333333333,-0.000833333333333)<br>Metadata:<br> AREA_OR_POINT=Area<br>Image Structure Metadata:<br> COMPRESSION=LZW<br> INTERLEAVE=BAND<br>Corner Coordinates:<br>
Upper Left (-180.0004167, 10.0004167) (180d 0'1.50"W, 10d 0'1.50"N)<br>Lower Left (-180.0004167, -10.0004167) (180d 0'1.50"W, 10d 0'1.50"S)<br>Upper Right (-159.9995833, 10.0004167) (159d59'58.50"W, 10d 0'1.50"N)<br>
Lower Right (-159.9995833, -10.0004167) (159d59'58.50"W, 10d 0'1.50"S)<br>Center (-170.0000000, 0.0000000) (170d 0'0.00"W, 0d 0'0.00"N)<br>Band 1 Block=24001x1 Type=Byte, ColorInterp=Gray<br>
<br>r.in.gdal input=W180N10.tif output=W180N10<br><br><a href="http://r.info" target="_blank">r.info</a> -g W180N10<br><br>north=10:00:01.5N<br>south=10:00:01.5S<br>east=159:59:58.500001W<br>west=179:59:58.499999E<br><br>
g.region rast=W180N10<br>
<br>r.out.gdal input=W180N10 output=W180N10_v2.tif<br><br>gdalinfo W180N10_v2.tif<br><br>Driver: GTiff/GeoTIFF<br>Files: gdalout.tif<br>Size is 24001, 24001<br>Coordinate System is:<br>GEOGCS["WGS 84",<br> DATUM["WGS_1984",<br>
SPHEROID["WGS 84",6378137,298.2572235630016,<br> AUTHORITY["EPSG","7030"]],<br> AUTHORITY["EPSG","6326"]],<br> PRIMEM["Greenwich",0],<br>
UNIT["degree",0.0174532925199433],<br> AUTHORITY["EPSG","4326"]]<br>Origin = (179.999583333055540,10.000416666666666)<br>Pixel Size = (0.000833333333333,-0.000833333333333)<br>Metadata:<br>
AREA_OR_POINT=Area<br>Image Structure Metadata:<br> INTERLEAVE=BAND<br>Corner Coordinates:<br>Upper Left ( 179.9995833, 10.0004167) (179d59'58.50"E, 10d 0'1.50"N)<br>Lower Left ( 179.9995833, -10.0004167) (179d59'58.50"E, 10d 0'1.50"S)<br>
Upper Right ( 200.000, 10.000) (200d 0'1.50"E, 10d 0'1.50"N)<br>Lower Right ( 200.000, -10.000) (200d 0'1.50"E, 10d 0'1.50"S)<br>Center ( 190.000, 0.000) (190d 0'0.00"E, 0d 0'0.01"N)<br>
<br>That seems like a GRASS, maybe GDAL issue. <br><br>-Jamie<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<font color="#888888"><br>
<br>
Hamish<br>
<br>
<br>
<br>
<br>
<br>
</font></blockquote></div><br></div>