企业官网建设流程全解析

1. 先搞清楚这套工具在链路里的位置

卫星影像三维重建这条链路，说长不长，说短也不短。从原始推扫影像到最终能用的三维产品，中间要跨过辐射校正、几何模型、连接点匹配、区域网平差、密集匹配、点云融合、DSM 生成、正射纠正好几个环节。Danesfield 就是这条链路上的一个开源实现，定位很明确：拿一批带 RPC 参数的高分辨率卫星影像，跑出一套可量测的三维成果，包括稀疏连接点、密集点云、数字表面模型和正射影像。它不是那种点几下鼠标就能出图的桌面软件，而是一套以命令行脚本驱动、分阶段落盘、每个阶段都能单独检查和干预的摄影测量管线。

我最初接触它，是因为手头有一批卫星影像要做地形级三维重建，商业软件授权成本高，而且流程像个黑盒，中间哪一步出了问题很难定位。Danesfield 的好处在于每个阶段的输入输出都是明文文件，匹配点、平差残差、点云、日志全都能翻出来看。坏处也很明显：文档偏工程化，依赖不少，参数需要自己摸。它适合有一定摄影测量基础、愿意读日志、能接受命令行操作的开发者或研究人员；如果你只想找一个“导入影像点生成”的傻瓜工具，这套东西会让你很痛苦。

这篇内容围绕实际使用展开，把环境准备、数据准备、分阶段跑通、参数取舍、问题排查这几个环节拆开讲。文中涉及的具体命令和配置字段，我会尽量给出示意写法，实际版本可能略有差异，跑之前建议先对照仓库里的示例配置确认一遍。这一点很关键，我见过不少人直接复制网上的命令，结果卡在参数名对不上。

1.1 卫星影像三维重建的基本链路

卫星影像和无人机影像的最大区别，在于相机模型。无人机通常用针孔模型加畸变参数，卫星推扫影像用的是有理多项式模型，也就是每张影像配一个 RPC 文件，里面包含 80 个系数，把地面点的经纬度高程映射到影像行列号。这个模型是拟合出来的，精度通常在米级到亚米级，单张影像直接交会也能出三维点，但多张影像之间会有系统偏差，所以必须做区域网平差。

完整链路可以拆成六步。第一步是数据整理，把影像、RPC、元数据对齐；第二步是特征提取与匹配，在影像重叠区找同名点；第三步是区域网平差，用同名点约束每张影像的 RPC 偏置，把整体几何一致性拉回来；第四步是密集匹配，在核线近似约束下逐像素找对应点，反投影成三维点云；第五步是点云融合与滤波，去掉误匹配和遮挡产生的飞点；第六步是栅格化，生成 DSM，再用 DSM 做正射纠正。Danesfield 的阶段划分基本对应这六步，只是把数据整理和预处理合并了。

理解这条链路的意义在于，你能判断问题出在哪。很多人一看到点云空洞就怀疑密集匹配参数，实际上源头可能是平差没收敛，连接点本身就有系统偏差。三维重建是个串联系统，前一级的误差会往后传，而且会被放大。所以我在实际项目里，宁可花一半时间在连接点和平差上，也不愿意后期对着点云反复调滤波。

1.2 Danesfield 的设计取向：脚本管线加分阶段落盘

Danesfield 的工程结构是典型的“主脚本加阶段脚本”模式。主入口脚本读取一份配置文件，按阶段依次调用可执行程序，每个阶段的输出写到独立目录。这样做的好处是可恢复：某个阶段跑崩了，改完参数从那个阶段续跑，不用从头再来。另一个好处是可检查：每个阶段的中间结果都能单独拿出来看，匹配点够不够、平差残差大不大、点云密度合不合理，一目了然。

它的配置通常分全局段和阶段段。全局段管工作目录、线程数、日志级别；阶段段管该阶段的算法参数，比如特征点的数量上限、匹配的搜索半径、平差的最大迭代次数。配置文件一般是键值对或者类似 INI 的格式，具体字段名各版本有差异。我的习惯是先跑一遍最小数据集，把生成的目录结构摸清楚，再对照日志逐个理解参数的作用，而不是一上来就对着文档调参数。

