Clarify case-sensitivity for ExtraByte names

[esilvia]

Clarify case-sensitivity for ExtraByte names

[rapidlasso]

I designed the "extra bytes" and it was my plan all along to be able to extend the existing point types with standardized additional attributes rather than adding point types 11 to 18. The reserved space that was specified to have to be zero was always meant to be an enumerator for those additional attributes someday. I may still have some older emails - from the undocumented untransperent days of the LWG - that are saying so. #nolas15

[rapidlasso]

I think case (in)-sensitiveness does not matter much because the "extra bytes" name is not going to be used for identification of standardized additional attributes.

1. For user-defined additional attributes stored as "extra bytes" they will continue to have an enumerator of 0 (currently the reserved / unused field) and only those who care about them will use them, most likely case-sensitive like LAStools does it. Also the VLR/EVLR are case-sensitive.

2. For standardized additional attributes stored as "extra bytes" it is the enumerator > 0 that decides what standardized attribute it is. Here we should also agree on what name and description should be and how they are capitalized but it is really this enumerator that software should have to check (if it cares about those).

[esilvia]

What you say makes sense, if we do indeed decide to use the two Reserved bytes at the front of the ExtraByte definition as an identity marker. I don't recall that I ever got confirmation that people liked that idea.

I guess for #37 I can just publish the versions as previously - i.e., use the first-letter case for Riegl's contributions and lowercase for yours. Unless Riegl is interested in switching to lowercase? Maybe @csevcik01 can comment? He's the only Riegl rep I'm aware of that's on here.

I can update the ExtraByte VLR Definition to explicitly state that it's case-sensitive and recommend lowercase.

[rapidlasso]

For the standardized extra bytes we - the committee - get to decide how we want the name and description strings to look. Lower case or upper case. With hyphens or without. With underscores or without.

When vendors want to implement the standardized extra bytes they have to go back and modify their export modules anyways because they will have to change the value they put into the reserved space that is currently specified to have to be zero into the correct non-zero value that enumerates those standardized extra bytes we decide on. When they do that also changing the names and descriptions at the same time is trivial. I expect the descriptions to also include the (metric) unit that we decide on.

[esilvia]

This works for me. I'll leave the specification as-is and keep this discussion in mind as we work toward standardizing some of these attributes.