Android 测绘计算工程化：七四参数、高程拟合与单位系统

测绘软件的多数 bug 不是算法写错，而是量纲与参数在层与层之间被悄悄换了。

一份测量成果偏出去十几公里，排查到最后往往是某个角落把以"秒"为单位的旋转角直接塞进了旋转矩阵；一个界面切到英尺后，相邻页面还显示着米，两处差了三倍多却没人发现。这类问题有一个共同特征：算法本身没错，错的是"这个值到底代表什么、该用哪套参数去换"这件事，在第一层写完后，到第二层、第三层被无声地替换掉了。

本系列前面八篇讲了表格、控件、架构、网络、地图数据这些"外壳"，这一篇落到测绘最内核的两类工程问题：一类是"数算不对"------坐标在不同基准之间转换时参数求算错了；一类是"量纲乱套"------同一个数字，在内部是米，在界面被当成了英尺，或者角度和长度被加在了一起。这两件事表面无关，根子上是同一个判断：测绘数据在层与层之间流动时，必须带着它的"单位"和"作用域"一起走，而不能靠注释提醒自己别忘了换。

下面把"七/四参数与高程拟合"和"全局单位系统"两篇笔记合并改写。前半部分讲怎么把专业转换参数做成可单测的纯函数模块；后半部分讲怎么让全 App 的单位只在一处切换。合起来的结论只有一句：工程上真正要做的，是给"带单位的值"和"带作用域的坐标"造类型，而不是依赖人脑记住每一层该换什么。

一、统一的判准：bug 不在算法，在量纲与参数被层间换掉

先说清楚为什么这两件事要放在一篇里讲。测绘软件里最容易出、也最难查的 bug，几乎都不是"公式抄错"，而是下面三种"换掉了"：

1. 量纲被换掉：角度和长度相加，米被当成英尺，平方米被当成亩。这类错误编译期发现不了，运行时常常也不报错，直到用户拿成果去放样才暴露。
2. 高程语义被换掉：GPS 给的是椭球高，工程要的是正常高，两者差着一个起伏面，不能直接相减。把椭球高当正常高用，高程整体偏几米，肉眼看坐标也对得上，只有到现场才发现桩打错位置。
3. 参数作用域被换掉：一套七参数只在某个测区有效，却被拿去换另一个测区的点；或者四参数的基准原点搞混了，平移量整体错掉。

三者有一条共同的对治思路：让"值"自己携带它的单位与作用域 。坐标不能只是一个 (x, y, h) 的三个浮点，而应该是"在 WGS84、带椭球高语义、准备用第 3 套参数去换"的对象；长度不能只是一个 Double，而应该是"以米为基准的长度，当前显示成英尺"。做到这一点，层与层之间传递时就换不掉------因为换不掉的信息被锁进了类型里。

前半部分的"七/四参数与高程拟合"给出的是专业知识的工程化封装；后半部分的"单位系统"给出的是量纲的全局收口。二者合起来，就是这套"造类型"思想的落地。

二、七参数与四参数：把刚体变换写成可测试纯函数

坐标从 WGS84 到本地成果，要连续穿过几个"坐标域"：先由经纬度进空间直角，七参数做全局三维变换，再投影到平面做四参数精调，最后用高程拟合把椭球高修成正常高。这条链路画清楚，才知道每一步该带什么单位、什么参数：

flowchart LR A["WGS84 经纬度 B/L"] --> B["空间直角 XYZ 七参数变换"] C["椭球高 H"] --> D["高程拟合 修正面"] B --> E["本地平面 N/E 四参数精调"] E --> F["本地北东坐标"] D --> G["正常高 高程成果"] F --> H["坐标成果输出"] G --> H

坐标转换的本质，是在两个坐标系之间建立一套数学关系，让任意一个源坐标都能换到目标坐标系。控制点就是"同一物理位置在两个坐标系下的已知坐标对"，靠它们反解出参数。一个控制点通常带四类信息：

