Hi Jim,
one last question: Suppose I store multiple images in a single netCDF
file and each image has its own coordinates (think of the ISS flying
around earth and you take a sequence of images). Would it be allowed to
have:
dimensions:
time = 10 ;
y = 2832 ;
x = 4256 ;
channel = 3 ;
double lat(time, y, x);
double lon(time, y, x);
short img(channel, time, y, x);
img:coordinates = "lat lon" ;
...
I couldn't find any example where the coordinate arrays varied over time.
Thanks
Maik
On 02/06/14 15:44, Jim Biard wrote:
Maik,
Your coordinate variables in your example are latitude and longitude.
You don't have any other ones. Remember that dimension names and
variable names are not significant. The standard_name attribute value
(and, to a lesser degree, the axis attribute value) are the only
things that matter. If you had a coordinate variable with a standard
name of "projection_x_coordinate", then you would have an "x"
coordinate variable. Your coordinate variables have standard names of
"longitude" and "latitude".
CF examples are often incomplete, in an attempt to allow the
particular thing being exampled to stand out more clearly. I agree
that it's frustrating at times, as it can be hard to pull all the
parts together. It would be nice to have both the minimal examples and
fully-realized versions. That's quite an undertaking though.
Grace and peace,
Jim
On 5/31/14, 5:35 AM, Maik Riechert wrote:
Thanks for confirming that I can use grid mapping in that way. Maybe
then the following sentence isn't enough to capture that intent:
"When the coordinate variables for a horizontal grid are longitude and
latitude, a grid mapping variable with grid_mapping_name of
latitude_longitude may be used to specify the ellipsoid and prime
meridian." (CF1.6 section 5.6)
In my case the coordinate variables are x and y, and not longitude and
latitude which is why I thought I couldn't use latitude_longitude here.
Also, I think it is a good idea to include grid_mapping for every
applicable example in the CF document, with a forward reference in cases
where grid_mapping wasn't defined yet (before 5.6). If it's not possible
to make it a requirement, then at least CF should promote it as much as
possible.
Cheers
Maik
Am 30.05.2014 21:01, schrieb Jim Biard:
Maik,
I think it would be good to make a CRS specification a requirement for
every variable with geographic coordinates. Backward compatibility
requires that we allow a default in the case that nothing was specified.
This is all further complicated by numerous data sets which have been
produced with physical latitudes and longitudes, but no CRS was
specified. So it's a messy situation.
Your example looks good to me.
Grace and peace,
Jim
On 5/30/14, 11:37 AM, Maik Riechert wrote:
Hi Jim
Thanks for the detailed explanations.
If a spherical earth (of a certain radius) is the default, shouldn't it
be defined as such? Otherwise, having latitude and longitude coordinates
without a datum, as in example 5.2, would represent (partially) useless
data, quoting ISO: "without the full specification of the coordinate
reference system, coordinates (that is latitude and longitude) are
ambiguous at best and meaningless at worst".
As for the coordinate variables, just to be sure, let's visualize it a bit:
http://eol.jsc.nasa.gov/sseop/images/ESC/large/ISS030/ISS030-E-84614.JPG
Let's assume for each pixel center I know the latitude and longitude --
for those pixels covering the earth. That gives me each an auxiliary 2D
coordinate array for latitude and longitude. It is an irregular grid of
course. I would model this data as:
dimensions:
xc = 4256 ;
yc = 2832 ;
band = 3 ; // red, green, blue
variables:
byte img(yc,xc,band) ;
img:long_name = "color intensity" ;
img:units = "unitless" ;
img:valid_min = 0 ;
img:valid_max = 255 ;
img:coordinates = "lon lat" ;
img:grid_mapping = "crs";
float lon(yc,xc) ;
lon:standard_name = "longitude" ;
lon:long_name = "longitude" ;
lon:units = "degrees_east" ;
float lat(yc,xc) ;
lat:standard_name = "latitude" ;
lat:long_name = "latitude" ;
lat:units = "degrees_north" ;
int crs ;
crs:grid_mapping_name = "latitude_longitude";
crs:semi_major_axis = 6378137.0 ;
crs:inverse_flattening = 298.257223563 ;
Is that correct? I am new to the field so please don't hesitate to give
any kind of suggestion :)
Cheers
Maik
Am 30.05.2014 16:20, schrieb Jim Biard:
Maik,
You have wandered into an area that has a few hot-button topics
associated with it. I'll see if I can help clarify without riling anyone
else. :)
Here we go, in order of your questions:
The spherical Earth is a default. It harkens back to CF's origins in the
modeling community, where they often use a spherical Earth.
The latitude and longitude coordinates variables, if they are true
coordinate variables (and not auxiliary coordinate variables) must each
be monotonic. If they are auxiliary coordinate variables, I don't think
there is any constraint.
The naming "grid_mapping" is (personally) a less-than-perfect choice.
The variable named by the grid_mapping attribute contains Coordinate
Reference System (CRS) information. Even a latitude-longitude CRS needs
to be declared, as there are a number of these. (Their differences are
largely ignorable if you are working on 2.5 degree centers, but that is
an assumption that may not be warranted with observation data.) The
variable named by the grid_mapping attribute contains the declaration of
the horizontal datum, whether it is for a projected CRS or a
latitude-longitude CRS. Declarations of the vertical datum are still
being ironed out.
Depending on what you were wanting to do, you should be able to use the
contents of the variable named by the grid_mapping attribute, along with
a geographic coordinate system package, to convert the values in
variables containing X-Y coordinates or latitude-longitude coordinates
into any other reachable CRS. (Not all CRSs are reachable from all other
CRSs, but that's a different problem.) If you have both X-Y and
latitude-longitude coordinates in your file, the software can use
whichever it chooses, and can convert to another CRS however it choses.
If you only have latitude-longitude coordinates in your file, the
software can use those straight, or can convert to another CRS, but for
precise conversion you need to know which ellipsoid to use (and where
the origin is located, etc) for the latitudes and longitudes in the file.
Does that help?
Grace and peace,
Jim
On 5/29/14, 6:30 PM, Maik Riechert wrote:
Hi,
I am confused about the following sentence in CF 1.6 under the
Latitude-Longitude heading in appendix F:
"This grid mapping defines the canonical 2D geographical coordinate
system based upon latitude and longitude coordinates on a spherical Earth."
First, why "spherical"? In example 5.9 it is used with WGS84.
Then, does the first sentence refer to a grid which must be regular? Can
it also be rectilinear? Or even irregular?
I think my main confusion is that latitude_longitude and
rotated_latitude_longitude are probably not projections but the rest of
the grid mappings is. Yet there is no clear differentiation between the
two types in appendix F.
I think the term "grid mapping" also adds to my confusion. To me, it
means that I define a mapping from my data array (the grid) to
latitude/longitude coordinates in a descriptive way, that is, as an
implicit transformation operation described by the parameters of the
grid mapping variable. In the case of the projections it makes sense.
You can completely ignore the latitude/longitude arrays and just use the
grid mapping to recompute the latitudes/longitudes (if you were a
software that draws the data on a map). Right? But for
latitude_longitude and rotated_latitude_longitude, this is not the case.
Here the software would be required to use the latitude/longitude
arrays. Is this right? If yes, then should I consider latitude_longitude
as a datum definition with an unknown projection?
I hope I could explain my confusion while not confusing you too.
Thanks for your time,
Maik
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
CICS-NC<http://www.cicsnc.org/> Visit us on
Facebook<http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC<http://cicsnc.org/>
North Carolina State University<http://ncsu.edu/>
NOAA's National Climatic Data Center<http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e:[email protected]
o: +1 828 271 4900
--
CICS-NC<http://www.cicsnc.org/> Visit us on
Facebook<http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC<http://cicsnc.org/>
North Carolina State University<http://ncsu.edu/>
NOAA's National Climatic Data Center<http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e:[email protected]
o: +1 828 271 4900
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: [email protected]
o: +1 828 271 4900
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
