This message came from the CF Trac system. Do not reply. Instead, enter your comments in the CF Trac system at https://cf-pcmdi.llnl.gov/trac/.
#107: CF Data Model 1.7 -----------------------------+---------------------------------------------- Reporter: markh | Owner: [email protected] Type: task | Status: new Priority: medium | Milestone: Component: cf-conventions | Version: Resolution: | Keywords: -----------------------------+---------------------------------------------- Comment (by markh): Replying to [comment:20 davidhassell]: > The way I see it, the purpose of a coordinate construct is to geo-locate the data. If it contains enough metadata for its array values to do this, then that is fine. I don't think a horizontal spatial coordinate will ever contain enough metadata to geo-locate itself accurately without a coordinate reference system. It is the CRS that provides the geolocation for coordinate value. > If not then a transform construct provides the extra information needed by the coordinate construct to do that geo-location. Is this different to your coordinate reference system? The coordinate reference system is for geolocation, yes. > Perhaps the name "transform construct" is troublesome. If I recall correctly (?), we chose it because its practical purpose in the conventions is to record how one set of coordinates may be ''transformed'' into another set of (possibly more meaningful) coordinates. Note that whether the latter set exists, or not, is immaterial to the data model, as is the domain of the transformation (horizontal (grid_mapping), vertical (formula_terms), or anything else). To me transformation is one of many practical purposes of accurate geolocation. Another example might be calculating the distance between locations on the geoid. Early CF focussed on one particular use case, that of providing explicit latitude longitude coordinates where the coordinate variables are not. This is useful, no doubt, but it is one of many cases. So, whilst I can see the similarity between this case and the parameterised vertical coordinate, with both providing a derived coordinate (or two) as an output, I am not comfortable with all coordinate reference system use cases being handled this way. I think it helps clarity to have the CRS as an explicit type in the data model and to handle derived coordinates, be they vertical or horizontal, as a separate type. There's no problem with CF-NetCDF having a particular method of encoding this which is sensitive to its historical development. -- Ticket URL: <https://cf-pcmdi.llnl.gov/trac/ticket/107#comment:21> CF Metadata <http://cf-pcmdi.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.
