Dear Sebastien Apologies. I meant Appendix F (grid mappings) not D. Could you describe your species of tripolar grid as one of these? Maybe there aren't any parameters to be recorded.
Best wishes Jonathan ----- Forwarded message from Sebastien Villaume <[email protected]> ----- > Date: Wed, 5 Apr 2017 08:47:57 +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 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 ----- End forwarded message ----- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
