Point cloud tiler based on epf

[wonder-sk]

It would be useful to have a command for tiling of input data (using a fixed geographical square size, e.g. 1000 meters) based on untwine's epf code. Compared to pdal tile, it would run in parallel, and not running out of open files allowed by OS.

[hobu]

I like the idea of having a purpose-built tiler outside of PDAL. Having something here in Untwine would be quite useful and flexible and allow the same EPF code to be reused.

untwine-tiler inputdirectory/*.laz \
              outputdirectory 
              --options writer-options.json

writer-options.json

{
    "type":"writers.las",
     "forward":"all",
     "vlrs": [{
            "description": "A description under 32 bytes",
            "record_id": 42,
            "user_id": "hobu",
            "data": "dGhpcyBpcyBzb21lIHRleHQ="
            },
            {
            "description": "A description under 32 bytes",
            "record_id": 43,
            "user_id": "hobu",
            "filename": "path-to-my-file.input"
            },
            {
            "description": "A description under 32 bytes",
            "record_id": 44,
            "user_id": "hobu",
            "metadata": "metadata_keyname"
            }]
}

[abellgithub]

You'd have to say what you really want. If you stop the process at the end of the tiling step, you have exactly that...tiled points. But I'm assuming that you want LAZ files as output. You can certainly add a step that LAZ-ifies the data in each tile. But doing this as the process runs (rather than write raw data) is a deal because you'll end up with the same problem (too many files open) that pdal tile has unless you do a bunch of work to either create chunks or modify the writer (lazperf) to handle open/close. It's non-trivial unless you want to take the brain-dead approach. Not saying it's awful, either.

[wonder-sk]

I think the brain-dead approach of doing a second pass to LAZ-ify raw point data would be fine, at least for the initial implementation - and it could get optimized in the future if needed...