企业官网建设流程全解析

简介：西藏路网矢量数据（WGS84坐标系）是面向ArcGIS用户的GIS基础数据集，覆盖城市道路、国道、省道、高速公路等多级路网，2021年版本可反映最新交通状况，适合地图制图、交通规划、路网分析与科研教学。数据包为zip压缩格式，共5个文件、约16.14MB，其中shp保存道路几何要素，dbf关联道路名称、等级等属性记录，prj记录WGS84投影信息，shx用于快速检索空间索引，xml提供元数据说明，各文件配套使用，在ArcGIS中可直接加载，完成地图可视化、要素查询、网络分析和叠加分析等操作。目前已有348人浏览学习，适合GIS专业学生、测绘工作者及交通领域研究人员使用。数据除空间位置外，还详细包含道路长度、宽度、类型、等级及连接节点等信息，便于按行政区域或道路等级筛选统计；也可与往年数据对比分析路网扩展趋势，或叠加人口、地形等图层，探讨交通与社会经济、自然环境的关联，为规划决策提供支撑。

1. WGS84坐标系的西藏路网数据，拿来就用的第一个晚上我就踩了坑

去年做一个区域路网分析项目，拿到一份2021年的西藏路网矢量数据，属性表里城市道路、国道、省道、高速公路分得清清楚楚，我甚至觉得这份数据可以直接用。结果把它拖进 QGIS 叠加卫星影像，整层路网和影像横向错开接近半公里，那一刻我意识到一个问题：一份写着 WGS84 坐标系的数据，坐标值未必真是 WGS84；即便坐标系没被动手脚，2021 年的通车状态放到今天也可能已经过时。这正是这篇要写清楚的事——西藏路网矢量数据的坐标系怎么验证、道路等级怎么拆分、拓扑断裂怎么修，以及合并使用和路径分析时会遇到的坑，希望能帮到你。

2. 先拆数据底细：道路分层逻辑、属性字段和西藏路网的特殊性

2.1 道路分层：城市道路、国道、省道、高速公路在属性表里怎么认

拿到 SHP 文件的第一件事，不是看地图，而是打开属性表。你用 QGIS 拖入图层后，右键图层选「打开属性表」，重点看两个字段：一个描述道路类别，一个存道路编号。我经手过的西藏路网数据里，type 字段的命名习惯不完全一致，常见取值包括 motorway、trunk、primary、secondary、residential，也有直接写中文「高速公路」「国道」「省道」「城市道路」的版本。字段名也可能叫 fclass、type、kind、level，先按数值分布确认实际分类。

这里要注意，不标注 motorway 不代表它不收费。西藏的国道很多路段线型好、车速快，但属性仍是 trunk；而部分城市快速路在数据里也可能标成 trunk。所以做按等级拆分前，先统计 type 字段的唯一值，确认数据生产方的分类口径，不要凭印象猜。ogrinfo可以直接从命令行看唯一值，后面章节会讲。

拿到字段后，我建议给道路图层做分级符号化：高速用红色实线、国道用黄色、省道用蓝色、城市道路用灰色。这一步不只是在视觉上舒服，它能让你快速看出数据在哪些区域密集、哪些区域明显缺失，比如一个县城周边只有 residential 没有 trunk，说明连接线数据可能没入库。

2.2 西藏路网的数据特征：从图形上读出来的地理逻辑

西藏的路网和内地省份有一个本质区别：路网密度极低，但单条线段跨度极大。打开整体视图你会看到，路网呈明显的树枝状，主干线沿河谷和山间盆地展开，支线像毛细血管一样向两侧延伸到一个点就结束，后面是大片无路区。这意味着处理断裂拓扑时，一段国道上一个 20 米的缺口，在数学上就把整个网络切成了两块，这是后续路径规划里最隐蔽的问题。

