GitHub user eschutho created a discussion: Deck.gl Path: Line Width by Metric
Deck.gl Path: Line Width by Metric
Overview
This feature enhances the Deck.gl Path visualization to support variable line
thickness driven by data, enabling richer visual encoding of weighted paths and
relationships.
Users will be able to control path width dynamically using a numeric metric,
similar to how Scatterplot supports size-by-metric encoding.
⸻
Problem Statement
Currently, the Deck.gl Path chart supports only a fixed line width for all
rendered paths.
This limits the ability to visually encode:
• Traffic volume
• Transaction weight
• Distance magnitude
• Flow intensity
• Relationship strength
• Any weighted network data
Users need the ability to vary line thickness based on a numeric value to
improve interpretability and highlight patterns.
⸻
Goals
• Enable metric-driven line width in Path charts.
• Match behavior and UX patterns used in Deck.gl Scatterplot.
• Support both screen-relative and geographic scaling units.
• Preserve backward compatibility with existing Path charts.
• Provide sensible scaling controls to ensure readability.
⸻
Key Capabilities
1️⃣ Metric-Driven Line Width
Users will be able to select a numeric metric (measure) to control the rendered
width of each path.
Behavior:
• Higher metric values → thicker lines
• Lower metric values → thinner lines
• Scaling applied proportionally across the dataset
If no metric is selected, the chart continues using fixed width.
⸻
2️⃣ Unit Selection
Users can choose how line width is interpreted:
• Pixels
• Screen-relative emphasis
• Line width remains consistent visually across zoom levels
• Meters
• Geographically scaled rendering
• Line width scales relative to map zoom and geography
Default behavior should match current implementation (typically pixels).
⸻
3️⃣ Chart Configuration Controls
Add the following controls to Path/controlPanel.ts:
A. Line Width Mode
Line Width:
- Fixed
- By Metric
(Default: Fixed)
B. Line Width Metric (shown when “By Metric” selected)
• Numeric metric selector
• Same control type and behavior as Scatterplot size metric
C. Unit Selector
Units:
- Pixels
- Meters
Visible in both Fixed and Metric modes.
D. Scaling Adjustment
Optional numeric input:
Width Scale Multiplier
Allows users to tune the visual output when metric values vary widely.
⸻
Scaling and Normalization
When “By Metric” is selected:
1. Determine min and max metric values across the dataset.
2. Normalize values into a proportional range.
3. Apply scaling multiplier.
4. Enforce minimum and maximum width bounds.
Proposed defaults:
• Min width: 1px (or 1 meter)
• Max width: 20px (or reasonable meter cap)
Bounds prevent:
• Extremely thin invisible paths
• Excessively thick, overlapping paths
Scaling implementation should mirror Scatterplot’s radius scaling logic where
possible.
⸻
Dimension vs Metric Support
Recommendation: Support numeric metrics only (V1)
Line width is a continuous quantitative encoding. It should:
• Accept only numeric metrics.
• Not support categorical dimensions.
If users need categorical differentiation, they should use:
• Color encoding (already supported or planned)
• Separate layers
Supporting dimensions would introduce ambiguity and visual confusion.
Future enhancement could support aggregated dimension-based counts, but that
should remain metric-driven.
⸻
Rendering Implementation
Rendering logic should:
• Modify the Deck.gl getWidth accessor.
• Evaluate the selected metric value per row.
• Apply scaling and bounds.
• Return computed width in selected unit system.
Implementation must:
• Reuse shared scaling utilities where possible.
• Follow Scatterplot’s size-by-metric implementation patterns.
• Avoid duplicating scale logic if reusable helpers exist.
Width computation must occur client-side in the layer accessor.
⸻
Backward Compatibility
• Existing charts remain unchanged.
• Default Line Width Mode = Fixed.
• No migration required for existing form_data.
⸻
Legend Behavior
V1:
• No legend required for line width scaling.
Future enhancement:
• Optional numeric scale legend for width encoding.
⸻
Testing Requirements
Unit Tests
Add tests for:
• Control visibility (conditional rendering).
• Width scaling logic:
• Fixed mode returns constant value.
• Metric mode scales proportionally.
• Bounds enforced.
• Multiplier applied correctly.
• Unit switching (pixels vs meters).
Regression Tests
• Existing Path charts render unchanged.
• No console errors introduced.
⸻
Acceptance Criteria
• Path supports fixed and metric-based width.
• Width scaling behaves proportionally.
• Unit selection works correctly.
• Scaling multiplier functions.
• No regressions in existing charts.
• Tests added and passing.
⸻
GitHub link: https://github.com/apache/superset/discussions/38135
----
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]
