简介面向轨迹数据挖掘与地理信息分析人员这份资源实现了TRACLUS轨迹聚类算法支持在线输入位置点并进行轨迹分类与聚类同时输出直观的可视化图像适合GIS、数据挖掘方向的初学者及研究者用于算法复现与实验验证。压缩包共38个文件以MATLAB脚本文件.m为主辅以测试数据集.mat、编辑备份.asv及说明文档.md整体仅400KB轻量易部署。目前已有506人学习使用。包内模块覆盖数据加载、轨迹分段、距离计算、密度聚类和绘图展示等关键环节并附带模拟轨迹生成与真实数据导入脚本可帮助读者从零跑通TRACLUS流程理解轨迹分段、聚类参数调节及结果可视化的联动关系为在线轨迹分析或相关课题研究提供可直接参考的源码实现。1. 从一条 GPS 轨迹说起TRACLUS 与轨迹聚类的边界TRACLUS 是轨迹聚类里被引用最多的算法之一核心是 partition-and-group 两阶段框架先用 MDL 原则把一条连续轨迹切成若干线段再对线段做基于密度的聚类最后输出能代表一组移动行为的代表轨迹。它解决的是整条轨迹无法直接比较的问题——长度不一、采样率不同、起终点随意经典的欧氏距离在这里基本失效。对做在线分类的人来说TRACLUS 是判断“新到的轨迹段正在走哪条已知路线”的常用基线实时路况、物流路径识别、骑手轨迹归因这些场景里都能看到它的影子。下面按从原理到落地的顺序讲清两阶段怎么工作、TRACLUS-master 怎么跑通最小示例以及在线分类场景下的滑动窗口改造和参数取舍。2. TRACLUS 核心原理拆解MDL 划分与线段密度聚类2.1 为什么不能把整条轨迹当点聚类最常见的错误是把一条轨迹整体当作一个对象算 DTW 或 Hausdorff 距离矩阵再丢给 KMeans。这样做的直接后果是轨迹长度差异越大距离越被长轨迹主导起终点随机比对时还要先做对齐KMeans 要求预先给定簇数而真实移动行为里你根本不知道有几类。TRACLUS 换了个切题的角度——轨迹的全貌不重要重要的是方向发生显著变化的位置也就是特征点。整个算法因此被拆成两个子问题在哪里切以及切下来的线段怎么聚。两个子问题各自都有明确算法这也是它多年以后仍然适合作为在线分类基线的原因批处理框架稳定改造点清楚。2.2 MDL 原则如何决定特征点划分阶段用 MDL最小描述长度判断“当前位置值不值得切开”。核心思想是如果一条线段能把一段点列描述得足够好那么用线段加误差来编码总代价应该低于逐个点编码。代价拆成两项L(H) 是线段本身的描述长度L(D|H) 是中间点偏离线段的误差描述长度两者相加就是压缩代价。逐点向右扩展当压缩代价超过不压缩的代价时说明方向已经发生明显变化上一个点应当记为特征点。下面是一个教学版实现论文里用的是前向和后向扫描加局部最优选择核心判断逻辑一致import math def segment_length(a, b): return math.hypot(a[0] - b[0], a[1] - b[1]) def perp_distance(seg, p): # 点到线段的垂直距离投影落在线段外时退化为端点距离 a, b seg dx, dy b[0] - a[0], b[1] - a[1] if dx dy 0: return segment_length(a, p) t ((p[0] - a[0]) * dx (p[1] - a[1]) * dy) / (dx * dx dy * dy) t max(0.0, min(1.0, t)) proj (a[0] t * dx, a[1] t * dy) return segment_length(p, proj) def split_cost(prev, end, between): # L(H)线段长度编码代价 l_h math.log2(segment_length(prev, end) 1e-9) # L(D|H)中间点误差编码代价之和 l_d sum(math.log2(perp_distance((prev, end), p) 1e-9) for p in between) return l_h l_d def should_split(prev, end, between): points [prev] between [end] compressed split_cost(prev, end, between) raw sum(math.log2(segment_length(a, b) 1e-9) for a, b in zip(points, points[1:])) return compressed raw逻辑说明should_split 返回 True 时表示“用一条线段加误差描述当前点列”比“逐点描述”更贵说明该切了。t 是对投影参数做 0-1 截断保证投影落在线段内部这是点线距离最常出错的地方。实际使用中要给 split_cost 的增益留一个阈值直接作比较会把轨迹切得过碎这一点的调法在第 5 章展开。2.3 线段之间怎么算距离三个分量相加聚类阶段不再有“点”只有线段所以距离函数必须是线段级的。TRACLUS 的线段距离由三个分量组成。垂直距离是两个端点到另一条线段的垂距平方和除以垂距和反映两条线偏离多少平行距离是把两段投影到同一直线后重叠区域之外的较小部分长度反映前后错位角度距离是较短线段长度乘以夹角正弦反映方向差异。三者相加得到最终距离这也是 eps 必须按“线段距离”标定而不是按普通坐标距离标定的原因。很多人直接把经纬度差放进 eps量级完全对不上后面怎么调都怪。实际计算时三个分量要统一到同一长度单位否则短线段上角度距离会被垂直距离淹没长线段上又会反过来主导。2.4 分组阶段为什么用 DBSCAN 而不是 KMeans分组阶段的做法和 DBSCAN 一致一条线段如果在 eps 半径内有足够多的邻居线段就形成一个簇核心再通过密度相连扩张。这样做的理由在于移动行为里簇数未知、噪声线段大量存在、同一条道路上的轨迹方向还可能相反。KMeans 强制每个对象入簇DBSCAN 系则可以顺理成章地把孤立线段当作噪声。对比项KMeans 路线TRACLUS 的 DBSCAN 路线聚类对象整条轨迹划分后的线段簇数必须给定 K由 eps 和 minLns 决定噪声处理全部强制入簇达不到密度阈值的线段被剔除输出质心簇内线段平均得到的代表轨迹minLns 就是“最少邻居线段数”语义和 DBSCAN 的 MinPts 对应。调参时先记住一个原则eps 决定合并多激进minLns 决定噪声多容易入簇两者在线分类场景下的改法完全不同这一点在第 4、5 章会反复用到。3. 在 TRACLUS-master 上跑通最小示例数据准备与核心入口3.1 先从源码布局里找三个入口从 GitHub 拉下来的 TRACLUS-master 版本源码布局大同小异核心代码放在一个 traclus 包或同名目录里里面至少有三个角色——轨迹数据类、MDL 划分类、线段 DBSCAN 类data 目录放样例轨迹输出目录放聚类结果和代表轨迹。我不建议一上来通读所有类先 grep 找到三个入口就够了。第一个是数据读入确认它吃 CSV 还是自定义格式第二个是划分确认它是整体切分还是逐条处理第三个是聚类入口确认 eps 和 minLns 在哪里设置。其余都是数据结构和工具方法用到再回来看。划分和聚类两个阶段是解耦的把中间结果落成临时文件对调试帮助很大跑之前先把轨迹坐标画一遍比看任何日志都快。3.2 数据准备把原始点整理成按轨迹分组的 CSV多数版本接受类似下面格式的输入轨迹 id、经度、纬度、时间戳一行一个点。来自车载终端或手机 App 的原始数据往往字段更多先做一步归一化。常见的做法是写一个小脚本只抽四个字段并按轨迹 id 分文件、按时间戳排序。# data/normalized.csv一列轨迹 id后面是经纬度和时间 head -5 data/normalized.csv # taxi_001,116.397,39.908,2024-06-01 08:00:00 # taxi_001,116.400,39.912,2024-06-01 08:00:05 # taxi_001,116.405,39.915,2024-06-01 08:00:10import csv def normalize(src: str, dst: str) - None: 把原始点抽成 id, lon, lat, ts 四列保持原始顺序 with open(src) as f, open(dst, w, newline) as out: w csv.writer(out) for line in f: dev, ts, lon, lat line.strip().split(,) w.writerow([dev, float(lon), float(lat), ts])逻辑说明只做抽取和字段顺序整理不做重采样。重采样会改变 MDL 对方向变化的判断能不做就不做。单位问题在这里就要决定短距离场景直接用于经纬度的长度计算每度对应的真实距离随纬度变化建议统一转成米制投影坐标比如 UTM再进聚类否则 eps 很难给出稳定值。3.3 最小调用划分、聚类、输出代表轨迹跑通流程通常就是五到十行代码。下面按典型 Java 版本写类名以实际拉到的代码为准重点是三个阶段先后的关系// TraclusApp.java 最小跑通流程 TrajectorySet set TrajectorySet.load(data/normalized.csv); // 阶段一MDL 划分把长轨迹切成线段 ListTrajectory parts new MDLPartitioner().run(set); // 阶段二线段级 DBSCANeps 是线段距离阈值minLns 是密度下限 SegmentDBSCAN db new SegmentDBSCAN(0.5, 3); ListCluster clusters db.run(parts); // 阶段三代表轨迹由簇内线段平均得到不是真实轨迹 for (Cluster c : clusters) { System.out.printf(cluster%s size%d rep%s%n, c.id(), c.size(), c.representative()); }参数说明eps0.5 是相对线段距离而言的第 5 章会说怎么从数据里估它的基准minLns3 表示一个簇的核心线段至少要有 3 根邻居。编译和运行一般用 Maven 一把过mvn -q compile mvn -q exec:java -Dexec.mainClassTraclusApp如果在 exec:java 上报不到主类检查 pom 里是否配置了 exec plugin或者直接 java -cp target/classes TraclusApp 运行。3.4 结果文件里到底有什么聚类输出一般会落到文本或 CSV常见字段如下表。字段含义用途cluster_id簇编号关联业务类别或路径标签rep_points代表轨迹的坐标串可视化、轨迹匹配member_cnt簇内线段数衡量该类行为支持度跑完先别急着调参做一件事把 member_cnt 从大到小排序看前三个簇的代表轨迹是否与直觉一致。一致说明数据管线和划分阶段正常问题只会在聚类参数上。如果绝大多数簇都只有 1 到 2 根线段说明划分阶段切得太碎或数据本身噪声大先回 3.2 检查排序和投影而不是直接调聚类。各版本的输出字段名略有差异以你拉到的代码为准。4. 在线分类改造滑动窗口、增量划分与线段级匹配4.1 在线分类和离线批处理的本质差别TRACLUS 原生是批处理全部轨迹到齐一次性划分、聚类再输出代表轨迹。在线分类的要求是数据边到达边判定“当前这段在走哪条已知路线”延迟要可控而且轨迹还在增长不能等整条结束再算。常见的改造有三步滑动窗口重划分、保留最后一个特征点做窗口衔接、线段级匹配分类而不是全局重聚类。这三步单独看都不难难点在于窗口边界和分类阈值处理不好会出现簇反复横跳。滑动窗口方案不是唯一选择也有人每到达固定点数就全量重跑一遍但批量重跑的最坏复杂度随轨迹总量二次增长在线数据流场景下撑不住。线段级匹配的复杂度只和窗口内新产生的线段数相关这是它成为主流改造方式的原因。4.2 增量划分只重切窗口内的点第一个改动是放弃整条轨迹只在滑动窗口内重新计算特征点。窗口大小决定延迟和稳定性之间的取舍我一般从 40 到 100 个点开始试点越密窗口越小。class OnlinePartitioner: def __init__(self, window60, gain_threshold0.2): self.buf [] # 当前窗口内的点 self.window window self.gain gain_threshold def push(self, p): self.buf.append(p) if len(self.buf) self.window: return [] # 窗口内重新计算特征点得到完整线段 chars find_chars(self.buf, self.gain) segments to_segments(chars) # 保留最后一个特征点作为下个窗口起点保证切分连续 self.buf [chars[-1]] return segments逻辑说明窗口内的 find_chars 就是第 2 章的 should_split 逐点判断gain_threshold 是给压缩增益留的余量。保留 chars[-1] 这一行是关键否则相邻两条线段会在窗口边界处少一个公共点聚类时出现零长度线段。返回的每一条线段直接进入分类模块不再参与全局聚类。4.3 分类不是“找最近”而是“阈值以内的最近”第二步是把新线段归到已有类别。不少实现写成最近邻就完事这在数据干净时没问题一旦遇到未见过的新路线就会乱分。正确的做法是先找最近的代表轨迹再拿距离和 eps 比较距离大于 eps 时只能进待定缓冲攒够 minLns 根线段再声明新类别。def classify(seg, classes, eps, pending, min_lns): best_cls, best_d None, float(inf) for c in classes: d segment_distance(seg, c.representative) if d best_d: best_cls, best_d c, d if best_d eps: return best_cls # 归属已知路线 pending.append(seg) # 未知线段先进待定区 if neighbor_count(pending, eps) min_lns: classes.append(build_class(pending)) # 密度足够开新类 pending.clear() return None说明segment_distance 就是第 2 章的垂直、平行、角度三分量之和。neighbor_count 统计待定区里彼此距离小于 eps 的线段数复用同一个阈值避免额外引入超参数。pending 里可以给每条线段加时间戳超过一定老化时间就剔除防止旧噪声攒成假类别。4.4 在线场景的参数表批处理参数不能直接搬过来原因是到达的数据天然带抖动窗口内轨迹短统计意义更弱。参数离线典型值在线建议值说明window_size整条轨迹40~100 点越小延迟越低线段越碎gain_threshold0 附近0.1~0.3在线数据抖动大太敏感会乱切eps中位线段长度×0.5中位×0.8~1.2分类阶段需要容忍采样噪声minLns3~53想抑制新类别出现就调大提示把“距离最近”直接当成“属于”是在线分类最常见的错误。没有 eps 做门槛每一条新轨迹都会被硬塞进某个旧类新路线永远发现不了。窗口改小后 eps 基准也会跟着变小两者需要联动验证。5. TRACLUS 参数调优eps、minLns 与 MDL 阈值的可复现选择5.1 用线段长度分布给 eps 定基准eps 的量级取决于线段距离而线段距离由空间单位决定所以先把坐标统一到米制再统计划分后所有线段的长度分布用中位数给 eps 一个起点。我一般按 0.3 到 0.5 倍中位线段长度起步。def estimate_eps(segments, ratio0.5): lengths sorted(s.length for s in segments) return lengths[len(lengths) // 2] * ratio更稳的做法是参考 DBSCAN 的 k-dist 曲线对每条线段计算它到第 minLns 近邻的线段距离排序后画折线拐点附近就是可用的 eps。拐点不明显说明数据本身簇结构弱这时候与其硬调 eps不如回第 2 章检查划分是否把轨迹切得太碎。5.2 minLns 控制的是噪声入场门槛minLns 太小比如 2几乎不滤噪声太大比如 8会抹掉稀疏但真实的行为。经验规则是先固定 minLns3 调 eps等簇数量稳定下来再动 minLns。一个健康的状态是eps 小幅变化时簇数平滑变化而 minLns 从 3 变到 4 时结果基本不变。如果 minLns 一改结果就剧变说明 eps 给得过大簇已经在靠密度延续而不是靠空间接近。另外要注意minLns 决定的是线段密度和簇最终包含多少条线段没有直接换算关系一个簇可以靠密度相连绵延几百条线段不要把它当成簇的最小规模来理解。5.3 五个典型踩坑与对应信号现象根因处理簇碎成大量小段MDL 阈值太严切点过多提高 gain_threshold减少切分一条轨迹被分到多个簇经纬度未投影距离单位混乱统一转米制坐标再聚类噪声全部进簇minLns 太小调大 minLns 或加线段最短长度过滤在线分类在两条路之间反复切换eps 太小放宽到中位线段长度的 0.8~1.0 倍代表轨迹形状怪异簇内混入方向相反的线段检查该簇是否横跨并行道路调小 eps第一行最容易被忽略很多人以为结果差是聚类参数问题实际是划分阶段已经把方向变化切碎了聚类再调也救不回来。排查顺序永远是先看划分出来的线段再看簇。5.4 网格搜索加一个分段评价最后补一个可复现的调参脚本。注意不要用簇数 K 当唯一标准簇数最少不代表最优常把噪声全归到一个大簇里。def grid_search(data, eps_list, min_lns_list): best, best_score None, -1.0 for eps in eps_list: for m in min_lns_list: clusters run_traclus(data, eps, m) if len(clusters) 2: continue score segment_silhouette(clusters) print(feps{eps} min_lns{m} k{len(clusters)} score{score:.3f}) if score best_score: best, best_score (eps, m), score return best说明segment_silhouette 是对每条线段计算它到自身簇和最近邻簇的距离差越大越好。线段数量大时这个计算很贵就随机抽样 2000 条线段来算结果足够用来排序对比。搜索范围不要跨数量级铺开在 5.1 节的基准附近取 3 到 4 个值就够了。6. 用代表轨迹和可视化验证 TRACLUS 聚类结果6.1 把代表轨迹输出成 GeoJSON调参完成后的第一件事永远是看代表轨迹长什么样。文本数字看不出问题把每个簇的代表轨迹导出成 GeoJSON拖到地图工具里对照底图看。import json def reps_to_geojson(reps, pathrep.json): feats [] for i, rep in enumerate(reps): coords [(pt.lon, pt.lat) for pt in rep.points] feats.append({ type: Feature, geometry: {type: LineString, coordinates: coords}, properties: {cluster: i, size: rep.size}, }) with open(path, w) as f: json.dump({type: FeatureCollection, features: feats}, f)坐标顺序是 GeoJSON 约定的经度在前、纬度在后写反了图上全跑到海里这是最常见的低级错误。6.2 三个快速验证指标稳定性同一路段不同时间采样的轨迹在线分类结果应保持一致如果同一簇内混入相反方向先怀疑 eps 太大。区分度两条平行且同向的道路如果被合并代表轨迹会在中间飘需要调小 eps 而不是调大 minLns。支持度按簇内线段数排序优先检查数量最少的簇异常几乎都藏在支持度只有 1 到 2 的孤立簇里。6.3 用方向方差区分合并和噪声一个实用技巧是把每个簇的线段方向方差和空间方差一起打点空间方差小但方向方差大的簇通常是并行道路被合并方向方差小但空间方差大的簇才是真噪声。前者调 eps后者调 minLns这个区分能省下大半调参时间。把方向方差阈值写进网格搜索的评价函数里超标的簇直接扣分调出来的参数会比只看轮廓系数更符合业务直觉。本文还有配套的精品资源点击获取 TRACLUS轨迹聚类详解：从MDL划分到在线分类实战
简介面向轨迹数据挖掘与地理信息分析人员这份资源实现了TRACLUS轨迹聚类算法支持在线输入位置点并进行轨迹分类与聚类同时输出直观的可视化图像适合GIS、数据挖掘方向的初学者及研究者用于算法复现与实验验证。压缩包共38个文件以MATLAB脚本文件.m为主辅以测试数据集.mat、编辑备份.asv及说明文档.md整体仅400KB轻量易部署。目前已有506人学习使用。包内模块覆盖数据加载、轨迹分段、距离计算、密度聚类和绘图展示等关键环节并附带模拟轨迹生成与真实数据导入脚本可帮助读者从零跑通TRACLUS流程理解轨迹分段、聚类参数调节及结果可视化的联动关系为在线轨迹分析或相关课题研究提供可直接参考的源码实现。1. 从一条 GPS 轨迹说起TRACLUS 与轨迹聚类的边界TRACLUS 是轨迹聚类里被引用最多的算法之一核心是 partition-and-group 两阶段框架先用 MDL 原则把一条连续轨迹切成若干线段再对线段做基于密度的聚类最后输出能代表一组移动行为的代表轨迹。它解决的是整条轨迹无法直接比较的问题——长度不一、采样率不同、起终点随意经典的欧氏距离在这里基本失效。对做在线分类的人来说TRACLUS 是判断“新到的轨迹段正在走哪条已知路线”的常用基线实时路况、物流路径识别、骑手轨迹归因这些场景里都能看到它的影子。下面按从原理到落地的顺序讲清两阶段怎么工作、TRACLUS-master 怎么跑通最小示例以及在线分类场景下的滑动窗口改造和参数取舍。2. TRACLUS 核心原理拆解MDL 划分与线段密度聚类2.1 为什么不能把整条轨迹当点聚类最常见的错误是把一条轨迹整体当作一个对象算 DTW 或 Hausdorff 距离矩阵再丢给 KMeans。这样做的直接后果是轨迹长度差异越大距离越被长轨迹主导起终点随机比对时还要先做对齐KMeans 要求预先给定簇数而真实移动行为里你根本不知道有几类。TRACLUS 换了个切题的角度——轨迹的全貌不重要重要的是方向发生显著变化的位置也就是特征点。整个算法因此被拆成两个子问题在哪里切以及切下来的线段怎么聚。两个子问题各自都有明确算法这也是它多年以后仍然适合作为在线分类基线的原因批处理框架稳定改造点清楚。2.2 MDL 原则如何决定特征点划分阶段用 MDL最小描述长度判断“当前位置值不值得切开”。核心思想是如果一条线段能把一段点列描述得足够好那么用线段加误差来编码总代价应该低于逐个点编码。代价拆成两项L(H) 是线段本身的描述长度L(D|H) 是中间点偏离线段的误差描述长度两者相加就是压缩代价。逐点向右扩展当压缩代价超过不压缩的代价时说明方向已经发生明显变化上一个点应当记为特征点。下面是一个教学版实现论文里用的是前向和后向扫描加局部最优选择核心判断逻辑一致import math def segment_length(a, b): return math.hypot(a[0] - b[0], a[1] - b[1]) def perp_distance(seg, p): # 点到线段的垂直距离投影落在线段外时退化为端点距离 a, b seg dx, dy b[0] - a[0], b[1] - a[1] if dx dy 0: return segment_length(a, p) t ((p[0] - a[0]) * dx (p[1] - a[1]) * dy) / (dx * dx dy * dy) t max(0.0, min(1.0, t)) proj (a[0] t * dx, a[1] t * dy) return segment_length(p, proj) def split_cost(prev, end, between): # L(H)线段长度编码代价 l_h math.log2(segment_length(prev, end) 1e-9) # L(D|H)中间点误差编码代价之和 l_d sum(math.log2(perp_distance((prev, end), p) 1e-9) for p in between) return l_h l_d def should_split(prev, end, between): points [prev] between [end] compressed split_cost(prev, end, between) raw sum(math.log2(segment_length(a, b) 1e-9) for a, b in zip(points, points[1:])) return compressed raw逻辑说明should_split 返回 True 时表示“用一条线段加误差描述当前点列”比“逐点描述”更贵说明该切了。t 是对投影参数做 0-1 截断保证投影落在线段内部这是点线距离最常出错的地方。实际使用中要给 split_cost 的增益留一个阈值直接作比较会把轨迹切得过碎这一点的调法在第 5 章展开。2.3 线段之间怎么算距离三个分量相加聚类阶段不再有“点”只有线段所以距离函数必须是线段级的。TRACLUS 的线段距离由三个分量组成。垂直距离是两个端点到另一条线段的垂距平方和除以垂距和反映两条线偏离多少平行距离是把两段投影到同一直线后重叠区域之外的较小部分长度反映前后错位角度距离是较短线段长度乘以夹角正弦反映方向差异。三者相加得到最终距离这也是 eps 必须按“线段距离”标定而不是按普通坐标距离标定的原因。很多人直接把经纬度差放进 eps量级完全对不上后面怎么调都怪。实际计算时三个分量要统一到同一长度单位否则短线段上角度距离会被垂直距离淹没长线段上又会反过来主导。2.4 分组阶段为什么用 DBSCAN 而不是 KMeans分组阶段的做法和 DBSCAN 一致一条线段如果在 eps 半径内有足够多的邻居线段就形成一个簇核心再通过密度相连扩张。这样做的理由在于移动行为里簇数未知、噪声线段大量存在、同一条道路上的轨迹方向还可能相反。KMeans 强制每个对象入簇DBSCAN 系则可以顺理成章地把孤立线段当作噪声。对比项KMeans 路线TRACLUS 的 DBSCAN 路线聚类对象整条轨迹划分后的线段簇数必须给定 K由 eps 和 minLns 决定噪声处理全部强制入簇达不到密度阈值的线段被剔除输出质心簇内线段平均得到的代表轨迹minLns 就是“最少邻居线段数”语义和 DBSCAN 的 MinPts 对应。调参时先记住一个原则eps 决定合并多激进minLns 决定噪声多容易入簇两者在线分类场景下的改法完全不同这一点在第 4、5 章会反复用到。3. 在 TRACLUS-master 上跑通最小示例数据准备与核心入口3.1 先从源码布局里找三个入口从 GitHub 拉下来的 TRACLUS-master 版本源码布局大同小异核心代码放在一个 traclus 包或同名目录里里面至少有三个角色——轨迹数据类、MDL 划分类、线段 DBSCAN 类data 目录放样例轨迹输出目录放聚类结果和代表轨迹。我不建议一上来通读所有类先 grep 找到三个入口就够了。第一个是数据读入确认它吃 CSV 还是自定义格式第二个是划分确认它是整体切分还是逐条处理第三个是聚类入口确认 eps 和 minLns 在哪里设置。其余都是数据结构和工具方法用到再回来看。划分和聚类两个阶段是解耦的把中间结果落成临时文件对调试帮助很大跑之前先把轨迹坐标画一遍比看任何日志都快。3.2 数据准备把原始点整理成按轨迹分组的 CSV多数版本接受类似下面格式的输入轨迹 id、经度、纬度、时间戳一行一个点。来自车载终端或手机 App 的原始数据往往字段更多先做一步归一化。常见的做法是写一个小脚本只抽四个字段并按轨迹 id 分文件、按时间戳排序。# data/normalized.csv一列轨迹 id后面是经纬度和时间 head -5 data/normalized.csv # taxi_001,116.397,39.908,2024-06-01 08:00:00 # taxi_001,116.400,39.912,2024-06-01 08:00:05 # taxi_001,116.405,39.915,2024-06-01 08:00:10import csv def normalize(src: str, dst: str) - None: 把原始点抽成 id, lon, lat, ts 四列保持原始顺序 with open(src) as f, open(dst, w, newline) as out: w csv.writer(out) for line in f: dev, ts, lon, lat line.strip().split(,) w.writerow([dev, float(lon), float(lat), ts])逻辑说明只做抽取和字段顺序整理不做重采样。重采样会改变 MDL 对方向变化的判断能不做就不做。单位问题在这里就要决定短距离场景直接用于经纬度的长度计算每度对应的真实距离随纬度变化建议统一转成米制投影坐标比如 UTM再进聚类否则 eps 很难给出稳定值。3.3 最小调用划分、聚类、输出代表轨迹跑通流程通常就是五到十行代码。下面按典型 Java 版本写类名以实际拉到的代码为准重点是三个阶段先后的关系// TraclusApp.java 最小跑通流程 TrajectorySet set TrajectorySet.load(data/normalized.csv); // 阶段一MDL 划分把长轨迹切成线段 ListTrajectory parts new MDLPartitioner().run(set); // 阶段二线段级 DBSCANeps 是线段距离阈值minLns 是密度下限 SegmentDBSCAN db new SegmentDBSCAN(0.5, 3); ListCluster clusters db.run(parts); // 阶段三代表轨迹由簇内线段平均得到不是真实轨迹 for (Cluster c : clusters) { System.out.printf(cluster%s size%d rep%s%n, c.id(), c.size(), c.representative()); }参数说明eps0.5 是相对线段距离而言的第 5 章会说怎么从数据里估它的基准minLns3 表示一个簇的核心线段至少要有 3 根邻居。编译和运行一般用 Maven 一把过mvn -q compile mvn -q exec:java -Dexec.mainClassTraclusApp如果在 exec:java 上报不到主类检查 pom 里是否配置了 exec plugin或者直接 java -cp target/classes TraclusApp 运行。3.4 结果文件里到底有什么聚类输出一般会落到文本或 CSV常见字段如下表。字段含义用途cluster_id簇编号关联业务类别或路径标签rep_points代表轨迹的坐标串可视化、轨迹匹配member_cnt簇内线段数衡量该类行为支持度跑完先别急着调参做一件事把 member_cnt 从大到小排序看前三个簇的代表轨迹是否与直觉一致。一致说明数据管线和划分阶段正常问题只会在聚类参数上。如果绝大多数簇都只有 1 到 2 根线段说明划分阶段切得太碎或数据本身噪声大先回 3.2 检查排序和投影而不是直接调聚类。各版本的输出字段名略有差异以你拉到的代码为准。4. 在线分类改造滑动窗口、增量划分与线段级匹配4.1 在线分类和离线批处理的本质差别TRACLUS 原生是批处理全部轨迹到齐一次性划分、聚类再输出代表轨迹。在线分类的要求是数据边到达边判定“当前这段在走哪条已知路线”延迟要可控而且轨迹还在增长不能等整条结束再算。常见的改造有三步滑动窗口重划分、保留最后一个特征点做窗口衔接、线段级匹配分类而不是全局重聚类。这三步单独看都不难难点在于窗口边界和分类阈值处理不好会出现簇反复横跳。滑动窗口方案不是唯一选择也有人每到达固定点数就全量重跑一遍但批量重跑的最坏复杂度随轨迹总量二次增长在线数据流场景下撑不住。线段级匹配的复杂度只和窗口内新产生的线段数相关这是它成为主流改造方式的原因。4.2 增量划分只重切窗口内的点第一个改动是放弃整条轨迹只在滑动窗口内重新计算特征点。窗口大小决定延迟和稳定性之间的取舍我一般从 40 到 100 个点开始试点越密窗口越小。class OnlinePartitioner: def __init__(self, window60, gain_threshold0.2): self.buf [] # 当前窗口内的点 self.window window self.gain gain_threshold def push(self, p): self.buf.append(p) if len(self.buf) self.window: return [] # 窗口内重新计算特征点得到完整线段 chars find_chars(self.buf, self.gain) segments to_segments(chars) # 保留最后一个特征点作为下个窗口起点保证切分连续 self.buf [chars[-1]] return segments逻辑说明窗口内的 find_chars 就是第 2 章的 should_split 逐点判断gain_threshold 是给压缩增益留的余量。保留 chars[-1] 这一行是关键否则相邻两条线段会在窗口边界处少一个公共点聚类时出现零长度线段。返回的每一条线段直接进入分类模块不再参与全局聚类。4.3 分类不是“找最近”而是“阈值以内的最近”第二步是把新线段归到已有类别。不少实现写成最近邻就完事这在数据干净时没问题一旦遇到未见过的新路线就会乱分。正确的做法是先找最近的代表轨迹再拿距离和 eps 比较距离大于 eps 时只能进待定缓冲攒够 minLns 根线段再声明新类别。def classify(seg, classes, eps, pending, min_lns): best_cls, best_d None, float(inf) for c in classes: d segment_distance(seg, c.representative) if d best_d: best_cls, best_d c, d if best_d eps: return best_cls # 归属已知路线 pending.append(seg) # 未知线段先进待定区 if neighbor_count(pending, eps) min_lns: classes.append(build_class(pending)) # 密度足够开新类 pending.clear() return None说明segment_distance 就是第 2 章的垂直、平行、角度三分量之和。neighbor_count 统计待定区里彼此距离小于 eps 的线段数复用同一个阈值避免额外引入超参数。pending 里可以给每条线段加时间戳超过一定老化时间就剔除防止旧噪声攒成假类别。4.4 在线场景的参数表批处理参数不能直接搬过来原因是到达的数据天然带抖动窗口内轨迹短统计意义更弱。参数离线典型值在线建议值说明window_size整条轨迹40~100 点越小延迟越低线段越碎gain_threshold0 附近0.1~0.3在线数据抖动大太敏感会乱切eps中位线段长度×0.5中位×0.8~1.2分类阶段需要容忍采样噪声minLns3~53想抑制新类别出现就调大提示把“距离最近”直接当成“属于”是在线分类最常见的错误。没有 eps 做门槛每一条新轨迹都会被硬塞进某个旧类新路线永远发现不了。窗口改小后 eps 基准也会跟着变小两者需要联动验证。5. TRACLUS 参数调优eps、minLns 与 MDL 阈值的可复现选择5.1 用线段长度分布给 eps 定基准eps 的量级取决于线段距离而线段距离由空间单位决定所以先把坐标统一到米制再统计划分后所有线段的长度分布用中位数给 eps 一个起点。我一般按 0.3 到 0.5 倍中位线段长度起步。def estimate_eps(segments, ratio0.5): lengths sorted(s.length for s in segments) return lengths[len(lengths) // 2] * ratio更稳的做法是参考 DBSCAN 的 k-dist 曲线对每条线段计算它到第 minLns 近邻的线段距离排序后画折线拐点附近就是可用的 eps。拐点不明显说明数据本身簇结构弱这时候与其硬调 eps不如回第 2 章检查划分是否把轨迹切得太碎。5.2 minLns 控制的是噪声入场门槛minLns 太小比如 2几乎不滤噪声太大比如 8会抹掉稀疏但真实的行为。经验规则是先固定 minLns3 调 eps等簇数量稳定下来再动 minLns。一个健康的状态是eps 小幅变化时簇数平滑变化而 minLns 从 3 变到 4 时结果基本不变。如果 minLns 一改结果就剧变说明 eps 给得过大簇已经在靠密度延续而不是靠空间接近。另外要注意minLns 决定的是线段密度和簇最终包含多少条线段没有直接换算关系一个簇可以靠密度相连绵延几百条线段不要把它当成簇的最小规模来理解。5.3 五个典型踩坑与对应信号现象根因处理簇碎成大量小段MDL 阈值太严切点过多提高 gain_threshold减少切分一条轨迹被分到多个簇经纬度未投影距离单位混乱统一转米制坐标再聚类噪声全部进簇minLns 太小调大 minLns 或加线段最短长度过滤在线分类在两条路之间反复切换eps 太小放宽到中位线段长度的 0.8~1.0 倍代表轨迹形状怪异簇内混入方向相反的线段检查该簇是否横跨并行道路调小 eps第一行最容易被忽略很多人以为结果差是聚类参数问题实际是划分阶段已经把方向变化切碎了聚类再调也救不回来。排查顺序永远是先看划分出来的线段再看簇。5.4 网格搜索加一个分段评价最后补一个可复现的调参脚本。注意不要用簇数 K 当唯一标准簇数最少不代表最优常把噪声全归到一个大簇里。def grid_search(data, eps_list, min_lns_list): best, best_score None, -1.0 for eps in eps_list: for m in min_lns_list: clusters run_traclus(data, eps, m) if len(clusters) 2: continue score segment_silhouette(clusters) print(feps{eps} min_lns{m} k{len(clusters)} score{score:.3f}) if score best_score: best, best_score (eps, m), score return best说明segment_silhouette 是对每条线段计算它到自身簇和最近邻簇的距离差越大越好。线段数量大时这个计算很贵就随机抽样 2000 条线段来算结果足够用来排序对比。搜索范围不要跨数量级铺开在 5.1 节的基准附近取 3 到 4 个值就够了。6. 用代表轨迹和可视化验证 TRACLUS 聚类结果6.1 把代表轨迹输出成 GeoJSON调参完成后的第一件事永远是看代表轨迹长什么样。文本数字看不出问题把每个簇的代表轨迹导出成 GeoJSON拖到地图工具里对照底图看。import json def reps_to_geojson(reps, pathrep.json): feats [] for i, rep in enumerate(reps): coords [(pt.lon, pt.lat) for pt in rep.points] feats.append({ type: Feature, geometry: {type: LineString, coordinates: coords}, properties: {cluster: i, size: rep.size}, }) with open(path, w) as f: json.dump({type: FeatureCollection, features: feats}, f)坐标顺序是 GeoJSON 约定的经度在前、纬度在后写反了图上全跑到海里这是最常见的低级错误。6.2 三个快速验证指标稳定性同一路段不同时间采样的轨迹在线分类结果应保持一致如果同一簇内混入相反方向先怀疑 eps 太大。区分度两条平行且同向的道路如果被合并代表轨迹会在中间飘需要调小 eps 而不是调大 minLns。支持度按簇内线段数排序优先检查数量最少的簇异常几乎都藏在支持度只有 1 到 2 的孤立簇里。6.3 用方向方差区分合并和噪声一个实用技巧是把每个簇的线段方向方差和空间方差一起打点空间方差小但方向方差大的簇通常是并行道路被合并方向方差小但空间方差大的簇才是真噪声。前者调 eps后者调 minLns这个区分能省下大半调参时间。把方向方差阈值写进网格搜索的评价函数里超标的簇直接扣分调出来的参数会比只看轮廓系数更符合业务直觉。本文还有配套的精品资源点击获取