GeoHashについての最近の話題

hfu @_hfu_

@_hfu_ GeoHash はグリッド、Spatial Index はMBR、といった方が正しい用語法かもしれない RT @_hfu_ @kokogiko GeoHash は固定グリッド、Spatial Index は可変グリッドの分、

hfu @_hfu_

端的に言って、GeoHash とは、32分木のタイルシステム。32の「苛烈さ」が GeoHash の個性。32が2であれば、TMS っぽいというか Google Maps だとか Virtual Earth とかの例のタイルシステムに近い。投影前の座標を使用しているところも個性。

hfu @_hfu_

投影座標系タイル：TMS, Bing Maps ( http://bit.ly/br2QP5 ), Google Maps、経緯度座標系タイル：GeoHash、地域メッシュコード、電子国土 Web システムタイル ( http://bit.ly/bpJ81t 6.2.1)

賀川義昭 @yoshiaki_kagawa

お～、ちょうど仕事でGeoHashによる範囲検索について考えていたのでこの話題は非常にためになります！ [Geohash で緯度経度の範囲検索のベンチマークとか] http://bit.ly/daVWZP

inuro @inuro

GeoHashはあるポリゴンをインデックス化する際に「内包する一番大きなGeoHash」「残った中でまた一番大きなGeoHash」・・・という具合に敷き詰めるGeoHashの数を最小化する方法が欲しいところだけど、もう存在してるのかな。たぶんしてるとは思うが。

inuro @inuro

でもってそれはGeoHEXにも欲しいなあと当然思うわけですね。

inuro @inuro

GeoHEXでやりたいなあと思うのは、環八とかのポリラインオブジェクトに対して一定範囲内のPOIを探索する道沿い検索を行う際の計算の最小化。なんとなく速そうな気がしている。

inuro @inuro

GeoHEXはGeoTriangleに分解しつつイテレーター的な概念（あるいは碁盤的な概念）を突っ込んだら内包系の問題を解くのに良い感じになったりしないだろうかとふと刹那的に思った。

OHTSUKA Ko-hei @kokogiko

せっかく @niyalist さんがGeoHash話題をまとめてくださったので、私ももう少しつぶやきます。

OHTSUKA Ko-hei @kokogiko

実は国盗りも、GeoHashと同じ原理でエリア検索してる。使ってる仕様はGeoHashじゃなく8次メッシュだが、Geoグリッド検索と言う点では同じ原理。

OHTSUKA Ko-hei @kokogiko

違うのは、今話題のGeoHash検索はエリアの検索条件で点（POI）を引き当てているが、国盗りは点（ユーザの国盗り地点）でエリアを引き当てていると言うところ。後、国盗りはエリアデータはRDBでなくKVS（TokyoTyrant）を使ってる。

OHTSUKA Ko-hei @kokogiko

流石に、単独点に対する複雑なポリゴンエリアの引き当て検索で、空間検索が普通のDBのインデックス検索に勝てるとは思ってなかったので、国盗りではGeoグリッド検索を取り入れた。

OHTSUKA Ko-hei @kokogiko

が、複雑なポリゴンではなくMBRを検索条件に、たかだか点を検索するようなレベルであれば、Geoグリッド検索に空間検索が負けるとは夢にも思ってなかった。なので今回の結果には若干ショックはある。

OHTSUKA Ko-hei @kokogiko

しかし、だからといって空間DBの役目は終わった、とは思わない。例えば国盗りの、エリア判定自体はGeoグリッドで高速化実現しているけれど、実際のエリア作成は、エリア定義に合わせての市町村ポリゴンマージ、分割から、Geoグリッドへの変換に至るまで、全部空間DBの力を借りてやってる。

OHTSUKA Ko-hei @kokogiko

多分、すごいレスポンスが要求されるWebアプリケーションの実装最前線では、空間DBの出番は今後もないんだろう。だが、バックエンドでのデータの準備や加工では、空間DBの力を借りないと実現できない面白い事がこれからも山ほど考えられると思う。

OHTSUKA Ko-hei @kokogiko

そうです。日本語としては私は最小外接矩形と呼んでますが。RT @niyalist MBR = minimum bounding rectangle （外接長方形），でいいですよね？

OHTSUKA Ko-hei @kokogiko

ちょっと変わってGeoグリッド系の仕様乱立の問題。GeoHex、LP-Address、GeoHash等と仕様が乱立していて、@jg2tkh さんは「GeoHexとGeoHashは戦う？」みたいな話もされていましたが、私は戦う必要はないと思う。

OHTSUKA Ko-hei @kokogiko

みんな全く違う目的意識から出てきていて、特長も異なるのだから、地図にいくつもの投影があって、用途に応じて使い分けているのと同様に、Geoグリッド系仕様も使い分ければいい。

OHTSUKA Ko-hei @kokogiko

例えばLP-Address。グリッドとしても使えるけど、元は経緯度を、システムだけでなく人間系を介しても使い易くしたい、という目的で生まれたのだから、それを追求すればよい。名刺に会社の所在地なんかを経緯度以外の方法で入れるとしたら、他の仕様と比較して一番映えるのがこれだと思う。

OHTSUKA Ko-hei @kokogiko

GeoHashは経緯度ベースの矩形グリッドだし、精度を制御する仕様もある。だから、今主流のGoogle Maps等の正角円筒図法に対して、表示範囲の検索を行う際の検索インデクス用グリッド仕様としては最適と言える。

OHTSUKA Ko-hei @kokogiko

GeoHexはやっぱり見た目勝負。矩形じゃない分インデクスグリッドとしては使いにくいし、LP-Addressのように人間系に優しくもないが、図示化した場合の見た目のインパクトは他の仕様を圧倒する。そういう特性を活かして、ゲーム等のエンタテイメント分野で使うのがいいと思う。

OHTSUKA Ko-hei @kokogiko

そしてそのようにGeoグリッド系仕様が共存してきた場合に、必要になるのが相互運用。そのような時期に、独自ジオコード間の相互運用仕様と言えるPI (Place Identifier)について、 @take14 さんが「Yahoo!はYOLPでPIに対応する」と話した意味は大きい。

開発用 @netartjp

Gep+Hexったら「リアル大戦略」しか思いつかないです。けど市街戦レベルで今の時代Hexはリアルじゃないしうーん。 RT @kokogiko: GeoHexはやっぱり見た目勝負。そういう特性を活かして、ゲーム等のエンタテイメント分野で使うのがいいと思う。

Toru Mori @jg2tkh

@kokogiko ジオ系の規格は一つに絞るのは無理があるので排他的な戦いは不要。だが「参照値」を設定して切磋琢磨するとGeoHexは広まると思う。 RT @jg2tkh さんは「GeoHexとGeoHashは戦う？」みたいな話もされていましたが、私は戦う必要はないと思う。

inuro @inuro

読み返すと「なんとなく」とか「刹那的に」とか無責任なヨタばかりなのでたまには実装して検証もしないとなと反省した。 RT @niyalist ありがとうございます！「GeoHashについての最近の話題」に @inuro さん， @kokogiko さんのTweet追加