2005年全国路网矢量数据清洗与坐标系转换实战指南

简介：覆盖全国范围的矢量地理数据合集，汇集道路、河流、铁路等多类要素，专为GIS使用者打造，适用于城市规划、交通分析、环境研究与历史变迁对比等场景，尤其适合需要借助ArcGIS进行空间查询、制图和专题分析的读者。包内为RAR压缩包，共161个文件，大小约11.25MB；其中包含22套shapefile标准要素文件（shp/shx/dbf及prj投影定义、sbn/sbx空间索引），还有GRID栅格数据（adf/001）、XML元数据、mxd地图文档等，可直接加载到ArcGIS中开展多尺度地图工作。内容聚焦2005年全国铁路网与路网矢量信息，涵盖高速铁路、普速铁路及各级公路的位置、等级与几何形态，是历史路网回溯、区域通达性评估和交通设施规划的可靠底图。目前已有2567人浏览学习，配合清晰的目录结构可快速定位所需图层，适合城市规划、地理信息相关专业师生及从业者作为基础数据使用。

1. 2005年全国路网矢量数据：一份有年代感的“全国底图”

做GIS的人迟早会被问到一句：你有没有全国的道路、铁路、河流图层？我手上常年放着一份2005年全国矢量数据图大全，里面叠着国道、省道、县乡道、铁路、河流和境界，道路河流铁路等要素分得清清楚楚。数据本身不新鲜，但它的价值恰恰在于“旧”——带时间断面的路网、老式字段命名、一堆还在用北京54坐标系的shp文件，刚好适合做历史对比、现状底图、流域模型前处理。适合三类人：搞规划的要做路网演变分析，做水文模型的要抠河网，还有被要求“三天内上线一张全国路网地图”的。后面所有操作都基于这套老数据展开，绕不开坐标系、编码和几何类型三个老问题。

2. 解包先清点：图层、字段与数据现状

2.1 解压后先认清图层划分

2005年的全国路网数据包，常见格式是压缩包解压后一堆Shapefile，偶尔混着E00交换格式和MapInfo的MIF/TAB。文件名不统一是常态，但图层划分有规律。道路层有时是一个总文件ROAD_L，有时按等级拆成ROAD_1、ROAD_2、ROAD_3；铁路层通常是RAIL_L加一个火车站点层RAIL_STATION_P；河流层分单线河RIVER_L和双线河RIVER_A，前者是线，后者是面；境界和居民地也会单独成层。

这个划分逻辑和现在的OSM路网风格不一样，它是按当年制图规范走的，核心是“分类分级”，不是“每个要素一个ID”。收到数据先别急着拖进QGIS，用命令行清点一遍，搞清楚这个包里到底有几层、每层多少要素、是点线还是面。

# 循环读取目录下所有Shapefile的图层概要，输出到data_inventory.txt for f in *.shp; do echo "===== $f =====" ogrinfo -so "$f" "$(basename "$f" .shp)" done > data_inventory.txt

-so参数表示只输出概要，包含要素数量、几何类型、字段列表。basename命令把“road.shp”去掉后缀变成“road”，因为ogrinfo要用图层名。跑完打开data_inventory.txt，你就能看到哪些是我们要的，哪些可能是附属的注记点。这个过程花两分钟，能避免后面对着错误图层白干半天。

常见图层对应关系可以按下面这个表去理解，真碰到名字不一样时心里有个底：

2.2 属性字段：哪些能直接用、哪些要小心

清点完图层，下一个任务是读属性表。2005年这一代数据的属性字段名普遍很短，经常是“GC”“CLASS”“NAME”“CODE”这种。道路层你要找等级字段，国省县乡四级通常编码为1/2/3/4或G/S/X/Y。铁路层关注“单线/复线”和“电气化”两个字段。河流层最重要的是NAME，但流向信息不一定有。

麻烦的是，Shapefile的dbf格式对字段名长度有限制，很多字段被截断成10个字符，有的数据商干脆把一堆说明塞进一个REMARK字段里，用分号隔开，读取后要自己拆。更常见的问题是中文乱码，这个后面避坑章节专门讲。先用一个Python脚本快速摸清每个字段的取值分布：

import geopandas as gpd # 读取道路层，如果中文乱码就把encoding参数从默认改成gbk再试 road = gpd.read_file("2005_road.shp", encoding="gbk") # 逐列打印唯一值数量和一条样例，快速判断哪些字段适合做分级和过滤 for col in road.columns: sample = road[col].dropna().iloc[0] if road[col].notna().any() else "NA" print(col, "unique=", road[col].nunique(dropna=True), "sample=", sample)

