You should check what the scale and offset are for your file. This can be done as follows:
This almost looks like an overflow error to me. The lower case x, y, and z properties need to re-scale and re-offset the coordinates to store it as an integer (which is how LAS files store them). To be honest, setting ...
According to this page, Laspy supports LAS/LAZ versions 1.0-1.4.
Looking at the Laspy code, it looks like
the format string "h6.0" would correspond to a version "1.6" of the spec.
A value of "6" for the format corresponds to a specific predefined header format. (See the code, or the following link, for clarification on what that means)
There's a good ...
I was able to come up with a solution. The following code works, but it feels like there is a much simpler way to do this operation. If anyone has a cleaner or more efficiect way to filter and reclassify lidar with laspy I'd love to accept that answer.
import numpy as np
from scipy.spatial import cKDTree
in_file = laspy.file.File(input_file, ...
The header needs to be set with a point format that supports RGB colors, see: https://pythonhosted.org/laspy/tut_background.html. For LAS 1.2, the minimum point format for color is 2:
header = laspy.header.Header(point_format=2) # LAS point format 2 supports color
with laspy.file.File(output_path, mode="w", header=header) as lasfile:
Laspy isn't going to give you convenient access to the SRS in a form you can easily consume. LAS files can have either WKT or GeoTIFF keys as the coordinate system description. For consumption in Esri tools (and elsewhere), you always want the WKT.
The most convenient way to get the WKT from an LAS file is to use PDAL. The following script will read a ...
So, is there a better way, more efficient, more pythonesque way of injecting the .las file points (from laspy) to the GeoPandas dataframe without passing through a numpy array?
No, and I'm not sure why you think this is the least efficient way to go. laspy is underneath the covers making a memoryview to the data and the Numpy array is a wrapper over that. ...
OK, I think I've solved my problem.
The issue is noted at the github page for laspy here:
I needed to adjust the "start_first_evlr" property to be the full length of the LAS file as shown below. Not sure if that is the best way, but it seems to work. I needed to read the mmap size for the input LAS file (before ...
The latest version of laspy will generate default file_sig = 'LASF', version_major = 1, version_minor = 2 and data_format_id = 0. However, the header offset and scale have to be specified. The following code (modified adamp's code) can generate output.las which can be read and then displayed using CloudCompare and QT Reader (The QT Reader needs minimum 4 ...
As determined while working through the problem with Aaron, I figured out I was working with corrupt data, because applying the same code to other .las file worked (here is the alternative file used).
I have opened another question related to why FUSION is creating corrupt data when using the polyclipdata module here: FUSION polyclipdata creates corrupt ...
The issue was that I was not using the set method from laspy writer. I modified the Outfile.red to outfile.set_red.
This makes a nice las 1.2 file from scratch.
def makeLASfile(finishPoints,LASheader, valuesP):
print("Your Making LAS file")
outfile = laspy.file.File("C:\\Users\\Cary Hutchinson\\Documents\\Programming\\...
This is a working solution with laspy:
import numpy as np
from mpl_toolkits.mplot3d import Axes3D
import matplotlib.pyplot as plt
# reading las file and copy points
input_las = laspy.file.File("test.las", mode="r")
point_records = input_las.points.copy()
# getting scaling and offset parameters
las_scaleX = input_las.header.scale