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
> CF-metadata at cgd.ucar.edu
> 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: v.balaji at noaa.gov
Received on Fri Feb 19 2010 - 12:45:18 GMT
