[Bug] fitBounds not working as expected in my app and in the react-map-gl example

[DaveSeidman]

Description

First off, thank you for this wonderful library, it's powerful, performant, and easy to use. I'm currently experiencing some inconsistent behavior with the fitBounds method. I've observed the issue in my own code as well as the react-map-gl hosted example here: https://visgl.github.io/react-map-gl/examples/zoom-to-bounds

If you watch the attached screen recording you'll notice the final position and zoom is different depending on the current view and where in the interactiveLayer the click happened. It always works correctly if you zoom the map out sufficiently before clicking a region.

Screen.Recording.2024-10-21.at.7.28.30.AM.mp4

I've worked around the issue by using the polygon from the original geoJson I'm loading to set the bounding box but it would be nice not to have to do that additional lookup as I believe the correct data should exist inside the onMapClick event's data.

Expected Behavior

I'd expect the MapLayerMouseEvent.features to be the same every time when clicking into the same interactive layer.

Steps to Reproduce

Pull this repo, and run the "zoom-to-bounds" example, add a line inside the onMapClick event to console the event.features[0].geometry.coordinates[0].flat() and observe different values returned when clicking at different points within the same feature.

Environment

• Framework version: [email protected]
• Map library: [email protected]
• Browser: Chrome 129.0.6668.101
• OS: Mac os Sanoma 14.4.1

Logs

No response

[chrisgervang]

Hey there! Thanks for reporting this issue. onClick is directly mapped to maplibre's click event. I think the issue you're experiencing would need to be resolved in Maplibre itself. I recommend reporting it to them directly. Also, this issue might be related to what you're experiencing: maplibre/maplibre-gl-js#3921

[DaveSeidman]

Hey @chrisgervang, that issue you linked is likely the culprit, thanks for sharing!

What it seems to suggest is that clicking on the map when you're very zoomed in will only return the features that are in view, so if some of a region is off-screen when clicked, we only get the features that are in-view (or at least close enough to have been grabbed from the tile server):

Screen.Recording.2024-12-14.at.7.46.45.AM.mp4

What's unfortunate is that even after visiting the region in question (meaning all it's features have been downloaded) it clips the ones outside the viewport when attempting to return to that region.

I know you wrote maplibre but i think you meant mapbox's click event? I believe the demo I referenced uses mapbox and the pointer event you linked to as well. I assume they're mapped similarly in both libraries so the behavior seems to be the same in both.

I understand that react-map-gl is working correctly with the data it receives, but I think the demo's functionality may mislead or confuse others that aren't aware of that underlying issue. I wonder if there is a way in either of those libraries to "pre-cache" all the features with the understanding it might force users to download more tile data than they need?

Thanks again.

[chrisgervang]

Ah, I see how that can be confusing. The event mapping code is the same for both libraries. This wrapper was created before the maplibre project started so a lot of code is still named after mapbox.

I'm not sure if there is a cacheing feature like that, but worth asking.

We're open to a PRs - you could help clarify us clarify this in the docs/add comments to the examples. From our POV, we're not adding features to the underlying libraries within react-map-gl. And since this is working as they've designed it.. we consider this behavior a feature, not a bug.

But again, at least with MapLibre, it's an open project that accepts improvements. So if there is some configuration we can demonstrate using something they ship, we'd love use it in the example.

Or, if the problem can be solved with flat files rather than a tile server, you could consider using deck.gl's react+maplibre integration and a layer like the GeoJsonLayer. I can understand it may not seem worth it to bring in another library, but I figure it doesn't hurt to share an option that doesn't rely on the same to feature picking limitation.

There is also an MVTLayer in deck.gl, but it is not a replacement for maplibre and may experience the same issue described here.