1. 从一次数据格式转换实践说起
上周在处理一批乡镇行政区划数据时，我遇到了一个典型问题：合作方提供的KML文件无法直接导入我们的地理信息系统，而系统只支持GeoJSON格式。这促使我深入研究了这两种主流地理数据格式的本质差异，并手动实现了它们之间的转换。这次经历让我意识到，很多开发者对这两种格式的理解往往停留在表面，而真正掌握它们的底层逻辑对处理空间数据至关重要。
2. GeoJSON与KML的技术基因解析
2.1 GeoJSON的JSON血统
GeoJSON本质上是一种基于JSON的地理数据交换格式。它继承了JSON的所有特性：
- 轻量级的文本结构
- 良好的可读性
- 与Web技术的天然亲和性
一个典型的GeoJSON对象结构如下：
{ "type": "Feature", "geometry": { "type": "Point", "coordinates": [116.4, 39.9] }, "properties": { "name": "Beijing" } }这种结构使得GeoJSON特别适合：
- 现代Web应用开发
- RESTful API设计
- 前后端数据交互
2.2 KML的XML渊源
KML(Keyhole Markup Language)则是基于XML的地理数据格式，最初由Keyhole公司开发（后被Google收购）。它的典型结构如下：
<kml xmlns="http://www.opengis.net/kml/2.2"> <Placemark> <name>Beijing</name> <Point> <coordinates>116.4,39.9</coordinates> </Point> </Placemark> </kml>KML的优势在于：
- 强大的可视化能力（支持样式、图标等）
- 与Google Earth的深度集成
- 复杂地物描述的灵活性
3. 核心差异的深度对比
3.1 数据结构差异
| 特性 | GeoJSON | KML |
|---|---|---|
| 基础格式 | JSON | XML |
| 坐标表示 | [经度, 纬度] | 经度,纬度[,高度] |
| 属性存储 | properties对象 | 扩展元素/自定义Schema |
| 几何类型 | 简单几何体 | 支持更多复杂类型（如模型） |
3.2 坐标系处理
GeoJSON默认使用WGS84坐标系（EPSG:4326），而KML虽然也主要使用WGS84，但在高度处理上有所不同：
- GeoJSON中高度是可选的
- KML中高度默认以米为单位，0表示海平面
3.3 扩展能力比较
GeoJSON通过properties对象实现属性扩展，而KML则提供了更丰富的原生扩展机制：
- 样式定义（StyleMap）
- 时间动画（TimeSpan）
- 屏幕叠加（ScreenOverlay）
- 3D模型支持（Model）
4. 手动转换实践详解
4.1 转换核心逻辑
转换过程的核心是几何对象和属性的映射：
- 解析KML文档结构
- 提取几何信息（点、线、面等）
- 转换坐标系（如有必要）
- 处理属性数据
- 构建GeoJSON对象树
4.2 关键代码实现
以下是Python实现的转换核心：
def kml_to_geojson(kml_str): # 解析KML root = ET.fromstring(kml_str) # 创建GeoJSON结构 geojson = { "type": "FeatureCollection", "features": [] } # 处理每个Placemark for pm in root.findall('.//{http://www.opengis.net/kml/2.2}Placemark'): feature = { "type": "Feature", "geometry": None, "properties": {} } # 处理几何体 geom = parse_geometry(pm) if geom: feature['geometry'] = geom # 处理属性 for elem in pm: if elem.tag.endswith('name'): feature['properties']['name'] = elem.text # 其他属性处理... geojson['features'].append(feature) return geojson4.3 特殊场景处理
4.3.1 多几何体处理
KML允许一个Placemark包含多个几何体，而GeoJSON要求每个Feature只有一个几何体。解决方案：
- 拆分为多个Feature
- 使用GeometryCollection类型
4.3.2 样式信息转换
KML的样式系统非常丰富，转换时需要做取舍：
- 简单颜色可以直接转换
- 复杂样式可能需要简化为GeoJSON支持的简单样式
5. 转换过程中的坑与解决方案
5.1 坐标顺序问题
最常见的陷阱是坐标顺序：
- GeoJSON要求[经度, 纬度]
- 某些KML文件可能使用[纬度, 经度]
解决方案：
def correct_coordinate_order(coords): if len(coords) >= 2: return [coords[1], coords[0]] + coords[2:] return coords5.2 高度值处理
高度值的单位转换经常被忽视：
- KML高度默认以米为单位
- 某些系统可能期望以千米或其他单位
5.3 属性类型转换
KML中的属性都是字符串，而GeoJSON支持多种类型：
- 需要智能类型推断
- 特殊处理日期时间格式
6. 性能优化实践
处理大型地理数据集时，性能成为关键考量：
6.1 流式处理
对于超大型KML文件：
- 使用SAX解析器替代DOM
- 分批写入GeoJSON
6.2 内存管理
- 及时释放不再需要的DOM节点
- 使用生成器减少内存占用
6.3 并行处理
将文件分区后并行转换：
from multiprocessing import Pool def parallel_convert(kml_chunks): with Pool() as p: results = p.map(kml_to_geojson, kml_chunks) return merge_geojson(results)7. 工具链选择建议
7.1 现成工具比较
| 工具 | 优点 | 缺点 |
|---|---|---|
| ogr2ogr | 功能全面，支持多种格式 | 学习曲线较陡 |
| togeojson | 简单易用 | 功能有限 |
| 自定义脚本 | 灵活可控 | 开发成本高 |
7.2 何时需要手动实现
以下情况建议自定义实现：
- 需要特殊业务逻辑处理
- 现有工具性能不足
- 有独特的格式扩展需求
8. 实际应用场景分析
8.1 Web地图开发
GeoJSON更适合：
- 直接用于Leaflet/OpenLayers
- 与前端框架无缝集成
8.2 桌面GIS应用
KML在以下场景更优：
- Google Earth集成
- 复杂可视化需求
8.3 数据存储
长期存储建议：
- 原始数据存档用KML（保留完整信息）
- 应用数据使用GeoJSON（更高效）
9. 扩展思考：格式选择的哲学
经过这次转换实践，我总结出几点选择原则：
受众决定格式：如果主要用户是GIS专业人员，KML可能更合适；如果是Web开发者，GeoJSON更友好
工具链考量：评估团队熟悉的工具和技术栈
未来扩展性：考虑数据使用的长期场景
性能需求：大数据量场景下，GeoJSON通常更高效
手动实现转换的最大价值不在于结果，而在于过程中对两种格式本质理解的深化。这让我在后续处理地理数据时，能够更准确地预测可能遇到的问题，并做出更合理的技术选型。