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
Besides the_geom, the_geom_webmercator(?), cartodb_id, the set should include any involved in interactivity, and any involved in styling.
I think the only column needed is the geodataframe geometry column.
To get styling variables, something of the form could be useful:
When the geodataframe is sent to the JS environment, we do gdf.to_json() to get the full geojson. What happens most of the time is that the user only needs a subset of the data: geometry, columns used in styling/widgets/popups.
What could probably be a performance gain is that if we could figure out how to select only the columns needed for sending to the JS environment:
This is the behavior when VL loads data from a CARTO dataset, but this can only be applied when there is a Maps API instantiation. So I like your proposal of filtering the geodataframe before passing it to the visualization. We could potentially save a lot of memory size!
I'm not sure about the implementation, but I'll definitely check this for the 1.0.
Besidesthe_geom
,the_geom_webmercator
(?),cartodb_id
, the set should include any involved in interactivity, and any involved in styling.I think the only column needed is the geodataframe
geometry
column.To get styling variables, something of the form could be useful:
The text was updated successfully, but these errors were encountered: