企业官网建设流程全解析

简介：这份地图匹配工程面向位置服务与轨迹处理开发者，基于GraphHopper实现，可将GPX采集的GPS轨迹吸附到OpenStreetMap道路网络，适用于轨迹纠偏、出行行为分析与地理空间数据清洗。项目需Java 8与Maven构建，压缩包共八十七个文件、约七点五八兆字节，含三十三个Java源码、十六个GPX轨迹样例、八个XML配置及图片和前端资源，另有OSM的pbf地图数据与压缩样本，覆盖匹配核心、HMM算法库、Web演示及打包模块，导入区域地图后即可运行验证，目录按功能清晰划分。已有1801人学习下载。读者可借此理解隐马尔可夫模型在道路候选与路径推断中的落地方式，参考轨迹捕捉流程、样例数据组织、Web端可视化与多模块构建配置，快速搭建完整可复现的实验环境，并据此排查匹配偏差、参数调优及相关排错思路，便于对照学习。

1. 带噪轨迹回收到路网：为什么值得在 Java 侧自己跑一遍地图匹配

把车机或手持设备采回来的 GPS 点叠在 OpenStreetMap 上，十有八九压不进路面：高架下偏十几米、隧道里断两分钟、出停车场直接瞬移到隔壁街。map-matching（地图匹配）要干的事，就是把这些带噪的 gps 点按序列约束重新吸附到路网边上。这个基于 GraphHopper 的 Java 地图匹配组件，把 OSM 数据导入成可路由图之后，用隐马尔可夫模型在候选边之间做 Viterbi 解码，最后输出一条连续的匹配路径。它适合做 tracking 回放、轨迹清洗、里程核算、geospatial 数据质量校验的团队；如果你手上已经有一套 Java 服务，不想为了匹配再引一套 Python 栈，这条路子会比想象中顺。下面按“它靠什么算 → 怎么跑起来 → 参数怎么定 → 坑在哪 → 怎么验证”拆开讲。

2. GraphHopper 地图匹配的内核：候选边、发射概率与 Viterbi 解码

2.1 从 OSM 数据到可路由图：匹配依赖的是边几何，不是路名

OpenStreetMap 的原始数据是三件套：node（带经纬度的点）、way（有序的 node 引用，代表一条道路或路径）、relation（关系，比如公交线路、行政区）。GraphHopper 导入阶段做的事，是把这三件套压成一张有向图：交叉口和形状点被切成节点，两个节点之间的一段就是一条边，边上挂着几何折线、长度、允许的通行方式、速度估计和权重。地图匹配全程都在这张图上做，不碰原始 XML。

这里有个容易被忽略的点：匹配用的是边的几何形状，不是路名也不是 way 的 id。一条 OSM way 在导入时会被交叉口切成好几段边，一条双向道路会被拆成两条方向相反的边。所以你在结果里看到的“匹配到某条边”，粒度是边，不是“某某路”。如果你后面要按路名聚合统计，得自己拿 OSM 的 tag 回查，别指望匹配结果直接给你路名。

另一个关键选择是 profile。car、bike、foot三种 profile 导出的图完全不同：单行道对 car 是单向的，对 foot 是双向的；高速对 foot 直接不可通行。匹配一段车载轨迹却用了 foot 的图，候选边集合从一开始就是错的，后面参数调得再细也救不回来。常见做法是：轨迹来自什么交通工具，就用对应 profile 的图，必要时为不同来源的数据各建一份图缓存。

图构建完成之后会落到一个本地目录（GraphHopper 里叫 graph cache）。importOrLoad()第一次会解析 OSM 文件建图，之后直接读缓存。生产上一般把建图和匹配拆成两个进程：建图是重活，跑一次就好；匹配是轻活，可以反复跑。这样调参数的时候不用每次重新解析几百 MB 的 pbf。

2.2 候选点生成：把每个 GPS 点投影到搜索半径内的边上

