简介KML/KMZ是谷歌地球常用的地理标记格式Shapefile则是ArcGIS中应用最广泛的矢量数据格式。面向需要在这两种格式间迁移数据的GIS技术人员该压缩包专门解决ArcGIS内置转换工具将KML/KMZ转为Shapefile后属性字段丢失的痛点。包内共2个文件其中基于GDAL/OGR的Python脚本可读取KML/KMZ中的点、线、面几何信息并同步保留原有属性字段最终输出包含.shp、.dbf等配套文件的完整Shapefile数据集另一个SWF格式的演示动画则逐步展示脚本调用方式与参数设置即使不熟悉命令行也能快速上手。整个压缩包约3MB轻量便捷已有2259人学习下载。对于需要开展地物符号化、GIS制图、数据入库及跨平台交换的测绘与GIS分析人员该工具既提供了可直接运行的转换脚本也给出了保留属性的操作思路能显著减少重复处理和字段重建成本。1. KML 转 SHP 没有想象中简单属性保留与坐标系是两座绕不开的坎谷歌地球导出的 KML/KMZ 格式拿给 ArcGIS 使用时大多数人第一反应是“转成 shapefile 不就完了”。但真正动手你会发现这一步的坑比想象中深属性字段静默丢失、中文乱码、坐标系偏出几百米、一个 Placemark 里的多个几何被合并成一条记录——每一条都足以让交付的成果被退回去。我经手的外业巡检项目里一线人员习惯用 Google 地球标注井盖、路牌和管线点标注点里带着编号、类型、照片链接这些现场信息这些信息全埋在 KML 的 ExtendedData 标签里。能不能把它们完好转进 ArcGIS 的 shapefile直接决定了内业能不能少加两天班。这篇笔记把三条主流转换路线——ArcGIS 内置工具、GDAL 命令行、Python 脚本——完整走一遍参数、边界和返工现场都摊开适合被外业数据反复“轰炸”的测绘、规划、自然资源行业的 GIS 从业者。2. 先说透格式差异KML 是 XML、SHP 是二进制属性规则完全不同转换做得稳不稳前提是先看清两边数据结构。KML 和 Shapefile 不是“同一种地图数据的不同后缀”它们在几何存储、属性承载、编码规则上是两套完全不同的体系。直接拿工具转你只是在赌工具默认行为的运气。2.1 KML 内部结构Placemark、ExtendedData 与坐标嵌套方式KML 本质是 XML 文档谷歌地球导出的.kml是纯文本.kmz是把 KML 和配套图片资源用 ZIP 算法打包后的压缩包。一个最常见的点要素长这样?xml version1.0 encodingUTF-8? kml xmlnshttp://www.opengis.net/kml/2.2 Document name外业标注/name Placemark name井盖_001/name ExtendedData Data name编号valueGX-2024-001/value/Data Data name类型value雨水/value/Data Data name管径valueDN300/value/Data /ExtendedData Point coordinates116.391,39.907,0/coordinates /Point /Placemark /Document /kml这个片段里的关键信息点有三处Placemark是唯一要素容器一个 Placemark 对应一个或多个几何ExtendedData里的Data标签是属性真正存放的位置coordinates的格式是“经度,纬度,高度”多个坐标点之间用空格分隔。很多转换工具默认只读name和description字段把 ExtendedData 里的内容忽略掉这就是属性丢失的根源之一。还有一点容易被忽略谷歌地球导出时如果用户是用“添加地标”按钮手动建的标注属性会写进description或ExtendedData如果用户是通过导入表格生成的标注KML 里通常会出现Schema标签来声明字段结构。前者转换工具大概率读不全后者 ArcGIS 反而识别得比较完整。实际接数据时我一般先打开 KML 文件搜索一下有没有Schema再决定后续用哪条转换路径。线、面要素的结构比点复杂一圈。多边形的坐标嵌套在Polygon的outerBoundaryIs里一条线所有顶点全放在一个LineString坐标串里。同一个 Placemark 里塞多个点或多个多边形的情况也很常见。这些结构上的差异直接决定了转换后要素数量和几何类型的表现。2.2 Shapefile 的属性承载边界DBF 字段名 10 字符限制与编码问题Shapefile 不是单文件而是.shp几何、.shx索引、.dbf属性三件套。几何和属性分开存储这条约束直接带来了转换中的最大矛盾.dbf的字段名最长只能 10 个字符而且历史上默认编码是 ANSI/GBK不是 KML 常用的 UTF-8。这意味着什么你 KML 里一个字段叫“备注信息_外业”转换到 dbf 里直接被截断成“备注信息_外”如果两个长字段前 10 个字符一样后一个字段会被改名或者直接覆盖。中文属性值本身能存但编码不一致时读出来就是乱码。ArcGIS 10.2 之后的版本能读 UTF-8 编码的 dbf但前提是写入时指定了编码很多命令行工具默认按系统区域写编码Windows 中文系统写出来就变成 GBK再被 QGIS 或 ArcGIS 按 UTF-8 读必然出乱码。所以转换前就得想清楚一件事KML 里的长字段名在 SHP 里是保不住的不是工具不够好是 dbf 格式的硬边界就在那里。我通常的做法是转换前就把字段重命名为 10 字符以内的逻辑名转换完再在 ArcGIS 里改回显示别名别等到转换完再处理一堆重复截断字段。2.3 三条转换路线怎么选ArcGIS 内置、QGIS 导入、GDAL 命令行先给结论单文件、不着急、要看得见摸得着用 ArcGIS 内置工具要快速核数或者手里没有 ArcGIS 授权用 QGIS 直接加载批量转换、要进自动化流程、对属性完整性有硬要求走 GDAL 命令行。三条路线在属性保真度上表现差别很大转换路线典型工具属性保真度主要风险ArcGIS 内置工具箱 KML to Layer中等识别 Data 标签但依赖 Schema字段截断、编码乱码、批量能力弱QGIS 导入通过 GDAL 驱动加载 KML中等可视化核对方便ExtendedData 字段顺序不稳定GDAL 命令行ogr2ogr高可显式控制编码和字段MultiGeometry 需要额外处理选型的关键不是“哪个工具最强”而是“你在什么阶段”。我见过不少同事直接用 ArcGIS 的 KML to Layer 转完属性只有 Name 和 Description当场就懵了。后来让他们在转换前先看一眼 KML 里有没有Schema哪个工具能做到可控就用哪条路。3. 走通 ArcGIS 桌面端KML to Layer 与导出 SHP 的完整路径ArcGIS 桌面端是最多人上手的路线因为它全图形化不需要记命令。但 KML to Layer 这个工具不是“一键导入”它做的是把 KML 转成一个中间图层之后还得再导出成 SHP。这两步拆开做每一步的参数都会影响最终结果。3.1 KML to Layer 工具的关键参数与操作路径打开 ArcToolbox找到 Conversion Tools → From KML → KML To Layer。输入 KML/KMZ 文件后需要设置输出工作空间和输出要素类名称。界面里还有一个容易被忽略的参数要素类型Feature Type默认为“全部”。输入C:\data\survey.kmz 输出要素类C:\data\output\survey_layer 要素类型Point根据数据实际类型选 包含地面叠加层默认勾选通常取消这个工具转换出来的不是 final 成果而是一个要素图层内部会生成点、线、面三个要素类分别放在输出工作空间里。如果数据里点线面混在一起选“全部”是最安全的代价是点、线、面各生成一份独立要素类后续需要在 ArcMap 里筛选。参数上的一个实际经验把“Include Ground Overlays”取消勾选。这个选项会把 Google 地球里的影像叠加层一起转成网格数据对普通点线面要素来说是纯负担转换时间翻倍还容易因为影像路径失效报错。3.2 从要素类导出 SHP右键导出与批量工具图层转换完成后在 ArcMap 内容列表里右键这个图层选择“数据 → 导出数据”把导出格式改成 Shapefile指定保存路径和名称。这一步看似简单但有两个隐藏问题。第一个是编码。导出 SHP 时 ArcMap 默认按当前系统的代码页写 dbf。中文 Windows 环境写出来是 GBK之后如果你把 SHP 拿到 QGIS 或者 Python 里处理按 UTF-8 读取必乱码。如果有选择余地优先用“转换工具 → 要素类转 Shapefile”这个工具它支持批量输入多个要素类且导出时不做任何几何简化。第二个是坐标系。KML 里的坐标一定是 WGS84 经纬度也就是 EPSG:4326。如果你的工程坐标系是高斯投影或者 CGCS2000 分带直接导出 SHP 后坐标值仍然是经纬度但数据框是投影坐标系看起来会飘到错误位置。正确做法是在 ArcToolbox 里跑“数据管理工具 → 投影和变换 → 要素 → 投影”把坐标真正转成目标投影而不是只靠动态投影看着对。3.3 KMZ 批量解压与预处理先拆包再转换在实际项目中外业交过来的往往不是一个 KMZ而是按日期、按巡查片区拆成几十个压缩包。ArcGIS 的 KML to Layer 工具支持直接输入 KMZ但批量处理时每个文件都要在界面上选一次非常低效。更稳妥的做法是先用脚本把 KMZ 解压成 KML再统一转。Windows 10 及以上系统自带 tar 命令解压 KMZ 不需要额外装软件。把下面这段保存为unzip_kmz.bat放在 KMZ 文件所在的目录下运行echo off for %%f in (*.kmz) do ( echo 正在解压 %%f mkdir %%~nf 2nul tar -xf %%f -C %%~nf ) echo 解压完成 pause这段批处理的逻辑很直接遍历当前目录所有.kmz文件以文件名去掉扩展名为目录名建立文件夹然后用 tar 把 KMZ 解压进去。这里%%f是批处理循环变量必须写成双百分号写成单百分号会在运行时直接报错。解压后每个文件夹里会有一个或多个.kml文件用 KML to Layer 逐个转换即可。需要提醒的是如果 KMZ 里包含大量照片解压过程会生成大量小文件在机械硬盘上可能要等几分钟。解压完先检查 KML 文件大小空的 KML 基本可以跳过别浪费时间转换。4. 编程路线ogr2ogr 命令行与 Python 脚本属性一条不丢当 KMZ 数量超过十个或者项目要求每次转完必须保证属性字段齐全时纯手点 ArcMap 就不够了。GDAL 里的ogr2ogr是处理这种格式转换最成熟命令它的 KML 驱动能读取 ExtendedData 属性且写入 dbf 时可以通过参数指定编码整个过程可控、可批量、可复现。4.1 ogr2ogr 一条命令KML 转 SHP 并保留 ExtendedData安装好 GDAL 后最简单的一条转换命令长这样ogr2ogr -f ESRI Shapefile \ -lco ENCODINGUTF-8 \ -nlt PROMOTE_TO_MULTI \ C:\output\survey.shp C:\input\survey.kml逐项解释参数-f ESRI Shapefile指定输出格式-lco ENCODINGUTF-8让写入的 dbf 文件使用 UTF-8 编码ArcGIS 10.2 之后能正常读出中文-nlt PROMOTE_TO_MULTI自动把单个点提升为多点、单个面提升为多面。这个命令最核心的价值是编码和几何类型都拿到了确定性控制。不加-lco ENCODING时在 Windows 中文环境里 dbf 会写成 GBK拿到 QGIS 里看属性表全乱码不加-nlt时遇到一个 Placemark 里包含多个几何写 SHP 时容易报错或只写出最后一个。如果目标坐标已经确定不是 WGS84再加一个-t_srs EPSG:4547之类的参数转换后坐标直接落在目标投影上省掉后续 ArcMap 里再跑一次投影工具。4.2 Python 批量流水线遍历 KMZ、解压、转换命令行手动敲一次没问题批量几十个文件就得写 Python。把解压、定位 KML、转换三部曲串起来import os import zipfile import glob import subprocess kmz_dir rD:\data\kmz out_dir rD:\data\shp os.makedirs(out_dir, exist_okTrue) for kmz_path in glob.glob(os.path.join(kmz_dir, *.kmz)): base_name os.path.splitext(os.path.basename(kmz_path))[0] tmp_dir os.path.join(out_dir, base_name _tmp) os.makedirs(tmp_dir, exist_okTrue) with zipfile.ZipFile(kmz_path, r) as z: z.extractall(tmp_dir) kml_files glob.glob(os.path.join(tmp_dir, *.kml)) if not kml_files: print(f[跳过] {kmz_path} 内部没有 KML 文件) continue kml_file kml_files[0] shp_path os.path.join(out_dir, base_name .shp) subprocess.run([ ogr2ogr, -f, ESRI Shapefile, -lco, ENCODINGUTF-8, -nlt, PROMOTE_TO_MULTI, shp_path, kml_file ], checkTrue) print(f[完成] {base_name} - {shp_path})脚本逻辑分三段第一步用zipfile.extractall解压 KMZ 到同名临时目录第二步用glob查找该目录下的 KML 文件第三步调用ogr2ogr转换。需要注意subprocess.run的checkTrue如果转换失败会直接抛异常并终止脚本这样批量任务里某个文件失败时不会静默继续。实际跑数据时还有几个细节值得注意KMZ 解压后如果包含doc.kml和别的 KML 文件优先取根目录的doc.kml名字带下划线后缀的多是谷歌地球自动生成的备份容易误导。tmp_dir在转换完成后不会自动清理批量多了磁盘会膨胀最好在转换成功后再加一行shutil.rmtree(tmp_dir)。4.3 字段映射长字段名截断与补充属性的常见做法如果 KML 里的字段名比 dbf 的 10 字符上限长ogr2ogr转换时会自动截断但截断规则在不同 GDAL 版本里不完全一致。为了可控先用ogrinfo看一眼源文件的字段结构ogrinfo -so -al C:\input\survey.kml这条命令只打印图层信息不读取全部几何速度很快。输出里会列出每个字段的名称、类型和宽度比如String (32.0)之类。确认哪些字段超长后用-sql在转换时即时重命名ogr2ogr -f ESRI Shapefile \ -lco ENCODINGUTF-8 \ -nlt PROMOTE_TO_MULTI \ -sql SELECT name AS 名称, well_id AS 编号, pipe_type AS 类型 FROM kml \ C:\output\survey.shp C:\input\survey.kml这里 GDAL 会把 KML 图层当作名为kml的表SQL 里AS 新字段名负责重命名。中文列名在 dbf 里能用但如果你后面还要把 SHP 喂给其他程序建议直接用英文列名比如well_id、pipe_type最后在 ArcGIS 里用字段别名显示中文两边都不耽误。还有一种更少见的情况KML 的 ExtendedData 里存的不是纯文本而是带 CDATA 的 HTML 片段。这种情况ogr2ogr读出来字段值是完整 HTML拿去分析完全没意义。我的一般做法是用 Python XML 解析库先抓目标字段转成 CSV再通过公共 ID 字段连接回 SHP。这算脏数据兜底方案实际项目中遇到一次就够折腾半天的。5. 避坑排查KML 转 SHP 的五个高频翻车现场转换类工作最大的特点就是“一次能跑通不等于每次能跑通”。下面这五个问题是我在处理不同来源的 KML 数据时真实遇到并排掉过的每条按现象、原因、解决三步记录可以直接对照排查。5.1 属性字段全部丢失只剩 Name 和 Description现象用 ArcGIS 的 KML to Layer 转完属性表里只有 Name、Description 两个字段编号、类型、管径全没了。原因KML 文件里没有Schema标签ArcGIS 工具无法识别 ExtendedData 的属性结构把整个 ExtendedData 当作 HTML 文本塞进了 Description 字段。GDAL 某些编译版本没有启用 libkml 驱动时也会出现类似情况。解决先用文本编辑器搜索 KML 文件中是否有Schema没有的话改用 Python 脚本直接解析 ExtendedData 标签把属性导出成 CSV再通过 Placemark 的 name 或顺序 ID 连接到转换后的 SHP 上。已经确认过不少次这条路径能兜住绝大部分属性丢失场景。5.2 坐标整体偏移几百米点和线飘到路边现象转换后的点数据在 ArcMap 里显示位置明显偏离真实位置偏移量在几百米量级且全部朝同一方向。原因KML 的坐标本身是 WGS84 经纬度但转换时如果数据框或者 SHP 的投影信息被错误定义为其他坐标系ArcMap 会按错误的空间参考来画图。还有一种常见情况是外业设备导出的 KML 底层是 GCJ-02 偏移坐标系Google 地球里看着正常转到标准 WGS84 下就整体偏移。解决先在图层属性里查看 SHP 的坐标系确认是 WGS84/EPSG:4326 之后再谈投影转换。如果确认源数据是 GCJ-02必须先用坐标纠偏算法把经纬度转换回 WGS84这个步骤没有捷径常见做法是用一个并行偏移修正参数做批量处理。之后再跑“投影”工具转到目标坐标系别直接用“导出数据”里的复制那只换坐标系标签不换坐标值。5.3 中文属性变乱码属性表显示一串问号或乱码字符现象属性表打开中文全部变成“”或者看不出含义的乱码。原因dbf 文件写入时用的编码和读取时认为的编码不一致。最常见的组合是写入 UTF-8ArcGIS 按 GBK 读以及反过来写入 GBKQGIS 按 UTF-8 读。解决用ogr2ogr转换时显式加-lco ENCODINGUTF-8让 dbf 的内部编码标记和实际写入一致。已经转完的 SHP 如果乱码用 QGIS 加载该 dbf 时手动选择 UTF-8 编码能正常显示后另存为新 SHP这相当于做了一次编码修复。注意 ArcGIS 如果读不了 UTF-8 的 dbf大概率是版本太老升级到 10.2 及以上再试。5.4 一个 Placemark 里有多个几何转换后只出来一个现象KML 里一个地标包含几十个巡检点转换后 SHP 只显示一个点或者在 ArcMap 里提示“几何类型不受支持”。原因一个 Placemark 里的多个点被解析成 GeometryCollectionSHP 格式不支持这个几何类型ogr2ogr默认只保留最后一个ArcGIS 的 KML to Layer 会尝试拆开但规则是不可控的。解决命令行加-explodecollections参数GDAL 3.x 版本都支持它会把集合几何拆成单个要素ogr2ogr -f ESRI Shapefile \ -lco ENCODINGUTF-8 \ -nlt PROMOTE_TO_MULTI \ -explodecollections \ C:\output\survey.shp C:\input\survey.kml拆完要素数量会是原来的几十倍这时候注意去看属性表同一个 Placemark 的属性会被复制到每个拆分后的要素上ID 字段重复是正常现象不用慌。5.5 要素数量对不上KML 里几百个要素转完剩一半现象在 Google 地球里数一下有好几百个标注转换后 SHP 属性表里只有一百多条记录。原因KML 里的空几何 Placemark只有属性没有坐标会被转换工具直接丢弃部分嵌套在 Folder 里的 Placemark 因为文件夹层级问题被滤掉还有一种情况是几何里坐标串解析失败导致整条要素跳过。解决先确认数量从哪一步开始丢。用ogrinfo -so -al查看源 KML 的要素数量再用同样命令看转换后 SHP 的要素数量。如果差异在转换这一步把 KML 在 QGIS 里直接打开作为参照QGIS 能加载出来的数量和 SHP 对比能快速定位是驱动解析问题还是几何非法问题。空几何没有补救价值直接用属性表过滤掉即可但需要在意的是那些因为坐标缺失被整条丢弃的要素确认没有重要信息损失再交付。6. 验证与进阶让每一次 KML 转 SHP 都可交付转换完成不代表可以交差。所有格式转换工作的最终验收标准只有一个属性字段对得上、要素数量对得上、坐标范围对得上。这一章的验证流程我一直在用能挡住绝大多数返工。6.1 快速验证字段名、要素数量、坐标范围三重对比字段层面对比最简单用ogrinfo分别打印源 KML 和结果 SHP 的字段列表肉眼对比或让脚本比较一下ogrinfo -so -al C:\input\survey.kml ogrinfo -so -al C:\output\survey.shp比对时留意两种差异KML 里有但 SHP 里没有的字段、以及被截断到 10 字符以内的字段名。要素数量对比同样用这两条命令的Feature Count输出。坐标范围对比则要看Layer Extent如果 SHP 的 extent 和 KML 的 extent 在纬度方向上偏移超过几十米基本可以判定坐标系出了问题。6.2 批量转换时把日志留好给自己留后悔药批量处理时我会在 Python 流水线里强制加日志每处理完一个 KMZ 就写一行状态记录。文件名、要素数量、字段列表、耗时全部落盘。一旦交付后被退回来第一件事不是重新转换而是打开日志看当时是用哪个版本的工具、哪套参数转的。这个习惯帮我省了大把排查时间。从那以后我每次接外业 KML都强制先跑一遍ogrinfo看图层结构和字段情况再决定走哪条转换路线哪怕对方说格式很标准我也当它是玄学先验了再说。希望这份记录帮到你少踩几个坑。本文还有配套的精品资源点击获取