3

私はとても混乱していて、上記のトリックを見つけるためにゴーグルするのにとても疲れています。実際、私は6つのフィールドid、Sratlatitude、Startlongitude、EndLatitude、EndLongitude、およびusernameを持つデータベーステーブルを持っています。今、私は次のようなデータベースでクエリを実行したい 

SELECT * FROM LOCATIONS（テーブル名）開始点（InputedStartlatitudeとInputedStartlongitude）と終了点（InputedEndlatitudeとInputedEndlongitude）の間のユーザー。
例：USERXXX入力開始点（InputedStartlatitude=18.9647およびInputedStartlongitude=72.8258）=ムンバイおよび終了点（InputedEndlatitude=18.9647およびInputedEndlongitude=72.8258）=デリー。ここで、彼はInutedlatitudesとInputedlongitudesを使用して、この入力ルート（運転方向）間のユーザー数を検索したいと考えています。検索クエリはmysqlデータベースに対して起動し、ムンバイからデリーまでの間に保存されている開始および終了の緯度と経度から比較します。

私はこれに対する1つの解決策を見つけました：データベースにクエリを作成するようなもの：

SELECT * FROM lOCATIONS(tablename) WHERE (InputStartLatitude >= StartLatitude and IntartLongitude >= StartLong) and (InputEndLatitude <= EndLatitude and InuteEndLongitude <= EndLongitude);

しかし、私は上記のクエリでいくつかの問題に直面しました。以下はいくつかの場所の座標です。ご覧ください：

ここに画像の説明を入力してください

開始座標と終了座標は赤色で表示されます。開始位置は：ポルバンダル、終了位置は：ムンバイです。問題は、ポルバンダルからムンバイまでの都市を検索しようとすると、すべての都市が実際に運転方向にあるわけではないということです。私はクエリでこれらの都市のみを呼び出しましたが、Lat and Longを開始するよりも大きく、LatandLongを終了するよりも小さいです。しかし、ここではムンバイの緯度と経度はすべての都市よりもほとんどありません。では、どうすれば適切な検索クエリを作成できますか？
私が上記の状況を十分に説明したことを願っています。

どんな返答も私にとって非常に役に立ちます。
私はバックエンドとしてphp-mysqlを使用し、クライアント側でandroidを使用しています。

4

1 に答える 1

4

問題は、開始値が終了値よりも高い場合、検索式が正しく機能しないことです。境界値をテーブル フィールドと比較する前に、境界値を並べ替える必要があります。

開始場所が終了場所の東または西 (および北または南) に関係なく、常に機能するクエリを次に示します。便宜上、 andのBETWEEN代わりに MySQL の演算子を使用していますが、このクエリの主な詳細は、境界値がand演算子を使用してソートされることです。>=<=LEASTGREATEST

SELECT * 
  FROM `locationtable` 
  WHERE  ( `lat` BETWEEN LEAST(InputStartLatitude, InputEndLatitude) AND GREATEST(InputStartLatitude, InputEndLatitude) )  
  AND    ( `long` BETWEEN LEAST(InputStartLongitude, InputEndLongitude) AND GREATEST(InputStartLongitude, InputEndLongitude) )
;

それがあなたが探しているものであることを願っています。

編集：

「間」が何を意味するのかを特定した後、タスクを解決するためのアルゴリズムについて最初に考える必要があることが明らかになります。そのアルゴリズムの実装 (MySQL または他の場所) について考えるよりずっと前です。

これは、あなたのパズルの解決策にどのようにアプローチするかの簡単なスケッチです。

  1. リクエストされた乗車と提供されたすべての乗車について、Google の運転ルートを取得します。
  2. これらのルート案内には「ステップ」 ( Maps APIを参照) が含まれています。これは基本的に、計算されたルートがすべて交差する緯度/経度のポイントのリストです。提供されたすべての乗り物の運転ルートをデータベースに保存する必要があります。これは、新しくリクエストされた乗り物を確認するために何度も必要になるためです。

  3. 基本的な魔法は、要求された乗り物の歩数がデータベースで提供された乗り物の歩数のサブセットであるかどうかを調べることです。残念ながら、要求された配車の最初と最後の 1 マイルは常に要求者の場所 (たとえば、自宅から次の高速道路までの道路) に非常に固有であるため、このようなケースはほとんどありません。したがって、ここである程度の許容範囲を実装する必要があります。複数のアプローチでそれを行うことができます。2 つの例を挙げましょう。

    a) リクエストされた乗り物が提供された乗り物に完全に含まれているかどうかを確認する代わりに (上記のように決して起こりません)、リクエストされた乗り物が提供された乗り物と共通しているステップを見つけようとすることができます。結果から、最も長いもの (ステップ数が最大のもの) を取得します。この最長のものは、「そのまま」依頼者に提供できます。これが、依頼者の依頼に利用できる最善の解決策です。共通のサブパーツを見つけるには、1.) 要求されたライドと提供されたライドの運転方向で最初の共通の緯度/経度ステップ座標を探し、2.) そこから、両方のライドで同一である以降のすべてのステップをカウントします。 . リクエストされた乗り物を提供されているすべての乗り物と照合する必要があるため、最初の共通の緯度/経度座標を見つけるプロセスは非常にコストがかかる可能性があります。

    b) もう 1 つの寛容なアルゴリズム (より単純で安価) は、短距離のみをカバーするすべての運転方向 (配車リクエストと配車オファー) の最初と最後からのすべてのステップを最初に破棄することです。これらの手順は、次の高速道路との間のローカル ドライブである可能性が最も高いでしょう。その後、それ以上の許容範囲なしで、短縮されたリストを直接照合できます。(短縮された) 要求が (短縮された) オファーに完全に含まれている場合、そのオファーはヒットです。これは非常に安価です。巧妙なデータ表現を作成すれば、MySQL でそれを行うことさえできるかもしれません。たとえば、短縮リスト内のすべての緯度/経度ペアの文字列表現を作成し、要求された乗り物を完全な部分文字列として含む提供された乗り物をデータベースでチェックできます (MySQL のLIKE '%string%'パターン マッチングを使用)。

これがあなたの問題に光を当て、正しい軌道に乗せることを願っています.

于 2012-11-02T10:51:53.707 に答える