• 源坐标：经纬度（B/L）+ 椭球高（H），通常是 WGS84 下的测量值；
• 目标坐标：已知的北坐标（N）、东坐标（E）、高程（H），是该点在本地坐标系里的准确值；
• 参与标志：这个点要不要参与平面求参（useH）、要不要参与高程求参（useV）；
• 残差：求参后回代算出的偏差（水平残差 Hrms / 垂直残差 Vrms）。

这一步看似只是收集数据，其实已经决定了工程化的一半：数据的取舍和标志位的设计。下面分别看七参数和四参数。

2.1 七参数：三维空间的刚体变换 + 尺度

七参数描述两个空间直角坐标系之间的关系，含 3 个平移（ΔX/ΔY/ΔZ）、3 个旋转（Rx/Ry/Rz）、1 个尺度 K。它的计算入口长这样：

// 传入所有控制点，让求解器反解出一套参数
val param7 = solver.solveSeven(sourcePoints, targetPoints)

// 旋转角：原始值以"秒"为单位，转成弧度/度才能用于旋转矩阵
val rx = param7.rx / 3600.0
val ry = param7.ry / 3600.0
val rz = param7.rz / 3600.0

// 尺度：库返回的是百万分之偏差，还原成真实比例因子
val scale = param7.k / 1_000_000.0 + 1.0

这里藏着两个最容易错的工程点，也正是"专业坑"：

1. 旋转角的量纲 。底层求出的旋转角常以"秒"为单位，必须 /3600 转成度，或再转弧度，才能塞进旋转矩阵。漏了这一步，角度差几十个数量级------这正是开篇说的"偏出十几公里"的典型成因。
2. 尺度的语义 。返回的 K 往往是"百万分之几"的偏差（比如 -116.4），真实比例因子是 K / 1e6 + 1。很多实现把这层换算埋在结果类里，调用方直接拿 K + 1，就错了。

七参数适合源、目标都是空间直角坐标（或能互相换算）的场景，一套参数覆盖全区域，但参数本身是大尺度的三维关系。工程上更关键的是把它写成可测试的纯函数：给定参数和源坐标，输出目标坐标，不碰任何全局状态，这样单测能直接断言。

// 七参数变换的纯函数：输入源空间直角坐标，输出目标空间直角坐标
// 旋转角已统一为弧度，尺度已还原为真实比例因子
fun transformSeven(
    px: Double, py: Double, pz: Double,
    dx: Double, dy: Double, dz: Double,   // 平移 ΔX/ΔY/ΔZ（米）
    rx: Double, ry: Double, rz: Double,    // 旋转（弧度）
    scale: Double,                         // 真实比例因子 = K/1e6 + 1
): Triple<Double, Double, Double> {
    // 先乘尺度与旋转矩阵，再加平移
    val s = scale
    val x1 = s * (px + rz * py - ry * pz) + dx
    val y1 = s * (-rz * px + py + rx * pz) + dy
    val z1 = s * (ry * px - rx * py + pz) + dz
    return Triple(x1, y1, z1)
}

这种纯函数写法有几个好处：旋转矩阵只依赖三个旋转角，尺度只依赖一个比例因子，平移只依赖三个分量，三者互不耦合；给定一组"权威软件算出的参数 + 坐标对"，单测能逐分量断言输出；重构旋转矩阵实现时，只要输出不变，测试就全绿。

2.2 四参数：平面上的平移 + 旋转 + 尺度

四参数是在平面坐标系里工作的：2 个平移（北 N、东 E）、1 个旋转角 R、1 个尺度 K，通常还带一个"基准原点"（OrgN/OrgE），表示这套参数是在哪个已知点上"锚定"的：

// 求四参数：输出 北平移、东平移、旋转角、尺度、基准原点
val param4 = solver.solveFour(controlPoints)

val result = Param4Result(
    dn = param4.dn,
    de = param4.de,
    rotation = param4.rotation,
    scale = param4.scale,
    originN = param4.orgN,
    originE = param4.orgE,
)

同样把它写成纯函数，注意所有量都相对于基准原点：

