I think this is good summary. More comments below:
On 8/4/2011 5:15 AM, Jon Blower wrote:
Hi Jonathan, all,
There is lots of important metadata which is optional, such as standard names
I think the case of a missing datum is different from the case of a missing
standard name. In order to plot data in a GIS (or similar system that allows
different datasets to be compared or overlain spatially) you *always* need a
datum. If one isn't supplied by the data provider, the user or client software
has to invent or guess one. That's not true for a standard name (although
arguably it is true for the coordinate bounds).
Not just GIS, any operation which involves data integration needs to
bring all the data sets in question to a common reference frame and when
it comes to spatial reference frame, datum is absolutely crucial. Data
integration is the keyword here. Without datum, the dataset is less
significant for data integration. If the data provider expects the data
to be used in any such operation, datum should be provided. Of course,
there are situations when datum is genuinely not known even to the data
provider. In such situations, I think it should be data provider who
should be guessing the datum after due diligence, not the user.
Upendra
Hence Heiko's comment about what ncWMS does - in fact ncWMS assumes WGS84 for
lat-lon coordinates, but perhaps it should assume something different. It
*does* make a difference in lots of cases - both model and obs data.
It seems we're all agreeing that CF should at least have the right tags to
ensure that a datum *can* be well specified, for 1D grid coordinates, projected
grid coordinates, 2D curvilinear grid coordinates and geolocation of
observations. Would you agree?
What seems to be under debate is to what happens when the datum is genuinely
(and regrettably) not known or incompletely specified (or perhaps where the
dataset has been derived from mixed datums). The proposals seem to be:
1. Rule this out of scope for CF and don't provide any datum information at all.
2. Invent CF tags that explicitly say the datum is unknown, and perhaps provide
a reason (to give the user a bit more information for his/her interpretation).
3. Specify a default datum (noting that client software or the user will
commonly have to invent one anyway).
Is this a fair summary of the situation?
Best wishes,
Jon
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Jonathan Gregory
Sent: 04 August 2011 08:23
To: [email protected]
Subject: Re: [CF-metadata] the need to store lat/lon coordinates in a
CF-compliant netCDF file
Dear all
I agree with Balaji about this:
It is perfectly possible to configure a GCM out of components with
inconsistent datums.
...
I still feel my principal objection to specifying the datum is the
implication of precision that does not exist.
This kind of argument may apply more to models, but it appears from the
comments that it might apply to obs datasets as well, for instance when they
have been assembled from various sources, which could be poorly documented.
Hence in terms of John's questions, I think this is good:
1) possible recommendations by CF to always include the datum, and
making sure we have the right metadata to do so.
We could make a recommendation in the standard document to include the
grid_mapping, if there is an applicable one, whenever there are horizontal
coordinates. The CF checker would then produce a warning if the grid_mapping
was absent. But I don't think it is the role of CF to include:
2) possible recommendations by CF as to what to do if the datum is not
present, or is only partially specified.
CF is a convention for allowing metadata to be provided. Its purpose is not to
prescribe or guess what the metadata should be. There is lots of important
metadata which is optional, such as standard names and bounds, and we do not
recommend what should be done when they are missing.
Cheers
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
