[pdal] How to get the metadata of a file?

[Jim Klassen]

On 9/14/20 6:39 AM, Andrew Bell wrote:
>
> On Mon, Sep 14, 2020 at 5:02 AM Peder Axensten <Peder.Axensten at slu.se <mailto:Peder.Axensten at slu.se>> wrote:
>
>     Pity.
>
>     I see that the present users’ domain doesn’t seem to have a need for bounding box header information. I believe that users in other domains do – possibly few and small domains, but who knows? To me it still seems an arbitrary limitation and your arguments have not convinced me.
>
>
> PDAL has been around for about six years and this hasn't come up, so I think this is a pretty unique ask. We calculate the bounding area all the time with the existing code and it works fine. The time it takes is dwarfed by the time it takes to read the file itself, with no other processing in place.
>
>     But it’s your prerogative.
>
>
> Actually, no. The code is there for you to do as you wish. The data you want is there, you just have to write a bit of code to fetch it.
>
>     I’ll ponder what the most viable option is for us: status quo with liblas, use pdal for reading only, or make a pdal filter/writer and use some workaround in our process chain. I will probably come back for more advice... :-)
>
>
> If what you want is just to read a LAS file into memory, then there's no reason not to use liblas if it meets your requirements.
>
> Best,
>
> -- 
> Andrew Bell
> andrew.bell.ia at gmail.com <mailto:andrew.bell.ia at gmail.com>
>

In my work we regularly work from a "tileindex" (which in this case is an index of the the desired output tiles rather than calculated from existing files).  We then use OGR within python to iterate over the features in the tile index and use that to override parameters in the pipeline like "readers.tindex.bounds" (or "readers.ept.bounds"), "writers.gdal.bounds", "writers.gdal.filename", etc.  Then each tile is submitted to a job queue which lets us process the tiles in parallel.

In our case the source is generally LAZ tiles, but relying on the LAZ header for the bounding box would still present issues for us. First, we generally set "readers.tindex.bounds" to be slightly larger than "writers.gdal.bounds" to avoid edge artifacts in the output tiles.  Second, in our case the LAZ tiles are more-or-less but not exactly grid aligned so using a tile bounding box would produce no-data areas in the output tiles.  (And this is after we had PDAL re-write all the LAZ tiles which along with doing other pre-processing and data cleanup, had the effect of correcting the bounding box information in the header which was all over the place as delivered).

So for us, we've found it more useful to move the tile bounding box identification a level above PDAL in our workflow.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20200915/2a5432ce/attachment.html>