Add an option to write PDAL's entire JSON metadata tree to LAS VLR(s)

[hobu]

There are situations where it would be helpful to be able to track how a file was created in a more detailed way than simply the software_id and system_id in an LAS file.

I would like to add a pdal_metadata option to writers.las that writes a JSON metadata object serialization of the PDAL metadata into a VLR (has to fit in 64k) or EVLR. pdal info can simply barf this back to users as raw JSON because it knows how to interpret it.

[kbevers]

I like this. What would be included in this JSON metadata? The generating pipeline? Version of PDAL?

[hobu]

What would be included in this JSON metadata? The generating pipeline? Version of PDAL?

Yes, the equivalent of pdal info --metadata along with all per-stage metadata of the pipeline.

[msmitherdc]

Is connection info part of the per stage metadata? If so, that would have to be removed

[hobu]

Is connection info part of the per stage metadata?

Yes.

If so, that would have to be removed

Maybe we will need a way to hide sensitive entries then.

[kbevers]

Yes, the equivalent of pdal info --metadata along with all per-stage metadata of the pipeline.

Only the stuff that is not already in the LAS file, right?

[hobu]

Only the stuff that is not already in the LAS file, right?

My default implementation will just copy it all in. Seems like extra work to keep it out, and maybe there's a discrepancy and you care about that later down the line :)

[msmitherdc]

i would agree on keeping in all metadata even if redundant

[kbevers]

I can't see the point of repeating information. As far as I can see the only thing from the pdal info --metadata output that is not already in the file is the version number of PDAL. Other metadata, like the pipeline, I find interesting though. Just my two cents :)

[hobu]

What if the pipeline that created it is a merge of a bunch of files? One can imagine a number of scenarios where you sometimes do and sometimes don't want everything. Much simpler to not care 😄

[kbevers]

That's a valid point. I hadn't considered that. You'll probably run into the 64kb limit quite easily though!

[hobu]

You'll probably run into the 64kb limit quite easily

Yes. We can split stuff and cat them together or write an EVLR. I'm not sure what to do.

[kbevers]

You could just write a VLR with info for each parent file that is used to create the file in question. That would be easy and very generic in terms of implementation.

[hobu]

a VLR with info for each parent file

They can nest in arbitrary ways. It will be better to just dump it as is, and then if anyone needs to go back through 1000s of files to figure something out, they can write a little program or regex to pluck out what they need.

[hobu]

Implemented in #1525