Opened 17 years ago

Closed 14 years ago

#1568 closed defect (fixed)

gdalinfo on a netCDF file returns uninitiated coordinate information if variable/band not specified

Reported by: Mike Taves Owned by: dnadeau
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.4.0
Severity: normal Keywords: netcdf
Cc: warmerdam, ksshannon@…


This behaviour is described in #1506, and appears to work with any any NetCDF file, for example (using the "" file from here):

$ gdalinfo -nomd 
Driver: netCDF/Network Common Data Format
Size is 512, 512
Coordinate System is `'
  SUBDATASET_1_DESC=[1x225x86] recharge (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)

The coordinate information 0.0, 256.0, etc. (power of 2) are uninitiated values for the raster band (or NetCDF variable), and are not representative for the file. It would seem appropriate for gdalinfo to report that the raster band has undefined coordinate information, rather than reporting ininitiated values.

Secondly, as there is only one variable/band in the netCDF file, gdalinfo should use that variable variable to define the coordinate information (I understand from #1506 that this is an unfinished defect in the NetCDF driver). The correct coordinate information is obtained by specifying the single band:

$ gdalinfo -nomd NETCDF:"":recharge
Driver: netCDF/Network Common Data Format
Size is 86, 225
Coordinate System is `'
Origin = (747650.000000000000000,5463750.000000000000000)
Pixel Size = (100.000000000000000,-100.000000000000000)
Corner Coordinates:
Upper Left  (  747650.000, 5463750.000) 
Lower Left  (  747650.000, 5441250.000) 
Upper Right (  756250.000, 5463750.000) 
Lower Right (  756250.000, 5441250.000) 
Center      (  751950.000, 5452500.000) 
Band 1 Block=86x1 Type=Float32, ColorInterp=Undefined
  NoData Value=-9999

Change History (8)

comment:3 by Mike Taves, 17 years ago

Version: unspecified1.4.0

Sorry, I should have mentioned that this is with version 1.4.1 (which I can't select in Trac!) and up to r11236 on Cygwin and Debian Etch platforms; also with FWTools version 1.2.2.

comment:4 by dnadeau, 17 years ago

Owner: changed from denis.nadeau@… to dnadeau
Status: newassigned


I have checked in a new version of netcdfdataset.cpp that should correct this behavior. (r11296)

comment:5 by Mike Taves, 17 years ago


I've tested r11296 on two platforms; both did not work as expected.

My Cygwin version does not want to compile, and I'm not exactly sure what the problem is, so I can't help for this case.

My Debian Etch version compiles successfully, and gdalinfo works on other rasters but throws a segmentation fault with any netcdf file. I ran a core dump through gdb, and it reports:

... (all symbols read and loaded without error)
Core was generated by `gdalinfo'.
Program terminated with signal 11, Segmentation fault.
#0 0xb77279f0 in NC_var_shape () from /usr/lib/

(sorry, I'm not a C++ programmer and I only have basic C skills, so I can't debug much further)

On the same platform I also tried to use the netcdf driver, which has successful results:

>>> import gdal
>>> gd = gdal.Open("")
Warning 1: Latitude grid not spaced evenly.
Setting projection for grid spacing is within 0.1 degrees threshold.

>>> gd.GetGeoTransform()
(-1.40625, 2.8125, 0.0, -89.258462312871046, 0.0, 2.7893269472772202)

I'm not sure if this is what the behavior was before or not, but at least it is working at some level.

comment:6 by warmerdam, 17 years ago

The crash you report (in NC_var_shape from library is due to conflicting netcdf apis in the hdf and netcdf libraries. The easiest way to avoid this problem is the configure GDAL --without-hdf.

comment:7 by Mike Taves, 17 years ago

Thanks Frank; configuring using --without-hdf4 --without-hdf5 avoided the seg fault on my Debian system (I recall I might have recently installed libhdf* packages inadvertently through another Debian package with HDF* dependencies, since I didn't have this issue before). However, I cannot test this version on my Cygwin setup (I'm pretty sure the problem that I noted above is somehow related to a new version of netcdf that I attempted to compile/install recently, so it shouldn't be a concern here).

Indeed, r11296 corrected the reported behaviour for this ticket, thanks again Denis.

comment:8 by dnadeau, 17 years ago

WHen compiling hdf4 libraries, make sure you set:


before calling configure.

This will create a wrapper around netcdf calls in to avoid conflicts with libnetcdf.

comment:9 by Kyle Shannon, 14 years ago

Keywords: netcdf added; NetCDF removed

comment:10 by Kyle Shannon, 14 years ago

Cc: ksshannon@… added
Resolution: fixed
Status: assignedclosed

It appears this was fixed in r11296, closing. Worked with the trunk and NetCDF 3.6.3 on my machine.

Note: See TracTickets for help on using tickets.