先週、造成現場で撮ったUAV点群をRevitに載せようとして、平面図と数十センチずれた。原因を追いかけていたら、Qiitaで同じ話にぶつかった。今週はドローン測量まわりの記事が点群処理・GIS・事業展開まで幅広く出ていて、社内の標準化にそのまま効きそうなネタが多い。整理しておきます。
今週の主なトピック
点群がUnityでずれる話、原因はfloat32の桁落ち
[Unity] 現場のLAS点群がずれる原因と対処法│float32の有効桁・測量座標のアンカー移動・LOD生成【OSS】では、平面直角座標系の値をそのままfloat32に入れると有効桁が足りず、cm単位で位置がずれる話が書かれています。対処はアンカーを原点付近に寄せてから相対座標で扱うという、地味だけど効く方法。
Unity固有の話に見えて、実はNavisworksでもUnreal系のビューワでも同じ罠がある。座標系の話は「BIMソフトが吸収してくれるだろう」で済ませがちだけど、外部ビューワに渡した瞬間に破綻する。うちでも過去に発注者提出の統合モデルで似た事故があった。
正高と楕円体高、オフラインで変換する仕組み
オフライン GIS 高さ計算システムの実装は、DTMとジオイドモデル（EGM2008、JPGEO2024）を使って標高と楕円体高をオフラインで相互変換する実装記事。RTK付きドローンで飛ばした点群のZ値がどっちの基準か、意外と現場では曖昧なまま処理が進むことがあります。
造成の土量計算まで来て「基準がずれてました」だと目も当てられない。オフラインで完結する変換手順を社内に持てるのは、セキュリティの厳しい現場でも動かせるので実務的にありがたい。
QGISプラグインで森林オープンデータを取得
【QGISプラグイン】Japan Forest Tools – 日本の森林オープンデータを簡単に取得・可視化は、林野庁系のデータをQGISから直接引ける拡張。土木系・造成系の初期調査で使えそうです。
事業側の動き
- ［経営教室スタートアップ編］テラドローン徳重氏「『まず日本から』では手遅れに」：測量・点検を柱にした海外M&A中心の成長論。国内ゼネコンから見ると、海外拠点の測量サービス調達先として名前が挙がる存在になりつつある。
- 「DJI Terra V5.3.0」解説セミナー（8/27福岡）：DJI Terraのアップデート内容とデータ活用の解説。写真測量ソフトはまだ現場で癖の把握が要るので、こういうセミナーは行かせる価値がある。
- エベレストのクンブ・アイスフォールを3Dモデル化：極地でのフォトグラメトリ事例。派手だけど、飛行計画とGCPの置き方の観点で見ると学びがある。
- APEXの技術コラム開設（ハンディSLAM等）：ハンディSLAMの実務ノウハウ公開。屋内・狭所の測量で協力会社に発注する時の目線合わせに使えそう。
ゼネコンBIM担当としての独自考察
今週の記事で一番効くのは、正直に言うとQiitaの2本です。派手さはないけど、社内標準化で毎回引っかかるのが座標系と高さ基準の話だから。
うちの会社では、UAV測量は協力会社に発注するケースが多い。納品されるLASやOBJの座標系・高さ基準・原点のオフセット処理が業者ごとにバラバラで、Revit/Civil 3D/Navisworksに載せる段階で毎回誰かが手作業で調整している。積算チームに数量出す時、この調整のせいで土量が数%動くこともあって、都度説明が要る。
そこに対して、発注仕様書のテンプレに「平面直角座標系の系番号」「高さ基準（標高か楕円体高か、ジオイドモデル名）」「オフセット原点の座標」「点群の間引き前後のファイル」を必須項目として書かせる形に来期から変えたい、と個人的には思ってます。Qiitaの記事はその根拠資料として社内に回せる粒度なのが助かる。
導入ハードルとしては、協力会社側の理解度の差が大きい。ジオイドモデルの話をすると引かれることもある。なので、社内で変換スクリプト（オフラインGISの記事のような仕組み）を用意して、業者からは楕円体高のまま貰って社内で標高に直す、という運用の方が現実的かもしれない。まだ試せていないけど、次の造成案件で1本走らせてみるつもり。
総括
ドローン測量は「飛ばして終わり」の時代から、「どの座標系・どの高さ基準で、どうBIMに載せるか」を発注時点で決めておく時代に入っている、と今週の記事群を読んで感じました。派手なアップデートより、座標のズレ1つで積算が揺れる話の方が、日々の業務にはずっと近い。来週の福岡セミナー、日程が合えば覗きに行きたい。