GPX 和 polyline：轨迹数据用哪个更适合徒步

polyline 究竟是什么

大多数人碰到的 polyline，是 Google 的 Encoded Polyline Algorithm Format，也是大多数需要在响应里把路线形状传回来的地图和路线规划 API 用的同一套方案。它接收一串经纬度坐标，把每个坐标四舍五入到小数点后五位，只保存跟上一个点的差值而不是坐标本身，再用一套类似 base64 的字符集把结果压进一小段 ASCII 字符里。一条按原始坐标存放可能要好几 KB 的路线，编码成 polyline 后可能只有几百个字符。

这段字符串本来就不是设计来单独打开、阅读或者保存的。它存在的意义是在一次 JSON 响应或者 URL 参数里跑一趟，被画地图的那一端解码回坐标列表，地图画出来之后就没用了，可以扔掉。它是路上的一个形状，不是一份记录。

GPX 装得下、polyline 却没地方放的东西

GPX 的轨迹点除了位置之外，还带着时间戳和海拔，有些设备还会在 extensions 里塞进 GPS 精度之类的额外字段。这些东西 polyline 一样都装不下，因为这个格式从一开始就只回答一个问题——这条线经过哪里，别的什么都不管。把时间戳从一次徒步里拿掉，就没法算出走了多久、哪个时刻的配速是多少、哪一段是移动时间、哪一段是停下来。把海拔拿掉，就没有了爬升曲线，没有上升也没有下降。polyline 回答的只是「去了哪里」，「什么时候」和「爬了多高」它一句都不提。

精度也被一并舍掉了

标准 polyline 编码里内置的五位小数四舍五入，本身就是一个小小的、故意做出的取舍——在赤道附近大约相当于一米的精度，换来的是它服务的那些 API 响应主要是为了在屏幕上画一条线，而不是为了精确测量一条路线。这笔交易在 polyline 实际被用到的场景里是划算的。但一旦目的从「把路线画出来」变成「把路线量出来」，这笔交易就不再成立了——而这正是一条地图上的线，变成一次想要真实距离和海拔数字的徒步时，发生的转变。

摆在一起比较

• 结构：GPX 是完整的文档，每个点各自带着时间戳和海拔；polyline 是一整段没有时间戳、也没有海拔的编码字符串。
• 来源：GPX 是 2002 年发布的开放格式，为 GPS 设备而设计；编码 polyline 格式是 Google 为自己的 Maps API 发布的，目的是让 API 响应里的路线形状尽量小。
• 兼容性：几乎所有为读取轨迹文件而做的地图、GIS、GPS 工具都能打开 GPX；polyline 得先有专门针对这套编码写的解码器，才能变成能用的东西。
• 适合场景：想保留、想测量、想导入别的工具的徒步用 GPX；在服务器和地图之间临时传一下路线形状用 polyline。
• 可读性：GPX 是纯文本 XML，肉眼就能读；polyline 是一串不透明的字符，就算准确无误，不解码也看不出任何意义。

两者互相转换

把 GPX 轨迹转成 polyline 是单向的。不少库和在线工具能读出 GPX 文件里的坐标，把它们编码成 polyline 字符串，但让 GPX 文件适合用来回顾一次徒步的那些东西——时间戳、海拔、逐点的细节——在目标格式里根本没地方放，只能被丢在半路。转换出来的东西画的是同一个形状，仅此而已。

反过来转更糟，因为已经没什么可丢了。把 polyline 解码回坐标，得到的只是一串光秃秃的经纬度，因为本来就没存过任何时间戳或海拔。想从这里再拼出一个 GPX 文件，做的就不是找回丢失的东西，而是凭空造出缺的那部分——比如沿着这条线均匀地编几个假时间戳——做出来的文件看着像一次记录，其实并不是。

TrailCam 导出什么格式

TrailCam 把记录下来的路线导出成 GPX 1.1 或者 CSV 汇总，两种格式都会在每个点上保留时间戳和海拔，而不是把一次徒步压缩成一个光秃秃的形状。对于想事后回顾、导入别的工具，或者当成一份真正的记录留着，而不是某张地图曾经画过的一条线的徒步来说，这个差别很重要。GPX 和 CSV 导出属于可选的 TrailCam Pro，App 本身免费下载。