Version 7 (modified by russ, 13 years ago) (diff)

Adding an explanation responding to Jonathan's comment.

Back to MultipleProjections

Although this is the shortest proposed representation, it encodes information in new syntax in the grid_mapping attribute value that clients would have to parse. This specific syntax depends on a special use of the ":" character to indicate the preceding variable name is associated with a subsequent grid_mapping name. This would not work if a grid_mapping name included a ":" character, e.g. "EPSG19914:" instead of "EPSG19914". That may be far-fetched, but is the kind of detail adopting such specialized syntax would entail.

The other proposals use a list of blank-separated variable names in the value of attributes, but CF already assumes such syntax for the coordinates attribute, among others.

So I think the conciseness of this proposal comes at too high a cost, the acceptance of a new specialized syntax for grouping items in a list.


Proposal No 1 retains the grid mapping as an attribute of the data variable, as in the present standard, and introduces an alternative format for it, allowing it to specify the 2D projection coordinates in association with the grid mapping, for more than one projection. The advantage of this is that there is minimal change to the way the file is interpreted; the grid mapping is found in the same place as in the existing convention, which I think we have to retain because of backward compatibility, and needs only to be parsed in a new way.

Proposal No 2 was made following Russ's comments; perhaps it is better to introduce a new differently named attribute of the data variable rather than an alternative syntax. Then software would have to check for alternatives, but at least they'd still be in the same place. The syntax I have proposed is the similar to formula_terms and cell_methods. I don't think the point Russ raises above about the colon is quite right. The colon terminates the name of a variable in both these proposals. This is not restrictive because colon is not a permitted character in a netCDF variable name.

In both these proposals, the association between mapping and coordinates is made independently on every data variable. This is a drawback in that it is repetitive, but an advantage in that it is consistent in principle with all the other kinds of coordinate system: we provide the same 1D coordinates or 2D lat-lon auxiliary coordinates for every data variable that needs them. We haven't introduced the "coordinate system" as a free-standing concept in any of the commoner cases, so it strikes me as unnecessary and inconsistent to do it in this specialised case.


Jonathan is right that the proposed syntax is similar to the syntax for formula_terms and cell_methods, but I think in these grid_mapping Proposals there is a crucial difference. For formula_terms, the values are always of the form "term: variable", where the second element, variable, is the name of a netCDF variable. For cell_methods, the values are of the form "name: method", where the second element, method, is selected from a specified list (in Appendix E of the current CF Conventions). But in Proposal 1, the projection name such as "EPSG19914" is neither the name of a variable nor necessarily taken from a specified list in the CF Conventions, but is rather a name chosen by the data provider, perhaps from a large list of externally maintained projection names that might contain blanks, colons, or other special symbols, making parsing the grid_mapping attribute string potentially problematical. Perhaps I have misunderstood, or we would need to be explicit about requiring that the projection name be a simple name with no special characters that might cause parsing problems.