4

約1セットの事前クラスタリングを行いたい。500,000ポイント。

私はまだ始めていませんが、これは私がやろうと思っていたことです:

  • すべてのポイントをlocalSOLRインデックスに保存します
  • いくつかの管理情報(たとえば大都市)に従って「自然なクラスターの位置」を決定します
  • 次に、各都市のクラスターを計算します。
    • 各都市について
      • ズームレベルごと
        • インデックスをクエリして、都市の周囲の半径に含まれるポイントを取得します(半径の長さはズームレベルによって異なります)

主要都市は100しかなく、SOLRクエリは非常に高速であるため、これは非常に効率的です。しかし、もう少し考えてみると、それは間違っていたことがわかりました。

  1. 都市の近くよりも互いに「近い」ポイントのクラスターが存在する可能性があります。それらは独自のクラスターを取得する必要があります
  2. 一部のズームレベルでは、一部のポイントがどの都市からも許容できる距離内にないため、カウントされません。
  3. 一部の都市は互いに近くにあるため、一部のポイントは2回カウントされます(両方のクラスターに追加されます)

他のアプローチがあります:

  • 各ポイントを調べて、それがどのクラスターに属しているかを判断します。これにより、上記の問題2と3は解消されますが、1は解消されません。また、非常に非効率的です。
  • (長方形の)グリッドを作成します(ズームレベルごとに)。これは機能しますが、何も「意味」しないクレイジー/任意のクラスターになります

汎用のジオクラスタリングアルゴリズム(またはアイデア)を探しているのですが、見つからないようです。


Geert-Janからのコメントに答えるために編集する

「自然な」クラスターを構築したいのですが、はい。任意のグリッドを使用すると、データの現実が反映されないのではないかと心配しています。たとえば、2つの長方形の交点またはその近くにあるポイントの周囲で発生するイベントが多い場合、クラスターを1つだけ取得する必要がありますが、実際には2つ(各長方形に1つ)を構築します。

もともと私はパフォーマンス上の理由からlocalSOLRを使用したかったのです(そして私はそれを知っていて、従来のデータベースにロードするよりも多くのデータをSOLRにインデックス付けする経験が豊富だからです)。ただし、事前クラスタリングについて話しているので、パフォーマンスはそれほど重要ではない可能性があります(ただし、新しいクラスタリング実験の結果を視覚化するのに数日かかることはありません)。事前定義された「大きなポイント」のセットに従って多くのポイントをクエリする私の最初のアプローチは、とにかく明らかに欠陥があります。私が言及した最初の理由は、最強であるということです。クラスターは、他の官僚的な定義ではなく、データの現実を反映する必要があります(明らかに重複していますが、データが最初に来る必要があります)。

コアのGoogleMapsAPIに追加されたライブクラスタリング用の優れたクラスタリング機能であるMarkerClustererがあります。誰かがそれを「オフライン」で実行しようとしたのではないかと思います。必要な時間実行してから、結果を保存しますか?

または、各ポイントをポイントごとに調べ、座標とポイント数を含めてクラスターを出力するクラスター化機能がありますか?これは妥当な時間内に実行されますか?

4

1 に答える 1