このドキュメントでは、道路管理インサイト（RMI）プロダクトの Road Selection API を使用して SelectedRoutes を定義するためのベスト プラクティスについて説明します。SelectedRoutes を適切に定義することは、モニタリング対象の道路セグメントについて正確で信頼性の高い交通量データを取得するために最も重要なステップです。技術概要について詳しくは、公式の Road Selection API のドキュメントをご覧ください。
SelectedRoute の作成に関する基本原則
モニタリング用の SelectedRoute を定義する場合は、SelectedRoute の精度とデータの有効性を確保するために、次の原則に従う必要があります。
1. 路肩に固有である
SelectedRoute は、単一の移動方向を表す必要があります。中央分離帯のある高速道路や道路の場合は、方向ごとに個別の SelectedRoute オブジェクトを作成する必要があります（たとえば、北行き用に 1 つ、南行き用に 1 つ）。出発地、目的地、中間地点が、監視する方向の道路の正しい側に配置されていることを確認します。分割された高速道路の誤った側に起点または終点を配置すると、意図しない SelectedRoutes またはデータエラーが発生する可能性があります。
2. 多層道路と高架道路を処理する
複数のレベルがある複雑な道路（高速道路の積み重ね、高架、複雑なインターチェンジなど）では、単一の緯度と経度のペアが曖昧になり、ルートが誤ったレベルに「スナップ」される可能性があります。これを防ぐには、中間地点を使用して、正しい道路セグメントとレベルにルートを誘導する必要があります。経由地を 1 つ以上追加すると、ルートがユーザーの意図に沿ったものになります。
3. 有効な開始点と終了点を定義する
SelectedRoute は、トンネルの内部で開始または終了することはできません。SelectedRoute の出発地と目的地のポイントは、屋外の場所に設定する必要があります。トンネルを通過する SelectedRoute はサポートされていますが、モニタリング セグメント自体はトンネル内で開始または終了できません。
4. 適切なルートの長さを定義する
SelectedRoute は柔軟性があり、さまざまなスケールで定義できます。
- 短いルート: SelectedRoute は 1 つの街区ほど小さくすることもできます。これは、都市部での詳細な分析に役立ちます。
- 均等なルート: 均等な距離（0.5 マイルごとなど）の SelectedRoutes を定義して、一貫したレポートを作成できます。
- 長いルート: SelectedRoute は、長く連続した道路をカバーできます。これは、高速道路の全区間や、重要な交差点間の主要幹線道路をモニタリングする場合に最適です。
モニタリングと分析のニーズに最も適した SelectedRoute の長さを選択します。
5. 垂直方向に分離された道路セグメント（トンネル、高架、橋など）を識別する
緯度と経度の座標を使用して道路セグメントを定義する場合は、複数の道路セグメントが同じ 2 次元地理空間を占有しているが、垂直方向に分離されているシナリオを考慮することが重要です。これは、トンネル、高架、陸橋、橋などの構造物でよく発生します。緯度と経度のみに依存し、標高を考慮しないと、SelectedRoute の選択とナビゲーションの精度が低下する可能性があります。たとえば、トンネルを通る道路は、その上の地表の道路セグメントと同じ上空の緯度と経度を持ちます。同様に、高架や橋は、その下の道路と水平座標を共有します。これらの垂直方向に積み重ねられたセグメントを区別できないと、上位の道路が意図されている場合に下位の道路にトラフィックが誤って転送されたり、その逆のことが起こったりする可能性があります。
この例では、ボストン（42.362347, -71.055935）に Big Dig という巨大なトンネルがあります。
道路上に経由地を配置する場合、正確な地理座標のわずかな誤差でも、ルートの計算結果が大きく異なることがあります。この経由地の配置に対する感度は、SelectedRoute 選択アルゴリズムの重要な要素です。
たとえば、ウェイポイントがトンネルのすぐ内側に設定されているシナリオを考えてみましょう。この経由地の位置が、緯度と経度の座標がほぼ同じであるにもかかわらず、隣接するアクセス道路にわずかに調整されると、ルーティング エンジンはまったく異なるルートを生成する可能性があります。この現象は、正確な経由地の入力の重要性と、特に複雑な道路網や地理的特徴がある地域でのルート最適化の複雑さを浮き彫りにしています。
6.すべての道路が追跡可能ではない
SelectedRoute が常に追跡可能とは限りません
- 登録された「管轄区域」以外
- 「道路の有用性」が低い
- これにより、時間の経過とともに追跡可能性が変化する可能性があります。
検証は非同期で実行されます ⇒ 登録された SelectedRoutes がすべてこの検証に合格しているかどうかを確認します
SelectedRoute 定義のベスト プラクティス
以下のベスト プラクティスに沿って、SelectedRoute の定義と結果データの品質を高めてください。
中間ウェイポイント（中間地点）を使用する
短く、一見すると単純な SelectedRoute であっても、少なくとも 1 つの中間経由地を含めることを強くおすすめします。
- 理由
- ガイド付きルーティング: 特に、出発地と目的地の間で代替道路が存在する場合に、SelectedRoute が目的の特定のルートに沿って進むようにします。
- ループを有効にする: 出発地と目的地が同じループまたは「往復」の SelectedRoute を正しく表すために必要です。
- 迂回路の検出の改善: 経由地を多く指定するほど、交通状況が意図した SelectedRoute から逸脱した可能性のあるデータポイントを検出しやすくなります。
- 方法
- 地理空間関数を使用して、既知の SelectedRoute に沿った中間点をプログラムで検索できます。
- 例（BigQuery）: ST_LINEINTERPOLATEPOINT 関数を使用します。
- 例（JavaScript）: Turf.js ライブラリの along 関数を使用します。
外部システムのルートを照合する
外部の GIS や別の道路網上に構築されたシステムからルートデータをインポートする場合、座標が Google の道路網と完全に一致しないことがあります。これにより、「意図しないルート」が生成される可能性があります。
- 修正方法:
- 道路のどちら側にあるかを確認する: まず、出発地と出発地点が道路の正しい側にあることを確認します。
- 道路へのスナップ: Roads API v2 の matchPath メソッドを使用して、既存のルートデータを Google の道路網にスナップします。
- 手動で調整して再描画する: ツールで経由地を手動で調整し、Google の道路に合わせます。次に、Routes API の computeRoute メソッド（トラフィックを「認識しない」に設定）を使用して、Google のネットワークに沿ったクリーンなポリラインを生成します。
- トレース: 最終手段として、GIS ツールで Google の道路網にデータを重ね合わせ、手動でルートをトレースして新しい経由地を作成します。
データ クリーニングと検証
BigQuery で受信するデータには、実際の状況が反映されます。クレンジング ステップを適用して、コアの SelectedRoute を表していないデータをフィルタする必要があります。
迂回を処理する
RMI を支える Routes API は、常に有効なルートを返そうとします。目的の SelectedRoute がブロックされているか、非常に混雑している場合、API は迂回して定義された中間経由地から外れるルートを返すことがあります。たとえば、SelectedRoute で A -> B -> C のルートを指定した場合、迂回路によって A -> C のルートが返されることがあります。
RMI の場合、これらの迂回レコードは、モニタリングしている特定の SelectedRoute を表していないため、あまり役に立ちません。
- アクション: これらの行を削除するだけではいけません。迂回が発生するタイミングと理由を把握するために、分析用にフラグを設定する必要があります。
- 迂回路をフラグ設定する方法: 迂回路をプログラムで識別するには、主に次の 2 つの方法があります。
- 経由地の不一致: 返されたルートのジオメトリに、指定したすべての中間経由地が含まれていないかどうかを確認します。
- 距離の不一致: 返されたルートの
distanceが、SelectedRouteの予測距離と大きく異なるかどうかを確認します。一般的なしきい値は 5% の差です。
- 迂回を検出する BigQuery の例:
SelectedRoutesテーブル（予想距離を含む）をRouteResponsesテーブルと結合し、CASEステートメントを使用してフラグを作成できます。
「MultiLineString」ジオメトリの処理
BigQuery の GEOGRAPHY データ型には、制限があります。それ自体と重複する単一の LineString（カーブした U ターン、迂回路のために折り返すルートなど）を保存できません。
- 現象: このような場合、BigQuery はジオメトリを
MultiLineStringとして保存し、ルートの一部が欠落する可能性があります。 - 対応: これらのレコードは、メインの分析から除外する必要があります。
- BigQuery フィルタ:
WHERE ST_GEOMETRYTYPE(route_geometry) != "ST_MultiLineString"を使用します。
- BigQuery フィルタ:
- 解決策:
- 迂回が原因で重複が発生している場合は、上記のようにレコードをフィルタできます。
- 目的の SelectedRoute に重複が含まれている場合は、SelectedRoute を 2 つ以上の個別の
SelectedRouteオブジェクトに分割して再定義する必要があります。
タイムゾーン変換
RMI BigQuery エクスポートのすべてのタイムスタンプ データは、協定世界時（UTC）で提供されます。ローカル タイムゾーンでのレポート作成や分析を行う場合は、これらのタイムスタンプを変換する必要があります。
- BigQuery の時間変換の例:
DATETIME関数とTIMESTAMP関数を使用して、UTC タイムスタンプを特定のローカル タイムゾーン（「America/Los_Angeles」など）に変換します。
まとめ
このガイドで説明するベスト プラクティスに従うことで、SelectedRoute 定義の精度と堅牢性を確保し、道路情報管理の分析情報から信頼性の高い実用的な交通データを取得できます。道路管理のニーズに合わせて RMI の可能性を最大限に引き出すには、ルートを適切に定義し、複雑な道路形状を処理し、結果として得られたデータを検証することが重要です。
著者
Sarthak Gangopadhyay: Google マップ Devrel Naoya Moritani: Google マップ Devrel