インバウンドの「通勤」等時線（目的地への移動）とアウトバウンドの等時線（出発地からの移動）を計算するにはどうすればよいですか？
v1 API では、travelDirection（travel_direction）パラメータを使用して、インバウンドとアウトバウンドの両方の計算がサポートされています。
FROM（往路）: 指定された制限時間内に出発地点から到達可能なエリアを計算します。fromこれは、配達エリアやサービス提供エリアなどのユースケースに適しています。TO（インバウンド）: 指定された制限時間内に出発地点からto移動できるエリアを計算します。これは、通勤機能や、中央オフィスや交通ハブ周辺の集客エリアの決定などのアプリケーションに適しています。
4 つの移動手段（DRIVE、TWO_WHEELER、BICYCLE、WALK）の違いは何ですか？
各モードでは、独自の道路ネットワーク アクセス ルール、ターンコスト、速度モデルが使用されます。
DRIVE: 走行可能な道路を、制限速度、自由流速度、またはリアルタイムの交通速度（TRAFFIC_AWARE）を使用して、最大 3,600 秒（60 分）まで移動します。TWO_WHEELER: 高速道路でDRIVEよりも低いモデル速度で、オプションのTRAFFIC_AWAREルーティングを使用して、最大 3,600 秒（60 分）で、自動二輪車が通行可能な道路を走破します。その結果、TWO_WHEELER等時線はBICYCLEより大きくなりますが、高速道路沿いのDRIVEよりは小さくなります。BICYCLE: 自転車が通行可能な道路、自転車レーン、道路の種類と傾斜に合わせて速度が調整された経路（高速道路と自動車専用道路を除く）を最大 7,200 秒（120 分）まで移動します。WALK: 歩行者用の歩道、トレイル、道路を、傾斜に合わせて調整された歩行速度で移動します（車両の一方通行制限は無視されます）。最大 7,200 秒（120 分）です。
Isochrones API にはフェリーや水路の横断が含まれますか？
いいえ。Isochrones API は、道路、橋、トンネル、経路の接続のみを走査します。フェリー航路と水上交通の横断は、すべての移動手段で除外されます。フェリーでのみ接続されている島や半島は、本土から生成された等時線には含まれません。
返されたポリゴンが、特に期間が長い場合に、ブロック状に見えたり、ギザギザの階段状のエッジになったりすることがあります。詳細レベルが変化するのはなぜですか？
Isochrones API は、リクエストされた travel_duration と travel_mode に基づいて、空間計算グリッドの解像度を動的に調整します。
- 期間が短い: 合計エリアが小さいため、高度に調整された高解像度のグリッドを使用します。これにより、詳細な境界が生成されます。
- 期間が長い場合: 粗い低解像度のグリッドに移行して、深刻なレイテンシを発生させることなく、広大な地理的エリアを効率的にカバーします。
期間に関係なく、特定の、一貫した詳細レベルが必要な場合は、オプションの polygon_fidelity を HIGH、MEDIUM、または LOW に設定できます。
公園、湖、大規模な工業団地内の座標の等時線をリクエストすると、「Not Found」エラーが返されることがあるのはなぜですか？
Isochrones API は、道路と経路を使用して移動時間を計算します。リクエストされた出発地の座標が認識された道路上にない場合、API は計算を開始する前に、最も近い互換性のあるセグメントにポイントを「スナップ」する必要があります。
各移動手段の最大スナップ距離は約 200 メートル以下です。WALK と BICYCLE は DRIVE と TWO_WHEELER よりも短い距離を使用し、DRIVE と TWO_WHEELER は歩行者専用の経路を無視します。
出発地の座標が、モードに対応した有効な道路セグメントからこの距離よりも離れている場合、スナップは失敗し、API から NOT_FOUND エラーが返されます。この問題を解決するには、座標が公道または歩道の近くに配置されていることを確認してください。
徒歩または自転車の交通状況を考慮したルートをリクエストするとエラーが発生するのはなぜですか？
リアルタイムの交通状況（TRAFFIC_AWARE）は、DRIVE と TWO_WHEELER の移動手段でサポートされています。routingPreference を TRAFFIC_AWARE に設定して WALK または BICYCLE の等時線をリクエストしようとすると、API は 400 INVALID_ARGUMENT エラーを返します。
マイマップ上に GeoJSON レスポンスをレンダリングすると、形状が間違った場所に表示される、歪む、またはレンダリングされない。原因は何ですか？
これはほとんどの場合、座標の順序が一致していないことが原因です。
GeoJSON 標準（RFC 7946）に従い、Isochrones 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 に設定したままにして、数学的に正確に計算された境界を使用するようにします。