I'd tend to say that a rotated pole coordinate system is a lat/lon CRS
that specifies a non-standard origin / orientation relative to a datum.
There is a WGS84 datum as well as a WGS84 CRS. It is not necessary to
think of a rotated pole CRS as a transformation on the WGS84 CRS,
although that is also valid.
Not critically important, but it is valid to argue that grid_mapping
entries currently have nothing but CRS definitions.
It's unfortunate that the name grid_mapping was chosen if what we really
have is coordinate_reference_system. But that's history. The name
implies a broader range of valid contents.
On 4/6/17 12:35 PM, Hollis, Dan wrote:
> Hi Jonathan,
>
> As is often the case, it's both informative and interesting to know something of the history of these things.
>
> I approach the subject from the perspective of someone who uses GIS software to map small portions of the globe. Consequently I'm thinking of this in terms of map projections (e.g. as defined by EPSG codes) rather than the more general grid mapping concept you describe.
>
> I guess it's all a question of how broad you make the concept. I see 'rotated pole' as 'lat-long CRS + a transformation', which is why I said I didn't think it was a CRS - from my viewpoint I'd probably prefer to see the base CRS and the transformation defined independently. In practice the grid mapping concept already extends to include rotated pole grids - based on the comments from David and Mark, and the fact that grid mapping was first introduced for models, I guess this is well accepted. Whether the concept can/should be even further generalised to accommodate any arbitrary mapping is unclear to me - it's certainly another step removed from what I might expect grid_mapping to describe. Clearly, from your perspective, it always was a general concept so no reinterpretation is required!
>
> Regards,
>
> Dan
>
>
> -----Original Message-----
> From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
> Sent: 06 April 2017 16:35
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
>
> Dear Dan and Mark
>
> It's true that the rotated pole is a different case from the others in App F, which are map projections. However my understanding of the grid mapping is that it's a more general idea. It maps the 1D x and y coordinates of the grid to geographical space. Like all of CF, it was first introduced for models, which have idealised worlds. Subsequently other parameters were added to describe mappings for worlds of realistic shape. There are quite a lot of additions to grid_mapping attributes in agreed trac tickets now being incorporated in CF 1.7 for this reason.
>
> With this general idea, it seems quite natural to me that a mapping from grid x and y indices to geographical space, which is what the tripolar grid does, fits in grid_mapping. There are many other model grids in use which are also not map projections, where it might be convenient to use grid_mapping to pro- vide further information about the construction of the grid in real space.
> This would not require any new machinery in CF, except possibly attributes in grid_mapping for new parameters, so it's an economical solution.
>
> If the construction of the grid is really quite arbitary, then probably the only information grid_mapping could provide would be a link to documentation which explains how lat,lon relate to i,j. But that would still be useful, I think.
>
> The mention of Appendix D (rather than F) was my mistake.
>
> Best wishes
>
> Jonathan
>
> ----- Forwarded message from "Hollis, Dan" <dan.hollis at metoffice.gov.uk> -----
>
>> Date: Thu, 6 Apr 2017 09:10:40 +0000
>> From: "Hollis, Dan" <dan.hollis at metoffice.gov.uk>
>> To: "Hedley, Mark" <mark.hedley at metoffice.gov.uk>, "cf-metadata at cgd.ucar.edu"
>> <cf-metadata at cgd.ucar.edu>
>> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
>>
>> Hi Mark,
>>
>> I support your concerns. There is a difference between stating which geographic and/or projected CRS is being used and defining which specific points are included in the data set. The issue of describing a tripolar grid seems to relate to the latter not the former.
>>
>> From a quick glance at Appendix F I would say that the odd one out is the rotated pole. Describing a grid as 'rotated pole' is surely just convenient shorthand for describing which points in a lat-long CRS you are using. It is certainly not a CRS and, arguably, not a grid mapping. Is it possible, for example, to declare that a grid is 'rotated pole' _and_ that the CRS is WGS84?
>>
>> Perhaps tripolar grids and rotated pole grids are two parts of the same problem.
>>
>> Regards,
>>
>> Dan
>>
>>
>> -----Original Message-----
>> From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf
>> Of Hedley, Mark
>> Sent: 06 April 2017 09:28
>> To: cf-metadata at cgd.ucar.edu
>> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
>>
>> I would like to restate my concern about describing the tri-polar grid as a coordinate reference system, using the 'grid mapping' defined in approach in 5.6. Horizontal Coordinate Reference Systems, Grid Mappings, and Projections and Appendix F Grid Mappings.
>>
>> I do not think that the tri-polar grid is a Coordinate Reference System, unlike all other entities defined in Appendix F. I think that adding a tri-polar definition here fundamentally alters the interpretation of 'grid mapping' and has potentially significant implications for software providing capabilities to work with grid mapping entities.
>> This would represent a significant change of scope for these aspects of the Conventions document.
>>
>> Currently all entries in Appendix F are either a Geographic Coordinate Reference System or a Projected Coordinate Reference System.
>> The tri-polar grid is neither of these.
>> The mechanics of looking up the required longitude and latitude values
>> for a given x/i and y/j coordinate index are not mathematically
>> similar to the calculations for geographic or projected space
>>
>> I think the CF community would do well to consider where else information defining a tri-polar grid may be encoded in a file, and to keep the scope of the Grid Mapping section constrained.
>>
>> I saw Appendix D: Parametric Vertical Coordinates mentioned as well, all be it in passing. The tri-polar grid does not seem like a case of parametric coordinates either, to me, even if the 'vertical' was relaxed.
>>
>> I realise I am raising objections but not proposing solutions, I do not have an easy answer here, I am afraid.
>>
>> all the best
>> mark
>>
>>
>> ________________________________________
>> From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of
>> Sebastien Villaume [sebastien.villaume at ecmwf.int]
>> Sent: 05 April 2017 19:20
>> To: Gregory, Jonathan
>> Cc: cf-metadata at cgd.ucar.edu
>> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
>>
>> Dear Jonathan,
>>
>> I will try to look at Appendix F and come back with a proposal. I have a rough idea of what I need but I have no clue what would be the proper terms for those: extra attributes to describe north pole 1 and north pole 2, latitude separating the "regular" from the irregular region, etc.
>>
>> ____________________________________
>>
>> Dr. S?bastien Villaume
>> Analyst
>> ECMWF
>> Shinfield Park,
>> Reading RG2 9AX, UK
>> +44 7825 521592
>> sebastien.villaume at ecmwf.int
>> ____________________________________
>>
>> ----- Original Message -----
>> From: "Jonathan Gregory" <j.m.gregory at reading.ac.uk>
>> To: cf-metadata at cgd.ucar.edu
>> Sent: Wednesday, 5 April, 2017 16:15:55
>> Subject: Re: [CF-metadata] CF compliant tripolar grid representation
>>
>> 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
>> <sebastien.villaume at ecmwf.int> -----
>>
>>> Date: Wed, 5 Apr 2017 08:47:57 +0000
>>> From: Sebastien Villaume <sebastien.villaume at ecmwf.int>
>>> To: cf-metadata at cgd.ucar.edu
>>> 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
>>> sebastien.villaume at ecmwf.int
>>> ____________________________________
>>>
>>> ----- Original Message -----
>>> From: "Jim Biard" <jbiard at cicsnc.org>
>>> To: cf-metadata at cgd.ucar.edu
>>> 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
>>> <sebastien.villaume at ecmwf.int> -----
>>>
>>>
>>>
>>> Date: Mon, 3 Apr 2017 13:56:40 +0000
>>> From: Sebastien Villaume <sebastien.villaume at ecmwf.int> To:
>>> cf-metadata at cgd.ucar.edu 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 sebastien.villaume at ecmwf.int
>>> +____________________________________
>>>
>>> ----- Original Message -----
>>> From: "Hedley, Mark" <mark.hedley at metoffice.gov.uk> To: "Jim Biard"
>>> <jbiard at cicsnc.org> , cf-metadata at cgd.ucar.edu 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 [ cf-metadata-bounces at cgd.ucar.edu ] on behalf of
>>> Jim Biard [ jbiard at cicsnc.org ]
>>> Sent: 31 March 2017 23:26
>>> To: cf-metadata at cgd.ucar.edu 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 sebastien.villaume at ecmwf.int
>>> +____________________________________
>>>
>>> ----- Original Message -----
>>> From: "James Orr" <James.Orr at lsce.ipsl.fr> To: "Karl Taylor"
>>> <taylor13 at llnl.gov> Cc: cf-metadata at cgd.ucar.edu 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 sebastien.villaume at ecmwf.int
>>> +____________________________________
>>> _______________________________________________
>>> 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> . /
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> CF-metadata mailing list CF-metadata at cgd.ucar.edu
>>> 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: jbiard at cicsnc.org o: +1 828 271 4900
>>>
>>> Connect with us on Facebook for climate and ocean and geophysics information, and follow us on Twitter at _at_NOAANCEIclimate and @NOAANCEIocngeo .
>>>
>>> _______________________________________________
>>> 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
>>> ----- End forwarded message -----
>>> _______________________________________________
>>> CF-metadata mailing list CF-metadata at cgd.ucar.edu
>>> 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: jbiard at cicsnc.org
>>> o: +1 828 271 4900
>>>
>>> Connect with us on Facebook for climate and ocean and geophysics information, and follow us on Twitter at _at_NOAANCEIclimate and @NOAANCEIocngeo .
>>>
>>> _______________________________________________
>>> 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
>>
>> ----- End forwarded message -----
>> _______________________________________________
>> 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
>> _______________________________________________
>> 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
> ----- End forwarded message -----
> _______________________________________________
> 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/20170414/5d5a0a06/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/20170414/5d5a0a06/attachment.png>
Received on Fri Apr 14 2017 - 08:45:38 BST
