2025年做地图相关的事情基本绕不开 OpenStreetMapOSM。最近我在整理一套“全国分省市”的 OSM 底图数据原本以为无非就是下载一个全国包再按省界裁一裁真正跑起来才发现把全国所有省级行政单位从全量数据里拆出来再把重点城市往下细分每一步都藏着不少道道。这篇文章就把完整的数据加工逻辑、实操过程和踩坑记录梳理一遍给同样需要处理 OSM 行政区划数据的朋友做一个参考。先说清楚这套数据是什么它基于 2025 年上半年的 OSM 公开全量矢量数据经过省级、地市级两级裁剪最终生成一套覆盖全国范围、以各省市为单位独立管理的矢量数据包。适合做地图底图、路径规划前的路网整理、POI 匹配、片区空间分析等场景尤其适合那些不希望每次都拿全量全国数据去跑项目的开发者和分析人员。下面按从需求拆解到最终交付的顺序把整个活儿讲透。1. 全国分省市 OSM 数据的需求与设计思路1.1 OSM 数据到底能提供什么为什么非要按省市切分OSM 是一套全球协作维护的开放空间数据要素类型非常丰富除了我们最熟悉的路网以外还有建筑轮廓、水系、绿地、铁路、公交站点、各类 POI。它最大的优点是免费、更新频率高、属性结构统一很多人拿它做底图或者训练数据。可是 OSM 的全球数据是整体打包发布的一个全国文件常常有几个 GB直接放进业务系统里查询会非常吃力。再加上国内行政区划边界、道路管理归属、各类应用场景都要按省市划分数据权限做全国级别的分析时如果不把数据切分好下游的每一次数据抽取都得加载一遍全量数据效率低且难以维护。所以“全国分省市”不只是数据组织习惯更是工程项目里的刚需。为什么不用在线 API 直接按范围拉取因为一次 API 拉取通常只能覆盖一个城市级别的范围而且有配额限制数据完整性和时效性也难保证。最稳妥的方案是拿一份全国全量 PBF在本地用边界文件做一次性裁剪得到各省市的独立数据文件后续再按需合并或抽取要素。这样生成的数据语义清晰、版本可控、可重复加工。1.2 不同数据源和切分策略怎么选网上能拿到 OSM 全国数据的地方不少常规渠道有全球镜像、第三方导出工具和一些提供定制切片的服务商。它们的数据鲜度、切分粒度差别挺大渠道类型数据粒度优点注意点全球公开镜像完整 PBF按洲或国打包数据全适合本地二次加工文件体积大首次下载耗时第三方行政边界导出部分已有省市分类省去自己裁剪边界可能过时属性标准化程度不一在线 API 拉取按包围盒或关系提取适合小范围快速获取有范围限制不适合全量批量自主研发裁剪任意边界组合灵活可控能统一坐标系和属性需要自己准备边界文件和工具链在实际项目中我一般推荐走“全量 PBF 本地裁剪”的路线因为这套流程在数据更新时只需要重跑一次裁剪脚本就能保持所有省市文件的同步更新。如果直接依赖第三方现成的省市数据包虽然省事可一旦遇到边界调整或者要素修正很难跟上节奏。自己做裁剪前期多一些工作量但胜在可控。为了避免数据处理过程中边界口径不一致我的设计思路是先确定一套统一边界数据建议用某数据源提供的标准行政边界 GeoJSON然后基于这套边界去裁剪全国 PBF保证所有省市文件的行政归属一致。这比按包围盒去切要严谨得多因为包围盒是矩形会把相邻省市的要素一并框进来给后期清洗带来额外负担。2. 核心技术点拆解数据格式、坐标体系与裁剪逻辑2.1 PBF、GeoJSON、Shapefile 到底怎么选OSM 的原始数据是 XML 或者 PBF 格式。XML 易读但体积巨大2025 年的全国全量 XML 动辄几十 GB实际工程里基本不碰PBF 是二进制压缩格式体积小、解析快是官方主推的数据交换格式。所以第一步拿到手的应该是全国 latest 版本的 PBF 文件。后续按省市裁剪后输出格式就要根据需求来定了如果只是做中间结果继续保留 PBF 就好后面还能用各类工具再加工如果要入库到 PostgreSQL/PostGIS 或者做空间分析GeoJSON 是最省心的因为 GDAL、Fiona、GeoPandas 都原生支持如果对接的是老 GIS 软件或者需要带字段样式进入传统管线Shapefile 仍然有它的江湖地位只是字段名长度限制、文件多文件支撑这些老问题要心里有数。我个人的经验是边界文件用 GeoJSON裁剪中间产物用 PBF最终面向业务系统的底图用 GeoPackage 或 Shapefile。GeoPackage 是单文件、支持空间索引、字段类型更丰富现在很多地图应用已经默认支持比 Shapefile 更适合作为交付格式。2.2 坐标系与地理配准为什么 OSM 数据要特别留意偏移OSM 的数据本身是基于 WGS-84 经纬度坐标系的也就是 GPS 设备常用的全球坐标。这个坐标系本身没毛病问题在于国内地图服务普遍使用加密坐标系两者之间存在着非线性偏移。直接拿 OSM 的 WGS-84 数据叠到某商业地图底图上会看到道路和建筑错位几十到几百米不等。所以如果只是做内部空间分析、路网建模、POI 匹配保留 WGS-84 没有问题但如果要跟国内主流地图混合展示就必须先做坐标转换。这个转换不是简单加减偏移量而是需要调用相应的纠偏算法或服务“固定偏移量”的做法只能在小范围勉强用放到全国尺度上误差会明显增大容易出现在同一城市不同区域内偏移方向不一致的情况。坐标系的处理应该在裁剪之前统一好。我建议先保持原始坐标系做完所有裁剪和属性操作最后到成图阶段再按业务需要投影或切换。因为裁剪阶段一旦做了坐标系转换边界匹配容易出问题后续想要回到原始坐标反而麻烦。2.3 裁剪算法原理简析不是“画个框切一刀”那么简单按省市裁剪看起来像是在全国地图上拿一把剪刀剪出各省的形状实际落地时有个核心难点边界线附近的要素怎么归属。比如一条横跨两个省的公路在 OSM 里可能是一条完整的长 LineString并不会因为省界就被拆成两段。如果只用简单的多边形相交判断这条公路要么整条留在 A 省要么整条划给 B 省跟真实情况不符。更合理的处理方式是先做边界要素的切割再根据要素几何与各省多边形的位置关系做归属分配。像路网、水系这类跨越边界的线状要素通常要把几何按边界线切分后分别归档到对应省份。建筑、POI 这类点状或面状要素则相对简单根据中心点或几何重心落在哪个省内来判断归属即可。Osmium 这类工具内部实现其实做了比较复杂的空间索引和几何切割它并不只是判断“是否在框内”而是会考虑线和边界多边形的关系对挂在边界上的要素做切割处理从而保证每个省的数据是相对完整的。理解这一点很重要否则当你发现省会城市周边道路总在边界处断开还以为工具出了问题其实是裁剪逻辑本来就是这样设计的。3. 实操全过程从下载到出成果3.1 环境准备工具清单与安装要点工欲善其事必先利其器。我这次用的组合是osmium-tool负责 PBF 提取和边界裁剪GDAL/OGR负责格式转换和矢量操作Python 3 环境配合 geopy/pyshp/geopandas 做批量处理QGIS用于人工抽检边界和要素分布osmium-tool 是命令行工具安装很直接macOS 上直接用 brew 装即可Windows 下可以下载预编译包放 PATH 里。这个工具对内存和 CPU 的利用率很高裁剪全国数据时如果机器的内存不足 8GB建议先做层过滤再裁剪不然内存会被撑爆。GDAL 是重头戏在很多发行版里可以直接通过包管理安装装完以后要顺手验证一下 ogrinfo 命令是否可用。另外一个容易忽略的点是处理中文属性值时一定确保系统 locale 支持 UTF-8否则后续转 Shapefile 时字段名和属性值都可能出现乱码。3.2 获取全国 PBF 数据版本选择与下载校验下载这一步看起来简单但有几个细节值得盯一下。一是要选对文件版本。公开的国内全量数据通常有“latest”和带日期的快照版本为了确保成果可复现我建议下载带日期的版本文件名里注明具体日期这样以后回溯数据修改时间点时有据可查。二是下载后要做完整性校验通常数据源会同时提供一个校验文件用系统自带的校验工具跑一遍摘要比对确保文件没有在传输过程中损坏。实际下载命令类似于wget https://某数据源路径/china-250101.osm.pbf wget https://某数据源路径/china-250101.osm.pbf.md5接着做哈希校验md5sum -c china-250101.osm.pbf.md5看到输出里出现 OK 字样才代表文件完整。这一环节很容易被忽略可一旦文件在传输中被截断后面的裁剪会失败或者得到错误数据排查起来非常浪费时间。拿到 PBF 后我先用 osmium 把全国 PBF 里面比较占空间但业务中不太需要的类型做一次粗筛。比如如果做的是道路和建筑分析可以先按类型提取所需要素保留到中间 PBF这样后续裁剪的压力会小很多。osmium tags-filter china-250101.osm.pbf w/highway w/waterway w/building r/route a/amenity -o china-filter.osm.pbf这里要解释一下w/代表 wayr/代表 relationa/代表 area后面跟的是标签条件。这样筛出来的中间文件会比原始文件小不少处理速度自然就上来了。3.3 准备省市边界文件统一口径的关键全国省市边界数据的收集是需要特别细心的一步。很多人会从各类在线地图抓取行政边界但这些边界很可能自带坐标偏移、边界顶点简化过度、不同层级边界互相矛盾等问题。我建议使用规范发布的行政边界 GeoJSON并且统一采用 WGS-84 坐标避免和 OSM 源数据坐标不一致。边界文件到手后第一件事是检查属性表里是否有省级代码、省级名称、地级市名称、地级市代码这些字段。因为这个字段将决定后面批量命名和分类是否正确省一级和市一级的数据能不能分别整理出来都依赖它。若字段不完整可以用代码表和名称做一个匹配映射表再用脚本补全属性。为了让后续按省、按市批量裁我习惯把边界文件按照层级存成两个目录一个放省级边界一个放地市级边界文件命名统一采用“行政区划代码名称.geojson”的形式。比如“某省.geojson”“某市.geojson”。代码和名称直接写在文件名里后面的裁剪脚本就能自动生成输出路径不需要每次手动改配置。3.4 核心裁剪步骤osmium extract 批量实施边界和源文件都备齐后裁剪过程就简单了。osmium 的 extract 子命令按多边形边界读取数据基础命令长这样osmium extract -p 某省.geojson china-filter.osm.pbf -o 某省.osm.pbf加--overwrite可以在重复执行时覆盖已有文件。这里有一个很重要的参数叫--strategy它控制的是完整区域提取还是简单区域提取。默认的 complete_ways 策略会保留跨越边界的完整线要素而 simple 策略则按相交关系切分。对于路网这种连续要素我更推荐用 complete_ways以保证每个省内的公路是连续完整的后续做路径规划时不会出现到了省界就断掉的问题。批量跑的时候我用一个简单的 bash 脚本遍历省级边界目录下的所有 GeoJSON 文件逐个调用 extract。示例脚本如下for f in boundaries/province/*.geojson; do name$(basename $f .geojson) osmium extract --overwrite -p $f china-filter.osm.pbf -o output/province/${name}.osm.pbf done省级裁剪完成以后再针对地市级边界跑一遍同样的流程只是输出目录换成地市级目录。这里特别提醒地市级裁剪应该基于裁剪后的省级 PBF还是基于全国 PBF按常理地市属于省直接从全国文件里裁也可以但为了保持数据的一致性和减少 I/O 开销我建议先裁省再从各省的 PBF 里裁市。这样每个市的数据严格是省级成果的子集不会出现省数据和市数据范围打架的现象。3.5 数据校验裁剪结果不可省的一道工序不能剪完就认为大功告成。裁剪之后我一般做三个层面的校验要素数量级对比对比全国 PBF、省级 PBF、地市级 PBF 的要素数量可以直观看出数据是否有异常丢失。比如某省数据量比相邻省份少一个数量级那基本可以断定边界或者裁剪参数出了问题。地理范围检查用 ogrinfo 或者 QGIS 打开边界文件检查数据的包围盒是否落在该省市范围内以及是否存在加载出来空白、坐标系异常的情况。属性标签检查抽取一部分要素确认 OSM 标签字段还在比如公路的highway值、建筑的building值没有丢失。关于第二点我提供一个小命令可以快速查看 PBF 基本信息osmium fileinfo --extended 某省.osm.pbf它会输出文件的总对象数、节点数、路径数、关系数、坐标范围等元数据。坐标范围这个指标最有用一眼就能看出数据是否真的落到了目标省市附近。如果范围对不上那说明边界文件和裁剪流程里有逻辑错误要立刻排查。3.6 导出为业务可用的格式GeoPackage 与 Shapefile裁剪后的一堆 PBF 还不是最终交付物。如果要进入业务系统通常还要转一次格式。我用 ogr2ogr 把 PBF 转成 GeoPackage这一步能把点、线、面分层导入数据库和 GIS 软件都能直接读取。ogr2ogr -f GPKG 某省.gpkg 某省.osm.pbf如果要把 OSM 的线、面混合数据拆分到不同图层可以用-where或者-sql参数做 SQL 级的过滤把它拆分成roads、buildings、waterways这些专题层。这样做对后续使用特别友好因为 OSM 原生数据是单图层混杂的不拆分的话业务端每次都要过滤标签查询效率很低。如果对接的老系统只认 Shapefile那导入后要注意字段名长度限制问题。OSM 的标签字段经过转换后常常变成很长的键名Shapefile 单个字段名不能超过 10 个字符直接转换会导致字段名被截断最好在导出前用 SQL 语句统一重命名。4. 常见问题与排查技巧实录4.1 边界数据缺失或错位做裁剪时最常见的问题是边界文件本身有问题。有时候从网上下载的边界 GeoJSON 缺了一个小岛有时候边界顶点密到极点在裁剪时会把相邻地区的零星要素带入目标区域导致边界处出现一些“飞地”要素。排查思路很简单先用 QGIS 打开边界文件重新投影到 Web 墨卡托底图上人工看一下边界是否闭合、是否覆盖完整。再用 osmium extract 之前用 ogrinfo 检查边界文件属性确认坐标范围不超过该省市的实际经纬度范围。处理飞行地要素的办法有两个一是裁剪后按要素中心点再做一次归属校验二是直接给边界做一些小的缓冲区收缩把边界线两侧各缩几米把误差范围压到最小。对于要求不那么严格的场景缓冲区收缩效果很好但如果是做精细路网就用中心点归属校验更稳。4.2 裁剪后要素数量差异过大有时候两个相邻面积差不多的省裁剪出来的要素数量能差 3 倍以上。这个现象不一定是错误更多是数据覆盖度不均导致的。因为 OSM 在国内的要素详情程度本身就有地区差异经济发达、活跃用户多的地区数据明显更细偏远地区可能只有主要公路和稀疏建筑要素数量自然差别巨大。不过如果某个省份裁剪前后完全没产出任何 PBF 文件那大概率是边界文件名和行政区划代码匹配出了问题。我在第一次跑批时就遇到过一个城市因为边界文件里没有对应代码脚本直接跳过导致输出目录里少了一个省。解决方法是写一个简单的清单比校脚本把输出目录的文件清单与边界目录逐一对比缺哪个就补哪个。另外要注意一个容易踩的坑全国 PBF 里部分边界附近的数据可能因为原始绘制的关系行政归属并不精确裁剪时要素跨越边界的情况非常频繁。省界附近可以定期抽检看看是否存在明显的距离误差再用数据清洗手段处理避免把这些错误带进最终业务分析。4.3 中文乱码与属性丢失OSM 的属性值是 UTF-8 编码在转 Shapefile 时如果系统默认编码不是 UTF-8就会出现乱码。解决方法是导出时显式指定编码ogr2ogr -lco ENCODINGUTF-8 -f ESRI Shapefile 某省.shp 某省.gpkg属性丢失一般出现在标签过滤阶段。若用 tags-filter 筛数据时只保留了部分标签那么后面导出自然少字段。解决的方法是明确列出需要的标签或者在裁剪完成后用 osmium tags-filter 再补一步全标签提取把常用标签合并进结果。我个人的习惯是先用全量标签裁剪导出到 GeoPackage 的阶段再做图层拆分这样能保留最完整的属性信息后续使用灵活。4.4 内存与性能优化裁剪全国 PBF 时最影响体验的就是内存占用。osmium extract 默认会读入大量节点信息如果文件到了多 GB 级别内存不够时会明显变慢甚至报错。我的处理经验是尽可能先做标签过滤把不相关的要素剔除再按大区拆分比如华东、华北先拆成若干中间块再从中间块里提取省市。对于多核服务器可以并行跑多个 extract但要注意磁盘 I/O 瓶颈。三个并发进程以内通常能线性加速开太多反而因为磁盘读写争抢而整体变慢。另外把源 PBF 放到 SSD 上能明显提升裁剪速度这个差异在处理十 GB 级文件时非常明显。4.5 裁剪后数据更新时间不同步OSM 每天都有变化可能今天导出的全国数据和本周第一次导出的、上月的都不尽相同所以数据的“时效性说明”非常重要。建议在最终交付目录里单独放一个 README 文件记录源数据快照日期、边界数据来源版本、裁剪工具版本和命令参数。这样即使过几个月后再重新生成也能知道和旧版本的差异点。每个省市包内也可以记录一个source.txt写清楚数据来源和时间这是很多项目审阅时必须的追溯材料。5. 这份数据能做什么以及后续扩展方向5.1 地图可视化与导航底图处理好的省市 OSM 数据最直接的应用是做可视化底图。把裁好的 GeoPackage 导入地图引擎配合道路等级样式渲染短时间内就能生成一套风格统一、免费可用的地图底图。对于跨省物流、旅游出行这类需要多区域底图叠加的业务分开管理的省市数据反而比全国整体数据更容易做按需加载用户滑动地图到哪个省就加载哪个省的数据性能优化空间很大。如果要做路径规划建议在裁剪时保留完整路网关系并额外用 OSM 的高等级道路标签做一层过滤生成一张更适合路径计算的路网底图。再结合导航引擎的拓扑规则做一个简单的路网连通性检查尤其是省界附近是否存在断裂这个检查能省去后期大量定位 bug 的时间。5.2 城市规划与基础设施分析OSM 里的建筑、水系、绿地数据在城市规划分析中很有价值。比如利用建筑轮廓数据计算片区的建筑密度利用水系数据做洪水影响范围粗分析利用绿地公园数据做居民步行可达性研究。这些分析通常不需要购买商业数据OSM 已经能提供一个不错的底数。使用时要记住不要把 OSM 数据当作官方权威数据。它的某些区域更新非常及时某些区域又长时间没人维护数据密度不代表真实情况。在输出分析结论前建议先做一个数据覆盖度可视化看目标区域的数据完整性是否满足分析要求。如果区域内明显有大量村庄没有建筑轮廓那分析时就要对缺失情况做说明避免结论失真。5.3 与自有数据融合的注意事项把 OSM 数据和业务采集的 POI、房屋产权数据做融合是另一个常见场景。融合前最重要的事是统一坐标系和 ID 体系。OSM 的 ID 是全局递增的在裁剪、转换后并不会保留原始关系 ID 的稳定值所以不要拿 OSM 的 ID 作为业务数据的关联键应该用经纬度加标签属性做空间联合方式匹配。融合时如果发现业务数据点在 OSM 边界里找不到对应的面要素不要急着丢弃很可能是两个数据源采用了不同的边界口径。解决方法是先把业务点落图人工抽几个样本判断是否存在系统性偏移。如果偏移方向一致可以统一做一次坐标修正如果方向不一致则要回到数据源排查采集问题。5.4 从省内再进一步按区县细分省级、市级数据都做好了后续如果业务需要下沉到区县完全可以复用这套流程只要把边界文件换成区县级 GeoJSON重跑一遍裁剪脚本就行。这也是我不建议直接使用网上现成省市包的原因——行政区划调整一旦发生区县边界就变了而利用脚本和边界目录重跑一套数据成本非常低。在脚本设计上我的做法是写一个三层循环分别遍历“省→市→区县”输入统一边界目录输出三级目录结构。这样不管是完整跑全国还是单独重算某个省都能一键完成。为了让模块便于维护我把边界目录、源数据路径、输出目录都抽成配置变量换一套行政区划数据也能直接复用不需要改代码逻辑。最后的经验小结把 2025 年全国分省市 OSM 数据完整做下来我最大的感受是技术上真正难的不是某一个环节的单独实现而是从全国 PBF 到分省市数据这个过程中如何保证边界一致、属性完整、更新可追踪。很多时候花在排查上的时间比裁剪本身还多。建议第一次接触这套流程的朋友先把边界文件、源数据、输出目录的命名规范定下来后续所有脚本都围绕这个规范写。哪怕初期多花半小时做规划后面重跑数据时你会回来感谢自己的。另外一个建议是数据交付时一定要带上生成说明文件。文件里写清楚源数据日期、裁剪策略、边界来源和坐标信息。这不仅是项目管理的需要也是同一份数据在不同团队成员手里能保持口径一致的基础。数据本身做得再好如果离开了这些元信息过几个月再被别人拿来用很可能就被当成普通数据直接使用而忽略掉它的时效性和适用边界。