Hi, Thanks for explaining this.
I think it would be very cool to have such clustering available in QGIS. >From time to time the questions comes up - and other GIS have this available (e.g. OpenLayers, UMN - see http://mapserver.org/mapfile/cluster.html) Around 10-12 years ago. I did a clustering webmap-app with Postgis and SVG. The use case was for a geology company who has around 20k reports in all of Switzerland - although with a focus on the german part of Switzerland. For small map scales we wanted to display clustered symbols, as we zoom in we wanted to display single points eventually at a large scale. In between we had threshold values of different cluster sizes. But I agree with you that a notion of pixels would be better than fixed map units for that purpose. In our webmap-app we had differents symbols for clusters (red, bigger squares) vs. single points where no clustering was made because (blue smaller rectangles). The clustered symbols also varied in size based on the number of features the cluster contains - see http://www.carto.net/neumann/temp/bis_berichte.jpg as an example and http://www.carto.net/neumann/temp/berichte.jpg for a zoomed in view. I think however, from the usage, UI and preferences point of view the options for the point displacement renderer are quite different from the point clustering. For the clustering you want to be able to have different sizes and shapes for clustered vs. single point symbols. You want to be able to label the cluster symbol with the number of features it contains. You want to be able to vary/classify the point symbol based on the nr of features the cluster contains. For the identify tool it would still be good to see the whole list of the cluster. Would be interesting to see if someone could work on this and if someone could fund the work. We would certainly be interested in the feature but have other priorities for our funding. Thanks, Andreas Am 24.01.2014 09:48, schrieb Andreas Neumann: > Hi Martin, > > So you think the same code of the point displacement renderer can also > be used for clustering? > > It was developed exactly for the opposite: if multiple geometries are on > top of each other they are displaced so you can see all of the points. A > use-case is where several people live at the same address but have > different attributes and you want to see them all. > > I am a bit surprised that the same code could be used for the opposite - > to cluster points that are not at the same position. Wouldn't it require > some additional code/work to do that? > > Just wondering. > > Andreas > > Am 24.01.2014 09:29, schrieb Martin Dobias: >> Hi Tim >> >> On Fri, Jan 24, 2014 at 2:31 PM, Tim Sutton <[email protected]> wrote: >>> On Fri, Jan 24, 2014 at 1:12 AM, A Huarte <[email protected]> wrote: >>>> >>>> Hi! >>>> >>>> About simplification (no clustering), I think that the If we discard >>>> points based on the distance to the last fetched and rendered point >>>> (https://github.com/qgis/QGIS/blob/master/src/core/qgsfeatureiterator.cpp#L36) >>>> it will be very effective to render big dense points layers. I have a GIS >>>> application using this technique and it draws LAS files (> 30mb) "fast". >>>> >>>> I would like write a "point simplifier" in QGIS to validate results. >>>> Do you agree ? >>> >>> >>> I think this would be great. Since you are doing a full scan of the dataset, >>> you should be able to count how many points each aggregate point represents >>> right? I was thinking we could pass that the the renderer as a 'virtual' >>> attribute so that we can use it to e.g. scale the symbol size. >>> >>> +1 from me to implement this anyway as a new cluster renderer (or a patch >>> the point displacement renderer if that seems workable). >> >> Actually in the threading branch I have significantly reworked the way >> how the clustering is done in the point displacement renderer. A quick >> test with ~75K points shows that QGIS 2.0 takes ~10 minutes to render >> with point displacement, while in threading branch it is matter of a >> second or two. In the threading branch the renderer uses spatial index >> for clustering. Another optimization could be to build the spatial >> index for a layer just once, for even better performance. >> >> So I believe now it's mainly a matter of adding more configuration >> options.to allow output similar to "usual" marker clustering - and >> make such options default. >> >> I would prefer not to have "point simplifier" somewhere in the data >> access API - like Tim suggests, it is best to keep such functionality >> in a renderer. >> >> Regards >> Martin >> _______________________________________________ >> Qgis-developer mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer > _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
