我有 6 支作品要在地圖上畫登山路線。作法看起來都一樣：拿一條路線的資料，把座標接成線，畫上去。
聽起來是一件很單純的事——一串座標而已。實際抓下來才發現，它根本不是一串座標。
抓一條路線，回 200 ────────────────────────────────────────── 你看到的 資料裡的 一條連續的線 → 5 段 一串座標點 → 956 個點，分散在那 5 段裡 ────────────────────────────────────────── 段的先後順序與每段的方向，都不保證
它是一份名單，不是一條線
2026-09-17 實測：用 OpenStreetMap 主 API 抓一條路線的完整結構，回 HTTP 200。
回來的東西不是一條線，是一個集合：這條路線由 5 段組成，5 段加起來共 956 個座標點。
為什麼要切成段？因為那些段本來就各自存在——它們是實際的路徑，一段可能同時被好幾條路線用到。所謂「一條路線」，是一份把這些段列在一起的名單。
地圖上那條連續的線是畫出來的結果，不是資料原本的樣子。
這件事會改變三個地方的寫法
算總長度。 要每一段各算一次再加起來。只算第一段不會報錯，只會給你一個小很多的數字，而那個數字看起來完全正常。
標起點和終點。 不能假設名單上第一段的頭就是起點、最後一段的尾就是終點。段在名單裡的排列順序不保證是走的順序，每一段自己的方向也不保證跟行進方向一致。要靠頭尾座標對得上不對得上去判斷，不能靠位置。
主線和變體要分開存。 長程路線幾乎都帶著替代路段、逃生路線、接駁岔路。它們在資料裡跟主線是平等的，全部倒進同一組座標畫出去，線會互相跳來跳去，看起來像資料壞掉。
6 支作品吃的是同一套結構
這 6 支的路線來自不同國家、不同資料來源、長度差很多，但拿回來的形狀一樣：一份段的名單。
所以處理這件事的程式只需要想通一次。第一支花掉最多時間，是因為在搞懂這個結構；後面幾支是把同一套骨架換上不同的資料。
可以拿去改的起點
拿到一條路線之後，第一件事不是畫，是數：
先數，再決定怎麼接： 1. 印出這條路線由幾段組成 2. 逐段印出每段有幾個座標點，順便看有沒有 哪一段只有一兩個點（那通常是標記，不是路） 3. 印出每段的頭座標與尾座標 4. 比對前一段的尾跟下一段的頭是不是同一點； 不是的話，記下來 5. 把第 4 步記下來的缺口列成清單 缺口清單是空的，照名單順序接起來就對了。 缺口清單不是空的，那幾段要自己決定順序或反轉。 先畫再回頭查，你會分不清是資料本來就斷， 還是你接錯了。
站內延伸
來源： OpenStreetMap 主 API 的 relation full 端點，取回一條路線的完整結構後，逐段計數 way 與座標點，2026-09-17 實測。
會出事的地方，常常是你以為不用確認的那一步。「一條路線就是一串座標」這個假設不會讓程式當掉，它只會讓總長度短一截、起點標在中間、幾條線纏在一起——而這三件事你都得自己看出來，沒有人會通知你。