[GRASS-user] flip raster

[Hamish]

Barry Eakins wrote:
> We've looked into this issue and the problem lies in how GMT v.4.3,
> which was used to create ETOPO1, and GDAL read and write netcdf grids.

> Both purport to handle netcdf COORDS-compliant grids though there is
> clearly a problem with one of these applications (the vertical flipping);
> the GDAL community forum has apparently already discussed this issue.
> We're working on a temporary solution, such as publishing an older "GMT
> 3.0" netcdf grid along with the current one that GDAL doesn't read
> properly. GDAL does read the older netcdf grid without problem.

um, about that "read without problem" .. FYI I had found an odd error with
the Smith & Sandwell 1' dataset (v10.1) in the older GMT format. As far
as I could determine the old GMT grd format introduced a floating point
+0.005 elevation shift error in th data. Minor, but uninvited so worth
investigating. (this is using GMT tools for Debian Etch; not sure if it's
a GMT processing bug or something deeper?)

see  http://grass.osgeo.org/wiki/Marine_Science#Bathymetric_data

my other problem with that dataset (and the focus of the above link) is
the rather vague map projection definition given, and struggles with
understanding the projection used with GMT's img2grd program.
(I haven't checked the new S&S 1' v11.1 dataset; there's no readme or log)
Earlier today on the PROJ.4 mailing list I got a chuckle to read the
phrase "geodetic abomination" be used in reference to using the mercator
projection on a sphere and then trying to tie it back to WGS84.

that's not your problem, just something to be aware of.


> I hope to have something up on our web site by next week.
> 
> One question that I have: "Is there another file format for the ETOPO1
> grids that would be of more use to the GRASS community than netcdf?"

As Glynn noted, GRASS relies primarily on GDAL for importing raster data,
but we also have a r.in.bin module which reads raw binary blocks. This
is what we've used in the past to import ETOPO2 and ETOPO5 without any
problem at all.

see  http://grass.osgeo.org/wiki/Global_datasets#ETOPO1


> We could host something such as geotiffs of the grids, which we can
> create easily, but I'm not a GRASS user so don't know what grid/raster
> file format would be easiest to import into GRASS.

r.in.gdal and r.in.bin cover most file formats rather well, so there's
not one single format to recommend. just a few lossy ones to avoid.


> I've also never used QGIS.

It also heavily relies on GDAL for data import/export, but with less
flexible options. GeoTiff is probably a safe bet for them.
One thing it is rather good at is quickly loading/previewing large
Geotiffs which bring your standard image viewer or paint program to its
knees, without the overhead and effort of a big GIS suite.

 
> P.S. Sorry about the grid- v. cell-registered grids being a
> pain, there really is an important difference between the two.

The cell registered version of ETOPO1 is trivial to import into GRASS,
but what motivated me to attempt to shoehorn in the grid-registed version
as chronicled in the above Global_datasets#ETOPO1 wiki page was - "The
grid-registered is the authoritative registration for each version. The
cell-registered was derived from the grid-registered version and the
conversion produces slightly flattened relief." comment on the NGDC site.

I take that to mean it takes an average of the 4 grid points at each of
the cell's corners?

The specific problem with working with global grid registered data in
GRASS is that lat/lon projects can not have bounds which exceed 90.0 deg
N,S. 



Here's another method to flip the data once it's in GRASS:
after loading the flipped raster in GDAL/GRASS export it from GRASS to
Matlab (or Octave if you prefer) with the r.out.mat module, run
flipud(map_data) in Matlab, resave, and import back into GRASS with
r.in.mat. (quicker than writing some C code to do the same)


thanks for the effort,
Hamish