Is MapboxOverlay now the prefered/recommended way to layer a deckgl instance and a mapbox/maplibre instance?

[jessekrubin]

AFAIK what is now called "inverted control" (deck with sub-map) was previously the recommended way to use deck + mapbox/maplibre. Has that changed? Is using MapboxOverlay now the recommended way to layer the 2?

Just curious! Thanks!

[chrisgervang]

We've more-so tried to clarify that there are 3 supported ways to integrate with mapbox and maplibre, and any one of them might be more or less appropriate for your use case. MapboxOverlay has been in deck since 8.9, and so the main change we've made is we've chosen to deprecate MapboxLayer in v9 and more prominently document the MapboxOverlay option, since it supports any JS environment (whereas the "reverse control" option is only supported in react and scripting).

[Pessimistress]

There is no "recommendation" without understanding your use case. All three integration modes are equally supported but each has its advantages and limitations. Mapbox/Maplibre are external libraries that work in fundamentally different ways from deck.gl. There is not going to be one approach that gives you all the features from both worlds.

[jessekrubin]

@chrisgervang @Pessimistress thanks so much for your thoughts and time!

I have now used deckgl and maplibre using all three of the methods. I guess my question on what is the "recommended" deck/maplibre layout comes from changes I noticed in the docs.

... Mapbox/Maplibre are external libraries that work in fundamentally different ways from deck.gl. ...

I would be very interested to read about their differences and what many of the design decisions behind how deckgl was/is architected -- would be a good read!

PS: will plug a side-project of mine that yall might find handy; utiles (utils + tiles OR it could be "ultra-tiles" depending on how you are feeling) and its python-lib, py-utiles

[chrisgervang]

These docs list out a lot of the differences. Many of them boil down to how deck.gl is architected for general purpose visualization, not just geospatial, and is designed to be very extensible by the end user (e.g. users can define custom Views and Controllers) whereas basemap libraries generally don't support this level of customization.

So to be interoperable with the basemap, not all of deck.gl's feature are able to be supported. We document common limitations and workarounds, but I'm also not surprised when I go to do something I haven't tried before and find it behaves just a little differently.. just last week I ran into a limitation in setting clearColor I hadn't noticed before.