Publish LAS 1.4 R14 #76
Conversation
Draft enhancements to support GmAPD LiDAR.
# Conflicts resolved: # source/10_point.txt
…r EVLRs section. Added Introduction root heading. Reorganized heading heirarchy to something more logical (#57). Removed (optional) tags from Defined VLRs headings. Capitalization of headings is now more consistent.
…s to reduce TOC noise.
Updates to address review comments from @hobu and @rapidlasso.
Undid typo correction. Should be in a different branch.
Adds Aggregate bit to the Global Encoding to accommodate new technologies.
Renamed "LAS 1.4 Additions" to "Comparison of LAS 1.4 to Previous Versions". Added issue links to changelog in 01_intro.txt.
Resolving Issue 57 - Clean up TOC and Headings
esilvia
added
clarification
deprecation
aesthetic
wiki
|
Turns out FUGRO implemented the triples in the Extra Bytes. For more info see my comment here: (#1) |
|
For the "extra bytes" scale factor and offset, should we state that the scale factor (if not used) should be set to 1.0 and that the offset (if not used) should be set to 0.0. I came across a data set that left the scale factor at zero and merely indicated in the 'options' that the scale factor was not set. This broke my code that always multiplied. Having a default value of 1.0 may safe future implementation from having that bug. |
|
The spec states in its current form that unused scale, offset, and nodata values should be zero if unused as indicated in the options field, which it sounds like is the case for your sample dataset. Since I don't see any ambiguity in its current form, I'm not sure that I can or should change that in a revision. Do you feel differently @rapidlasso ? |
|
Not strongly. But the best "zero" for a scale factor is a value of "1.0". It was just a poor decision / oversight when I wrote that part of the "Extra Bytes" specification back then and I wish I had formulated it like that. |
|
If we do want to simplify, then in that case one could deprecate the flags for offset/scale factor. They are always there and set to 0.0/1.0 as default. We should not have both a flag that indicates not to use them and a default value for those that ignore the flag. |
|
Here I strongly disagree. That would really change the specification as this also affects used scale factors (that may no longer get used because the flag is zero). My suggested change only affects the zero setting of unused scale factors. |
|
I agree that from a compatibility stand my suggestion is not good. |
|
I've chewed on this for a bit and I think it's best to keep the scale defaulting to zero. When we implement a "Compact Extra Bytes" VLR then I think we should take this into consideration. |
|
The change from raw anytype to scaled and offset double values for the min / max values will require LASlib (and maybe other implementations) to make functional changes. How are we supposed to know whether an existing LAS/LAZ file uses the old anytype convention that is currently valid versus the new double convention that is soon to be valid once R14 is ratified? Here are the current functions used in the LASlib and LASzip APIs for this: https://github.com/LAStools/LAStools/blob/master/LASzip/src/lasattributer.hpp#L119 |
|
@rapidlasso comments repeat what I had previously said at #1 No matter the intention, the R14 changes the type of the min/max fields from R13 without anywhere an indication in the file that it is a different version. CARIS stores min/max values as the field type. LASLib interprets them as such as well. |
|
CARIS stores min max doubles or min max anytype? I don't think LASlib / LAStools actually use those values anywhere at the moment. |
|
anytype: Value interpreted as anytype: Values interpreted as double: |
|
@rapidlasso some lasreader code is calling set_min/max and update_min/max. (_ply/_qfit/_txt). In the current version it is calling lasattributer.cast which converts the stored value to anytype. |
|
Yes. LASlib / LASzip can set anytype min/max values when writing. But I have no tool that uses the written values for any post processing. So I would currently not notice when these values are broken. |
Clarified form of the ExtraByte min/max field.
|
You're right. A revision shouldn't change the field type regardless of the original intent. I'll revert #4 for R14 and defer it to 1.5. The original post now has updated PDF and commit comparison links. |
|
Now that the ExtraByte min/max objection has been resolved, this is the last call for comments before LAS 1.4 R14 gets released. If I receive no more objections, I'll merge the pull request, remove the DRAFT tags, and send the PDF to ASPRS for publication. |
LAS 1.4 R14 is ready for final comment before publication. Please post any comments on this thread and we'll do our best to address your feedback promptly.
Here's a summary of the changes with respect to R13, the current version (issue numbers included):
Noteworthy changes:
Clarification or usability improvements:
anytypetodouble, which was the original intent. (Clarify that ExtraByte min/max values should be double-float #4)chararrays, especially VLR Description (Clarify (E)VLR descriptions don't have to be null-terminated #46)In accordance with the requirements for a Revision without incrementing the Version Number, there are no substantive changes that significantly impact the interpretation of the LAS format itself.
PDF here: https://s3.amazonaws.com/asprs-las/LAS-specification-5ae7567ae98f953674c09b078596f72e0a08a223.pdf
Line by line comparisons: https://github.com/ASPRSorg/LAS/pull/76/files