Hi all,
I could try to draft an new entry in grid_mapping or a new entry in Appendix D
(it will not be a dimensionless "vertical" coordinate but a dimensionless
"horizontal" coordinate)
Could we agree first on what I need to define? I don't want to invest too much
time in defining something before everyone agree on the way forward.
thanks
____________________________________
Dr. Sébastien Villaume
Analyst
ECMWF Shinfield Park,
Reading RG2 9AX, UK
+44 7825 521592
[email protected]
____________________________________
----- Original Message -----
From: "Jim Biard" <[email protected]>
To: [email protected]
Sent: Tuesday, 4 April, 2017 21:47:36
Subject: Re: [CF-metadata] CF compliant tripolar grid representation
Hi.
I tend to agree with Jonathan about the use of the grid_mapping variable,
although it would probably be necessary to provide a clear distinction between
this sort of information about mapping grid indices to lats and lons and
providing information about mapping projected coordinate axis values to lats
and lons. This new use is probably more appropriate for the name of the
variable ( grid _mapping). Having said that, the potential for confusion and
complication makes me wonder if a new construct isn't needed.
The problem that I see with x/y_coordinate_index is that the indices are very
likely indices to lat/lon coordinates, not x/y coordinates. They function as a
sort of unitless, non-geographic x and y, but I think it would better to avoid
overloading concepts. It's also possible that these indices could be indices to
x and y coordinates, so it seems to me that lat/lon_coordinate_index would be
no better. This is what led me to the names in my list that didn't use x, y,
lat, or lon. They could be useful in other scenarios, such as satellite swath
imagery, which have axes of scan and sample, so I didn't want to constrain the
terms too closely to the mesh grid scenario that this discussion started with.
Grace and peace,
Jim
On 4/4/17 4:25 PM, Jonathan Gregory wrote:
Dear Sébastien et al.
>From what you say I understand that the translation of indices to coordinate
values is rather ad-hoc, rather than being done by the same formulae for all
sorts of tripolar grid. You could identify the grid construction, if that would
be useful, in a non-standard way in some attribute such as "comment". To
provide a standardised description, I still think grid_mapping would be the
right place, but evidently "tripolar" would not be a sufficient definition.
Instead you would need different entries in Appendix D for the different sorts
of tripolar grid in use. In these entries you could certainly give URLs to
documentation, I think, as well as a description. The aim of putting it in
Appendix D would be to provide a source of information about how the indices
are related to coordinate values.
I suggested [xy]_coordinate_index because these phrases are already used in
standard names (one of each). If we don't like them now, we ought to change the
existing names, since we should be consistent. I think the phrase "coordinate
index" means "the index to a coordinate value". Just "index" would be less
informative, I feel.
Best wishes
Jonathan
----- Forwarded message from Sebastien Villaume <[email protected]>
-----
Date: Mon, 3 Apr 2017 13:56:40 +0000
From: Sebastien Villaume <[email protected]> To:
[email protected] Subject: Re: [CF-metadata] CF compliant tripolar grid
representation
X-Mailer: Zimbra 8.6.0_GA_1200 (ZimbraWebClient - FF50 (Linux)/8.6.0_GA_1200)
Hi Mark,
I agree that we need to find the best way to describe these grids (with the
appropriate controlled metadata) and not necessarily use an existing concept
(crs, grid_mapping) if it does not fit the purpose and generates confusion.
These tripolar grids are tricky and I guess this is why there is no standard
systematic way to describe them.
Reading more on it, I realized that some of them are not always "regular grids"
(by regular I mean monotonic increase of lat and lon when increasing i and j
indices): it seems that some NEMO configurations reuse some of the i and j
indices that are over land (large parts of Asia and Africa) and relocate them
over specific water regions to locally increase the grid resolution!
This can be seen here:
http://www.nemo-ocean.eu/content/download/7538/40914/file/meshmask_grid.pdf
Some of these grids do not have a simple analytical description since it is a
composite of several local descriptions. How can I then properly
reference/identify them? using an attribute like "model_grid_mapping" or
"model_mesh_mapping" or simply "mesh_mapping" instead of "grid_mapping" and
points to an URN/URI?
AMy main issue is that I can not derive directly from the metadata the type of
grid used. I have to plot it to know what it is and this is not satisfactory.
Regardless of the preferred solution (if one exists), I would still like to
have a proper standard name for my 1-D mesh indices i and j.
thanks
____________________________________
Dr. Sébastien Villaume
Analyst
ECMWF Shinfield Park,
Reading RG2 9AX, UK
+44 7825 521592 [email protected]
____________________________________
----- Original Message -----
From: "Hedley, Mark" <[email protected]> To: "Jim Biard"
<[email protected]> , [email protected] Sent: Monday, 3 April, 2017
10:28:05
Subject: Re: [CF-metadata] CF compliant tripolar grid representation
Hello All,
I'd like to pick up on an earlier comment from Jim:
If I'm not mistaken, we would need to propose a new grid_mapping to be
added to the Conventions that would define a Tripolar Coordinate Reference
System, along with any attributes that don't currently exist that are
needed to complete the definition. I did a search for a standard tripolar
CRS in proj4 or epsg, and was unable to find one. Is it possible to make
such a definition?
I don't think this is the correct approach
In my opinion, the tri-polar grid is described with respect to a Geographic
Coordinate Reference System: typically the one used to co-locate the
observations for assimilation, by spatial coordinates.
The 'Grid' is not a projection and it is not a coordinate reference system: it
is the description of a model grid.
In data files I have seen, each spatial location is defined by a location in
latitude, longitude and depth, with respect to a suitable geodetic datum.
I agree with your more recent comment Jim:
I'm wondering if x and y have too strong an association to projected coordinate
systems. I also like u/v, but that may be too strongly associated for some
people
with vector components (wind, for example).
I think that describing grid indices should be carefully distinguished from
spatial coordinates. Put a different way, I don't think a grid index can be
georeferenceable.
I think that a good deal of care not to confuse the grid indices with any
interpretation of 'grid_mapping' relations is required here.
I don't think that a CF grid mapping should be used to connect any description
of model index space with geographic space in these cases.
Sebastien states:
I would like to propose for addition standard names to support the mesh
indices/coordinates:
"mesh_grid_i/j_index" suggested by Jim
or
"x/y_coordinate_index" suggested by Jonathan
The mixing of the terms coordinate and index gives me pause for thought. What
information is being encoded here?
A key question I have is about the expectation for values of these indices,
under operations such as sub-setting. I have seen many files which do not have
coordinate variables for the x-like and y-like dimensions, the only horizontal
spatial metadata is contained in auxiliary coordinates.
Clearly I can perform index operations on these arrays, but I don't consider
the index values important and I don't preserve them.
Sebastien:
Is it the case that you would like to ensure that model index space values are
preserved, for example when removing a regional subset from a tri-polar ocean
model?
Would you like to be able to encode a result where it is clear that a regional
subset of 50 <= x < 150, 70 <= x < 120 has been taken from a larger extent
model?
If standard names are provided to encode such information, I would advocate
clear descriptive text stating that there is no mathematical relationship
between such index coordinates (i still don't like mixing these terms) and
projection coordinates or geographic coordinates
Sebastien states:
I have checked both IPSL and CNRM CMIP5 datasets. It is indeed NEMO datasets
and it is probably a
ORCA tripolar grid in both cases. I write "probably" because it is not clear
and conclusive
without plotting the datasets: lat and lon are 2D fields, the datasets define 2
extra 1D coordinates "i" and "j"
to be used as mesh indices (but without a proper standard name).
The datasets also have bounds for lat and lon, defined as "lat_vertices" and
"lon_vertices" which I think
is one solution to describe the tripolar grid. I would prefer something more
standardized and documented so
that one can quickly identify from the metadata that it is a tripolar grid
(defining the resolution,
where are the poles, how it is derived, etc.)
I appreciate the desire to have a standardised approach to defining such a
model grid. I would not advocate trying to use grid mapping variables
and relationships for this, I think this could do more harm than good.
I don't have a better suggestion to hand, I'm sad to say.
I am not raising principled objections to this conversation or the direction of
travel; I am raising waryness and caution about introducing further confusion
or implying stronger relationships than can be provided.
all the best
mark
From: CF-metadata [ [email protected] ] on behalf of Jim Biard [
[email protected] ]
Sent: 31 March 2017 23:26
To: [email protected] Subject: Re: [CF-metadata] CF compliant tripolar
grid representation
Hi.
I like the more generic x/y_coordinate_index name, but I'm wondering if x and y
have too strong an association to projected coordinate systems. I also like
u/v, but that may be too strongly associated for some people with vector
components (wind, for example). What do the rest of you think? Here are some
names that come to mind. Feel free to suggest something better!
* mesh_grid_i_index, mesh_grid_j_index
* grid_i_index, grid_j_index
* grid_i_coordinate, grid_j_coordinate
* x_coordinate_index, y_coordinate_index
* index_x_coordinate, index_y_coordinate (this ordering matches the
projection_x/y_coordinate naming)
* u_coordinate, v_coordinate
* i_coordinate, j_coordinate
* grid_row_coordinate, grid_column_coordinate
* row_coordinate, column_coordinate
The more I look at these, the more I like the last two.
As for a definitions, how about something like this variation on the ones for
the projection_x/y_coordinate?
column_coordinate: "column" indicates the fastest-changing dimension of a
two-dimensional grid, when this is not associated with a spatial coordinate
dimension such as longitude or projected X, positive with increasing column.
The column coordinate, possibly in conjunction with the row coordinate, serves
as a parametric driver mapping abstract grid positions to spatial coordinates
such as latitude and longitude.
row_coordinate: "row" indicates the the slowest-changing dimension of a
2-dimensional grid, when this is not associated with a spatial coordinate
dimension such as latitude or projected Y, positive with increasing row. The
row and column coordinates serve as a parametric driver mapping abstract grid
positions to spatial coordinates such as latitude and longitude. Grace and
peace,
Jim
On 3/31/17 5:37 PM, Sebastien Villaume wrote:
Hi all,
I have checked both IPSL and CNRM CMIP5 datasets. It is indeed NEMO datasets
and it is probably a ORCA tripolar grid in both cases. I write "probably"
because it is not clear and conclusive without plotting the datasets: lat and
lon are 2D fields, the datasets define 2 extra 1D coordinates "i" and "j" to be
used as mesh indices (but without a proper standard name). The datasets also
have bounds for lat and lon, defined as "lat_vertices" and "lon_vertices" which
I think is one solution to describe the tripolar grid. I would prefer something
more standardized and documented so that one can quickly identify from the
metadata that it is a tripolar grid (defining the resolution, where are the
poles, how it is derived, etc.)
I would like to propose for addition standard names to support the mesh
indices/coordinates:
"mesh_grid_i/j_index" suggested by Jim
or
"x/y_coordinate_index" suggested by Jonathan
I let the experts in standard names decide which pair suits best the present
case.
Regarding tripolar grids characteristics, I did some research and came to the
conclusion that "Murray tripolar grids" are not identical to "ORCA/NEMO
tripolar grids". This is true even without considering characteristics like the
grid resolution, the location of the poles or where the latitude boundary is
placed between the modified and unmodified parts.
The Murray tripolar grid (used by GFDL) has its "north" poles on the boundary
as shown here:
https://www.gfdl.noaa.gov/wp-content/uploads/pix/user_images/mw/bipolar.gif The
ORCA/NEMO tripolar grids have the "north" poles within the modified regions but
not on the boundary as shown in my original post:
http://www.geomar.de/typo3temp/pics/globe_grid2_14_b8edb639ae.png This
complicates things...
____________________________________
Dr. Sébastien Villaume
Analyst
ECMWF Shinfield Park,
Reading RG2 9AX, UK
+44 7825 521592 [email protected]
____________________________________
----- Original Message -----
From: "James Orr" <[email protected]> To: "Karl Taylor"
<[email protected]> Cc: [email protected] Sent: Thursday, 30 March, 2017
23:01:54
Subject: Re: [CF-metadata] CF compliant tripolar grid representation
The IPSL and CNRM cimate models that participated in CMIP5 both used the NEMO
model (ORCA2 and ORCA1 configurations) with tripolar grids. Both provided
output the was CF compliant.
James
On Thu, 30 Mar 2017, Karl Taylor wrote:
Hi Sebastien,
More than one group stored output on a tripolar grid in CMIP5. I'm pretty
sure they did it in a CF-conforming way. I know at least some of the GFDL
model output was reported on a tripolar grid, as described at
http://nomads.gfdl.noaa.gov/CM2.X/oceangrid.html (or search on "tripolar
grid" for additional links). You could look to their example, and see if you
think it is done correctly.
I don't think extensions or modifications to CF are needed for tripolar
grids.
best regards,
Karl
On 3/30/17 9:42 AM, Jim Biard wrote:
Sébastien,
If I'm not mistaken, we would need to propose a new grid_mapping to be
added to the Conventions that would define a Tripolar Coordinate Reference
System, along with any attributes that don't currently exist that are
needed to complete the definition. I did a search for a standard tripolar
CRS in proj4 or epsg, and was unable to find one. Is it possible to make
such a definition?
Regarding the standard names for your X and Y coordinate variables, I think
you could use "projection_x/y_coordinate" once a grid_mapping has been
defined. Of course you could always leave the attribute off, since a
standard_name attribute is not a requirement.
If making a new grid_mapping is not feasible, you could request standard
names along the lines of mesh_grid_i_index and mesh_grid_j_index. These
standard names would (on reading their definitions) make it clear that the
measurements are on a mesh grid for which there is no CRS. At least that's
what comes to mind at the moment.
Grace and peace,
Jim
On 3/30/17 11:52 AM, Sebastien Villaume wrote:
Hello all,
I am looking for the best approach to describe in a CF compliant way the
tripolar grids usually used in NEMO configurations.
Basically, the difference with a usual bipolar grid (north pole-south
pole) is that the north pole is split into 2 poles moved over Canada and
Russia (to have distortions/singularities not over the ocean). A good
visual representation can be found here:
http://www.geomar.de/typo3temp/pics/globe_grid2_14_b8edb639ae.png everything
south of the green line (40degN) is identical to a regular
grid, but everything north of it is computed using a technique described
here:
Madec, G. and M. Imbard, 1996 : A global ocean mesh to overcome the north
pole singularity. Clim. Dyn., 12, 381–388.
The usual NEMO output of the grid looks like this:
float longitude(y, x) ;
longitude:standard_name = "longitude" ;
longitude:units = "degrees_east" ;
longitude:long_name = "longitude" ;
float latitude(y, x) ;
latitude:standard_name = "latitude" ;
latitude:units = "degrees_north" ;
latitude:long_name = "latitude" ;
Basically both latitudes and longitudes need to be specified for each grid
point, hence lat and lon are 2D arrays. This is not a problem itself but I
would like to give more information through maybe grid_mapping or crs so
it is clear that the grid is tripolar. This is useful information if one
want to project/interpolate this back to a more regular representation.
Looking at the CF conventions, I can see that grids can be fairly nicely
documented but nothing for tripolar grids.
Is there some documentation/guidelines on how to derive a proper
grid_mapping/crs with valid attributes for tripolar grids?
I would also like to add to my netcdf file a way to better describe axes:
double y(y) ;
y:units = "1" ;
y:long_name = "j-index of mesh grid" ;
y:standard_name = ??? ;
double x(x) ;
x:units = "1" ;
x:long_name = "i-index of mesh grid" ;
x:standard_name = ??? ;
what would be the standard name of these?
Thanks,
____________________________________
Dr. Sébastien Villaume
Analyst
ECMWF Shinfield Park,
Reading RG2 9AX, UK
+44 7825 521592 [email protected]
____________________________________
_______________________________________________
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 National Centers for
Environmental Information <http://ncdc.noaa.gov/> /formerly NOAA’s National
Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: [email protected] <mailto:[email protected]> o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on
Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo> . /
_______________________________________________
CF-metadata mailing list [email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata --
Visit us on
Facebook Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA National Centers for Environmental Information
formerly NOAA’s National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: [email protected] o: +1 828 271 4900
Connect with us on Facebook for climate and ocean and geophysics information,
and follow us on Twitter at @NOAANCEIclimate and @NOAANCEIocngeo .
_______________________________________________
CF-metadata mailing list [email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list [email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
_______________________________________________
CF-metadata mailing list [email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Visit us on
Facebook Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA National Centers for Environmental Information
formerly NOAA’s National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: [email protected]
o: +1 828 271 4900
Connect with us on Facebook for climate and ocean and geophysics information,
and follow us on Twitter at @NOAANCEIclimate and @NOAANCEIocngeo .
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
