[GRASS-dev] r.in.gdal problems

[Hamish]

Laura wrote:
> I imported a large SRTM grid with r.in.gdal;  when
> starting grass64 with this location there is an error.
> Some part of Grass seems to work despite this error, except
> d.rast shows a blank screen.  The east and west (see
> below)  have the same value, except E/W. Could this
> cause troubles?
> 
> GRASS 6.4.0RC4
> (northamericaSRTM3):~/gis/DATA/SRTM/SRTM-V2-frome0srp01u.ecs.nasa.gov/SRTM3/north_america
> > Error in startup script: divide by zero
>     while executing
> "expr round($parts(w)/$parts(ewres))*$parts(ewres)"
>     (procedure "MapCanvas::zoom_gregion" line
> 17)
>     invoked from within
> "MapCanvas::zoom_gregion $mon"
>     (procedure "MapCanvas::create" line 40)
>     invoked from within
> "MapCanvas::create"
>     (procedure "Gm::startmon" line 11)
>     invoked from within
> "Gm::startmon"
>     (procedure "Gm::create" line 79)
>     invoked from within
> "Gm::create"
>     (procedure "main" line 30)
>     invoked from within
> "main $argc $argv"
>     (file
> "/usr/local/grass/grass-6.4.0RC4/etc/gm/gm.tcl" line 566)


note that the tcl/tk gis.m GUI has some problems with lat/lon
zooming at global scales. I've tried to fix it a little in RC5
but it is still not done. the library and d.* module end of
things are fine, and now the cosmetic on-screen stuff is fine,
but the middle GIS.m tcl code is a mess. I can't put any more
time into that right now, but I'd hate to see 6.4.0final release
with it so broken...

see http://trac.osgeo.org/grass/ticket/608

... for now you might have better luck working with the d.mon
XDRIVER windows, which will be a bit more error tolerant.


> GRASS 6.4.0RC4
> (northamericaSRTM3):~/gis/DATA/SRTM/SRTM-V2-frome0srp01u.ecs.nasa.gov/SRTM3/north_america

does it really extend from 180 lon to 180 lon? (ie include asia)


> > g.region -p
> projection: 3 (Latitude-Longitude)
> zone:       0
> datum:      wgs84
> ellipsoid:  wgs84
> north:      61:00:01.5N
> south:      9:59:58.5N
> west:       179:59:58.5E
> east:       179:59:58.5W
> nsres:      0:00:03
> ewres:      0:00:00.000007
> rows:       61201
> cols:       432001
> cells:      26438893201


what it has done is to squeeze all the east-west data into a
tiny strip along the date line! note the ewres value.

try fixing the map's bounds with r.region.

it should accept -180 to 360 for longitude, so maybe you can
figure out for to fit it in that range.

due to the grid vs cell center registration difference between
srtm tiles and grass's raster maps I think it is normal that
the cell edges seem to hang 1/2 a cell beyond exact round
numbers.



Hamish