⇐ ⇒

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

From: Tom Kunicki <tkunicki>
Date: Mon, 1 Aug 2011 12:42:47 -0500

Heiko,

Comments below.

On Aug 1, 2011, at 2:56 AM, Heiko Klein wrote:

> 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.

I believe you are referencing the Bursa Wolf parameters needed to allow use of the a more accurate intra-datum transformation. This is not currently supported in CF and it would be nice if it was.

>
> * 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.

lat/lon positions do change between datums, which include the specification of the ellipsoid and the position of the prime meridian relative to greenwich. For those hoping to store (and use!) data with adequate spatial resolution/certainty knowledge of the source datum is crucial.

To the CF group..

One thing to keep in mind is that people are using CF for data other than GCM output. When reference datum information is missing it's left to the user to track the information down. At any stage in the creation of CF compliant file, where datum information is known it *must* be inserted. Without this one is doing a disservice to the users of their data. I will acknowledge that many creators may not understand the importance of this information. But for many users attempting to utilize data without any reference to a datum is a big issue and it shouldn't be ignored. If the user wants to ignore the information based on their usage of the data that's their prerogative. By not including it you are not giving your users a choice.

Tom

>
> 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
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Mon Aug 01 2011 - 11:42:47 BST

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

⇐ ⇒