[GRASS-user] pb. with netCDF row order

Nicolas Pérenne nicolas.perenne at free.fr
Sun Oct 24 12:40:35 EDT 2010


Hi, 

I am new to GRASS but bought the book (3rd edition) and searched the
mail archive before sending in this question. The issue is about reading
a netCDF file: I got a "vertical mirror" of "upside down" effect (when I
display the imported raster using d.rast) but when I use an
old-fashioned technique (translating to GRASS ASCII, see below) it looks
okay. 

The netCDF file itself is fine when viewed using, e.g., Ferret
(http://ferret.pmel.noaa.gov/Ferret/). The outputs of ncdump and
gdalinfo are provided at the end of this mail. 

The best procedure would be to follow
http://lists.osgeo.org/pipermail/grass-user/2010-September/057799.html
and thus either use r.in.gdal directly: 
grass>r.in.gdal -o NETCDF:"r2.nc":xe out=xe2
(in a WGS84 LOCATION) or after a gdal_translate: 
grass>gdal_translate -a_srs EPSG:4326 NETCDF:"r2.nc":h0 h02.tiff
grass>r.in.gdal h02.tiff out=h02

But when I view the resulting raster, h02, it is flipped "upside
down" (as if the latitude was increasing "downward"). 

Thus so far I need to rely on a script which is actually a follow-up of
this (old) thread: 
http://lists.osgeo.org/pipermail/grass-user/2002-December/008022.html
I have attached the script I use to this mail, in case somebody finds it
useful (you also need awk and nco); it is only an ersatz though, and I
would like to know what I can do to import my netCDF file directly into
GRASS (without a temporary GRASS ASCII file). 

Are there metadata I should add to the netCDF file to get r.in.gdal
happy? Does r.in.gdal need a particular row order in the netCDF file
(such as j index increasing southward)? 

That was a long one! 
Hope it was more or less clear. 

Nicolas

PS the system I am working with: 
bash>uname -a
Linux Herminet1 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:48:22 UTC
2010 i686 GNU/Linux
bash>gdalinfo --version
GDAL 1.6.3, released 2009/11/19
bash>grass -v
GRASS GIS 6.4.0RC5+39438

#####################
bash> ncdump -h r2.nc
netcdf r2 {
dimensions:
	longitude = 133 ;
	latitude = 64 ;
	time = UNLIMITED ; // (14 currently)
variables:
	double longitude(longitude) ;
		longitude:units = "degrees_east" ;
	double latitude(latitude) ;
		latitude:units = "degrees_north" ;
	double time(time) ;
		time:units = "seconds since 1900-1-1" ;
	float h0(latitude, longitude) ;
		h0:units = "m" ;
		h0:missing_value = -999.f ;
	float xe(time, latitude, longitude) ;
		xe:units = "m" ;
		xe:missing_value = -999.f ;
	float u(time, latitude, longitude) ;
		u:units = "m/s" ;
		u:missing_value = -999.f ;
	float v(time, latitude, longitude) ;
		v:units = "m/s" ;
		v:missing_value = -999.f ;
// global attributes:
		:Conventions = "COARDS" ;
}
####################
bash> gdalinfo r2.nc 
Driver: netCDF/Network Common Data Format
Files: r2.nc
Size is 512, 512
Coordinate System is `'
Metadata:
  NC_GLOBAL#Conventions=COARDS
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"r2.nc":h0
  SUBDATASET_1_DESC=[64x133] h0 (32-bit floating-point)
  SUBDATASET_2_NAME=NETCDF:"r2.nc":xe
  SUBDATASET_2_DESC=[14x64x133] xe (32-bit floating-point)
  SUBDATASET_3_NAME=NETCDF:"r2.nc":u
  SUBDATASET_3_DESC=[14x64x133] u (32-bit floating-point)
  SUBDATASET_4_NAME=NETCDF:"r2.nc":v
  SUBDATASET_4_DESC=[14x64x133] v (32-bit floating-point)
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0,  512.0)
Upper Right (  512.0,    0.0)
Lower Right (  512.0,  512.0)
Center      (  256.0,  256.0)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nc2grass.sh
Type: application/x-shellscript
Size: 2581 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-user/attachments/20101024/5be835e8/nc2grass.bin


More information about the grass-user mailing list