Vector Tiles

[pjcozzi]

2D maps like Google, Apple, MapBox GL, and OL3 are moving to actual vectors for rendering vector data, instead of baking vector data into a raster tile. This allows, for example, to make labels always face up even if south is up and to fade out labels so they never hit each other.

For now, this roadmap is a collection of resources on this topic.

• Google Maps + WebGL = MapsGL
• Vector tiles for fast custom maps (video)
• Videos from FOSS4G
• Mapbox Vector Tile Specification
  • blog post
  • tools: vector-tile-js and mapnik-vector-tile
  • Client-side: pbf.js to decode tiles (protocol buffers).
• geojson-vt
• MMT-Vector-Tiles

[sanjeetsuhag]

@davenquinn Given the heavy dependency on maplibre-gl, I agree that it may be better to keep this as a separate module to start. I took a look at the cesium-vector-provider repo and the associated fork of maplibre-gl, and it seems like the heavy lifting is done in the BasicRenderer in maplibre-gl, with cesium-vector-provider mostly being an API to call through to query for images and features. I have a few questions so far:

• In the README, it says "It'd be nice to align the approaches used here with Cesium's first-party 3D Tiles stack". Is this referring to the caching system? I know that there is a caching system implemented on the renderer side, is there a need for one on the provider side?
• I noticed that in some areas there is reference to a light source in the shading, would it be possible to account for the position of the sun in Cesium?
• Regarding performance, is the rendering done in workers on an offscreen canvas?
• What is the state of metadata support right now? Is there any limitation to users being able to pick features?

[davenquinn]

Hi @sanjeetsuhag thanks for the questions.

The current structure of the code (the fork of maplibre-gl with the BasicRenderer sidecar) is mostly due to my having not figured out how to compile and reference the shaders that Mapbox GL uses independently of their build pipeline. Much of the BasicRenderer code may more properly belong in cesium-vector-provider but I think once the approach is solidified, it might be possible to build a small number of necessary hooks into Maplibre and contribute them to the core project. https://github.com/maplibre/maplibre-gl-js/issues/166 demonstrates that the team there is amenable to making some APIs public to serve deep integrations, which would be the ideal long-term approach.

• By "aligning with 3D Tiles" I was thinking mostly about taking cues from where in the Cesium rendering stack 3D tiles are handled. I'm not really that familiar with Cesium's internal APIs and right now everything is done in single tiles.
• I believe rendering is right now being done in worker threads, because offscreen canvas is not supported everywhere
• Metadata support and basic filtering have been carried over from @kikitte's work, but not validated. Making this work is on the roadmap, but basic rendering + labels are I think a somewhat higher priority. The goal would be to have it work somewhat similarly to how Maplibre filtering works within their stack.

Additional points:

1. One big item that might have some influence on the "right" way to hook into Cesium is labeling. Labels clearly must be viewport-aligned and span tile boundaries. Figuring how to integrate these layers with Cesium's renderer might be difficult and is something I just haven't tackled yet.
2. I'm happy to discuss moving or changing the ownership of davenquinn/cesium-vector-provider if this is something that would help centralize specific work on this in the right space.

[davenquinn]

I will also note that one of the potential improvements to rendering will be if we can directly render into Cesium-managed canvas contexts rather than creating our own, serializing as images, and exposing in a tile provider.

This feels like a lot of hoops to jump through and is purely a function of my and previous folks’ unfamiliarity with Cesium’s internals.

[nf-s]

A light-weight alternative to mapbox-gl/maplibre-gl is https://github.com/protomaps/protomaps.js - it supports MVT and a subset of mapbox style spec.

We have been using it in TerriaJS for nearly a year - and it works quite well.

https://github.com/TerriaJS/terriajs/blob/main/lib/Map/ImageryProvider/ProtomapsImageryProvider.ts

[davenquinn]

I will also note that one of the potential improvements to rendering will be if we can directly render into Cesium-managed canvas contexts rather than creating our own, serializing as images, and exposing in a tile provider.

This feels like a lot of hoops to jump through and is purely a function of my and previous folks’ unfamiliarity with Cesium’s internals. On May 13, 2022, 11:17 AM -0400, Daven Quinn @.***>, wrote:

Hi @sanjeetsuhag thanks for the questions. The current structure of the code (the fork of maplibre-gl with the BasicRenderer sidecar) is mostly due to my having not figured out how to compile and reference the shaders that Mapbox GL uses independently of their build pipeline. Much of the BasicRenderer code may more properly belong in cesium-vector-provider but I think once the approach is solidified, it might be possible to build a small number of necessary hooks into Maplibre and contribute them to the core project. maplibre/maplibre-gl-js#166 demonstrates that the team there is amenable to making some APIs public to serve deep integrations, which would be the ideal long-term approach.

• By "aligning with 3D Tiles" I was thinking mostly about taking cues from where in the Cesium rendering stack 3D tiles are handled. I'm not really that familiar with Cesium's internal APIs and right now everything is done in single tiles. • I believe rendering is right now being done in worker threads, because offscreen canvas is not supported everywhere • Metadata support and basic filtering have been carried over from @kikitte's work, but not validated. Making this work is on the roadmap, but basic rendering + labels are I think a somewhat higher priority. The goal would be to have it work somewhat similarly to how Maplibre filtering works within their stack.

Additional points:

1. One big item that might have some influence on the "right" way to hook into Cesium is labeling. Labels clearly must be viewport-aligned and span tile boundaries. Figuring how to integrate these layers with Cesium's renderer might be difficult and is something I just haven't tackled yet.
2. I'm happy to discuss moving or changing the ownership of davenquinn/cesium-vector-provider if this is something that would help centralize specific work on this in the right space.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[gberaudo]

For information, MapLibre is building their roadmap and calling for popular vote. There is a proposition for a minimal build which may align with your needs @davenquinn. See https://github.com/maplibre/maplibre/discussions/159 / https://maplibre.org/news/2023-03-13-second-call-for-bounties/

[puzonevan]

@davenquinn Any updated progress on the module?

[markchagers]

We really look forward to vector tile (PBF) support for cesium. The newer ESRI services use this format, and currently cannot be used in cesiumjs. This is a much needed enhancement.