the French National Geographic Institute (IGN) is progressively releasing lidarHD data. And it looks reeeaaaalll dope.
It is expected that more and more people (from all horizons) will have an interest in these data as they continue to cover larger territories.
The files come in .LAZ format (binary), I believe GIS softwares can process them (sometimes through .LAS conversion).
Can GMT do it too ? In the form of laz2xyz maybe ?
Do you know if gdal reads it?
Would it be worth to add to gmt6.5?
It’s not that simple. laz files are highly compressed las files and would require writing an interface with lazlib (that stores way more than just x,y,z data). I have an old port in Mirone but it required patching the lazlib.dll to export the needed symbols. Don’t know how’s the current state (main developer passed away last year).
And if I wanted to tease @Andreas I would show him this but it’s needs to be resurrected (needs to update the lib and quite likely some functions that are now deprecated).
Just waiting for @Joaquim to create a time machine and anti-gravity device with Julia. That day will come. I’m sure of it.
Well, the timemachine(date::DateTime=2017) is giving its first baby steps and already took you (and back) to a little voyage to 2017. It the function cana_multiplier
cana_multiplier(wine=barrels, fishes=lots, hands=few, helpers=few)
that is more buggy
I have not worked with point cloud data directly. I use the OpenTopography system to make gridded datasets before working with airborne laser scanning point clouds. In a fairly small area they can acquire 10^7 to 10^9 points, and I don’t expect that GMT is ever going to be the right tool to work with that kind of data.
You might be interested in @weiji14’s tutorial for EGU that combines laspy for reading .laz format with pygmt for processing - https://www.generic-mapping-tools.org/egu22pygmt/lidar_to_surface.html.
I’m more inclined to use matlab.
Still, I think it would be a nice addition to pure gmt.