[FEATURE]: Allow fitbounds to use only a subset of traces
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- javascript
- Domain
- data-visualization
Research direction
Start by tracing how scattergeo handles layout.geo.fitbounds and gathers locations, then read the linked discussion in issue #8046. Define how a trace-selection option should work while keeping unselected routes visible, and verify the selected-route extent, including antimeridian-crossing routes, without changing the broader view.
Written by the indexing model from the issue text.
Description
Summary
I would like to request a way to control which traces participate in the fitbounds calculation.
The current behavior is correct in the sense that fitbounds considers all relevant traces in the graph. However, for interactive maps with multiple routes, it would be useful to fit the view to a selected trace (or subset of traces) while keeping the other traces visible.
Related issue
This feature request follows from the discussion in the closed issue:
More specifically, this follows from camdecoster's comment on #8046.
Use case
I am building an interactive flight-route map using scattergeo.
The map contains many flight routes. When the user selects one route, I would like to:
- Keep all routes visible.
- Fit/zoom the map to the selected route only.
- Keep the other routes visible, but exclude them from the calculation used to determine the fitted view.
This is particularly important for routes crossing the antimeridian.
For example, a route from Vancouver (YVR) to Seoul (ICN) crosses the antimeridian. If this is the only trace in the graph, fitbounds: 'locations' correctly fits the route and rotates the map to the Pacific.
However, when all the other routes are present, fitbounds considers their locations as well, resulting in a much wider/global view.
Current workaround
I tried temporarily removing the other routes, fitting the map to the selected route, and then adding the other routes back.
The first two steps work correctly:
- Remove/disable the other routes.
- Fit the view to the selected route.
However, as soon as the other routes are added back, fitbounds recalculates using all traces and the view immediately returns to the wider extent.
I also tried making the other routes transparent, but opacity does not exclude their locations from the fitbounds calculation.
I therefore currently have to choose between fitting the map correctly to the selected route and keeping all routes in the graph.
Proposed feature
It would be useful to have a way to specify which traces should participate in the fitbounds calculation.
For example, conceptually something like:
layout: {
geo: {
fitbounds: 'locations',
fitbounds_traces: [3, 7]
}
}
- Dominant language
- JavaScript
- Stars
- 18.3k
- Forks
- 2k
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 21
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from plotly/plotly.js
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
chore P3 plotly-internal size: 3 task
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
chore P1 plotly-internal size: 1 task
Difficulty 1/5 Under an hour Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
chore P3 plotly-internal size: 1 task
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
plotly/plotly.js#7648 · 3 comments ·
Maintainers usually reply within 1 day
All issues in plotly/plotly.js
Similar issues
-
status: waiting triage
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
freeCodeCamp/freeCodeCamp#70412 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Jason-Vaughan/TangleClaw#1884 ·
Maintainers usually reply within 1 day
-
bug good first issue web
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
microsoft/TypeScript#64453 ·
Maintainers usually reply within 1 day
-
self-driving
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day