[GRASS-user] r.in.gdal global raster incorrect extents

Jamie_Adams · October 13, 2008, 7:41pm

Hello all,

When I import a global elevation dataset with extents 180w 90n 180e 90s using r.in.gdal, the GRASS raster shows up with w-e extents both showing 180E. While this doesn’t seem to be affecting raster calculations, afaik, it’s causing issues with QGIS. It displays it with it’s origin at 180E and extends to 540E. Has anyone run into this problem?

gdalinfo:

Driver: GTiff/GeoTIFF
Files: 2_00-res/out-2_00-nozero-res.tif
Size is 43200, 21600
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.000000000124970,90.000000000000000)
Pixel Size = (0.008333333333333,-0.008333333333333)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left (-180.0000000, 90.0000000) (180d 0’0.00"W, 90d 0’0.00"N)
Lower Left (-180.0000000, -90.0000000) (180d 0’0.00"W, 90d 0’0.00"S)
Upper Right ( 180.0000000, 90.0000000) (180d 0’0.00"E, 90d 0’0.00"N)
Lower Right ( 180.0000000, -90.0000000) (180d 0’0.00"E, 90d 0’0.00"S)
Center ( -0.0000000, 0.0000000) ( 0d 0’0.00"W, 0d 0’0.00"N)
Band 1 Block=43200x1 Type=Float32, ColorInterp=Gray
NoData Value=10

r.info:

Timestamp: none

Type of Map: raster Number of Categories: 255
Data Type: FCELL
Rows: 21600
Columns: 43200
Total Cells: 933120000
Projection: Latitude-Longitude
N: 90N S: 90S Res: 0:00:30
E: 180E W: 180E Res: 0:00:30
Range of data: min = -10814.000000 max = -0.010000

Data Description:
generated by r.in.gdal

Comments:
r.in.gdal input=“out-2_00-nozero-res.tif” output=“2_00_res”

±---------------------------------------------------------------------------+

Nikos_Alexandris1 · October 13, 2008, 8:35pm

On Mon, 2008-10-13 at 12:41 -0700, Jamie Adams wrote:

Hello all,

When I import a global elevation dataset with extents 180w 90n 180e
90s using r.in.gdal, the GRASS raster shows up with w-e extents both
showing 180E. While this doesn't seem to be affecting raster
calculations, afaik, it's causing issues with QGIS. It displays it
with it's origin at 180E and extends to 540E. Has anyone run into
this problem?

gdalinfo:

