* A single style specification format that works well for both base map rendering and data overlays
* Parity across native and web rendering
* Smooth SDF text rendering with decent i18n support
* A font to SDF renderer that is open source: https://github.com/mapbox/node-fontnik
* A tiled data format that is open source: https://github.com/mapbox/vector-tile-spec
I hope this licensing change can spur some competition among open source renderers. I’d recommend taking a look at:
* Tangram: https://github.com/tangrams/tangram - another WebGL based renderer with some key advantages over MapboxGL JS such as custom shaders and canvas text
* OpenLayers: https://openlayers.org has some vector and WebGL capabilities now as well
* Harp: https://www.harp.gl is another new WebGL option
I've been working recently with Tangram, so contact me (see user link) if you have questions or are interested in collaborating!
- GeoJSON-VT (fast GeoJSON processing) https://github.com/mapbox/geojson-vt
- Earcut (triangulating polygons) https://github.com/mapbox/earcut
- Supercluster (point clustering) https://github.com/mapbox/supercluster
- vt-pbf (converting GeoJSON tiles to VT) https://github.com/mapbox/vt-pbf
- vector-tile (decoding vector tiles) https://github.com/mapbox/vector-tile-js
- pbf (fast reading/writing of protobuf) https://github.com/mapbox/pbf
- TinySDF (generating SDF from local CJK fonts) https://github.com/mapbox/tiny-sdf
- Potpack (generating sprite layouts) https://github.com/mapbox/potpack
- grid-index (spatial index for collisions/querying) https://github.com/mapbox/grid-index
- Pixelmatch (image comparison in render tests) https://github.com/mapbox/pixelmatch
- Polylabel (fitting labels into polygons) https://github.com/mapbox/polylabel
As far as I know as someone who worked here for 7+ years (take this as personal opinion), Mapbox wants to keep investing heavily in open source and open data sustainably and indefinitely, and this GL JS change is an unevitable prerequisite for that. This may not be easily apparent at this moment but it will be soon.
Introducing a drastic billing change under the implied threat that your year or more of man hours performed using an underlying open source library with an understandable billing model is now potentially at risk, is shady. These billing changes make some self hosted tile users go from $0 to tens of thousands of dollars a month in usage. It’s shady, don’t lie to yourself.
Also, you are not your company. I am not saying you are shady, because you are just a person who has bills and a skill and you need a salary. Don’t conflate criticisms of your employer as attacks on yourself, or you can have a hard time seeing what other people see. Tricking yourself to believe something that might not be true is one of the worst thing you can do.
This only happens if the developer deliberately upgrades and adds a token. If you do nothing and you keep using v1 - nothing changes for you.
The frustrating thing is that we just went through this with google. We paid a reasonable amount, but then got extorted to pay more or jump ship. We jumped ship to a reputable company, mapbox, and we paid a reasonable sum of money for how we used the software, and now the cycle continues. To be clear, I am not complaining that we are paying $0 and we should get the benefits for free. I am saying that we shouldn't be jumped up multiple orders of magnitude in cost, which isn't in-line with our actual usage. That's the shady part.
With move like this, what's the difference?
(Yes, I do share anonfornoreason's sentinent in the sibling comment.)
It's no different to the likes of Oracle. Oracle also employs hundreds of people.
But hey, if you think everyone who criticizes it is full of vitriol, I don't think any further discussion is needed.
In Mapbox there was an easy way to build mapping tools. It let you create rubberbands, hook into map events. Is that possible with Tangram?
For anyone interested in an open source mapping library (that also has 3D support) that can handle raster data (including the Mapbox tiles), I launched a project 2 weeks ago that is the culmination of 7 years effort: https://github.com/felixpalmer/procedural-gl-js/.
I must say (while acknowledging my huge bias) that I'm disappointed with how the 3D terrain works in the new Mapbox version. It is the top-billed feature, but the controls feel clunky, the terrain often disappears and they didn't even bother implementing distance fog to give the scene scale. When they announced the 3D feature last year I was expecting more.
This is really impressive. Just one question about the distance fog, though: as you say it does give the scene scale when you're close to ground, but if you zoom out everything becomes foggy so it seems like it kind of gets hard to see anything. Wouldn't it make sense to somehow reduce the fog as you zoom out so this doesn't happen?
* openlayers, but vector tiles have no web GL support there
* Procedural GL JS
* deck.gl (from Uber)
* harp.gl (from HERE Maps)
Leaflet is also great.
If you're doing any sort of front end GIS I recommend openlayers above all else including mapbox.
But I suspect 99% of users just need basic maps. Leaflet is great for that.
They removed this support in some previous version, I think.
Or do you have a link to a pull request or issue?
(IMO Leaflet is dead now that the creator is working since several years for Mapbox)
What someone can see as less development activity is simply a sign of a mature product that doesn't need many new features and changes to remain useful — focusing on the core basic mapping needs has always been its goal, and it continues to adhere to it.
What I see or meant as a sign of "dead" is that there will be no new features that Mapbox GL JS has but that are critical for future applications. Like proper or inbuilt vector tiles support.
Unfortunately that whole business unit got canned and the code is now gathering dust somewhere :/ would have loved to open source that one
I'd encourage you to reach out and ask for permission to release it. In the past I've found that the sticking point was usually copyright assignment rather than the release per-se (with a side helping of worry over hidden IP violations), so get them to release a tarball under a permissive license like MIT/BSD, even if your intention is to immediately fork it.
Basically, if you can manage to do the work for them so they can just rubber stamp the release, you can probably get it done.
I thought one of the primary features of Leaflet was its modularity. Would built-in vector tile support be an anti-pattern?
I've perpetually run into memory leaks and Max gpu issues whenever I try to use WebGL stuff in Openlayers depending on which browser I use.
Something will work fine in Chrome but max out my laptop's discrete card in Firefox until my laptop thermal throttles.
If you want a concrete example of this I would be happy to put together a reproducible example for you.
It does 3d, 2d, vector tiles, client side geoprocessing, and plenty of open data/service types
I'm keen on industrial archaeology and it's really helpful to have 3D visualisations of sites like old quarries.
Stand-alone 3D models can be done like  and the detail is substantially better compared to the map 3D views  (pits are pits again!) but I want to embed these into a website and start overlaying other data - just like I can with Mapbox maps.
2. https://felixpalmer.github.io/procedural-gl-js/, search for Llanberis
I have seen in demos coming from a few construction projects using this.
We also created a 3D renderer for sports tracking app Ayvri. Our standard player is Cesium, but if you click on the view beta link, you'll see our custom renderer. Still improvements to be made in tile loading.
- Why have a vertical limit when rotating in 3D? I have to click on 2D to look directly top-down. This would be the natural result if I simply tilted the camera all the way downward, but instead it maxes out at some arbitrary angle. (Same the other way, I want to look at the horizon, but I guess there are bandwidth issues involved.)
- Scroll zoom is waaay to slow. I have a mouse with an inertial wheel, so I can just let 'er rip, but this must be frustrating with a regular mouse wheel.
- +/- keys don't zoom, like I'd expect them to.
As you say, the further you can see the higher the bandwidth bill. If you really want to see the horizon, make the window narrow :)
For the other issues, could you please file a issue on the repo? This is not expected and works great on all machines I've tested.
I noticed on the demo that if I zoom all the way out, and then use my mouse wheel to zoom in quickly enough I can clip into the earth and see the black below. This does seem to depend on scroll speed being high enough.
The FAQ says developers can still use self hosted tiles, but also says that usage is now billed per map load, and "a map load occurs whenever a Map object is initialized on a webpage. Each map load includes unlimited vector tiles, raster tiles, and terrain tiles for the length of the map session.".
To me that sound like while I can still use my own map tiles, it would still costs the same as if I used Mapbox hosted tiles.
That's my reading of it, as well. Even though it's somewhat expected on the data collection side, it's decidedly unexpected that they not only require ToS acceptance, but also licensing fees for what used to be entirely free, OSS software.
> Hopefully the OSS community can maintain a fork of the 1.x codebase.
I'm sure this will happen. My company is trying to get some consensus around the best way to proceed. Email in bio if you're interested in taking part!
Let's set autobuild of documentation, packages and configure CI on pull requests. Pull requests, forks & contributions welcome - as on other parts of the https://openmaptiles.org/ project providing free and open-source vector tiles of entire world for self-hosting.
In all seriousness I completely agree as someone in the mapping community this seems like a logical home. You have my vote!
WhirlyGlobe/Maply has been around a long time. It actually predates MapboxGL and it's used in popular apps like Dark Sky, as well as a ton of aviation apps and a not a few GIS apps.
Engineers like to write their own, so we're going to hear from a ton of random projects here. And hey, more power to 'em.
But you're looking for a fast, open source mobile map toolkit that's going to be around next week? It us.
With Native it's more critical. A GL JS fork can continue quite easily. The iOS Native library, however, uses OpenGL and will therefore stop working when Apple finally switches to Metal-only. (Mapbox only released their Metal port under the new proprietary TOS.)
Under 50,001 monthly loads is free but after that it costs $5.00 per 1,000 loads: https://www.mapbox.com/pricing/
> Mapbox GL JS v1.x.x: A map load occurs whenever a Mapbox GL JS Map object is initialized on a webpage and you request a Mapbox-hosted map tile.
> Mapbox GL JS v2.x.x: A map load occurs whenever a Mapbox GL JS Map object is initialized on a webpage. https://docs.mapbox.com/help/glossary/map-loads/
"This license terminates automatically if a user no longer has an active Mapbox account."
> Can I use data or tiles from Google Maps or other non-Mapbox services?
> Yes. GL JS is fully interoperable with third party map sources that provide vector or raster tiles in supported formats. Usage of v2 is billed by Map Load to the Mapbox account owner. The license terms make no distinction between data sources.
They're charging for Mapbox GL JS, even if you don't actually use their tiles.
OSS, we hoped, was about enabling people and unlocking people's ability to collaborate. It turns out that in 2020, it's mostly helping companies and getting nothing in return. That's not a dynamic you can build a sustainable business on.
I believe that you believe this is well intentioned, but it had a very negative impact on open source geospatial software development. Again, I SHOULD KNOW.
Mapbox is doing what is good for Mapbox. It's a company. But let's not pretend this change is good for anyone but Mapbox.
But there's more to it. When the roadmap of an open-source project is tightly controlled by a sponsor, that can make third-party contributions hard or impossible. I know OSRM much better than MBGL so I'll cite an example from that - the distance matrix issue. This is massive for many users, plays right to OSRM's strengths, but Mapbox wouldn't accept patches to provide it for _years_. IIRC it only got in when Mapbox's attention shifted to Valhalla.
I'm not blaming the Mapbox devs at all for that; it wasn't important for Mapbox's business, and any extra code inevitably brings a maintenance burden. But it partly explains why third-party contributors are reluctant to contribute when the roadmap's out of their control.
Back on MBGL, there was/is a community, but the community formed around MVT rather than MBGL specifically - again, possibly because MBGL is just so good. https://github.com/mapbox/awesome-vector-tiles sums up the enormous community energy in the space (I think that might be your document originally, apologies if not). It's kind of a shame that MBGL being so far ahead of everything else has probably crimped development on alternative renderers.
Regarding code contributions, the community contributed e.g. the TypeScript and React bindings, or am I mistaken?
While I agree there has been non-trivial contributions external to the core of gl js (eg. bindings, plugins), and these help the ecosystem, they don't replace work on the core.
Personally I'd hoped that those businesses who were using GL JS commercially without a commercial subscription through Mapbox would contribute and become part of the core development and maintenance, but that didn't happen to a large degree.
EDIT: The title has now changed but it was "Mapbox GL JS is no longer open source", which is the point: they didn't change from an open source license to another.
We're looking into this, as well as trying to build consensus with the other map vendors on how to approach it.
If you're a vendor and what to be part of it, email me (luke at stadiamaps.com).
I also use mapbox gl js for visualizing large datasets locally (precomoute vector tiles from non-geographic datasets), which doesn’t seems like it needs to be reaching out to mapbox servers.
Happy to help, I’ve had a few pull requests accepted to the mapbox gl js codebase.
We'll probably end up removing Mapbox from the deck.gl examples, but I can't say for sure.
If that's because of the licensing, would you remove Google Maps & ArcGIS examples as well?
The rest of the examples are to show deck.gl's capabilities. They currently use Mapbox GL JS v1 (recently changed to use Carto's basemaps so that new users can test deck.gl without any API key). Those examples focusing on deck.gl are what I meant to refer to originally; it seems unlikely we'd move them to GL JS v2, at least, because we aren't currently using Mapbox services with them. (But again, the team hasn't had full discussions about this yet).
You can use deck.gl + Google Maps: https://deck.gl/docs/get-started/using-with-map#using-deckgl...
Deck.gl has also a MVTLayer: https://deck.gl/docs/api-reference/geo-layers/mvt-layer
Pins dropped down the street from actual address and search results don't narrow in accurately using POI and city/state - for example "Chipotle Parker Colorado" rather than showing the 3 chipotles in Parker, CO lists:
- the city "Parker, CO"
- Parker street in Pueblo, CO
- childrens hospital therapy center in Parker, CO
It just doesn't match the behavior our users have - probably because they have been trained how to search using google and google maps.
I am guessing the main use for mapbox is actually custom tiles and custom datasets but anyone using it as a replacement for google maps I'd love to hear if you were able to solve this without too much trouble. We preferred their API, sdks, and pricing over google maps but just couldn't get the results we wanted.
We wrote and maintain the open-source Pelias geocoder(https://github.com/pelias/pelias) at Mapzen and have been continuing to improve it in the 3 years since Mapzen's shutdown.
Geocode Earth is our hosted service built around Pelias so you can get started quickly, not worry about keeping data up to date, or doing all the fine tuning and optimization that we've had to do to get fast and reasonably accurate autocomplete outside of Google and Mapbox.
Using our hosted comparison tool you can see that we do a pretty decent job of finding two out of 3 of the Chipotles (the third might have been deduplicated or not in OSM):
Most our users end up passing a focus point, in which case the results are generally even better, although they're the same in this example
We will keep you in mind as our usage grows or if we have another project. Your tiered pricing doesn't make sense for us as we launch.
Thanks for the good feedback on our pricing. We plan to roll out pay-as-you-go pricing in 2021 that should help with that. In the meantime feel free to reach out to us at firstname.lastname@example.org and we can set you up with a smaller plan to get you started, if you'd like.
https://opencagedata.com seems to be the best around using open data and offer API compatibility (or did at last check).
Looking over their API docs, you can search for points of interest (POI), but that's it: https://docs.mapbox.com/api/search/geocoding/
For your use case, you should look into a geocoding service . And then you can display the location results with your mapping library of choice. Google Maps does provide an all-inclusive service, but as you've mentioned, styling is better with Mapbox (and pricing).
 - Aside from Google and Mapbox, I've never used any of these alternative geocoding services: https://smartystreets.com/articles/is-there-a-geocoding-api-...
I think "location text" is the part they are not parsing well.
The screenshots all over that page show someone entering a couple of letters and getting the resulting POI with address.
Unfortunately, we could not get reliable results using their web place search so maybe they just have better mobile sdks that are adding more filter data to the requests automatically ¯\_(ツ)_/¯
If you're sticking with Mapbox, you'd probably need to a two-step lookup to obtain some useful results.
1. If there's no street address, check the search string to see if there's a city, or city, state. Find the lng,lat of that to use as the proximity bias. If nothing exists, use the user's current location. (Maybe this is why the mobile SDK is better.)
2. Then add the proximity bias while searching for the POI
But just a heads up, even a simple city query can be problematic. From personal experience, "san jose" would return San Jose in Costa Rica, or San Jose City in the Philippines, and rarely San Jose, CA, US unless a user was to type all that.
Google definitely has better NLP to handle user search queries.
Pretty common to use Google to look up an entity (to either get address or full geocoding results) and then Mapbox to do the display though.
I regret building out on mapbox-gl-js rather than leaflet...
Hundreds of new forks on Github in the last few hours. Maybe there will be a semi-official community version.
Our initial primary goal is to avoid fragmentation, and thereby support a healthy OSGeo community.
Updating from mapbox-gl-js should be pretty smooth, I just pushed the first batch of release builds to npm for what will become email@example.com: https://www.npmjs.com/package/@maps-gl/maps-gl
IANAL, but it seems you can only use the library if you have an active account, and you can still modify the code except billing and analytics. The it links to the TOS ( https://www.mapbox.com/legal/tos ).
But, the big change is in their issue they opened about it:
> Can I still use self-hosted map tiles?
> Yes. Developers simply need a Mapbox account and access token to use this v2.
Maybe won't be long until we see "Open Distro for Mapbox" like was done with Elasticsearch
At least 50% of my work projects happen because the resources I'm using are free. If it isn't free, the project either doesn't happen, or I spend a few months coding what is missing.
So I'd rather they tell me upfront that I can't afford their product than waste my time.
Why? This strategy often maximizes shareholder value. Provide a free product in the growth phase and once you shake off competitors and build a moat (aka a monopoly), you start taking profits. Charging money during the growth phase will slow down the growth.
First as bigbubba said it's a dick move and second, do you really want users that have no trust in your company. Google is missing a lot of potential users for its cloud business due to them killing products on seemingly random basis.
Is there any OSS or economical (Non-ESRI; non-Google) commercial solution for WebGL maps and vector base layer that supports non-mercator projections without hacks? (Arbitrary projections, not just distorting mercator onto a spehere)
https://www.mapbox.com/pricing/ A map load is counted every time Mapbox GL JS initializes on a webpage or in a web app. A map load includes unlimited Vector Tiles API and Raster Tiles API requests.
Not all closed source software is pay-per-use, but this one is. And can you point me to an open source license that requires pay per use?
This move to closed source stops the free use that was possible this far with the open source license. To me, that's a plausible motive. Is there a more significant one?
This is from 2014 https://github.com/mapbox/mapbox-gl-js/blob/3727f6f012866f77...
It is as if people were exploiting their ideological free labor for personal benefits... weird how the real world works...