Android GIS系列 栅格怎么存、格网怎么归算：两个容易混淆的 GIS 链路

栅格是一张二维数组，但每个元素都带物理含义------把结构层当成语义层用，就会出现"像素当米用"。

处理影像、高程网格、DEM 这类栅格数据时，新手最容易把两件事搅在一起：像素值该怎么在内存里存，以及这个像素在真实地面上到底代表多长距离。一个关心"怎么放进去"，一个关心"拿出来代表什么"，看似都在跟栅格打交道，其实是两条完全不同的链路。

我见过最典型的一类 bug：有人写了一套高程读取，开发时用的是 8 位灰度测试图，一切正常；换成 16 位整型 DEM 一跑，高程值全乱了，不是被截断就是符号不对。这还只是结构层内部的错。更隐蔽的是另一类：高程读对了，但下游做距离计算时直接拿了"像素个数"当"米"，放样到现场发现整体偏了几十厘米到几米，而且越远偏得越多，怎么查坐标转换都查不出问题------因为坐标转换没错，错在"像素"和"米"根本不是一回事。

把第一件事搞错，你存进去的高程会被当成灰度、浮点会被当成整数，读出来全是错的；把第二件事搞错，你量了 100 个像素，就以为那是 100 米，放样直接偏到隔壁地块。这两类错误经常结伴出现，因为很多人没意识到：栅格只是一张二维数组，但每个元素都带物理含义。这篇文章把栅格数据的"结构层"（怎么存、怎么在类型间包装转换）和"语义层"（像素在地面代表多长、怎么归算）拆开讲，帮你把两条链路分清楚。

一、栅格缓冲区：一块内存要按任意类型读写

先讲结构层。处理栅格数据（影像、高程网格、DEM）时，一个绕不开的需求是：同一块连续内存，希望它能按不同数据类型来解释。有时里面是 8 位灰度，取值范围 0~255；有时是 16 位整型高程，可能带符号、范围到 ±32767；有时又是 32 位浮点，存的是精确高程或反射率。如果你为每种类型各写一套类，代码爆炸；如果你用 Object 硬扛，又慢又难维护。

Java 里有个很尴尬的处境：泛型 T 在运行时会被擦除 ，你没法在 T get() 里直接说"按 T 的类型去读内存"。假设有一个通用的数据缓冲抽象，希望它能封装任意类型的栅格值：

abstract class DataBuffer<T> {
    protected val buffer: ByteBuffer
    abstract fun get(): T      // 按 T 的类型读当前值
    fun put(value: Any): DataBuffer<T>   // 写入任意原始类型
}

你面对的核心矛盾是：get() 里到底调用 getByte()、getShort()、getInt() 还是 getDouble()？这取决于 T 是什么，但运行时的 T 是未知的 （被擦除了）。你总不能在泛型方法里写 when(T::class)，因为 T::class 取不到------编译期 T 还在，T::class 能写出，但运行期 T 已经被擦成 Object，JVM 里根本没有 T 的影子。这正是泛型"编译期存在、运行期消失"带来的硬限制。

更麻烦的是索引语义。栅格是二维数组，但内存是线性的。一个"位置 i"应该是"第 i 个元素"，而不是"第 i 个字节"------对 INT 类型，第 10 个整数对应第 40 个字节（一个 int 占 4 字节），如果直接用字节下标去取，取出来的就是错位且破碎的数据。所以"读第 i 个"必须换算成"偏移 i × 单个元素字节数 个字节"，而"单个元素字节数"又由类型决定。这又绕回到了"类型在运行时不知道"那个坑上。

