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