[pgpointcloud] Nature of patches

[Stephen Mather]

Never mind:

--bounds arg                 Extent (in XYZ to clip output to)

Best,
Steve



On Mon, Jul 14, 2014 at 3:58 PM, Stephen Mather <stephen at smathermather.com>
wrote:

> 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/20140715/88aac412/attachment.html>