简介基于共享单车骑行大数据面向城市数据分析师、规划研究者及共享出行从业者的一份PDF报告聚焦成都文艺场所热点挖掘。报告源自第一财经商业数据中心与ofo小黄车的联合研究以真实骑行订单为样本结合大众点评热度系统分析茶馆、书店、博物馆、美术馆、酒吧等城市文化空间的骑行特征与人群偏好呈现武侯区、锦江区等区域的文艺生活图谱并为城市规划与公共设施优化提供数据决策视角。文件为单个PDF文档大小2.24MB内容完整共1份文件便于直接阅读或归档。目前已吸引73人学习使用。读者可从报告中获取完整的数据说明、分析方法与可视化结论包括各场所骑行距离、时段分布、年龄与性别差异如90后男性更倾向美术馆与酒吧、工作日与周末骑行波动等尤其适合用作文旅消费洞察、城市空间研究或数据报告写作的参考案例。1. 骑行数据不是白骑的热点地图才是骑行的“副产品”每天打开骑行 App 记录轨迹最终只换来自行车的里程数和朋友圈的几张照片这其实是一种浪费。骑行轨迹里每一秒都在产生 GPS 坐标点把大量骑行者的轨迹汇聚起来就能看到一座城市真实的“生活温度”清晨的滨江绿道、午间写字楼旁的咖啡店、深夜仍在亮灯的小吃街、周末的郊野公园这些都会以热力分布的形式呈现出来。所谓“寻找城市热点”不是搜索关键词而是从空间统计的角度找到人流、车流、停留行为在空间上的聚集区域。这个思路可以落到一个能交付的工程结果上把骑行轨迹清洗入库做网格密度聚合再用 H3 六边形格网做热点分级最后把结果输出成带图表的 PDF 报告。这篇文章就按这条链路展开适合做城市数据分析、LBS 应用开发或有骑行数据源的团队参考。你不需要有 Hadoop 集群撑场面一台 8 核 16G 的机器加 PostGIS 就够跑完一个中等城市的全年数据。2. 骑行轨迹采集与预处理从 GPS 坐标点到可用轨迹段2.1 原始骑行数据长什么样无论是从自行车码表、运动手表还是手机 App 导出骑行数据的标准交换格式通常是 FIT、GPX 或 CSV。GPX 是最容易处理的格式XML 结构里按trkpt节点记录经纬度、海拔和时间。CSV 更简单但各家厂商的列名五花八门常见的有latitude、longitude、timestamp也有直接写lat、lon的。处理的第一步不是写算法而是统一 schema。原始骑行数据标准化字段CSV 为例 字段名 类型 说明 ride_id string 单次骑行ID device_id string 设备标识 lat double 纬度WGS84 lon double 经度WGS84 alt double 海拔米 speed double 即时速度km/h recorded_at timestamp 记录时间这里有一个容易踩坑的地点坐标系。绝大多数民用 GPS 设备输出的是 WGS84 经纬度但国内很多地图 SDK 和行政区划边界数据用的是 GCJ-02火星坐标或 BD-09百度坐标。如果直接把 WGS84 坐标叠加到高德底图上做热力可视化错位会在 100 米到 600 米之间热点中心直接偏移到隔壁街区。做数据处理这一层统一存 WGS84输出展示层再做转换不要在入库阶段混用。2.2 清洗脏数据漂移点、静止点和跳变点GPS 在城市峡谷环境里表现并不稳定——高架桥下、隧道口、密集高楼区间卫星信号反射会带来几十米的定位跳动。这些漂移点放到热力聚合里会在马路上凭空造出一片“虚拟热点”。清洗逻辑按以下三步处理按轨迹连续性剔除速度异常点。两点间距离除以时间差如果瞬时速度超过 70km/h——普通自行车不可能达到——直接标记为漂移点。过滤静止点。速度小于 1km/h 且持续时间超过 180 秒的点说明骑行者已经停下休息或逛店这类点单独归类为“停留点”用于后续挖掘但不参与线路热力聚合。按轨迹分段打断。相邻两个点时间间隔超过 5 分钟或者距离超过 500 米断开为两条轨迹。因为用户可能中途停顿后继续骑行中间缺失段如果强行连线会画穿建筑物。用 Python 处理时我常用 GeoPandas 做向量化操作而不是逐行 for 循环。几百万行的轨迹点逐行用 Python 循环要跑几分钟向量化几十秒就能完成。import pandas as pd import geopandas as gpd from shapely.geometry import Point from datetime import timedelta df pd.read_csv(raw_rides.csv, parse_dates[recorded_at]) df df.sort_values([ride_id, recorded_at]) # 用 groupby 做组内差分避免循环 grouped df.groupby(ride_id) df[prev_time] grouped[recorded_at].shift(1) df[prev_lat] grouped[lat].shift(1) df[prev_lon] grouped[lon].shift(1) # 计算每段距离与速度Haversine 简化为等距近似 df[d_lat] (df[lat] - df[prev_lat]) * 111320.0 df[d_lon] (df[lon] - df[prev_lon]) * 111320.0 * (df[lat].radians.cos() if False else 0.8) # 简化场景直接用 scipy 或 geopy 计算实际工程里用矢量化的 haversine 函数 df[seg_dist] ((df[d_lat]**2 df[d_lon]**2) ** 0.5).fillna(0) df[seg_time_s] (df[recorded_at] - df[prev_time]).dt.total_seconds().fillna(0) df[seg_speed] df[seg_dist] / df[seg_time_s].replace(0, 1) * 3.6 # m/s - km/h # 剔除漂移点速度 70km/h df df[df[seg_speed] 70.0] # 标记静止点速度小于 1km/h 且持续超过 180 秒 df[is_stop] (df[seg_speed] 1.0) (df[seg_time_s] 180) stops df[df[is_stop]].copy() # 线路热力只保留非静止点或静止时间很短的轨迹 route_df df[~df[is_stop] | (df[seg_time_s] 30)].copy()代码里关键点在于用groupby加shift一次算出前后点差而不是循环每个点。速度计算必须在每个骑行 ID 内部做跨 ID 计算会算出从上一段终点到下一段起点的假速度容易误删数据。静止点单独存一份后面做停留热点分析还会用到。2.3 轨迹分段和路网匹配的取舍清洗后的轨迹可以直接做热力聚合但存在一个空间分布不均的问题骑行者在马路上是“线状”运动原始点在道路上的分布密度与道路等级相关主干道天然比小巷子点多。如果直接用点做热力渲染结果会偏向主干道真正有意思的“热点”——比如某个小巷子口的网红店、某个公园的隐藏入口——反而不容易被识别出来。两种常见做法不做路网匹配直接网格聚合。适合“哪个区域骑行强度高”这类宏观问题处理成本低数据量几百万点也不怕。做路网匹配Map Matching把 GPS 点投影到 OpenStreetMap 路网上再聚合。适合“哪条具体街道最热门”这类微观问题准确度高但要引入 Valhalla 或 GraphHopper 这类服务还要处理路网数据的时效性。对城市热点发现这个目标我更推荐先做网格聚合不做路网匹配。热点本身是一个区域概念不是一个点概念网格聚合天然带有空间平滑效应能容忍 GPS 的定位误差也不会因为路网数据缺了某条新建道路而漏掉热点。3. 热点识别算法选型与参数调优从密度聚类到格网评分3.1 三种主流方案的对比拿到清洗后的轨迹点做热点识别有三种成熟的技术路径方案原理优点缺点适用场景固定网格密度计数把城市切成等大的格子统计每个格子内的轨迹点/轨迹段数量实现简单计算快可解释性强网格边界生硬热点会被切到两个格里初筛、宏观热力发布H3 六边形格网聚合Uber 开源的六边形索引体系层级固定面积均匀六边形没有边角偏差按层级缩放方便引入外部依赖概念要额外学习城市级热点分级DBSCAN 空间聚类基于密度的聚类算法自动发现任意形状的聚类不需要预设网格能发现任意形状热点参数需要调大数据量下要配合空间索引发现点状热点例如停车点聚集区固定网格的最大问题是摩尔纹效应——同一片热点区域如果网格平移半个格宽聚合结果就会拆成两片小热点看起来像网格纹理干扰城市尺度上的判断。H3 六边形格网在这个问题上比正方形网格好得多六个邻居完全对称热点区域的连续性更好。DBSCAN 则完全摆脱网格的约束更适合找到“点状”热点——诸如共享单车停放潮汐点、骑行者的聚集起点。3.2 用 H3 做城市骑行热度聚合的具体实现H3 的分辨率 9 级六边形单格面积约为 0.105 平方公里半径约 174 米适合识别城市游憩热点。如果用 10 级面积缩到约 0.015 平方公里能识别街区级热点但噪声也随之增加。做完清洗全量轨迹点后实际实施如下import h3 import numpy as np import pandas as pd # 假设 route_df 已清洗完成包含 lat、lon 列 RESOLUTION 9 # 为每个轨迹点绑定 H3 六边形 ID route_df[h3_index] route_df.apply( lambda row: h3.latlng_to_cell(row[lat], row[lon], RESOLUTION), axis1 ) # 每格有效骑行轨迹点数 cell_counts route_df.groupby(h3_index).size().reset_index(namepoint_cnt) # 每格经过的独立骑行次数去重 ride_id cell_rides route_df.groupby(h3_index)[ride_id].nunique().reset_index(nameride_cnt) # 每格累计骑行时长分钟 cell_duration route_df.groupby(h3_index)[seg_time_s].sum().reset_index(nametotal_sec) cell_duration[total_min] cell_duration[total_sec] / 60.0 # 合并三项指标 heat_df cell_counts.merge(cell_rides, onh3_index).merge(cell_duration, onh3_index) # 构造 GeoDataFrame 便于后续出图或写 PostGIS heat_df[geometry] heat_df[h3_index].apply(lambda x: h3.cell_to_latlng(x))注意这段代码里用apply逐行绑定 H3 ID数据量大时性能偏慢但胜在逻辑简单清晰。对百万级点跑完约需几十秒可以接受。如果到了千万量级用h3的向量化 API 或 PySpark UDF逻辑不变。热点不是靠单一指标决定的。point_cnt代表骑行强度ride_cnt代表覆盖的骑行者规模total_min代表在这片区域花的时间长短。三个指标的组合视角完全不一样point_cnt高而ride_cnt低说明是几个重度用户反复刷出来的路段point_cnt中等而ride_cnt高说明是广泛人群经过的公共通道后者作为城市热点的意义更大。3.3 DBSCAN 识别停留点聚集区骑行路线热力适合回答“哪里骑得多”却回答不了“哪里值得停下来”。城市的消费热点恰恰是后者——人们愿意停下来花时间的地方。把 2.2 节里单独保存的stops表拿出来对停留点做 DBSCAN 聚类可以自动圈出聚集区。这里需要调两个参数eps邻域半径城市尺度建议 200 到 300 米。太小会把一个商圈拆成几个簇太大把两个相邻商圈合并成一团。min_samples最少样本数建议 20 到 50。设定在 20 意味着至少 20 次有效停留才算一个候选热点。from sklearn.cluster import DBSCAN import geohash2 # 停留点转弧度坐标供 DBSCAN 使用用米制距离需要转投影这里用简化的球面距离 coords stops[[lat, lon]].values # 粗略把经纬度换算成公里量级适配 eps0.3 公里 coords_km np.column_stack([ coords[:, 0] * 111.0, coords[:, 1] * 111.0 * np.cos(np.radians(coords[:, 0])) ]) clustering DBSCAN(eps0.3, min_samples20, metriceuclidean).fit(coords_km) stops[cluster_id] clustering.labels_ # 聚合每个簇的停留强度 stop_hotspots stops[stops[cluster_id] 0].groupby(cluster_id).agg( stop_count(ride_id, count), avg_duration_min(seg_time_s, mean), lat(lat, mean), lon(lon, mean) ).reset_index() stop_hotspots stop_hotspots[stop_hotspots[stop_count] 20].sort_values(stop_count, ascendingFalse)DBSCAN 的问题在于eps在低纬度和高纬度地区对应的实际距离差异很大代码里用cos(lat)做了一次近似修正把经度方向的真实距离拉平到公里尺度。这样在在中国从哈尔滨到三亚的范围内参数都不需要重新调整。聚类的中心点坐标是所有停留点的均值不是实际存在的某个 POI 位置后续步骤里要拿它去关联附近的商户或地标而不是直接把坐标交给地图渲染。3.4 热点分级不能用裸的轨迹点数量一刀切聚合完成后会得到几百上千个候选格网但报告里不可能展示全部。热点分级用“帕累托法则”思路处理分数排序后前 5% 为一级热点5% 到 20% 为二级热点其余为三级。评分公式综合骑行强度、骑行者覆盖规模和停留时长hotspot_score zscore(log(point_cnt)) * 0.3 zscore(log(ride_cnt)) * 0.4 zscore(log(total_min)) * 0.3取对数是因为轨迹点数量呈长尾分布少数格网占据绝大多数点数直接取原始值会让少数主线道路垄断所有高分热点。综合评分后热点排名就不会永远是滨江大道这样的骑行主干道——停留时长这一项会把商圈、景点、咖啡馆聚集区顶上来这才是“城市热点”而非“骑行路线热力”。4. 结合路网与 POI 数据识别热点属性骑行者到底去了哪4.1 从热点格网到语义标签H3 网格和 DBSCAN 聚类只能告诉你在“哪个六边形里人多”没告诉你人为什么多。热点没有语义标签做出来的城市热点地图就是一张热力图始终停留在视觉层。要让结果变得真正可交付下一步是把热点与城市的基础设施数据进行叠加关联通常接入的是三类数据OpenStreetMap 路网数据判定热点是否沿绿道、主干道分布。POI 数据包括餐饮、购物、景点、居住小区、办公园区用于打标签。行政区划或城市功能区划数据标注热点在哪个商圈、哪个街道。这一步的实际操作分两类情况。如果热点格网比较小而且密集可以直接用空间连接把 POI 关联到格网里如果热点是分散的小簇以 3.3 节得到的聚类中心点做缓冲区查询更合适因为 POI 和停留点中心并不完全重合。缓冲区半径通常取 300 到 500 米对应骑行者的步行活动半径。-- 使用 PostGIS 做空间连接标注热点区域的 POI 分布 SELECT h.h3_index, h.ride_cnt, h.total_min, string_agg(DISTINCT p.category, , ) AS poi_categories, count(DISTINCT p.id) AS poi_count FROM heat_df h JOIN poi_table p ON ST_DWithin( ST_SetSRID(ST_MakePoint(h.lon, h.lat), 4326)::geography, p.geom::geography, 500 ) GROUP BY h.h3_index, h.ride_cnt, h.total_min HAVING count(DISTINCT p.id) 3 ORDER BY h.ride_cnt DESC;ST_DWithin加上geography类型后距离自动按球面距离计算单位是米省去了手动做投影转换的麻烦。HAVING 条件保证至少关联到 3 个 POI 才认定热点语义可解释否则可能只是临近某个偏僻设施的孤立网格。4.2 按时间段切片热点是流动的城市热点不是静态分布。同一个滨江公园早高峰是通勤骑行者的必经路周五晚上是休闲骑的聚集地。把 H3 聚合按recorded_at小时切片可以观察热点在一天里的动态转移——这是最有价值的分析维度之一。实践上把一天切成五个时段早高峰06:00-09:00、午间11:00-14:00、晚高峰17:00-20:00、晚间休闲20:00-23:00、深夜23:00-06:00。对每个时段分别跑一遍 H3 聚合可以求出每个格网的时间热度和“时段热度偏移量”。def parse_period(hour): if 6 hour 9: return morning_peak elif 11 hour 14: return midday elif 17 hour 20: return evening_peak elif 20 hour 23: return night_leisure else: return late_night route_df[period] route_df[recorded_at].dt.hour.map(parse_period) # 每个格网按时段统计 period_heat route_df.groupby([h3_index, period]).size().reset_index(namecnt) # 找出每个格网最活跃的时段 pivot period_heat.pivot_table(indexh3_index, columnsperiod, valuescnt, fill_value0) pivot[dominant_period] pivot.idxmax(axis1) pivot[dominant_ratio] pivot.max(axis1) / pivot.sum(axis1)dominant_ratio的用途很关键它表示最活跃时段占全天骑行量的比例。这个值高比如超过 0.6说明该格网的活跃时段高度集中如果是通勤路线定位就非常清晰比值在 0.3 到 0.5 之间说明全天均匀活跃通常是全天候公共空间或热门商圈类型的热点。4.3 生成可视化热点图与 PDF 报告分析结果最终要交付“城市热点”的呈现方式直接决定报告能不能被看懂。用 ECharts 的散点图加热力图层叠加在地图底图上是最直观的呈现。出图后要导出一份 PDF 报告给业务方或决策层常见做法是 ECharts 在前端渲染大屏展示同时用 Python 的 ReportLab 或 Playwright 截屏生成 PDF 存档。我倾向用 Playwright 把 ECharts 图表截成图片再嵌入 PDF 报告。这样图表和报告布局完全可控底图渲染使用浏览器的 WebGL 能力比纯 Python 画图库更符合“大数据可视化大屏”级别的效果。报告按“城市总览-热点 Top10-时段变化-专项分析”四段组织核心图表不超过 6 页。5. 用自举法验证热点可信度三个值得一试的工程技巧5.1 热点稳定性验证别被几个重度用户带偏热点地图会被少量高频用户的轨迹扭曲成“个人骑行史”——一个每天刷同一段路通勤的骑友贡献的轨迹点可能是几十个普通用户的量。验证热点是否稳定我做自举抽样从ride_cnt维度随机抽取同数量的骑行记录重复跑 H3 聚合看热点格网排名变化多少。需要对网格排名使用 bootstrap 方法估计置信区间从总体骑行轨迹中抽样 100 次每次抽总记录数的 70%然后观察热点格网进入 Top 10 的频率。如果某个格网只在含特定几个用户的抽样里出现它的稳定性指数就低报告里应当降权或标注保留。5.2 热点的最小有效样本量检验九个等级 H3 格网面积为 0.105 平方公里这个区域内至少有 3 次独立骑行才能把格网判定为“候选热点”少于 3 次独立骑行的格网直接剔除它们的出现可能是单次骑行沿路的连续性产生的伪聚集成团。hotspot_candidates heat_df[heat_df[ride_cnt] 3].copy() hotspot_candidates hotspot_candidates[hotspot_candidates[point_cnt] 10].copy()point_cnt 10的过滤条件排除了哪些情况呢配速 20km/h 的骑行者穿过一个 174 米宽的 H3 格网约需 30 秒。如果按每秒采样一个点计算正常穿行约产生 30 个点少于 10 个点时那只是擦了个边的轨迹残留对应的热度不可靠。5.3 报告里的“热点”标注应同时给出置信范围交付 PDF 报告时不要只标一个点或一片多边形而应标注“热点范围 推荐半径 精度提示”。例如“滨江绿道桥下空间热点范围约 0.2 平方公里中心点精度约正负 80 米”。这个精度值来自 H3 格网点到质心的平均偏移量它直接告诉业务方数据的可靠边界。要让这个标注自动化在 H3 聚合完成后额外算每个格网的离散度指标用格网内所有轨迹点的标准差椭圆来表示主方向与扩散范围。热点是沿江的带状分布还是环湖的面状分布报告图上一眼就能看出差别。这个细节对城市规划和商业选址类的报告尤其有价值也是区分专业报告和花架子报告的一个明显的差异点。本文还有配套的精品资源点击获取 从骑行轨迹到城市热点：基于H3格网与空间聚类的热点识别工程实践
简介基于共享单车骑行大数据面向城市数据分析师、规划研究者及共享出行从业者的一份PDF报告聚焦成都文艺场所热点挖掘。报告源自第一财经商业数据中心与ofo小黄车的联合研究以真实骑行订单为样本结合大众点评热度系统分析茶馆、书店、博物馆、美术馆、酒吧等城市文化空间的骑行特征与人群偏好呈现武侯区、锦江区等区域的文艺生活图谱并为城市规划与公共设施优化提供数据决策视角。文件为单个PDF文档大小2.24MB内容完整共1份文件便于直接阅读或归档。目前已吸引73人学习使用。读者可从报告中获取完整的数据说明、分析方法与可视化结论包括各场所骑行距离、时段分布、年龄与性别差异如90后男性更倾向美术馆与酒吧、工作日与周末骑行波动等尤其适合用作文旅消费洞察、城市空间研究或数据报告写作的参考案例。1. 骑行数据不是白骑的热点地图才是骑行的“副产品”每天打开骑行 App 记录轨迹最终只换来自行车的里程数和朋友圈的几张照片这其实是一种浪费。骑行轨迹里每一秒都在产生 GPS 坐标点把大量骑行者的轨迹汇聚起来就能看到一座城市真实的“生活温度”清晨的滨江绿道、午间写字楼旁的咖啡店、深夜仍在亮灯的小吃街、周末的郊野公园这些都会以热力分布的形式呈现出来。所谓“寻找城市热点”不是搜索关键词而是从空间统计的角度找到人流、车流、停留行为在空间上的聚集区域。这个思路可以落到一个能交付的工程结果上把骑行轨迹清洗入库做网格密度聚合再用 H3 六边形格网做热点分级最后把结果输出成带图表的 PDF 报告。这篇文章就按这条链路展开适合做城市数据分析、LBS 应用开发或有骑行数据源的团队参考。你不需要有 Hadoop 集群撑场面一台 8 核 16G 的机器加 PostGIS 就够跑完一个中等城市的全年数据。2. 骑行轨迹采集与预处理从 GPS 坐标点到可用轨迹段2.1 原始骑行数据长什么样无论是从自行车码表、运动手表还是手机 App 导出骑行数据的标准交换格式通常是 FIT、GPX 或 CSV。GPX 是最容易处理的格式XML 结构里按trkpt节点记录经纬度、海拔和时间。CSV 更简单但各家厂商的列名五花八门常见的有latitude、longitude、timestamp也有直接写lat、lon的。处理的第一步不是写算法而是统一 schema。原始骑行数据标准化字段CSV 为例 字段名 类型 说明 ride_id string 单次骑行ID device_id string 设备标识 lat double 纬度WGS84 lon double 经度WGS84 alt double 海拔米 speed double 即时速度km/h recorded_at timestamp 记录时间这里有一个容易踩坑的地点坐标系。绝大多数民用 GPS 设备输出的是 WGS84 经纬度但国内很多地图 SDK 和行政区划边界数据用的是 GCJ-02火星坐标或 BD-09百度坐标。如果直接把 WGS84 坐标叠加到高德底图上做热力可视化错位会在 100 米到 600 米之间热点中心直接偏移到隔壁街区。做数据处理这一层统一存 WGS84输出展示层再做转换不要在入库阶段混用。2.2 清洗脏数据漂移点、静止点和跳变点GPS 在城市峡谷环境里表现并不稳定——高架桥下、隧道口、密集高楼区间卫星信号反射会带来几十米的定位跳动。这些漂移点放到热力聚合里会在马路上凭空造出一片“虚拟热点”。清洗逻辑按以下三步处理按轨迹连续性剔除速度异常点。两点间距离除以时间差如果瞬时速度超过 70km/h——普通自行车不可能达到——直接标记为漂移点。过滤静止点。速度小于 1km/h 且持续时间超过 180 秒的点说明骑行者已经停下休息或逛店这类点单独归类为“停留点”用于后续挖掘但不参与线路热力聚合。按轨迹分段打断。相邻两个点时间间隔超过 5 分钟或者距离超过 500 米断开为两条轨迹。因为用户可能中途停顿后继续骑行中间缺失段如果强行连线会画穿建筑物。用 Python 处理时我常用 GeoPandas 做向量化操作而不是逐行 for 循环。几百万行的轨迹点逐行用 Python 循环要跑几分钟向量化几十秒就能完成。import pandas as pd import geopandas as gpd from shapely.geometry import Point from datetime import timedelta df pd.read_csv(raw_rides.csv, parse_dates[recorded_at]) df df.sort_values([ride_id, recorded_at]) # 用 groupby 做组内差分避免循环 grouped df.groupby(ride_id) df[prev_time] grouped[recorded_at].shift(1) df[prev_lat] grouped[lat].shift(1) df[prev_lon] grouped[lon].shift(1) # 计算每段距离与速度Haversine 简化为等距近似 df[d_lat] (df[lat] - df[prev_lat]) * 111320.0 df[d_lon] (df[lon] - df[prev_lon]) * 111320.0 * (df[lat].radians.cos() if False else 0.8) # 简化场景直接用 scipy 或 geopy 计算实际工程里用矢量化的 haversine 函数 df[seg_dist] ((df[d_lat]**2 df[d_lon]**2) ** 0.5).fillna(0) df[seg_time_s] (df[recorded_at] - df[prev_time]).dt.total_seconds().fillna(0) df[seg_speed] df[seg_dist] / df[seg_time_s].replace(0, 1) * 3.6 # m/s - km/h # 剔除漂移点速度 70km/h df df[df[seg_speed] 70.0] # 标记静止点速度小于 1km/h 且持续超过 180 秒 df[is_stop] (df[seg_speed] 1.0) (df[seg_time_s] 180) stops df[df[is_stop]].copy() # 线路热力只保留非静止点或静止时间很短的轨迹 route_df df[~df[is_stop] | (df[seg_time_s] 30)].copy()代码里关键点在于用groupby加shift一次算出前后点差而不是循环每个点。速度计算必须在每个骑行 ID 内部做跨 ID 计算会算出从上一段终点到下一段起点的假速度容易误删数据。静止点单独存一份后面做停留热点分析还会用到。2.3 轨迹分段和路网匹配的取舍清洗后的轨迹可以直接做热力聚合但存在一个空间分布不均的问题骑行者在马路上是“线状”运动原始点在道路上的分布密度与道路等级相关主干道天然比小巷子点多。如果直接用点做热力渲染结果会偏向主干道真正有意思的“热点”——比如某个小巷子口的网红店、某个公园的隐藏入口——反而不容易被识别出来。两种常见做法不做路网匹配直接网格聚合。适合“哪个区域骑行强度高”这类宏观问题处理成本低数据量几百万点也不怕。做路网匹配Map Matching把 GPS 点投影到 OpenStreetMap 路网上再聚合。适合“哪条具体街道最热门”这类微观问题准确度高但要引入 Valhalla 或 GraphHopper 这类服务还要处理路网数据的时效性。对城市热点发现这个目标我更推荐先做网格聚合不做路网匹配。热点本身是一个区域概念不是一个点概念网格聚合天然带有空间平滑效应能容忍 GPS 的定位误差也不会因为路网数据缺了某条新建道路而漏掉热点。3. 热点识别算法选型与参数调优从密度聚类到格网评分3.1 三种主流方案的对比拿到清洗后的轨迹点做热点识别有三种成熟的技术路径方案原理优点缺点适用场景固定网格密度计数把城市切成等大的格子统计每个格子内的轨迹点/轨迹段数量实现简单计算快可解释性强网格边界生硬热点会被切到两个格里初筛、宏观热力发布H3 六边形格网聚合Uber 开源的六边形索引体系层级固定面积均匀六边形没有边角偏差按层级缩放方便引入外部依赖概念要额外学习城市级热点分级DBSCAN 空间聚类基于密度的聚类算法自动发现任意形状的聚类不需要预设网格能发现任意形状热点参数需要调大数据量下要配合空间索引发现点状热点例如停车点聚集区固定网格的最大问题是摩尔纹效应——同一片热点区域如果网格平移半个格宽聚合结果就会拆成两片小热点看起来像网格纹理干扰城市尺度上的判断。H3 六边形格网在这个问题上比正方形网格好得多六个邻居完全对称热点区域的连续性更好。DBSCAN 则完全摆脱网格的约束更适合找到“点状”热点——诸如共享单车停放潮汐点、骑行者的聚集起点。3.2 用 H3 做城市骑行热度聚合的具体实现H3 的分辨率 9 级六边形单格面积约为 0.105 平方公里半径约 174 米适合识别城市游憩热点。如果用 10 级面积缩到约 0.015 平方公里能识别街区级热点但噪声也随之增加。做完清洗全量轨迹点后实际实施如下import h3 import numpy as np import pandas as pd # 假设 route_df 已清洗完成包含 lat、lon 列 RESOLUTION 9 # 为每个轨迹点绑定 H3 六边形 ID route_df[h3_index] route_df.apply( lambda row: h3.latlng_to_cell(row[lat], row[lon], RESOLUTION), axis1 ) # 每格有效骑行轨迹点数 cell_counts route_df.groupby(h3_index).size().reset_index(namepoint_cnt) # 每格经过的独立骑行次数去重 ride_id cell_rides route_df.groupby(h3_index)[ride_id].nunique().reset_index(nameride_cnt) # 每格累计骑行时长分钟 cell_duration route_df.groupby(h3_index)[seg_time_s].sum().reset_index(nametotal_sec) cell_duration[total_min] cell_duration[total_sec] / 60.0 # 合并三项指标 heat_df cell_counts.merge(cell_rides, onh3_index).merge(cell_duration, onh3_index) # 构造 GeoDataFrame 便于后续出图或写 PostGIS heat_df[geometry] heat_df[h3_index].apply(lambda x: h3.cell_to_latlng(x))注意这段代码里用apply逐行绑定 H3 ID数据量大时性能偏慢但胜在逻辑简单清晰。对百万级点跑完约需几十秒可以接受。如果到了千万量级用h3的向量化 API 或 PySpark UDF逻辑不变。热点不是靠单一指标决定的。point_cnt代表骑行强度ride_cnt代表覆盖的骑行者规模total_min代表在这片区域花的时间长短。三个指标的组合视角完全不一样point_cnt高而ride_cnt低说明是几个重度用户反复刷出来的路段point_cnt中等而ride_cnt高说明是广泛人群经过的公共通道后者作为城市热点的意义更大。3.3 DBSCAN 识别停留点聚集区骑行路线热力适合回答“哪里骑得多”却回答不了“哪里值得停下来”。城市的消费热点恰恰是后者——人们愿意停下来花时间的地方。把 2.2 节里单独保存的stops表拿出来对停留点做 DBSCAN 聚类可以自动圈出聚集区。这里需要调两个参数eps邻域半径城市尺度建议 200 到 300 米。太小会把一个商圈拆成几个簇太大把两个相邻商圈合并成一团。min_samples最少样本数建议 20 到 50。设定在 20 意味着至少 20 次有效停留才算一个候选热点。from sklearn.cluster import DBSCAN import geohash2 # 停留点转弧度坐标供 DBSCAN 使用用米制距离需要转投影这里用简化的球面距离 coords stops[[lat, lon]].values # 粗略把经纬度换算成公里量级适配 eps0.3 公里 coords_km np.column_stack([ coords[:, 0] * 111.0, coords[:, 1] * 111.0 * np.cos(np.radians(coords[:, 0])) ]) clustering DBSCAN(eps0.3, min_samples20, metriceuclidean).fit(coords_km) stops[cluster_id] clustering.labels_ # 聚合每个簇的停留强度 stop_hotspots stops[stops[cluster_id] 0].groupby(cluster_id).agg( stop_count(ride_id, count), avg_duration_min(seg_time_s, mean), lat(lat, mean), lon(lon, mean) ).reset_index() stop_hotspots stop_hotspots[stop_hotspots[stop_count] 20].sort_values(stop_count, ascendingFalse)DBSCAN 的问题在于eps在低纬度和高纬度地区对应的实际距离差异很大代码里用cos(lat)做了一次近似修正把经度方向的真实距离拉平到公里尺度。这样在在中国从哈尔滨到三亚的范围内参数都不需要重新调整。聚类的中心点坐标是所有停留点的均值不是实际存在的某个 POI 位置后续步骤里要拿它去关联附近的商户或地标而不是直接把坐标交给地图渲染。3.4 热点分级不能用裸的轨迹点数量一刀切聚合完成后会得到几百上千个候选格网但报告里不可能展示全部。热点分级用“帕累托法则”思路处理分数排序后前 5% 为一级热点5% 到 20% 为二级热点其余为三级。评分公式综合骑行强度、骑行者覆盖规模和停留时长hotspot_score zscore(log(point_cnt)) * 0.3 zscore(log(ride_cnt)) * 0.4 zscore(log(total_min)) * 0.3取对数是因为轨迹点数量呈长尾分布少数格网占据绝大多数点数直接取原始值会让少数主线道路垄断所有高分热点。综合评分后热点排名就不会永远是滨江大道这样的骑行主干道——停留时长这一项会把商圈、景点、咖啡馆聚集区顶上来这才是“城市热点”而非“骑行路线热力”。4. 结合路网与 POI 数据识别热点属性骑行者到底去了哪4.1 从热点格网到语义标签H3 网格和 DBSCAN 聚类只能告诉你在“哪个六边形里人多”没告诉你人为什么多。热点没有语义标签做出来的城市热点地图就是一张热力图始终停留在视觉层。要让结果变得真正可交付下一步是把热点与城市的基础设施数据进行叠加关联通常接入的是三类数据OpenStreetMap 路网数据判定热点是否沿绿道、主干道分布。POI 数据包括餐饮、购物、景点、居住小区、办公园区用于打标签。行政区划或城市功能区划数据标注热点在哪个商圈、哪个街道。这一步的实际操作分两类情况。如果热点格网比较小而且密集可以直接用空间连接把 POI 关联到格网里如果热点是分散的小簇以 3.3 节得到的聚类中心点做缓冲区查询更合适因为 POI 和停留点中心并不完全重合。缓冲区半径通常取 300 到 500 米对应骑行者的步行活动半径。-- 使用 PostGIS 做空间连接标注热点区域的 POI 分布 SELECT h.h3_index, h.ride_cnt, h.total_min, string_agg(DISTINCT p.category, , ) AS poi_categories, count(DISTINCT p.id) AS poi_count FROM heat_df h JOIN poi_table p ON ST_DWithin( ST_SetSRID(ST_MakePoint(h.lon, h.lat), 4326)::geography, p.geom::geography, 500 ) GROUP BY h.h3_index, h.ride_cnt, h.total_min HAVING count(DISTINCT p.id) 3 ORDER BY h.ride_cnt DESC;ST_DWithin加上geography类型后距离自动按球面距离计算单位是米省去了手动做投影转换的麻烦。HAVING 条件保证至少关联到 3 个 POI 才认定热点语义可解释否则可能只是临近某个偏僻设施的孤立网格。4.2 按时间段切片热点是流动的城市热点不是静态分布。同一个滨江公园早高峰是通勤骑行者的必经路周五晚上是休闲骑的聚集地。把 H3 聚合按recorded_at小时切片可以观察热点在一天里的动态转移——这是最有价值的分析维度之一。实践上把一天切成五个时段早高峰06:00-09:00、午间11:00-14:00、晚高峰17:00-20:00、晚间休闲20:00-23:00、深夜23:00-06:00。对每个时段分别跑一遍 H3 聚合可以求出每个格网的时间热度和“时段热度偏移量”。def parse_period(hour): if 6 hour 9: return morning_peak elif 11 hour 14: return midday elif 17 hour 20: return evening_peak elif 20 hour 23: return night_leisure else: return late_night route_df[period] route_df[recorded_at].dt.hour.map(parse_period) # 每个格网按时段统计 period_heat route_df.groupby([h3_index, period]).size().reset_index(namecnt) # 找出每个格网最活跃的时段 pivot period_heat.pivot_table(indexh3_index, columnsperiod, valuescnt, fill_value0) pivot[dominant_period] pivot.idxmax(axis1) pivot[dominant_ratio] pivot.max(axis1) / pivot.sum(axis1)dominant_ratio的用途很关键它表示最活跃时段占全天骑行量的比例。这个值高比如超过 0.6说明该格网的活跃时段高度集中如果是通勤路线定位就非常清晰比值在 0.3 到 0.5 之间说明全天均匀活跃通常是全天候公共空间或热门商圈类型的热点。4.3 生成可视化热点图与 PDF 报告分析结果最终要交付“城市热点”的呈现方式直接决定报告能不能被看懂。用 ECharts 的散点图加热力图层叠加在地图底图上是最直观的呈现。出图后要导出一份 PDF 报告给业务方或决策层常见做法是 ECharts 在前端渲染大屏展示同时用 Python 的 ReportLab 或 Playwright 截屏生成 PDF 存档。我倾向用 Playwright 把 ECharts 图表截成图片再嵌入 PDF 报告。这样图表和报告布局完全可控底图渲染使用浏览器的 WebGL 能力比纯 Python 画图库更符合“大数据可视化大屏”级别的效果。报告按“城市总览-热点 Top10-时段变化-专项分析”四段组织核心图表不超过 6 页。5. 用自举法验证热点可信度三个值得一试的工程技巧5.1 热点稳定性验证别被几个重度用户带偏热点地图会被少量高频用户的轨迹扭曲成“个人骑行史”——一个每天刷同一段路通勤的骑友贡献的轨迹点可能是几十个普通用户的量。验证热点是否稳定我做自举抽样从ride_cnt维度随机抽取同数量的骑行记录重复跑 H3 聚合看热点格网排名变化多少。需要对网格排名使用 bootstrap 方法估计置信区间从总体骑行轨迹中抽样 100 次每次抽总记录数的 70%然后观察热点格网进入 Top 10 的频率。如果某个格网只在含特定几个用户的抽样里出现它的稳定性指数就低报告里应当降权或标注保留。5.2 热点的最小有效样本量检验九个等级 H3 格网面积为 0.105 平方公里这个区域内至少有 3 次独立骑行才能把格网判定为“候选热点”少于 3 次独立骑行的格网直接剔除它们的出现可能是单次骑行沿路的连续性产生的伪聚集成团。hotspot_candidates heat_df[heat_df[ride_cnt] 3].copy() hotspot_candidates hotspot_candidates[hotspot_candidates[point_cnt] 10].copy()point_cnt 10的过滤条件排除了哪些情况呢配速 20km/h 的骑行者穿过一个 174 米宽的 H3 格网约需 30 秒。如果按每秒采样一个点计算正常穿行约产生 30 个点少于 10 个点时那只是擦了个边的轨迹残留对应的热度不可靠。5.3 报告里的“热点”标注应同时给出置信范围交付 PDF 报告时不要只标一个点或一片多边形而应标注“热点范围 推荐半径 精度提示”。例如“滨江绿道桥下空间热点范围约 0.2 平方公里中心点精度约正负 80 米”。这个精度值来自 H3 格网点到质心的平均偏移量它直接告诉业务方数据的可靠边界。要让这个标注自动化在 H3 聚合完成后额外算每个格网的离散度指标用格网内所有轨迹点的标准差椭圆来表示主方向与扩散范围。热点是沿江的带状分布还是环湖的面状分布报告图上一眼就能看出差别。这个细节对城市规划和商业选址类的报告尤其有价值也是区分专业报告和花架子报告的一个明显的差异点。本文还有配套的精品资源点击获取