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" <bryan.lawrence at stfc.ac.uk> 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
> > > >> CF-metadata at cgd.ucar.edu
> > > >> 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
>
--
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
Received on Fri Feb 19 2010 - 07:45:01 GMT
