Jonathan Gregory wrote:
> Dear Steve and Brian
>
> Brian wrote
>
>> I'd say the requirement is to enhance the feature of allowing data to be
>> spatially located using alternate coordinate systems. This is optional
>> metadata that supplements the required lat/lon coordinates which insure
>> interoperability. CF already contains this feature, but we didn't design
>> it with the use case in mind that some data providers would like to include
>> more than one alternate coordinate system for a single data variable.
>>
Hi Jonathan, Brian,
(I cannot locate this block of text in an earlier email ... will work
from here.)
I think we should try to get more precise in our description of
requirements than the above. And we need to detach the description of
the requirement from the implementation. In this sense "enhancing a
feature" is not a proper requirement.
Borrowing a little language from John Caron's helpful discussion today
our requirement might be:
"CF needs to be able to associate multiple alternative coordinate
systems ( "grid mappings") with a latitude/longitude/depth/time grid
and its associated variables. The number of grid mappings to be
supported needs to be arbitrary (0 or more) but fixed in the sense
that there will be no future requirement to expand the list.
After the discussions of implementations to address a requirement have
converged on a proposal (where we are at now) we need to have a
thoughtful discussion of cost/benefits. Can someone weigh in regarding
the benefit side of this requirement? Will it be commonplace to require
multiple grid mappings in some communities? In those communities are we
confident that the number of alternative grid mappings will remain fixed?
As you know I believe personally that the cost of added complexity, of
muddying concepts, etc. in CF is not given enough weight in our
discussions. Often we have a pressing need to create new files, but a
much vaguer future intention to create software to read those files, and
a vaguer still sense of our future users and scalability issues.
> That's a good summary. I agree. Sorry I wasn't clear in my contribution.
>
> Steve wrote
>
>>> The idea of the CF metadata
>>> is to _make the datasets self-describing_.
>>>
> Steve, your following argument seems to be against the idea of including
> projection coordinates at all, not just against the extension of the feature
> that Bert has requested. You could argue that since we require 2D lat and lon
> to be included, it would be better to provide external translators that could
> convert such 2D lat and lon into any projection coordinate system the user
> wanted, and not store the projection coordinates in the file. But that seems
> unhelpful to potential users of the file. Indeed, if they would prefer a
> projection different from any of those which the file has stored, they could
> always calculate it from lat and lon, but if the data-provider knows there
> is a projection(s) likely to be of use, is it not a good idea to store the
> projection coords in the file?
>
I did not participate in past discussions of grid mappings. I suspect
that the scope of those discussions was narrower than what we are
discussing now. With the range of requirements that is emerging in the
current discussion I might indeed have lobbied for an alternative
approach -- say, that the CF file might include a unique *identifier*
for a particular grid. This identifier would then be used to allow us
to define external resources (files) to perform all sorts of tricks --
regridding, alternative coordinate representations, grid-spec geometry
details, etc., etc. I'd note that we have already made a group
endorsement regarding the concept of an external resource file to
address the gridspec needs. That discussion remains immature. Isn't
there an argument to saying that we should not finalize a solution to
the current problem while such a large, related problem remains in flux?
As you can see, my discomfort is not with the proposal, itself. My
concern is that we move towards a CF process that can manage an
ever-increasing level of complexity and scope of demands from users.
(On a personal note, it is very much _*not *_a fun position to be the
lone voice crying "whoa". If I am indeed the only one who is concerned
that we are moving with undue haste making changes in CF, I will back
away from it. This should be a first-order-of-business topic for the CF
conventions committee.)
- Steve
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061201/8433185f/attachment-0002.html>
Received on Fri Dec 01 2006 - 12:49:52 GMT
