Do not remove Mapbox code

[hyperknot]

I wanted to write an anti-feature request, that is, to please do not remove Mapbox code (as in #21).

Right now, mapbox-gl-js 1.x is an almost perfect library to be used both with Mapbox sources and with independent sources. Setting an API key is 100% optional, it works perfectly without it.

If you do supply the key, then it enables all the mapbox:// specific features.

For example, my project is MapHub (https://maphub.net/), where users can select from multiple basemaps. Some of them are from Mapbox, some of them are from independent sources, and mapbox-gl-js 1.13.x works perfectly as of today.

If you decide to break mapbox:// sources, then using this library wouldn't be a possibility for me, and for many other users who'd like to keep using multiple providers, including Mapbox.

A much better approach would be to leave mapbox:// as it is and introduce alternative urls, like maplibre:// which doesn't apply the API token (today I have to use transformRequest + regex as a hack). Also renaming accessToken -> mapboxAccessToken would be a good thing, but definitely not removing the whole code.

[anarchodin]

The warning in the file seems unlikely to be enforceable as stated. In particular, it cannot be true that modification of anything in that file is a violation of Mapbox ToS. That would imply that the APIs could only be accessed by Mapbox-authored SDKs.

That said, it would make sense to replace whatever's in that file and causes them to put that warning there ... if there even is anything other than FUD. (Edit: Oh, and of course also brace for changes to the terms of service that actually do ban use of code not supplied by Mapbox. When someone shows you who they are...)

[hyperknot]

The Mapbox requirements seems clear to me: do not modify the logic what would affect Mapbox billing. Since in 1.13.x it's simply one SKU token per map loading. As long as we keep the SKU code unmodified, we should be good.

[stevage]

I totally agree.

IMHO, any MapLibre-GL-JS v1.x should be backwardly compatible with Mapbox-GL-JS v1.13. Removing support for mapbox:// etc doesn't really make sense.

[anarchodin]

I went and looked at the specifics of the terms of service. Those refer to a distinct document, the service terms. A clause there says the following:

You may only use mapbox gl-js version 2.0 or higher (“Mapbox Web SDK”) under this Agreement.

There's an earlier clause about using the 'Mapping APIs', which makes this really strange. (If you can access the mapping APIs with any client, this can't be enforced.) In any case, that looks to me like a reason not to trust any argument based on what seems reasonable.

[AbelVM]

Looks like, as of today, the above, explicit, limitation to use a 3rd party software to access the APIs are now gone from the Mapbox services terms (dated 2021.09.10). We might want to come back to this issue.

BUT, there's some reference to a Qualified renderer

That can be found to be one of their SDKs:

So, it's a bit obfuscated whether you can or not use a 3rd party to access Mapbox APIs, and I'm myself quite lost with all this jargon. I have a pay-as-you-go account, the common one, paid by active users amount... but are those the same as map loads? I would say yes, but who actually knows... 😫

[hyperknot]

How do you get this service terms? The one I find is Mapbox Rev. 02/17/2020. BTW it explicitly says GL JS 1.0 or above is allowed, like you say.

[AbelVM]

https://www.mapbox.com/legal/service-terms

[hyperknot]

Yes, that's the one I'm looking at. It says 2020 but has the sections you've pasted.

[anarchodin]

Wait, no. It just needs you to look at it from the perspective of billing, rather than a technical perspective.

Keeping the current code would be a violation, because it would continue to use "map load" pricing. That can't be maintained.

[hyperknot]

And what about all their clients who want to use IE 11? As an enterprise company, I'm sure they have many of them. Since 2.x drops IE support, what are they going to do?

I think a more realistic scenario is they keep supporting 1.x clients for a very long time.

[anarchodin]

The current terms of service say they don't. It may be worth requesting clarity on that point.

[gitcatrat]

We should make sure that modules are set up in a way that all Mapbox specific code gets tree-shaken if it's not needed. If that's the case, I won't mind it one bit. This lib has loads of features but I doesn't mean that bundle size is not important.

[ForsakenHarmony]

And what about all their clients who want to use IE 11? As an enterprise company, I'm sure they have many of them. Since 2.x drops IE support, what are they going to do?

I think a more realistic scenario is they keep supporting 1.x clients for a very long time.

I mean honestly, IE should not really be supported, it's a security risk for any company using it either way

[hyperknot]

IE will be living with enterprise companies for a long time, it is still supported by Microsoft.

[cigone-openindoor]

Well, just do like all other tools that rely on IE: do not update.

[hyperknot]

do not update

That's exactly my point: there will be companies who use IE -> Mapbox needs to support 1.x for a while.

[anarchodin]

Are you assuming they've thought this through?

I wouldn't.

[ForsakenHarmony]

We should make sure that modules are set up in a way that all Mapbox specific code gets tree-shaken if it's not needed. If that's the case, I won't mind it one bit. This lib has loads of features but I doesn't mean that bundle size is not important.

Not possible if you want everything to work like it does now, there's no separate import that could include all mapbox code

[marcelnormann]

Its hard to tell if this issue is ever solved, so I convert it into an discussion.

[flemmens]

IMHO, mapbox:// or any other prefix should be removed and we should accept only standard z/x/y URLs, this will simplify the code and this is a more universal solution.

For those who want to use mapbox tiles, it is very easy to replace the source with the full mb url like this:

    "composite": {
      "type": "vector",
      "tiles": ["http://a.tiles.mapbox.com/v4/mapbox.mapbox-streets-v8/{z}/{x}/{y}.vector.pbf?access_token={token}"]
    }

This is what we done in a fork for our company, it allowed us to remove a lot of needlessly complex code and it works very well with both custom and mapbox tiles.

[hyperknot]

There is so much more in a style.json than X,Y,Z, good luck putting this information in a string:
https://tiles.stadiamaps.com/data/openmaptiles.json

[kylebarron]

There is so much more in a style.json than X,Y,Z, good luck putting this information in a string

That's not a style.json, that's a TileJSON document. It doesn't contain any styling information, just metadata to describe how to load the data. When you add a source in Maplibre GL, you can either provide a URL to a tilejson file or the tilejson parameters directly to addSource. So that's orthogonal to the question of removing the mapbox:// prefix.

[webberig]

I think most of the comments here should be addressed to Mapbox, not Maplibre. It comes down to the (poor) choices that mapbox made by adding client-side code for commercial purposes and the change in billing policy for using 2.x.

From a technical standpoint I think it should be the other way around: Maplibre should have no notion of access tokens or proprietary code for metrics and billing purposes, etc... Instead, Mapbox could ideally create a proprietary maplibre-plugin containing access token configuration and metrics that allows using their tiles.

Just like Google Maps (using their API's means using their client SDK), the same goes for Mapbox now.

• If you use their tiles, use their JS (they don't want you to use anything else)
• If you don't use their tiles, use Mapbox 1.x as long as you wish, but think about the future and migrating to Maplibre.

Don't expect an open source project to maintain or even tolerate proprietary code!

[HarelM]

I've merged the removal of the access token to main.
This will be part of version 2.0.
Version 1.x can be used for legacy compatibility.
There's also the addProtocol that can be used to add Mapbox support I guess. I don't know what it means in terms of payment, license etc. So use it at your own risk...

[hyperknot]

Can you give a brief update on the state of the things as of today? I need to offer basemap switching for users between various basemaps (including self generated OpenMapTiles) and Mapbox Satellite. Is there any supported solution for this?

AFAIK Mapbox v2 is out of question because it registers a request for non-Mapbox basemaps. Maplibre v2 is out of the question because it cannot load Mapbox Satellite. If I understand correctly, my only choice is Mapbox v1 or Maplibre v1 right? Both of them unsupported soon.

[HarelM]

I don't think it had changed since my last post...
I haven't seen anyone talking about implementing something related to addProtocol for mapbox but it might be because it's illegal, I don't know.
In any case, I guess it's your choice how to proceed in terms of support for old versions, relevant satellite source and payment options :-)
If you have issues with Mapbox implementation of payment you should talk to them. But I would advise to pay them according to their conditions if you are using their data. They are working hard on their products and deserve the money, IMHO.

[hyperknot]

Of course you pay them for their data, you only get data with a valid access token. That's why I'm basically stuck on v1, and I believe a lot of other projects as well.

[HarelM]

This is between you (and others projects) and Mapbox, I believe. Mapbox have decided to change their payment method to their products, which is a fully valid change, even if we don't like it :-)

[hyperknot]

I know it's clear and has been clear since 2.0 came out. I wanted to ask here other users of Maplibre how do they implement Mapbox + non-Mapbox sources in the same client application.

Basically it seems like the only option is to ship 2 libraries and use Deck GL or a similar wrapper on top of them.