Lonboard with tiled data

[kylebarron]

Lonboard is really powerful for rendering large-ish datasets but sometimes people have data that's just too large to send to the frontend. This can be large raster datasets (think Landsat and Sentinel) or large vector datasets (think Overture).

In manzt/anywidget#453 Trevor manz showed how it's possible to have the JS side request data from Python. This is different from all existing data transfer in lonboard, because existing methods push data from Python to JS rather than pulling data from JS.

This also has the potential to greatly simplify authentication because the frontend requests data via the Jupyter comm. If you have raster data on a remote server and you had a separate tile server running on that machine, you'd usually have to manage the firewall to expose the data. With lonboard, we can have an in process tile server as part of lonboard, so there's no authentication aside from setting up Jupyter.

A very bare prototype of the RPC can be found in #413.
The deck TileLayer has a getTileData callback. We can await the call to Python.

On the raster side, I think the simplest approach would be to add rio-tiler as an optional dependency and use it to generate PNG/JPG tiles. One question is whether we'd need to put rio-tiler in a threadpool so that each request doesn't block the Python kernel.

We could additionally port something like geojson-vt to export GeoArrow tiles. Then we could have a TileLayer that renders GeoArrow layers as sublayers. And then in theory we could handle truly any size of vector data.

cc @batpad @vincentsarago

[kylebarron]

We should test again with the new AbortSignal support: manzt/anywidget#540

[cboettig]

@kylebarron Do you see a role for PMTiles here? We've been very happy with PMTiles for leaflet-based maps (e.g. via folium-pmtiles, leafmap, rendered with maplibre) but from what I can tell it's not supported in deck.gl.

[kylebarron]

deck.gl supports any tiled data source, as long as you provide a callback for how to load each tile. So for a JS application using deck.gl, supporting PMTiles is not too hard.

The harder part is styling the data, especially depending on the trajectory of the data, and specifically whether data goes straight from server to browser or whether it passes through Python.

The part about pydeck that I dislike the most is that it featured a custom, hacky string domain-specific language for how to run JS code to style the input data. As I write in the internals doc, one of the main goals of lonboard is to support data scientists working with data already in Python. The map's styling could then be done in Python rather than in JS.

For comparison, folium-pmtiles, which uses protomaps-leaflet, looks like it implements the Mapbox Style Specification, so it has a way to apply a declarative JSON style to the data fully on the client.

This issue was originally focused on dynamically tiling data from Python to be sent to JS for visualization, but where the data already lived in Python, or at least was being proxied through Python. We could also implement a PMTiles proxy that would load tiles through Python, and give users the option of a callback to generate usual python layers

[cboettig]

Awesome, thanks! Definitely agree with the sentiments here, 💯 on supporting data scientists who are already in Python and would like to do styling from python and not JS. Like you say, this mostly works pretty well in folium-pmtiles because we can provide this information in JSON / dict format, though I could wish that the support for deriving styles from the data attributes was more pythonic than {"fill-color": ["get", "color"]) . otoh, that is easy to wrap around, and mapbox / maplibre styling is very flexible and well documented.