GIS开发必知：WKT、WKB与GeoJSON格式详解

1. 地理空间数据格式概述

地理空间数据格式是GIS（地理信息系统）和地图应用开发中的基础元素。作为一名长期从事地理信息开发的工程师，我深刻理解选择合适的数据格式对项目效率的影响。WKT、WKB和GeoJSON这三种格式各有特点，适用于不同场景。

在实际项目中，我们经常需要处理这样的场景：从PostGIS数据库读取空间数据，通过API传输给前端地图应用展示。这个过程中就可能涉及WKB→WKT→GeoJSON的多次转换。理解它们的特性和转换方法，可以避免很多性能问题和数据错误。

2. WKT格式深度解析

2.1 WKT的核心语法规则

WKT(Well-Known Text)的语法设计遵循几个基本原则：

1. 几何类型使用全大写（如POINT、LINESTRING）
2. 坐标对使用空格分隔，不使用逗号
3. 多部分几何使用逗号分隔各部分
4. 坐标顺序通常是(经度 纬度)，但具体取决于SRID定义

一个常见的误区是坐标顺序。虽然WKT规范没有强制规定顺序，但实际应用中：

• 地理坐标系（如EPSG:4326）通常使用(纬度 经度)
• 投影坐标系通常使用(东向 北向)

2.2 复杂几何类型的WKT表示

2.2.1 带孔多边形

带孔多边形的WKT表示需要特别注意环的方向：

wkt复制POLYGON(
  (116.0 39.5, 117.0 39.5, 117.0 40.5, 116.0 40.5, 116.0 39.5),  -- 外环逆时针
  (116.3 39.8, 116.3 40.2, 116.7 40.2, 116.7 39.8, 116.3 39.8)   -- 内环顺时针
)

外环必须使用逆时针方向，内环（孔洞）必须使用顺时针方向，这是OGC规范的要求。如果方向错误，某些GIS软件可能无法正确解析。

2.2.2 三维几何体

三维几何体支持Z坐标（高度）和M值（测量值）：

wkt复制POINT Z (116.4074 39.9042 50.0)        -- 带高度的点
POINT M (116.4074 39.9042 100.0)       -- 带测量值的点
POINT ZM (116.4074 39.9042 50.0 100.0) -- 同时带高度和测量值

2.3 WKT的实用技巧

2.3.1 性能优化

虽然WKT可读性好，但在处理大量数据时性能较差。一些优化建议：

1. 减少不必要的空格和换行
2. 对于重复使用的几何，考虑缓存解析结果
3. 在数据库查询中直接使用WKB格式

2.3.2 常见问题排查

3. WKB格式详解

3.1 WKB的二进制结构

WKB采用紧凑的二进制格式，其结构可以分解为：

1. 字节序标记（1字节）：0x00表示大端，0x01表示小端
2. 几何类型（4字节）：整数类型代码
3. 坐标数据：根据几何类型变化

以LINESTRING为例的详细结构：

code复制[字节序][类型][点数][坐标1][坐标2]...
01       02000000 02000000 [x1][y1][x2][y2]

3.2 EWKB扩展格式

PostGIS使用的EWKB在标准WKB基础上增加了SRID支持：

code复制[字节序][类型][SRID][坐标数据]
01       01000020 E6100000 [x][y]

其中：

• 类型码的最高位字节0x20表示包含SRID
• E6100000表示SRID=4326（小端序）

3.3 WKB处理实践

3.3.1 Python处理示例

python复制from shapely import wkb
import binascii

# 十六进制WKB转换为几何对象
wkb_hex = '0101000000000000000000F03F0000000000000040'
geom = wkb.loads(binascii.unhexlify(wkb_hex))
print(geom.wkt)  # 输出: POINT (1 2)

# 几何对象转WKB
point = Point(116.4, 39.9)
wkb_bytes = wkb.dumps(point)
print(binascii.hexlify(wkb_bytes).decode())

3.3.2 数据库中的WKB操作

PostgreSQL示例：

