3

I am working with multi pulse LiDAR data that collects points along a number of lines within the flight path. From what it appears there are four scan lines within the data, at different intervals but with identical gps timestamps. I am trying to determine the name and number of individual lines within the las file. I am using libLAS module in Python.

I found this documentation that explains the different fields stored in an las file. It mentions a data field (get_data and set_data) at the very bottom of the page.

The 'point data format' and 'point data record length' in the header set aside space for this 'data' field. My header says I have 28 bytes set aside for the data field, and there are 28 values stored in the data field. The 19th value (at least in two datasets from two different sensors) refers to the line number. I have a single value in single pulse data and 4 in multi pulse data.

I was wondering if there is a standard for what is stored in this field or if it is proprietary.

Also, as a way to get the name of each scan line, I wrote the following code:

import liblas
from liblas import file as lasfile

# Get parameters
las_file = r"E:\Testing\00101.las"

f = lasfile.File(las_file, mode='r')

line_list = []
counter = 0
for p in f:
    line_num = p.data[18]
    if line_num not in line_list:
        line_list.append(line_num)
    counter += 1
print line_list

It results with the following error:

Traceback (most recent call last):
  File "D:\Tools\Python_Scripts\point_info.py", line 46, in <module>
    line_num = p.data[18]
  File "C:\Python27\ArcGIS10.1\lib\site-packages\liblas\point.py", line 560, in get_data
    length = self.header.data_record_length
  File "C:\Python27\ArcGIS10.1\lib\site-packages\liblas\point.py", line 546, in get_header
    return header.Header(handle=core.las.LASPoint_GetHeader(self.handle))
WindowsError: [Error -529697949] Windows Error 0xE06D7363

Does anyone know more about the line numbers stored in the las point/header? Can anyone explain the error?

4
  • Source flightline information should be contained in the "Point Source ID" field in the Public Header Block. Commented Nov 20, 2013 at 23:07
  • @JeffreyEvans, That's what I thought, however, liblas.point.point_source_id does not return the correct values. If I get point.xml, it contains a pointsourceid tag with the correct value. I am beginning to think this is a bug issue.
    – Barbarossa
    Commented Nov 21, 2013 at 15:02
  • It could be that the vendor did not populate the field. The data description you explain sounds a bit strange as well. What was the sensor model? I have never heard of discrete return lidar with these characteristics. Commented Nov 21, 2013 at 15:50
  • Optech ALTM and Leica ALS60 both have line numbers stored in the raw data. lasinfo.exe and terraScan both show these line numbers are in the data, and point_soure_id (p.data[18]) is consistent with the line numbers.
    – Barbarossa
    Commented Nov 21, 2013 at 16:26

1 Answer 1

2

Just saw the source code was updated 5 hrs ago. After an inquiry, it appears that they found the issue I was asking about. They have updated the code to correct the problem. p.point_source_id now returns source id instead of user_data.

1
  • I have incorporated these changes into the main libLAS tree, and they will be included in subsequent releases. Commented Dec 17, 2013 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.