// 四参数变换纯函数：输入本地平面坐标（相对基准原点），输出目标平面坐标
fun transformFour(
    n: Double, e: Double,
    dn: Double, de: Double,       // 北、东平移（米）
    rotation: Double,             // 旋转角（弧度）
    scale: Double,                // 真实比例因子
    orgN: Double, orgE: Double,   // 基准原点
): Pair<Double, Double> {
    val dn0 = n - orgN
    val de0 = e - orgE
    val cos = kotlin.math.cos(rotation)
    val sin = kotlin.math.sin(rotation)
    val x = scale * (dn0 * cos - de0 * sin) + dn
    val y = scale * (dn0 * sin + de0 * cos) + de
    return Pair(x, y)
}

四参数适合"小范围平面测区"：范围不大时，把地球面近似成平面，用平移+旋转+尺度就能覆盖大部分误差。它和七参数不是二选一，工程里经常先求一套七参数做整体框架，再在平面层叠一套四参数精调，两个结果并存。下面这张图说明二者的适用边界：

flowchart TD Q["源与目标坐标类型"] -->|"均为空间直角坐标"| S7["七参数 大区域全局框架"] Q -->|"小范围平面测区"| S4["四参数 平面精调"] S7 --> C["先建整体三维关系"] S4 --> C C --> R["两者并存 七参数做底 四参数叠在上面精调"]

七参数和四参数的工程差异可以归成一张对照表，方便选型时快速判断：

对比项	七参数	四参数
作用空间	三维空间直角坐标	平面坐标
参数构成	3 平移 + 3 旋转 + 1 尺度	2 平移 + 1 旋转 + 1 尺度 + 基准原点
尺度基准	全局比例因子（K/1e6+1）	局部比例因子
适用范围	大区域、全局框架	小范围平面测区精调
典型场景	源目标均空间直角	地球面近似平面
是否叠加	可单独使用	常叠在七参数之上

三、高程拟合：把椭球高换回正常高

平面坐标换完了，还有个高程问题：GPS 测出来的是椭球高 ，可工程用的通常是正常高（相对似大地水准面）。两者差一个起伏，不能简单相减，得用一个"拟合面"来修正。

拟合面常用多项式表示，系数是 A0~A5，加一个基准原点：

// 平面拟合：高程修正值 = A0 + A1 * (N - OrgN) + A2 * (E - OrgE)
fun heightCorrect(n: Double, e: Double): Double {
    return a0 + a1 * (n - orgN) + a2 * (e - orgE)
}

高程拟合的方法选择本身就是个工程决策，常见的几种：

• 加权平均：按距离加权，适合控制点分布不规则、只求一个整体修正量；
• 平面拟合：用 A0 + A1·dN + A2·dE，适合小范围、地形平坦；
• 曲面拟合：升到更高阶（A0~A5），能表达更复杂的起伏，但要更多控制点才稳；
• 自动判断：让求解器根据控制点数量/分布自己挑一种；
• 垂直平差：当成一个整体基准平移 + 南北/东西向坡度来处理。

// 高程拟合方法枚举：把"选哪种拟合"从页面逻辑里收口
enum class FitMethod { WEIGHTED_AVG, PLANE, SURFACE, AUTO, VERTICAL }

// 拟合接口：统一入口，具体算法可替换
interface HeightFitter {
    fun fit(controlPoints: List<ControlPoint>): HeightModel
    fun correct(model: HeightModel, n: Double, e: Double): Double
}

选错了，拟合面在小范围内看着没问题，出了控制点范围就飞了。这是高程拟合最典型的"专业陷阱"。下面这张表把方法、特征和适用场景对齐，作为选型的硬参照：

方法	公式 / 特征	适用场景
加权平均	按距离加权	控制点分布不规则、只求整体修正
平面拟合	A0 + A1·dN + A2·dE	小范围、地形平坦
曲面拟合	A0~A5 高阶多项式	起伏复杂、控制点充足
自动判断	按数量/分布自动挑	不固定测区
垂直平差	基准平移 + 南北/东西坡度	整体带坡度

四、参数求算的工程化闭环：回代残差验收与单测钉死

把前面两节的专业坑汇总成一张对照表，方便排查时直接对号入座------这些坑几乎都出在"量纲或参数在层间被换掉"：