有人会问：为什么不直接用普通的 Array<Any> 或原生数组，而非要包一层 ByteBuffer？原因是栅格数据往往从文件或网络直接以字节流形式读入，ByteBuffer 能零拷贝地包裹这块原生内存，避免中间再转抄一份；而且它支持按字节序（大端 / 小端）读取，跨平台的栅格文件（比如不同字节序的 DEM）也能被正确解析。类型包装层恰恰是在 ByteBuffer 之上，补齐"按元素下标索引"和"按具体类型读取"这两件 ByteBuffer 自己不负责的事。选 ByteBuffer 而不是数组，本身就是在为"多类型、零拷贝、跨字节序"这三个真实需求让路。

二、匿名子类把类型"焊"回去

Java/Kotlin 的泛型是编译期类型检查、运行时擦除 的。也就是说，DataBuffer<Int> 和 DataBuffer<Double> 在运行时刻是同一个类，T 只是一个编译期符号，运行时不存在。所以：

1. 你没法用 T 直接索引到正确的读法；
2. 一个"读当前值"的抽象方法，必须在具体类型下实现；
3. 但你又不想为 7 种类型各写 7 个完整子类。

思路很直接：既然 T 在运行时不存在，那就让每个实例在构造时就"自带"一份正确的读取行为。 用匿名子类，每种 DataType 生成一个只覆盖 get() 的匿名实例：

companion object {
    fun create(buffer: ByteBuffer, datatype: DataType): DataBuffer<*> =
        when (datatype) {
            DataType.BYTE -> object : DataBuffer<Byte>(buffer, datatype) {
                override fun get() = buffer.get()
            }
            DataType.SHORT -> object : DataBuffer<Short>(buffer, datatype) {
                override fun get() = buffer.getShort()
            }
            DataType.INT -> object : DataBuffer<Int>(buffer, datatype) {
                override fun get() = buffer.getInt()
            }
            DataType.FLOAT -> object : DataBuffer<Float>(buffer, datatype) {
                override fun get() = buffer.getFloat()
            }
            DataType.DOUBLE -> object : DataBuffer<Double>(buffer, datatype) {
                override fun get() = buffer.getDouble()
            }
            // ... 其余类型类似
        }
}

flowchart TD A["create buffer datatype"] --> B{"datatype 类型"} B -->|"BYTE"| C["get 读 getByte"] B -->|"SHORT"| D["get 读 getShort"] B -->|"INT"| E["get 读 getInt"] B -->|"FLOAT"| F["get 读 getFloat"] B -->|"DOUBLE"| G["get 读 getDouble"]

每个匿名子类只覆盖一行 get()，其余逻辑（索引换算、resample、flip）全在基类里共用。这既避免了写 7 个完整子类的爆炸，又把"类型信息"以多态 的形式固化到了每个实例里------get() 被调用时，虚拟分派自动走到正确的读取代码，运行时开销为零。

为什么强调"零开销"？因为另一种常见做法是反射或 when(type) 分支判断，每次读取都要判断一遍类型，大量像素遍历时这笔判断成本不可忽略。而匿名子类把"类型 → 读法"的映射在构造时就定死了，调用 get() 直接是一次函数分派，没有分支、没有反射，和其它手写 buffer.getInt() 一样快。代价只是每个 DataType 多生成一个极轻量的匿名类，这点类加载开销几乎可以忽略。

位置换算则由基类统一处理：把"第 i 个元素"换算成"第 i × 类型字节数 个字节"：

fun get(i: Int): T {
    buffer.position(i * datatype.size())   // datatype.size() = 字节数
    return get()
}

这里 datatype.size() 返回的是单个元素占几个字节（BYTE 是 1、SHORT 是 2、INT/FLOAT 是 4、DOUBLE 是 8）。基类不需要知道具体类型，只要问 datatype.size() 就能正确定位。这就是把"类型相关的部分"收敛到 get() 和 size() 两个方法里，其余逻辑一律复用。

跨类型写入 ，用 instanceof 分派即可，因为写入侧拿到的是明确的具体值：

fun put(value: Any): DataBuffer<T> {
    when (value) {
        is Byte -> buffer.put(value)
        is Short -> buffer.putShort(value)
        is Int -> buffer.putInt(value)
        is Double -> buffer.putDouble(value)
        else -> throw IllegalArgumentException("unknown value: $value")
    }
    return this
}

