wiki:MultipleProjectionsJonathan

Version 3 (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.

--Russ

I prefer my proposal (at the moment, anyway), which 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. The drawback is that the association between mapping and coordinates is made independently on every data variable, but this is consistent in principle with all the other kinds of coordinate system: we provide the same 1D coordinates or 2D lat-lon coordinates for every data variable that needs them.

In view of 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 same as formula_terms and cell_methods. Jonathan