Implement OGC WKTv2 (or later) as the coordinate system definition

[hobu]

OGC WKTv2 is the follow-on standard of the well-known text coordinate description grammar that LAS 1.4 uses. The WKTv1 (actually GDAL-dialect WKT) that LAS 1.4 uses is deficient in a number of situations:

• No support for description of dynamic coordinate systems.
• Weak 3D CRS description capabilities (aren't we doing 3D stuff here? 😄 )
• Future proofing to eliminate the need to increment the LAS specification.

Dynamic Coordinate System Support

The most pressing need for WKTv2 support is the now-delayed upcoming NATRF2022 effort by NOAA NGS for US-based geodesy. Other geodetic organizations around the world such as LINZ in New Zealand are also putting out time-based deformation models. As the world moves to space-based, time-aware geodesy, the software systems describing data must also be able to describe where and when the data are referenced. WKT used by LAS 1.4 does not do a sufficient job.

Weak 3D CRS description capabilities of WKTv1

A specific case of the insufficiency of WKTv1 that LAS 1.4 uses is evident in the USGS LiDAR Base Specification (LBS). It states:

The geoid name shall be appended to the VERT_CS[] name field. For example: VERT_CS[“NAVD88 height (ftUS) - Geoid12b”

This attempt to inject the geoid's epoch (Geoid12b) in the VERT_CS entity name causes the VERT_CS's entity name to be invalidly specified WKT. WKT parsers such as PROJ have been updated to account for mis-specification, but this prescription does not follow specification and would not succeed in a strictly compliant parser.

The way to handle this in WKTv2 is to use the GEOIDMODEL node. See https://gist.github.com/hobu/e6f218bba7fda414694c2272f7e4353d for an example WKTv2 of NAD 83, UTM Zone 15, GEOID12A, vertical units ft. (use 5703 instead of 8228 for the vertical if you want meters).

Future proofing

The LAS 1.5 specification should declare the WKT specification version using OGC version names. For OGC WKTv1, which wasn't technically ratified at the time LAS 1.4 was put forward, the name would be 01-009. For OGC WKTv2, it would be 18-010r7. It is not expected that WKT will be rapidly evolving, but there is a chance there will be a WKTv3. Rather than wait until that event and require an LAS increment, let's defer to any later OGC WKT specification.

[kjwaters]

Howard, I'm in support of this suggestion. However, I don't see the GEOIDMODEL node in your linked example. Should it be there?

Kirk

On Wed, Jul 15, 2020 at 12:10 PM Howard Butler notifications@github.com wrote:

OGC https://www.opengeospatial.org WKTv2 http://docs.opengeospatial.org/is/18-010r7/18-010r7.html is the follow-on standard of the well-known text https://en.wikipedia.org/wiki/Well-known_text_representation_of_coordinate_reference_systems coordinate description grammar that LAS 1.4 uses. The WKTv1 (actually GDAL-dialect WKT) that LAS 1.4 uses is deficient in a number of situations:

• No support for description of dynamic coordinate systems https://geodesy.noaa.gov/datums/newdatums/background.shtml.
• Weak 3D CRS description capabilities (aren't we doing 3D stuff here? 😄 )
• Future proofing to eliminate the need to increment the LAS specification.

Dynamic Coordinate System Support

The most pressing need for WKTv2 support is the now-delayed upcoming NATRF2022 effort by NOAA NGS for US-based geodesy. Other geodetic organizations around the world such as LINZ in New Zealand are also putting out time-based deformation models. As the world moves to space-based, time-aware geodesy, the software systems describing data must also be able to describe where and when the data are referenced. WKT used by LAS 1.4 does not do a sufficient job. Weak 3D CRS description capabilities of WKTv1

A specific case of the insufficiency of WKTv1 that LAS 1.4 uses is evident in the USGS LiDAR Base Specification https://prd-wret.s3.us-west-2.amazonaws.com/assets/palladium/production/atoms/files/Lidar-Base-Specification-version-2-1.pdf (LBS). It states:

The geoid name shall be appended to the VERT_CS[] name field. For example: VERT_CS[“NAVD88 height (ftUS) - Geoid12b”

This attempt to inject the geoid's epoch (Geoid12b) in the VERT_CS entity name causes the VERT_CS's entity name to be invalidly specified WKT. WKT parsers such as PROJ https://github.com/OSGeo/PROJ/pull/1978 have been updated to account for mis-specification, but this prescription does not follow specification and would not succeed in a strictly compliant parser.

The way to handle this in WKTv2 is to use the GEOIDMODEL node. See https://gist.github.com/hobu/e6f218bba7fda414694c2272f7e4353d for an example WKTv2 of NAD 83, UTM Zone 15, GEOID12A, vertical units ft. (use 5703 instead of 8228 for the vertical if you want meters). Future proofing

The LAS 1.5 specification should declare the WKT specification version using OGC version names. For OGC WKTv1, which wasn't technically ratified at the time LAS 1.4 was put forward, the name would be 12-063r5. For OGC WKTv2, it would be 18-010r7. It is not expected that WKT will be rapidly evolving, but there is a chance there will be a WKTv3. Rather than wait until that event and require an LAS increment, let's defer to any later OGC WKT specification.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ASPRSorg/LAS/issues/95, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5B33J5Z4MYUFTYFFOF3GTR3XICRANCNFSM4O2VGYBA .

[hobu]

Gist updated.

[rouault]

OGC WKTv1, which wasn't technically ratified at the time LAS 1.4 was put forward, the name would be 12-063r5.

http://docs.opengeospatial.org/is/12-063r5/12-063r5.html is the WKT:2015 (first release of WKTv2). I suspect LAS 1.4 actually implements OGC 01-009 (https://www.ogc.org/standards/ct / http://portal.opengeospatial.org/files/?artifact_id=999), which is to my knowledge the latest revision of the WKTv1 specification . Page 8 of https://prd-wret.s3.us-west-2.amazonaws.com/assets/palladium/production/atoms/files/Lidar-Base-Specification-version-2-1.pdf actually mentions "CRS information in LAS files shall use WKT as defined in OGC (2001). All other WKT specifications, including Esri, ISO, and OGC (2015) are expressly forbidden"

[hobu]

Thanks for the touch ups @rouault. Our intention with WKT in LAS 1.4 was "GDAL dialect WKT" at the time of the specification in 2010. This was to avoid being bound to the Esri dictionaries, which weren't freely available at the time. The language in the document wasn't so clear on that topic, but what "GDAL dialect WKT" was at that time wasn't so clear either.

Page 8 of https://prd-wret.s3.us-west-2.amazonaws.com/assets/palladium/production/atoms/files/Lidar-Base-Specification-version-2-1.pdf actually mentions "CRS information in LAS files shall use WKT as defined in OGC (2001). All other WKT specifications, including Esri, ISO, and OGC (2015) are expressly forbidden"

But then the LBS bastardizes that with the recommendation I described in point #2 above. The LBS piling on additional format requirements like this has been a problem because it has caused software breakage because so much LAS data is written in service of activities like 3DEP. Organizations have had to contort WKT-writing things significantly to try to meet these requirements too. Now that OGC WKTv2 is finalized and the dust is settling, making the LAS specification simply reference it hopefully will be much better going forward. It would be helpful if the group working on the LBS simply point at OGC WKTv2 in the document instead of making its own prescriptions that disrupt data interchange once LAS has incremented with it.

[kjwaters]

I'm wondering if we might want to add another standard VLR for WKTv2 instead of replacing the old definition. That would allow existing software to not break and might not have to wait for version 1.5. This might exacerbate the problem of multi georeferencing records and which one to believe, so that might need to be addressed.

[hobu]

I'm wondering if we might want to add another standard VLR for WKTv2 instead of replacing the old definition.

It brings forward the question of whether or not we ever need another LAS version at all. It hasn't happened in 10 years, and if pushing forward another VLR definition is the solution to this particular challenges, maybe that's ok. It makes more mess rather than cleaning stuff up though, but it's probably too late anyway.

It was developer intent to allow extension of the format with VLRs. Our community is missing a VLR registry to share and communicate those extensions. If it had it, discrimination between VLRs sanctioned by the ASPRS committee and those that are unsanctioned wouldn't really matter that much.

[esilvia]

We could consider moving all of the ASPRS VLR definitions out of the LAS spec and into the wiki like we've started doing with the ExtraByte definitions. We've already determined that modifications of the VLRs does not constitute a material change to the specification itself, so this wouldn't violate that principle.

That said, we already have a precedent of embedding the CRS style in the global encoding bit, so in my opinion it's probably wise to stick with that precedent for WKTv2. Between #6 and this issue that feels like sufficient cause to proceed with LAS 1.5.

Not that I'm happy about it or looking forward to the battle with software devs.

[nkules]

I understand that the time precision issue would require a new version. But could we not produce a method to provide standardization of WKTv2 within our current LAS 1.4 structure?

I believe I may have proposed this in a previous meeting but my thought would just be the utilization of another global encoder bit to signify WKTv2 (and still support WKT using the current encoding bit). This would allow for earlier adoption of WKTv2. If I'm incorrect in this approach assumption do let me know!

[esilvia]

I've gone through a few scenarios that all land on needing a new version because they break existing implementations.

Add a new WKTv2 VLR and global encoding bit to LAS 1.4

Technically this is possible in a revision because it doesn't technically break existing implementations. However, LAS 1.4 parsers that don't yet support WKTv2 will "correctly" think it's an invalid LAS 1.4 file since it's missing WKTv1 or geotiff CRS information. They don't know that a new CRS format exists, and there's nothing in the file to suggest that something's broken.

Extend existing WKTv1 VLR to allow WKTv2 in LAS 1.4

As I understand it, WKTv1 and WKTv2 are not at all compatible, so CRS parsers in existing implementations will break if we encode WKTv2 when it's expecting WKTv1. Unsetting the WKTv1 global encoding bit could be the best way, but then parsers will think there's no CRS info at all.

Include WKTv1 for old parsers but also add WKTv2 for new parsers

We could add a second WKT CRS VLR just for WKTv2 encoding while still also including the WKTv1 CRS VLR. This is the most palatable non-1.5 option by far. I don't like it because it creates the opportunity for conflicting and mutually exclusive CRS definitions to be present.

This is more or less what LAS 1.4 did for the geotiff encoding, but in my interpretation the spec actively discourages including both at the same time. It would be weird to suddenly add this option.

Conclusion

I agree that the third option might be an acceptable workaround if there was no other motivating issue for LAS 1.5. However, in light of #6 I think that the two issues together constitute justification for the disruption from introducing LAS 1.5.

[esilvia]

From the Nov 2023 LWG call: Consider phrasing the new language to support ProjJSON? https://proj.org/en/latest/specifications/projjson.html

Established a desire to phrase the LAS 1.5 spec to broadly adopt a specific minimum OGC standard/version, and then endorse (?) specific code libraries as known to work, with specific features called out. For example, PROJ x.y is known to work with WKTv1, PROJECT a.b is known to work with epoch-based CRS definitions, etc.

Howard to leverage next week's OGC meeting in Vienna to hammer out some of these issues.

[esilvia]

From the Dec 2023 LWG call:

Key missing piece in WKTv2 right now is being able to record the exact epoch. There's an ugly workaround to use COORDINATEMETADATA to store this info, but it's VERY poorly supported and kludgy. (https://docs.ogc.org/is/18-010r7/18-010r7.html#130)

Howard: "We are doing enough harm to our users by eliminating the geotiff codes option."

Recommended approach from @hobu is to relax LAS 1.4's lock on WKT version for LAS 1.5 to allow for future improvements to WKT, and continue using the original LAS 1.4 WKT VLR for the LAS 1.5 CRS. This shouldn't break much software because there's no self-describing encoding of WKT version in the WKT string itself. Most parsers will be agnostic between the supposed WKTv1 and WKTv2. The distinction doesn't technically exist, but a parser may choke.

What if the epoch didn't belong in the CRS definition? We may need to consider encoding epoch (yyyy.mm or yyyy.yy) into a new specialized and optional VLR. Geotiff/GDAL did something similar by storing a specialized value as a STRING in the TIF header. (https://gdal.org/user/coordinate_epoch.html)

At first glance, endorsing PROJ.9 or newer may be the best bet for most users as a guideline.

[rouault]

We may need to consider encoding epoch (yyyy.mm or yyyy.yy) into a new specialized and optional

I'd strongly encourage to use decimal year, that is year with a fractional part, which is the "standard" way to encode epochs. In WKT2, or in the GeoTIFF 1.2 CoordinateEpochGeokey (cf https://github.com/opengeospatial/geotiff/blob/master/GeoTIFF_Standard/standard/clause_7_requirements.adoc#requirements-for-dynamic-crs)

[hobu]

I'd strongly encourage to use decimal year, that is year with a fractional part, which is the "standard" way to encode epochs.

Concur, and this is what I was trying to recommend, and I flubbed up what I remembered as to its encoding.

From the GeoTIFF link:

The date at which coordinates are referenced to a dynamic coordinate reference system is expressed as a decimal year in the Gregorian calendar, and stored in the CoordinateEpochGeoKey. Example: 2017-03-25 in the Gregorian calendar is epoch 2017.23.

[hobu]

Here is my plan for CRS WKT in 1.5. I will try to make a PR that implements this against the 1.5 branch during the holiday quiet period:

• Relax the WKT VLR definition to include any published OGC CRS WKT version. This would have some positive effects feature-wise.
  • It would allow both 18-010 and 12-063. 12-063 didn't exist when we originally wrote LAS 1.4, but this is what we were intending when we said "use OGC WKT and not Esri dialect" in the doc.
  • It would allow OGC to increment a new version of the specification and have the LAS specification still be valid. No more need to increment the LAS specification just to react to a CRS increment
  • Existing software could continue to write the older WKT definitions in 1.5 files and have it still be valid. Lots of LAS software is not so CRS-aware, and WKT is painful to consume and work with. If they're already doing enough with the older WKT variant, they wouldn't have to change
  • Software wouldn't have to handle different versions of the CRS specification specially – no conditional in your code to deal with WKT1 vs WKT2 vs WKTx
• Add another LASF_Projection VLR that defines the coordinate epoch of the data in the same way that GeoTIFF has begun providing.
• Recommend that implementors look to PROJ 9.0+ for CRS handling inspiration (or outright use, in a lot of cases)

[abellgithub]

Not sure I love this. This would mean that an invalid file (because of a WKT spec) could become valid when a new spec is published, right?

How about providing a VLR dictionary that can be amended outside of a LAS version update. That way, when someone changes the SRS info (or anything else), a new VLR can be defined to support the change without modifying the LAS spec at all.

[hobu]

Not sure I love this. This would mean that an invalid file (because of a WKT spec) could become valid when a new spec is published, right?

I'm not sure what you mean by a "invalid file" here, as people tend not to write sneaky new versions of WKT 😉 Are you worried about people starting to write WKTv2 in 1.4 files? That's not valid according to the 1.4 specification language. The purpose of my proposal is to completely and entirely defer the validity of the coordinate system information to OGC's specifications for LAS 1.5+ (and beyond, although there's no beyond though, is there?). Maybe someday OGC will version WKT, but for now it is possible to determine the version by inspecting for specific keys.

A VLR dictionary would be nice to have as a resource but it has the same problems as the LAS specification itself. When would such definitions be active or deprecated? Who has decided? Was it voted/published?

[mgswartz1]

An issue we have seen is lidar that has been localized. Scaled and rotated about an origin. Any way to place this information into the .las header would be beneficial. If such a mechanism is currently in place please let me know about it and I apologize for just being a casual user. However I do strongly advocate storing the complete SRS information in the .las header.

[rouault]

Scaled and rotated about an origin.

WKT has the concept of DerivedProjectedCRS. e.g https://docs.ogc.org/is/18-010r7/18-010r7.html#119 , which combined with a METHOD["Affine parametric transformation", ID["EPSG",9624]] as the DERIVINGCONVERSION, could potentially do that. Although that's quite esoteric...

[mgswartz1]

Even,

Thanks for taking the time to respond. Now I can do my reading and then start educating our Locations and Survey Unit and have a dialog with Trimble Support, LP360 Support and Global Mapper Pro Support. I appreciate how massive the work is when trying to update a worldwide standard.

Thanks,

Marc Swartz Engineer (Contributing) Photogrammetry Unit North Carolina Department of Transportation

919 707 7117 Office @.**@.>

1020 Birch Ridge Drive 1585 Mail Service Center Raleigh, NC 27699-1585

[1489589433450_PastedImage]

Email correspondence to and from this address is subject to the North Carolina Public Records Law and may be disclosed to third parties.

From: Even Rouault @.> Sent: Wednesday, January 31, 2024 8:07 AM To: ASPRSorg/LAS @.> Cc: Swartz, Marc G @.>; Comment @.> Subject: [External] Re: [ASPRSorg/LAS] Implement OGC WKTv2 (or later) as the coordinate system definition (#95)

CAUTION: External email. Do not click links or open attachments unless verified. Report suspicious emails with the Report Message button located on your Outlook menu bar on the Home tab.

Scaled and rotated about an origin.

WKT has the concept of DerivedProjectedCRS. e.g https://docs.ogc.org/is/18-010r7/18-010r7.html#119 , which combined with a METHOD["Affine parametric transformation", ID["EPSG",9624]] as the DERIVINGCONVERSION, could potentially do that. Although that's quite esoteric...

— Reply to this email directly, view it on GitHubhttps://github.com/ASPRSorg/LAS/issues/95#issuecomment-1919070196, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BDAKUBXIFR7YEUEOXVLPDILYRI6XLAVCNFSM4O2VGYBKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRHEYDOMBRHE3A. You are receiving this because you commented.Message ID: @.**@.>>

---

Email correspondence to and from this sender is subject to the N.C. Public Records Law and may be disclosed to third parties.

[esilvia]

Significant work was completed on #144 during today's meeting. Those present agreed that the specification should be descriptive of what should be done and explicit about the GeoTIFF codes no longer being authoritative, without going so far as to invalidate a LAS 1.5 file with a GeoTIFF-related VLR. The PR appears to be ready to merge. Last call for comments!