写入比读取简单，因为调用方传进来的 value 是具体类型，运行时 is Byte / is Int 这类判断能正常工作（注意：这里判断的是具体值，不是泛型 T，所以不受擦除影响）。非法类型直接抛异常，把错误暴露在写入点而不是读出点，排错更友好。

重采样同样可以抽象在基类：最近邻插值，本质就是"从源缓冲按比例取像素填到目标缓冲"：

fun resample(from: Dimension, to: Dimension): DataBuffer<T> {
    val out = create(to.width * to.height, datatype)
    val xRatio = from.width.toDouble() / to.width
    val yRatio = from.height.toDouble() / to.height
    for (y in 0 until to.height) {
        for (x in 0 until to.width) {
            val px = floor(x * xRatio).toInt()
            val py = floor(y * yRatio).toInt()
            out.put(y * to.width + x, get(py * from.width + px))
        }
    }
    return out
}

注意重采样也只依赖基类已有的 get(i)、put(i, v) 和 create，完全不关心底层是 INT 还是 DOUBLE------类型抽象的红利在这里体现得最明显：一套重采样算法，七种类型通用。

整条链路下来，调用方永远面对一个统一的 DataBuffer<T>，内部却按真实类型在读写------类型抽象的正确性，靠的是多态而非 Object 强转。到这一步，结构层的问题（像素值怎么存、怎么在类型间转换）就解决了。

当然，这套手法有适用边界：它适合"类型集合固定、且每种类型只需覆盖很少几个方法"的场景。栅格数据类型就那么 7 种，每种只需覆盖一个 get()，用匿名子类最划算。如果子类方法很多、或类型可能动态扩展，匿名子类代码会膨胀，此时更扁平的做法是把"读取函数"存成函数对象 (ByteBuffer) -> T，用一张 Map<DataType, 读取函数> 查表。但不管哪种，核心思想一致：把"类型 → 行为"的映射固化下来，别在运行时反复猜。

如果把思路推到极致，还可以更进一步：把"类型 → 读取函数"做成一个函数表 Map<DataType, (ByteBuffer) -> T>，每种类型注册一个读取函数对象。调用 get() 时直接 readers[datatype](buffer)，省掉匿名子类的类生成，结构也更扁平、更易单测。代价是第一次访问要多一次 Map 查表（一次哈希，几乎可忽略），以及要额外维护这张表。匿名子类和函数表没有绝对优劣，判断标准是"类型是否稳定、子类方法有多少"------稳定且少方法用前者，多变或方法多则用后者。栅格数据类型就那么几种、且只需覆盖一个 get()，所以匿名子类是当下最合适的选择。

三、坑：把"像素数"当成"米"用

但结构层顺了，不等于整件事就对了。结构层只管"这块内存里第 i 个位置是个什么类型的数"，它完全不知道这个数在现实世界代表什么。一个高程栅格，每个像素是 16 位整型，结构层把它正确读出来了；可如果你接着拿"横向 100 个像素"当成"100 米"去放线，错就来了。

原因很简单：像素是存储单位，米是物理量，中间隔着一个分辨率。栅格的每个像素对应地面上一块正方形区域，边长就是分辨率（比如 0.5 米/像素、30 米/像素）。100 个像素在 0.5 米分辨率下是 50 米，在 30 米分辨率下是 3000 米------同一个"100"，落到地面上差了 60 倍。把结构层产出的"像素数"直接当成语义层的"米"，就是典型的量纲错误，而且它不会报错，只会在长距离上悄悄累积偏差。

