LoD (pyramid) support

[aleksandrmelnyk]

It would be very cool if queries would support generalisation.

[strk]

+1 -- simplest would be specifying a density. Extent and numpoints are in the header so density would quickly map to a fraction of points to skip.

[Remi-C]

Hey, as you may know I have worked a lot on LOD. There are several issues

• currently, even when you need one point, you have to retrieve all the patch (would be possible to avoid that with postgres toast mechanism, but would require dev. in the compressed case (dimensional)) I prototyped something at the C level to only return a part of the patch, I gained about 30% speed, because the slowness comes precisely because we have to read all the patch on disk.
• your patch may not have the same spacial extent (problem is worse in 3D than in 2D), thus your density definition is going to be difficult at best
• your patch may contain strongly spatially unbalanced point repartition (making the random picking gives wrong result)

My conclusion was that we need small dev to retrieve only a part of a patch on disk This dev is going to be little more difficult in the compressed patch case (which is, practically, not an option!). The difficulty comes from the fact that when a dimension is compressed, you don't know how much bytes to read to get only N points. (It varies depending on the compression and the actual values of the points). Nothing impossible, but too difficult for me.

In the meantime, you may use pure plpgsql function to emulate LOD : here : https://github.com/Remi-C/PPPP_utilities/tree/master/pointcloud In the file _rcexplode.sql, you get several functions for LOD :

• return only the N first points of a patch (ordered)
• return only N points taken randomly in the patch (random)
• return only N points with good 2D spatial repartition (random on grid)

You have a whole framework to perform octree ordering to guarantee good spatial repartition in 3D, but it is a little complicated to use. (here : https://github.com/Remi-C/LOD_ordering_for_patches_of_points). If you are interested I can send you the 8 pages papers explaining howo it works.

Cheers, Rémi-C

2015-06-25 10:53 GMT+02:00 Sandro Santilli notifications@github.com:

+1 -- simplest would be specifying a density. Extent and numpoints are in the header so density would quickly map to a fraction of points to skip.

— Reply to this email directly or view it on GitHub https://github.com/pgpointcloud/pointcloud/issues/87#issuecomment-115168554 .

[aleksandrmelnyk]

thanks guys, that looks quite promising, am gonna look into that rc_explode.sql.

Alex.