Hi While the EPSG code is very simple to implement, I understand and agree with the fundamental notion of self description.
Crs_wkt will work for us just as well as EPSG code. The biggest wkt I have seen is 32kB. As you can imagine, way too many parameters to describe in individual attribs. Best leave that to the experts in that field. I would fully support wkt. Regards ----- Original Message ----- From: [email protected] <[email protected]> To: Kennedy, Paul; [email protected] <[email protected]> Sent: Mon Sep 26 20:22:28 2011 Subject: Re: [CF-metadata] Question on metadata for coordinate referencesystems Hi Paul, ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Kennedy, Paul Sent: 24 September 2011 11:38 To: [email protected] Subject: [CF-metadata] Question on metadata for coordinate reference systems Hi, I have been trying to figure out the correct mechanism for the representation of coordinate reference system (CRS) metadata. I guess that the meaning of 'correct' depends on what end uses you envisaged for your particular dataset(s). In the most trivial case you might only need to indicate the radius of the sphere that was used to approximate the shape of the Earth. And for that one can use the existing 'earth_radius' attribute (attached to an appropriate grid mapping variable). For more complex coordinate systems, however, 'correct' may be harder to attain. In principle, though, one should endeavour to specify as many of the CRS-related CF attributes as possible that are applicable to your data. It is recognised that the current list of such attributes is a fairly limited subset of the complete set that would be required to fully define any particular CRS (from the infinity of possibilities!). I read the online documents for CF conventions. It talks about the definition of a few CRS's but there are many and some are highlt complex (eg NZ MapGrid). While we could attempt to define attributes for all parameters in a given CRS this is a complex matter and is probably better handled by existing standards such as those in EPSG or PROJ (wkt). Can anyone provide guidance on this? As you say, definition of coordinate reference systems is a complex topic (beyond the obvious trivial cases, that is). IMHO, it seems unlikely - and probably undesirable - that the CF specification will ever support a full implementation of the OGC/EPSG data model for CRS's. Consequently I agree that a better approach is to adopt an existing CRS encoding standard, and the CRS Well Known Text (CRS WKT) format is the obvious candidate in this respect. (I'm aware also that this method is being used informally by some data producers and software vendors.) Originally devised by POSC (Petrotechnical Open Software Consortium), my current understanding is that the CRS WKT specification now falls under the custodianship of the OGC. Which I reckon is a positive development. As part of my earlier CF trac ticket submissions (9 and 18) I proposed that an optional 'crs_wkt' attribute may be attached to a grid_mapping variable in order to provide additional details about the corresponding CRS. At the time use of this particular attribute didn't get endorsed. However, the recent spike in posts regarding CRS's on the CF mailing list suggests that this proposal may now have broader support. If that is the case, and if someone from the CF community is willing to act as ticket moderator, then I'd be happy to compose a trac ticket proposing the addition of an optional 'crs_wkt' grid mapping attribute. In my perfect world we could simply drop in a 5 digit EPSG code and we are done. This idea was also discussed in my earlier trac ticket proposals. However, the use of attributes to record EPSG codes was also rejected at the time on the basis that they infringe the 'self-describing files' rule imposed upon CF metadata. Personally I'd have no objection to the use of such optional attributes. However, there are numeric codes for many different types of entity in the OGC/EPSG data model, so it would be necessary to agree which of these should be included. The attraction of the CRS WKT route is that that method is, for the most part, self-describing. It merely enables the compact definition of multiple CRS properties in a single netCDF text attribute, rather than several separate ones. As always, you (or your organisation) are free to use any or all of these techniques without breaking CF compliance... assuming that your files are indeed CF-compliant in other respects! Regards, Phil
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