这类错误的迷惑性在于：在小范围、低精度需求下，它看起来"也没啥问题"。10 个像素当 10 米用，差可能只有几米甚至更小，肉眼难辨；可一旦尺度拉到几百上千个像素，或者分辨率本身很大（比如卫星影像 30 米/像素），误差就会膨胀到工程不可接受的程度。更糟的是，这个错误发生在"读数之后、计算之前"的环节，既不在类型包装里，也不在坐标转换里，所以常规的调试手段很难抓到它------你能看到坐标都是对的，但现场就是对不上。

这正是要引入语义层的原因：栅格的每一个元素除了"值"还带"物理含义"，而把值翻译成物理量，靠的是投影归算，不是类型包装。

四、格网与地面的归算：投影平面距离会撒谎

讲语义层。做测量、工程放样、测绘内业的人，可能都遇到过这种诡异的现象：同一个两点之间，投影坐标系里算出来的距离，和你在现场用全站仪、钢尺实测的距离，对不上。短的差几厘米，长的可能差几十厘米甚至更多。

假设你有一个投影坐标系（比如高斯-克吕格），里面记录了工程区的控制点。你要在 A、B 两点之间放线，全站仪架在 A 点。你用坐标反算出 AB 的"图上距离"是 500.000 米，可全站仪实测的斜距却是 499.978 米。这 2.2 厘米的差异，不是误差，而是系统性偏差。原因有两个：

1. 比例因子：把椭球面上的弧段摊平到投影平面上，会产生尺度缩放。中央子午线附近变形小，离得越远变形越大。
2. 高程因子：你站在地面，地面离椭球面有一段高度。你把"贴在地面上的真实长度"投影到椭球上，自然也会缩短。

两者乘在一起，就是所谓的"组合比例因子"。换算关系如下：

地面距离 = 格网距离 / 组合因子
格网距离 = 地面距离 × 组合因子

只要算准了组合因子，两段距离就能互相换算。难点在于：组合因子不是常量，它随参考点的纬度、经度差、高程一起变化，必须针对工程区的参考点单独计算。

先看比例因子从哪来。以最常见的高斯投影族（高斯-克吕格、横轴墨卡托、UTM）为例，投影把一个椭球上的点映射到平面上，映射本身会引入随位置变化的尺度变形。衡量这个变形，可以用曲率半径来刻画------在测量学里，用子午圈曲率半径 和卯酉圈曲率半径 来描述椭球表面的局部几何，二者的几何平均就是平均曲率半径：

val a = crs.ellipsoid.a      // 长半轴
val b = crs.ellipsoid.b      // 短半轴
val e1 = sqrt(a * a - b * b) / a   // 第一偏心率
val e2 = sqrt(a * a - b * b) / b   // 第二偏心率
val B = deg2rad(lat)
val W = sqrt(1 - e1 * e1 * sin(B) * sin(B))
val V = sqrt(1 + e2 * e2 * cos(B) * cos(B))
val M = c / (V * V * V)       // 子午圈曲率半径
val N = a / W                 // 卯酉圈曲率半径
val aveRadius = sqrt(M * N)   // 平均曲率半径

这里 c 是极曲率半径（c = a / sqrt(1 - e1*e1)，即 a^2/b）。M 描述沿经线方向的曲率，N 描述沿纬线方向的曲率，二者在赤道和极点差异明显，在中等纬度接近。取几何平均得到 aveRadius，它代表该纬度附近椭球表面的"平均弯曲程度"。

有了平均曲率半径，高程因子就非常直观：你站得越高，投影到椭球上就越缩。它等于"椭球处半径 /（椭球处半径 + 你的高程）"，这是一个小于 1 的因子，所以地面距离总比格网距离大：

val heightFactor = aveRadius / (alt + aveRadius)

直觉上可以这样理解：地面是贴在椭球面之上 alt 高度的一层曲面，把地面上一段长度"压"回椭球面时，半径变小的那一层周长更短，所以长度被压缩了。海拔越高，压缩越明显，高程因子越小。

而比例因子则是在基础比例尺 k0 之上，再叠加投影的局部变形修正。对高斯投影族，可以用经度差展开的级数来逼近：

