This message came from the CF Trac system. Do not reply. Instead, enter your
comments in the CF Trac system at http://kitt.llnl.gov/trac/.
#107: CF Data Model 1.7
-----------------------------+------------------------------
Reporter: markh | Owner: cf-conventions@…
Type: task | Status: new
Priority: medium | Milestone:
Component: cf-conventions | Version:
Resolution: | Keywords:
-----------------------------+------------------------------
\
\
\
\
\
\
Comment (by biard):
Replying to [comment:74 jonathan]:
> Dear Jim
>
> Replying to [comment:71 biard]:
> > I think you've put your finger directly on the disagreement I have
with your approach. As I look at it, grid_mapping does not do the thing
you describe in point 1 [''i.e. georeferencing''], and formula_terms is
not involved with the thing you describe in point 2 [''i.e. defining a
geophysical surface''].
>
> 1. Latitude and longitude are implicitly georeferenced - not
precisely, without stating the ellipsoid, but with sufficient definition
for many purposes, especially in the spherical GCM world. Projection
coordinates on a Cartesian plane, however, are not at all georeferenced
without the projection information. The `grid_mapping` provides that
information.
>
> 2. Vertical coordinates in CF, identified by `standard_names`, are
referred to a geophysically defined surface e.g.
`height_above_reference_ellipsoid`. For some purposes, it may be necessary
to specify precisely what that surface is. We cannot currently do this in
CF for vertical coordinates, but I think it is highly likely that we will
want to do it, since the issue has already been raised. We could do it
using a `grid_mapping`, and then a vertical coordinate would require both
`formula_terms` and `grid_mapping` for precise georeferencing.
>
> In summary, both `grid_mapping` and `formula_terms` have function (1),
for different kinds of coordinate. `grid_mapping` has function (2), which
is currently allowed only for horizontal coordinates. This mismatch
between purposes and CF-netCDF constructs arises from the history of the
convention. If we were starting from scratch, I think we would have a
netCDF construct like `grid_mapping`, but extended, for both horizontal
and vertical coordinates, and that would simpler. Essentially, that is
what we are proposing for the logical data model.
>
> Cheers
>
> Jonathan
Jonathan,
I can see your point about latitude and longitude being coarsely
georeferenced (assuming they aren't rotated), and it's quite clear that in
the history of all this, it was assumed that lat, lon, and height were de
facto georeferenced. This was, clearly, ''good enough'' for the GCM world.
Working from this background, it's easy to see why grid_mapping was
thought of as a transform. I don't, however, think it's a good idea to
continue to think of it this way. I'm in full agreement that grid_mapping
needs to be extended to allow definition of a fully 3D CRS.
Regarding your inclusions ["i.e. georeferencing"] and ["i.e. defining a
geophysical surface"] in your reply to my reply (to your reply...):
Grid_mapping does accomplish georeferencing. It georeferences all the the
georeferenceable coordinate variables, both X/Y and lon/lat, assuming it
declares a projected or Cartesian CRS. (If it's a lon/lat CRS, then there
won't be any X/Y coordinate variables.)
Formula_terms doesn't define a geophysical surface. As stated in the CF
standard formula_terms provides "a mapping between the dimensionless
coordinate values and dimensional values that '''can be''' uniquely
located with respect to a point on the earth's surface." (Emphasis mine.)
The output of applying formula_terms is georeferenceable. This input
isn't.
This is what it boils down to in my view:
The contents of a variable that are dimensionless vertical coordinate
values are not, themselves, georeferenceable (sigma coordinates, etc).
They can be used as one of the inputs to the transform/function declared
by the formula_terms attribute, and the outputs are georeferenceable. The
outputs require a declaration of the CRS used in order to fix their
locations relative to the body of the Earth. The historical view of the
output values was that they were implicitly georeferenced, which was
considered good enough for many purposes, and often was/is.
The contents of a variable that are horizontal projection coordinate
values are, themselves, georeferenceable. They require a declaration of
the CRS used in order to fix their locations relative to the body of the
Earth. Longitudes and latitudes within the declared CRS may be obtained
from the contents of a pair of X and Y coordinate variables using
transforms that are associated with, but not provided by the grid_mapping
associated with the X and Y coordinate variables.
The contents of a variable that are latitude or longitude values are,
themselves, georeferenceable. They require a declaration of the CRS used
in order to fix their locations relative to the body of the Earth. The
historical view of the values was that they were implicitly georeferenced,
which was considered good enough for many purposes, and often was/is.
If you don't assume that georeferenceable equates to georeferenced, then I
think it's clear that formula_terms does not equate to grid_mapping in
functionality. CRSs are a complicated topic, and there are subtleties and
variations that the above descriptions gloss over (as we've seen from the
CRS discussions), but I don't think any of those variations negate the
point that formula_terms transforms non-georeferenceable values into
georeferenceable values, while grid_mapping (if I, for the sake of
argument, accept the premise) bidirectionally transforms one set of
georeferenceable values into another set of georeferenceable values.
Even if you had used the dummy variable formalism for formula_terms (which
would have been great!), it wouldn't make formula_terms any more
equivalent logically to grid_mapping.
Grace and peace,
Jim
\
\
\
--
Ticket URL: <http://kitt.llnl.gov/trac/ticket/107#comment:77>
CF Metadata <http://cf-convention.github.io/>
CF Metadata
This message came from the CF Trac system. To unsubscribe, without
unsubscribing to the regular cf-metadata list, send a message to
"[email protected]" with "unsubscribe cf-metadata" in the body of your
message.
