简介郑州市OSM道路矢量数据是一份面向GIS从业者、城市规划与交通研究人员的已处理地理数据集基于OpenStreetMap项目提取郑州市道路网络包含道路线性几何、类别与属性信息可用于路网分析、可达性计算及多源数据叠加等场景。压缩包共9个文件核心为Shapefile格式涵盖.shp几何存储、.dbf属性表格、.prj坐标参考、.sbn/.sbx/.shx索引加速、.cpg字符编码及.shp.xml元数据另附道路类别对照图便于理解OSM标签与本地分类的对应关系。整个资源包约4.49MB轻量易用配合QGIS或ArcGIS即可直接加载与查询。已有395人下载学习适合需要高质量道路底图的中级及以上GIS用户快速开展空间分析与可视化。1. 郑州市OSM道路矢量数据已处理一份拿来就能算的路网省掉的不只是下载如果你做过任何一个和城市路网打交道的空间分析一定遇到过这种场景千辛万苦从 OSM 拿到了郑州市的矢量数据打开属性表一看里面什么都有——从高速公路到田埂小路从正在修的断头路到已经被废弃的机耕道highway 字段二三十种取值name 字段有的是中文有的是拼音还有的是乱码。于是你不得不花一个下午写筛选逻辑、处理拓扑、统一坐标系然后才敢开始你要做的路网密度测算或者路径规划。这份被标记为“已处理”的郑州市OSM道路矢量数据解决的就是这个问题。它不是原始抓取数据而是已经把道路分级筛选、坐标统一、拓扑修正等脏活做完了的数据。适合做城市规划分析、物流路径规划、GIS 制图和空间数据库入门的从业者拿到手可以直接进分析流程而不是先当几天数据清洁工。2. 数据成分拆解字段、坐标系与“已处理”到底处理了什么拿到一份别人交付的矢量数据第一件事不是急着打开而是先搞清楚它的“底细”。这里的“已处理”三个字不同的人可能有完全不同的理解。有人做的处理是转了坐标有人是裁了边界有人只是改了文件名。所以这一章先帮你看懂这份数据的内部结构再教你怎么核对它到底处理到位没有。2.1 从OSM原始路网到“已处理”数据highway标签体系与筛选逻辑OSMOpenStreetMap的路网数据核心是一个叫highway的标签体系。它不像国内很多商业数据那样把道路分成“高速公路、一级公路、二级公路”这么简单而是分得极细——motorway是高速trunk是高等级干线primary是城市主干道secondary是次干道tertiary是支路residential是居住区内部道路service是内部服务道路还有footway、cycleway、path这类非机动车道以及motorway_link、trunk_link这类匝道连接线。原始 OSM 数据里这些类型全部混在同一条道路上。你做一个全市路网长度统计如果不加筛选把footway和cycleway也算进去结果会虚高得离谱。一份“已处理”数据最基础的处理工作就是按使用场景做了道路分级筛选。常见做法是只保留motorway、trunk、primary、secondary、tertiary、unclassified、residential这些可通行机动车道路酌情保留link类匝道去掉footway、path、steps、cycleway这类非机动车道。判断一份数据处理得到不到位先看它是否保留了多层级的筛选逻辑而不是一刀切只留主干道。好的处理会在数据里加一个road_class或者road_level的中文分类字段比如“高速公路、国道、省道、县道、乡道”或者“快速路、主干路、次干路、支路”。这样下游做不同尺度的分析可以按字段取数。2.2 字段说明从OID到oneway哪些能直接用、哪些要小心打开这种处理过的矢量数据的属性表你大概率会看到这样几个标准字段字段名常见类型含义说明使用建议oid或osm_id整型OSM 原始要素 ID 或处理后的唯一编号可用于关联原始数据不做分析依据name字符串道路名称注意可能有空缺或含旧名需人工抽查highway字符串OSM 道路类型原值保留原始类型便于后续自定义筛选road_class字符串处理后的中文道路分级做统计时优先用这个字段oneway字符串/整型单行道标识yes/-1/空空值不代表双向详见第 5 章避坑lanes整型车道数OSM 数据常有缺失缺失时建议按道路等级估算maxspeed整型限速km/h同样有缺失率用于路由分析时要兜底surface字符串路面材质多数道路为空判断可通行性时慎重length_m浮点型处理时计算好的道路长度米前提是数据已转投影坐标否则长度不准拿到数据后我建议你先用 SQL 或者 Excel 统计一下每个字段的非空率。比如name字段如果覆盖度低于 60%说明这条数据的名称信息不完整做地名检索和路径规划的体验会大打折扣。length_m字段是后续所有统计的基础抽几条路和 OSM 网络页面对比一下长度误差在合理范围内才敢放心用。2.3 坐标系这道坎WGS84经纬度、投影坐标与距离计算的玄学做路网数据的人在坐标系上翻车是常态。原始 OSM 数据一律是 WGS84 经纬度坐标EPSG:4326单位是度不是米。当你直接拿经纬度数据计算道路长度时得到的结果是“度”毫无意义。一份“已处理”数据通常有两种坐标形态。第一种是保留 WGS84 经纬度方便直接叠加各类在线底图和原始 OSM 数据做对比。第二种是转成了适合郑州市本地的投影坐标比如 CGCS2000 3 度带高斯投影或 UTM 49N郑州经度约113.6°EUTM 49N 覆盖 111°E 到 117°E这样length_m才能算得准。我一般会看两个信息来判断坐标处理是否正确一是查数据框的属性看PRJ文件或 GeoJSON 里的crs声明二是把数据叠加到在线底图上看道路走向是否和底图吻合。如果数据标注是 WGS84 但叠上去整体偏移了 300 米左右那大概率是二次加密后的坐标不是真正的 WGS84。这一点在后面的避坑章节会展开讲。2.4 你应该核对的数据清单拿数据后先查这四样别管数据描述写得多漂亮拿到手必须自己验一遍。我每次拿到同类路网数据会固定检查四样东西第一空间范围。用 QGIS 打开数据查看图层范围是否正好覆盖郑州市行政边界还是带了一大圈周边区县。有些“郑州市数据”其实裁的是整个郑州都市圈做统计数据时容易把周边城市的路网也算进来。第二字段完整性。对照上一节的字段表检查必需字段是否存在、是否有大量空值。重点查oneway和lanes这两个字段在 OSM 原始数据里缺失率相当高处理后数据如果没做填补后面做交通分析会有麻烦。第三几何有效性。在 QGIS 里运行“检查几何有效性”看有没有自相交、重复节点、空几何。郑州老城区路网经过多次编辑偶尔会有拓扑问题残留。第四时间戳。看 OSM 数据的timestamp或元数据里标注的数据获取时间。城市道路变化很快五年前的数据和现在的路网差距巨大。如果你拿旧数据做现状路网分析结论会失真。3. 从OSM自己造一份“已处理”路网下载、裁剪、清洗的完整步骤不是说所有场景都适合直接用别人处理好的数据。有些项目对数据口径有特殊要求——比如你只需要高速和主干道或者你需要包含完整的步行道路网。这种情况下自己从 OSM 原始数据走一遍处理流程更靠谱。这一章给出一条完整的操作路径每一步都有对应命令。3.1 获取郑州市范围OSM数据的常规渠道与命令获取 OSM 数据有几种常见渠道Geofabrik 提供按国家和地区划分的下载包粒度到省BBBike 提供按城市范围定制的提取服务Overpass API 适合按 bbox 或行政区边界做自定义查询。对于郑州市这个尺度最快的办法是直接下载中国区数据然后用边界裁剪或者用 Overpass 按 bbox 拉取。以命令行操作为例用osmium工具从中国区数据中提取郑州市范围是常见做法。先把下载好的中国区 PBF 文件放在工作目录# 下载中国区 OSM PBF 数据以 Geofabrik 为例文件名按实际情况替换 # curl -O https://download.geofabrik.de/asia/china-latest.osm.pbf # 用 osmium 按边界裁剪出郑州市范围 # 假设你已有一个 zhengzhou.geojson 或 zhengzhou.poly 边界文件 osmium extract -b 112.5,34.2,114.2,35.0 china-latest.osm.pbf \ --output zhengzhou_raw.osm.pbf \ --strategycomplete_ways # 或者如果边界文件是 poly 格式 osmium extract -p zhengzhou.poly china-latest.osm.pbf \ --output zhengzhou_raw.osm.pbf \ --strategycomplete_ways这里-b参数后面跟的是郑州市的经纬度边界框西、南、东、北具体数值需要按你的实际范围调整。--strategycomplete_ways的作用是保证每条被裁剪出来的道路都保留完整的几何——如果不加这个参数跨边界的道路会被截断成两截后续做路网分析会产生大量断点。osmium是一条命令搞定 OSM 数据处理的利器支持 extract、tags-filter、time-filter 等子命令。如果机器上还没装在 Ubuntu 上可以用apt install osmium-tool在 macOS 上用brew install osmium-tool需要 Tap。Windows 用户可以直接下载 exe 二进制文件。3.2 按行政边界裁剪不只是几何相交那么简单上一步用了 bbox 裁剪但 bbox 是矩形范围会把郑州周边郊县和邻近城市的道路也裁进来。做正式分析前最好按郑州市行政边界做精确裁剪。常见做法是先从国家地理信息公共服务平台或者公开的行政区划数据集里拿到郑州市的区划边界转成 GeoJSON 或 poly 格式然后用osmium extract -p按多边形裁# 按郑州市行政边界 polygon 裁剪 osmium extract -p zhengzhou_adm.poly china-latest.osm.pbf \ --output zhengzhou_admin.osm.pbf \ --strategycomplete_ways # 查看裁剪结果的分层统计 osmium fileinfo --extended zhengzhou_admin.osm.pbf这里有个关键细节行政边界裁剪时覆盖边界的道路会被完整保留还是被切断取决于 OSM 数据里那条路是否跨越边界。complete_ways策略会保留跨边界道路的完整几何但代价是会把边界外一段距离的路也包含进来。做严格统计时需要后续在 GIS 里再做一次按边界的精确裁剪把边界外的部分切掉。这其实引出一个常见争论统计城市道路里程时跨城道路是全场算还是只算城内段我见过两种处理逻辑都有但你在交付分析结果时必须说明口径。如果数据是拿来做城市内部路网结构的建议用 GIS 的裁剪功能做一次精确切割如果是做区域交通分析的保留完整几何更合理。3.3 道路筛选与字段规整ogr2ogr的SQL方言用法从 OSM 提取的 PBF 装的是原始数据包含道路、建筑、水系、土地利用等所有类型的要素。下一步是把道路单独抽出来并整理字段。这一步用 GDAL 的ogr2ogr一步到位非常方便# 先把 OSM PBF 转为带几何的 GPKG同时用 SQL 筛选道路类型 ogr2ogr -f GPKG zhengzhou_roads.gpkg zhengzhou_admin.osm.pbf \ -sql SELECT osm_id, name, highway, oneway, maxspeed FROM lines WHERE highway IS NOT NULL \ -lco GEOMETRYLINESTRING # 再按 highaqy 类型过滤掉非机动车道 ogr2ogr -f GPKG zhengzhou_roads_clean.gpkg zhengzhou_roads.gpkg \ -sql SELECT * FROM zhengzhou_roads WHERE highway IN (motorway,trunk,primary,secondary,tertiary,unclassified,residential,motorway_link,trunk_link,primary_link,secondary_link,tertiary_link) \ -nln roads第一段命令里的lines表是 OSM 在 GDAL 驱动下的默认图层名它包含所有线状 OSM 要素所以要用WHERE highway IS NOT NULL把非道路的线剔除。GEOMETRYLINESTRING是 GPKG 的图层创建选项保证几何类型统一。第二段命令用IN列表精确圈定要保留的机动道路类型。这里我给你一个忠告谨慎决定是否保留link类匝道。如果你做的是全市路网密度分析匝道会被统计进里程但如果你做的是路网连通性分析匝道恰恰是连接高速和城市道路的关键要素。两种需求对是否保留link有截然不同的答案所以原始数据里保留link字段、在分析时再筛比一开始就删掉要灵活得多。3.4 拓扑修复断头路与路口断点怎么补OSM 道路数据是志愿者编辑的不同路段的接续关系经常不完美。最典型的问题是在立交桥和交叉路口两条本来应该相交的道路在交点处没有共享节点几何上看起来很近但并没有真正连接。这对制图影响不大但做路径规划和网络分析时是致命的。拓扑修复的常规操作分两步。第一步在 QGIS 里做直观检查加载数据后用“拓扑规则检查”工具设定“不能有悬挂节点”规则找出所有端点没有连接到其他道路的线。第二步用v.cleanQGIS 处理工具箱里的 GRASS 算法做批量修复# QGIS 处理工具箱里的 GRASS v.clean 命令在工具箱搜索框输入 v.clean inputroads outputroads_clean \ toolsnap,break,rmdupl \ threshold0.0001,0.0001,0.0001这里的threshold单位是度和数据坐标系一致。对于 WGS84 经纬度数据0.0001 度大约对应 11 米——这个容差对城市道路来说偏大可能会把平行的相邻车道错误地合并。我一般会用 0.00001约 1 米作为起始值根据实际断裂情况微调。需要提醒的是拓扑修复不是无条件的“能连就连”。原本不相交的人行天桥和被立交分隔的上层道路在 GIS 里距离很近但物理上确实不连通。自动修复这些错误比手工画还难。所以我的做法是分两级高速公路和城市快速路的连接点全部人工检查支路和内部道路用自动修复把错误控制在可接受范围。4. 离线应用落地把shp格式矢量数据导出为WKT再进PostGIS数据无论从哪个渠道拿到的最终都要落到实际的业务场景里。对很多人来说郑州市的路网数据是用在离线环境下的内网开发、本地系统集成、没有外网的数据分析平台。这一章讲怎么把这套矢量数据转成离线环境最容易用的格式以及怎么接进空间数据库做查询。4.1 为什么离线交付常用shpWKT这套组合Shapefileshp是 GIS 领域最通用的矢量交换格式几乎所有平台、库、语言都支持读写。但它有个老毛病属性表字段名限制 10 个字符而且一个完整要素需要.shp、.dbf、.shx、.prj四个文件一起携带少一个就麻烦。WKTWell-Known Text是文本形式的几何表达单条记录长这样LINESTRING (113.62 34.74, 113.63 34.75, ...)。它最大的好处是纯文本、可读、几乎任何语言都能解析一份 CSV 文件里可以同时放属性字段和 WKT 几何列离线系统里做数据交换非常方便。要做离线路网分析常见的做法是保留 shp 作为基础数据包需要与外部系统交换时再导出为带 WKT 列的 CSV。这样原始数据不丢交换时又不怕对方没有 GIS 环境。4.2 用ogr2ogr把shp导出为WKT的快速命令如果你有 GDAL 环境导出 WKT 是几个参数的事# 把 shp 或 geojson 导出为 CSV几何字段输出为 WKT ogr2ogr -f CSV zhengzhou_roads_wkt.csv zhengzhou_roads_clean.gpkg \ -lco GEOMETRYAS_WKT \ -lco CREATE_CSVTYES \ -select oid,name,highway,road_class,oneway,length_m # 查看导出结果前三行 head -3 zhengzhou_roads_wkt.csv第一段命令的关键在-lco GEOMETRYAS_WKT它告诉 GDAL 把几何字段输出为 WKT 文本而不是二进制。CREATE_CSVTYES会额外生成一个.csvt文件声明每列的数据类型这样再导入 PostgreSQL 或其他数据库时字段类型不会自动被猜错。这个命令特别适合在离线环境下使用。你可以在内网机器上装一个便携版 GDAL把转换流程写成一个脚本每天跑一遍增量更新本地团队拿着 CSV 就能做二次开发。4.3 用Python批量把shp转WKTgeopandas方案如果你的环境里有 Python用 geopandas 处理更灵活。这里给一个可以直接改参数用的脚本import geopandas as gpd # 读取 shp 或用友 GPKG 数据 gdf gpd.read_file(zhengzhou_roads_clean.gpkg, layerroads) # 把几何列转为 WKT 文本 gdf[geometry_wkt] gdf.geometry.to_wkt() # 构造输出 DataFrame只保留需要的属性列 out gdf[[oid, name, highway, road_class, oneway, length_m, geometry_wkt]] # 导出为 CSV编码用 utf-8避免中文乱码 out.to_csv(zhengzhou_roads_wkt.csv, indexFalse, encodingutf-8-sig) # 顺手打印一条样例验证 print(out.iloc[0][name], out.iloc[0][geometry_wkt][:50])这段代码的关键是to_wkt()方法geopandas 底层用 shapely 的 WKT 输出默认保留完整精度。utf-8-sig编码会给文件加 BOM 头这样用 Excel 打开 CSV 时中文不会乱码——这个细节处理不好收你数据的人第一眼就会觉得不专业。如果不想要纯 CSV还可以用gdf.to_file(zhengzhou_roads_wkt.geojson, driverGeoJSON)GeoJSON 本身就是类 WKT 的文本结构很多 Web GIS 系统可以直接消费。4.4 导入PostGISshp2pgsql与空间查询示例离线环境中最常用的空间数据库是 PostgreSQL PostGIS。把处理好的路网数据导入 PostGIS后面所有空间分析、路径规划、属性查询都有了一致的数据源。# 用 shp2pgsql 命令把 shp 导入 PostGIS shp2pgsql -s 4326 -g geom -W utf-8 zhengzhou_roads_clean.shp zhengzhou.roads | psql -U postgres -d zhengzhou_gis # 或者用 ogr2ogr 直接导入更省事 ogr2ogr -f PostgreSQL PG:hostlocalhost dbnamezhengzhou_gis userpostgres \ zhengzhou_roads_clean.gpkg -nln roads -nlt LINESTRING导入完成以后可以做几个典型的空间查询来验证数据。比如统计每条道路的长度并找出全市最长的十条路-- 按道路名称聚合长度 SELECT name, SUM(ST_Length(geom::geography)) AS total_length_m FROM zhengzhou.roads WHERE name IS NOT NULL GROUP BY name ORDER BY total_length_m DESC LIMIT 10;这里用ST_Length(geom::geography)而不是ST_Length(geom)原因在于geom如果是 WGS84 经纬度直接算长度得到的是度。转成geography类型可以按椭球体计算真实距离单位是米。再比如做路网密度分析按 1km 网格统计每个格子里的道路里程-- 生成 1km 渔网并关联统计道路长度 WITH grid AS ( SELECT (ST_PixelAsPolygons(ST_SetValue(ST_AddBand(ST_MakeEmptyRaster(...), 1, 8BSI), 1, 1))) AS geom ) SELECT g.rid, COALESCE(SUM(ST_Length(ST_Intersection(g.geom, r.geom))), 0) AS road_length_m FROM grid g LEFT JOIN zhengzhou.roads r ON ST_Intersects(g.geom, r.geom) GROUP BY g.rid;这类查询在日常城市分析中很常用数据进了 PostGIS就等于有了一个随时可查询的“离线路网服务”不需要再反复打开桌面 GIS 导数据。5. 避坑指南处理郑州OSM路网时我踩过的五个坑这一章写的全是真实工作里遇到并解决过的问题。每条按“现象→原因→解决”写希望你能直接跳到与自己场景相关的条目少走一趟弯路。5.1 坐标系错位数据坐标明明是WGS84叠加后整体偏移现象拿到一份数据属性文件里写的是 WGS84但在 QGIS 里叠加在线卫星影像所有道路整体向东南方向偏移了三四百米。地图上道路悬浮在楼顶和农田上简直没法看。原因OSM 原始坐标确实是 WGS84但部分处理过的人工数据或者经手的数据商在导出时把坐标套到了加密坐标系上而且没有改掉prj文件里的描述。这属于典型的“文件名和内容对不上”。解决先用ogrinfo或 QGIS 的图层属性确认真实坐标。如果是加密坐标把图层强制重新定义为 WGS84 后再用“导出要素”重新赋值。如果偏移量稳定在几十到几百米可以做一个仿射变换选一组明显的路口控制点算平面偏移量然后在整个数据上做平移。这个操作在 QGIS 的Georeferencer或者 PostGIS 里用ST_Translate都能完成。5.2 路口拓扑断裂两条路在路口没有公共节点现象做最短路径分析时从一条主干道拐到交叉的另一条主干道上路径规划显示无法到达或者绕了单行线一圈。单独看几何两条路的端点距离只有几米视觉上明明构成十字路口。原因OSM 里两条道路的编辑时间和编辑者不同路口的交点没有通过共享节点连接。呈现上两条线各自断在路口附近几何不闭合。这个问题在城市道路中高发尤其是老城区和频繁修改的路段。解决先用 PostGIS 的ST_Snap把距离容差内的线端吸附到交点再重新构建拓扑。QGIS 里也可以用v.clean的snap和break配合处理。处理完以后必须用“Topology Checker”再跑一遍检查才能交付否则以后每个分析都可能踩雷。5.3 匝道混入主路motorway_link让统计数字虚高现象统计郑州市快速路里程结果比官方统计年鉴多了 15% 以上。查数据发现所有高架桥上下桥匝道都被统计进去了而且每条匝道长度被算了两遍——进入和离开方向各一条几何。原因highway字段里motorway_link、trunk_link这类连接线属于新增道路几何不做区分时会全部计入主路里程。而且匝道通常是双向分开绘制几何长度重复计算。解决做统计前先按道路等级过滤。用road_class字段如果已经分类好直接按快速路/主干路维度聚合。如果没有这个字段用highway的IN条件把link全部排除或者单独作为一个分类统计。好的做法是保留数据但统计口径里明确写“不含匝道”。5.4 oneway字段留空单行线方向被当成了双向现象输入一个路径规划请求从 A 点到 B 点导航输出一切正常但从 B 点回 A 点路线突然绕了两倍的距离。检查道路数据发现大量老城区道路没有oneway值而现实里它们是单行线。原因OSM 对单行线的标记依赖编辑者主动添加onewayyes或oneway-1。如果编辑者漏标数据里这一字段就是空。更隐蔽的是部分导出工具对空字段默认处理为“双向可通行”方向完全错误。解决拿到数据后先统计oneway字段的空值率。对郑州这种老城区单行线密集的城市空值率达到 40% 是正常的。要么用外部数据源比如在线地图或交管路况数据做匹配填补要么在分析的路径规划系统里对缺失oneway的道路采用保守策略——默认不开放双向通过人工核验补全单行方向。只靠 OSM 自身的数据做完全准确的单行线模拟目前是做不到的。5.5 dbf属性中文乱码导出CSV或进GIS后地名全花现象用 Excel 打开导出的 CSV道路名称全是“é¾å®¶åº”这类乱码。在 QGIS 里打开 shp 属性表中文正常但用 Python 读出来却报编码错误。原因Shapefile 的.dbf属性表没有内嵌编码声明最常见的是 GBK 编码。QGIS 能自动识别是因为它能猜但命令行工具和编程库不一定能猜准。把 GBK 的 dbf 直接导出为 UTF-8 CSV 时如果没有指定源编码就会按系统默认编码解读导致乱码。解决在 QGIS 里打开 shp 时在数据源管理器里手动指定“GBK”或“UTF-8”编码。用 Python 读文件时显式声明encodinggbk再输出为 UTF-8。用 ogr2ogr 导出时加上-lco ENCODINGUTF-8参数。核心原则是尽量不要使用软件默认值每次导入导出都显式指定编码。6. 数据验证与进阶用法把已处理数据用出生产力的技巧数据拿到手、也做了清洗和入库最后这一步是教你验证数据质量以及把数据用出真正生产力价值的几个技巧。6.1 三分钟验证法抽样叠加与字段核对我不会迷信“已处理”三个字数据到了手先花三分钟做一个快速验证。方法很简单在 QGIS 里加载数据和在线影像底图随机挑五个路段放大看是否和影像吻合。再看一眼属性表name字段的非空率。最后用length_m字段求和和常识对一下数量级——郑州市建成区城市道路总里程在数千公里级别如果你算出来只有几百公里或者几十万公里那一定有问题。更严格的做法是用 PostGIS 做一个自动校验脚本。检查每个要素的几何是否有效ST_IsValid(geom)是否全部为真相邻要素是否在端点处相交是否有投影范围外的异常点。校验脚本跑完输出一份报告这份报告可以随数据一起交付比口头说“已检查”可信得多。6.2 用一个轻量路径规划验证路网连通性路网数据能不能用于路径规划可以用 Python 的networkx快速验证。核心思路是把路口作为图的节点道路作为边跑通一条随机路径import geopandas as gpd import networkx as nx # 读取路网数据 gdf gpd.read_file(zhengzhou_roads_clean.gpkg) # 构建图以每条道路的起点和终点作为图的点 G nx.Graph() for _, row in gdf.iterrows(): coords list(row.geometry.coords) if len(coords) 2: start, end coords[0], coords[-1] G.add_edge(start, end, weightrow.geometry.length, osm_idrow[oid]) # 检查最大的连通子图占总节点数的比例越高越好 largest max(nx.connected_components(G), keylen) print(f最大连通域节点占比: {len(largest) / G.number_of_nodes() * 100:.1f}%)这个脚本的连通域占比如果低于 90%说明路网断裂严重需要回头做拓扑修复。对于处理后且修复过拓扑的路网数据这一指标通常能到 95% 以上。6.3 进阶用法把WKT转GeoJSON接入轻量可视化最后贡献一个我在离线项目中常用的技巧把 WKT 数据转成 GeoJSON再丢给前端做交互式渲染。GeoJSON 本身就是 JSON 文本浏览器可以直接解析。用 ogr2ogr 一行搞定ogr2ogr -f GeoJSON zhengzhou_roads_web.geojson zhengzhou_roads_clean.gpkg \ -t_srs EPSG:4326 \ -lco RFC7946YES转完之后用任何支持 GeoJSON 的前端库比如 Leaflet 或 MapLibre就能搭一个离线路网浏览器。不需要 PostGIS 也不需要桌面 GIS一个静态文件加一个网页就能让业务部门在线查看路网。我在多个内网项目里就是这样交付数据的。回看我经手过的同类数据最大的教训是一份路网数据交付出去真正决定口碑的不是下载时的完整度而是坐标系、编码、拓扑这几个基础细节有没有做好。这个道理同样适用于你自己动手处理的数据——每次多做一步验证和收尾后面使用的人就少踩一个坑。希望这些经验对你有用也祝你的路网数据顺利跑通。本文还有配套的精品资源点击获取