Andreas & Jim,
The hdf5_handler module in Hyrax OPeNDAP server has implemented the Jim's idea of making the group structure flat. For example, we've made ICESat-2 Mabel product (HDF5 with many groups) conform to CF conventions [1] so users can even download it as NetCDF-3 [2]. We've made many NASA HDF5 products work with Panoply in this manner [3]. By the way, we used '_' instead of '/' because we thought CF doesn't allow '/' character according to the following statement: "Variable, dimension and attribute names must begin with a letter and be composed of letters, digits, and underscores." According to Jim, it seems OK to use '/' in var/dim/att names. I'd like to confirm it with this CF group if '/' is really OK. Anyway, there's a chance that your file can be visualized with Panoply through OPeNDAP hdf5_handler because NetCDF-4 is HDF5 underneath. If you want, I can quickly check if your file can be visualized with Panoply using our demo OPeNDAP server. Please feel free to send your data file for testing. Regards, [1] http://eosdap.hdfgroup.uiuc.edu:8080/opendap/data/NASAFILES/hdf5/more/mabel_l2a_20110322T165030_005_1.h5.das [2] http://eosdap.hdfgroup.uiuc.edu:8080/opendap/data/NASAFILES/hdf5/more/mabel_l2a_20110322T165030_005_1.h5.html [3] http://hdfeos.org/zoo/hdf5_handler/ -- HDF: Software that Powers Science On Mon, May 20, 2013 at 10:58 AM, Jim Biard <[email protected]> wrote: > Andreas, > > CF has yet to address the new netCDF-4 features. My personal opinion is > that CF needs to be extended to embrace the new netCDF-4 features (and I am > currently using netCDF-4 with groups), but interoperability / backward > compatibility concerns have prevented this. As a result, I'm not surprised > to find that PanoplyJ doesn't support your file. I'm not sure, but I think > it might be that there is no viewer application that will properly handle > your file. > > Since there are no applicable CF conventions, what I'm about to say has no > authority whatsoever, but I am going to share my thoughts and opinions > about file design using groups as a possible step in the direction of > developing such conventions. > > I think the best way to consider groups within a netCDF-4 file is to treat > each one as a file in its own right (with certain extensions). The group > concept in netCDF-4 is a form of scope control. Placing coordinates in a > different group than measurements would then imply that the two sets of > variables are not visible to one another. If there are dimensions or > coordinate variables that are common to data variables that have been > placed in different groups, they could be reasonably be placed at a common > level above the groups (such as the root). Dimensions declared in a group > (including the root) are visible to all child groups, so extension to > coordinate variables would not be unreasonable. > > There is another way to think about groups, which is to consider them as > nothing more than ways to make hierarchical names for attributes, > dimensions, and variables. In this view, your file contents are effectively > > dimensions: > lon = 5760 ; > nv = 2 ; > lat = 2880 ; > time = UNLIMITED ; // (204 currently) > variables: > double coordinates/lon(lon) ; > coordinates/lon:standard_name = "longitude" ; > > coordinates/lon:units = "degrees_east" ; > > coordinates/lon:bounds = "coordinates/lon_bnds" ; > > double coordinates/lon_bnds(lon, nv) ; > > double coordinates/lat(lat) ; > > coordinates/lat:standard_name = "lat" ; > > coordinates/lat:units = "degrees_north" ; > > coordinates/lat:bounds = "coordinates/lat_bnds" ; > > double coordinates/lat_bnds(lat, nv) ; > > int coordinates/time(time) ; > > coordinates/time:standard_name = "time" ; > > coordinates/time:units = "hours since 1994-01-01 00:00:00 +0:00" ; > > coordinates/time:calendar = "gregorian" ; > > coordinates/time:bounds = "coordinates/time_bnds" ; > > int coordinates/time_bnds(time, nv) ; > > double data/sciamachy_vcdtrop-no2_v4(time, lon, lat) ; > data/sciamachy_vcdtrop-no2_v4:_FillValue = NaN ; > data/sciamachy_vcdtrop-no2_v4:least_significant_digit = 5L ; > > > (I have used '/' characters to concatenate the group names with the > variable names to make the "flattened" names. You could as easily use '_' > characters instead.) > > There is nothing overtly "wrong" about variables with names such as these. > In fact, there is a certain attraction to making the distinction between > measurement and coordinate variables clear through what amounts to a naming > convention. But (You knew that was coming, didn't you?), I have > reservations about a convention that starts by splitting the world into > coordinate and measurement domains at the top level. I think this approach > will lead to unnecessary limitations. > > Grace and peace, > > Jim > > Jim Biard > Research Scholar > Cooperative Institute for Climate and Satellites <http://www.cicsnc.org/> > Remote Sensing and Applications Division > National Climatic Data Center <http://www.ncdc.noaa.gov/> > 151 Patton Ave, Asheville, NC 28801-5001 > > [email protected] > 828-271-4900 > > > > Follow us on Facebook <https://www.facebook.com/cicsnc>! > > On May 19, 2013, at 11:50 AM, Andreas Hilboll <[email protected]> wrote: > > Dear Dr. Schmunk, dear CF experts, > > I'm wondering if CF concentions say anything about the grouping within a > netCDF4 file, and if PanoplyJ can handle files with different groups? I > couldn't find anything in the documentation, but wanted to make sure. > > I'm having issues using PanoplyJ > (http://www.giss.nasa.gov/tools/panoply/) with a file where data and > coordinate variables are in different groups. For example, the data > variable of this file cannot be plotted with Panoply: > > ---8<------- > dimensions: > lon = 5760 ; > lat = 2880 ; > time = UNLIMITED ; // (204 currently) > nv = 2 ; > > group: coordinates { > variables: > double lon(lon) ; > lon:standard_name = "longitude" ; > lon:units = "degrees_east" ; > lon:bounds = "lon_bnds" ; > double lon_bnds(lon, nv) ; > double lat(lat) ; > lat:standard_name = "lat" ; > lat:units = "degrees_north" ; > lat:bounds = "lat_bnds" ; > double lat_bnds(lat, nv) ; > int time(time) ; > time:standard_name = "time" ; > time:units = "hours since 1994-01-01 00:00:00 +0:00" ; > time:calendar = "gregorian" ; > time:bounds = "time_bnds" ; > int time_bnds(time, nv) ; > } // group coordinates > > group: data { > > group: VCDtrop_NO2 { > > group: SCIAMACHY { > variables: > float sciamachy_vcdtrop-no2_v4(time, lon, lat) ; > sciamachy_vcdtrop-no2_v4:_FillValue = NaNf ; > sciamachy_vcdtrop-no2_v4:least_significant_digit = 5L ; > } // group SCIAMACHY > } // group VCDtrop_NO2 > } // group data > } > ---8<------- > > However, when collapsed so that all variables are in the rootgrp, the > file is plotted correctly: > > ---8<------- > dimensions: > lon = 5760 ; > nv = 2 ; > lat = 2880 ; > time = UNLIMITED ; // (204 currently) > variables: > double lon(lon) ; > lon:standard_name = "longitude" ; > lon:units = "degrees_east" ; > lon:bounds = "lon_bnds" ; > double lon_bnds(lon, nv) ; > double lat(lat) ; > lat:standard_name = "lat" ; > lat:units = "degrees_north" ; > lat:bounds = "lat_bnds" ; > double lat_bnds(lat, nv) ; > int time(time) ; > time:standard_name = "time" ; > time:units = "hours since 1994-01-01 00:00:00 +0:00" ; > time:calendar = "gregorian" ; > time:bounds = "time_bnds" ; > int time_bnds(time, nv) ; > double sciamachy_vcdtrop-no2_v4(time, lon, lat) ; > sciamachy_vcdtrop-no2_v4:_FillValue = NaN ; > sciamachy_vcdtrop-no2_v4:least_significant_digit = 5L ; > ---8<------- > > So my question is: is this a bug in PanoplyJ, or is Panoply doing the > right thing and I don't understand the CF conventions correctly? > > Your help is greatly appreciated! > Andreas. > > > -- Andreas. > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > >
<<CicsLogoTiny.png>>
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
