[FEATURE]: Allow fitbounds to use only a subset of traces

[jvolsicky]

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:

plotly/plotly.js#8046

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:

1. Keep all routes visible.
2. Fit/zoom the map to the selected route only.
3. 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:

1. Remove/disable the other routes.
2. 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]
    }
}

[camdecoster]

As I mentioned, this seems like a reasonable feature request. I'll add it to the backlog. If someone wants to work on it, I'd be open to that as long as they present their plan for a solution.

[jvolsicky]

I made a small prototype against Plotly 4.1.1 to test the proposed approach.

The prototype uses a trace-level flag to exclude individual visible traces from the fitbounds calculation while keeping them rendered.

The concept works: when a route is selected, only its traces participate in fitbounds, while all other routes remain visible. This also correctly handles routes crossing the antimeridian — for example YVR → ICN rotates the map to the Pacific as expected.

The remaining issue is the zoom level: the fitting/rotation is correct, but the resulting extent is currently wider than I would like. I am still experimenting with that part.

So this is definitely not intended as a finished implementation, but it seems to confirm that the proposed concept is technically viable.

For reference, the application marks the selected traces like this:

trace.meta = trace.meta || {};
trace.meta.fitbounds = isSelected;

The relevant change in the 4.1.1 fitbounds collection logic is essentially:

if (
    q.visible === true &&
    q._module.fitCoords &&
    (!q.meta || q.meta.fitbounds !== false)
) {
    F.push(q._module.fitCoords(...));
}

This means that a trace with:

meta: {
    fitbounds: false
}

is still rendered normally, but is ignored when Plotly calculates the geographic bounds.

In the prototype I set fitbounds: true for the two traces belonging to the selected flight (route + endpoint marker), and fitbounds: false for all other routes and the airport-code trace.

This is just a quick proof-of-concept modification to 4.1.1, not intended as a proposed final API or implementation. The main point was to verify whether excluding selected traces from the fitbounds calculation can solve the interactive use case described above.

[jvolsicky]

I have now extended the prototype and can confirm that the approach works as intended.

The prototype allows individual traces to participate in fitbounds while remaining fully rendered on the map.

For the flight-route use case:

• the selected flight is marked with meta.fitbounds = true
• all other flight traces are marked with meta.fitbounds = false
• the selected traces are used for the geographic fit calculation
• the other traces remain visible/rendered, but do not affect the calculated view
• this works correctly for both rotation and zoom
• routes crossing the antimeridian are handled correctly

For example, with a short flight such as PUS → CJU (416 km), Plotly automatically zooms tightly around the selected route even though all other flights remain visible.

For a long trans-Pacific flight such as YVR → ICN (9,161 km), the native fitting correctly produces the wider view required for the route and rotates the map appropriately.

Prototype implementation

The application marks the selected traces like this:

trace.meta = trace.meta || {};
trace.meta.fitbounds = isSelected;

The first change in the Plotly 4.1.1 fitbounds collection logic is very small.

Original:

q.visible === true &&
q._module.fitCoords &&
F.push(q._module.fitCoords(j, i))

Prototype:

q.visible === true &&
q._module.fitCoords &&
(!q.meta || q.meta.fitbounds !== false) &&
F.push(q._module.fitCoords(j, i))

This means that a trace with:

meta: {
    fitbounds: false
}

is still rendered normally, but is ignored when Plotly collects the geographic coordinates used for fitbounds.

However, I found that this alone is not sufficient for the zoom calculation.

There is another part of the existing fitbounds implementation which calculates the automatic axis range using concatExtremes(). That function uses u._traceIndices, so the other visible traces could still influence the resulting scale even after they had been excluded from the geographic coordinate collection.

I therefore made a second small change around the existing concatExtremes() call.

Original:

let P = fir(r, u);

Prototype:

let _ti = u._traceIndices;

u._traceIndices = _ti.filter(j => {
    let q = r._fullData[j];
    return q &&
           q.visible === true &&
           q._module &&
           q._module.fitCoords &&
           (!q.meta || q.meta.fitbounds !== false);
});

let P = fir(r, u);

u._traceIndices = _ti;

The original trace indices are restored immediately afterwards, so this only affects the fitbounds calculation. The other traces remain fully rendered.

No custom zoom calculation is used. In particular, the prototype does not apply an arbitrary multiplier to projection.scale. The resulting zoom is produced by the existing Plotly 4.1.1 native fitbounds calculation.

The actual patch is very small - only a few additional lines around the existing fitbounds logic.

Result

With this prototype:

1. Only the selected traces participate in fitbounds.
2. Other traces remain visible.
3. Native Plotly zoom is preserved.
4. Native geographic rotation is preserved.
5. Antimeridian-crossing routes work correctly.

I have tested this with both short and long routes, including:

• PUS → CJU - 416 km
• YVR → ICN - 9,161 km

The prototype is based on Plotly 4.1.1 and is still only a proof of concept. I am not suggesting this exact implementation as the final API. The main purpose of the experiment was to verify whether trace-level exclusion from fitbounds can support this use case without removing or hiding the other traces.

At this point, the prototype confirms that it can.

Let me know if you'd like to have a look at the plotly-4.1.1-fitbounds-prototype.js that I created with the help of AI.

Cheers! :)