我要算一條登山路線的總爬升。手上有一串座標，缺的是每個點的高度。
免費的高程服務打一下就回來了，而且回得很有把握：3872.0。帶小數點，看起來精確到公分。
玉山主峰（OSM 標高 3952 公尺） ───────────────────────────────────────── srtm30m 3921 低 31 公尺 mapzen 3921 低 31 srtm90m 3911 低 41 aster30m 3872 低 80 天氣 API 的網格 3861 低 91 ───────────────────────────────────────── 五個都低估，彼此最多差 60 公尺
我以為發生了什麼
我以為高程是個客觀事實。地表就在那裡，量一次就有答案，不同的服務只是把同一份測量結果轉發給我。
我也以為小數點代表精確度。
實際發生了什麼
2026-09-17 實測，同一組經緯度（23.469987, 120.957273，OSM 標的玉山主峰，標高 3952 公尺）打五個來源：
srtm30m 回 3921、mapzen 回 3921、srtm90m 回 3911、aster30m 回 3872，而某個天氣服務自己回報的網格高度是 3861。
沒有一個是 3952。全部低估，最少差 31 公尺，最多差 91 公尺，而它們彼此之間也差了 60 公尺。
更要命的是座標的敏感度。同一個 aster30m，我把經度從 120.9573 改成 120.95——橫向大約七百五十公尺——它回 3355。同一個資料集、同一座山，差 517 公尺。
原因不難懂：這些資料是網格，一格涵蓋三十到九十公尺見方，山頂那種尖的地形會被整片抹平。而你只要沒站在格子正中央，拿到的就是隔壁那格的高度。
官方文件寫了嗎
有寫，但寫的是規格不是後果。文件會告訴你這份資料的網格大小、覆蓋範圍、垂直精度的統計值。
它不會告訴你的是：對山頂、稜線、塔狀岩峰這種地形，「平均誤差」這個數字沒有意義，因為誤差不是隨機分布的，而是系統性地往低估那一邊倒。平地量得準，山頂一定偏低。
你一定會踩的那個細節
真正的陷阱不是它不準，是它不準的時候完全不會說。
沒有信心區間、沒有警告、沒有「這個點附近地形變化劇烈」的旗標。它回 HTTP 200，回一個帶小數點的浮點數，跟一個查平地的請求長得一模一樣。
所以驗證不能拿 DEM 去對 DEM——兩個都低估的東西互相印證，只會得到「一致」這個假訊號。要有一個外部的宣稱高度才構成驗證：
拿一批你已知正解的點，做一次對照： 1. 準備 20 個有官方標高的點（山峰的 OSM ele 標籤、 三角點資料、地圖上印的高程都可以） 2. 用你要採用的那個資料集逐點查一次 3. 算「查到的 − 官方的」，看這串差值的分布 差值全部同號（都低估）→ 系統性偏差，可以整批校正 差值忽正忽負且很大 → 座標有問題，不是資料集的問題 沒有第二個宣稱高度可比對的點，就標「未驗證」， 不要因為它回了 200 就當成查過。
站內延伸
來源： OpenTopoData 公開端點（aster30m／srtm30m／srtm90m／mapzen）、Open-Meteo forecast 端點的 elevation 欄、OSM 該 peak 節點的 ele 標籤，皆為 2026-09-17 當日實測。
一個帶小數點的數字，看起來像是量出來的，其實是算出來的。要判斷它能不能用，得先知道它是怎麼來的——而這件事永遠不會寫在回傳的 JSON 裡。