Hi Phil,
Philip Bentley wrote:
> 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.
I agree with all your above points.
I prefer the idea in your last point of a new container variable for
holding vertical CRS attributes. It should give us a bit more
flexibility than one or more global or variable attributes would provide
and it will better allow for any unforeseen complexity. I'm not sure
about how to contain transformation/offset data or just a relationship
between a vertical coordinate variable and a vertical auxiliary
coordinate variable.
Allowing some explicit connection between a vertical coordinate variable
and an auxiliary coordinate variable seems related to your notion of
trying to map to a standard vertical CRS like WGS84 geoid.
> * If the 'grid_mapping' attribute is intended to encapsulate all
> things CRS then we should consider renaming it (e.g. 'crs_definition').
If I'm understanding what you mean here, I would prefer to keep the
current correspondence between grid mapping and horizontal CRS. So maybe
horizontal_crs_definition?
Keeping vertical CRS separate would allow for combining horizontal and
vertical CRS in a single file in different ways to describe different
3-D CRS. [We deal with a lot of data that has all/most variables on a
single horizontal CRS but different sets of variables are on different
vertical CRS. So that use case is always front and center for me.]
> * 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?
I agree this is a big job and can't imagine any of us individually can
spare all the time needed. However, I think the big challenge is to find
a few people to champion the issue and keep it moving forward (even if
slowly, hopefully not too slowly). If we don't have that, it won't
matter how the discussion is conducted. So, in that spirit, I will
commit to doing two things in the next two or three weeks: 1)
summarizing the conversation we've had up to this point; and 2) writing
a draft document that lists requirements and use cases from the
conversation so far. We can move on from there and hopefully not let the
effort flounder.
Ethan
--
Ethan R. Davis Telephone: (303) 497-8155
Software Engineer Fax: (303) 497-8690
UCAR Unidata Program Center E-mail: edavis at ucar.edu
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
---------------------------------------------------------------------------
Received on Mon Sep 29 2008 - 22:43:45 BST
