Ability to specify grid_mapping name

[vsherratt]

✨ Feature Request

When saving a netCDF file, it would be helpful to have an option to choose the names used for "grid mapping variables" - the dummy variables used to hold parameters for coordinate reference systems.

Motivation

I have to provide data for a system that appears to be strangely specific about things like this.

In fact, the final product may not be so picky, but its specification does strongly imply that a specific grid_mapping must be used. And of course there's a simple enough workaround, to save the files as usual then tweak them with netCDF4.

Whether or not it's required on this particular occasion, it's possible that there may be some future need for it. It strikes me as very similar to choosing the _FillValue, which Iris does expose as an option.

Additional context

If I've interpreted the CF conventions correctly:

• Every variable and dimension may have a grid_mapping attribute, which should be the name of another variable in the file (a "grid mapping variable")
• A grid mapping variable has no data, only a grid_mapping_name attribute and various attributes as required by the CRS to define it
• The actual name used for the grid mapping variable is irrelevant, as long as it's consistent. Iris chooses it to be the same as the grid_mapping_name.

@stephenworsley has suggested that the cleanest way of implementing this would be to add a CoordSystem.var_name attribute, in line with Cube.var_name and Coord.var_name. This would also allow a slightly more consistent round-trip when loading and re-saving netCDF files, by simply setting that attribute according to whatever is found in the file.

[bjlittle]

@bsherratt Thanks for taking the time to raise this. We've briefly discussed this and we feel that we'd like to discuss this more openly, so I'm going to covert this issue to a GitHub Discussion... and we can take it from there.

Thanks again 🍻

[bjlittle]

@SciTools/iris-devs Let's start thinking about @bsherratt issue, which might run deep and wide within iris... thoughts?

[trexfeathers]

@stephenworsley has suggested that the cleanest way of implementing this would be to add a CoordSystem.var_name attribute, in line with Cube.var_name and Coord.var_name. This would also allow a slightly more consistent round-trip when loading and re-saving netCDF files, by simply setting that attribute according to whatever is found in the file.

From my naïve standpoint this approach sounds neat and makes sense, providing there are no hidden issues.

[bjlittle]

This strays into the Common Metadata API territory for me... i.e., we would be remiss to cheaply tack on a var_name property to a CoordSystem class

We took that approach several years ago with Cube and Coord et al, and we've been paying the technical debt levy ever since iris 3.0.0 made steps to address it.

[vsherratt]

I had actually tried tacking on a var_name, and it seemed to go fine. So I was a little confused to see a discussion opened up. But if there's work elsewhere to take a more common approach to metadata like this, then this indeed seems like a good point to include CoordSystems in that. How much work is it, and how much would it help with the technical debt?

[bjlittle]

@bsherratt Both very good questions.

Firstly, it shouldn't be too much work, thanks to iris 3.0.0, which tackled a huge amount for technical debt regarding metadata management within iris.

For me, changes in this realm should pretty much be additive, and justify the effort sunk into the common metadata API that we now have.

I guess my point here is that anything we do now hopefully only consist of mopping up any other first class objects within iris that can benefit from the common metadata API ground work. Hopefully, such new additions fit the existing pattern of the API, or only require minor course corrections.

It all sounds doable. However, what I am particularly interested in here are anti-patterns. Maybe CoordSystem or other such nuances we stumbled across unravel or challenge the data model... I'd love to know the answer to that 🤔

[pp-mo]

For me, this relates to the whole problem of "round-trip" data, i.e. what metadata in a file we currently discard on load, or can't control on save.
This is especially an issue for netcdf, as we have no easy way of intervening in read/write of low-level file data
( unlike PP/FF and GRIB, where we can "tweak" file data, in Python,
between file-read and iris-load or between iris-save and file-write (eg)
- if you want to do this with netcdf data, you must fiddle with actual files
).

For saving netcdf, we have added some special control aspects :

• data fill-value
• data packing
• unlimited dimensions
• some cube attributes are automatically saved as file-global, and others not, with some control provided

For loading, some extra metadata details are recorded (which might not have been) :

• var_name of data- and coordinate variables (but not bounds)
  • as discussed, it is questionable whether this "ought" to form part of the identity of a cube (let alone a coord-system)
  • but at present it does, and cube1 != cube2 if they have different var_names (even if one is None).
• file("global") and data-variable ("local") attributes

It may not always be a good idea to consider those things as part of "identity" -- as with var_name, but also the "history" attribute can be a problem.

Also, some things are lost altogether:

• dimensions : names, and "unlimited" status
• grid-mapping variables : var_name; additional properties; dtype (surely not significant??)
• data/coordinate/ancillary variables : valid_min and _max; some attributes matching reserved names of other things
• bounds variables : var_names; any additional properties; (possibly dtype, if different from main var?)
• file-ordering of dimensions + variables (+possibly attributes?)

[pp-mo]

I can see I should probably have put this somewhere else 😩

[pp-mo]

See also : #3325
And in fact others labelled "Feature: netcdf + cf-conventions"

BTW I would like to label this, but discussions don't take labels. Is that annoying/surprising or obvious ?
It seems hard to keep related things joined up. (edited : yes, you can!)

[pp-mo]

somewhere else

Now at : #4215