[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #SEN-247226]: open end with NetCDF: Not a valid data type or _FillValue type mismatch

I believe this bug was fixed in the latest version of netcdf-c.
As a workaround, you might add the prefix [nofillmismatch] to the url.
E.g. use this URL and see if it helps.
'[nofillmismatch]http://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/MPOC/mday'

> 
> I am trying to use the data set
> http://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/MPOC/mday . It
> works well with netcdf 4.4.1.1 and software linked to the version of netcdf.
> 
> With 4.6.3 I get with
> 
> ncdump -h http://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/MPOC/mday
> 
> the error message: NetCDF: Not a valid data type or _FillValue type
> mismatch
> 
> My netcdf is build with gcc-7  on opensuse 42.3 and passed through all
> checks. So I do not send all details on configure etc. yet.
> 
> The data set on the NOAA - server can be analysed with netcdf 4.4.1.1.
> It looks like follows: (lines removed in the end, to make it shorter)
> 
> netcdf mday {
> dimensions:
>         eightbitcolor = 256 ;
>         lat = 4320 ;
>         lon = 8640 ;
>         rgb = 3 ;
>         time = 197 ;
> variables:
>         byte palette(rgb, eightbitcolor) ;
>                 palette:_Unsigned = "true" ;
>                 palette:_FillValue = -1b ;
>         float lat(lat) ;
>                 lat:long_name = "Latitude" ;
>                 lat:units = "degrees_north" ;
>                 lat:standard_name = "latitude" ;
>                 lat:_FillValue = -999.f ;
>                 lat:valid_min = -90.f ;
>                 lat:valid_max = 90.f ;
>         float lon(lon) ;
>                 lon:long_name = "Longitude" ;
>                 lon:units = "degrees_east" ;
>                 lon:standard_name = "longitude" ;
>                 lon:_FillValue = -999.f ;
>                 lon:valid_min = -180.f ;
>                 lon:valid_max = 180.f ;
>         int time(time) ;
>                 time:units = "seconds since 1970-01-01T00:00:00Z" ;
>                 time:_CoordinateAxisType = "Time" ;
>                 time:long_name = "Centered Time" ;
>                 time:standard_name = "time" ;
>                 time:axis = "T" ;
>         short poc(time, lat, lon) ;
>                 poc:long_name = "Particulate Organic Carbon, D.
> Stramski, 2007 (443/555 version)" ;
>                 poc:scale_factor = 0.2f ;
>                 poc:add_offset = 6400.f ;
>                 poc:units = "mg m^-3" ;
>                 poc:_FillValue = -32767s ;
>                 poc:valid_min = -32000s ;
>                 poc:valid_max = -27000s ;
> 
> All fill values seem to be identical to the type of the variables. (Fill
> values for coordinates are strange anyway.) I suspect the -1b of palette
> is not accepted, since negative bytes do not exist. However NOAA is a
> big player and the rejection of a data set because of such an error is
> stopping the workflow. May be a warning and some default missing value
> would help.
> 
> I am not really lost, since I kept the old netcdf-libraries and related
> software. I report the problem anyway, since others may see the same.
> 
> Best regards,
> 
> Martin Schmidt
> 
> 
> 

=Dennis Heimbigner
  Unidata


Ticket Details
===================
Ticket ID: SEN-247226
Department: Support netCDF
Priority: Normal
Status: Open
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.