Jonathan Gregory wrote:
> Dear Steve
>
> I think your comment belongs more in the thread about the projections than
> about the process of approving changes. :-) The points you raise are
> interesting, but I can't see how provisional status or test implementations
> would help us to answer such questions in any way that thinking and talking,
> before we make an agreement, already does.
>
> Supporting more than one projection as Bert would like do increases
> interoperability, rather than reducing it, as far as I can see. Firstly, the
> files still contain the required 2D lat and lon, so any application can
> locate the data without understanding the grid mappings. Secondly, the two
> grid mappings might well be the same kind of projection, just with different
> parameters, and Bert was asking for a way to store this, rather than for new
> kind of projection. Thirdly, providing the projection coordinates in the
> systems supported by two different countries makes the files usable in both
> places without either having to write software to support the other. If you
> provide N projections, that is actually less work than N(N-1)/2 systems of
> translation between the projections. I hope that's a correct summary of Bert's
> aims.
>
Hi Jonathan,
What is lacking in this discussion (and is a general issue we should
address in our process) is a clear statement of the requirements that
are being addressed. My reservations might evaporate if we shared an
agreement that we were working towards addressing a well-stated
requirement. ... and if we then concluded our discussions with an
assessment that the increased generality and interoperability to be
achieved warranted the increased complexity in CF.
As stated, though, I heartily disagree with the analysis above. Of
course it is correct if you envision the simplest case -- a tightly
controlled and unchanging group of data providers and users. Say, two
different user groups each using a different projection. They can
readily use the proposed machinery to create files that are
interoperable. But this outlook seems insufficient for long term, broad
interoperability. What happens in the preceding scenario when an
unanticipated new member joins the group? New files will now need to
contain 3 projections. _All of the legacy files will lack the desired
interoperability properties._ We would have been better off to have
placed the translation information into a resource that is external to
the CF files. Then we need only modify that single resource to achieve
interoperability among all of the legacy files. (A single file could
guide the mapping between an arbitrary N alternative projections.)
This is an example of a more general issue. The idea of the CF metadata
is to _make the datasets self-describing_. When we start to talk about
translations between alternative coordinate representations, we are
talking about two outlooks rather than one -- a native view of
coordinates and a target view of coordinates. A CF file can describe
itself thoroughly. But it cannot describe all possible alternative
viewpoints, because (in general) that is an extensible list. This has
arisen before in discussions of regridding. Similarly in that case, it
would not be appropriate to embed pre-computed gridspec information that
supported regridding from native to target grid into the CF file,
because that would presume that there will only ever be a single, unique
target grid. Better to place this into an external resource. (The
notion of "native" and "target" will seem arbitrary in cases where the
alternative coordinate representation have equal status, but that point
is a kind of hair-splitting from the perspective of CF implementation.)
Considering Bert's situation in particular (please correct me if I get
this wrong, Bert) -- if he is absolutely clear that there are two and
exactly two (forever) different parameters/projections to be
represented, and he wants to embed content metadata content to help the
these two known and fixed user groups achieve interoperability, of
course he should do so. CF does not prevent him from doing so. It
would be simple for him to define a new attribute or two that would
provide the custom metadata he needs. But stability and simplicity have
to be very high priority considerations in guiding the evolution of CF.
I am not (yet) convinced that we have identified a requirement that
merits an extension to CF, itself.
Can you state the requirement in terms that represent this as a more
general problem? ... and address details like whether the list of
candidate projections must be guaranteed to be rigidly fixed.
- 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/20061130/574a35df/attachment-0002.html>
Received on Thu Nov 30 2006 - 12:10:00 GMT
