摘要：一份 SHP、一张 CAD 图、一堆测量点库——把它们画到地图上要过两道关：格式关（怎么读进来）和坐标关（怎么换算到屏幕）。这篇讲清两道关的解耦方式，以及为什么"逐点投影"在点一多就废，而"中心点 + 比例尺"能把成千上万个点又快又稳地画上去。
目录（TOC）
一、两个现场：读一个画一个，和多点就卡死
1.1 现场一：读一个画一个，后面全是灾难
你刚拿到一份测绘队发来的矢量数据文件，可能是 .shp、可能是 CAD 图纸、也可能是一堆带坐标的测量点库。你只想做一件事——把它画到地图上。
大部分人第一版代码长这样：
fun loadAndDraw(filePath: String, canvas: Canvas) {
val reader = openFile(filePath)
while (reader.hasNext()) {
val shape = reader.next()
// 读一个，画一个 —— 解析和渲染纠缠在一起
drawShape(shape, canvas)
}
}
看起来"顺理成章"的边读边画，恰恰是后面所有灾难的起点。 等你在真机上跑起来，会撞上三个麻烦：
- 换个坐标系全乱——矢量文件里的坐标可能是平面投影坐标，而地图要的是经纬度，中间差一次投影转换，漏了就偏；
- 画得很卡 / 内存爆——大量要素一次全画，没有分层、没有裁剪；
- 加一种格式要重写一遍——SHP 一套、CAD 一套、点库一套，全写死了。
1.2 现场二：逐点投影，点多就废
做测绘应用的人都经历过这一幕：手里是一批"北坐标、东坐标"的测量点，屏幕要的是像素，两边怎么对起来？
新手第一反应很简单粗暴——每个点都做投影转换：
// 直观但低效：每个点都走完整投影链路
fun surveyToScreen(north: Double, east: Double): PointF {
val latLon = surveyToLatLon(north, east) // 每点都投影反算，开销大
return projection.toPixels(GeoPoint(latLon))
}
点少时这代码毫无问题，可一旦点一多（线、面、整片图斑），"逐点全量投影"立刻暴露三个问题：
- 慢：每个点都做一次投影 + 反投影，累计开销可观；
- 抖动：不同点在投影边界附近精度不一致，画出来边缘不齐；
- 依赖地图引擎：一旦脱离地图视图（离屏绘制、打印出图），这套换算就废了。
二、根因：两道关，两个解耦
两个现场，其实卡在两道不同的关：
| 现场 | 卡在哪道关 | 问题的本质 |
|---|---|---|
| 读一个画一个 | 格式关 | 解析（IO 密集、一次性）与渲染（每帧触发）耦合 |
| 逐点投影卡死 | 坐标关 | 用"高成本精确换算"去做"海量点的批量换算" |
两道关的解法，思路是同一个：把"昂贵且多变的事"做一次，把"廉价且统一的事"留给批量。
- 格式关：解析做一次（格式相关、多变），产出统一几何对象；渲染只认统一对象（格式无关、统一）。
- 坐标关：投影做一次（昂贵、精确），建立基准；仿射换算做批量（廉价、线性）。
flowchart LR
subgraph G1["关卡一：格式关"]
P["解析<br/>SHP / CAD / 点库"] --> U["统一几何对象<br/>Feature"]
end
subgraph G2["关卡二：坐标关"]
B["投影换算<br/>建立基准（少量）"] --> A["仿射换算<br/>中心点+比例尺（海量）"]
end
U --> B
A --> D["Canvas 绘制"]
style P fill:#e6f7ff,stroke:#1890ff
style U fill:#f6ffed,stroke:#52c41a,stroke-width:2px
style B fill:#fff7e6,stroke:#fa8c16
style A fill:#f9f0ff,stroke:#722ed1,stroke-width:2px
三、关卡一：解析与渲染分离
3.1 两种完全不同的复杂度
- 解析：格式相关、IO 密集、一次性——把文件读成内存对象。SHP 要读几何 + 属性表，CAD 要解析各种图元，点库要查数据库；
- 渲染：坐标变换 + Canvas 绘制、每帧都可能触发——把内存对象画到屏幕。跟"你从哪个文件来的"无关，只跟"你的几何长什么样"有关。
两者耦合的恶果：数据多时解析和绘制互相拖累；格式一换，渲染逻辑被迫跟着改。
正确做法是：解析阶段产出"统一几何对象"，渲染阶段只认这种对象。
3.2 解析阶段：各格式 → 统一几何对象
// 每种格式各自负责"读进来"并转成统一对象
fun parseShp(filePath: String): List<Feature> {
val coords = readGeometry(filePath) // SHP 几何
val attrs = readDbf(filePath) // SHP 属性表
// 投影转换：把文件坐标系 -> 统一坐标系
return coords.map { Feature(toUnifiedCoord(it), attrs) }
}
fun parseCad(filePath: String): List<Feature> {
// CAD 图元（线、弧、圆、文字）-> 统一对象
}
fun parsePointLibrary(): List<Feature> {
// 点库 -> 统一对象
}
投影转换藏在解析里：矢量文件的坐标通常是平面投影（如高斯投影的北东坐标），而地图引擎内部是经纬度 / Web 墨卡托。解析时就要用文件自带的坐标系信息（.prj）做投影转换，得到统一的几何。
这一步千万别拖到渲染时——渲染每帧都跑，把一次性的投影塞进去，等于把 IO 成本乘以帧率。
3.3 渲染阶段：按"点/线/面"分发，而非按"格式"分发
// 渲染管线只认"统一几何列表"，不管来源
for (feature in allFeatures) {
if (feature.type == POINT) drawPointSymbol(feature, mapView, canvas)
if (feature.type == LINE) drawLine(feature, mapView, canvas)
if (feature.type == POLYGON) drawPolygon(feature, mapView, canvas)
}
注意这里的分发维度：按"点 / 线 / 面"分发，而不是按"SHP / CAD / 点库"分发。这就是解耦的收益——来什么格式，渲染代码都无感。
3.4 新增格式 = 新增解析器
正因为解析和渲染分离，三种数据源才能共用同一条绘制逻辑。新增一种数据格式，只需新增一个解析器，把它的输出接进统一模型即可——渲染、变换、坐标纠偏全部复用。
四、关卡二：坐标变换的两条路
4.1 屏幕与测量坐标是"平移 + 缩放"的仿射关系
屏幕像素和测量坐标之间，本质是一个仿射变换，由两部分决定：
- 平移：屏幕中心点对应的测量坐标（测量中心）；
- 缩放：比例尺——每像素对应的测量距离（横向
scaleE、纵向scaleN）。
所以只要维护住"屏幕中心 ↔ 测量中心"和"横向 / 纵向比例尺"这四个量，任何测量坐标都能用一个线性公式换算到屏幕，反之亦然。不需要每点重算投影——投影只用来在"屏幕范围和测量范围"之间建立一次性的基准换算。
4.2 由屏幕范围推算比例尺
当你知道当前屏幕对应的测量范围（东向 [minE, maxE]、北向 [minN, maxN]）时：
// 横向比例尺：东向范围宽度 / 屏幕宽度（像素）
scaleE = (maxE - minE) / screenWidthPx
// 纵向比例尺：北向范围高度 / 屏幕高度（像素）
scaleN = (maxN - minN) / screenHeightPx
// 通常强制二者一致（保证图上不变形），取较大者
if (scaleN > scaleE) scaleE = scaleN else scaleN = scaleE
为什么强制一致？ 因为如果横纵比例尺不同，一个正方形地块会被画成长方形——在测绘场景里这是硬伤。取较大者意味着"以较小的缩放倍率为准"，画面会留一点边，但绝不变形。
4.3 测量坐标 → 屏幕坐标
fun surveyToScreen(n: Double, e: Double, center: Point2D, centerPx: Point2D): PointF {
val x = centerPx.x + (e - center.e) / scaleE
val y = centerPx.y - (n - center.n) / scaleN // 注意：屏幕 y 向下，北向向上，故取负
return PointF(x.toFloat(), y.toFloat())
}
y 取负是关键：测量坐标"北"越大，屏幕 y（向下为正）越小，所以是减号。漏掉这个，图形会上下颠倒——这是坐标互转里最高频的一个 bug，而且因为"看起来画出来了"，常常要盯很久才发现。
4.4 屏幕坐标 → 测量坐标（反向）
fun screenToSurvey(px: Float, py: Float, center: Point2D, centerPx: Point2D): Point2D {
val n = center.n + (centerPx.y - py) * scaleN
val e = center.e + (px - centerPx.x) * scaleE
return Point2D(n, e)
}
反向换算在交互式采集里是刚需：用户在屏幕上点一下，你要反算出对应的测量坐标存进点库。注意它和正向公式严格互逆——任何一个符号写反，正反两次换算就不闭合，表现为"点下去存回来的坐标偏了一点点"。
4.5 经纬度底图下的"纬度修正"
当业务坐标是"经纬度"（而非平面投影）时，横向比例尺直接套"经度差 / 像素"会在高纬度严重失真——因为地球是球体，同一经度差在高纬对应的实际地面距离更短（到极点收敛为 0）。
工程上常引入一个纬度修正系数，把经度比例尺放大到接近真实地面比例：
// 经纬度模式下，把经度比例尺修正到真实地面尺度（示例系数 103000 量级）
val groundScale = lonScale * LAT_CORRECTION // 纬度高则修正更明显
// 修正后，一像素对应的"地面米数"才与北向一致，图才不变形
这个修正系数本质是 1 度纬度对应的地面米数（约 111km 量级）的换算，让"经度差"和"地面距离"在图上能统一。
4.6 分层策略：投影定基准，仿射算海量
如果重写，我不会只用一种策略，而是分层：
flowchart LR
BASE["投影换算<br/>（少量·建立基准）"] --> CENTER["中心点 + 比例尺"]
CENTER --> MASS["仿射换算<br/>（海量点）"]
MASS --> DRAW["Canvas 绘制"]
BASE --> ZOOM["缩放级别换算"]
style BASE fill:#fff7e6,stroke:#fa8c16
style MASS fill:#f9f0ff,stroke:#722ed1,stroke-width:2px
- 投影换算：只在"建立基准"时用（算中心点、算屏幕范围、算缩放级别），量少；
- 仿射换算：在"海量点批量绘制"时用，所有点共用同一个中心 + 比例尺，快且稳。
两者分工明确：投影定基准，仿射算海量。
这套"中心点 + 比例尺"的思想，也常见于 CAD 渲染、GIS 出图——本质上都是把"世界坐标 ↔ 设备坐标"简化为平移 + 缩放。
五、合起来：完整矢量渲染管线
把两道关的解法合起来，得到完整的矢量数据渲染管线：
flowchart TB
subgraph SRC["数据源（可插拔）"]
S1["SHP 解析器"]
S2["CAD 解析器"]
S3["点库解析器"]
end
SRC --> PRJ["投影转换<br/>（读 .prj，一次性）"]
PRJ --> GEO["统一几何列表<br/>List"]
GEO --> BASE["投影定基准<br/>中心点 + 屏幕范围"]
BASE --> AFF["仿射换算<br/>中心点 + 比例尺"]
AFF --> DISP{"按几何类型分发"}
DISP -->|"点"| DP["drawPointSymbol"]
DISP -->|"线"| DL["drawLine"]
DISP -->|"面"| DPG["drawPolygon"]
DP --> CV["Canvas"]
DL --> CV
DPG --> CV
style GEO fill:#f6ffed,stroke:#52c41a,stroke-width:2px
style BASE fill:#fff7e6,stroke:#fa8c16,stroke-width:2px
style AFF fill:#f9f0ff,stroke:#722ed1,stroke-width:2px
要点：
- 数据源可插拔：新增格式 = 新增解析器，接进统一
Feature模型； - 投影一次性：在解析阶段完成，不进渲染循环；
- 基准 + 仿射：投影只用来算中心点和范围，海量点走线性换算；
- 按几何类型分发：渲染代码对数据格式完全无感。
更进一步，可以把"坐标变换链"也做成可配置：投影方式、是否纠偏、目标坐标系，全部由数据源声明，而不是散落在各处 if-else。
六、坑对照表
| 症状 | 关卡 | 根因 | 解法 |
|---|---|---|---|
| 换个坐标系数据全偏 | 格式关 | 投影转换漏了或放错阶段 | 在解析阶段用 .prj 做投影转换 |
| 加一种格式要改好几处 | 格式关 | 解析与渲染耦合 | 统一 Feature 模型 + 按几何类型分发 |
| 数据一多就卡 / OOM | 格式关 | 一次全量绘制，无裁剪 | 分层 + 范围裁剪（见性能篇） |
| 点多了明显变慢 | 坐标关 | 逐点做完整投影 | 投影定基准，仿射算海量 |
| 图形上下颠倒 | 坐标关 | y 未取负（北向上、屏幕 y 向下） | y = centerPx.y - (n - center.n) / scaleN |
| 高纬度图形横向拉伸 | 坐标关 | 未做纬度修正 | 引入纬度修正系数统一地面尺度 |
| 点击位置与存回坐标对不上 | 坐标关 | 正反公式不严格互逆 | 检查符号，保证正反闭合 |
| 正方形地块画成长方形 | 坐标关 | 横纵比例尺未强制一致 | 取较大者统一横纵 |
| 脱离地图视图换算就废 | 坐标关 | 依赖 projection.toPixels | 用中心点 + 比例尺，与视图解耦 |
七、结论
- 矢量数据上地图要过两道关：格式关（解析 vs 渲染）和坐标关（投影 vs 仿射），两关都要解耦。
- 解析与渲染分离：解析负责把各格式读成统一几何对象，渲染只认统一对象；投影转换放在解析阶段，别拖到渲染时。
- 渲染按"点 / 线 / 面"分发，而非按格式分发；新增格式 = 新增解析器。
- 屏幕与测量坐标是平移 + 缩放的仿射关系，维护"中心点 + 横纵比例尺"即可批量换算。
- 测量 → 屏幕时 y 取负（北向上、屏幕 y 向下），漏了会上下颠倒；正反公式必须严格互逆。
- 经纬度底图下横向比例尺要加纬度修正系数，否则高纬严重失真。
- 分工：投影定基准、仿射算海量。
完整可运行源码：GitCode 仓库 · android_osmdroid_maplibre
对照阅读：本系列第 01 篇（坐标纠偏：WGS-84 落到 GCJ-02 底图，为什么要转两次）——坐标变换链和纠偏链在这里会交汇，两篇对照看能理清"什么时候该转、转几次"。
延伸阅读：本系列第 03 篇（分层世界：离线方案、图层模型与 Overlay 体系）
评论区聊聊：你在接入 SHP / CAD / 点库时，踩过"坐标系对不上"或者"图形上下颠倒"的坑吗？最后是怎么定位的？
本系列为 osmdroid / MapLibre 双引擎对照实战，源码开源可运行。如果这篇对你有帮助，点个赞收藏一下，后续会持续更新地图接入、数据绘制、性能优化的完整链路。
