Round-trip netcdf data

[pp-mo]

We have been asked a few times why we can't reproduce netcdf input exactly.
This is intended as a quick summary of the issues, and maybe a starting-point for how we could / if we should improve on this.

So, in general, although the Iris data-model is explicitly based on netcdf-CF, we aren't able to exactly reproduce netcdf files as we originally read them.
Firstly, there are a few things that can be explicitly controlled on saving but are not actually represented in the data-model (e.g. : data compression options; data fill-values; unlimited dimensions).
Also, more significantly, there are aspects of data encoding that we simply ignore + don't store, and which may not even be easily accessed in a load callback (e.g. : dimension names, bounds-variable names) .

The point is that Iris when loading considers some data encoding details as 'incidental' and discards them.

Here is my list of some things which we don't handle in netcdf loading/saving :

file information aspects	controllable via netcdf.save	notes
dimensions : names	-
dimensions : "unlimited" status	Y
dimensions : ordering	-
file variables : ordering	-
variable attributes : ordering	-
data : compression	Y
data : fill-values	(Y)	See https://scitools-iris.readthedocs.io/en/v3.0.2/techpapers/missing_data_handling.html
file-global attributes	(Y)	mixed up with properties of data-variables. Partially controllable on save. See #3325
grid-mapping : details (**)	-	no corresponding Iris object - that is, a CoordSystem, but this is not a CfVariableMixin, so does not have varname/attributes/etc
bounds variables : details (**)	-	no corresponding Iris object (? dtype subject to CF rules : see section 7.1 here, independence of main variable is unclear?)
existence of optional CF attributes + defaults	-	e.g. ? : units, _FillValue, axis, positive ?

(**) "details" : such as var_name; dtype; additional non-CF attributes. See discussion "Ability to specify grid_mapping name"

Extra notes on the above :

• excluding aspects which are "bad CF", such as : links to non-existent coordinates ; bad units ; bad standard-names
  (though we do tolerate and even record some of those things)
  • likewise : redundant dim-coords listed in "data-variable::coordinates"

[trexfeathers]

@pp-mo you've previously mentioned an object that is associated with a Cube, which holds how it will be represented in NetCDF. Are you now thinking of an xarray Dataset for this purpose?