Make modifying `Cube` `CoordSystem`s easier

[trexfeathers]

From conversations on #4719:

The proposal in Step 2 will often give rise to code like this:

for cube in my_cube_list:
   for coord in cube.coords():
   	coord.coord_system.encode_axis_order = True
my_cube_list.save("tmp.nc")

Which is quite clunky. We also regularly find user confusion about the difference between Coord.coord_system and Cube.coord_system(), and adding the need to do the above will only increase the frequency of confusion.

So: it would be good to provide more convenience for modifying coord_system at the Cube level - i.e. automatically modify the coord_system of all Coords attached to the Cube, assuming they are identical.

If sensible, we think it should take the form of Cube.coord_system - a @property that can be set - rather than the current method (coord_system()), which just invites confusion. The method would have to stay until the next major release of course.

---

suggestion is going to be clunky; coordinate_system objects aren't shared across coordinates, so would either need a rehaul of how it works, or more effort on the user's side.
Instead, we would offer a docstring tutorial in the new code. This seems to be the more sensible option.

[larsbarring]

This might be a naive question, but is there a use case for having different grid mappings for different coordinates?

[trexfeathers]

This might be a naive question, but is there a use case for having different grid mappings for different coordinates?

The CF data model actually attaches grid mappings to the data variables, which has often seemed odd to us. Following CF would force us to NOT have different grid mappings for different coordinates.

Of course Iris has done the more 'sensible' thing of storing coordinate systems on the coordinates themselves, since that is where they have meaning, so this allows coordinates to 'move around' and be used in different Cubes. And it already allows for different grid mappings on different coordinates - they just can't be saved.

Whatever we do with this issue will need to account for different coordinates having different CoordSystems.

[pp-mo]

This might be a naive question, but is there a use case for having different grid mappings for different coordinates?

The CF data model actually attaches grid mappings to the data variables, which has often seemed odd to us. Following CF would force us to NOT have different grid mappings for different coordinates.

Of course Iris has done the more 'sensible' thing of storing coordinate systems on the coordinates themselves, since that is where they have meaning, so this allows coordinates to 'move around' and be used in different Cubes. And it already allows for different grid mappings on different coordinates - they just can't be saved.

Whatever we do with this issue will need to account for different coordinates having different CoordSystems.

Well, that's only the case for the "classic" grid-mapping syntax.
There is provision in CF for different coord systems applying to different coordinates.
.. but it's outstanding work for us to support it
See : #3388

This might be on its way now, since we are hoping to make #4719 work

[larsbarring]

Probably I was misunderstanding the comment

... coordinate_system objects aren't shared across coordinates ...

as meaning that e.g. x and y coordinates could have different gridmappings attached to them. But, as was noted in #3388, referring to CF Example 5.10, a data variable, Cube, may have several gridmappings, but each one is attached to the coordinates (plural) that define the grid.

[ESadek-MO]

@SciTools/peloton Sorry for any confusion, here's what we know:

We can't think of a use-case for different coord systems on x and y, although there might be one we don't know about. Iris can store this situation now, but all of Iris' operations assume that they will be identical. The CF extended grid mapping makes it possible to load and save different coord systems, see #3388 for making this possible in Iris.

[trexfeathers]

During the work on #6536, @ukmo-ccbunney and I worked out that it is not appropriate to have this as a CoordSystem property - in the file it is controlled on the data variables (the Cubes), so that is what we're going with for the least possible confusion: 564c37c

So this issue is now unnecessary. Closing.