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
