Is it valid to have several extrabytes VLR?

[Jean-Romain]

What is the issue about?

Inquiry about the specification

Issue description

I recently received a file with three identical VLRs describing three groups of extra-bytes created by three different software applications. To my understanding, this is not compliant with the specifications, and LASlib is failing to read the extra-bytes properly.

However, there is fundamentally nothing preventing a reader from supporting this special case. Therefore, I'm wondering whether the software should be enhanced to support this case or if the file should be fixed to be compliant with the specifications.

Does this look like a legitimate file to you? The header has three extra byte definitions for a total of eight extra byte attributes.

• RIEGL Extra Bytes
  • Amplitude
  • Pulse width
  • Reflectance
  • Deviation
• NA
  • confidence
• TerraScan Extrabytes
  • Distance
  • Group
  • Normal

lasinfo

variable length header record 2 of 5:
  reserved             0
  user ID              'LASF_Spec'
  record ID            4
  length after header  768
  description          'RIEGL Extra Bytes'
    Extra Byte Descriptions
      data type: 3 (unsigned short), name "Amplitude", description: "Echo signal amplitude [dB]", min:, 0, max:, 10000, scale: 0.01, offset: 0 (not set)
      data type: 3 (unsigned short), name "Pulse width", description: "Full width at half maximum [ns]", min:, 1, max:, 10000, scale: 0.1, offset: 0 (not set)
      data type: 4 (short), name "Reflectance", description: "Echo signal reflectance [dB]", min:, -5000, max:, 15000, scale: 0.01, offset: 0 (not set)
      data type: 3 (unsigned short), name "Deviation", description: "Pulse shape deviation", min:, 0, max:, 65535, scale: 1 (not set), offset: 0 (not set)
variable length header record 3 of 5:
  reserved             0
  user ID              'LASF_Spec'
  record ID            4
  length after header  192
  description          ''
    Extra Byte Descriptions
      data type: 1 (unsigned char), name "confidence", description: "confidence values", scale: 1 (not set), offset: 0 (not set)
variable length header record 4 of 5:
  reserved             0
  user ID              'LASF_Spec'
  record ID            4
  length after header  576
  description          'TerraScan Extra Bytes'
    Extra Byte Descriptions
      data type: 6 (long), name "Distance", description: "Distance", min:, 2147483649, max:, 2147483647, scale: 1, offset: 0 (not set)
      data type: 5 (unsigned long), name "Group", description: "Group", min:, 0, max:, 4294967295, scale: 1, offset: 0 (not set)
      data type: 5 (unsigned long), name "Normal", description: "Normal vector 2+15+15 bits", min:, 0, max:, 0, scale: 1, offset: 0 (not set)

[hobu]

three identical VLRs describing three groups of extra-bytes created by three different software applications.

My recollection is Martin and I were thinking a single VLR entry when we developed the extra bytes VLR. Certainly it is valid, but I would argue it was not the expected condition, and software implementations probably do not expect to have to concatenate multiple extra byte VLRs together – I expect they might just take the first one they see and leave the additional bytes uninterpreted.

[Jean-Romain]

@hobu Thanks you for your reply. LASlib implementation takes the last definition and thus reads corrupted data. Keeping the first definition would allow, at least, to read the few first extra-bytes properly with minor modification. If this respects the standard I guess concatenation should be supported. But this is no longer a question for ASPRS.

[manfred-brands]

@Jean-Romain Can you see if TerraScan actually adds new data or is it overwriting Riegls.

Is the point size matching the sum of all 3 VLRs or only the last.

[Jean-Romain]

@manfred-brands good question and I already checked it.

It is a LAS 1.4 PDRF 8. The Minimum PDRF Size is 38 bytes. The point data record length is 59 bytes. According to the header there are 4 short + 1 char + 3 long i.e. an additional payload of 21 bytes for an expected total of 59 bytes. It matches.