On Sun, 6 Mar 2005, David Adam wrote:
Hamish wrote:
>>I'm trying to set up a region, starting with a Landsat TIFF
>>image from California. I have imported the region with r.in.gdal,
>>which produces a large file. I then close grass60 and reopen in the
>>new location, at which point I get the errors
>>
>>
>>GRASS_INFO_ERROR(5579,1): default region is invalid
>>GRASS_INFO_ERROR(5579,1): line 15: <depths: -1074916636>
>>
>>The relevant file for the region is
>>
>>DEFAULT_WIND --
>>
>>proj: 99
>>zone: 0
>>north: 213720.89780907
>>south: -6149.10219093
>>east: -168613.96484194
>>west: -404623.96484194
>>cols: 7867
>>rows: 7329
>>e-w resol: 30
>>n-s resol: 30
>>top: 1
>>bottom: 0
>>cols3: 7867
>>rows3: 7329
>>depths: -1074916636
>>e-w resol3: 30
>>n-s resol3: 30
>>t-b resol: 1
>>
>>--------------
>>
>>Most of the fields in the file are explained in the REGION section
>>of the manual, but I can't seem to find anyplace that defines or
>>explains what the "depths" field is about. But until I can get
>>grass to accept the region, I can't do much of anything.
>>
>>All help is much appreciated...
>>
>>
>
>
>rows,cols, and res=30 all look right. I don't know what is causing the
>depths to go nuts. Try editing the "WIND" file in your mapset to make
>depths: 1?
>
>
>maybe this works as a temporary workaround--
>
>try viewing the GeoTIFF meta-data with "gdalinfo".
>
>If the meta-data is bogus, wipe it clean with:
>
>tifftopnm map.tiff | pnmtotiff > map_clean.tiff
>
>
>This will wipe all geo-coding, but you should be able to load into a X,Y
>location ok and at least view the data. May rectify from there.
>
>
>
>Hamish
>
>
>
>
Thanks, I'll give that a try.
In response to another reply, this is happening under Grass6.0.0beta2.
But one of my questions still stands: What does depth represent? The
other terms in the
DEFAULT_WIND file are defined in the g.region documentation, but not
depth. If I knew
what it stands for, perhaps I could guess the right value.
This seems to be another side-effect of the precipitate introduction of 3D
windows in 6.0.0beta*. The code seems to be in lib/gis/adj_cellhd.c, about
line 249 - it may not be, because working out what is going on is far from
easy. r.in.gdal seems not to write a depth (about raster/r.in.gdal/main.c
line 227 and following). So the next operation to access the data tries to
make one, and:
if (!depth_flag)
{
cellhd->depths = (cellhd->top - cellhd->bottom + cellhd->tb_res/2.0) /
cellhd->tb_res;
if (cellhd->depths < 0)
cellhd->depths = 1;
}
says:
(1 - 0 + (1/2)) / 1
[1] 1.5
for this data. But while top, bottom and tb_res are double, depths is
integer, and the printed output looks very much like an integer that has
fallen over the edge. But maybe the functions called don't visit
G_adjust_Cell_head3(), just something else?
It would be really nice if we had a fixed set of operations that a release
candidate had to pass before changes were introduced and made available to
non-developers.
Roger
Thanks for the help!
david
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no