[pgpointcloud] Nature of patches

[Howard Butler]

Steve,

Instead of using the chipper, you could just start voxelizing the data until the maximum point count in any of the voxels is less than the patch size, and then store those voxels (plus their bounds).  PDAL has a filters.tiling that could do this in 2D. It could be adapted to do 3D, but it doesn't cut down the data to be less than the patch size. You'd have to come up with that yourself. Then you could query the cubes however you wanted.

There's nothing in pgpointcloud that requires you use the PDAL chipper to make your chips. You can do it however you want (write a entire file in there even). The chipper as currently implemented tries to balance three things:

1) Non-overlapping, 2D 
2) "squarish" in shape so as to not have tiny slivers that don't match typical query windows
3) Don't recurse to oblivion. Mostly full is good enough instead of paying the full cost for perfectly full.

Howard


On Jul 14, 2014, at 1:15 PM, Stephen Mather <stephen at smathermather.com> wrote:
> OK, yes, I could see how a 3D chip could be an issue. You start to throw away the efficiencies that you gain with chipping in the first place.
> 
> Would it make sense to implement some sort of sub-chip for a 3rd dimension? I'm thinking of use cases where I want to understand both the 2D spatial distribution and the vertical as a series of slices 2D slices.
> 
> https://smathermather.files.wordpress.com/2014/07/chipping.png
> 
> I'm thinking along the lines of chip in xy (or xz, or whatever) to a known number of points, but then have a sub-chips which further sub divide each xy chip into vertical components (pre-set or otherwise).
> 
> Best,
> Steve
> 
> 
> 
> 
> 
> On Mon, Jul 14, 2014 at 11:49 AM, Howard Butler <howard at hobu.co> wrote:
> 
> On Jul 10, 2014, at 9:21 PM, Stephen Mather <stephen at smathermather.com> wrote:
> 
> > Hi Howard,
> >
> > An octree as in a 3D octree? That could be very powerful, It would still arrange the points in a chip close to each other vertically, while allowing for vertical stratification.  I think I could definitely see uses for that.
> 
> The design of the chipper http://www.pdal.io/stages/filters.chipper.html is such that it allows the storage of point patches to be predictable and efficient. It is not necessarily what you want when you're doing searching operations, however.
> 
> An octree or quadtree allows for better and more natural searching, but the leaf nodes do not have predictable point counts. In the database world, this means that some of your rows are filled to 100% capacity, while others might only be 10% or 2%. Because the cost of a row is fixed, the database storage efficiency can be low.
> 
> >
> > 3D indexing is pretty good, I think, in the limited tests I've done with it. Makes me wonder what a 3D r-tree looks like, actually.
> >
> > "We could add some functionality to the chipper to allow you to set which dimensions you want to use as the X and Y. This would allow you to flip the orientation of the data as it is chipped."
> >
> > I understand the first sentence-- that would be brilliant. I'm not sure the meaning of second.
> 
> The idea would be to allow you to chip in different projections -- not just XY, but XZ, and YZ too.
>