Changes between Version 7 and Version 8 of MultipleProjectionsJonathan


Ignore:
Timestamp:
02/09/07 07:14:03 (13 years ago)
Author:
russ
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MultipleProjectionsJonathan

    v7 v8  
    3232''Jonathan''
    3333
    34 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.
     34Jonathan 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.  In any case, the problem is relatively minor and I admire the conciseness of the representation.
    3535
    3636''Russ''