HMM 的第一步，是给轨迹上的每个 GPS 点找“它可能在哪几条边上”，这些边上的投影点就是候选点（candidate）。做法是：以该点为中心，在半径 R 内检索附近的边，然后把点垂直投影到每条边的折线上，取折线上离它最近的那个位置，记录两件事——投影点在边上的位置（通常是沿边的距离比例），以及 GPS 点到这条边的垂直距离。

半径 R 是整个匹配里最敏感的旋钮之一。R 太小，噪声大的点一个候选都找不到，轨迹直接断成几截；R 太大，密集城区里一个点能命中几十条边，候选数量爆炸，Viterbi 的状态空间从几十涨到几千，耗时成倍上升，而且容易匹配到隔壁街。常见起点是 30 到 50 米，再根据你的 GPS 精度分布往上或往下调。

投影本身也有边界情况：GPS 点落在折线第一个顶点之前，或者最后一个顶点之后，投影点会退化到端点。这时候垂直距离按到端点的距离算，某些实现里还会给这种候选打一个折扣，避免轨迹末端被强行拉到某条边的尽头。这个细节在轨迹起点和终点特别明显——如果你的轨迹总是从某条路的中间“跳”到路口，多半就是端点的投影逻辑在起作用。

候选点还要带方向信息。一条边是单向的，如果轨迹的运动方向和边的方向夹角超过阈值，这个候选通常会被丢掉。车载数据在掉头、绕环岛的时候，方向判断容易出错，这时候宁可放宽阈值，让 Viterbi 用序列信息去裁决，而不是在候选阶段就一刀切。

2.3 发射概率、转移概率与 Viterbi 递推的完整链路

有了候选点，就要给它们打分了。HMM 里有两类概率。

发射概率描述“如果真实位置在这条边上，观测到这个 GPS 点的可能性有多大”。最常见的形式是高斯：GPS 点到候选边的垂直距离 d 越小，概率越高。公式大致是exp(-0.5 * (d / sigma)^2)再乘一个归一化系数，sigma就是那个“测量误差标准差”参数。sigma 设成 10 米，意味着距离 10 米的候选点概率大约是真值处的 0.6；距离 30 米的候选点概率已经掉到 0.01 量级。所以 sigma 实质上是在说“我有多相信 GPS”。

转移概率描述“从前一个候选点走到当前候选点，合不合理”。做法是把两个候选点在路网上做一次路由，得到路由距离（或路由时间），再和 GPS 两点之间的直线距离（或时间差）比较。两者差得越远，说明越可能是“瞬移”或“绕路”，概率越低。常见形式是指数衰减：exp(-|routeDistance - straightDistance| / beta)，beta控制衰减速度。beta 越小，对绕路越不能容忍；beta 越大，模型越愿意相信“轨迹确实绕了一圈”。

有了这两类概率，Viterbi 就是逐点递推：对第 t 个点的每个候选，遍历第 t-1 个点的所有候选，算出“前一步最优代价 + 转移代价 + 当前发射代价”，取最小，并记下前驱。走完整条轨迹后，从最后一个点的最优候选回溯，就得到每个 GPS 点对应的边。把这些边按顺序拼起来，就是最终的匹配路径（merged path）。

这个链路的复杂度是 O(T × K²)，T 是轨迹点数，K 是平均候选数。一条一万个点的轨迹，K 取 10，就是一百万次转移计算，每次转移还要算一次路由——这才是真正的时间大头。所以生产上常见两种优化：一是对长轨迹做分段，二是把候选半径压小，从源头上限制 K。

2.4 为什么不用“逐点找最近边”

最简单的做法是每个 GPS 点独立找最近的边，拼起来完事。这条路在开阔路段能用，一进城区就崩：两个相邻点分别匹配到平行主路和辅路，中间没有任何边把它们连起来，结果就是一条断成两截、来回横跳的轨迹。HMM 的价值就在于它把“序列连续性”编码进了转移概率——单点看可能辅路更近，但加上前后点的约束，主路才是全局最优。

