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: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
> Sent: 04 August 2011 08:23
> To: cf-metadata at cgd.ucar.edu
> 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
> 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
Received on Thu Aug 04 2011 - 08:18:53 BST