sql复制-- 插入WKB数据
INSERT INTO spatial_table (geom) 
VALUES (ST_GeomFromEWKB(E'\\x0101000020E61000009A99999999993B400000000000805040'));

-- 导出WKB
SELECT ST_AsBinary(geom) FROM spatial_table;

4. GeoJSON全面解析

4.1 GeoJSON规范要点

GeoJSON遵循IETF RFC 7946标准，有几个关键特性：

1. 必须使用WGS84坐标系（EPSG:4326）
2. 坐标顺序必须是[经度, 纬度]
3. 支持Feature和FeatureCollection两种主要结构

4.2 高级GeoJSON特性

4.2.1 几何集合

json复制{
  "type": "GeometryCollection",
  "geometries": [
    {
      "type": "Point",
      "coordinates": [116.4, 39.9]
    },
    {
      "type": "LineString",
      "coordinates": [[116.4,39.9],[117.2,39.1]]
    }
  ]
}

4.2.2 属性数据类型

GeoJSON的properties可以包含任意JSON数据类型：

json复制{
  "properties": {
    "name": "Beijing",
    "population": 21710000,
    "isCapital": true,
    "districts": ["Dongcheng", "Xicheng", "Chaoyang"],
    "geoInfo": {
      "elevation": 43.5,
      "timezone": "UTC+8"
    }
  }
}

4.3 GeoJSON性能优化

4.3.1 减少文件大小

1. 移除不必要的空格和换行
2. 使用数字ID代替长字符串属性
3. 考虑使用TopoJSON（基于GeoJSON的扩展格式）

4.3.2 流式处理大型文件

对于大型GeoJSON文件，可以使用流式解析：

javascript复制const JSONStream = require('JSONStream');
const fs = require('fs');

const stream = fs.createReadStream('large.geojson')
  .pipe(JSONStream.parse('features.*'));

stream.on('data', feature => {
  // 处理单个要素
});

5. 格式转换实战指南

5.1 转换方法对比

5.2 典型转换场景

5.2.1 数据库到Web应用

sql复制-- PostGIS查询返回GeoJSON
SELECT ST_AsGeoJSON(geom) FROM cities WHERE population > 1000000;

5.2.2 前端到后端传输

javascript复制// 前端提交GeoJSON
fetch('/api/save-feature', {
  method: 'POST',
  body: JSON.stringify(geoJSONFeature),
  headers: {'Content-Type': 'application/json'}
});

// 后端转换为WKB存储
app.post('/api/save-feature', (req, res) => {
  const wkb = wkx.Geometry.parseGeoJSON(req.body).toWkb();
  // 存储到数据库...
});

5.3 转换性能测试

我们对10000个点要素进行了格式转换测试（单位：ms）：

结论：数据库内置函数通常性能最优，对于批量处理推荐使用PostGIS或专用ETL工具。

6. 格式选型决策树

6.1 详细决策流程

1. 数据来源：

   • 来自数据库 → 优先考虑WKB
   • 来自GPS设备 → 通常为GeoJSON
   • 人工编辑 → 考虑WKT

2. 处理阶段：

   • 存储阶段 → WKB
   • 处理分析 → WKT（调试）或WKB（批量）
   • 可视化 → GeoJSON

3. 系统环境：

   • 纯后端系统 → WKB/WKT
   • Web应用 → GeoJSON
   • 移动应用 → 考虑Protocol Buffers等压缩格式

6.2 行业应用案例

6.2.1 智慧城市管理系统

• 数据存储：WKB（PostGIS）
• 内部处理：WKT（SQL调试）
• 对外API：GeoJSON
• 大数据分析：Parquet+WKB

6.2.2 实时交通监控平台

• 设备接入：Protocol Buffers
• 实时处理：内存中的WKB格式
• 可视化：GeoJSON over WebSocket
• 持久化存储：WKB列式存储

7. 性能优化专项

7.1 内存优化技巧

