2

ユーザーが通勤ルートをデータベースに保存するアプリケーションがあります。

ルートはポリライン (折れ線) として保存されます。データベースにはインシデント、交通事故なども保存されています。定期的にルートを照会して、ルートの半径 1k 以内にインシデントがあるかどうかを確認する必要があります。

クエリの結合は次のように構成されています。

    Route r left outer join Incident i on
    r.PolyLine.STDistance(i.Location) < 1000

今、私も次のようなことを試しました：

Route r left outer join Incident i on   
r.PolyLine.STBuffer(1000).STIntersects(i.Location) = 1

速度を改善するためにこれまでに試みたことは次のとおりです。

  1. ラインストリングに沿ってポイントの数を減らします
  2. 空間インデックスを追加します (ただし、微調整する方法はわかりません)

1) 上記はうまくいきましたが、十分ではなく、インシデントがルートに沿ったすべてのポイントと比較されていて、本当に効率が悪いと思われます。

バウンディング ボックスにアクセスし、STContains を取得するために、長い緯度を幾何学と地理学として強く検討しています。

インシデントをチェックする前に、PolyLine で reduce を呼び出すことも検討してください。

4

1 に答える 1

2

ジオメトリの保存をお勧めします。このシナリオで地理学に行くことの利点は、コストを上回るようには見えません。

空間インデックスは非常に重要です。空間クエリを使用した 1 つのプロセスは、適切に調整された空間インデックスを使用することで、約 15 分から約 1 分になりました。ただし、最適な設定を自動的に取得するための適切な方法に関するドキュメントは見つかりませんでした。空間インデックスの調整に関する同様の質問に回答しました。ここで提供したストアド プロシージャは、データ セットごとに時間がかかりますが、他の作業をしながらバックグラウンドで実行できます。

クエリに関する限り、別のクエリを設定し、そのパフォーマンスを上記の 2 つと比較しました。ルートのバッファーをジオメトリ変数に入れ、その変数を空間比較に使用すると、パフォーマンスが向上するようです。この理由は、比較する行ごとに 1 回ではなく、1 回だけバッファーを作成 (または距離を評価) する必要があるためです。これを試して、どのような結果が得られるかを確認できます。

DECLARE @routeBuff geometry
SET @routeBuff = (SELECT r.PolyLine.STBuffer(1000) FROM route r WHERE recordID = 2778) --how ever you select the particular route

SELECT
    *
FROM
    incident i
WHERE
    i.location.STIntersects(@routeBuff) = 1
于 2013-04-08T15:41:39.173 に答える