分阶段落盘还有一个隐含要求：磁盘空间要留够。密集匹配阶段的中间文件可能是原始影像的好几倍，点云文件也不小。我一般按原始数据量的五到八倍预留空间，跑之前先用df -h看一眼，别等跑到一半磁盘满了，进程直接挂掉，日志还来不及写。

1.3 它适合谁、不适合谁

适合的人群很具体：做遥感影像处理的研究人员、需要批量处理卫星影像的工程团队、想研究摄影测量算法细节的开发者。它的优势是流程透明、可干预、可二次开发，你能改匹配策略、换平差模型、接自己的滤波算法。不适合的人群同样具体：需要开箱即用、不愿意碰命令行、对摄影测量原理不熟、数据量只有几张影像且要求快速出图的用户。这类需求用桌面软件更省时间。

还有一个现实问题：Danesfield 对数据质量比较敏感。影像云量大、重叠度低、时间跨度大、地表纹理弱，跑出来的结果都不会太好看。它不是那种靠算法强行弥补数据缺陷的工具。所以用它之前，先花时间筛数据，比后期调参数划算得多。

2. 环境准备：别急着跑脚本，先把地基打稳

环境这一步最容易出问题，而且报错信息往往指向性不强。我见过编译时报某个库找不到，折腾半天发现是版本不匹配；也见过运行时报段错误，最后定位到内存不够。Danesfield 的依赖主要包括 C++ 编译工具链、Boost、Eigen、OpenCV、GDAL、PROJ，以及用于并行的 MPI 或者线程库。不同版本对这些依赖的版本要求不一样，建议优先看仓库里的构建说明，按它推荐的版本组合来，不要盲目追新。

操作系统层面，主流 Linux 发行版都比较稳，Ubuntu 和 CentOS 系用得比较多。Windows 不是不能跑，但依赖配置麻烦，出了问题参考资料少，不建议新手折腾。我自己的习惯是在一台单独的机器上做编译和测试，跑通最小数据集之后再迁移到正式的计算节点，避免在正式环境里反复试错。

2.1 硬件与操作系统的现实配置

硬件方面，CPU 核心数比单核频率更重要，因为特征提取、匹配、密集匹配都能并行。内存是硬约束，卫星影像的像素量摆在那里，一张一亿像素的影像解成浮点数组就是几百兆，几十张一起处理，加上中间缓存，64GB 内存只能算起步，128GB 会舒服很多。磁盘建议用 SSD，密集匹配阶段大量随机读写，机械盘会把时间拖得很长。

显卡不是必须的，但如果你的版本支持 GPU 加速的特征提取或者密集匹配，一块显存够大的卡能明显缩短时间。这里要注意，GPU 加速往往需要重新编译并打开对应开关，默认构建不一定启用。我一般先用纯 CPU 跑通流程，确认结果正确，再考虑开 GPU 优化速度，不然出了问题分不清是算法还是加速模块的锅。

操作系统配置上，有几个细节值得提前处理。文件句柄数限制调高，密集匹配会同时打开不少文件；临时目录指向大容量磁盘，有些库默认往/tmp写中间文件；关闭不必要的自动更新，避免跑到一半依赖库被升级。这些都是小事，但真碰上会让人很烦。

2.2 依赖库与编译时的几个关键开关

依赖安装建议用系统包管理器打底，缺什么补什么。Boost 和 Eigen 一般用系统版本就够，OpenCV 和 GDAL 要注意版本，太老的版本可能缺接口，太新的版本可能有 ABI 变化。PROJ 负责坐标转换，版本和数据目录要匹配，否则会出现坐标转换失败或者精度异常。

编译时的关键开关主要有几个：是否启用 MPI 并行、是否启用 OpenMP、是否链接 GPU 模块、优化等级。MPI 适合多机或者多进程并行，单机多核用 OpenMP 更简单。优化等级建议用-O2或者-O3，调试阶段可以加-g保留符号，方便崩溃时定位。如果编译报链接错误，先看库的搜索路径，再看库的版本是否匹配，最后看编译器和库的 ABI 是否一致。