这段代码的价值在于快速区分“分类字段”和“标识字段”。如果某个字段只有三五个唯一值，多半是等级或类型，可以直接用来做分级渲染；如果每个要素都不同，那大概是ID或名称。打印sample能让你看到字段内容是不是乱码、是不是被截断。我一般跑完这个脚本，再head一下前五行，对数据的“脾气”就有数了。

2.3 数据现状三查：几何类型、坐标系、空值

清点完字段，动手前还要做三查：一查几何类型，二查坐标系，三查空值和无效几何。这三项决定后面能不能顺利转格式、叠加、分析。

import geopandas as gpd road = gpd.read_file("2005_road.shp", encoding="gbk") print("CRS:", road.crs) print("几何类型:", road.geom_type.unique()) print("空几何数量:", road.geometry.isna().sum()) print("无效几何数量:", (~road.geometry.is_valid).sum())

打印出来的几何类型如果同时出现LineString和MultiLineString，说明制图员在编辑时把同一道路的多个路段合并成了Multi，这会影响后面按要素统计长度和做网络分析。空几何数量大于0说明原始数据有坏记录，需要先删或补。无效几何多数是自相交或悬挂点，用QGIS的“修复几何”工具可以批量处理。坐标系这一项最关键，CRS如果显示None或EPSG:4326，要警惕——很多2005年的数据实际是北京54投影，但PRJ文件丢了，读出来显示WGS84，这就是坐标错位的根源。

提示：这三查做完，把结果和文件名、日期一起存成一个文本，作为这次数据处理的基础记录。后续所有转换和发布环节都以这份记录为准，不要凭记忆。

3. 坐标系统一：从北京54到WGS84的转换参数与验证

3.1 为什么2005年数据会混着三套坐标系

2005年正好是坐标系统混乱期的尾声。八十年代以前大量成果用北京54，九十年代以后新测的用西安80，国际合作项目又转成WGS84。所以这份2005年路网数据，如果一个包里混着三套坐标系，一点都不奇怪。

北京54和西安80不是简单平移关系，它们用的椭球参数不同，转换需要至少三个公共点求七参数，而且没有公开统一参数。GDAL里直接做椭球变换时，默认towgs84参数是0,0,0，等于几乎不转，转换后坐标和源坐标差不了多少。这就是为什么很多人发现“转了等于没转”，或者转了之后偏差反而更大。

更麻烦的是分带问题。北京54下全国道路数据通常按高斯克鲁格3度带存储，带号选错，转换结果不会变形，而是整体平移几十公里甚至上百公里。我见过最典型的翻车：用某一个3度带参数转全国数据，转完范围只剩河北一角，东西部全飞了。所以在动手转坐标系之前，先搞清楚源数据和带号，比什么都重要。

3.2 批量查询SRS并转成EPSG:4326

转换前先确认每个文件的SRS。有PRJ文件时GDAL能自动读，但PRJ文件经常乱码或缺失。用ogrinfo查每个图层的SRS描述最可靠：

# 查看道路和河流的投影信息，确认是投影坐标还是经纬度 ogrinfo -so 2005_road.shp 2005_road | grep -i "SRS\|GEOGCS\|PROJCS" ogrinfo -so 2005_river.shp 2005_river | grep -i "SRS\|GEOGCS\|PROJCS"

输出里如果看到Krasovsky、Gauss_Kruger字样，就是北京54投影坐标；看到GCS_Beijing_1954说明是北京54经纬度；完全没有SRS信息的，多半是裸shp。对于裸shp，先看坐标范围：如果范围是经纬度数值，比如经度75到135、纬度18到54，说明它实际是经纬度数据，只是丢了定义。这时用-a_srs强制声明：

ogr2ogr -overwrite -a_srs EPSG:4326 -t_srs EPSG:4326 road_wgs84.shp road_noprj.shp

-a_srs是“分配源坐标系”，只给没有PRJ的文件用，它有PRJ时再写会覆盖原定义。确定源坐标系正确后，正式转WGS84：

# 将北京54投影的2005年道路数据转成WGS84经纬度 ogr2ogr -overwrite -s_srs "EPSG:21413" -t_srs "EPSG:4326" 2005_road_wgs84.shp 2005_road.shp

这个=s_srs=EPSG:21413是北京54/3度带第13带，适用于东经117度附近的区域，其他区域要按实际经度换带号。如果你手里是全国拼接版，建议直接用“先投影坐标转经纬度再统一拼接”的思路：每个分带文件转成4326后再合并，不要在投影坐标下直接拼接。

