Changes between Version 8 and Version 9 of MultipleProjectionsJonathan


Ignore:
Timestamp:
02/09/07 07:20:52 (12 years ago)
Author:
russ
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MultipleProjectionsJonathan

    v8 v9  
    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.  In any case, the problem is relatively minor and I admire the conciseness of the representation.
     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 (as in WKT syntax), 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, I admire the conciseness of the representation, and the problem with parsing is relatively minor although not present in the other proposals that can use arbitrary strings for the projection name.
    3535
    3636''Russ''