Hi Karl,
I'm not arguing that CF shouldn't support the many complicated grids
that modelers use to represent their data. My point is that the current
spec is so complicated that it is unlikely that there will ever be a
software library that supports all of the features. How does a data
provider know which of the conventions in CF are likely to have been
implemented by commonly used applications or libraries and which haven't
been implemented at all? Or, to be more concrete: say I use the
"auxiliary coordinate variables" convention; will most users be able to
correctly interpret my data? (It turns out that the answer is no -- both
Ferret and GrADS, two of the most commonly used applications, do not
interpret the data correctly.)
One way around this would be to define a (hopefully minimal) subset of
CF "features" that software would have to support to be considered CF
"compliant." This would serve two purposes: software developers would be
more likely to support this subset (nothing like a 70 page spec to scare
off a developer!), and data providers would have a reasonable
expectation that their data could be read by a wide variety of
applications. Nothing would prevent a data provider from using
conventions (i.e. complicated grids) that weren't in the subset; they
just wouldn't have the expectation that their data would be widely
accessible.
Another possibility is to not consider a new CF "feature" as final until
a software implementation exists that handles the semantics of the
conventions as expected. Maybe this is already part of the process (I'm
not familiar with the CF process rules).
Cheers, Joe
Karl Taylor wrote:
> Dear Joe,
>
> You are correct that most users do not know how to map data from a
> complex grid to a cartesian longitude x latitude grid, which is why
> the CMIP3 specs were written the way they were. Never-the-less this
> is not a desirable situation because whenever data is mapped to a
> different grid, information is lost, and certain types of analysis can
> no longer be performed accurately (e.g., computing a divergence). CF
> makes it possible to describe the most important traits of complex
> grids, and should facilitate the development of software that would
> automatically regrid data (preserving certain desirable
> characteristics) to any target grid. There is at least one reasonably
> general "regridding" tool with capability to do this (SCRIP, see
> http://public.lanl.gov/pwjones/ ), but at present I don't think it can
> harvest the metadata from a CF-compliant netCDF file and use it to
> generate the weights needed to map from one grid to another. Thus, the
> user must do this himself, which is considerable work.
>
> By the way for the next CMIP (CMIP5), which will serve the AR5, it is
> expected that model output will be accepted on the native grids.
> Thus, there is an immediate need to begin developing user-friendly
> software that will indeed serve the purposes of users who want data on
> a longitude x latitude grid. One proposal is to require modeling
> groups to supply the "mapping factors" (i.e., weights) needed by SCRIP
> to regrid to a longitude x latitude grid chosen by the contributing
> modeling group. A perhaps better solution is for someone to develop a
> software tool that allows the user to regrid the data to any target grid.
>
> The bottom line is that it is difficult for most researchers to make
> use of data not on longitude x latitude grids, but I don't think this
> is an argument for not allowing modeling groups to store their data in
> a way that has fundamental advantages (i.e., on the native grid). We
> simply need to develop a tool that allows the grid meta-data to be
> interpreted by SCRIP, which I think could be done with less than 1
> person-year of effort.
>
> If this isn't done, the data contributed to the CMIP5 archive on
> non-cartesian longitude x latitude grids will be of marginal value.
>
> Best regards,
> Karl
>
>
>
> Joe Sirott wrote:
>> Hi all,
>>
>> I was wondering if anyone involved in the CF process knows of any
>> software libraries that are completely CF 1.2 compliant. I know that
>> from my point of view -- as a software developer who develops
>> software that must be able to read a wide variety of geophysical data
>> formats -- it has been impossible to keep up with the increasingly
>> complex conventions in the specification. It would be very helpful if
>> I had access to a library that fully supported the semantics in the
>> CF conventions (such as projections from CF allowed coordinate system
>> to lat/lon space).
>>
>> I'm guessing (and hoping that I'm wrong) that this software doesn't
>> exist. In fact, it seems that the main focus of the CF conventions
>> process has been on the needs of data /providers/ rather than data
>> /consumers/. There is an inherent conflict between the two groups --
>> a modeler wants to write data using the coordinate system of his
>> model while a data consumer would prefer that the data be in a
>> standard lat/lon coordinate system. The CF conventions clearly are
>> biased in favor of the provider, and while the full conventions might
>> be suitable for data sharing in a small, specialized modeling group
>> they don't work well for interdisciplinary data sharing.
>>
>> So, I'm wondering if it would be possible to come up with a subset of
>> CF conventions that would suit the needs of consumers rather than
>> providers -- a set of conventions where it would be practical for
>> programmers to develop (and share) code to interpret data formatted
>> according to the conventions and that would establish guidelines for
>> data providers who wanted their data to be widely accessible. A model
>> (no pun intended!) for this would be the data submission standards
>> <http://www-pcmdi.llnl.gov/ipcc/IPCC_output_requirements.htm>established
>> for submission of data to the CMIP3 archive of IPCC AR4 model data.
>> For example, that archive required that modelers interpolate their
>> data to a lat/lon grid before the data would be accepted.
>>
>> - Joe S.
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu May 22 2008 - 18:48:43 BST