3.3 转换后如何量化验证偏移

转完不能只看坐标变了就收工。验证分三步：范围、叠合、距离。

先把转换后的坐标范围打出来：

# 查看转换后的坐标范围，与全国经纬度范围做快速核对 ogrinfo -so 2005_road_wgs84.shp 2005_road_wgs84 | grep -i "Extent"

全国范围经度应在75到135、纬度在18到54之间。如果范围只覆盖一个局部区域，说明-s_srs的带号选错了。如果范围看起来正常，再用叠加或距离的方式细验。

有参考图层时，用GeoPandas计算转换后数据与参考数据的最近距离，中位数能反映整体偏移量：

import geopandas as gpd # 转换后的道路线 与 一份可信的WGS84省界线比较，看质心偏移 road = gpd.read_file("2005_road_wgs84.shp") ref = gpd.read_file("province_wgs84.geojson") print("道路质心:", road.unary_union.centroid) print("参考质心:", ref.unary_union.centroid)

质心差在0.5度以内可以接受，超过1度基本就是坐标系搞错了。没有参考图层时，至少在QGIS里叠加一张在线影像，选三个不同位置的点放大看道路是否贴合。肉眼看着差几十米到一百米，属于椭球转换的正常残留；差几百米以上，就要回头检查源坐标系声明。

3.4 为GeoServer统一存储坐标系

如果你要把这套路网发布出去，GeoServer这条线提前规划。GeoServer发布矢量数据最常见的问题，就是“原生坐标系”和“声明坐标系”不一致导致切片错位。

建议的统一策略是：所有2005年路网数据入库前转成EPSG:4326，GeoServer里只对应选EPSG:4326，前端瓦片请求时再让GeoServer自动重投影到EPSG:3857。新建Shapefile数据源时，如果PRJ缺失，必须在“声明坐标系”里手动选，不能让它显示unknown。发布图层时，“原生SRS”和“声明SRS”要一致，这个细节漏了，切片错位就跑不掉。

入库后要检查每层的坐标范围：在GeoServer的图层预览页里，如果看到范围是负数或极小矩形，说明SRS声明错了，千万别点发布。另外，矢量数据发布服务不是越新越好，存储统一、SRS明确、字段精简，才是长期稳定的基础。

4. 从Shp到业务数据：GeoJSON、ArcSWAT与拓扑修复

4.1 转GeoJSON前的三个考量

把2005年老数据转成GeoJSON，是前端可视化和跨平台交付的高频操作。动手前想三件事：编码、字段、坐标精度。

Shapefile的dbf对字段名有长度限制，中文列名也常出问题。GeoJSON没有字段名长度限制，但字段名别带空格和特殊符号，否则前端JS读取要额外处理。编码方面，dbf常是GBK，GeoJSON固定UTF-8，转换时要把源编码指对。

坐标精度也别无脑保留十几位小数，全国数据几十万要素，每一个坐标多几位，文件体积成倍涨。经纬度保留6位小数，实际精度约0.1米，足够做路网显示和大部分分析。转换命令如下：

# 转GeoJSON：输出RFC7946标准，限制坐标小数位为6 ogr2ogr -f GeoJSON -lco RFC7946=YES -lco COORDINATE_PRECISION=6 road.geojson road_wgs84.shp

RFC7946=YES表示输出标准GeoJSON，坐标顺序是经度在前。不写这个参数时GDAL输出的是老版GeoJSON，大多数前端库能读但格式不完全符合新规范。COORDINATE_PRECISION=6控制输出坐标小数位，对文件体积影响非常明显。如果源文件的属性是GBK编码，转换前记得设置环境变量：

# 强制按GBK读取源dbf，避免转出来的中文变成问号 export OGR_ENCODING=GBK ogr2ogr -f GeoJSON -lco RFC7946=YES road.geojson road_wgs84.shp

注意OGR_ENCODING影响的是输入读取，不影响输出；源文件本身就是UTF-8时不要再设这个变量，否则会二次转码出乱码。

4.2 拓扑问题怎么处理：省界断线与悬挂点

全国路网数据跑不掉两个拓扑毛病：省界缝合线、断头路。同一条国道，相邻两省各画一遍，拼接处两条线没有合在一起，重叠部分造成长度重复统计。还有一种情况是道路明明连成一条，属性里被切成几十个线段，线头线尾差几米没接上，做网络分析时直接断网。

