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 markh):
Replying to [comment:79 jonathan]:
Hello Jonathan
> 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,
I can see that this can be done, the important question for me is should
it be done?
Where are the benefits and where are the costs?
I do not perceive the benefits of this conflation to form a new
`geolocation` type, based on the comments to date.
This conflation is quite a jump from the current CF conventions
terminology, which concerns me; I think it is difficult to explain.
> 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.
A particular benefit I see in having two separate concepts in the CF data
model is interoperability with other domains and concepts.
If a concept in the CF data model cleanly and clearly relates to a concept
in another domain then this is a big supporting factor for
interoperability.
I think this is the case here: the georeferencing capability provided by a
coordinate reference system type of thing in CF is very closely aligned to
the ISO19111 definition of a coordinate reference system. This brings
huge benefits in providing interoperability with other ISO aware
communities, such as the OGC, as highlighted by [comment:80 edavis]. I
think this is the approach Stefano has taken with the OGC to date. The
documents he has written link grid_mapping variables to OGC CRS instances.
The derivation of coordinate values, perhaps for georeferencing purposes,
based on bespoke defined algorithms and reference data sets is a much more
specialised field, which is not widely used in the ISO and OGC communities
(for example).
Conflating the well known georeferencing function of coordinate reference
systems with these derived coordinate functionality in a single data model
type is making it very hard for that type to be understood and used
effectively by other communities.
It also makes it much harder for CF to adopt useful building blocks for
other communities, as the interfaces are all in different places.
So, the cost of the approach of conflating these concepts is it isolates
the CF community from other communities, just when we and they stand to
benefit so much from better interoperability.
The benefit has to significantly outweigh this cost, and I am afraid I
cannot see this.
With this in mind I strongly favour the separation of these concepts
within the data model. Whilst they can be logically conflated, I think
the cost is prohibitive and the benefit minimal.
all the best
mark
\
\
\
--
Ticket URL: <http://kitt.llnl.gov/trac/ticket/107#comment:82>
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.
