The gridspec doc (which hasn't yet been vetted by CF) does indeed
contain a specification of arc_type, how you draw a line between
vertices, specified by a controlled vocabulary: great_circle,
small_circle, etc.
It's needed for regridding. If the need is only a correct specification
of areas and volumes for doing integrals, it would be enough for the
creator of the data to write out the area they want you to use and
specify it as a cell_measure.
For swath data (where neighbouring pixels may have overlapping spheres
of influence) would it make sense to even connect lines between the
vertices?
Thomas Lavergne writes:
Dear Karl,
I agree with the points you made and do not think we will get along with simple
changes and yet cover all the possibilities.
I also like your remark that the lines connecting the vertices are not
necessarily straight lines in CF.
However, you write:
In the measurement examples provided as motivation for extending the
definition of cell bounds to include ellipses, the cell shapes were in
fact only *approximately* represented by an ellipse, so should the
description include this information to distinguish it from a true
ellipse (i.e., should we use the words "approximate ellipse" rather
than "ellipse")?
My original post contained two examples:
One example of such a dataset would be one where at each grid location
we report the mean/minimum/maximum temperature or pressure recorded by
any station found in a radius of, say, 30 km around the central
point.
Another example is satellite data in swath projection where each
record is associated to a Field Of View, which is often approximated
as a an ellipse.
The first one has no "approximation" in it. It only reflects a different (but
not very rare) way of collecting information around a point. A circle instead of a cell
in cartesian coordinates.
As far as this example is concerned, we could maybe manage with some attribute stating
that the connecting lines are "circular" (with constant 2nd curvature) and
provide two points only. The cell is defined by the interior of this domain.
Alternatively, we could give only one point, but specify that the cell is centered at the
point given by the coordinates values. This would also work for ellipses (3 points are
enough, right?) and we could extend this to 3D.
Definitions would then rely on some maths (is that topology?) and we would
probably have to limit ourselves to the most obvious shapes, still covering
arbitrarily shaped polygons, circles and ellipses.
As far as the second example is concerned, you are right, it is only an
approximation. However, I mean that if the data provider wants to approximate
the FOV by an ellipse (his choice), the CF convention should maybe provide a
vocabulary for that.
The question is then if CF wants to strongly specify the shape of the cell or
does it merely encourage users to approximate any shape with a sufficient
number of vertices, report the exact area and use freely formatted comments for
describing those cells. It would serve most of the purpose of describing the
data collection method to a human reader but would not allow for efficient
interpretation by specialized software.
Cheers,
Thomas
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
V. Balaji Office: +1-609-452-6516
Head, Modeling Systems Group, GFDL Home: +1-212-253-6662
Princeton University Email: [email protected]
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