处理思路是先合并再打断。QGIS里可以用“修复几何”处理无效几何，但全国级路网几条万条数据，桌面工具卡到怀疑人生。我一般导到PostGIS里用ST_Node重建拓扑：

-- 把全部线段合并后打散，生成节点完全相交的线网络 CREATE TABLE road_noded AS SELECT (ST_Dump(ST_Node(ST_Collect(geom)))).geom AS geom FROM road_raw;

ST_Collect把所有线段收集成一个MultiLineString，ST_Node在相交处加节点打断，ST_Dump把打散的MultiLineString展开成多行单线。这个操作会丢失原始属性字段，所以做之前先把FID和道路等级、名称备份到另一张表，打断后通过空间位置把属性连接回来。

如果不需要做网络分析，只是统计路网长度，可以考虑直接用原始线做Dissolve加属性统计，省去打断这步。但如果要跑最短路径或做连通性分析，ST_Node这步不能省。

4.3 ArcSWAT前处理：河流线、DEM坐标系、唯一ID

ArcSWAT做小流域分析要用什么矢量数据，几乎每个入门的同学都问过。官方要的其实是三样：DEM必选，河流、土地利用、土壤等可选。2005年路网里的单线河数据，正好适合做河网参考，用来做burn-in让SWAT把实际河道刻进DEM。

但这里有三个硬性要求。第一，河流线必须和DEM使用相同的投影坐标系，ArcSWAT不认经纬度。第二，河流范围不能超出DEM范围，超出部分会报错或产生无效河网。第三，每段河流必须有唯一ID，重复FID会导致流域划分混乱。

先做投影和裁剪：

# 把单线河转成与DEM一致的UTM投影，裁剪到DEM边界范围内 ogr2ogr -t_srs EPSG:32650 -clipsrc dem_extent.shp river_utm_clip.shp river_utm.shp

EPSG:32650适合东经117到123度区域，其它纬度带和经度带要换带号。裁剪用-clipsrc参数，接收一个矩形范围或一个矢量图层，这里用DEM边界shp做裁剪，保证河流严格落在DEM内部。

ArcSWAT的burn-in输入还要注意一个细节：2005年河网数据往往很密，直接全量导入会让SWAT生成的子流域边界被密河网“撕碎”。建议先按属性或长度筛选出主干河流，比如双线河对应的单线河、长度大于阈值的主河道，去掉季节河和细支流，再进SWAT。这个筛选用QGIS按属性选择导出就行。

5. 常见问题与避坑：坐标系错位、乱码与几何类型翻车

5.1 属性表中文乱码

现象：QGIS打开shp属性表，中文全变成“锟斤拷”或问号；GeoJSON加载后名称字段显示乱码。

原因：2005年数据的dbf属性多采用GBK/ANSI编码，而QGIS、GeoPandas默认按UTF-8读取。GeoJSON输出端固定UTF-8，输入源编码没指定就全乱了。

解决：读取时显式声明源编码。GeoPandas用read_file(..., encoding="gbk")，QGIS在数据源管理器里把编码从UTF-8改成GBK重新连接。命令行做转换时先export OGR_ENCODING=GBK再执行ogr2ogr。已经转坏的文件别靠“再存一次”修复，回到原始shp重新转，或者用字段计算器从原始dbf重新读一次。

5.2 道路与铁路叠合偏差几百米

现象：国道和铁路在图上明显平行或共线，叠加到遥感影像后横向差几百米。

原因：道路和铁路图层来自不同坐标系版本。典型的组合是道路层是北京54高斯投影，铁路层是西安80投影，两个椭球差异在部分地区能到200米。还有人把丢失PRJ的图层强制当成WGS84用，偏差更大。

解决：两个图层统一转到同一坐标系再叠加。转换后如果仍差几十米，且你有野外控制点，就在QGIS里用配准工具或Vector Bender做局部纠正。不要试图用“图层平移”解决问题，平移只处理固定偏移，坐标系差异在空间上是不均匀的。

5.3 全国图层分析和渲染卡死

现象：对全国路网做缓冲区或叠加分析，QGIS转圈不动，内存占用飙到几个G。

原因：数据量大、没有空间索引、几何类型混杂。全国道路线要素动辄几十万条，桌面软件直接拿去计算，内存和CPU全被吃满。

解决：先转成GeoPackage并建索引，再考虑用数据库扛。GeoPackage默认带空间索引，加载和分析都比shp快很多。更重的分析用PostGIS：

