Add units to ExtraBytes attribute definition

[esilvia]

The "extra space" could be used to describe two alternate units as follows. After deprecating "tuples" and "triples" we could reuse the array entires [1] and [2] of no_data, min, max, scale, and offset. Below my "old" struct of 192 bytes that is the payload of the official "extra bytes" VLR.

struct LASattribute
{
  U8 reserved[2];           // 2 bytes
  U8 data_type;             // 1 byte
  U8 options;               // 1 byte
  CHAR name[32];            // 32 bytes
  U8 unused[4];             // 4 bytes
  F64 no_data[3];           // 24 = 3*8 bytes // last 16 bytes deprecated
  F64 min[3];               // 24 = 3*8 bytes // last 16 bytes deprecated
  F64 max[3];               // 24 = 3*8 bytes // last 16 bytes deprecated
  F64 scale[3];             // 24 = 3*8 bytes // last 16 bytes deprecated
  F64 offset[3];            // 24 = 3*8 bytes // last 16 bytes deprecated
  CHAR description[32];     // 32 bytes
};

and - just to present a tangible example - we could re-use it as shown below to offer two alternate units assuming the conversion can be done by changing the scale and the offset.

struct LASattribute
{
  U8 reserved[2];           // 2 bytes
  U8 data_type;             // 1 byte
  U8 options;               // 1 byte
  CHAR name[32];            // 32 bytes
  U8 unused[4];             // 4 bytes
  F64 no_data;              // 8 = 1*8 bytes
  U8 unit                   // 1 byte
  CHAR unit_name[15];       // 15 bytes
  F64 min;                  // 8 = 1*8 bytes
  U8 alt_unit1              // 1 byte
  CHAR alt_unit1_name[15];  // 15 bytes
  F64 max;                  // 8 = 1*8 bytes
  U8 alt_unit2              // 1 byte
  CHAR alt_unit2_name[15];  // 15 bytes
  F64 scale;                // 8 = 1*8 bytes
  F64 alt_unit1_scale;      // 8 = 1*8 bytes
  F64 alt_unit2_scale;      // 8 = 1*8 bytes
  F64 offset;               // 8 = 1*8 bytes
  F64 alt_unit1_offset;     // 8 = 1*8 bytes
  F64 alt_unit2_offset;     // 8 = 1*8 bytes
  CHAR description[32];     // 32 bytes
};

Originally posted by @rapidlasso in #37 (comment)

[esilvia]

In my opinion, self-documenting the units makes ExtraBytes harder to implement because it puts the burden of synchonizing units onto the developer, not the data user. For that reason I'm reluctant to make this change, especially if we provide a mechanism for alternative units. I'm open to differing opinions.

[esilvia]

On the other hand, this provides a very elegant solution for the question about representing different levels of precision for an ExtraByte. For example, one could represent Height From Ground in units of decimeters, centimeters, or Tenths of a Foot if one so desired, without having to change the data_type.

[esilvia]

Can @rapidlasso comment on how alternative units are supposed to work? Does one select their primary unit from amongst the alternatives? Are there only three allowed for a given standard ExtraByte, or is this up to the user to decide? Do we have to provide a standard list of ExtraByte units somewhere, or do we rely on the EPSG list? What if there's a unit not supported by WKT, such as decibels for Riegl Reflectance?

As @hobu observed here this isn't as simple as deciding between meters and feet.

[esilvia]

Also tagging @kjwaters because he was the one that brought this up in the first place. :)

[rapidlasso]

I still prefer hard-coded metric units for storage purposes. In any software has to present them in other units to their users ... a unit conversion really is not rocket science. Although having an overly complex scheme to define units may explode a rocket if boosters are launched too late or too early due to an incorrectly parsed unit description. If we add a unit description it should not happen in this release. A hasty solution will definitely blow up spaceships. Let's go with hard coded metric units for this release and brainstorm if and how other units should be supported.