GeoJSON vs TopoJSON：不仅是体积差异，而是数据模型的差异

👉 GeoJSON vs TopoJSON：不仅是体积差异，而是数据模型的差异

1. 问题背景（真实场景）

在一个地图项目中，我们曾经遇到一个很典型的问题：

需要展示全国行政区划（省 / 市 / 区）
使用 GeoJSON，数据体积约 12MB
前端加载慢、渲染卡顿

团队第一反应：

👉 "压缩一下不就好了？"

于是：

gzip ✔
删除 properties ✔
降精度 ✔

结果：

👉 依然很大，性能依然不理想 ❗

后来换了一种数据格式：

👉 TopoJSON

结果：

数据体积下降到 3MB
渲染明显流畅

👉 这时候很多人会得出一个"错误结论"：

👉 TopoJSON 只是更小的 GeoJSON

2. 核心问题（本质分析）

👉 这个认知是错的。

❗ 本质区别一句话：

👉 GeoJSON 是"几何模型"，TopoJSON 是"拓扑模型"

两者核心差异：

维度	GeoJSON	TopoJSON
数据模型	几何（Geometry）	拓扑（Topology）
存储方式	每个对象独立	共享边界
数据冗余	高	低
表达能力	描述形状	描述关系

👉 TopoJSON 不是"优化版 GeoJSON"，而是另一种思维方式

3. 原理讲解（深入但通俗）

3.1 GeoJSON：面向"形状"的描述

GeoJSON 的核心是：

👉 每个 Feature 独立描述自己的几何形状

json 复制代码

{
  "type": "Polygon",
  "coordinates": [
    [[0,0],[1,0],[1,1],[0,1],[0,0]]
  ]
}

问题在于：

👉 相邻区域：

边界会被重复存储 ❗
完全不知道彼此关系

3.2 TopoJSON：面向"关系"的描述

TopoJSON 的核心思想：

👉 把"边"抽出来共享

👉 举个直观例子：

两个相邻区域：

复制代码

A | B

GeoJSON：

👉 A 存一条边

👉 B 再存一条一模一样的边

👉 ❗ 完全重复

TopoJSON：

👉 这条边只存一次

👉 A / B 共享它

👉 ✔ 数据直接减半

3.3 Arc（弧段）机制（关键）

TopoJSON 的核心结构：

json 复制代码

{
  "arcs": [
    [[0,0],[1,0],[1,1]],
    [[1,1],[0,1],[0,0]]
  ]
}

👉 每个 Polygon：

不是直接存坐标
而是引用 arcs

👉 本质：

👉 从"存坐标" → "存引用"

3.4 为什么体积能大幅减少？

原因不止一个：

✔ 边界去重

👉 最大收益来源

✔ 坐标量化（Quantization）

TopoJSON 会：

降低精度
使用整数存储

👉 比 float 更紧凑

✔ 差分编码（Delta Encoding）

👉 坐标不存绝对值，而存"变化量"

👉 这三个叠加：

👉 50% ~ 80% 体积下降是常态

4. 常见错误或误区

❌ 误区1：TopoJSON 只是压缩格式

👉 错

✔ 它是：

👉 数据模型升级

❌ 误区2：任何场景都适合 TopoJSON

👉 错

TopoJSON 适用于：

面数据（Polygon）
存在共享边界的场景

不适合：

点数据（Point）
高频动态数据

❌ 误区3：TopoJSON 可以直接用来渲染

👉 不完全对

👉 前端通常需要：

👉 TopoJSON → GeoJSON 转换

5. 解决方案（如何正确使用）

5.1 数据生成（后端）

bash 复制代码

npm install -g topojson-server topojson-client
geo2topo input.json > output.topo.json

5.2 前端使用方式

js 复制代码

import { feature } from "topojson-client"

fetch("/data/topo.json")
  .then(res => res.json())
  .then(topo => {
    const geo = feature(topo, topo.objects.layer)
    render(geo)
  })

5.3 使用策略（非常关键）

👉 不要这样用：

复制代码

TopoJSON → 转 GeoJSON → 一次性加载 ❌

👉 正确方式：

TopoJSON + Tile 切片 ✔
按需加载 ✔

6. 工程实现（踩坑经验）

❗ 坑1：精度丢失

TopoJSON 默认会量化：

👉 精度降低

导致：

边界偏移
细节丢失

✔ 解决：

调整 quantization 参数

❗ 坑2：数据不可编辑

TopoJSON：

👉 不适合做"编辑数据源"

因为：

数据是压缩结构
不直观

✔ 建议：

👉 编辑用 GeoJSON，发布用 TopoJSON

❗ 坑3：转换成本

TopoJSON → GeoJSON：

👉 有 CPU 开销

大数据量时：

👉 需要考虑 Worker

7. 架构或设计思路

✔ 推荐数据流

复制代码

GeoJSON（源数据）
    ↓
TopoJSON（压缩存储）
    ↓
Tile 服务（切片）
    ↓
前端按需加载
    ↓
转换为 GeoJSON 渲染

❗ 核心思想

👉 不同阶段，用不同数据结构

阶段	格式
编辑	GeoJSON
存储	TopoJSON
传输	Tile / PBF
渲染	GeoJSON

👉 这才是工程级设计

8. 性能或优化建议

✔ 适合使用 TopoJSON 的场景

行政区划
地图边界
面状数据

❌ 不适合

实时轨迹
点位海量更新
高频交互数据

✔ 性能收益总结

👉 相比 GeoJSON：

体积 ↓ 50% ~ 80%
网络传输 ↓
内存占用 ↓

👉 但注意：

👉 它不是终极方案

9. 总结（认知提升）

一句话认知升级：

👉 GeoJSON 解决"怎么描述形状"

👉 TopoJSON 解决"怎么描述关系"

更深一层：

👉 性能优化的本质，不是压缩，而是数据建模

👉 当你开始思考：

👉 "数据之间的关系能不能复用？"

👉 说明你已经进入：

👉 数据结构设计层

10. 延伸思考

👉 留三个关键问题：

TopoJSON 为什么不适合实时数据？
Vector Tile 和 TopoJSON 的关系是什么？
是否可以设计"业务级拓扑结构"？

完结，撒花✿✿ヽ(°▽°)ノ✿