代价是要做路由计算，比逐点最近边慢一到两个数量级。但这个代价换来的确定性很值：逐点最近边没有任何参数可以调，匹配质量完全取决于 GPS 噪声；HMM 至少有 sigma 和 beta 两个旋钮，你可以根据数据源的特性去调，这在工程上比“玄学”靠谱得多。

3. 从 OSM 文件到一次匹配：最小可运行链路与代码结构

3.1 环境与依赖：JDK、Maven 坐标与图缓存目录

Java 侧需要 JDK 17 以上的版本（GraphHopper 近几年的主线版本对 JDK 要求不低，老项目如果还在 8 上，得先确认你锁定的 GraphHopper 版本支持到哪个基线）。构建工具用 Maven 或 Gradle 都行，依赖主要是两个 artifact：graphhopper-core和graphhopper-map-matching。版本号不要抄文章里的，查你本地私服或者官方发布页，然后统一用属性管理，避免 core 和 map-matching 版本错位。

<properties> <!-- 版本以你仓库里实际可用的发布版为准，两边必须一致 --> <graphhopper.version>${YOUR_VERSION}</graphhopper.version> </properties> <dependencies> <dependency> <groupId>com.graphhopper</groupId> <artifactId>graphhopper-core</artifactId> <version>${graphhopper.version}</version> </dependency> <dependency> <groupId>com.graphhopper</groupId> <artifactId>graphhopper-map-matching</artifactId> <version>${graphhopper.version}</version> </dependency> </dependencies>

graphhopper-core负责建图、路由、空间索引；graphhopper-map-matching依赖它，提供MapMatching、MatchResult、EdgeMatch这些类。两个包版本必须严格对齐，core 升级了 map-matching 没跟上，最常见的结果是运行时NoSuchMethodError，而且堆栈指向的是匹配内部，很难一眼看出是版本问题。

目录规划上，我一般会固定三个路径：OSM 源文件目录、图缓存目录、轨迹与结果目录。图缓存目录一旦建好，除非换了 OSM 数据或者改了 profile，否则不要删——重建一次大区域的图可能要几分钟到几十分钟。可以在目录名里带上 profile 和 OSM 数据的日期，比如graph-car-20240115，这样多套配置并存不会互相覆盖。

3.2 最小匹配程序：加载图、构造 MapMatching、执行 doWork

下面这段是能跑通的最小骨架，逻辑分四步：配置 GraphHopper、导入或加载图、构造匹配器并设参数、读轨迹执行匹配。

