杭打ちナビをどう設計するか — 次期アプリ「GeoC」開発メモ
GeoDiveExa（GDE）の次に計画している9本のアプリ構想のうち、開発順2番目にあたるのが「RTK杭打ちナビ＋基準点チェッカー」です。GDEで培ったRTK高精度測位の知見をどう「杭打ち誘導」という別の使い方に転用するか、企画段階の設計メモをまとめます。
※本記事では、非公開の次期アプリの正式名称は伏せ、GeoCという仮称で表記しています。
杭打ちナビが解く問題
測量・土木の現場でよくある作業に「設計座標の位置に、実際に杭を打つ」という工程があります。トータルステーションで行う方法もありますが、RTK-GNSS受信機とスマホがあれば、後方視通のいらない身軽な運用ができます。GeoCが目指すのは、この「目標座標へどれだけ近いか」をスマホ画面だけで直感的に把握できるナビゲーション機能です。
GDEはすでに「現在位置と測点を地図上にリアルタイムでプロットする」機能を持っていますが（RTK測点を現場で地図にリアルタイム表示）、杭打ちナビはこれとは目的が異なります。地図で広い範囲の測点分布を俯瞰する機能ではなく、1点の目標座標に対して「あと何m、どちらの方向か」を歩きながら追い込むための、狭い視野に特化したUIが必要になります。
誘導UIの基本設計
杭打ちナビのUI設計で軸になるのは、次の3つの表示要素です。
| 要素 | 内容 | 設計上の論点 |
|---|---|---|
| 方向矢印 | 目標座標への方角を示す矢印。歩く向きに応じて回転する | 端末の向き（コンパス）と進行方向のどちらを基準にするか。磁北と真北のズレも考慮が必要 |
| 残距離 | 目標座標までの水平距離（cm単位まで） | 近づくほど桁を細かく表示し、視認性を落とさない工夫が要る |
| 測位品質 | Fix / Float / Single の状態表示 | Float状態のまま誘導を続けると誤差が大きいため、品質に応じて警告色を変える |
矢印による誘導は直感的ですが、GNSSの生の位置は数十ms～数秒単位で微小に揺れるため、そのまま矢印を動かすとブレて見づらくなります。GDEの複数回測定の平均＋外れ値除去で使っている「ある程度の回数を溜めてから確定値にする」考え方を、杭打ちナビでは「表示の平滑化（移動平均で矢印のブレを抑える）」という形で転用できないか検討しています。
許容誤差をどう設計に落とすか
杭打ちの精度要求は用途によって大きく異なります。公共測量の作業規程の準則では、測量の種別・等級ごとに許容できる誤差の範囲が定められており、GeoCではこれを「許容誤差プリセット」として選択式にする方向で考えています。
- 厳密な境界確認・出来形管理：数cm単位の高い精度が要求される
- 仮設・準備工の位置出し：数十cm程度の精度で足りる場合が多い
許容誤差の設定値によって、誘導UIの「これでOK」判定（画面の色が緑に変わる距離のしきい値）を変える設計です。Fix解が出ていない状態で緑判定を出してしまうと誤った安心感を与えるため、測位品質と距離の両方が条件を満たしたときだけOK表示にするという組み合わせ判定を基本方針にしています。
基準点チェッカー機能
GeoCのもう一つの柱が「基準点チェッカー」です。既知の基準点（電子基準点・三角点・任意の控え点など）の公表座標に受信機を据え、実測値との差を確認する機能で、RTK環境が正しく機能しているかを現場で簡易検証する用途を想定しています。
これは目新しい機能ではなく、GDEが持つ「測定→比較→記録」の基本ループを、目的地に固定基準点データを設定する形に組み替えたものです。GCVPの座標変換ログのテキスト保存のように、「何を根拠にこの結果を出したか」を記録に残す設計思想は、GeoCでも踏襲したいポイントです。
GDEの資産をどこまで転用できるか
GeoCの設計は、GDEで実装済みの以下の要素を土台にする想定です。
- RTK受信方式のクライアント／サーバ切替（受信機の機種を選ばない接続）
- Fix/Float/Singleの品質表示とビープ通知
- 測定値のローカル自動保存
一方で、杭打ちナビ特有の「狭い視野での誘導UI」「許容誤差プリセット」「基準点データベースとの照合」は新規に設計する部分です。既存資産を流用できる範囲と、新規に作り込む範囲を早い段階で切り分けておくことで、開発順2番目としての着手をスムーズにしたいと考えています。
まとめ
- GeoCは「目標座標への方向・残距離・測位品質」を1画面で示す杭打ちナビと、既知基準点との差を確認する基準点チェッカーの2機能を柱にする
- 誘導UIはGNSSの微小な揺れを平滑化する工夫が必要で、GDEの複数回測定平均の考え方を応用できないか検討している
- 許容誤差は用途別のプリセットとし、測位品質と距離の両方を満たしたときだけOK判定を出す設計にする
- RTK接続・品質表示・ローカル保存などGDEの実装資産は土台として転用し、誘導UI・許容誤差プリセット・基準点照合は新規設計する
関連記事
- Geoアプリ9本構想 — 個人開発のプロダクトポートフォリオ設計（GeoDiveExa）
- RTK1点のばらつきを抑える — 複数回測定の平均＋外れ値除去で測点を決める（GeoDiveExa）
- Fix解の「取り逃がし」を防ぐ — 測位品質の常時表示とビープ通知で現場のミスを減らす（GeoDiveExa）
- GeoCoreJPの高精度座標変換を支える設計思想（GeoConverterPro）
- 単独測位からRTK・PPPまで — 測位方式の精度を可視化で学ぶ入門（GeoPrism JP）
開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。
お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。
コメントを残す