どこかからpostgisデータベースのラインストリングフィールドに〜1000個のパスをインポートしました。
(編集)私のテーブルはこのようなものです
+---------+---------------+------------------+
| id(int) | name(varchar) | path(LINESTRING) |
+---------+---------------+------------------+
| 123 | foo | 000002... |
| 124 | bar | 000002... |
各パスがチャンクに分割され、場合によってはそれらのチャンクが混在するという問題がありました。
ポイント番号 50 と 70 で分割された線ストリングを想定します。
- チャンク A: ポイント 1 ~ 50
- チャンク B: ポイント 51 ~ 70
- チャンク C: ポイント 71-100
それをデータベースに移行したところ、それらが混在したため、結果の折れ線は次のようになります。
- チャンク A: ポイント 1 ~ 50
- チャンク C: ポイント 71-100
- チャンク B: ポイント 51 ~ 70
これにより、50 から 71 へのジャンプと、100 から 51 へのジャンプが生成されます。
(編集) これらのパスをチャンクに分割してインポートしたとき、それらは順序付けられていると思いましたが、実際にはいくつかが混在していたため、2 番目の例のようにポイントが順序付けられた線ストリングがいくつか作成されました。
これらのチャンク (ポイントの) を並べ替えられるようにしたいので、ポイントが混在しているパスを検出する SQL クエリを作成し、手動で (openlayers を使用して作成されたツールを使用して) それらを並べ替えることができます。
この問題を解決するには、SQL 更新クエリを使用することが望ましいですが、検出はより簡単だと思います (エラーのあるパスは ~5% 以下であると推測されます)。
EDIT3:パスにあまりにも離れた連続したポイントのペアが含まれているかどうかを検出用のスクリプトで確認できると思います。おそらく、最長のセグメントを含むパスからパスを並べ替える SQL が良いでしょう。
ラインストリングの最大セグメントの長さを取得する関数を作成するにはどうすればよいですか?
ここに例を示します。これはデータベース内の様子です
こうやって直してほしい
EDIT4 : EDIT3 で計画したように、 ST_NPoints()とST_PointN( )を使用して線ストリングのポイントを反復処理する線ストリング内の 2 つの連続するポイント間の最長距離を見つける関数を作成し、パスを並べ替えるクエリを作成できます。その最長距離で。この距離が長すぎる線ストリングが、説明されている問題を引き起こす可能性が非常に高くなります。そうすれば、それらを検出して手動で修正できます。
検出 SQL の結果は次のようになります。
|ordered by this|
+---------+---------------+------------------+---------------+
| id(int) | name(varchar) | path(LINESTRING) | msbtcp(int) |
+---------+---------------+------------------+---------------+
| 123 | foo | 000002... | 1000 |
| 124 | bar | 000002... | 800 |
*msbtcp は次の関数の結果です。max_separation_between_two_consecutive_points(path)