另一个特点是城市道路高度集中在少数几个城镇节点，城区路网呈团块状，团块之间用国道和省道连接。中间经过的高海拔垭口路段，线型往往比较平直，因为那是沿着高原面走，而不是沿峡谷盘绕。你在做简化抽稀的时候，对这些长直路段的抽稀阈值可以放得比内地更宽，不容易丢形状。

还要留意道路通行状态字段。西藏有大量季节性通车路段，冬天积雪封路是常态，但 2021 年的数据未必能反映这个动态。数据里如果有 surface 字段（铺装类型），gravel/unpaved 占比会比其他省份高；如果有 access 字段，部分地区会标 no（冬季封闭）。如果你打算做全年可用的路径规划，最好把这些季节性路段的通行权重调低，而不是直接删掉——夏季它是通的。

2.3 2021 年的数据到现在，哪些地方可能已经变了

2021 年这个时间戳决定了数据的时效边界。过去几年的道路建设速度很快，尤其是连接重点城镇和口岸的新通道，以及高速公路的延伸段，这些很可能不在数据里。用的时候要有预期：数据缺失的路段会表现为道路网络在某处突然中断，而中断点经常出现在城镇外围几公里处，那里往往是新建连接线的位置。

怎么核实时效性？我的建议是抽样而不是全量。挑十来个分布在不同方向的点位，把路网叠加到较新的卫星影像上，检查影像上明显存在的道路在矢量数据里有没有对应线。更简单的方法是把这份路网和你手机里的在线导航数据做对比——但要小心坐标系，多数在线导航底图是加密偏移过的，直接叠上去整体错位，你会误判成数据质量问题。正确做法是只对比「道路是否存在、走向是否一致」，不要对比空间位置重合。

如果拿来做底图展示，2021 年的数据在大部分区域完全够用；如果拿来做实时路径规划或里程核算，就要先补齐新建路段，或者用更新年份的数据做融合。这里没有"能不能用"的绝对答案，只有「你的分析容忍度有多高」的问题。常见的判断标准是：偏离超过 5% 的路网缺失就要考虑补数据，否则统计结论会有偏差。

3. 加载与坐标系验证：先花三分钟确定这份 WGS84 数据到底歪没歪

3.1 用 ogrinfo 检查坐标系声明和数据范围

QGIS 里右键图层看属性，能读到坐标系信息，但我想给一个更硬核的验证路径：直接用 GDAL 的命令行工具。它对 SHP 内部真实存储的内容读取更底层，能避免 QGIS 做了可视化环节的掩盖。打开终端，进入数据目录后执行：

ogrinfo -so -al 西藏路网_2021.shp | grep -E "GEOGCS|PROJCS|EPSG|EXTENT"

这段命令里，-so表示只输出概要信息，-al表示遍历所有图层，grep把坐标系和数据范围的行筛出来。输出中你会看到类似 GEOGCS["WGS 84"]、DATUM["World_Geodetic_System_1984"] 这样的内容，说明坐标基准是世界大地测量系统 1984；如果出现 PROJCS 字样，说明实际是投影坐标系而不是纯经纬度。

同时看 EXTENT 行。WGS84 是经纬度坐标系，单位是十进制度，西藏的范围应该在东经 73 到 99 度、北纬 26 到 37 度之间。如果输出里出现的是 2510000 到 2790000 这种米制单位的大数字，说明这个数据被存储成了投影坐标，常见的是 UTM 分区或者凯尔文投影。这种情况经常被错误标记成 WGS84。

3.2 叠加影像做目视校验：整体偏移三四百米基本可判定坐标系被动过

命令行查完声明，接下来验证「声明」和「实际内容」是否一致。这个方法很朴素但很有效：在 QGIS 中加载一份坐标系可信的卫星影像底图，把路网图层叠上去，缩放到底图能看清道路的位置，目视检查路网中的道路线是否压在影像中的道路上。

