Investigate: subsetting a `MeshCoord` should return a `MeshCoord`?

[trexfeathers]

I might have some code that could help with this:

https://github.com/SciTools/iris/blob/6adac1b6f83baa2e1d4a13ced0d6748ff91092ee/lib/iris/tests/stock/init.py#L840-L886

[trexfeathers]

This is very closely linked to #4751 - it's probably a choice between 1 and the other

[stephenworsley]

Another potential route for subsetting a mesh is proposed here #6014.

---

After considering this I see essentially two alternatives to the current behaviour for subsetting a MeshCoord.

1. A MeshCoord is returned whose Mesh is a reduced version of the original.
2. A MeshCoord (or similar Coord) is returned whose mesh is a "view" onto the original Mesh.

This second alternative, implemented above as the MeshIndexSet class, has some precedence in the UGRID concet of a "location index set". It would be more sophisticated and difficult to implement, but could be useful for types of operations which require splitting up and recombining data from a mesh.

It should be noted that a MeshCoord superficially appears like an AuxCoord (indeed, this appearance is why the existing behaviour "falls out" as a natural consequence). Therefore, changing the behaviour to return MeshCoords yields a result which looks superficially similar to the existing behaviour, and only adds extra information. This means there is a good case to be made that changing this behaviour would not be a breaking change, especially since returning a MeshCoord as the result of a slice of a MeshCoord already seems like the more natural result. There is a similar case to make that the MeshIndexSet only adds information, however since this does not seem like the more natural result, I would be hesitant about the idea of returning this as the result of a slice of a MeshCoord and would consider this more likely to be a breaking change. There is still a good case that this could be the result of some other method of subsetting a MeshCoord.

In the meantime, it is worth highlighting that the existing behaviour of returning an AuxCoord may be liable to change if we are unable to put in a change before taking mesh code out of experimental. A warning when slicing a MeshCoord may suffice.

[trexfeathers]

The below code demonstrates the currently typical way of recreating a mesh after subsetting (#4751 refers to this as 'remeshing').

If we make the suggestions here work then the below code could create some confusing situations - no MeshCoord will have been replaced with an AuxCoord. But it will be easy to avoid that happening if we just add a clause into Mesh.from_coords() that knows to perform a 'no-op' if the coordinates passed in are already MeshCoords - just return the existing Mesh.

If we made that work I would be comfortable implementing changes even after mesh support becomes non-experimental.

https://github.com/SciTools/iris/blob/409f92cf7e77c8c3f7173df10d22f4511b301ed7/lib/iris/experimental/geovista.py#L324-L333

[trexfeathers]

Closing now the intent is captured in #6120.