Epoch description support for 1.5

[hobu]

What is the issue about?

Committee efforts

Issue description

As described in https://github.com/PDAL/PDAL/issues/3995, there is a need for data to advertise the coordinate epoch. I propose we implement an optional VLR with the user/id of LASF_Projection:1970. More information about coordinate epochs and how to write them (there is a standard form that is a floating point number) can be found at https://gdal.org/user/coordinate_epoch.html#coordinate-epoch

[esilvia]

Why is another VLR needed just for epoch? I would have thought Epoch information would have been a mandatory inclusion for WKTv2 and therefore part of the CRS definition itself. Is it not?

[hobu]

Epoch support wasn't added to WKT until recently. https://docs.ogc.org/is/18-010r7/18-010r7.html#130, which is called WKT:2019 in GDAL-speak and supports epoch information.

We could require only WKT:2019 or later for epoch support. That said, it would be nice to be able to go back and add eVLRs to old data that define the epoch rather than having the silly LBS recommendation to put it in the datum title (that causes breakage everywhere).

[esilvia]

Thanks for clarifying! Since NATRF2022 and its epoch-based design is a motivator for LAS 1.5 in the first place, I think it certainly makes sense for us to include WKT:2019 as a core feature.

If we do this, it would be confusing to also include an optional VLR in the LAS 1.5 definition. We'd likely end up with files that do both. We could, however, put it in the VLR wiki: https://github.com/ASPRSorg/LAS/wiki/User-Contributed-VLRs

The proposal in https://github.com/PDAL/PDAL/issues/3995 makes sense to me. I've seen this done in other software; however, one must be careful about double-applying transformations when there's an implicit epoch transformation bundled into the standard datum transformations, such as between realizations of NAD83. It's always messy.