Update imagerepo for mpl 1.5.1

[bjlittle]

This PR is associated with SciTools-incubator/test-images-scitools#5, which contains the required images to support mpl 1.5.1 for all iris image tests and iris documentation example tests.

In total 139 new images are proposed to be added in SciTools-incubator/test-images-scitools#5

This is the result of image changes for 125 iris image tests, and 22 documentation example tests. This is reflected in the 125 + 22 = 147 changes to imgagerepo.json in this PR.

Note that, only 139 new images are required to support this PR, as 8 images are duplicates.

• Investigate, verify 2 additional images (see commit 5a8298c)
• Merged New images for unpinned mpl. SciTools-incubator/test-images-scitools#5

[marqh]

position of points is the biggest concern so far

[marqh]

y

[marqh]

minor change in extent, known with mpl15, data location looks the same

[marqh]

y

[marqh]

this one looks a bit odd, is this an actual code change?

[bjlittle]

@marqh Naively I thought this was a simple code change, but it's slightly more than that.

I've narrowed it down to a difference in iris (apparently) between 1.7.2 and 1.8.0.

During that time the documentation example test framework appears to have changed ... I'll dig further, but this appears to be a very old image that we've banked ...

[pp-mo]

👍 to allow this change

I don't see that this is a relevant issue.
The presentation of this type of plot has changed, but the plot itself is good.

So we don't necessarily need to resolve this...
Even if this is a new default behaviour, and the earlier method is now available using a particular control option, I don't think we should attempt to specialise Iris for that : It's much preferable, wherever possible, to offer a thin wrapper to 'normal' matplotlib functionality.

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

this looks like a positional shift in points, this doesn't seem ideal to me

[marqh]

i would like to understand how matplotlib is doing something different with this positional data

[bjlittle]

This is related to the above comment with regards to the behaviour of matplotlib.pyplot.scatter >1.3.1

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[pp-mo]

investigated a couple of the problems raised

[pp-mo]

👍 to allow this change

I don't see that this is a relevant issue.
The presentation of this type of plot has changed, but the plot itself is good.

So we don't necessarily need to resolve this...
Even if this is a new default behaviour, and the earlier method is now available using a particular control option, I don't think we should attempt to specialise Iris for that : It's much preferable, wherever possible, to offer a thin wrapper to 'normal' matplotlib functionality.

[pp-mo]

👍 to allow this change

Note: in fact, this problem doesn't affect only the one subplot mentioned, but also the one at bottom-left.

The key problem is that the subplots don't all have the same size, i.e. their borders don't line up.
That might be reasonable if they were different types of plot, or even had wildly different X and Y axes, but these ones are all the same ...

By fiddling with what is plotted in each subplot, I established that it is the cube data that triggers the change, and nothing to do with the metadat (such as X and Y coords) :

• none of these cubes (slices) are masked
• all the cubes compare equal if they are given the same data array and 'realization' is removed
• If you make all the data arrays the same, the subplots do all line up neatly

So... there is nothing special about some subplots in terms of Iris' actions : it is in matplotlib where the behaviour somehow depends on the exact data content.
This seems like a (new) bug in matplotlib with subplot positioning : It seems clear to me what is expected from the use of 'subplot', and it just doesn't quite deliver.
I don't see any sensible means of fixing this, the subplot call should just handle it really.

Eventually this may need raising as a matplotlib issue, or possibly we can add a workaround in Iris.
I've made a new Iris issue to cover that : #2171

[marqh]

y

[marqh]

y

[marqh]

y

[pp-mo]

y

[marqh]

y

[marqh]

y

[pp-mo]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[pp-mo]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[pp-mo]

y

[marqh]

y

[marqh]

y

[marqh]

y

[pp-mo]

y

[marqh]

y

[marqh]

y

[marqh]

y

[marqh]

y

[pp-mo]

y

[marqh]

y (a bit of a wobble, but y ;)

[pp-mo]

y

[marqh]

y

[pp-mo]

y

[marqh]

there is a small shift in the lower part of this plot, I can't convince myself its a problem, but it's not as neat most of them

y

[pp-mo]

y

[pp-mo]

y

[marqh]

there is a small shift in the lower part of this plot, I can't convince myself its a problem, but it's not as neat most of them

y

[marqh]

ace works kids
@pp-mo @bjlittle

[bjlittle]

@marqh and @pp-mo thanks!

So proud to have bagged the noisiest PR in the history of iris ... github even gave me a pink unicorn to boot! 😃