一个常见的坑是多个版本的库混装。比如系统里同时存在两个版本的 GDAL，编译时找到的是 A 版本，运行时加载的是 B 版本，表现就是启动即崩或者某个功能异常。排查方法是看链接时的库路径和运行时的库搜索路径是否一致，用ldd检查可执行文件依赖的实际库文件。

2.3 工作目录与配置文件怎么组织

工作目录建议按“项目、阶段、日期”三级组织，不要把不同项目的数据混在一起。一个典型的目录结构是这样：

project/ ├── config/ │ └── project.cfg ├── input/ │ ├── images/ │ └── rpc/ ├── work/ │ ├── stage0_init/ │ ├── stage1_match/ │ ├── stage2_ba/ │ ├── stage3_dense/ │ └── stage4_raster/ ├── logs/ └── output/

配置文件放在config下，输入影像和 RPC 分目录存放，工作目录按阶段划分，日志单独放，最终产品放output。这样组织的好处是，出问题能快速定位到阶段，重跑时也只影响对应目录。

配置文件的关键字段通常包括输入路径、输出路径、线程数、日志级别、各阶段开关和参数。我的习惯是保留一份“最小可跑”配置，只放必填项，用来验证环境；再保留一份“生产”配置，把调过的参数都写进去并加注释。配置里不要写死绝对路径中的用户名或者临时目录，换机器跑的时候容易出问题。

[global] work_dir = /data/project/work input_image_dir = /data/project/input/images input_rpc_dir = /data/project/input/rpc output_dir = /data/project/output num_threads = 32 log_level = info [stage1] max_features = 20000 match_ratio = 0.8 [stage2] max_iterations = 50 outlier_threshold = 2.0 [stage3] downsample_factor = 2 min_elevation = 0 max_elevation = 800

上面这段只是示意，字段名和取值要以实际版本为准。重点在于理解每个字段控制什么，而不是照抄数字。比如match_ratio控制匹配时的比值检验阈值，值越大保留的匹配越少但越稳；outlier_threshold控制平差时剔除粗差点的残差阈值，单位通常是像素。

3. 输入数据准备：RPC 与影像质量决定上限

三维重建的上限由输入数据决定，这句话在卫星影像上尤其成立。影像重叠度不够，连接点就少；云量大，匹配就被遮断；时间跨度大，地表变化会让同名点对不上；RPC 精度差，平差就要花更大力气去拉。Danesfield 能做的，是在数据质量允许的范围内把几何一致性做到最好，它没法凭空补出不存在的信息。

我一般把数据准备分成三件事：筛影像、查 RPC、做预处理。筛影像看重叠度、云量、视角差异；查 RPC 看文件是否齐全、坐标系是否一致、精度标注是否合理；预处理包括匀色、降采样、生成掩膜。这三件事做完，再开始跑流程，返工概率会低很多。

3.1 影像选型与云量、重叠度

卫星影像的重叠度分航向和旁向。航向重叠建议不低于 60%，旁向不低于 30%，这是保守值，实际项目里重叠度越高，连接点越多，平差越稳。但重叠度也不是越高越好，影像太多会增加计算量，而且时间跨度大的影像之间地表变化明显，反而引入错误匹配。我的经验是，同一区域选时间相近、云量低、视角差异适中的一批影像，比堆一大堆不同时期的影像效果更好。

云量筛选不能只看元数据里的云量百分比，那个数字经常偏乐观。薄云、碎云、云影在百分比上看不出来，但对匹配影响很大。有条件的话，先做一遍快速目视检查，或者用简单的云检测跑一遍，把云区占比高的影像剔掉。云影比云本身更麻烦，因为它会让地表纹理变暗，特征点响应变弱，匹配容易失败。

视角差异也要看。卫星影像的侧摆角不同，同一地物的成像几何不一样，视角差太大时，特征描述子的相似度会下降。一般来说，侧摆角差异控制在合理范围内，匹配成功率会高不少。具体范围要看传感器和分辨率，没有统一标准，我的做法是先拿几张影像试匹配，看匹配点数量和分布，再决定要不要加入更多影像。

3.2 RPC 文件的坑

