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:70 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
Jonathan,
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, and formula_terms is not involved with the thing you
describe in point 2.
X/Y coordinates and lat/lon coordinates are just two types of coordinates.
Both need to be georeferenced. The grid_mapping doesn't describe a
transform. It declares the CRS that your coordinates are defined with
reference to - both X/Y and lat/lon. Formula_terms declares a transform -
one that takes unitless values as input (along with other inputs) and
outputs '''georeferenceable''' coordinate values. Continuing to insist
that the grid_mapping is a transform obfuscates what it is really needed
for (which isn't what you first thought), leading to confusion.
As for the headache, I have often found that when I model a system, if I
lump elements together that should be separate it comes back to cause
trouble later, forcing me to go back and refactor the model in order to
move forward. That's a headache.
Grace and peace,
Jim
\
\
\
--
Ticket URL: <http://kitt.llnl.gov/trac/ticket/107#comment:71>
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.
