I previously gave a brief introduction to TopoJSON in GIS Tutorial: What Is TopoJSON. At that time, I left a loose end: I only said that it is much smaller than GeoJSON, but did not explain clearly why it is so much smaller. Recently, some people in the Mala GIS group asked a similar question, so I took a real dataset and ran a test, and also expanded on the underlying mechanisms. Those who need it can refer to this.
Real-World Test
I ran a real-world test on my local machine using the official toolchain. The data source was the China provincial boundary GeoJSON from Alibaba Cloud DataV.GeoAtlas (100000_full.json). The conversion used the official TopoJSON CLI (geo2topo + topoquantize), with the default quantization grid of 1e4. The results are as follows:
As can be seen, after deduplicating shared arcs, 583 KB dropped to 396 KB, about 32% smaller. If quantization is added (default 1e4), it further dropped to 143 KB, a cumulative reduction of about 75%. Finally, when gzip is used during data transmission, the 143 KB TopoJSON is only 39 KB, while the original GeoJSON still requires 201 KB.
Why is it so much smaller? This is mainly related to TopoJSON's three major mechanisms: shared arcs (boundary deduplication), delta encoding (coordinates only record changes), and quantization.
Mechanism 1: Shared Arcs
In GeoJSON, every polygon is an "independent kingdom." The shared boundary between two adjacent provinces appears completely in the coordinate arrays of both polygons, with opposite directions. China's 34 provincial-level administrative regions border one another, so this "duplicated work" is very substantial.
TopoJSON's approach is to split all boundary lines into arcs, store them in a global arcs array, and store each arc only once. Polygons no longer write coordinates; they only write references to arc indices, and a negative sign indicates the reverse direction. The longer the adjacent boundaries and the more adjacent features there are, the more is saved. This is also why data with dense adjacency, such as China's provincial boundaries, is especially suitable for TopoJSON.
Mechanism 2: Delta Encoding
Deduplication alone is not enough. When encoding coordinates, TopoJSON has another trick: it does not store the full longitude and latitude for every point. Instead, the first point stores the original value, and subsequent points only store the difference relative to the previous point.
On its own, this step does not save many bytes, but it has two implications: first, it turns large numbers into small numbers; second, after quantization turns floating-point numbers into integers, the same content can be compressed further. Therefore, delta encoding is actually the foundation for the later quantization and compression mechanisms.
Mechanism 3: Quantization
Coordinates can be infinitely precise, but many scenarios do not need that at all. By default, TopoJSON maps coordinates onto a 1e4 x 1e4 integer grid, turning longitude and latitude into integers between 0 and 10000. Together with scale and translate in transform, approximate coordinates can be restored.
However, this step comes at the cost of precision loss. Under the quantization grid used in this test, the coordinate precision is about 0.006 degrees (roughly 0.5 to 0.7 km), which is imperceptible on small-scale maps. If high-precision analysis is required, the grid can be increased (for example, 1e5 or 1e6), but the file size will increase accordingly.
Summary
To summarize the three mechanisms that make TopoJSON smaller: shared arcs remove duplicated boundaries, delta encoding makes numbers smaller, and quantization reduces precision. Stacked together, they produce the 75% to 81% size reduction seen in the test. For front-end maps, this means faster loading and lower bandwidth usage, especially for boundary-dense data such as provincial and municipal data, where the benefits are very obvious.
By the way, using a topological structure in TopoJSON also has a hidden benefit: because adjacent features share the same arc, simplification will not create gaps or overlaps. This is also why many map libraries like to use TopoJSON. Finally, if you also want to use this format, you can refer to several methods I wrote earlier for converting GeoJSON to TopoJSON, see GIS Tutorial: Methods to Convert GeoJSON to TopoJSON. Those who need it can try it.
References
- TopoJSON official documentation: https://github.com/topojson/topojson
- Alibaba Cloud DataV.GeoAtlas China provincial data source: https://geo.datav.aliyun.com/areas_v3/bound/100000_full.json
- TopoJSON: A smaller GeoJSON with some neat tricks (Mike Bostock talk): https://www.somebits.com/~nelson/SotM-2013-TopoJSON.pdf
- TopoJSON vs GeoJSON comparison: https://geodata.tools/blog/topojson-vs-geojson/