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:66 jonathan]:
> Dear Jim and Mark
>
> `grid_mapping` and `formula_terms` look rather different in CF-netCDF,
but they do have a similar purpose. `formula_terms` tells you how to
translate the vertical coordinate variable into coordinate values which
"indicate the location of the data" (as it says in 4.3) in the vertical
dimension, in practice meaning height or depth with respect to a
geophysically defined reference surface, or pressure, which is (in some
cases) a reasonable proxy for height or depth. `grid_mapping` tells you
how to translate the horizontal coordinate variables into longitude and
latitude, which have a special status in CF for providing horizontal
location; as you know, we insist that it must be possible to locate the
data in lat-lon if it has horizontal dimensions.
>
> After `grid_mapping` was introduced, it was expanded to allow the
ellipsoid to be defined, and as a result of recent discussion I've
proposed it should allow the geoid to be identified too. At the moment,
the ellipsoid and geoid definition cannot be applied to vertical
coordinates, but it seems very likely this will become desirable, also as
a result of recent discussions. For example, we can specify a vertical
coordinate as height above the geoid, but we cannot specify precisely what
the geoid is for the vertical coordinate, unless we allow `grid_mapping`
to do that. So, in this respect too, vertical and horizontal coordinates
will require similar treatment.
>
> Given these two sorts of similarity, it seems logical to us that we
should describe the two CF-netCDF mechanisms as different applications of
the same logical construct. It doesn't matter that they are formally
different. The formal difference arises partly because `formula_terms`
applies to only one dimension but `grid_mapping` to two dimensions, and
partly because they were designed at different times without seeing the
larger picture. In writing down the logical model, we can take a step back
to see that larger picture, and make it simpler as a result.
>
> Cheers
>
> Jonathan
Jonathan,
The two elements have almost nothing whatsoever to do with each other,
except in that they both deal (on entirely different levels) with
coordinate data. I understand that you guys thought that there was back
in the day, but I am convinced that this was an example of
misunderstanding the problem space.
I see no damage being done by properly separating these two constructs in
the data model, and great potential for better understanding and future
growth. If we force the two concepts into a single construct, we will be
making an "ad hoc aggregation" within the data model that is confusing and
will cause headaches moving forward.
Grace and peace,
Jim
\
\
\
--
Ticket URL: <http://kitt.llnl.gov/trac/ticket/107#comment:68>
CF Metadata <http://kitt.llnl.gov/>
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.
