はじめに
GeoPo v2って何？
GeoPo v2（ジオポ バージョン2）は、地球上のどんな場所でも短い文字列で表現できるシステムです。例えば：
- 富士山 →
AZtdRhttps://geopo.creco.net/AZtdR - 東京駅 →
AZtRmuhttps://geopo.creco.net/AZtRmu - 大阪城 →
AZMHKGuhttps://geopo.creco.net/AZMHKGu
住所を覚えなくても、全世界を数文字のコードで正確な位置を共有できます。URLに直接入れれば、すぐにその場所の地図が開きます。
なぜ作ったの？
2025年8月にリリースしたGeoPo v2は、従来のGeoPo（v1）が抱えていた課題を根本から解決し、より実用的で精密な地理位置符号化（DGGS: 離散グローバルグリッドシステム）を実現するシステムです。
今回は、GeoPo v1から v2への進化の軌跡と、その技術的な背景について詳しくお話しします。
GeoPo v1の成果と課題
成果：革新的な符号化アプローチ
2009年にリリースしたジオポ（GeoPo v1）は、地理位置を短い文字列で表現する画期的なシステムでした：
- 階層構造による効率的な符号化：上位レベルから下位レベルへの段階的な位置特定
- 可読性の高いコード：人間が覚えやすく、URLで伝えやすい短い文字列
- 階層的URL構造：1文字削るだけで上位レベルに移動可能
- 符号化アルゴリズム・サンプルコード：開発者が簡単に組み込める開発者向け情報の提供
根本的な課題：メルカトル図法の限界
しかし、GeoPo v1は地球を平面的な格子で分割していたため、深刻な問題を抱えていました：
1. 緯度による面積の不均一性
- 赤道付近と極地では同じレベルのセル面積が大きく異なる
- 北極・南極に近づくほど、セルが極端に小さくなる
2. アスペクト比の歪み
- 高緯度地域では縦横比が崩れ、極端に縦長のセルになる
- 実用的な位置精度が地域によって大きく変動
3. 極地での実用性の欠如
- 北極・南極周辺では事実上使用不可能
- 全球対応を謳いながら、実際は中低緯度限定のシステム
これらの問題により、GeoPo v1は学術的には興味深いものの、実用システムとしては限界がありました。
解決策の模索：様々なアプローチの検討
球面座標系への直接的な挑戦
まず、地球の丸みを考慮した球面座標系を直接利用するアプローチを試みました。具体的には、球面調和関数や測地座標系での等面積分割、独自の球面格子システムの開発などを模索しましたが、どれも共通の課題に直面しました。
それは、計算の複雑さ、既存の地理情報システム（GIS）ツールとの互換性の低さ、そして高い開発・保守コストです。これらの問題から、独自のアプローチは現実的ではないと判断しました。
既存の技術標準の調査
次に、すでに存在する離散グローバルグリッドシステム（DGGS）の技術標準を詳しく調査しました。
- HEALPix（NASA開発）：球面を細分化する優れたアルゴリズムでしたが、柔軟な階層構造に限界がありました。
- S2 Geometry（Google開発）：高性能である一方で、その複雑さから導入のハードルが高いという問題がありました。
この段階では、どの技術もGeoPoが求める要件を完全に満たすものではありませんでした。
最適解「H3」との出会い
そんな中、以前から存在は知っていたUberのH3（Hierarchical Hexagonal Geospatial Indexing System）を改めて詳細に調査しました。H3は、私たちの求めていたすべての特性を驚くほど高いレベルで満たしていました。
- 真の等面積分割: 地球上のどこでも均一な六角形のセルで分割でき、正確なデータ解析が可能です。
- 六角形グリッド: 隣接するセルとの関係が明確で、位置検索やデータ集計の計算効率が非常に高いです。
- 階層構造: 15段階の解像度で、広域からピンポイントまで柔軟に対応できます。
- 成熟したエコシステム: 多言語に対応したライブラリが豊富に揃っており、開発コストを大幅に抑えられます。
この「H3」が、GeoPoの次世代システムを構築するための最適な基盤であると確信し、開発を進めることになりました。
H3に最適化された49文字セットの採用
GeoPo v1ではURLとして使用できる64文字・Base64 URL（0-9, a-z, A-Z, -, _）を使用していましたが、H3の特性に合わせて49文字セットを採用しました：
採用文字（49文字）
大文字(24): A B C D E F G H J K L M N P Q R S T U V W X Y Z 小文字(17): a b d e f g h j k m n p q r t u y 数字(8): 2 3 4 5 6 7 8 9
49文字採用の技術的背景
- H3のセル分割: 各親セルから7×7=49個の子セルが生成される
- 効率的なマッピング: 49進法により文字セットと1:1対応
- レベル1の制約: H3基本セル122個のため2文字必要（49×3=147で余裕あり）
除外した文字とその理由
0, 1, O, I, o, i, l：視覚的混同の防止c, s, v, w, x, z（小文字）：大文字と同形状のため除外
この設計により、H3の数学的特性を活かしつつ、実用的な符号化を実現しました。余剰容量（レベル1で18段階）は将来的に高度レイヤーなどの拡張にも活用可能です。
GeoPo v2の核心：H3と独自の符号化レイヤー
H3をベースとした新アーキテクチャ
GeoPo v2は、H3の堅牢な基盤の上に、独自の符号化レイヤーを構築しました：
GeoPo v2 アーキテクチャ ┌─────────────────────────┐ │ GeoPo符号化レイヤー │ ← 人間が扱いやすい文字列 ├─────────────────────────┤ │ H3六角形グリッド │ ← 数学的に最適な空間分割 ├─────────────────────────┤ │ 球面座標系 (WGS84) │ ← 地球の正確な形状 └─────────────────────────┘
H3インデックスとの相互変換
GeoPo v2では、内部的にH3インデックスを使用しつつ、外部向けには読みやすい文字列を提供します：
// H3インデックス → GeoPo code変換例（東京駅付近）
const h3Index = "0000000082bf604"; // H3レゾリューション8
const geoPoCode = "AZtRmu"; // 対応するGeoPo code（レベル5）
// 逆変換も可能
const convertedH3 = geoPoCodeToH3Index(geoPoCode, 5);
console.log(convertedH3); // "0000000082bf604"この変換により、H3エコシステムの豊富なツール群を活用しつつ、人間にとって扱いやすいコードを提供できます。
技術的な特徴
GeoPo v2は、H3六角形グリッドを採用することで、以下の4つの技術的な優位性を実現しました。
1. 確かな「等面積性」
GeoPo v2の最大の強みは、地球上のどこでも同じレベルのセルがほぼ同じ面積を持つことです。従来のシステムでは、極地と赤道でセルの大きさが大きく異なっていましたが、GeoPo v2ではその歪みがなくなり、一貫した精度で位置情報を扱えます。これにより、緯度に関わらず正確なデータの比較や集計が可能になりました。
2. 最適化された階層構造
GeoPo v2の階層構造は、世界全体をカバーするレベル1から、建物の位置を特定できるほどのレベル8まで、合計8段階の解像度を備えています。それぞれのレベルが地理的なスケールに意味を持つように設計されているため、用途に応じて適切な精度で位置を表現できます。たとえば、国単位から都市、街区、建物へと段階的に絞り込むことが可能です。
3. 効率的な近傍計算
六角形グリッドの特性を活かした効率的な近傍計算も大きなメリットです。隣接するセルとの関係が明確なため、ある地点の周囲にあるセルを高速に検索することができます。これにより、特定のエリア内の店舗や施設を素早く見つけ出すといった、位置情報サービスの応答速度が大幅に向上します。
4. シームレスな境界表現
GeoPo v2は、地球全体をグリッドで覆っているため、国境や時差に関係なく、連続的な符号化が可能です。陸地だけでなく海洋部分も同様に扱えるため、地理的な境界に縛られることなく、あらゆる場所をシームレスに表現できます。これにより、国際的なデータ共有や、海域での位置情報サービス開発も容易になります。
49進法による効率的な階層表現
GeoPo v2では、49文字セットを活用した49進法により、効率的な階層構造を実現しています：
階層の展開パターン
レベル1: AA, AB, AC, ..., CZ (122個の基本セル、2文字)
↓
レベル2: AAA, AAB, AAC, ..., AA9 (各セルから最大49個の子セル、3文字)
↓
レベル3: AAAA, AAAB, AAAC, ... (各セルから最大49個の孫セル、4文字)六角形セルの配置パターン
H3の六角形グリッドでは、各親セルから49個の子セルが生成されます。子セルは文字セットの順序で割り当てられます：
最初の7セル: A B C D E F G 次の7セル: H J K L M N P 続く7セル: Q R S T U V W ... 最後の7セル: 3 4 5 6 7 8 9 (数字含む)
子セルは GEOPO_CHARSET 配列の順番で配置されます：
- インデックス 0 →
A（最初の大文字） - インデックス 23 →
Z（最後の大文字） - インデックス 24 →
a（最初の小文字） - インデックス 40 →
y（最後の小文字） - インデックス 41 →
2（最初の数字） - インデックス 48 →
9（最後の数字）
この規則的なインデックス配置により：
- 方向性の保持：隣接するGeoPo codeは地理的にも近接
- 検索効率の向上：近傍セルの高速な特定が可能
- 直感的な理解：コードの文字順が地理的配置と対応
最新技術で実現した、高速で快適な体験
Web技術スタックの選択
GeoPo v2のWebアプリケーションには、以下の最新技術を採用しました：
フロントエンド
- React 18 + TypeScript：型安全性と開発効率
- MapLibre GL JS：軽量で高性能な地図表示
- Vite：高速なビルドシステム
地図・可視化
- H3-JS：H3アルゴリズムのJavaScript実装
- 六角形セル可視化：リアルタイムレンダリング
- 階層ナビゲーション：直感的なズーム操作
パフォーマンス最適化
1. 遅延読み込み（Lazy Loading）
- コンポーネントの動的インポート
- 初期読み込み時間の短縮
2. チャンク最適化
- ライブラリごとの分割（React、MapLibre、H3）
- 効率的なキャッシュ戦略
3. モバイル対応
- レスポンシブデザイン
- タッチ操作に最適化されたUI
GeoPo v2の革新的特徴
1. 真のグローバル対応
// 座標からGeoPo codeへの変換
const tokyoCode = coordsToGeoPoCodeSafe(35.6812, 139.7671, 5); // 東京駅 → "AZtRmu" (レベル5)
const sydneyCode = coordsToGeoPoCodeSafe(-33.8688, 151.2093, 2); // シドニー → レベル2コード
// GeoPo codeから座標への逆変換
const coords = geoPoCodeToCoords("AZtRmu");
console.log(coords); // [lng, lat]の配列2. H3インデックスとの完全互換性
// GeoPo codeとH3インデックスの相互変換（東京駅例）
const geoPoCode = "AZtRmu"; // レベル5（6文字）
const level = 5;
// GeoPo code → H3インデックス
const h3Index = geoPoCodeToH3Index(geoPoCode, level);
console.log(h3Index); // "0000000082bf604"
// H3インデックス → GeoPo code
const backToGeoPo = h3IndexToGeoPoCode(h3Index, level);
console.log(backToGeoPo); // "AZtRmu"この互換性により、既存のH3ベースシステムとの連携が容易になりました。
3. 直感的なURL構造
https://geopo.creco.net/AZ # レベル1セル（2文字）
https://geopo.creco.net/AZt # レベル2セル（3文字）
https://geopo.creco.net/AZtR # レベル3セル（4文字）
https://geopo.creco.net/AZtRm # レベル4セル（5文字）
https://geopo.creco.net/AZtRmu # レベル5セル（6文字、東京駅付近）
URLに直接GeoPo codeを含めることで、ブックマークや共有が簡単になりました。
4. 視覚的な階層ナビゲーション
- セルクリックで下位レベルに移動
- 範囲外クリックで上位レベルに戻る
- スムーズなアニメーション付きズーム
ビジネスや日常生活の使用例
災害時の位置共有
地震発生地点: "AZtRmuf" https://geopo.creco.net/AZtRmuf
従来の住所表示より迅速で、誤解の余地がありません。
配送・物流業界
配送先: 建物レベルまで特定可能 GeoPo code: "AZtRmufpA" (レベル8精度・9文字)
IoTデバイスからのデータ送信
{
"device_id": "sensor_001",
"location": "AZtRmu", // レベル5（6文字、東京駅付近）
"timestamp": "2025-01-01T09:00:00Z"
}GeoPo v2 ライブラリの提供
開発者の皆様がGeoPo v2を独自のプロジェクトで活用できるよう、コアライブラリを提供します。
📦 ライブラリ構成
geopo-v2-lib.zip ├── geopo-core.ts # 純粋GeoPo実装（H3依存なし） ├── geopo-v2-core.ts # 階層構造・検証機能 ├── geopo.ts # 統合エントリポイント └── API-REFERENCE.md # 完全なAPI仕様書
🚀 基本的な使用方法
1. 純粋GeoPo機能（H3依存なし）
import { validateGeoPoCode, numberToGeoPoCode, geoPoCodeToNumber } from './geopo-core';
// 49進数変換
const code = numberToGeoPoCode(12345, 5); // "AAFG7"
const num = geoPoCodeToNumber("AAFG7"); // 12345
// コード検証
const result = validateGeoPoCode("AuB"); // { isValid: true, level: 2 }2. 階層構造処理
import { getParentCode, generateChildCodes } from './geopo-core';
// 親子関係
const parent = getParentCode("AuBA"); // "AuB"
const children = generateChildCodes("Au"); // ["AuA", "AuB", "AuC", ...]3. 統合機能（H3連携込み）
import { generateGeoPoCell, coordsToGeoPoCodeSafe } from './geopo';
// 座標からGeoPo変換
const code = coordsToGeoPoCodeSafe(35.6812, 139.7671, 5); // 東京駅 → "AZtRmu"
// セル情報生成
const cell = generateGeoPoCell("AZtRmu");
console.log(cell.center); // [lng, lat]
console.log(cell.boundary); // 境界座標配列📋 ライブラリの特徴
- モジュラー設計：必要な機能のみを選択して使用可能
- 型安全性：TypeScriptによる完全な型定義
- H3統合：Uber H3との相互変換機能
- 軽量：依存関係を最小限に抑制
- 検証済み：包括的なテスト実装
🔗 ダウンロード
GeoPo v2コアライブラリは、以下からダウンロードできます：
ライブラリには詳細なAPI仕様書が含まれており、すべての関数の使用方法と実装例が記載されています。
まとめ
GeoPo v2は、単なるバージョンアップではありません。H3という数学的に優秀な基盤を採用することで、実用レベルの地理位置符号化システムを実現しました。
従来の課題を解決
- ✅ 全球で均一な面積とアスペクト比
- ✅ 極地での実用性確保
- ✅ 数学的に最適化された六角形グリッド
実用性を大幅向上
- ✅ 直感的なWebインターフェース
- ✅ URL直接アクセス対応
- ✅ モバイルファースト設計
- ✅ 自動デプロイによる高い可用性
開発者向け機能
- ✅ 軽量なコアライブラリ提供
- ✅ H3エコシステムとの完全互換
- ✅ TypeScriptによる型安全性
- ✅ モジュラー設計で柔軟な導入
GeoPo v2は、学術的な興味だけでなく、実際のビジネスや日常生活で活用できる実用的なツールに進化しました。開発者向けライブラリの提供により、さらに多くの分野で地理位置符号化の利便性を提供していきます。
GeoPo v2を体験・活用する
- 🌐 https://geopo.creco.net – Webアプリケーション
- 📦 geopo-v2-lib.zip – 開発者向けライブラリ
- 📱 モバイルからもアクセス可能
- 🔗 任意のGeoPo codeでの直接アクセス対応
皆さんもぜひGeoPo v2をお試しいただき、新しい地理位置符号化の可能性を体感してください。開発者の方は、ぜひライブラリを活用して独自のアプリケーションを構築してみてください。
コメント