3 ms·

> But for most of our use cases, we don’t need the latest and greatest. This is the crux of this. Let’s not pretend that much of this is anything other than “o

> But for most of our use cases, we don’t need the latest and greatest. This is the crux of this. Let’s not pretend that much of this is anything other than “open source clones of Mapbox”. PMTiles is genuinely innovative and I’m delighted to see it getting traction. Maplibre GL (which I use and like very much) is a fork of the last open source version of Mapbox GL, with not many code changes between now and then. Maputnik is an open source reimplementation of Mapbox Studio. Mapbox went on to hire its original dev. OpenMapTiles started life as basically a how-to/makefile pulling together the disparate, poorly documented parts of Mapbox’s open source tile generation code. It’s now mostly known for a reasonable, not particularly exceptional vector tile schema. It’s great that people are now shipping production vector tiles without paying the Mapbox dollar. But, PMTiles aside, this is still Mapbox’s world. The next challenge is to evolve the tech stack to something beyond what Mapbox worked up five/ten years ago.

lukeqsee 4y ago
> PMTiles aside, this is still Mapbox’s world. Isn't this a bit like saying we're still in Google's world because most maps still use Web Mercator? :) Good tech builds on what came before. Mapbox did a lot of ground-breaking work in building tooling around OSM, but so have many others. The fact that they named it Mapbox Vector Tiles is genius in hindsight, because even though we may use tons of tooling they didn't create to build and render them, their name is still there. > The next challenge is to evolve the tech stack to something beyond what Mapbox worked up five/ten years ago. Agreed, and I think we've seen a lot of iterative work in the open since then. The next challenge is likely building a OSS stack to do proper 3D: open data (including OSM) to pixels, and that work is already beginning across a lot of organizations: https://github.com/nyurik/future-mvt/discussions https://github.com/nyurik/future-mvt/discussions, Overture Maps, MapLibre, etc.
- twelvechairs 4y ago
  I get the parent comment. There are good alteratives to the mapbox ecosystem though they arent always used because people see mapbox as default DeckGL for instance is a very innovative js library for front end (really developed by Uber I believe), with better 3d and movement, better with dealing data at scale, etc. Prettymaps is a pure python approach to rendering OSM data. Etc.

lukeqsee 4y ago

> PMTiles aside, this is still Mapbox’s world. Isn't this a bit like saying we're still in Google's world because most maps still use Web Mercator? :) Good tech builds on what came before. Mapbox did a lot of ground-breaking work in building tooling around OSM, but so have many others. The fact that they named it Mapbox Vector Tiles is genius in hindsight, because even though we may use tons of tooling they didn't create to build and render them, their name is still there. > The next challenge is to evolve the tech stack to something beyond what Mapbox worked up five/ten years ago. Agreed, and I think we've seen a lot of iterative work in the open since then. The next challenge is likely building a OSS stack to do proper 3D: open data (including OSM) to pixels, and that work is already beginning across a lot of organizations: https://github.com/nyurik/future-mvt/discussions https://github.com/nyurik/future-mvt/discussions, Overture Maps, MapLibre, etc.

twelvechairs 4y ago
I get the parent comment. There are good alteratives to the mapbox ecosystem though they arent always used because people see mapbox as default DeckGL for instance is a very innovative js library for front end (really developed by Uber I believe), with better 3d and movement, better with dealing data at scale, etc. Prettymaps is a pure python approach to rendering OSM data. Etc.