The third line above takes 1.15s to display just a few hundred polygons.
I ran just the last line under a profiler and found that 80% of time takes place in the shapely coords.xy call.
This issue is known in shapely with no workaround.
if i want to avoid having to call this, can i precompute from the geometry into a dataframe columns for Polygons so that holoviews/geoviews/geopandas does not call this on the fly?
@philippjfr Once I have the view displayed, I would like to update the ‘data’ dimension values and update the choropleth map displayed with those new data values. Currently, I create a view everytime as you have above and display it.
Is there a more efficient way to just update the colors of the polygons without having to redraw them everytime?
@philippjfr I hacked the performance for the ‘bokeh’ renderer by obtaining the handle to the rendered view
rendered_view=hv.render(view)
renderer=rendered_view.renderers[0]
target = show(rendered_view, notebook_handle=True)
# update renderer source data with the new values
# (xs and ys have not changed) i.e. polygon shapes
renderer.data_source.data['data']=dflines['data'].values
push_notebook(handle=target)
The above code renders the update view more than an order of magnitude faster 50ms vs 900ms
Is there a way to do this in holoviews ? or do I have to let this be renderer specific ?
Also this is a usecase that could help with datashade renderers performance as well, esp for meshes that are static, i.e. the points/polygons not changing, only color changes due to data mapping.
The above code renders the update view more than an order of magnitude faster 50ms vs 900ms
If you’re modifying the same underlying datastructure HoloViews should optimize this automatically. Basically the optimization works by checking whether the elements .data has the same id, e.g. in this example you’ll see that updates are pretty quick but if you were to make a copy of poly_data it’ll be about an order of magnitude slower:
That said we could perhaps consider some mechanism by which you can explicitly declare which columns in the dataframe to update.
This seems very unlikely to me, datashader will still have to iterate over the entire data to aggregate the values so I don’t see much scope to optimize here. Where there is scope for that kind of optimization is trimesh rendering because the datastructure is converted to one that datashader can iterate over easily, which is quite expensive.
Huh, yes you’re right. When I tried it the first time it was significantly faster, but if I try it now it’s definitely slower. Will have to look at that properly.