review RMS tolerance failures in `dev`

[jGaboardi]

• review RMS tolerance failures in dev
• https://github.com/pysal/mapclassify/actions/runs/23641767522/job/68863947031#step:7:502

[jGaboardi]

Quick Diagnosis

All current failures in dev appear to be non-trivial. They are not simply minor differences in plot alignment leading to small RMS, but substantive behavior changes coming from matplotlib=v3.10.8 installed via pip when compared to matplotlib=v3.10.8 installed via conda-forge

These seems to be in 2 groups

• axes labels being present when they are not expected in test_value_by_alpha failures
• multi input colormap being overridden in test_legendgram failures

This deserves a deeper investigation.

[jGaboardi]

Deeper dive

VBA Choropleth

(not confirmed but) at least some of this actually seems to like it might be new behavior in geopandas plotting functionality from @martinfleis's work in geopandas/geopandas#3728? For example, comparing CF available geopandas vs. geopandas@main there are now x,y labels where previously there were none.:

%load_ext watermark
import geopandas
import libpysal
from mapclassify import vba_choropleth
%watermark -iv

# ......

gdf = geopandas.read_file(libpysal.examples.get_path("columbus.shp"))
x, y = "HOVAL", "CRIME"
vba_choropleth(x, y, gdf)

conda-forge - geopandas=v1.1.3

geopandas current @main

[jGaboardi]

axes labels

Maybe having to do with this line in geopandas calling _set_axis_labels()

@martinfleis – with the geopandas.plotting.plot_{series,dataframe}() functions is there now labelled axes with no logic to turn off?

Seems directly related to geopandas/geopandas#3748

[martinfleis]

That's right. It normally shows units when CRS is set. You can use matplotlib to change that. Do you think this would need a keyword on geopandas side? Id rather avoid that.

[jGaboardi]

this is a clear improvement, and it makes one a little bit more conscious of the CRS they're using.

While I agree completely with @m-richards sentiment from that PR, I also think there should be an option to turn that off – and I suspect there will be many issues being filed asking for that once this next version of geopandas is released.

How much more complicated would you say it is to have something like crs_label=True in there? Other than having yet another keyword, do you foresee that causing other undue side effects?

[martinfleis]

The main reason is additional noise in already very noise function signature. If you don't want axis labels, you can remove them via matplotlib.

ax = df.plot()
ax.set_xlabel("")
ax.set_ylabel("")

The fact that geopandas is currently showing axes coordinates without any label is a bit strange, especially since we normally know something about them.

But it is true that this was motivated by the default behaviour of Xarray, which does have a keyword to control that (add_labels).

[jGaboardi]

legendgram failures

• test_legendgram.py::TestLegendgram::test_legendgram_map
• test_legendgram.py::TestLegendgram::test_legendgram_most_recent_cmap

I am absolutely stumped as to what's causing these. I can confirm they are failing in dev locally on macOS when running through pytest, but I can't reproduce interactively. So maybe something with how the geopandas plotting update handles colormaps?

test_legendgram_map

• test itself
• for some reason it seems that the legendgram is resetting to using the turbo colormap??

test_legendgram_most_recent_cmap

• test itself
• no longer warns, and when pytest.warns is turned off also producing a turbo colormap like above (not desired)

[jGaboardi]

test_legendgram_map

• printing this _child_cmaps object, eg.

        _child_cmaps = [
            (cc.cmap, cc.cmap.name)
            for cc in _ax.properties()["children"]
            if isinstance(cc, Collection)
        ]
        print(f"\n\n\n{_child_cmaps=}\n\n\n")

give the following

latest (expected)

_child_cmaps=[(<matplotlib.colors.ListedColormap object at 0x15eb7cad0>, 'viridis')]

dev (trouble)

_child_cmaps=[
(<matplotlib.colors.LinearSegmentedColormap object at 0x123568a10>, 'jet'), 
(<matplotlib.colors.LinearSegmentedColormap object at 0x123568940>, 'jet'), 
(<matplotlib.colors.LinearSegmentedColormap object at 0x1235686d0>, 'jet'), 
(<matplotlib.colors.LinearSegmentedColormap object at 0x123568460>, 'jet'), 
(<matplotlib.colors.LinearSegmentedColormap object at 0x123393790>, 'jet'), 
(<matplotlib.colors.LinearSegmentedColormap object at 0x123392f70>, 'jet'), 
(<matplotlib.colors.LinearSegmentedColormap object at 0x123392dd0>, 'jet'), 
(<matplotlib.colors.LinearSegmentedColormap object at 0x1233931e0>, 'jet'), 
(<matplotlib.colors.LinearSegmentedColormap object at 0x123393040>, 'jet'), 
(<matplotlib.colors.LinearSegmentedColormap object at 0x123392ea0>, 'jet')
]

• seems the cmap is jet, not turbo -- but not expected nonetheless.

---

@martinfleis Do you know offhand if this is expected behavior from the plotting refactor or a regression?

[martinfleis]

I get this - this is a pretty hacky solution we have here that relied on the internal structure of geopandas collections. That has changed now. Why does it register as jet I am not sure. Will try to look into that.

[martinfleis]

The jet cmap used to be a default, until 2016 (matplotlib/matplotlib#875). Matplotlib image comparison is apparently forcing the "classic" style which results in jet. And because geopandas now plots this as a proper categorical variable, it iterates through categories, assigns a single colour per category and creates a collection out of that. It does not specify cmap there at any point. So matplotlib defaults to jet.