现象	根因	解法
坐标偏出十几公里	旋转角以"秒"返回未 /3600 转度	统一 /3600 转度或弧度再进矩阵
尺度差百万倍	K 是百万分比未 K/1e6+1 还原	还原真实比例因子 K/1e6+1
高程出控制点范围就飞	拟合面阶数/方法选错	按控制点数量地形选方法，加范围校验
两页面单位显示不一致	单位换算散落各页	全局注册表 + 统一 format 入口
切换单位数字剧烈跳动	各页精度硬编码不同	精度按量纲配置，切换小数位不变
椭球高当正常高用	混淆两种高程语义	必须经高程拟合修正面再使用

求参这件事，最难的不是写对公式，而是证明它算得对。工程化的做法有三板斧：

1. 回代残差验证。用算出的参数把控制点的源坐标换回目标坐标，看偏差（Hrms/Vrms）是否在限差内。残差本身就是一道验收关卡，超过阈值就该怀疑控制点里混进了坏点。
2. 把已知结果钉进单元测试。维护一组真实坐标对和一份"参照软件算出的权威结果"，每次改动后用断言（比如精度 0.0001）校验参数是否仍一致。改库、重构都不会悄悄跑偏。
3. 参数模型与计算实现分离。结果类（七参/四参/拟合系数）只管承载，求解逻辑收敛在底层，上层只负责"收集控制点 → 配置方法 → 拿结果 → 验证残差"。

先看控制点模型和残差怎么定义，这一步把"参与标志"和"残差"都钉进类型：

// 控制点：源坐标 + 目标坐标 + 参与标志 + 残差
data class ControlPoint(
    val srcB: Double, val srcL: Double, val srcH: Double,  // 源 经纬度+椭球高(WGS84)
    val tgtN: Double, val tgtE: Double, val tgtH: Double,  // 目标 北东高(本地)
    val useH: Boolean,   // 是否参与平面求参
    val useV: Boolean,   // 是否参与高程求参
    var hrms: Double = 0.0,  // 水平残差
    var vrms: Double = 0.0,  // 垂直残差
)

// 参数模型只承载，不做事：七参/四参/拟合系数都是纯数据
data class Param7Result(
    val dx: Double, val dy: Double, val dz: Double,
    val rxDeg: Double, val ryDeg: Double, val rzDeg: Double, // 已转成度
    val scale: Double,                                        // 已还原 K/1e6+1
)

回代残差验证与单测断言，是"可测试闭环"的两道关：

// 回代：用求出的参数把控制点源坐标换回目标，算残差
fun backCheck(param7: Param7Result, points: List<ControlPoint>): List<ControlPoint> {
    return points.map { p ->
        val (x, y, z) = transformSeven(
            blhToXyz(p.srcB, p.srcL, p.srcH),
            p.srcH, p.srcH, p.srcH,           // 占位，实际平移取 param7
            Math.toRadians(param7.rxDeg),
            Math.toRadians(param7.ryDeg),
            Math.toRadians(param7.rzDeg),
            param7.scale,
        )
        p.hrms = Math.hypot(x - p.tgtN, y - p.tgtE)
        p.vrms = Math.abs(z - p.tgtH)
        p
    }
}

// 单测：把权威结果钉死，断言精度 0.0001
@Test
fun `七参数与权威结果一致`() {
    val param = solver.solveSeven(REF_SRC, REF_TGT)
    assertEquals(REF_DX, param.dx, 0.0001)
    assertEquals(REF_SCALE, param.scale, 1e-6)
}

把专业算法当成一个可单测的纯函数模块，界面和参数文件都是它的外围。比起在 Activity 里堆一坨求参逻辑，这种模块你敢改、敢重构，也敢交给新人维护。这套闭环流程可以画成一张图：

flowchart TD A["采集控制点 含 useH/useV"] --> B["求解器 求七参/四参/拟合"] B --> C["回代残差 Hrms/Vrms"] C -->|"超限差"| D["剔除坏点 重新求参"] C -->|"合格"| E["参数模型入库"] D --> B E --> F["单元测试 断言精度 0.0001"] F --> G["业务/界面/存储复用同一模型"]

五、单位系统：内部标准单位 + 全局注册表 + 统一格式化