如果看到的是整体偏移，而且偏移方向一致、距离在几百米量级，几乎可以断定这份数据的坐标值被人为加偏过，也就是常说的加密坐标。WGS84 和加密坐标之间的差值不是常数，但在一个城市范围内近似可看作整体平移。你可以在图上选几个特征明显的路口，对比影像坐标和路网坐标，记下差值，如果几个点的差值是稳定的几百米，基本就坐实了。

这里提醒一句：选底图时要确认底图本身的坐标系。某些在线影像服务用的不是 WGS84，叠加时要把底图先转换到 WGS84 再对比，否则你看到的错位可能是两个坐标系之间的系统差，而不是数据本身的问题。

3.3 坐标范围检查与投影参数误判

还有一种容易被忽视的情况：数据的存储坐标系是对的（WGS84 经纬度），但字段里的坐标值被写成了度分秒格式，而不是十进制度。这种情况下 QGIS 里能正常显示，但一旦导出或用于计算距离，数值会差一个量级。检查方法很简单，打开属性表看几何字段或导出为 CSV，如果经纬度类似 91°10'30" 这样的带度分符号的字符串，就要先用工具转换成十进制度。

坐标范围检查还有个用途：识别数据的空间范围是不是和标题一致。一份覆盖整个西藏的路网数据，EXTENT 应该是全区域的；如果你看到 EXTENT 只覆盖了很小的区域，说明数据被打过切片或者经过了裁剪。这种情况在做全区域统计分析时会产生明显偏差，需提前知晓。

如果确认数据声明 EPSG:4326 但实际坐标数值范围异常，可以用下面的命令强制按正确坐标系重写投影声明。注意，这只是在数据本身几何没有变形的条件下修复元数据，不是对偏移数据的矫偏：

ogrinfo -so 西藏路网_2021.shp | grep -i "epsg:4326" ogr2ogr -t_srs EPSG:4326 西藏路网_wgs84_fixed.shp 西藏路网_2021.shp

第二行命令把数据强制转换到 EPSG:4326。转换本身不会修复坐标值被加密的问题，它只是把投影描述改对。做这一步之前，务必确认数据源的真实情况，不然你可能把一个本该是 GCJ-02 偏移的数据从"声明错误"变成"声明正确"，反而更隐蔽。

4. 数据清洗与格式转换：从原始路网到可交付数据

4.1 按道路等级拆分：用 ogr2ogr 一次拆出四个图层

数据清洗的第一步是按道路类型拆分图层。拆分的目的是让每条数据的使用者只拿到需要的部分——做城市路网分析不需要国道，做区域交通规划不需要住宅区小路。拆分命令关键要匹配 type 字段的实际值，所以先列出所有唯一值：

ogrinfo -al -so 西藏路网_2021.shp | grep "type" | sort -u

确认字段值后，用下面这段脚本批量导出。假设数据里高速对应 motorway、国道对应 trunk、省道对应 primary、城市道路对应 residential：

for road_type in motorway trunk primary residential; do ogr2ogr -where "type='${road_type}'" \ -f "GeoJSON" \ 西藏路网_${road_type}.geojson \ 西藏路网_2021.shp done

这段脚本里，-where是 SQL 过滤条件，值来自前面查看的唯一值；-f "GeoJSON"指定输出格式。我选 GeoJSON 做中间格式是因为它在属性名兼容性上比 SHP 更宽松，后续转到其他平台都方便。拆分完成后，每个文件只包含对应等级的路段，后续处理互不干扰。

这里的参数值得说明：-where的字符串语法要严格匹配属性值的大小写，motorway 和 Motorway 会被当成两个不同值。如果数据里同时存在大小写变体，先统一字段值再拆分。另外，你也可以不用 for 循环，直接用 QGIS 的「按表达式提取」工具实现同等效果，但命令行方式好在跨机器可复现。

4.2 修复拓扑断裂：v.clean 参数怎么设才不至于把路网修坏

