Hi.
I didn't mean to imply that '/' was OK by CF standards. I just picked it because of the connection to folder path syntax.
Grace and peace,
Jim
Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001
jim.biard at noaa.gov
828-271-4900
Follow us on Facebook!
On May 20, 2013, at 2:46 PM, H. Joe Lee <hyoklee at hdfgroup.org> wrote:
> 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 <jim.biard at noaa.gov> 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
> Remote Sensing and Applications Division
> National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801-5001
>
> jim.biard at noaa.gov
> 828-271-4900
>
>
> <CicsLogoTiny.png>
> Follow us on Facebook!
>
> On May 19, 2013, at 11:50 AM, Andreas Hilboll <lists at hilboll.de> 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
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130520/770be09e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130520/770be09e/attachment-0001.png>
Received on Mon May 20 2013 - 13:53:08 BST
