[CI Bot] environment lockfiles auto-update

[scitools-ci]

Lockfiles updated to the latest resolvable environment.

If the CI tasks fail, create a new branch based on this PR and add the required fixes to that branch.

[rcomer]

Looks like we might need #5098 for this one, as we just have more of Antarctica showing...

... though I'm not clear why or whether we should be seeing more of Antarctica: the latitude coordinate doesn't go below 80S 🤔

[trexfeathers]

... though I'm not clear why or whether we should be seeing more of Antarctica: the latitude coordinate doesn't go below 80S 🤔

Patch releases of Cartopy and PyProj seem like candidates for an unintended change. I'm not aware of any Minor/Major releases that might have deliberately changed behaviour.

Maybe Shapely? Maybe an interaction between Cartopy and Shapely? I know that was giving the Cartopy devs some grief.

[trexfeathers]

Have proved during local testing that Shapely causes the change in test_2d_coord_bounds_platecarree:

• v1.8.5 = pass
• v2.0.0 = fail

[trexfeathers]

The change in Shapely version has stumbled across a problem that already existed at different central_longitude settings: SciTools/cartopy#2121.

It is difficult to know how to address this. The behaviour already existed and the test was just getting lucky at avoiding it. Meanwhile the test has already set a precedent of using specific settings to avoid another known problem (see SciTools/cartopy#1421):

iris/lib/iris/tests/integration/plot/test_plot_2d_coords.py

Lines 39 to 43 in 34560a5

	def test_2d_coord_bounds_platecarree(self):
	# To avoid a problem with Cartopy smearing the data where the
	# longitude wraps, we set the central_longitude
	cube = simple_cube_w_2d_coords()[0, 0]
	ax = plt.axes(projection=ccrs.PlateCarree(central_longitude=180))

Possible ways forward:

• Pin Shapely until we/Cartopy can address the problem.
  • No guarantee of resource - could be a while
  • Pins are bad
• Accept this change in behaviour.
  • The test would then be knowingly asserting for an incorrect plot
• Pick a different central_longitude that behaves correctly.
  • Definitely feels like evasion, but the test was already doing that anyway
• Remove the test.
  • It's not really doing its job if we're willing to change it to hide problems
  • On the other hand it is still demonstrating other correct behaviours

[rcomer]

I propose option 5:

• Use ax.set_extent to fix the area that gets plotted.

The problems that this would hide are not Iris’ problems and, as you say, the test “is still demonstrating other correct behaviours”. The test presumably exists to check that iplt.pcolormesh works with 2d coords, and it still does that even if the latitude extent of the plot fluctuates by default.

Since you found that the problem exists with older Shapely but different longitudes, I don’t think it makes sense to pin.

[trexfeathers]

Use ax.set_extent to fix the area that gets plotted.

@rcomer I'd appreciate your experience with this method. I tried a few different arguments last week and they were not producing the desired result. (I saw some suggestion of using set_xlim() instead but I can't remember the context, maybe that was the correct thing for curvilinear coords).

[pp-mo]

@trexfeathers Use ax.set_extent to fix the area that gets plotted ... set_xlim

It's my understanding that set_xlim / set_ylim don't work for geoaxes, and you must use set_extent instead. Always been poorly explained IMHO, but it is the kind of thing which doesn't fit too well in the Cartopy doc style.

[rcomer]

Hmmm, set_extent uses the axes’ projection by default, so I would have expected something like

ax.set_extent((0, 360, -80, 90))

to Just Work. I must admit I didn’t try it though. Could use get_extent to find out what it’s currently set to.

[trexfeathers]

Replaced by #5132.