Changes between Version 4 and Version 5 of MultipleProjectionsJonathan


Ignore:
Timestamp:
12/28/06 14:48:54 (12 years ago)
Author:
jonathan
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MultipleProjectionsJonathan

    v4 v5  
    99--Russ
    1010
    11 I prefer my proposal (at the moment, anyway), which retains the grid mapping as an attribute of the data
     11Proposal No 1 retains the grid mapping as an attribute of the data
    1212variable, as in the present standard, and introduces an alternative format for
    1313it, allowing it to specify the 2D projection coordinates in association with
     
    1616found in the same place as in the existing convention, which I think we have
    1717to retain because of backward compatibility, and needs only to be parsed in a
    18 new way. The
    19 drawback is that the association between mapping and coordinates is made
    20 independently on every data variable, but this is consistent in principle with
     18new way.
     19
     20Proposal No 2 was made following Russ's comments; perhaps it is better to
     21introduce 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.
     22
     23In both these proposals, the association between mapping and coordinates is made
     24independently on every data variable. This is a drawback in that it is repetitive, but an advantage
     25in that it is consistent in principle with
    2126all the other kinds of coordinate system: we provide the same 1D coordinates or
    22 2D lat-lon coordinates for every data variable that needs them.
     272D lat-lon auxiliary coordinates for every data variable that needs them. We haven't introduced
     28the "coordinate system" as a free-standing concept in any of the commoner cases, so it strikes me as
     29unnecessary and inconsistent to do it in this specialised case.
    2330
    24 In view of Russ's comments, perhaps it is better to
    25 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. I don't think the point Russ raises above about the colon is quite right; the colon terminates the name of auxiliary coordinate variables. ''Jonathan''
     31''Jonathan''