val l = deg2rad(dL)                       // 相对中央子午线的经度差
val d2 = 0.5 * l * l * cosB * cosB * (1 + eta * eta)
val d4 = l.pow(4) * cosB.pow(4) * (5 - 4 * t * t) / 24
val scaleFactor = k0 * (1 + d2 + d4)

k0 是中央子午线比例尺（高斯-克吕格通常取 1.0，UTM 取 0.9996）。d2、d4 是经度差 l 的二阶、四阶修正项------注意它们都含 l*l，所以离中央子午线越远，比例因子偏离 k0 越大，这正对应了"中央子午线附近变形小、远处变形大"的结论。级数只取前两项，在中低纬度、离中央子午线不太远时精度足够；工程级精度要求下一般就够用。

补充一点：高斯-克吕格的 k0 取 1.0，UTM 取 0.9996，所以同样经度差下 UTM 的比例因子整体略小------这 0.04% 的差异，正是 UTM 把变形均摊到南北两条标准纬线附近的体现，目的是让整条带内的尺度变形既不太大也不太小。别小看这 0.04%，乘以几十公里的距离就是几十米的偏差；如果混用两种投影的 k0 去算归算，系统性错误会直接进到放样结果里。

最后把两者相乘：

val combinedFactor = scaleFactor * heightFactor

这就是"格网 ↔ 地面"换算里最关键的那个数。有了它，距离和坐标都能互相折算。回到开头那个例子：图上 500.000 米，如果组合因子是 1.000044，地面距离就是 500.000 / 1.000044 ≈ 499.978 米，和全站仪实测严丝合缝。所以那 2.2 厘米的差异，根本不是 bug，而是没做归算。

还有一个常被问到的问题：既然组合因子随点变化，算距离时该用 A 点、B 点还是中点？答案是：在局部小范围内，用靠近工程区的参考点近似即可，误差在工程允许之内；若两点相距很远（比如几十公里以上），严格做法是对整条路径逐段取当地因子积分。日常工程放样尺度下，取单一参考点因子已经足够，这也是测量软件默认只让你选一个参考点、而不是对每对点单独算因子的原因------在局部近似的精度兜底之下，简单就是更好的工程选择。

把归算因子做成"随点刷新"还是"固定参考点"，本质是精度与简单的取舍：随点刷新每算一次距离都重算因子，交互略重但精度最高；固定参考点一次算好、全局复用，简单顺滑，代价是离参考点越远近似误差越大。工程上通常选后者，因为放样区范围有限，参考点选在工程中心，误差完全可以忽略------这再次印证了"局部近似"在测量软件里的核心地位：它不是偷懒，而是在已知误差界内的最优解。

flowchart LR A["投影格网距离"] --> B["组合比例因子"] B --> C["地面实测距离"] D["平均曲率半径"] --> E["高程因子"] F["经度差级数"] --> G["比例因子"] E --> B G --> B

五、分投影族归算，以及两条链路的关系

不同投影的尺度公式长得不一样，所以代码里先按投影类型分流：

• 高斯投影族（高斯-克吕格 / 横轴墨卡托 / UTM）：直接用上面的经度差级数展开。
• 兰勃特切圆锥（1SP） ：需要引入等角投影的量------等量纬度差 deltaQ、径向距离 rho、以及投影常数 beta，用它计算该点的尺度比。
• 兰勃特割圆锥（2SP） ：多了一条割纬线，两条标准纬线 lat1、lat2 共同决定投影常数 beta。

比如切圆锥的尺度比，可以用径向距离和当地卯酉圈半径之比来算：

val m = beta * rho / (N * cos(B))
val scaleFactor = k0 * m

而 beta、rho 这些量，都是从"等量纬度"（等角投影的核心中间量）推出来的。等量纬度本身是一个含对数与偏心率修正的表达式：

