GeoHashを中心に，はてな技術勉強会を受けての議論
-
- いいね！0
hfu
@_hfu_
precision を上下に行き来する自在さが GeoHash の実用性の根源なのですが、基数が32なので上下の面積比が苛烈。Base4 で再設計して明示的に自由な GeoHash があれば、計算やリソース命名には便利な気がします。
2010-08-26 22:18:05
hfu
@_hfu_
逆に、基数が32であるために、データのおおよそのスケールがさだまれば、precision を選ぶのにほとんど迷いが要らないのは、GeoHash の利点かもしれない。
2010-08-26 22:19:45
hfu
@_hfu_
地域メッシュは、独自に拡張して n 分の一 メッシュコードを作りたくなるスキがある。規格の中で複数の基数を混合して使っているので、おそらく世の中にはかなりの数の独自拡張が存在している。格子点として使うことを認めていないのに実際には格子点の規格としても使われていることも。
2010-08-26 22:27:56
hfu
@_hfu_
GeoHash の場合、グリッドの面として解釈するならこのbox,格子点として解釈するならばこのpointと、意味論にかなり気を使っているふしがみられる。そのあたりがやはり現代的だと感じます。
2010-08-26 22:30:22
Yoshinori Ehara
@yehara
はてな技術勉強会から帰宅。おもしろかった。Geohash 興味深い。２次元の近傍の探索が１次元の文字列の先頭一致や Range Scan で実現できるので GAE の Datastore との相性も抜群。#hatenatech
2010-08-26 22:34:06
OHTSUKA Ko-hei
@kokogiko
DoCoMo iエリアの7/8次メッシュとかね RT @_hfu_ 地域メッシュは、独自に拡張して n 分の一 メッシュコードを作りたくなるスキがある。規格の中で複数の基数を混合して使っているので、おそらく世の中にはかなりの数の独自拡張が存在している。
2010-08-26 22:35:50
hfu
@_hfu_
京都で GeoHash が語られた #hatenatech と思えば、間髪入れずにつくばで Ruby 会議 http://rubykaigi.org/2010/ が始まる。日本は、いい国だなあ。
2010-08-26 22:40:17
OHTSUKA Ko-hei
@kokogiko
なるほど、二分木のように細かい調整が効かない分、あるスケールに適用する精度に迷いが生じないのかRT @_hfu_ 逆に、基数が32であるために、データのおおよそのスケールがさだまれば、precision を選ぶのにほとんど迷いが要らないのは、GeoHash の利点かもしれない。
2010-08-26 22:43:01
Toru KAWAMURA
@tkawa
RT @hiratara: Geohash のマス目の大きさは長さ(precision)で全然変わるので、どのprecisionで3枚のプレーンを用意するかを決めないと意味がなさそう？ http://www.ustream.tv/channel/hatenatech #hatenatech
2010-08-26 22:43:42
Kozo Kamada
@geo80k
@_hfu_ 基数が大きいことは、確かに本質的な相違ですね。それと、10進数にこだわったのがある意味敗因で、それが @_hfu_ さんの言われる「倍系のメッシュで包含関係が崩れる」を招いているんですけど、あれは当時でも評判悪かった。自分も新人の時に文句を言って上司に窘められたり。
2010-08-26 22:46:16
Kozo Kamada
@geo80k
@_hfu_ 大沢先生の定義された一連の木は、再帰的な定義が可能だっただけではなく、狭い範囲のデータしか取り扱わない場合は、表記の工夫で広い範囲の記述を大幅に省略できたりした（そうしてメモリを節約した）。でも、基本的には2分木系だった。2進数だから仕方ない、が当時の合い言葉。
2010-08-26 22:48:11
OHTSUKA Ko-hei
@kokogiko
@sa2da でも、Hexは小さい図形で大きい図形を内部充塡できないから、前方一致させる意味ないかも。やっぱり妙にいろんな用途で使えるようにと考えるより、特長を前面に推した方がいいかも。
2010-08-26 22:51:45
Toru KAWAMURA
@tkawa
あと、位置が「マス目の境界上にあるとまずい」というよりは「境界に近いと精度が落ちる」という感じなので、マス目をずらして3個持っても3つのすべてで境界に十分近い点を選んだら結局精度は落ちてしまう気がする #hatenatech (via http://bit.ly/d1Hl88)
2010-08-26 22:52:13
hfu
@_hfu_
@inuro http://watchizu.gsi.go.jp/watchizu.html?meshcode=65445555 とかでも2次メッシュに四分木を接木した独自拡張が使われていたりしますね。索引図から隣接した図を辿ってURLを比較。3次メッシュと値域重複。
2010-08-26 22:52:40
Kozo Kamada
@geo80k
@_hfu_ GeoHash が標準地域メッシュよりも概念として優れているのはほぼ自明だが、私には全く違うコンセプトには見えなかった、という話だったのでした。ああ、それと、当時は紙に印刷して（メッシュコードまで）、それを素人に見せて理解してもらえるか？というタスクもあった。
2010-08-26 22:53:08
Takashi Someda
@tksmd
Geohash が、緯度経度のビットを互い違いに配置しているのは、エンコード後の文字列の先頭からの前方一致で、近傍を探索しやすく為と、先頭からの有効文字数で精度をコントロールしやすくする為か。なるほど。面白いなー。帰宅してしばらくしてようやく。 #hatenatech
2010-08-26 22:53:49
inuro
@inuro
これに同意。と今日紙上シミュレートしてて思った。“@kokogiko: @sa2da でも、Hexは小さい図形で大きい図形を内部充塡できないから、前方一致させる意味ないかも。やっぱり妙にいろんな用途で使えるようにと考えるより、特長を前面に推した方がいいかも。”
2010-08-26 22:54:32
Kozo Kamada
@geo80k
GeoHash にしても、LocaPoint にしても、二次元（多様体）の広がりを一次元的な文字列で表現できるところが本質。（その意味では、古いメッシュコードも同じ）。実装の仕方はもちろん全く違うし、それが性能の差にも出てくるわけだが。
2010-08-26 22:58:03
hfu
@_hfu_
@kokogiko JIS 的言い回しでは 1/16, 1/32 地域メッシュみたいなやつでしょうか。QT DoCoMo iエリアの7/8次メッシュとかね
2010-08-26 22:58:11
Kozo Kamada
@geo80k
二次元空間を一次元的な文字列で表現するから、大小比較が可能になるけど、代わりに隣接の概念を表現するのが難しくなる。幾何学的には当然の話ではある。
2010-08-26 22:58:52
Yoshinori Ehara
@yehara
はてな技術勉強会から帰宅。おもしろかった。Geohash 興味深い。２次元の近傍の探索が１次元の文字列の先頭一致や Range Scan で実現できるので GAE の Datastore との相性も抜群。 #hatenatech
2010-08-26 22:59:26
hfu
@_hfu_
@kokogiko lower corner だったと記憶してます。文字列から素直に?算出したそのままの値。いわゆる左下。 QT GeoHashは、点として捉えるとBoxの中央点になるの?
2010-08-26 23:01:23