⇐ ⇒

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

From: Jon Blower <j.d.blower>
Date: Wed, 3 Aug 2011 15:20:34 +0000

OK, so this is a use case for an "unknown" (as opposed to a "deliberately unspecified") datum I guess?


> Almost certainly, but by a comparatively small number of individuals within an organisation I would guess.

All the more reason to encourage people to encode it in NetCDF files! ;-)

Jon

-----Original Message-----
From: Bentley, Philip [mailto:philip.bentley at metoffice.gov.uk]
Sent: 03 August 2011 16:18
To: Jon Blower; cf-metadata at cgd.ucar.edu
Subject: RE: [CF-metadata] the need to store lat/lon coordinates in a CF-compliant netCDF file

Hi Jon,

> I've been following this thread with great interest. For me it boils
> down to this question:
>
> - Is the datum always known by the data provider?

Almost certainly, but by a comparatively small number of individuals within an organisation I would guess. However - and here's the blocker - probably not by many/enough of the people who have the (let's be frank) unglamorous job of compiling metadata for large volumes of spatial data.

>
> If the answer is "yes" then I see no reason to omit the datum (and
> plenty of reasons to include it). If there *are* situations where the
> datum is genuinely unknown or undefined then we need to express this
> clearly too so users can beware.
>
> (Previous posts mentioned GCMs as possible situations where the datum
> is unknown - is this really true? Surely there is always a sphere
> with a known radius on which coordinates are based?)
>
That would be my assumption also - that the raw facts are always known.

In my experience the problem tends to be organisational rather than technical. Few organisations seem to employ staff whose lapel badge reads 'Spatial Metadata Operative'. Which is, I realise, a pretty lame excuse. Anyhows, I'm drifting off topic.

Cheers,
Phil
Received on Wed Aug 03 2011 - 09:20:34 BST

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

⇐ ⇒