NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi all, Having neglected to CC the GALEON list, I'm forwarding a copy of the note below. Sorry if you end up getting two copies. -- Ben ---------- Forwarded message ---------- From: Ben Domenico <Ben@xxxxxxxxxxxxxxxx> Date: Wed, Dec 28, 2011 at 11:26 AM Subject: CF-netCDF standardization update To: CF-netCDF SWG <CF-NetCDF-1.0.SWG@xxxxxxxxxxxxxxxxxxxxxxxx> Hi all, With no CF-netCDF session at the Brussels OGC TC meeting, there has not been a lot of public progress on the CF-netCDF standardization work, so it is time to re-invigorate the effort for the coming new year. The March TC meeting in Austin, Texas (a state in the southwestern region of the US.) will be an important one for CF-netCDF. There is new information on a couple issues that have been troublesome for us in the past. One is the relationship of our work to OPeNDAP and HDF standards. As most of you know OPeNDAP, Inc. is now a full voting member of the TC so we can work directly with them in the context of the OGC TC. HDF is also important for us because a profile of HDF5 is the encoding form for netCDF4. A recent email exchange between Aaron Braeckel and Carl Reed have uncovered a very hopeful avenue for us to pursue for that component of the CF-netCDF standards process. Below are relevant excerpts of an email exchange that describes an approach to consider: Aaron to Carl: The NetCDF 4 data format is built on a NASA standard: HDF5. Unless there have been developments I am not aware of, OGC cannot reasonably take ownership of the HDF5 standard. The reasonable thing seems to be for OGC to own and operate NC4 and NASA would continue to own and operate HDF5. Could the OGC NetCDF 4 standard document reference a specific version of the NASA HDF 5 standard, much as OGC standards reference specific versions of XML, XML schema, and other external encoding standards? Carl's response: The short answer is yes. The only issue could occur if you wanted to move NetCDF 4 into the ISO process. They might take exception but then we could use the PAS process. A big thanks is in order to Aaron and Carl for the clarification. This is an area where rapid progress will be very valuable. It complements our draft specification for the netCDF Enhanced Data Model (aka the netCDF4 data model) and provides a path for standardizing both the data model and encoding for netCDF4. Discussion of these issues will be important at the Austin meeting, But we have considerable ongoing initiatives to attend to as well. I'll append the summary of the CF-netCDF session from the TC meeting in Boulder last September as a reminder of the outstanding issues and I'll attach the netCDF Enhanced Data Model Extension Specification that was drafted before that meeting. Enough for now. I just want to get our SWG (mainly me) back on task so we can begin addressing the many important opportunities in time for the Austin meeting. Happy New Year! -- Ben ================================================= *CF-netCDF SWG Session at the September 2011 OGC TC Meetings in Boulder* *Agenda* The agenda consisted of: 1. CF extension to the netCDF core standard (Stefano Nativi) 2. CF-netCDF extension to the WCS core standard (Stefano Nativi) 3. Enhanced Data Model extension to the netCDF core standard (Ben Domenico) 4. Uncertainty model for netCDF-CF (Lorenzo Bigagli and Stefano Nativi) 5. Determine how to deal with errors in existing netCDF binary standard noted by Simon Cox (see next slide) Item 5 was taken care of in brief discussions with Carl Reed and Simon Cox outside the SWG session. They both agree that the changes are not substantive, so the typos can be corrected in the existing spec and a phrase can be inserted clarifying that Requirement 1 is a special type of requirement, namely, a dependency. The presentations and draft documents are available at: https://portal.opengeospatial.org/index.php?m=projects&a=view&project_id=82&tab=2&artifact_id=45016 *Issues* A couple additional issues came up during the discussion - There is a need to register a mime type for netCDF with IANA. The question is whether to try to come up with all the modifiers (e.g.netCDF -3, netCDF-4, netCDF-CF,…) before submitting request. The sense of the group is that a base mime type necdf should be registered with modifiers for netCDF-, netCDF-4, CF-netCDF, etc. - With the new modular approach to specifications, OGC is creating a bit of a Humpty Dumpty Problem of having too many modules in specs, too many conformance classes within modules, etc. As a consequence, potential new users can be overwhelmed. It isn't always clear how to assemble fragments into a coherent, working whole. Primers with an overall overview are a help by not a solution. One new possibility is to emphasize the need for overview information in Profile specs where the application to a particular community is documented. *Action Items* (all internal to the SWG) - Make non-substantive edits to existing netCDF binary encoding spec. See note in Agenda above. (Ben Domenico) - In the CF Extension to netCDF core, some items that are optional for CF are mandatory in the proposed OGC specification. A list of these items will be circulated with the call for comments. (Stefano Nativi) - The CF-netCDF overview and planning documents should indicate that XML-encoding is addressed in CF-netCDF extension to WCS. (Ben Domenico) - Discussion paper for netCDF uncertainty conventions will be captured in a discussion paper for next TC. Will include netCDF3 and netCDF4 options and will pursue with CF conventions community in parallel (Lorenzo Bigagli) *Motions* There were no motions at this SWG ==============================================
Attachment:
11-038-NetCDF_Enhanced_Data_Model-New_Template.doc
Description: MS-Word document
galeon archives: