空間集計のサポート

SQL Server ポイントテーブルで大規模なデータを視覚化して分析する機能がサポートされるようになりました。この分析は、XY 列 (緯度と経度および/または XY 座標値が個別のスカラー値として格納されている) とジオメトリ列 (ポイントジオメトリが SQL Server の Geometry または Geography タイプで格納されている) のどちらでも実行できます。Spectrum Spatial は、ジオハッシュ ID を用いてテーブルを縮尺可変にする空間アグリゲーション (空間クラスタリングとも呼ばれる) をサポートしているため、大量のデータを適切に視覚化できます。例えば、マップで表現したい縮尺の異なる複数のジオメトリや複数のポイントを統合的に集約できます。クラスタ化されたポイントデータをクライアントからベクトルデータ (GeoJSON 形式) として利用できるので、クライアントアプリケーションはデータにさまざまなスタイル (サイズ可変シンボルや異なる色の範囲など) を適用し、データをクライアント側でヒートマップとして表現することもできます。

geohash について

geohash は、世界を再帰的にグリッドセルに分割して、各グリッドに一意の ID 値を割り当てるグリッド分割手法です。geohash には 12 の長さがあります。最初のジオハッシュ距離では、世界を 32 個のグリッドセル (8x4 セル) に分割します。次のジオハッシュ距離では、各グリッドセルをさらに 32 個のセル (4x8 セル) に分割して世界全体を 1024 個のセルで覆います (以下同様)。

縮尺について

テーブルを縮尺可変にするというのは、テーブル内の各ポイントにジオハッシュ ID を割り当てて、ポイントをジオハッシュ距離のより大きなセルに集約できるようにすることです。クライアントアプリケーションが、縮尺を認識するテーブルに対してフィーチャーを要求する場合は、送信した MI SQL 式の一部として使用する縮尺が引き渡されることが想定されます。縮尺の値は m/pixel 単位 (ピクセルあたりのメートル数) で送信されます。Openlayers などのマッピングライブラリではこれを解像度とも呼びます。クライアント側のマッピングライブラリでは、通常、解像度として渡された値をそのまま使用します。

サーバー側では、Spectrum Spatial によって、データの集計に適切な geohash の長さが選択されます。以下の表は、入力されたピクセルあたりのメートル数の値に基づいて geohash の長さを選択する方法を示しています。


選択するジオハッシュ距離	ピクセルあたりのメートル数
2	>= 19000
3	>= 2400 かつ < 19000
4	>= 600 かつ < 2400
5	>= 80 かつ < 600
6	>= 10 かつ < 80
7	>= 2 かつ < 10
8	>= 0.3 かつ < 2
9	>= 0.06 かつ < 0.3
10	< 0.06

例えば、クライアント側のマップの解像度がピクセルあたり 600 メートル以上 (かつ 2400 未満) の場合は、データを集約する長さの単位としてジオハッシュ距離 4 を選択します。この関係により、集約されたフィーチャーが適切な数だけ返され、クライアント側で十分に詳細なマップがベクトルレイヤとしてレンダリングできるようになります。集約されたフィーチャーがいくつ返されるかは、クライアントデバイス上のマップのサイズと集約すべきフィーチャーの密集・分布状況によって変化します。

フィーチャー数の上限

1024 x 780 ピクセルの典型的なクライアントマップで実行されるほとんどのクエリでは応答のフィーチャー数が 1000 を下回ります。しかし、解像度によってはクエリの返すフィーチャー数が 1000 を超えることもあります。1024 ピクセルよりも大きなクライアントマップではフィーチャー数が 1000 を超える公算が大きいでしょう。[サービス > フィーチャー] にある Spectrum Spatial™ Manager でフィーチャー数の上限を 5,000 ～ 10,000 あたりまで増やして、応答のフィーチャー数が1000 を超えてもエラーが発生しないようにすることをお勧めします。

ジオハッシュ ID をテーブルに追加する

既存のテーブルを縮尺可変にして空間アグリゲーションで使えるようにするには、ジオハッシュ ID をテーブルに手動で追加する必要があります。詳細な手順については、ジオハッシュインデックスをテーブルに追加するを参照してください。

テーブルの空間アグリゲーションを有効化する

名前付きテーブルを作成または変更するとき Spectrum Spatial™ Manager で空間アグリゲーションを有効化できます (詳細は、テーブルの作成およびXY テーブルの作成を参照)。テーブルの空間アグリゲーションが有効化されているかどうかは、 Spectrum Spatial™ Managerでテーブルの詳細ページを表示すれば確認できます。[リソース情報] タブにジオハッシュ列と精度が表示され、[列] タブにはジオハッシュ列とその属性 (タイプのほか、インデックス作成済みか、読み取り専用か、Null が設定可能かなど) が表示されます。

重要: テーブルの空間アグリゲーションを有効化する場合は、フィーチャー数の上限を 1000 (デフォルト) ～ 10,000 レコードの範囲で大きくすべきです。クライアント側のマップのズームレベル、空間的広がり、集約すべきフィーチャーの密集・分布状況によっては、集約されたフィーチャーが 1,000 個以上返されることがあるからです (ただし、1024 x 780 ピクセルのクライアントマップでは、通常、2500 個以上のレコードが返されることはありません)。Spectrum Spatial™ Manager で Feature サービスの MaximumFeatures 値を調整してください (../../repoman/featureservice_config_intro.html#featureservice_smを参照)。

縮尺可変テーブルに対するフィーチャーの要求

縮尺可変テーブルに対してフィーチャーを要求するにはクライアントアプリケーションで MI SQL を使います。サーバー側のクラスタリングは Feature サービスで REST 版の Search By SQL リクエストを使うことで有効になります。クライアントは MI SQL の集約メソッドと SCALE 句を用いてクエリを発行できます。

注: ジオメトリ列に対する集約クエリで MI_Transform 関数はサポートされていません。マップ上の大規模なデータを集約する場合は、Spectrum Spatial におけるデータテーブルの投影法とクライアントマップの投影法を一致させてください。あるいは、クライアント側で GeoJSON 応答を投影してからベクトルレイヤに追加してください。

SCALE 句の詳細 (およびサンプルクエリ) と集約メソッド (MI_AggregateCentroid など) については、『Spectrum Spatial ガイド』の「MapInfo SQL 言語リファレンス」セクションを参照してください。

縮尺可変クエリの例

http://152.144.226.251:8080/rest/Spatial/FeatureService/tables/features.json?
q=SELECT MI_AggregateCentroid(SP_GEOMETRY), Count(*) as feature_count FROM "/LargePoints" 
WHERE MI_EnvelopesIntersect(FromWKT('POLYGON((-8627389.58 4756566.36,-8627389.58 5196843.64,-7844674.42 5196843.64,
-7844674.42 4756566.36,-8627389.58 4756566.36 ))','EPSG:3857'), SP_GEOMETRY) SCALE 611.49622628141

パフォーマンスに関する検討事項

最適なパフォーマンスを得るには以下の点を考慮する必要があります。

Spectrum Spatial は実行時にそのほとんどの処理を DBMS に任せるように設計されています。システムを設計する際、パフォーマンスとスケーラビリティはデータベースサーバーが利用できるメモリと処理能力に強く依存することを覚えておいてください。
データベースクエリ最適化チール (SQL Server Tuning Advisor など) でパフォーマンスチューニングを行うことをお勧めします。小規模テストやデータベースインデックスの調整をどう行えばよいかはデータベース管理者と相談して決めてください。
ジオメトリ列 (ポイントジオメトリが SQL Server の Geometry または Geography タイプで格納されている) よりも XY 列を使用した方が高いパフォーマンスを得ることができます。可能であれば、大規模なデータテーブルを扱う場合は XY テーブルを使用し、経度と緯度 (X と Y)、プライマリキー列 (クラスタ化インデックス)、ジオハッシュ列、その他、クエリで使われている集約列をインデックスとして設定してください。データベース管理者またはチューニング担当者から、上記の列を組み合わせたものに追加的なインデックスを設定するよう勧められることもあります。