[pdal] About litree filter output: "PDAL: All points collinear"
Ulises Ibarra
ulisesmartinibarra at gmail.com
Tue Dec 27 19:28:08 PST 2022
Hi Jim:
Thank you very much for answering.
I thought that the origin of the problem was due to the fact that the
input.las file was made from the union of several files obtained by (TLS)
terrestrial scanning. I can't understand the concept of PointView, and I
imagined that the error was that there were many points where the
terrestrial scanner is located, but when making a large file made of small
files, that information was lost.
I did a test with a single file and got good results even though multiple
trees were considered under the same ClusterID. I subsampled the original
file with filters.sample.radios=0.020. And to this file I applied the
pipeline that I sent in my previous email with small modifications.
Processing time was around 24 hours.
In total I have 47 scans of that piece of rainforest. A question: What do
you think about the processing time of a large file that contains the 47
scans: Could it take 24 hours X 47 files = 1128 hours?
Regards
Ulises
El mié, 21 dic 2022 a las 1:01, Jim Klassen (<klassen.js at gmail.com>)
escribió:
> On 12/16/22 19:19, Ulises Ibarra wrote:
>
> Hello everyone:
> I have a question about the use of filters.litree. When I run:
>
> $ pdal pipeline ./litree_prueba.json
>
> where de ./litree_prueba.json:
>
> [
> "./input.las"
> {
> "type":"filters.hag_delaunay"
> },
> {
> "type":"filters.sort",
> "dimension":"HeightAboveGround",
> "order":"DESC"
> },
> {
> "type":"filters.litree",
> "min_points":50,
> "min_height":3.0,
> "radius":50.0
> },
> {
> "type":"writers.las",
> "filename":"./output.as",
> "minor_version":4,
> "extra_dims":"all"
> }
> ]
>
> I get de following output:
> "PDAL: All points collinear"
>
> And the file "output.las" was never created.
>
> Could you guide me on what I'm doing wrong, please?
>
> Thank you
>
> Ulises
>
>
> I've seen that error before when using hag_delaunay. It's complaining it
> can't make triangles (delaunay triangulation) because it thinks all of the
> input points fall on a line. I found that sometimes hag_nn will work in
> these situations. It has been awhile since I've hit that error (so I was
> using an older version of PDAL), it was sporadic (only occurred on some
> input tiles) and I didn't have time to track down the exact points that
> were causing it.
>
> I'm assuming (dangerous, I know) that PDAL is looking at some subset of
> close points when it is constructing the triangulation and that the error
> is stating that all points were collinear in one/some of those subsets
> rather than saying that the entire point cloud is collinear. However, if
> all of the source points are actually all collinear, then that would
> explain it.
>
> If I remember right, this tended to happen on messy (noisy), very dense
> (higher point density than reasonable given the precision of the
> measurements) point clouds where I suspect that it may have been possible
> for the point cloud to have areas where there were many points at the same
> or nearly the same X,Y,Z. Another possibility was the error being
> triggered by some odd (noise) points forming nonsensical geometries. But
> as I said, I never did have time to track down the root cause for sure.
> _______________________________________________
> 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/20221227/e19e3b2d/attachment.htm>
More information about the pdal
mailing list