座標系の平行移動と回転 parallel translation and rotation of the coordinate system

はじめに

 CloudCompare Wiki に頼る。このサイトの検索窓にrotationを入力すると,Apply Transformation が表示される。内容は簡潔明瞭である。まずはこの情報に従って,1. 実行プロセスをまとめて,2. ぼくのcloudを使っての作業を示すことになる。ぼくにとっては,初めての試みでワクワクしている。

 これによれば,transform, i.e. rotate and/or translate, とあって,座標変換 coordinate transformationとは,水平面での回転 と, 回転せずに平行移動,するということである。 手軽にできるので,基本的に調査後には実行することになるであろう。

1 Apply Transformation 座標系の回転と平行移動の手順

 Apply Transformation の記述に従ってまとめると次のようになる。座標変換のためのスカラーの入力にはここでは,3種用意されているが,最も簡潔な,XY平面内(Z値は固定)での回転軸と回転角(degrees),そして平行移動(xyz3軸の筈だろう),を選択する。
 次の記述は,この章より後の実行プロセスで得た内容をフィードバックした形で示すことになるだろう。

  1. 座標変換対象のcloud(ぼくの経験値ではFBXファイル)を開く。
  2. Edit>Apply transformationメニューを選択する。
  3. Axis, Angleタブを選び,スカラー値を入力する。
  4. OKボタンをクリックして完了。

2 座標変換対象とするcloudの紹介

 iPhone 12 Proで3Dスキャニングを実験的に初めたのは,当方のサイトの記録からすると2月9日夜に自宅のシングルソファをScaniverseで撮影した時に始まる。昨日,iPhone 12 ProからEveryPointを削除し,ScaniverseについてはLibraryを空にしたので正確な日付は不明である。スキャニバースももう不要とは思っているが。最初の撮影は2月8日の夜かも知れない。外部のcloud公開サイトにもぼくは関心が無く,アップも数回して止めた。20日間でここまできた。

 対象cloudは,裸岩露頭のiPhone 12 Proを使った点群撮影 の,「7 凄腕Metascanを理解すべく:白姫大明神,Feb. 18, 2022」の図26, 27で紹介したLiDAR撮影のcloudとする。これは,二つの3Dスキャンマップを繋ぐ でマージし,CloudCompareで不要なポイント群または面群の削除 で,測量結果として使える程度にゴミ取りを実施した,Merged mesh.bin 2022/02/24 1:44 を使うことにする。

図1 Merged mesh 全体像

 図1には,Merged meshの全体像を示している。このほぼ中央には二枚のcloudを繋ぐのに使った4枚のラベルが見える。そのズームインが図2である。赤白のターゲット1〜4が右上1,右下,左の中程,左上4にこの順で見えている。

図2 Merged mesh ラベル4枚付近

 iPhone 12 Pro撮影の3Dスキャン画像の座標を捉える では,「実際の調査の際には,光波測量などを実施することになるし,4点ほどの地標情報も得ることができる。iPhone 12 Proのすごさであるが,重心方向は瞬時に検知されていて,Z軸は重心軸と平行である。3Dスキャン点群のZ軸のゼロ点は現地での海面高を測定して潮位計算をして得ることができる。XY軸の方位軸も地標との対応関係から3Dスキャン点群を磁北または真北に回転することが可能である。それゆえ,3Dスキャン点群の座標値が得られれば,事実上,光波測量の座標系に載せることができるので,殊更,3Dスキャン点群をこのCloudcompareでtransformationする必要性は,ない。」としている。

 で,残念ながら地標の実測情報が無いので,仮の作業を実施することにする。ラベル1を原点とし,ラベル4をラベル1から視準した場合の真北方向とする。磁北方向としても良いがここでは作業を単純化するために,真北方向とするのである。iPhone 12 Proによる3Dスキャン図をCloudCompareで読み込んだ場合の座標系はユークリッド座標系であるが,それをこのラベル1と4の情報から座標変換をすることになるのである。

 ラベル1と4の座標値は,次のページの図8に見える。二つの3Dスキャンマップを繋ぐ
それを書き出したのが次の表1である。

XYZ
ラベル1 R00.236343-0.496429-0.229579
ラベル4 R30.1394210.4741563.645772
表1 ラベル1と4のXYZ値

 

 今後,座標変換をする際に,複数のcloudを繋ぐことは面倒なので(Metascan Proは使用制限が無い),(前もって手順を考えて)一気に全域をスキャンすることになるだろう。ラベルの座標値は,次に紹介した方法で求めることができる。iPhone 12 Pro撮影の3Dスキャン画像の座標を捉える の,4.1 Point picking,4.2 Point list picking,である。

 4.1 Point pickingを実施して,ラベル1と4の座標値を確認した。図3に見えるように,ラベル1ではラベルがダブって見られる。座標値から確認したのであるが,アラインメントの際のレファランスになった方は,この図の上方のものである。図4のラベル4では幸い1枚だけが示されている。なお,図3と図4の左手のペーンの赤で囲った情報から,座標を知ることができる。

