t very friendly to the tools that we are
>currently using.
>
>
> Thanks in advance,
>
> - Tom
>
>
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-m
sea_ice_melt_pond_area)/sea_area ? or divided by
sea_ice_area?
Sorry for this lengthy email, hopefully I am not the only one confused about
this, and it can help others.
Regards,
Thomas
>
> Best wishes
>
> Jonathan
> _______
> CF-metad
Dear all,
During early summer, especially in the Arctic, melt water ponds form on top of
sea ice. Seen from above, there are thus 3 types of surfaces: "sea ice", "melt
ponds", "ocean water" (in between the ice floes). Seen from below, there are
only 2 area types: "sea ice", and "ocean water".
nds since "
}
Cheers,
Thomas
>
> Best wishes
>
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
=
Dear all,
I need a new standard_name, inspired by the existing one on sea_ice_extent. The
aim is to count the area of surface covered by snow (in the sense of "land",
that is excluding snow over sea ice) .
A standard name for snow cover extent (total snow covered area) similar to that
for sea
Dear Mark, and all,
Going through this very interesting thread once more, I wonder if one solution
to make the definitions evolve could be to introduce a new grammar to form the
standard names of vector components by using a mechanism à la standard name
modifiers.
You might know I started on
ion for the umbrella variable is
> different
> viz. to identify a group of data variables which together constitute a
> single
> higher-level geophysical quantity.
>
> Best wishes
>
> Jonathan
> ___
> CF-metadata mailing
and another for user-provided categorizations,
> which would then be enumerated in the same file.)
>
> Cheers,
>
> --Seth
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> ht
Hei Jonathan, and all,
- Original Message -
> > At the current stage, it would be valid to define an umbrella vector
> > variable from two component variables, one being dX(time,xc,yc) and
> > dY(time,height,xc,yc). What would be the meaning of such a
> > construct? And if invalid, how ca
Dear Jonathan,
- Original Message -
> > Thus, although I am unsure we should impose it from the convention,
> > e.g. by allowing to define some attributes from the "umbrella" level
> > (such as :coordinates), I see little use for defining vector objects
> > that do not share all their dime
say, and these could be
> proposed as
> required. The new standard names would be permitted only with the
> umbrella
> variables, or with ancillaries of the umbrella variables.
>
> Best wishes
>
> Jonathan
--
==
Thomas Lavergne
Norweg
omponents"
attribute. A revisit/cleanup of many definitions of existing standard names of
component variables could also be envisaged.
This proposal needs to be more thouroughly discussed. Those CF users handling
vector quantities could check against their file if this approach breaks
>Reference
> >System properties in Well-Known Text format" :
> >
> > https://cf-pcmdi.llnl.gov/trac/ticket/69 >
> > <https://cf-pcmdi.llnl.gov/trac/ticket/69#comment:31> >
> >however, the intention is for this principle to guide future CF
> >proposals
> >also.
> >
>
nt?
> >>>
> >>> Best wishes
> >>>
> >>> Jonathan
> >>>
> >>> ___
> >>> cf-satellite mailing list
> >>> cf-satell...@unidata.ucar.edu
> >>> For list information or to u
ise for the
> moment.
>
> Best wishes
>
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
==
Thomas Lavergne
Norwegian Meteorologic
; that this becomes a large problem which we can't deal with
> effectively, we
> will have to think again. So far that has not happened.
>
> Best wishes
>
> Jonathan
> _______
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailm
Dear all,
This message is to revive (part of) a short-lived thread in the last days of
May 2011. Jonathan was kind enough to answer some of my questions then, but it
never ended in a definite solution to my problem, thus the need (for me) to
revive the subject.
I have a (satellite product) dat
Dear Laurent, Bruce, Jonathan, and all,
May I step in?
Laurent expresses a need for new standard names related to sea ice type, from a
modellers point of view. I would like to take the opportunity to also discuss
standard names for such quantities, but from a satellite observation point of
vie
Dear Jonathan,
I would like to comment on the issue you are pointing out for
sea_ice_displacement, as I introduced this standard name.
- "Jonathan Gregory" wrote:
> sea_ice_displacement -> magnitude_of_sea_ice_displacement
>
> This change is proposed so that "sea_ice_displacement" is defin
Dear Karl,
I agree with the points you made and do not think we will get along with simple
changes and yet cover all the possibilities.
I also like your remark that the lines connecting the vertices are not
necessarily straight lines in CF.
However, you write:
> In the measurement examples
e variable identified
> by
> > > the bounds
> > > attribute, but the cell perimeter is not uniquely defined by its
> > > vertices (because
> > > the vertices could, for example, be connected by straight lines,
> or,
> > > on a sphere,
> >
Dear all,
I do not think someone reacted on my concern/question about non-polygonal cell
boundaries. Maybe I am the only one with this issue or maybe this topic went
un-noticed because of heavy load on the CF list at that time.
I thus re-post my original message in hope that someone will comme
ure recorded by all stations
found in a radius of, say, 30 km around the central point.
Another example is satellite data in swath projection where each record is
associated to a Field Of View, which is often approximated as a an ellipse.
Did someone give it a thought already?
Cheers,
Thomas
--
Dear John,
- "John Caron" wrote:
> The geometry of each point is an interesting wrinkle, and may need
> some new conventions. would a rotated ellipse work (3 params) or do we
> need a more general polygon? Does it have to be specified per point,
> or can is be common to all points? I would i
Dear all,
This is a good very good idea and I hope I will be able to participate.
May I point out that:
1) swath data should be able to include non-scanning instruments (conical
sensors like SSM/I, AMSR-E, etc...) so that along-track/cross-track might be
better than along-track/along-scan.
2
ot think they should continue in this context.
As far as I am concerned, and unless someone comes with strong opinion against
them, those names, definitions and units are suitable and I am happy if you
close the subject.
Cheers,
Thomas Lavergne,
Research Scientist, met.no, Oslo, Norway
-
>> That's the
> >> moment for which the model stores the data, whether they're
> >> instantaneous
> >> values (intensive variables) or time-averages over the previous
> timestep
> >> (extensive variables).
> >>
> >> If you used the
Dear Jonathan,
- "Jonathan Gregory" wrote:
> Dear Thomas
>
> I'm not saying the coordinate *must* be the mid-point. If there's a
> good reason
> for it being something else, then you could choose it to be so. I was
> suggesting that we could recommend it should be the mid-point if there
> is
Dear Jonathan,
Thank you for rapid answer. I agree that the mid-point is the most obvious
choice, BUT:
Shouldn't we start by identifying what kind of variables we are referring to?
Forgive me if my semantic is not accurate:
1) intensive variables : for those there is no problem, since bounds a
Dear all,
I would like to push the discussion a bit further on those cell bounds.
We agree that some variables are intensive, others are extensive. For coping
equally well with both types of variable, the CF convention offers the notion
of coordinates (axis) and cell bounds.
However, there s
Dear all,
Mea culpa.
Due to a mistake in my own software, I was the one writing 'shifted' X and Y values in my netCDF
files. Although they were never explicitly named, the software development team deserves my
apologies :-/. It took me some time to investigate and make sure that it was my mist
Dear Jonathan,
We should not be overly surprised by the choice made by some applications. Software were designed
and developed before CF conventions (or even netCDF) came in place and, in the slow process of
adapting to new standards, need to keep backward compatibility with previous ways of do
Hi,
I apologize if this was discussed already but I did not find it explicitly in the archive nor in the
standard document.
I have datasets mapped in a polar stereographic projection. My file structure
is thus something like:
dimensions:
xc = 119 ;
yc = 177 ;
variables:
Hi Alison,
Thanks for taking the time.
I think I agree with the current definitions with your modifications. I am happy we could be a bit
less strict on the time bounds and that I could convey the idea that "a displacement does not
prescribe a trajectory". I will now communicate with my 'scient
Hi Alison and all,
Pamment, JA (Alison) wrote:
Not all standard names proposals lead to a great deal of discussion. I
think that your names are fairly straightforward and certainly nobody
has objected to them. A very important part of including new names in
the table is to make sure the quanti
Hi all,
In the 'units' attribute of any time variables, there must be a mention of the
epoch:
:units = "seconds since 1978-01-01". Does this epoch needs to be a string?
For example, if I have a time variable which indeed is a "delta time". Its unit is "seconds since
reference_time". And this "
Hi Jonathan,
eastward_sea_ice_displacement [m] (length of [lon0,lon1] on Earth
surface)
northward_sea_ice_displacement[m] (length of [lat0,lat1] on Earth
surface)
sea_ice_x_displacement[m] (length from P0 to P1, taken along
the grid's X axis)
sea_ice_y_displacement
on to North of the
[P0,P1] vector)
I can clarify my point further when the discussion starts, if needed.
Have a nice week-end,
Thomas Lavergne
met.no - Oslo - Norway
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
38 matches
Mail list logo
