[I'm personally happy with Github, but count as an interested person / long
time lurker!]
A lot of open source projects resolve this problem by splitting the
conversation into two mailing lists. One is typically "-devel" for developers
(in this case, anyone working on the standard or
On 27/06/14 11:56, Maik Riechert wrote:
is the plate carrée projection really missing as a grid mapping in the
CF conventions? If so, why?
I suspect a lot of people just use the latitude_longitude mapping as a
proxy for this and otherwise don't worry about it. It probably would be
better to
On 12/03/14 17:41, Jeffrey F. Painter wrote:
You may have gathered that I don't think the highlighting system has
worked as well as originally intended, so I would welcome a change -
whether or not we continue to use DocBook, etc.
As someone that reasonably often consults the conventions
Hi Alison,
On 20/12/13 11:50, Frederic MELIN wrote:
For the rest, I'd recommend:
volume_absorption_coefficient_of_radiative_flux_in_sea_water_due_to_dissolved_organic_matter_and_non_pigmented_particles;
...
is the sum of the other 2, and is a standard satellite product (the other 2
terms
On 11/11/13 18:47, John Graybeal wrote:
I'm looking for the latest status of presenting swath data in CF. I
I think most user-level satellite swath data follows the principle of
providing full (or at least tie-point) lat/long grids, e.g.
Hi Randy,
Thanks for the explanation - that cleared things up a lot for me and I
certainly see what you're getting at now. I liked the resolution
proposal and could see us and many others using that too. I think this
requires no standard name and is just an addition to the cell methods
part of
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, but it
On 12/12/2012 11:06 PM, Steve Hankin wrote:
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).
At a glance it is apparent that
On 28/09/12 12:40, Martin Raspaud wrote:
Within this context, we would like to associate a palette of (rgb)
..
However, I can't find information on how to do this in netcdf and more
particularly within CF.
This is really a presentation issue and, as such, I don't think it's
been addressed
Hi Jonathan,
On 13/06/12 14:40, Jonathan Gregory wrote:
There is an open CF trac ticket, opened by Etienne Tourigny
https://cf-pcmdi.llnl.gov/trac/ticket/77
which proposes to add the sinusoidal projection to the list of CF grid
mappings. This is a simple change to make. It would be helpful if
On 06/18/2012 10:44 PM, Hoang, Anthony T. wrote:
I’ve fixed the mail problem………Please try requesting a trac account
now.
All worked perfectly, thanks very much!
Cheers,
Mike.
br /
hr /
pfont face=Arial size=1
Plymouth Marine Laboratorybr /
Registered Office: br /
Prospect Placebr /
The
On 30/03/12 15:01, Corey Bettenhausen wrote:
To the CF group in general, how can I help to introduce groups into
the CF conventions? And also extend CF to HDF5? What's the first
step I need to take?
My experience is that coming up with a proposal or two is a good start,
as it will often get
Hi Corey,
Just to give you a bite on the netCDF4 issue, I don't see any reason
why CF couldn't bless netcdf4 with all elements in a root group, though
one could reasonably argue this isn't really any improvement on using
the classic model.
It would be more useful (imho) to recommend that all
Hi Cauquil,
On 12/03/12 15:29, Cauquil Pascal (Capgemini) wrote:
We intend to use netcdf4 for this new program to use compression and
group possibilities but, we want also to be compliant with CF-1.6
convention.
Do you think it is a possible to display CF-1.6 compliant using
these 2
Now I *think* I mostly understand the problem - thanks for the summary
explanation, Jonathan, and apologies for the earlier missing-the-point :)
However, I probably still need a bit more straightening out or have
missed the point again.. I'd be grateful to understand more about why
one needs a
On 02/11/11 20:20, Mike Grant wrote:
I'll put that in another email as this is already way too long and I
suspect it's unworkable ;)
Trying to address wanting different standard_names, shared or different
flag_meanings and shared or different flag data..
Extend the idea in Jonathan's #2
Hi Jon,
Thanks for the helpful summary :) We have had similar issues with
handling data that represents time periods, and it'd certainly be good
to find some way to address that.
On 21/10/10 15:28, Jon Blower wrote:
1. Steve and Roy both asked (I think) why we can't have a more general
notion
On 19/04/10 15:43, Jonathan Blower wrote:
specification, which datum should be assumed? Spherical Earth? WGS84?
If you're picking one at random, I'd go for WGS84 - that's a pretty safe
bet for a lot of remote sensed and GPS related data.
Cheers,
Mike.
18 matches
Mail list logo
