Hi all:
If I understand the situation, a GCM, whether global or regional, always
has a datum. In the simple case, its just the radius of a spherical
earth. However, for current global models its typical that this datum
doesnt affect anything (presumably as long as its within the typical
range of values). Is that correct?
It seems that modelers are wary of downstream users incorrectly assuming
that the grid point locations have more precision than is warrented, and
possibly drawing incorrect conclusions about accuracy etc. Is that the case?
In performing transformations, software has to use a datum, and so will
make an assumption if the datum is missing. It would be nice if a human
was made aware of that assumption, but in practice this mostly wont happen.
If the above is correct, I would advocate a sentence in section X
something like:
/CF recommends that data providers always specify the datum. In the
simplest case, this just means adding a _latitude_longitude_// grid
mapping with the value of the spherical earth radius that was used in
the model. However, data users are cautioned not to infer unwarranted
precision of the model grid point locations when comparing to observations./
Or something like that, probably needs some tweaking.
John
On 7/28/2011 6:47 AM, David Blodgett wrote:
> Dear Jonathan, All,
>
> Coming from the perspective of a geographer, for CF to be "a
> convention whereby people can provide accurate and complete metadata
> for their data." Datum specification would be required.
>
> I understand that the normal practice in the climate science community
> is to throw out datum information from ingested ground based data as
> it is being applied to a model or summary product that essentially
> smears the measurement in space. So in fact, for strict accuracy of
> geolocation for course resolution low numerical accuracy applications,
> a datum may not add anything of value. Its clear I'm not going to win
> this argument by claiming that the status quo should not impose
> inaccuracy on the edge case.
>
> I hope that software developers do throw warnings when data has an
> unknown piece of information that is required to perform a geographic
> transformation. This lack of required information for processing is
> really the crux of the issue and why I have pushed it this far.
>
> In Chapter 4 (.1-.2) no recognition is given to the fact that latitude
> or longitude coordinates are essentially meaningless without the
> assumption of a datum, this recognition would go a long way to making
> me more comfortable with the spec. Something like the follows is may
> be warranted.
>
> /Data consumers should be aware that latitude and longitude
> coordinates lacking description of the ellipsoid shape and prime
> meridian, or datum, must be assumed to lie on any arbitrary datum. It
> should be understood that it is up to end users of such data to assign
> this information according to their best judgement. We recommend, when
> accurate grid geolocation is appropriate, for data producers or
> publishers to use a /_/latitude_longitude/_/ grid mapping as described
> in chapter 5.6./
> /
> /
> Cheers,
>
> Dave
>
>
> On Jul 28, 2011, at 5:00 AM, Jonathan Gregory wrote:
>
>> Dear Dave
>>
>> I sympathise with your concerns about the consequences of missing
>> datums but
>> I don't think CF can help a lot.
>>
>>> Are there any arguments against CF recommending a standard datum
>>> assumption when intersecting data without a datum specified with
>>> data that does have a datum specified?
>>
>> I don't think that's the role of CF. CF is a convention whereby
>> people can
>> provide accurate and complete metadata for their data. If the data
>> provider
>> doesn't have a real-world datum that could be specified, it is not
>> appropriate
>> for CF to suggest what it should be, I would argue. In fact, most
>> parts of CF
>> are optional. People may choose not to describe their data with
>> standard_names
>> for example. They are not mandatory, but of course it makes the data less
>> useful if they are not supplied. I think the best can be done, rather as
>> Balaji suggests, is for software that reads CF files to emit warnings
>> about
>> metadata which could have been included but isn't, so that analysts
>> are aware.
>>
>> Best wishes
>>
>> Jonathan
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110728/5f14672d/attachment-0001.html>
Received on Thu Jul 28 2011 - 07:29:54 BST
