some files have pad bytes when they shouldn't

[hobu]

Looks like it happened between versions 1.2b2 and 1.2b3. 1.2b2 displays fine.

On 4/7/09 1:06 PM, "Smith, Michael ERDC-CRREL-NH"

Howard,

I'm getting completely incorrect results using las2txt from the 1.2 release. I tried 1.2b3 as well as got the same wrong results.

The 1.0.1 release works fine. The las file is located at  XYZ_a1_sanam01-02_1.5Million.las.zip (4130 KB)

• Example correct (from 1.0.1)

[root@beta11gr2 las-1.0.1]# apps/las2txt --parse Mxyz --stdout /loading/XYZ_a1_sanam01-02_1.5Million.las
0 252600.603519 4004400.9949 290.758108
1 252604.093519 4004400.9949 290.448108
2 252629.283519 4004402.2049 290.448108
3 252651.433519 4004402.5049 290.448108
4 252685.873519 4004400.8349 290.448108
5 252689.513519 4004402.5049 290.298108
6 252693.003519 4004400.8349 290.448108
7 252726.233519 4004405.2449 290.298108
8 252729.273519 4004402.5049 290.298108
9 252735.943519 4004400.8349 290.298108
10 252737.923519 4004405.5449 290.298108
11 252747.633519 4004402.5049 290.298108
12 252748.083519 4004405.3949 290.298108
13 252757.953519 4004400.9949 290.298108
14 252783.443519 4004401.2949 290.298108
15 252783.443519 4004402.2049 290.298108
16 252788.443519 4004405.3949 290.298108
17 252804.383519 4004402.8149 290.298108
18 252811.513519 4004405.8449 290.298108
19 252813.333519 4004402.5049 290.298108
20 252815.303519 4004405.8449 290.298108

• Example Incorrect (from 1.2)

[root@beta11gr2 loading]# las2txt --parse Mxyz --stdout XYZ_a1_sanam01-02_1.5Million.las
0 4723267.473519 4168238.4749 -82938.721892
1 4951463.663519 4168238.4749 -103254.881892
2 6602315.503519 4247537.0349 -103254.881892
3 8053937.903519 4267197.8349 -103254.881892
4 10310997.743519 4157752.7149 -103254.881892
5 10549548.783519 4267197.8349 -113085.281892
6 10778269.423519 4157752.7149 -103254.881892
7 12956030.703519 4446766.4749 -113085.281892
8 13155260.143519 4267197.8349 -113085.281892
9 13592385.263519 4157752.7149 -113085.281892
10 13722146.543519 4466427.2749 -113085.281892
11 14358501.103519 4267197.8349 -113085.281892
12 14387992.303519 4456596.8749 -113085.281892
13 15034832.623519 4168238.4749 -113085.281892
14 16705345.263519 4187899.2749 -113085.281892
15 16705345.263519 4247537.0349 -113085.281892
16 17033025.263519 4456596.8749 -113085.281892
17 18077669.103519 4287513.9949 -113085.281892
18 18544940.783519 4486088.0749 -113085.281892
19 18664216.303519 4267197.8349 -113085.281892
20 18793322.223519 4486088.0749 -113085.281892

Header seems correct in both versions:

• 1.01

[root@beta11gr2 loading]# lasinfo XYZ_a1_sanam01-02_1.5Million.las

---------------------------------------------------------
  Header Summary
---------------------------------------------------------
  File Name: XYZ_a1_sanam01-02_1.5Million.las
  Version:                    1.1
  Source ID:                  0
  Reserved:                   0
  Project ID/GUID:           '00000000-0000-0000-0000-000000000000'
  System Identifier:         ''
  Generating Software:       'QT Modeler'
  File Creation Day/Year:    0/0
  Header Size                227
  Offset to Point Data       757
  Number Var. Length Records 3
  Point Data Format          0
  Point Data Record Length   20
  Number of Point Records    1503899
  Number of Points by Return 1503899 0 0 0 0
  Scale Factor X Y Z         0.01 0.01 0.01
  Offset X Y Z               257119.983519 4007019.984900 292.038108
  Min X Y Z                  252600.141661 4004400.379430 278.761414
  Max X Y Z                  261639.825378 4009639.590370 305.314802
 Spatial Reference           

---------------------------------------------------------
  VLR Summary
---------------------------------------------------------
   User: 'LASF_Projection' - Description: ''
   ID: 34735 Length: 72

   User: 'LASF_Projection' - Description: ''
   ID: 34736 Length: 40

   User: 'LASF_Projection' - Description: ''
   ID: 34737 Length: 256

• 1.2.0

[root@beta11gr2 loading]# cd liblas-src-1.2.0/
[root@beta11gr2 liblas-src-1.2.0]# apps/lasinfo /loading/XYZ_a1_sanam01-02_1.5Million.las 

---------------------------------------------------------
  Header Summary
---------------------------------------------------------
  File Name: /loading/XYZ_a1_sanam01-02_1.5Million.las
  Version:                    1.1
  Source ID:                  0
  Reserved:                   0
  Project ID/GUID:           '00000000-0000-0000-0000-000000000000'
  System Identifier:         ''
  Generating Software:       'QT Modeler'
  File Creation Day/Year:    0/0
  Header Size                227
  Offset to Point Data       757
  Number Var. Length Records 3
  Point Data Format          0
  Point Data Record Length   20
  Number of Point Records    1503899
  Number of Points by Return 1503899 0 0 0 0
  Scale Factor X Y Z         0.01 0.01 0.01
  Offset X Y Z               257119.983519 4007019.984900 292.038108
  Min X Y Z                  252600.141661 4004400.379430 278.761414
  Max X Y Z                  261639.825378 4009639.590370 305.314802
 Spatial Reference           

---------------------------------------------------------
  VLR Summary
---------------------------------------------------------
   User: 'LASF_Projection' - Description: ''
   ID: 34735 Length: 72

   User: 'LASF_Projection' - Description: ''
   ID: 34736 Length: 40

   User: 'LASF_Projection' - Description: ''
   ID: 34737 Length: 256

Mike

[hobu]

The problem is that this is a 1.1 version file, but it has pad bytes written at the end of the header that aren't accounted for in the header's offset. I was unable to confirm Mike's assertion that how we read stuff changed between beta2 and beta3, however.

Pretty much any 1.1 file from QT Modeler will exhibit this problem: http://liblas.org/samples/LAS12_Sample_withIntensity_Quick_Terrain_Modeler.las

I would say that QT Modeler is writing files incorrectly as far as the spec is concerned, but they are not the only one. There are number of files in the samples directory that are 1.0 that *don't* have pad bytes.

http://liblas.org/samples/LDR030828_211804_0.LAS http://liblas.org/samples/las10_format0.las http://liblas.org/samples/las10_format1.las

I have made an attempt to work around this issue with r1190.

[mloskot]

Good job!

Digression: I understand the problem and I understand that there is a specification and there is reality. However, the idea of patching libLAS to handle all possible broken ASPRS LAS datasets scares me. Perhaps, we should introduce something like strict mode (switched on by default) which will validate all assumptions regarding version vs offsets vs ... and just abort processing. If users do not want to fix their data, they can ask for relaxed mode with --relax switch, but they they accept that behaviour may be not well defined, it may work but it may not at the same time.

[hobu]

Backported to the 1.2 branch in r1199