[GRASS-user] flip raster

GRASS GRASS user
, ,
1

Hi all,

I was informed of this forum discussion via email this morning (not being a
GRASS user). 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. 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?" 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. I've also never used QGIS.

Any ideas or suggestions would be much appreciated.

Thanks,
Barry Eakins
National Geophysical Data Center

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

José María Michia wrote:

2008/10/6 Hamish <hamish_b@yahoo.com>:

José María Michia wrote:

> I've imported a NetCDF file (ETOPO1 model). The resulted raster
appears
> flipped vertically. How can I fix this?

hmmm, this problem sounds vaguely familiar.

Is this the dataset from:
http://www.ngdc.noaa.gov/mgg/global/global.html

?

if so, which version? the cell/grid registration thing is a slight pain.

Yes: grid-registered version, netCDF format.

The same problem (vertical inversion) occurs with QGIS. Same in GMT,
with an strange (to me) situation: one GMT program produce normal
maps.

The same problem (vertical inversion) is produced with QGIS.

And so does GMT, but one of GMT programs produce the expected result:

This, produce vertical inverted map:

$ grdraster 1 -R-80/-50/-50/-20 -Gargentina.nc
$ grdimage argentina.nc -JM6i -P -B2 -Ctopo.cpt -V -K > topo.ps

grdraster extract a subset of netCDF grid. Definition for grdraster id 1
is:

1 "ETOPO1 global topography" "m" -R-180/180/-90/90 -I1m
GG i 1 0 none
/mnt/hdb1/geodata/etopo/ETOPO1_Bed_g.grd B

And this produces the expected map:

$ grdcontour -R-80/-50/-50/-20
/mnt/hdb1/geodata/etopo/ETOPO1_Bed_g.grd -JM6i -P -B2 -C250 -A1000 >
topo2.ps

But, this map is a contour map, not raster map. So, is not adequate
for GRASS import.

I'm downloading the cell-registered version, I will try again with this
version.

With the alternative suggested by Hamish (see below), no need to
import this file.

Alexander: Thanks for your suggestion. I will take into account the
CDO program in the future.

Another idea for those interested: an alternative might be to use the
GDAL program to convert the file into another format NetCDF middle, a
format for which it is possible to import into GRASS. This
intermediate format can be ASCII, to be able to easily modify it as
needed.

for importing 1' global elevation from:
http://topex.ucsd.edu/marine_topo/mar_topo.html
here are some hints, including ETOPO2:
http://grass.osgeo.org/wiki/Marine_Science#Bathymetric_data

Thanks for the suggestions. I've found the desired data in
http://topex.ucsd.edu/cgi-bin/get_data.cgi

Hamish

Saludos
José María
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
View this message in context: http://www.nabble.com/flip-raster-tp19836768p20708964.html
Sent from the Grass - Users mailing list archive at Nabble.com.

2

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

3

I've posted new versions of ETOPO1 that GDAL can read properly (north is
north) on the ETOPO1 web page
(http://www.ngdc.noaa.gov/mgg/global/global.html), along with an explanatory
readme file (in each netcdf folder). I've also created and posted geotiff
versions of ETOPO1. Please let me know if any more problems are encountered.

Thanks,
Barry Eakins
barry.eakins@noaa.gov

ETOPO1 1 Arc-Minute Global Relief Model
http://www.ngdc.noaa.gov/mgg/global/global.html

--
View this message in context: http://www.nabble.com/flip-raster-tp19836768p21081238.html
Sent from the Grass - Users mailing list archive at Nabble.com.