[GRASS-user] r.in.gdal global raster incorrect extents
Jamie Adams
jaadfoo at gmail.com
Mon Oct 13 21:57:59 EDT 2008
On Mon, Oct 13, 2008 at 6:08 PM, Hamish <hamish_b at yahoo.com> 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
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20081013/9b88e1d6/attachment.html
More information about the grass-user
mailing list