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'?
was an earlier version of gdalinfo able to read it?
can gmt's grdinfo say anything about it?
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
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!