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
The point-based Deck.gl charts mainly read in lon/lat data format (3D Hexagon, Arc, Contour, Grid, Heatmap, Multiple Layers, Scatterplot and Screengrid).
The Deck.gl charts based on a wider panel of shapes - polygons, lines and points (Polygon, GeoJSON and Path) mainly read GeoJSON.
However, a large part of geospatial data users have a database that has its own geometric data format (a proper binary in the case of SAP HANA, Geopackage, PostgreSQL with PostGIS extension, SpatialLite...). This allows users to benefit from all the scope of SQL spatial queries made available by the database ("ST_" ...).
To display this data in the Deck.gl charts, you must create a new GeoJSON column, which increases the table’s weight, or create it on the fly via a view, which requires the DB server.
Since Superset includes Mapbox/MapLibre and this graphics library is hyper-optimized to read vector tiles, I wonder if it would be possible for Deck.gl charts to read the "vector tile" XYZ format. ( .pbf extension, encoded in MVT or MLT)?
Geospatial data users would then only have to install, next to the DB and Superset, a tile server (for exemple, Martin, Tegola, Pg_tileserv, Geoserver (with the Vector Tiles extension) or QGIS Server ...) to display in the Deck.gl chart their data stored in the geospatial database’s own format. Only one geometric data format is stored.
In addition to this, this would allow, in the case of a large number of geometries, a strong acceleration of the data display thanks to the spatial index of the DB and the tiling provided by the tile server.
It should be noted that the "cardiodiagram" chart already extends the formats displayable to WMS, WFS, and XYZ.
Is there any discussion on this subject among the developer community?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
The point-based Deck.gl charts mainly read in lon/lat data format (3D Hexagon, Arc, Contour, Grid, Heatmap, Multiple Layers, Scatterplot and Screengrid).
The Deck.gl charts based on a wider panel of shapes - polygons, lines and points (Polygon, GeoJSON and Path) mainly read GeoJSON.
However, a large part of geospatial data users have a database that has its own geometric data format (a proper binary in the case of SAP HANA, Geopackage, PostgreSQL with PostGIS extension, SpatialLite...). This allows users to benefit from all the scope of SQL spatial queries made available by the database ("ST_" ...).
To display this data in the Deck.gl charts, you must create a new GeoJSON column, which increases the table’s weight, or create it on the fly via a view, which requires the DB server.
Since Superset includes Mapbox/MapLibre and this graphics library is hyper-optimized to read vector tiles, I wonder if it would be possible for Deck.gl charts to read the "vector tile" XYZ format. ( .pbf extension, encoded in MVT or MLT)?
Geospatial data users would then only have to install, next to the DB and Superset, a tile server (for exemple, Martin, Tegola, Pg_tileserv, Geoserver (with the Vector Tiles extension) or QGIS Server ...) to display in the Deck.gl chart their data stored in the geospatial database’s own format. Only one geometric data format is stored.
In addition to this, this would allow, in the case of a large number of geometries, a strong acceleration of the data display thanks to the spatial index of the DB and the tiling provided by the tile server.
It should be noted that the "cardiodiagram" chart already extends the formats displayable to WMS, WFS, and XYZ.
Is there any discussion on this subject among the developer community?
All reactions