Re: [netcdf-java] NetCDF-Java CF compliance

  • To: Jacobs Tim <tim.jacobs@xxxxxxx>
  • Subject: Re: [netcdf-java] NetCDF-Java CF compliance
  • From: Sean Arms <sarms@xxxxxxxx>
  • Date: Thu, 26 Nov 2015 10:48:11 -0700
Hi all,

I'm in-between baking pies for Thanksgiving, but having taken a quick look
(because I just can't resist), I see that while the LAI data variable is
signed, the valid range is set using unsigned bytes.

Using `ncdump -h` on the first file:

byte LAI(lat, lon) ;
    LAI:_FillValue = -1b ;
    LAI:grid_mapping = "crs" ;
    LAI:standard_name = "leaf_area_index" ;
    LAI:missing_value = -1b ;
    LAI:scale_factor = 0.0333333333333333 ;
    LAI:valid_range = 0UB, 210UB ;

When netcdf-java sees this, it does what it's told and reads the valid
range to be 0 to -46.

If I set the valid range using ncml to be an integer between 0 and, say 16,
I am able to visualize the grid in ToolsUI (see attached) and the actual
value (with the scale applied) are from 0 to roughly 0.5, which is more
what I would expect LAI to be.

Maybe your python code isn't writing the valid range attribute out
correctly?

Cheers,

Sean


On Thu, Nov 26, 2015 at 9:33 AM, Jacobs Tim <tim.jacobs@xxxxxxx> wrote:

> Dear Sean, Robert,
>
>
> Thanks to both for the fast reply.
>
> I’ve sent you a link to the sample NetCDF4 files, generated with Python’s
> netCDF4 package (custom code)
>
> and GDAL v1.11 utilities.
>
>
>
> I’ve tried several options (like datatype for dataset or valid_range,
> _Unsigned attribute, etc), as you
>
> can see in the four examples (prefixed 1_, 2_,… in filename).
>
> H5dump –A output for each file is included as well (h5d_1.txt for the file
> 1_...nc and so on).
>
>
>
> Files 1-2-3 use signed integer datatype:
>
> ·         dataset LAI cannot be shown on standard geo2D plot in Panoply
>
> ·         CF compliance checker at Reading, UK gives no warning or error
> (and I know it checks datatypes),
> so file is (largely) compliant with CF v1.6.
>
>
>
> File 4 uses unsigned datatype
>
> ·         can be read/plotted in Panoply, though the valid range is
> printed wrongly (0…-46 but UB type)
>
> ·         CF compliance checker complains
>
> ERROR (8.1): LAI must be of type byte, short or int
>
> and section 8.1 of CF conventions doc mentions the use of signed integers .
>
>
>
> The LAI-QFLAG 16-bit dataset is shown properly though, so I think you can
> focus on LAI dataset
>
> and possibly byte/ubyte for the tests.
>
>
>
> Best regards,
>
> Tim
>
>
>
> *From:* Sean Arms [mailto:sarms@xxxxxxxx]
> *Sent:* woensdag 25 november 2015 18:38
> *To:* Jacobs Tim
> *Cc:* netcdf-java@xxxxxxxxxxxxxxxx
> *Subject:* Re: [netcdf-java] NetCDF-Java CF compliance
>
>
>
> Greeings Tim,
>
>
>
> Good question. Typically users have a issues with netcdf-java and unsigned
> ints, as Java does not have an unsigned int primitive type. However,
> netcdf-java fully supports signed ints. For a list of supported datatypes,
> checkout:
>
>
>
>
> http://www.unidata.ucar.edu/software/thredds/v4.6/netcdf-java/CDM/DataType.html
>
>
>
> It looks like the latest version of panoply is using the latest release of
> netcdf-java (v4.6.3), so I do not see anything on the netcdf-java side that
> could be an issue. netCDF-3 only uses signed types, so one quick way to
> check panoply is to open a netcdf-3 from from a different dataset or source
> and see if you can view any int fields.
>
>
>
> I'd be more than happy to take a look at your specific file to see if
> anything jumps out to me on the netcdf-java side.
>
>
>
> Cheers,
>
>
>
> Sean
>
>
>
> On Wed, Nov 25, 2015 at 1:18 AM, Jacobs Tim <tim.jacobs@xxxxxxx> wrote:
>
> Dear Unidata colleagues,
>
>
>
> CF conventions are more restrictive than NetCDF regarding
>
> the data type used for the variables. CF for instance requires the use
>
> of signed integers. However, NASA’s Panoply, that uses NetCDF-java,
>
> cannot display variables with signed integer datatype, whereas changing
>
> to unsigned equivalent works fine.
>
> Can NetCDF be updated to accommodate also signed integers?
>
> Or is the problem in Panoply’s own code?
>
>
>
> Best regards,
>
> Tim Jacobs
>
>
>
> Remote Sensing Dept.
>
> VITO NV
>
> Boeretang 200
>
> 2400 Mol
>
> Belgium
>
> Tel: +32 14 336710
>
> Skype: jacobs.timmeke
>
>
>
> VITO Disclaimer: http://www.vito.be/e-maildisclaimer
>
>
> _______________________________________________
> netcdf-java mailing list
> netcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
>
>

Attachment: Screen Shot 2015-11-26 at 10.41.48 AM.png
Description: PNG image

  • 2015 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: