Hello,
I am facing with the issue that my application really slows down when i ovelay my rasterized data with a tile map on a linux machine. Just displaying the rasterized data without a tile map is fast as I presume it. When I run the same Application on my windows desktop as localhost it is smooth enough. Does anyone dealed with a problem like that as well? Maybe the precompute functionality ist not doing its job? I know without minimal example ist hard to say but maybe someone has an idea.
The linux/windows difference raises my suspicion.
Have you tried different browsers on each?
Could there be a problem with your graphics drivers?
I tried edge and firefox.
Hello,
some more information including minimal example.
I applied my approach on the Chesapeake and Delaware Bays dataset (source: https://s3.amazonaws.com/datashader-data/Chesapeake_and_Delaware_Bays.zip). As I described above the application runs smooth on localhost with rasterized data backed by tile service. As I start the same code on a virtual linux machine in the intranet it is not realy working. If I just run the data it is smooth and the wmts tiles alone can be zoomed fast as well. The Videos show the different perfomance.
import datashader as ds
import pandas as pd
from holoviews.operation.datashader import rasterize
import holoviews as hv
import param
import geoviews as gv
import panel as pn
hv.extension('bokeh')
class bay_test(param.Parameterized):
fpath = param.String('./data/Chesapeake_and_Delaware_Bays.3dm')
color_select = param.ObjectSelector(default='blues', objects=['viridis', 'greens', 'blues'])
def __init__(self, **params):
super().__init__(**params)
#self.base_dir = base_dir
self.get_raster()
@param.depends('fpath', watch=True)
def get_raster(self):
df = pd.read_csv(self.fpath, delim_whitespace=True, header=None, skiprows=1,
names=('row_type', 'cmp1', 'cmp2', 'cmp3', 'val'), index_col=1)
e3t = df[df['row_type'] == 'E3T'][['cmp1', 'cmp2', 'cmp3']].values.astype(int) - 1
nd = df[df['row_type'] == 'ND' ][['cmp1', 'cmp2', 'cmp3']].values.astype(float)
nd[:, 2] *= -1 # Make depth increasing
verts = pd.DataFrame(nd, columns=['x', 'y', 'z'])
tris = pd.DataFrame(e3t, columns=['v0', 'v1', 'v2'])
points = gv.operation.project_points(gv.Points(verts, vdims=['z']))
trimesh = hv.TriMesh((tris, points))
self.raster = rasterize(trimesh, aggregator=ds.mean('z'), precompute=True)
@param.depends('color_select')
def overlay_data_map(self):
return hv.element.tiles.EsriImagery()*self.raster.apply.opts(
framewise=True, xaxis=None, yaxis=None,
cmap=self.color_select, width=500, height=800)
@param.depends('color_select')
def overlay_data(self):
return self.raster.apply.opts(
framewise=True, xaxis=None, yaxis=None,
cmap=self.color_select, width=500, height=800)
Baytest = bay_test()
def layout():
Baytest = bay_test()
layout = pn.Column(Baytest.overlay_data_map, Baytest.param.color_select)
return layout
if __name__.startswith("bokeh"):
# commandline start with panel serve script.py
layout().servable()
if __name__ == "__main__":
# console start with python script.py
layout().show()
I start the server on command line running
panel serve bay_example.py --allow-websocket-origin=internalserveradress.de:5006
I think the bottleneck is the CPU utilization. If I only look at the data (without the background Tiles), the CPU utilization goes up to a maximum of 25%. In combination with the WMTS, the load is at 100%. What could be the reason for this?
On my Windows computer I can’t see a big difference between the two applications in terms of CPU usage.
I just add the output of lshw -c video
just in case someone knows about the configuration stuff:
*-display
description: VGA compatible controller
product: SVGA II Adapter
vendor: VMware
physical id: f
bus info: pci@0000:00:0f.0
logical name: /dev/fb0
version: 00
width: 32 bits
clock: 33MHz
capabilities: vga_controller bus_master cap_list rom fb
configuration: depth=32 driver=vmwgfx latency=64 resolution=1176,885
resources: irq:16 ioport:1070(size=16) memory:e8000000-efffffff memory:fe000000-fe7fffff memory:c0000-dffff
Update: Reinstalling packages did the job. I don’t know witch package caused the missbehave.