ルーティング

14.1 ルーティング

ルートは、場所要素間で計算されます。

<start_location>、<location> (中間地または中間地点)、<end_location>という3種類の場所要素があります。場所要素は、ジオコード化された住所、事前ジオコード済の住所、エッジID/パーセンテージのペアまたは逆ジオコード化された緯度/経度ペアとして指定できます。

ルーティング・エンジンでは、その計算に出発時間を組み込むことができます。たとえば、都市圏では、平日に自宅から空港まで自動車で行く場合の推定所要時間は、午前8時と午後7時で大きく異なります。時間の計算は、リアルタイムの収集データではなく、過去のトラフィック・パターンに基づきます。(たとえば、現在の事故や悪天候は考慮されません)。

このオプションの機能を含めるには、ルート・リクエストにstart_timeとオプションのstart_date値を指定し、return_route_timeをtrueに設定して(つまり、レスポンスに合計推定ルート時間を含める)、タイム・ゾーン・ユーザー・データを使用可能にします。return_route_timeがtrueで、出発時間が指定されない場合、ルート・リクエストが発行された時間が出発時間とみなされます。(関連する属性については、「ルーティング・エンジンのXML API」を参照してください。)

このオプション機能は、一括ルート・リクエストやバッチ・モード・リクエストには適用されません。

親トピック: ルーティング・エンジン

14.1.1 単純ルート・リクエスト

単純ルート・リクエストには、<start_location>と<end_location>の両方の要素が含まれます。単純ルート・リクエストのレスポンスは、出発地から目的地までの単一のルートです。

単純ルート・リクエスト内のいくつかの属性は、ルートの計算方法およびルート・レスポンスで戻される内容を制御します。これらの属性については、「ルーティング・エンジンのXML API」で説明しています。

親トピック: ルーティング

14.1.2 単純マルチアドレス・ルート・リクエスト

単純マルチアドレス・ルート・リクエストには、必須の<start_location>要素など、少なくとも3つの場所が含まれている必要があります。マルチアドレス・ルート・リクエストには、1つ以上の<location>要素も含まれている必要があり、オプションで<end_location>要素が含まれます。

単純マルチアドレス・ルート・リクエストの結果は、各中間地を通る、出発地から目的地までの単一のルートです。この単一ルートは複数のサブルートで構成されます。サブルートは、個々の場所間のルートです。

単純マルチアドレス・ルート・リクエストでは、optimize_route属性が存在しないかFALSEに設定されている必要があります。単純マルチアドレス・ルート・リクエストでは、すべての場所が固定されます。場所を訪れる順序の最適化は試行されません。ルート内の場所は、リクエストで指定された順序で訪問されます。

単純マルチアドレス・ルート・リクエストでは、route_type属性を使用して、ルートを開いた行程または閉じた行程として分類します。

開いた行程: ルートは最終中間地または指定した目的地で終了します。
閉じた行程: ルートは出発地に戻ります。

単純マルチアドレスの閉じた行程ルートがリクエストされた場合、ルート計算中に<start_location>要素指定は目的地としても使用されます。単純マルチアドレスの閉じた行程ルート・リクエストで<end_location>要素が指定されている場合は、エラーが戻されます。

例: 単純マルチアドレスの開いた行程ルート・リクエスト

職場から顧客Aまで運転し、次に顧客B、その次に顧客Cまで運転する必要があるとします。

ルート・リクエストには、職場が出発地、顧客AとBが中間地、そして顧客Cが目的地として含まれます。
戻されるルートには、(1)職場から顧客A、(2)顧客Aから顧客Bおよび(3)顧客Bから顧客Cという3つのサブルートが含まれます。
各サブルートには、複数のセグメントが含まれる場合があり、各セグメントは、特定の運転方向ステップに関連付けられます。

例: 単純マルチアドレスの閉じた行程ルート・リクエスト

職場から顧客Aまで運転し、次に顧客B、その次に顧客Cまで運転してから、職場に戻る必要があるとします。

ルート・リクエストには、職場が出発地、顧客A、B、Cが中間地として含まれます。職場は目的地としても使用されます。<end_location>要素はルート・リクエストで指定しないでください。ルーティング・エンジンは、閉じた行程のリクエストを検出すると、顧客Cから職場までのサブルートを自動的に追加します。
戻されるルートには、(1)職場から顧客A、(2)顧客Aから顧客B、(3)顧客Bから顧客Cおよび(4)顧客Cから職場という4つのサブルートが含まれます。
各サブルートには、複数のセグメントが含まれる場合があり、各セグメントは、特定の運転方向ステップに関連付けられます。

単純マルチアドレス・リクエストには、各サブルートに固有の複数の属性を含めることができます。これらの属性には、return_subroutes、return_subroute_edge_idsおよびreturn_subroute_geometryが含まれます。これらの属性については、「ルート・リクエストXMLスキーマ定義」で説明しています。

親トピック: ルーティング

14.1.3 巡回セールスマン(TSP)ルート・リクエスト

巡回セールスマン(TSP)ルート・リクエストには、少なくとも3つの場所が必要です。単純マルチアドレス・ルート・リクエストとは異なり、<start_location>要素はオプションです。

TSPルート・リクエストは、optimize_route属性が存在し、TRUEに設定されたマルチアドレス・リクエストです。TSPルート・リクエストは、リクエスト内の固定されていない場所を並べ替えて全体的なルートの最適化を試みます。

TSPリクエスト内のすべての場所は、非固定または固定として分類されます。

非固定の場所: 場所が<location>要素で指定されている場合は、非固定の場所とみなされ、ルート計算時に並替えの対象となります。
固定の場所: 場所が<start_location>または<end_location>要素で指定されている場合は、固定の場所とみなされ、ルート計算時に並替えの対象になりません。

中間地を固定する必要がある場合は、TSPルート・リクエストのかわりに単純マルチアドレス・ルート・リクエストを使用する必要があります。

TSPルート・リクエストでは、route_type属性を使用して、ルートを開いた行程または閉じた行程として分類します。

開いた行程: ルートは出発地に戻りません。
閉じた行程: ルートは出発地に戻ります。

TSPの閉じた行程ルートがリクエストされた場合は、<start_location>要素を指定する必要があります。この出発地はルート計算中に目的地としても使用されます。TSPの閉じた行程ルート・リクエストで<end_location>要素が指定されている場合は、エラーが戻されます。定義では、TSPの閉じた行程ルートは単一の固定の出発および目的地を使用しますが、中間地は並替えの対象となります。

例: TSPの開いた行程ルート・リクエスト

職場から運転し、顧客A、B、Cを訪問する場合は、次のようになります。

ルートには固定の出発地として職場があります。
ルートには、非固定の中間地として顧客A、B、Cがあります。これらの場所が並べ替えられて、全体的なルートが最適化されます。
戻されるルートは、職場から最初の並べ替えられた場所、さらに2番目の並べ替えられた場所を通過して最終目的地に到達する、最適化された開いた行程ルートです。

例: TSPの閉じた行程ルート・リクエスト

職場から運転し、顧客A、B、Cを訪問し、職場に戻る場合は、次のようになります。

ルートには固定の出発地として職場があります。職場は固定の目的地としても使用されます。<end_location>要素はルート・リクエストで指定しないでください。ルーティング・エンジンは、閉じた行程のリクエストを検出すると、最後の非固定の場所から職場までのサブルートを自動的に追加します。
ルートには、非固定の中間地として顧客A、B、Cがあります。これらの場所が並べ替えられて、全体的なルートが最適化されます。
戻されるルートは、職場から最初の並べ替えられた場所、さらに2番目と3番目の並べ替えられた場所を通過して最終的に出発地に戻る、最適化された閉じた行程ルートです。

TSPルート・リクエストには、各サブルートに固有の複数の属性を含めることができます。これらの属性には、return_subroutes、return_subroute_edge_idsおよびreturn_subroute_geometryが含まれます。これらの属性については、「ルート・リクエストXMLスキーマ定義」で説明しています。

親トピック: ルーティング

14.1.4 一括ルート・リクエスト

