[pdal] Troubleshooting GDAL writer and "Grid width out of range."

[Theo Hartsook]

Hi everyone,

I am having trouble figuring out where the problem is with a script I am
working on.

My goal is to rasterize a point cloud at different height ranges (i.e.
0-10m height above ground, 10.1-20m height above ground, etc.).

The point cloud stored HeightAboveGround to an extra dimension and I
confirmed that the values are correct by viewing in CloudCompare.

The steps I use are the following:

{'type':'readers.las', 'filename':input_las,
'extra_dims':'HeightAboveGround=float32'}
{'type':'filters.range', 'limits':'HeightAboveGround[0:10]'}
{'filename':band,'gdaldriver':'GTiff','output_type':'count','resolution':'1','type':'writers.gdal'}

This leads to a strange part. Mostly these steps work and produce rasters
that look how I expect at that height range. It has never failed on the
lowest height range, say 0-10m. However, on following height ranges, say
10-20m, I receive the following error:
"RuntimeError: writers.gdal: Grid width out of range."
I am not sure where in my process is triggering this error, since it works
on the prior height range. The range filter works at each height range,
even when the GDAL step fails. I confirmed this by writing the filtered
point clouds to disc instead of rasterizing them and viewing them in
CloudCompare.

I created another version of this same point cloud where the Z values were
replaced with HeightAboveGround using the ferry filter and then saved to
disc. When I change the range filter to select for Z instead of height
above ground, the raster step doesn't throw an error at any height range
and produces the results I expect. However, if I try to add these steps to
the pipeline when reading the original point cloud (read point cloud with
HeightAboveGround, ferry HeightAboveGround to Z, then range filter for Z
values), I still get the Grid width out of range error on the second height
range.

I tested one last thing. I wondered if there was some error with how my
script generated the height ranges. So I manually ran the filter at the
next increment (10-20m) and unfortunately still got the same error. This
scenario has me quite confused and I would appreciate any help and advice!
My best guess from my tests is that the problem lies with the GDAL step,
not prior.

Best regards,
Theo Hartsook
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20230127/40b241b2/attachment.htm>