Dear All:
Can someone out there provide a summary of the CF conventions 1.7 document
state ?
very respectfully,
randy
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
mailinglistsOn Mon, Mar 28, 2016 at 5:50 AM, Randy Horne <rho...@excaliburlabs.com> wrote:Ethan:RE:Adding features to better support satellite dataSee attached white paper for how to extend CF conventions for GOES-R level 1b space weather data. These conventions will work for polar orbiting satel
mailinglistsOn Mon, Mar 28, 2016 at 5:50 AM, Randy Horne <rho...@excaliburlabs.com> wrote:Ethan:RE:Adding features to better support satellite dataSee attached white paper for how to extend CF conventions for GOES-R level 1b space weather data. These conventions will work for polar orbiting satel
Does anyone out there have any insight into the performance when using the
Fletcher32 checksum ? Actual benchmarks are best but any information you have
would still be useful.
It would also be useful if this is contrasted with the performance when using
data compression.
the variable are same.
On 10/31/2011 12:12 PM, Randy Horne wrote:
The current CF conventions dictate that quality flags are
attached to specific variables. The implication is that
comforming with CF conventions would require the same quality
flags to be stored multiple times in our NetCDF product
the variable are same.
On 10/31/2011 12:12 PM, Randy Horne wrote:
The current CF conventions dictate that quality flags are
attached to specific variables. The implication is that
comforming with CF conventions would require the same quality
flags to be stored multiple times in our NetCDF product
, and geos makes it easier to compute
lon/lats from there, hence my proposal. For more technical details about
geos, see the CGMS 03 document I cite in the original post.
Don't hesitate to ask more if I wasn't clear !
Best regards,
Martin
- Reply message -
Från: Randy Horne rho
Martin:
Discussion with our Image Navigation and Registration lead (Dr. Jim Carr)
reveals that the EUMETSAT GEOS projection is not the same as the GOES-R
projection (i.e. the ABI fixed grid).
The reason has to do with the gimbaling characteristics of the two imagers.
Both of the imagers are
Folks:
Depending on how loose we define vector in this context, this umbrella variable
concept can achieve my objective where multiple data variables share the same
quality flags.
In the problem domain I am working, there are multiple related data variables
in the same coordinate space for
(this is long winded….sorry)
The next generation GOES program will be providing operational level 2
lightning detection products.
These products have the following essential characteristics.
(1)
There will be a variable number of lightning observations in a NetCDF product
file. These
Folks:
Regarding the geosync request for comment .
In the case of GOES-R (and also Meteosat) our coordinate variable values are
N/S elevation angle and E/W scanning angle, which can be syntactically valid
values albeit off the disk of the earth.
However, it is very possible that there
Jonathan:
We are putting in fill values for these off-earth points in the data variables.
very respectfully,
randy
Randy C. Horne (rho...@excaliburlabs.com)
Principal Engineer, Excalibur Laboratories Inc.
voice fax: (321) 952-5100
url: http://www.excaliburlabs.com
PGP Public Keys available
Jonathan:
not to belabour , but in the interest of clarity, For GOES-R level 1 and 2
hemispheric products ...
there are non-existent points, at which the data vars have missing values and
the aux coord vars have (syntactically) valid values.
note that placing (syntactically) valid values in
Is it CF compliant to use cell constructs for data having a featureType of
point (i.e. no implied coordinate relationship to other points) ?
..End of Message ...--
___
Folks:
Appendix A, Table A.1 in the CF conventions state that add_offset and
scale_factor can be used with data variables, but not coordinate variables.
For the data producing system I am working (GOES-R Ground Segment) it is
particularly convenient to make use of add_offset and scale_factor
Jonathan:
Thanks for taking the time to respond to my question.
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).
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
Jonathan:
(1)
At a conceptual level, I like your suggestions, but I do have a question …
Why have you not used a cell_measure attribute in the event_energy data
variable to associate this data variable with the event_area data variable as
shown in example 7.3 in the CF standard (e.g.
@ 459.67 if we have converted from Kelvin
to Fahrenheit).
Anyway, I can't think of a reason not to allow these attributes on
coordinates - these variables can be very large, after all.
All the best,
David
Original message from Randy Horne (01PM 05 Apr 12)
Date: Thu, 5 Apr 2012 13
Folks:
The GOES-R system will be generating a lightning detection product.
This product has multiple data variables that have relationships that do not
appear to be captured with the CF cell or ancillary data constructs.
For example, there is a one data variable that is a result of measuring
Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001
jim.bi...@noaa.gov
828-271-4900
On Apr 11, 2012, at 10:50 AM, Randy Horne wrote:
The allure of using add_offset scale_factor with coordinate variables goes
beyond saving space
Should flag variables, which are associated with data variables that have
explicit coordinates and grid mapping attributes, explicitly specify these same
coordinates and grid mapping attributes ?
___
CF-metadata mailing list
Folks:
It would seem that all the facets of this issue have been discussed.
can closure be reach ?
very respectfully,
randy
On Apr 13, 2012, at 5:31 AM, Mike Grant wrote:
On 13/04/12 10:15, David Hassell wrote:
That sounds reasonable to me. From a backwards compatibility view
point, it
David:
what specific suggestion are you referring to ?
very respectfully,
randy
-- Original Message --
From: David Hassell d.c.hass...@reading.ac.uk
Date: Thu, 10 May 2012 19:10:20 +0100
I personally have no objections, but acting as an ad hoc
Folks:
we have a product type (lightning detections) that has three data variables
where there is a relationship that must be captured in the NetCDF data set.
The 3 data variables are (1) flash_energy, (2) group energy), and (3)
event_energy.
A flash_energy is associated with one or more
Folks:
I am working the GOES-R program. We have a few very specific questions on the
use of a standard name (toa_bidirectional_reflectance):
The top of atmosphere (TOA) reflectance is a key product from satellite
observations but is
often ambiguous as a result of the many non-standard
Dear all:
Is it a given that the CF conventions apply to data below, at, or above the
surface of the earth ?
very respectfully,
randy
Randy C. Horne (rho...@excaliburlabs.com)
Principal Engineer, Excalibur Laboratories Inc.
voice fax: (321) 952.5100
knowledge about this will have to comment,
though...I'm out of my element on this one ;-)
tom
On Fri, Jul 13, 2012 at 4:01 PM, Randy Horne rho...@excaliburlabs.com wrote:
Tom:
I might have read or deduced this, but, in any case, the essence of
conforming to CF compliance revolves around being able
What is the generally accepted approach for how a specific quality flag value
should be assigned for a corresponding data value (in the corresponding data
variable) that has a _FillValue ?
Is it sufficient that, because the data variable value is _FillValue, the
corresponding quality flag
For the GOES-R product files, the plan is to use the NetCDF4 file format and
the classic data model.
Is it CF compliant if a NetCDF dataset/file uses two different unlimited
dimensions in two data variables ?
very respectfully,
randy
..End of Message
this requirement...
Regards,
Michael
On 28.08.2012 22:59, Randy Horne wrote:
For the GOES-R product files, the plan is to use the NetCDF4 file
format and the classic data model.
Is it CF compliant if a NetCDF dataset/file uses two different
unlimited dimensions in two data variables ?
very
Folks:
The GOES-R system generates level 1b space weather products. These products
fall into three categories:
(1) Products data generated from looking directionally with 3D field of
views into celestial space
(2) Products data generated from observing the sun
(3) Product data
Folks:
We have a type of product we are generating where the data value is not
precisely known…only a range between two values.
Cells / boundary variables would work, but according to appendix A, they are to
be used for coordinate variables only.
Is there a CF compliant approach to handling
Hi Jonathan:
The range for the data variable is not error/uncertainty.
Rather, the data variable is one of a set of data variables needed to define
the current environmental conditions at a location.
The specific data variable is an energy band with an upper and lower limit
where the energy
and units from:
- Mike Grant.
- Jim Biard.
- Randy Horne.
I am attending the GSICS joint meeting next week and I shall discuss the
proposals and these inputs with the GSICS Data working group members (NOAA,
NASA, JMA, CMA, KMA, etc.). I will then compile updates, discuss
Jonathan:
We are planning on using flags with numeric values as you suggest Your input
is helpful in that is is deemed unnecessary to specifically identify values in
the definition as is the case with the binary_masks, This provides additional
flexibility to data producers.
Revising the
Jonathan:
Answering your questions…
(1)
clear_sky instead of clear is fine.
(2)
super_cooled_liquid_water is a subset of liquid_water.
Thus, the definition you have suggested for:
standard_name: cloud_phase_category
with definition:
The variable is a string, taking one of the following
Folks:
resending a post hoping someone can help me. see below.
very respectfully,
randy
On Apr 18, 2013, at 2:01 PM, rho...@excaliburlabs.com wrote:
Folks:
The current definition for atmosphere_optical_thickness_due_to_cloud in the
current standard name table is:
The optical
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
:
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
Aleksander:
They look good !.
Note that the immediately preceding email cleared up a misunderstanding we had
regarding what we thought was ambiguity related to the term central.
Thanks for your patience.
very respectfully,
randy
On May 2, 2013, at 5:53 PM, Aleksandar Jelenak - NOAA
Jonathan:
As you suggest, there is info in the product file that will allow determination
of the pixel / data point resolution albeit not in the most straightforward
manner.
For us, there will be use cases where different products on the same earth
projection but with different resolution
Jonathan:
_area_fraction is fine.
very respectfully,
randy
On Jun 14, 2013, at 1:11 PM, Jonathan Gregory j.m.greg...@reading.ac.uk wrote:
Dear Randy
The specific geophysical quantity where this issue came up are the
different cloud phase categories (std name =
Folks:
The current area_type table includes cloud, snow, and vegetation. These
are environmental conditions whose existence and location vary over time.
In GOES-R, we are generating rainfall, fire, aerosol (smoke and dust), and
volcanic ash product files. These product files contain
Folks:
This is a restatement of trac item #106, that is better handled on the CF
message board. This restatement includes adjustments to the original proposal
as a result of comments received from Jonathan Gregory.
The GOES-R system generates fire, aerosol, rainfall rate/quantity, and
Folks:
We have a product with a data variable containing 10 degree latitude band
statistics (i.e. min, max) derived from observation data whose east/west
extents are associated with the field of view of a geostationary satellite
(i.e. the recently defined geostationary grid mapping /
Jonathan:
Thanks for taking the time to reply.
Some of the algorithms that generate our level 2 products using hyper spectral
observation data are sensitive to the solar zenith angle. For these products,
variables capturing the percentage of the product image in day, night, and
twilight
Dear Jonathan:
RE:
The first sentence is not clear to me. Does it mean, The fraction of the
horizontal area where the solar zenith angle is within a specified range?
Yes, that is what it means.
Incorporating this more clear statement yields the following:
area_fraction_of_solar_zenith_angle
Dear Jonathan:
All the options identified so far all have pros and cons. I’ll take a crack at
a summary-level recap ….
(1) add a type of area fraction consistent with current definition of existing
area_fraction (i.e.. day_area_fracton, night_area_fraction,
Dear Jonathan:
good point on “area”.
“twilight” is fine.
I’m good with your preference of [a hybrid of (1) and (2) (i.e.
area_fraction_of_night_defined_by_solar_zenith_angle,
area_fraction_of_day_defined_by_solar_zenith_angle,
area_fraction_of_twilight_defined_by_solar_zenith_angle)]
very
to
interpret.
best regards,
Karl
On 1/10/14 4:52 AM, Randy Horne wrote:
Dear Jonathan:
good point on “area”.
“twilight” is fine.
I’m good with your preference of [a hybrid of (1) and (2) (i.e.
area_fraction_of_night_defined_by_solar_zenith_angle
Dear All:
we requested the same and related quantities last year. I had the impression
these standard_names were accepted.
cloud_binary_mask: X_binary_mask has 1 where condition X is met, 0 elsewhere. 1
= cloud present, 0 = cloud absent (clear). Note that if no threshold is
supplied, the
Dear All:
we requested the cloud mask and related quantities last year, and I had the
impression these standard_names were accepted.
cloud_binary_mask: X_binary_mask has 1 where condition X is met, 0 elsewhere. 1
= cloud present, 0 = cloud absent (clear). Note that if no threshold is
Jim:
Our two GOES-R products that are height quantities are geopotential heights -
(1) the quantity for which the standard_name is being requested now
(geopotential_height_at_cloud_top) and (2) the height of volcanic ash clouds
for which we got a standard name added last year
Dear All:
Finalizing the sunglint_angle standard name based on a recommendation from Gary
Meehan three weeks ago...
definition
The angle between an incident beam of solar radiation and the outgoing
beam specularly reflected at a sea surface.
canonical units:
rad
very respectfully,
randy
Dear All:
“b is appended to all fill value, valid range, flag mask, and flag values in
the flag variable examples (see para. 3.5 Flags). Note that in the examples,
“b” is appended to values that are base 10 values, and in some cased are
numbers where multiple bits are needed to represent
Dear All:
I think Richard and Martin are on the right track in recommending a scheduling
cadence, preferably where “time to market” has high priority, as it would
provide certainty, and also allow operational program needs to be addressed in
a manner that is satisfactorily timely.
Also worth
Dear All:
We have data variables containing observation data that have corresponding flag
variables containing status info (i.e. status_flag). These flag variables are
ancillary data and the observation data variable includes the
ancillary_variables attribute.
The observation data variable
Dear All:
I am proposing the following…
standard_name:
brightness_temperature_at_cloud_top
definition:
cloud_top refers to the top of the highest cloud. brightness_temperature of a
body is the temperature of a black body which radiates the same power per unit
solid angle per unit area. A
Dear All:
I would like to propose the following standard_name:
dvorak_tropical_cyclone_cloud_region_scene_type
definition:
The variable is a string, taking on one of the following values to indicate the
Advanced Dvorak Technique tropical cyclone cloud region scene type:
Dear Jonathan:
Is there an existing standard name for a distance threshold as well ?
very respectfully,
randy
On Apr 23, 2014, at 11:30 AM, Jonathan Gregory j.m.greg...@reading.ac.uk
wrote:
Dear Gary
In your new definition, the threshold is not stated, and I agree that it
better
in
Dear Jonathan:
Thanks for feedback.
Is there a need to specifically call out the need for time and space bounds
in the definition of this standard name or is it good as is ?
very respectfully,
randy
On Jul 11, 2014, at 10:52 AM, Jonathan Gregory j.m.greg...@reading.ac.uk
wrote:
Dear
John:
geostationary projection and vertical perspective projections are not the same.
an example of a vertical projection image is one taken by a camera in space,
which is not necessarily at the equator, and the data for the entire image is
observed using a single exposure.
the geostationary
:
http://www.remotesensing.org/geotiff/proj_list/geos.html
is it wrong/misleading?
is geostationary a special case of vertical perspective?
On Tue, Nov 18, 2014 at 6:28 PM, Randy Horne rho...@excaliburlabs.com wrote:
John:
geostationary projection and vertical perspective projections
Dear All:
Please refer to trac item #74 (Allow sharing of ancillary variables among
multiple data variables).
This enhancement support handling data variables that do not have standard
names.
here are the final posts in this trac item ….
Dear All:
This post defines strawman redlines to
Hi Daniel:
In the case with the GOES-R data sets, Rather than embedding clear sky in the
standard name we used both data quality flags and the CF constructs
cell_methods and area_types (as applicable) to capture clear sky.
Are there data points in your data sets for which there is no clear
Folks:
I have a very general comment on CF Swath related to geolocating pixels in a
swath.
Level 1/2 product generation systems that output remotely sensed swath data
from polar orbiting systems often have a concern/requirements related to
keeping the volume of data to a minimum.
If I am
e satellite
> to the Earth's centre and the perpendicular projection of the line of sight
> onto the reference plane.
>
>
> regards,
>
> Martin
>
>
>
>
> ________
> From: CF-metadata <cf-metadata-boun...@cgd.ucar.edu> on behalf o
Ethan:
What you suggest is fine.
As an aside ….
If you look at the CF standard name table, the canonical units for standard
name “ projection_x_coordinate” and “projection_y_coordinate” are meters (not
radians).
The GOES-R designers (specifically me) inadvertently used these two standard
tude
>>>> instead of x and y. In addition, spherical or cylindrical coordinate
>>>> systems would expect at least one coordinate to be angular. Thoughts?
>>>>
>>>> Grace and peace,
>>>>
>>>> Jim
>>>>
>>>>
Folks:
RE: “ Definition: "x" indicates a vector component along the grid x-axis, when
this is not true longitude, positive with increasing x. Angular projection
coordinates are angular distances in the x- and y-directions on a plane onto
which the surface of the Earth has been projected
Hi Martin:
RE: I agree with Jim that a little more basic information is needed about what
the angles are. I may be misinterpreting the discussion, but I had imagined
that the angles as components of a spherical coordinate system centred on the
satellite, with the nadir at (0,0) ... is that
e same.
>
> Cheers,
> Daniel
>
>> -Original Message-
>> From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf
>> Of Martin Juckes - UKRI STFC
>> Sent: 20 April 2018 15:41
>> To: Randy Horne <rho...@excaliburlabs.com>
&g
73 matches
Mail list logo
