為什麼我最多可以要求 2 小時的步行或自行車等時線，但開車等時線最多只能要求 1 小時？
這項限制是根據計算的運算複雜度而定。在相同時間內，車輛行駛的距離遠遠超過行人或自行車騎士，這表示必須分析的基礎路網會呈指數級擴展。為確保 API 能在快速的即時同步視窗內傳回回應，駕駛時間最多只能 1 小時 (3,600 秒)，而步行和騎自行車則最多可達 2 小時 (7,200 秒)。
如何計算「上班通勤」的抵達等時線 (前往目的地) 與出發等時線 (從起點出發)？
v1 API 支援使用 travel_direction 參數計算傳入和傳出資料：
FROM(出發)：計算指定時間限制內可從起點抵達的區域。適用於外送區域或服務涵蓋範圍等應用情境。fromTO(抵達)：計算您可以在指定時間限制內，從起點to抵達的區域。這適用於通勤功能等應用程式，或判斷中央辦公室或轉運中心周圍的集水區。
有時傳回的多邊形看起來會呈現方塊狀，或有鋸齒狀的階梯式邊緣，尤其是時間較長的情況。為什麼詳細程度會改變？
等時線 API 會根據要求的 travel_duration 和 travel_mode，動態調整空間計算格線的解析度：
- 較短的持續時間：使用精細的高解析度格線，因為總面積較小，因此會產生詳細的邊界。
- 時間較長：轉換為較粗略的低解析度格線，有效涵蓋廣大地理區域，不會造成嚴重延遲。
如果無論時間長度為何，您都需要特定詳細程度的資料，可以將選用的 polygon_fidelity 設為 HIGH、MEDIUM 或 LOW。
為什麼要求公園、湖泊或大型工業區內座標的等時線時，有時會傳回「找不到」錯誤？
等時線 API 會使用道路和路徑計算行程時間。如果要求的起點座標不在可辨識的道路上，API 必須先將點「貼齊」至最近的相容路段，才能開始計算。
每種交通方式都有特定的最大對齊距離門檻：
DRIVE：200 公尺 (忽略僅限行人的路徑)。BICYCLE：180 公尺。WALK：150 公尺。
如果起點座標與有效且與模式相容的路段距離超過這些門檻，系統就會無法貼齊，且 API 會傳回 NOT_FOUND 錯誤。如要解決這個問題，請確保座標位置靠近公共街道或路徑。
我在地圖上算繪 GeoJSON 回應時，形狀顯示的位置有誤、扭曲或無法算繪。造成這個問題的原因是什麼？
這幾乎都是因為座標順序不符所致。
根據 GeoJSON 標準 (RFC 7946)，等時區 API 會依 [longitude, latitude] 順序傳回座標。不過，許多地圖 SDK (包括 Google Maps JavaScript API 和各種行動地圖元件) 預期座標或 LatLng 物件的順序為 [latitude, longitude]。
如果地圖的算繪結果不正確，您必須在 GeoJSON 酬載中逐一檢查座標，並先轉置值，再將這些值傳遞至地圖 SDK。
為什麼等時區多邊形內有空心「洞」？可以改為實心形狀嗎？
洞代表在時限內無法抵達的區域。這在有大片森林、水體、機場或私人土地的區域很常見，因為車輛或行人無法通行。
外部 v1 API 不會公開自動移除孔洞的參數。如果應用程式需要明確的邊界 (例如執行多邊形內點的包含檢查)，您可以採取下列做法：
- 將
polygon_fidelity參數設為MEDIUM或LOW，鼓勵演算法概括並合併這些內部間隙。 - 使用用戶端 GIS 程式庫 (例如 Turf.js) 剖析 GeoJSON，並只擷取第一個座標環 (外殼)，捨棄後續的任何內部環 (洞)。
我是否應為後端空間分析啟用 enable_smoothing 選項？
否。enable_smoothing 參數僅供視覺美觀之用，
可將基礎計算格線的銳角變圓，讓地圖上的形狀看起來更自然。
平滑處理會改變頂點並稍微移動邊界，因此不建議用於精確的空間分析。如要進行後端計算、資料庫查詢或多邊形內點測試，請將 enable_smoothing 設為 false，確保使用數學上精確的計算邊界。