Driver: GTiff/GeoTIFF
Files: 2_00-res/out-2_00-nozero-res.tif
Size is 43200, 21600
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.000000000124970,90.000000000000000)
Pixel Size = (0.008333333333333,-0.008333333333333)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left (-180.0000000, 90.0000000) (180d 0'0.00"W, 90d 0'0.00"N)
Lower Left (-180.0000000, -90.0000000) (180d 0'0.00"W, 90d 0'0.00"S)
Upper Right ( 180.0000000, 90.0000000) (180d 0'0.00"E, 90d 0'0.00"N)
Lower Right ( 180.0000000, -90.0000000) (180d 0'0.00"E, 90d 0'0.00"S)
Center ( -0.0000000, 0.0000000) ( 0d 0'0.00"W, 0d 0'0.00"N)
Band 1 Block=43200x1 Type=Float32, ColorInterp=Gray
  NoData Value=10

r.info:

+----------------------------------------------------------------------------+
| Layer: 2_00_res Date: Fri Oct 10 17:45:37
2008
| Mapset: PERMANENT Login of Creator: jamie

| Location: Bathy

| DataBase: /work/grass

| Title: ( 2_00_res )

| Timestamp: none

|----------------------------------------------------------------------------
|

| Type of Map: raster Number of Categories: 255

| Data Type: FCELL

| Rows: 21600

| Columns: 43200

| Total Cells: 933120000

| Projection: Latitude-Longitude

| N: 90N S: 90S Res: 0:00:30

| E: 180E W: 180E Res: 0:00:30

| Range of data: min = -10814.000000 max = -0.010000

|

| Data Description:

| generated by r.in.gdal

|

| Comments:

| r.in.gdal input="out-2_00-nozero-res.tif" output="2_00_res"

|

+----------------------------------------------------------------------------+

1. I am not 100% sure but I think the line "Center ( -0.0000000,
0.0000000) ( 0d 0'0.00"W, 0d 0'0.00"N)" in the geo-metadata should
read enter ( 0.0000000, -0.0000000) ( 0d 0'0.00"W, 0d
0'0.00"N)

(Could it be that the file is not ok?)

2. What doeas g.region -p say? If you get the same value for east and
west it's wrong I guess. west should be, well... west: 180W and east:
180E.

3. Try to set "g.region e=180 s=-90 w=-180 n=90 -p". Re-import again and
check for errors.

Regards, Nikos

Jamie_Adams · October 13, 2008, 11:13pm

Thanks for the suggestions. I opened the image up in python using gdal, looked at the geotransform and found that the image is ever-so-slightly shifted west (-180.00000000012497). Hence the negative W-E center. Maybe this is why GRASS thinks it has a 180E origin also, though I don’t know.

I checked the region - same problem - then set it manually and re-imported. Same results. In the end I was able to assign correct extents using r.region. Though the boundary isn’t exactly at 180W, I think nine 0s after the decimal point is a bit much.

Thanks again.

-Jamie

On Mon, Oct 13, 2008 at 1:35 PM, Nikos Alexandris <nikos.alexandris@felis.uni-freiburg.de> wrote:

On Mon, 2008-10-13 at 12:41 -0700, Jamie Adams wrote:

Hello all,

When I import a global elevation dataset with extents 180w 90n 180e
90s using r.in.gdal, the GRASS raster shows up with w-e extents both
showing 180E. While this doesn’t seem to be affecting raster
calculations, afaik, it’s causing issues with QGIS. It displays it
with it’s origin at 180E and extends to 540E. Has anyone run into
this problem?

gdalinfo:

Driver: GTiff/GeoTIFF
Files: 2_00-res/out-2_00-nozero-res.tif
Size is 43200, 21600
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.000000000124970,90.000000000000000)
Pixel Size = (0.008333333333333,-0.008333333333333)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left (-180.0000000, 90.0000000) (180d 0’0.00"W, 90d 0’0.00"N)
Lower Left (-180.0000000, -90.0000000) (180d 0’0.00"W, 90d 0’0.00"S)
Upper Right ( 180.0000000, 90.0000000) (180d 0’0.00"E, 90d 0’0.00"N)
Lower Right ( 180.0000000, -90.0000000) (180d 0’0.00"E, 90d 0’0.00"S)
Center ( -0.0000000, 0.0000000) ( 0d 0’0.00"W, 0d 0’0.00"N)
Band 1 Block=43200x1 Type=Float32, ColorInterp=Gray
NoData Value=10

r.info:

±---------------------------------------------------------------------------+
| Layer: 2_00_res Date: Fri Oct 10 17:45:37
2008
| Mapset: PERMANENT Login of Creator: jamie

| Location: Bathy

| DataBase: /work/grass

| Title: ( 2_00_res )

| Timestamp: none

|----------------------------------------------------------------------------
|

| Type of Map: raster Number of Categories: 255

| Data Type: FCELL

| Rows: 21600

| Columns: 43200

| Total Cells: 933120000

| Projection: Latitude-Longitude

| N: 90N S: 90S Res: 0:00:30

| E: 180E W: 180E Res: 0:00:30

| Range of data: min = -10814.000000 max = -0.010000

|

| Data Description:

| generated by r.in.gdal

|

| Comments:

| r.in.gdal input=“out-2_00-nozero-res.tif” output=“2_00_res”

|

±---------------------------------------------------------------------------+

I am not 100% sure but I think the line “Center ( -0.0000000,
0.0000000) ( 0d 0’0.00"W, 0d 0’0.00"N)” in the geo-metadata should
read enter ( 0.0000000, -0.0000000) ( 0d 0’0.00"W, 0d
0’0.00"N)

(Could it be that the file is not ok?)

What doeas g.region -p say? If you get the same value for east and
west it’s wrong I guess. west should be, well… west: 180W and east:
180E.

Try to set “g.region e=180 s=-90 w=-180 n=90 -p”. Re-import again and
check for errors.

Regards, Nikos

Nikos_Alexandris1 · October 13, 2008, 11:18pm

On Mon, 2008-10-13 at 16:13 -0700, Jamie Adams wrote:

Thanks for the suggestions. I opened the image up in python using
gdal, looked at the geotransform and found that the image is
ever-so-slightly shifted west (-180.00000000012497). Hence the
negative W-E center. Maybe this is why GRASS thinks it has a 180E
origin also, though I don't know.

I checked the region - same problem - then set it manually and
re-imported. Same results. In the end I was able to assign correct
extents using r.region. Though the boundary isn't exactly at 180W, I
think nine 0s after the decimal point is a bit much.

Thanks again.

-Jamie

Jamie,

would you share some python command examples (using gdal)? I am learning
python stuff (although very slowly) and I would like to have some
examples as the one you did.

Thank you, Nikos

Jamie_Adams · October 13, 2008, 11:59pm

Sure, python w/ gdal is great for doing these sanity checks. Assuming you are using a FWTools install or have the python-gdal plugin:

python

import gdal

or newer version:

from osgeo import gdal

image = gdal.Open(‘/the/path/to/my/raster.tif’,gdal.GA_ReadOnly)

****or if your version of gdal has Grass support ****

image = gdal.Open(‘/grassdir/location/mapset/cellhd/rastername’,gdal.GA_ReadOnly)

image.GetGeoTransform()
(-180.0, 0.0083333333333333332, 0.0, 90.0, 0.0, -0.0083333333333333332)

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. According to gdal, they were the same.

Looks like I need to file a bug report.

Enjoy.

-Jamie

On Mon, Oct 13, 2008 at 4:18 PM, Nikos Alexandris <nikos.alexandris@felis.uni-freiburg.de> wrote:

On Mon, 2008-10-13 at 16:13 -0700, Jamie Adams wrote:

Thanks for the suggestions. I opened the image up in python using
gdal, looked at the geotransform and found that the image is
ever-so-slightly shifted west (-180.00000000012497). Hence the
negative W-E center. Maybe this is why GRASS thinks it has a 180E
origin also, though I don’t know.

I checked the region - same problem - then set it manually and
re-imported. Same results. In the end I was able to assign correct
extents using r.region. Though the boundary isn’t exactly at 180W, I
think nine 0s after the decimal point is a bit much.

Thanks again.

-Jamie

Jamie,

would you share some python command examples (using gdal)? I am learning
python stuff (although very slowly) and I would like to have some
examples as the one you did.

Thank you, Nikos

Nikos_Alexandris1 · October 14, 2008, 12:21am

On Mon, 2008-10-13 at 16:59 -0700, Jamie Adams wrote:

Sure, python w/ gdal is great for doing these sanity checks. Assuming
you are using a FWTools install or have the python-gdal plugin:

python

>>> import gdal

or newer version:
>>> from osgeo import gdal

>>> image = gdal.Open('/the/path/to/my/raster.tif',gdal.GA_ReadOnly)

****or if your version of gdal has Grass support ****
>>> image =
gdal.Open('/grassdir/location/mapset/cellhd/rastername',gdal.GA_ReadOnly)

>>> image.GetGeoTransform()
(-180.0, 0.0083333333333333332, 0.0, 90.0, 0.0,
-0.0083333333333333332)

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. According to gdal, they were the same.

Looks like I need to file a bug report.

Enjoy.

-Jamie

Great!! Thanks again, Nikos

Hamish · October 14, 2008, 1:08am

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?

fyi, you can fix/reset the broken GeoTiff with gdal_translate -a_ullr

According to gdal, they were the same.

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?

Hamish

Jamie_Adams · October 14, 2008, 1:57am

On Mon, Oct 13, 2008 at 6:08 PM, Hamish <hamish_b@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

Hamish · October 14, 2008, 4:45am

> 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)

...

My global 0.5 min grid is working, but I've discovered problems with
other data sets

Hamish:

> what is the problem besides a slightly-broken input file?

Jamie:

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

....

Origin = (-180.000416666999996,10.000416666700000)
Pixel Size = (0.000833333333333,-0.000833333333333)

note in this case the amount it exceeds 180 by is 1/2 the cell resolution.
i.e. the cells are centered on the grid lines. read about that here:
http://grass.osgeo.org/wiki/GRASS_raster_semantics
http://www.ngdc.noaa.gov/mgg/global/

Adjustments therefore need to be made so that coordinates refer to the
cell boundaries, not centers. For an idea how that is done, read through
the r.in.srtm script:
http://trac.osgeo.org/grass/browser/grass/trunk/scripts/r.in.srtm/r.in.srtm

So in this case, the SRTM tile is not broken, it is what it is and we
just have to process it correctly to compensate.

in your prior example though (-180.00000000012497, ...) the >180 error
is not due to grid vs. cell conventions (off by 1/2 a cell). It is much
more likely due to a loss of floating point precision in the program that
created it. Thus I call that one "broken". I don't think GDAL is to blame,
as for me GDAL reports the origin longitude cleanly. (see below).

What value gets stored in the $MAPSET/cellhd/ file for this image??

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

...

Origin = (179.999583333055540,10.000416666666666)
Pixel Size = (0.000833333333333,-0.000833333333333)

in the above the longitude is ok for at first, but then loses it for
the later digits: 179.999583333 055540.

To clean things up you might try the g.region -a flag. You may need to
double the resolution if that "rounds to whole numbers" and you want
the region to be "on the halves". [e.g. w=25 e=75 res=50 -a would "round"
outwards to w=0 e=100 res=50; it fails to notice the grid is already at
50m if the whole thing is offset. setting res=25 with -a avoids the 1/2
cell shift. you can set res back to 50 after the -a align step]

for a SRTMv2 tile I have here, it looks ok:
$ gdalinfo S46E170.hgt
....
Origin = (169.999583333333334,-44.999583333333334)
Pixel Size = (0.000833333333333,-0.000833333333333)

ie the origin longitude doesn't lose precision. (GDAL 1.5.0)

make sense?

Hamish

Hamish · October 14, 2008, 5:07am

> gdalinfo W180N10.tif
....
> Origin = (-180.000416666999996,10.000416666700000)
> Pixel Size = (0.000833333333333,-0.000833333333333)

Hamish:

note in this case the amount it exceeds 180 by is 1/2 the
cell resolution.

....

So in this case, the SRTM tile is not broken, it is what it
is and we just have to process it correctly to compensate.

oops, -180.000416666999996 is broken after all, "180.000416666 999996"

it seems that 180.000416667 is asked for more precision than it has.
(but it works fine )

I see that gdalinfo 1.5.2 uses %.15f:
printf( "Origin = (%.15f,%.15f)\n",
adfGeoTransform[0], adfGeoTransform[3] );

printf( "Pixel Size = (%.15f,%.15f)\n",
adfGeoTransform[1], adfGeoTransform[5] );

but why then does it work fine for me?
I downloaded a 180W tile, that looks fine too:
ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3/Australia/S20W180.hgt.zip
....
Origin = (-180.000416666666666,-18.999583333333334)
Pixel Size = (0.000833333333333,-0.000833333333333)

where do your .tif files come from?

(see also this discussion:
http://thread.gmane.org/gmane.comp.gis.grass.devel/29622/ )

Hamish

Jamie_Adams · October 14, 2008, 4:31pm

but why then does it work fine for me?
I downloaded a 180W tile, that looks fine too:
ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3/Australia/S20W180.hgt.zip
…
Origin = (-180.000416666666666,-18.999583333333334)

Pixel Size = (0.000833333333333,-0.000833333333333)

I grabbed the same tile and imported it into GRASS using r.in.srtm and am having the same issue:

gdalinfo S20W180.hgt

Origin = (-180.000416666666666,-18.999583333333334)
Pixel Size = (0.000833333333333,-0.000833333333333)

r.in.srtm input=S20W180 output=S20W180

cat /location/mapset/cellhd/S20W180

proj: 3
zone: 0
north: 18:59:58.5S
south: 20:00:01.5S
east: 178:59:58.5W
west: 179:59:58.5E
cols: 1201
rows: 1201
e-w resol: 0:00:03
n-s resol: 0:00:03
format: 3
compressed: 1

gdalinfo /location/mapset/cellhd/S20W180

Origin = (179.999583333333334,-18.999583333333334)
Pixel Size = (0.000833333333333,-0.000833333333333)

r.out.gdal outputs a GeoTiff consistent with this gdalinfo output - so shifted 180E.

where do your .tif files come from?

I wrote a python script that creates these as equal divisions of an input area (in this case the world). I wanted to use them along with srtm, so I used the same res and pixel registration scheme. I looked into it a bit further and noticed that my script is using a truncated version of the res variable (initialized to 1/1200):

geotransform:
(-180.000416667, 0.00083333333333299999, 0.0, 10.0004166667, 0.0, -0.00083333333333299999)

cat cellhd/W180N10

proj: 3
zone: 0
north: 10:00:01.5N
south: 10:00:01.5S
east: 159:59:58.500001W
west: 179:59:58.499999E
cols: 24001
rows: 24001
e-w resol: 0:00:03
n-s resol: 0:00:03
format: 0
compressed: 1

I fixed this and the precision issue went away. But as with the srtm tile, it doesn’t fix the e-w region issue.