[GRASS-user] Wrong projection info after importing Geotif

GRASS GRASS user
,
1

Hi!

I'm trying to import a geotif file
(http://user.uni-frankfurt.de/~grieser/downloads/NetPrimaryProduction/npp_CruP_All_fine_geo.zip)

I import the geotif file with:
  r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif
output=npp

and check the region:

alobo@alobo-laptop:~$ g.region rast=npp
alobo@alobo-laptop:~$ g.region -p

GRASS_INFO_ERROR(19559,1): region for current mapset is invalid

GRASS_INFO_ERROR(19559,1): line 9: <e-w resol: 0>

But, according to gdalinfo, the geotif file is correct:

$ gdalinfo npp.tif
Driver: GTiff/GeoTIFF
Files: npp.tif
Size is 1440, 572
Coordinate System is:
GEOGCS["WGS 84",
     DATUM["WGS_1984",
         SPHEROID["WGS 84",6378137,298.2572235629972,
             AUTHORITY["EPSG","7030"]],
         AUTHORITY["EPSG","6326"]],
     PRIMEM["Greenwich",0],
     UNIT["degree",0.0174532925199433],
     AUTHORITY["EPSG","4326"]]
Origin = (-180.000000000000000,85.000000000114397)
Pixel Size = (0.250000000000200,-0.250000000000200)
Metadata:
   AREA_OR_POINT=Area
Image Structure Metadata:
   INTERLEAVE=BAND
Corner Coordinates:
Upper Left (-180.0000000, 85.0000000) (180d 0'0.00"W, 85d 0'0.00"N)
Lower Left (-180.0000000, -58.0000000) (180d 0'0.00"W, 58d 0'0.00"S)
Upper Right ( 180.0000000, 85.0000000) (180d 0'0.00"E, 85d 0'0.00"N)
Lower Right ( 180.0000000, -58.0000000) (180d 0'0.00"E, 58d 0'0.00"S)
Center ( 0.0000000, 13.5000000) ( 0d 0'0.00"E, 13d30'0.00"N)
Band 1 Block=1440x1 Type=Float32, ColorInterp=Gray

Any help appreciated!
Thanks,

Agus

--
Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo@ija.csic.es
http://www.ija.csic.es/gt/obster

--
Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo@ija.csic.es
http://www.ija.csic.es/gt/obster

2

On Wed, Oct 22, 2008 at 10:34 AM, Agustin Lobo <aloboaleu@gmail.com> wrote:

Hi!

I'm trying to import a geotif file
(http://user.uni-frankfurt.de/~grieser/downloads/NetPrimaryProduction/npp_CruP_All_fine_geo.zip)

Note that the map exceeds South!

gdalinfo npp_CruP_All_fine_geo.tif
Driver: GTiff/GeoTIFF
Files: npp_CruP_All_fine_geo.tif
Size is 4320, 2160
Coordinate System is:
GEOGCS["WGS 84",
...
Metadata:
  AREA_OR_POINT=Area
...
Pixel Size = (0.083333333343262,-0.083333333343262)
...
Corner Coordinates:
Upper Left (-179.9583334, 89.9583333) (179d57'30.00"W, 89d57'30.00"N)
Lower Left (-179.9583334, -90.0416667) (179d57'30.00"W, 90d 2'30.00"S)
Upper Right ( 180.0416667, 89.9583333) (180d 2'30.00"E, 89d57'30.00"N)
Lower Right ( 180.0416667, -90.0416667) (180d 2'30.00"E, 90d 2'30.00"S)
Center ( 0.0416667, -0.0416667) ( 0d 2'30.00"E, 0d 2'30.00"S)
Band 1 Block=4320x1 Type=Byte, ColorInterp=Gray
  NoData Value=254
  Offset: 0, Scale:10.4598910148779

-> 90d 2'30.00"S does not quite exist.

Looking at North:

89.9583333+0.083333333343262

[1] 90.04167

I suspect a pixel-refers-to-center versus pixel-refers-to-corner bug in the
map.

I import the geotif file with:
r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif
output=npp

Here I get

GRASS 6.4.svn (latlong):~ > r.in.gdal npp_CruP_All_fine_geo.tif out=test
Projection of input dataset and current location appear to match
WARNING: Fixing subtle input data rounding error of south boundary
         (-0.0416667>4.62963e-07)
100%
<test> created
r.in.gdal complete.

-> South is "fixed" (not necessarily correct, though, see above).

GRASS 6.4.svn (latlong_tbe_climate):~ > g.region rast=test -p
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 89:57:30.000039N
south: 90S
west: 179:57:30.000077W
east: 179:57:29.999923W
nsres: 0:05:00.069477
ewres: 0
rows: 2159
cols: 4320
cells: 9326880

-> Global wrap around problem... due to the apparently shifted map:
179d57'30.00"W and 180d 2'30.00"E do not look right to me.

But, according to gdalinfo, the geotif file is correct:

$ gdalinfo npp.tif
Driver: GTiff/GeoTIFF
Files: npp.tif
Size is 1440, 572

...

You are looking at a different file here, comparing the size and the
coordinates.

The map in the ZIP file doesn't look properly positioned to me.
Subsequently GRASS fails.

Markus

3

Markus,

You are right that the file I'm using is not quite the
one of the link that I included in my message. I actually
passed that map to R, and just redifined:
>b <- npp_geotiff
>b@data$band1[b@data$band1 <0 ]<- 0

and then wrote b as npp.tif (I used QGIS manageR)

But I do not
think that this is a matter of concern. The point is that
the geographic info displayed by gdal for npp.tif is correct
(the "90d 2'30.00"S" problem is not in this file)
while the region set by grass from it with
g.region rast=npp.tif
is not.

I guess that the r.in.gdal I have is older (and wrong) than yours,
mine is the one in QGIS 1.0preview:
GRASS > g.version
GRASS 6.3.0 (2008)

Thus I don't think there is any way to solve this, except
installing a 6.4 version, import ant then copy to the LOCATIOn and mapset I would use with QGIS. Am I wrong?

Agus

Markus Neteler wrote:

On Wed, Oct 22, 2008 at 10:34 AM, Agustin Lobo <aloboaleu@gmail.com> wrote:

Hi!

I'm trying to import a geotif file
(http://user.uni-frankfurt.de/~grieser/downloads/NetPrimaryProduction/npp_CruP_All_fine_geo.zip)

Note that the map exceeds South!

gdalinfo npp_CruP_All_fine_geo.tif
Driver: GTiff/GeoTIFF
Files: npp_CruP_All_fine_geo.tif
Size is 4320, 2160
Coordinate System is:
GEOGCS["WGS 84",
...
Metadata:
  AREA_OR_POINT=Area
...
Pixel Size = (0.083333333343262,-0.083333333343262)
...
Corner Coordinates:
Upper Left (-179.9583334, 89.9583333) (179d57'30.00"W, 89d57'30.00"N)
Lower Left (-179.9583334, -90.0416667) (179d57'30.00"W, 90d 2'30.00"S)
Upper Right ( 180.0416667, 89.9583333) (180d 2'30.00"E, 89d57'30.00"N)
Lower Right ( 180.0416667, -90.0416667) (180d 2'30.00"E, 90d 2'30.00"S)
Center ( 0.0416667, -0.0416667) ( 0d 2'30.00"E, 0d 2'30.00"S)
Band 1 Block=4320x1 Type=Byte, ColorInterp=Gray
  NoData Value=254
  Offset: 0, Scale:10.4598910148779

-> 90d 2'30.00"S does not quite exist.

Looking at North:

89.9583333+0.083333333343262

[1] 90.04167

I suspect a pixel-refers-to-center versus pixel-refers-to-corner bug in the
map.

I import the geotif file with:
r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif
output=npp

Here I get

GRASS 6.4.svn (latlong):~ > r.in.gdal npp_CruP_All_fine_geo.tif out=test
Projection of input dataset and current location appear to match
WARNING: Fixing subtle input data rounding error of south boundary
         (-0.0416667>4.62963e-07)
100%
<test> created
r.in.gdal complete.

-> South is "fixed" (not necessarily correct, though, see above).

GRASS 6.4.svn (latlong_tbe_climate):~ > g.region rast=test -p
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 89:57:30.000039N
south: 90S
west: 179:57:30.000077W
east: 179:57:29.999923W
nsres: 0:05:00.069477
ewres: 0
rows: 2159
cols: 4320
cells: 9326880

-> Global wrap around problem... due to the apparently shifted map:
179d57'30.00"W and 180d 2'30.00"E do not look right to me.

But, according to gdalinfo, the geotif file is correct:

$ gdalinfo npp.tif
Driver: GTiff/GeoTIFF
Files: npp.tif
Size is 1440, 572

...

You are looking at a different file here, comparing the size and the
coordinates.

The map in the ZIP file doesn't look properly positioned to me.
Subsequently GRASS fails.

Markus

--
Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo@ija.csic.es
http://www.ija.csic.es/gt/obster

4

Agustin,

On Wed, Oct 22, 2008 at 8:19 PM, Agustin Lobo <aloboaleu@gmail.com> wrote:

Markus,

You are right that the file I'm using is not quite the
one of the link that I included in my message. I actually
passed that map to R, and just redifined:

b <- npp_geotiff
b@data$band1[b@data$band1 <0 ]<- 0

and then wrote b as npp.tif (I used QGIS manageR)

But I do not
think that this is a matter of concern. The point is that
the geographic info displayed by gdal for npp.tif is correct
(the "90d 2'30.00"S" problem is not in this file)

Can you please post this output, or, better, the npp.tif file?
It's hard to test without.

while the region set by grass from it with
g.region rast=npp.tif
is not.

I guess that the r.in.gdal I have is older (and wrong) than yours,

I don't think so (I am not aware of relevant changes).

mine is the one in QGIS 1.0preview:
GRASS > g.version
GRASS 6.3.0 (2008)

Thus I don't think there is any way to solve this, except
installing a 6.4 version, import ant then copy to the LOCATIOn and mapset I
would use with QGIS. Am I wrong?

Before doing that, let me try your file.

Markus

5

Markus,

Markus Neteler wrote:
.../...

But I do not
think that this is a matter of concern. The point is that
the geographic info displayed by gdal for npp.tif is correct
(the "90d 2'30.00"S" problem is not in this file)

Can you please post this output, or, better, the npp.tif file?
It's hard to test without.

The output is the one I had in my original message, I reproduce it here
and the file is at http://aloboaleu.googlepages.com/forMarkus
Thanks for your help!
Agus

$ gdalinfo npp.tif
Driver: GTiff/GeoTIFF
Files: npp.tif
Size is 1440, 572
Coordinate System is:
GEOGCS["WGS 84",
     DATUM["WGS_1984",
         SPHEROID["WGS 84",6378137,298.2572235629972,
             AUTHORITY["EPSG","7030"]],
         AUTHORITY["EPSG","6326"]],
     PRIMEM["Greenwich",0],
     UNIT["degree",0.0174532925199433],
     AUTHORITY["EPSG","4326"]]
Origin = (-180.000000000000000,85.000000000114397)
Pixel Size = (0.250000000000200,-0.250000000000200)
Metadata:
   AREA_OR_POINT=Area
Image Structure Metadata:
   INTERLEAVE=BAND
Corner Coordinates:
Upper Left (-180.0000000, 85.0000000) (180d 0'0.00"W, 85d 0'0.00"N)
Lower Left (-180.0000000, -58.0000000) (180d 0'0.00"W, 58d 0'0.00"S)
Upper Right ( 180.0000000, 85.0000000) (180d 0'0.00"E, 85d 0'0.00"N)
Lower Right ( 180.0000000, -58.0000000) (180d 0'0.00"E, 58d 0'0.00"S)
Center ( 0.0000000, 13.5000000) ( 0d 0'0.00"E, 13d30'0.00"N)

--
Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo@ija.csic.es
http://www.ija.csic.es/gt/obster

6

Agustin,

I could reproduce the problem...:

GRASS 6.4.svn (latlong_tbe_climate):~ > r.in.gdal npp.tif out=npp
ERROR: region for current mapset is invalid
       line 9: <e-w resol: 0>
       run "g.region"

# Now I reset the location which was still messed up from the previous
# try to import npp_CruP_All_fine_geo.tif:

GRASS 6.4.svn (latlong_tbe_climate):~ > g.region -dp
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 50N
south: 30N
west: 5E
east: 20E
nsres: 1
ewres: 1
rows: 20
cols: 15
cells: 300

# Voilà - the import works again:

GRASS 6.4.svn (latlong_tbe_climate):~ > r.in.gdal npp.tif out=npp
Projection of input dataset and current location appear to match
100%
<npp> created
r.in.gdal complete.

I assume that a 'g.region -d' which cure it also at your end.

Markus

7

Thanks Markus,
but this should not be the correct way for r.in.gdal to work,
should it? I mean that the default is reading the
the geotif with its own region, which should not
be interfered by the current region unless you use
the -o option. Am I wrong?

Anyway, my problem for applying your solution is
described in message http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html

(I set up the default region using qgis and, by some reason, was wrong
and cannot modify it)

Agus

Markus Neteler wrote:

Agustin,

I could reproduce the problem...:

GRASS 6.4.svn (latlong_tbe_climate):~ > r.in.gdal npp.tif out=npp
ERROR: region for current mapset is invalid
       line 9: <e-w resol: 0>
       run "g.region"

# Now I reset the location which was still messed up from the previous
# try to import npp_CruP_All_fine_geo.tif:

GRASS 6.4.svn (latlong_tbe_climate):~ > g.region -dp
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 50N
south: 30N
west: 5E
east: 20E
nsres: 1
ewres: 1
rows: 20
cols: 15
cells: 300

# Voilà - the import works again:

GRASS 6.4.svn (latlong_tbe_climate):~ > r.in.gdal npp.tif out=npp
Projection of input dataset and current location appear to match
100%
<npp> created
r.in.gdal complete.

I assume that a 'g.region -d' which cure it also at your end.

Markus

--
Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo@ija.csic.es
http://www.ija.csic.es/gt/obster

8

Agus,

On Sat, Oct 25, 2008 at 10:48 AM, Agustin Lobo <Agustin.Lobo@ija.csic.es> wrote:

Thanks Markus,
but this should not be the correct way for r.in.gdal to work,
should it? I mean that the default is reading the
the geotif with its own region, which should not
be interfered by the current region unless you use
the -o option. Am I wrong?

since I still don't know which steps you really did (apparently
you created the location from the GeoTIFF file?)
I don't know how to help. Maybe I just missed that.

Anyway, my problem for applying your solution is
described in message
http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html

(I set up the default region using qgis

OK, but in QGIS, what did you do to set up the default region?

and, by some reason, was wrong and cannot modify it)

To reproduce it, I would need the steps in a detailed way...
(say, due to work overload I am most motivated with the
full procedure :-).

Markus

9

Markus,

I made the mapset using the QGIS plugin Grass /New mapset.
I'm not sure if I made something wrong or it was a problem of
the plugin(I'll clarify this), but the fact is that I ended up with
this (wrong) region:
~$ g.region -p

GRASS_INFO_ERROR(9537,1): region for current mapset is invalid

GRASS_INFO_ERROR(9537,1): line 9: <e-w resol: 0>

GRASS_INFO_ERROR(9537,1): run "g.region"

First problem is that I cannot fix this region as explained in
http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html

Second problem is that I run r.in.gdal as I mentioned to import the file that I've put
in http://aloboaleu.googlepages.com/forMarkus
and get a wrong region for the raster as well:
r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif output=npp
~$ g.region rast=npp
~$ g.region -p

GRASS_INFO_ERROR(19559,1): region for current mapset is invalid

GRASS_INFO_ERROR(19559,1): line 9: <e-w resol: 0>

Nevertheless, according to gdalinfo, the geotif file is correct
(see my last message for the gdalinfo output).

  Probably, r.in.gdal would have worked fine if the default region had been correct, but this is no the point (I think). r.in.gdal should set the region for the raster according to the geotiff settings, which are correct.

So there is something wrong with r.in.gdal?

Thanks for your patience!

Agus

Markus Neteler wrote:

Agus,

On Sat, Oct 25, 2008 at 10:48 AM, Agustin Lobo <Agustin.Lobo@ija.csic.es> wrote:

Thanks Markus,
but this should not be the correct way for r.in.gdal to work,
should it? I mean that the default is reading the
the geotif with its own region, which should not
be interfered by the current region unless you use
the -o option. Am I wrong?

since I still don't know which steps you really did (apparently
you created the location from the GeoTIFF file?)
I don't know how to help. Maybe I just missed that.

Anyway, my problem for applying your solution is
described in message
http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html

(I set up the default region using qgis

OK, but in QGIS, what did you do to set up the default region?

and, by some reason, was wrong and cannot modify it)

To reproduce it, I would need the steps in a detailed way...
(say, due to work overload I am most motivated with the
full procedure :-).

Markus

--
Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo@ija.csic.es
http://www.ija.csic.es/gt/obster

10

Agus,

On Mon, Oct 27, 2008 at 10:17 PM, Agustin Lobo <Agustin.Lobo@ija.csic.es> wrote:

Markus,

I made the mapset using the QGIS plugin Grass /New mapset.
I'm not sure if I made something wrong or it was a problem of
the plugin(I'll clarify this), but the fact is that I ended up with
this (wrong) region:
~$ g.region -p

GRASS_INFO_ERROR(9537,1): region for current mapset is invalid

GRASS_INFO_ERROR(9537,1): line 9: <e-w resol: 0>

GRASS_INFO_ERROR(9537,1): run "g.region"

Yes (@devs: suggest the -d flag?)

First problem is that I cannot fix this region as explained in
http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html

If you looks closely, there was suggested:

g.region -d

Did you really run that (g.region set to default region)?
GRASS doesn't automatically recover from a illegal
region setting.

Then I suppose that it will work.

Markus

Second problem is that I run r.in.gdal as I mentioned to import the file
that I've put
in http://aloboaleu.googlepages.com/forMarkus
and get a wrong region for the raster as well:
r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif output=npp
~$ g.region rast=npp
~$ g.region -p

GRASS_INFO_ERROR(19559,1): region for current mapset is invalid

GRASS_INFO_ERROR(19559,1): line 9: <e-w resol: 0>

Nevertheless, according to gdalinfo, the geotif file is correct
(see my last message for the gdalinfo output).

Probably, r.in.gdal would have worked fine if the default region had been
correct, but this is no the point (I think). r.in.gdal should set the region
for the raster according to the geotiff settings, which are correct.

So there is something wrong with r.in.gdal?

Thanks for your patience!

Agus

Markus Neteler wrote:

Agus,

On Sat, Oct 25, 2008 at 10:48 AM, Agustin Lobo <Agustin.Lobo@ija.csic.es>
wrote:

Thanks Markus,
but this should not be the correct way for r.in.gdal to work,
should it? I mean that the default is reading the
the geotif with its own region, which should not
be interfered by the current region unless you use
the -o option. Am I wrong?

since I still don't know which steps you really did (apparently
you created the location from the GeoTIFF file?)
I don't know how to help. Maybe I just missed that.

Anyway, my problem for applying your solution is
described in message
http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html

(I set up the default region using qgis

OK, but in QGIS, what did you do to set up the default region?

and, by some reason, was wrong and cannot modify it)

To reproduce it, I would need the steps in a detailed way...
(say, due to work overload I am most motivated with the
full procedure :-).

Markus

--
Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo@ija.csic.es
http://www.ija.csic.es/gt/obster

--
Open Source Geospatial Foundation
http://www.osgeo.org/
http://www.grassbook.org/

11

Markus, I already did use -d, I copy the output below. But
the problem that worries me most is not that the default region
be wrong, but that r.in.gdal gets confused and interfered by
the default or active region while I think that the only geographic info that should
matter for r.in.gdal is the one in the geotiff file,
which is correct.

$ g.region -d
$ g.region -p
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 90N
south: 90S
west: 180E
east: 180E
nsres: 0:14:25.153538
ewres: 0:21:36
rows: 749
cols: 1000
cells: 749000
$ r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif output=npp

GRASS_INFO_MESSAGE(18845,1): Projection of input dataset and current location appear to match

$ g.region rast=npp
$ g.region -p

GRASS_INFO_ERROR(18874,1): region for current mapset is invalid

GRASS_INFO_ERROR(18874,1): line 9: <e-w resol: 0>

GRASS_INFO_ERROR(18874,1): run "g.region"

Thanks,
Agus

Markus Neteler wrote:

Agus,

On Mon, Oct 27, 2008 at 10:17 PM, Agustin Lobo <Agustin.Lobo@ija.csic.es> wrote:

Markus,

I made the mapset using the QGIS plugin Grass /New mapset.
I'm not sure if I made something wrong or it was a problem of
the plugin(I'll clarify this), but the fact is that I ended up with
this (wrong) region:
~$ g.region -p

GRASS_INFO_ERROR(9537,1): region for current mapset is invalid

GRASS_INFO_ERROR(9537,1): line 9: <e-w resol: 0>

GRASS_INFO_ERROR(9537,1): run "g.region"

Yes (@devs: suggest the -d flag?)

First problem is that I cannot fix this region as explained in
http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html

If you looks closely, there was suggested:

g.region -d

Did you really run that (g.region set to default region)?
GRASS doesn't automatically recover from a illegal
region setting.

Then I suppose that it will work.

Markus

Second problem is that I run r.in.gdal as I mentioned to import the file
that I've put
in http://aloboaleu.googlepages.com/forMarkus
and get a wrong region for the raster as well:
r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif output=npp
~$ g.region rast=npp
~$ g.region -p

GRASS_INFO_ERROR(19559,1): region for current mapset is invalid

GRASS_INFO_ERROR(19559,1): line 9: <e-w resol: 0>

Nevertheless, according to gdalinfo, the geotif file is correct
(see my last message for the gdalinfo output).

Probably, r.in.gdal would have worked fine if the default region had been
correct, but this is no the point (I think). r.in.gdal should set the region
for the raster according to the geotiff settings, which are correct.

So there is something wrong with r.in.gdal?

Thanks for your patience!

Agus

Markus Neteler wrote:

Agus,

On Sat, Oct 25, 2008 at 10:48 AM, Agustin Lobo <Agustin.Lobo@ija.csic.es>
wrote:

Thanks Markus,
but this should not be the correct way for r.in.gdal to work,
should it? I mean that the default is reading the
the geotif with its own region, which should not
be interfered by the current region unless you use
the -o option. Am I wrong?

since I still don't know which steps you really did (apparently
you created the location from the GeoTIFF file?)
I don't know how to help. Maybe I just missed that.

Anyway, my problem for applying your solution is
described in message
http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html

(I set up the default region using qgis

OK, but in QGIS, what did you do to set up the default region?

and, by some reason, was wrong and cannot modify it)

To reproduce it, I would need the steps in a detailed way...
(say, due to work overload I am most motivated with the
full procedure :-).

Markus

--
Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo@ija.csic.es
http://www.ija.csic.es/gt/obster

--
Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo@ija.csic.es
http://www.ija.csic.es/gt/obster

12

On Tue, Oct 28, 2008 at 9:28 AM, Agustin Lobo <Agustin.Lobo@ija.csic.es> wrote:

Markus, I already did use -d, I copy the output below. But
the problem that worries me most is not that the default region
be wrong, but that r.in.gdal gets confused and interfered by
the default or active region while I think that the only geographic info
that should
matter for r.in.gdal is the one in the geotiff file,
which is correct.

$ g.region -d
$ g.region -p
projection: 3 (Latitude-Longitude)
zone: 0
datum: wgs84
ellipsoid: wgs84
north: 90N
south: 90S
west: 180E <<-
east: 180E <<-

This is no good.
West should be 180W.

This means that the DEFAULT_WIND contains
bad data. How did you create the location (sorry I forgot).

Another magic could be to add -e to r.in.gdal below.
But it seems that the location definition is inappropriate.

Markus

nsres: 0:14:25.153538
ewres: 0:21:36
rows: 749
cols: 1000
cells: 749000
$ r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif
output=npp

GRASS_INFO_MESSAGE(18845,1): Projection of input dataset and current
location appear to match

$ g.region rast=npp
$ g.region -p

GRASS_INFO_ERROR(18874,1): region for current mapset is invalid

GRASS_INFO_ERROR(18874,1): line 9: <e-w resol: 0>

GRASS_INFO_ERROR(18874,1): run "g.region"

Thanks,
Agus

Markus Neteler wrote:

Agus,

On Mon, Oct 27, 2008 at 10:17 PM, Agustin Lobo <Agustin.Lobo@ija.csic.es>
wrote:

Markus,

I made the mapset using the QGIS plugin Grass /New mapset.
I'm not sure if I made something wrong or it was a problem of
the plugin(I'll clarify this), but the fact is that I ended up with
this (wrong) region:
~$ g.region -p

GRASS_INFO_ERROR(9537,1): region for current mapset is invalid

GRASS_INFO_ERROR(9537,1): line 9: <e-w resol: 0>

GRASS_INFO_ERROR(9537,1): run "g.region"

Yes (@devs: suggest the -d flag?)

First problem is that I cannot fix this region as explained in
http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html

If you looks closely, there was suggested:

g.region -d

Did you really run that (g.region set to default region)?
GRASS doesn't automatically recover from a illegal
region setting.

Then I suppose that it will work.

Markus

Second problem is that I run r.in.gdal as I mentioned to import the file
that I've put
in http://aloboaleu.googlepages.com/forMarkus
and get a wrong region for the raster as well:
r.in.gdal input=/media/mifat32/MASTER_ICTA2007_2008/2008b/npp.tif
output=npp
~$ g.region rast=npp
~$ g.region -p

GRASS_INFO_ERROR(19559,1): region for current mapset is invalid

GRASS_INFO_ERROR(19559,1): line 9: <e-w resol: 0>

Nevertheless, according to gdalinfo, the geotif file is correct
(see my last message for the gdalinfo output).

Probably, r.in.gdal would have worked fine if the default region had
been
correct, but this is no the point (I think). r.in.gdal should set the
region
for the raster according to the geotiff settings, which are correct.

So there is something wrong with r.in.gdal?

Thanks for your patience!

Agus

Markus Neteler wrote:

Agus,

On Sat, Oct 25, 2008 at 10:48 AM, Agustin Lobo
<Agustin.Lobo@ija.csic.es>
wrote:

Thanks Markus,
but this should not be the correct way for r.in.gdal to work,
should it? I mean that the default is reading the
the geotif with its own region, which should not
be interfered by the current region unless you use
the -o option. Am I wrong?

since I still don't know which steps you really did (apparently
you created the location from the GeoTIFF file?)
I don't know how to help. Maybe I just missed that.

Anyway, my problem for applying your solution is
described in message
http://lists.osgeo.org/pipermail/grass-user/2008-October/047198.html

(I set up the default region using qgis

OK, but in QGIS, what did you do to set up the default region?

and, by some reason, was wrong and cannot modify it)

To reproduce it, I would need the steps in a detailed way...
(say, due to work overload I am most motivated with the
full procedure :-).

Markus

--
Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo@ija.csic.es
http://www.ija.csic.es/gt/obster

--
Dr. Agustin Lobo
Institut de Ciencies de la Terra "Jaume Almera" (CSIC)
LLuis Sole Sabaris s/n
08028 Barcelona
Spain
Tel. 34 934095410
Fax. 34 934110012
email: Agustin.Lobo@ija.csic.es
http://www.ija.csic.es/gt/obster

--
Open Source Geospatial Foundation
http://www.osgeo.org/
http://www.grassbook.org/