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"<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
>>>
>>
>
>
>
Received on Fri Feb 19 2010 - 09:25:02 GMT