参数部分解决的是"数算不对"，单位系统解决的是"量纲乱套"。做测量、GIS 类应用，用户要在"米 / 英尺 / 英寸"、"度 / 弧度 / 度分秒"、"平方米 / 亩"之间切换，切换一次，全 App 所有显示距离、角度、面积的地方都要跟着变。

如果每个页面各自存一份单位、各自写一遍换算，那将是灾难：漏改一处、两个页面显示不一致、换算精度还不一样。核心矛盾只有一句：数据在内部始终用统一的标准单位（距离用米、角度用度、面积用平方米），显示时才按当前单位换算。 换算和格式化收口在单位系统里。

5.1 单位注册表：一组"量纲 + 当前单位"

先定义量纲（长度、角度、面积），每个量纲有自己的"基准单位"和一组可切换的"显示单位"。全局一个注册表持有每个量纲当前选中的单位：

enum class Dimension { LENGTH, ANGLE, AREA }

// 一个量纲下的单位定义
data class Unit(
    val id: String,
    val label: String,
    val toBase: (Double) -> Double,  // 本单位 -> 基准单位
    val fromBase: (Double) -> Double // 基准单位 -> 本单位
)

class UnitRegistry {
    // 每个量纲当前激活的单位
    private val current = mutableMapOf<Dimension, Unit>()

    fun switch(dimension: Dimension, unit: Unit) {
        current[dimension] = unit
    }

    fun current(dimension: Dimension): Unit =
        current[dimension] ?: defaultFor(dimension)
}

这样"当前用哪个单位"是一个全局可变状态，任何页面想读当前单位、想切换单位，都走同一个入口。初始化时给每个量纲一个默认单位，避免空指针：

// 默认单位与注册：基准单位固定，显示单位可切
val METER = Unit("m", "m", { it }, { it })
val FOOT = Unit("ft", "ft", { it / 3.2808 }, { it * 3.2808 })
val DEGREE = Unit("deg", "°", { it }, { it })
val DMS = Unit("dms", "°′″", { dmsToDeg(it) }, { toDMS(it) })

fun defaultFor(d: Dimension): Unit = when (d) {
    Dimension.LENGTH -> METER
    Dimension.ANGLE -> DEGREE
    Dimension.AREA -> METER   // 面积基准也用平方米
}

5.2 换算与格式化：数据进，字符串出

页面拿到内部的标准值（米/度/平方米），要做两件事：换算成当前单位、再格式化成字符串。这两步都封装成"从量纲 + 值 到 显示字符串"的单一入口：

fun format(dimension: Dimension, value: Double): String {
    val unit = registry.current(dimension)
    val converted = unit.fromBase(value)     // 标准单位 -> 当前单位
    val precision = precisionFor(dimension)   // 每个量纲的精度策略
    return "${trim(converted, precision)} ${unit.label}"
}

页面从此不再关心"现在是米还是英尺、要不要保留 3 位小数"，只需调用 format(Dimension.LENGTH, internalMeters)。换单位时，页面只需重新触发一次重绘，取值函数自动读到新单位，显示立刻统一变化。

角度单位（度 / 度分秒 / 弧度）特殊一些，需要专门处理。基准用"度"，转换函数：

// 度 -> 度分秒 的转换
fun toDMS(degrees: Double): String {
    val d = degrees.toInt()
    val m = ((degrees - d) * 60).toInt()
    val s = (degrees - d - m / 60.0) * 3600.0
    return "${d}°${m}′${String.format("%.1f", s)}″"
}

5.3 精度与显示策略：别让换算结果吓到用户

不同量纲的显示精度策略不同，应该按量纲配置而非各处硬编码：

• 距离：默认保留 3 位小数，单位切换时小数位保持不变，避免切换后数字剧烈跳动；
• 角度：默认保留 4 位小数；切到度分秒时，秒保留 1 位；
• 面积：根据量级自适应，几平方米和几十万平方米用不同精度。

// 精度策略按量纲配置，与格式化一并输出
fun precisionFor(dimension: Dimension): Int = when (dimension) {
    Dimension.LENGTH -> 3   // 距离 3 位小数
    Dimension.ANGLE -> 4    // 角度 4 位小数
    Dimension.AREA -> 2     // 面积按量级再调
}

