Help with Corrupt Laz files with -0 Y offset

[Alex M]

 Hi Lastools team and community,

We are having an issue with some lidar data that has been processed by an external supplier that appears to have a corruption in the header causing a strange output. The lasinfo report shows the x, y, z offset as 0, 0, -0. Strangely lasinfo only shows the -0 when run with -cpu64 however it shows up in other software (e.g QGIS metadata).

Attached is an example failed tile.

Command line output running lasinfo with -cpu64:

 Lasinfo output:

Lasinfo with -repair:

After -repair the offset is correctly set 0,0,0 but the chunks still register as corrupt.

Running laszip with -check gives:

 Running lasvalidate does not show fails/corruptions/warnings for the issue other than CRS:

We are contacting our vendor to see if they can figure out what they have changed in their process recently that would start causing this.

In the mean time does anyone have an idea about how to find what is corrupted in the file? Or what would cause a -0 offset? Or how to fix the current data? The points are all correct and in the right place and the laz files load fine, however they are still likely to fail QA checks due to the corrupt chunks.

Many thanks,

Alex M

New Zealand

[Möst, Karin (LDBV)]

Hi ,

 

maybe you can use

lasinfo  -i *.la* -repair -otxt -odix _info_repaired -compute_density -cpu64 -cores 8

 

See attached lasinfo

 

Regards

Karin

--
Download LAStools at
https://rapidlasso.de
Manage your settings at
https://groups.google.com/g/lastools/membership
---
You received this message because you are subscribed to the Google Groups "LAStools - efficient tools for LiDAR processing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lastools+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lastools/dcff10f4-30b6-4cd8-b784-a09737aee350n%40googlegroups.com.

[Jochen Rapidlasso]

Hi Alex,

probably there is not much to repair: If the chunk is broken it is a wild guess whats behind this mismatch.

Easiest thing to do is a simple 

    las2las -i tile2_Corrupt.laz -o tile2_ok.laz

This will copy the header and get out of the corrupt file as much as possible.

The new file will have the same amount of (valid) points and no more errors.

Don't get confused with the -0 z offset.

This have been seen with some files. Within the header it is all 00000.
Probably this is just a display issue, but it is still zero.

Cheers,

Jochen @rapidlasso