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

From: Heiko Klein <Heiko.Klein>
Date: Thu, 04 Aug 2011 08:55:28 +0200

Dear Phil,

a programmer has usually to decide if he accepts 'minor' problems with
the input or not. A program-user usually selects the program which
accepts most input. So a CF-processing program not accepting a dataset
without datum won't get very popular. Of course, a program allowing the
user to modify/correct the datum is even more popular.

The climate and forecast modellers used for a very long time a spherical
earth with a radius around 3671km (= GRS1980 Authalic Sphere, not the
GRS1980 ellipsoid). Therefore, all CF-processing programs I know assume
that spherical earth radius of that size (i.e. netcdf-java, ncview,
fimex). So, the proposed default is the de facto standard and I believe,
it is better to write it down than to keep it informal.

If datum information is merely an extension to CF, it will take very
long until it is accepted. If CF always comes with a datum,
data-providers will adapt more quickly, since a missing datum might be
an obvious error (high priority) rather than a missing extension (low
priority).


Setting a default for something previously undefined is very common. A
precedence which was the same amount of work (update of attributes) for
all non-english data-providers was the definition of UTF-8 as
character-encoding in netcdf-3.6.3 in ~2008.

Best regards,

Heiko

On 2011-08-03 15:48, Bentley, Philip wrote:
> Dear Heiko,
>
>> I hope CF could define a default datum, e.g. the GRS1980
>> Authalic Sphere, since this matches most closely with
>> existing software (netcdf-java). This would make live easier
>> for the software-developers who have to use something if
>> nothing is given.
>
> I'm not sure that defining a default datum for CF is the right way to go
> in this instance. I would have thought that if a particular piece of
> data analysis is at a resolution that requires a geodetic datum to be
> specified then, in absentia the actual one being defined in metadata,
> it's not clear to me that using some semi-arbitrary, and potentially
> invalid, default datum is any better than giving the user the
> opportunity to select the one s/he believes to be the most appropriate
> for the task in hand.
>
> The current CF conventions include a (fairly minimal) set of metadata
> attributes which can be used to describe the basic properties of the
> coordinate reference system associated with a given dataset. The onus
> then is on data producers to utilise those metadata attributes to
> describe their data to the fullest extent possible. Furthermore, other
> non-CF attributes may be used to augment the standard set - over time
> some of these additional attributes would no doubt find their way into
> the CF specification.
>
> Ultimately, if end-users consider that a given dataset has insufficient
> metadata to justify its use within a particular context, then they can
> always choose to ignore that dataset. With the passage of time - and in
> true Darwinian fashion - such datasets (and their producers) will find
> that they are increasingly disregarded/overlooked in analyses. Hopefully
> this would galvanise such data producers into improving the quality of
> their spatial metadata!
>
> Regards,
> Phil
>
>
> PS: if a default datum were to be encoded into the CF conventions, I'd
> imagine that the WGS84 datum would be the way to go rather than GRS80
> which, if I understand correctly, has somewhat more of a bias towards
> use over the North American continent. That said, I suspect the
> differences between the 2 datums are sufficiently small as to get lost
> in the underflow for many metocean research applications.
Received on Thu Aug 04 2011 - 00:55:28 BST