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