RPC 文件是卫星影像几何处理的命门。常见问题有几个：文件缺失、文件与影像不对应、坐标系定义不一致、RPC 精度本身很差。文件缺失好办，补齐就行；文件与影像不对应最麻烦，跑出来的结果会整体偏移或者扭曲，而且不容易发现。我的做法是每次拿到数据先做一次抽样检查，用 RPC 把影像角点投影到地面，看看落点是否合理，再反算回来看看误差有多大。

坐标系不一致也很常见。有的 RPC 用经纬度高程，有的用投影坐标，有的高程基准不统一。Danesfield 内部一般会做坐标转换，但前提是配置里的坐标系定义正确。如果配置写错，平差可能不报错，但结果整体偏移。排查方法是找几个已知地面控制点，比较反投影误差，如果整体偏移量很稳定，多半是坐标系或者基准的问题。

RPC 精度差的情况也有。有些影像的 RPC 是粗略拟合的，单张定位误差可能到几米甚至十几米。这种情况下，平差阶段的连接点要足够多、分布要足够均匀，才能把系统偏差拉回来。如果影像本身重叠度低、连接点少，平差结果就会很不稳。这种数据我一般会先降低预期，或者补充控制点。

3.3 影像预处理：匀色、降采样、掩膜

匀色不是必须的，但对匹配有帮助。不同时间、不同传感器、不同大气条件下的影像，辐射差异可能很大，特征描述子对亮度变化有一定鲁棒性，但差异太大时匹配点还是会减少。简单的直方图匹配或者相对辐射归一化就能改善，不需要做得很复杂。

降采样是控制计算量的常用手段。高分辨率影像的像素量很大，全分辨率跑密集匹配对内存和时间都是考验。我的做法是先用降采样影像跑特征匹配和平差，确认几何没问题，再用全分辨率跑密集匹配。降采样因子根据分辨率和目标成果精度来定，一般二到四倍比较常见。注意降采样时 RPC 也要做对应调整，或者用工具重新生成，否则坐标会错。

掩膜主要用来排除无效区域，比如影像边缘、云区、水体。水体在密集匹配里基本出不了点，留着只会增加误匹配。云区同理。掩膜可以在预处理阶段生成，也可以在匹配阶段用参数控制。我倾向于先生成掩膜文件，流程里显式引用，这样每个阶段都能复用，也方便检查。

4. 分阶段实操：从特征匹配到平差

环境和数据准备好之后，就可以进入实操阶段。Danesfield 的流程按阶段推进，每个阶段有独立的输入输出。我的建议是不要一上来就跑全流程，先在最小数据集上逐个阶段跑通，确认每个阶段的输出符合预期，再扩大数据量。这样出问题时容易定位，不会一锅粥。

最小数据集一般选三到五张影像，重叠度好、云量低、纹理丰富。跑通标准是：特征匹配阶段有足够多的连接点，平差阶段收敛且残差合理，密集匹配阶段能生成连续点云。这个标准看起来简单，但实际跑的时候，每个阶段都可能卡住。

4.1 阶段一：特征提取与匹配

特征提取一般用 SIFT 或者类似的尺度不变特征。卫星影像的视角变化相对小，SIFT 基本够用；如果视角差异大或者地表纹理特殊，可以考虑仿射不变特征，但计算量会上去。特征点数量上限要控制，太多会增加匹配时间，太少会影响平差稳定性。我的经验是每张影像保留一万到两万个特征点，具体看影像分辨率和纹理丰富程度。

匹配阶段的关键参数是搜索策略和比值检验阈值。卫星影像的匹配搜索范围可以由 RPC 预测，也就是先用 RPC 把地面格网投影到影像上，估计同名点的初始位置，在这个位置附近搜索。这样比全图搜索快得多，也能减少误匹配。比值检验阈值控制匹配的严格程度，阈值小则匹配少而稳，阈值大则匹配多但可能混入错误点。

# 示意命令，实际参数名以版本为准 ./run_stage1_match.sh \ --config config/project.cfg \ --max-features 20000 \ --match-ratio 0.8 \ --search-radius 64

跑完之后要检查匹配点数量和图分布。数量太少，说明纹理弱或者参数太严；分布不均，说明某些区域被云或者阴影遮住了。匹配点最好在影像重叠区均匀分布，不要集中在某一个角落，否则平差时几何约束不够。

4.2 阶段二：光束法平差

