Dear Bert, John, Steve et al.
Bert's requirement is to provide one or more pairs of auxiliary 2D projection
coordinates which can be derived by a grid mapping from latitude and longitude
x(latitude,longitude), y(latitude,longitude). This requires an extension to the
existing standard, which only supports grid mappings in which the projection
coordinates are the 1D coordinate variables of the data variable.
Three conventions have been proposed to record this information in the netCDF
file at
http://cf-pcmdi.llnl.gov/trac/wiki/MultipleProjections. Alternatively,
it has been suggested that the 2D projection coordinates could be computed by a
server instead of recording them in the file.
All three proposed conventions provide a way of associating the grid_mapping
with the 2D projection coordinates. This is necessary because projection
coordinates are georeferenced only by specifying the mapping. These are my
views of the three proposals:
John's proposal introduces a coordinate system variable which is
separate from the data variable. The coordinate system variable points to the
grid mapping and the projection coordinates. The data variable points to one or
more coordinate system variables. The advantage of this is that it directly
associates the grid mapping and the projection coordinates, and it saves having
to make the same association on every data variable. I would say that this is
an attractive idea, and it is quite natural to introduce this abstraction as a
way of interpreting the file. However, I think it would be inconsistent to
separate the coordinate system from the data variable *only* in this rather
specialised case, while we do not do it in the commoner situations where the
coordinate system is defined by the 1D coordinate variables, or by 2D lat-lon
auxiliary coordinate variables. Also, this abstraction may make the file harder
to understand and to use by simple programs or inexpert users. Users are
accustomed to seeing the coordinates attached to the data variable, which seems
an obvious approach.
Jonathan's proposal 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. (If preferable to supporting two formats for one attribute, we could
instead introduce a new differently named attribute of the data variable.) 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.
Bert's proposal has the data variable point to the 2D projection coordinates
via the coordinates attribute used for auxiliary coordinate variables. The
grid mapping becomes an attribute of 2D projection coordinate variables; each
such variable points to its grid mapping. The advantages of this are that the
association between grid mapping and projection coordinates does not have to
be made for every data variable independently, and that the grid mapping
attribute does not need a new format. The drawbacks are that software would
have to look in two different places for the grid mapping attribute (either on
the data variable or on the auxiliary coordinate variables), and that the
grid mapping is specified on *both* of the 2D projection coordinates for each
projection. If they happened to be different by accident, the file would be
broken.
Please comment on the above summary. If there are many comments, we could
perhaps compile them on the wiki. I hope that a summary of the arguments might
provide the necessary information for more people to consider the question and
make a decision.
Cheers
Jonathan
Received on Sun Dec 17 2006 - 01:58:53 GMT
