[pdal] "resolution" keyword in

Connor Manning connor at hobu.co
Tue Apr 2 08:10:14 PDT 2019


If you specify a resolution of 50 to the EPT reader, the EPT reader will
determine a minimal octree depth such that this depth provides a precision
at *least* as precise as what you've specified.  Because EPT is an octree
structure with discrete precision steps, the returned precision will likely
be more precise than your request.  The nomenclature of the 'resolution'
option was lifted from the GDAL writer (
https://pdal.io/stages/writers.gdal.html#writers-gdal), where it represents
a spacing value - so a smaller value means *more* precision.

That means that for your request of resolution=50, the EPT reader is
selecting the minimum octree depth such that the octree cell width is less
than 50 units.

So your query will capture at least one point for every 50x50x50 unit
volume, if data exists in that volume.  I wouldn't say that this is
representative of that 50m^3 volume - only that you're guaranteed to have
at least one point from this volume if one exists.

If you run your pipeline with `--debug` you can see logs of the actual
resolution used for the query as well as the corresponding octree depth.

The resolution for each depth can be determined by the bounds (
https://entwine.io/entwine-point-tile.html#bounds) and the span (
https://entwine.io/entwine-point-tile.html#span).  At every subsequent
depth, the bounds are bisected into octants although the number of grid
cells remains constant, effectively doubling the precision in each spatial
dimension.

Hopefully this helps to clarify things.

- Connor

On Mon, Apr 1, 2019 at 7:51 AM Matt Beckley <beckley at unavco.org> wrote:

> Hi - thanks for the responses.  Basically, I'm trying to develop a
> workflow to calculate the number of points per class in a given ept
> dataset. My experience is that the `pdal info --stats` command will read
> all of the data into memory and will not work on large ept files (like the
> usgs lidar datasets).  Conor helped me out and suggested that I could use
> the "resolution" flag to estimate the number of points at a given level in
> the ept structure, and I've done that with a resolution = 50. So, for
> example, I have run a query like:
>
> pdal info --stats --filters.stats.dimensions=Classification
> --filters.stats.count=Classification ept://
> https://s3-us-west-2.amazonaws.com/usgs-lidar-public/USGS_LPC_MD_VA_Sandy_NCR_2014_LAS_2015 --readers.ept.resolution=50
> --readers.ept.threads=12
>
> I'm trying to understand if the counts I get per classification is
> representative of a 50 m^2 area?  It seems like from the documentation (and
> Jim's answer), that it is trying to take data at the octree level that is
> closest to the specified resolution.  So, is there a way I can "back out"
> the point totals per classification to get a representative count per
> classification for the entire dataset?  Is there a way to calculate what
> the actual returned resolution level is?  Currently I am just taking a
> ratio between total count of the entire dataset to returned count from the
> subset dataset using the "resolution" flag.  I then apply that ratio to the
> different class counts to get a rough estimate of points per classification
> for the entire dataset.  This is certainly not the best method as it will
> over-estimate some of the classification totals.
>
> Thanks for your help.
>
> matt.
> ---------------------------
> Matthew Beckley
> Data Engineer
> UNAVCO/OpenTopography
> beckley at unavco.org
> 303-381-7487
>
>
> On Mon, Mar 25, 2019 at 1:30 PM Andrew Bell <andrew.bell.ia at gmail.com>
> wrote:
>
>>
>>
>> On Mon, Mar 25, 2019 at 2:49 PM Matt Beckley <beckley at unavco.org> wrote:
>>
>>> Is there more information available regarding how the 'resolution'
>>> keyword works for the latest version of readers.ept?  Is it "gridding" the
>>> data at a specified cell size?
>>>
>>
>> The EPT format is essentially an octree of point data.  The resolution
>> options essentially tells the reader how far to descend the tree when
>> fetching data.
>>
>>
>>>   If so, how does it handle nominal class data such as lidar
>>> classifications?  Is it taking the first, last, or a random sample to
>>> assign as the classification for each cell(assuming a scenario where there
>>> are multiple classifications that fall within a given cell).  In other
>>> words, how is the defining classification assigned for each cell given a
>>> sample of points with varied classification values?
>>>
>>
>> The resolution option is unrelated to point classification, so I'm not
>> sure that I understand your question.  Perhaps you can provide some more
>> detail or an example.
>>
>> --
>> Andrew Bell
>> andrew.bell.ia at gmail.com
>>
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pdal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20190402/d395a7b2/attachment.html>


More information about the pdal mailing list