Open3
postgisやgeohashについて

postgis(postgresql)
- GeohashやQuadkeyといったアルゴリズムを使用すると、位置情報をハッシュ化することが可能
- 緯度・経度から1件ずつ距離を計算していては計算コストが非常に高い
- ハッシュ化により文字列の前方一致検索で可能になる
- ST_Distance(point, ST_GeomFromText('POINT(139.701636 35.65803)', 4326 , false) <= 100;
- 基準となる位置から100m内に存在するデータを抽出する条件
- https://qiita.com/yabooun/items/da59e47d61ddff141f0c
- データ型
- Geometry:平面座標(基礎が平面)
- Geography:地理座標(基礎が球面)。ジオグラフィ上の計算 (面積、距離、長さ、インタセクション等)は、球面上で計算しなければならず、複雑な計算が必要となる
- 違い:座標をデカルト座標として扱うか否か
- 緯度と経度は角度なので、Geographyとして扱うのが適切だが用途次第ではGeometryでも特に問題は生じず計算コストが低いというメリットがある
- データが小さいエリア内におさまるなら、適切な投影を選択してジオメトリを使うのが、効率面でも機能面でも最も良い方法
- 投影法を理解していなくて、学習したくもなくて、かつ、ジオグラフィで使える関数が限られていることを受け入れるのなら、ジオグラフィを使った方が簡単
- 比較演算子
- ~=:幾何オブジェクト同士が厳密に等しいかどうかを比較
- =:幾何オブジェクト同士の境界(boundary box)が等しいかどうかを比較
- http://mikanbako.blog.shinobi.jp/データベース/-postgis- 幾何オブジェクト同士の等しさを比較する方法に注意

- http://blog.masuidrive.jp/2010/01/13/geohash/
- 緯度経度は測地系によって値が違う
- GeoHash
- GeoHashは、緯度経度の二つの座標を、一つの文字列にまとめたもの
- GeoHashはグリッドになるので、緯度経度のようにポイントではない
- ハッシュが8文字あると、19m*31mのグリッドになる
- GeoHashの最大の特徴は、その長さによって精度が変わること
- ハッシュの前方一致の文字列検索で周辺にある場所の取得が可能になる
- 例)東京タワーを中心とした 19m*31mのエリアは「xn76ggrw」ですが、これを頭5文字「xn76gg」だけ取り出す
- はてぶでmattnさんが「同じ四角形でも場所によって同じ面積にならない」が気になった
- Geohashのミソは、座標を2進数にして、それを交互に並べる所にあります。そしてそれをBASE32でエンコードすることで、座標を文字列にして表現
- BASE32は、5ビットで1文字なので、Geohashの長さが奇数の場合は、経度の方がビットが短くなる(例: 5文字の場合 全25ビット 緯度が13ビット、経度が12ビット)
- そのため、グリッドの大きさが、Geohashが奇数の場合は縦長、偶数の場合は横長になる
-
https://yuroyoro.hatenablog.com/entry/20100115/1263526125
- "xpssc0"というGeoHash表現は、「北緯43.0224609375から43.0279541015625の間で、東経141.3720703125から141.383056640625の矩形範囲」であり、座標はこの矩形範囲の中心点になる
- デメリット
- bit数が5となっており、精度によって縦長、横長となる
- そもそも長方形なので特定の点からの一定距離でデータが欲しい場合に外れるデータが出てくる
- 精度による範囲の細かいコントロールが難しく、サービスによっては細かな検索には不向き
- quadkey
- 同じ一次元ハッシュコード検索をするならば、GeoHashより検索効率のよいquadkeyを使うべき
-
https://qiita.com/kochizufan/items/2fe5f4c9f74636d22ddb
-
- デメリット:eoHashに比べてコードサイズが長くなってしまいデータ量が増大する(単純計算で同じ精度なら2.5倍)
-

- MySQL:0000-00-00 00:00:00がおk、PostgreSQLはNG
- http://riisaconsulting.co.jp/勉強会/post_2578