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
When we move the map the widgets (dataviews) data is requested again. Server side we calculate everything again, so if we have a formula widget with the count we do something like this for each request:
select count(1) from NODE_TABLE where the_geom_webmercator && USER_VIEWPORT_BBOX
this makes sense when we do the first data fetch but when the user moves the map a little bit (which is pretty common) we launch that query again even if the viewport only changes a little bit.
A possible optimization: instead of getting the count for the full USER_VIEWPORT_BBOX do the calculation for the diff between the last viewport and the new one so with basic math we could know the new count
This should work for all the widgets.
While I was thinking about this it reminded me of the WMS way to do things. WMS fetches the whole viewport image to render the map, then someone would likely thought the same thing about just calculating diffs and came up with the tiles solution (not a new idea, Slotted ALOHA was pretty successful splitting things in fixed steps). That probably means that if we have the right aggregations on tiles we would be able to calculate widgets update without hitting database.
EDIT: crossfilters.js, the library that does what our widgets to but in client side, use this technique. I'd recommend spending a little bit time on the source code (yes, arg), specifically things like this
The text was updated successfully, but these errors were encountered:
When we move the map the widgets (dataviews) data is requested again. Server side we calculate everything again, so if we have a formula widget with the count we do something like this for each request:
this makes sense when we do the first data fetch but when the user moves the map a little bit (which is pretty common) we launch that query again even if the viewport only changes a little bit.
A possible optimization: instead of getting the count for the full USER_VIEWPORT_BBOX do the calculation for the diff between the last viewport and the new one so with basic math we could know the new
count
This should work for all the widgets.
While I was thinking about this it reminded me of the WMS way to do things. WMS fetches the whole viewport image to render the map, then someone would likely thought the same thing about just calculating diffs and came up with the tiles solution (not a new idea, Slotted ALOHA was pretty successful splitting things in fixed steps). That probably means that if we have the right aggregations on tiles we would be able to calculate widgets update without hitting database.
EDIT: crossfilters.js, the library that does what our widgets to but in client side, use this technique. I'd recommend spending a little bit time on the source code (yes, arg), specifically things like this
The text was updated successfully, but these errors were encountered: