Isochrones API に関するよくある質問

徒歩または自転車の等時線は最大 2 時間までリクエストできるのに、運転は 1 時間に制限されているのはなぜですか?

この制限は、計算の計算複雑度に基づいています。車両は同じ時間で歩行者や自転車よりもはるかに長い距離を移動するため、分析する必要がある基盤となる道路網が指数関数的に拡大します。運転は最大 1 時間(3,600 秒)に制限されています。これは、API が高速なリアルタイム同期ウィンドウ内で応答を返せるようにするためです。一方、徒歩と自転車は最大 2 時間(7,200 秒)までサポートされています。

通勤の等時線(目的地に向かう)と、出発地の等時線(出発地から出発する)を計算するにはどうすればよいですか?

v1 API では、travel_direction パラメータを使用して、インバウンドとアウトバウンドの両方の計算がサポートされています。

  • FROM(アウトバウンド): 指定された時間制限内で出発地点から到達可能なエリアを計算します。配送ゾーンやサービス範囲などのユースケースに適しています。from

  • TO(流入): 指定された時間内に to の出発地点に移動できるエリアを計算します。これは、通勤機能や、本社や交通機関のハブ周辺の集客ゾーンの特定などのアプリケーションに適しています。

返されるポリゴンがブロック状になったり、ギザギザの階段状の境界線になったりすることがあります(特に期間が長い場合)。詳細レベルが変化するのはなぜですか?

Isochrones API は、リクエストされた travel_durationtravel_mode に基づいて、空間計算グリッドの解像度を動的に調整します。

  • 期間が短い場合: 総面積が小さいため、高解像度のグリッドを使用すると、境界が詳細になります。
  • 期間が長い場合: 粗い低解像度のグリッドに移行して、大きな地理的領域を効率的にカバーし、レイテンシの増加を抑えます。

期間に関係なく、特定の詳細レベルを維持する必要がある場合は、オプションの polygon_fidelityHIGHMEDIUM、または LOW に設定できます。

公園、湖、大規模な工業団地内の座標のアイソクロンのリクエストで、「Not Found」エラーが返されることがあるのはなぜですか?

等時線 API は、道路と経路を使用して移動時間を計算します。リクエストされた出発地の座標が認識された道路上にない場合、API は計算を開始する前に、ポイントを最も近い互換性のあるセグメントにスナップする必要があります。

各移動手段には、特定のスナップ距離の最大しきい値があります。

  • DRIVE: 200 メートル(歩行者専用の経路は無視されます)。
  • BICYCLE: 180 メートル。
  • WALK: 150 メートル。

出発地の座標がこれらのしきい値よりも有効なモード互換の道路セグメントから離れている場合、スナップは失敗し、API は NOT_FOUND エラーを返します。この問題を解決するには、座標が公道または歩道の近くに配置されていることを確認してください。

地図上に GeoJSON レスポンスをレンダリングすると、シェイプが間違った場所に表示される、歪んで表示される、レンダリングされない。原因は何ですか?

これはほとんどの場合、座標の順序の不一致が原因です。

Isochrones API は、GeoJSON 標準(RFC 7946)に従って、[longitude, latitude] の順序で座標を返します。ただし、Google Maps JavaScript API やさまざまなモバイルマップ コンポーネントなど、多くのマッピング SDK では、座標または LatLng オブジェクトが [latitude, longitude] の順序で指定されることが想定されています。

地図のレンダリングが正しくない場合は、GeoJSON ペイロードの座標をループ処理し、値を転置してから地図 SDK に渡す必要があります。

等時線ポリゴンの内部に「穴」が開いているのはなぜですか?代わりに塗りつぶされた形状を取得できますか?

穴は、制限時間内に到達可能な道路がないエリアを表します。これは、車両や歩行者が通行できない広大な森林、水域、空港、私有地がある地域でよく見られます。

外部 v1 API には、穴を自動的に削除するパラメータがありません。アプリケーションで、ポリゴン内のポイントの包含チェックを行うなど、明確な境界が必要な場合は、次の操作を行います。

  • polygon_fidelity パラメータを MEDIUM または LOW に設定して、アルゴリズムがこれらの内部ギャップを一般化して統合するようにします。
  • クライアントサイドの GIS ライブラリ(Turf.js など)を使用して GeoJSON を解析し、最初の座標リング(外側のシェル)のみを抽出し、後続の内側のリング(穴)を破棄します。

バックエンドの空間分析で enable_smoothing オプションを有効にする必要がありますか?

いいえ。enable_smoothing パラメータは、純粋に視覚的な美しさを目的として設計されています。基盤となる計算グリッドの鋭い角を丸めて、地図上で形状が自然に見えるようにします。

平滑化は、頂点を変更し、境界をわずかにシフトするため、正確な空間分析にはおすすめしません。バックエンドの計算、データベース クエリ、ポイントインポリゴン テストでは、enable_smoothingfalse に設定して、数学的に正確な計算境界を使用するようにしてください。