Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Epoch description support for 1.5 #129

Open
hobu opened this issue Apr 17, 2023 · 5 comments
Open

Epoch description support for 1.5 #129

hobu opened this issue Apr 17, 2023 · 5 comments
Milestone

Comments

@hobu
Copy link
Contributor

hobu commented Apr 17, 2023

What is the issue about?

Committee efforts

Issue description

As described in PDAL/PDAL#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

@hobu hobu added this to the v1.5 milestone Apr 17, 2023
@esilvia
Copy link
Member

esilvia commented Apr 18, 2023

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
Copy link
Contributor Author

hobu commented Apr 19, 2023

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
Copy link
Member

esilvia commented Apr 21, 2023

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 PDAL/PDAL#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
Copy link
Member

esilvia commented Sep 19, 2024

@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
Copy link
Member

esilvia commented Nov 22, 2024

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants