[CF-metadata] Horizontal Data Coordinate System Definition [long]

From: Jonathan Gregory <j.m.gregory>
Date: Mon, 21 Feb 2005 11:42:54 +0000

Dear All

I like the idea of making use of the definitions provided by EPSG for mappings
and ellipsoids. Their document defining the formulae looks useful too.

I can see the attraction of adopting a shorthand for mapping and ellipsoid
which is used by other software, but I'm not convinced that we should do that
for CF because

* only a subset of the CF community are users of GIS software, WMS servers
and MS Access. I'm not familiar with any of these, for instance, and I expect
I am typical of scientists working with GCMs. It would make CF less easily
usable, for those who are not, to tie ourselves to particular software.

* codes are not self-describing. We haven't used codes anywhere else in CF
because it means you can't understand the file without the code table, so we
prefer to use names. Of course, names may not provide *all* the necessary
information; you may still need reference documents such as the CF appendices
and the descriptions of standard names, but names do enable a human to get a
rough understanding of the contents of the file without such help.

So far CF is self-contained. When we have used information from elsewhere,
such as the projections, or the names for regions (from the NASA GCMD), we
have explicitly incorporated them in CF. The reason for that is that the other
sources haven't provided the detail or the self-consistency we needed. EPSG
is a large database. It might be difficult to choose a subset of it, and as
Rich says this could be inconvenient for the unfortunate user whose options
weren't included. But adopting it wholesale would means we would make CF
depend on EPSG continuing to maintain it, and we might expose CF to EPSG
making backward-incompatible changes.

How much work would it to be to extract a snapshot of EPSG listing the names
of all the ellipsoids, projections and their parameters? We could copy such a
snapshot into a CF appendix, and if the process was fairly automated we could
repeat it from time to time. If it works well, perhaps we could negotiate with
EPSG for them to supply exactly what we need. In making the snapshot, I would
favour continuing CF conventions in translating all names to lower case and
replacing spaces with underscores, for consistency of style. The snapshot
could give equivalences to EPSG codes (as we do with GRID and PCMDI codes for
standard names), and if we provide a machineable form of it, software of the
kind Rich mentioned could use it to translate. We would also have to resolve
any inconsistency with the projections we have already defined.

Rich and EPSG have clarified that projection and ellipsoid are different.
Hence we should add allow attributes defining the ellipsoid to be added to
any grid_mapping that needs them (name, semi-major axis, flattening).

With that clarification, it's not obvious to me why UTM needs to be a new
mapping. All we need is to say how the UTM zone number translates to the TM
parameters, don't we?

I'm going to be silent for a couple of weeks because of a conference.

Jonathan
Received on Mon Feb 21 2005 - 04:42:54 GMT