On Mon, Oct 13, 2008 at 6:08 PM, Hamish <[EMAIL PROTECTED]> wrote: > Jamie Adams wrote: > > In my case, the source GeoTiff had a geotransform of: > > (-180.00000000012497, 0.0083333333333333297, 0.0, 90.0, > > 0.0, -0.0083333333333333297) > > > > One strange thing was, the original grass import (west coordinate of > > 180E) had the same geotransform as the corrected raster I ran > > r.region on. > > It may have on the surface (ie what the program output reports: up to the > programmer defined number of decimal places), but internally the stored > value may be ever so slightly different. > > the actual value used for grass rasters is in $MAPSET/cellhd/$MAPNAME > > > it is still not ok after r.region?
My global 0.5 min grid is working, but I've discovered problems with other data sets > > > fyi, you can fix/reset the broken GeoTiff with gdal_translate -a_ullr Yes, I'm aware of that - just questioning what a broken file is (see below) > > > > > According to gdal, they were the same. > Using python->gdal > > > ie gdalinfo & r.info? or python->gdal? > > > Looks like I need to file a bug report. > > > with QGIS? > what is the problem besides a slightly-broken input file? 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. gdalinfo W180N10.tif Driver: GTiff/GeoTIFF Files: W180N10.tif Size is 24001, 24001 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.2572235630016, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (-180.000416666999996,10.000416666700000) Pixel Size = (0.000833333333333,-0.000833333333333) Metadata: AREA_OR_POINT=Area Image Structure Metadata: COMPRESSION=LZW INTERLEAVE=BAND Corner Coordinates: Upper Left (-180.0004167, 10.0004167) (180d 0'1.50"W, 10d 0'1.50"N) Lower Left (-180.0004167, -10.0004167) (180d 0'1.50"W, 10d 0'1.50"S) Upper Right (-159.9995833, 10.0004167) (159d59'58.50"W, 10d 0'1.50"N) Lower Right (-159.9995833, -10.0004167) (159d59'58.50"W, 10d 0'1.50"S) Center (-170.0000000, 0.0000000) (170d 0'0.00"W, 0d 0'0.00"N) Band 1 Block=24001x1 Type=Byte, ColorInterp=Gray r.in.gdal input=W180N10.tif output=W180N10 r.info -g W180N10 north=10:00:01.5N south=10:00:01.5S east=159:59:58.500001W west=179:59:58.499999E g.region rast=W180N10 r.out.gdal input=W180N10 output=W180N10_v2.tif gdalinfo W180N10_v2.tif Driver: GTiff/GeoTIFF Files: gdalout.tif Size is 24001, 24001 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.2572235630016, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (179.999583333055540,10.000416666666666) Pixel Size = (0.000833333333333,-0.000833333333333) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 179.9995833, 10.0004167) (179d59'58.50"E, 10d 0'1.50"N) Lower Left ( 179.9995833, -10.0004167) (179d59'58.50"E, 10d 0'1.50"S) Upper Right ( 200.000, 10.000) (200d 0'1.50"E, 10d 0'1.50"N) Lower Right ( 200.000, -10.000) (200d 0'1.50"E, 10d 0'1.50"S) Center ( 190.000, 0.000) (190d 0'0.00"E, 0d 0'0.01"N) That seems like a GRASS, maybe GDAL issue. -Jamie > > > > Hamish > > > > > >
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user