Hi.
I agree with Mark. In the case where the coordinate system does not correspond
to 'x = longitude, y = latitude', such as a polar stereographic system, x and y
are clearly identified by the definition of the coordinate system, and it makes
sense to allow a standard name to identify data
Hi Mark
I'm not suggesting the status quo is perfect, I'm suggesting adding
imperfection doesn't help us.
Your example below is different from what I am flagging up. Your example is of
one standard name meaning different things in different places, is just a
different version of one of the
Hi all,
My name is Sean Gaffney, from the British Oceanographic Data Centre, and I'm
working on a project dealing with numerical model data that are in CF compliant
NetCDF, so I thought I'd sign up to the community.
The project I am working on aims to develop a web-based delivery system for
Hi all,
I started off agreeing with Mark in this discussion and thought that
eastward_wind should be a special case of x_wind. However, I'm not so sure
now. eastward is a suitably imprecise concept to go with the
suitably-imprecise definition of longitude in CF (hence its evolution I
Heres my two cents:
The meaning of the x_coordinate and y_coordinate is actually well
defined. But it does not mean x=east and y=north. It means the input to
the projection function proj(x,y) - (lat,lon), which are defined in
appendix F, with pointers to reference software. AFAIU, these
On 4/19/2012 9:13 AM, Gaffney, Sean P. wrote:
Hi all,
My name is Sean Gaffney, from the British Oceanographic Data Centre, and I'm
working on a project dealing with numerical model data that are in CF compliant
NetCDF, so I thought I'd sign up to the community.
The project I am working on
Steve,
The Reading checker link is working again for me. Thanks to whomever
fixed this.
It is valuable to have access to completely independent checkers.
Among other things, they can catch each others' mistakes and
omissions. I hope that Juelich continues to maintain their checker
Hi Sean,
From your description, it sounds like you're confusing valid_min and valid_max
with actual_min and actual_max. The former attributes define theoretical
extrema, beyond which data is considered invalid (e.g., latitude 90 degrees
or precipitation 0). The latter are what modelers would
Sean,
I run into this frequently, especially with files that do not come
from carefully crafted official archives. I regard all flavors of
range attributes as frequently unreliable. I think best practice is
to extract ranges directly from the coordinate values when plotting
data on the fly, and
Hi Seth, all,
Sean did mean valid_min/max, not actual_min/max. His situation was a
curvilinear grid which requires latitude and longitude 2D data variables. The
valid_min/max should have been -90:90 for the latitude data variable, but were
set incorrectly (not by Sean) to a narrower range,
Ah, I see. Interesting. Maybe that's an argument for recommending that
valid_min/max be used sparingly and only when necessary, and not as generic
prophylaxis?
At least with regard to things like lat/lon coordinates, this example has me
thinking that it's more likely that one would encounter
11 matches
Mail list logo
