[RFC] Remove access token or expose MapLibre well known tile providers?

[m0nac0]

Note: I have changed the title of this issue to start a discussion on how to proceed regarding access tokens and well-known tile providers, see below: #21 (comment)

---

MapLibre Android and iOS libraries now have out of the box support for some well-known tile providers (Maptiler, Mapbox, MapLibre). We should allow users of this library to use these.

These well-known providers also have a flag whether they require an access token.
If a well-known provider with required access token is used, but no access token is passed, we should warn.
Otherwise we shouldn't warn about "missing" access tokens. (see #20)

[m0nac0]

Also see maplibre/maplibre-native#90

[m0nac0]

Hm, I couldn't find anything similar on maplibre-gl-js, they actually seem to have removed support for access tokens entirely. If you want to use a provider with access tokens, you have to provide a tile source url with the token included, like https://tiles.example.com/x/y/z?access_token=1234

So after all that might be the more viable approach for this plugin, otherwise we'd have to keep our own list of well-known tile providers with all the respective styles and API urls...

[m0nac0]

Disclaimer: I'm not a lawyer and this is not legal advice:

The Mapbox Terms of Service (https://www.mapbox.com/legal/tos) link to the "Service Terms" which as of right now state under 7.1:

"...You must use the Mobile SDKs as your exclusive means of
accessing the Services in mobile applications..."

Since this plugin does not use Mapbox's Mobile SDKs, it seems to me that using Mapbox maps with this plugin probably wouldn't be allowed (at least for Android and iOS) anyways. Thus further reducing the potential value of having well-known tile providers in this plugin...

[m0nac0]

In #25, I propose removing the access token functionality altogether. This is the approach selected by maplibre-gl-js: If someone wants to use a tile provider that requires an api key, they can simply provide a tile source url with that key included. But they don't want to maintain special functionality for api keys in their open-source library. I think that approach is a good idea, since it's still very easy to specify an API key for anyone wanting to do so, but it's less work for maintaining the library.

The alternative, as outlined above, would be the approach of the maplibre-gl-native libraries:
allow usage of the library without api key (already supported by us), but optionally allow selecting from a list of well known tile providers. If one of these tile providers is selected, you can specify an API key and load one of their styles. This would mean, however, that we would need to maintain a list of these providers, with their different style URLs, in this plugin.

I'm in favor of the first approach (as propoesd in #25): it makes this plugin less complex and easier to maintain. And it's still easy for anyone to use styles with api keys. But this plugin stays provider-agnostic.

I'd be glad to hear some opinions on this, though.

[m0nac0]

#25 is merged.