西藏路网最让人头疼的坑是拓扑断裂。典型场景：一条国道在某个路口处与省道相交，但两条线的端点没有落在一起，路径规划时车辆需要绕行很远处才能掉头。这个问题在数据里靠肉眼看往往不明显，而路径规划算法对它是零容忍。修复常用的工具有 GRASS 的 v.clean。在 QGIS 的处理工具箱里搜索 v.clean 即可，命令行方式如下：

v.clean input=西藏路网_2021.shp output=西藏路网_clean \ tool=break,rmdupl,rmsa,snap \ threshold=10.0 --overwrite

参数拆开看：tool=break在两条线相交处打断；rmdupl删除完全重复的线段；rmsa删除小角度伪节点；snap把距离小于阈值的端点吸附到一起。threshold=10.0的单位是地图单位，对 WGS84 经纬度数据来说也就是十进制度。这里注意：如果数据是经纬度坐标系，阈值 10.0 度会直接把西藏所有路网黏成一个点，必须使用投影坐标系或先转成米制单位。

我的习惯是先把数据转成适合西藏地区的投影坐标系（比如 UTM 46N），再做拓扑修复，最后转回 WGS84 用于交付。snap 阈值的选择血泪经验是：对精度较好的路网取 5 米，对西藏这类大范围采集数据取 10～15 米。阈值太小修不断裂隙，阈值太大则会把平行距离小于阈值的两条路粘在一起，产生虚幻的交叉口。

4.3 交付格式选型：SHP、GeoJSON、GeoPackage 分别什么时候用

路网数据清洗完，要交付成什么格式？这是有讲究的，取决于下游使用场景。SHP 是二十多年前的老格式，现在依然被很多传统 GIS 平台接受，但它有字段名长度限制和单一文件大小限制；GeoJSON 适合网页端可视化，各大前端库原生支持；GeoPackage 是 SQLite 封装格式，单文件支持空间索引，使用范围越来越广。三者对比：

如果是路径规划，我一般交付 GeoPackage，因为它支持空间索引，pgRouting、QGIS 都能直接读。转换命令如下：

ogr2ogr -t_srs EPSG:4326 -lco ENCODING=UTF-8 \ 西藏路网_clean.gpkg 西藏路网_clean.shp

参数里-t_srs EPSG:4326把数据转回 WGS84 经纬度；-lco ENCODING=UTF-8是给 GeoPackage 设置字符编码，防止中文属性在别的机器上打开变成乱码。这里有个常见误操作：有的人在转换时忘了指定编码，导致地名在对方电脑上全是问号，这不是数据错了，是编码声明丢了。

5. 避坑手册：西藏路网数据处理的五类高频问题

5.1 坐标系声明与实际不符：叠加影像整体偏移 500 米

现象：路网数据在 QGIS 里显示正常，一旦叠加影像底图，道路整体向某个方向偏移约 400～600 米，而且偏移方向在全区保持一致。
原因：数据在流转过程中被重新加工过，坐标值被人为加偏，但 .prj 文件里的声明没有同步修改。这在从部分地图平台导出的数据里很常见，导出环节做了坐标转换却没更新元数据。
解决：先确认偏移量在局部区域是否近似常数，然后使用 QGIS 的矢量整体平移工具或 Affine Transform 插件，按测得的平均值平移。平移后一定要再叠加影像复核，因为加密坐标的偏移量在不同方向不完全相同，局部误差可能达到几十米。如果要求高精度，就找参考点做线性校正，但注意不要过度拟合。

5.2 道路线断裂导致路径规划绕远几十公里

现象：用清洗后的数据做路径规划，明明路口就在眼前，规划路线却绕到几公里外掉头。检查数据发现两条线在路口处相距仅 2 米，但没有任何节点相连。
原因：路网数据由不同批次的采集数据拼接而成，接边处没有做节点捕捉；立交桥上下行分离路段尤其容易出现这类问题。
解决：用 v.clean 的 snap 工具，阈值按采集精度设定。对西藏的数据，我一般先用 5 米 snap 跑一遍，看修复统计里 snapped 的数量；如果还大量存在，加到 10 米再跑。不要一次性设成 50 米，那样会把平行的国道和旁边的老路错误合并。