1. 对象复用：

   java复制// Java示例：重用GeometryFactory
   GeometryFactory factory = new GeometryFactory();
   Point p1 = factory.createPoint(new Coordinate(116.4, 39.9));
   Point p2 = factory.createPoint(new Coordinate(121.4, 31.2));
   

2. 坐标序列优化：

   python复制# 使用numpy数组存储批量坐标
   coords = np.array([[116.4,39.9],[121.4,31.2]], dtype=np.float32)
   

7.2 存储优化方案

1. 数据库存储：

   • PostGIS：使用GEOMETRY类型而非GEOGRAPHY
   • MySQL：合理设置SRID减少计算开销

2. 文件存储：

   • 大量静态数据：考虑SpatiaLite或FlatGeobuf
   • 时序数据：GeoParquet格式

7.3 网络传输优化

1. 压缩策略：

   • 启用HTTP压缩（gzip/brotli）
   • 对于GeoJSON，考虑使用JSON简写：

     json复制{"t":"Feature","g":{"t":"Point","c":[116.4,39.9]},"p":{"n":"Beijing"}}
     

2. 分片加载：

   javascript复制// 地图可视化的分片加载
   map.on('moveend', () => {
     const bbox = map.getBounds();
     fetch(`/api/features?bbox=${bbox.toArray()}`);
   });
   

8. 常见问题解决方案

8.1 坐标系统问题

问题：WKT显示的位置与GeoJSON不同
原因：坐标顺序或SRID不匹配
解决方案：

1. 确认WKT的坐标顺序与SRID定义一致
2. 转换时明确指定SRID：

   sql复制SELECT ST_AsText(ST_Transform(geom, 4326)) FROM table;
   

8.2 性能瓶颈

问题：GeoJSON解析速度慢
优化方案：

1. 使用增量解析：

   javascript复制const parser = new JSONStream.parse('features.*');
   fs.createReadStream('large.geojson').pipe(parser);
   

2. 考虑使用二进制格式如FlatGeobuf

8.3 数据精度问题

问题：坐标精度丢失
解决方法：

1. WKT中保留足够小数位：

   wkt复制POINT(116.407526 39.904030)  -- 保留6位小数
   

2. GeoJSON中使用数字原样而非科学计数法

9. 工具链推荐

9.1 开发工具

1. 验证工具：

   • GeoJSONLint (在线验证)
   • WKT Validator (QGIS插件)

2. 转换工具：

   • GDAL ogr2ogr (命令行)
   • PostGIS ST_函数 (数据库)

9.2 性能分析工具

1. 数据库：

   sql复制EXPLAIN ANALYZE SELECT ST_AsGeoJSON(geom) FROM large_table;
   

2. JavaScript：

   javascript复制console.time('geojson-parse');
   JSON.parse(largeGeoJSON);
   console.timeEnd('geojson-parse');
   

9.3 可视化调试

1. QGIS：支持直接粘贴WKT/GeoJSON
2. GeoJSON.io：在线编辑和查看
3. DBeaver：数据库WKB可视化

10. 进阶话题

10.1 自定义扩展格式

可以基于WKB设计高效的自定义格式：

python复制# 自定义头部结构
header = struct.pack('!BII', version, srid, num_points)
# 坐标数据
coords = np.array([...], dtype=np.float32).tobytes()

10.2 空间索引与格式选择

不同格式对空间索引的影响：

1. WKB最适合R-Tree索引
2. GeoJSON需要先解析才能建立索引
3. 考虑使用H3或S2等空间编码

10.3 未来趋势观察

1. GeoArrow：基于Arrow的高效空间数据交换
2. FlatGeobuf：适合流式处理的二进制格式
3. WebAssembly：在浏览器中直接处理WKB

在实际项目中选择数据格式时，我通常会考虑整个数据处理流水线的需求。比如最近一个城市交通分析项目中，我们使用PostGIS存储WKB格式数据，处理时转换为WKT便于调试，最终API输出GeoJSON给前端。这种组合兼顾了存储效率、处理便利性和可视化需求。