平差阶段用连接点约束 RPC 偏置。卫星影像的 RPC 模型通常只校正少数几个偏置参数，而不是重算全部系数。常见做法是每张影像估计行列方向的平移和线性漂移，也就是几个参数。这样做的好处是稳定，不会因为连接点不足导致模型过拟合。

平差的关键参数是迭代次数、粗差剔除阈值和连接点数量下限。迭代次数一般几十次就够，收敛后会自动停；粗差剔除阈值按像素残差设，常用一到三个像素；连接点数量下限用来剔除弱连接影像，低于下限的影像可能不参与平差或者需要人工检查。

./run_stage2_ba.sh \ --config config/project.cfg \ --max-iterations 50 \ --outlier-threshold 2.0 \ --min-connections 50

平差跑完，重点看三样东西：残差分布、每张影像的连接点数量、整体收敛情况。残差应该是零均值、小方差的分布，如果有明显的系统性偏移，说明模型或者数据有问题；连接点数量太少或者分布不均的影像，平差结果不可靠；收敛情况看日志里的迭代残差曲线，正常应该快速下降然后趋于平稳。

4.3 平差结果怎么判断好坏

判断平差好坏，不能只看残差大小。残差小不代表几何正确，可能是因为连接点太少、约束太弱，模型没怎么动。更可靠的方法是做检查点验证：找一些已知地面坐标的点，用平差后的模型反投影，看误差有多大。如果没有检查点，可以用影像重叠区的一致性来间接判断，比如同一地物在不同影像上的反投影位置是否一致。

还有一个实用技巧：看平差前后的 RPC 偏置量。偏置量应该在合理范围内，如果某张影像的偏置量特别大，说明这张影像的 RPC 本身有问题，或者匹配点有系统误差。这种情况下，要么剔除这张影像，要么单独检查它的数据。

5. 密集匹配与三维产品生成

平差通过之后，几何框架就稳了，接下来是密集匹配。密集匹配的目标是给每个像素找对应点，反投影成三维点云。这一步的计算量和内存消耗最大，参数也最多。核心思路是在核线近似约束下，沿某个方向搜索同名点，用相似性测度找最佳匹配，再用一致性检查剔除错误。

卫星影像的核线不像框幅式影像那么规整，一般用 RPC 投影近似。搜索范围由高程范围决定，高程范围设得越宽，搜索范围越大，计算量越大，误匹配风险也越高。所以高程范围要尽量收紧，用先验 DEM 或者稀疏点云的高程统计来确定。

5.1 密集匹配的参数取舍

密集匹配的关键参数包括降采样因子、高程范围、匹配窗口大小、一致性阈值。降采样因子控制分辨率和计算量，因子越大越快但细节越少；高程范围控制搜索空间，太宽会增加误匹配；匹配窗口大小影响纹理弱区的匹配稳定性，窗口大则稳但边缘模糊；一致性阈值控制左右一致性检查的严格程度，用来剔除遮挡和误匹配。

我的经验是，先用大降采样因子跑一遍，看整体点云形态是否合理，再逐步提高分辨率。高程范围先用稀疏点云的高程统计加一定余量，跑完看有没有明显的截断或者拉伸。匹配窗口在水体、阴影、裸地这些弱纹理区可以适当放大，在建筑密集区要适当缩小，避免跨建筑匹配。

./run_stage3_dense.sh \ --config config/project.cfg \ --downsample 2 \ --min-elevation 0 \ --max-elevation 800 \ --window-size 5 \ --consistency-threshold 1.0

内存估算有个粗略公式：总内存约等于影像总像素数乘以通道数乘以单像素字节数，再乘以并行度和中间缓存的系数。比如三十张八千万像素的影像，总像素二十四亿，按三通道浮点算就是二十八 GB 左右，再乘二到三倍的中间缓存，六十四 GB 内存就很紧张。这种情况下要么降采样，要么分块跑，要么减少同时处理的影像对数。

5.2 点云融合与去噪

密集匹配输出的是逐影像对的点云，需要融合成统一的多视点云。融合的过程会做一致性检查，把多视不一致的点去掉。这一步能去掉不少飞点，但也会在遮挡区留下空洞。融合之后通常还要做统计滤波，去掉离群点，再做一次栅格化前的平滑。

