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@… |
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 (8)
comment:3 by , 17 years ago
Version: | unspecified → 1.4.0 |
---|
comment:4 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Michael,
I have checked in a new version of netcdfdataset.cpp that should correct this behavior. (r11296)
comment:5 by , 17 years ago
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.
comment:6 by , 17 years ago
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.
comment:7 by , 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 , 17 years ago
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.
comment:9 by , 14 years ago
Keywords: | netcdf added; NetCDF removed |
---|
comment:10 by , 14 years ago
Cc: | added |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
It appears this was fixed in r11296, closing. Worked with the trunk and NetCDF 3.6.3 on my machine.
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.