Hi Philip, > This situation is especially pertinent to the complex realm of coordinate > reference systems, where it is difficult to focus on one particular facet - > vertical coordinate systems, say - without also having to consider other > facets - horizontal coordinate systems, geodetic datums, ellipsoids, > projections, and so on. It's an all-or-nothing kind of problem domain.
This is a very good point - in fact ISO 19111 says that you can't separate horizontal and vertical CRSs in some cases. I'm wary of making such proposals myself because I frankly don't understand all the issues properly (we need some geodesists or GIS experts or something). So it's a tricky one. Cheers, Jon On Thu, Aug 7, 2008 at 5:48 PM, Philip Bentley <[EMAIL PROTECTED]> wrote: > Hi Jonathan et al, > > (2) Precision about *which* real-Earth reference ellipsoid or geoid is > meant. > As others have said, this is related to the definition of the horizontal > coordinate reference system. It has been raised several times before, and we > deferred it from the discussion of Phil Bentley's ticket in order to limit > the > scope of the discussion and because it appeared no-one had time to formulate > and describe a proposal to deal with the vertical aspects of the datum. > > A significant CF governance/evolution issue here - one that I ran up hard > against when formulating trac proposals #9 and #18 - is that, in attempting > to put forward a proposal to address CF requirements A, B, and C, one > anticipates closely allied *future* requirements X, Y, and Z. Yet the > current CF 'philosophy', as I understand it, is to avoid introducing new > features until there is an identified and immediate need for them. > > This situation is especially pertinent to the complex realm of coordinate > reference systems, where it is difficult to focus on one particular facet - > vertical coordinate systems, say - without also having to consider other > facets - horizontal coordinate systems, geodetic datums, ellipsoids, > projections, and so on. It's an all-or-nothing kind of problem domain. > > This conflict between wanting to make manageable, incremental progress [on > the CF conventions] and wanting to put forward holistic solutions that > address a range of current and anticipated requirements, has IMHO yet to be > resolved. Personally I would like to see the latter approach trialled, if > nothing else, by implementing some of the larger-scale changes (CRSs, common > concept bundles, namespace support, etc) into a CF 2.0 candidate release. > Existing CF-compliant software can then continue to work against the CF 1.x > specifications. > > this. The geoid model is too complicated to be specified by CF metadata, so > I > think it would have to be named in some way. > > Ah, I see, so netCDF files don't always have to be self-describing then :-)) > > Regards, > Phil > > _______________________________________________ > 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 > > -- -------------------------------------------------------------- Dr Jon Blower Tel: +44 118 378 5213 (direct line) Technical Director Tel: +44 118 378 8741 (ESSC) Reading e-Science Centre Fax: +44 118 378 6413 ESSC Email: [EMAIL PROTECTED] University of Reading 3 Earley Gate Reading RG6 6AL, UK -------------------------------------------------------------- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
