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:79 jonathan]:
> Dear Jim
>
> Both `grid_mapping` and `formula_terms` can be described logically by
the [http://kitt.llnl.gov/trac/ticket/107?replyto=55#comment:55 text which
David posted]. For instance,
>
> * a vertical georeference construct might apply to an atmosphere
hybrid height coordinate, in which case it would contain the `a`
(dimensions of height) and `b` (dimensionless) auxiliary coordinate
constructs, a field of surface height above the geoid, the auxiliary
coordinate construct of height above the geoid (if it exists in the
dataset), and optionally the name of the geoid (if we permit this
extension). Its purpose is to relate the `a` and `b`, which by themselves
do not geolocate the data, to the height above the geoid, which is a
geophysically defined surface whose precise realisation might be specified
as well.
>
> * a horizontal georeference construct might apply to a rotated
latitude-longitude coordinate system, in which case it would contain the
rotated latitude and longitude coordinate constructs, the (unrotated,
geographical) latitude and longitude of the rotated pole, the auxiliary
coordinate constructs of latitude and longitude, and optionally the
definition of the reference ellipsoid. Its purpose is to relate the
rotated latitude and longitude, which by themselves do not geolocate the
data, to geographical latitude and longitude, which do geolocate the data,
optionally with the ellipsoid to make their definition more precise.
>
> What is to be gained in clarity or simplicity by regarding these two
things as distinct concepts? We don't talk about transforms or coordinate
reference systems because these terms have technical and sometimes
restrictive meanings, and therefore may make the description less clear.
>
> Best wishes
>
> Jonathan
Jonathan,
It's clear that we are not going to come to an agreement on this, and I'm
not the one bearing the burden of trying to write the model, so this will
be the last posting I'll make about the georeferencing construct. I think
that clarity and simplicity is exactly what you gain by keeping
formula_terms and grid_mapping as distinct concepts. Your avoidance of
talking about coordinate reference systems just makes the whole thing even
more unclear.
The formula_terms attribute, if not restricted to producing
georeferenceable values, could be easily used for non-georeferencing
purposes. It has no intrinsic affinity with georeferencing. Grid_mapping,
on the other hand, is clearly a georeferencing construct, and doesn't lend
itself to other uses. What greater clarity or simplicity is obtained by
coming up with a construct that attempts to put these two simple yet
different concepts into a single genericized one?
Grace and peace,
Jim
\
\
\
--
Ticket URL: <http://kitt.llnl.gov/trac/ticket/107#comment:81>
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.
