GPX 里的"轨迹"和"路线"到底差在哪

先给结论

GPX 里的轨迹(文件中写作 <trk>)是一串带时间戳的记录点,是 GPS 接收器在有人实际移动的过程中,一点一点记下来的。GPX 里的路线(<rte>)是提前规划好的路径——一串按顺序排列、打算依次经过的地点,通常完全没有时间信息。一款记录徒步、散步或骑行的 App,写出来的是轨迹。一款用来在出发前规划要走哪条路的 App,读写的更可能是路线。当有人说起已经走完的一次徒步,说"我的路线"时,他几乎肯定指的是轨迹。

两种结构诞生的时刻不一样

这个区别落在一段路的哪个阶段被创建出来。路线属于"之前"——在规划类 App 里,或者手动画出来的,一串打算按顺序抵达的地点,出发前就定好了。轨迹属于"当中"和"之后"——GPS 接收器实际穿过那些地点、以及中间所有位置留下的那条线,是事情发生时被记下来的,而不是提前决定好的。GPX 规范把这两者作为同一份文件格式里的两个独立元素,是因为它们回答的是不同的问题:路线说的是打算去哪里,轨迹说的是实际去了哪里。

数据上到底差在哪

轨迹点

轨迹点几乎总是带着时间戳——它的存在本身,就是因为接收器在某个时刻记下了一次位置,一分钟里重复很多次。把时间戳去掉,线条照样能画出同样的形状,但没法再说清楚哪一段走得多快、什么时候停下过。轨迹的点也很密集,整段距离上每隔几秒就有一个点,因为接收器实际记录的方式就是这样。

路线点

路线点通常不带这些信息。它是一个有名字、有坐标的点,打算被经过,但对于到下一个点要花多久,没有任何概念。路线的点数往往也很少——几个标记转弯或地标的点,而不是连续的轨迹,因为它表达的是一份计划,不是一次记录。

日常说法和文件格式为什么对不上

"路线"这个词,不管是平时说话,还是很多 App 界面上的用法,指的都是整段记录下来的行程——线条的形状、走过的距离、去过的地方。这个用法完全合理,大多数人想到的也正是这个意思。只是 GPX 规范恰好已经把这个词用在了另一个更窄的地方:一份完全没有记录支撑、只是规划好的地点序列。这两种用法谈不上真正冲突,只是各自默认的场景不同——直到有人打开文件去找 <rte> 元素,却发现根本没有,这种偏差才会冒出来。

一个文件里到底装的是哪一种,什么时候真的要紧

大多数时候不要紧。一款能画线的地图 App,不管拿到的是轨迹还是路线都能画出线来,大部分查看器根本不会区分这两者。开始要紧的地方,是那些围绕"跟着路线走"而不是"回看轨迹"设计的导航类工具:一个指望拿到一串有序地点、逐段带你走下去的工具,读的就是 <rte> 元素本身,一个只有 <trk> 的文件,哪怕地图上的线看起来一模一样,也可能不会按那个工具期望的方式工作。反过来的情况也会发生——一条只有寥寥几个点的手工路线,放进指望拿到密集轨迹的工具里,地图上看起来没问题,却可能根本没有配速或海拔曲线需要的时间信息。

容易让人卡住的地方

• 文件里完全没有 <rte>——多数记录类 App 本来就不会写路线,因为一段被记录下来的行程,按定义就是轨迹,不是计划。
• 导入的路线没有配速或海拔曲线——文件里本来就没有能画出这类图的时间信息。
• 一个只读 <rte> 元素的工具,好像在文件里什么都没找到——那段行程其实是作为轨迹存在文件里的,只是挂在这个工具没去找的那个标签下。
• 路上散落着一个个点,却没有线连起来——多半是轨迹没导入成功,只有个别、更接近路线点的坐标被传了过来。

TrailCam 在这里的角色

TrailCam 把一次徒步、散步或骑行记录成一条 GPS 轨迹——实际移动过程中留下的一串带时间戳的点——然后导出成 GPX 1.1 或 CSV。这对应的正是 GPX 格式里"轨迹"的那一半,也是 Strava、Garmin Connect、Komoot 这类围绕回看已完成行程设计的服务几乎都会去读的那种数据。导出属于可选的 TrailCam Pro,App 本身免费下载。