Background: The application is a web map application with a LeafletJS front-end and NodeJS back-end with Postgres database. The application is to be used on both desktops and smartphones/ tablets in the field. The map should visualise ~30K polygons whose number grows by ~3k per year. The data set has insertions and deletions less than once every 12 hours but has queries constantly. At all zooms, a representation of the entire spatial data set should be available. At lower zooms a cluster or heatmap representation is ideal. At high zooms the individual polygons should be visible. The main issue is that the data set count represented by clustering must also be filterable by a finite number of sets each with finite number of options membership (year, type of survey etc.)
A naive implementation would be to calculate the centre/ centroid/ pole-of-inaccessibility of each polygon along with its set options and send these to a standard Leaflet clustering library on the client side to visualise when below a threshold zoom level, and to send the polygons themselves when above a zoom level. The client-controlled filter would iterate through each layer in the cluster or polygon set.
It seems to me that a better cluster would be to build a R-Tree server-side and at each node level include the total child count, then on the client-side each cluster is represented as this child count at the centre of its node's bounding box. Above the threshold zoom, polygons for that area are also stored in a client-side R-Tree to avoid querying the database for areas that have been traversed more than once.
(A) Is this a sensible data structure and method of representing clusters?
(B) How can it be extended to compute child count of subsets at different levels of zoom, such as calculating the count of every exclusive set at each level? (eg: count of elements in years x1 to x2 and survey type a,b,c, not d)