maps
maps copied to clipboard
Remove default map implementation
Summary
This removes Maplibre as the default map implementation for Android, causing the build process to fail if the parent project does not specify a value for RNMapboxMapsImpl
.
Description
A few months ago, Maplibre became more tightly integrated into this library, and part of that change involved setting it as the default implementation on Android. This means that any project that previously was not specifying a default was automatically switched from the Mapbox SDK to Maplibre's.
The reason this is potentially a big deal is that the cost of à la carte map tiles from Mapbox, which is Maplibre's default tileset, is approximately 40x the cost of tiles received through the official Mapbox SDK. It's hard to do a direct comparison because the units are different, but suffice to say that projects with a high number of users could potentially see an enormous pricing change.
I understand the value of having a sensible default, but for a change with potentially large consequences like this, I believe it makes sense to ask the user to make a one-time configuration choice.
@naftalibeder thanks much for bringing up the issue. I'm sorry if you were hit by this price issue. Is the price difference between consuming the mapbox via their -gl
and maplibre
sdk documented somewhere?! Is the the difference between consuming via v10
and gl
RNMapboxMapsImpl
also defaults to maplibre
on iOS as well. So if we want to change it we need to change it there was well. I thin the only difference is that on android setAccessToken
was also changed wellknownTileserer
while on iOS it has to be done manually.
As for the reason for maplibre
default, it was chosen as Mapbox
libs requires access token configurations even for download. So for getting started with default as maplbire
is simpler.
This means that any project that previously was not specifying a default was automatically switched from the Mapbox SDK to Maplibre's.
To clarify this was done together, with the project rename, branch rename, major version increase and it was documented (although that could be improved), and it was done on the #main
branch. So previous projects were only switched if they renamed the imports, and chose to consume for #main
branch etc. It was also announced before see - https://github.com/rnmapbox/maps/discussions/1680#discussioncomment-2299185
I understand it can be a huge issue for existing projects.
Is the price difference between consuming the mapbox via their -gl and maplibre sdk documented somewhere?!
It is documented on their pricing page, but not in a way that makes it possible for someone to easily estimate (users vs. tile requests). Personally I don't think Maplibre should default to requesting Mapbox tiles, if the whole point is that you can use any (free) tile set.
Is the the difference between consuming via v10 and gl
No - both of this library's Mapbox implementations use the cheaper SDK. Maplibre, since it can't use the SDK, makes individual tile requests.
RNMapboxMapsImpl also defaults to maplibre on iOS as well
I agree about changing that too, if that's your implication.
So for getting started with default as maplbire is simpler To clarify this was done together [...]
Again, I agree - I just think that the opt-in make sure that people are choosing intentionally. I don't think that the choice to change the default was a bad one, but I guess it made it easier for us to make a mistake. That's most of what I'm trying to do here - keep the setup effort low, but make it hard to accidentally switch over without realizing it.
Would you be open to that? I could make the iOS change if so.
On maplibre to use mapbox servers we now require explicit setWellKnownTileServer call, and I mention in docs there that pricing might be different. https://github.com/rnmapbox/maps/blob/main/docs/MapboxGL.md#setwellknowntileservertileserver