Hi Steve,
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.
It seems (to me) like a good thing if CF allows producing a single file
that any CF compliant utility can process (because it contains lat/lon
coordinates) and that specialists in that data are happy with as well.
This avoids duplicating data in different files with different coordinate
systems.
Brian
On Thu, Nov 30, 2006 at 11:10:00AM -0800, Steve Hankin wrote:
>
>
> 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
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Nov 30 2006 - 18:14:07 GMT
