John,
Your comments are very useful to fuel the CF debate. I just wanted to pick up the station and trajectory data question, and to add radar data to that list. I think that CF is becoming (or being used as) the standard for lots of these data types because it is the best option, even if it is still lacking. As you say, CF's strength is really gridded data, but unless there are other standards out there that can encompass station, trajectory and radar data then I'd rather CF worked harder to understand and fully include these data types. We have a radar group in the UK who have all switched to NetCDF so drawing on experience such as theirs would be a sensible way forward. Perhaps we need a working group on each of these data types with some interactions that would ensure they didn't diverge too radically.
Kind regards,
Ag
-----Original Message-----
From: cf-metadata-bounces at cgd.ucar.edu on behalf of John Caron
Sent: Thu 26/05/2005 11:01 PM
To: CF-metadata
Subject: [CF-metadata] Thoughts about CF future
Since I am not able to come to the GO-ESSP meeting to discuss these
issues in person, I wanted to lay out my thoughts about where CF could
go in the future. These are personal opininions, and not in any way
official Unidata positions.
We (Unidata) have been pushing CF as the recommended way to write
gridded files to anyone who asks. We have had a lot of success,
including with ESRI who are working on reading CF compliant netdf files
into ArcView. CF has really done a great job of clarifying the semantics
of data. In my view, the current edges of CF that need work are:
1. staggered grids, eg as output by the WRF model.
2. need to specify very detailed info as used by GIS, for example,
ellipsoids and datums etc.
3. ongoing need to add new projections and vertical coordinate types
4. ongoing need to develop standard names and hook these into other
ontologies
My primary concern is creating a process for evolving CF, what Bryan
called "governance". I would like to see a formal decision making group
be identified, with super-majority but not necessarily unanimous consent
required. I would also like to have ad-hoc subgroups form to work on
special topics, for example "Regional/local models" and "GIS". These
subgroups would work out a concrete recommendation, then submit to the
entire group for feedback and eventually a decision by the governance group.
Another issue that has recently come up: CF has a small section about
both Station and Trajectory data, that is good as far as it goes, but
needs more semantics to be complete. I would recommend that CF restrict
itself to gridded data, and withdraw the Station and Trajectory data
sections. However, if there is enough interest, i would recommend
forming a subgroup that would finish specifying it.
There is also development at Unidata that effects CF, most notably the
"coordinate system" object model, prototyped in the Netcdf-Java library
(which we may also add to the Netcdf-4 library). This parses CF
conventions (among others) and presents a unified coordinate system API
to the user. We also are working on "scientific data type" APIs that so
far include Grid, Point, Station, Trajectory and Radial data types. This
work is not as far along as the coordinate systems, but as part of it we
have been evolving our view of what makes good file formats in those cases.
Whatever is decided, we will continue to support CF as an important
semantic description of data. I appreciate all the time and intelligence
this group continues to provide.
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Fri May 27 2005 - 03:53:58 BST
