做过道路测量和断面绘图的人都清楚这条路线上真正折磨人的从来不是算土方而是把一堆桩号和高程变成一张能交出去的图。我前后折腾过几个版本的道路纵横断面绘图工具从最早用表格加手绘到后来写脚本批量生成图纸中间踩的坑足够写一本小册子。这篇就把整套东西拆开讲这个工具到底该做成什么样、数据怎么组织、纵断面和横断面分别怎么画、土方怎么算、批量出图怎么不崩以及那些只有真跑过项目才会遇到的问题。先说清楚适合谁看。如果你是被安排画断面图的施工技术员天天在CAD里一根线一根线地描这篇能让你少加很多班如果你是做内业数据处理的技术人员手上有一堆全站仪导出的原始数据不知道怎么变成成品图这里的格式约定和校验方法可以直接照搬如果你想自己动手写这套工具文中的技术选型、算法实现和排查经验基本能覆盖从零到能用的全过程。工具最终要解决的事情很朴素输入测量数据和设计参数输出一套符合出图习惯的纵断面图、横断面图和土方计算表中间不需要人工干预。1. 先把这个工具的功能边界想明白动手写代码之前我花了差不多两天时间只是梳理需求。这两天看起来是浪费实际上是整个项目里性价比最高的投入。因为断面绘图这件事看起来简单——不就是画两条线——但真做起来边界模糊得可怕要不要画竖曲线要不要算超高横断面边坡要不要自动求交土方要不要分层的每一个要不要背后都是几百行代码的差距。1.1 从一线痛点倒推功能清单我观察过手工画断面的完整流程。一个熟练的绘图员画一个横断面从读数据到画完标注大概十五到二十分钟。一条几公里的路断面间距20米就是一两百个断面一个人干一周都算快的。更麻烦的是返工设计参数一改所有图全废得从头再来一遍。这不是效率问题是流程问题。所以工具的核心价值不在于画得好看而在于把数据和图形解耦。数据是源图形是渲染结果。源改了重新渲染一遍就行五分钟的事。这条原则定下来之后很多设计决策就顺了所有设计参数必须外置成配置文件不能硬编码在画图函数里绘图模块必须是纯函数输入数据输出图元不依赖任何全局状态中间结果必须能落盘方便对比两个版本的差异。落到功能清单上我最终圈定了这么几块其余一律砍掉功能模块是否必做理由桩号解析与里程换算必做所有计算的地基出错全盘皆错纵断面地面线绘制必做核心产出纵断面设计线含竖曲线必做没有设计线就没法算填挖横断面地面线绘制必做核心产出横断面设计线含边坡求交必做土方计算的前提超高与加宽处理必做曲线段断面画错是硬伤断面面积与土方计算必做交付成果之一图框、标尺、图例必做不出图等于没做三维地形建模不做需求外成本极高路线平纵横联动编辑不做那是商业软件的活砍掉后两项是我最庆幸的决定。很多自研工具死掉不是因为功能不够是因为一开始胃口太大做到一半发现收不了尾。1.2 为什么不直接买商业软件这个问题我被问过很多次。商业软件当然成熟断面绘制、土方计算、出图规范都是现成的。但有三个现实问题绕不开。第一是数据格式封闭。现场拿到的原始数据五花八门有的是全站仪导出的特定文本有的是手写记录后录入的表格字段顺序、分隔符、单位全都不一样。商业软件通常要求你先手工整理成它规定的格式这一步的耗时经常比画图本身还长。自研工具可以直接写适配器管你什么格式我写个解析函数就行一次投入长期受益。第二是出图习惯不一致。每个单位、每个项目的图框、标题栏、标注样式、比例尺习惯都有细微差别。商业软件的模板定制往往要绕一大圈而自研工具里改一个常量就完事。第三是批量处理和自动化。半夜跑批、CI里跑回归、跟其他脚本串联这些商业软件基本做不到或者做起来很别扭。而我自己这套东西一个命令行加参数就能跑完一整条线还能挂到定时任务里。当然代价也很明确你得自己保证正确性。这个后面会专门讲校核方法这是自研工具唯一不能省的部分。1.3 技术栈Python 打底DXF 交付技术选型我试过三条路最后落在 Python 上。最早试的是 CAD 二次开发用 C# 写插件。优点是直接在图里画所见即所得缺点是部署极其麻烦每台机器都要装对应版本的 CAD 和运行库版本一升级插件就废而且调试体验很差一个异常能卡半天。第二条路是纯前端方案用 Canvas 或者 SVG 画图再导出。预览体验确实好但导出 DWG 这条路走不通施工单位要的是能在 CAD 里打开、能编辑、能量长度的文件PDF 和图片都不满足。这个方案我做到一半就放弃了。最后落在 Python ezdxf matplotlib 的组合上分工很清楚ezdxf负责生成 DXF。DXF 是 CAD 的通用交换格式几乎所有版本都能打开生成过程完全不需要安装 CAD 软件纯 Python 就能跑服务器上部署零负担。画多段线、文字、标注、块引用都有现成接口。matplotlib负责快速预览。调样式的时候如果每次都开 CAD 看效果效率低到无法忍受。用 matplotlib 渲染一份 PNG改一行看一次几秒钟出结果定稿了再出 DXF。numpy / pandas负责数据清洗和数值计算。断面数据动辄几千行向量化处理比纯 Python 循环快一个数量级。argparse 或 click负责命令行入口。参数化是批量处理的前提。这里有个必须提前说清楚的坑DXF 的默认单位是毫米。所有我在计算阶段用米算出来的坐标写进 DXF 之前必须乘 1000。这个坑我在第一个版本就踩了出来的图小了一千倍打开一片空白还以为是文件损坏排查了两个小时。后来我干脆在代码里立了个规矩所有内部计算一律用米只在写图元的最后一层做单位转换函数名叫to_mm()看到这个名字就知道在干什么。2. 数据层把乱七八糟的原始数据变成能算的东西数据层是整个工具最不显眼但最容易出问题的部分。我的经验是绘图代码写完基本不用改数据解析代码每接一个新项目就要改一次。所以这部分的架构必须留足扩展余地。2.1 三类输入的格式约定工具需要吃进去三类数据分别对应不同的来源和格式。第一类是纵断面地面线数据通常来自中桩高程测量。最朴素的格式就是两列K0000.000,512.346 K0020.000,512.871 K0040.000,513.402 K0060.000,514.115也有的记录方式是只写米数不写K或者桩号和高程中间用制表符、分号分隔。我的做法是写一个parse_station()函数专门处理桩号再写一个read_profile_csv()处理整份文件用正则做宽松匹配把常见的几种写法都吃掉。第二类是横断面数据每个断面一组通常包含中线桩号和两侧的地面变坡点。常见格式是偏距和高程成对出现K0020 -8.20,513.105 -5.40,512.980 -2.10,512.902 0.00,512.871 2.30,512.845 5.60,512.790 9.10,512.512注意这里的偏距符号约定。工程上有两种习惯一种是面向线路前进方向左侧为负、右侧为正另一种反过来。这两种写法在不同单位的资料里都能见到混淆了会把整个断面画成镜像图看着挺正常但土方全错。我的处理方式是把它做成配置项offset_sign_convention默认左负右正解析时统一转换到内部约定永远不在下游代码里判断符号规则。第三类是设计参数这部分不是测量数据是设计成果通常来自设计文件。拆成两块纵断面设计变坡点桩号、变坡点高程、竖曲线半径。有几段就写几行。标准横断面车道宽度、路肩宽度、路拱横坡、填方边坡坡率、挖方边坡坡率、边沟尺寸、超高方式。我倾向于用 YAML 或者 TOML 来写这些配置可读性好支持注释改起来不容易错。JSON 不支持注释用在需要人手工维护的配置上是个缺点。2.2 桩号与里程一个必须做对的转换桩号是道路工程里最容易出错的地方没有之一。因为它在人的习惯和机器的习惯之间横跨了一道鸿沟。人看的是K12345.678机器要的是12345.678米。转换规则很直白K 后面是千米数加号后面是米数两者相加。但实现时有几个细节必须处理。import re from decimal import Decimal STATION_PATTERN re.compile( r^\s*[Kk]?\s*(\d)\s*\\s*(\d(?:\.\d)?)\s*$ ) def parse_station(text: str) - float: 把桩号文本转成里程米。支持 K12345.678 / 12345.678 / 12345.678 text text.strip() m STATION_PATTERN.match(text) if m: km int(m.group(1)) meter Decimal(m.group(2)) return float(km * 1000 meter) # 纯数字直接当米处理 try: return float(text.replace(,, )) except ValueError: raise ValueError(f无法解析桩号: {text!r})这里用Decimal而不是float来接收米数部分是因为遇到过K12345.678被浮点截断成345.67799999的情况。虽然对绘图影响微乎其微但一旦要做桩号相等判断、做数据去重这点误差就会导致匹配失败。工程数据里凡是涉及精确相等的地方都应该避开浮点直接比较。反向转换也有坑。里程12345.678转回桩号是K12345.68看起来简单但边界情况必须处理12345.999按两位小数保留就变成K12346.00而12999.999会进位到K13000.00。如果没做进位处理就会出现K121000.00这种非法桩号图上标注乱成一团。def format_station(mileage: float, decimals: int 2) - str: 里程转桩号文本自动处理进位。 scale 10 ** decimals total round(mileage * scale) / scale km int(total // 1000) m total - km * 1000 # 处理 999.999 - 1000.00 的进位 if round(m, decimals) 1000: km 1 m - 1000 return fK{km}{m:0{decimals 4}.{decimals}f}还有一点桩号在曲线上是不等于实际距离的。缓和曲线、圆曲线段桩号里程和平面上的直线距离不是一回事。不过对于纵断面和横断面绘图来说我们用的都是沿中线展开的里程这个差异在断面图里体现不出来只要保证数据源一致就行。这一点在新手那里容易造成困惑为什么我量图上的水平距离和桩号差对不上答案是比例尺不是曲线。2.3 数据校验宁可提前报错不要事后返工我在这上面交过学费。有一次一批断面数据里混进了一个单位错误——某个断面的高程整体差了 100 米大概是录入时把5敲成了5开头的三位数。图跑出来了看着也挺正常直到同事拿去做土方对比才发现某个断面的挖方量离谱。回头看跑一遍校验就能发现。我的校验规则清单现在固定为这么几条每条都对应过真实事故校验项触发条件处理方式桩号重复两行桩号换算后差值小于 1mm报错人工确认保留哪条桩号乱序后一行里程小于前一行自动排序并警告缺少中桩点横断面偏距里没有 0.00 附近±0.5m的点警告插值补一个中桩高程突变相邻点高差超过阈值默认 5m警告列出桩号断面点数不足少于 3 个点报错无法构成面积偏距不单调同一侧的偏距没有从小到大排列排序并警告地面线穿越设计线多次交点数量异常警告人工看断面这里有一个我自己加的技巧校验函数不只返回布尔值而是返回一个结构化的报告对象包含每条异常的级别error / warning、位置第几行、哪个桩号和建议动作。然后在主流程里设一个--validate-only开关只跑校验不画图。这么做的好处是遇到问题数据的时候可以先花半分钟跑一遍校验把脏数据清理干净再出图而不是等图出来发现不对再回头查。提示--validate-only这个开关我用得比任何功能都频繁。接到新数据的第一件事永远是跑校验看报告而不是直接跑出图。3. 纵断面绘制坐标换算和竖曲线是两道坎纵断面图看起来就是一上一下两条曲线但真正决定这张图专业不专业的是比例、网格、标尺和标注。这几个东西做对了图立刻就像那么回事做不对懂行的人一眼就能看出是外行画的。3.1 里程-高程坐标系与比例尺换算纵断面图的核心矛盾是里程方向几百上千米高程方向只有几十米如果按同一个比例画就是一根几乎水平的线什么细节都看不出来。所以必须做纵向放大。行业习惯是横向 1:2000、纵向 1:200。这意味着什么横向 1:2000 表示图上 1 个单位对应实际 2000 个单位图上一毫米代表实际 2 米纵向 1:200 表示图上一毫米代表实际 0.2 米。两者一比高程方向被放大了 10 倍。换算公式很直接。设起点里程为L0基准高程为H0横向比例分母Sx纵向比例分母Sy那么任意点 (里程 L, 高程 H) 画在图上的位置是x_图上 (L - L0) / Sx y_图上 (H - H0) / Sy单位是米图上米。举例L0 0Sx 2000里程 1000 米的点图上 x 0.5 米 500 毫米。这刚好是 A3 纸横向420mm放不下的所以一张图大约只能覆盖 800 米里程。纵向Sy 200H0 500高程 550 米的点图上 y 0.25 米 250 毫米。A3 纸纵向 297mm减去图框、标题栏、标尺占用的空间实际绘图区大概 150mm对应高程范围 30 米。所以纵向比例选 1:200 还是 1:100得看这段路的高差范围。我把这个逻辑写成了一个自动选比例的辅助函数先算这段路的里程跨度和高程跨度再反推合适的比例从标准比例序列里挑一个。标准比例我限定了几个常用值横向 1:1000/1:2000/1:5000纵向 1:100/1:200/1:500避免出现 1:1737 这种怪比例出图会被人笑话。STANDARD_H [1000, 2000, 5000] STANDARD_V [100, 200, 500] def pick_scale(span_mileage, span_elev, box_w_mm380, box_h_mm150): 根据里程跨度和高程跨度挑一对标准比例。 for sh in STANDARD_H: w_mm span_mileage / sh * 1000 if w_mm box_w_mm: continue for sv in STANDARD_V: h_mm span_elev / sv * 1000 if h_mm box_h_mm: return sh, sv raise ValueError(跨度过大需要分幅出图)关于比例尺还有一个极其容易踩的坑同一个项目里纵断面和横断面的比例不能混用但也不能统一。纵断面是横向压缩、纵向放大横断面是横向放大、纵向压缩。我见过把横断面也按 1:2000 横向画的出来就是一根竖线。所以比例配置必须分两套命名上也要区分清楚比如profile_scale和section_scale绝不能用同一个变量名。3.2 设计线、竖曲线与坡长坡度标注地面线是数据设计线是设计。设计线的绘制要复杂一些因为涉及竖曲线。纵断面设计的基本单位是坡段从一个变坡点到下一个变坡点中间是一条直线斜率就是纵坡。两个坡段之间的转折点叫变坡点为了让车辆平顺通过要在变坡点处插入竖曲线。竖曲线一般用圆曲线或者二次抛物线近似工程上更常用抛物线因为计算简单、精度足够。给定变坡点桩号K、变坡点高程H、前坡i1、后坡i2、竖曲线半径R计算流程是这样坡度代数差ω i2 - i1注意带符号上坡为正。竖曲线长度L R × |ω|切线长T L / 2外距E T² / (2R)。竖曲线起点桩号K - T终点桩号K T。在竖曲线范围内任意一点设计高程的计算用切线高程加上改正值设计高程 切线高程 x² / (2R)其中x是该点到竖曲线起点的距离或者到变坡点的距离取决于公式的写法两种都行别混就行。这个改正值的符号要特别注意凸形竖曲线ω 0改正值为负设计线在切线下方凹形竖曲线ω 0改正值为正设计线在切线上方。我第一版实现的时候把符号搞反了结果凸曲线画到了切线上方图上看不出来因为差得很少几十厘米直到算填挖的时候发现某一段的挖方量明显偏小才对上。教训是写完竖曲线代码一定要拿一个手算得出来的简单例子验证。比如i1 2%、i2 -2%、R 5000那么ω -0.04L 200T 100E 1.0米。在变坡点处设计高程应该比切线低 1 米。这个数字一眼能算出来对不上就是代码错了。def design_elev(sta, vpi_list): vpi_list: [(桩号, 高程, 竖曲线半径), ...]返回该桩号的设计高程。 # 先找到所在坡段 for i in range(len(vpi_list) - 1): k1, h1, r1 vpi_list[i] k2, h2, r2 vpi_list[i 1] if not (k1 sta k2): continue grade (h2 - h1) / (k2 - k1) z_tangent h1 grade * (sta - k1) # 判断是否落在起点或终点的竖曲线范围内 for k, h, r, prev_k, prev_h, next_k, next_h in _nearby_vpi(vpi_list, i, sta): i1 (h - prev_h) / (k - prev_k) if prev_k is not None else grade i2 (next_h - h) / (next_k - k) if next_k is not None else grade omega i2 - i1 L r * abs(omega) if L 0: continue t L / 2 if k - t sta k t: x sta - (k - t) # 抛物线改正凸凹自动处理 return z_tangent (omega / (2 * L)) * x * x return z_tangent return vpi_list[-1][1]上面这段代码里的_nearby_vpi是个辅助函数用来取当前坡段前后各一个变坡点目的是判断桩号是否落在相邻变坡点的竖曲线范围内。真实实现里我会把这一步拆得更清楚先为每个变坡点构造竖曲线对象算出起终点桩号然后再做区间判定。写成上面这样主要是为了让读者看清逻辑主线。图面上还要标坡度和坡长。惯例是在每段坡的上方写一条水平的坡度线标注成i2.35%和L320.00的形式。有的单位喜欢写成分数1:42.5这个做成配置项。坡长标注的位置在坡度线的中间字高比坡度字小一号。3.3 图框、标尺与网格细节决定专业度这部分没有技术难度纯粹是耐心活。但恰恰是这部分让一张图从能看变成能交付。标尺分上下两条。上标尺标的是桩号每 50 米标一个数字每 10 米画一个小刻度下标尺标的是高程网格对应的里程或者干脆不标。刻度线的长度要分主次主刻度50m长一点次刻度10m短一点视觉上才有层次。高程网格是水平的横线每 1 米或者 2 米一条取决于纵向比例最左边的网格线上标高程值。网格线的颜色要浅我用的是浅灰色 ACI 8 号色否则会盖住地面线。地面线和设计线必须区分得非常清楚。我的习惯是地面线用黑色实线线宽 0.35mm设计线用红色或蓝色线宽 0.5mm加粗一点。有些单位要求地面线用虚线设计线用实线这个也做成配置。标注是最占时间的。每一个地面线变坡点都要标高程但点太密的时候标不下必须抽稀。我的策略是先按变坡点标如果相邻两个标注的水平间距小于字宽的 1.5 倍就合并或者跳过中间那个优先保留极值点局部最高点和最低点必须标。还有一个容易被忽略的细节图块的复用。标尺、图框、标题栏这些重复出现的东西应该做成 DXF 的块block插入的时候用块引用。这样文件体积小而且后期修改一处就能全改。我第一版傻乎乎地把图框拆成四条线逐张画两百张图的文件有 20 多兆打开卡得要死。4. 横断面绘制边坡求交是核心算法横断面比纵断面复杂难就难在设计线不是给定的而是要根据地面线算出来的。因为填方边坡和挖方边坡的坡率不同边坡要从路基边缘向下或向上延伸直到与地面相交。这个交点也就是边桩位置决定了断面图的实际宽度和面积。4.1 横断面数据的组织与左右侧分离一个标准横断面由中线向两侧延伸每一侧又有若干个坡段路面横坡、路肩横坡、边坡有时候还有边沟、护坡道、挡墙。为了统一处理我把每一侧的数据组织成一个有序的点列从中心向外排列每个点只需要两个属性相对中线的偏距、高程。地面线也是同样的结构只不过它的点是从实测数据来的。两者放在同一个坐标系里就能比较了。这里有个细节要处理实测的地面线通常不会刚好在中线位置有测点。有的是偏距 0.00 处有测点有的是 0.15 或者 -0.10。如果不处理中桩高程就对不上。我的做法是在偏距 0 的位置做线性插值补一个虚拟点并且在日志里记一笔中桩高程为插值值。两侧的处理逻辑可以完全共用只要把偏距的统一处理做好。内部约定是左负右正那么左侧就是偏距小于 0 的所有点右侧是大于 0 的点。绘图的时候只需要在 X 轴上做一次镜像其他逻辑一样。这个设计能省掉一半代码。4.2 填挖边坡求交一个需要迭代的问题这是整个工具里唯一需要求解的地方也是最容易写错的地方。场景是这样的路基宽 10 米也就是从中心往两侧各 5 米。在偏距 5 米处路基边缘有一个设计高程假设是 513.00。现在地面在偏距 5 米处的高程是 511.50比设计低 1.5 米这是填方。填方边坡的坡率是 1:1.5垂直:水平意思是每下降 1.5 米水平方向往外延伸 1 米。那么边桩位置应该满足设计线z_d(d) 513.00 - (d - 5) / 1.5 d 5 地面线z_g(d) 通过实测点线性插值得到 求 d 使得 z_d(d) z_g(d)这是个求根问题。由于地面线是分段的线性函数z_d(d) - z_g(d)在每一段内都是线性的理论上可以直接解方程。但实际实现里用迭代法更省事也更稳因为不用处理各种退化情况。我用的方法是线性段遍历 逐段解方程。从d 5出发按地面线数据点的偏距依次走每走进一段就用这段的直线方程和设计线的直线方程联立求交点。如果交点落在这一段内找到了如果落在这段外继续下一段。如果走完全部地面线点还没找到说明边坡太缓一直没追上地面这时候要么加宽用地要么设挡墙必须报错让人工介入。def find_side_slope_point(d_start, z_start, slope, ground_pts): 从 (d_start, z_start) 出发按 slope 求与地面线的交点。 slope 为水平:垂直的倒数比如填方 1:1.5 时 vertical_per_h 1/1.5。 ground_pts 为 [(偏距, 高程), ...]偏距单调递增。 for i in range(len(ground_pts) - 1): x1, y1 ground_pts[i] x2, y2 ground_pts[i 1] if x2 d_start: continue # 设计线方程z z_start (d - d_start) * slope # 地面线方程z y1 (d - x1) * k_g k_g (y2 - y1) / (x2 - x1) # z_start (d - d_start)*slope y1 (d - x1)*k_g denom slope - k_g if abs(denom) 1e-9: # 平行跳过 d_start max(d_start, x2) continue d (y1 - k_g * x1 - z_start slope * d_start) / denom if d_start d x2: z z_start (d - d_start) * slope return d, z d_start max(d_start, x2) raise ValueError(边坡与地面线无交点需检查坡率或用地方案)这段代码看着不难但有一个关键点slope的符号和方向。填方时边坡向下走slope是负的随偏距增大高程降低挖方时边坡向上走slope是正的。这点如果搞混填方算成挖方土方结果会离谱到没法看。我在函数文档里专门写了这么一句话提醒自己也在代码里加了个断言填方时z_start应该大于地面的初始高程不然就是数据有问题。挖方还有一种特殊情况地面很陡边坡反而追不上地面会形成高边坡。这时候如果坡率是单一的边坡线会一直往上延伸而地面上升更快理论上确实无交点。检测到这种情况必须报错因为实际工程里这种情况要分级放坡或者设挡墙不是单一边坡能解决的。工具不能假装解决了必须老老实实告诉使用者这里需要人工设计。4.3 超高与加宽曲线段的断面不能画错直线段的横断面很简单两侧对称路拱双向各 2%。进入曲线段就不一样了为了让车辆克服离心力路面要做成单向横坡也就是超高。超高值从直线段的 -2% 渐变到圆曲线段的 4%举例过渡段缓和曲线内线性变化。这个变化对横断面图的影响是直接的左右两侧的路面边缘高程不再对称。绕中线旋转的话中线高程不变左侧边缘降低右侧边缘升高或者反过来取决于超高的方向。左侧边缘高程 中线高程 - (半幅宽) × i_left 右侧边缘高程 中线高程 (半幅宽) × i_right其中i_left和i_right是各自的横坡值带符号。直线段时i_left -0.02、i_right 0.02全超高时i_left 0.04、i_right 0.04同向过渡段则按位置线性插值。加宽类似圆曲线内侧需要加宽加宽值在缓和曲线内从 0 渐变到设计值。加宽直接影响路基边缘的偏距进而影响边坡的起点位置最后影响土方。这两块我在第一版里完全忽略了因为当时处理的路线以直线为主画出来的图看着没问题。后来做了一段山区路线曲线半径只有 200 米超高值 6%同行一眼就看出来你这个断面怎么是平的。补这个功能的代价是重写了设计线生成模块如果一开始就考虑进去会省很多事。注意超高的方向必须和曲线转向一致。左转曲线超高在外侧右侧抬高右转反之。这个方向搞反了图上看不出来但用地方案和土方全错。5. 土方计算算法不难难在口径统一土方计算是断面图的最终目的之一。算法本身在教科书上写得明明白白但真做起来坑不在算法在口径——面积怎么算、体积用什么方法、单位是什么、填挖怎么分、清表要不要扣。这些问题不统一两个人算同一段路能差出百分之十几。5.1 断面面积坐标法是最省事的办法计算由两条线围成的面积最容易想到的是把它拆成若干梯形逐个算完相加。这个方法的问题是必须先把两条线的交点找出来把区域切成一块块代码量不小而且容易在交点判定上出错。更简单的办法是坐标法鞋带公式。把围成封闭多边形的所有顶点按顺序列出面积等于A 0.5 × |Σ(x_i × y_{i1} - x_{i1} × y_i)|公式对多边形凹凸都成立不需要判断形状只需要保证顶点顺序是沿着边界走一圈。对于断面来说这个多边形就是地面线从左到右的所有点加上设计线从右到左的所有点首尾闭合。def polygon_area(points): 鞋带公式points 为闭合多边形的顶点序列。 if len(points) 3: return 0.0 s 0.0 n len(points) for i in range(n): x1, y1 points[i] x2, y2 points[(i 1) % n] s x1 * y2 - x2 * y1 return abs(s) / 2.0填挖要分开算。做法是把地面线和设计线的所有交点求出来按偏距排序这些交点把整个断面切成若干区间。在每个区间里两条线不会相交所以整个区间要么是填要么是挖判断一下上下关系就行。然后对每个区间单独构造多边形算面积累加到对应的计数器。这里有个数值细节交点的坐标是用线性插值算出来的会有浮点误差。如果两个交点离得极近比如 1e-6 米可能产生一个面积几乎为零的碎片区间。这种区间可以过滤掉但要设一个阈值太小了没意义太大会漏算。我用的是面积小于 0.0001 平方米就丢弃实践下来没问题。5.2 平均断面法与棱柱体法选哪个差多少有了每个断面的面积接下来就是沿纵向积分求体积。两种常用方法方法公式特点平均断面法V (A₁ A₂) / 2 × L计算简单结果偏大工程上最常用棱柱体法V (A₁ A₂ √(A₁A₂)) / 3 × L结果偏小理论上更接近真值两者在断面面积变化平缓时差异很小在面积突变比如一个断面突然出现挡墙或者大面积挖方时差异明显。工程计量习惯用平均断面法因为偏保守也因为它简单、可核对。我在工具里默认用平均断面法同时在输出表里附一列棱柱体法的结果方便对比。如果两者差异超过 5%就在日志里标出来提示复核——这通常意味着某两个相邻断面的地形变化异常值得看一眼。还要注意间距不等的情况。实际断面间距不一定严格是 20 米有的是 15 米有的是 25 米曲线段还可能加密。这时候不能用断面数量去乘必须逐段用实际间距V_total Σ L_i × (A_i A_{i1}) / 2这一点我在早期版本里错过一次当时想当然地按断面数 × 20 米估算总长结果因为加密段的存在总长多算了百分之几土方量跟着偏大。虽然比例不大但报出去的数是错的这就很尴尬了。5.3 精度校核自研工具的唯一保险自研工具最怕的不是功能少是算错了自己不知道。所以我给自己定了三条校核规矩每次改动核心算法都要跑一遍。第一条是手算对照。挑一个形状简单、坐标整齐的断面比如地面是一个规则的三角形设计线是水平的手算面积和程序结果比。差值应该在 0.001 平方米以内。第二条是总量级校验。一段一公里的路土方总量应该在什么量级心里要有个数。如果算出来是几千方或者几百万方八成是哪里的单位或者符号错了。这个方法很土但极其有效。第三条是回归测试集。把历史项目里有代表性的断面平坦的、陡坡的、有边沟的、超高段的、加宽段的整理成一个测试集每次改代码跑一遍把输出的面积和土方导出成 CSV和基准文件逐行比对。只要有一个数字变了就必须搞清楚为什么变是修 bug 还是引入了新 bug。这套东西做起来大概要花半天时间但它在我后面几年的时间里救了我至少三次。没有它我根本不敢改核心算法。6. 批量出图让一百个断面自己长出来单个断面画对了只是第一步真正体现高效的是批量。一条路的横断面动辄一两百个如果每个都要手工调位置、排版、标注那自研工具的价值就少了一大半。6.1 图幅布局与自动分幅横断面图通常是一张纸上排几个断面左右并列或者上下堆叠。排布的核心约束是每个断面占的图面尺寸不能重叠而且要留出标注空间。每个断面的图面宽度由最大偏距决定图面高度由高差范围决定。假设断面横向比例 1:200最大偏距 ±15 米那么图面宽度 30 / 200 × 1000 150 毫米。A3 纸横向 420 毫米减去图框边距可用宽度约 380 毫米所以一行能放 2 个断面2 × 150 300还剩 80 毫米余量。纵向同理。有了这个规则就可以写自动分幅先算每个断面的包围盒按行排布放不下就换行一行放满了就换页。这个逻辑不复杂但必须做成通用的因为不同项目的断面宽度差异很大——有的断面只有十几米一行能放四个有的断面有四十米一行只能放一个。def layout_sections(bboxes, page_w, page_h, margin, gap): 把断面的包围盒排布到多页上返回每页每断面的插入点。 pages, page, cursor_x, cursor_y, row_h [], [], margin, margin, 0 for w, h in bboxes: if cursor_x w page_w - margin: # 换行 cursor_x margin cursor_y row_h gap row_h 0 if cursor_y h page_h - margin: # 换页 pages.append(page) page, cursor_x, cursor_y, row_h [], margin, margin, 0 page.append((cursor_x, cursor_y)) cursor_x w gap row_h max(row_h, h) if page: pages.append(page) return pages这段逻辑我用了很久稳定可靠。唯一要注意的是row_h的更新时机——同一行内不同断面的高度可能不同行高要取这一行里最大的那个否则下一行会压到上一行。6.2 标注避让与文字样式统一断面图上的文字有三种点号、偏距、高程。点号可以省略偏距和高程通常是必须的。文字多了必然重叠。我的处理策略分三步先按规则放置然后检测冲突最后按优先级删除。规则的细节是这样的高程标在点的正上方偏距标在点的正下方字体高度按出图比例定图面上 2.5 毫米字高换算到 DXF 就是 2.5 的单位因为 DXF 用毫米。冲突检测用简单的包围盒判定两个文字的包围盒相交就算冲突。冲突时的删除优先级先删中间的、非极值的点保留左右两端和填挖分界点。文字样式统一也是个体力活。DXF 里的文字样式STYLE需要单独定义如果不定义打开文件时可能显示成问号或者乱字体。我的做法是在生成文件的初始化阶段就定义好两个文字样式一个用于表格和标题仿宋或宋体一个用于数字标注等宽或者 Arial。字体文件名不能硬编码成绝对路径否则换台机器就找不到了。用相对路径或者干脆只指定字体名让 CAD 自己去找。提示中文乱码是 DXF 出图的高频问题。根源是文字样式里的字体没有指定正确或者 DXF 的编码版本不对。用 ezdxf 时建议显式设置doc.header[$DWGCODEPAGE] ANSI_936并把文字样式的字体名写成gbcbig.shx之类的中文字体。6.3 批量执行的容错与可追溯批量跑一百个断面不出错是不可能的。关键是出错之后能不能快速定位、能不能跳过继续。我的做法是逐断面隔离 结构化日志。主循环里每个断面单独 try 包裹捕获异常后记录桩号、异常类型、堆栈摘要然后继续下一个。全部跑完后输出一份汇总列出成功多少个、失败多少个、失败的是哪些桩号。results [] for sec in sections: try: draw_section(sec) results.append({station: sec.station, status: ok}) except Exception as e: log.error(断面 %s 处理失败: %s, format_station(sec.station), e) results.append({ station: sec.station, status: failed, error: f{type(e).__name__}: {e}, }) pd.DataFrame(results).to_csv(run_report.csv, indexFalse)这份run_report.csv的价值远超它的大小。有了它跑完一眼就能知道哪几个断面有问题直接跳到那几行去看原始数据不用在几百个断面里瞎找。而且这个文件可以归档以后出现争议还能追溯。还有一个工程上的小技巧分块写 DXF。如果一页图一个 DXF 文件几十个文件管理起来很烦如果全部塞进一个文件几百兆的文件打开要几分钟。我的折中是每 10 页一个文件文件名带上起止桩号既方便查找又不会太大。写文件的时候用doc.saveas()写完立刻释放避免内存越用越多。7. 踩坑记录与排查速查表下面这些是我这几年攒下来的真实问题按出现频率排序。我把它们整理成速查表出问题的时候先对着表排查能省掉大量时间。7.1 现象与原因对照速查现象最可能的原因排查动作打开 DXF 什么都看不到单位没转坐标差 1000 倍检查是否调用了 to_mm试试全部缩放图很小挤在角落比例尺分母当分子用了核对 scale 的定义图上一米对应实际多少断面图上下颠倒偏距符号约定搞反了检查配置里的 left_is_negative填挖颜色反了设计线与地面线的高低判断反了打印一个断面的两侧高程对比中文显示成问号文字样式字体未定义或编码不对检查 STYLE 定义和输入编码必要时改页属性土方量明显偏大平均断面法用在了面积突变处对照棱柱体法结果差异超过 5% 要复核某些断面缺失批量循环里异常被吞掉了看 run_report.csv 里的 failed 行图面文字重叠严重抽稀阈值太小调大最小间距或增加极值点保留规则边坡点找不到填挖坡率符号配错打印起点高程和地面高程确认填还是挖曲线段断面不对称超高没做或者方向错检查该桩号的超高值和旋转轴桩号出现 K121000.00进位逻辑缺失检查 format_station 的进位分支文件打开极慢图元没有做成块数量爆炸统计图元数把重复内容改成块引用这张表里排第一的那个什么都看不到我在不同项目里至少遇到过三次每次都是因为某个新写的模块忘了做单位转换。后来我在代码里加了个检查生成 DXF 后读回来算一下所有图元的包围盒如果范围小于 1 个单位毫米或者大于 1e8直接抛异常。这个自检只花几毫秒但能拦住一整类错误。7.2 几条用真金白银换来的经验第一条先跑通一个断面再谈批量。我见过太多人包括我自己一上来就写批量框架结果单个断面的绘制逻辑还没验证跑出来一百张图全错根本不知道从哪查。正确的顺序是拿一个最简单的手工能算的断面做样本单步调通把输出的每个坐标都打印出来核对一遍。这一步做扎实了批量只是循环。第二条数据永远比你想象的脏。空格、全角逗号、BOM 头、Excel 导出的科学计数法、混合了中英文标点……这些我都遇到过。解析函数的容错能力要按最坏情况设计宁可宽松匹配加警告也不要严格匹配直接崩。因为崩了之后使用者不知道怎么办而警告至少能让人看到问题在哪。第三条比例尺不要相信默认值。每个项目的出图习惯都不同有的是 1:200有的是 1:100横断面的纵向比例更是五花八门。我在配置文件里把比例设为必填项缺了就报错绝不设默认值。默认值是万恶之源因为它让人以为应该是这样实际上每个项目都不一样。第四条给每个断面留一张体检报告。除了出图我还额外输出一份 CSV包含每个断面的桩号、填方面积、挖方面积、填方边坡偏距、挖方边坡偏距、地面线点数、是否有插值中桩。这份表格不出图但它是排查问题的第一手资料。当有人质疑这个断面的挖方为什么这么大的时候翻出这张表看看边坡偏距是不是异常几秒钟就能定位。第五条版本要能追溯。每次出图文件名里带上日期和配置文件的哈希前六位比如section_20240612_a3f9c1.dxf。这样当两版图对不上的时候能立刻确定是用哪份配置生成的。这个习惯看起来小题大做但在需要复现历史成果的时候价值巨大。最后分享一个我自己觉得最实用的小功能--compare对比模式。传入新旧两份数据工具不画图只输出两份数据的差异清单哪些桩号的断面面积变了、变了多少、哪些点是新增或删除的。设计变更频繁的项目里这个功能比画图本身还受欢迎因为它直接回答了这次改动到底影响了什么这个问题。这套工具从最早的一个脚本到现在前后迭代了十几版核心的绘图逻辑其实没怎么变变的全是数据容错和异常处理。如果你也打算自己做一套我的建议是先想清楚数据长什么样、出图要什么样再动手写代码别反过来。 
长河君 · 2026/10/29 13:00:23 · 阅读 1.2k 道路纵横断面绘图工具：从测量数据到DXF批量出图与土方计算
做过道路测量和断面绘图的人都清楚这条路线上真正折磨人的从来不是算土方而是把一堆桩号和高程变成一张能交出去的图。我前后折腾过几个版本的道路纵横断面绘图工具从最早用表格加手绘到后来写脚本批量生成图纸中间踩的坑足够写一本小册子。这篇就把整套东西拆开讲这个工具到底该做成什么样、数据怎么组织、纵断面和横断面分别怎么画、土方怎么算、批量出图怎么不崩以及那些只有真跑过项目才会遇到的问题。先说清楚适合谁看。如果你是被安排画断面图的施工技术员天天在CAD里一根线一根线地描这篇能让你少加很多班如果你是做内业数据处理的技术人员手上有一堆全站仪导出的原始数据不知道怎么变成成品图这里的格式约定和校验方法可以直接照搬如果你想自己动手写这套工具文中的技术选型、算法实现和排查经验基本能覆盖从零到能用的全过程。工具最终要解决的事情很朴素输入测量数据和设计参数输出一套符合出图习惯的纵断面图、横断面图和土方计算表中间不需要人工干预。1. 先把这个工具的功能边界想明白动手写代码之前我花了差不多两天时间只是梳理需求。这两天看起来是浪费实际上是整个项目里性价比最高的投入。因为断面绘图这件事看起来简单——不就是画两条线——但真做起来边界模糊得可怕要不要画竖曲线要不要算超高横断面边坡要不要自动求交土方要不要分层的每一个要不要背后都是几百行代码的差距。1.1 从一线痛点倒推功能清单我观察过手工画断面的完整流程。一个熟练的绘图员画一个横断面从读数据到画完标注大概十五到二十分钟。一条几公里的路断面间距20米就是一两百个断面一个人干一周都算快的。更麻烦的是返工设计参数一改所有图全废得从头再来一遍。这不是效率问题是流程问题。所以工具的核心价值不在于画得好看而在于把数据和图形解耦。数据是源图形是渲染结果。源改了重新渲染一遍就行五分钟的事。这条原则定下来之后很多设计决策就顺了所有设计参数必须外置成配置文件不能硬编码在画图函数里绘图模块必须是纯函数输入数据输出图元不依赖任何全局状态中间结果必须能落盘方便对比两个版本的差异。落到功能清单上我最终圈定了这么几块其余一律砍掉功能模块是否必做理由桩号解析与里程换算必做所有计算的地基出错全盘皆错纵断面地面线绘制必做核心产出纵断面设计线含竖曲线必做没有设计线就没法算填挖横断面地面线绘制必做核心产出横断面设计线含边坡求交必做土方计算的前提超高与加宽处理必做曲线段断面画错是硬伤断面面积与土方计算必做交付成果之一图框、标尺、图例必做不出图等于没做三维地形建模不做需求外成本极高路线平纵横联动编辑不做那是商业软件的活砍掉后两项是我最庆幸的决定。很多自研工具死掉不是因为功能不够是因为一开始胃口太大做到一半发现收不了尾。1.2 为什么不直接买商业软件这个问题我被问过很多次。商业软件当然成熟断面绘制、土方计算、出图规范都是现成的。但有三个现实问题绕不开。第一是数据格式封闭。现场拿到的原始数据五花八门有的是全站仪导出的特定文本有的是手写记录后录入的表格字段顺序、分隔符、单位全都不一样。商业软件通常要求你先手工整理成它规定的格式这一步的耗时经常比画图本身还长。自研工具可以直接写适配器管你什么格式我写个解析函数就行一次投入长期受益。第二是出图习惯不一致。每个单位、每个项目的图框、标题栏、标注样式、比例尺习惯都有细微差别。商业软件的模板定制往往要绕一大圈而自研工具里改一个常量就完事。第三是批量处理和自动化。半夜跑批、CI里跑回归、跟其他脚本串联这些商业软件基本做不到或者做起来很别扭。而我自己这套东西一个命令行加参数就能跑完一整条线还能挂到定时任务里。当然代价也很明确你得自己保证正确性。这个后面会专门讲校核方法这是自研工具唯一不能省的部分。1.3 技术栈Python 打底DXF 交付技术选型我试过三条路最后落在 Python 上。最早试的是 CAD 二次开发用 C# 写插件。优点是直接在图里画所见即所得缺点是部署极其麻烦每台机器都要装对应版本的 CAD 和运行库版本一升级插件就废而且调试体验很差一个异常能卡半天。第二条路是纯前端方案用 Canvas 或者 SVG 画图再导出。预览体验确实好但导出 DWG 这条路走不通施工单位要的是能在 CAD 里打开、能编辑、能量长度的文件PDF 和图片都不满足。这个方案我做到一半就放弃了。最后落在 Python ezdxf matplotlib 的组合上分工很清楚ezdxf负责生成 DXF。DXF 是 CAD 的通用交换格式几乎所有版本都能打开生成过程完全不需要安装 CAD 软件纯 Python 就能跑服务器上部署零负担。画多段线、文字、标注、块引用都有现成接口。matplotlib负责快速预览。调样式的时候如果每次都开 CAD 看效果效率低到无法忍受。用 matplotlib 渲染一份 PNG改一行看一次几秒钟出结果定稿了再出 DXF。numpy / pandas负责数据清洗和数值计算。断面数据动辄几千行向量化处理比纯 Python 循环快一个数量级。argparse 或 click负责命令行入口。参数化是批量处理的前提。这里有个必须提前说清楚的坑DXF 的默认单位是毫米。所有我在计算阶段用米算出来的坐标写进 DXF 之前必须乘 1000。这个坑我在第一个版本就踩了出来的图小了一千倍打开一片空白还以为是文件损坏排查了两个小时。后来我干脆在代码里立了个规矩所有内部计算一律用米只在写图元的最后一层做单位转换函数名叫to_mm()看到这个名字就知道在干什么。2. 数据层把乱七八糟的原始数据变成能算的东西数据层是整个工具最不显眼但最容易出问题的部分。我的经验是绘图代码写完基本不用改数据解析代码每接一个新项目就要改一次。所以这部分的架构必须留足扩展余地。2.1 三类输入的格式约定工具需要吃进去三类数据分别对应不同的来源和格式。第一类是纵断面地面线数据通常来自中桩高程测量。最朴素的格式就是两列K0000.000,512.346 K0020.000,512.871 K0040.000,513.402 K0060.000,514.115也有的记录方式是只写米数不写K或者桩号和高程中间用制表符、分号分隔。我的做法是写一个parse_station()函数专门处理桩号再写一个read_profile_csv()处理整份文件用正则做宽松匹配把常见的几种写法都吃掉。第二类是横断面数据每个断面一组通常包含中线桩号和两侧的地面变坡点。常见格式是偏距和高程成对出现K0020 -8.20,513.105 -5.40,512.980 -2.10,512.902 0.00,512.871 2.30,512.845 5.60,512.790 9.10,512.512注意这里的偏距符号约定。工程上有两种习惯一种是面向线路前进方向左侧为负、右侧为正另一种反过来。这两种写法在不同单位的资料里都能见到混淆了会把整个断面画成镜像图看着挺正常但土方全错。我的处理方式是把它做成配置项offset_sign_convention默认左负右正解析时统一转换到内部约定永远不在下游代码里判断符号规则。第三类是设计参数这部分不是测量数据是设计成果通常来自设计文件。拆成两块纵断面设计变坡点桩号、变坡点高程、竖曲线半径。有几段就写几行。标准横断面车道宽度、路肩宽度、路拱横坡、填方边坡坡率、挖方边坡坡率、边沟尺寸、超高方式。我倾向于用 YAML 或者 TOML 来写这些配置可读性好支持注释改起来不容易错。JSON 不支持注释用在需要人手工维护的配置上是个缺点。2.2 桩号与里程一个必须做对的转换桩号是道路工程里最容易出错的地方没有之一。因为它在人的习惯和机器的习惯之间横跨了一道鸿沟。人看的是K12345.678机器要的是12345.678米。转换规则很直白K 后面是千米数加号后面是米数两者相加。但实现时有几个细节必须处理。import re from decimal import Decimal STATION_PATTERN re.compile( r^\s*[Kk]?\s*(\d)\s*\\s*(\d(?:\.\d)?)\s*$ ) def parse_station(text: str) - float: 把桩号文本转成里程米。支持 K12345.678 / 12345.678 / 12345.678 text text.strip() m STATION_PATTERN.match(text) if m: km int(m.group(1)) meter Decimal(m.group(2)) return float(km * 1000 meter) # 纯数字直接当米处理 try: return float(text.replace(,, )) except ValueError: raise ValueError(f无法解析桩号: {text!r})这里用Decimal而不是float来接收米数部分是因为遇到过K12345.678被浮点截断成345.67799999的情况。虽然对绘图影响微乎其微但一旦要做桩号相等判断、做数据去重这点误差就会导致匹配失败。工程数据里凡是涉及精确相等的地方都应该避开浮点直接比较。反向转换也有坑。里程12345.678转回桩号是K12345.68看起来简单但边界情况必须处理12345.999按两位小数保留就变成K12346.00而12999.999会进位到K13000.00。如果没做进位处理就会出现K121000.00这种非法桩号图上标注乱成一团。def format_station(mileage: float, decimals: int 2) - str: 里程转桩号文本自动处理进位。 scale 10 ** decimals total round(mileage * scale) / scale km int(total // 1000) m total - km * 1000 # 处理 999.999 - 1000.00 的进位 if round(m, decimals) 1000: km 1 m - 1000 return fK{km}{m:0{decimals 4}.{decimals}f}还有一点桩号在曲线上是不等于实际距离的。缓和曲线、圆曲线段桩号里程和平面上的直线距离不是一回事。不过对于纵断面和横断面绘图来说我们用的都是沿中线展开的里程这个差异在断面图里体现不出来只要保证数据源一致就行。这一点在新手那里容易造成困惑为什么我量图上的水平距离和桩号差对不上答案是比例尺不是曲线。2.3 数据校验宁可提前报错不要事后返工我在这上面交过学费。有一次一批断面数据里混进了一个单位错误——某个断面的高程整体差了 100 米大概是录入时把5敲成了5开头的三位数。图跑出来了看着也挺正常直到同事拿去做土方对比才发现某个断面的挖方量离谱。回头看跑一遍校验就能发现。我的校验规则清单现在固定为这么几条每条都对应过真实事故校验项触发条件处理方式桩号重复两行桩号换算后差值小于 1mm报错人工确认保留哪条桩号乱序后一行里程小于前一行自动排序并警告缺少中桩点横断面偏距里没有 0.00 附近±0.5m的点警告插值补一个中桩高程突变相邻点高差超过阈值默认 5m警告列出桩号断面点数不足少于 3 个点报错无法构成面积偏距不单调同一侧的偏距没有从小到大排列排序并警告地面线穿越设计线多次交点数量异常警告人工看断面这里有一个我自己加的技巧校验函数不只返回布尔值而是返回一个结构化的报告对象包含每条异常的级别error / warning、位置第几行、哪个桩号和建议动作。然后在主流程里设一个--validate-only开关只跑校验不画图。这么做的好处是遇到问题数据的时候可以先花半分钟跑一遍校验把脏数据清理干净再出图而不是等图出来发现不对再回头查。提示--validate-only这个开关我用得比任何功能都频繁。接到新数据的第一件事永远是跑校验看报告而不是直接跑出图。3. 纵断面绘制坐标换算和竖曲线是两道坎纵断面图看起来就是一上一下两条曲线但真正决定这张图专业不专业的是比例、网格、标尺和标注。这几个东西做对了图立刻就像那么回事做不对懂行的人一眼就能看出是外行画的。3.1 里程-高程坐标系与比例尺换算纵断面图的核心矛盾是里程方向几百上千米高程方向只有几十米如果按同一个比例画就是一根几乎水平的线什么细节都看不出来。所以必须做纵向放大。行业习惯是横向 1:2000、纵向 1:200。这意味着什么横向 1:2000 表示图上 1 个单位对应实际 2000 个单位图上一毫米代表实际 2 米纵向 1:200 表示图上一毫米代表实际 0.2 米。两者一比高程方向被放大了 10 倍。换算公式很直接。设起点里程为L0基准高程为H0横向比例分母Sx纵向比例分母Sy那么任意点 (里程 L, 高程 H) 画在图上的位置是x_图上 (L - L0) / Sx y_图上 (H - H0) / Sy单位是米图上米。举例L0 0Sx 2000里程 1000 米的点图上 x 0.5 米 500 毫米。这刚好是 A3 纸横向420mm放不下的所以一张图大约只能覆盖 800 米里程。纵向Sy 200H0 500高程 550 米的点图上 y 0.25 米 250 毫米。A3 纸纵向 297mm减去图框、标题栏、标尺占用的空间实际绘图区大概 150mm对应高程范围 30 米。所以纵向比例选 1:200 还是 1:100得看这段路的高差范围。我把这个逻辑写成了一个自动选比例的辅助函数先算这段路的里程跨度和高程跨度再反推合适的比例从标准比例序列里挑一个。标准比例我限定了几个常用值横向 1:1000/1:2000/1:5000纵向 1:100/1:200/1:500避免出现 1:1737 这种怪比例出图会被人笑话。STANDARD_H [1000, 2000, 5000] STANDARD_V [100, 200, 500] def pick_scale(span_mileage, span_elev, box_w_mm380, box_h_mm150): 根据里程跨度和高程跨度挑一对标准比例。 for sh in STANDARD_H: w_mm span_mileage / sh * 1000 if w_mm box_w_mm: continue for sv in STANDARD_V: h_mm span_elev / sv * 1000 if h_mm box_h_mm: return sh, sv raise ValueError(跨度过大需要分幅出图)关于比例尺还有一个极其容易踩的坑同一个项目里纵断面和横断面的比例不能混用但也不能统一。纵断面是横向压缩、纵向放大横断面是横向放大、纵向压缩。我见过把横断面也按 1:2000 横向画的出来就是一根竖线。所以比例配置必须分两套命名上也要区分清楚比如profile_scale和section_scale绝不能用同一个变量名。3.2 设计线、竖曲线与坡长坡度标注地面线是数据设计线是设计。设计线的绘制要复杂一些因为涉及竖曲线。纵断面设计的基本单位是坡段从一个变坡点到下一个变坡点中间是一条直线斜率就是纵坡。两个坡段之间的转折点叫变坡点为了让车辆平顺通过要在变坡点处插入竖曲线。竖曲线一般用圆曲线或者二次抛物线近似工程上更常用抛物线因为计算简单、精度足够。给定变坡点桩号K、变坡点高程H、前坡i1、后坡i2、竖曲线半径R计算流程是这样坡度代数差ω i2 - i1注意带符号上坡为正。竖曲线长度L R × |ω|切线长T L / 2外距E T² / (2R)。竖曲线起点桩号K - T终点桩号K T。在竖曲线范围内任意一点设计高程的计算用切线高程加上改正值设计高程 切线高程 x² / (2R)其中x是该点到竖曲线起点的距离或者到变坡点的距离取决于公式的写法两种都行别混就行。这个改正值的符号要特别注意凸形竖曲线ω 0改正值为负设计线在切线下方凹形竖曲线ω 0改正值为正设计线在切线上方。我第一版实现的时候把符号搞反了结果凸曲线画到了切线上方图上看不出来因为差得很少几十厘米直到算填挖的时候发现某一段的挖方量明显偏小才对上。教训是写完竖曲线代码一定要拿一个手算得出来的简单例子验证。比如i1 2%、i2 -2%、R 5000那么ω -0.04L 200T 100E 1.0米。在变坡点处设计高程应该比切线低 1 米。这个数字一眼能算出来对不上就是代码错了。def design_elev(sta, vpi_list): vpi_list: [(桩号, 高程, 竖曲线半径), ...]返回该桩号的设计高程。 # 先找到所在坡段 for i in range(len(vpi_list) - 1): k1, h1, r1 vpi_list[i] k2, h2, r2 vpi_list[i 1] if not (k1 sta k2): continue grade (h2 - h1) / (k2 - k1) z_tangent h1 grade * (sta - k1) # 判断是否落在起点或终点的竖曲线范围内 for k, h, r, prev_k, prev_h, next_k, next_h in _nearby_vpi(vpi_list, i, sta): i1 (h - prev_h) / (k - prev_k) if prev_k is not None else grade i2 (next_h - h) / (next_k - k) if next_k is not None else grade omega i2 - i1 L r * abs(omega) if L 0: continue t L / 2 if k - t sta k t: x sta - (k - t) # 抛物线改正凸凹自动处理 return z_tangent (omega / (2 * L)) * x * x return z_tangent return vpi_list[-1][1]上面这段代码里的_nearby_vpi是个辅助函数用来取当前坡段前后各一个变坡点目的是判断桩号是否落在相邻变坡点的竖曲线范围内。真实实现里我会把这一步拆得更清楚先为每个变坡点构造竖曲线对象算出起终点桩号然后再做区间判定。写成上面这样主要是为了让读者看清逻辑主线。图面上还要标坡度和坡长。惯例是在每段坡的上方写一条水平的坡度线标注成i2.35%和L320.00的形式。有的单位喜欢写成分数1:42.5这个做成配置项。坡长标注的位置在坡度线的中间字高比坡度字小一号。3.3 图框、标尺与网格细节决定专业度这部分没有技术难度纯粹是耐心活。但恰恰是这部分让一张图从能看变成能交付。标尺分上下两条。上标尺标的是桩号每 50 米标一个数字每 10 米画一个小刻度下标尺标的是高程网格对应的里程或者干脆不标。刻度线的长度要分主次主刻度50m长一点次刻度10m短一点视觉上才有层次。高程网格是水平的横线每 1 米或者 2 米一条取决于纵向比例最左边的网格线上标高程值。网格线的颜色要浅我用的是浅灰色 ACI 8 号色否则会盖住地面线。地面线和设计线必须区分得非常清楚。我的习惯是地面线用黑色实线线宽 0.35mm设计线用红色或蓝色线宽 0.5mm加粗一点。有些单位要求地面线用虚线设计线用实线这个也做成配置。标注是最占时间的。每一个地面线变坡点都要标高程但点太密的时候标不下必须抽稀。我的策略是先按变坡点标如果相邻两个标注的水平间距小于字宽的 1.5 倍就合并或者跳过中间那个优先保留极值点局部最高点和最低点必须标。还有一个容易被忽略的细节图块的复用。标尺、图框、标题栏这些重复出现的东西应该做成 DXF 的块block插入的时候用块引用。这样文件体积小而且后期修改一处就能全改。我第一版傻乎乎地把图框拆成四条线逐张画两百张图的文件有 20 多兆打开卡得要死。4. 横断面绘制边坡求交是核心算法横断面比纵断面复杂难就难在设计线不是给定的而是要根据地面线算出来的。因为填方边坡和挖方边坡的坡率不同边坡要从路基边缘向下或向上延伸直到与地面相交。这个交点也就是边桩位置决定了断面图的实际宽度和面积。4.1 横断面数据的组织与左右侧分离一个标准横断面由中线向两侧延伸每一侧又有若干个坡段路面横坡、路肩横坡、边坡有时候还有边沟、护坡道、挡墙。为了统一处理我把每一侧的数据组织成一个有序的点列从中心向外排列每个点只需要两个属性相对中线的偏距、高程。地面线也是同样的结构只不过它的点是从实测数据来的。两者放在同一个坐标系里就能比较了。这里有个细节要处理实测的地面线通常不会刚好在中线位置有测点。有的是偏距 0.00 处有测点有的是 0.15 或者 -0.10。如果不处理中桩高程就对不上。我的做法是在偏距 0 的位置做线性插值补一个虚拟点并且在日志里记一笔中桩高程为插值值。两侧的处理逻辑可以完全共用只要把偏距的统一处理做好。内部约定是左负右正那么左侧就是偏距小于 0 的所有点右侧是大于 0 的点。绘图的时候只需要在 X 轴上做一次镜像其他逻辑一样。这个设计能省掉一半代码。4.2 填挖边坡求交一个需要迭代的问题这是整个工具里唯一需要求解的地方也是最容易写错的地方。场景是这样的路基宽 10 米也就是从中心往两侧各 5 米。在偏距 5 米处路基边缘有一个设计高程假设是 513.00。现在地面在偏距 5 米处的高程是 511.50比设计低 1.5 米这是填方。填方边坡的坡率是 1:1.5垂直:水平意思是每下降 1.5 米水平方向往外延伸 1 米。那么边桩位置应该满足设计线z_d(d) 513.00 - (d - 5) / 1.5 d 5 地面线z_g(d) 通过实测点线性插值得到 求 d 使得 z_d(d) z_g(d)这是个求根问题。由于地面线是分段的线性函数z_d(d) - z_g(d)在每一段内都是线性的理论上可以直接解方程。但实际实现里用迭代法更省事也更稳因为不用处理各种退化情况。我用的方法是线性段遍历 逐段解方程。从d 5出发按地面线数据点的偏距依次走每走进一段就用这段的直线方程和设计线的直线方程联立求交点。如果交点落在这一段内找到了如果落在这段外继续下一段。如果走完全部地面线点还没找到说明边坡太缓一直没追上地面这时候要么加宽用地要么设挡墙必须报错让人工介入。def find_side_slope_point(d_start, z_start, slope, ground_pts): 从 (d_start, z_start) 出发按 slope 求与地面线的交点。 slope 为水平:垂直的倒数比如填方 1:1.5 时 vertical_per_h 1/1.5。 ground_pts 为 [(偏距, 高程), ...]偏距单调递增。 for i in range(len(ground_pts) - 1): x1, y1 ground_pts[i] x2, y2 ground_pts[i 1] if x2 d_start: continue # 设计线方程z z_start (d - d_start) * slope # 地面线方程z y1 (d - x1) * k_g k_g (y2 - y1) / (x2 - x1) # z_start (d - d_start)*slope y1 (d - x1)*k_g denom slope - k_g if abs(denom) 1e-9: # 平行跳过 d_start max(d_start, x2) continue d (y1 - k_g * x1 - z_start slope * d_start) / denom if d_start d x2: z z_start (d - d_start) * slope return d, z d_start max(d_start, x2) raise ValueError(边坡与地面线无交点需检查坡率或用地方案)这段代码看着不难但有一个关键点slope的符号和方向。填方时边坡向下走slope是负的随偏距增大高程降低挖方时边坡向上走slope是正的。这点如果搞混填方算成挖方土方结果会离谱到没法看。我在函数文档里专门写了这么一句话提醒自己也在代码里加了个断言填方时z_start应该大于地面的初始高程不然就是数据有问题。挖方还有一种特殊情况地面很陡边坡反而追不上地面会形成高边坡。这时候如果坡率是单一的边坡线会一直往上延伸而地面上升更快理论上确实无交点。检测到这种情况必须报错因为实际工程里这种情况要分级放坡或者设挡墙不是单一边坡能解决的。工具不能假装解决了必须老老实实告诉使用者这里需要人工设计。4.3 超高与加宽曲线段的断面不能画错直线段的横断面很简单两侧对称路拱双向各 2%。进入曲线段就不一样了为了让车辆克服离心力路面要做成单向横坡也就是超高。超高值从直线段的 -2% 渐变到圆曲线段的 4%举例过渡段缓和曲线内线性变化。这个变化对横断面图的影响是直接的左右两侧的路面边缘高程不再对称。绕中线旋转的话中线高程不变左侧边缘降低右侧边缘升高或者反过来取决于超高的方向。左侧边缘高程 中线高程 - (半幅宽) × i_left 右侧边缘高程 中线高程 (半幅宽) × i_right其中i_left和i_right是各自的横坡值带符号。直线段时i_left -0.02、i_right 0.02全超高时i_left 0.04、i_right 0.04同向过渡段则按位置线性插值。加宽类似圆曲线内侧需要加宽加宽值在缓和曲线内从 0 渐变到设计值。加宽直接影响路基边缘的偏距进而影响边坡的起点位置最后影响土方。这两块我在第一版里完全忽略了因为当时处理的路线以直线为主画出来的图看着没问题。后来做了一段山区路线曲线半径只有 200 米超高值 6%同行一眼就看出来你这个断面怎么是平的。补这个功能的代价是重写了设计线生成模块如果一开始就考虑进去会省很多事。注意超高的方向必须和曲线转向一致。左转曲线超高在外侧右侧抬高右转反之。这个方向搞反了图上看不出来但用地方案和土方全错。5. 土方计算算法不难难在口径统一土方计算是断面图的最终目的之一。算法本身在教科书上写得明明白白但真做起来坑不在算法在口径——面积怎么算、体积用什么方法、单位是什么、填挖怎么分、清表要不要扣。这些问题不统一两个人算同一段路能差出百分之十几。5.1 断面面积坐标法是最省事的办法计算由两条线围成的面积最容易想到的是把它拆成若干梯形逐个算完相加。这个方法的问题是必须先把两条线的交点找出来把区域切成一块块代码量不小而且容易在交点判定上出错。更简单的办法是坐标法鞋带公式。把围成封闭多边形的所有顶点按顺序列出面积等于A 0.5 × |Σ(x_i × y_{i1} - x_{i1} × y_i)|公式对多边形凹凸都成立不需要判断形状只需要保证顶点顺序是沿着边界走一圈。对于断面来说这个多边形就是地面线从左到右的所有点加上设计线从右到左的所有点首尾闭合。def polygon_area(points): 鞋带公式points 为闭合多边形的顶点序列。 if len(points) 3: return 0.0 s 0.0 n len(points) for i in range(n): x1, y1 points[i] x2, y2 points[(i 1) % n] s x1 * y2 - x2 * y1 return abs(s) / 2.0填挖要分开算。做法是把地面线和设计线的所有交点求出来按偏距排序这些交点把整个断面切成若干区间。在每个区间里两条线不会相交所以整个区间要么是填要么是挖判断一下上下关系就行。然后对每个区间单独构造多边形算面积累加到对应的计数器。这里有个数值细节交点的坐标是用线性插值算出来的会有浮点误差。如果两个交点离得极近比如 1e-6 米可能产生一个面积几乎为零的碎片区间。这种区间可以过滤掉但要设一个阈值太小了没意义太大会漏算。我用的是面积小于 0.0001 平方米就丢弃实践下来没问题。5.2 平均断面法与棱柱体法选哪个差多少有了每个断面的面积接下来就是沿纵向积分求体积。两种常用方法方法公式特点平均断面法V (A₁ A₂) / 2 × L计算简单结果偏大工程上最常用棱柱体法V (A₁ A₂ √(A₁A₂)) / 3 × L结果偏小理论上更接近真值两者在断面面积变化平缓时差异很小在面积突变比如一个断面突然出现挡墙或者大面积挖方时差异明显。工程计量习惯用平均断面法因为偏保守也因为它简单、可核对。我在工具里默认用平均断面法同时在输出表里附一列棱柱体法的结果方便对比。如果两者差异超过 5%就在日志里标出来提示复核——这通常意味着某两个相邻断面的地形变化异常值得看一眼。还要注意间距不等的情况。实际断面间距不一定严格是 20 米有的是 15 米有的是 25 米曲线段还可能加密。这时候不能用断面数量去乘必须逐段用实际间距V_total Σ L_i × (A_i A_{i1}) / 2这一点我在早期版本里错过一次当时想当然地按断面数 × 20 米估算总长结果因为加密段的存在总长多算了百分之几土方量跟着偏大。虽然比例不大但报出去的数是错的这就很尴尬了。5.3 精度校核自研工具的唯一保险自研工具最怕的不是功能少是算错了自己不知道。所以我给自己定了三条校核规矩每次改动核心算法都要跑一遍。第一条是手算对照。挑一个形状简单、坐标整齐的断面比如地面是一个规则的三角形设计线是水平的手算面积和程序结果比。差值应该在 0.001 平方米以内。第二条是总量级校验。一段一公里的路土方总量应该在什么量级心里要有个数。如果算出来是几千方或者几百万方八成是哪里的单位或者符号错了。这个方法很土但极其有效。第三条是回归测试集。把历史项目里有代表性的断面平坦的、陡坡的、有边沟的、超高段的、加宽段的整理成一个测试集每次改代码跑一遍把输出的面积和土方导出成 CSV和基准文件逐行比对。只要有一个数字变了就必须搞清楚为什么变是修 bug 还是引入了新 bug。这套东西做起来大概要花半天时间但它在我后面几年的时间里救了我至少三次。没有它我根本不敢改核心算法。6. 批量出图让一百个断面自己长出来单个断面画对了只是第一步真正体现高效的是批量。一条路的横断面动辄一两百个如果每个都要手工调位置、排版、标注那自研工具的价值就少了一大半。6.1 图幅布局与自动分幅横断面图通常是一张纸上排几个断面左右并列或者上下堆叠。排布的核心约束是每个断面占的图面尺寸不能重叠而且要留出标注空间。每个断面的图面宽度由最大偏距决定图面高度由高差范围决定。假设断面横向比例 1:200最大偏距 ±15 米那么图面宽度 30 / 200 × 1000 150 毫米。A3 纸横向 420 毫米减去图框边距可用宽度约 380 毫米所以一行能放 2 个断面2 × 150 300还剩 80 毫米余量。纵向同理。有了这个规则就可以写自动分幅先算每个断面的包围盒按行排布放不下就换行一行放满了就换页。这个逻辑不复杂但必须做成通用的因为不同项目的断面宽度差异很大——有的断面只有十几米一行能放四个有的断面有四十米一行只能放一个。def layout_sections(bboxes, page_w, page_h, margin, gap): 把断面的包围盒排布到多页上返回每页每断面的插入点。 pages, page, cursor_x, cursor_y, row_h [], [], margin, margin, 0 for w, h in bboxes: if cursor_x w page_w - margin: # 换行 cursor_x margin cursor_y row_h gap row_h 0 if cursor_y h page_h - margin: # 换页 pages.append(page) page, cursor_x, cursor_y, row_h [], margin, margin, 0 page.append((cursor_x, cursor_y)) cursor_x w gap row_h max(row_h, h) if page: pages.append(page) return pages这段逻辑我用了很久稳定可靠。唯一要注意的是row_h的更新时机——同一行内不同断面的高度可能不同行高要取这一行里最大的那个否则下一行会压到上一行。6.2 标注避让与文字样式统一断面图上的文字有三种点号、偏距、高程。点号可以省略偏距和高程通常是必须的。文字多了必然重叠。我的处理策略分三步先按规则放置然后检测冲突最后按优先级删除。规则的细节是这样的高程标在点的正上方偏距标在点的正下方字体高度按出图比例定图面上 2.5 毫米字高换算到 DXF 就是 2.5 的单位因为 DXF 用毫米。冲突检测用简单的包围盒判定两个文字的包围盒相交就算冲突。冲突时的删除优先级先删中间的、非极值的点保留左右两端和填挖分界点。文字样式统一也是个体力活。DXF 里的文字样式STYLE需要单独定义如果不定义打开文件时可能显示成问号或者乱字体。我的做法是在生成文件的初始化阶段就定义好两个文字样式一个用于表格和标题仿宋或宋体一个用于数字标注等宽或者 Arial。字体文件名不能硬编码成绝对路径否则换台机器就找不到了。用相对路径或者干脆只指定字体名让 CAD 自己去找。提示中文乱码是 DXF 出图的高频问题。根源是文字样式里的字体没有指定正确或者 DXF 的编码版本不对。用 ezdxf 时建议显式设置doc.header[$DWGCODEPAGE] ANSI_936并把文字样式的字体名写成gbcbig.shx之类的中文字体。6.3 批量执行的容错与可追溯批量跑一百个断面不出错是不可能的。关键是出错之后能不能快速定位、能不能跳过继续。我的做法是逐断面隔离 结构化日志。主循环里每个断面单独 try 包裹捕获异常后记录桩号、异常类型、堆栈摘要然后继续下一个。全部跑完后输出一份汇总列出成功多少个、失败多少个、失败的是哪些桩号。results [] for sec in sections: try: draw_section(sec) results.append({station: sec.station, status: ok}) except Exception as e: log.error(断面 %s 处理失败: %s, format_station(sec.station), e) results.append({ station: sec.station, status: failed, error: f{type(e).__name__}: {e}, }) pd.DataFrame(results).to_csv(run_report.csv, indexFalse)这份run_report.csv的价值远超它的大小。有了它跑完一眼就能知道哪几个断面有问题直接跳到那几行去看原始数据不用在几百个断面里瞎找。而且这个文件可以归档以后出现争议还能追溯。还有一个工程上的小技巧分块写 DXF。如果一页图一个 DXF 文件几十个文件管理起来很烦如果全部塞进一个文件几百兆的文件打开要几分钟。我的折中是每 10 页一个文件文件名带上起止桩号既方便查找又不会太大。写文件的时候用doc.saveas()写完立刻释放避免内存越用越多。7. 踩坑记录与排查速查表下面这些是我这几年攒下来的真实问题按出现频率排序。我把它们整理成速查表出问题的时候先对着表排查能省掉大量时间。7.1 现象与原因对照速查现象最可能的原因排查动作打开 DXF 什么都看不到单位没转坐标差 1000 倍检查是否调用了 to_mm试试全部缩放图很小挤在角落比例尺分母当分子用了核对 scale 的定义图上一米对应实际多少断面图上下颠倒偏距符号约定搞反了检查配置里的 left_is_negative填挖颜色反了设计线与地面线的高低判断反了打印一个断面的两侧高程对比中文显示成问号文字样式字体未定义或编码不对检查 STYLE 定义和输入编码必要时改页属性土方量明显偏大平均断面法用在了面积突变处对照棱柱体法结果差异超过 5% 要复核某些断面缺失批量循环里异常被吞掉了看 run_report.csv 里的 failed 行图面文字重叠严重抽稀阈值太小调大最小间距或增加极值点保留规则边坡点找不到填挖坡率符号配错打印起点高程和地面高程确认填还是挖曲线段断面不对称超高没做或者方向错检查该桩号的超高值和旋转轴桩号出现 K121000.00进位逻辑缺失检查 format_station 的进位分支文件打开极慢图元没有做成块数量爆炸统计图元数把重复内容改成块引用这张表里排第一的那个什么都看不到我在不同项目里至少遇到过三次每次都是因为某个新写的模块忘了做单位转换。后来我在代码里加了个检查生成 DXF 后读回来算一下所有图元的包围盒如果范围小于 1 个单位毫米或者大于 1e8直接抛异常。这个自检只花几毫秒但能拦住一整类错误。7.2 几条用真金白银换来的经验第一条先跑通一个断面再谈批量。我见过太多人包括我自己一上来就写批量框架结果单个断面的绘制逻辑还没验证跑出来一百张图全错根本不知道从哪查。正确的顺序是拿一个最简单的手工能算的断面做样本单步调通把输出的每个坐标都打印出来核对一遍。这一步做扎实了批量只是循环。第二条数据永远比你想象的脏。空格、全角逗号、BOM 头、Excel 导出的科学计数法、混合了中英文标点……这些我都遇到过。解析函数的容错能力要按最坏情况设计宁可宽松匹配加警告也不要严格匹配直接崩。因为崩了之后使用者不知道怎么办而警告至少能让人看到问题在哪。第三条比例尺不要相信默认值。每个项目的出图习惯都不同有的是 1:200有的是 1:100横断面的纵向比例更是五花八门。我在配置文件里把比例设为必填项缺了就报错绝不设默认值。默认值是万恶之源因为它让人以为应该是这样实际上每个项目都不一样。第四条给每个断面留一张体检报告。除了出图我还额外输出一份 CSV包含每个断面的桩号、填方面积、挖方面积、填方边坡偏距、挖方边坡偏距、地面线点数、是否有插值中桩。这份表格不出图但它是排查问题的第一手资料。当有人质疑这个断面的挖方为什么这么大的时候翻出这张表看看边坡偏距是不是异常几秒钟就能定位。第五条版本要能追溯。每次出图文件名里带上日期和配置文件的哈希前六位比如section_20240612_a3f9c1.dxf。这样当两版图对不上的时候能立刻确定是用哪份配置生成的。这个习惯看起来小题大做但在需要复现历史成果的时候价值巨大。最后分享一个我自己觉得最实用的小功能--compare对比模式。传入新旧两份数据工具不画图只输出两份数据的差异清单哪些桩号的断面面积变了、变了多少、哪些点是新增或删除的。设计变更频繁的项目里这个功能比画图本身还受欢迎因为它直接回答了这次改动到底影响了什么这个问题。这套工具从最早的一个脚本到现在前后迭代了十几版核心的绘图逻辑其实没怎么变变的全是数据容错和异常处理。如果你也打算自己做一套我的建议是先想清楚数据长什么样、出图要什么样再动手写代码别反过来。