5.3 属性字段错乱：国道编号大面积缺失

现象：ref 字段（道路编号）大部分为空，或者 type 字段全部是 unclassified，整份路网无法区分道路等级。
原因：数据导出时做了字段重映射，原字段名和新字段名不匹配导致值丢失；有些众源数据的属性本身就靠志愿者补录，覆盖不全已经注明。
解决：如果只是字段名对不上，用 QGIS 的字段计算器把旧字段复制到新字段；如果真是缺失，利用空间关系回填。比如拿一份含编号的国道数据，用空间连接把最近国道的编号匹配到缺失路线上。回填时注意：匹配距离阈值要控制在 50 米以内，否则会把相邻的省道错标成国道。

5.4 中文属性乱码：换台电脑打开地名全是「???」

现象：在你自己机器上显示正常的中文属性，复制给别人打开后全是问号或者乱码字符。
原因：Shapefile 的 .dbf 文件编码被写成了 GBK，而对方的软件默认按 UTF-8 读取。这不是数据损坏，是编码声明缺失或写错。
解决：统一用ogr2ogr -lco ENCODING=UTF-8重新导出；如果对方软件坚持用 GBK 读，就在导入时手动指定编码。更彻底的方案是把交付格式换成 GeoPackage，它在编码处理上比 Shapefile 省心很多。

5.5 线要素方向混乱：里程计算出现「一半正一半负」

现象：在计算道路长度时，部分路段的长度值出现异常，或者沿同一道路往返的里程日志明显不一致。
原因：数据生产时没有统一线要素的方向语义，部分线从起点画到终点，部分从终点画到起点，方向字段 oneway 和实际几何方向冲突。
解决：先用 QGIS 的「检查线方向」工具找出反向段，再用「反转线」批量修正。如果数据是用于路径规划，记住最终必须保证连通后每个节点上的线段方向语义一致，且 oneway 字段只对真正的单行道填写，西藏的大部分国道都不该设 oneway，否则规划出来的路线会强制绕死弯。

6. 进阶：用三个指标验证路网是否可用于路径分析

6.1 三个可量化的数据质量指标

数据修完交付前，我习惯用三个指标做最终验收，而不是只靠肉眼观察地图。第一个是悬挂端点数，指的是线段端点距离最近的其他线段超过阈值却没有连接的数量，这个值越低越好；第二个是主要连通分量数量，把整个路网看成图，如果被分割成几十个孤立的子图，跨区域路径分析就没法做；第三个是断裂点密度，即单位长度路网上需要修复的节点数量。

用 PostGIS 可以把这些指标一次性算出来。假设你已经把清洗后的数据导入数据库，并创建了名为 roads 的表，跑这个 SQL 就能统计连通分量数量：

SELECT count(DISTINCT component) FROM pgr_connectedComponents( 'SELECT id, source, target FROM roads' );

这个查询依赖 pgRouting 的连通组件函数。id、source、target是拓扑表里已有的字段，source和target表示每条线段的起止节点编号。如果输出值大于 3，说明路网碎片化严重，需要回到 v.clean 重新处理。注意这里的前提是先执行过pgr_createTopology来生成节点关系。

6.2 判定标准与经验阈值

我的经验阈值是：悬挂端点数不超过总路段数的 2%，主要连通分量不超过 3 个，断裂点密度每公里不超过 0.2 个。超过这个标准，路径规划结果就不具备参考价值。这三个指标没有绝对的正确值，它们是与数据用途挂钩的——展示型应用可以放宽，导航决策类应用必须从严。我现在的习惯是，任何一份新的区域路网数据拿到手，先把这套验证流程跑一遍，确认数据底子是干净的，再进入实际业务分析。路网数据不像普通属性表，错一个节点，后面所有分析都会跟着歪，这是我用多次翻车换来的教训。希望帮到你。

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