去噪要克制。过度滤波会把细小地物抹掉，比如电线杆、围墙、小建筑。我的做法是先保留原始点云，另存一份滤波后的版本，栅格化时用滤波版，需要细节时再回原始点云查。滤波参数按点云密度和地物尺度来定，统计邻域点数不要设得太大，否则小地物会被当成噪声。

5.3 DSM 栅格化与正射影像输出

栅格化是把散乱点云变成规则格网 DSM。常用方法是反距离加权或者三角网插值，空洞区可以标记为无效值，也可以做有限填补。填补要谨慎，大范围空洞填补出来的地形不可信，最好在成果里保留无效值标记，让使用者知道哪里是插值出来的。

正射影像用 DSM 做地形校正，把影像重采样到正射投影。这一步的精度直接受 DSM 影响，DSM 有系统偏差，正射影像就会有整体偏移；DSM 有局部错误，正射影像就会有局部拉伸。所以正射之前，最好先检查 DSM 的剖面和检查点误差，确认没问题再往下做。

./run_stage4_raster.sh \ --config config/project.cfg \ --dsm-resolution 0.5 \ --ortho-resolution 0.5 \ --fill-holes false

6. 常见问题与排查实录

这套流程跑下来，问题基本集中在几个地方：匹配点不够、平差不收敛、内存不够、点云空洞和拉花。每个问题的现象不同，排查路径也不一样。我把自己踩过的坑整理成下面这些，按现象、可能原因、排查方法、解决思路来组织。

6.1 匹配点少或者匹配错

匹配点少的典型现象是，平差日志里每张影像的连接点数量只有几十个，分布还很偏。可能原因包括影像重叠度不够、云量大、地表纹理弱、匹配阈值太严、搜索半径太小。排查时先看匹配点的分布图，如果集中在某个区域，多半是云或者阴影遮断；如果整体都少，先放宽匹配阈值和搜索半径，再看影像质量。

匹配错的典型现象是，平差残差很大，或者平差后点云整体扭曲。可能原因是重复纹理、视角差异大、RPC 预测偏差大。排查时看匹配点的残差分布，如果有明显的离群簇，用 RANSAC 或者一致性检查剔除。重复纹理区域，比如农田、规整建筑群，匹配本来就容易错，可以适当提高比值检验阈值，减少错误匹配。

6.2 平差不收敛

平差不收敛的表现是迭代残差来回震荡或者一直不下降。常见原因有：连接点粗差太多、某些影像的 RPC 异常、连接点分布严重不均、平差参数设置不合理。排查时先看每张影像的连接点数量和残差，把连接点特别少或者残差特别大的影像剔除，再跑一遍看是否收敛。

如果剔除影像后还不收敛，检查 RPC 文件是否有异常，比如系数缺失、坐标系错误、数值量级不对。RPC 系数一般是有固定量级的，如果某个系数明显偏离常理，多半是文件损坏或者格式不对。另外，平差的粗差剔除阈值不要设得太宽松，否则粗差点会拖累迭代。

6.3 内存爆掉与进程被杀

内存爆掉的典型现象是进程突然消失，日志最后一行停在密集匹配阶段，系统日志里有内存不足的记录。排查时先看影像数量和分辨率，估算总内存需求，再看并行度设置。解决思路有三个：降采样、分块、减少并行。降采样最直接，但会损失分辨率；分块需要改流程，把大区域切成小块分别跑；减少并行会拖慢速度，但最省事。

还有一个隐蔽的原因是内存泄漏。如果进程跑一段时间后内存持续上涨，最后被杀，可能是某个模块有泄漏。这种情况下，减小单次处理的数据量，或者分阶段跑，能缓解问题，但根治要靠修代码或者换版本。

6.4 点云空洞与拉花

点云空洞的原因是某片区域没有匹配出足够的点。常见于水体、阴影、云区、弱纹理区、遮挡区。排查时把空洞位置和原始影像对照，看是不是这些区域。如果是水体，本来就不该有点，空洞正常；如果是阴影或者云，考虑补数据或者标记无效；如果是弱纹理，可以放大匹配窗口或者降低一致性阈值。