把精度也收口进单位系统，配合格式化一起输出，就能保证全 App 任何一个角落的数值，格式都是统一的。单位换算的链路可以画成一张图，看清"内部标准值"到"显示字符串"只经过一个入口：

flowchart LR I["内部标准值 米/度/平方米"] --> R["UnitRegistry 当前单位"] R --> C["fromBase 换算到显示单位"] C --> P["precisionFor 取精度"] P --> F["trim 格式化"] F --> O["显示字符串 带单位标签"]

量纲与用例的对照表，把"基准单位、显示单位、精度、换算例"锁死，避免各页各写：

量纲	基准单位	显示单位	精度策略	换算示例
长度 LENGTH	米	米 / 英尺 / 英寸	3 位小数	1 m = 3.2808 ft
角度 ANGLE	度	度 / 度分秒 / 弧度	4 位；秒 1 位	1° = 60′ = 3600″
面积 AREA	平方米	平方米 / 亩	量级自适应	1 亩 ≈ 666.67 ㎡

5.4 收口：给"带单位的值"和"带作用域的坐标"造类型

回到开篇的统一判准。单位系统和坐标系转换，本质都在解决"值在不同层之间被换掉"。只靠全局注册表和格式化还不够------如果某段代码手里就是一个裸 Double，它仍然可能被人当成别的量纲去用。彻底的收口，是把"带单位的值"和"带作用域的坐标"都造成类型：

// 带单位的值：永远以基准单位存储，携带量纲
data class Measure<T : Dimension>(val dimension: T, val baseValue: Double) {
    fun display(registry: UnitRegistry): String = format(dimension, baseValue)
}

// 带作用域的坐标：携带所属坐标系与将用哪套参数去换
data class ScopedCoordinate(
    val system: CoordinateSystem,        // WGS84 / 本地测区A / 测区B
    val n: Double, val e: Double, val h: Double,
    val heightKind: HeightKind,          // ELLIPSOID 椭球高 / NORMAL 正常高
) {
    // 换到目标系必须显式传参数，作用域跟着坐标走，换不掉
    fun transformTo(target: CoordinateSystem, param: Param7Result): ScopedCoordinate =
        transformWith(param).copy(system = target)
}

Measure 保证"长度永远是米、角度永远是度"进类型；ScopedCoordinate 保证"这套坐标属于哪个系、用哪套参数换"被锁死在对象里。任何跨系换算都必须显式传参，编译期就拦住了"拿 A 测区的参数去换 B 测区的点"。这就是"造类型而非靠注释"的全部含义。

六、小结

• 测绘 bug 多不在算法，而在量纲与参数在层间被换掉：角度长度相加、米当英尺、椭球高当正常高、A 测区参数换 B 测区的点。
• 七参数（3 平移 + 3 旋转 + 1 尺度，覆盖空间直角全局）、四参数（2 平移 + 1 旋转 + 1 尺度 + 基准原点，平面精调）应写成可测试纯函数 ，旋转角须 /3600 从"秒"转度、尺度须 K/1e6+1 还原真实比例因子。
• 高程拟合把椭球高修成正常高，方法按控制点数量与地形选（加权/平面/曲面/自动/垂直平差），选错会"出控制点范围就飞"。
• 参数求算工程化三板斧：回代残差验收（Hrms/Vrms 超阈查坏点）→ 单测钉死权威结果（断言 0.0001）→ 参数模型与求解逻辑分离。
• 单位系统核心：内部始终存标准单位（米/度/平方米），显示才换算；全局注册表 + 统一 format 入口 + 按量纲的精度策略（距离 3 位、角度 4 位、秒 1 位、面积自适应）。
• 终极收口：给"带单位的值"造 Measure、给"带作用域的坐标"造 ScopedCoordinate，让单位与作用域随类型走，而不是靠注释提醒------这是把两篇笔记合成一个可测试专业模块体系的关键。

---

你手上的测绘/测量项目里，坐标转换和单位换算现在是散落在各页面，还是已经收口成了一个可单测的纯函数模块？哪一处最让你不敢改？