⇐ ⇒

[CF-metadata] Question on metadata for coordinate reference systems

From: Bentley, Philip <philip.bentley>
Date: Mon, 26 Sep 2011 13:22:28 +0100

Hi Paul,
 



________________________________

        From: cf-metadata-bounces at cgd.ucar.edu
[mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Kennedy, Paul
        Sent: 24 September 2011 11:38
        To: cf-metadata at cgd.ucar.edu
        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
        

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110926/0cbca23f/attachment-0001.html>
Received on Mon Sep 26 2011 - 06:22:28 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