简介：全球飞行航线数据以标准矢量格式封装，面向地理信息研究人员、航空交通分析人员及数据爱好者，适用于航线网络研究、航空流量统计与地理空间建模。压缩包内共15个文件，核心为航线几何文件，另含属性数据表、投影坐标定义文件，以及多种索引文件与元数据文档，整套数据大小约八兆，下载和部署都很便捷。数据覆盖全球主要航线，记录了起降机场坐标、航路点与飞行方向等信息，可直接在地理信息软件中加载，用于航线密度分析、机场间距离测算、航班时刻规律挖掘等场景。已有七百余人学习使用，适合需要真实航线数据进行科研、教学或可视化展示的读者。配合属性字段和坐标参考，还可与其他社会经济数据叠加分析，探索航空网络与区域发展的深层关系。
1. 全球飞行航线数据到底是个什么东西
先说结论：全球飞行航线shp数据，就是一份把全世界民航客机常飞航线的起点、终点、路径连线全部以矢量形式存下来的地理信息文件，后缀是.shp，但实际用的时候它不是一个文件，而是一组文件。这份数据在GIS圈、民航圈、数据可视化圈都特别常见，做航线网络分析、航班流量热力、区域通达性研究，甚至做一张“世界航线地图”当大屏背景，都得靠它。
很多人第一次拿到的全球航线shp数据，是从OpenFlights这类公开数据源转出来的。OpenFlights原始数据是CSV，记录了全球几千个机场的经纬度、IATA三字码、城市、国家，以及几十万条航线记录（每条记录包含承运航空公司、起飞机场、目的地机场）。CSV本身没有几何信息，你要画航线图，必须把“机场位置”和“航线关系”结合起来，在GIS软件里生成线要素，才能导出成shp。所以市面上传播的“全球飞行航线数据shp”，本质上是别人已经把两趟工作做完了：一是从机场表生成点的几何，二是把点对点的关系连成了线。
这就能解释为什么网上流传的各种版本的航线shp，字段和精度都不一样——有的带航班频次，有的只有起终点名称，有的航线是直线，有的是按大圆航线（Great Circle）插值过的弧线。你拿到的文件如果只有几十MB，大概率是简化版；几百MB的那版，基本是每条航线都做了密集插值，弧线非常平滑，但也非常吃内存。
再补充一个关键认知：shp里的线要素，默认只能存“直线段”或“折线”。如果一份航线数据的线段数量特别多，那一定是有人手动把大圆航线按经度每5度或10度插值成一个一个折点，然后再写进shp的。这个细节你后面做可视化的时候会深有体会——用Leaflet或Mapbox加载，直线版航线在跨太平洋的路径上会显得“弯得不够”，插值版就会自然很多。
2. 入手shp前，先搞懂它的三个硬脾气
2.1 一个shp不是文件，而是一套文件
我见过太多新手拿到一个.shp就往软件里拖，结果提示打不开。真正的shp是一组同名文件组成的集合，至少包含三个：
- .shp：几何信息主体，存点、线、面的坐标
- .shx：形状索引文件，负责快速定位几何对象
- .dbf：属性表，存每个要素的非几何字段，比如航线名称、起终点城市、航班量
除此之外还常见的还有：
- .prj：坐标系定义文件，没有它，很多软件会默认按WGS84经纬度来猜
- .cpg：属性编码文件，通常是UTF-8或GBK
- .sbn / .sbx：空间索引文件，加载大文件时自动生成
所以拷贝给别人时，最好把整个目录打包，别只发一个.shp。很多人的航线数据加载出来“位置不对”“属性乱码”，十有八九是.prj和.cpg丢了。
2.2 坐标系是航线数据的隐形裁判
全球航线数据涉及世界地图，坐标几乎是铁定的WGS84经纬度（EPSG:4326）。但你在国内做项目，经常需要叠加到“墨卡托投影”的底图上（EPSG:3857，也就是Web Mercator）。这时候如果直接把4326的shp丢到3857的底图上面，航线会整体偏移甚至扭曲——不过大部分GIS软件会自动做“实时投影”，所以肉眼不容易发现，只有做距离量算、缓冲区分析时，才看得出问题。
我个人的习惯是：不管最终展示用哪个坐标系，原始数据一律保留4326不动，只在导出成geojson或做切片时再动态转换。因为4326是全球数据的事实标准，转来转去必然带来精度损失，尤其是跨180度经线的航线（比如中国飞北美西海岸），转一次投影就可能出错。
2.3 属性编码的坑，最容易在中文环境踩
OpenFlights的CSV是全英文的，但很多国内团队二次加工过的航线shp，会在属性表里加上“中文城市名”“中文航空公司”。这时如果.cpg文件标记的是UTF-8，你在ArcGIS里打开没问题，在QGIS里打开也没问题；但如果有人用老版本ArcMap或者直接把.dbf用Excel打开，就会看到“鏉窞”这种乱码。这不是数据坏了，是编码解释不一致。
解决办法也简单：收到一份航线shp，先看.cpg里写的是什么编码，如果是GBK且你需要在QGIS里显示中文，只需右键图层设置编码为GBK重新加载即可。反过来，如果你要发布成GeoJSON给Web前端用，统一转成UTF-8，否则浏览器里全部乱码。
3. 实操指南：把GeoJSON转成shp的完整流程
热搜词里有个“geojson转换成shp格式工具”，这确实是最常被搜索的需求。原因很简单：地理数据在Web端（前端可视化）基本都流行用GeoJSON，而桌面端GIS分析和传统制图流程仍然紧抱shp不放。你在网上找的全球航线数据，很可能拿到的就是一份.geojson文件，或者从某个API接口拉的实时航线JSON，这时候想进ArcGIS/QGIS做分析，就必须转成shp。
3.1 最快路径：QGIS另存为
如果你已经装了QGIS，这是最省事的方案，不需要记任何命令行。
步骤非常简单：
- 打开QGIS，把.geojson文件直接拖进图层窗口
- 右键图层，选择“导出”->“要素另存为”
- 格式选“ESRI Shapefile”
- 文件名填航线数据，坐标系保持原始用的WGS 84（EPSG:4326）
- 编码选UTF-8
- 确认后，目录下自动生成.shp/.shx/.dbf/.prj/.cpg一套文件
单看操作，一分钟就能完成。但实际过程中有两个容易被忽略的细节。第一个是要素数量，全球航线动辄10万条以上，QGIS导出时默认会做几何检查，如果源文件里有“自相交”或“空几何”的线，导出会报错。我一般先跑一遍“修复几何”工具，再导出。第二个是字段名长度，shp的.dbf格式对字段名长度限制在10个字符以内，GeoJSON里那些“airline_name”“departure_city”这类长字段名会被自动截断，导出后你可能会看到“airline_na”这种奇怪的名字。所以转之前，先手工把字段名改成短名，等到导出后再补字段值也不迟。
3.2 命令行方案：ogr2ogr一键批量转换
如果你有大量航线文件要转，或者想把转换流程固化成一个自动化脚本，ogr2ogr是不可替代的。它是GDAL自带的一个命令行工具，装了QGIS之后，在系统命令行里就能直接用（Windows下建议把QGIS的bin目录加进PATH）。
最基本的转换写法：
ogr2ogr -f "ESRI Shapefile" 航线数据.shp 航线数据.geojson这句话的意思是把GeoJSON转成Shapefile，默认读取源文件的坐标系，输出到当前目录，属性字段全保留，编码默认UTF-8。如果你需要指定坐标系，加一句：
ogr2ogr -f "ESRI Shapefile" -t_srs EPSG:4326 -lco ENCODING=UTF-8 航线数据.shp 航线数据.geojson两个参数解释一下：-t_srs是目标坐标系，-lco ENCODING=UTF-8是让dbf属性文件用UTF-8编码保存。这里我建议除非有特殊要求，否则不要改坐标系，始终用EPSG:4326，最稳。
如果你拿到的源文件是一个包含几十个航线图层的GeoJSON（比如一个FeatureCollection里按不同颜色分好了大洲），ogr2ogr默认一个图层只会转出一个shp，无法一次全拆。此时可以用参数：
ogr2ogr -f "ESRI Shapefile" -explodecollections 输出目录 航线数据.geojson使用-explodecollections，图层里每个独立要素会被分别拆出来写进同一个shp，颜色或分类信息会保留在属性表里，方便后续按属性渲染。
3.3 在线转换工具：应急可以，不建议主力用
市面上有不少在线的geojson转shp工具，界面做得也友好，上传文件一键就出结果。我的看法是：文件小、临时看两眼可以；做正经项目，别用。原因有两个。
第一，航线数据动辄几十MB，在线工具上传下载一次，时间成本比本地转换高得多。第二，很多免费在线工具不保留.prj文件或者把坐标系信息丢得一干二净，你拿到shp后还得手动指定坐标系，反而不如本地一句命令来得干净。如果你确实需要在线转换，建议转完第一时间把shp拖进QGIS，右键图层属性查看坐标系的显示，确保是WGS 84再继续后续操作。
4. 航线shp在实际项目里的三个高阶玩法
4.1 大圆航线弧度插值，让航线图不“拉直线”
前面提到过，很多公开的航线shp数据是直线连接，但真实航路是按大圆航线飞的——也就是在地球球面上取两点之间的最短路径，反映到平面地图上是一条向极地弯曲的弧线。视觉上，弧线比直线高大上很多，也更贴合人们对“全球航线”的预期。
如果拿到的shp里航线是直线，想在QGIS里快速生成弧线版本，有个思路：把线要素转成点序列，再按大圆插值重新生成。具体做法是：
- 用菜单“处理工具箱”搜索“提取折点”，把每条线拆成起点和终点两个点
- 用“按表达式提取”处理出起点层和终点层
- 对每一对起终点，写一个表达式，按经度间隔生成插值点，再把点连成线
这一步用Python脚本或QGIS的Geometry Generator更高效。简单的做法是使用“Shape Tools”插件里的“Great Circle Lines”功能，选中起点和终点图层后，它能自动按设定步长生成圆弧线，直接输出成新的shp。步长我推荐设成5度，即每隔5个经度插一个点，线够平滑，文件体积也不会爆表。
4.2 用地物底图叠加，做机场可达性热力分析
航线数据当然不只用来画地图。把机场点shp和某国省界shp叠加，再结合航线表里的航班频次字段，就能做“从某机场出发两小时内可以飞到哪里”的可达性分析。
实操时，先把机场shp用“缓冲区”工具按半径生成圆形（如果考虑地球曲率，在4326坐标系下不要用固定公里数，要用QGIS里的“处理工具箱->矢量几何->缓冲”里的“距离字段”，填上每公里对应的度数值），再把航线表按“出发机场”关联到缓冲区上，最后用“按位置连接”统计每个机场的航线数量。这套流程跑通之后，你就能得到一张“全球航空枢纽热度图”，哪个机场是真正的中转之王，一目了然。
4.3 把shp发布成Web地图，前端加载不卡顿的技巧
最后一步经常被忽略：你辛辛苦苦整理好的航线shp，如果想让它在网页上展示，不能直接丢给浏览器去加载。shp不是Web原生格式，浏览器得借助解析库（比如shapefile-js）才能读，而且一旦文件超过10MB，前端卡成PPT一点都不意外。
我的做法是：先在QGIS里把航线shp按密级或区域筛选一遍，只导出需要展示的航线（比如只保留每天航班数大于10条的主干线），再用“矢量切片”工具（如tippecanoe）转成mvt切片，最后用Mapbox或Leaflet加载。这样一个几十MB的全球航线文件，优化后能压到几百KB，地图缩放时还能自动显示不同粒度的航线，交互体验完全不一样。
5. 整理一份避坑清单，供你直接照做
- 下载到任何航线shp，第一件事先打开属性表看字段名和记录数，别急着画图
- 用ArcGIS打开发现中文乱码，先右键图层去掉编码改为UTF-8，但别直接改源文件编码，否则全图要素会丢失
- 转换GeoJSON到shp时，字段名超过10个字符会被截断，先统一改成短字段名
- 处理跨180度经线的航线，比如“上海-洛杉矶”，务必把线要素按经度拆开成两段再投影，否则会出现一条直线横跨整个地图的诡异现象
- 大文件加载慢时，把shp按航线长度分层，短途航线一个图层，洲际航线一个图层，分别控制显示范围，性能会立竿见影
- 千万保留一份原始.geojson或者源CSV，shp一旦操作失误修改了属性表，很多时候很难回退
- 用来发布Web地图时，先压成矢量切片，不要直接丢shp给前端
6. 我个人在实际操作中的一点体会
做全球航线数据这几年，我最强烈的感受是：这个数据的“坑”不在数据本身，而在大家对shp格式的认知惯性。现在WebGIS越来越流行，GeoJSON、FlatGeobuf这些新格式越来越常用，但传统的GIS分析工具、老旧的制图流程、甚至很多科研机构的数据库接口，依然默认只认shp。所以“把GeoJSON转成shp”这件事，在未来很长一段时间内都会是刚需。
我自己现在的固定路径是：原始数据尽量找GeoJSON格式保留（小巧、跨平台、容易做版本管理），任何需要进入桌面GIS分析的任务，一律用ogr2ogr一条命令转成shp，再进QGIS。等分析完了，要发布到Web端，再转回GeoJSON或转成矢量切片。这个流程来回走了几百趟，基本没出过什么大问题。
如果你也是第一次碰全球航线数据，我建议别急着寻找“最全”“最大”的那份数据源，先拿一份几MB的测试版本，把QGIS加载、属性查看、坐标系检查、转shp这一套流程跑通，再换大数据集去折腾，会轻松得多。最后再分享一个小技巧：QGIS里加载全球航线shp之后，把线颜色设成半透明、宽度按航班频次分级，再用暗色底图，出来的效果非常能打，视觉上直接就是一张专业的全球航线网络图。
本文还有配套的精品资源，点击获取
