続国土地理院の基準点成果の利用 a sequel to using control point survey results made by the Geospatial Information Authority of Japan or GSI
はじめに
国土地理院の基準点成果の利用 は，2022年秋に作成したものである。これを元に，文学論集Vol. 74, No. 4に投稿すべく記述してみて，2年間のブランクもあって，一つの章を追加する必要性を感じ（2年前に残したことであった），それをここにまとめることにした。制限ページ数に近く，ここで書き込んだもののダイジェストを文学論集Vol. 74, No. 4の第Ⅹ章にしたいと思った。
0. 「Ⅹ LiDARルート測量とライダーROI測量を繋ぐ」（コピペ）
2024年秋現在，筆者の利用の観点からすると，最も優れた3D LiDAR ScannerアプリはScaniverse[i] (v.4.0.2) である。Polycam[ii]と，これまで述べてきたMetascanは，マニュアルを読む限り，パワフルなアプリという印象を受けてきたが，1セッションのLiDAR測量継続時間はいずれも10分間に限られる。Polycam Pro [for iOS v.3.5.18 (225)]の説明書には10分間の限界は書かれていないが，10分を超えると，「前のエリアに戻って再開する」と「最初からやり直す」の二択を迫られる。戻っても再開されない。Scaniverseには，この制限に関連する情報は記されていないが，幸い経験的にこのような限界はないように思う。
さて，ここでは本章タイトルを実行する。許されたページ数は残りわずかなので，これまでのような順を追った説明は省く。これまで，基準点4カ所を通るLiDARルート測量結果を平面直角座標系に載せる手法を示してきたが，ROIのライダー測量結果を平面直角座標系に載せる手法は示していない。しかし，賢明な読者はこれから述べる内容をすでに見抜いておられるのではないかと想像している。
本報告の目的は，ROIのLiDAR測量結果を平面直角座標系に載せる手法を示すことにある。測量ルートの選定は当然，ROIを通過するかその近接地にすることになる。ルート測量の途中でROIのLiDAR測量を実施することも可能かも知れない。ただ，ROIでは丹念にLiDAR測量を実施するので通常，ルート測量とは別にしたいと考えるだろう。
そこでルート測量の際に，ROI付近に一時的な二次的基準点を4カ所設置すれば良いと考えられる。ルート測量して，引き続きまたは翌日にでもROIのLiDAR測量を実施することもできる。なんらかの理由で繰り返しLiDAR測量したい場合にもこの4カ所の二次的基準点を繰り返し使うことができるのである。
[i] Scaniverseは，Niantic（ナイアンティック）https://nianticlabs.com/products?hl=ja による開発中のアプリ。NianticはGoogle社内のスタートアップ企業でGoogle EarthもGoogle mapも開発している。現在Googleから独立したらしい。かつては有料だったが無料化されて，先進的なGaussian Splatting機能が付加されてもなお，無料のままだ。
[ii] https://poly.cam Polycam Proを2024年10月に月契約（＄26.99）してみた。
1. Oct. 26, 2024実験
曇りの日で雨が降りそうな天気であった。自分の影が映らなくて良いと感じた。Splattingに期待もしていた。Polycam (Pro)が，LiDAR測量の10分間限定を超えるのではないか，という期待があった。先に結果を言えば，PolycamもScaniverseもSplattingはルート測量には適さないということである。LiDAR測量こそ，ルート測量に適していることが判明した。諦めがついた。図1を参照してほしい。
後述するが，DOIに当たるのが，打越池南縁の歩道である。DOIを公共の基準点とつなぐ目的でルートを設定している。
南西部の基準点3-61から出発し，打越池南縁のDOIに階段②から入って③の阪急バス停「青松苑」から出て，⑤の交差点を通過して，④の基準点3-42に到達して交差点⑤に戻り，⑥の基準点3-40に北進する。そして，⑦の基準点3-41，②を通過して，①の基準点3-61に戻っている。
文学論集図51に登録済み。
階段②からバス停③の間がDOIという設定であるが，そのルートのGoogle map (2024年) 画像を図A下部に示している。画像右下隅に見えるスケールの長さは10mである。③と④の間の300mほどの距離の間に，レーベル L-1〜-4を設置しているのである。
図B，Cは打越池南縁プロムナードのステレオ写真である。ベンチの向こう先端の左手のレンガとアスファルト境界付近の地面にLabel-1を置いていた。左右両方の金網塀には葛が絡まっている。
Label 1〜4を図D〜Gに示す。Label 1は階段に近く，Label 4はバス停に近い。
以上，2024年10月24日記
2 Polycam社そのものの社会的信頼度は低い
Splatting機能をもつPolycamとScaniverseではあるが，ぼくの昨日のルート測量には使えないことがわかった。Scaniverseは無料で，Polycamは有料版でないと撮影はできるがその後の計算処理や出力ができない。2024年10月14日付でアップルから3300円が請求されていた。アカデミックで申請して半額の筈であるがフルに請求されている。1カ月当たりの料金である。別途ぼくの銀行からもDebit Cardから出金しているので（Debit Cardのみ受付と要求された），二重の請求である。銀行とVISAからの二重請求である。Debit Cardは即時送金なので，アップルにクレームをつけるしかない。11月11日に銀行引き落としなので，書類を揃えてアップルケアに連絡することになるだろう。
今，書類は全部揃えた。明日，アップルケアに電話しよう。ぼくのVisaカードの11月11日の支払い明細（3300円），アップルからの領収証（3300円），銀行の取引明細（2103円）。3300円/$26.99= 122円/$，2103円/$13.5= 156円/$，である。
図H, Iは，購入の際に見た価格やアカデミックディスカウントの情報。図9のhttps://poly.camから入ってアカデミックの契約をして，Debit Cardのみの受付と要求されたので，ぼくの銀行から送金したことになっている。そうしないと，進めなかったのである。
以上，2024年10月27日記。
2.a アップルケアに連絡
さきほど，アップルケアに問い合わせた。相談員との話の前に，サブスクリプション，の問題として宣言し，iPhoneだけで読めるメッセージが届く。そこにあるリンクから申請もできるが，相談員とコンタクトを持てるとアナウンスがあり，相談員が電話に出るのを待った。事情を説明し，了解いただいた。二日間の審査があって，ぼくのクレームの是非が審査されるという。
どう審査されるのかを問いただした。PolycamのウェブサイトでのぼくのDebit Cardでの支払いをアップルは把握しようとしないことが判明。ぼくの手持ちの書類を受け取る形も持っていない。アップル関係者が，PolycamのWebサイトでぼくのように，アカデミックディスカウントのリンクに入ってDebit Cardでの支払いをしてみないとわからないと，相談員に伝えた。相談員はかなり優秀でぼくの意見は理解していたようである。Polycamにぼくがクレームをした方が良いという提案もあった。
2.b Polycamにメール
poly.camと入力すると，https://poly.cam/library に入ることになる。これがトップページと考えて良いだろう。この最上段のリンクの一つに，contact salesリンクがある。個人情報を入れてコメント欄に入力することになる。そのコメントは次のよう。
Please return ¥3300 = $26.99 per month for Polycam Pro to me.
My apple account: xxxxx@xxxxx.ac.xxxx
————————————————
- I bought “Polycam for Education” using my Debit Card you need on Oct. 14, 2024.
“¥2103=$13.5 on Oct. 14, 2024” is shown in the Description of a trade of my city bank.
I had received your message: Polycam for Education
Thank you for applying for Polycam for Education!
Here’s your promo code for 50% off Polycam Pro: EDU0523AXJ
Here’s how to redeem your promo code:
Create or log in to your account on our website at https://poly.cam
- I recognized the following supposedly impermissible thing yesterday.
a. I found a mail from Apple Inc. to moto@kansai-u.ac.jp: a receipt of ¥3300 = $26.99 per month for Polycam _ LiDAR 3D scanner (order no: MML2T4M8MN)
b. I checked the billing details of my credit VISA card and found ¥3300 = $26.99 from Apple Com Bill.
————————————————
I made a phone call to the Apple Care, and advised to call you. Thank you. Oct. 28, 2024.
発送のちすぐに対応するとのことだが，すでに2時間あまりが経過したが返事はない。現地時間は活動時間帯ではないかもしれない。
このコメント発信ののち，当方のacademyメールをチェックしたら，アップルからの3300円の領収書が来ていた。びっくりして，アップルケアに電話した。どうも，ロボットに，サブスクリプション，と宣言した時点で，アップルから10月14日の領収証が再送されたらしい。
2.b アップルから返金があった
Polycamからの返事は全くなかったが，アップルからOct. 14, -¥3300の連絡があった。このアップルに登録しているクレジットカードの請求明細は変更されていない。次回の明細にOct. 29 -¥3300となるのであろう。
以上，2024年10月30日。
2.c 一ヶ月後にまたデビットカードから泥棒された
Polycamのサイトにログインしても，脱会のリンクがない。返事も来ない。それで，ユーザー登録そのものを削除した。その際，アクセスできない趣旨の警告があった。iPhone 12 Proからアプリを削除し，iPhone 12 Proのシステム設定のアプリのリストも削除した。前述の１回だけ，Polycamにアップロードしただけであった。
アクセスしようにも，次の図I-J 4, 5のように既存ユーザーがアクセスするリンクがない。コンタクトしても返事はないのでもう，やる気がしないし。ハイリスクの印象だ。
にもかかわらず，Nov. 7, 2024にキャンセルしないとまた請求するよというメールが届いた。宣伝メールやこの種のメールが届くが怖くて無視。返事はない。そして，Nov. 14に
図I-J 6は，Polycamからのメールだ。その一分後にりそなから，引き落としの連絡だ。
このPolycamから離脱すべく，りそなのデビットカードに連絡した。デビットカードを停止にしても勝手に引き出される可能性があるという。結局16桁のVISA番号を廃棄するしか方法がない。銀行に出向いて，デビットカードから退会して，キャッシュカードだけにするしかない。銀行に出向いての手続きの予約した。デビットカードは引き落とされたら戻らない。保証がない。かなり危険なツールである。クレジットカードはそういう意味で安全が担保されている。
ただ，このウェブサイトのコンテンツ作成にともなって銀行口座からのクレジットカード引き落としを最近調べた。少なくとも数年にわたって二ヶ月に1回6000円あまりが抜かれていて，覚えがなく，二ヶ月前かにこの銀行に行って，この引き落としを差し止めた。この会社からはなんの連絡もない。トヨタのTSキュービックカードのようだ。トヨタ販売会社に問い合わせ，車利用のなんらかの諸費用の発生の所在を聞いたが，思い当たらないという。そういう意味でトヨタも危険だ。トヨタは気づいていないのかも知れない。誰かが騙っている。銀行の調べでは引き出している事務所は移転していて，その移転先はわからないという。それでも銀行は気にしない。
このりそな銀行のデビットカードの相談の後，アップルケアに電話して，アップルストアの問題点を詳細に伝えた。まあ上に上げると言っていたが，二日前の日経ニュースで，アップルからの不当な手数料回避のためにソフト会社が抜け道を模索しているらしい。Polycamそのものが特に悪というわけでなく，システム作りが甘いだけでなないかと思う。返事もないし，Webページに書かれている環境を実現できていないのだろうとは思う。とにかく，POLYCAMはやめた方がいいのは確かだ。Apple Storeはこの面では保証外だ。手数料を下げて，ソフト販売会社の手綱をしっかりと握ってほしいものである。
以上，挿入，2024年11月15日。
3 Polycam – LiDAR 3D スキャナーによるスプラッティング
スプラッティング splattingに対応する日本語はない。この技術が我々消費者に提供されたのは昨年秋である。NeRFという技術に基づいている。たとえば，NeRFとは？従来の技術との違いとユースケース、これからの課題について 2023/10/28によれば，「NeRF(Neural Radiance Fields) は、カルフォルニア大学の研究員が2020年3月に発表された新しい技術で、ニューラルネットワークを使用して、複数の写真から3Dシーンを生成する技術」とされている。「NVIDIAは，2022年1月に高速化を実現した「Instant NeRF」を発表し、数時間かかっていた処理が数秒で実現させることに成功しました」とある。
Polycam Proで図Aのルートを21分間でsplatting スキャンした。動画を選んだ。スキャン完了後，そのファイルは1.97GBとある。「uploadと処理」か「後でアップロードする」という選択が出るので，高速のWi-Fi環境がある自宅で実行すべく，さしあたり，「後でアップロードする」を選択した。
帰宅後，「uploadと処理」を選択すると，図Jが現れる。写真枚数は最低20〜最大2000とあり，今回のは717枚を自動撮影したらしい。動画を選んだのであるが，写真も撮られる。実際，スキャン中，シャッター音がひっきりなしにあった。基準点や交差点での信号待ちの際にはパシャパシャとシャッター音がしていた。図JのProcessing modeでまずは，Gaussian splatボタンを選択したら，図Kが現れた。図Jの詳細メニューは無くなっている。「アップロードと処理（1.97GB）」のボタンをタップした。
図Lはprocessingの途中である。18:24にスタートして，20:03でアップロード中25%となっている。図Mはprocessingの終了直後である。4時間20分ほどprocessingにかかったということである。サーバーへのアップロードが終わったということであり，次にサーバーでsplattingの解析が始まっているのである。図Nはライブラリーに戻った際の表示で，対象ファイルは，「処理中」とある。しかし，図Oのように，23:06には「キャプチャー処理に失敗しました」というメッセージが現れた。
つまり，ぼくの今回のルートスキャンのような作業にはPolycam ProのSplattingには対応していないということである。狭い範囲のDOIでの詳細なスキャンを実施すれば結果が出る可能性はもちろんあるだろう。
4. Scaniverseによるスプラッティング
図Aのルートを24分間かけてsplattingした。スキャン中（図P），more slowlyと忠告が出続けた。最後まで中断されることはなかった。more slowlyの忠告は図Pのスキャン中出ていたがスクリーンショットには映っていない。画像はゴミのようなものが続いた。以前タニハでこれを使った際にはかなりゆっくりとスキャンして一応，出力できたが，スキャン中は雲のようで映像がはっきり見えなかった。Polycamの映像がクリアなのと大きな違いである。無料だからしかたがないとは思う。
図Qはスキャンが完了した際のスクリーンショットである。Process Laterを選んだ。Polycamと違って，Wi-Fiでアップロードせず，iPhone内で完結する。ここがメリットとも言える。自宅に戻ってProcessingを実行したが４回ほどトライしたがerrorから抜け出せない。ルート測量には適さないということだ。
以上，2024年10月28日。
5. Scaniverse によるLiDAR測量のおよそ
結局，ルート測量はLiDAR測量に限定されるということらしい。写真測量はかなりの情報が必要なのに比べて，LiDAR測量は，直接ベクトル長や方向角を捉えるために，空間把握が「高速」なのである。図1ではルート途中に打越池南縁のROIが含まれるのであるが，ルート測量の途中なので，このROI部分を詳細にスキャンするという発想もあったが，それは誤りである。ルートスキャン測量と詳細スキャン測量は別に考えた方がよい。前者で公共の基準点4点とROI内のLabels 1 to 4をスキャンして，公共の基準点4点からROI内のLabels 1 to 4の座標点を求めて，その上で，Labels 1 to 4を含むROI内の詳細スキャンを実施するのが適当ということになる。
10月26日にLiDARによってルート測量をScaniverseで実行した結果をアイフォーンのライブラリー表示でまずはみたいと思う。このルート測量結果は図1のものである。図Sでは，①つまり3-61基準点を出発しこの①に戻っている。同じ3-61基準点の3D距離が26.38mにもなっている。ズレているのである。図Tではこの3-61基準点が二つのヘビの鎌首のように見える。巣閉距離も垂直距離もずれている。図Uでは，図の下方から上方に進み，上端付近では，プロムナードが終わってバス停があるアスファルトの歩道に出ている様子が見える。バス停そばのLabel 4付近は立ち止まってスキャン時間が多少長くなっているので，プロムナードがはっきり見えるが，そのあと早足で歩道に出ているのである。画像が切れていても，場所情報は繋がっている。これはLiDAR測量の貴重な長所とも言えるのである。
図Vはライブラリー表示の画面であるが，下部の生垣などの画像はScaniverseのSplattering測量の結果が見えるが，画像はLiDAR測量と違ってはっきりと再現されている。詳細スキャン測量はSplatteringが有効とわかるだろう。
6. LiDARルート測量結果をグリッド平面座標に
これからの作業は，macでこのWebページを作成，計算処理も実施しつつ，Windows PCでCloudCompare操作をしてその作業過程のスクリーンショットを撮影し，それをmacでのWebページ作成に利用するので，macとWindows PCの間をサーバー接続環境にしている。
6.a 基準点を使ってアラインメント
1 iPhoneアプリScaniverseのライブラリーに格納されている筆者作成のライダー測量結果を点群系のPLYファイルでmacにアップロードし，共有設定したWindows PCにも保存する。ファイル名：IshimaruOct26-2024byScaniverseLiDAR.ply
2 Windows PCのCloudCompareから，このPLYファイルを開く。
3 macで表6のルート5地点①，④，⑥，⑦，①の (Y,X,Z)の基準点3D座標値から，csvファイルを作成して，両共有フォルダーにコピーしておく。次の表6にまとめている。
4 CloudCompareのコンソールのPLYクラウド上で，ルート5地点のpoint list pickingを実施する。point list picking：Tools > Point list picking，またはトップのツールバーの左から5番目のアイコンをタップ。
図Wは実行後の結果で，Points #0 to #4の座標値はcsvファイルで出力している。
5 上記のpoint list pickingの結果のcsvファイルを元に次の表7を作成した。
表6と表7に関わってハンドホール蓋上面と基準点真鍮鋲の関係を解説する。LiDAR測量では基準点の真鍮鋲はハンドホール内にあって測量プロセスの観点から直接には測量できない。そこで基準点の高度として，真鍮鋲ではなく，ハンドホールの蓋上面の高度を使用する必要がある。LiDAR測量結果の点群数はたとえば図Wでは429,321点に及ぶので，たった4点の基準点の高度を変更した方が適切なのである。そのため，表6の「”reference entities” csvファイル出力用」に真鍮鋲とハンドホール蓋の高度関係を組み込むことになる。
6 さて，align実行の下準備は完了した。LiDARルート測量結果クラウド（IsimaruOct26-2024byScaniverseLiDAR）と表6の最後の3列からなるcsvファイル Ishimaru5points_revised.csvをcontrolキーで同時に選択して，tool > Registration > Align (point pairs picking)，またはトップのツールバーの左から9番目のアイコンをタップする。
図XではSelect aligned entitiesのパネルでIsimaruOct26-2024byScaniverseLiDAR – Cloudを選んでいる。そして，OK。
次に，aligned entities （クラウド上で基準点対応点をあらかじめ求めた表7の5点）のまずは第一点A0を入力する。コンソールにはそのA0点が表示される。
次にはreference entities（基準点に蓋上面からの真鍮鋲までの深さを足したZ’値を反映した表6の5点）のA0に対応するR0をまずは入力する。同様にA4, R4まで入力したのが図Zである。alignボタンをタップした結果が図Zである。
図Zは図Aの3-61地点付近を拡大表示している。R4とR0は同じ位置に重なっている。A0はこのルート測量の出発点で，A4は終着点であり，いずれもR4(R0)基準点であった。できれば，A0とA4を一致させたかったが，難しいと考え，aligned entitiesのA4とreference entitiesのR4を表右手の❌をクリックして削除した。その上で，alignボタンをタップした。その結果が図AAである。
☑️した結果が図BBである。RMSが見える。A点とR点がこの画面でほぼ近いことが見える。
図CCはこのアラインメントを終了した後の表示である。この図は図AAとほぼ一致している。この程度の処理で筆者の目的からすると十分である。緑色のPoint #付きのアイコンはクラウド上のピッキング記録であり，そのそばにある黄色の四角はレファランスの基準点である，ペアで最も近接しているのは⑥3-40であり，最も離れているのは，Point #4と3-61である。3-61で最初に利用した①のPoint #0は，#1, 3とほぼ同様の距離である。
以上，2024年11月2日。
6.b Labels 1〜4の平面直角座標系座標値を求める
前節では，基準点3-61, 3-42, 3-40, 3-41の4地点とそれらを通過するLiDARルート測量を実施し，LiDARルート測量結果の点群point cloudをグリッド座標系に載せた。その点群上のLabels 1〜4をCloudCompareのpoint list pickingツールを利用して，グリッド座標値，つまりは，平面直角座標系6の座標値を求めることになる。LiDARルート測量の際には前もって，打越池南縁のプロムナードにあたるDOIに，Labels 1 to 4の4点のラベルを設置している。それゆえ，この点群には，4ラベルが記録されているのである。
ルート測量の際に早足で歩いたために，点群密度はDOIのスキャン作業結果と比べてかなり低くなっている。4点個々のラベルとその付近では立ち止まってスキャンしていたが，ラベルが小さいこともあって，点群では設置場所を特定できなかった。それゆえ，メッシュ系のFBXを観察してラベルの位置を特定し，点群と対比して点群上でも特定することができた。
FBXのコンソールでの表示は，ラベルが明瞭に見えるところまでズームインし，スクリーンショットを撮り，その後，ズームアウトして，さらにスクリーンショットを撮影した。FBXの像とPLY点群の像のアウトラインはかなり異なっているので，ズームアウト像は必須である。
この経験からの反省点を次に挙げる。ラベル紙は7cm弱四方でクラウドで見るには小さすぎた。ラベル用としては，A4用紙の短辺23cm四方が適当かもしれない。その上でラベルとその周辺のスキャンに時間をかけた方が良いようだ。このような反省点はあるが，DOIでのラベルの平面直角座標系6の座標値は図DDのように得ることができた。
図DDの右上のpicking listの#番号は5〜8になっている。前節での作業を継続させたためである。
次の表8にはこの作業での結果をまとめている。平面直角座標系6での作業では，座標は（Y, X, Z）であるが，CloudCompareでのグリッド座標系では，図DDの表にあるように，(X, Y, Z) になっている。
前節では，4基準点を使って（スキャンに含めて），LiDARルート測量結果である点群をグリッド座標に載せたのであるが，DOIでのLiDARスキャン結果はこの4ラベルを使って（スキャンに含めて），点群をグリッド座標に載せる必要がある。
7. 点群からメッシュにむけて
ここでは，国土地理院の基準点成果を利用して，調査フィールドDOIのLiDAR測量結果をグリッド座標系に載せる手法を示した。LiDAR測量の結果の景観再現性は，外観的には点群よりもメッシュの方が良い場合があるが，CloudCompareではver. 2.6以降，メッシュFBXの場合もこの種の手法が可能となっているが，異なる座標系での作業を試したことがなかった。マニュアルにもその実例はない。
点群の平面図（Set top view）は，測量を実施した場の平面図と一致しているが，メッシュでは正面図（Set front view）の裏返し 3D image flipping が点群の平面図と対応している。そのため，pickingして表示される座標値は，(X, Z, -Y）になっており，基準点座標との関係を求める場合，注意が必要だと思うが，挑戦して，さいわい成功した。
以上，2024年11月2日。
7.1 メッシュと点群の座標軸の違い
点群は感覚的によく合っているが，メッシュは開いたところがSet top viewにあたっているが，正面図だ。
Set top viewにすると，図FFのように，平面図になる。
裏返したのが図GG。右下の座標軸を見ると，水平右方向がX，水平下方向がZ，そして垂直方向がYだ。
点群とメッシュの比較をするために，図Aの各基準点対応のメッシュ座標値をPoint List Pickingしてみよう。Point #1 to #4だ。図Aの，①，④，⑥，⑦，①だ。図819〜823を見ると，ハンドホールがはっきりと見える。点群と全然ちがう。
7.2 メッシュ上でのPoint List Picking
Point List Pickingの結果はcsvで出力した。その結果を表9に示すが，前述のように，点群 (Y, X, Z’)は，メッシュ (Y, Z’, -X) になっている。鬱陶しいだろうが，表6も追加したものを次に。
7.3 アラインメント align (point pairs picking)
メッシュentitiesと基本基準点 entitiesとの対応関係をとることになるが，点群 (Y, X, Z’)と違って，メッシュ (X, Z, -Y)とする必要性がある。表9はalign entitiesであるが，新たに表10を用意した。これでアラインメントの準備はできた。これが正しいかどうかはやってみないとわからない。
図824でアラインメントの準備完了。コンソールに，A3, R3が見えるが，align entities，reference entitiesに，A0〜A3, R0〜R3が入力されたことを示している。
alignの結果を図825に。大成功だ。
RMS: 8.86だ。点群と同様だな。クラウドでの基準点位置極めは，メッシュの方が精度が高かったが，RMSはあまり変わらない。
図827ではalignの表は無くなった。
さて，ROIに4カ所の二次的基準点を設けるべく，Lavels 1〜4に，picking実施。点群ではラベルが見えなかったが，はっきりとその中心も見える。さいわいなるかなあ。
図833では，このmeshの座標軸の配列を理解するのにいいかと思う。コンソールの右下隅に,R(X)G(Y)B(Z)軸が見える。
表11では，平面直角座標系6の座標軸とメッシュの座標軸の対応関係を示している。
以上，アラインメント機能を使って，グリッド座標系（平面直角座標系6）とメッシュの座標軸との関係を明確にすることができた。メッシュを使ってこそ，基本基準点をROIに二次的基準点を作成することができるし，環境把握も妥当なものとなることがわかった。
以上，2024年11月5日。
