ASPRSorg / LAS

LAS Specification
https://www.asprs.org/committee-general/laser-las-file-format-exchange-activities.html
154 stars 17 forks source link

Epoch description support for 1.5 #129

Open hobu opened 1 year ago

hobu commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

esilvia commented 2 months ago

@hobu noted in today's (9/19/2024) LWG call that the most recent WKTv2 drafts (currently unratified) include the EPOCH designation, which would be redundant with this new VLR and potentially conflicting. The most recent versions of PROJ already support this.

Consensus at the moment seems to be that this VLR is not needed and could potentially cause more trouble, but referencing a wiki that calls out the desire to use EPOCH in the spec, among other hints toward a high quality CRS.

esilvia commented 2 days ago

Significant work was completed on #144 during today's meeting. We ended up including this VLR as optional, but are open to removing it. The PR appears to be ready to merge. Last call for comments!