GitHub user eschutho created a discussion: [Feature] Deck.gl Path: Support
metric-based color scales (Fixed / Categorical / Breakpoints)
[Feature] Deck.gl Path: Support metric-based color scales (Fixed / Categorical
/ Breakpoints)
Summary
Enhance the Deck.gl Path visualization to support metric-based color scaling
options, matching behavior available in the Deck.gl Scatterplot chart.
Specifically, Path should support three color modes:
1. Fixed
2. Categorical
3. Breakpoints (threshold-based)
Currently, Path supports only a fixed color. This limits expressiveness for
metric-driven visualizations.
⸻
Problem
The Path visualization allows users to render geographic paths (e.g., routes,
flows, trajectories), but the line color is static.
Users need the ability to:
• Color paths dynamically based on a metric value.
• Define categorical color palettes.
• Define numeric breakpoints (e.g., thresholds) with associated
colors.
Scatterplot already supports:
• Fixed color
• Categorical color mapping
• Breakpoints / threshold mapping
Path should provide the same capabilities for consistency and usability.
⸻
Proposed Solution
Extend Deck.gl Path visualization to support metric-driven color configuration,
aligned with Scatterplot behavior.
1️⃣ Add Color Mode Selector
Add a new control:
Color Mode:
- Fixed
- Categorical
- Breakpoints
Default remains Fixed to preserve backward compatibility.
⸻
2️⃣ Behavior Per Mode
Fixed (existing behavior)
• Single color picker.
• Applies same color to all paths.
⸻
Categorical
• Select metric (or group-by column).
• Apply categorical palette.
• Color varies based on metric result.
Should reuse:
• Existing categorical palette infrastructure.
• Legend rendering behavior consistent with Scatterplot.
⸻
Breakpoints (Threshold-based)
Allow users to:
• Select metric.
• Define breakpoints (e.g., 0–100, 100–400, 400+).
• Assign a color to each range.
UI requirements:
• Add dynamic rows for:
• Lower bound
• Upper bound
• Color picker
• Support adding/removing breakpoint rows.
Behavior:
• Color for each path is determined by the metric value falling
within the defined range.
• Boundaries should be clearly defined (inclusive/exclusive
consistent with Scatterplot).
⸻
3️⃣ Control Panel Changes
In plugins/plugin-chart-deckgl/src/Path/controlPanel.ts:
• Add color mode selector control.
• Add conditional controls for:
• Metric selection (if not already present).
• Categorical palette selection.
• Breakpoint configuration.
Controls should match implementation patterns from:
• Scatter/controlPanel.ts
Avoid duplicating logic; reuse shared control configs where possible.
⸻
4️⃣ Rendering Logic
In the Path layer implementation:
• Update accessor logic for getColor to:
• Evaluate metric value per row
• Map to:
• Fixed color
• Categorical scale
• Breakpoint scale
Implementation should follow patterns used in:
• Deck.gl Scatterplot layer
• Other Deck.gl layers with metric-based coloring
Color computation must occur in the data-to-layer mapping step.
⸻
5️⃣ Legend Behavior
• Categorical mode → show categorical legend.
• Breakpoints mode → show range legend.
• Fixed mode → no legend change.
Legend styling and behavior must match other Deck.gl visualizations.
⸻
6️⃣ Backward Compatibility
• Existing charts must render identically.
• Default color mode = Fixed.
• No breaking changes to saved form_data.
⸻
Testing Requirements
Unit Tests
Add tests for:
• Control panel config (new controls appear conditionally).
• Color scale logic:
• Fixed mode returns constant color.
• Categorical mode maps distinct values correctly.
• Breakpoints mode maps values to correct color ranges.
Reuse testing patterns from Scatterplot tests.
⸻
Integration Tests (if applicable)
• Ensure saved charts with default (fixed) color still render.
• Ensure new modes correctly apply color scaling.
⸻
Acceptance Criteria
• Path visualization supports:
• Fixed color
• Categorical palette
• Breakpoints
• Behavior matches Scatterplot implementation.
• Legend renders correctly.
• No regression in existing Path charts.
• Tests added and passing.
⸻
Notes for Implementation
• Prefer reusing existing color scale utilities instead of
reimplementing mapping logic.
• Ensure color logic is applied at the accessor level (getColor)
and not precomputed in SQL.
• Keep parity with other Deck.gl chart types.
• Avoid introducing chart-type-specific scale implementations if
shared utilities exist.
⸻
Labels (Suggested)
• feature
• deck.gl
• visualization
• frontend
• enhancement
⸻
GitHub link: https://github.com/apache/superset/discussions/38134
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
