This looks great, although on first glance seems that the new GL implementation is a new library, not an extension of Leaflet.
I think that's a mistake — Leaflet is solid and is the foundation on which a lot of extensions are built, to the point where my impression is that it's pretty much the de facto JS-based map widget these days.
While the new library looks decent, I don't see the point of creating a brand new library rather than extending Leaflet, other than to force clients to couple tightly to Mapbox's API, tile server etc.
It makes a lot of sense because this library is vastly different from usual slippy maps — fluid continuous zoom & rotation, extremely powerful visualization and interactivity potential, no DOM constraints — fitting it into the Leaflet API which was designed for simple image tile-based maps would be very limiting.
On the other hand, Mapbox GL JS is a very complicated technology under the hood, it is much heavier, with more code, lots of algorithms, serious backend technology to support it etc. So there's a place for both libraries — Leaflet remaining the go-to super-simple, friendly and lightweight library for most maps, while GL JS being an experimental ground for maps of the future with unlimited potential.
Considering Mapbox's history of slight misunderstandings with the Openstreetman community, I would have thought that the touchy subject of attribution would have been dealt with more carefully...
Mapbox is now a major actor in the Openstreetmap community - its contributions are considerable in quality and quantity. As a result, there is a lingering fear of Openstreetmap sliding toward dependency from Mapbox. In this context, there have been a some flaming about the flexible way Mapbox interpreted the attribution requirement on its maps - Mapbox fixed that but it left some contributors edgy about it. Then there have been requests by Mapbox, notably at the last SOTM-US, for a license change to drop the share-alike requirement - that too has ruffled feathers. So while I believe the relationship with the rest of the Openstreetmap community will work out fine, Mapbox needs to work on not being perceived as arrogant.
Sorry, we focused so much on the underlying tech challenges and getting this out in the open as fast as possible that we slipped some presentation details. Fixing today.
Thanks for taking that into account - and don't apologize for your priorities : had you not had published such a technically excellent product, no one would have bothered complaining...
The whole Mapbox GL stack is open source and can be used locally as well. It is complicated, but possible nevertheless.
Also, it's very different — with OL3, you just have GL rendering usual server-rendered image tiles with some simple vector data overlays, while Mapbox GL JS renders OSM vector data on the client.
This is really impressive. It's clear someone really spent a lot of time making the controls feel nice and fluid. I'd love to know more about how vector tiles are streamed to the client, and how I could do similar streaming of my own data.
I guess some of the old dusty GIS Enterprise Solutions, now _slowly_ have to start worrying about competition in such form (I know you can't compare it to a full Featured GIS, as a map is only a component of many many things that are required to be usefull). Current solutions are way behind and the moment when it comes to the presentation and manipulation of data (imho). They will have to up their game significantly to stay relevant.
What is interesting with MapBox, is that they essentially offer functionality similar to Geoserver + Openlayers, but with a far more focused, nice, modern user experience.
Certainly in terms of government systems, I think companies sell to people who will never use the system. Procurement people who worry about getting locked in by Mapbox just like they were with ESRI. Government IT people who want to host everything locally. Sadly in that kind of a sale, user experience doesn't matter so much as it should.
> [...] it uses JavaScript and WebGL to dynamically draw data with the speed and smoothness of a video game.
Am I the only one who gets poor performance?
When I drag around the first map quickly, I get about 5 FPS, and the "chrome" process on my system jumps to 100% CPU usage (running Chrome 35.0.1916.153). The same with Firefox Nightly (33.0a1), although the FPS is higher here (10-15 FPS). My CPU is an eight-core AMD FX-8320.
This is the first time we're hearing performance in that magnitude, and it's definitely not the intended frame rate. It sounds like your system is switching to software OpenGL rendering, rather than running directly on your GPU. Could you please share more details about your system on Github? https://github.com/mapbox/mapbox-gl-js/issues/new
I just updated my GPU drivers using the xorg-edgers PPA on Ubuntu 14.04 (https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa) and now it's a lot better. Dragging the map, there's a small delay before the map moves, but when it does it's smooth. I remembered that I was having problems with Google Maps, as well as other Web GL stuff, so I figure there was a bug in my drivers.
This is crazy impressive. I'm still reading the source but so far what i see is really great already. Very concise and clean. I would love to see an embeddable C + portable ES2/CoreGL version of this.
Edit: Just found the native version. A bit heavy on dependencies but basically what I was asking for. :)
I'd love to hear a bit more about how you handle thick lines and anti-aliasing in WebGL.
Currently my approach is to make the line a little thicker and then apply the anti-aliasing in the frag shader. Similar to GPU Gems "Fast Prefiltered Lines." But it gets tricky with end caps, round joins, etc.
Just this mean, we can style a raw vector map from mapbox without applying styles? I'm not able currently style maps with a huge number of point on vector mapbox due to the tile processing limit. I am able to host the vector file though. Being able to directly style raw vector files on the client really opens the doors to a realm of possibilities.
Doesn't look intentional. I've gotten drastically different street name coverage for the same area at the same zoom level depending on whether I got there by panning or zooming. And neither one includes names for the whole screen. Still a few kinks to work out?
It feels like the text pops in and out as large zones, and the zones are unloading themselves before the whole zone is offscreen, sometimes leaving large areas blank.
For reference, the upper image was produced by panning. The area on the right had been showing text, but it vanished as it got near the edge of the screen.
I'm running Firefox 32 Beta on Windows 8.1 with DPI scaling, in case that helps narrow it down. Tried to test it, but I don't think I can get FF to stop scaling without logging out and back in; quitting and rerunning it with the disable scaling box checked doesn't work. That's normally the first thing I look at for graphical glitches on here, though I have no idea how it affects WebGL.
Great job with this! Coming from Google Maps and similar, the smooth motion is mesmerizing, especially labels staying level as you rotate. And tile loading/pop-in is much quicker than what I get from Google.
Hands down the best team I've had the pleasure of meeting so far; these guys have a track record of building awesome stuff. Looking forward to use this on our next project.
I think that's a mistake — Leaflet is solid and is the foundation on which a lot of extensions are built, to the point where my impression is that it's pretty much the de facto JS-based map widget these days.
While the new library looks decent, I don't see the point of creating a brand new library rather than extending Leaflet, other than to force clients to couple tightly to Mapbox's API, tile server etc.