Dear Alison,
Thank you for the detailed analysis of my proposed standard names and
for summarizing efficiently all outstanding issues. My replies to your
questions are below.
On Thu, Jun 6, 2013 at 9:36 AM, wrote:
> 6) sensor_zenith_angle (degree)
>
> 'sensor_zenith_angle is the angle between t
Jonathan, Randy:
Are these standard names acceptable:
sensor_band_central_radiation_wavelength
sensor_band_central_radiation_wavenumber
sensor_band_central_radiation_frequency
I think they are consistent with the "radiation_..." theme and still
containt "central" in them.
-Aleksandar
Hello Randy,
On Thu, May 2, 2013 at 8:49 AM, rho...@excaliburlabs.com
wrote:
> (1) standard_name: sensor_band_central_wavelength
>
> We have read the follow-up discussion regarding this proposed standard name.
> Consider the following:
>
> (a)
>
> The "center" wavelength could either be the mid
Dear Jonathan,
Thank you for reviewing those unattended standard name proposals.
On Sun, Apr 21, 2013 at 4:18 PM, Jonathan Gregory
wrote:
> A sensor is not necessarily a device which measures radiation. In fact the
> only existing standard name containing this word is
> temperature_of_sensor_for
Dear Martin,
Thanks for taking the time to review the proposed names.
On Wed, Apr 17, 2013 at 2:36 AM, Schultz, Martin
wrote:
> "relative_platform_azimuth_angle" and "relative_platform_azimuth_angle": in
> my understanding "relative" denotes a (percent) fraction rather than a
> difference. The
Dear Ted,
On Tue, Apr 16, 2013 at 7:11 PM, Ted Kennelly wrote:
> it seems that some good progress has been made to
> tackle the thorny issue of how to represent what is the fundamental product
> of remote sensing observations, i.e, the
> measurement of top of atmosphere radiance incident at the
Dear all,
I think the names I proposed back in November last year have reached
the business end of the acceptance process. For your convenience they
are gathered in one place:
http://wiki.esipfed.org/index.php/Standard_Names_For_Satellite_Observations#Proposal_.232
The proposed names are color-c
Dear Jonathan,
Thank you for the prompt reply.
> If having more than one canonical units is deemed too much of a
> > radical change ...
>
> Yes, it would be too radical. It is a principle of the standard name table
> that if quantities have different physical dimensions, they must be
> different
Dear all,
I proposed last November a standard name:
toa_outgoing_spectral_radiance
Canonical units: mW m-2 sr-1 (cm-1)-1
Definition:
"toa" means top of atmosphere; "outgoing" means toward outer space;
"spectral" means per unit wavenumber or as a function of wavenumber.
Radiance is the radiant p
Dear All,
I know this will likely end up as a trac ticket but would like first
to gauge the community's opinion about defining a new coordinate type.
Satellite data originates as measurements at a number of intervals of
the electromagnetic spectrum. These intervals are commonly referred to
as band
Hello Ken, Randy,
On Wed, Apr 3, 2013 at 11:44 AM, Kenneth S. Casey - NOAA Federal <
kenneth.ca...@noaa.gov> wrote:
> Randy - I am not the expert on these definitions, but the word "emitted"
> is used in each of them. Might be more appropriate to say "emitted or
> reflected"??? Meaning, the radi
Hi Randy,
On Wed, Apr 3, 2013 at 11:28 AM, rho...@excaliburlabs.com
wrote:
> #2
>
> standard_name: toa_outgoing_spectral_radiance
>
> Definition: "toa" means top of atmosphere. "outgoing" means emitted toward
> outer space. "spectral" means per unit wavenumber or as a function of
> wavenumber. Ra
On Fri, Mar 22, 2013 at 4:31 PM, Seth McGinnis wrote:
> Maybe I'll change my mind after the community has made the jump to
> netcdf4
Dear Seth,
What benchmark do you suggest to use to determine whether the CF
community has made this jump?
-Aleksandar
_
Hi Steve,
On Wed, Mar 27, 2013 at 11:05 AM, Steve Hankin wrote:
> I think we're talking about different issues. The thought question I posed
> was not whether it is acceptable to have a standard_name assigned to string
> variable. Nothing wrong with a string variable. Rather it was to point
Hi Steve,
On Tue, Mar 19, 2013 at 6:19 PM, Steve Hankin wrote:
> Hi Aleksander,
>
> A question to debate in your trac ticket. Per the CF documentation, the
> definition of the standard_name is "The name used to identify the physical
> quantity"
I found five standard names for variables with str
On Fri, Mar 22, 2013 at 5:03 PM, John Graybeal wrote:
> Note the name says "interval", but the definition says "difference". To me
> the term 'difference' is more appropriate, as 'interval' has a connotation of
> recurrence.
Nice catch! Yes, "difference" sounds better to me, too. So:
time_samp
Hi Philip,
On Fri, Mar 22, 2013 at 3:48 AM, Cameron-smith, Philip
wrote:
> I don't think anyone has responded to your email below, so I am responding,
> in part, so it doesn't get lost in the recent blizzard of emails on other
> topics :-).
Thank you very much! I was getting worried the other
Hello Andreas,
On Wed, Mar 20, 2013 at 5:50 PM, Andreas Hilboll wrote:
> I was wondering if it is possible to describe the pixel geometry of
> satellite measurements in CF. In atmospheric trace gas remote sensing,
> an individual measurement's location is often described by the center
> point's l
Hello Steve,
On Tue, Mar 19, 2013 at 6:19 PM, Steve Hankin wrote:
> A question to debate in your trac ticket. Per the CF documentation, the
> definition of the standard_name is "The name used to identify the physical
> quantity"
> (http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-convent
Dear Jonathan,
On Tue, Mar 19, 2013 at 3:34 PM, Jonathan Gregory
wrote:
> Is the proposal for the use of date-time strings in auxiliary coordinate
> variables only, not in (Unidata) coordinate variables,
> to provide a human-readable equivalent to the encoded time coordinate
> variable?
Not ex
Dave,
Please post here. I don't want to lose this momentum now... :-)
-Aleksandar
On Tue, Mar 19, 2013 at 3:55 PM, Dave Allured - NOAA Affiliate
wrote:
> Aleksandar,
>
> I support the standard name proposal for datetime_iso8601. However, I
> see several areas needing refinement, evidenc
Nan,
On Tue, Mar 19, 2013 at 3:08 PM, Nan Galbraith wrote:
> There seems to be surprisingly broad support for this idea, so I've been
> re-reading the thread, looking for a reasonable use case. I can't say that
> I've found any description of why we actually need this - am I missing
> something?
On Tue, Mar 19, 2013 at 12:57 PM, John Graybeal wrote:
> Thanks Aleksander for pushing in this direction.
Thanks!
> On the other hand, we should limit it to only the formats expressing an
> instance of date/time (meaning single date or date + time), and exclude the
> range or duration notation
I would say something like
>> "azimuth_of_sensor_seen_from_observed_point", but, clearly, this doesn't
>> follow the guidelines for construction of CF Standard Names.
>> At least, does this correctly reflect what you mean ?
>>
>> Bruno.
>>
>>
I fully support John Caron's proposal of having ISO 8601 datetime
strings as another way for encoding time data. But I proposed a
standard name so would like to return to that.
>From a few replies so far it seems that many interpret this standard
name proposal as a fundamental change of the conven
nsing of grouping two
independent measurements based on a set of spatial, temporal, and
viewing geometry criteria.
Units: s
-Aleksandar
On Wed, Feb 27, 2013 at 1:16 PM, Aleksandar Jelenak - NOAA Affiliate
wrote:
> On Wed, Jan 16, 2013 at 3:10 PM, Cameron-smith, Philip
> wrote:
&g
On Wed, Jan 16, 2013 at 3:10 PM, Cameron-smith, Philip
wrote:
> Hi, Edward,
>
> _sample_ seems a good alternative.
>
> I still like the idea of _due_to_collocation, since that defines what the
> interval is about. So how about the following?
>
> time_sample_interval_due_to_collocation
>
>
Hi Philip,
> time_repeat_interval_due_to_collocation
What is "repeat" in the name for? Can you quickly clarify that please?
-Aleksandar
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadat
se who are willing to
spend a few more kilobytes of their CF-netCDF files on duplicating
time data as ISO 8601 strings.
-Aleksandar
On Fri, Jan 11, 2013 at 4:37 PM, Chris Barker - NOAA Federal
wrote:
> On Fri, Jan 11, 2013 at 9:00 AM, Aleksandar Jelenak - NOAA Affiliate
> wrote:
Hi Philip,
On Mon, Jan 14, 2013 at 3:34 PM, Cameron-smith, Philip
wrote:
> it may be a good idea to make the std_name capture your concept more
> precisely.
I was thinking to propose first collocation_interval but then realized
it is just a time interval and I would need to define "collocation"
ct point -- is it the azimuth angle of the platform, or
> of the instrument on the platform? (the former, in this case).
> Platform_orientation seems to be the accepted name for the purpose.
>
> The definition is very weak though -- can we propose the substitution of this
> de
Hello Philip,
On Fri, Jan 11, 2013 at 2:53 PM, Cameron-smith, Philip
wrote:
>> 5) time_interval
>> An interval of time.
>> Units: s
>
> Can you clarify what you want for time_interval that cannot be encoded with
> the existing CF?
I want to store time intervals between collocated observations m
Dear Bruno,
On Fri, Jan 11, 2013 at 11:52 AM, Bruno PIGUET wrote:
> I have one remark about "platform_azimuth_angle"
>
> I like this name and it correspond to usual navigation definition (as
> far as I can tell from my experience with airborne and shipborne
> measurements), but...
>
> There is a
Dear Sander,
On Fri, Jan 11, 2013 at 12:22 PM, Sander Niemeijer wrote:
> Shouldn't one allow room for storing leap seconds? (ss in range 00-60 instead
> of 00-59)
Yes, you are correct. The corrected statement is:
* "ss" is a two-digit second (00-60).
-Aleksandar
___
Dear All:
Here's the modified proposal for the datetime_iso8601 standard name:
standard_name: datetime_iso8601
Units: N/A
String representing date-time information according to the ISO
8601:2004(E) standard. Variables with this standard name cannot serve
as coordinate variables. Date-time infor
ption of the others.
-Aleksandar
On Tue, Nov 20, 2012 at 9:34 AM, Aleksandar Jelenak - NOAA Affiliate
wrote:
> [...snip...]
> Proposed standard names are:
>
> 1) sensor_band_identifier
>
> Alphanumeric identifier of a sensor band.
>
> Units: N/A
>
> 2) sen
Dear Corey,
On Tue, Nov 20, 2012 at 10:02 AM, Corey Bettenhausen
wrote:
> Regarding the "which is often due north" language, if you measure azimuth
> angle from due south, how should this communicated in the file? A comment?
> Or should the definition force the use of due north for this standa
Dear All,
I wish to propose the standard names below for acceptance in the official
list. Those of you with good memory may remember my message from
October 2010 where I proposed several very similar names. There was
never a final
decision on that proposal so consider the names here as the improve
38 matches
Mail list logo
