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
Some time ago, we made a first attempt at coding a widget for the interactive visualization of the time series in javascript, with the ability to zoom in and out. We tested two approaches:
Our first widget pulled the entire time series from the database to the client side, and then vizualised the relevant time window on the client. This had the advantage that data had to be pulled in only once, and that zooming was quick (as the data was already at the client side). The disadvantage was that potentially a very large time series was pulled in (if the time series is long) and not all of it is needed (if the client never zooms out to the full time series). Some clients even struggled to keep the full time series in their memory.
In a second attempt, the client only requests the time slice that is visualised. This is quicker, but requires a request to the database for every zoom-out action. This can slow down the user experience. However, we mitigated this by making use of the aggregated (hourly, daily) data in the database. The widget calculated the resolution of the time series based on the size of the viewport (number of pixels) and select the coarsest time series needed to visualize. For example, if the visualization zoomed to 2 years of data, and the viewport is 600 pixels wide, then the daily data (730 data points) is perfectly fine. This method worked really well, as the amount of data transferred and processed per zoom action was minimized.
There are many such visualization widgets nowadays, and they may already have smart was to do this, but I thought I would document here in case it is still of relevance.
Some time ago, we made a first attempt at coding a widget for the interactive visualization of the time series in javascript, with the ability to zoom in and out. We tested two approaches:
Our first widget pulled the entire time series from the database to the client side, and then vizualised the relevant time window on the client. This had the advantage that data had to be pulled in only once, and that zooming was quick (as the data was already at the client side). The disadvantage was that potentially a very large time series was pulled in (if the time series is long) and not all of it is needed (if the client never zooms out to the full time series). Some clients even struggled to keep the full time series in their memory.
In a second attempt, the client only requests the time slice that is visualised. This is quicker, but requires a request to the database for every zoom-out action. This can slow down the user experience. However, we mitigated this by making use of the aggregated (hourly, daily) data in the database. The widget calculated the resolution of the time series based on the size of the viewport (number of pixels) and select the coarsest time series needed to visualize. For example, if the visualization zoomed to 2 years of data, and the viewport is 600 pixels wide, then the daily data (730 data points) is perfectly fine. This method worked really well, as the amount of data transferred and processed per zoom action was minimized.
There are many such visualization widgets nowadays, and they may already have smart was to do this, but I thought I would document here in case it is still of relevance.
Originally posted by @ICHydro in #209
The text was updated successfully, but these errors were encountered: