#2599 closed defect (fixed)
accessing NetCDF band data of type char causes errors
Reported by: | mdsumner | Owned by: | warmerdam |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | GDAL_Raster | Version: | 1.5.0 |
Severity: | normal | Keywords: | netcdf |
Cc: |
Description
This file contains variables of type char, which gdalinfo reports as being of type Float32.
ftp://ftp.ifremer.fr/ifremer/argo/latest_data/2004/02/20040213_prof.nc
I'm using trunk, checked out 2008-10-10 on Windows. The same problem occurs in Linux with an old GDAL (GDAL 1.5dev, FWTools 1.3.2, released 2007/06/01)
gdalinfo NETCDF:"20040213_prof.nc":PLATFORM_NUMBER -stats Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute Warning 1: Unsupported netCDF datatype (2), treat as Float32. Driver: netCDF/Network Common Data Format Files: none associated Size is 8, 33 Coordinate System is `' Metadata:
PLATFORM_NUMBER#long_name=Float unique identifier PLATFORM_NUMBER#conventions=WMO float identifier : A9IIIII PLATFORM_NUMBER#_FillValue=
Corner Coordinates: Upper Left ( 0.0, 0.0) Lower Left ( 0.0, 33.0) Upper Right ( 8.0, 0.0) Lower Right ( 8.0, 33.0) Center ( 4.0, 16.5) Band 1 Block=8x1 Type=Float32, ColorInterp=Undefined ERROR 1: netCDF scanline fetch failed: Attempt to convert between text & numbers ERROR 1: IReadBlock failed at X offset 0, Y offset 0 ERROR 1: netCDF scanline fetch failed: Attempt to convert between text & numbers ERROR 1: IReadBlock failed at X offset 0, Y offset 1 ERROR 1: netCDF scanline fetch failed: Attempt to convert between text & numbers ERROR 1: IReadBlock failed at X offset 0, Y offset 2 . . .
ncdump reports this information (including the variable in question):
netcdf 20040213_prof { dimensions:
DATE_TIME = 14 ; STRING256 = 256 ; STRING64 = 64 ; STRING32 = 32 ; STRING16 = 16 ; STRING8 = 8 ; STRING4 = 4 ; STRING2 = 2 ; N_PROF = 33 ; N_PARAM = 4 ; N_LEVELS = 110 ; N_CALIB = 1 ; N_HISTORY = UNLIMITED ; (219 currently)
variables:
char DATA_TYPE(STRING16) ;
DATA_TYPE:comment = "Data type" ; DATA_TYPE:_FillValue = " " ;
char FORMAT_VERSION(STRING4) ;
FORMAT_VERSION:comment = "File format version" ; FORMAT_VERSION:_FillValue = " " ;
char HANDBOOK_VERSION(STRING4) ;
HANDBOOK_VERSION:comment = "Data handbook version" ; HANDBOOK_VERSION:_FillValue = " " ;
char REFERENCE_DATE_TIME(DATE_TIME) ;
REFERENCE_DATE_TIME:comment = "Date of reference for Julian days" ; REFERENCE_DATE_TIME:conventions = "YYYYMMDDHHMISS" ; REFERENCE_DATE_TIME:_FillValue = " " ;
char PLATFORM_NUMBER(N_PROF, STRING8) ;
PLATFORM_NUMBER:long_name = "Float unique identifier" ; PLATFORM_NUMBER:conventions = "WMO float identifier : A9IIIII" ; PLATFORM_NUMBER:_FillValue = " " ;
char PROJECT_NAME(N_PROF, STRING64) ;
PROJECT_NAME:comment = "Name of the project" ;
Change History (4)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Component: | default → GDAL_Raster |
---|---|
Keywords: | netcdf added |
Priority: | normal → low |
Status: | new → assigned |
Version: | unspecified → 1.5.0 |
On review I do not consider the behavior particularly inappropriate. Unrecognised datatypes are treated as Float32, and the netcdf libraries are asked to try and convert to float32. It fails in this case because the values are not even numeric. This particular product array is really not suitable to access via GDAL.
I'm going to make an effort to exclude char type data from the subdataset list to help users avoid this sort of issue...
comment:3 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I have modified the netcdf driver to ignore NC_CHAR variables when preparing the subdataset list in trunk (r15492). I do not currently judge this as important enough to go into 1.5 branch.
Here is the gdalinfo output formatted more nicely.