拉花是点云或者 DSM 上出现的拉伸、拖尾、重复纹理，通常是因为平差不准或者匹配错误。排查时先看平差残差，再看匹配点分布。平差不准导致的拉花是全局性的，匹配错误导致的拉花是局部性的。全局问题回头修平差，局部问题用一致性检查和滤波处理。

6.5 常见问题速查表

7. 精度验证与参数经验沉淀

跑出成果只是第一步，能不能用要看精度。卫星影像三维重建的精度验证，通常分内符合和外符合。内符合看连接点残差和重叠区一致性，外符合看检查点误差。有条件的话，两种都做；没条件的话，至少做内符合，再结合目视检查。

参数经验这块，没有一套放之四海而皆准的配置。城市、山地、平原、沙漠，纹理和地形差异很大，参数倾向也不一样。我的做法是给每个场景类型沉淀一套基线配置，新项目先套基线，再根据数据特点微调，调完记录改动和效果，慢慢积累自己的参数库。

7.1 怎么验证结果靠谱

检查点验证最直接。找一批已知地面坐标的点，均匀分布在测区，用平差后的模型反投影到影像，计算平面和高程误差。检查点数量不用太多，但分布要覆盖测区边缘和中心，避免只在一块小区域验证。误差统计看均值和标准差，均值反映系统偏差，标准差反映随机误差。

没有检查点时，可以用重叠区一致性做间接验证。同一地物在不同影像上的反投影位置应该一致，统计这个不一致量，能反映相对精度。另外，把 DSM 和公开的参考地形数据做剖面对比，也能看出大致趋势，但要注意参考数据的精度和时效性。

目视检查不能省。把点云或者 DSM 叠加到影像上，看建筑边缘是否清晰、地形起伏是否合理、有没有明显的拉花和空洞。很多几何问题目视就能发现，而且比数字更直观。

7.2 参数组合与效果对照

下面这张表是我在不同场景下总结的参数倾向，只能作为起点，具体还要看数据。

这张表的核心逻辑是：纹理越弱，窗口越大、阈值越松；重复纹理越多，阈值越严；建筑越密集，窗口越小。理解逻辑比记住数字重要，因为实际数据往往介于几种类型之间。

7.3 我在实际项目里踩过的坑

第一个坑是忽视 RPC 检查。有一次拿到一批影像，直接开跑，平差怎么都不收敛，折腾了两天才发现其中几张影像的 RPC 文件和影像不对应。后来养成习惯，数据进流程之前先抽样反投影，几分钟的事，能省很多时间。

第二个坑是内存估算太乐观。早期按像素数粗算，觉得内存够，结果密集匹配跑到一半进程被杀。后来按像素数乘通道再乘系数估算，并且留百分之三十余量，再没出过问题。内存这东西，宁可多留，不要卡着线跑。

第三个坑是过度滤波。为了让 DSM 好看，把点云滤波参数调得很激进，结果小建筑和围墙全被抹掉，成果没法用。后来改成保留原始点云，滤波版单独输出，需要细节时回查原始数据，灵活很多。

第四个坑是忽略日志。Danesfield 的日志写得比较细，每个阶段的输入输出、参数、统计信息都有。一开始我只看最后报错，后来学会逐阶段看日志，很多问题在早期就有征兆，比如匹配点数量骤降、残差分布异常，早发现早处理，比后期返工省事。

7.4 后续可以扩展的方向

这套流程跑通之后，能扩展的地方不少。比如接入自己的滤波算法替换默认的点云去噪，或者用外部 DEM 约束密集匹配的高程搜索范围，再或者把平差结果导出，接其他软件做后续处理。Danesfield 的模块划分比较清晰，二次开发的门槛不算高，前提是先把默认流程跑稳，理解每个模块的输入输出。

另一个方向是自动化。把数据检查、参数选择、阶段调度、质量检查串成脚本，减少人工干预。但自动化之前，得先把人工流程摸透，知道每个参数为什么这么设，否则自动化只是把错误放大。我自己的做法是先把一个项目完整跑三遍，每遍记录参数和问题，形成检查清单，再考虑写脚本。这个清单后来成了团队里最常用的东西，比任何文档都实用。