You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
👋 This is really cool and I've been a fan of both of your work for a long time!
I saw you added some geospatial support and I'm curious if there could be some benefits to integrations between our projects. I'm working on Lonboard, an interactive geospatial visualization library for Jupyter Notebooks built on (Geo)Arrow, Parquet, and deck.gl (which uses WebGL). Since both projects are very performant, I think they could be quite complementary. So for example, your taxi example is really nice, but it plots the data on a plain canvas. For many users being able to plot data on an interactive map with a basemap is really useful context.
To give an idea of the expected performance, here's 3 million points rendered from a GeoDataFrame in 3 seconds, including calculating a unique color and radius per point.
lonboard-fig1.mov
One potential area of collaboration is for cross filtering between spatial and non-spatial views, since it seems Mosaic really excels at this. Lonboard recently added support for GPU-based data filtering for numeric attributes. Geometries whose attributes are outside the selected ranges are not displayed. Here those same 3 million points (from internet speedtest data) are filtered based on download/upload speeds
Screen.Recording.2024-02-13.at.11.55.00.AM.mov
A natural integration would be through our jupyter APIs. When I looked at mosaic a few weeks ago I thought I saw that the selection state of the widget was passed back to Python as a SQL string, and I had been worried that I'd need to parse the SQL string to interpret ranges. Am I imagining that it used to be SQL-based? But with 0.6.0 it looks like widget.params now holds a dict possibly containing ranges?
So I'm thinking a compelling demo would be to set up a widget connection where expected behavior might be:
User selects filter in mosaic view
Mosaic's view updates based on filter
Mosaic propagates filter parameters to Python via widget
an observe handler sees the change in filter parameter and sets the filter on lonboard's map
lonboard's widget sends the new filter range to the frontend
deck.gl updates the map rendering based on that filter range
We'll have multiple copies of the data, but I think that's ok because mosaic seems quite integrated around duckdb and I'm blocked on duckdb integration pending duckdb/duckdb_spatial#153.
What do you think? Is this of any interest to you?
The text was updated successfully, but these errors were encountered:
👋 This is really cool and I've been a fan of both of your work for a long time!
I saw you added some geospatial support and I'm curious if there could be some benefits to integrations between our projects. I'm working on Lonboard, an interactive geospatial visualization library for Jupyter Notebooks built on (Geo)Arrow, Parquet, and deck.gl (which uses WebGL). Since both projects are very performant, I think they could be quite complementary. So for example, your taxi example is really nice, but it plots the data on a plain canvas. For many users being able to plot data on an interactive map with a basemap is really useful context.
To give an idea of the expected performance, here's 3 million points rendered from a GeoDataFrame in 3 seconds, including calculating a unique color and radius per point.
lonboard-fig1.mov
One potential area of collaboration is for cross filtering between spatial and non-spatial views, since it seems Mosaic really excels at this. Lonboard recently added support for GPU-based data filtering for numeric attributes. Geometries whose attributes are outside the selected ranges are not displayed. Here those same 3 million points (from internet speedtest data) are filtered based on download/upload speeds
Screen.Recording.2024-02-13.at.11.55.00.AM.mov
A natural integration would be through our jupyter APIs. When I looked at mosaic a few weeks ago I thought I saw that the selection state of the widget was passed back to Python as a SQL string, and I had been worried that I'd need to parse the SQL string to interpret ranges. Am I imagining that it used to be SQL-based? But with 0.6.0 it looks like
widget.params
now holds a dict possibly containing ranges?So I'm thinking a compelling demo would be to set up a widget connection where expected behavior might be:
observe
handler sees the change in filter parameter and sets the filter on lonboard's mapWe'll have multiple copies of the data, but I think that's ok because mosaic seems quite integrated around duckdb and I'm blocked on duckdb integration pending duckdb/duckdb_spatial#153.
What do you think? Is this of any interest to you?
The text was updated successfully, but these errors were encountered: