Traffic TPEG API 開発者ガイド（交通情報）

Delta の更新

デルタ更新 getmessages では、最初の要求の後に変更されたイベントと新しいトラフィックイベントのみを送信することで、応答サイズを削減します。

デルタ更新の計算ルール

デルタ更新の計算には、次のルールが使用されます。

連続的に交差する近接のみまたは経路のみの検索が要求された場合、最後の結果には、以前のすべてのリクエストのアイテムがフィルタリングされます。

図 1. 同じタイプの検索のデルタ更新を計算しています

シナリオ : ユーザーが最初の近接エリア（ Prox#1 ）のトラフィックを要求し、すべてのイベントを取得します（この時点ではデルタはありません）。次に、ユーザーが、最初の領域と交差する 2 番目の近接領域（ Prox#2 ）のトラフィックを要求します。交差する領域からのイベントがフィルタリングされると、デルタ更新のみが取得されます。次に、ユーザーが、以前に使用した両方の領域と交差している 3 番目の近接領域（ Prox#3 ）のトラフィックを要求します。両方の交差する領域からのイベントがフィルタリングされた場合、デルタ更新のみが取得されます。同じロジックが、連続するコリドー検索にも適用されます。
検索の種類を変更するときに、連続する交差する検索が要求された場合 ( 近接型からコリドー、近接型から近接型、またはコリドー型から近接型へ ) 、最後の結果には、同じ種類の以前の検索の項目もフィルタリングされます。

図 2. 変更されたタイプの検索のデルタ更新を計算しています

シナリオ: ユーザーが最初のエリア（ Prox#1 ）のトラフィックを要求し、すべてのイベントを取得します（この時点では Delta はありません）。次に、ユーザーが最初のエリアと交差する廊下エリアのトラフィックを要求し（ Corr#2 ）、交差エリアからのイベントがフィルタリングされたときにデルタ更新のみを取得します。次に、ユーザーが、以前に使用した両方の領域（ Prox#3 ）と交差する近接領域のトラフィックを再度要求します。交差する両方の領域からのイベントがフィルタリングされたため、デルタ更新のみが取得されます。

Delta アップデートの応答サイズのサンプル

次の例は、ドイツで約 300km 走行し、まず近接検索を実行してから、ドライブ中にインシデントおよび交通量をルート経路で検索するときのサイズの違いを示しています。

最初 getmessages のリクエストは 10 km の近接検索です。その後 getmessages のリクエストは、ルート全体のウェイポイントを使用したルートコリドー検索です。 getmessages 残りのルートの車両位置から、 2 分ごとに新しいリクエストが送信されます。

合計で 152 getmessages 件のリクエストが送信され、 TPEG サービスから返された応答がいくつもあります。青の線 getmessages は、デルタ更新が使用された場合の応答サイズを示します。グラフには、 Compressed TrafficML (TML) およびバイナリ TPEG 形式を使用した非デルタ応答のサイズも表示されます。

デルタ更新のしきい値

交通イベントコンパクト（ TEC ）：インシデントのパラメータが変更 getmessages された場合、インシデントがまだ検索範囲内にある場合、次の応答でインシデントが更新されます。

フローのデルタ（ TFP ）：しきい値の計算では、次のパラメータの値が考慮されます。デフォルトでは、Traffic TPEG API はフィードで定義されている単位を使用します。

完全な更新

表 1. トラフィックフローおよびデルタ検出による予測で使用される属性
パラメーター	しきい値 [ リアルタイムフィードで定義された単位 ]
平均速度 [SP]	`5`
フリーフロー [FF]	`5`
紙詰まり係数 [JF]	`1`
信頼度 [CN]	`0.1`
TMC （サブセグメント）の長さ [LE]	`0.001`

デルタ更新ではなく常にフルトラフィック更新を受信するには、initsession 要求で TimeOut=0 を設定します。 TimeOut が 0 より大きい場合、その期間よりも前に完全なトラフィック更新を取得する唯一の方法は、新しいセッションを開始することです。