# 把Shapefile导入PostGIS，自动创建空间索引并统一几何类型为Multi ogr2ogr -f PostgreSQL PG:"dbname=gis user=postgres" road.shp -nlt PROMOTE_TO_MULTI -lco SPATIAL_INDEX=YES

PROMOTE_TO_MULTI把所有线统一转成MultiLineString，避免同一个图层里几何类型混合导致SQL报错。导入后确认索引存在：

CREATE INDEX ON road USING GIST (geom);

如果Node数太多，可以用ST_SimplifyPreserveTopology做适当化简，山区道路节点密集处效果明显，拓扑关系不会破坏。

5.4 LineString和MultiLineString混乱

现象：处理时报“几何类型不匹配”，或者统计长度时某条路长度异常。

原因：制图人员把同一条路的多个线段合并成了MultiLineString，或反过来把原本的整段路拆成多个单线要素。两种类型混在同一图层里，不少分析工具会直接拒绝。

解决：统一转成单一LineString：

# 将MultiLineString展开为单个LineString要素，属性会复制到每段 ogr2ogr -nlt LINESTRING road_clean.shp road_raw.shp

-nlt LINESTRING强制输出为单线几何，MultiLineString会被拆成多条LineString，属性跟着复制到每段。副作用是原一个要素可能变多段，按名称统计时要先Dissolve。如果只是做长度统计，用SQL的ST_LineMerge更合适，不破坏原有属性关系。

5.5 GeoServer发布后切片错位

现象：GeoServer加载全国路网，浏览器里显示的位置和底图差一大截，放大后越偏越远。

原因：图层数据源的“原生坐标系”设置错误，或前端请求的坐标系与发布坐标系不一致。常见的是源shp丢PRJ后，在GeoServer里没手动声明坐标系，默认当成了EPSG:4326或WGS84。

解决：在GeoServer的“图层 → 数据”页面，确认“原生SRS”和“声明SRS”一致。如果源数据是北京54，原生SRS要先声明成对应的EPSG:214xx，再在“定义SRS”里添加EPSG:4326用于发布。强烈建议发布前把数据统一转成EPSG:4326入库，让GeoServer只做重投影，不从错坐标系硬转。

6. 进阶：用等级宽度把旧路网缓冲成道路面

老路网数据在浏览器里默认渲染成细线，前端想画成按等级区分宽度的“道路面”，最常见做法是把中心线缓冲成面。“GeoJSON高精度路网数据制作道路面”这件事，关键不在工具，而在每一级道路到底给多少缓冲宽度。缓冲宽度定得合适，叠加到卫星影像上能看出高速公路和乡村道的区别；定得太宽，道路旁边的房子全被包进去。

高速公路、国道、省道、县道、乡道五档，我常用的宽度从30米、20米、15米、10米、6米递减。注意这个宽度不是路面实际宽度，而是中心线向两侧各扩一半得到的整体宽度，适应显示比例尺和分析精度。GeoPandas几行代码就能生成：

import geopandas as gpd road = gpd.read_file("2005_road.geojson") # 按道路等级字段映射缓冲半径，单位米 width_map = {"G": 15.0, "S": 10.0, "X": 7.5, "Y": 5.0} road["buf"] = road["level"].map(width_map).fillna(5.0) # 缓冲生成道路面，坐标系必须是投影坐标系，经纬度下单位不生效 road_face = road.geometry.buffer(road["buf"]) road_face = gpd.GeoDataFrame(road[["name", "level"]], geometry=road_face) road_face.to_file("road_face.geojson", driver="GeoJSON")

这里最容易踩的坑是坐标系：经纬度数据直接buffer，宽度会被当成度，10度宽的“道路面”能覆盖半个市。所以做缓冲之前，先投影到UTM或其它投影坐标系，buffer的宽度单位才是米。生成道路面后，建议导出GeoPackage而不是GeoJSON，几十万条面要素的GeoJSON文件体积会大得离谱，前端加载卡成幻灯片。

验证方法不复杂，选两个不同地形区的县级市，用最新卫星影像叠加道路面，看面是否贴合真实路幅。山区道路弯道处如果出现锯齿或内切，适当降低缓冲宽度；平原高速如果被建筑包围，可以把宽度调到实际路幅的一半再验一次。做这套流程时，我养成的习惯是拿到任何老数据，第一件事永远是看坐标系和编码，这两个坑填平了，后面基本不会再翻车。希望这套处理流程能帮你把2005年这份路网数据真正用起来。

本文还有配套的精品资源，点击获取