This needs really solid Metal support or it won't be adopted on mobile.
Last I checked there's no WebMetal.
Maplibre: community-driven Mapbox GL fork
61–70 of 87 posts
Re: Maplibre: community-driven Mapbox GL fork
#62Earlier quoted context omitted.
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.
no, openlayers supports vector tiles out-of-the-box and leaflet with a plugin
You can use vector tiles with openlayers but they draw it on the canvas and not via web GL i.e. it is slower.
Re: Maplibre: community-driven Mapbox GL fork
#63This needs really solid Metal support or it won't be adopted on mobile.
Last I checked there's no WebMetal.
Does there need to be?
Re: Maplibre: community-driven Mapbox GL fork
#64Earlier quoted context omitted.
What would it take to display a map in a style as close as possible to the one used on openstreetmap.org ?
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
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
Re: Maplibre: community-driven Mapbox GL fork
#65Earlier quoted context omitted.
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 ti…
To some degree its possible to combine bitmap tiles and client side lightweight vector overlay. If you want to work with ortofoto (basically satellite/airplane captured imagery) then you basically have to do it that way.
Re: Maplibre: community-driven Mapbox GL fork
#66This is going to be a good test of my rule that any project with "libre" in the name -- except, as my astute colleague pointed out, libreadline -- is doomed to failure.
Re: Maplibre: community-driven Mapbox GL fork
#67I don’t see any support for alternate projections. For my raster-based dataset (satellite data) of polar regions I don’t see any benefit over my current openlayers approach. Looks great for vector-based 4326/3857 projected data, though! Please let me know if I’ve overlooked projection support?
Re: Maplibre: community-driven Mapbox GL fork
#68Earlier quoted context omitted.
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 Rea…
> Either way, the recommended way of connecting deck.gl with Mapbox is through React Map GL.
I should note this is only the recommended way when you're using React
Re: Maplibre: community-driven Mapbox GL fork
#69Earlier 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?
Along with dynamic rendering mentioned in other comments, vector data is sparse, so bandwidth is basically zero past a certain (surprisingly low) zoom. Raster tiles are a dense data structure, so you need to bake tiles to the maximum allowed zoom and clients need to download them. High zoom tiles also have higher entropy so you end up with a huge volume of images with low cache hit rates. It’s expensive for the provider and slow for bandwidth constrained mobile users.
Re: Maplibre: community-driven Mapbox GL fork
#70I'm one of the folks behind the fork (and part of the initial steering committee). Happy to answer any questions!
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?
It's not perfect, but you can put counts of points in each cluster (maybe you have count = 5, A_count = 2, B_count = 3 which means that this particular cluster has 5 points total, 2 of which are A and 3 of which there are B). Then you can filter based on these attributes.
The obvious downside of this is that the cluster positions aren't accurate because they're based on points that are supposed to be hidden, but it's fast and doesn't require recalculating.