Update test figures for Matplotlib 3.11

[QuLogic]

Rationale

As we all know, Matplotlib changed text rendering, as well as some image resampling code, so tests are all failing when running against the latest version.

I went for replacing the images and adding a tolerance for older versions. This does result in quite high tolerances in some cases, so it is possible we may wish to ship two images for some time instead.

Implications

Compatibility with latest release of Matplotlib.

I also compressed the results with oxipng -o max, which saved:

Files processed: 57/57
Input size: 4.45 MiB (4663311 bytes)
Output size: 2.02 MiB (2121057 bytes)
Total saved: 2.42 MiB (54.52%)

Fixes #2666

[QuLogic]

I've pushed a followup that changes tests that were already affected to use the mpl20 style. This is more modern and also minimizes the RMS tolerance we need in most cases. Probably these two commits can be squashed, but I kept them separate if you wish to review them by themselves.

[QuLogic]

Note in test_images, I went with changing the axes() call to add_axes with this rect:
https://github.com/SciTools/cartopy/pull/2685/changes#diff-ef0d6ab6699444c9c1bdbb5f5003c73a10781b3d70cec64f3009344a4d3a647dR129

I don't know if one way looks better than the other.

[QuLogic]

This prevents the y-axis from changing to a smallish number with a 1e6 multiplier.

[rcomer]

Thanks for doing this @QuLogic.

I think we can get rid of the largest of these tolerances by using your text_placeholders fixture (see my comments on the images). I'm not sure about the others: I never got the hang of what counts as too high for a tolerance.

[QuLogic]

Ah, it looks like the placeholders didn't handle rotation, so the boxes stick together a little differently on macOS. I'll try and see if I can get the placeholders to rotate as well.

[rcomer]

Will we always need to vendor the fixture or will we be able to import it from Matplotlib when we require a high enough version?

[QuLogic]

After a bit of CI debugging, I've found that on Ubuntu (x86_64) vs macOS (arm64), there are some small differences in the map boundary and subsequent gridline calculations. The map boundary difference is only somewhere below the 12th decimal place though, so that would seem not very relevant. What does differ more significantly is the calculated MultiLineString of the intersection of the latitude line with the map boundary.

On Ubuntu (x86_64), the 20°S, 0, and 40°N lines are split into 4 segments, whereas 20°N, 60°N, and 80°N are only 2 segments. On the hand, with macOS (arm64), the 60°N and 80°N lines are also split into 4. This occurs roughly at the ends +/-180° longitude, which on the LCC projection for the test is at about 60° from the top-left edge. You can see a comparison here:

It may be a bit difficult to see, but there are a few extra colours along that split for the two innermost latitudes. For MultiLineString, the code then picks up to the eighth-last (not entirely sure why that limit; it should maybe be a distance long the path?) element as a possible position (see the last for loop below). When we have 4 parts, it picks a position in one of the small ones, and some slightly different points in the longer one than it would if there were only 2 parts. This causes the labels to seem to overlap, and get turned off.

cartopy/lib/cartopy/mpl/gridliner.py

Lines 813 to 839 in c1b512a

	elif isinstance(intersection, (sgeom.LineString,
	sgeom.MultiLineString)):
	if isinstance(intersection, sgeom.LineString):
	intersection = [intersection]
	elif len(intersection.geoms) > 4:
	# If lines are parallel, there will be many intersections
	# merge them to get only one for the calculations below
	merged_line = shapely.line_merge(intersection)
	if isinstance(merged_line, sgeom.MultiLineString):
	# our merge still produced a multilinestring, so
	# manually concatenate the original coordinates
	xy = np.concatenate(
	[inter.coords for inter in intersection.geoms], axis=0)
	merged_line = shapely.LineString(xy)
	intersection = [merged_line]
	else:
	intersection = intersection.geoms
	tails = []
	heads = []
	for inter in intersection:
	if len(inter.coords) < 2:
	continue
	n2 = min(len(inter.coords), 8)
	tails.append(inter.coords[:n2:n2 - 1])
	heads.append(inter.coords[-1:-n2 - 1:-n2 + 1])
	if not tails:
	continue

Now, it turns out that when we get 4 parts, each smaller part is just two elements long and an end is coincident with an end of a longer part. I'm uncertain why we end up with these extra parts (as at least the transformed latitude line is the same on both platforms, and the split is nowhere near the map boundary), but if we merge them together, then we can get consistent potential-label-positions on all platforms and they end up all being visible in the same way. As you can see in the above code, we already merge the lines if there are more than 4 parts.

I do not have a strong idea of whether we should always have one LineString, so I have only applied the merge everywhere, and not the coalescence into a single one. The only loss is to Robinson where the top 180 labels have gone missing.

[QuLogic]

Will we always need to vendor the fixture or will we be able to import it from Matplotlib when we require a high enough version?

I didn't end up applying any rotation changes, so yes, we can import it when we require a high enough version.

[QuLogic]

The only loss is to Robinson where the top 180 labels have gone missing.

Sigh, and now macOS produces a different result for that one... Let me see what the calculations are like.

[QuLogic]

So I guess I see this Robinson case is the reason why we have that merging code for MultiLineString. The 180 lines are nearly coincident with the boundary and produce ~90-part MultiLineString of mostly two-point LineStrings. Unfortunately, the line_merge appears to sort them in a different order, which is in line with the "mild" canonical form that Shapely produces, but causes us to pick slightly different spots to attempt to label. I have tried calling normalize on the result before the manual concatenation, but it's still inconsistent. I'm beginning to wonder if there's a Shapely or GEOS bug across platforms now.

[QuLogic]

OK, I've had to isolate the changes in the last commit, so that if after line merging we still have to combine all the sub-geometries manually, then do that on the pre-line-merged intersection. This avoids the platform-specific re-ordering that Shapely/GEOS seems to be doing. If I can make a reproducer, I will report this to whichever upstream, but in the meantime, this will allow us to get tests working.

[rcomer]

Thanks for the detailed explanations @QuLogic. These changes all makes sense to me. I think we just need to decide what to do with the packaging import and then this is good to go.

[rcomer]

Please handle the merge however you would like.