[GRASS-user] Re: grass cell registration format

[Seb]

On Wed, 13 May 2009 00:35:28 -0700 (PDT),
Hamish <hamish_b at yahoo.com> wrote:

> Seb wrote:
>> What type of registration do GRASS raster cells use?

> cell, not grid.  see
> http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html

>> I'm trying to import several hundred rasters from GMT into GRASS,

> old GMT binary grid or new NetCDF GMT binary grid?

>> and the only way I managed to do it was by piping grd2xyz output
>> through r.in.xyz,

> did r.in.gdal not work? that should take care of the grid->cell
> registration region adjustments for you. (hopefully) does it segfault
> too?

>> as the Wiki recommendation to use r.in.bin failed with segmentation
>> fault (I think this is due to the GDAL packages in Debian sid, which
>> cannot read the GMT grids because gdalinfo shows that same segfault).

> weird, r.in.bin specifically does not use GDAL at all. did you convert
> to an old style GMT grid before trying 'r.in.bin -h'?

I had made a silly mistake in my script where grdreformat was failing to
convert to the old format, so r.in.bin failed too.  I've tried with it
now and it imports fine with: r.in.bin -hf grid.grd


> was an earlier version of gdalinfo able to read it?  can gmt's grdinfo
> say anything about it?

I've experienced this problem with GDAL in the past.  gdalinfo has been
segfaulting with all (new format) GMT grids in my Debian sid AMD64
system for more than a year.  I've also seen the problem with GDAL and
other netCDF files, but I haven't been able to properly track this down.
There's nothing wrong with the GMT grids, and grdinfo doesn't report
anything weird, and they also plot fine.  r.in.gdal also segfaults,
reinforcing my feeling this is related to GDAL (or its Debian packages).
I'd be interested to know whether you're able to import (new format) GMT
grids to GRASS with r.in.gdal, especially if you're in Debian.


>> One of my concerns with the pipe I described is that grd2xyz's output
>> corresponds to grid line registration, and I'm not sure this matches
>> what GRASS uses.  All of this happens in a lat/lon location.  Any
>> tips would be appreciated. Thanks.

> maybe the new XYZ import wiki page Markus just created can help?  it
> explains how to expand the region by half a cell outward to deal with
> the different registration method. (see also the r.region module)
> http://grass.osgeo.org/wiki/Import_XYZ

Thank you, this looks very helpful if I can't avoid piping via r.in.xyz!


Thanks,

-- 
Seb