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@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
