Steve Hankin wrote:
>Brian Eaton wrote:
>
>
>
>>Hi Steve,
>>
>>Thanks for your comments. They're always welcome, whenever they come in.
>>
>>On Mon, Mar 10, 2003 at 11:41:11AM -0800, Steve Hankin wrote:
>>
>>
>>>Hi Brian,
>>>
>>>As always, I have to preface my remark with an apology for entering the
>>>discussion late and not attempting to follow every detail. Would that some
>>>other commitments could somehow diminish ...
>>>
>>>Two comments:
>>>
>>> 1. on the general issue of "standard names"
>>> There is a level of risk to the interoperability and versioning of CF
>>> files when you introduce standard name tables. This is not a new issue in
>>> CF, but with each new step down this path (e.g. grid_mapping_name) we
>>> expand the problem area. GRIB stands as an example of where the need on
>>> the part of users to add new names has fragmented the standard. For CF,
>>> each new modeling group that develops an interesting coordinate system
>>> will be motivated to extend the standard by encoding their own pet name
>>> into their grid_mapping_name.
>>>
>>> Thought should be given to how to minimize this problem. Should we
>>> implement some kind of procedure (at Unidata?) to allow users a path to
>>> register new grid mapping names? (Importantly registration can make users
>>> aware that someone else may already have added the same new grid mapping
>>> under a different name.) [Obviously, a much better solution would be if
>>> the desired grid metrics could be generalized in a manner that does not
>>> depend upon a name. Have all such approaches already been discussed and
>>> dismissed as unfeasible? Aren't some of the modeling framework folks
>>> working on this problem?]
>>>
>>>
>>At one point we were discussing allowing the user to specify a "projection
>>authority", i.e., the source of the names they used to describe the grid
>>mapping. We decided against this idea because of the problems associated
>>with using different sets of names for the same projection.
>>
>>Our intention with both the standard_name and the grid_mapping_name values
>>is to extend these lists by user request. By having users go through us we
>>can insure that the name scheme remains consistent (which improves its
>>usability) and prevent duplications. There is a note about this in the
>>standard name table document, but I notice that there is not a similar note
>>in the grid mapping section. I will make this point more clearly in the CF
>>document.
>>
>>
>
>Hi Brian et. al.,
>
>This discussion provides an excellent segue into a "meta-topic" -- not the CF
>standard, itself, but the process by which the CF standard is created and evolves.
>The importance of CF is growing steadily. It has become a cornerstone of standard
>interchange (or planning for it) in GODAE, in a goodly number of model
>intercomparison projects in climate, atmosphere, and oceans, and elsewhere. Last
>week I participated in some related discussions at NOAA/GFDL. One thing that emerged
>in those discussions was that apparently both PRISM and ESMF are developing netCDF
>standards which are described as "based upon CF but with extensions". I'm sure I do
>not need to point out that the seeds of future interoperability problems are to be
>found in this approach. Standards which are extensions from a common ancestor will
>probably not be interoperable in those extensions. Yet the standards needs of these
>groups lies directly on the bulls eye of CF. These groups should not be considering
>extensions beyond CF, they should be participating in the development of CF, itself.
>
one of the main deficiencies in CF has been heretofore the lack of
projection specification. Now, I hope that is resolved. I wonder what
issues the PRISM and ESMF folks are trying to resolve?
last week I sent an email to the WRF modelers encouraging (pleading?)
that they adopt the CF conventions, or propose extentions to it for
incorporation into CF. The response has been lukewarm so far, perhaps
because the core modelers 1) dont concentrate on the the post processing
phase, and/or 2) tend to have highly specialized post-processeing tools
that dont require generic conventions. (one could also ask how the
truly awful AWIPS netcdf format "happened").
>
>CF has reached a stage of maturity where it is a community resource and it is vital
>that a wide spectrum of groups actively participate in the CF process. Are we (and I
>guess I am speaking to you, Jonathan, Bob, and Karl as well as myself) comfortable
>that we are casting our net wide enough? I am not sure, myself, how widely the
>cf-metadata email list gets read, or the degree to which "outsiders" understand that
>CF needs their participation.
>
>As a community we suffer from the lack of a well-defined standards process. Most of
>our standards are ad hoc. Not only do the standards arise from grass roots efforts,
>they also exist and evolve at the pleasure of the same grass roots groups. There is
>no established path to achieve public review and acceptance. How can we improve upon
>this for CF? Please share your thoughts.
>
> - steve
>
there is a tension between a good, lightweight standard for one's own
purposes, and a generic standard that can get complex (look how many
pages CF is!). Its important for CF to mark its boundaries with a
statement of purpose.. I think we have agreed its for "global and
regional model output" (??). Is that sufficient ?? Anyway, given a
clear statement of purpose, we could then broadcast the offer that we
want CF to include other models that fall within its intent. We could eg
periodically post that offer to netcdfgroup. We should actively solicit
important models that we know about. We then need a decision making
process, and a versioning process.
Yeah I know, its a lot of work!!!
>
>=============
>
>
>
>>> 2. on the specific example of the rotated pole grid in section 5.6
>>> The explanatory text says "This should prevent a COARDS compliant
>>> application from mistaking the variables rlon and rlat to be actual
>>> longitude and latitude coordinates."
>>> The standard names "grid_latitude" and "grid_longitude" were not a part of
>>> COARDS, so including them does not really provide the claimed backwards
>>> compatibility. Some word smithing to explain that the curvilinear grids
>>> are an extension to COARDS would suffice to fix this -- there is no way
>>> that COARDS could have understood this file.
>>>
>>>
>>Our idea here is that a COARDS conforming application should not recognize
>>rlon as a longitude axis because instead of having the units "degrees_east"
>>(or an equivalent), it has units of "degrees" which is disallowed by
>>COARDS. On the other hand a CF conforming application will recognize rlon
>>as the longitude in the rotated grid by the presence of the standard name
>>"grid_longitude".
>>
>>In our initial draft of the rotated pole example the units of rlon were
>>given as "degrees_east". We then realized that this would allow a COARDS
>>application to misinterpret the rotated longitudes as true longitudes. So
>>we decided to bring back the disallowed "degrees" for this case.
>>
>>Thanks,
>>Brian
>>
>>
>
>_______________________________________________
>CF-metadata mailing list
>CF-metadata at cgd.ucar.edu
>http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
Received on Tue Mar 11 2003 - 09:41:03 GMT
