Iris: Remove experimental equalise_cubes

Created on 13 Nov 2019  路  6Comments  路  Source: SciTools/iris

Follow-up on #3527, and remove the iris.experimental.equalise_cubes module, akin to #3523.

Target this for the 3.1.0 release.

Good First Issue Minor

Most helpful comment

Thanks @larsbarring, much appreciated.

My head is in the space of considering how to make iris more lenient and customisable for users, particularly when performing such operations as this, as well as concatenation, merging, arithmetic and equality.

You should probably also be aware of https://github.com/SciTools/iris/issues/3325 which intends to address the issue of iris being opinionated about what attributes it cares about.

Anyways, I appreciated the unnecessary hoops that users are forced to jump through, so your use case here is valuable, thanks for taking the time to feedback 馃槂

All 6 comments

Closes #3342

Now, when this function becomes a 'regular member of iris', would it be possible to have it returning the attributes ( etc) that had to be removed to equalise the cubes?

Hey @larsbarring,

Good to hear from you. I'm assuming that this is because you want to reattach some of the metadata that was removed?

Yes, either reattaching as for example with tracking_id, or just to know what is not consistent when I expected it to be.
Lars

... and a follow-up thought:
The order in which the removed attributes should be returned is (of course) the same as in the cube list. No complication there I would think. But how can I know in which order the cubes were concatenated (or merged) so that I can combine the removed attributes in the right order and attach the result to the new cube?

A practical example would be a list of cubes having their own unique tracking-id. I could use equalise_cubes to first get all "offending" attributes, and from there extract the individual tracking_id:s (and possibly do something else with the other). I concatenate the cubes to carry out some processing and in the resulting cube I would like to record all the input tracking_id:s as a comma separated list in one attribute.

In this example I might get away without having the tracking_id:s sorted according to concatenation order. But if we take the attribute creation_date instead, having them in right order would help [a human] to spot if all input files were produced in one go, or if some files were replaced/updated at a later stage.

Admittedly, this should probably be a different issue, but it gives the context for my request above.

Thanks @larsbarring, much appreciated.

My head is in the space of considering how to make iris more lenient and customisable for users, particularly when performing such operations as this, as well as concatenation, merging, arithmetic and equality.

You should probably also be aware of https://github.com/SciTools/iris/issues/3325 which intends to address the issue of iris being opinionated about what attributes it cares about.

Anyways, I appreciated the unnecessary hoops that users are forced to jump through, so your use case here is valuable, thanks for taking the time to feedback 馃槂

Was this page helpful?
0 / 5 - 0 ratings