Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve mapserver clustering performance #5503
Though the current clustering algorithm implemented in mapserver is accurate, but it doesn't perform very well if large number of points should be clustered. Clustering 100k points may take several minutes to be completed and this may be inconvenient for an online application. Because of the stateless nature of the rendering we cannot preserve pre-processed information between the sessions (like the points in the quadtree) to increase performance.
It was a requirement to provide a more basic variation of the algorithm which provides a faster (but less accurate) result, where we don't expect to get the same result as soon as the order of the points from the source is changing. After some investigations the following approach would be sufficient for the purpose:
To switch on this appoach, the PROCESSING "CLUSTER_ALGORITHM=SIMPLE" should be used.
With this approach the real positions of the first clustered point is retrieved by default, average position is not calculated for the cluster. The average positions may have caused that some of the clusters fall within the specified distance eventually.
NOTE: The simplified algorithm will igore the FILTER parameter because it would have the same effect as setting the FILTER at layer level. This algorithm will support the GROUP parameter in the same way as with the FULL algorithm
added a commit
Oct 27, 2017
Would it be appropriate, for the sake of performance, to include a minimum threshold of display scale? For example, under the 1: 2000 scale, clustering stops. This could be an optional parameter and this would help to present correctly for superposed entities. Currently only the first clustered point gives its attributes to the symbolized point, the other does not have attributes.
@pelord Fixed an issue related to GetFeatureInfo for this new algorithm, probably this is what you mention at the second part. Regarding to the first part if this solution doesn't work, I think we should somehow trigger clustering only for specific classes, where the scale dependency can be set as usual.