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 jonathan):
Replying to [comment:68 biard]:
> 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.
Dear Jim
I don't think we misunderstand the problem. We have spent a long time
thinking about it. The applications of `grid_mapping` and `formula_terms`
are quite varied already, but (to restate my last posting), they have two
things in common: (1) They relate one set of coordinates to another set of
coordinates which CF/COARDS regards as geolocated (longitude, latitude and
height or pressure - pressure has a special status in CF/COARDS), (2) They
may need to refer to the reference ellipsoid or geoid (your contributions
on the email list helped to clarify that this need applies to both
vertical and horizontal coordinates).
We could have devised a convention to do the job of `formula_terms` with a
netCDF construction involving a dummy variable, like `grid_mapping`, but
we hadn't thought of that idea then (in the beginning of CF). If we had
chosen to do so then, these two constructions would already look formally
quite similar, I think, and then the idea of combining them might not
appear so surprising. I agree of course that we do not ''have'' to
represent these two parts of CF with a single logical construct, but I see
it as a simplification which would avoid some redundancy e.g. from (2)
above. Please could you explain what headache or confusion it will cause
you?
Cheers
Jonathan
\
\
\
--
Ticket URL: <http://kitt.llnl.gov/trac/ticket/107#comment:70>
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.