fun isoLatitude(B: Double, e1: Double): Double =
    0.5 * ln((1 + sin(B)) / (1 - sin(B)))
        - 0.5 * e1 * ln((1 + e1 * sin(B)) / (1 - e1 * sin(B)))

把这些中间量串起来，就能得到每个投影族各自的组合因子。整个过程参考的是经典测量学教材中的"地面归算"章节，但代码把它们收敛成了可复用的纯函数。这里有个工程上的关键点：组合因子必须以"工程区的参考点"为准单独计算。参考点选得离工程区越近，局部近似越准；如果拿一个很远的城市坐标去算因子，再套到本地放样上，偏差会重新放大。这也解释了为什么测量软件通常让用户"在工程区里选一个参考点"来生成归算参数，而不是用一个全局常量。

现代做法里，很多软件会把这个归算因子做成"随点位置实时刷新"的全局参数，而不是每对点单独算，从而在交互上更顺滑，精度上也足够。但无论怎么封装，底层永远绕不开"组合因子 = 比例因子 × 高程因子"这一条。

把结构层和语义层并排看，栅格数据其实有两张脸：

维度	结构层（类型包装）	语义层（格网与地面归算）
关心什么	像素值怎么在内存里存、怎么在类型间转换	这个像素在真实地面上代表多长、怎么归算
典型错误	类型擦除导致读错读法、像素/字节混淆	像素当米用、忽略分辨率与组合因子
关键量	DataType、字节数、索引换算	分辨率、比例因子、高程因子、组合因子
工具	匿名子类固化类型、ByteBuffer	曲率半径、投影族公式、等量纬度
出错表现	读出来的值整体错位、类型不对	距离/坐标系统性偏移、长距离累积

统一根因一句话：栅格只是一张二维数组，但每个元素都带物理含义。 结构层解决"怎么存"，语义层解决"代表什么"，把结构层当成语义层用，就会出现"像素当米用"这类量纲错误。两条链路缺一不可------只管结构层，值是对的但量纲是错的；只管语义层，连值都读错就更无从谈归算。

一个实用的自检习惯是：凡是栅格参与距离、面积、放样计算，先问自己两个问题------"我读出来的数是不是对的类型？"（结构层）和"我有没有把像素换算成真实地面量？"（语义层）。两个问题都答了"是"，结果才站得住脚。

回到文章开头那两个 bug：高程值全乱的问题，根子在结构层------用错了 DataType，把 16 位当成 8 位读，高位被截断；而放样整体偏掉的问题，根子在语义层------像素没乘分辨率、没做地面归算，相当于把"格子数"直接当"米"。两个 bug 表现很像（都是"结果不对"），但修的地方完全不同：前者改类型包装，后者改归算。分不清结构层和语义层，就会在错误的那一层反复折腾，越改越乱。把两条链路拆开，不只是文章写法，更是排错时的第一直觉。

小结

• 泛型在运行时被擦除，DataBuffer<T> 没法按 T 直接读内存，要用匿名子类在构造时固化类型、运行时零开销。
• 位置换算（第 i 个元素 → 第 i×size 个字节）放基类统一处理，跨类型写入用 instanceof 分派，类型集合有限时匿名子类比反射更划算。
• 像素是存储单位、米是物理量，中间隔着分辨率；把"像素数"直接当"米"是典型量纲错误，且只在长距离上暴露。
• 投影平面距离 ≠ 地面实测距离，差在比例因子（投影变形）与高程因子（高度压缩）的乘积上。
• 组合因子 = 比例因子 × 高程因子，是格网与地面互转的唯一纽带，且随参考点纬度、经度差、高程变化，须就近取参考点计算。

---

系列导航：GIS 系列第 7 篇（共 10 篇）。上一篇《异步 IO 流与数据解析管道》，下一篇《火星坐标反解与投影映射》。

你处理栅格时，是先把"像素数 × 分辨率"转换成地面距离再做计算，还是直接拿像素下标去参与放样？