Ticket #1568 (assigned defect)

Opened 1 year ago

Last modified 1 year ago

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

Reported by: mwtoews Assigned to: dnadeau (accepted)
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.4.0
Severity: normal Keywords: NetCDF
Cc: warmerdam

Description

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

$ gdalinfo -nomd test-0001.nc 
Driver: netCDF/Network Common Data Format
Size is 512, 512
Coordinate System is `'
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"test-0001.nc":recharge
  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:"test-0001.nc":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

04/10/07 01:51:31 changed by mwtoews

  • version changed from unspecified to 1.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.

04/19/07 18:39:46 changed by dnadeau

  • status changed from new to assigned.
  • owner changed from denis.nadeau@gmail.com to dnadeau.

Michael,

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

04/19/07 20:52:55 changed by mwtoews

Daniel,

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 out.nc'.
Program terminated with signal 11, Segmentation fault.
#0 0xb77279f0 in NC_var_shape () from /usr/lib/libmfhdf.so.4

(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("out.nc")
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.

04/19/07 23:03:34 changed by warmerdam

The crash you report (in NC_var_shape from library libmfhdf.so) 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.

04/20/07 02:02:14 changed by mwtoews

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.

05/02/07 18:41:30 changed by dnadeau

WHen compiling hdf4 libraries, make sure you set:

. export CFLAGS=-DHAVE_NETCDF

before calling configure.

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