简介郑州市道路网络矢量数据集基于OpenStreetMapOSM开源地图项目已经过预处理面向GIS开发者与城市规划研究人员可用于道路网络分析、交通规划及可视化展示等场景。压缩包共9个文件约4.49MB包含核心几何数据.shp、属性表.dbf、坐标参考系统.prj等Shapefile标准组件并附有一张OSM类别对照表.jpg便于理解道路分类与OSM标签的对应关系。已有395人学习下载。数据集涵盖郑州市道路的线性几何、属性分类与道路名称可直接在QGIS、ArcGIS等软件中加载执行最短路径分析、交通热点识别或与人口、公交线路等其他数据进行叠加分析为城市规划、交通管理及应急响应等应用提供基础数据支持。1. 这份“已处理”的OSM道路数据到底能帮你少踩多少坑做城市规划、交通分析或地图可视化的朋友多半都有过这样的经历从 OpenStreetMap 下载到的郑州市道路数据打开一看坐标系是 WGS84 经纬度道路类型全靠highway字段里的几十种英文值区分而且路网断头、重叠、悬挂线到处都是连做个最简单的路网密度分析都得先花两天洗数据。这份标题里的“郑州市OSM道路矢量数据已处理”就是针对这个痛点来的——它不再是你自己从 OSM 原始导出的一堆“毛坯路网”而是已经完成投影转换、拓扑清洗、属性重构的“精装修”数据。本文会把这份数据的来龙去脉、加工逻辑、使用方法和踩坑点一次讲透让你拿到手就能直接用而不是再交一遍数据清洗的学费。2. 从OSM原始数据到“已处理”产物背后动了哪三刀要理解这份数据先得知道 OSM 原始数据长什么样以及“已处理”到底意味着什么。我见过太多工程师拿到 OSM 数据就直接做分析结果写在论文里被审稿人问“你的路网拓扑处理过吗”就直接卡住。处理过的数据和原始数据之间的差距绝不是换个坐标系那么简单。2.1 数据加工的第一个层次坐标系转换OSM 的原始数据一律使用 WGS84 经纬度坐标这个坐标系是个球面坐标系统单位是度不适合做长度和面积量算。做郑州市层面的路网分析常见做法是转换成 CGCS2000 / 3-degree Gauss-Kruger zone 38即 EPSG:4547或者 Web MercatorEPSG:3857。我一般会强烈建议用 CGCS2000 的高斯投影因为这个坐标系在郑州地区的长度变形小于 1/10000做道路长度统计、缓冲区分析时数据才是可信的。Web Mercator 虽然浏览器兼容性好但它的面积变形在郑州这个纬度约北纬 34°会膨胀 2 倍左右做密度类分析会出大问题。# QGIS 中查看当前图层坐标系 # 在图层属性 - 信息 - 坐标系 中确认 # EPSG:4547 是 CGCS2000 / 3-degree Gauss-Kruger zone 38覆盖河南地区 # 如果原始数据是 WGS84EPSG:4326用重投影图层工具转换很多新手在这步最容易翻车拿着经纬度坐标的数据直接叠加 CGCS2000 的底图结果道路全部偏出地图边界。处理好的数据会直接给你投影坐标系省掉这个最容易出错的操作。2.2 拓扑清洗把毛坯路网变成可计算的路网原始 OSM 数据的第二个痛点是拓扑混乱。道路在路口处经常没有精确相接公共边重复绘制还有大量只绘制了一半的断头路。这些在可视化里看不出问题但一旦做网络分析最短路径、等时圈结果会让人崩溃——因为路网根本连不上。处理过的数据会对道路进行拓扑重建具体包括三个动作断链处理把在路口相交但不共节点的线在交点处断开生成真正的节点。这步在 ArcGIS 里叫“打断相交线”但要注意打断后需要重建拓扑关系。重复边合并对于双向道路被画成两条几乎重合的线的情况将其合并成一条中轴线字段里用oneway或双向标记走向。悬挂线检查长度小于阈值通常取 3 米的悬挂线会被删除或标记为待核查。处理前后最大的观感差异是原始数据里有大量“毛刺”——几条十几厘米长的短线互相重叠交叉处理后的数据画面干净得多。2.3 属性字段重构从 highway 到面向分析的字段体系OSM 原始数据的highway字段是分类的核心但它的取值极其庞杂光道路类就有 motorway、trunk、primary、secondary、tertiary、unclassified、residential、service、living_street 等近 20 种而且还混着 footway、cycleway、path 等非机动车道类型。分析时要自己过滤非常麻烦。处理后的数据一般会重构字段结构常见做法是新增中文分类字段如道路等级把 OSM 的英文分类映射到国家标准体系。比如 motorway 映射为“高速公路”trunk 映射为“快速路”primary 映射为“主干道”secondary 映射为“次干道”tertiary 映射为“支路”。同时保留原始highway字段供你自行二次细分。字段重构的价值在于你可以直接在属性表里按“主干道”筛选而不是写一长串WHERE highway IN (primary, trunk, motorway)——这是一个非常真实的生产力提升。3. 读懂坐标系与投影郑州的道路数据到底落在哪套坐标里处理好的数据通常已经给出了明确的坐标系定义但你需要真正理解它是什么否则后续叠加其他数据源时还会犯糊涂。数据拿到手后不要急着做分析先花五分钟确认坐标系——这是所有地理数据工作的第一性原理。3.1 WGS84经纬度到地方投影的转换路径郑州位于东经约 113.6 度北纬约 34.7 度处于高斯-克吕格投影 38 度带的覆盖范围内。OSM 数据是 WGS84 经纬度直接换算到 EPSG:4547 后你会看到坐标数值从113.6, 34.7这样的度变成几百米的千米级数值——这是高斯投影带内的以米为单位的平面坐标。如果你拿到的处理数据是 EPSG:3857Web Mercator它也能用但这个坐标系只适合做底图显示和前端可视化不适合做长度和面积量算。做统计分析的底线是量算类操作必须在投影坐标系下做而不是在经纬度下做。-- SQL 示例PostGIS 中把 WGS84 数据重投影到 EPSG:4547 ALTER TABLE zz_roads_processed ALTER COLUMN geom TYPE geometry(LineString, 4547) USING ST_Transform(geom, 4547); -- 走查转换后检查长度变化 -- 原本经纬度下无法直接算长度转换后可以用 ST_Length 统计 SELECT SUM(ST_Length(geom)) AS total_km FROM zz_roads_processed; -- 结果单位是米除以 1000 得到公里数投影转换后一定要做一次全量长度统计作为“合理性检查”。郑州市建成区道路总里程大约在 3000~5000 公里量级如果你算出来只有 200 公里或者有 5 万公里那一定是有地方错了——要么是坐标系没转对要么是数据裁剪范围不对。合理范围的检查是数据工程师的底线意识。3.2 在QGIS里快速验证数据坐标系的正确性拿到数据后先做三件检查哪怕你不是 GIS 专业出身也要会打开图层属性看坐标系是否是 EPSG:4547、EPSG:4490 或者 EPSG:3857 之一加载一个在线底图如天地图或 ESRI 影像把道路数据叠加上去看道路是否和影像上的道路对齐看看道路图层能否正常显示中文属性属性表里打开道路名称这一列确认不是乱码。如果第一步发现坐标系是空的或者未知那就是数据出问题了千万别用。如果第二步对不齐不要轻易手动平移——很可能是坐标系搞错了应该回去确认坐标系定义。3.3 统一坐标系跨数据源叠加分析前的必做动作实际工作中你手里绝不是只有这一份数据。你还会有行政区划边界、土地利用现状、POI 点数据、影像底图这些数据来自不同口径坐标系可能五花八门。最稳妥的工作流是把所有数据统一到一个坐标系下再做任何叠加操作。我自己的经验是在郑州项目里我会把行政区划边界、POI、路网统一到 EPSG:4547。这个坐标系是 CGCS2000 下的高斯投影和目标区域完全匹配。注意这里有一个隐藏坑如果底图是遥感影像的 Web 服务通常是 EPSG:3857 切片叠加分析时请先确认你用的是不是“动态投影”模式——QGIS 会自动做即时转换但 ArcGIS 里有时候需要手动开“后台处理”。统一坐标系之后做缓冲区、做叠加统计、做路网密度计算出来的结果才是有意义的数字而不是一个仅供可视化的“图”。这个原则比任何具体工具都重要。4. 把数据用起来道路筛选、拓扑建网与网格化统计数据拿到手第一步是筛选你需要的那部分。全量道路数据包含所有等级的机动车道和非机动车道通常处理后的数据还会保留人行道、自行车道等 OSM 要素这些在你只需要机动车路网时是要剔除的。4.1 用字段筛选快速提取指定等级道路处理后的数据一般有类级或level字段按照从高速到支路的顺序排列。做路网分析时通常只需要保留机动车道过滤条件是等级在“支路”及以上同时剔除人行道、阶梯、行人区。-- 使用 SQL 筛选机动车道路网 CREATE TABLE zz_roads_motor AS SELECT * FROM zz_roads_processed WHERE 类级 IN (高速公路, 快速路, 主干道, 次干道, 支路) AND 类级 IS NOT NULL; -- 逻辑说明 -- 直接排除 footway、cycleway、path、steps 等非机动车道类型 -- 这些类型在 OSM 原始数据里很常见不排除会把路网密度统计抬高 -- 类级字段是处理时映射的若你的数据里没有这个字段 -- 退回使用原始 OSM 的 highway 字段筛选 -- WHERE highway IN (motorway,trunk,primary,secondary,tertiary,unclassified,residential)筛选这一步看着简单但有一个细节OSM 原始数据里residential居住区道路和unclassified一般等级未分类道路数量非常大它们在城市道路统计里通常算作支路级别。如果你在计算路网总里程时把它们排除结果会比真实值少很多。要不要包含这两类取决于你的分析目标——如果做“机动车可通行总里程”建议包含如果只统计“县级以上道路里程”则排除。4.2 拓扑建网把可视化的线变成可计算的路网处理过的数据虽然已经断链但在导入 PostGIS 之后还需要一步动作——构建拓扑网络。PostGIS 的pgr_createTopology函数用来生成路网的节点和连接关系给最短路径分析做准备。-- PostGIS 路由分析前必须执行的拓扑构建 SELECT pgr_createTopology(zz_roads_motor, 0.0001, geom, id); -- 参数说明 -- 第一个参数是表名第二个参数 0.0001 是容差单位与坐标系一致这里是米 -- 0.0001 米容差意味着距离 0.1 毫米内的节点会被合并这个值对处理过的数据足够 -- 第三个参数是几何列名第四个参数是主键列名 -- 拓扑构建完成后表里会多出 source 和 target 两列记录每条线的起终点节点 ID执行完拓扑构建你可以立刻做一个连通性检查-- 找出孤立的道路子网不能从主路网到达的部分 SELECT count(*) FROM ( SELECT DISTINCT source FROM zz_roads_motor WHERE source NOT IN ( SELECT target FROM zz_roads_motor ) ) AS isolated_nodes; -- 如果结果接近 0说明路网连通性良好如果几百上千说明数据存在问题 -- 不过注意城市路网中确实存在“飞地”路段比如被铁路隔断的局部支路拓扑构建失败或者连通性差多半是因为容差设置不当。容差太大会把近在咫尺但不相连的道路错误合并容差太小断链处没接上后续路径规划就会绕远路。处理过的数据已经断链容差可以设得比较小0.0001 到 0.01 之间是常用区间。4.3 网格化统计1公里网格内的路网密度计算做城市规划分析路网密度是绕不开的指标。处理后的路网数据可以直接拿来计算把研究区分成 1km x 1km 的网格统计每个网格内的道路总长度。-- 生成网格并计算路网密度米/平方公里 CREATE TABLE zz_grid AS SELECT (ST_PixelAsPolygons(ST_SetValues( ST_AddBand(ST_MakeEmptyRaster(50, 50, ST_XMin(ST_Extent(geom)), ST_YMin(ST_Extent(geom)), 1000, 1000, 0, 0, 4547), 1, 0))) ).geom AS grid_geom FROM zz_roads_motor; -- 上面这段生成 1km 网格比较复杂我实际更常用 QGIS 的创建网格工具 -- 矢量 - 研究工具 - 创建网格网格类型选择多边形宽度/高度设为 1000 米 -- 高级直接用 ST_Subdivide 或 Bbox 方式按已知研究区边界生成网格网格生成后用空间连接统计每个网格内的道路总里程-- 空间连接统计道路长度 CREATE TABLE zz_grid_density AS SELECT g.id, g.grid_geom, COALESCE(SUM(ST_Length(ST_Intersection(r.geom, g.grid_geom))), 0) AS road_m FROM zz_grid g LEFT JOIN zz_roads_motor r ON ST_Intersects(r.geom, g.grid_geom) GROUP BY g.id, g.grid_geom; -- 说明 -- ST_Intersection 会精确切割道路落在网格内的部分再统计长度 -- 这样避免了整条道路跨越多个网格时在多处重复计算的问题 -- COALESCE 把没有道路的网格记作 0而不是 NULL -- 最后 road_m / 1000 / (1km*1km) 得到公里/平方公里的密度值这个统计在 ArcGIS 里可以用“空间连接-求和”直接达成但 PostGIS 的 SQL 方式好处是结果可复现——你在脚本里留下公式以后换城市、换数据源只要改表名就能重跑。我做这类分析时永远不会用 GUI 操作完就交付因为半年后回溯时需要能回答“这个数字是怎么来的”。5. 避坑指南OSM数据处理的5个高频坑数据处理和分析做了这么多年见过的问题五花八门。这里挑 5 个最常见的坑按“现象 → 原因 → 解决”的方式记录希望你能少走点弯路。5.1 坐标系搞错叠加天地图底图全偏现象把路网数据拖进 QGIS叠加在线天地图后发现道路与卫星影像中的道路错位了几百米而且偏差方向不固定。原因OSM 原始数据是 WGS84 经纬度在叠加 Web 墨卡托底图时被直接当作 Web Mercator 投影的平面坐标使用坐标数值没变但单位被错解成米导致数据被“压扁”在错误位置。解决拿到任何 OSM 数据的第一步永远是确认坐标系定义不要相信文件名的“已处理”字样。检查方式图层属性里看坐标系是否明确用信息工具点击道路查看坐标值——如果坐标值在 113 左右的经纬度说明还是 WGS84如果坐标值在几千上万米制确认是投影坐标系。确认是 WGS84 后用“重投影图层”转到目标投影坐标系再做分析。5.2 中文路名字段显示乱码现象属性表里打开道路名称字段中文全部显示为“锟斤拷”或者方框乱码英文和拼音正常。原因处理数据时把 GBK 编码的 CSV 或 Shapefile 的 dbf 文件当成 UTF-8 读取或反过来。OSM 原始数据的 name 字段在社区编辑中大量使用中文势必涉及编码处理。常见的坑是对 Shapefile 的 dbf 头文件里的语言驱动标识处理不当。解决如果数据是 GeoJSON 或 GPKG直接用 QGIS 打开一般没问题如果是 Shapefile在 QGIS 中选择图层时要注意编码选项手动指定 UTF-8 或 GBK 重载。更省心的方法在 PostGIS 里读一次数据统一让数据库管理编码应用程序从数据库读取就不会有编码问题。5.3 立交桥断链导致路口拓扑异常现象路网在其他地方都正常唯独在互通立交、高架桥区域出现大量断头做路径规划时车辆会“飞”上去或者无法上下匝道。原因OSM 对立体交叉的处理思路是画多条平面线段用layer或bridge标记上下层关系但处理时如果没有把layer字段纳入断链逻辑匝道和主路的上下层线段就会被错误地做立体连接或者反过来该连接的地方没连上。解决处理数据时给匝道、桥面加空间属性特征区分断链时先按layer标签区分层级再在同一层内打断。拿到处理后的数据时检查立交桥位置是否保留匝道口如果确实有断链手动在 QGIS 打开节点编辑模式修复或者用“拓扑检查器”插件扫描批量修复所有 source/target 不匹配的悬挂节点。5.4 道路分级字段缺失一条路“身份不明”现象用“道路等级”筛选时发现很多道路没有等级字段统计里程时分不到任何等级类别里结果偏低。原因OSM 原始数据中大量highway标签缺失或用了非标准值比如highwayroad表示“不知道是什么路”处理时映射表没有兜底规则这些路就被丢弃了。解决处理时对这类道路采用“未知等级 → 支路”的兜底映射保证所有机动车道都归入可统计的等级框架。拿到数据处理后先检查有没有“未知”或“未分级”的类别数量别超过总长度的 5%。如果超过在分析报告里把这个比例写清楚这是诚实的数据态度。5.5 面积/长度统计失真——投影坐标系的选择陷阱现象用 EPSG:3857Web Mercator做面积统计结果比真实值大了 20% 以上做缓冲区分析缓冲区形状在视觉上是圆形的但实际面积远不是理论值。原因Web Mercator 是等角投影在高纬度地区面积变形极其严重。郑州虽然在中纬度但面积变形仍然不可忽略——在 34.7°N 纬度上Web Mercator 的面积膨胀约 1.7 倍到 2 倍。解决核心原则——量算和统计分析一律用高斯投影EPSG:4547或 UTM 投影郑州对应 EPSG:32650。Web Mercator 只用于屏幕显示。我自己的项目里所有计算结果输出部署前都会用投影坐标系重算一遍把“显示坐标系”和“分析坐标系”严格分离。6. 进阶技巧用空间索引把百万级道路数据的查询压到秒级处理后的郑州路网数据量虽然不算巨大但做城市级分析时总免不了叠加、缓冲区、空间连接这些高开销操作。空间索引用好了性能提升按数量级计算。6.1 构建空间索引-- PostGIS 中给道路表创建空间索引 CREATE INDEX idx_zz_roads_geom ON zz_roads_processed USING GIST (geom); -- 说明 -- GIST 索引专门用于空间数据配合 ST_Intersects、ST_DWithin 等操作符 -- 创建后可以立刻对比查询时间 -- SELECT COUNT(*) FROM zz_roads_processed WHERE ST_Intersects(geom, ST_GeomFromText(...)) -- 索引建好后第一次查询仍可能较慢第二次开始显著提速不要指望空间索引在建完后所有操作都变快——它的本质是缩小“参与运算的候选集”。道路数据越多索引加速越明显。如果 PostGIS 做叠加分析仍然慢可以尝试用 ST_Subdivide 把长线段切碎让每个小块进入独立索引范围。6.2 用SQL完成道路缓冲区的批量生成-- 给所有快速路生成 50 米缓冲区用于分析道路两侧用地 CREATE TABLE zz_roads_buffer AS SELECT id, ST_Buffer(geom, 50) AS buffer_geom FROM zz_roads_processed WHERE 类级 IN (快速路, 主干道); -- 参数说明 -- ST_Buffer 的第二个参数是缓冲半径单位与坐标系一致这里是米 -- 注意在 EPSG:4547 下 50 米就是 50 米但如果在 EPSG:3857 下做缓冲区 -- 实际空间范围会因投影变形产生误差务必先确认坐标系 -- 批量缓冲后建议检查生成的缓冲区是否有自相交情况缓冲区生成后有一步很多人会忽略检查生成的缓冲区几何是否有效。ST_IsValid 可以排查对无效要素做 ST_MakeValid 修复。这是防止后续叠加统计时报错的关键步骤。6.3 交叠道路的拓扑校验与修复处理后的数据偶尔也会有遗漏尤其在 OSM 社区最近更新的区域。做网络分析前跑一遍全库自相交检查是有必要的。-- 找出自身相交的道路 SELECT a.id, ST_Intersection(a.geom, b.geom) AS intersect_geom FROM zz_roads_processed a, zz_roads_processed b WHERE a.id b.id AND ST_Intersects(a.geom, b.geom) AND ST_GeometryType(ST_Intersection(a.geom, b.geom)) IN (ST_Point, ST_MultiPoint); -- 如果结果里只有“点”说明是正常的十字交叉或立交 -- 如果出现 LineString 类型的相交说明两条线有重叠段需要合并或修正 -- 修复重叠段用 ST_LineMerge 合并同一道路的重叠线 UPDATE zz_roads_processed SET geom ST_LineMerge(geom) WHERE ST_IsValid(geom) false;我的习惯是跑完修复再补一次ST_IsValidDetail看错误类型和位置批量导出错误要素到单独图层人工抽查一遍。数据质量不是一次检查能保证的尤其是 OSM 这种众包数据在月度更新后务必重新跑一遍拓扑校验。希望这个工作流能帮你在郑州路网数据上少踩几个坑。本文还有配套的精品资源点击获取