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 _at_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 at excaliburlabs.com)
Principal Engineer, Excalibur Laboratories Inc.
voice & fax: (321) 952.5100
url:
http://www.excaliburlabs.com
Received on Tue Apr 30 2013 - 13:52:16 BST