一括ルート・リクエストは、バッチ・モード・リクエスト(「バッチ・モード・ルート・リクエスト」で説明)と個別のルート・リクエストのハイブリッドです。一括ルート・リクエストは、複数の単純、単純マルチアドレスおよびTSPルート・リクエストをルーティング・エンジンに対する1つのリクエストで処理する方法です。バッチ・モード・リクエストの一括処理は許可されていません。

バッチ・モード・リクエストと同様に、一括ルート・リクエストの一番外側の要素は<batch_route_request>です。バッチ・モード・リクエストとは異なり、一括ルート・リクエストにはバッチ・リクエストの内部に1つ以上の<route_request>要素がネストされています。

一括ルート・リクエストでは、含まれる<batch_route_request>要素に関連する属性はすべて無視されます。かわりに、ネストされた<route_request>要素に関連付けられた属性が個々のルートの処理時に使用されます。これにより、ユーザーは単一の一括個別ルート・リクエスト内に単純、単純マルチアドレスおよびTSPの各リクエストを混在させることができます。

一括ルート・リクエストは、最速ルートを最短ルートと比較するなど、属性の異なる単一のルート・リクエストの複数のバリエーションを送信し、結果を比較する場合に役立ちます。

一括ルート・リクエスト内の個々のルート・リクエストでは、単純ルート・リクエストの任意の属性を使用できます。これらは、単純マルチアドレス・リクエストおよびTSPルート・リクエストの任意のサブルート固有属性も使用できます。

一括ルート・リクエスト内のすべての個々のルート・リクエストはスタンドアロンです。これらはバッチ内の他のルート・リクエストに影響しません。

親トピック: ルーティング

14.1.5 バッチ・モード・ルート・リクエスト

バッチ・モード・ルート・リクエストには、1つの<start_location>要素および1つ以上の<end_location>要素が含まれます。

バッチ・モード・ルート・リクエストの結果には、複数のルートが含まれます。各ルートは、出発地から目的地の1つまでのルートです。バッチ・モード・リクエスト内の各ルートは、共有出発地を除き、他のすべてのルートから完全に分離されます。

バッチ・モード・ルート・リクエストには、複数のバッチ・モード固有属性を含めることができます。これらの属性には、cutoff_distanceおよびsort_by_distanceが含まれます。これらの属性については、「ルート・リクエストXMLスキーマ定義」で説明しています。

親トピック: ルーティング

14.1.6 ルーティング・エンジンとジオコーダ間の関係

ルーティング・エンジンはジオコーダに依存するため、ルーティングおよびジオコーディングに使用するデータは一貫している必要があります(つまり、データ・プロバイダからの同じヴィンテージである必要があります)。

ジオコーディング・リクエストは、道路セグメントごとに(1)パーセントとEdgeIDおよび(2)経度と緯度を含むSDO_GEO_ADDRオブジェクトを返します。ルーティング・エンジンでは、パーセントとEdgeIDのみが考慮されます。

ルート・サーバーのエッジID値は、セグメントの方向を反映して正または負になります。(ジオコーディングでは方向は関係ないため、ジオコーディングのエッジIDは常に正です)。ルーティング表とジオコーディング表の同じ道路セグメント識別子は、符号のみ異なる場合があります。

住所がジオコードされ、後でルーティングに使用される次の例について考えてみます。

SELECT SDO_GCDR.GEOCODE('ODF_NA_Q312', 
  SDO_KEYWORDARRAY('5100 Geary Blvd', 'SAN FRANCISCO,CA 94118'), 
  'US', 'RELAX_POSTAL_CODE') 
  FROM dual;

ジオコーダは、edgeid = 127806839、パーセント= .86 (EDGEIDはジオコーダGC_ROAD_SEGMENT表のroad_segment_id列に対応)を返します。ただし、ルーティング・エンジンが使用するEDGE表には、edge_id -127806839と同じ(負の符号のみが異なる)セグメントが存在する可能性があります。正のroad_segment_id (GC_ROAD_SEGMENTから)が負のedge_id (EDGEから)のみと一致する場合は、対応するパーセントを取得するために、ジオコーダから返されるパーセントを1から減算して逆エッジ(edge_id)に適用する必要があります。この例では、1 - .86 = .14となります。

親トピック: ルーティング