図3 ラベル1の座標情報
図4 ラベル4の座標情報

3 ”Axis, Angle”タブでの入力値を前もって求める

 ラベル2枚のcloud位置情報で,ラベル1を基点とする。後の変更は簡単なので,ラベル1(X, Y) = (0, 0) とし,ラベル4はラベル1からの真北線上に載せたい。言い換えると,現地調査の際には目的によるが多数のラベルを設置する。そのうちの1ラベルを基準点とする。この場所の地球座標系の1点としてできれば確定したいのであるが,地形研究でそれほどの精度も必要ではなくて,iPhone 12 Proのgpsで得た情報でも足りるとは思う。そして,クリノコンパスを使って磁北方向を視準し,地上のまあいわば目立つ場所を覚えて,そこにもラベルを設置する。現地測量はこれで終わりである。ただ,白姫大明神裏の参道では,この作業すら実施していない。
 なお,クリノコンパスを使う理由はiPhone 12 Proのコンパスの不安定性である。周辺環境の電磁波の影響を受けやすく,沖永良部島の海岸部の一画では明らかにiPhone 12 Proのコンパスは磁北を指さなかったが,従来型のメカニカルなクリノメーターは磁北を指していたという体験がある。

 繰り返すが,LiDARモードや写真モードで3Dスキャンした情報には最低かつ必要十分な2枚のラベルが不可欠である。一つは測量の仮原点(地球座標系上の点)として,もう一つは仮原点からの真北または磁北の延長線上に設置されていることである。両点の距離などの測定は不要である。

 
 

図5 3Dスキャンcloud座標系をランドマーク座標系に変換

 図5解説: CX-CYはiPhone 12 Proで取得したcloudの座標系である。赤線のLx-Lyは地標の測量から得られた座標系である。cloud座標系を地標座標系に変換する流れを示している。図5は重力Z軸成分を外して表現している。
 Apply Transformationの設定では,回転軸の座標値,回転角度(度),平行移動ベクトルを入力する。

表2 エクセルで回転角度の計算

上掲は図5や表2などの計算ができるエクセルファイル。利用者は,四角枠内の赤い数値に替わって自らの数値を入力することになる。

 図5に基づいて表2の上段(2〜7行目まで)では,アークサインの計算をしている。座標の回転は,真北軸の時計回り90度,反時計回り90度,で完全に満たされるので,arccosineではなく,arcsine(エクセル関数はasin)を求めているのである。

図6 Axis, Angles タブ入力

 図6では,主に表2の上段の計算に基づいて,Edit>Apply transformationメニューを選択して,”Axis, Angle”タブを選んで,スカラー値を入力している。入力時に混乱もありうるので,表2の中段(10〜14行目)で改めて,入力値の配列などを揃えて表現している。OKボタンを選んだ結果は,次の図7と図8に示している。図7は原点対応のラベル1,図8は真北視準軸上のラベル4である。

図7 原点対応のラベル1
図8 真北視準軸上のラベル4

 座標変換の結果を表2の下段(16〜25行) に示している。これを評価するのに,ランドマーク2点の座標値で比較している。18〜20行のランドマーク1関連の数値は,原点 (0, 0) に近い値を得たかったのであるが,x値: -0.0017,y値: 0.0005,であり,かなりいい結果となっている。z値には2.5000が期待され,2.4995となっているので,これも良い結果が得られている。

 22〜25行の真北視準線上のランドマーク4については,x値: 0.1819であり,座標変換前の 0.1394よりも却って x値: 0.0000よりも離れてしまった。とはいえ,0.20m以内のズレであって,致し方が無いようである。変換式の特性に由来するものであろう。この問題は測量結果を評価する際に検討を要するかもしれないが,結局,この計算はすべてcloud内でのものであり,変換アルゴリズムに帰すべき問題と言える。

 平行移動に誤差要因は働かず,回転には多少問題があるようである。地形解析では方位に拘る必要性は無いとも考えられ,平行移動だけを実施するのもいいのではとも思われる。

おわりに

 以上で,座標変換作業プロセスについては理解できたものと考える。

以上,Mar. 1, 2022記。