Register | Login
Attackpoint - performance and training tools for orienteering athletes

Discussion: Correcting LIDAR data for use in Kartapullautin

in: Orienteering; General

Feb 4, 2020 9:25 PM # 
Trying to convert some CT lidar (NAD83 CT State Plane) which is in feet, to metric for processing in Kartapullautin. Using las2las.exe but it keeps resulting in tiles with far too many contours. Not sure if I'm using the wrong command line arguments, or perhaps in the wrong order to be interpreted correctly.

Anyone here process NAD83 data and care to share your las2las syntax so I can deduce where I'm going wrong? Thanks..
Feb 4, 2020 9:47 PM # 
"Far too many contours" ... do you mean after KP processing, and are you looking at the "contours03.dxf" (raw file in ... 0.25m (maybe?) interval) or "out2.dxf", which is the final contours with (by default) 2.5m interval contours? Use "out2.dxf", if you're not.

That said: to answer your question, I have successfully used:

las2las -i INFILE.laz -o OUTFILE.laz -target_utm 18N -feet -elevation_feet

18N is something different where you live, which you probably already know. :)

Does that help? If not, get us the output of:

lasinfo FILE.laz
Feb 4, 2020 10:13 PM # 
This should work for a quick fix: The NOAA data viewer has the most recent CT lidar data, and that site lets you specify what options you want before downloading, e.g., meters or feet, state plane or UTM, las or laz, etc. The url is:

I'm guessing you're getting the CT lidar from the UCONN Magic site (at least it was the Magic site last time I used it). The NOAA site has the exact same lidar files, just with better user options.
Feb 4, 2020 10:17 PM # 
Best answer, RickD! Assuming it’s public data.
Feb 4, 2020 10:26 PM # 
It is public--your tax dollars at work....
Feb 4, 2020 11:29 PM # 
Thanks Rick, I'll check the NOAA site. I was pulling 2016 data from UConn (now CTECO). Just trying to come up with a quick and dirty map for some explorations I need to do on Saturday.

{edit} seemed pretty painless, and easier to box a region than downloading individual tiles... We'll see what it looks like when it shows up...
Feb 5, 2020 12:22 AM # 
moving laz file to meters:
las2txt -i tile_1300000_195000.laz -o -scale_x 0.3048 -scale_y 0.3048 -scale_z 0.3048 -parse xyzcnri
output is xyz text file, but pullauta.exe can understand it.

What is xyzcnri?
xyz -- coordinate/altitude
c - classification -- this is one of the LIDAR classifications from the laz file, e.g. - "Lidar Return types to import"
Feb 5, 2020 1:27 AM # 
This will work for you specifically.

las2las -i "FILEPATH\FILENAME.las" -target_utm 18N -target_precision 0.00025 -olaz -sp83 CT -survey_feet -vertical_navd88_geoid12b

I recommend if you're doing multiple tiles that you merge the tiles prior to transforming then split if desired or you may have some discontinuities along the tile edges.

At least the one file I looked at is messed up - the separate metadata is correct but the file is wrong which is why it was causing you issues.

Getting the data from NOAA is much better - the national sources do a much better job providing data.
Feb 5, 2020 1:59 AM # 
@RickD: hah! Yeah, I meant that the data he had was public, not a private source.
Feb 5, 2020 12:45 PM # 
@hughmac4 - I hadn't even looked at the dxf contour files. I was just trying to get a quick PNG to have in hand for a quick exploratory run later this week.

@RickD - the pre-corrected data from NOAA did the trick. It was large enough that they sent it as numerous tiles anyway, but I merged them into one large las file and processed overnight - I'll lay a few of the obvious features on top in OOM and should be good to go.

Thanks all for the input..
Feb 5, 2020 1:31 PM # 
But of course you could have just used OCAD 12 or OCAD 2019 and the DEM Import Wizard function would have taken the .laz files as is and produced your map in minutes, not hours, I'm guessing.
Feb 5, 2020 1:56 PM # 

I have been recently filling some holes in - just for fun - by processing missing tiles with my home laptop. Original 2016 coverage at left, current at right. About 15000 km2 new map now. If I got figures right Karttapullautin seems to process about 7 tiles (3x3 km tiles) per hour, that makes about 1 min/km2. I've been processing 16 tiles parallel with octacore laptop. Slow, but with thin enough data (~1 pt/m2), parallel processing and enough cores makes it not that bad.
Feb 5, 2020 2:34 PM # 
Mr Wonderful:
But of course you could have just used OCAD 12 or OCAD 2019 and the DEM Import Wizard function would have taken the .laz files as is and produced your map in minutes, not hours, I'm guessing.

I couldn't figure out how to get OCAD to handle planar feet, just elevation feet, so I thought it was necessary to reproject first, unless you are never going to get open street stuff at 3.xx times scale to help with trails etc. If there's a way to skip that, please let me know!
Feb 5, 2020 3:16 PM # 
As I understand it the original LiDAR was in the Grid coordinate system US State plane projection system (ft US). Right?
OCAD wants it in the equivalent UTM in meters so it will do that conversion for you.
There is an article by David Fisher, SLOC that explains the process. He is using OCAD 12 but the process is pretty well identical for OCAD 2019.
Feb 5, 2020 9:53 PM # 
Gord - I am not running Windows. OCAD 2019 does run under Wine, but there are some issues so its not my first choice. In particular it doesn't play nice with HiDPI monitors so the menu text is barely legible on my system.
Feb 5, 2020 10:38 PM # 
Too bad. I'm sorry for your difficulty which I definitely do not understand.

Please login to add a message.