Clarify that ExtraByte min/max values should be double-float about las

[esilvia]

A while back we had an extensive discussion in LASroom regarding the data types of min, max, and nodata in the EXTRA_BYTES structure:

https://groups.google.com/d/msg/lasroom/thdrEOeAUvc/rpS7dDDNAwAJ

(note: this post also includes some discussion history regarding #1)

In it we concluded that min and max should both be type double instead of anydata, whereas the type of nodata should match the up-cast version of the data itself. The reasoning was as follows:

1. Using a double for min-max here would be consistent with the usage in the LAS header for XYZ min/max values. That is, ExtraByte min/max values should not require the application of the scale and offset to retrieve the actual value and are therefore the transformed values.
2. nodata values must remain byte-compatible with the raw data, which requires that no mathematical operations (i.e., scale and offset) should be applied. For example, for an extrabyte descriptor of an unsigned short integer, NODATA value of 65535, and scale value of 0.001, the nodata value stored in the descriptor should be 65535 and not its transformed value, 65.535.

I intend to proceed for R14 as if that decision still stands, but I'll leave this open for a couple days in case there's further discussion required.

[rapidlasso]

It seems the "most popular" implementation of Extra Bytes (namely the RIEGL exporter) does not use floats but follows the current specification (see this white paper).

[esilvia]

Where do you see that? As far as I can tell, most implementations seem to store a 64-bit double.

[esilvia]

@manfred-brands correctly pointed out in #76 that because this has already been implemented in existing software packages, we can't change the data type for the existing ExtraByte min/max VLR, regardless of the original intent or what "makes sense" moving forward. This change will be deferred to LAS 1.5, probably as a part of #37 or a future alternative ExtraByte definition.

@rapidlasso Do I correctly understand that the min/max should actually be an untransformed value? If so, I'll add a new commit with that clarification.

[rapidlasso]

Unfortunately all the "extra bytes" discussions happened long before the LWG adopted the record keeping and the decision-making transparency of usual standardization bodies. I will have to dig up the email threads from 2010 / 2011 to see who (most likely me) decided on the design of the min/max values and what the intended meaning is. I seem to remember yes, the untransformed values. @lgraham-geocue or @hobu may also still have those cc-ed email discussion threads. I'll get back to you on that if they don't, but now it's happy hour time here in Costa Rica ... (-;

[rapidlasso]

I went back through my emails. On Aug 25, 2011, I proposed to the LWG via email the following:

"The LAS format already allows to store n "extra bytes" for every LAS point simply by specifying a point size in the LAS header that is n bytes larger than minimally required by the point type. These extra bytes can be used to store user specific data. I am proposing an "Extra Bytes" LASF_Spec VLR (see attached PDF) that users can use to - optionally - describe these "extra bytes".

This could also be seen as first step towards a self-describing LAS format. It will provide us a with a no-cost real-world “test-run” for self-describing content that is completely risk-free but will give us user feedback and insights for designing LAS 2.0."

LAS_1_4_addendum.pdf

This was sent to LWG chair Lewis Graham (GeoCue) and cc-ed to Howard Butler (Hobu Inc.), Michael Watry (Qcoherent), Paul Conrad (Optech), Paul Galla (LeicaUS), Jim van Rens (RIEGL), Arttu Soininen (Terrasolid), Ramesh Sridharan (Virtual Geomatics), Michael Umansky (Applied Imagery), Randy Rhoads (Network Mapping),,Andre Koestli (Trimble), Craig Glennie (University of Houston), Michael Rosen (Lizardtech), Karl Heidemann (USGS), and Wanning Peng (ESRI).

[rapidlasso]

A few months later, on Nov 12, 2011, after lots of private email exchanges with various parties, including Howard Butler (Hobu Inc), Gottfried Mandelburger (TU Vienna), and others I sent a revised document by private email to Lewis Graham that he then integrated into the then current revision of the evolving LAS 1.4 draft (R10 from 11 November 2011) to produce the next revision (R11 from 12 November 2011). I was able to find all these documents for some "extra bytes" VLR history:

LAS 1 4 - R10.docx

LAS 1 4 - Extra Bytes Update.docx

LAS 1 4 - R11.docx

[esilvia]

@rapidlasso Thanks Martin! I think that confirms my suspicion that the min/max should match the raw data_type but upcast to 8 bytes. I modified this comment to §4.3 as follows:

Interesting that your original proposal for the ExtraBytes as singles (not triples) matches where we ended up after all.