Hi,
Since I'm name-checked in this thread I thought I ought to chip in with
my 2 cents worth.
FWIW, I'd make the following observations (some of which reiterate other
contributions):
* I don't think that the 'grid_mapping' attribute (and its associated
variable) is the right place to encode this information. In the case of
in situ observations/measurements, for example, presumably it would be
quite normal to want to provide geoid and/or reference datum metadata
that has little or no relevance to grids or grid mappings (i.e. in the
map projection sense).
* We could encode geoid metadata in an attribute called, say,
'geoid_name' or 'geoid_id', at either the global or variable level. As
already discussed this would identify a well-known geoid, the details of
which would need to be determined from external sources.
* We could encode vertical datum metadata in an attribute called, say,
'vertical_datum_name' or 'vertical_datum_id', again at either the global
or variable level, the latter overriding the former. As before, this
attribute would identify a well-known datum, defined externally to CF.
* Where appropriate, we might consider encoding a local datum offset to
an agreed reference datum (the WGS 1984 datum perhaps?) in the same way
as is currently done for WGS 84-related lat-long coords. This we could
do using an attribute called, say, 'vertical_offset_from_wgs1984_datum'.
Of course, this would only make sense in the simple case of a constant
offset (I have no feeling for how common or rare this scenario is -
presumably the relationship between different vertical datums is
decidedly non-trivial).
* If we don't like the idea of attaching the above attributes to
individual variables then we could collect them together in a
'container' CRS attribute & variable as per the 'grid_mapping' attribute
& variable. This was my preferred approach when compiling my original
Trac ticket (#9). However, in order to reach agreement on the core
aspects of that ticket, it was decided to keep them within the existing
grid mapping container.
* If the 'grid_mapping' attribute is intended to encapsulate all things
CRS then we should consider renaming it (e.g. 'crs_definition').
* IMO, pulling together a coherent proposal covering the desired facets
of horizontal and vertical coordinate reference systems will likely take
a suitably-knowledgeable person 3 months work, possibly more. Does
anyone have that kind of time to spare?
* As mentioned in a previous posting, I believe that these (and some
other key) updates might best be addressed by a small team of technical
experts producing a draft CF 2.0 specification. I'm not convinced that
the current Trac discussion mechanism would work successfully for such a
large proposal (the fragmentation of the 'common concept' proposal
illustrates the problem here).
* The suggestions above run counter to current 'CF philosophy' in that
(i) CF/netCDF files would not necessarily be self-describing; (ii) we
would be introducing changes to the CF conventions which anticipate
future rather than immediate requirements. As a community are we willing
to go down this route?
Regards
Phil
On Mon, 2008-09-29 at 09:10 +0100, Jonathan Gregory wrote:
> Dear Ethan
>
> I agree that different definitions of the reference ellipsoid do not constitute
> different geophysical quantities. Likewise different definitions of the geoid
> all give the same geophysical quantity. Therefore I agree that the geoid should
> be identified as part of the CRS (naming it in the grid_mapping would be
> convenient), just as the ellipsoid is identified as part of the CRS (we added
> the parameters specifying the ellipsoid to the grid_mapping as part of Phil
> Bentley's change to the conventions). I agree too that the definition of the
> vertical CRS is relevant both to coordinate variables and data variables. That
> is another reason why it would make sense to put it in the grid_mapping.
>
<snip>
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20080929/a925e4ef/attachment-0002.html>
Received on Mon Sep 29 2008 - 08:18:09 BST