import com.graphhopper.GraphHopper; import com.graphhopper.config.Profile; import com.graphhopper.matching.MapMatching; import com.graphhopper.matching.MatchResult; import com.graphhopper.util.GPXEntry; import java.util.List; public class MatchDemo { public static void main(String[] args) throws Exception { String osmFile = "/data/osm/region.osm.pbf"; String graphCache = "/data/graph/graph-car-20240115"; // 1. 建图配置：profile 决定哪些边可通行，选错等于全盘错 GraphHopper hopper = new GraphHopper(); hopper.setOSMFile(osmFile); hopper.setGraphHopperLocation(graphCache); hopper.setProfiles(new Profile("car") .setVehicle("car") .setWeighting("fastest")); // 2. 首次解析 OSM，之后直接读缓存 hopper.importOrLoad(); // 3. 用已加载的图构造匹配器 MapMatching matching = MapMatching.fromGraphHopper(hopper); matching.setMeasurementErrorSigma(15); // 单位：米 matching.setTransitionProbabilityBeta(2.0); // 转移概率衰减尺度 // 4. 读轨迹并执行 List<GPXEntry> track = GpxReader.read("/data/track/sample.gpx"); MatchResult result = matching.doWork(track); System.out.println("edge matches: " + result.getEdgeMatches().size()); System.out.println("merged distance: " + result.getMergedPath().getDistance()); } }

setMeasurementErrorSigma(15)对应发射概率里的标准差，15 米大致是普通车载 GPS 在开阔路段的量级；setTransitionProbabilityBeta(2.0)是转移概率的衰减系数，采样间隔一秒一个点时，2.0 是个比较温和的起点。这两个值的调整逻辑在第 4 章展开。

importOrLoad()是幂等的：图缓存存在且校验通过就直接加载，不存在才走解析。所以第一次跑会慢，后面几次基本是秒级。如果你改了setProfiles里的任何一项，缓存会失效并触发重建——这也是为什么 profile 配置要写进代码或者配置中心，而不是散在各个调用点。

doWork返回的MatchResult是整条轨迹的匹配结果，不是逐点的。里面最常用的是getEdgeMatches()（每一步匹配到哪条边、投影位置、是否断链）和getMergedPath()（拼好的连续路径，能直接拿距离和几何）。

3.3 轨迹读入：GPX 解析、坐标顺序与时间戳回填

轨迹来源五花八门，GPX 是最通用的一种。下面这段手写解析不依赖第三方库，够用且可控。

import org.w3c.dom.Document; import org.w3c.dom.Element; import org.w3c.dom.NodeList; import com.graphhopper.util.GPXEntry; import javax.xml.parsers.DocumentBuilderFactory; import java.io.File; import java.time.Instant; import java.util.ArrayList; import java.util.List; public final class GpxReader { public static List<GPXEntry> read(String path) throws Exception { DocumentBuilderFactory f = DocumentBuilderFactory.newInstance(); f.setNamespaceAware(false); // 只取 trkpt，关掉命名空间省事 Document doc = f.newDocumentBuilder().parse(new File(path)); NodeList pts = doc.getElementsByTagName("trkpt"); List<GPXEntry> entries = new ArrayList<>(pts.getLength()); for (int i = 0; i < pts.getLength(); i++) { Element el = (Element) pts.item(i); // 注意：GPX 属性是 lat/lon，构造参数顺序要对照 GPXEntry 的定义 double lat = Double.parseDouble(el.getAttribute("lat")); double lon = Double.parseDouble(el.getAttribute("lon")); NodeList timeNodes = el.getElementsByTagName("time"); long millis; if (timeNodes.getLength() > 0) { millis = Instant.parse(timeNodes.item(0).getTextContent().trim()) .toEpochMilli(); } else { // 没有时间戳就按固定间隔回填，否则转移概率没有时间维度可用 millis = i * 1000L; } entries.add(new GPXEntry(lat, lon, millis)); } return entries; } }

三个细节值得单独说。第一，GPX 里是lat/lon两个属性，但很多数据库导出的 CSV 是lon,lat顺序，混着用就会出现“轨迹跑到南极洲”这种翻车现场。第二，GPXEntry的构造参数顺序要以你锁定的版本为准，有的版本是经纬度在前，有的是经度在前，写反了不会报错，只会匹配出一堆莫名其妙的结果。第三，没有时间戳的轨迹不是不能匹配，但转移概率会退化成纯空间约束，遇到绕圈路段的准确率明显下降，能补时间戳就补。

点数量也要做个上限保护。一条几万个点的轨迹一次性丢进doWork，内存和时间都可能超预期。常见做法是在读入阶段按距离或时间抽稀，比如相邻点距离小于 3 米就丢掉后一个，既能降计算量，又不会损失匹配精度。

3.4 结果读取：EdgeMatches、MergedPath 与几何导出

MatchResult里两个对象最实用。getEdgeMatches()是一个列表，每个元素对应轨迹上的一个点（或者一段），能拿到匹配到的边、在边上的投影位置、以及这一段的匹配状态。断链的情况在这里能看出来——如果某一段的匹配边为空或者状态异常，说明模型在那里放弃了连接。

getMergedPath()把匹配到的边拼成一条连续路径，能直接取getDistance()、getTime()，也能拿到getPoints()输出成 GeoJSON。我一般会同时导出两份东西：一份是匹配后的路径（用于可视化对比），一份是每个原始 GPS 点对应的投影坐标（用于算偏移量指标）。只导路径不导投影，后面验证阶段就没法量化误差，等于自断后路。

导出 GeoJSON 的写法很直接：

import com.graphhopper.util.PointList; import com.graphhopper.util.shapes.GHPoint; PointList points = result.getMergedPath().getPoints(); StringBuilder sb = new StringBuilder("{\"type\":\"LineString\",\"coordinates\":["); for (int i = 0; i < points.size(); i++) { GHPoint p = points.get(i); if (i > 0) sb.append(","); // GeoJSON 是 [lon, lat]，别和 GPX 的 lat/lon 搞混 sb.append("[").append(p.lon).append(",").append(p.lat).append("]"); } sb.append("]}");

这段代码的坑在第 8 行的注释里：GeoJSON 规范是[经度, 纬度]，而 GPX 是lat属性在前。两份数据混着写，地图上看到的线会整个反过来。这种错误不报异常，只能靠肉眼在小比例尺下发现，属于典型的“血泪经验”。

4. 参数怎么定：sigma、beta、候选半径与时间窗的取舍

4.1 measurementErrorSigma：先用 GPS 精度定起点

sigma 的物理含义是“观测误差的标准差”，所以它不该拍脑袋定，而应该从你的数据源推。手机上普通定位在开阔地大概 5 到 15 米，城市峡谷能到 30 米以上；车载设备带差分的一般在 3 到 8 米。第一步是先统计一批已知位置的轨迹点，算一下垂直偏移的分布，取一个接近 68 分位的值作为 sigma 的起点。

sigma 偏小的后果是模型过度自信：稍微偏一点的候选就被发射概率压死，Viterbi 被迫在错误的边上硬走，表现为轨迹在两条平行路之间频繁横跳。sigma 偏大的后果是模型变“软”：发射概率区分度不够，转移概率主导决策，表现为轨迹被强行拉直、拐弯处切角。这两种失败模式长得很不一样，调参时先看现象再动值。

一个实用的做法是做参数扫描：固定 beta，把 sigma 从 5、10、15、20、30 各跑一遍，看匹配路径的总长度和原始轨迹长度的比值。这个比值稳定在 1.0 到 1.05 之间的那个 sigma，通常就是这批数据的合理区间。

4.2 transitionProbabilityBeta：和采样间隔绑定的量

beta 不能孤立地看，它和轨迹的采样间隔强相关。采样越稀疏，两个 GPS 点之间的真实路由距离和直线距离差异越大（因为中间可能绕了弯），这时候 beta 要放大，否则模型会认为所有绕路都是不合理的。反过来，一秒一个点的高频轨迹，相邻点之间几乎不可能绕路，beta 可以压小，让模型对异常跳变更敏感。

经验上的起点是：采样间隔 1 秒，beta 取 1.5 到 3；间隔 5 秒，取 3 到 6；间隔 30 秒以上，取 10 以上。这组数不是定理，只是让初始值不至于太离谱。真正的做法还是扫描——固定 sigma，把 beta 翻倍跑几轮，观察断链数量和匹配路径长度偏差的变化趋势。

还有一个容易忽略的点：如果轨迹的时间戳有跳变（比如设备休眠后醒来，时间戳直接跳了几分钟），转移概率里的时间差会变得极大，模型会认为这段不可达。处理办法是在读入阶段检测相邻点时间差，超过阈值就断开成两段独立轨迹分别匹配，而不是硬塞给模型。

4.3 候选半径、最大转移距离与时间窗

候选半径不在MapMatching的两个 setter 里，它藏在更底层的索引查询参数中，不同版本暴露方式不一样。但逻辑是统一的：半径决定了每个点的候选集合大小。城区密集路网建议 30 到 40 米，郊区可以放到 50 到 80 米。判断依据是“你的 sigma 的 2 到 3 倍”——候选半径小于 2 倍 sigma，噪声大的点会找不到候选；大于 3 倍 sigma，候选集合会明显膨胀。

最大转移距离是另一道闸门：两个候选点之间的路由距离超过这个值，转移概率直接归零。它的作用是防止模型把轨迹“传送”到几公里外的另一条路上。这个值要按采样间隔估：1 秒采样、车速 120 km/h，两点间最多 33 米，取 100 米足够宽松；30 秒采样就得放到 1 公里以上。

时间窗和最大转移距离是一对。有些实现用时间差乘以最大速度来约束可达范围，比单纯用距离更合理，因为高速上的点本来就该跨得远。如果你的轨迹混合了不同采样率和不同车速，用时间窗比用固定距离稳。

4.4 一组可复现的参数表与调整顺序

把上面几个参数整理成一张表，方便照着试：

调整顺序我一般固定为：先确认 profile 和图没问题，再定 sigma（用偏移分布定起点），再定 beta（用采样间隔定起点），最后调候选半径压计算量。顺序反了会很难受——半径没定好就调 sigma，候选集合一直在变，参数之间互相干扰，调到最后也不知道是哪个起了作用。

5. 避坑与排查：五类把匹配结果搞崩的常见原因

5.1 现象：所有点都被判为不可匹配，结果为空或极短

原因通常不在匹配算法，而在输入。最常见的是坐标顺序反了——经纬度写反，所有点都落在海里或者几千公里外，候选检索自然一个都命中不了。其次是 profile 选错：拿步行图去匹配车载轨迹，高速路段全部不可通行，轨迹在高速上会整段断掉。第三是图缓存和 OSM 文件不匹配，用了 A 城市的缓存去匹配 B 城市的轨迹。

排查顺序：先把前几个 GPS 点打印出来，对照地图看位置对不对；再确认setProfiles里的 vehicle 和轨迹来源一致；最后检查图缓存目录是不是这次建图生成的。这三步能解决九成以上的“全空”问题。

5.2 现象：匹配结果绕出十几公里的大圈，或者路径长度是原始轨迹的好几倍

这是转移概率失控的典型表现。beta 设得太大，模型对绕路完全不敏感，只要发射概率稍微占优，它就敢沿着路网绕一大圈去够那个候选点。另一种可能是候选半径过大，某个噪声点命中了远处一条边，Viterbi 为了连上它，前后都得绕路。

解决办法是先把 beta 砍半再跑一次，看绕路是否消失；如果还在，就把候选半径压到 sigma 的 2 倍以内。还有一个隐蔽原因是单行道：轨迹实际是逆行（比如设备漂移导致的假逆行），模型为了合法通行只能绕远，这种情况要看getEdgeMatches()里那一段的具体边，确认是不是方向约束导致的。

5.3 现象：高架、隧道、平行辅路之间反复横跳

这是地图匹配最经典的难题，本质是三维路网被压成了二维。高架和地面道路在平面上可能只差几米，GPS 高度信息又极不可靠，发射概率分不出两者。隧道里没有信号，出来后位置跳变，转移概率也接不上。

工程上的处理分两层：一是在候选阶段引入 layer 或者 elevation 相关属性，把不同层的边区分开（前提是你的 OSM 数据里这些 tag 是完整的）；二是在隧道前后做断链，把轨迹切成两段分别匹配，中间用路由补上。指望一套参数同时解决高架和普通路段，通常会顾此失彼。平行辅路的问题更依赖方向约束和 beta 调小，让模型更相信“车不会瞬移到隔壁道”。

5.4 现象：导入阶段 OOM，或者图缓存加载时报校验失败

OOM 基本是 OSM 文件太大而堆内存不够。GraphHopper 建图阶段的内存占用和区域面积、路网密度正相关，一个省的范围给 2G 堆往往不够，给到 6G 到 8G 比较稳。可以通过-Xmx调 JVM 参数，也可以先用工具把 OSM 文件裁成你真正需要的区域——绝大多数业务只需要一个城市或者一条走廊，没必要全国建图。

图缓存校验失败通常是建图过程中断导致的半成品。GraphHopper 会在缓存目录写版本和配置信息，加载时对不上就报错。处理办法很简单：删掉缓存目录重建，不要试图手工修补。另外，不同版本的 GraphHopper 生成的缓存格式不兼容，升级依赖后必须重建，这一点在灰度发布时特别容易踩。

5.5 现象：同一条轨迹跑两次，结果不一致

如果代码里没有并发问题，那大概率是图加载状态不一致：第一次跑触发了建图，第二次读的是缓存，两者理论上应该一致，但如果建图参数（profile、编码方式）在两次之间变过，结果就会不同。另一种可能是轨迹读入时用了HashMap之类无序结构做中间存储，点的顺序被打乱。

排查办法是把匹配结果的关键指标（边 id 序列、总距离）打日志，比对两次运行。如果边 id 序列一致但距离不同，查单位换算；如果序列本身就不同，查输入顺序和图缓存。生产上我会把图缓存的路径和版本号写进匹配结果的元数据里，出问题能直接定位是哪次建图的产物。

6. 验证匹配质量：把玄学变成可量化指标

调参调到最后，必须有一个不依赖肉眼的标准，否则就是在猜。我的做法是准备一小批“对照轨迹”：选几条你熟悉的路段，人工在 OSM 上标出真实经过的边序列，或者用高精度设备采一遍作为参考。样本不用多，每条路段两三条、覆盖城区、高速、隧道各一种场景就够了。

在这个小样本上算三个指标。第一个是命中率：匹配出来的边序列里，有多少比例落在人工标注的边集合内，这个指标对断链特别敏感。第二个是平均垂直偏移：每个原始 GPS 点到它匹配边的投影距离，取均值和中位数，中位数比均值更能反映典型水平，因为少数漂移点会把均值拉高。第三个是路径长度偏差：匹配路径总长除以参考轨迹总长，理想值在 1.0 附近，超过 1.1 基本说明有绕路。

# 离线评估：三个指标的最小实现 import math def haversine(lat1, lon1, lat2, lon2): r = 6371000.0 p1, p2 = math.radians(lat1), math.radians(lat2) dp = math.radians(lat2 - lat1) dl = math.radians(lon2 - lon1) a = math.sin(dp / 2) ** 2 + math.cos(p1) * math.cos(p2) * math.sin(dl / 2) ** 2 return 2 * r * math.asin(math.sqrt(a)) def evaluate(raw_points, projected_points, matched_edges, truth_edges, ref_length): # 1. 命中率：匹配边有多少落在人工标注集合内 hit = sum(1 for e in matched_edges if e in truth_edges) / max(len(matched_edges), 1) # 2. 平均偏移：原始点到投影点的距离 offsets = [haversine(a[0], a[1], b[0], b[1]) for a, b in zip(raw_points, projected_points)] offsets.sort() median_offset = offsets[len(offsets) // 2] # 3. 长度偏差：匹配路径长度 / 参考长度 matched_length = sum(haversine(raw_points[i][0], raw_points[i][1], raw_points[i + 1][0], raw_points[i + 1][1]) for i in range(len(raw_points) - 1)) length_ratio = matched_length / ref_length if ref_length else float("nan") return {"hit_rate": hit, "median_offset_m": median_offset, "length_ratio": length_ratio}

这段脚本的输入需要你从匹配结果里导出：raw_points是原始 GPS 序列，projected_points是每个点对应的投影坐标，matched_edges是边 id 序列，truth_edges是人工标注集合。第三个指标这里用了原始点之间的球面距离近似，只是为了快速对比，严格算应该用匹配路径的实际几何长度。

指标跑通之后，参数调整就有了依据：改一个参数，三个指标一起看，命中率升、偏移降、长度比接近 1.0，才算真的改对了。我见过太多“看着图挺顺”但其实长度比 1.4 的匹配结果，放大到全量数据上，里程统计直接偏了三成。

从那以后我每接一批新的轨迹数据，都会先抽二十个点跑一遍这套指标，再决定要不要动参数——图看着顺不算数，数对了才算。希望帮到你。

本文还有配套的精品资源，点击获取