特定のポイントが、MySQL Spatial を使用して記録されたデータベースに存在するルート ラインから少なくとも 500 メートル (他の距離) 離れているかどうかを確認する必要があります。
MySQL Spatial には同様の機能がないことがわかり、このソリューションをポイントごとに確認するには線が大きすぎる (300km 以上) ため、うまくいかない以前の回答を見つけました: Find N Nearest LineString From A Point MySQL 空間拡張機能の使用
ポイントにバッファ（指定された半径の円/ポリゴン）を作成して、接触しているかどうかを確認することさえできません。
更新 - 12/7 私はそれをやったが、MySQL Spatial は縫い目が信頼できない。私はcreateBuffer関数を作成し、指定されたポイントの周りに20ポイントのPolygonを作成し、半径にメートルの距離を指定しました: http://pastebin.com/xEFb8ZXi
私はこのバッファから与えられた結果を QGis でテストしていますが、関数ですべて問題ありません (期待よりも小さい値を生成するメートルから 10 進数の低下値を除いて、それは今のところ問題ではありません)。
そして、いくつかの交差チェックを行いました。結果のポリゴンがラインと交差していなくても、これは true を返します。中心点のみを使用して同じテストを再作成しましたが、結果は同じです。INTERSECT が LineString を Point または Polygon でチェックするのではなく、LineString BBox の外側のポイントを示す場合、LineString の境界ボックスをチェックすることを発見しました。
Intersects QUERY ここで、「rota」は Linestring データです。
SELECT Intersects(rota, createBuffer(GeomFromText('POINT(-19.7736 -43.7255)'),500))
FROM log_viagem WHERE rota IS NOT NULL;
MySQL Spatial を信頼するにはどうすればよいですか? または、INTERSECTS に関する私の概念が間違っていますか?
解決済み: MySQL のバージョン 5.5 で重要な注意事項を読んでいませんでした:
注 現在、MySQL は仕様に従ってこれらの関数を実装していません。実装されているものは、対応する MBR ベースの関数と同じ結果を返します。
解決策は、サーバー管理者と一緒に 5.6.1 に更新することです。メモにアップグレードがあります。
注意 MySQL は当初、これらの関数を、オブジェクト境界矩形を使用して、対応する MBR ベースの関数と同じ結果を返すように実装していました。MySQL 5.6.1 の時点で、正確なオブジェクト形状を使用する対応するバージョンが利用可能です。これらのバージョンには、ST_ プレフィックスが付いた名前が付けられています。たとえば、Contains() はオブジェクト境界長方形を使用しますが、ST_Contains() はオブジェクト形状を使用します。
MySQL 5.6.1 の時点では、すでに正確であった既存の空間関数の ST_ エイリアスもあります。たとえば、ST_IsEmpty() は IsEmpty() のエイリアスです。