NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Hi Mike:
There is no need to capture vertices in a boundary variable for image pixels as
all the image pixels are the same size in area, angular field of view, or in a
projected lat/lon space. Value is not added to the data user, and the size of
the product is substantially larger.
In the case of the GOES-R ground system, the pixels all cover the same angular
field of view of the earth In some cases, image pixels cover the exact same
surface (or above surface) area. For many earth projections, the image pixels
do not cover the same area, but even in this case the imagery is still
associated with a horizontal spatial resolution.
One idea that came to mind on how to extend CF cells to capture the spatial
resolution of imagery is to leverage the conventions discussed in para. 7.3.2.
The standard term "interval" is used to capture distance between data points.
Maybe we could add the standard term "resolution" to capture the physical
extents associated with image pixels.
For GOES-R products where we have coordinate variables x and y, which
correspond to east to west, and north to south axes. The relevant portion of
the CDL specification would look something like ….
dimensions:
x=5424 ;
y-5424 ;
variables:
int x(x) ;
axis = "X" ;'
int y(y) ;
axis = "Y" ;
float data (y,x);
:coordinates = "y x" ;
:cell_methods="y: x: point (resolution: .000056 rad) ;
very respectfully,
randy
On Apr 30, 2013, at 2:50 PM, Mike Grant wrote:
> Hi Randy,
>
> On 30/04/13 19:33, Randy Horne wrote:
>> Although it works, using boundary variables to capture the horizontal
>> spatial resolution of imagery is inefficient.
>>
>> Using cell methods with the keyword "interval" could be used to
>> capture the horizontal spatial resolution of imagery, but it implies
>> the data values represent specific points rather than areas. (I
>> guess a "resolution" keyword could be added for use with cell
>> methods.)
>>
>> Another option is to establish a standard_name for horizontal spatial
>> resolution and relate the value to the data variable using the
>> "ancillary_variables" keyword.
>
> I think it would need to be reasonably clear what the contents of this
> variable should be in order for it to be useful as a standard (and it's
> more metadata than a data variable, so I think it may be better just to
> improve the cell bounds part of CF).
>
> It'd also be good to be clear how this differs from and is better than
> the cell boundaries. I think you mean a standard way to specify that a
> pixel is "100m horizontally" rather than "drawing" these with vertices
> in a bounds variable? Perhaps you could expand on this?
>
> Cheers,
>
> Mike.
>
>
> Latest news: www.pml.ac.uk and @PlymouthMarine
>
> Plymouth Marine Laboratory (PML) is a company limited by guarantee registered
> in England & Wales, company number 4178503. Registered Charity No. 1091222.
> Registered Office: Prospect Place, The Hoe, Plymouth PL1 3DH, UK.
>
> This message is private and confidential. If you have received this message
> in error, please notify the sender and remove it from your system. You are
> reminded that e-mail communications are not secure and may contain viruses;
> PML accepts no liability for any loss or damage which may be caused by
> viruses.
>
____________________________________
Randy C. Horne (rhorne@xxxxxxxxxxxxxxxxx)
Principal Engineer, Excalibur Laboratories Inc.
voice & fax: (321) 952.5100
url: http://www.excaliburlabs.com
cf-satellite archives: