[HN Gopher] Maplibre: community-driven Mapbox GL fork
___________________________________________________________________
Maplibre: community-driven Mapbox GL fork
Author : klokan
Score : 242 points
Date : 2021-06-23 15:30 UTC (7 hours ago)
(HTM) web link (maplibre.org)
(TXT) w3m dump (maplibre.org)
| DrBenCarson wrote:
| Forgive me if obvious--where are you pulling the underlying data
| from? Is the data itself OS licensed?
| tuukkah wrote:
| OpenStreetMap in the form of OpenMapTiles:
| https://openmaptiles.org/
| z77dj3kl wrote:
| Doesn't need to be OMT though. That's just the de facto free
| & open source tile generator from OSM data.
| codetrotter wrote:
| OpenStreetMaps probably.
|
| Mapbox uses data from OSM among others when they create their
| tiles. https://docs.mapbox.com/help/getting-started/mapbox-
| data/#co...
| Freak_NL wrote:
| OpenStreetMap* (no s at the end).
| codetrotter wrote:
| Sorry :p It's ironic because I had a friend once--well we
| shared kitchen and bathroom in the student housing,
| flatmates of sorts--that used to refer to Google Maps as
| "Google Map" and I never corrected her because I just found
| that adorable for whatever reason. Lol.
| unknown_error wrote:
| Good thing it's all digital. Unfolding one big Google Map
| would take a looooooong time...
| westnordost wrote:
| Where the SDK pulls its data from is not hardcoded.
|
| The SDK is just a library, used to render vector map tiles,
| usually in the MVT-format: https://docs.mapbox.com/vector-
| tiles/specification/
|
| Most maps rendered with such an SDK are based on OpenStreetMap
| data.
| lukeqsee wrote:
| As others stated, this demo dataset is pretty simple. I believe
| it's only using Natural Earth data
| (https://www.naturalearthdata.com/). The primary focus is on
| the rendering library.
| andrewljohnson wrote:
| This needs really solid Metal support or it won't be adopted on
| mobile.
| arsome wrote:
| Last I checked there's no WebMetal.
| RandallBrown wrote:
| Does there need to be?
|
| https://github.com/maplibre/maplibre-gl-native
| kennydude wrote:
| The smoothness on the demo (at least on my machine) is very nice.
| Good work :)
| klokan wrote:
| Open-source mapping libraries for developers using JavaScript,
| Android, iOS and more...
| ldng wrote:
| Same acceleration bug with Firefox under Linux that makes me
| hates Mapbox GL with passion ... Makes quite a lot of website
| unbearably unusable ...
|
| Would you please provide a way for the user to deactivate that
| terrible idea ? Thanks.
| mourner wrote:
| Can you please report this on our issue queue? From a cursory
| search, it doesn't look like anyone complained about scroll
| zoom on Firefox under Linux before. We'd be happy to fix this
| after hearing more details. https://github.com/mapbox/mapbox-
| gl-js/issues
| lukeqsee wrote:
| I'm one of the folks behind the fork (and part of the initial
| steering committee). Happy to answer any questions!
| unknown_error wrote:
| I've struggled to understand the relationship between Mapbox,
| Mapbox Studio, Mapbox GL, OpenStreetMap, and other libraries
| like OpenLayers or Leaflet.
|
| Could you please explain (in brief) the mapping "ecosystem" as
| it were, and where Maplibre fits into the picture?
| huy-nguyen wrote:
| Rough overview:
|
| Leaflet: fairly simple open source mapping library. Canvas-
| based. The original Mapbox (called MapboxJS) is based on
| this.
|
| Openlayers: open source mapping library that's more capable
| (e.g many different protections) but also more complex. Can
| render to Canvas or SVG.
|
| Openstreetmap: public and free source of mapping data. Mapbox
| uses this as a default data source.
|
| MapboxGL: completely new implementation of a mapping library
| written in WebGL (should perform better). MapboxGL changed
| its license recently, prompting the creation of the libremap
| fork.
| lukeqsee wrote:
| Good question! There's a lot of Map<thing>s and it's very
| unclear how they all fit together without prior experience.
|
| OpenStreetMap (OSM) is a community-driven, fully open and
| usable data library. It has usable data for almost the entire
| world for everything from cities, roads, houses, parks,
| country borders, and work. _It 's a database of everything
| you need to make map._ They also have a website that renders
| that map, but it's not commercially usable.
|
| Mapbox is one of the first companies to take OSM's dataset
| and commercialize it. Along the way they created a _lot_ of
| the wildly used mapping libraries, including renders, data
| formats, and styling tools.
|
| Mapbox Studio is one of Mapbox's proprietary tools for
| working with maps in their ecosystem.
|
| Mapbox GL is a suite of renderers, originally entirely open
| source, developed by Mapbox with the community to render map
| data (from many different sources).
|
| MapLibre GL is a community-driven _fork_ of the Mapbox GL
| suite, after Mapbox closed the licenses to require payment if
| you use the latest versions.
|
| OpenLayers and Leaflet are both alternative, open source
| renderers with various levels of capabilities. Interestingly,
| the creator of Leaflet now works for Mapbox (if my facts are
| correct and current).
| apendleton wrote:
| Yeah, the bit about the developer of Leaflet is accurate.
| One thing I'd expand on: the first iteration of web mapping
| was all built on raster maps, where the map was rendered in
| advance, server-side, and a simple client downloaded tiles
| to the client to build a slippy map. Leaflet was an open
| source library that did that task well.
|
| The commercial players have mostly abandoned this approach,
| though, in favor of technologies that render on the client.
| They're more performant (tiles are smaller), and necessary
| if you want, say, to be able to rotate your map and still
| have all the labels be upright and not collide, or
| show/hide individual geographic features dynamically in
| response to user input, or apply perspective/tilt as you
| would for a heads-up display in a car, etc.
|
| Mapbox GL was Mapbox building that (as already exists for
| Google Maps, Apple Maps, etc.). At a very high level, it
| and Leaflet serve a similar purpose, but are technically
| very different from one another.
|
| (full disclosure: former Mapbox employee, still a
| shareholder)
| la_fayette wrote:
| Isn't it the case that pre-rendered tiles are more
| performant for the mobile user? Continously rendering the
| tiles on a smartphone is draining more battery? I would
| guess?
| astrange wrote:
| It's true that raster tiles are easier to draw, but
| CPU/GPU is rarely the limit for performance even on
| (modern) mobile devices, network access then disk access
| then memory usage is. And using the network is one of the
| largest sources of power use. Vector tiles are smaller
| downloads, therefore they are more performant.
|
| Wall time CPU profiling is just not that useful anymore
| and yet it's the only thing most people ever think about
| for some reason.
| afavour wrote:
| Definitely true. In my experience it's less to do with
| battery and more that the client-side rendering process
| is so intense. Particularly because of the single-
| threaded nature of JS: a GL-based map on a web page makes
| the whole thing drag on a low-specced phone.
|
| These days Chrome and Firefox have the OffscreenCanvas
| API that would let you do all that rendering in a
| different thread, but last I looked MapBox GL didn't
| support it. Not sure if that's changed with libre.
| [deleted]
| kevinventullo wrote:
| Yeah, pre-rendered tiles are typically more performant on
| any device. It's basically downloading and displaying a
| png. In my experience, download times were not the
| bottleneck for vector tiles, but rather all the on-device
| rendering. This is especially true when you consider that
| most of the time, the tiles are already cached on your
| device.
|
| I believe the reason most companies moved to vector had
| more to do with the other stuff gp mentioned: ability to
| rotate, dynamically show/hide features, etc.
| apendleton wrote:
| If you never change what you display, that might well end
| up being true, but if changing display state (you want to
| highlight or shade or hide a feature, for example) that
| would likely require downloading whole new tiles for
| raster but could be a pretty trivial mutation of the
| current local state that doesn't require a full re-render
| from scratch. You probably also don't need to download as
| much on zoom; there _are_ tiles for different zoom levels
| with vector tiles because tiles get really large when
| zoomed way out otherwise, mostly full of features or
| detail you can 't see or wouldn't show, but you might not
| need as many, and can overzoom a given tile and have it
| still look nice with relatively few artifacts. All of
| which is to say: it depends.
| lukeqsee wrote:
| Yes, for sure. Good expansion points.
| unknown_error wrote:
| Got it. Thanks a lot for the clear explanation!!
| kabes wrote:
| Leaflet started because openlayers was very clunky. But
| since the major rewrite of openlayers v3 it's become a
| great choice and the author of leaflet has stated here on
| hackernews hat it's probably what you should use these days
| kristov wrote:
| Great explanation, thanks!
| mindcrime wrote:
| I feel like I half-remember something I saw here on HN a
| couple of years ago, about some mapping related startup
| going out of business, and open sourcing some interesting
| tidbits. Do you (or anyone else) happen to remember that,
| or know what I'm talking about?
|
| Sorry for being so vague, that's just all I remember of the
| whole deal. I probably bookmarked the link, but I'll
| probably never find it again now.
|
| Edit: it may have been MapZen that I was thinking about.
|
| https://www.mapzen.com/blog/shutdown/
| lukeqsee wrote:
| Mapzen is probably the one you're thinking of. A lot of
| their projects got rolled into various foundations (e.g.,
| Linux Foundation).
| tuukkah wrote:
| A big difference moving from OpenLayers and Leaflet to
| MapLibre GL is that you can use vector tiles and style them
| in the browser as opposed to rendering PNG files on the
| server. Converting OpenStreetMap to vector tiles is
| implemented by OpenMapTiles and they also have some open map
| styles.
| kabes wrote:
| no, openlayers supports vector tiles out-of-the-box and
| leaflet with a plugin
| karussell wrote:
| You can use vector tiles with openlayers but they draw it
| on the canvas and not via web GL i.e. it is slower.
| tppiotrowski wrote:
| Leaflet - developed to work with PNG image map tiles
|
| Mapbox GL/Maplibre - works with vector tiles which are
| similar in format to an SVG
|
| I believe this plugin[1] is a hybrid approach which allows
| Leaflet to load vector tiles on a plain 2D map with no map
| tilt or rotation
|
| [1] https://github.com/mapbox/mapbox-gl-leaflet
| loulouxiv wrote:
| What would it take to display a map in a style as close as
| possible to the one used on openstreetmap.org ?
| kylebarron wrote:
| It would take someone designing the same style in the vector
| format. This [0] is the closest I've seen to a vector port of
| the default OSM style. Demo [1]
|
| [0]: https://github.com/baremaps/openstreetmap-vecto
|
| [1]: https://www.baremaps.com/assets/demo.html
| loulouxiv wrote:
| In the Github issue linked by z77dj3kl I found a link to
| this vector port by ESRI : http://esri.maps.arcgis.com/apps
| /View/index.html?appid=d6b18... Closed source but very
| impressive
| lukeqsee wrote:
| A few things:
|
| - A data source for vector tiles; there's a lot of options:
| https://stadiamaps.com (my company), https://maptiler.com/ &
| https://jawg.io (other core contributing companies), among
| others.
|
| - A style that matches. I'm not aware of an open source style
| that closely mirrors OSM's style using MapLibre GL Styles
| (also forked from Mapbox). OSM Bright is pretty close:
| https://github.com/mapbox/osm-bright /
| https://github.com/openmaptiles/osm-bright-gl-style.
| z77dj3kl wrote:
| The OSM style is here:
| https://github.com/gravitystorm/openstreetmap-carto
|
| There is an issue about converting it to vector:
| https://github.com/gravitystorm/openstreetmap-
| carto/issues/3...
|
| Doesn't seem like there's any current vector versions of that
| style, but you could make one yourself using Maputnik or
| similar; you'd probably want to start with OpenMapTiles and
| maybe even one of the pre-existing styles for OMT like OSM
| bright.
| twelvechairs wrote:
| Im curious as to integration with DeckGL which seems to be the
| emerging standard for 3d maps and also for interactivity. Do
| you know if maplibre will work the same with it as mapboxgl
| does?
| kylebarron wrote:
| Yes. deck.gl has two ways of interfacing with Mapbox GL,
| either where deck.gl is a layer on top of Mapbox GL (with a
| separate WebGL context) or by sharing the same WebGL context.
| Sharing the same WebGL context allows e.g. Mapbox's 3D
| buildings to "pop" above deck.gl or to put Mapbox's labels
| above deck.gl layers. Those docs are here [0].
|
| Either way, the recommended way of connecting deck.gl with
| Mapbox is through React Map GL. Those docs describe how to
| use Maplibre GL here [1] and here [2].
|
| [0]: https://deck.gl/docs/get-started/using-with-map#using-
| deckgl...
|
| [1]: https://visgl.github.io/react-map-gl/docs/get-
| started/mapbox...
|
| [2]: https://visgl.github.io/react-map-gl/docs/get-
| started/get-st...
| lukeqsee wrote:
| I'm not sure as to specifics (as I haven't tried this), but
| if DeckGL worked with 1.x Mapbox GL JS, it should just work
| with MapLibre, with a few potential minor adjustments (e.g.,
| nomenclature). Can't promise it though.
| billygoat wrote:
| I can verify this: I upgraded my Deck.gl project from
| MapBox to MapLibre recently, and it was a simple matter of
| renaming some imports.
|
| This works absolutely seamlessly.
|
| I'm using Vue instead of the React integration and that's
| also working without any issues.
| unknown_error wrote:
| I noticed that Mapbox Studio has a way of creating & exporting
| styles (kinda like stylesheets but for maps). Do you know if
| those styles can be imported into a libre renderer like
| Maplibre, or if a similar tool/ecosystem exists for creating &
| sharing open-source map styles? Like if I wanted all roads to
| be rainbow-colored and rivers to be green.
|
| In Mapbox Studio, the features all seem to be semantically
| tagged (e.g. this is a road of type X, a POI of type Y) and it
| makes styling a cinch. I know OSM has its own set of tags for
| features. Are these compatible (not sure if Mapbox Studio is
| using OSM data underneath)? Is there an established standard
| for this type of thing?
|
| (ps TY again for answering my other question so thoroughly)
| lukeqsee wrote:
| https://maputnik.github.io is similar to Mapbox Studio, but
| isn't going to give you all you mentioned.
|
| All vector tile sources use tags in various ways, so Maputnik
| (and the resulting styles) do as well. There isn't a standard
| tagging schema (and all MVT sources tend to differ slightly),
| but OSM's tagging is often influential on the resulting
| schema.
| unknown_error wrote:
| That's exactly what I was hoping for. Thank you again!
| billfruit wrote:
| Does it support rendering of rasters? What about support on
| Desktop platforms?
| z77dj3kl wrote:
| Yes, you can render raster layers (tile sources).
|
| https://docs.mapbox.com/mapbox-gl-js/example/map-tiles/
| tuukkah wrote:
| And here's the forked version of that example:
| https://maplibre.org/maplibre-gl-js-docs/example/map-tiles/
| lukeqsee wrote:
| MapLibre GL Native supports server-side raster rendering via
| tileserver-gl or a custom server implementation (my company
| does this).
|
| Desktop support should be possible with some extra work with
| Native, but I'm not certain, for instance, if the QT bindings
| are fully working yet.
| mnutt wrote:
| My understanding is that mapbox-gl-native dropped node
| binding support prior to the fork; the code is still there
| but the build system can't build it. I'm hoping to help
| maplibre bring it back up to a working state.
| fatnoah wrote:
| The site mentions "additional functionality" vs. Mapbox Native.
| Is that additional functionality listed somewhere? (Apologies
| if it is and I missed it)
| lukeqsee wrote:
| Metal support (coming soon) and MBTiles support (released
| AFAIK) are two things I know of, but I defer to the Releases
| page for specifics beyond that:
| https://github.com/maplibre/maplibre-gl-native/releases.
| fatnoah wrote:
| Thanks!
| TOMDM wrote:
| Maybe not the best place for this, but hey it's a question.
|
| When adding clusters vs points to a map, filtering points is
| really simple, but I haven't found a simple way to filter
| clusters outside of filtering a data source and reapplying it
| to the clusters.
|
| If there a better way of doing this?
| [deleted]
| [deleted]
| westnordost wrote:
| If it is true that Apple will soon drop OpenGL and only support
| Metal:
|
| Will the SDK also work on iOS and Mac then, i.e. has Metal
| support?
| lukeqsee wrote:
| There is active development on a Metal-supporting version, yes!
|
| https://github.com/maplibre/maplibre-gl-native/tree/metal-su...
| is the branch and https://github.com/maplibre/maplibre-gl-
| native/issues?q=is%3... are associated issues.
| sulewicz wrote:
| Yes, we have a beta build of the SDK with Metal support
| (https://github.com/maplibre/maplibre-gl-native/tree/metal-
| su..., https://github.com/maplibre/maplibre-gl-
| native/releases/tag/...). There are some minor issues we are
| addressing in the new release. Contributors and brave souls
| willing to try out the build are more than welcome :).
___________________________________________________________________
(page generated 2021-06-23 23:00 UTC)