Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maplibre: community-driven Mapbox GL fork

maplibre.org

Post reply on HN
Print view View original

41–50 of 87 posts

Re: Maplibre: community-driven Mapbox GL fork

#41

Post by la_fayette »

apendleton wrote: post #32
lukeqsee wrote: post #28

Earlier quoted context omitted.

Good question! There's a lot of Map 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 i…

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 techno…

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?

Re: Maplibre: community-driven Mapbox GL fork

#42

Post by lukeqsee »

mindcrime wrote: post #39
lukeqsee wrote: post #28

Earlier quoted context omitted.

Good question! There's a lot of Map 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 i…

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…

Mapzen is probably the one you're thinking of. A lot of their projects got rolled into various foundations (e.g., Linux Foundation).

Re: Maplibre: community-driven Mapbox GL fork

#43

Post by lukeqsee »

twelvechairs wrote: post #40
lukeqsee wrote: post #3

I'm one of the folks behind the fork (and part of the initial steering committee). Happy to answer any questions!

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?

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.

Re: Maplibre: community-driven Mapbox GL fork

#44

Post by kevinventullo »

la_fayette wrote: post #41
apendleton wrote: post #32

Earlier quoted context omitted.

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 techno…

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?

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.

Re: Maplibre: community-driven Mapbox GL fork

#45

Post by afavour »

la_fayette wrote: post #41
apendleton wrote: post #32

Earlier quoted context omitted.

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 techno…

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?

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.

Re: Maplibre: community-driven Mapbox GL fork

#46

Post by [deleted] »

la_fayette wrote: post #41
apendleton wrote: post #32

Earlier quoted context omitted.

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 techno…

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?

[deleted]

Re: Maplibre: community-driven Mapbox GL fork

#47

Post by mnutt »

lukeqsee wrote: post #22
billfruit wrote: post #9

Earlier quoted context omitted.

Does it support rendering of rasters? What about support on Desktop platforms?

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.

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.

Re: Maplibre: community-driven Mapbox GL fork

#48

Post by kristov »

lukeqsee wrote: post #28
unknown_error wrote: post #24

Earlier quoted context omitted.

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?

Good question! There's a lot of Map 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 i…

Great explanation, thanks!

Re: Maplibre: community-driven Mapbox GL fork

#49

Post by apendleton »

kevinventullo wrote: post #44
la_fayette wrote: post #41

Earlier quoted context omitted.

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?

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…

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.

Re: Maplibre: community-driven Mapbox GL fork

#50

Post by kylebarron »

twelvechairs wrote: post #40
lukeqsee wrote: post #3

I'm one of the folks behind the fork (and part of the initial steering committee). Happy to answer any questions!

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?

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...

Post reply on HN