Archived discussions · Captured October 28, 2026

Question on suitability of bokeh for real-time seismic data display

haunmaSep 11, 2018 #1

Hi,

I’m new to bokeh, and having a potential application in mind, I thought it would be wise to ask the experts if I can make it do what I need, before diving in any further.

I would like to build a web-based display for a seismometer. I’ve looked at Javascript solutions like D3 in the past, and found them not particularly well suited, and also not sufficiently performant. A rough sketch of the requirements:

– The plot style is stacked line graphs, what seismologists call a “helicorder” display after the old-style pen-and-drum recorders which traced data in one long spiral.

– Real-time data are provided at 30-Hz sampling rate from the server. All computation happens on the client (browser) side, with a data cache of the raw 30-Hz data from the server. Often the period of interest is 1-3 days, so the client side has to decimate (rate change) on the fly as needed to present a view spanning several million data points, without compromising pan/zoom performance. I.e. UI responsiveness for scrolling or zooming in time can’t be worse than ~ 1 second, and preferably better than that.

– The data have a high dynamic range (~ 120 dB), so amplitude zoom by a factor of a thousand is common and should not feel sluggish as all of the data points on-screen update.

– Display auto-updates every 30 seconds or so as new [current] data arrive from the server. Ok to draw progressively and only scroll when the plot reaches the right edge of the screen and starts a new line below.

Does this sound like something I could achieve with bokeh?

Thanks,

Mark

⌁ Link to post

Corey_O_MearaSep 11, 2018 #2

Hey man,

Your use case sounds similar to ours and we have been using bokeh successfully for it.

Our data rate is only 1 Hz but plots can be up to 10 years so we needed server side downsampling. We can also plot about 12,000 different time series sensors (not at the same time haha)

We essentially built a wrapper for bokeh using Django and bokeh stuff running in a “bokeh application” that is served via the bokeh server and use the “auto embed” JavaScript approach where the bokeh server initially provides some JS code which gets injected into our plot area on the webpage, then this code is executed client side and maintains a callback loop to always look at the ranges the user is currently zoomed at - depending on their window size and zoom range , we inject new time series data to the plot (replace the column data source). It’s fast and unnoticeable that they’re looking at new data.

The tricky part is getting our bokeh app to query our database (Apache Cassandra ) and then performing on the fly resampling at different time intervals. Maybe for you, you can store these pre-sampled intervals but for us we cannot so that calculation takes time.

Here’s a screen shot btw: https://twitter.com/cpomeara/status/1001352604859936773?s=12

···

On Sep 11, 2018, at 4:51 AM, haunma@gmail.com wrote:

Hi,

I’m new to bokeh, and having a potential application in mind, I thought it would be wise to ask the experts if I can make it do what I need, before diving in any further.

I would like to build a web-based display for a seismometer. I’ve looked at Javascript solutions like D3 in the past, and found them not particularly well suited, and also not sufficiently performant. A rough sketch of the requirements:

– The plot style is stacked line graphs, what seismologists call a “helicorder” display after the old-style pen-and-drum recorders which traced data in one long spiral.

– Real-time data are provided at 30-Hz sampling rate from the server. All computation happens on the client (browser) side, with a data cache of the raw 30-Hz data from the server. Often the period of interest is 1-3 days, so the client side has to decimate (rate change) on the fly as needed to present a view spanning several million data points, without compromising pan/zoom performance. I.e. UI responsiveness for scrolling or zooming in time can’t be worse than ~ 1 second, and preferably better than that.

– The data have a high dynamic range (~ 120 dB), so amplitude zoom by a factor of a thousand is common and should not feel sluggish as all of the data points on-screen update.

– Display auto-updates every 30 seconds or so as new [current] data arrive from the server. Ok to draw progressively and only scroll when the plot reaches the right edge of the screen and starts a new line below.

Does this sound like something I could achieve with bokeh?

Thanks,

Mark

–

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+unsubscribe@continuum.io.

To post to this group, send email to bokeh@continuum.io.

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/eda13af3-f187-466d-b154-d8a2f8fead5f%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

⌁ Link to post

James_A_BednarSep 12, 2018 #3

This sounds like a job for Datashader, which has a nice Bokeh interface provided by HoloViews. I.e., Bokeh handles the plotting in browser and the user interaction, Python handles the big data structures, and Datashader converts the data into an image-like representation that Bokeh can easily display in the browser. Check out datashader.org and holoviews.org.

···

On Monday, September 10, 2018 at 10:59:50 PM UTC-4, Mark H wrote:

Hi,

I’m new to bokeh, and having a potential application in mind, I thought it would be wise to ask the experts if I can make it do what I need, before diving in any further.

I would like to build a web-based display for a seismometer. I’ve looked at Javascript solutions like D3 in the past, and found them not particularly well suited, and also not sufficiently performant. A rough sketch of the requirements:

– The plot style is stacked line graphs, what seismologists call a “helicorder” display after the old-style pen-and-drum recorders which traced data in one long spiral.

– Real-time data are provided at 30-Hz sampling rate from the server. All computation happens on the client (browser) side, with a data cache of the raw 30-Hz data from the server. Often the period of interest is 1-3 days, so the client side has to decimate (rate change) on the fly as needed to present a view spanning several million data points, without compromising pan/zoom performance. I.e. UI responsiveness for scrolling or zooming in time can’t be worse than ~ 1 second, and preferably better than that.

– The data have a high dynamic range (~ 120 dB), so amplitude zoom by a factor of a thousand is common and should not feel sluggish as all of the data points on-screen update.

– Display auto-updates every 30 seconds or so as new [current] data arrive from the server. Ok to draw progressively and only scroll when the plot reaches the right edge of the screen and starts a new line below.

Does this sound like something I could achieve with bokeh?

Thanks,

Mark

⌁ Link to post

systemJul 21, 2021 #4

⌁ Link to post

End of archived discussion · Replies are disabled