LinearColormap(...).to_step(n=1) raises a ZeroDivisionError.
In map/choropleth workflows, after filtering or classification, there may be only one bucket/class to display, and a one-step colormap seems semantically reasonable.
Currently, we get:
❯ uv run --with branca python
Python 3.12.3 (main, Mar 23 2026, 19:04:32) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import branca
>>> from branca.colormap import LinearColormap
>>> print(branca.__version__)
0.8.2
>>>
>>> cm = LinearColormap(["red", "blue"], vmin=0, vmax=1)
>>> cm.to_step(n=1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File ".../branca/colormap.py", line 450, in to_step
index[i] * (1.0 - i / (n - 1.0)) + index[i + 1] * i / (n - 1.0),
~~^~~~~~~~~~~
ZeroDivisionError: float division by zero
The API says n is the expected number of colors in the output StepColormap. When no index/data is supplied it constructs a regular grid from n; later, it computes colors using n - 1.0, which fails at n=1.
Possibilities:
- Could
to_step(n=1) to return a StepColormap with one color/bin?
- Or should
n <= 1 be explicitly rejected with a clear ValueError?
- Or a mention in the docs stating that callers need to special-case single-class data?
LinearColormap(...).to_step(n=1)raises aZeroDivisionError.In map/choropleth workflows, after filtering or classification, there may be only one bucket/class to display, and a one-step colormap seems semantically reasonable.
Currently, we get:
The API says
nis the expected number of colors in the outputStepColormap. When no index/data is supplied it constructs a regular grid fromn; later, it computes colors usingn - 1.0, which fails atn=1.Possibilities:
to_step(n=1)to return aStepColormapwith one color/bin?n <= 1be explicitly rejected with a clearValueError?