出租车GPS数据分析：从数据清洗到城市路况建模全流程-北京尧图网络

简介一份以深圳市出租车GPS数据为对象、研究城市道路交通状况的数学建模PDF资料适合数学建模竞赛备赛者、交通数据分析学习者及城市规划相关专业学生。压缩包内共含一个PDF文件大小约972KB正文涵盖问题分析、模型假设、符号说明、模型建立与求解、模型改进等完整结构。该资料在CSDN已有145人浏览学习。内容围绕交通小区划分、OD时空分布计算与推断、拥堵路段/路口识别等实际问题展开演示了DBSCAN聚类、带约束二次规划、内点障碍罚函数等方法的运用并给出了数据库SQL处理海量GPS数据的思路对理解数学建模从数据处理到模型求解的完整流程有帮助。通过阅读可掌握利用GPS时空数据研究交通流动态的方法也可借鉴其建模与论文写作框架。1. 出租车 GPS 数据数学建模里最容易被低估的“路况黑匣子”数学建模竞赛里凡是沾上“交通”二字的题目十有八九会给你一份 GPS 数据。2025 年研究生数学建模竞赛 E 题就能看到这类影子——给的往往是某个城市的出租车轨迹让你从里面积分出路况、拥堵、甚至是城市职住结构。很多人拿到数据的第一反应是画散点图画完就卡住了因为轨迹点连起来不是路是一条条横七竖八的乱线。实际上出租车 GPS 数据是一份被低估的交通感知网络一辆车就是一个移动传感器几万台车同时跑就把一座城市的路况“采样”出来了。这份《数学建模资料-用出租车GPS数据分析深圳道路交通情况》解决的正是在这种场景下的完整流程问题从原始 CSV 轨迹点到清洗、地图匹配、路段速度计算再到拥堵评价和 OD 分析。适合三类人——准备数学建模竞赛的学生、刚接触交通数据分析的从业者、以及想用开源方式做城市分析的研究者。新手能跟着把流程跑通熟手可以跳过常规步骤直接看边界条件和参数陷阱。2. 出租车轨迹的数据结构与深圳场景先搞懂点在记录什么2.1 一条 GPS 记录里的字段远不止经纬度出租车 GPS 数据最常见的格式是 CSV一行一条记录深圳这类城市的开放数据集中核心字段一般逃不出这七列车辆 ID、时间戳、经度、纬度、速度、方向角、载客状态。有些数据集还会带车牌类型、公司编号、甚至当班司机 ID。很多参赛队拿到数据就开始算距离结果忽略了一个关键事实载客状态通常用 0/1 表示0 是空车1 是载客直接把轨迹切成了两类——载客时的轨迹反映的是乘客的出行路径空车时的轨迹反映的是司机的寻客逻辑。做路况分析两类都能用做 OD 分析只取载客段。时间戳在深圳这份数据里常见的是 Unix 秒或毫秒级整数少数是字符串格式“yyyy-MM-dd HH:mm:ss”。如果是整数第一步先转换成可读时间再按车辆 ID 和时间做排序否则轨迹是乱的。排序这件事看似简单实际是后续所有计算的地基——不排序算出来的速度可能是个负值。还有个容易忽略的点是数据采样率。深圳出租车 GPS 的采样间隔常见是 10 秒到 30 秒不等部分公司设备是 5 秒。这意味着相邻两个点之间的距离可能在 100 到 500 米之间市区拥堵时短高速上长。采样率直接决定了你能做什么分析——10 秒间隔能做路段速度但做不到车道级精细度。2.2 坐标系的坑WGS84 与 GCJ-02 的偏移国内出品的 GPS 数据十份里八份是 GCJ-02 坐标系也就是俗称的“火星坐标”。深圳的出租车数据大多也不例外。GCJ-02 是在 WGS84 基础上做了一次非线性偏移偏移量大约在 100 到 700 米之间而且城市不同偏移不同。如果你把 GCJ-02 数据直接丢到天地图或者某些国际底图上叠绘会发现轨迹整体偏到路对面甚至偏移到另一条路上。判断坐标系是哪个有一个土办法取一个已知地标的经纬度比如深圳市民中心然后跟地图软件上点的坐标对比。如果粗略一致大概率是 GCJ-02然后你用 WGS84 的标准值做差如果差值在百米量级基本确认是火星坐标。从 WGS84 转 GCJ-02 有公开的转换算法反向也有网上能搜到一份流传很广的 Python 实现核心是查表加多项式逼近。坐标系不统一的后果很致命后续做地图匹配时轨迹点和路网不重合偏移几百米后可能匹配到隔壁平行路上算出来的车速偏差直接到 30% 以上。数据清洗做得再漂亮坐标错全盘皆输。3. 数据清洗三步走漂移点、驻车段、异常速度3.1 漂移点的识别与剔除GPS 设备在城市峡谷里容易收到多路径反射信号导致点位瞬间跳出几百米。漂移点的典型特征是相邻两点距离异常大比如 5 秒内跳出 1 公里且计算出的瞬时速度远超道路限速。有一类漂移暂时算不出来——设备自主上报的状态位错误——这部分属于系统性噪声后面用滤波处理。处理漂移点的常用做法是遍历每辆车的轨迹点计算相邻点的距离和速度如果速度超过某个阈值比如 120 km/h出租车在城市里极少超过这个值就标记为疑似漂移点再结合方向角变化率判断。方向角在短时间内剧烈变化同时伴随高速移动基本可以确认是设备受干扰直接剔除。import pandas as pd import numpy as np def haversine(lon1, lat1, lon2, lat2): R 6371000 lon1, lat1, lon2, lat2 map(np.radians, [lon1, lat1, lon2, lat2]) dlon lon2 - lon1 dlat lat2 - lat1 a np.sin(dlat/2)**2 np.cos(lat1) * np.cos(lat2) * np.sin(dlon/2)**2 return 2 * R * np.arcsin(np.sqrt(a)) df pd.read_csv(shenzhen_taxi.csv) df[timestamp] pd.to_datetime(df[timestamp]) df df.sort_values([vehicle_id, timestamp]) for vid, group in df.groupby(vehicle_id): lon group[longitude].values lat group[latitude].values time_diff group[timestamp].diff().dt.total_seconds().values dist haversine(lon[:-1], lat[:-1], lon[1:], lat[1:]) speed dist / time_diff[1:] * 3.6 # m/s - km/h invalid np.zeros(len(group), dtypebool) invalid[1:] speed 120 # 方向角突变检测 heading_diff np.abs(np.diff(group[heading].values)) heading_diff[heading_diff 180] 360 - heading_diff[heading_diff 180] invalid[1:] | (heading_diff 60) (speed 60) df.loc[group.index[invalid], is_invalid] True df df[df[is_invalid] ! True]这段代码里 haversine 函数算的是球面距离输入经度、纬度输出单位为米。时间差用 pandas 的 diff 函数直接算得到的是秒数。速度单位换算成 km/h 是为了跟阈值 120 对比更直观。方向角突变条件有两个方向变化超过 60 度同时当前速度大于 60 km/h——满足这两个条件才标记单方向变化剧烈可能只是正常转弯不能一刀切。3.2 驻车段与空转段的处理出租车有大量的路边等待和红绿灯停车这类点位的速度接近零但不是数据错误不能直接删。真正要处理的是两类一类是长时间原地不动超过 3 分钟且经纬度几乎不变这大概率是停车休息或排队充电不是红绿灯另一类是数据里出现的重复点——同一时刻上报了多条相同记录这在很多城市的原始数据集里都存在。我的处理习惯是先做完全相同记录的去重再按车辆 ID 分组计算相邻点经纬度距离。如果连续 5 个以上的点都在 10 米范围内移动且持续超过 3 分钟就判定为驻车段整体标记出来但不删除。路况计算时排除这些段OD 分析时它们反而是线索——空车长时间停在某个区域说明那里有接单机会或者司机在等人。这里有个容易被忽略的细节驻车段的判断不能只看时间阈值要看“连续静止”。出租车在拥堵路段也会出现走走停停的情况每个点之间间隔 20 秒速度 5 km/h位移 30 米——这跟驻车状态完全不同。如果简单粗暴地按“速度 1 km/h 就剔除”你会把拥堵路段的数据全部删掉算出来的路况直接失真。3.3 时间戳与轨迹排序数据处理过程中时间戳问题的优先级比想象中高。个别车辆上的设备可能出现时钟漂移导致时间戳比实际时间快几分钟或慢几分钟。这个问题肉眼很难发现但会在 OD 分析里露出马脚——某辆车的载客段出现“负时长”。处理方式是逐车检查时间戳的时间间隔分布正常情况下的间隔应当是采样间隔的整数倍出现大量小于 1 秒的异常间隔就要标记该车为可疑设备。time_gaps df.groupby(vehicle_id)[timestamp].diff().dt.total_seconds() gap_summary time_gaps.groupby(df[vehicle_id]).agg([min, max, median]) abnormal_vehicles gap_summary[gap_summary[min] 0].index.tolist()这段代码做的事情很直白先按车辆分组计算每辆车内部相邻时间戳的间隔秒数然后做摘要统计。出现min 0说明时间戳逆序车辆的设备时钟出了问题。把这些车辆单独隔离出来检查是否是少数几辆车的问题如果占比很小少于 0.5%直接剔除即可不影响整体分析结论。4. 从轨迹点到路段路况地图匹配与速度反演4.1 网格化匹配不做完整地图匹配也能算出路况完整的地图匹配算法比如隐马尔可夫模型在论文里很好看但在数学建模场景下复杂度高、调参难而且对路网数据的要求高——你得先有深圳完整的道路拓扑。实际竞赛中很多队伍没拿到路网数据就开干了这时候网格化就是一个务实的替代方案。网格化的思路很简单把深圳按经纬度切成均匀的格子比如 500 米 × 500 米每个格子作为一个“路段代理”。把 GPS 点落入对应的网格格子里然后按网格汇总速度。这个方法的代价是精度受格子大小影响好处是不依赖任何外部路网数据拿一份经纬度边界就能跑通全流程。grid_size 0.005 # 约500米 df[grid_lon] (df[longitude] / grid_size).astype(int) df[grid_lat] (df[latitude] / grid_size).astype(int) def calc_grid_speed(group): speeds group[speed].values speeds speeds[(speeds 2) (speeds 80)] return np.mean(speeds), len(speeds) grid_stats df.groupby([grid_lon, grid_lat]).apply(calc_grid_speed)这段代码的网格划分用了整数取整的方式0.005度大约对应 500 米在赤道附近的距离深圳维度接近北回归线实际约 540 米对路况分析反正是粗粒度够用。速度过滤2 ~ 80 km/h是为了排除驻车点和异常高速点。统计结果里的len(speeds)是样本量后面评估拥堵指数可靠性时要用到——一个网格里只有两条记录的均速没有任何参考价值。网格粒度怎么选我一般建议做两轮实验第一轮用 1 公里粒度跑一遍看整体路况分布是否合理第二轮切到 300 米粒度细看核心城区。市中心的经纬度网格天然会出现一个格子横跨三条路的情况这点后面专门讲。4.2 拥堵指数计算从平均速度到路况等级平均速度本身不能直接当拥堵指标——同一条路限速 80 和限速 40跑 30 km/h 的含义完全不同。深圳的快速路北环大道、滨海大道限速普遍 80市区主干道限速 60支路限速 40。为了可比业内常用 TSITraffic State Index的思路实际运行速度与自由流速度的比值映射到 0 到 100 的指数。自由流速度怎么取没有官方参考值时可以用该网格/路段在一天内速度分布的 85 分位数作为近似。比如某路段一天内所有经过车辆的速度 85% 都在 55 km/h 以下那 55 就当作自由流速度的估计值。思路是夜间的出租车速度更接近道路设计速度取一天的高位分位数能天然消除早晚高峰的拥堵影响。def calc_tsi(avg_speed, free_flow_speed): ratio avg_speed / free_flow_speed if ratio 0.8: return 1 elif ratio 0.6: return 2 elif ratio 0.4: return 3 elif ratio 0.2: return 4 else: return 5 grid_speed grid_stats[0] # 平均速度 grid_free_flow df.groupby([grid_lon, grid_lat])[speed].apply( lambda x: np.percentile(x, 85) ) grid_tsi pd.DataFrame({ avg_speed: grid_speed, free_flow_speed: grid_free_flow }).apply(lambda row: calc_tsi(row[avg_speed], row[free_flow_speed]), axis1)TSI 等级从 1 到 51 表示畅通5 表示严重拥堵。这个五级分类法跟很多城市的交通运行指数公布口径类似竞赛论文里用这套表述评委一看就知道你做了标准化的工作。需要注意的是自由流速度按天算还是分时段算——我建议分时段凌晨的 85 分位数速度会高于晚高峰的 85 分位数速度如果统一用全天数据高峰期的“相对畅通”会被误判成拥堵。4.3 早晚高峰的切片分析做完网格速度计算下一步就是时间维度上的切片。深圳的交通有两个明显的窗口早高峰 730 到 930晚高峰 1730 到 1930。把一天 24 小时切成 5 分钟窗口每个窗口内统计一次网格平均速度就能得到“一天内拥堵演化”的时间序列。这个切片的参数敏感性很高。窗口太短1 分钟部分网格可能一个样本都没有窗口太长30 分钟高峰期的拥堵细节全被抹平。5 分钟窗口配合 500 米网格在深圳出租车数据量下通常每个格子有几十个到几百个样本是比较合适的平衡点。有了时间序列后可以做的事就多了定位“常发拥堵点”连续三天同一时段 TSI 为 4 以上的网格、分析拥堵在空间上的扩散方向从关口向市中心蔓延、甚至做拥堵预测的模型输入。论文里画一张热力图——横轴时间纵轴网格 ID颜色表示 TSI——比整页的文字更有说服力。5. 出租车 GPS 分析的避坑记录这些坑我都踩过5.1 坐标系混淆导致的路网偏移现象轨迹点画出来和深圳地图的路网对不上整体偏移大约 200 到 500 米跟道路平行但不重合。原因数据用的是 GCJ-02但你拿的是 WGS84 底图或者反过来。深圳的数据大多偏火星坐标直接画图就是这样。解决先用已知地标做坐标验证确认坐标系后做统一转换。GCJ-02 转 WGS84 网上有标准算法转换后必须抽样复检——取几个路口点位跟地图交叉核对误差在 20 米内才说明转换参数没问题。5.2 重复记录导致的负时间间隔现象部分车辆的轨迹里面出现连续两条完全相同的记录时间间隔为 0个别甚至出现负间隔。代码跑速度计算时报出离谱的 2000 km/h。原因设备的重复上报以及车辆熄火后数据补传导致的乱序。这不是你代码的问题是设备行为。解决做全字段去重再按车辆 ID 和时间戳排序排序后如果还有负间隔直接标记该车辆并剔除。血泪经验负间隔如果只出现在个别车辆上剔除是最省事的做法不要试图修正因为你不知道是时钟问题还是补传问题。5.3 网格划分造成的虚假拥堵现象某条快速路在热力图上呈现深红色“严重拥堵”但你抽样看原始轨迹车速其实 60 以上。原因快速路和辅路并行在同一网格内辅路的低速样本拉低了平均值。网格是沙盘不是解剖刀——它分不开并行道路。解决评估网格内样本量的分布如果某个网格里速度分布出现双峰一个峰值在 60一个在 20 以下说明网格内混了不同限速的道路。处理方式是缩小网格尺寸到 200 米重新计算或者在论文里明确网格方法的精度边界承认它识别的是片区拥堵而非路段拥堵。竞赛里承认方法边界不比硬扛减分。5.4 载客状态字段不规范现象OD 分析里出现单次行程超过 3 小时、里程超过 200 公里的记录明显不合理。原因部分车辆载客状态切换存在延迟——乘客下车后 1 到 2 分钟才上报空车导致上一次行程被拉长。解决在提取出行段时设定最大时长阈值比如 120 分钟和最大距离阈值比如 100 公里超出即切断。还要检查状态切换是否交替出现——连续两次载客之间没有空车状态就是字段异常直接丢弃这一段。6. 进阶把路况分析做成决策依据路况分析做到网格和 TSI 这层已经是很多竞赛队伍的终点了。但这份深圳出租车数据还能再往下挖一层。一个值得投入的方向是把 OD 分析与道路运行状态叠起来看。提取载客段后聚合出每个网格的出行发生量和吸引量再结合白天/夜晚的时段划分能看到深圳的职住分离程度——越过梧桐山隧道去盐田上班的人有多少福田到南山通勤的潮汐方向是什么。这些结论放在竞赛论文里是从“描述现象”升到“解释机制”的关键一步。另一个实用技巧是数据存储的优化。深圳一天的出租车轨迹大约千万行级pandas 处理起来还不至于卡死但如果要跑全月数据建议用列式存储格式同时按日期分区。把清洗后的数据转成 parquet 格式文件体积能压缩到原来的三成以下后续加载速度提升一个量级。代码上只需在清洗完成后加一行转换。可视化层面我用过比较顺手的是 folium 做采样点快速核查正式出图用 pyecharts 的热力图。动态时序图能清楚地看到晚高峰拥堵从罗湖口岸向外扩散的过程——这种图在答辩时放出来比静态地图有感染力得多而且做起来就是逐帧渲染热力图而已。从头跑完这套流程后我的一个习惯是从不直接拿网格分析结果下结论。每次都会先抽出几个网格把原始轨迹点画出来人眼确认路况判断是否真实。从那以后不管用模型还是数据我都会强制过一遍“抽点看原始数据”的环节这个动作在竞赛和实际项目里都帮我拦住了不少错误结论。希望这份资料里的流程和踩坑记录能帮你少走一段弯路把重点放在真正有说服力的交通分析上。本文还有配套的精品资源点击获取

出租车GPS数据分析：从数据清洗到城市路况建模全流程

相关推荐

DeepSeek R1 本地部署实战：Ollama+AnythingLLM 零基础跑通指南

AI技术如何革新企业并购估值方法与系统架构

新一代AI基础设施白皮书解读：从算力到Agent的工程化落地

更多资讯

零基础大模型入门：从提示工程到私有化部署的考点地图

跨文档同名实体消歧：替换原文之前先保护字符偏移

Flask数据可视化大屏源码实战：多页面轮播与实时数据渲染

C# Winform开发OA系统：C-S架构实战与三层架构解析

Transformer架构优势解析：为何超越CNN与RNN

数据科学如何重塑大数据技术生态与实战应用

今日更新

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？