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?

  • Source flightline information should be contained in the "Point Source ID" field in the Public Header Block. – Jeffrey Evans Nov 20 '13 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 Nov 21 '13 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. – Jeffrey Evans Nov 21 '13 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 Nov 21 '13 at 16:26
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.

  • I have incorporated these changes into the main libLAS tree, and they will be included in subsequent releases. – Howard Butler Dec 17 '13 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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