定义
TopoJSON 是一种以 JSON 为载体的拓扑地理空间数据交换格式，建立在 GeoJSON 之上[1]。它的根对象类型固定为「Topology」，必须包含 objects 与 arcs 两个成员，前者是若干具名几何对象的集合，后者是构成这些几何的全部弧段[4]。除此之外还可以带可选的 bbox 边界范围和 transform 变换参数[5]。
它与 GeoJSON 的关键差别在于组织坐标的方式：GeoJSON 把每个要素的完整坐标各自写一遍，TopoJSON 则把共享线段拆成被反复引用的公共单元[6]。几何类型仍然沿用 GeoJSON 的一套，包括点、多点、线、多线、多边形、多多边形与几何集合[1]。
原理
TopoJSON 的核心构件是「弧」(arc)，即一段由若干位置点构成的折线。相邻要素重叠的边界只被写成一条弧，各几何图形通过对弧的正向或反向引用来拼出自身轮廓，因此加利福尼亚与内华达之间的州界只在文件中出现一次，而不是两个州各存一份[2]。引用方向决定边界走向，方向相反即表示另一侧的要素[4]。这种做法与马特·布洛赫(Matt Bloch)的 MapShaper 以及 Arc/Info 的 .e00 交换格式思路相近。
为进一步压缩体积，TopoJSON 可以对坐标做量化。量化把浮点坐标映射到整数格点上，通常取 10⁴、10⁵ 或 10⁶ 这样的量级作为量化参数，参数越大保留的精度越高、文件也越大[7]。量化后 arcs 中的点采用增量编码，即每个点只记录相对前一个点的偏移量，首点则以原点为参照；需要还原坐标时，先乘以 scale 再相加 translate，变换公式为 $x = x_c \times scale_x + translate_x$，$y = y_c \times scale_y + translate_y$[1]。编码流程可概括为：
$GeoJSON \rightarrow 抽取共享弧 \rightarrow 量化取整 \rightarrow 增量编码 \rightarrow TopoJSON$[4]
读取端按相反的顺序解码，把弧还原成坐标序列，再依据各几何记录的弧索引拼接为完整轮廓，并转换回 GeoJSON 供渲染工具使用[8]。引用同一弧的相邻要素在解码后保证边界完全贴合，不会出现缝隙或重叠[3]。
发展历程
TopoJSON 的早期实现始于 2012 年末，最初的 JavaScript 工具库由迈克·博斯托克发布，2013 年 1 月的版本已经支持点与多点几何，并陆续加入简化相关的功能。格式规范由博斯托克与卡尔文·梅特卡夫(Calvin Metcalf)共同编写，规范文档在 2013 年 9 月前后集中修订，确定了量化弧与 transform 成员的定义。
2017 年前后，工具链经历了一次较大的重组：原先单一的实现被拆分为分别负责生成、简化与客户端操作的多个模块，转换、简化与还原等功能由此分属不同组件[9]。此后 TopoJSON 也被多种语言重新实现，包括 Go 语言版本等，用于在服务端完成 GeoJSON 与 TopoJSON 之间的双向转换[10]。在标准化方面，开放地理空间信息联盟在试验项目中对 TopoJSON 作为网络要素服务的输出格式进行了测试[5]。
应用
网页地图与数据可视化是 TopoJSON 最主要的应用场合。数据可视化库 D3.js 可直接加载 TopoJSON 拓扑并以画布或矢量方式绘制国家、州、县等边界，共享控制点只需投影一次，渲染效率高于逐个要素处理[2]。围绕这一生态还形成了预生成的数据集，例如由自然地球(Natural Earth)数据转换而来的世界地图集，其中包含国家与陆地两个几何集合，覆盖 1:1.1 亿与 1:5000 万两种比例尺。
由于保留的拓扑关系可以被程序读取，TopoJSON 支持一些单纯几何文件难以实现的操作。抽取网格后可以只描边共享边界，做拓扑保持的简化时相邻要素在简化后仍然相连，跨要素集合的简化也能保持一致[2]。基于邻接关系还可以实现地图自动着色、邻接要素查询，以及多林(Dorling)图与六边形统计地图等制图形式[6]。
在地理信息系统的服务端，TopoJSON 可作为网络要素服务的一种输出格式使用，客户端在请求中指定输出格式即可获得拓扑编码的要素数据，不需要单独维护一套拓扑库[5]。除网页前端外，商业智能工具与政府、城市的地理信息系统也用它存放行政区划、道路网络、建筑轮廓等规模较大的空间数据[3]。
局限
压缩收益伴随解析成本的上升。读取时必须先解码弧与变换参数、再重新拼装几何，解析耗时通常高于直接读取坐标已展开的 GeoJSON，在性能较弱的设备或强调实时交互的场景中可能带来延迟[3]。量化本身也是有损的：坐标取整会引入误差，误差上限是浮点输入坐标与其定点量化结果之间的最大差值，量化参数设得越小，几何变形越明显[11]。
拓扑编码并非对所有数据都划算。点、轨迹等本身不共享边界的要素无法从弧复用中获益，反而多出索引与变换的结构开销；实时更新的动态数据也难以利用这一机制[3]。此外，arcs 的索引与 transform 参数不宜人工阅读和修改，拓扑错误或量化参数设置有误时容易出现几何变形，且通常需要借助专门的工具排查[3]。
工具支持的广度是另一个限制。格式出现较晚，早期支持它的软件与库相对有限，在部分地理信息平台中使用时需要自行开发扩展或转换插件，可处理的几何类型也受到实现范围的制约[12]。
参见
参考资料
- The TopoJSON Format Specification [引用日期2026-10-14]
- TopoJSON [引用日期2026-10-14]
- TopoJSON（拓扑结构优化的JSON地理数据格式）-GIS百科-GISBox [引用日期2026-10-14]
- README [引用日期2026-10-14]
- ogc.org 上的 PDF 文件 [引用日期2026-10-14]
- topo [引用日期2026-10-14]
- TopoJSON Server [引用日期2026-10-14]
- JSPM – topojson-client@2.1.0 [引用日期2026-10-14]
- 'topojson' tag wiki [引用日期2026-10-14]
- topojson [引用日期2026-10-14]
- "prop0": "value0", [引用日期2026-10-14]
- 5_GeoJSON_y_TopoJSON(PDF) [引用日期2026-10-14]