S?bastien,
I think mesh_grid_i/j_index standard names would be good additions. The
units associated with standard names in the table are not requirements,
but the use of the projection_xy_coordinate standard names would be
somewhat misleading, especially if there is no CRS involved. The
definitions could explain, in general terms, the relationship between
these and the 2D lat and lon grids. The satellite community has a
similar issue for image swath data. The native 1D coordinates are often
scan and sample (or names like that), which are unitless and have a
complex and dynamic relationship to latitude and longitude.
You are right to feel weird about identifying 2D lat and lon as Y and X
axes. The axis attribute should never be applied to 2D variables. It is
only valid for 1D "true" coordinate variables.
CF compliance is a fuzzy thing. You can have next to no CF attributes in
your file and still be CF compliant as long as the attributes you did
put in your file are properly formed and its structure is valid. I know
people are working on completeness metrics of various sorts, but I don't
think we have an application that will grade a file on how full its CF
implementation is.
Grace and peace,
Jim
On 3/30/17 5:23 PM, Sebastien Villaume wrote:
> Dear Jim and Karl,
>
> thank you for your quick answers.
>
> Karl, it seems that the tripolar grid mentioned in the link you sent is defined in this paper:
>
> Murray, R. J., 1996: Explicit generation of orthogonal grids for ocean models. Journal of Computational Physics, 126, 251-273
>
> which is cited by the paper from the NEMO group (Madec et al) that I mentioned in my original question. I need to check carefully if the definition is really identical or if they simply got inspired by the "Murray tripolar grid" and derived something similar but not exactly identical. In that case, it means there are several types of tripolar grids...
> One first difference I can directly identify is that the separation between the regular lat-lon and the modified part is not at the same latitude: 65N for Murray tripolar grid and 40N for the NEMO one.
> In any case, if someone already defined tripolar grids in a CF compliant way, I can definitely start from there.
>
> Regarding X and Y, I thought that "projection_[x|y]_coordinate" were used in the case of a projection on an Euclidian plane since the units of both standard names are "meters".
> What I am really after is more what you are suggesting later in your answer, i.e. mesh_grid_[i|j]_index. It feels weird to have a 2-D lat and lon as coordinates axis Y/X, this is why I need I would like to add those 1-D coordinate variables. I also noticed the grid_latitude and grid_longitude in the standard_name table but it is explicitly for rotated grids.
>
> Would it be possible to request mesh_grid_i_index and mesh_grid_j_index? (regardless of the feasibility of defining a proper tripolar crs)
>
> ____________________________________
>
> Dr. S?bastien Villaume
> Analyst
> ECMWF Shinfield Park,
> Reading RG2 9AX, UK
> +44 7825 521592
> sebastien.villaume at ecmwf.int
> ____________________________________
>
> ----- Original Message -----
> From: "Jim Biard" <jbiard at cicsnc.org>
> To: cf-metadata at cgd.ucar.edu
> Sent: Thursday, 30 March, 2017 17:42:01
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
>
> 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 sebastien.villaume at ecmwf.int ____________________________________
> _______________________________________________
> CF-metadata mailing list CF-metadata at cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> 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: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
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 _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170331/540fa343/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170331/540fa343/attachment.png>
Received on Fri Mar 31 2017 - 08:20:30 BST
