Hi Jon,
It seems to me that this is an example that may serve to illustrate the
importance of implementation and testing in "systems of realistic
complexity". You have pointed out that it is straightforward to see how
individual applications can interpret the proposed files. That seems a
reasonable claim. But there has not been much discussion of whether
this approach will enhance or degrade community-wide interoperability
over the long term. Some exploration of that ....
I think what has been proposed here is that a given file may contain an
arbitrary number of distinct "projection coordinates". Is this the best
way to achieve broad interoperability in the long term? At first
analysis, I have my doubts. Imagine just two sets of projection
coordinates "A" and "B", If we have three files that respectively
contain projection coordinate systems "A", "B" and "A&B", then neither
the "A"-sensitive applications nor the "B"-sensitive applications can
read all of the files. Extending this line of reasoning to broad
collections of files and many different sets of projection coordinates
and we have a frustrating situation where many files are not readable by
many applications.
As an alternative, how about an approach that takes the information
needed to translate between projection coordinate systems (and therefore
between files) out of the individual files? Then the translation
information may be regarded as interoperability resources to support
interoperability between any files that use either projection coordinate
"A" or "B". Could we envision ancillary files (somewhat in the spirit of
gridspec files) that contained the translations between alternative
projection coordinates?
By the way (stating the obvious), CF already allows all sorts of
non-standardized content to be put into files. So there is nothing to
prevent a group that has unique coordinate projection needs from
embedding that content into the files they generate. The discussion in
this email thread is that if we are going to support projection
translations as a fundamental CF concept, then how do we do it in a way
that scales well to many files and many projection coordinate systems.
- Steve
================================================
Jonathan Gregory wrote:
> Dear all
>
> I just made the point below in the thread about 2D projection coordinates.
> I should not have put it there, because it complicates the threads! Sorry.
>
> That thread (on curvilinear Cartesian coordinates) this is an instance of how
> we have generally developed conventions by discussion. It is not obvious to me
> that trial implementations would help. We have written examples of both
> schemes, and as humans we have no difficulty in interpreting them. Hence
> programs could be written to interpret them. The problem is sufficiently
> simple it seems unlikely we have made a fundamental error. As you say [Brian]
> opinions about which is "easier" depend partly on taste, rather than more
> objective criteria.
>
> I'm raising this example because I would like to get a better picture of
> what would be done during provisional status and the benefits it would bring.
> I can see advantages in having a period of reflection, and the necessity for
> example files, but I'm less clear about what "testing" is needed.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
Received on Wed Nov 29 2006 - 12:50:19 GMT
