ジオハッシュ エンコーダー/デコーダー
プライバシー優先設計 — すべてブラウザ内で処理します
エンコードモードでは緯度と経度を入力(精度スライダー付き)してジオハッシュ文字列を取得します。デコードモードではハッシュを貼り付けて中心の座標と南西/北東のバウンディングボックスを確認します。空間インデックス、近接検索、位置データの仮名化保管などに役立ちます。
ジオハッシュが実際に符号化しているもの
ジオハッシュは経度と緯度のビットを交互に並べ、その結果を独自のアルファベット(0〜9 と a/i/l/o を除く b〜z)で base32 にエンコードします。各文字は 5 ビットの精度を持ち、経度と緯度を交互に細かく刻みます。出力は短く URL セーフな文字列で、接頭辞の関係がそのまま空間の包含関係に対応します。"dr5ru" で始まるジオハッシュは必ず dr5ru セル内にあります。
精度とセルのサイズ
精度 1 では世界は 32 個の幅約 5,000 km のセルに分かれます。精度 5(赤道付近で約 4.9 km)は地区単位のグルーピングに向きます。精度 9(約 5 m)は建物単位に最適です。精度 12 は約 4 cm まで詰まり、測量級の作業以外ではほとんど不要です。極に近づくほどセルは縮みます。
ジオハッシュを使う理由
文字列の接頭辞は PostgreSQL、Redis、DynamoDB、SQLite で効率よくインデックス化できます。半径 5 km 以内の点を探すなら、ターゲットの精度 5 ハッシュを計算して接頭辞一致で検索するだけでよく、大円距離クエリよりはるかに安価です。セル境界のエッジケースは現実に発生するため、本番パイプラインは目的ハッシュと隣接 8 セルの計 9 セルを同時に検索します。S2 や H3 より単純で古いものの、ホットパスの近接ワークロードでは現役です。
よくある質問
- なぜ精度 5 で都市全体を覆えるのですか?
- 各文字が 5 ビットなので、精度 5 は 25 ビットで赤道付近で約 4.9 km × 4.9 km のセルに相当します。数キロ規模の都市は 1 つのセル内に収まり、多くの配車・配達アプリが運転手や注文を精度 5 のジオハッシュでまとめて高速マッチングするのはそのためです。
- 近い 2 点で異なるジオハッシュになりました。バグですか?
- バグではなく、グリッドの仕様です。セル境界の両側にある 2 点は、たった 1 m 離れていても接頭辞を共有しません。本番では目的ハッシュ + 8 個の隣接セル(3×3 リング)を一緒に問い合わせます。
- ジオハッシュのアルファベットは?
- 0〜9 と a/i/l/o を除く b〜z の合計 32 文字です。a/i/l/o を除外することで、低コントラストのフォントでも 0/1 と混同しません。これは RFC 4648 の base32 ではなく、独自アルファベットの base32 です。
- S2 や H3 との比較は?
- ジオハッシュは三者の中で最もシンプルで歴史が古いものです。S2(球面に投影した立方体)と H3(六角形グリッド)は極の歪みをより上手く扱えますが、コード量も増えます。アプリでの近接処理にはジオハッシュで十分、地球規模のナビゲーション/ルーティングなら S2/H3 が有利です。
- PostgreSQL でジオハッシュを安全にインデックス化できますか?
- できます。ハッシュを text 列にして btree インデックスを張れば、接頭辞検索(LIKE 'dr5ru%')は非常に高速です。空間クエリが必要なら PostGIS を併用しますが、ほとんどのケースは接頭辞一致で足ります。
- Toova はエンコードした座標を記録しますか?
- 記録しません。エンコード/デコードはこのページ内の JavaScript で完結し、座標も結果ハッシュも Toova のサーバへ到達することはありません。