[pgpointcloud] Nature of patches

[Stephen Mather]

I could pre-chip into strata (1-10 meters, 10-20, etc.) and then from there
pipe that through the existing 2D chipper. That would be adequate, I think,
for my needs.

Ok, where do I start in the code tree... ?


On Mon, Jul 14, 2014 at 2:51 PM, Howard Butler <howard at hobu.co> wrote:

> 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.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgpointcloud/attachments/20140714/f16df904/attachment.html>