Re: [CF-metadata] Choice of fill value for unpacked data
On 10/10/2012 6:36 AM, Jim Biard wrote: John, I agree that there is no ambiguity in the original dataset. I was just pointing out a scenario in which the difficulty mentioned by Phil in his original post would manifest itself. The methodology referenced by Russ won't handle it. If you (for reasons beyond your control) have a packed fill value that is inside your valid range, then no guidance is provided by CF to automated client software for how to represent the unpacked fill value, leaving the user with a requirement to dig back through the packed values, find the elements marked as fill, and "manually" mark the unpacked values. Its true CF is silent about this, so "automated client software" has to make their own Convention. The netcdf-JAVA package supplies a method boolean isMissing(double value); for this purpose. Alternately, it will just set missing real values to NaNs, which works well in Java. I think NaNs are the right choice for missing values myself. ___ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] Coordinate systems
Hi.
I mentioned I thought/concern I had about coordinate systems in CF as an aside
a while back, and I didn't much response, so I'm writing it now as a standalone
post.
When I look at the way geographic coordinate systems are implemented in CF, I
keep getting the feeling that the associations (in a UML sense) don't make good
sense.
What we have right now is that a variable has coordinates associated with it,
and also has a grid_mapping (a definition of a geographic coordinate system)
associated with it. Here's a cheap ASCII picture of that.
[coordinate]2-->*[variable]*<--1[grid_mapping]
*
^
|
|
2
[lon/lat]
I'm on purpose limiting myself for the sake of this discussion to the case of 2
coordinates (X/Y, lon/lat, etc) for any given variable. I know there can be
more, but we are still fuzzy on Z, and other coordinates that might be present
aren't geographic. I have also shown the longitude and latitude auxiliary
coordinates smashed together into a single element for compactness. I hope
it's not overly confusing.
Based on this model, the coordinates don't have a coordinate system except by
relation through a variable. As a result, the same coordinates could be
associated with different geographic coordinate systems in different variables.
You could two different grid_mappings defined (UTM zone 8 and Polar
Stereographic, for example) associate one with variable 1 and the other with
variable 2, yet have the same coordinates associated with both variable 1 and
variable 2. Furthermore, the longitude and latitude are assumed to relate (via
dimensionality) with the coordinates as defined by the grid_mapping, which
could (again) be different for each variable. This model seems more than a bit
fragile and unnatural to me.
The thing is, coordinates are meaningless without the definition of the
coordinate system they belong to. Starting from scratch, the natural approach
to this would be to associate coordinate systems with coordinates, which can
then be associated with variables. The diagram would be:
[grid_mapping]1->*[(aux) coordinate]*-->*[variable]
Each coordinate would have a geographic coordinate system associated with it.
A variable could have any number of (pairs of) coordinates associated with it.
Longitude/latitude or other auxiliary coordinates would fit into this model in
just the same way.
Written as CDL, what you would see is:
netcdf {
dimensions:
xt = 50;
yt = 50;
variables:
float xt(xt=50);
:grid_mapping = "TM";
:units = "m";
float yt(yt=50);
:grid_mapping = "TM";
:units = "m";
float temperature(xt=50, yt=50);
:coordinates = "lon lat xp yp";
:units = "K";
float lon(xt=50, yt=50);
:units = "degrees_east";
:grid_mapping = "LonLat";
float lat(xt=50, yt=50);
:units = "degrees_north";
:grid_mapping = "LonLat";
float xp(xt=50, yt=50);
:units = "m";
:grid_mapping = "PolarStereo";
float yp(xt=50, yt=50);
:coordinates = "xt yt";
:units = "m";
:grid_mapping = "PolarStereo";
char LonLat;
:grid_mapping_name = "latitude_longitude";
char PolarStereo;
:grid_mapping_name = "polar_stereographic";
char TM;
:grid_mapping_name = "transverse_mercator";
}
I left out the details of the grid_mapping variables for brevity.
So, having said all that, I'm curious to know if there is any particular reason
why geographic coordinate systems are being done the way they are right now,
and wondering if what I have described makes sense to anyone else.
Grace and peace,
Jim
Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001
jim.bi...@noaa.gov
828-271-4900
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
[CF-metadata] CF-netcdf for Mercator projection - use lat/lon, or xc/yc plus lat/lon
I have data that I'm putting into CF netcdf format (conventions 1.6)
that is in the Mercator projection. I'm trying to determine which
method is preferred for CF-compliance, in regard to the projection
information. The basic question is: Since the Mercator projection is
N-S-E-W, is there any need to provide projection coordinates (xc, yc)?
I can see the need to provide the projection coordinates for projections
such as Polar Stereographic.
Example 1: Use of x and y projection coordinates, with separate lat/lon
variables.
netcdf \1 {
dimensions:
xc = 287 ;
yc = 232 ;
time = 1 ;
variables:
char Mercator ;
Mercator:longitude_of_projection_origin = 135.f ;
Mercator:long_name = "projection information" ;
Mercator:standard_parallel = 0.f ;
Mercator:false_northing = 0.f ;
Mercator:grid_mapping_name = "mercator" ;
Mercator:false_easting = 0.f ;
float yc(yc) ;
yc:units = "m" ;
yc:standard_name = "projection_y_coordinate" ;
float xc(xc) ;
xc:units = "m" ;
xc:standard_name = "projection_x_coordinate" ;
int time(time) ;
time:units = "hours since 1970-01-01T00:00:00Z" ;
time:long_name = "starting time for grids" ;
time:standard_name = "time" ;
time:calendar = "gregorian" ;
float longitude(yc, xc) ;
longitude:units = "degrees_east" ;
longitude:standard_name = "longitude" ;
float latitude(yc, xc) ;
latitude:units = "degrees_north" ;
latitude:standard_name = "latitude" ;
float Wind_SFC(time, yc, xc) ;
Wind_Mag_SFC:_FillValue = -3.f ;
Wind_Mag_SFC:grid_mapping = "Mercator" ;
Wind_Mag_SFC:coordinates = "latitude longitude" ;
Wind_Mag_SFC:valid_range = 0.f, 64.30556f ;
Wind_Mag_SFC:standard_name = "wind_speed" ;
Wind_Mag_SFC:cell_methods = "time: mode" ;
Wind_Mag_SFC:units = "m sec**-1" ;
Example 2: Just using lat/lon coordinate variables, even though the
projection is not latlon.
netcdf \1 {
dimensions:
longitude = 287 ;
latitude = 232 ;
time = 1 ;
variables:
char Mercator ;
Mercator:longitude_of_projection_origin = 135.f ;
Mercator:long_name = "projection information" ;
Mercator:standard_parallel = 0.f ;
Mercator:false_northing = 0.f ;
Mercator:grid_mapping_name = "mercator" ;
Mercator:false_easting = 0.f ;
int time(time) ;
time:units = "hours since 1970-01-01T00:00:00Z" ;
time:long_name = "starting time for grids" ;
time:standard_name = "time" ;
time:calendar = "gregorian" ;
float longitude(longitude) ;
longitude:units = "degrees_east" ;
longitude:standard_name = "longitude" ;
float latitude(latitude) ;
latitude:units = "degrees_north" ;
latitude:standard_name = "latitude" ;
float Wind_SFC(time, latitude, longitude) ;
Wind_Mag_SFC:_FillValue = -3.f ;
Wind_Mag_SFC:grid_mapping = "Mercator" ;
Wind_Mag_SFC:valid_range = 0.f, 64.30556f ;
Wind_Mag_SFC:standard_name = "wind_speed" ;
Wind_Mag_SFC:cell_methods = "time: mode" ;
Wind_Mag_SFC:units = "m sec**-1" ;
Which example is preferred? If example 2 is used, should the xy
coordinates be provided as:
float xc(longitude) ;
float yc(latitude);
and use the coordinate attribute for Wind pointing to xc and yc?
Thanks.
Regards,
Mark
--
Mark Mathewson Consulting
535 Swanson Mill Rd.
Tonasket, WA 98855
509-429-8635
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
