很多人第一次接触百度热力图、百度慧眼这类数据时,第一反应都是:终于有免费的人口分布数据可以用了。真拿到手才发现,原始的慧眼数据跟你在网页上看到的那个红红蓝蓝的热力图完全是两回事。网页上看到的是已经加工渲染好的结果,而慧眼原始数据是一堆按网格聚合的人口规模数值,少则几十万行,多则上百万行,字段含义需要对着文档反复猜,坐标系统还需要自己处理。我最早做城市活力分析项目时,光是把这份数据处理成能用的状态,就折腾了将近两周。这篇教程就是把我后来整理成体系的数据处理流程和活力计算逻辑完整拆开来讲,覆盖从拿到百度慧眼原始网格数据,到做数据清洗、时空聚合,再到计算活力指数并落图成热力图的完整环节。
这套方法和流程更适合城市规划、商业选址、地理数据分析、时空大数据挖掘方向的从业者和学生。无论你是刚接触到慧眼数据的新手,还是已经被网格数据折磨过一轮的“准熟手”,这篇内容都可以作为一份直接对照操作的手册来用。我尽量把每个步骤背后的原因也讲清楚:为什么这样清洗、为什么这样聚合、为什么用这几个指标算活力。
1. 这套教程到底在解决什么问题
1.1 为什么城市研究的人都在盯百度热力图
把时间拨回几年前,城市规划领域想拿到一份覆盖全城、逐小时更新的人口分布数据,几乎是不可想象的。传统的解决办法只有几种:要么等人口普查(十年一次,街道级精度),要么靠手机信令数据(需要跟运营商谈合作,流程长、价格高),要么发问卷做抽样调查(成本高、覆盖有限)。所以当百度地图推出热力图功能的时候,搞城市研究的人眼睛都亮了——这玩意儿每天实时更新,能反映某个区域此时此刻有多少人,简直是城市活力度量最理想的数据源。
但是问题也随之而来:你在百度地图App上看到的那个热力图,是渲染好的图片,只能看,不能下载,也不能做定量分析。真正做研究、做商业选址评估,需要的是热力图背后的数值数据,也就是某个网格单元里到底有多少人。百度慧眼的数据服务解决的正是这个需求——它把脱敏聚合后的人口栅格数据提供给研究者和企业用户,让大家在合规的前提下拿到可用于定量分析的数据。这也是整个项目链条的起点:先解决数据可得性问题,再谈处理和计算。
1.2 数据处理的完整链条是什么
从拿到百度慧眼原始数据,到最终生成一张可用的城市活力热力图,中间要经过一个不算短的处理链条。我把它拆成四个核心环节,这也是整套视频教程的章节骨架:
- 数据理解与格式规范化:理解每个字段的含义,统一时间格式、坐标系、字段命名。这一步做得越扎实,后面就越省事。
- 数据质量处理:处理缺失值、异常值、重复记录,处理网格在行政边界上的“半网格”问题。
- 时空聚合与重映射:把原始的小时级格网数据,按研究需求聚合到日、周、月等时间尺度,或者按街道、商圈等空间尺度重新汇总。
- 活力指数计算与可视化输出:基于处理好的时空数据,构建活力评价指标体系,计算每个网格的活力得分,最终用热力图库渲染成图。
整个流程的核心逻辑可以概括为一句话:原始数据是“原料”,处理流程是“烹饪”,活力热力图是“成品”。很多人拿到数据就急着想画图,跳过了中间最关键的质量处理和聚合环节,最后画出来的图可能看着挺热闹,但数据口径一查全是漏洞,这样的结论是不可靠的。
1.3 适合谁来读这篇教程
说句实在话,这篇教程不太适合完全没接触过数据分析的人。你至少需要知道Pandas的基本操作,比如DataFrame的读写、groupby聚合这类操作。但如果你已经具备这些基础,只是不知道百度慧眼数据具体长什么样、里面的字段都是什么意思、活力指数到底怎么算,那么这篇内容就是为你准备的。
我自己也是从零开始一点点踩过来的。最开始连这个数据的坐标系是什么都不知道,直接把经纬度画到图上,结果点位偏了十万八千里。后来看了很多资料,又查了百度地图开放平台的技术文档,才知道慧眼数据用的是百度坐标系(BD-09),而常用的底图可能是WGS-84坐标系或者GCJ-02坐标系,坐标系不统一,位置必然漂移。这种坑,不实际拿数据跑一遍,光看书是学不会的。这篇教程就是要把这类经验一次性讲透。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 百度慧眼数据源的底层逻辑
2.1 慧眼数据是怎么来的
百度慧眼是百度地图旗下的大数据解决方案品牌,核心数据来源是百度地图App的定位数据、百度系产品的用户授权数据等。每天产生的定位请求量级极大,覆盖的城市和区域范围也非常广泛。但这里要强调一点:所有输出给研究者和企业用户的数据,都是经过严格脱敏和聚合处理的,你拿到的数据里不存在任何个体级别的信息。
数据的基本形式是空间网格。百度慧眼通常会把城市或研究区域划分成一定边长的正方形网格,比较常见的有500米乘500米、1公里乘1公里的规格。每个网格记录某个时间段内的人口规模数值或相关指标。网格化处理有几个好处:第一是隐私安全,网格级别聚合后的数据无法反推出个人位置;第二是计算方便,规则网格比不规则的行政区边界更容易做空间运算;第三是时间可比性,同一个网格在不同时间点的数值可以直接比较,这为后面计算活力变化打下了基础。
2.2 数据结构长什么样
以我拿到过的数据为例,慧眼数据的表结构通常包含几个核心字段。不同版本的交付数据在字段命名上可能稍有出入,但逻辑差不多:
| 字段名 | 字段含义 | 说明 |
|---|---|---|
| grid_id | 网格唯一编码 | 用于标识一个空间网格单元,通常与网格原点坐标绑定 |
| lng / lat | 网格中心点坐标 | 一般是百度坐标系(BD-09),经纬度单位是度 |
| time | 时间戳 | 记录该条数据对应的时间点,粒度可能是小时或天 |
| population / count | 人口数量 | 该网格在对应时间点的活跃人口数量估计值 |
| work / live / dwell | 工作/居住/到访类型 | 部分数据按人口行为类型拆分,用于区分工作人口和居住人口 |
| area | 网格面积 | 可用于计算人口密度 |
先别急着用数据,逐字段确认含义非常关键。我见过不少同学拿到数据就开始groupby,结果跑完了才发现有个字段理解偏了,整个结果全得推翻重来。比如有的数据给出的不是某个时间点的瞬时人口,而是某段时间内的累积到访人次,两者的量纲完全不同,计算出来的“活力”含义也完全不一样。
2.3 数据获取的合规与注意点
关于数据获取渠道,这里多说几句。百度慧眼面向企业用户和科研机构提供数据服务,通常需要走正式的商务或合作流程。如果是高校科研使用,可以尝试通过学校与百度相关团队建立合作关系;如果是企业项目,可以直接联系百度智能云或百度地图开放平台,咨询慧眼数据的商务获取方式。
我的建议是不要试图通过爬虫手段去抓百度地图的热力图瓦片。一方面技术上行不通,热力图瓦片拿到的是渲染后的颜色值,不同颜色对应的人口密度区间没有统一标准,数值精度无法保证,做定量分析基本没有意义;另一方面这也涉及数据合规风险。既然慧眼已经提供了正规数据服务,走正规渠道获取数据,做出来的研究才能经得起检验。
3. 原始数据拿到手之后,清洗这一步要做对
3.1 环境准备与读取原始数据
进入实际处理的环节。我默认大家的开发环境是Python 3.8以上版本,核心依赖是Pandas、NumPy、Geopandas,如果后续要做空间可视化,还会用到Pyecharts、Folium等库。直接贴一个依赖清单,便于大家对照安装。
code复制pip install pandas numpy geopandas pyecharts folium
原始数据一般以CSV或者Excel格式交付,也有部分项目会直接给Shapefile格式的矢量网格。如果是CSV,读取本身很简单,但要注意编码问题——很多数据服务商交付的CSV文件带BOM头,不指定编码方式读取的时候第一列列名会出现奇怪的字符。推荐统一用下面的方式读取:
python复制import pandas as pd
df = pd.read_csv('huiyan_raw.csv', encoding='utf-8-sig')
print(df.head())
print(df.info())
先看字段名和数据类型,确认列数、行数、是否有明显的解析异常。这一步不需要做任何转换,纯粹建立对数据整体面貌的感知。
3.2 坐标系统一:忽略它,你画出来的图全是偏的
在国内做地理数据处理,坐标系问题是怎么绕都绕不开的。百度慧眼的数据一般使用百度坐标系(BD-09),而常见的开源底图如OpenStreetMap使用WGS-84坐标系,高德地图使用GCJ-02坐标系。如果拿BD-09的经纬度直接画到WGS-84底图上,点位会发生明显的偏移,在城区尺度上这个偏移量可能会有几百米,对于五百米网格来说足以让整个空间分析错位。
处理办法有两条路径。第一条:如果后续全部使用百度地图体系的底图做可视化,那就不需要做任何坐标转换,数据加载直接对齐。第二条:如果使用其他底图,或者需要和WGS-84/GCJ-02来源的数据做空间叠加分析,就必须先转坐标。
WGS-84转GCJ-02、GCJ-02转BD-09的算法代码在社区里已经很成熟了,基本是公开的标准算法。我自己习惯的做法是写一个独立的坐标转换模块,把共用的转换函数封装好,方便多个脚本调用:
python复制import math
def gcj02_to_bd09(lng, lat):
# 标准 GCJ-02 转 BD-09 算法
x_pi = 3.14159265358979324 * 3000.0 / 180.0
x = lng
y = lat
z = math.sqrt(x * x + y * y) + 0.00002 * math.sin(y * x_pi)
theta = math.atan2(y, x) + 0.000003 * math.cos(x * x_pi)
bd_lng = z * math.cos(theta) + 0.0065
bd_lat = z * math.sin(theta) + 0.006
return bd_lng, bd_lat
def bd09_to_gcj02(bd_lng, bd_lat):
# 标准 BD-09 转 GCJ-02 算法
x_pi = 3.14159265358979324 * 3000.0 / 180.0
x = bd_lng - 0.0065
y = bd_lat - 0.006
z = math.sqrt(x * x + y * y) - 0.00002 * math.sin(y * x_pi)
theta = math.atan2(y, x) - 0.000003 * math.cos(x * x_pi)
gcj_lng = z * math.cos(theta)
gcj_lat = z * math.sin(theta)
return gcj_lng, gcj_lat
拿到数据后先检查数据交付说明中标注的坐标系,不要想当然。如果交付文档没写,可以直接拿几个已知地物的坐标做交叉验证,比如把数据中的某个标志性地点坐标和地图上的实际坐标对比一下,偏移量几百米基本就能判断出坐标系类型了。
3.3 缺失值和异常值处理:宁缺毋滥,但不要错杀
地理网格数据的缺失值和异常值处理和普通表格数据不太一样。普通数据缺失了可以填充均值,但网格数据的空间属性意味着某一网格缺失值不能简单用全局均值填,因为城市中心网格和远郊网格的人口数量可能差了两个数量级。
我实际处理中的做法分几步:
第一步,检查缺失值整体规模。如果某个时间切片缺失网格占比超过50%,基本说明这个时间点的数据质量不可靠,直接整层丢弃比强行插补更合理。如果只是零星缺失,可以采用KNN插值法,基于空间邻近网格的数值来估算缺失网格的值,这在Geopandas里做空间连接后就能实现。
第二步,识别异常值。网格人口数据的异常主要表现为两类:一类是单个网格数值远高于邻域同类网格,可能是数据源在该网格存在统计异常;另一类是同一网格在相邻时间点的数值发生剧烈跳变,比如凌晨2点是500人,凌晨3点突然变成3000人,这种大概率也是异常。
我常用的检测方法是基于空间和时间两个维度计算Z-Score:
python复制import numpy as np
# 空间维度:按网格计算邻域均值,再算偏离程度
df['z_spatial'] = (df['population'] - df['population_mean_neighbor']) / df['population_std_neighbor']
# 时间维度:同一网格相邻时段的差值
df_sorted = df.sort_values(['grid_id', 'time'])
df_sorted['pop_diff'] = df_sorted.groupby('grid_id')['population'].diff().abs()
df_sorted['pop_diff_z'] = (df_sorted['pop_diff'] - df_sorted['pop_diff'].mean()) / df_sorted['pop_diff'].std()
对于Z-Score绝对值大于3的记录,先标记出来人工抽检,而不是直接删除。因为有些看似异常的数值可能是真实事件带来的,比如大型演唱会、体育赛事导致的局部人口激增,这种“异常”对活力研究来说恰恰是极其重要的信号,删掉反而丢失了信息。所以异常值处理的原则是:先标记,再理解,最后再决定去留。
3.4 网格ID的编码与空间关联
慧眼数据的网格ID本身是一个编码体系,但不同项目交付的编码方式可能不一致。有些是纯数字流水号,有些是“行号-列号”形式的组合编码,有些直接把网格左上角坐标拼进了ID里。分析之前,先把网格ID和真实地理位置的对应关系理清楚,这一步能用空间校验的方式确保编码体系的理解没问题。
我的做法是把网格的中心经纬度转换成Geopandas的GeoDataFrame,然后和行政区划边界做空间连接,给每个网格打上所属的区县、街道标签。这样做的好处非常直接:后续做活力分析时,可以随时按行政区划维度汇总数据,比如直接算出某个商圈覆盖的所有网格的总活力,而不需要回到原始表里去手工筛选。
python复制import geopandas as gpd
from shapely.geometry import Point
gdf = gpd.GeoDataFrame(
df,
geometry=[Point(xy) for xy in zip(df['lng'], df['lat'])],
crs='EPSG:4326'
)
# 读取行政区划数据,坐标系先统一到 WGS-84
admin = gpd.read_file('city_districts.shp')
admin = admin.to_crs('EPSG:4326')
# 空间连接,给每个网格打上行政区域标签
gdf = gpd.sjoin(gdf, admin, how='left', predicate='within')
这一步执行完,数据表里就多出了区县和街道两个维度的标签字段。后面不论做聚合、做筛选、做对比,都方便很多。这一步千万别省,越早把空间属性补齐,后面分析越顺。
4. 活力计算模型:比想象中更有讲究
4.1 活力指数到底算什么
“活力”这个词在城市研究里有一个经典的定义框架。雅各布斯在《美国大城市的死与生》里提出的街道活力概念,核心是人的存在和人的活动。后来的研究者把活力操作化为“一定时空范围内人口聚集的强度、持续性和多样性”。放到数据层面,对应到百度慧眼数据上,就是人口密度、人口时间分布的波动情况、人口活动的持续性这几个维度。
所以计算活力指数,本质上不是算一个简单的平均值,而是要同时刻画三个层面:某个地方平均水平有多少人(强度)、高峰期和低谷期的落差有多大(波动性)、这个地方全天有多长时间保持活跃(持续性)。这三个维度缺一不可。一个白天人山人海、晚上空无一人的办公区,和一个全天人口稳定的居住区,平均人口可能相近,但城市活力形态差异巨大。
4.2 核心指标的计算逻辑
基于上面的理解,我构建活力指数时通常会算以下几个基础指标。这里以小时级数据为例展开:
平均活跃人口(AvgPop),反映某个网格在统计时段内的人口强度:
code复制AvgPop = sum(population_hourly) / 24
人口密度(PopDensity),把人口数值除以网格面积,消除网格大小不一致的影响(如果数据网格规格统一,这个指标和平均活跃人口只有常数倍差异,但概念上更规范):
code复制PopDensity = AvgPop / GridArea
活跃时长(ActiveHours),统计一天中人口数量超过某个阈值的小时数。这个阈值可以取该网格全天平均人口的50%,或者取整个研究区域人口的某个分位数。这个指标很直观地反映了“这个地方一天当中有多长时间是有人气的”。
时段变异系数(CV),衡量人口数量在一天内的波动程度:
code复制CV = std(population_hourly) / AvgPop
CV值高说明该网格人口在时间维度上分布很不均匀,典型的是纯办公区;CV值低说明人口分布稳定,典型的是成熟居住区。
计算逻辑用Pandas表达很简单,核心是groupby:
python复制hourly_stats = (
df.groupby(['grid_id', 'date'])
.agg(
avg_pop=('population', 'mean'),
max_pop=('population', 'max'),
min_pop=('population', 'min'),
std_pop=('population', 'std'),
active_hours=('population', lambda x: (x > x.mean() * 0.5).sum())
)
.reset_index()
)
hourly_stats['cv'] = hourly_stats['std_pop'] / hourly_stats['avg_pop']
4.3 活力指数的合成:权重设定要与研究目标挂钩
有了基础指标,最后一步是合成一个综合活力指数。常见的做法是极差归一化后加权求和。归一化要把不同量纲的指标统一到0到1的区间,再用线性加权合成。这里最需要警惕的是权重设定不能拍脑袋。权重反映的是研究者对“活力”的理解倾向,不同研究目标对权重的需求完全不同。
如果你做的是商业选址评估,可能更看重平均人口强度,因为零售消费直接依赖人流规模;如果你做的是城市空间品质诊断,可能更看重活跃时长和时段均衡性,不希望城市空间只是“潮汐式”的拥挤;如果你做的是夜间经济评估,可能还要单独给夜间时段的人口赋更高权重。
我一般先做等权重的基准方案,也就是强度、波动性、持续性各占三分之一,得到一份基准活力排名,再按不同场景调权重,做敏感性对比。如果调权重之后排名变动很大,说明城市各地块的活力形态差异明显,这本身就是有价值的分析结论。
以下是一版可执行的活力指数计算代码:
python复制def normalize(s):
return (s - s.min()) / (s.max() - s.min())
hourly_stats['norm_avg_pop'] = normalize(hourly_stats['avg_pop'])
hourly_stats['norm_active_hours'] = normalize(hourly_stats['active_hours'])
# 注意:CV 是负向指标,活力越高 CV 应越低,所以用 1 - normalize
hourly_stats['norm_cv'] = 1 - normalize(hourly_stats['cv'])
# 加权求和,默认等权重
hourly_stats['vitality_index'] = (
hourly_stats['norm_avg_pop'] * 0.4 +
hourly_stats['norm_active_hours'] * 0.3 +
hourly_stats['norm_cv'] * 0.3
)
以办公型区域和居住型区域的对比为例:办公型区域往往平均人口很高,但活跃时段集中在工作时段,CV值很高,active_hours也不算长,综合活力指数会被拉低;居住型区域平均人口中等,但全天人口稳定,active_hours长,CV低,综合活力指数就可能更高。这种结果符合我们对城市活力的直觉:一个地方如果只有白天有“人气”,它的整体活力仍然是脆弱的。
4.4 夜间活力单独建模的必要性
当下城市研究里夜经济是个热门话题,夜间活力也常常被单独拿出来分析。我的习惯是从24小时数据中切出晚间时段(比如18:00到24:00,有人会延伸到凌晨2:00),单独计算夜间活力指数。
夜间活力计算框架和全天活力一致,但对人口强度的权重建议适当调高。因为夜间时段本身人口基数低,活跃时长和CV的意义相对弱化,“你这里能聚到多少人”才是核心问题。我一般用这样的权重组合:夜间平均人口占0.6,夜间活跃时长占0.2,夜间人口稳定性占0.2。
这一维度在实际项目里的应用非常直观:排查一个城市有哪些区域具备夜间消费潜力、哪些区域夜间存在明显的活力洼地,对规划夜市经济带、布置24小时便利店点位都有直接参考价值。
5. 把计算结果画成热力图
5.1 可视化选型的底层逻辑
数据算完了,活力指数已经落到每个网格上,接下来要做的就是把这份空间数据变成视觉上一眼能看懂的热力图。
这里有一个选型问题:直接在地图上渲染网格,还是用热力点的方式渲染?如果网格本身是规则多边形,你其实可以直接把每个网格的活力值填充成对应网格的颜色,这种“真实网格图”的科研感更强,适合论文和报告。如果希望展示效果更平滑、更像公众认知中的百度热力图,那就要做核密度估计或者直接使用热力图库对网格中心点做渲染。
在技术选型上我建议结合使用场景来定:
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 静态论文插图 | Matplotlib / Geopandas | 出图快,支持自定义样式,可直接嵌入论文 |
| 网页交互展示 | ECharts / MapV / L7 | 交互流畅,支持缩放平移、多图层叠加 |
| 快速数据探索 | Folium | 基于Leaflet,三五行代码就能出一张交互图 |
| 大数据量高性能 | Mapbox GL / Deck.gl | WebGL渲染,支持百万级数据点流畅展示 |
我自己在项目里迭代探索阶段用Folium比较多,原因是写起来最快,省时间。方案汇报阶段改用ECharts,因为交互体验好,客户可以直接缩放看细节。论文出图阶段再回到Geopandas,因为矢量出图的清晰度和可编辑性最好。
5.2 基于ECharts的完整代码示例
下面是一段基于ECharts的GeoJSON + 散点热力的核心代码思路,用来在前端渲染活力指数。ECharts的heatmap系列本身不直接支持经纬度,但可以用scatterGL或自定义系列间接实现。更简单的方式是用scatter系列把每个网格中心点画出来,点的大小和颜色由活力值映射,也能达到类似热力图的效果。
javascript复制// 假设后端返回的数据格式
const data = [
{ lng: 116.391, lat: 39.907, value: 0.87 },
{ lng: 116.405, lat: 39.915, value: 0.65 },
// ... 每个网格中心点对应一个活力值
];
const option = {
tooltip: {
trigger: 'item',
formatter: (params) => {
return `活力指数: ${params.value[2].toFixed(3)}`;
}
},
visualMap: {
min: 0,
max: 1,
dimension: 2,
inRange: {
// 白色 -> 黄色 -> 红色,模拟百度热力图的经典配色
color: ['rgba(255,255,255,0)', '#ffffb2', '#fecc5c', '#fd8d3c', '#e31a1c']
}
},
series: [{
type: 'scatter',
coordinateSystem: 'geo',
data: data.map(d => [d.lng, d.lat, d.value]),
symbolSize: 12,
blendMode: 'lighter',
geoIndex: 0
}],
geo: {
map: 'china',
roam: true,
itemStyle: {
areaColor: '#f5f5f5',
borderColor: '#aaa'
}
}
};
这段代码的精髓在于blendMode: 'lighter',这个设置让多个半透明点叠加时颜色自动叠加变亮,从而模拟出热力图的“光晕”效果。点半径大小需要根据地图缩放级别动态调整,不然缩小到城市尺度时点与点之间会粘在一起。
如果追求更规范的热力图效果,我建议直接用MapV或者L7这类专业的地理可视化库。L7的PointLayer配合HeatmapStyleOptions就能做到基于经纬度核密度平滑的热力渲染,视觉上比scatter方案更接近百度地图的热力效果:
javascript复制import { Scene, HeatmapLayer } from '@antv/l7';
import { GaodeMap } from '@antv/l7-maps';
const scene = new Scene({
id: 'map',
map: new GaodeMap({
style: 'light',
center: [116.4, 39.9],
zoom: 11
})
});
const layer = new HeatmapLayer({
source: {
data: data,
parser: { type: 'json', x: 'lng', y: 'lat' }
},
size: {
value: 30,
field: 'value'
},
style: {
intensity: 5,
radius: 30,
opacity: 0.8,
rampColors: {
colors: ['#ffffb2', '#fecc5c', '#fd8d3c', '#e31a1c'],
positions: [0, 0.3, 0.6, 0.9]
}
}
});
scene.addLayer(layer);
到这里,从原始数据到可视化热力图的完整链路就通了。
6. 一个完整的实操案例:城市商业区活力评估
6.1 案例背景与数据准备
这里用一个简化的案例把整个流程串起来。假设我们在分析某城市核心商圈的活力分布,目标是识别出哪些网格在周末和工作日呈现不同的活力模式,为商业布局调整提供参考。
数据用的是百度慧眼某城市连续两周的小时级人口网格数据,网格规格为500米乘500米,时间覆盖范围为周一至周日全天24小时,字段包括网格ID、中心点经纬度、时间、人口数量。
第一步还是读取数据、检查质量、补充行政区划标签,这些按前面章节的逻辑走即可。这里重点演示后续的聚合逻辑。
6.2 按工作日与周末分组计算活力
工作日和周末的人口活动节奏差异很大。工作日的活力峰值集中在早晚通勤和午休时段,周末的活力峰值可能出现在午后和晚间。如果混在一起算一个平均活力,两个时段的不同特征会被掩盖掉。
处理思路是给每条数据标记日期类型,再按网格加日期类型分组计算活力指标:
python复制df['date'] = pd.to_datetime(df['time']).dt.date
df['hour'] = pd.to_datetime(df['time']).dt.hour
df['day_of_week'] = pd.to_datetime(df['time']).dt.dayofweek
df['day_type'] = df['day_of_week'].apply(lambda x: 'weekend' if x >= 5 else 'weekday')
# 按网格 + 日期类型聚合
agg = (
df.groupby(['grid_id', 'day_type'])
.agg(
avg_pop=('population', 'mean'),
max_pop=('population', 'max'),
std_pop=('population', 'std'),
)
.reset_index()
)
agg['active_hours'] = (
df.groupby(['grid_id', 'day_type'])
.apply(lambda g: (g['population'] > g['population'].mean() * 0.5).sum())
.reset_index(name='active_hours')['active_hours']
)
计算完基础指标后,再套用前面写的归一化和权重合成逻辑,分别得到weekday_vitality和weekend_vitality两个列,然后可以对比分析。
6.3 结果解读的常见模式
从这类对比分析里,我经常观察到几种典型模式:
第一种,两侧都高的全能型网格。工作日活力高,周末活力也高,通常是城市级的综合商圈或交通枢纽。这种地方适合布局全时段业态,品牌旗舰店、餐饮综合体会有不错的客流基础。
第二种,工作日高、周末低的潮汐型网格。典型的办公区、产业园,工作日白天人声鼎沸,周末冷清。这里适合做工作日白领生意,轻食咖啡、健身房都有稳定客群,但周末业态要慎重。
第三种,工作日低、周末高的休闲型网格。典型的是大型居住区周边的商业中心,或者郊区的SHOPPING MALL。周末是客流高峰,适合布局体验型业态、亲子娱乐、影院餐饮。
第四种,两侧都低的活力洼地。这种网格如果不是新开发区域,就要警惕是不是存在交通可达性差、公共配套缺失等问题,是城市更新需要重点关注的区域。
这些判断如果只用一张全天平均热力图是看不出来的,必须做了工作日和周末的分维对比才能浮现出来。这也解释了为什么活力计算不能停留在单一指标上,时间维度的拆解是核心价值所在。
7. 踩坑实录:我在这套流程里犯过的错
7.1 网格边界与行政区边界不重合的问题
这是最早坑到我的问题。500米的网格是规则的方形,但行政区边界是曲折的,一个网格可能同时跨越两个行政区。做空间连接时如果直接用predicate='within',跨越边界的网格会被整块划到某一个区里,或者干脆匹配不上。
我采用的解决办法是改用面积占比法:先求网格与行政区边界的交集面积,按面积最大原则给网格归属。或者更精细一点,在做后续聚合分析时,将网格人口按网格落在各行政区的面积比例拆分到不同行政区。后者在统计上更严谨,特别是当边界两侧人口密度差异较大的时候。
7.2 人口数值量纲的确认
不同数据版本的“人口”字段可能含义完全不同。有的版本给的是实时人口存量,有的版本给的是时段累计到访量,有的版本给的是一个指数化的相对值,而不是真实人口数。如果默认它就是真实人口数,后面做密度计算、多城市对比都会出问题。
我现在的习惯是拿到数据后先看交付说明,没有说明就抽几个网格做人工校验。比如找一个已知实际客流的大型商场,对比商场周边网格的数据量级是否在合理范围。这一步虽然笨拙,但能避免后续一路错到底。
7.3 凌晨数据的稀疏问题
凌晨两点到五点的数据量普遍很少,定位请求量骤降,很多网格可能出现人口为0的情况。这不代表那个地方真的空无一人,只是使用百度产品的活跃用户数下降到检测门槛以下。对不区分昼夜直接算全天活力的场景,凌晨大量的0值会把平均人口整体拉低,同时也会拉高CV值,导致城市中心区域的活力评分被系统性低估。
解决方式分两种:如果你关心的是全天整体活力,可以在聚合前先做低置信时段剔除,比如只保留6点到24点的数据,并在方法论里注明口径;如果你的研究关注夜间活力,那么对凌晨数据需要换一套更宽容的阈值判断标准,不能按白天的标准去处理0值。
7.4 多天数据之间的可比性
做两周甚至更长时间段的分析时,要注意不同日期的数据可能存在系统性差异。这种差异可能是数据服务方处理逻辑调整导致的,也可能是季节、天气、节假日等外部因素造成的。最简单有效的处理方式是把数据按“周内工作日-周末-节假日”分层后分别聚合,而不是把所有日期混在一起算均值。节假日单独分一层尤其重要,因为节假日的人口分布规律和工作日、普通周末都有显著差异。
如果手头数据跨度较长,还可以用移动平均或者同比归一化来平滑单日波动,再进入活力计算。我这里不太推荐用STL这种复杂的时间序列分解,对大多数商业分析场景来说,分层聚合已经够用了,跑复杂模型边际收益不高。
另一层容易忽略的是时间字段的时区问题。百度慧眼的数据一般基于北京时间,但如果你拿到的是UTC时间戳,直接聚合会导致小时错位8个小时。读取数据后先确认time字段的时区,统一转换到北京时间再做后续处理。
8. 从数据处理到业务落地的几点体会
项目做到后期,我发现数据处理和活力计算真正的分水岭不在于会不会调库、会不会写算法,而在于是否理解数据口径并敢于做口径判断。百度慧眼的数据虽然质量总体不错,但它本质上是基于百度系产品活跃用户反推的人口分布估计,存在系统性偏差。比如极低龄和极高龄人口在使用智能设备和地图产品上的活跃度偏低,这部分人群在慧眼数据里会被低估;又比如夜间时段数据覆盖下降,导致夜间人口被系统性低估。
那这些偏差怎么处理?一种思路是引入多源数据做校正。我做过一个项目,将百度慧眼数据与手机信令数据做了对比,在两个数据源的共同覆盖时段内计算校正系数,然后用这个系数对慧眼数据的系统偏差做线性校正。这个方法不完美,但在商业项目的时间表内,算是性价比比较高的折中方案。
另一种思路是接受偏差,但保持口径一致。如果数据源、时间范围、处理逻辑保持一致,那么系统偏差在空间上的影响大致均匀,仍然可以用这套数据做横向对比研究。最忌讳的是在分析中途更换数据源或改变处理口径,导致前后数据不可比,那才是真正灾难性的问题。
给新接触这类数据的读者的建议很简单:先不要急着做高级模型,花一周时间把数据拿到手、处理好、画出几张基础图,哪怕只是按小时做一张全天人口曲线,也比对着别人写好的论文结论去套数据要强。数据这个东西,上手摸过一遍的体感和只看文档完全不一样。
