Dear all,
Grid cell bounds were originally meant to provide precise information
about the spatial extent of each grid cell or the interval of time over
which a measurement was made. An ellipse would be inappropriate in
either of these two cases (because 2-d space can't be completely
completely represented by a set of non-overlapping ellipses). We note
that CF does not in fact unambiguously provide any information about the
shape of the grid cells; it just says that there are "vertices" that get
connected (presumably by quasi-straight lines, perhaps running along
great-circles or latitude circles). An ellipse might be considered a
special case in which the "vertices" are connected by curves following
the shape of an ellipse (with the definition of "vertice" stretched in
this case to mean the 4 locations representing locally maximum distances
from the center of the ellipse).
Perhaps that's too much of a stretch, but I think it points to the fact
that we might think a bit longer about what cell "shapes" might be need
to specified. Should we specify, for example, that for a particular
latitude-longitude grid the grid cell latitude bounds might follow
latitude circles, while the longitude bounds follow great circles along
lines of longitude?
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")?
Best regards,
Karl
On 19-Feb-10 6:45 AM, Bryan Lawrence wrote:
hi Thomas
I think Nan's right that four points is enough to unambiguously define an
ellipse, but how do we know it's an ellipse?
We get the vertices from cell bounds
We get the area from cell measures
The only thing missing is the knowledge that the bounds need to be interpreted
as ellipse coordinates rather than a polygon when plotting or something more
sophisticated.
There are at least two possible routes:
a) while long_name is not required for a boundary variable, we could use it
to say it's an elllipse, or
b) We extend cell_measures or cell_methods. My preference would be the
latter, so we could add ellipse or FOV or something like that to appendix E (I
haven't thought this through in detail yet, I was hoping someone else would
suggest something).
Cheers
Bryan
On Friday 19 February 2010 14:15:47 Thomas Lavergne wrote:
Hei Nan and Bryan,
Indeed, as far as I see it, you could not specify or reproduce this shape since
you do not know it is an ellipse. It might furthermore be slanted with respect
to the axis, which requires an extra piece of information.
Bryan, did I miss something or you haven't yet proposed your "slight
modification"? I am all ears :-)
Thomas
----- "Bryan Lawrence"<[email protected]> wrote:
Hi Nan
... but you couldn't plot this properly because you don't know that
it's an ellipse ... which is why I would suggest a very slight
modification to add that particular piece of metadata ... (or am I
missing something)
Cheers
Bryan
On Thursday 18 February 2010 14:36:05 Nan Galbraith wrote:
Four coordinates and an area is enough to define an ellipse; if
these are more complex shapes, that's another problem.
As long as these are ellipses, the existing convention should work;
you'd
give the n/s e/w extremes of the disc in lat(cell), lon(cell) and
use
cell_measures = "area: cell_area" after calculating the area from
the
lengths
of the major& minor axes.
Maybe my geometry is even rustier than I thought, otherwise this
should
work as it exists in the standard.
The vertices of the cells can be stored in the variable identified
by
the bounds
attribute, but the cell perimeter is not uniquely defined by its
vertices (because
the vertices could, for example, be connected by straight lines,
or,
on a sphere,
by lines following a great circle, or, in general, in some other
way).
- Nan
On Wednesday 17 February 2010 13:36:21 Thomas Lavergne wrote:
Dear all,
I do not think someone reacted on my concern/question about
non-polygonal cell boundaries. Maybe I am the only one with this issue
or maybe this topic went un-noticed because of heavy load on the CF
list at that time.
I thus re-post my original message in hope that someone will
comment on it (or point me to an archived thread that I did not yet
see).
Original post:
Hi everyone,
I refer to Chapter 7 on "Data Representative of Cells", 7.1
"Cell
Boundaries".
The specification of those boundaries seems to biased towards
polygonal boundaries (in the case of a 2D surface). This covers
certainly most of the needs but what happens if the cell is
defined as
a disc of radius x km (with center at the coordinate value)?
Of course, I can always give 10 to 10,000 vertices that will
approximate my disc but it does not sound very neat nor
efficient. We
would have to somehow move away from listing the 'bounds' and
start
describing the shape of the cell (disc, ellipse, rectangle,
etc...).
Note that the concepts of "cell measures" and "cell methods"
would
still perfectly hold.
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.
Did someone give it a thought already?
_______________________________________________
CF-metadata mailing list
[email protected]
http://*mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Bryan Lawrence
Director of Environmental Archival and Associated Research
(NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
STFC, Rutherford Appleton Laboratory
Phone +44 1235 445012; Fax ... 5848;
Web: home.badc.rl.ac.uk/lawrence
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
