| 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: 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) ; (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 [email protected] 828-271-4900  Follow us on Facebook! On May 19, 2013, at 11:50 AM, Andreas Hilboll <[email protected]> wrote: Dear Dr. Schmunk, dear CF experts, |
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
