⇐ ⇒

[CF-metadata] the need to store lat/lon coordinates in a CF metadata compliant netCDF file

From: Heiko Klein <Heiko.Klein>
Date: Mon, 01 Aug 2011 09:56:24 +0200

Hi,

while trying to translate weather-model-data for the GIS community, and
as such translating CF-parameters to proj4 parameters, I recognized some
things:

* The latitude-longitude field does not give any additional information
to the grid-mapping. In fact, in most cases the latitude-longitude grid
is calculated from the grid-mapping by the models. (Well, in fact the
model don't output CF at all, but The grib-format only gives the
grid-mappings).

* I didn't manage to describe a complete datum in CF 1.5. I'm only able
to describe the ellipsoid, but not the reference point, i.e. the +towgs
parameters in proj4.

* and aren't the latitude-longitude positions not changing with the
ellipsoid, too? It's nowhere stated in CF that the lat-lon coordinates
are WGS84 geodetic coordinates.

Heiko

On 2011-07-28 15:29, John Caron wrote:
> 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
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

-- 
Dr. Heiko Klein                              Tel. + 47 22 96 32 58
Development Section / IT Department          Fax. + 47 22 69 63 55
Norwegian Meteorological Institute           http://www.met.no
P.O. Box 43 Blindern  0313 Oslo NORWAY
Received on Mon Aug 01 2011 - 01:56:24 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