Deck.gl Polygon legend labels share endpoints (cosmetic / ambiguous range labels)

[alex-poor]

Bug description

The deck.gl Polygon chart legend renders bucket labels with shared endpoints, so consecutive bins appear to overlap. With default settings (no manual break points), the legend shows e.g.:

1 - 81
81 - 212
212 - 369

Every interior breakpoint (81, 212, …) appears in two adjacent labels — once as an upper bound, once as a lower bound — which reads as overlapping ranges and is confusing.

This is a cosmetic / UX-clarity issue, not a correctness bug. The underlying binning and coloring are correct: colors are assigned with d3's scaleThreshold, which treats each breakpoint as a half-open cut point, so a value of exactly 81 lands in exactly one bucket (81–212). No polygon is double-counted or mis-colored. Only the legend label text is ambiguous.

Root cause

In superset-frontend/plugins/preset-chart-deckgl/src/utils.ts, getBuckets() builds each label by pairing adjacent breakpoints:

const range = `${breakPoints[i]} - ${breakPoints[i + 1]}`;

This always reuses each interior breakpoint in two labels. The color scale (getBreakPointColorScaler, same file) uses scaleThreshold, which is half-open and unambiguous — so the labels misrepresent the (correct) bucketing logic.

Scope

• Affects the deck.gl Polygon layer only — it is the only chart in the frontend that renders a discrete numeric-range legend (scaleThreshold appears nowhere else in superset-frontend).
• Country Map / World Map avoid this by using a continuous linear color scale with no discrete-range legend.
• ECharts charts use categorical legends (names, not ranges), so they are unaffected.
• Independent of the Number of buckets vs Bucket break points controls — setting explicit break points changes where the bins are, but labels still share endpoints.

Expected behavior

Legend bins should read as a clean, non-overlapping partition. There is no existing internal convention to match (Polygon is the only discrete-range legend), so candidate formats:

1. Edge-operator notation (common GIS/choropleth convention — ArcGIS, Datawrapper): < 81, 81 – 212, 212 – 369, > 369
2. Interval notation: [1, 81), [81, 212), [212, 369]
3. Render the boundary number once between touching swatches (gradient-bar style) rather than as isolated a - b rows.

Note: simply incrementing the lower bound (82 - 212) is not correct in general — breakpoints and metric values can be fractional, so a value like 81.5 would fall into a labeling gap.

How to reproduce

1. Create a deck.gl Polygon chart with a numeric metric.
2. Leave Bucket break points empty (use default Number of buckets).
3. Observe the legend — adjacent bins share endpoints (1 - 81, 81 - 212, …).

Superset version

master / latest (also observed on 5.0+).

Related (different) issues

• The legend limits are incorrectly calculated in deck.gl polygon #34747 — legend limits miscalculated (rounding the max bound); a separate, already-fixed bug.
• Add extra bucket when max outside range #7264, fix(deck.gl): restore legend display for Polygon charts with linear palette and fixed color schemes #35142 — other deck.gl legend fixes; none address label formatting.

No existing open issue/PR covers the shared-endpoint label formatting.

[sadpandajoe]

@dosubot help debug this

[dosubot]

Here's the full debug breakdown of the shared-endpoint label issue:

The problematic code is in getBuckets() at superset-frontend/plugins/preset-chart-deckgl/src/utils.ts [1]:

breakPoints.slice(1).forEach((_, i) => {
  const range = `${breakPoints[i]} - ${breakPoints[i + 1]}`;
  ...
});

This pairs adjacent breakpoints directly, so for breakpoints [1, 81, 212, 369] you get "1 - 81", "81 - 212", "212 - 369" — each interior value appears in two labels.

The color scale uses D3's scaleThreshold [2], which creates left-inclusive / right-exclusive intervals:

• [1, 81) → color 0
• [81, 212) → color 1
• [212, 369] → color 2

So a value of exactly 81 lands in bucket 2, not bucket 1. The bucketing is correct; only the labels are ambiguous.

Breakpoint generation (getBreakPoints, [3]) computes evenly spaced values using (startValue + i * delta).toFixed(precision), where precision is derived from Math.ceil(Math.log10(1 / delta)). These can be fractional strings, which is why a naive "lower + 1" fix doesn't generalize.

Legend rendering — the formatCategoryLabel function [4] splits each range on " - " and formats each number, then the Legend component renders them as color-swatch rows [5].

A minimal fix would be localized to getBuckets(). For example, using the edge-operator notation proposed in the issue:

breakPoints.slice(1).forEach((_, i) => {
  let range: string;
  if (i === 0) {
    range = `< ${breakPoints[i + 1]}`;
  } else if (i === breakPoints.length - 2) {
    range = `≥ ${breakPoints[i]}`;
  } else {
    range = `${breakPoints[i]} - ${breakPoints[i + 1]}`;
  }
  ...
});

However, this would also require updating formatCategoryLabel in the Legend component since it currently splits on " - " to format the numbers. The interval notation ([1, 81)) would be more semantically precise and wouldn't require changes to the delimiter-based formatting — you'd just need to ensure the brackets don't get stripped.

The relevant files for a fix are:

1. superset-frontend/plugins/preset-chart-deckgl/src/utils.ts — label generation [6]
2. superset-frontend/plugins/preset-chart-deckgl/src/CategoricalDeckGLContainer.tsx — legend rendering [7]
3. superset-frontend/plugins/preset-chart-deckgl/src/layers/Polygon/Polygon.tsx — where getBuckets is called [8]

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.