简介激光雷达数据处理工具集LAStools的Visual Studio编译版本是一份可直接在Windows系统下运行的软件/插件资源面向测绘、城市规划、环境研究及无人机点云处理等领域的技术人员与研究者。该编译版本运行稳定高效能够充分利用多核处理器性能支持数据格式转换、点云过滤与分类、数字高程模型构建、区域裁剪与拼接、土方体积计算等丰富功能并可通过脚本串联多个步骤实现批处理自动化。压缩包共400个文件大小10.63MB主要包含编译生成的中间代码模块、动态库、可执行程序与调试符号表等运行文件以及源代码、构建配置和说明文档兼顾直接使用与二次开发需要。目前已有365人学习下载。面对大规模激光雷达点云数据使用者无需自行搭建编译环境解除配置与编译的繁琐可快速投入实际项目也可参考自带源代码进行二次开发或功能定制。1. 从“VS编译好的LAStools工具”说起等别人编译好的不如自己按一下 F7LAStools 是激光雷达点云处理里绕不开的一整套命令行工具lasinfo 查头信息、las2las 重写点、lasground 做地面分类几乎每个跑点云数据的人电脑里都放着一份。大多数人直接下官网安装包打开 bin 目录就有现成 exe但安装包有个尴尬版本被锁死、看不到源码、想在自己程序里调 LASlib 接口也没有库文件更不用说拿到一台装着 VS 的离线机器连安装包都不好弄。标题里说的“VS编译好的LAStools工具”就是把 LAStools 源码放进 Visual Studio 里自己按 F7 编译出一整套 exe 和静态库版本、参数、调试全在自己手里。这篇给出从源码到可执行文件的可复现路径适合在 Windows 下做点云开发、又不想用黑匣子的工程师。2. 编译前先搞清楚三件事源码结构、VS 版本、依赖关系2.1 LAStools 源码目录里装了什么把 LAStools 源码包解压后根目录结构基本分四块。src/下是全部工具源码lasinfo.cpp、las2las.cpp 这类每个 cpp 对应一个命令行工具laslib/是对外提供 LiDAR 读写接口的核心库laszip/负责 las/laz 的压缩解压bin/里放的是一批 .bat 脚本演示每个工具怎么在命令行里带参数调用。我拿到源码后的第一件事永远是确认这两个库工程在不在LASlib 和 LASzip。LASlib 把点云头文件解析、点记录读写、变长记录都包了LASzip 管压缩解压后面所有工具 exe 本质都是“一个带 main 的 cpp 链接 LASlib 和 LASzip”。这两个库编译失败后面全是连锁报错先单独编它们是最稳的起步。源码包里的工具远不止单个程序las2dem、lasboundary、lasgrid 这类带 GUI 或依赖较多库的功能确实强但如果你只是要处理点云先用 lasinfo、las2las、laszip、lasmerge 这四个足够覆盖大半日常。编译时也可以只挑这几个工程出来生成不用全量编。2.2 为什么在 Windows 下优先选 VS 而不是 MinGW 或 CMake选 VS 不是因为它“正统”而是因为源码包自带可用的 Visual Studio 解决方案文件。直接打开 .sln 就可以编译不需要像 CMake 那样生成工程、也不用在 MinGW 下跟一堆 Windows 头文件兼容性纠缠。源码里有大量#ifdef _MSC_VER之类的分支本来就是按 MSVC 写的换编译器等于给自己加工作量。如果你拿到的这份源码只有 CMakeLists.txt那就用 CMake 生成 VS 工程再编生成器选 Visual Studio 2022。但常见做法是直接用 .sln所以后面按这个路线讲。另一点VS 的“生成解决方案”会把所有工具都编一遍其中一些工具依赖外部库后面讲 Boost第一次编很容易在某个工具上挂掉。我的习惯是先只生成 LASzip 和 LASlib 两个库工程确认库没问题再单独编要用的工具这样错误定位最快。值得提一句 Debug 和 Release 的区别。Release 版用于实际数据处理速度差好几倍Debug 版留着以后自己写 LASlib 插件时打断点用。两者不要混着跑下文踩坑章节会专门说。2.3 先确定三件事平台工具集、字符集、运行库打开解决方案后别急着按 F7先做三个配置动作不然报错量会直接把你劝退。第一是平台工具集。VS2022 打开老工程时通常会提示升级 v140 到 v143直接同意老代码在 v143 下能过前提是字符集和语言标准不选错。VS2019 就保留 v142VS2017 用 v141原则是“你能装哪个版本就用哪个别选提示里不存在的”。第二是字符集这是最大的坑。LAStools 的老工程很多按“使用多字节字符集”设计而 VS 新工程默认是“使用Unicode字符集”。不改成多字节一编译就是几百个 C2664函数参数无法从const char*转换到LPCWSTR这问题在避坑章节会细讲这里先记住结论。第三是运行库。项目属性 → C/C → 代码生成 → 运行库Release 下常见两种选择多线程/MT或多线程 DLL/MD。这个值必须和 Boost 的编译方式一致用 vcpkg 装的动态 Boost 就选/MD自己静态编 Boost 就选/MT混用链接阶段直接报 LNK2038。如果你只编 lasinfo 这类不依赖 Boost 的工具这个选项暂时无所谓但后面编全量工具就会炸。3. 在 Visual Studio 里把 LAStools 源码编成整套 exe逐步操作3.1 用 .sln 打开工程先编译 laszip 和 laslib操作开始前先做一个关键动作把源码解压到一个没有空格、没有中文的路径。比如放到C:\LiDAR\LAStools而不是C:\Program Files\LAStools或者D:\点云工具\LAStools。原因很现实老工程的配置里到处是硬编码的相对路径和批处理空格会引出一堆“系统找不到指定的路径”中文路径在某些工具里会直接乱码。解压后先确认拿到的是哪类工程文件用命令行看一眼cd /d C:\LiDAR\LAStools dir /b *.sln dir /b VisualStudio如果第一条dir /b *.sln有输出说明源码根目录自带解决方案直接用 VS 打开就行。有的版本把 .sln 放在VisualStudio子目录下那就进子目录再看。如果没有 .sln 但找到了 CMakeLists.txt改用 CMake 生成工程生成器选 Visual Studio 2022 x64。打开 .sln 后在“解决方案资源管理器”里能看到几十个工程。不要直接点“生成解决方案”先右键 laszip 工程点“生成”再右键 laslib 工程点“生成”。两个库都成功后剩下的工具怎么编都行。命令行编译时用 msbuild 可以精确控制先后顺序。先生成两个库msbuild LAStools.sln /t:laszip;laslib /p:ConfigurationRelease /p:Platformx64 /m/m表示多核并行编译/t指定目标工程分号分隔多个工程名/p用来传配置和平台。这个命令只在解决方案里挑这两个库生成不会碰其他工具。库编译成功后再全量生成msbuild LAStools.sln /p:ConfigurationRelease /p:Platformx64 /m这次会把这套工具全部编出来输出目录下能看到的 exe 数量取决于源码里包含多少工具工程。如果某个工具比如依赖 GUI 库的 lasview编译失败它不会影响已经成功的工程稍后单独排查就好。3.2 把单个工具设成启动项目按 F7 生成 exe如果不是全量处理其实没必要编全套。实际项目里最常用的是 lasinfo、las2las、laszip、lasmerge、las2txt这五个编出来就够支撑日常点云检查和格式转换。编单个工具很简单。找到 lasinfo 工程右键 → 设为启动项目再右键 → 生成或者直接按 F7。VS 只会编译这个工具和它依赖的库工程不会碰其他无关工具。生成成功后在输出窗口能找到 exe 的完整路径一般就在C:\LiDAR\LAStools\bin\Release\下。生成完成后验证一下 exe 是否真的能用在命令行里执行C:\LiDAR\LAStools\bin\Release\lasinfo.exe -version正常会打印出 LASlib 的版本信息、编译选项和版权声明。能看到这段输出说明 VS 编译好的 LAStools 工具已经能独立运行了。这里注意很多工具双击 exe 是没有反应的它们必须带命令行参数运行双击打开只是闪一下就退出这是正常现象不是编译坏了。3.3 Debug 版和 Release 版分开输出避免 exe 互相覆盖老工程默认把输出目录写在相对路径上Debug 和 Release 的产出经常混到一个文件夹里。你今天编了 Release明天为了调试改了配置又编一次 Debugexe 直接被覆盖几天后自己也分不清手上到底是哪个版本。这问题我踩过不止一次。项目属性 → 常规 → 输出目录改成$(SolutionDir)bin\$(Configuration)\这样 Release 的 exe 进bin\ReleaseDebug 的进bin\Debug。命令行下用批处理跑数据时只要在脚本里写对应路径就不会拷错库、跑错版本。这个配置所有 LAStools 工程最好统一改改法是在解决方案里多选工程然后统一设置属性VS 支持批量改。改完之后建议把bin\Release加到系统 PATH 里或者在你自己的批处理脚本开头写上set PATHC:\LiDAR\LAStools\bin\Release;%PATH%后面所有 las 工具都能直接裸敲命令名调用不用每次写一长串绝对路径。这招对批量处理大量 las 文件非常省事批处理脚本也会干净很多。4. 六个必调参数和工程配置避开“编译通过、一跑就崩”4.1 参数表照着改就不会半夜在群里求助编译 LAStools 时真正影响成败的就六个配置项。其他选项保持默认先看这张表配置项推荐值选错或漏改的后果配置ReleaseDebug 版性能差 5~10 倍跑大数据慢到怀疑人生平台x64Win32 编译出来内存受限处理稍大的 laz 直接崩溃平台工具集v143VS2022/ v142VS2019提示找不到 v140 工具集无法开始生成字符集使用多字节字符集几百个 C2664API 参数类型转不过去运行库与 Boost 方式匹配的 /MT 或 /MD链接阶段 LNK2038运行库不匹配Windows SDK 版本下拉框里选已安装的版本提示找不到 Windows SDK 版本无法解析工程前两个不用解释x64 平台是点云处理的基础32 位进程开一个超过 2GB 的文件就难以为继。平台工具集和 SDK 版本属于 VS 安装环境问题装 VS2022 时选了“使用 C 的桌面开发”工作负载这两个一般都有下拉框里选择你机器上存在的版本即可。字符集和运行库是编译的硬门槛。字符集选错错误日志里全是 Unicode 转换问题一眼望去以为是源码版本太老实际上是工程配置没跟上。运行库则要结合 Boost 的编法一起决定静态编 Boost 和动态编 Boost 对应不同的值。4.2 语言标准、预处理器和警告设置老代码需要被“惯着”LAStools 源码有年头了新编译器默认的标准和警告级别会让它闹脾气。C/C → 语言 → C 语言标准选“默认”或者 C14不要选 C17/C20更不要选“预览最新草案”。老代码里很多隐式转换在新的语言标准下直接升级成错误没必要为了尝鲜给自己加活。C/C → 命令行 → 附加选项建议加上这两个宏_CRT_SECURE_NO_WARNINGS;_CRT_NONSTDC_NO_DEPRECATE加了之后fopen、strcpy 这类函数的安全告警会少一大半。这不是必须的不影响链接结果但能让你把注意力放在真正的错误上而不是每天面对一堆“warning C4996”刷屏。还有一处C/C → 语言 → 符合模式如果报错 C2760记号不允许把“符合模式”设为“否”老代码经常触发这个。这些设置看起来琐碎但它们决定了你编译时是“一版过”还是“报错到半夜”。我见过太多人卡在 C4996 刷屏里以为源码有问题其实只是没给老代码穿对衣服。4.3 Boost 依赖到底要怎么给 VS 指路LAStools 部分工具依赖 Boost主要是 filesystem 和 thread 这两个子库。如果你只用 lasinfo、laszip、lasmerge可以完全不管 Boost但如果要编 las2dem、lasboundary 这类就必须先把 Boost 配好。我推荐用 vcpkg 安装命令如下vcpkg install boost:x64-windows vcpkg integrate installvcpkg integrate install会在 VS 里注册环境安装完成后新开的 VS 会自动带上 Boost 的包含目录和库目录。如果你不想用 vcpkg也可以下载 Boost 源码自己用 b2 编译参数要记牢b2 address-model64 linkstatic runtime-linkstatic --build-typecomplete这里linkstatic对应工程里运行库选/MTruntime-linkstatic表示静态连运行时。如果你用的是 vcpkg 默认编出来的动态 Boost工程运行库要选/MD。两者对应关系错了链接就会出现 LNK2038 或者找不到 boost_filesystem 的 lib。还不放心的话可以手动确认一遍工程配置。项目属性 → VC 目录 → 包含目录能看到 vcpkg 自动添加的路径如果没有把 vcpkg 的 include 路径手动加进去库目录同理。每台机器环境不一样手动指定路径虽然啰嗦但一次配好之后整套工具基本不会再出 Boost 相关的问题。5. 编译 LAStools 的常见坑与排查5.1 “生成解决方案”全面报错但单独编译 laslib 是好的现象点“生成解决方案”几十个工程里一大半失败错误列表拉都拉不完但右键 laslib 单独生成却秒过。原因失败的多半是依赖 Boost 的工程比如 las2dem、lasboundary、lasgrid。Boost 路径没配好这些工程在预编译阶段就找不到boost/filesystem.hpp报错一个接一个。解决先单独编 laslib、laszip 和你要用的核心工具把不依赖 Boost 的先拿下。之后再看失败工程的第一行错误如果开头是cannot open source file boost/filesystem.hpp按 4.3 节配 Boost如果开头是 LASlib 头文件找不到检查 VC 目录里的附加包含目录是否指到了源码的 laslib 目录。记住一条经验全量失败时看第一行错误别翻几十行后面的花絮。5.2 一编译就是几百个 C2664const char* 转不了 LPCWSTR现象刚打开工程按下生成错误列表直接几百行全是 C2664很多集中在文件路径、字符串参数、命令行解析这几个函数上。原因工程属性里字符集设成了“使用 Unicode 字符集”。LAStools 老代码内部大量按多字节处理字符串和命令行参数VS 的 Unicode 宏把 API 转发到了宽字符版本两者对不上。解决工程属性 → 常规 → 字符集改成“使用多字节字符集”。改完重新编译这一整类报错基本消失。这是 LAStools 在 VS 上编译最高频的坑没有之一。很多从网上下源码的新手第一步就折在这里。5.3 链接阶段 LNK1104找不到 boost_filesystem 的 lib现象编译阶段全部通过到了链接阶段报错类似LNK1104 cannot open file boost_filesystem-vc143-mt-x64-1_8x.lib后面还有一串版本号。原因这个 lib 名称是工程配置里写死的命名规则它要求 Boost 按照固定的“工具集 线程 地址模型”约定命名并放到指定目录。vcpkg 装的 Boost 使用的命名规则或者版本号和工程预期对不上或者 Boost 装了但没装 filesystem 子库。解决先确认 vcpkg 里 install 了哪些 Boost 子库vcpkg list看一下。没有 filesystem 就补装boost-filesystem:x64-windows。有的话检查工程属性 → VC 目录 → 库目录是否真的指向了 Boost 的 lib 目录。还有一种更直接的办法把工程里写死的 Boost 版本宏找到一般在src/某个公共头文件里改成你实际安装的 Boost 版本号。这样 VS 按新版本号去找 lib名称就对得上了。5.4 生成成功一运行就提示找不到 laslib.dll 或 laszip.dll现象编译毫无问题exe 也生成出来了但双击或命令行里运行弹出“无法启动此程序因为计算机中丢失 laslib.dll”。原因工程默认动态链接 LASlib 和 LASzip运行时需要这两个 DLL 在 exe 能找到的目录里。VS 的调试环境会把 DLL 路径临时带进去你自己跑到命令行里执行时没人帮你带路径。解决到 laslib 和 laszip 的输出目录把两个 DLL 复制到你的工具 exe 同一个目录下。更省心的办法按 3.3 节把输出目录统一成bin\Release然后让库工程和工具工程都往这里输出这样 exe 和 DLL 永远在一起。运行库选/MD的话还要留意 vcruntime 系列不过一般 Windows 10/11 自带的就够了。5.5 双击 exe 没有任何反应窗口一闪而过现象编译成功exe 双击一下黑窗口闪一下就没了于是认为“编译好的工具”是坏的。原因LAStools 所有工具设计上都要带命令行参数运行没有参数时它打印几行帮助就退出了这是正常行为不是编译失败。解决打开 cmd切到 bin 目录再执行例如lasinfo -i C:\LiDAR\data\test.las或者直接执行lasinfo -h查看帮助。用批处理也好用 PowerShell 也好只要记住“LAStools 工具是命令行程序”这一个事实后面就能避免很多误判。5.6 Debug 和 Release 的产物混用现象今天用 Release 版本跑出了结果明天在 Debug 下又跑一遍程序在运行过程中断言报错或者内存崩溃数据量越大越明显。原因Debug 和 Release 用的 C/C 运行库不同LASlib 的库文件混进错误的目录exe 链接了不同配置的库内部结构对不上。解决严格执行 3.3 节的输出目录隔离Debug 库和 Release 库分开存放脚本里固定写 Release 路径。遇到数据异常需要 Debug 排查时单独建一个临时目录把 Debug 的 exe 和 DLL 放进去跑不要污染主环境。这条不是 LAStools 特有的问题任何 C 项目都适用只是 LAStools 老工程默认输出混乱更容易踩到。6. 编译完怎么验收半小时验证“编译好的工具”不是黑匣子编译成功后先别急着上生产数据花半小时做一轮验收确认这套自己按 F7 出来的工具真的可用。先跑通一个最小命令确认真实数据能打开lasinfo -i C:\LiDAR\data\test.laz -cd这个命令会打印点云的范围、点数、坐标边界-cd 是只显示坐标范围速度快。能正常输出说明 LASlib 的读写、LASzip 的解压、命令行解析全部工作正常。再来一轮回归对比。找一个你手上已有的、从别处获得的 LAStools 安装包把同一个数据分别用两个版本跑一遍 lasinfo输出做文本比对lasinfo -i sample.las official.txt C:\LiDAR\LAStools\bin\Release\lasinfo -i sample.las selfbuilt.txt fc official.txt selfbuilt.txt输出一致说明自编译版本和官方版本行为完全对齐可以放心用。输出不一致也不是一定有问题有时候是版本号字段的差异重点看点数、范围、坐标偏移这些核心字段是否一致。最后一个建议。如果你编译 LAStools 不只是为了用现成工具而是要在自己的程序里调用 LASlib那最好花十分钟写个最小的读写测试。这个技巧是我后来养成的习惯每次换环境、换编译器、换 Boost 版本先跑一遍这个最小的读写循环再干别的#include lasreader.hpp #include laswriter.hpp LASreadOpener readOpener; readOpener.set_file_name(input.las); LASreader* reader readOpener.open(); if (!reader) return -1; long long pointCount 0; while (reader-read_point()) { pointCount; } reader-close(); LASwriter* writer 0; LASwriteOpener writeOpener; writeOpener.set_file_name(output.las); writer writeOpener.open(reader-header); // 重新读取一遍点并写入验证读写链路 reader-close(); if (writer) writer-close(); return 0;这段代码只要能在 Debug 下跟断点走通说明 LASlib 的头文件、lib、DLL 全部搭配正确后面写自己的点云工具就有底了。我早期编译完 LAStools 就直接拿生产数据跑结果用的还是旧 exe浪费了一下午。后来固定顺序编完先看版本号再跑基线对比最后才上数据。磨刀不误砍柴工这半小时值得花。希望帮到你。本文还有配套的精品资源点击获取