Hi Rich,
This sounds like just the right solution. It's onsistent with the use
of precise_lon and precise_lat in Example H.5. (A single timeseries with
time-varying deviations from a nominal point spatial location)
It's a pretty complicated encoding, though. To make sure that you get
inter
Ethan,
Two more topics to consider as additions to your list:
1. "UGRID" -- Of interest to the coastal ocean modeling community, and
stuck in a holding pattern for quite a long time, is the harmonization
of mesh/unstructured grid coordinates into the main body of CF. The
work is mostly compl
Hi Jonathan,
A quick message here, intended as much as anything for the email
archives, to make it clear that differences of viewpoint remain about
the use of negative depth values. The alternative viewpoint is that the
implicit semantics in the term "depth" is its _realm_: the variable name
On 1/29/2014 9:26 AM, Jonathan Gregory wrote:
Dear Steve
In practice I do not think that
standard_name=depth and positive=up are necessarily in conflict (see
bold text below). We fairly commonly encounter ocean model outputs
in which the depths are encoded as negatives:
0
-10
-20
John, Jonathan,
One detail I would differ on: In practice I do not think that
standard_name=depth and positive=up are necessarily in conflict (see
bold text below). We fairly commonly encounter ocean model outputs in
which the depths are encoded as negatives:
0
-10
-20
...
The
//www.ietf.org/rfc/rfc2119.txt
On 1/15/2014 10:46 AM, Karl Taylor wrote:
All,
Yes, that statement seems quite definitive and unambiguous, and for the
reasons stated in other emails, I support retaining it.
regards,
Karl
On 1/15/14 9:37 AM, Steve Hankin wrote:
On 1/15/2014 9:24 AM, Jim Biard wrote
On 1/15/2014 9:24 AM, Jim Biard wrote:
Chris,
The point is, the Conventions themselves state that there is *no
standard*. People are all the time trying to add meaning to variable
names, but the standard actually states that the meaning is to reside
in the attributes. The variable names ar
Hi John,
Philosophically I am aligned with Bryan: the purpose of the CF standard
is to constrain (simplify and make predictable) the use of a highly
general file creation toolkit like netCDF. The question of limitations
placed on name strings should be evaluated on this yard stick.
There
d your
concern over consistency with "realization". Either choice is fine
with me.
- Steve
On 11/15/2013 11:15 AM, Steve Hankin wrote:
On 11/15/2013 10:30 AM, Jonathan Gregory wrote:
Dear Steve et al.
I support the idea that the
On 11/15/2013 10:30 AM, Jonathan Gregory wrote:
Dear Steve et al.
I support the idea that the term "ensemble" be allowed (by whatever
machinery) as an alias for "realization".
It'd be fine to have an standard_name alias, I agree, but I think it should be
"ensemble_member", not "ensemble". The
onathan Gregory [mailto:j.m.greg...@reading.ac.uk]
Sent: 15 November 2013 17:09
To: cf-metadata@cgd.ucar.edu
Cc: ca...@unidata.ucar.edu; Steve Hankin; Kettleborough,
Jamie; Hedley, Mark
Subject: [CF-metadata] Standardizing how ensemble
(realization) axes are encoded
Dear all
This is partly a reply to various
y and unambiguously encode that my 2D (lat lon) data values are:
"the 30 year mean of the seasonal(djf) mean of the daily maximum
air_pressure values at the surface in hPa"
I thought the was the raison d'etre of the cell_methods string
mark
Two quick comments:
1. "We could perhaps ... introduce a new standard name such as
ensemble_member_id (a string) or ..."
* Have you hit on a void in CF that needs to be filled? Unless
I've overlooked it CF has not yet standardized the manner in
which ensemble axes are to be
Hi Mark,
Volumes of documentation have been written about cell_methods that I
have not kept up with, so this response comes with implicit caveats.
Maybe this response is "coming from left field". But here goes ...
In your ensemble mean example (the second/result example on your Wiki)
the en
On 9/24/2013 9:45 PM, Charlie Zender wrote:
It is not my place to determine whether there is a consensus, or how
close we are, but it's clear to me there is no consensus yet. Bryan
Lawrence, Steve Hankin, Jonathan Gregory, Karl Taylor, and Philip
Cameron-Smith are not "on board&quo
ng the global attributes I listed above.]
best regards,
Karl
On 9/19/13 6:55 AM, Corey Bettenhausen wrote:
On Sep 18, 2013, at 12:32 PM, Steve Hankin wrote:
On 9/18/2013 7:56 AM, Roy Mendelssohn - NOAA Federal wrote:
Hi All:
NASA has used hierarchies for years, and appears committed
On 9/18/2013 7:56 AM, Roy Mendelssohn - NOAA Federal wrote:
Hi All:
NASA has used hierarchies for years, and appears committed to them. So, either
it is done in an ad hoc way, or through a standard. That doesn't mean CF is
the place for the standard, just that it would be nice to have one.
Hi Charlie,
Great that you have opened the door onto this discussion topic. Total
agreement from my pov that "group-awareness" in CF is an area that is
crying to be explored and solved. Your analysis of technical details
-- e.g. attribute scope and inheritance by group descendents, etc. --
You nailed it, Mike. H.5 is the intended illustration where "A9.2.3.2"
is referenced. Thanks for pointing out the error.
- Steve
On 5/28/2013 9:35 PM, Mike McCann wrote:
Hi,
I'm working on understanding how to properly express nominal and
precise locations for timeSeriesProfile data fr
On 5/23/2013 9:00 AM, John Graybeal wrote:
+1 Martin. I am bugged (not the technical term) by the conclusions here, which
seem to be: Because people design systems badly, I must constrain my own system
to accommodate their failures.
Hi John,
The flip side of this argument is even more comp
All,
I'm for option B, though I might be persuaded to go for option A given a
compelling counter-example. The example that has been given regarding
forecast times seems out of step with common CF practice in the
utilization of CF "forecast run aggregations". That context recognizes
forecast
s,
Philip
---
Dr Philip Cameron-Smith, p...@llnl.gov, Lawrence Livermore National Lab.
---
*From:*CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] *On
Behalf Of *Steve Hankin
*Sent:* Monday, April 01, 2013 9:13 AM
*To:
On 3/30/2013 11:08 PM, John Graybeal wrote:
On Mar 28, 2013, at 22:23, Chris Barker - NOAA Federal
wrote:
If it's not going to be used as the time coordinate, then we don't need a
standard_name or unit for it, as you don't need libraries to be able to
universally auto-detect it and be able
Hi All,
All interesting questions are questions of balance. This discussion
raises interesting questions. What are the issues we are balancing.
* On the one side is *technical precision*: how to correctly describe
the transformations that have been applied
* Balancing this is *usabilit
CF does support using ASCII strings for enumerated lists of named
objects: PI name, ship names, species names, etc. An important
encoding ability. That capability is not in question.
- Steve
On 3/28/2013 9:36 AM, John Graybeal wrote:
On Mar 28, 2013, at 17:54, Steve Hankin
<mailto:cf-metadata-boun...@cgd.ucar.edu>] On Behalf Of Chris Barker
- NOAA Federal [chris.bar...@noaa.gov <mailto:chris.bar...@noaa.gov>]
Sent: 27 March 2013 15:56
Cc: cf-metadata@cgd.ucar.edu <mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] New standard name: datet
On 3/27/2013 8:56 AM, Chris Barker - NOAA Federal wrote:
On Wed, Mar 27, 2013 at 8:05 AM, Steve Hankin wrote:
ISO date-time strings are a way of encoding the physical quantity
that we know as TIME. So TIME is the "right" standard_name for ISO
date-time strings per the definit
On 3/26/2013 7:20 PM, Aleksandar Jelenak - NOAA Affiliate wrote:
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_phy
On 3/26/2013 7:37 AM, Nan Galbraith wrote:
Jim, I think you use an 'ancillary_variables' attribute to tie quality
or other
variables together.
It's alarming to think people can use an unmodified standard name like
sea_water_temperature for a variable that is in fact a standard deviation
or an
On 3/25/2013 10:40 AM, Jonathan Gregory wrote:
Dear Ken
Thanks for your response too (copied here? is it bad form in a listserv to
consolidate responses like this?)
I think it's convenient, myself!
That answer seems so easy and obvious that I wonder if I asked the question
properly! I'll
Hi Ken,
As hoped, Jonathan, has already responded. I'm off on a tangent here ...
I want here to comment on a *wee* (and admittedly debatable) side
metadata issue -- the proper use of the "long_name" attribute. The
long_name is typically used as the source of a title string for plots
and l
On 3/21/2013 8:25 AM, John Caron wrote:
Probably my proposal comes down to 2 parts, which are separable:
1. Find a suitable replacement for udunits as a reference library for
CF calendar dates. Unfortunately, udunits used a slightly non-standard
syntax, which we need to still be legal for bac
On 3/20/2013 7:58 AM, John Caron wrote:
Hi all:
I guess I started this messy discussion, then invited everyone to
drink too much and say whatever they wanted. The conversation gets a
bit loud and fuzzy. So now we've switched back to caffeine and the
sober realities of deciding on grammars in
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/"
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#standard-name).
It is the 'units' string (
ov.uk
<http://www.metoffice.gov.uk/>
*From:* CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] *On Behalf
Of *Steve Hankin
*Sent:* 24 February 2013 19:07
*To:* John Caron
*Cc:* cf-metadata@cgd.ucar.edu
*Subject:* Re:
On 2/23/2013 11:01 PM, Chris Barker - NOAA Federal wrote:
[...]
Largely agree with the points that Chris has made, but want to follow up
on one of them.
when you have non-standard calendars, the difficulty is compounded many
times over. How many seconds since 1970 is April 3, 2045 at 1:13 a
On 2/23/2013 1:41 PM, John Caron wrote:
Hi Chris, and all:
On 1/11/2013 2:37 PM, Chris Barker - NOAA Federal wrote:
On Fri, Jan 11, 2013 at 9:00 AM, Aleksandar Jelenak - NOAA Affiliate
wrote:
Here's the modified proposal for the datetime_iso8601 standard name:
...
String representing date
fyi -- CF adopted as an OGC standard
(sorry for double postings)
--- Begin Message ---
-- Forwarded message --
From:
Date: Thu, Feb 14, 2013 at 1:18 PM
Subject: [Tc] OGC Approves Climate and Forecast (CF) extension to NetCDF
Core data model standard
To: t...@lists.opengeospatial.o
Hi Nicolas,
Various organizations enforce their own standards for abbreviated names
in CF files -- OceanSites, Argo, WMO, CF, itself, does not.
The reason that CF does not attempt to standardize the names of
variables (which is how the abbreviations are used in the above cases),
is
.
- Steve
$ cal 9 1752
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
but anyone who works with the dates of real historical events should be aware
of the need to put them into the same calendar.
Cheers
Jonathan
- Forwarded message
On 12/14/2012 9:35 AM, Jonathan Gregory wrote:
Dear Cecilia, Steve et al.
Steve is right that mostly we use the Gregorian calendar. That is what I meant
mostly when I said that the default is the calendar we use. The real world
is mixed Julian-Gregorian, and I don't think dealing with this cale
Hi CFers,
For anyone needing a break from discussions of Gregorian calendars ;-),
the topic of how to encode uncertainties is opening up within OGC in the
attached email. The work under discussion here builds on CF 1.5 as a
normative standard and contains a CF 1.5 data model in UML (Figure 1
eat a remark that Steve Hankin made whose implications have not been
explored in this discussion: different countries adopted the Gregorian calendar
at different times. (Greece didn't adopt it till 1923!) So what is considered
a valid Gregorian date varies from country to country (and som
On 12/6/2012 4:09 PM, John Caron wrote:
Hi Cathy:
There no question that CF currently defaults to mixed gregorian
calendar. The discussion is whether thats the best choice (probably
not), and to advise users not to cross the discontinuity (eg store
modern dates starting from 1-1-1).
Im cur
On 12/6/2012 1:37 PM, John Caron wrote:
Hi Steve, Cecelia:
I agree we should move to a better default calendar, probably
proleptic_gregorian. We are stuck with mixed Gregorian for previous CF
versions.
I think we just need a proposal that says "As of version X, the
default calender is prol
On 12/6/2012 11:48 AM, John Caron wrote:
Hi Cecelia:
Thanks for this information. A few questions:
* So you are not supporting "standard Gregorian calendar" even though
thats the CF default?
John et. al.,
We ought to fix this in ambiguity the CF specification. Your quotations
around "sta
Cecelia et. al.,
An important and somewhat awkward topic. I like your suggestion,
myself. I might suggest slightly different terminology to describe it,
though. I think we are proposing that _for the present_ *gridspec
*and/or *ugrid *(there need not be the same answer for both) ought to be
Hello CF metadata experts,
I encountered the following pair of variable names in the CF standard
name list:
*
surface_carbon_dioxide_partial_pressure_difference_between_*air_and_sea_water*
and
*
surface_carbon_dioxide_partial_pressure_difference_between_*sea_water_and_air*
AFAICT, thes
Jonathan, David,
I probably sounded more negative than I intended. I was just raising
the concerns that should be balanced against an easy "yes". In public,
group discussions the forces of "no" are inherently weakened by the
social dynamics. That, and imho CF has long had an imbalance betw
Richard, Jonathan, et. al.,
As the famed Henning piece on CORBA stated -- in standards committees
"no" is a preferable answer to "yes" all other things considered. More
generality can often lead to less interoperability in CF or other data
standards.
Having CF time axes that run backwards
On 4/2/2012 4:52 AM, Jim Biard wrote:
I like Jonathan's suggestion.
Fine w/ me.
- Steve
On Sat, Mar 31, 2012 at 4:19 PM, Jonathan Gregory
mailto:j.m.greg...@reading.ac.uk>> wrote:
Dear all
John Caron proposed
> "Applications should treat the data as missing where the
ls/products is going to lead to more of these discussions.
- Steve
-Rich
On Thu, Mar 29, 2012 at 1:01 PM, Steve Hankin wrote:
Returning to Nan's valid example, the proposed wording isn't very attuned to
the valid needs of (in situ) observations. If the pressure sensor fails,
whi
Returning to Nan's valid example, the proposed wording isn't very
attuned to the valid needs of (in situ) observations. If the pressure
sensor fails, while other sensors remain active, then the Z auxiliary
coordinate becomes unknown but other parameters remain valid.The
observations have p
On 12/13/2011 4:28 PM, Seth McGinnis wrote:
I agree with your reasoning. It is worth considering the use of Groups, but
the approach should be weighed against the best proposals that can be
generated that stick to the classic model. Fundamentally the need is for 2
bit of semantics:
1. associ
On 12/13/2011 10:40 AM, Jonathan Gregory wrote:
OTOH, if we start thinking in terms of the extended model, a
Structure ("compound type" in HDF5 parlance) might be useful. What
do you think about starting to think about possible uses of extended
data model?
Thomas suggested groups. We could put t
John, Jon, Thomas, et. al.,
I will weigh in here with a vote _*against*_ creating another dimension
( a new axis type) to achieve vector component . In higher level code
creating a multi-dimensional vector object may well be an elegant
approach -- but I will argue in bullets below that at the
Nice work! Way to go Jeff!
On 12/5/2011 4:35 PM, Jeffrey F. Painter wrote:
Today I changed the state of CF Conventions 1.6 from "public draft" to
"published" after a couple of minor changes related to identification
of stations.
http://cf-pcmdi.llnl.gov/documents/cf-conventions/latest-cf-con
Hmmm, this quickly gets to be the kind of discussion where different
readers takes away different meanings, depending on their initial
prejudices. What are the semantics of "semantics" and "conventions"
(*)? If our interpretation of these words is that "semantics" refers to
*meanings* of lang
On 8/11/2011 9:14 AM, Upendra Dadi wrote:
Hi,
I have a related question about "bounds" attribute. I often see
regularly gridded latitude-longitude data which do not have "bounds"
specified when probably they should. But they almost always have
regularly spaced latitude and longitude values
Hi Jim,
[My gosh, two responses arrived as I typed this. A hot topic, clearly.]
The short answer depend upon what are you trying to *do* with values,
since conceptually a monthly average doesn't have a point location in
time -- it represents a range. When plotting, for example, it is
equall
nstrument_manufacturer Instrument_model
Instrument_sample_scheme Instrument_serial_number
TEMP_qc_procedure
TEMP_accuracy TEMP_precision TEMP_resolution";
and then
short INST_SN(depth) ;
INST_SN:long_name = "instrument_serial_number" ;
... etc.,
.
- Steve
=
On 7/14/2010 6:21 AM, Jeff deLaBeaujardiere wrote:
In another discussion, Steve Hankin wrote:
> CF generally favors attributes attached to variables over attributes
attached to files
This reminds me of a question I wanted to ask: d
Just my 2-cents. Hopefully this is helpful.
Dave Blodgett
Center for Integrated Data Analytics (CIDA)
USGS WI Water Science Center
8505 Research Way Middleton WI 53562
608-821-3899 | 608-628-5855 (cell)
http://cida.usgs.gov
On Jul 8, 2011, at 11:51 AM, Steve Hankin wrote:
Hi All,
Section
Hi All,
Section 4.1 says:
(http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html#coordinate-types)
"/Coordinate types other than latitude, longitude, vertical, and
time _*are allowed*_. To identify generic spatial coordinates we
recommend that the |axis| attribute
rajectories. Something needs to be clarified here, or
the examples changed.
This was ticket 37. Are there any comments from Steve Hankin, the
moderator, or any of the other people who contributed to writing
Chapter 9, or anyone else who knows more than me?
stand by. I think Chris has pointed
Hi Philip,
Compression by Gathering as defined in the CF document is not widely
supported in software. You should anticipate serious interoperability
barriers if you choose to use it. In view of the option to use
"chunked" netCDF4 compression transparently with the netCDF3 classic
API, ther
On 4/2/2011 2:03 AM, Stefano Nativi wrote:
Hi Upendra,
My plane was delayed ...
Please, find attached the draft CF-netCDF data model specification
that Ben and I are developing for the OGC.
In this version of the specification, the CF conventions are still
version 1.1. However, I have bee
good sleuthing!
On 4/2/2011 9:32 AM, Steve Emmerson wrote:
Dear CF'ers,
On 04/02/2011 05:42 AM, Jonathan Gregory wrote:
I don't really agree with this. Units are units, not descriptins of quantities.
The National Institute of Science and Technology (NIST) agrees that
information shouldn't be
On 3/26/2011 9:11 AM, Karl Taylor wrote:
Dear all,
I think "3 days since 1970-01-01" is a sensible statement, with "3"
being the number and "days since 1970-01-01" being the units. Would
anybody normally interpret "5 3 days since 1970-01-01" as meaning "15
days since 1970-01-01"? If not,
to go back and read the arguments, but I think I agree with
most of what Steve Hankin has said.
Best regards,
Karl
Hi Karl:
There are 2 things incomplete from my POV:
1) CF specifies calendars, but theres no reference library that
implements them. If CDMS does so then perhaps we can lever
On 3/17/2011 5:20 PM, John Caron wrote:
On 3/17/2011 12:19 PM, Steve Hankin wrote:
On 3/17/2011 9:50 AM, Christopher Barker wrote:
On 3/16/11 8:47 AM, John Caron wrote:
1. time instants vs time duration
- one must distinguish between dimensional time ("time duration",
units=&q
On 3/17/2011 9:50 AM, Christopher Barker wrote:
On 3/16/11 8:47 AM, John Caron wrote:
1. time instants vs time duration
- one must distinguish between dimensional time ("time duration",
units="secs"), and calendar time ("time instant", or "point on the time
continuum") *which is not dimension
On 3/16/2011 8:47 AM, John Caron wrote:
On 3/16/2011 3:57 AM, Jon Blower wrote:
Hi all,
There have been multiple interesting sub-threads of this
conversation, and I'm getting them a bit tangled, not helped by my
email client apparently not distinguishing clearly between quotes and
new mate
On 3/15/2011 9:28 AM, John Caron wrote:
On 3/15/2011 9:19 AM, Benno Blumenthal wrote:
I am sorry, but this conversation is more confusing that it needs to
be -- once calendar 360_day is chosen, there is nothing "fuzzy" about
month or year, and once calendar 365_day or 366_day is chosen, there
John et. al.,
It looks like this thread has reached reasonable conclusions:
1. units of days (or secs or mins) can provide an accurate encoding
for months ("days since 1930-01-01")
2. "units of measure" should not be quantities that vary
3. udunits could in principle offer calendar ty
On 2/24/2011 8:06 AM, Ted Habermann wrote:
Hello all,
There was some recent discussion about challenges related to adding
ISO metadata to netCDF files. Rich Signell mentioned some work my
group has been doing recently and John Graybeal pointed out that
initially that work has focused on the
On 2/11/2011 10:25 AM, Alexander Pletzer wrote:
*Hi,*
While reading
http://cf-pcmdi.llnl.gov/conformance/requirements-and-recommendations/1.5/
I found:
2.4 Dimensions
*Requirements:*
* The dimensions of a variable must all have different names.
This appears too restrictive.
Hi Eli,
There is a CF convention for storing multiple observations that is under
development at https://cf-pcmdi.llnl.gov/trac/ticket/37.The details
are still subject to changes, but the changes will probably be
relatively small. The spec that is on-line is a little out of date --
to be
[cross-posting this email to the cf-satellite list]
=
On 2/3/2011 1:11 PM, Janine Goldstein Aquino wrote:
Hi all,
At NCAR/RAF we have netCDF files with multiple time frequencies in the
same file:
dimensions:
Time = 18421;
Sps1 = 1;/
On 1/11/2011 4:28 AM, Bryan Lawrence wrote:
Hi Jonathan
Thanks for doing this. I think it's an important step.
Unequiviocally: CF needs an explict data model, independent of netCDF!
My take on this is that the right way to go forward is to produce an
abstract description (aka a data model) fo
Trial balloon:
This conversation circles around the idea of masks that serve a
discipline-specific purpose: a land mask for terrestrial types; or a
sea mask for ocean types. Each discipline finds it natural to have "1"
indicate valid points for his particular outlook. It will always be an
I second that thought.
On 12/14/2010 3:12 AM, Bryan Lawrence wrote:
Hi Dom
Actually, I think we really want:
http://cfconventions.org/something
(We own cfconventions.org, so we can point it where we want!)
And I would like in 2011 to have settled on a permanent answer to that
question!
Chee
On 12/13/2010 1:50 PM, Karl Taylor wrote:
Dear all,
Does anyone remember, why we didn't allow the "bounds" attribute to be
attached to a scalar coordinate variable? Currently CF requires the
user to include a dimension a size one if he wants to define
coordinate bounds:
"The advantage of
On 10/22/2010 6:13 PM, John Caron wrote:
On 10/22/2010 9:46 AM, Julia Collins wrote:
Hello,
Benno's comment provides a convenient entry point for me to describe a
recent problem.
On Fri, 22 Oct 2010, Benno Blumenthal wrote:
Note: if the time zone is omitted the default is UTC, and if both t
Months, &c
(the second M(inutes) can only occur after T so it is
distinguishable from M[onths]);
y, m, d, h, m, are integers;
s is integer or real;
unneeded components can be omitted.
Example: P7DT6H30M means an interval of 7 days, 6 hours, 30 minutes.
-Jeff DLB
th, nor do they have a maximum length (in contrast to what I said
before, sorry). So I can see some implementation challenges in NetCDF.
Cheers, Jon
-Original Message-
From: bennoblument...@gmail.com [mailto:bennoblument...@gmail.com] On Behalf Of
Benno Blumenthal
Sent: 21 October 201
Hi Jon,
Why do you see this as an issue of date-times as ISO strings in
particular? The same issues of precision are found in longitudes
expressed as a degrees-minutes-seconds string compared to a floating
point. Or indeed to a depth expressed as a decimal string of known
numbers of digits
Hi Chris (neighbor!),
From a technical perspective I think (although without detailed
investigation) that your particular slant on the particle tracking can
fit into standard CF 1.4 "5.5. Trajectories". There is no prohibition
in CF about defining other special axes -- such as a num_particl
Tony et. al.,
I support Benno's approach. This is an argument that goes back a very
long time (probably 20+ years!). I have always taken the same position
that you have -- namely that the proleptic Gregorian calendar is the
common sense one to use for scientific (though not social science)
10/13/2010 10:39 AM, Steve hankin wrote:
Hi All,
2 cents: Since this is a new twist on previously discussed feature
types, the tires of alternative approaches probably deserve to be
kicked. What's special about this use case is that the trajectories
are all synchronized in time. (Though
Hi All,
2 cents: Since this is a new twist on previously discussed feature
types, the tires of alternative approaches probably deserve to be
kicked. What's special about this use case is that the trajectories are
all synchronized in time. (Though with differing start/stop times.)
Analogo
Hi Aleksander,
I'm understanding that your data have a time and spectral frequency
axes. Maybe also lat/lon position of the satellite as a function of
time? (i.e. defining a trajectory)
With only this to go on it sounds like the simple CDL below might be be
a sufficient outline. (You woul
Hi Aleksandar,
Satellite datasets have a range of needs that the
PointObservationConventions (a.k.a. Discrete Sampling Geometries") don't
try to address. It might be worth your while consulting with some of
the individuals who are working on applications of CF to satellite obs.
I've cc'ed
44 (*new*)
Skype ID:crazit
altE-mail: craig.don...@gmail.com <mailto:craig.don...@gmail.com>
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Steve Hankin, NOAA/P
__
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Steve Hankin, NOAA/PMEL -- steven.c.han...@noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
"The o
[Ken, Craig -- a quick look please?]
As a general rule level 3 satellite fields are "representative" -- or
perhaps "accumulated" would be an alternative term. They are the
accumulated result of a number of satellite passes that take place at
distinct times, and then perhaps some interpolation
bove
proposal, as it is secondary to Martin's original suggestion, and I
feel sure it will have to be considered at some length in TRAC if we
get that far. Just wanted to mention that the semantic technologies
can enable some very useful views/approaches to some of these problems.
John
Hi Martin,
You've had two enthusiastic "yes" responses, so I guess I have the
privilege to be the wet blanket. So it goes. I will give only a very
cautious and limited "yes". Not an outright "no" ... but a suggestion
for more thought and discussion.
The proposal here is effectively the c
end the lexicon and syntax when necessary.
Cheers
Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Steve Hankin, NOAA/PMEL -- steven.c.han...@noaa.gov
7600 Sand Point Way NE, S
or not? Its probably a common
enough problem.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Steve Hankin, NOAA/PMEL -- steven.c.han...@noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206
1 - 100 of 120 matches
Mail list logo
