[GRASSLIST:7465] "Illegal latitude" problem

GRASS GRASS user
,
1

Grasslist:

I've encountered a strange problem in r.in.gdal where I get the
following error:

"WARNING: G_set_window(): Illegal latitude for South"

What I did was:

"GRASS 6.0.0 (GL1KMWGS84):~/DATA/GL1KMWGS84/PERMANENT > r.in.gdal
-oe o10g out=o10g"

This is especially strange because I'm converting GLOBE DEM tiles,
four of which share the same south latitude, and no others produce
this error.

Here's the script I used to batch-convert:

"for all in `ls *.gz`
do
   gzip=`echo "$all"`
   out=`echo $gzip | cut -b1-4`

   gunzip $gzip

   r.in.gdal -oe $out out=$out

done"

...and progress reported:

"[...]Over-riding projection check.
Proceeding with import...
100%
CREATING SUPPORT FILES FOR m10g
Over-riding projection check.
Proceeding with import...
100%
CREATING SUPPORT FILES FOR n10g
Over-riding projection check.
Proceeding with import...
WARNING: G_set_window(): Illegal latitude for South
Over-riding projection check.
Proceeding with import...
100%
CREATING SUPPORT FILES FOR p10g"

I'm using Lorenzo Moretti's Grass 6.0.0-1 on OSX 10.3.9.

Incidentally, I got the same error for North latitude when trying to
convert the global GLCF SRTM-GTOPO30 mosaic (GeoTiff), as well as an
in-house global elevation grid (Arc/Info, not sure of original
source).

Has anyone seen this before and come-up with a fix?

Many thanks in advance,

Greg Booma
CIESIN - Columbia University

2

I've encountered a strange problem in r.in.gdal where I get the
following error:

"WARNING: G_set_window(): Illegal latitude for South"

What I did was:

"GRASS 6.0.0 (GL1KMWGS84):~/DATA/GL1KMWGS84/PERMANENT > r.in.gdal
-oe o10g out=o10g"

This is especially strange because I'm converting GLOBE DEM tiles,
four of which share the same south latitude, and no others produce
this error.

..

WARNING: G_set_window(): Illegal latitude for South

..

Incidentally, I got the same error for North latitude when trying to
convert the global GLCF SRTM-GTOPO30 mosaic (GeoTiff), as well as an
in-house global elevation grid (Arc/Info, not sure of original
source).

Has anyone seen this before and come-up with a fix?

Yes, this has been seen before, search the mailing list archives (both
the users and devel list, I can't remember which) for discussion on this
topic from the last month or two. (Specifically the SRTM-GTOPO30
datasets)

Not surprisingly, a GRASS lat/lon location won't let you set the
latitude bound higher than 90 degrees. These datasets will, for example,
have the top half of a 3" cell extend into the >90 degree territory.

GRASS measures the rasters' region bounds as the outer extent of the
boundary cells, not the value at the cell centers.

In my personal opinion, the datasets are broken in this case, not GRASS.
GRASS should be tolerant of floating point error taking the latitude
bound slightly beyond 90, but not accept half a cell's worth of error.

Work-around: import into a simple XY location, not a lat/lon location.
After cleaning the data (e.g. by chopping off the offending line of
data) you can copy the map into a lat/lon location.

Use gdalinfo to explore what the data bounds are.

Hamish

3

Quoting Hamish <hamish_nospam@yahoo.com>:

Work-around: import into a simple XY location, not a lat/lon
location.
After cleaning the data (e.g. by chopping off the offending line
of
data) you can copy the map into a lat/lon location.

Use gdalinfo to explore what the data bounds are.

Many thanks. Since the 'o10g' GLOBE tile only contains a few small
islands I was able to use r.patch to quickly fill missing land
area. I tried your suggestion with SRTM-GTOPO, though, and it went
smoothly. Cheers-