Changes between Version 1 and Version 2 of MultipleProjectionsJonathan


Ignore:
Timestamp:
12/23/06 12:33:36 (13 years ago)
Author:
jonathan
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MultipleProjectionsJonathan

    v1 v2  
     1'''Back to MultipleProjections'''
     2
    13Although 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.
    24
     
    79--Russ
    810
     11I prefer my proposal (at the moment, anyway), which retains the grid mapping as an attribute of the data
     12variable, as in the present standard, and introduces an alternative format for
     13it, allowing it to specify the 2D projection coordinates in association with
     14the grid mapping, for more than one projection. The advantage of this is that
     15there is minimal change to the way the file is interpreted; the grid mapping is
     16found in the same place as in the existing convention, which I think we have
     17to retain because of backward compatibility, and needs only to be parsed in a
     18new way. The
     19drawback is that the association between mapping and coordinates is made
     20independently on every data variable, but this is consistent in principle with
     21all the other kinds of coordinate system: we provide the same 1D coordinates or
     222D lat-lon coordinates for every data variable that needs them.
     23
     24In view of Russ's comments, perhaps it is better to
     25introduce 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``