Hi Randy and all,
I remember NCEP proposed extension to GRIB edition 2 to handle space weather
data, a couple of years ago I think. I don't hear recent activity on it,
but anyway it should be relevant topic for some people in atmospheric
sciences.
For me it sounds like your required metadata consists of lots of angles and
coordinates. The best consistent way to CF should be:
- axes of an image should be coordinate variables, associated to the
variable containing the image data
- other coordinates could be EITHER attributes on the image variable OR
scalar variable in the dataset
I feel like it might be better to use scalar variables.
- Defining new attributes sounds like defining a new convention, while only
new standard_name is needed to use scalar variable.
- It is always good to specify units explicitly.
- A netCDF variable has three names (variable name, long_name, and
standard_name) so we can use few-letter symbols together with descriptive
names. It is especially useful when a concept has different names in
different communities.
I say the last point because I'm not so confident that the terms like ECI,
ECEF, or BRF are best understood. I once had a chance to learn about a data
model defined by another group of space physics. Their dictionary
http://www.spase-group.org/docs/dictionary/ seems to give names "Geocentric
Equatorial Inertial" and "Geocentric Corotating" to what you call ECI and
ECEF respectively.
Hope my thoughts are helpful....
Best Regards,
Eizi
--
TOYODA Eizi
Japan Meteorological Agency, associate member of WMO/CBS/IPET-DRC
----- Original Message -----
From: "Randy Horne" <rhorne@xxxxxxxxxxxxxxxxx>
To: "Randy Horne" <rhorne@xxxxxxxxxxxxxxxxx>; "Tom Whittaker"
<whittaker@xxxxxxxx>
Cc: <cf-metadata@xxxxxxxxxxxx>; <cf-satellite@xxxxxxxxxxxxxxxx>
Sent: Tuesday, July 17, 2012 1:09 AM
Subject: Re: [cf-satellite] applicability of CF conventions
Tom et al:
To locate space weather data, (I think) four types of information are
required.
(1)
Where is the satellite in space ? This is typically communicated with ECI
or ECEF coordinates.
(2)
How are the instruments positioned on the satellite ? One approach is to
use Body Reference Frame (BRF) coordinates.
(3)
The instrument itself may have one or more apertures where sensing occurs
that are positioned relative to the instrument structure itself.
(4)
Because the satellite has "jitter", spacecraft quaternions are often used
to capture the EXACT orientation of the satellite at specific moments in
time.
Somehow, the coordinate variables for these space weather products need to
include this information.
very respectfully,
randy
---------- Original Message ----------------------------------
From: Tom Whittaker <whittaker@xxxxxxxx>
Date: Mon, 16 Jul 2012 10:34:23 -0500
Hi Randy...
I'm wondering if some of the constructs put forth for the radar people
might address the "coordinates" issue you raise. As far as I know,
nothing is "blessed" yet my the CF committee for radar scans, but the
geometry (3D vector and a solid angle) might be common.
Others with more 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 <rhorne@xxxxxxxxxxxxxxxxx>
wrote:
Tom:
I might have read or deduced this, but, in any case, the essence of
conforming to CF compliance revolves around being able to locate the
data in space and time. The conventions for locating data in space
revolve around coordinate variables and the related CF conventions.
Solar and space weather data directly related to climate and forecasting
here on the earth can make use of many of the existing CF constructs,
but the CF constructs to locate data in space have little relevance.
On GOES-R we have solar images and we also have space weather data where
its location is a 3D vector and a solid angle (i.e. a cone looking off
into space).
The implication is that these extensions to the CF conventions need to
augment the existing CF core coordinate variable related constructs.
Is this going to be palatable to this community or is just establishing
a new, independent set of conventions, which can make use of the
relevant CF conventions to the extent possible, the way to go ?
very respectfully,
randy
On Jul 13, 2012, at 4:26 PM, Tom Whittaker wrote:
Randy...
I see no reason why not. As we have discussed for geo satellites,
though, we may need to make extensions to get some conventions
established where they do not already exist (e.g., 'band') so that
application developers can put in code to recognize these conventions.
tom
On Fri, Jul 13, 2012 at 12:48 PM, Randy Horne
<rhorne@xxxxxxxxxxxxxxxxx> wrote:
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 (rhorne@xxxxxxxxxxxxxxxxx)
Principal Engineer, Excalibur Laboratories Inc.
voice & fax: (321) 952.5100
url: http://www.excaliburlabs.com
_______________________________________________
cf-satellite mailing list
cf-satellite@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
--
Tom Whittaker
University of Wisconsin-Madison
Space Science & Engineering Center (SSEC)
Cooperative Institute for Meteorological Satellite Studies (CIMSS)
1225 W. Dayton Street
Madison, WI 53706 USA
ph: +1 608 262 2759
____________________________________
Randy C. Horne (rhorne@xxxxxxxxxxxxxxxxx)
Principal Engineer, Excalibur Laboratories Inc.
voice & fax: (321) 952.5100
url: http://www.excaliburlabs.com
--
Tom Whittaker
University of Wisconsin-Madison
Space Science & Engineering Center (SSEC)
Cooperative Institute for Meteorological Satellite Studies (CIMSS)
1225 W. Dayton Street
Madison, WI 53706 USA
ph: +1 608 262 2759
..............End of Message ...............................-->
_______________________________________________
cf-satellite mailing list
cf-satellite@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
