Version 5 (modified by jonathan, 13 years ago) (diff)


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 auxiliary coordinate variables.

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.