Gents:
Once again?thanks for the feedback !
I need to provide some comments that (hopefully) provide some clarification on the characteristics of the product data ?.
(1)
I was imprecise when I said that a lightning detection is associated with an "interval of time". There are requirements that the product contains the start time of the lightning detection and the end time of the lightning detection. These times are based on lightning "events" detected by the sensor. I was thinking doing something like:
dimensions:
time = UNLIMITED; (note that the number of lightning detections in a specific NetCDF file varies.)
number_of_time_values = 2;
variables:
float time (time);
:units = "?.";
...
:bounds = "time_bounds";
float time_bounds (time, number_of_time_values);
With this design, each lightning detection really has 3 time values, one in the time variable (the midpoint), and two in the time_bounds array (containing the first and last "event" associated with the lightning detection)
(2)
We have a requirement to explicitly include the area of each lightning detection in the product (i.e. vertices are not required). So, I am looking for a CF compliant method to include the area of each lightning detection and associate it with the lightning detection energy, which is the primary data variable. I was thinking something like:
dimensions:
number_of_lightning_detections = UNLIMITED
variables:
float lightning_detection_energy (number_of_lightning_detections);
:units = "?";
?
:cell_measures = "area: lightning_detection_area";
float lightning_detection_area (number_of_lightning_detections);
:units = "m2";
...
very respectfully,
randy
On Apr 9, 2012, at 3:21 PM, John Caron wrote:
> On 4/9/2012 1:07 PM, Jonathan Gregory wrote:
>> Dear Randy
>>
>>> The GOES-R system will be producing a hemispheric lightning detection product.
>>>
>>> It will be an array of lightning detection that occur within some number of seconds across the western hemisphere (i.e. it is not a gridded product).
>> Is is a timeseries of values, for probability or number of occurrence or
>> yes/no - something like that? If so, I don't think there's a featureType for
>> it yet. It's a timeseries which doesn't apply to a station. It would be
>> among the list of things not covered by chap 9 yet (see sect 9.1). But you
>> don't need to give it a featureType. Chap 9 is primarily for datasets which
>> need to use the techniques provided there for saving space.
>
> hmm, my reading is that this would be an appropriate "point" feature type. Jonathan, not sure why you think not?
>
>>
>>> A lightning detection has a center location, and needs to be associated with an area and an interval of time.
>>>
>>> (2) Use the cell "bounds" construct to capture the time interval.
>> Fine. cell_methods should say "time: sum", where time is the name of the time
>> dimension. From your description, I think "sum" is appropriate because this
>> quantity is extensive in time. The probability would be larger if the interval
>> were longer. See App E.
>>
>>> (3) Use the cell "cell_measures" construct to capture area (i.e. ":cell_measure = area: lightning_detection_area").
>> That's not quite right, I think. The entry is to indicate what kind of
>> statistic this is, and I would say that again this is extensive. If you
>> considered an area smaller than the W hemisphere, the probability would be
>> smaller, for instance. So I would suggest "area: sum".
>
> if you are trying to describe the location bounds, a "bounds" on the lat, lon might be one way to do it?
>
> or perhaps you just want to add some notion of error associated with the location?
>
>
> John
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
____________________________________
Randy C. Horne (rhorne at excaliburlabs.com)
Principal Engineer, Excalibur Laboratories Inc.
voice & fax: (321) 952.5100
url:
http://www.excaliburlabs.com
Received on Mon Apr 09 2012 - 14:57:00 BST
