はじめに

　このタイトルのアップルブックを出版したいと思っている。まずは所属している大学の紀要に書き上げて，それを元にアップルブックスを出版したいと考えた。現役時代は所属大学の紀要に書く意味を高くは考えていなかったが，リタイアしてその意義はボクの中でより高くなった。この変化がぼく固有のものか，一定の賛同を得るのかはわからない。昨年はぼくの専門分野からかけ離れたテーマで投稿したが，今回はぼくの一応専門分野に入るテーマである。昨年のものはKindle本として出版されている。
記紀スサノヲの歌に隠されたレトリック — 日本タニハ文化研究所 (教養)

　このKindle本出版は，知人のKindle本出版に係わって鑑賞者の立場からボランティア活動をしたことがどうも契機になったようだ。Kindle本はテキストだけのコンテンツの発表には最適の媒体だと思うが，図や写真などは不適な媒体である。いわば絵本のような本はアップルブックスがいい。このフィールド科学云々のコンテンツには多数の図表や写真がある。お飾りではなくて，図などがコンテンツの中心となっている。こういうものにはアップルブックスがいい。

　まずは大学紀要に書くのはMicrosoft Wordということになる筈であるが，この過程を踏むと，アップルブックスのために仕切り直しをする必要性がある。その無駄を省くために，アップルブックスの作成ソフトPagesを使うことにしたい。そして，この過程を通じて，Pages（for iCloud）の利用にも慣れるだろうと思うのである。さらに，Pagesはテキストと図や写真などの配置も意識する必要があり，両プレースホルダのレイアウトを意識せざるを得なくなる。そうすると，だらだらと文章を連ねて行く泥沼を回避することができるのではないかと思うのである。なお，PagesファイルはMicrosoft Wordに変換できる。図表などはどういう形で崩れるかわからないが，図表などのレイアウトは出版社に指示すれば足りる。

　このポスティングはフィールド科学云々の本をこの方針で作成して行く過程で気付いたことをまとめて行きたいと思う。

以上，Apr. 4, 2023記。

１　iCloud.comにアクセスしApple IDでサインイン

　Pagesに用意されたテンプレートのうち，Apple Books (landscape)を全部参照して，シンプルさと構成が見易いと感じた，レポート：野生の象，を選んだ。レイアウトやコンテンツの変更に関する説明はないが，さわってみると，感覚的に実行できることを知った。幼稚園の子供こそ，すぐに使えるのではないかとも思えた。
　用意されたファイルを変更するのは，iCloud Pagesタブに戻って，…アイコンをクリックして，書類を名称変更，すれば良い。表紙の象さんについては今はこのままにしておく。
　ログアウトせず，放置しても，iCloudの接続が切れている場合は，その確認のアラートが出ることがある。上部ペーンには，サインアウトされている場合は，サインイン，が表示されているので，これをクリックすると，ユーザー名に替わる。当分，この形で使いたいと思うが。
　表紙の象の画像に替わるイメージとしては，iPhoneLiDARで測量して3Dマップが作成されるというようなものか。iPhoneLiDARからレーザーが出て，地表３Dを捉えている画像を作ればよいだろう。今盛りの八重桜をバックにしたらどうかと思う。

　Microsoft Word同様の，章などの見出しを意識して，ページを作成してゆく必要がある。ページ上のテキストを選ぶと，右のペーンに，スタイル，テキスト，配置，のタブが用意されており，テキストタブの最上部に，段落スタイルというのがあって，ここで指定してゆく。

２　アップルブックスのBookテンプレートなどは使えない

　勘違いしていたようだ。アップルブックスで公開するためには，Pages for iCloudのテンプレートではBookを使わないと行けないと。
　Book形式（図１）は，紙の本のように，各ページの文字数や枠組みが決まっている。しかも，いわばパワーポイントまたはキーノートのように，一つのコマでレイアウトを決める必要がある。しかも文章はページを超えて流れて行かない。図１では上段のページにテキストを流したが，下段のページには流れ込まない。
　動物図鑑とか，天文ショーみたいのだと可能であるが，ロジックを展開して行くのにはこの形は窮屈だ。完成後に出版社が本の形を編集する場合には可能かも知れないとは思うが，これも無理だ。
　用意されたテンプレートで，カタログ的でないテンプレートは何か。レポートや小説などか。図２はレポートの例だ。上段のページに流したテキストは下段のページに溢れて行く。まあ，Microsoft Wordのようだ。
　図１のBookテンプレートを使っていて脚注が入らないと悩んだが，図２のレポートのテンプレートの場合は，「脚注」が灰色ではなくて黒文字になっていて，脚注を入れることができた。この種の情報はネット上には無かった。なーんだ。Pages for iCloudがぼくのmac OS 10.12に対応していないためかと勘違いした。

　アップルブックスで，図や写真などを使えると思ったのは，ある意味，ぼくの勘違いであった。紙の本のようなレイアウトの場合に，図や写真が見えるということだ。デジタルの場合，大きな画面のパソコンでは，本そのままみたいなレイアウトをそのまま，見ることができるが，iPhoneなどの小さな画面では，Bookテンプレートのものは表示はできるが，見えなくて，部分的にピンチアウトして拡大して見ることになって，紙の本のようにはゆっくりとは見ることができない。

　繰り返すことになるが，アップルブックスの図や写真表示は，スマートフォンなどの小さな画面では，到底使い物にはならないということである。

３　キンドルでまともに図や写真を使うには

　スマートフォンで寝っ転がって読むためには，テキストはリフロー型に限る。アップルはそういう発想が中心軸にはなっていない。小説などは文字サイズの大小を決めることはできるが，文字の読みやすさでは圧倒的にキンドルである。キンドル万歳だ。とはいえ，アマゾンとアップルの比較であって，ぼくは日本人が以前から利用してきた青空文庫やbReaderなどが大好きだ。キンドルが特に優れているとは思えない。

　まあ，世界的観点ではキンドルがいいということになる。で，併せて，図や写真を比較的高い解像度で文書に組み込みたい，そして読者がストレス無く，閲覧できたらと思う。現在，世界に流布するKindle本はどうにも図や写真の解像度が低くて見るに堪えない。小さな画面のスマートフォンで，リフロー型のテキストを読み進めて，所々にある図や写真をストレス無く見る環境を提供したい。どうすれば良いのか。それをここでは考えたいというか，ネット検索したいと思う。

　この解決法としては，図や写真は自分のサーバーのコンテンツにリンクすればいいのだが，Kindle本同様，ネット環境が無くても，鑑賞ができるのがいい。

以上，Apr. 10, 2023記。

おわりに

　もう，おわりに，だ。日本のウェブ上には全く，キンドル本の図や写真をまともに使う情報がない。で英語コンテンツをあさっていたら，キンドルのBuild Your Book – Format a Paperback Manuscript に出会えた。これについて，ぼくの関心があるところを次のページに示したい。Build Your Book – Format a Paperback Manuscript from Kindle site

　今日，タニハに行くのは難しいなあ。まだ，高圧洗浄機が届かない。

以上，Apr. 11, 2023記。

　

はじめに

　ぼくは混乱状態になってきたので，ここで整理したいと思う。その上で，CloudCompareやMeshLabでのぼくの利用姿勢を正すことができる。

１　２セットの段ボール三箱と神武天皇遙拝所碑のLiDAR撮影

　この章は全く自分用の覚え書きである。3Dデータの欠損をMeshLabを使って穴埋めする　で示したように，MeshLabへのメッシュOBJの読み込みの際に，ファイル名に注意を払うべきことに気付いた。ファイル名内に空白spaceを入れてはならないことである。2バイト文字日本語も入れない方が良いとも考えている。
　図１には，二つのファインダーが見える。Wikipediaによれば，「ファインダー（英: finder）は、カメラにおいて撮影前に目で構図を決めたりピントを合わせたりするのに使用する覗き窓など」とある。そういえば，アナログカメラを使っていた時代にこのファインダーは自分の言葉として定着していた。macのファインダーの名称はここから来ているんだなあ。今更の気付きだけど。
　このファインダーの左部は，2023年1月11日に撮影したものである。OBJファイルだけは1月25日の日付があるが，これはMeshLabへのOBJ読み込みが出来ず，iPhone 12 ProのScaniverseで名称変更をする必要性があって，出力し直したためである。OBJ以外についてはファインダー上で直接，修正した。
　この1月11日の撮影は1月7日にMetascanでの撮影結果に愕然とした結果である。1月7日にMetascanで段ボール三箱と神武天皇遙拝所碑を撮影したが，いずれも線分を表現できず，がっかりして，次点候補だったScaniverseに望みを託したからであった。そしてScaniverseがMetascanと比べると遙かに線分の再現性が高いことを実感した。その結果が左のファインダーなのである。Metascanで取得したものは線分が歪んでいるので，表示対象にしなかったので，Metascanの出力ファイルは無い。
　で，右のファインダーのファイルは1月26日に撮影をし直したものである。上記の学習のゆえに，ファイル名は英数字のみにし，スペースも排除している。ただ，Metascanで撮影したファイル名は，metascan_20230126_1536_ぼくの命名，となる。記録する上でこの接頭辞は邪魔ではないが，ぼくの命名自身に含まれている内容なので，ぼくの命名法をMetascanについては変更した方が良いと思われる。その変更結果を図２に示したいと思う。
　図１の左のファインダーを見ると，Scaniverseによる出力ファイルは，メッシュ（OBJ, FBX），点群（LAS, PLY）である。LASについては，iPhoneでも使えるようになったLiDARの標準ファイル形式「LAS」ってどんなデータなの？を、PDAL/Laspyを使って調べてみる。で解りやすく説明されているが，ぼくには今のところ不要で図２では削除している。
　図１の右のファインダーを見ると，どうもエキスポートしたあとで，ファインダーで各ファイルを個々のフォルダーに整理したようである。図１の左のファインダーでは整理されていないが，実はmouseWindowsでは同様に整理している。CloudCompareでの作業ファイル群の名称が単純で元ファイルとの関係がわからなくなるために，iPhone 12 Proからエキスポートされたファイルを個々のフォルダーに入れる必要があった。その経験を踏まえて，macのファインダーでその作業を実行したのである。図１の右ファインダーでは上から見ると，段ボール三箱では，Metascanによる，メッシュOBJ，点群PLY，Scaniverseによる，メッシュOBJ，点群PLY，神武天皇遙拝所碑では，Scaniverseによる，メッシュOBJ，点群PLYが見える。神武天皇遙拝所碑については，1月7日にMetascanでLiDARと写真測量を丁寧に実施し直線の復元ができなかったので，実施しなかった。このファイルをmacにダウンロードしているかどうか，確認すべく，metascan_2023_01，で検索したがこのファイルは見つからなかったので，iPhone 12 ProのMetascanのライブラリーを見て，本日には，一応ダウンロードすることにした。というのは，Jan. 30, 2023でProが更新日で，回避したいからである。

　さて，今後のファイル名の構成は次の形が適当か。現場での命名のあと，インドアでmacに保存する際に整理すれば良い。現地では難しいが，ローマ字でもいいから英数字で揃えた方が良いだろう。
形式１：　[日付230138]+[テーマ3carton]+[3d-app(+LiDARorPhoto)]+[試行回数_4]
形式２：　[テーマ3carton]+[日付230138]+[3d-app(+LiDARorPhoto)]+[試行回数_4]
　形式１と形式２の何れがいいか。調査地では何らかのテーマがある。同日に異なったテーマでスキャンすることも当然ある。同じテーマで調査日が大きく離れる場合もある。パソコンで分析する場合に，最も有効なファイル名称は何だろうか。ファインダーまたはブラウザーでの操作だけでなく，CloudCompareやMeshLabの読み込みも考えた方が良いだろう。というわけで，形式２を採用したい。なお，一連のファイルを検索する際には上位カテゴリーとして日本語を入れた方が良いだろう。ファイルのパスで２バイト文字が介在する場合，現在の欧米のソフトは文字化けはしないのではないか。CloudCompareとMeshLabについては問題が無いように感じている。そこで，形式２の関連ファイルを，神武天皇遙拝所碑と段ボール三箱に入れ込んだ方が良いだろう。

　で，何とかmacのファインダーでファイルなどの名称を変更したが，特にOBJファイルセットについては動くかどうか心配である。同じ内容のものを一つはMac_Win_Sharedフォルダーに入れ，フォルダー名を直方体撮影ファイル名再構成forMeshLabとした。もう一つはmouseWindows10のmoto > Documents > win_moto_documents > win_3d_scan，にコピーし，フォルダー名を直方体撮影ファイル名再構成forCloudCompareとした。
　というのは，CloudCompareで操作過程で生まれたファイルと，MeshLabの操作過程で生まれたファイルを区別するためなのだが，同じファイルをCloudCompareとMeshLabで表示してみて，同時に比較したいということがある。CloudCompareはmouseWindows10で，MeshLabはWindows10 on Parallels Desctop of macで操作する。実際にやってみて，どうなるかはわからないので，今後変更する可能性がある。macのファインダーでの「直方体撮影ファイル名再構成」のファイル群のスクリーンショットを次に示す。

　さて，図２と３では，iPhone 12 ProのスキャンアプリMetascanとScaniverseについてまとめている。そして出力ファイルは，主にメッシュのOBJと点群のPLYファイルに注目している。それをまとめたのが，次の表１である。

　ターゲットは神武天皇遙拝所碑と段ボール三箱である。神武天皇遙拝所碑については表１上段の４組のOBJとPLYがあるが，一般に最大値を示す赤字が見えるのはScaniverseである。ScaniverseのJan. 10とJan. 26の違いは，身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める の「図53b　Mesh Simplificationの説明」に示されている。Scaniverseの描く段ボール箱の平面の点群が少なくて，何らかの省略プロセスがあると考えていたが，まさにこのMesh Simplificationがデフォルトで選択されていた。そのため，これを解除してスキャンをやり直したのが，Jan. 26のデータである。objファイルを見ると，Jan. 10は526kBで，Jan. 26は21.9MBと大きな違いがあった。
　段ボール三箱の結果を見ると，objファイルの関係は神武天皇遙拝所碑と同じであるが，plyファイルでは神武天皇遙拝所碑とは違って，逆転して，Jan. 26の5.6MBに対して，Jan. 10は21.6MBとなっている。何故なのか，わからない。

　そこで，点群数などターゲットの再現性を，CloudCompareとMeshLabで閲覧して，確認したいと思う。なお，スキャンの密度などはその時のぼくの心身の感覚も関係するが，とにかく，アプリで表示される像に従っているのであって，およそ恣意的ではないと思う。

以上，Jan. 30, 2023記。

３　CloudCompareとMeshLabによって3Dスキャンの再現力を見る

３.1　ScaniverseのMesh Simplicationの解除前と解除後の比較

最初にチェックしたいのは，ScaniverseのMesh Simplicationの解除前のJan.10のものと，解除後のJan. 26のものである。点群PLYとメッシュOBJについて求める。

a　段ボール三箱の点群PLY　解除前Jan.10

　すでに掲載したものであるが，改めてWindowsのCloudCompareで表示した（図４）。回転して上下逆にしている。面の大きな穴からバックの紺色が見える。Cloud > Points 1,437,942。

　

　次に同じファイルをmacのParallels Desktop上のMeshLabで見てみる（図５）。図４とほぼ一致している。当然ではあるが。右ペーンの上のProject 1の枠内のファイル名左端の小さな▶をクリックすると，File, Verticles, Facesが現れる。Verticlesの数値は図４と一致している。

b　段ボール三箱の点群PLY　解除後Jan.26

　解除後のPLYを見てみよう。CloudCompareに限定する（図６）。このJan. 26撮影PLYは，Cloud > Points 376,363とあり，Jan.10撮影のものに比べて点数が四分の一にまで低くなっている。Mesh Simplication解除後の方が点群の数が小さくなっているのである。この逆転現象はもちろん表１のファイルサイズで予測されたことである。この結果はScaniverseのプログラムバグに間違いはない。大きな問題だ。

　表１のように，神武天皇遙拝所碑の結果では，この逆転現象はなくて，Mesh Simplication解除後の方がファイルサイズがかなり大きくなっている。ターゲットの材質に拠るものとしか考えられない。

　この段ボール三箱に戻って，図６を見ると，図４，図５同様，点群の大きな穴が空いている。段ボール箱の配置はJan. 10とJan. 26でほぼ同じにしており，身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める の図38などと同じ場所で大きな穴が発生している。同じ段ボール箱に生じているのではなく，室内の光と影の位置から生じたものである。最も影の濃い面で生じている。前掲ページの図36での右手の面に対応している。奥方向と手前方向そして左手の面にはそれぞれ自然光が入る環境で，この大きな穴が生じた右手の面だけは自然光が最も入り難い場所になっているのである。

c　神武天皇遙拝所碑の点群PLY　解除前Jan.10

　このファイルはすでに見てきたものである。Cloud > Points 59,246。

d　神武天皇遙拝所碑の点群PLY　解除後Jan.26

　図7と図８に，PLYを表示している。図7では碑の前面の「神武天皇遙拝所」の文字がしっかりと読める。しかし，図８は碑の後面にあたるが，ここでは点群がかなり不足していて前面の碑名が透かして見えている。
　結果的には，スキャン密度が足りなかったということであるが，スキャン（中サイズで距離2.5mまで）に要した時間は5分間であったが，ProcessingはDetailを選ぶことができた。5分間を超えると，Detailを選ぶことができずAreaという中間的な解析手法になってしまう。保存前にEditで，Exposure 20, Contrast 53, Sharpness 35, no filter，を選択した。保存したのはスキャンが終わって3分後であった。

　これまでの経験から，5分リミット（5分間を超えるとdetail processingが出来なくなるというリミット）に規制されると，まともなスキャンができないということになる。Scaniverseは，Metascan (Pro) のように10分間までしかスキャンできないという強面ではない。とにかく，また，この神武天皇遙拝所碑，をScaniverseでスキャンせざるを得ない。図8では碑のトップが取得されていないのだけど，これまでの経験を踏まえて，繰り返し，頭の部分を腕を伸ばして，繰り返しスキャンしたはずなのである。
　とにかく，じっくりとスキャンしないと行けない。どうしても後面のスキャン不足はこの付近の足場が狭く，無理な姿勢でスキャンする環境が響いているようである。情けないが，寒かったこともある。この冬一番の寒波（当時マイナス2℃ぐらいに過ぎないのだけど），という日であった。

e　メッシュOBJのファインダーでの名称変更はNGだった

　恐れていたことが起きた。OBJファイル関連ファイル群をmacのファインダーで名称変更したが，それはNGであった。ファイル名はファイル内に書き込まれていて，ファインダーやブラウザーでの変更を受け付けない。Scaniverseは現在，Proであっても無料なので問題無いが，Metascan Proは月単位の契約にしていて，Jan. 30に終わっている。

　次の図9と10にその読み込みエラー表示を示した。そのため，iPhone 12 ProのScaniverse内で名称変更を実施しAirDropでmacにdownloadした。そして共有フォルダMac_Win_Shared中の古いファイル群を削除しこの新たなファイル群を移動した。さらにmouseWindowsについても既存フォルダを削除して新たに修正版をコピーした。この新たなフォルダ中のmetascanによるOBJファイル群はすべて削除した。名称変更前のmetascanのOBJファイル群はWindowsに残っていると思う。

f　段ボール三箱のメッシュOBJ　解除前Jan.10

　ScaniverseによるメッシュOBJファイルには全く穴が見られない（図11）。写真のようだ。左ペーン上段のDB Treeでのvetticesにチェックを入れてPoint size = 3としたのが，図12である。図11，12の段ボール三箱の左手の段ボール面には画像的には全く穴が無いが，図12のpointsの分布を見ると，点群PLYと同様，空白になっている。Cloud > Points 75,567となっている。同スキャンでのPLY出力（a，図4）を見ると，Cloud > Points 1,437, 942，であり，このPLYはOBJの19倍もある。
　そして，点数の多いPLYであっても，段ボール三箱の表現に大きな穴が生じているのである。線分に境される立体，言い換えると平面からなる立体の表現には，メッシュ形式が圧倒的に優れていることを知るのである。
　CloudCompareでは，計算機能は点群に対して優れているので，このメッシュを点群に変換した方がいいかも知れない。そういう能力はMeshLabが優れている。その方法は一般に知られているので，後日，実施したいとは思う。とにかく，平面からなる立体の点群を生み出すのは困難を極めると言えるだろう。

g　段ボール三箱のメッシュOBJ　解除後Jan.26

　Mesh Simplication解除後の方は，ファイルサイズがかなり大きくなっている。段ボール三箱の表現が明るいのは，iPhone 12 Pro内でのEdit作業の結果だろうから，その面から比べるのは違うと思う。ただ，図14のverticesの表現はかなり白っぽくなっていて，点数が増加したように見える。解除前は，Cloud > Points 75,567，この解除後は，236,214とあるから，3倍余りになっている。
　とにかく，メッシュファイルの表現力は圧倒的に凄い。

h　神武天皇遙拝所碑のメッシュOBJ　解除前Jan.10

　解除前の神武天皇遙拝所碑を図15,16に示している。メッシュobjを開くと，materials, Texture coordinates, verticesのチェックが可能だが，表示としては，前二つは関係がない。Cloud > Points 4644，と少ない。

i　神武天皇遙拝所碑のメッシュOBJ　解除後Jan.26

Cloud > Points 169,986と多い。解除後のPLY（d 図8）とは違って，後面の画像もあり，穴は空いていない。奇妙な感覚に囚われる。

おわりに

　ここでは，Metascanについては述べなかったが，すでに述べてきたように，直方体を対象にする場合，使いものにならない。これ以上，述べる必要性は無いかと思う。この直方体からなる段ボール三箱と神武天皇遙拝所碑を通じて，Scaniverseが圧倒的に優れていることがわかった。Metascanのように10分間という使用時間の制限も設定されていない。
　いわば人工的な直方体とは違った自然物についてのMetascanの能力はすでに求めているところであり，Metascanを完全に否定するものではない。Scaniverseには写真測量の機能がなく，その点でも200枚という限定はあるが，Metascanは捨てきれない。
　3Dファイルのうち，汎用性の高いものは，メッシュではOBJ，点群ではPLYであるが，ターゲットの表現力は圧倒的に，メッシュのOBJである。点群の分析ツールとしてCloudCompareが優れていて，できればメッシュではなくて，点群ファイルが欲しいところである。
　これをテーマの一つとして，3Dデータの欠損をMeshLabを使って穴埋めする に戻りたいと思う。
　

はじめに

　iPhone 12 ProのLiDAR機能を使って3Dファイルを得て来たが，CloudCompareでまずは体積や面積を求めるというような言わば幾何学的空間分析での基礎的な作業の際に，3Dデータの欠損に基づくエラーには悩まされてきた。そして，単に体積や面積を求めることよりも，3D空間データの位置の信頼性そのものも気にかかるところではあった。
　この種の問題を解決してくれるであろうMeshLabに本日出会った。他の用件もあるけど，大きな関心があり，ちょっと触ってみた。

１　始める前に

　MeshLabは，3Dメッシュデータ用ではあるが，点群ファイルにも使うことができるらしい。読み込み対応ファイルのうち，ぼくが使うiPhone 12 ProのアプリはScaniverseとMetascanで，これらのエキスポートファイル形式との関係では，MetascanのメッシュデータではSTLとOBJ，点群データではPLYとXYZ，ScaniverseのメッシュデータではSTLとOBJ，点群データではPLYに限られる。何らかの作業が終わって出力する形式はCloudCompareの利用を考えると，メッシュデータではSTLとOBJ，点群データではPLYに限られる。
　MeshLabアプリは，https://www.meshlab.net/ から提供されており，最新のものは MeshLab version: 2022.02　28/Feb/2022であり，mac，Windows64，何れにも対応している。さきほど何れにもインストールし，何の問題も無かった。同梱のRead.meには次の但し書きがある。

　さて，操作マニュアルを調べてみた。
MeshLAB Tutorial ここには，はじめに，Cloud Compare:
Point cloud and mesh editor，MeshLab
Point cloud and mesh editor，とあって，ネット上では，meshファイル対応と流布されているが，点群のPLYファイルが重視されている。
MeshLab Documentation November 13, 2017 | Author: Lucy Sharp | Category: N/Aこれは，2017年発行でPDFの形でダウンロードできる。ほとんど図が無くて覚え書きのような印象である。

追記　Jan. 27, 2023：　School of Design, Faculty of Liberal Arts and SciencesのMeshLab: Point Cloud to Mesh の情報はpoint cloudをmeshに変換するためのMeshLab使用の注意点を学生に示したものである。一般に3Dスキャナーで得られたpoint cloudの点数は膨大のため，その前に軽量化せよという。iPhone 12 Pro LiDARを使うボクには全くあてはまらない。ただ，MeshLabがそういう使い方のためでもあると理解できたのである。File > Import mesh，のコマンドは，そういう訳で，point cloudを当然含んでいることになる。そして，そのあと，mesh出力が可能なのである。point cloudファイルはここでは.ascなので，三段階の処理が必要になる。ぼくの場合の3Dスキャン結果の出力データはplyファイルなので，この必要は無いと思うが，図2のOBJファイル表示を見ていると，メッシュファイルであっても，faceの裏表が不揃いなので，plyファイルについてもこの三段階の作業は必要かも知れないと思う。そこで，一応，上記サイトの情報を次にコピペしておく。上記サイトには図も掲載されている。

Once it has imported successfully then you need to do three operations:

1. Compute Normals:　（メッシュの三角形面faceを作成するために必要な法線の作成）
Filters > Normals, Curvatures and Orientation > Compute Normals for Point Sets
– Accept the default settings by pressing Apply. Wait

2. Optimise your point cloud:　（これはpoint cloudの膨大なpoint数を縮減するための操作でぼくの場合は不要か）
Reduce the density of the point cloud by choosing
Filters > Point Set > Point Cloud Simplification

　このPoint Cloud Simplificationのパネルについて，
In the “Number of Samples” field pick somewhere between 100,000 (quicker, less detailed) and 1,000,000 (slower, bigger but more detailed). Click Apply. Wait.
　You will now see two versions of your point cloud scan – the original and the reduced version.
　この画面の説明として，You can switch them on and off (like Photoshop layers) in the right hand panel. Also you can drag the point size lower to get a clearer view of your scan.

3. Convert the optimised point cloud to a mesh:　（点群をメッシュに）
Click to turn off the original point cloud, leaving just the optimised version on and selected. Then Choose
Filters > Remeshing, Simplification and Reconstruction > Surface Reconstruction: Ball Pivoting
Accept the defaults and select Apply. Wait – potentially for a while.
After the process is complete you will then be able to view your mesh – if it is too poor quality you could try again by optimising the original point cloud with a higher sample count.
When you are happy with the result export the mesh using
FILE > EXPORT MESH AS
and choose an appropriate file type – OBJ would be suitable for bringing into Rhino, Blender, 3DS etc
NOTE: when you bring your mesh into your 3d application there may be “back to front” sections; in Rhino these will show up as darker patches.
To unify these normal, issue the command
UnifyMeshNormals
and select everything. This will flip all back to front faces in the same way.

　なお，Rhino, Blender, 3DSなどの嗜好を知るのに，【2021年】3DCADとBlenderは違う～3Dモデリング検証編 は参考になるかもしれない。ただ，ぼくはこの分野には全く関心がない。

２　メッシュファイル OBJの読み込み

　mouseのWindows 10にイントールしたMeshLabを立ち上げて，ScaniverseでLiDAR撮影した段ボール三箱のOBJファイルを読み込んだ。メーンメニュー File > Import mesh を実施したが，まともに読み込めない。右のペーンの下部に，赤字でエラーメッセージがある。

　ネット検索して，SOURCE FORGEのMeshLab Discussionで，たぶん原因を見つけた。

windbrand – 2012-05-18

Hiya,
I tried to import and obj model (sleeveless top) in meshlab, however it gives
this error: “Error details: some materials definitions were not found, a
default white material is used where no materials are available”. The model
imports correctly but like the error says there is no material, it’s just
blank. All my material files are there, I even tried to copy over all the
files into the same folder as the .obj file. Does anyone know what might be
causing this?
Thanks.

Giulio – 2012-06-05

Try this, it worked for all my .obj with the same error. Seems that Meshlab
doesn’t allow spaces in the name of the files.
Rename texture, .mtl file, .obj file without spaces. Open with wordpad o
notepad .mtl file and .obj file and at the beginning change the name of the
texture and of the .mtl file. Open .obj with meshalb again!

　CloudCompareでは日本語のファイル名には何の問題もなかったが，MeshLabでは問題が生じるのであろう。図２のメーンペーンの下縁の紫色の中央に，ぼくの日本語「段ボール箱」を含むファイル名が文字化け無しで表示されている。元のファイル名は，段ボール箱scaniverse_Jan10＿2complete.jpg, .mtl, objである。an10＿2completeの，＿も気になるところである。carton_scaniverse_Jan10_2complete.jpg, .mtl, .objと変更した。ブラウザーではこの変更は見えるが，MeshLabで何回か，読み込もうとしてもファイル名の変更が実現しないので，Windowsを再起動するなどした。そして，開いたのであるが，図次のようなメッセージが出ている。奇妙なことに，objファイル名は変更したものと一致するが，jpgファイルでは段ボール箱が残っている。

　　そこで，共有しているmacでzipファイル名を丸ごと替えることにしたのであるが，これを解凍すると図４のようであった。図４でハイライトがあるcarton_scaniverse⋯⋯⋯⋯⋯.zipを解凍すると，この直ぐ上のファイル名になるというか，替えたzipファイル名が全く反映していない。
　それゆえ，Scaniverseに格納されているファイルに戻って，ここでファイル名を替えて，エアドロップでmacに移動して，解凍して，Windowsに移動した。macからWindowsのこの関連ファイルを削除しようとしたがどうしてもできなかった。Windows内のファイルはWindows内で削除しなければならなかった。スクリーンショットの場合と異なる形だ。
　そして，MeshLabを立ち上げて，File > Import Mesh，を実行して，図５のように，問題無く，読み込むことができた。

　なお，ファイル名に日本語が入っていたのが原因かどうか，わからない。Windowsが，ファイル名にFEPの関係か勝手にスペースを入れていたようで，スペースが原因の可能性もある。図4では，「_ 」の代わりに「＿ 」が入っているが，Windowsで見ると，「⋯⋯Jan10 _ 2complete.obj 」とか，なっていたし。

以上，Jan. 26, 2023記。

３　CloudCompareのファイル名書式の確認を

　図５の絵作りは見事なものであった。どこにも穴が無い。後に示すがMeshLabでこの図５のファイルをwireframeやFace表示したが，ホールが見つからない。一体のunitで，ホールholeを検知detectして，それを表示して，手作業である部位についてはキャンセルなどして，一気に穴埋めする，というようなプロセスをGitHubなどで検索したが，そういう質問はあっても回答は全く無い。ネット上にはそういう役立つコンテンツが無い。昨日，半日ぐらい，英語サイトを中心に探したがみつからなかった。公式マニュアルもリスト的で役に立たない。MeshLabのプラグインリストでpythonのディスクリプションは見つかったが，変数定義が見えないので，理解するのが困難だ。

　とにかく，ぼくとしては，少なくとも10年以上に渡って積み上げられ，無料で公開されているCloudCompareとMeshLabを使って，極めて極めて低次の希望を叶えることである。ぼくの希望は何だろうか。研究のツールなのだけど，高齢なので研究テーマも極めて限定的になる。とにかく，海岸地形の計測ということになろうか。その際にpoint cloudの欠損は問題になるものだろうか。大したことでは無いだろう。身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める で拘った体積計算も，point cloudファイル情報の精度とCloudCompareの能力を知りたかったからであった。実は，体積そのものにも，研究的な関心がある訳でも無い。ぼくの性癖に由来するものである。ぼくが幾何学やpythonの高い素養があればこの泥沼に入ってしまうのだけど，幸い，そういう素養が無いので，助かっている，と切実に思う。

　さて，そういう訳で，iPhone 12 Pro LiDARで得た3D point cloudやmeshでみっともない欠落などがあった場合，自然界のものなので，そもそも簡単に補修できるものではない。欠落部分が研究の観点から重要な場合，アプリなんかでは，補修できない。現場に行って，3Dスキャンして取得するしかない。と考えると，point cloudやmeshの穴や破れが補修の対象になるのはかなり特殊な目的に限定される。この例が体積や表面積の計算であった。まあ，ぼくが何を求めているのか，都度確認をしないと行けない。

　本章のタイトルのテーマを含めて，新たなポスティングを作成した方がいいと考えた。それは，
iPhone-LiDAR + Scaniverse or Metascanから書き出された点群とメッシュを比較
である。

以上，Jan. 27, 2023記。

　次の章を当初は，「MeshLabでメッシュOBJを点群PLYに変換する」としていた。どうもこの考え方には根本的な問題があるようだ。Can I generate Point Cloud from mesh ? を読んで何となく理解できた。ぼくはmeshからいわば均等のpoint cloudが作られると考えた。その発想が根本的に誤りだった。
　MeshLabでの作業として，点群point cloudからメッシュを作るのが妥当だとすると，ぼくからするとiPhone 12 Pro内のアプリで3Dスキャンした後，点群PLYとしてもメッシュOBJとしても出力できるので，MeshLabは不要ということだ。すでに 元伊勢大饗石のLiDAR測量 では，CloudCompareで，点群からメッシュに変換し，さらにこのメッシュから点群に変換しているので，この後半のプロセスを実行すれば良い。
　そして，MeshLabを使おうと思った動機を思い出した。点群の欠損を探してそれを穴埋めすることだ。でも点群PLYで得られる像がメッシュOBJ に比べてより不完全ならば，メッシュOBJを使うことになる。

以上，Jan. 31, 2023記。

４　MeshLabで欠損を探す１

　MeshLabを立ち上げて，File > Import Mesh，で，段ボール三箱のScaniverseで作成したobjファイルを開く。それが図５になるのであるが，最新のJan. 26のものをまずはここでは使いたい。メッシュの欠損の存否を見たい。

　メーンメニューのすぐ下には，図６のように，ショートカットアイコン群が並ぶ。アイコン群16（Draw XYZ axes in world coordinates）をタップすると，XYZ軸が現れる。XYZはそれぞれRGB三原色の軸が使われており，右手座標系（デカルト座標系）になっているのがわかる。ただ，重力軸はZ軸の筈であるが，Y軸になっている。この点，注意が必要だ。
　Nos. 10〜14の五個のアイコンは，左から，Bounding Box（境界ボックス），Points（点群），Wireframe（立体の辺だけから成るような線の集合で表現されるもの），Vert（vertices 多面体の頂点），そしてFace（多面体の面）が並ぶ。objを読み込んだ際には，この５アイコンのうち，右端のFaceだけが選ばれた状態であり，図７のように見える。押されたFaceをタップして解除すると，全画像が見えなくなる。

　図８はFaceの上にワイアーフレームを表現したものである。右ペーンにもツールアイコン群が並ぶ。この部分でもより細かな設定が可能である。No. 14のFaceのアイコンをタップして解除すると，図９のようにワイアーフレームだけが見えるのであるが，余りに密度が高く，その欠損部を探すのは個々の場所を拡大しても，難しい。

　なお，MeshLabのmouse操作は特殊で，Meshlab_Tutorial_iitd.pdf p.8に掲載されている。右クリックは何故か使われていない。ぼくの環境では機能しないものも幾つかある。興味深いのは１の機能で感覚的に理解しやすい。

NAVIGATION IN MeshLAB

1. Left mouse button + drag: rotate around trackball center
2. Mouse wheel: move forward or backward
3. Center mouse button + drag: pan
4. Shift + mouse wheel: change camera field of view
5. Double click on specific point: places that point at the trackball center
6. Control + mouse wheel: moves near clipping plan
7. Control + Shift + mouse wheel: moves far clipping plan
8. Alt + Enter: enter full screen mode
9. Control + Shift + left mouse button + drag: changes light direction (this
   only takes effect if there are normals)

　それで，欠損部（ポリゴン境界やメッシュの欠損部）を探すのに，境界や穴の表示 によれば， Filters > Selection > Select Border である。その結果を次の図10に示す。境界は赤線で表示されており，段ボール三箱を置いている絨毯のトリミングの四角形の四辺に限定されており，メッシュの欠損は無いということになる。

　次に神武天皇遙拝所碑の最新OBJを見てみよう。図11を見ると，点群plyでは頭は大きく欠損していたが，メッシュobjでは全く欠損が見られない。この図11は，Filters > Selection > Select Border ，を反映したものであるが，土台の切り取った部分にしか赤線は無い。

　最新のScaniverseで得られたメッシュOBJには欠損が全く無い，ということになるが。

以上，0:20, Feb. 3, 2023記。

５　MeshLabで欠損を探す２

　ところが，CloudCompareで Edit > Mesh > Measure volume，で，体積計算すると，consoleに，”The above volume might be invalid (mesh has holes)，となっていて，改善が見られない。表面積の方はそういうエラーメッセージは出ない。両数値とも悪い数値では無いが。
　MeshLabでの，Filters > Selection > Select Border，を使ったチェックが役に立っていないのである。ワイアーフレーム表示をして明らかな穴を埋める方法については，後に実行したいと思うが，今のこの問題をどうするかで，である。
　穴埋め関係の情報は，MeshLab Simple Mesh Editing に整理されている。Close Holesに関連して，max size to be closedのデフォルトが30になっているが，このmax sizeの意味が理解できない。このサイトでは，
Close Small Holes　Holes which are “small” with respect to the mesh size, possibly almost planar…
Simple filter: Remeshing, simplification and reconstruction->Close Holes
Parameters: max size to be closed (in terms of perimeter lenght)
とある。ここでmax sizeは穴の周囲長としている。が，現物をスキャンした者からすると，単位としてメートルを考えてしまう。段ボール箱などで穴が30mという最大値そのものに意味が無いので，実際に作業をしてみるしかない。

　そこで，まずは次のサイトを参考にした。MeshLab でメッシュの穴埋めを行なう。
１　ツールバー右端の検索場で「close」を入力すると，検索結果に「Close Holes」が見え，それを選ぶと，図12のように，Close Holesのパネルが見えるので，Max size to be closed: 30などデフォールトのまま， Applyする。そうすると，図13のようなFilter Failureが現れる。ここには，filter requires edge manifoldeness，と出ている。

２　逆引きMeshLab の，Filter (スキャンデータをきれいにする)，には，穴埋め欄の説明に，
Filters > [Remeshing simplification and Reconstruction] > [Close Holoes]
Manifoldのエラーが出る場合は事前に、Filters > Cleaning and Repairing > Remove faces from Non Manifold Edges，などを実施，とある。図14のように，現在のMeshLabではより改良されている。
Filters > Cleaning and Repairing > Repair non Manifold Edges

３　図17右下のconsoleには，Repair non Manifold Edges，が成功したことが示されている。”Successfully removed 15 non-manifold faces”である。
　そして，再び，図16のように，Close Holesを実行したのであるが，図17右下のconsoleには，”Closed 12 holes and added 20 new faces”，とある。なお，Close Holesは，
Filters > Remeshing, Simplification and Reconstruction > Close Holes，で実行される。

４　とはいえ，実行結果を見ることはできない。またCloudCompareで体積と表面積を計算してみたい。
File > Save Project As…，で，3carton230126scaniverse_obj \ 3carton230126scaniverse_obj_1.mlp，で一応保存した（図18）。
　このファイルではCloudCompareで扱えないので，File > Export Mesh，を実行したが，File > Export Mesh As…としなかったので，ファイル名称変更のステップは無かった。ブラウザーで探したら，元ファイルと同じフォルダーには，新たに，mtlファイルが作成されていた（図19）。図19の右端には，このMTLファイルの作成日（時刻）があり，2023/02/06 17:46（作業時刻と一致），となっている。

５　CloudCompareで，これを開いてみた。図20のように，チェッキングリストを全部外した3Dクラウドが図20のものである。RGB情報は全く失われている。そういうものであることを，ここで認識することができた。メーン画面の右下隅のXYZ軸を見ると，MeshLabでの座標系も鉛直軸方向も変わっていない。
　segmentして，Edit > Mesh > Volume, Surfaceを実行した結果が，図21のConsoleの最下行から上の4行に現れている。何と相変わらず，体積について，might be invalid (mesh has holes)が現れている。
　V=0.1287㎥, S=1.4542㎡，であるが，身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める の表４の実測値と比較すると，0.1287/0.1212 = 1.06，1.4542/1.4522 = 1.00，となっていて，正解と考えて良い。

　以上から，MeshLabでClose Holesを実行し，CloudCompareで表面積を求めるプロセスは，成功したと言えるだろう。

おわりに

　さらに，この後，明らかな欠損を埋めるプロセスをまとめれば，ぼくのMeshLab操作技術は向上することであろうが，一応，ここで終了したい。大きな欠損を埋めることはぼくには実は意味が無いことでもある。３Dプリンターを使う必要性もないし，カラー写真のようなRGBが自然に表現されている3Dイメージがぼくの求めるものであって，細々と触る必要性も無いのである。

　この結果に基づいて，大饗石のメッシュOBJを使って体積と面積を次に求める作業に入りたいと思うが，他のキンドル版出版の作業に入りたいと思っている。この体積計算に拘った切っ掛けは，大饗石の体積値が妥当かという問題意識からであった。

以上，Feb. 6, 2023記。

はじめに

　元伊勢大饗石のLiDAR測量 に続いて，このページを作成する。大饗石のCloudCompareの体積計算の妥当性を検証したいのである。
　その方法として容易に考え得るのは，スケールで計測可能な直方体の体積を，LiDARまたは写真測量，そしてCloudCompareで求めて，この手法の再現性を確かめるということである。
　近所で直方体を探したが，なかなか見つからない。墓石は近所に見られるが，避けたいところである。で，近所の為那都比古（いなつひこ）神社では，由緒も何も無い神武天皇遙拝所なるものを計測した。出直すつもりで，疲れて自宅に戻ったが，屋外は期待薄なので，狡（ずる）して室内で段ボール三個をまとめて計測することにした。
　以上の材料を使って，このページを作成してゆく。

１　為那都比古神社の神武天皇遙拝所碑

　さすが，式内社だけにトベラの大木がある（図１，２）と思ったが，この境内は必ずしも古い地ではないようだ。一般に，神社の境内は掃き清められていて，古さを感じないこともあるが，それにしても，この境内では神々しい感じがしない。なお，図１のトベラの葉の塊の中段付近には垂直方向に伸びるトベラの徒長枝（とちょうし）である。

　なんともわからないが，かつては医王岩（図４，看板が右下に小さく見える　ソース不明でネットから拝借）に係わって為那都比古神社の前身があったようだが。一度参拝したいと思う。自宅から徒歩で1時間ほどか。図３に見えるが，山麓線からバス路線「ルミナス箕面の森」への道に入ってすぐ右手の「あかつき特別養護老人ホーム」の看板がある交差点から入って，大宮寺観世音菩薩を過ぎると，医王岩参道入り口があって，そこから北に登ることになる。

以上，Jan. 7, 2023記。

追記　May 17, 2023：

　奥さんの見舞いに娘がMay 15に来たので，懸案だった医王岩に出かけた。そして埼玉に戻ったMay 17にも医王岩に再訪した。というのは，15日に撮影した医王岩が一枚岩では無くて，落石が基盤岩に載った構造のように見えたからである。ジョイントには惑わされるので，層理面についても，走向傾斜を求めた。ノートを忘れたので，読みは録音した。

追記図1, 2：　図１で右手の道路に進むと特養あかつき荘へ。図２は図１の左手の道を進むと辿り着くちょっとした広場である。右手の垂直面が医王岩になる。

追記図3, 4：　全部で４区分でき，足下，下半身，上半身，そして，首（顔），とも見える。首（顔）＝最上部には天狗の鼻のようなものも見える。しかし，これは冠か何かにして，上半身としたのが顔で，横一文字の割れ目から下が上半身と下半身になるのであろう。横一文字の割れ目を境に，下方は左上から右下に層理のようなものが見えて，上方では左下から右上に層理のようなものが見える，ようにも見える。全体が一枚岩か，それとも複数の岩体なのか。それが気になって，May 17に出かけたのである。自宅から20分余りで到着した。

以上。

追記　May 18, 2023：

　May 17の調査では紙を忘れてiPhoneの録音機能を使ったが，問題があって，駄目だった。
アップルのボイスメモを押してすぐにしゃべると，最初の音声が録音されていなかった。
なぜか，ずーとオンのままで，聞くに耐えない。
録音の時刻が自動に記録されると思ったが誤りだった。タイムスタンプが無い。いいソフトを探そう。

追記図5〜7：　追記図5とのジョイントは，N38ºE, 62ºE, N33ºE, 58ºE。図6のそれは，N38ºE, 52ºE。だいたい，この医王岩最下部の走向傾斜はこんなものか。

追記図8, 9：　層理面を確認した。走向傾斜は計測したがボイスメモに問題。層理の傾斜はほぼ垂直に近い。

追記図10, 11：　層理面を確認した。走向傾斜は計測したがボイスメモに問題。層理の傾斜はほぼ垂直に近い。

追記図12, 13：　両写真の最下部が，胴と顔の境界のジョイントになるのだろう。ジョイント面の山側には顔のブロックが消失している。

追記図14, 15：　消失している部分の面の走向と傾斜を測ったが，N62ºW, 20ºSか。再確認の必要あり。

追記図16, 17：　層理が明瞭だ。胴より上の顔の残骸の一部だろう。N10ºE，83ºEか？　要確認のこと。

　再調査，必要。層理面の走向傾斜が医王岩の<胴体最下部>でも，<胴体最上部>でも，<顔ブロック>でも，類似しておれば，同一岩体となる。要走向傾斜計測。今度は紙を忘れないように。蚊がもう出てきて，顔ブロック周辺の走向傾斜計測中には目の前で，嚼まれてしまった。

以上。

　為那都比古神社の違和感についつい，拘ってしまった。図５に神武天皇遙拝所碑を示す。この正面に立って拝む場合の方位はどうなっているのか。磁石としては最も信頼できるコンパスSUUNTOを使ってまずは土台に載せてみた（図６）。ほぼ北東を指す。ぼくのこの地の方向感覚からすると奇妙なので，この土台からコンパスを離すと（図７），正しく，東を向く。図７右部には，コンパスのエッジと碑の土台とはほぼ平行になっている。この花崗岩は，磁鉄鉱系列の山陰起源の可能性が高い。
　遙拝先として考えられているのは畝傍山の麓に明治になって造営された神武天皇陵なのか，伊勢神宮なのか，わからない。磁北から90ºの東方向に向かって遙拝する形なので，天皇陵にも伊勢神宮にも向いていない。

２　神武天皇遙拝所碑のスケール実測3D

　

３　LiDARおよび写真測量で得られたイメージの限界

　今回の実験で，LiDARも写真も，かなり欠陥があることがわかった。真っ直ぐの稜線の復元に大きな歪みが生じる。室内で段ボール箱３個を並べたもののスチール写真 still photo（図9, 10）を先に示す。

　この段ボール箱三個のLiDAR像を図11, 12に示す。真っ直ぐな稜線の復元力は，Metascan（図11）よりもScaniverse（図12）の方がある。しかしながら，図12の段ボール右下に大きなnotchが見える。Metascanでは取り込みに相対的に多くの時間（3分ほどか?）を要した。４回ぐらい周回している。Scaniveseは狙った段ボール箱三個はすぐに（数秒か）見かけ上，取得したのであるが，念のために周回している。狭い場所であることと照明が不均一であることがあり，LiDAR撮影の条件は良くはなかったが，それにしてもという結果であった。図12の最上部に示されている時刻は撮影時刻ではなく，iPhone 12 Proでのスクリーンショットの時刻を示している。撮影時刻は両図でほぼ同じ時間帯であった。

　次に神武天皇遙拝所碑を見てみる。図13はLiDAR測量の結果である。碑の周囲の石垣が表示されていないのは，碑にスキャンを集中したからである。かなりの時間を費やしてスキャンしたのであるが，神武天皇遙拝所の漢字はかなり歪んでいる。石柱の稜線は歪んでいる。このことから，予定外ではあったが，２周回して50枚の写真を撮影した。この写真測量結果については，自宅のWi-Fi環境でサーバーにアクセスして像を構築した。写真では歪まないであろうと期待したが，図13よりも図14の方がより歪んでいる。漢字は正しく復元されている。写真測量もまっすぐの稜線を復元するのは苦手らしい。
　一般にネット情報では，この観点は全く無い。単純な直方体の撮影を試みていないためであろう。

　Metascan，Scaniverse以外のアプリはどうだろうか。こういう疑問は生じるが，おそらく徒労に終わるであろう。すでにMetascanが屋外でのスキャンに最適であることは承知している。Scaniverseについては像の再現性や速度で優れているのであるが，スキャン中に，正しくスキャンできた場所とできていない場所の区別がMetascanより劣っていた。
　それにしても，この優れたScaniverseが全面的に無料なのは何故だろう。写真測量の機能が無くLiDAR限定ではあっても。で今使っているScaniverseの設定を調べてみると，Scaniverse Proというのが有料で提供されていたらしい。それを無料にするというメッセージが入っている。開発を諦めるのでPro契約の方からは今後は集金しないし，誰でも使えるようになるという。
　念のために，Scaniverseをアップルストアで検索して，インストールしようとすると，ぼくのiPhone 12 ProのScaniverseのSettingsの画面に戻ってしまう。この最下部には，2023 NIANTIC, INC. V2.0.3とあって，昨年このScaniversを買収した社名が表示されている。2022年9月付けのケータイWatchのニュースには，
　「これまでは、iPhone 12 Proシリーズ以降やiPad Pro搭載のLiDARを活用していたが、今回より、LiDARなしでも利用できるようになった。LiDARなしでも3Dスキャンを実現した背景には、ナイアンティックのManyDepth技術を採用したことがある。ManyDepth技術は、2Dの画像から3Dの奥行きを推測するというもの。カメラを動かしながらスキャンすることで、ニューラルネットワークが3Dを広げていく。」とある。

　WIDAR-3Dスキャン&編集，という日本製アプリがいま，ネット上で宣伝されていて，一応，インストール中。

以上，Jan. 8, 2023記。

４　直線の低い再現性について

　寝ながら理由を考えた。

１　段ボール箱の撮影は室内の隅で夜間に実施したので，距離と照明の問題が考えられる。そこで段ボールについては，明日Jan. 10, 2023に再試行したい。つまり，居間でスペースを確保して，明るい昼閒にMetascanとScaniverseを実施しよう。WIDARにもトライするかも知れない。

２　神武天皇遙拝所碑の撮影をもう一度したいと思う。Metascan によるLiDAR測量を前回はかなり近い場所から実施したので，トップの四角錐を除いては，台座に載らないで実施してみよう。Scaniverse，場合によっては，WIDARも使ってみるかも知れない。現場ですぐにチェックできるので，試行錯誤をしたい。

　今日Jan. 9, 2023，タニハの艮岩をScaniverseとWIDARでLiDAR測量した。次の図15〜18は艮岩の四面を撮影したものである。LiDAR測量の再現性を知る上で，この四枚の写真は重要である。MetascanででもLiDAR測量したかったが，WIDARがバッテリーを激しく食ったためにできなかった。

　WIDARでもスキャンした。WIDARの場合はLiDARと写真の選択があった。未だ検知していない場所は紫色で表示され，検知すると写真のような画像が現れる。最初はtextureが粗く表現され，時間が経つに連れて緻密になってゆく。この完成到達点を判断するのが難しい。Scaniverseだとスキャンした所を再度訪れても画像が残っているが，WIDARは画像が残っていず再度スキャンを始める印象であった。それゆえ13分間を要した。Metascanだと10分間で強制的に終了するがこのWIDARは強制的なシャットダウンは無い。このWIDARを終了した後，iPhone 12 Proがバッテリー切れの警告が出て，Metascanを使えなかった。WIDARを使う時には，特に予備のバッテリーが必須のようだ。
　出来上がったスキャンデータを見ると，Scaniverse同様，直線性の稜線を復元していた。ただ，croppingなど，撮影後の取扱が面倒で，艮岩についてはもう廃棄してしまった。
　明日の神武天皇遙拝所碑の撮影では，Scaniverseでうまく行かない場合，WIDARを使ってみようと思う。

以上，Jan. 9, 2023記。

5　Scaniverseが最高

　神武天皇遙拝所碑と段ボール三個の3D撮影の問題を通じて，Scaniverseの高い3D復元能力には驚く結果となった。最近発売されたWIDAR-SCANの宣伝とそのユーザー達の自己喪失した感想には多少引っ張られたが，全くScaniverseの敵ではなかった。WIDAR-SCANは日本製らしいのだが，最も肝心の再現性の技術力が弱いように思う。そして，フィールドでの3D読み込みの進行の評価の観点でMetascanが最優秀と考えてきたが，今回の経験から圧倒的にScaniverseに軍配が上がることがわかった。今後は基本的にScaniverseを使うことになるだろう。それをここで立証したい。

　とはいえ，Scaniverseが無料である点を調べてみた。Scaniverse is joining Niantic で見ると，今後さらに開発されてゆくことは確かなようである。現在，かつて有料だったScaniverse Proが無料で公開されているようだ。ぼくのように元々無料で使ってインストールしている場合，いわば自動的にProに替わっているらしい。今日も使いながら，使用環境に制限を感じたので，あらたに有料化されて制限を撤廃してもらいたいものだ。

　さて，今日の経験を次に示す。まずは室内の段ボール三個だ。図19〜22はstill写真だ。

　図23は，Scaniverseでスキャン開始した頃のスクリーンショットである。Scaniverseでは，iPhone 12 Proの最上段に時刻とバッテリー残量が継続的に表示される。これはスキャン経過を一つの画面で同時に見ることができるので，非常にありがたい。下段の赤丸の右手の‖マークは，pauseボタンである。ポーズを解除すれば，再開できる。「Range 2.5m」は，LiDARの到達距離であり，スキャン開始時に，medium objectを選んだ結果である（さらに調整できるが）。図23には，赤白パターンが見えるが，これはScaniverseが読み込めていない部分を示している。このあと右にスキャンを進める過程で，この赤白パターンは消えて行った。つまり，未読部分が解除される前でもスキャン箇所を移動しても良いということである。
　本日，この段ボール三箱の3Dスキャンについては，Scaniverseで二回実施した。一回目は失敗した。結果を見ると段ボールの歪みが残っていた。図12ほどではないが相変わらずnotchが残っていた。図23のように，居間を片付けて段ボール三個をその中央に設置したし，昼閒の明かりも居間に入っている。
　一回目では歪みが段ボールの最下部に近いところで強かったので，二回目ではiPhone 12 Proを逆さにして下部を真っ直ぐにスキャンできるようにした。斜め上からのスキャンがこのようなnotchを生んでしまうと考えたのである。その結果，図24のようにかなり改善が見られた。とはいえ，右手前の垂直稜線のうち，上部1/3が少しだけ凹んだように見える。対応部分の写真（図20）ではそのような凹みは見られない。他の部分は完璧のように見えた。ムーヴィーの提示は省略する。
　1 foot，つまり，30cmほど近づけても問題はなかった。スキャンタイムは12: 33 – :36で3分間ほどだった（４回ほど巡ったか）。5分間以下ならば，detail processingが可能のようで，そういう風に指示される。（5分を超えると，中間の画質 area processingに強制的に誘導される）。

　段ボール三箱スキャンをした後，屋外に出た。以前，Metascanでこの石丸の４個の基準点を巡ったが，Scaniverseがより高い画質を得られるかも知れないと思い，試してみた。
　国土地理院の基準点成果の利用 の図39の3-61〜3-39を以前，Metascanでルート測量したが，この時はかなりの早足で何とか10分間をギリギリに切る形で，測量した。それで，Scaniverseに期待したのは，Metascanの10分間限定を超えることができるか，ということであった。
　3-61（図25）からスタートして，前回同様の早足であるくと，図23の上部の赤ラベルのSCANNING相当の下に，move slowlyとかなんとかのメッセージが出る。そのアドバイスに応じて減速しようとするのであるが，ついつい早くなってしまう。画像取得が追いつかない（図26）。まあ，何とか減速しつつ，10分を過ぎていることを意識しつつ，10分オーバーがScaniverseに受け入れられることを期待して，3-39に辿り着いた。このスキャン開始以来，13分が過ぎていた。まだ行けそうである。すでに5分を超えたので，中間の精度 area processingを選んで，実行。2分弱で計算終了。これもMetascanよりかなり早い。iPhone 12 Pro画面の最上部のバッテリー残量は88%で，バッテリーを食うという印象はない。図27は得られたルート図である。図25や26のように画像の復元性を見ると，Metascanよりもかなり図的表現の完成度が高い。Metascanの常識からすると，Scaniverse驚くべしである。

　WIDAR-SCANには慣れていないためもあったが，ぼくはこれ以上触る気がしない。昨日，タニハで艮岩を撮影した（図28）。今日は段ボール撮影はしないで，このルート作成（この一例を図29に）を試みたのであるが，反応が遅くて耐えられない。これはフィールドで作業するには，使いものにならないと感じている。艮岩にはかなりの時間を費やしたので，画像の復元結果はScaniverseと大差無いようには見える。前述のように，スキャンして3D取得したと思っても同じ場所に戻ると，過去のスキャン結果が反映されていないで，最初からスキャンしなければならないというような徒労に近い作業を強いられた。
　図29のルート図はScaniverseとほぼ同速度で歩いてスキャンした結果である。使用に耐え得ないので中止した。
　

　図31，32はScaniverseによるスキャンのスクリーンショット。図33はWIDAR-SCANによるスキャンの途中である。Scaniverseによるスキャン時間は14分間であった。垂直の稜線と頭の四角錐の直線を捉えるのに時間がかかった。繰り返し実施した。レーダーの深さは2.5m（medium object）の筈であるが，水平方向にすると，不要なものを捉えるようだったので，上から下の方向にレーダー射出を変えてから，垂直の稜線をより捉えることができたように思う。Scaniverseでさえもほぼ満足がゆく画像を得るのに14分間を要したのである。5分を過ぎたので否応無く，area processing になった。
　WIDAR-SCANでの作業のスクリーンショットが図33である。神武天皇遙拝所の文字の認識がなかなかできない，というか際限なくできない。それで9分で終えた。スキャンの距離は5m未満であるが最近接した1 footでも認識はできてはいたが。

　図34，35は，WIDAR-SCANのLiDAR測量の結果である。「神武天皇遙拝所」文字列後半が認識できていない。頭の四角錐が丸い。垂直の稜線はほぼ捉えられている。

６　Scaniverse取得の直方体体積計算の準備

　以下，Scaniverseで取得した段ボール三箱と神武天皇遙拝所碑という二つの直方体を主とするオブジェクトの面積と体積をCloudCompareで求める作業に入る。段ボール三箱のスキャン結果を次のムーヴィー３に掲載し，計算結果を図36に示す。なお，神武天皇遙拝所碑の体積はすでに，図８に示している。
　図36には，サンペレグリノ炭酸水の箱を三箱並べている。スケールでサイズを測ると同じ段ボール箱ながら束ねると単に合計サイズにはならない。500mLビンが36本入っているこの箱を正位置にして，短辺と長辺を比べると，長辺は短辺の正しく２倍になっているので，短辺を一つの単位とすると，図36の側面は12面からなっている。体積と面積に共通の上面の面積は実測値 (3x短辺) x (2x短辺) = 61.5 cm x 41.5 cmとなっている。図36では短辺のみからなる辺は5辺あるがいずれも21cmであった。以上の観点と計測結果から，図36で示した体積と面積の結果を得ることができた。
　

　Scaniverseから点群point cloudファイルの一つplyでエキスポートし，図37のように共有したmouseのdocumentsフォルダにコピーした。

７　CloudCompareによる直方体体積と面積の計算：点群plyを使っての段ボール三個編

　体積と面積の計算法は，元伊勢大饗石のLiDAR測量 の「４　大饗石の体積を求める１：　まずはデフォルトで」〜「おわりに」までに記述しており，これに従ってゆく。
１　「２　必要な部分を切り抜く」ステップ：
　段ボール箱scaniverse Jan10-2 completeを図38に表示している。面がスカスカで奥の面も見えている。Points数は1,437,942で十分だと思うが。図38左ペーンの下部に見られるように，Point size 3に設定しているが，値を増やしても，汚くなるだけだ。どうも自然光の影の部分がスカスカになっているようだ。

　set top viewにして少し回転して，上段のツールのハサミアイコンをクリックして，segmentationを実施した。 図39左ペーン上部のDB Treeに見られるように，remainingは選択せずsegmentedだけを表示している。図39に見られるremainingクラウドは削除して，segmentedのクラウドを含むメーンファイルを選択して，保存した。

２　「４　大饗石の体積を求める１」「５　大饗石の体積を求める２」ステップ：
　体積計算では段ボールを設置したカーペットのZ値が必要である。上段のツールの左から四番目のPoint list pickingを使用する。segmentedした後であっても，辛うじて残ったカーペットでの５点のZ値のうち，0.008332が最小であったので，Ground値を一応，0.008とした。この作業実行後，Octreeも作成された。
　segmentedクラウドを選んで，Tools > Volume > Compute 2.5D volume，を選んで実行した（図40）。Ground > Default height =0.008とし，Ceilのファイルはこのsegmentedクラウドで，Empty cellsには一応，interpolate，Grid > step = 0.001（最小値）自動でのサイズ表示は663×674 (44,862 cells)だ。赤い横に長いボタンUpdateをクリックした。エラーメッセージはない。
　Volume 0.133（図36に示した実測値は0.1212），Surface 0.365（図36に示した実測値は1.4522）だ。CloudCompareによる体積計算値は多少大きめになっている。matching cellsは81.6%でかなり高い値になっている。

追記　Feb. 5, 2023:　このページ作成時には図36での面積計算のミスに気が付かなかった（ある読者には発見を期待していた）。図36のように実測表面積は1.4522㎡であって，点群plyを使っての表面積の計算はCloudCompareでは全くできていない。他のCloudCompare評価では全く問題にされていない。CloudCompareの点群ファイルの表面積計算は能力外のことと言える。

　図41ではsegmentedのクラウドを非表示にして，OctreeのDisplay levelを15にした場合である。

　segmentedクラウドを選んで適宜回転して，おおよそ図39の面を表示したのが図42である。図41，42にも実は見えるが，カーペットを削除したにもかかわらず，Groundレベルまたは近くでのクラウドの繋がりや，斜めの黄色に近い線状のゾーンが見えて，（この発生は）何らかのクラウドの欠損が関係しているように見える。

３　「６　大饗石の体積を求める３」ステップ：
　点群欠損部の解消のために，いったんメッシュ化を経由させてみよう。
手順１　Octree レベル8で実行された。segmentedクラウドをvisableにして，Height difference rasterを非表示にしたのが図43である。裏ができて，段ボールの欠損が明瞭になっている。

手順２　メッシュ化する。Keep old normals ? に対してYes。これでtriangulationが実施される。図44に見られるように，この作業でも欠損が見える。

　図45のように，MeshのWireframeにチェックを入れると，欠落部が埋まったように見える。Stippling（点描）についてはチェックを入れても入れなくても表示に違いが見られない。

手順３　点群データに変換。図46は実行の後である。図46では，メッシュアイコンのクラウドが選ばれているが，この作業で，新たにこの下方のルートに点描クラウドが見える。

　図47のように，新たな点群cloudは欠損が埋められたが，赤色の曲線で示したように，斜めに追加されており，元々の段ボール三箱の体積も表面積も増大しているようだ。

　この段階で，体積計算をしてみよう。２　「４　大饗石の体積を求める１」「５　大饗石の体積を求める２」ステップ，を繰り返す。先ほどの結果を再掲する。Volume 0.133（図36での実測値0.1212），matching cellsは81.6%。
　今回は，Volume 0.132（図36　0.121），matching cellsは81.7%。ということで，メッシュ化を経た結果と変わらない。
————————————————
新たな手順の追加１　図48で赤丸で示した２箇所を何とかしなければならない。図49にはこの箇所を斜めに見ている。膜状の繊維束が見える。Groundでもこの部分は緑色のカーペットがあり，この二カ所の直角三角形部分をsegmentしてしまえばいいと考えた。

　問題の箇所をsegmentした。図50はsegmentした結果の捨てる方を表示しているが，全クラウドが見えていて，segmentの結果が見えない。ところが，図51のように，Height difference rasterを非表示にすると，削除した部分がハッキリと見える。図52は，Cloud.segmented.mesh.sampled.sagmented，であり，期待していた形を得ることができた。

　

　Empty cellsに対して，leave emptyとすると，Volume 0.025, Matching cells 16.3%となり，この作業を経てもクラウドの穴は完全には修復されていない。赤字で，At least one of the cloud is sparse ! You should fuill the empty cells.が出ている。

　以上，Scaniverseのplyファイルを触ってみて，Metascanと比べてオブジェクトの点群分布が粗雑に感ぜられる。iPhone 12 Proでの絵作りについてはScaniverseは優れているが，CloudCompareで見たら，惨憺たるものであった。

追記 Jan. 12, 2023：　一晩考えてみて。Scaniverseは平面の認知が早く，稜線把握能力が高い。そのため，平面には点群が異常に少なくて大きく破れている。その面は相対的に影の部分であり，明度が高い面では点群は多い。影の部分であってもiPhone 12 Pro段階で画像的表現がなされており，そういう点でメッシュ的な情報が優れているように感じる。そこでCloudCompareに対応してScaniverseが出力可能なFXB, OBJが有効かも知れない。体積と面積計算のためにはこれをpoint cloudに変換してから，体積計算をすることになる。

CloudCompareの体積計算だが，Ground値を最低Z値（カーペットでの５点中）よりも小さい値を設定することで，平行六面体の高さの積み上げが生じていて，実際の体積よりも多目に出ている可能性があるので，カーペットでの５点中の最大値を使って計算するのが妥当かも知れない。その場合，大饗石の計算についても考え直す必要性がある。
　Ground値ではなくて，対象オブジェクト周辺のベースにあたるクラウドに換えて，CloudCompareで計算する必要性があるかもしれない。が，すでに述べたように，平行六面体ではオブジェクトの3D構造は捉えられており，この考え方は問題があるかも知れない。

追記 Jan. 13, 2023：　Jan. 12の追記を実行した。その結果が次の表１だ。第１列で言うと，実測値〜3 carpet min，はすでに述べたもので，ここにまとめている。そして，横罫線………… 以下の，4 carpet max，5 carpet max，を追加的に実行した。Ground heightをカーペットのZ値の最小値0.008から最大値+0.005=0.025に換えた。stepは0.001より高く，言い換えるとcellサイズを大きくして，0.002，0.003としてみた。体積は多少小さくなって実測値に近づいた。すでに実測値の計算法を示したが，辺の長さも計算法も単純化したものである。3 carpet min/「実測値」について，体積は+11.5%，多めになっている。段ボール箱が緩み膨れていることと三箱の隙間があることを考慮しても，是認できるズレではないと思われる。

追記 Feb. 6, 2023：　繰り返し追記しているが表面積の実測値は，修正図36にあるように1.4522㎡で，CloudCompareの点群plyには使えない。

追記 Jan. 25, 2023:　追記 Jan. 12で，「Scaniverseは平面の認知が早く，稜線把握能力が高い。そのため，平面には点群が異常に少なくて大きく破れている。」としているが，まさに，Scaniverseの設定（図53a）の中に，そういうオプションがあった。PROCESSING > Mesh Simplification，が選ばれている。これはデフォルトでそうなっているようだ。図53aではこの選択をすでに外した画面になっている。このMesh Simplificationの右手の？マークをタップすると，図53bが現れる。これを選択することで，まあ見た目で合理的な絵作りが行われるらしいのだけど，この説明にあるように，グリッドの密度を求めるのであれば，ボタンを切るようにとあった。ぼくがScaniverseに求めているのは絵作りではなくて，メッシュのグリッドの高い密度であり，Mesh Simplificationは排除した方がいいだろう。ただ，基準点を繋ぐ形の長い距離で迅速な測量をするには，このMesh Simplificationを採用した方がいいだろうと思う。
　Scaniverseのメリットは，レーザー感知範囲を限定できるということだ。図53cのようにLiDARの検知範囲（max 5m）を縮小できるようになっているが，Jan. 2023時点では，このページに示したように，対象による三択になっている。図53dでは撮影後のテクスチャーを三択できるようになっているが，スキャン時間が5分間を超えた場合は，Detailは選べなくなっている。
　撮影の注意点として，同じオブジェクトでも影の部分ではゆっくりと丁寧にスキャンする必要があると記されている。なお，Saveする前に編集機能を使った方がいいようだ。コントラストや密度を上げる。
　なお，石碑と段ボール三個について，このMesh Simplificationを外した設定で，再度，スキャンしたいと思っている。明るい場が必要で，いずれも明るい時刻や天候の時に，再挑戦したいと思う。

追記　Feb. 5, 2023：　図36修正済みの表面積の計算式と計算結果は，新たに修正したものである。これによれば，CloudCompareは少なくとも点群plyでは表面積は計算できない。それゆえ，このページの記述の表面積に関するものは全く無効である（その記述部分を削除したつもりであるが今だ残っているかも知れない）。表１も表面積（実測値は過って，0.29になっている）については全くの無効である。体積については，VolumeはGround heightを0.025にすることで実測値に近づいている。

８　CloudCompareによる直方体体積の計算：神武天皇遙拝所碑編

　さて，Scaniverse （Feb. 5, 2023追記：点群plyクラウドに対してでかつ，Mesh SimplificationをデフォルトでONにしていた環境であるが）にはガッカリした。iPhone 12 Proで見える絵作りは優れているが，CloudCompareでみるとボロボロだ。分析的観点からすると，Metascanとの間に大きな開きがある。さて，Scaniverseのこういう個性を生かすような使用法をすればいいのであろうが，さて，他のファイル形式はどうであろうか。また段ボール箱でトライする元気がもう無いので，神武天皇遙拝所碑について，この観点から記述を進めたいと思う。

　ScaniverseのExport Modelは，メッシュファイルとして使えそうなのは，FBXとOBJである。点群ファイルではLASと，ここで使ったPLYとがある。一応，全部，表示してみることだ。

以上，Jan. 11, 2023記。

１　fxbのmeshについて碑部分をsegmentしたのが，図54左ペーンDB Treeに見えるmesh.partで，これをEdit > Mesh > Measure Volumeした結果が図54メーンペーンの下部のConsole下部に見える。V=0.0510 (cube units)で，図8の「実測値」=0.0547㎥と比較すると，大きな違いはない。ただ，このコンソールのメッセージには，”The above volume might be invalid (mesh has holes)”，とある。

　面積は，Edit > Mesh > Measure Surfaceした結果が図55である。consoleに結果が表示されるが，S=1.16624 (square units)で，図8の「実測値」=1.264 ㎡と比較すると，大きな違いはない。Vと違って，”invalid”のメッセージは無い。

２　fxbに代わって，もう一つのメッシュのファイルOBJの結果を図56に示す。fxbの体積同様，”invalid”表示が出ている。V=0.0511 (cube unit)で，fxbとほぼ同じである。

objの表面積は，fxbの表面積同様，”invalid”表示が出ていない。S=1.146 (square units)で，fxbとほぼ同様である。

　以上を簡潔に整理すると，表２修正済みのようになる。

　表２修正済みから，メッシュファイル対応の体積と面積の計算アルゴリズムが，点群クラウドのものと比べると優れているということが解りますねえ。ただ，異なったオブジェクトに異なる計算式を適用しているので，単純に言い切れないと考えてしまう。さて，点群の計算過程は複雑なので，メッシュファイルの計算をした方が楽だなあ。ということは，段ボール三箱についてメッシュファイルの計算をすることにしよう。

９　紙箱と石碑の材質の差による違いはなかった

　第８章の終わりに示した着想で，段ボール三箱のメッシュファイルの体積と面積を計算した。その結果を，表２に追加したのが表３修正済みである。

　表３修正済みは，メッシュファイルを使った段ボール三箱の体積と面積の計算結果を表２修正済みに追加したものである。段ボール三箱も神武碑も，メッシュファイルでは，体積面積共に，実測値に近い。なお，メッシュの体積については，いずれも次のエラーメッセージが現れている。The above volume might be invalid (mesh has holes).

　fxbとobjのwireframeを次に比較したい。図58のfxbファイルではメッシュサイズがかなり大きな部分はあるが，図59のobjファイルでは大きく破れている面がある。この面は図38で正面に見える幅広い面ではなく，図43の正面に見える幅広い面にあたる。同じメッシュファイルであっても，メッシュ形成に大きな違いがある。面の捉え方としてはobjよりもfxbが優れていると言わざるを得ない。少なくとも，Scaniverseでは，メッシュファイルはfxbを採用すべきと考えられるのである。

　次に，石碑の点群クラウドPLYも一応，評価しておく。

１０　神武天皇遙拝所碑の体積と面積を点群クラウドPLYで求める

　さて，元伊勢大饗石のLiDAR測量 の「６ 大饗石の体積を求める３: 点群欠損部の解消」に従って，石碑のScaniverseによるPLYから体積と面積を求める。図69（図番号が不注意で大きく跳んでしまった）はPLYでpoint size=3で表したもので，神武天皇云々の字が読みにくい。set top viewではなぜか石碑の垂直方向からずれているのでマニュアルで回転して，手作業で図70のように石柱が垂直に見えるようにした。

追記 Jan. 24, 2023：　本日，実測値に疑問を感じて，この冬一番の冷え込み？の中，この石碑の再測に行った。そして，序でに垂直に立っているか，確認した。確かに，傾いている。図60では東へ，図61では北へ，図62では東へ。なお，図番号は図59と図69の間が欠番になっていたので，図番号の60, 61, 62を挿入した。

　PLYファイルは点群であるが図70ではcellがハッキリと見えている。なお，不思議なことであるが，図70の台座に見える雲のようなものは実は台座の中に作られている。LiDARイメージは石碑の表面だけの筈であるが，その薄皮内は，空白の空間の筈であるが，雲ができている。3D回転などをして，確かめているので間違いは無い。

　図70で，segment toolを使って，円柱とその周辺の台座のみを採取した。それが図71である。3Dで観察したが，点群欠損部はみつからなかったが，この手順は点群ファイルには必須のプロセスであると認識している。

　　手順２の点群データからメッシュデータに変換した結果から，OctreeのDisplay level =6として台座付近を観察したい。図71に示す。current levelを見ると，cell size = 0.0264 mになっている。台座の雲のようなものは台座表面にくぼみとして捉えられていた。図71右手のメーン画面で一例を赤丸で囲っている。図７，35，56から推定すると，この窪みは花崗岩台座の黒班に由来するようである。Scaniverseの弱点かも知れない。色から3Dを推測するアルゴリズムが入っている可能性がある。これはかなり危険なアルゴリズムだろうと思われる。Metascanにも在るかも知れないし，さらに言えば，iPhone 12 ProのLiDARそのものの限界かも知れない。
　LiDARの利用者からすれば，2D限定のPhotoshopに対して3Dで修正できるような機能が欲しい。このCloudCompareにあってもいい。何度かこのマニュアルを見てきたが，すこし深みに入ることができるような情報が見当たらない。

　図71の石柱部分をこのアングルから見ると，wireが広く欠落している。これは何を意味するのか，わからない。

　手順３のメッシュデータから点群データに変換した結果を図72に示す。何となく金属光沢がある。台座の凹みがより明瞭になっているし，頭の歪みも明瞭だ。Point size = 3としている。

　手順４は体積計算である。「４，５　大饗石の体積を求める１，２」と同様にする。set top viewにして，台座周辺のZ値をpoint list pickingで求める。周囲四点の最小値は0.720768 mなので，Ground levelを0.720768を切り上げて，0.721とする。Volume calculationのパネルで，Grid > step=0.001000 （最小値），size 436 x 439 (191,404 cells)。

　図 73にVolume calculationの計算結果を示す。V: 0.032 ㎥, S: 0.189 ㎡, Matching cells: 98.7%。CloudCompareの計算そのものの精度はかなり高いものになったが，表３の実測値（V: 0.0548, S: 1.2641）と大きな開きがある。

　次の図74は，Height difference raster (0.001)である。

　この点群PLYの結果を追加すると，表４修正済みのようになる。

　点群PLYファイルの体積と表面積は余りに実測値とかけ離れている。この原因として考えられるのは，元々の点群クラウドの欠損である。
　とはいえ，ここで確かめなければならないのは，石碑の形態を代表する幾つかのポイントの(X, Y, Z）座標をpoint list pickingで調べて，個々の代表点から幾何学的な3Dモデルを求めて，実測モデルと一致するかどうかを確かめる必要がある。これこそ，体積や表面積を論じる以前に重要である。

　次のKindle本の出版に向けて，眞さんから届いたデータを編集する必要があり，この方面の仕事は中断したいと思う。とはいえ，クラウドの欠損を補修するアプリとしてMeshLabが有望であり，次の展開のためにも，この導入に関するページを次に作成したいと思う。

以上，Jan. 25, 2023記。

追記　Feb. 6, 2023：　このページのすべてを再々チェックして，数値など文章表現も含めて修正した。

おわりに

　この学びの流れのなかで，3Dデータの欠損をMeshLabを使って穴埋めする のページを作成してきた。そして，１月26日撮影の段ボール三箱OBJファイルについて，MeshLabでClose Holesを実行して後，CloudCompareのFile > Mesh > Volume, Surfaceを実行し，V=0.1287㎥, S=1.4542㎡，が得られた。この値は，0.1287/0.1212 = 1.06，1.4542/1.4522 = 1.00，となっていて，正しく，体積と面積を得ることができたのである。石碑は省略した。同様の結果が得られるであろう。次は，この問題意識が始まった大饗石の体積と面積を同様の方法で求めたいと思っている。
　デスクワークについては，キンドル版の次の発行に向けて時間を注ぎたいと思う。

以上，Feb. 6, 2023記。

はじめに

　このpostingでは，このテーマに限定する。iPhone 12 Proによって大饗石のLiDAR測量結果は得ている。さらに，幾つかの手順で外観だけでなく，数値データも整理する必要がある。そのアプリとして最も利用されているのが，CloudCompareである。Windows版のオープンソースであり，ドーネーションが期待されている。ここではインストールされていることを前提とする。メニューの一部が日本語化されているバージョンもあるが翻訳が不完全で，日本語化されているものはお勧めできない。
　ぼくはmouseのWindows 10とmac内のWindows 10 on Parallels Desktopにインストール （2022年3月実施）している。このウェブページでのコンテンツ利用には，mac内が便利ではあるが，多々支障はある。なお，mac版も提供されているが以前使って問題があって，ぼくのmacからは削除している。以下を実行する上で，次のページを読み込む必要性がある。

　iPhone 12 Pro撮影の3Dスキャン画像の座標を捉える
　裸岩露頭のiPhone 12 Proを使った点群撮影
　二つの3Dスキャンマップを繋ぐ

１　 iPhone 12 ProからCloudCompareにファイル転送する

　iPhone 12 Proからファイル出力の際には，USDZ以外，Metascan Proの契約をしていないとできない。唯一有効なPC処理アプリCloudcompareは，残念ながら，USDZに対応していない。大饗石のLiDAR撮影結果は，すでにMeshファイルとしてはFBX（121.5MB），Point CloudファイルとしてはPLY（81.8MB）とXYZ（zip 89.9MB）を出力し，macに取り込んでいる。XYZ出力はzipファイルとして出力されているので，解凍する必要がある。この順でCloudCompareに取り込んだ結果が次の図１である。
　左端のツールのうち，虫眼鏡直下のSet top viewが図１のコンソールに現れている。このコンソールの右下隅には，3D軸が見え，これは右手座標系でZ軸は手前方向に延びている。

　図１の中央の赤線で囲んだ範囲が大饗石で，この上に何か白いキノコのようなものが見える。図２ではこの図１を少し回転したもので，赤丸で囲んだこの白いキノコのようなものは大饗石よりも高い位置にあることがわかる。スキャンニングの際に，大饗石よりも高い位置の「障害物」が捉えられているのである。大饗石だけを残す形で切り取ることになる。

以上，Dec. 31, 2022記。

２　必要な部分を切り抜く

　このLiDAR測量の際の意図をはっきりとは，もう覚えていない！　大饗石のみを詳細にスキャンしたつもりではあるが，大饗石周辺もかなり捉えられている。大饗石のみを切り出そうと考えていたが，まずはより広い範囲をまずは抜き出したいと思う。そこで，topビューで大饗石とその周辺を切り出すのではなくて，地上の木本以外の地形を切り出すべく，z軸に直交する平面で切り取りたいと思う。
　CloudCompareで不要なポイント群または面群の削除　にはその手法を整理しているので，参照して欲しい。この参照を前提に，以下，記述する。

１　まずはこの例では，set lift sideして，ツール左端の‖をクリックして，Segmentation [PAUSED] にして，フロートや邪魔になりそうなスギの頭などがsegmentしやすいように回転などして，ツール左端のトグルスウィッチ‖をクリックして，segmentationを実行してゆく（図３→図４）。segmentationを実行すると，Segmentation [PAUSED]にもどるので，位置決めをして，また，トグルスウィッチ‖をクリックして，segmentationを実行してゆく。

　一応，終了しよう。ツールの✅️（confirm segmentation Enter）した。その直後が図5で，remainingとsegmentedがともに表示されている。前者の✓を外したのが図6であり，作業結果が見える。set right side view，表示である。ほぼ側面図にあたる。中央のトップが水平に近い岩塊が凝灰岩（fall）からなる大饗石で，左手の岩塊はデイサイトの大岩塊である。いずれも前期中新世の溶岩または凝灰岩層から，崩落したものである。
　保存作業であるが，remainingファイルはこれを右クリックで選んでdeleteした。

　作業結果のクラウドを保存するには，segmented Fileを選んで，保存することになるが。File > saveの形で，ファイル名に_segmentedを追加して，元ファイルのフォルダに保存すべく実行して，確認のために，このtxtファイルを読み込んで表示したのが図７であるが，残念ながらRGB表示ができない。
　図８のように，保存する際に下段にファイル名とファイルの種類を指定する必要性がある。デフォールトでは元々のファイル名がそのまま使用され，ファイルの種類もtxtファイルになってしまう。図７はファイル名には_segmentedを追加したがtxtファイルで保存してしまった。図8ではファイルの種類をbinつまり，ClouCompare entities，にして保存したのである。binとは，binary拡張子で，バイナリー形式のデータであることを表している。txtファイル形式ではCloudCompareの機能を発揮できないのである。

　それゆえ，処理のそれぞれの画期で，ファイル名に作業を付加したbinファイルを保存してゆく必要がある。図６の形で完成とも考えることができる。大饗石だけよりも，立地がよく理解できる。とはいえ，大饗石の3D情報を得たいと考えての調査であったので，この大饗石だけを刳り抜いて見たい。図９は大饗石のズームインである。

３　大饗石だけの刳り貫き

大饗石3Dクラウドを確保したい。図10はset top viewにして表示したもので，この形でsegmentedしたが不明瞭な部分が多く，図11〜13のようにパースで見て，segmentedしていった。図14は新たにbinファイルとして保存したものである。binファイル名は，metascan_20221121-1440大饗石周辺のロックフォール_onlyOoaeishi.binというように名付けることができるが，この下位のクラウドの名称は自動的に，metascan_20221121-1440大饗石周辺のロックフォール – Cloud.segmented.segmented，となる。

以上，Jan. 1, 2022記。

４　大饗石の体積を求める１：　まずはデフォルトで

　3Dファイルにはメッシュmeshと点群point cloudがある。画像的な表現では前者がより優れているが，右座標系など幾何学的な分析には後者がすぐれているようにぼくは感じている。体積計算に関しては，公式マニュアルは全く役に立たない。
　では，http://www.cloudcompare.org/doc/wiki/index.php/Main_Page，はどうだろうか。2.5Dで検索すると，2.5D Volume のページに行きつく。このページを理解した上での使用例として，下記を挙げる。CloudCompareでの体積計算　その2　（その１はこの「その２」の予告だけ）
（引用１）2.5D Volumeの説明に従って，大饗石の体積計算に挑む。このアプリは次の機能がある。
This tool can be used to compute the volume between a 2.5D cloud and an arbitrary plane (constant height) or between two 2.5D clouds.
　二つのクラウド間の扱う例としては，例えば工事前Beforeと工事後Afterで，土量のプラスマイナスを求めることができる。一つだけのクラウドで体積を求めるというのは，この大饗石の体積を求めたい場合である。図６のように，大饗石のトップはほぼ水平で下部もまあ水平と見做すことができるので，下部の最も低い部分の高度を使えばいいと思う。（引用１）の「an arbitrary plane (constant height) 」をその高度とすれば良いだろうということになる。

１　フォルダと対応ファイルに✓して，対応ファイルを選ぶ（ハイライト）。そして，Tools > Volume > Compute 2.5D volume 。
　図15はleft side viewである。奥行きの軸がXで，縦長の軸がY，そして垂直軸はZとなっている。左のペーンのPropertiesのBox dimensionsを見ると，X: 5.39993, Y: 7.43598, Z: 2.96101，となっている。iPhone 12 ProのLiDAR測量は海抜高度を反映していないので，上記の例とはかなり異なり，数字が大きくない。大饗石は地中に多少埋まっているであろうが，凝灰岩の層理を反映しており，後掲するVolume caluculationのパネルでのGround（空間）/Before（時間）のGroundと考えて良いだろう。

　この大饗石の座標値が未だ理解できないので，Point list picking（６点）を実施してみた。図16がそれである。この画像表示はpoint間の位置関係がわかるように岩の上部を少し手前に回転している。Point list pickingの表では，座標値を一目では３行しか見ることができないので，右上の表のツールのフロッピーアイコンをクリックして保存して，次のように，そのテキストを，参照した。

Point #0,-0.939450204372,2.67226147652,-0.758838474751
Point #1,-0.485350400209,3.48180985451,0.743179500103
Point #2,-0.7682762146,0.985117554665,2.12557053566
Point #3,-2.89230465889,-3.08031964302,1.72712016106
Point #4,-2.35597205162,-3.85543513298,1.05731666088
Point #5,-3.39330339432,-1.8211826086,-0.585319936275

　この6点の座標値からXYZ軸を理解することができる。今，必要なのはGround値で，Point #0のZ値と見做して問題ないだろう。Ground値を-0.758 (m) とする。ミリメートル単位である。図17ではパラメータを入力している。図18は，図17の赤いベルトのUpdateを実行した結果である。図18下部のResultsが一気には見えないので，”Copy to clipboard”ボタンを押して，Google Chromeを使って，macのmailにgmailした。
　その結果を図19の左手のテキスト群に示している。図18の右手のrelative heightベルトの左手の模様は，大饗石の高度分布を示している。図19は大饗石のtop viewであるが，これと図18の模様と対応しているのである。

以上，Jan. 2, 2022記。

５　大饗石の体積を求める２：　step （メッシュサイズ）= 0.008 m

　とにかく，デフォルトでやってみた。図19で言うと，長軸方向（上辺が斜面の下手で下辺が上手），これの直交方向が短軸方向，そして高さは図16で推定できる。大雑把にいうと，6.5 m x 3.6 m x 2.7 m = 63 ㎥ 。Volume: 70.765 ㎥ は悪い値ではない。ただ，Matching cells: 75.0%という値は適切ではない。
　さて，この体積計算アプリ（図17）で，ユーザーが設定できるパラメータは実質，”Grid”では”step”のみ，Ceil/Afterとしては指定したクラウドの”Empty cells”だけである。stepに関する説明がマニュアルにないが，図19から見ると，stepは，まさにgrid（方眼）を構成する正方形squareの一辺の長さである。step = 1.000000としたので，size = 6 x 8となったのだが，適切な英語表現に替えると，”step”はside-size of a square，”size”はnumber of squaresである。point cloudとmeshとの対比からすると，混乱するが，stepはmesh sizeで，sizeはmesh numbersである。
　体積を求めるための地物に対して，メッシュサイズ（step）を小さくするほどメッシュ数は大きくなってゆく。この図17の場合，size: 6 x 8とある。この設定での計算結果が図19に見えるが，横軸（左右）X 6，縦軸（上下）Y 8のグリッド（白いドット）が見える。かなり粗っぽく計算されたことがわかる。
　図20と21は，step = 0.008（自動的に，size = 676 x 930）で計算した結果である。サイズは1000 x 1000以内に収まるようにというアドバイスがある利用サイトにあったので，その意味の根拠はわからないが，そういう制限のもとで，step = 0.008が決まった。
　計算結果をクリップボードにコピーして，このウィンドウズからメールでペーストして，macに送った結果を次に示す。
Volume: 31.317　Surface: 14.883
———————-
Added volume: (+)31.317
Removed volume: (-)0.000
———————-
Matching cells: 37.0%　Non-matching cells:　ground = 63.0%　ceil = 0.0%
Average neighbors per cell: 5.6 / 8.0

　体積は第4章に比べてほぼ半分になってしまったマッチングセル率は37%で，非マッチングセル率はceilではゼロだが，groundでは63%に及んでいる。これはGroundを斜面下縁（図16に続くPoint#0のZ値=-0.758）にしたことに依っているのであろう。この体積 31㎥ を提示されると，なるほど，と思ってしまう。計算のアルゴリズムは公開されていないが，メッシュ数676 x 930 = 628,680で，メッシュサイズ = 0.008 m だから，(676 x 0.008) x (930x 0.008) = 5.408 m x 7.44 m = 40.235 ㎡ になる。図21の矩形域の面積がこれにあたる。それぞれのメッシュでクラウドの深度幅を掛けて，全体の和を求めると，体積となる。粗っぽく目算すると地物はメッシュ枠の半分ほどであり，深度幅が1.5mほどだすると，体積30 ㎥ 余りとなるのである。

　さて，図22と23は，この地物の空っぽの裏が見えている。この体積計算過程では，LiDAR測量結果が正しく把握されている。色分けはZ値を示すもので，もちろんトップ面のほとんどが赤色である。Z = -0.7588からの比高によって色付けされているのである。オーバーハングの場なども正確に表現されている。

　CloudCompare octree （8分木空間分割を最適化が参考になる）を表示する。DB Treeには，体積計算を実行すると，Height difference raster (0.008)のサブディレクトリにOctree（8分木空間分割）が作成される。これに✓して，PropertiesのOctree欄でDisplay levelを5にした場合が，図24の表示である。多数の平行６面体が見えるだろう。このレベルだと，Current level情報に，Cell size : 0.232482 m, Cell count: 1,822, Filled Volume: 22.8938 ㎥ が見える。

６　大饗石の体積を求める３：　点群欠損部の解消

　作業過程でこの地物にさらにフロートなどが残っていた。図22にその滓を示している。滓を排除したあと，自動的に作成されるファイル名は，segmented.segmented.setmentedと三つ並ぶ。これが現段階での地物の最新クラウドである。LiDARスキャンした際の不手際で，点群データの欠損が見られる。図21や図23の赤丸の部分である。図21の赤丸部分はトップ面に属し，図23の残りの二つの赤丸部分は側面に属している。

　この作業は，フィールドで確認作業をすれば不要だったかも知れない。1日目にこのLiDAR測量をしたので，当日のホテルで確認をすれば良かったとは思う。フィールドではiPhone 12 Proの画面での作業になるので見落とす可能性もある。図20左のパネル内に赤丸で示した赤字のメッセージは，クラウドに欠損があり解決すべきとしている。この欠損解決するため，iwamaによる iPhone LiDAR×CloudCompareで体積算出しようぜ！を参考にした。
　iwamaのサイトでは点群データをメッシュデータに変換して，点群の欠損部をなくした後に，このメッシュデータを点群データに戻している。点群データをメッシュデータに変換するだけで，何故，元の点群の欠損を消すことができるのか，それはメッシュデータは点群の欠損部を否応無くメッシュでカバーしてしまうからのようである。
　Hajime Saitoさんの メッシュのデータ構造 によれば（不要と思われる部分は削除），「メッシュは突き詰めれば点の集まりで、点と点を結んで線を作り、線と線を結んで面を作る。点は頂点、線はエッジ、面はフェイスと呼ばれる。」，とある。
　この文で，「点の集まり」のところが点群データなのだが，点群データからメッシュデータに変換する意義などが示された，点群データの3Dモデル化！点群をCADデータ・メッシュデータ・サーフェスデータに変換 ，が参考になる。「点群データは、3Dスキャンによって取得した段階の場合、単純に点の集合の状態でしかありません。そのためCADデータとして編集を行う際には、点群データを「点」から「面」の状態に変換していく必要があります。」，とある。点から面の状態に変換する場合，メッシュ（ポリゴン）データとサーフェス（ジオメトリ）データがあり，ここではメッシュデータに限定する。その説明の一部を次に引用する。

　このメッシュデータの説明から，点群データの欠落部が埋められるのは容易に理解できる。
　それでは，iPhone LiDAR×CloudCompareで体積算出しようぜ！のプロセスを大饗石の点群データに適用してゆく。表現は替えている。

手順１　DB Treeから該当の点群データを選択し、Edit > Nomals > Computeで，特にパラメータには触らず，OKを選択すると，点群データに「表裏」ができる（図24）。
手順２　点群データをメッシュデータに変換するため、Edit > Mesh > Delaunay2.5D(XYPlane)で，特にパラメータには触らず，OKを選択する。ここで，図25のように，Keep old normals ? のアラートが現れるので，Yesを選択する。

　観察すると，大饗石のすべての表面には，図26のようにメッシュが貼られている。

手順３　メッシュデータを再度点群データに変換するため、ツールバーのPoints Sampling on mesh（図26に見える上段のツールバー群の左端（選択中なのでブルーになっている））を実行する。Points Number（デフォルト）を選択し，OK。この実行の結果，図27に施した赤丸のように, ⋯⋯⋯⋯⋯.mesh.sampled　という点群データファイルが生まれているが，変換前のメッシュデータも合わせて表示されているので，点群データが見えない。図28では，変換前のファイルの前にある□で✓を外しているので，点群データだけが見えている。

　ここまでの作業結果を確認したい。点群の欠損を果たして埋めることができたのか。図29はメッシュデータであるが，図23に見られる欠損は埋められている。
　図30を見ると，この変換過程に入る前のもともとの点群データと比べて，トップ面の点密度が小さくなったような印象を受ける。Propertiesで見ると，Points 1,000, 623であり，滓を取った点群データ（図23）Points 615,237と比べると，むしろ増えており，問題無いのだろう。

省略手順　iwamaのサイトでは，点群密度を間引く作業が用意されているが当方は不要なので省略する。

同省略手順　iwamaのサイトでは，地物のベースの部分を切り取って，ground側のクラウドとする作業が実施されている。二つのクラウドの差を取るCloudCompareの手法を実現するためのなかなか良い工夫だと思うが，その必要性があるのか疑問なので，一応，この手順も省略したい。
　後に実行しようとしたが，segmentation 機能と

　図31を画面一杯に表示することもできる。Resultsも一気に見ることができる。Octreeの詳細も見える。図31と32で計算結果が異なるが，図31の出力の後，処理を修正したことが反映しているようだ。図33はHeight difference rasterの分布を見ている。図22〜24の赤色の3D分布と比べて，圧倒的に事実を反映していることがわかる。この章で実行した「点群ファイル→メッシュファイル→点群ファイル」のプロセスは体積計算には欠かせないものだろうと思う。

　本章の作業結果と，前章の作業結果では，かなりの大きな違いがあり，本章の作業は体積計算に欠かせないものだと思う。

７　大饗石の体積を求める４：　メッシュデータの面積と体積の計算

　メッシュデータの場合には，Edit > Mesh > Measure Surface，そして，Measure volume，のコマンドを使って，計算が可能で，結果は下部のConsoleに表示される（マニュアルp. 65）この場合の結果は，
時刻 [Mesh Surface] Mesh ファイル名: S = 1141.79 (square units)
時刻 [Mesh Surface] Average triangle surface: 0.000928008 (square units)

時刻 [Mesh Volume] Mesh ファイル名: V = 35.2555 (cube units)
時刻 [Mesh Volume] The above volume might be invalid (mesh has holes)

面積は何故か，非現実的な値となっている。1141.79 = 0.000928008 x 1230367で求めることができる。1230367は，このメッシュファイルのProperties > Mesh > Faces = 1,230,367に対応している。非常に詳細な凹凸を認識しての表面積であり，誤りでは無いが，一般に認知されている表面積ではない。一般に認知されているのはいわば表面のデコボコを無視して平滑な面で構成される地物の表面積なのだろう。

　体積も同様の計算過程を経たとしても点群ファイルとの差は大きくは無いはずで，V = 35 ㎥は適当と考えて良いのであるが，なんと，点群ファイルの欠損部分埋めた筈のメッシュファイルにもホールがあるという。というわけで，このメッセージ故に信頼できないとなるのである。

おわりに

　エラーを回避できた計算結果は， 第６章での53.8㎥ のみであった。この結果を受け容れることになる。ただ，CloudCompareの体積計算機能が適切なのか，簡単に計測が可能な直方体を通じて知る必要がある。次のポスティングに引き継ぎたいと思う。

身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める

以上，Jan. 7, 2023記。

はじめに

　今日はカローラを車検に出すべく，カローラの販売店に出向いた。帰りは徒歩で，R171から離れるべく，都市労働者用宅地に蚕食された残存農地を歩いた。図１は，鍋田川の入り口付近で，箕面警察の南側を東西に走る道と交差する場所付近である。図２の白い住宅の後背には箕面市立第二中学校がある。木立なども文化が感ぜられず何とも殺伐とした風景である。
　この川の左岸沿いに上って車道の交差点から東方向（ヴィソラ方面）に向かった。図３には装飾的に設置された道標が見える。『箕面の道しるべ』（箕面市文化財愛好会編，箕面市教育委員会刊, 1991年）によると，みのお山瀧への道しるべになっているようである。この裏面には，図4上段左端の碑文が見える。図３は同上段右端の碑文に相当する。おそらくこのp.100で紹介されている道標がここに1991年より後に移設されたのではないか，と考えた。ところが，本日Nov. 16にこの箇所を通ったので設置者の面（図3-3）を見ると，願主（図４上段中央の）とは違って，施主となっており同じ道標ではないことは確かなことであろう。この図3-3の施主の部分は，図４と同様「京」という字が見えて，名前のはじまりは「中」と読めるがその下の字は読めそうで読めない。拓本を取れば読めるかも知れない。
　箕面にあたる字面は，みの織，みのを，ミ乃を，などがあるが，図３にみえる地名，みの□，は興味深い。□は，図３のように，扌偏に，二旁，で表現されている。なお，図３の，「みの扌二」のすぐ上の二字は，「むく」，つまり，向く，ではないだろうか。

追記 Nov. 16, 2022：図3-1〜-3を追加した。

　京や大坂などでは，箕面の滝は現箕面市域のうちでは，最も著名なランドマークであったようである。箕面の滝は，蓑が下がっている，つまり蓑が下がった面に見える瀧，として，発生した地名であろう。白糸の瀧などからすると，なんともロマン性から外れた命名ではある。

　ヴィソラの西方150m見当に図５〜７のごとき異次元空間がある。散歩の際に，一度は通過したようにも思うが，本日はじめて中に入った。図５にOPEN看板が見える「ゴットウ デリ」ではおからの揚げたのだののオーガニック弁当を買って，ベランダで食べた。さっぱりして良い感じだった。パイプ椅子の脚がスノコに刺さって抜く時に指をぐねった。季節外れの蚊が右手首を刺した。図６の奥の林は隣接する当対池公園のものだ。図７の奥の「楽駝（らくだ）」は目の前でOPENになった。怪しいおっさんが出てきてCLOSEDの看板をひっくり返していた。午後3時すぎだ。この怪しいおっさんと，ふつうの奥さんと，話してみた。10円の駄菓子が小さな棚にみえる。小さなカウンターがある。ビールの絵があるので，質問したら自家製ビールだという。金曜日と土曜日の午後6時〜10時に営業しているようだ。ぼくの奥さんと来ると約束したものの帰宅して提案したら奥さんには脚下されてしまった。今週か来週あたり自転車に乗ってこのラクダを襲うつもりである。

以上，Nov. 13, 2022記。

１　基準点成果へのアクセス

　比沼の真名井（京都府京丹後市峰山町久次）の大饗石（おおみあえいし）へのアクセスルートと，石そのもののマッピングをする準備の一つになる。アクセス過程を次に示す。
　当方が暮らす場所では都市化が進んでいるので，基準点も京丹後市に比べたら圧倒的に多い筈だ。大饗石（おお-あえ-いし）付近にはまずは無いだろう。無くても問題ない。知りたいことは，既知の２点間について，Metascanを使ってLiDAR測量を実施して，測定結果がどの程度の誤差が生じるかである。比沼の真名井（京都府京丹後市峰山町久次）の大饗石（おおみあえいし）の図２のルートマップの想定出発点dから大饗石までは水平距離で1200mほどである。さらに，垂直距離は100mほどである。これをそのまま再現する必要性もないだろう。

１.1　国土地理院の基準点閲覧サービス利用

　地理院地図（電子国土Web）から，基準点成果等閲覧サービス　に入ることが出来るが，もちろん，基準点成果等閲覧サービスから直接入ることもできる。「通常検索」と「詳細検索」のタブがあるが，何故か「詳細検索」タブでは表示されず，デフォルトの「通常検索」タブで実行することになる。基本基準点，公共基準点のいずれにも，その他項目があるがチェックを入れると事実上フリーズ状態になってしまうので，その他には追加的にチェックを入れない方がよい。
　図８は，当方自宅周辺を表示して検索したあと，ズームアウトした結果である。元々の範囲の検索結果が反映されている。この上段に，ブルーの「基準点成果等閲覧サービス」という文字が見えるが，この右手方向には中心緯度経度などが表示されているが，ポップアップ，と，テキスト情報，に，新たにチェックを入れている。チェックを入れることで，それぞれの基準点の下方に，成果IDと基準点名を，図８のように地図上で見ることができる。ぼくが知りたい座標値や海抜高度情報ではない。

　この情報を使って，1.2kmほどの距離を持つペアを探す必要がある。LiDAR測量をしつつ基準点を見つけるのは難しいので，図８をズームインして目星をつけて，ペアを探さなければならない。これが完了し，更にLiDAR測量をした段階でこのページを追加したいと思う。なお，この作業の際には，ポップアップは煩いので，外している。

１.2　近所の基準点調査

　図８のうち，近所の何点かが入った地図をプリントアウトして自転車で回った。驚いたことに一つも残っていなかった。国土地理院は何を思ってこのような意味の無い情報を公開しているのだろう。

　仮に，①〜⑥とナンバーリングして，それぞれの写真を次に示す。前半３件は真鍮製の基準点鋲で，Sシリーズナンバーがついている。後半３件はハンドホールのフタのみで，そういった情報はない。偶然であるが，このハンドホール３件はいずれも山麓線（箕面池田線）から少し入ったところに立地している。

　箕面市役所に問い合わせて，みどりまちづくり部まちづくり政策室（かつての都市計画課）ではなく，道路管理室（別館5F）が管理保管していることがわかった。明日Nov. 15, 2022に訪ねるつもりだ。

以上，Nov. 14, 2022記。

　昨日はタニハへ。今日，午後１時過ぎに訪問すべく，道路管理室に自転車で向かう。課題を次に。
１　ぼくのこのウェブページをプリントアウトして持って行く。一応，名刺も。
２　もちろん，閲覧依頼をする。可能ならば地図と基準点リストのコピー依頼。
３　国土地理院の基準点と，箕面市のそれとの関係を聞く。なぜ，更新されていないのかも聞く。
４　ハンドホールの基準点箇所と，真鍮鋲との位置関係（平面と垂直）を聞く。

１.3　箕面市の基準点情報

　昨日Nov. 16（水），箕面市道路管理室に出かけて，多くの学びがあった。本日Nov. 17（木），その情報に基づいて，およそ想定できるルートを自転車で回って，「露出した真鍮鋲」と「ハンドホール内の真鍮鋲」の様態などを確かめた。関心の範囲は図９であった。
　箕面市道路管理室の担当者には，丁寧にご対応頂いた。国土地理院の基準点成果等閲覧サービスの基準点情報の基準点が残っていないことを告げたら，その認識はなかった。本日巡ってみて，ぼくの認識ミスであることがわかった。真鍮鋲ばかり探していたので，ハンドホールに気付かなかっただけであった。図９の山麓線に近い④地点で，偶然？ハンドホールに「箕面市基準点」という刻印を見つけて後，いわば立て続けに計３箇所のハンドホールを見つけたが，これが国土地理院の三等基準点とは繋がらなかった。
　本日Nov. 17，巡っている時には気付かなかったが，いま，調査結果？をこのWebページに入力を始めて，箕面市基準点のハンドホールが，国土地理院の三等基準点に対応することに気付いたのである。真鍮鋲には，例えば図13のように，S-200などのナンバーリングがある。この真鍮鋲に対しては標高情報がない。平面直角座標系の(X, Y)値だけである。４級基準点にあたっている。
　今回の実験試行では，この真鍮鋲の基準点は省略しようと思う。今日， 真鍮鋲を確認することで現在位置の誤りに気付いたりしたが，計算過程の煩瑣をさけるためもあって，三等基準点限定にしたいと思う。ハンドホール内の真鍮鋲の配置は一定ではなく，一つ一つ確かめる必要がある。この作業が本日の中心的なものであった。以下，調査結果をまとめたいと思う。

　測量結果をまとめる際には3D情報が必要なので前記のように三等基準点に限定して示す。

　当方の住居そばなので，次の１点だけ，４等基準点を示す。

　以上，3-61, -41, -40, -39, -38, -43, -42, -44の８点の主に三等基準点のホール内真鍮鋲位置を示した。LiDAR測量の際は，ハンドホールの蓋が閉まったままなので，蓋のどの位置に真鍮鋲の中心があって，その位置から深さ何mmにその頭があるのかを求める必要がある。蓋のどの位置に真鍮鋲の中心があるのかは，後にイラストレータを使って示したいと思う。
　なお，ハンドホールの蓋を開けるのにドライバーで十分かと思ったが，一応両釘抜を持参した。ぼくには最も近い図39の南西端の3-61に行ってみた。ここでは基準点を何度か探したがこれまでは見つからなかった。しかし，前々日に見たハンドホールを探してみると，果たしてあった。頭から真鍮鋲を探してしまうと決してこの箕面市基準点のハンドホールは見つからないのである。蓋は，この両釘抜だけで何とか開けることができた。どうもハンマーも必要だと感じて自宅に引き返した。図32や図37に見えるハンマーと両釘抜は必須であった。この両ツールを使ってもなお開けにくい蓋もあったのである。ホールの写真に見える曲尺（カネジャク）は偶然だが手頃だった。フィールドバックに入れていてもほとんど使ってこなかったのであるが。

２　LiDAR測量

２.1　ルート選定

　まずは，明日Nov. 18のLiDAR測量のルート図を描く必要があり，図39に提示した。南西端の3-61を出発し，-41, -40, -39, -38, -43, -42, -44と進むことになる。図39のスケールはグーグルマップから簡易的に求めたものである。これを使うと，1800m余りとなる。

2.2　Metascanの準備

　Metascanは久しぶりに使う。
————————————————

Metascan（最新は，ver. 2.8.0 (Nov. 7, 2022)）のトップページ：　https://metascan.ai/
Start 3D scanning today　https://metascan.ai/pricing

Freeでは，
For getting started.
$0/month
for individuals
Get Metascan
Unlimited LiDAR Scans
5 Photo Scans per month
USDZ, iMessage export
Share scans to web
HD Video export

Pro契約をすると，
For individuals.
$4.17/month
billed at $83.88 $49.99/year
Get Metascan
Everything in Free, plus:
150 Photo Scans per month
Maximum detail
Unlimited export
4K Video export

となっている。フリーでも，Unlimited LiDAR Scansのように見える。使用時間やファイル容量に限界がある。本日の経験では使用時間最大20分程度。この限界に達するとProにアップグレードするようにアラートが出るが，Proに替えても何ら能力は改善されない。
　以前，写真モードでの再現性を主に確かめるために，月契約をした。早めに契約を切ると，残りの日数が目一杯使えるというような連絡があったので，忘れそうになったら，早めに終了の手続きをした方がよい。ただ，LiDARはProにしても全く改善されない。

tutorialsがあるがこれは，SDK　略＝Software Development Kit●ソフトウェア開発キットなので，ぼくのようにこのMetascanのユーザーには関係が，無い。
————————————————

以上，Nov. 17, 2022記。

追記Nov. 18, 2022：　後述するように，LiDAR測量中に，Proへアップグレードが迫られて，パスワードが通らず，何故か，その次善の策として？，アップルストアのパスワードの更新が迫られた。それゆえ，metascanのパスワードの更新をしておこう。
１　iPhoneのMetascanのホーム画面の最上段右端の…をタップ。
２　Settingsをタップ。この最上段に，
Manage Pro subscription (150 photo scans left)となっている。（後述のように路上で購入したので）これを選択すると，Metascan Pro 月額￥780　更新日: 12月17日，となっている。この下に「サブスクリプションをキャンセルする」というボタンがあるので，更新日が近づけば，これを実施する。
４　Settings > Manage account に入る。Emailとして以前登録したメールアドレスがあり，現在主に使うものに変更した。そうすると，これに対応する新たなパスワードが求められるので入力した。その後，赤地の”Log in”ボタンが表示されるので，それをタップすると，新たなメールアドレスとパスワードの入力が求められるので，先に入力したものを再度入力すると，ログインが完了する。これで自らの情報を把握できたので，安心だ。

２.3　LiDAR測量時の問題点

　この節を用意はしていたが，本当に問題点が出るかどうかは，わからなかった。本日午後４時過ぎから始めたのであるが，終わったのは午後５時半を過ぎた。そして，図39の想定ルートそのものだけでも，達成することができなかった。

１　秋の夕べの西日を背にして東方に，LiDAR測量を始めた。loc. 3-60からloc. 3-44に向かって山麓線の南側の歩道を歩いた。自らの影法師が撮影されるのを気にしつつ，歩いた。結構，普通に歩いていたがLiDARは地面を捉えていたように思う。loc. 3-42（山麓線の北側ではあるが）に当たるところぐらいからか，反応がにぶくなったので，ゆっくり進む必要に迫られた。いま思えば直射日光が無くなった頃からだと思う。
　このルートは図39の予定には無かった。ぼくの住居そばの南西隅のloc. 3-61にあたる石丸二丁目の交差点を信号のみどりの内に渡りきれるかが気になったのである。無事渡りきることができたので，もうそのまま，山麓線を東に向かったのである。

３　さて，つぎには，3-42まで移動して，ここから出発したのであるが，3-39に到着する前に，Proにアップグレードする前と同様に，LiDAR測量の継続ができなくなった。第１回目が66MBなのに，第２回目は27MBに過ぎない。因みに第３回目は20.6MBでこれはMetascanの限界ではなくて，ぼくが終了したことによるものだ。
　結局，フリーの段階で一定程度の負荷を与えると，そのユーザーに対してProの利用を勧めるという形だ。ユーザーとしては，Proを購入すればこの限界が無くなるって，思うよねえー。でもそっそれはMetascanの有料ユーザー獲得の戦略であって，ソフトウェアの限界は全く超えることはでーきないんだねー。

４　今回の体験では，ちょっと驚いたことがある。
Taking good scans requires practice. Here are some tipsとして，次の項目がある。

Scan bright, well-lit areas and try to avoid capturing small objects.
Make sure your camera lenses are clean. Wipe them with a cloth before starting.
Check that the tracked feature points (colored dots) appear stable before you start scanning.
Aim to keep between 0.5 to 3.0 meters between you and the surface you’re scanning.
Avoid moving too quickly – it causes camera motion blur.
Avoid transparent, shiny or reflective surfaces such as windows, metal or mirrors.
Avoid any moving objects, people or animals.

このアドバイス群の最初，「Scan bright, well-lit areas」の意味がわからなかったが，今日の試技でよーく観念できた。図41はMy scansというホームページ。この左上のものが，暗くなってからのLiDAR作業のものである。Photoshopの低画質化で，3-39to3-61のファイルでも線が見えているが，ぼくのiPhone 12 Proの画面では，他の２件からするとほぼ見えない。その理由は暗い環境での撮影のためである。

　図42は暗い場合，色が再現されず，ほぼ黒色になっている。かつ，認識能力が落ちて，読み取れない部分が透明に抜けている。ただこの図42は街灯のそばや住宅の明かりのそばでの現象で，明かりが近くに無い場合は図43のように”Tracking limited”と表示され，読み取ることができなくなる。で，また街灯のそばに行くと，図42のように黒色で読み出す訳である。
　実際に計測したいのは山林中で，町中と比べるとかなり暗いので，できるだけ太陽光が高くて雲が無い時が良いということになる。LiDARでは雨は敵とだけ思っていたが，曇りの日も良くないということである。簡単に納得できる表現で言えば，光学カメラでの撮影と同じということである。

２.4　ファイル出力

１　My Scansのファイルの表示で，最上段のSelectボタンをタップすると，ファイル選択画面になるので，今の場合，図41のルートスキャン３ファイルをタップする。そして，下段のアップロードアイコンをタップする。
２　ぼくが実験検証した Metascanの出力からテキストファイルを得る が最も参考になる。この結果によれば，LiDARモードで，表現力の高いポイントクラウドを得るのには，ply形式が良い。なお，画像的な表現力はぼくの経験からすると，mesh形式はFXB形式が良いので，この二つを出力してみることにする。
３　１で選んだ３ファイルについて，アップロードの書式としては，MeshとしてFBX，Point CloudとしてはPLYを選ぶ。なお，平面直角座標系との関連がわかりやすいのではないかと，XYZも選択することにする。AirDropを使ってmacに送った。
４　macのParallels DesktopにインストールしているWindosws X内のCloudCompareを立ち上げて，スキャンファイルを見ることにした。

２.5　現地でのLiDAR測量の適当な手法は？

　Nov. 18の反省に立って，今日Nov. 19にもMetascanを実行した。その結果わかったことを踏まえて，このページに記録したいと思うが，明日からこの調査旅行なので，まとめる前に，気付いたことをここに示したい。
１　懐中時計とフィールドノートが必要
２　もちろんiPhone 12 Pro（満充電）と，携帯バッテリー。昨日はトータルの移動時間１時間半ほどでバッテリー残量が50%，今日は実働１時間ほどでバッテリー残量66%だった。大饗石の測量時間は不明だが２時間余りではないかと思っている。
３　iPhone 12 Pro付属の時計で，タイマーを15分間に設定にする。昨日の経験で20分ほどでMetascanが記録を強制的に停止するので，LiDARのセッションはそのまま続けて，自家製のマーカー１をまずはアラームが鳴った位置付近にセットし（マーカー１は動かさない），次に，20m?ほどスキャンしながら進んでマーカー２をセットして，このマーカー２をスキャンして，このセッションを終了する（マーカー２も動かさない）。終了すると，processingを開始する。継続時間によるが最大3分間ほどが必要である。LiDARモードは，サーバーへの写真のアップロードが必要な写真モードと異なり，計算所用時間は短い。なお，計算終了後，測量シリーズがわかるような名前でファイル名を付けた方が良いだろう。
　次のセッションは，残していたマーカー１に戻る。まずはタイマー15分間を開始して，新たなスキャニングを始めるのであるが，マーカー１を含めてスキャンを開始する（マーカー１を回収する）。残していたマーカー２まで進みこれもスキャンする（マーカー２も回収する）。そしてこのセッションを15分のアラームが鳴るまで続ける｡以下同様である。

　図44にはLiDARスキャナーの位置を示す。なお，図中の三つの大きなレンズは，

超広角
・焦点距離13mm
・視野角120度
・絞り値ƒ/2.4
・5枚構成のレンズ
・レンズ補正
広角
・焦点距離26mm
・絞り値ƒ/1.6
・7枚構成のレンズ
・光学式手ブレ補正機能
望遠
・焦点距離52mm
・絞り値ƒ/2.0
・4倍の光学ズームレンジ（2倍のズームイン/2倍のズームアウト）　接写はこの望遠レンズが使われると思われたがそう単純ではない。「接写」したつもりで，iPhoneの写真アプリでその写真を選んでその情報を見ると，使用されたレンズを見ることができる。接写したつもりであっても，広角カメラ 26mm f1.6の場合もあるし，望遠カメラ 52mm f2の場合もある。
・最大10倍のデジタルズーム
・6枚構成のレンズ
・光学式手ブレ補正機能

である。なお，右上の小さな薄茶色に見えるのはストロボだ。

　LiDAR撮影の際には，このLiDARスキャナーの表面の汚れを布（紙は決して使ってはいけない，レンズなどに傷が付く）で拭き取ることも必要だ。スキャン移動中に脚が入るのがまずいことと，レーダー光の適正な感知範囲が0.5〜3.0mであることを考慮しつつ，iPhone面を45°程度頭を上に上げるのがいいようだ。そうすることで先の感知範囲が広がり，歩行移動速度への対応も改善されるように思う。

追記，Dec. 13, 2022：　LiDAR測量の際は，スタート時からiPhoneに充電器を付けて実行した方が良いようだ。少なくとも30分ほどの使用であれば，iPhone本体のバッテリー残量は変化しない。

以上，Nov. 19, 2022記。

３　測量結果をCloudCompareで平面直角座標系に載せる準備

　もう，このページを書いて二十日ほどが経ってしまった。峰山町の大饗石のLiDAR測量準備のために，このページを開設したのであるが，Nov. 21には大饗石のLiDAR測量は終わっている。
　大饗石のLiDAR測量をまとめる前に行きがかり上（そしてネット上の誰かのためにも？），このページを完結させる必要がある。これまでの石丸付近での撮影ファイル群のすべてを処理する意欲は失われている。そこで，Nov. 19のラストトリップだけ，まとめたいと思う。このラストトリップはこの一連のトリップのうちで，LiDAR撮影能力が最も高まった時のものである。
　My Scansのうち，当該ファイルを選んで，meshファイルのうち，fbxは，airdropを使って，macにアップロードできた（38MB）が，point cloudファイルのうち，ply は当初airdropでmacを検知できず，Google Driveにアップロードしようとしたが途中で失敗，再度airdropを使ったらmacを検知できて，今，アップロードできた（289MB）。あと，point cloudのxyzを選んだ（zipアーカイブで344.5MBであるが解凍の後に開くことができる）。

３.1　ハンドホールの蓋と三等基準点の関係

　図45ではこのハンドホールの中央のLiDAR測量座標値を示しているが，この点は必ずしも3等基準点に該当しない。この蓋を開けてこの蓋の中央点と基準点との対応を見る必要がある。しかし，作業上，別の観点がより実際的と思われるのである。以下，国土地理院三等基準点の３点3-61，3-41，3-40とハンドホールの蓋の関係をまとめたいと思う。
　まずは，図45の3-40である。ハンドホールの蓋の画像は図19（Loc. 05）を利用した。ホール内の真鍮鋲の画像は図28のものである。ホール蓋とホール内の関係を捉えるには，右写真の蓋の外周から作成した円を左の写真に移して写真サイズを揃えなければならない。さらに，画像上のxy軸を平行にしなければならない。左の写真の真鍮鋲はかなり風化しており，真鍮鋲の外周が不明瞭のために，正方形の枠を設定する必要がある。図46の解像度は低く，左写真の真鍮鋲に設置した黄色の枠線が見にくいが，そのような措置をしている。そして，穴の中心から真鍮鋲の中心へのベクトルを求めた。その長さは6mmであった。右の写真の中心から右上方向に短い白線がみえるが，この先端が真鍮鋲になっているのである。この作業や今後の作業のエラー値を考えるとほぼ一致していると言えるが，エラーの重なりを排除するために，一応，この成果を生かして，CloudCompareでpickingする必要がある。蓋上面から真鍮鋲トップまでの深度は16.4cmであることを考慮して，平面直角座標系との対応関係を得る必要がある。以下，3-41と3-61の作業結果を図47と48に示す。3-41では中心位置が2cm近くあり，深度は14.0 cmであった。3-61では中心位置が1.92cmで，深度は14.8cmであった。

３.2　三等基準点を含むLiDAR測量例

　３点の測量基準点情報を使って，一定の程度の精度が得られるかをチェックすることになる。

　図49ではCloudCompareの画面の説明をしている。このファイルはfbxであり，基準点は３点（図中の3-61, 3-41, 3-40）をカバーしている。図39のマップと対照すると図49のスキャン画像のマップ上の位置を知ることができるが，全く方位情報が無いことがわかる。そしてこの図49は上空から見た画像である。この図49の画面の右下には小さく座標系が提示されている。図49ではその部分を拡大して配置している。スキャンルート図は適宜矩形域に配置されている。この図の横軸方向はX，縦軸方向はZとなっており，深さ方向がYとなっている。つまり，左手座標系になっている。この表示は図49の左端のツール群のset back viewを選んだ結果であり，CloudCompareからすると，set front viewでは右手座標系なのである。Metascanでのスキャンデータはそういう形になる。スキャンアプリによって異なると考えて良いだろう。fbxファイルはデフォルトではこのようになる。point cloudファイル形式の場合，CloudCompareに取り込む際に指定することができる。
　point cloudから得られる画像の鮮明度は低く，この種の作業にはfbxを使うので，どうしてもこの限界がある。で，国土地理院の基準点は平面直角座標系だから，左手座標系になるが，単純に対応させることはできない。もちろん，LiDAR座標値には方位情報はなく，単に軸配置を次に示している。
　　LiDAR＿＿＿＿＿_ X Z Y
　　Plane_Cartesian_ Y X Z

以上，Dec. 13, 2022記。

３.3　三等基準点を何とか４点含める　Dec. 13, 2022

　図49のスキャンが大饗石調査前の最後のスキャン試行であったが，ここに含まれる国土地理院の三つの基準点付近を拡大表示すると，3-61と3-41のハンドホールの蓋の表示の鮮明度は低かったので，図47と48に示した拘りは十分に生かすことができないことがわかった。残念だ。
　図49でaligningで指示したアイコン上にマウスを載せると，Aligns two clouds by picking (at least 4) equivalent point pairs，と表示される。基準点が少なくとも4点必要と言っている。CloudCompare開発者の指示には，「少なくとも３点と４点の場合があり一定しない」が，アプリのツールにmouseをホバーhoverする際に見える本段落はじめの指示が適切なのであろう。
　そこで，本日Dec. 13, 2022には，一つのスキャンで基準点を4箇所含めるべく行動した。図49では3-61，3-41，3-40の三箇所が含まれるが，図39のマップで見て，さらに北上して，3-39を追加したいと考えたのである。天候に恵まれた。iPhone 12 Proの頭を45º上げて，ゆっくりとスキャンしていった。この速度では図49の範囲がギリギリ取得という結果になった。到底，3-39を追加することはできない。
　iPhone使用中に時間を見ることができないので，懐中時計を持参して計測すると，MetascanでのLiDAR測量は最大10分間に過ぎない。limitに達する10秒前ぐらいだろうか，警告が出て終了してしまう。この開発会社info@aboundlabs.comに先ほどメールした。その内容は，I know your Metascan app is best among scanning apps for iPhone.  I am sorry not to get more 10 minute long scanning.  Please show me how to clear this limitation. Thanks alot. Dec. 13, 2022. である。10分間は余りに短い。何とかならないものか。なお，もちろん撮影範囲をダブりつつ，断続的な撮影をすれば，Cloudを繋いで行くことはできるが，精度は落ちるし，短い人生も使い切ってしまう。
　iPhone 12 Proを45º傾けて，ゆっくりと歩いた場合，ぎりぎり，3点をカバーすることができる。基準点近傍については，丹念に一周している。4点をカバーするには，iPhone 12 Proの頭を上に30º傾けて，かなり早足で歩く必要があった。このトライの１回目は何とか成功したが，同じぐらい早く歩いたつもり（12月4日のホテルでの左足甲上の南京虫禍が展開中で化膿して腫れていて靴の圧迫が辛いという中での早足）であったが，疲れもあったのだろう，帰りのトライは失敗した。この早く歩いてのLiDAR撮影はかなり不完全なスキャンになる。スカスカほどではなく，一応連続させたつもりであったが，出来上がったものはかなりスカスカだ（スカスカでも空間の継続性は問題無いようだ？）。ただ，4箇所の基準点付近は一巡りしたのでハンドホール（このページ中，過ってアームホールなどとしている場合がある）の蓋はほぼ鮮明に捉えることができた。
　なお，最後の4箇所の基準点をカバーすべく実施した12月13日最後のLiDARスキャン往復では，懐中時計とともに，充電器を使用した。その結果，iPhone 12 Proのバッテリー残量はほぼ100パーセントが維持されていた。iPhone 12 Proの電池残量が少なくなったから予備のバッテリーを使うのではなく，LiDAR測量やGPSの連続的利用の際には，スタート時から予備のバッテリーを使うべきだと思う。なお，この予備のバッテリーは Sanyo USB出力付リチウムイオンバッテリー KBC-L2B（INPUT: DC 5.0V, 500mA/1A; OUTPUT: DC5.0V, 1A MAX; 充電式リチウム電池: 3.7V/5000mAh 〘19Wh〙 ）であるが，現在はパナソニックに吸収されたあと，生産終了。

以上，Dec. 14, 2022記。

３.4　三等基準点４点の平面直角座標値

　3-39が新たに加わったので，「３.1　ハンドホールの蓋と三等基準点の関係」に追加する必要があり，イラレでの作業の後，図48の次に追加して図48’としたい。

　次に，４基準点それぞれについて，CloudCompareでpoint pickingを実施することになるが，そのまえに，４基準点の平面直角座標値をここにリストアップする。本ページの1.1に紹介した基準点成果閲覧サービスから直接入って，ログインすると，その後は，図50のように，地図上の検索結果に基づいて表示された基準点アイコンをクリックした際に表示される基準点詳細の成果表pdfをクリックすると閲覧できる。ぼくのmacの環境では直接印刷することはできず，表示中の成果表のスクリーンショットを印刷することになる。

　次の表１に結果をまとめている。

国土地理院基準点成果表 in meters
平面直角表系VI	Ｘ northing	Ｙeasting	Ｚ  海抜高度
3No.39	-128119.067	-45939.721	130.52000
3No.40	-128258.355	-46044.227	127.62000
3No.41	-128364.148	-46214.319	123.77000
3No.61	-128607.078	-46307.813	109.90000

４　LiDAR測量クラウドでのpoint list picking

　一つのcloudから複数の座標情報を得るには，このpoint list pickingツールを使用する。CloudCompare Version 2.6.1 – user manual では，pp. 89-90 に掲載されている。使用勝手がよく結果は，表のテキスト形式で得ることができる。LiDAR測量結果についても後掲予定の表２を得ることができるのである。表１と表２から，高度や平面直角座標での位置の対応関係，つまりLiDAR測量の信頼性を検証することが出来るはずである。何故か，mac内のCloudCompareではpoint list pickingツールで使用できるウィンドウサイズが小さくて，mouseのCloudCompareを使わざるを得なかった。４点すべてをpickingしないと一まとまりの表にはならないので注意が必要だ。
　FBXファイルの画質が圧倒的に良いので，これを使用する。図51のようにまずは基準点3-39を対象に実施した。

　次に図52のように，基準点該当地点3-40をpickingしようとするが出来ない。左ペーンでは，図51と同様，Mesh9となっている。つまり，meshファイルではMeshを超えてこのコマンドを実行することができないのである。マニュアルには一つのクラウドで実行できるとあったが，meshファイルの個々のMeshはいわば別のクラウドになっているのである。meshファイルでは，事実上，point list pickingツールが使えないのである。

　そこで，FXBファイルを諦めて，図53のように，point cloudファイルのplyを使うことにした。

　まずは3-39該当点をピッキングした。画像が不明瞭でFXBファイルのようには実行できない。

　図55のように，二つ目のピッキングもできた。

　図56，図57のように3点目3-41，４点目3-61もピッキングできた。

　図58のように，4点の基準点該当点をピッキングすることができた。左の下段ペーンで”Show name”にチェックを入れているので画面中にファイル名が表示されている。なお，この図58では，右下隅のXYZ軸表示を拡大している。

　図57の段階で，画面右上の表のメニューのフロッピーアイコンをクリックすると四択があって，ここではlocal index, x,y,zを選ぶ（マニュアルp. 90 Export optiions参照）。出力されたテキストファイルを整理すると次のようになる。

５　LiDAR測量結果の座標値と平面直角座標系基準点座標値との対応

　大阪府は，兵庫県を除く近畿地方をカバーする平面直角座標系６（図59）に該当する。原点は福井県の北部にあって，大阪府だとこの原点の南西に位置し，例えば表１のように，X軸もY軸もマイナスの値となる。石丸は大阪府の北縁に近く，南北軸と東西軸を比べると，原点からの南北軸の長さは大きい。南北軸はnorthing軸，東西軸はeasting軸と言い，前者をX軸，後者をY軸と言う。Z軸は海面から高く離れるほど＋値が大きくなる。この関係は図60の左手系の図2-3に当たっている。
　写真測量やLiDAR測量の結果は右手座標系で表現されている。Metascanによる測量結果を見ると，mesh系とpoint cloud系に分かれ，この両者で異なる座標系が使われている。meshのfbx形式は図49の右下隅の座標系表示（方位を除いてルート表示がマップと対応しうるback view）からすると，左手座標系が使用されている。これに対し，point cloudのply形式は図58の右下隅の座標系表示（top view）からすると，右手座標系が使用されているのである。
　図58では，ply形式のLiDAR測量結果が示され，左右X，上下Y，奥行きというか手前への出っ張りZとなっている。この図では方位情報がなく，単に矩形域の表示を実行するために，XY軸が設定されているのである。iPhone 12 Proの重力方向（Z）軸だけが，平面直角座標系のZ軸方向と一致しているのである。
　このように考えると，LiDAR測量結果を平面直角座標系に載せたい場合，XY軸の対応関係は問題にならないとは思うが，その対応関係を実行する際に，Z軸を４つの基準点に平行移動して，その後回転することを考えると，LiDAR座標系が右手系で，これを平面直角座標系の左手系に合わせることには違和感があるのである。
　それでは，上掲の４基準点の「X値，Y値，Z値」の順を，「Y値，X値，Z値」の順にして，後のassigningを実行すべきかと言うと，そうはならないと思う。基準点だけ変更すると他の何十万以上の点とは独立した作業なので，完全に過ってしまう。つまり，LiDAR測量の座標値の配列を全部替えることは難しくは無いが，それよりも，表１（平面直角座標系基準点の４座標値）で，（X northing, Y easting）を，（Y easting，X northing）に替えることで，平面直角座標系を右手座標系に替えることができる筈である。後にassigningを実行して確かめたいと思う。

　なお，ハンドホール蓋上の基準点の特定作業について，FBXファイルでの方がPLYファイルでよりも容易であり，FBXファイルでは，point list pickingを１点に限定するか，CloudCompare Version 2.6.1 – user manual pp. 87-89の”point picking”を実施して，座標値を求めて置くのもいいと思われる。FBXファイルの3-39対応の画像は，図51に示していて，この右上のpoint picking結果の表を見ると，次の最初の数値行のようになっている。この座標値と，plyファイルの対応関係を見ると（表２），次の二番目の行のようになる。
————————————————
FBXファイル　 X: 42.35611, Y: 14.310058, Z: -304.504669
PLY ファイル X: 42. 36515, Y: 304.47617, Z: 14.31222
————————————————
　鉛直軸は，FBXファイルではY軸で，PLYファイルではZ軸になっている。この対応関係を知って，基準点対応座標値を読み替える必要がある。とはいえ，測量的な感覚から言うと，FBXファイルの結果には違和感がある。CloudCompareの表示の際も，set back viewの形ではじめて，平面図を得ることができるし，Z値がマイナス値になっているのは変換はできるのであるが，かなり問題であり，当方の座標値を扱う測量では，point cloud系のファイルが適当であることを改めて思う次第である。

６　LiDAR測量の現実空間の高い再現性

　海抜高度と距離の再現性を評価すべくエクセルで処理した。表３はその基礎的データである。

　海抜高度の再現性を表４に示す。決定係数0.998だから十分な結果であった。

　距離の再現性を表５に示す。３次元空間での距離計算を実施した。その結果，決定係数は1.000になった。

　予想以上の結果となった。MetascanのLiDAR撮影が10分間に限られているために，４基準点での一周撮影を含めて，850mほどを時速5km余りで歩いた。撮影画像は一応繋がっているとは思ったが，実際はかなり脱落部があった。それでも，位置情報は継続されていて，このような結果になったのである。
　当方の暮らす石丸で４箇所の三等基準点を何とか入れ込むという条件での作業であった。実際のフィールドワークでは，このような基準点を利用することはできず，潮位計測とGPSによる3D情報に基づくことになる。光波測距儀を使って基準点を幾つか設置して，その上でそのラベルを貼ったポイントをつなぐ形での測量ゆえに，石丸のようなタイトな条件では無い。
　一人でも，光波測量，LiDAR測量は，無理なくできる。断面測量も複雑な地形を記録できるので，これまで以上に精緻な断面を描くことができるのである。Metascanを使った写真測量やLiDAR測量では磁北情報が無いので，光波測距儀での磁北セットが重要である。
　LiDAR測量だけでラベリングした近接した二カ所の磁北からの角度を計測して，測量成果に磁北線を描くことは可能である。今後は磁北を意識した測量をすべきだと思っている。図56

７　平面直角座標系に従ってLiDAR測量結果をグリッド平面座標に

　CloudCompare操作ガイド日本語メニュー版.pdfというものが公開されている。これは，全般的なマニュアルではなく，スキャン（写真とLiDAR測量）データをレファランス座標点に対応させるだけがテーマである。ここではこれを使用して，LiDAR測量の結果を国土地理院の基準点（平面直角座標系）にレファランスする作業を実施する。最も広範なマニュアルは，CloudCompareの開発者が作成した CloudCompare Version 2.6.1 – user manual であるが，この日本語メニュー版の使用例は紹介されていないように思う。開発者の用例では二つのクラウドを選んで，対応ポイント（またはversion 2.6からはメッシュにも対応）をピッキングする形だけだ。
　この章の作業は，LiDAR測量結果を平面直角座標系６上に載せるということではない。載せることはできるが，ここではそうではなくて，（任意の）グリッド平面に載せるのである。
　フィールドでLiDAR測量を実施して，その結果を自宅に戻って整理するのだけど，ぼくが必要なのは最長1kmほどの断面図や数百メートル四方の範囲の詳細な地形情報である。Metascan in iPhone 12 Proでは，記録時間は10分間に限定されているので，これを超える範囲であれば，座標系の平行移動と回転 に示した方法でどんどんマージして行くことはできる。どんどんとは言っても疲れるので，できれば一気にスキャンしたい。
　とにかく，この章ではLiDAR測量結果を，グリッド平面座標に載せる過程を示したい。グリッド平面座標という表現は地図学では無いだろう。紙地図は普通，平面であり，平面直角座標系６のすべての地図は一つの平面上にある。そういうように設定されている。図59の近畿地方を中心とする平面直角座標系６は平面を為している。その上の基準点を使うのでグリッド平面座標とここでは表現している。

　CloudCompareではそういうAlign (point pairs picking) （CloudCompare Version 2.6.1 – user manual pp. 101-104）のメニューが用意されている。以下，実行過程を示す。

　図61では，LiDAR測量の結果得られたpoint cloudと，国土地理院４箇所の３等基準点（表１）が見える。これは，左ペーン上部のpicking listファイルを開いているからである。これが選択選択されているので，コンソールの矩形はこの４点がカバーしている。

　残念ながら，４点からなるpicking listはこの作業では使えない。図62のコンソール右上の表の上部（赤い矩形域には，読みにくいが，show ‘to align’ cloud，と表記されている）には，LiDARクラウドで新たにピッキングした４点のうち３点が見える。下部（黄色の矩形域には，読みにくいが，show ‘reference’ cloud，と表記されている）には，表１の情報を入力している。ただし，前述したように，表１の(X,Y,Z)を，(Y,X,Z)に替えて入力している。

　図63には，コンソール右上の表の最下段の ‘align’ ボタンをクリックした結果を示している。alignの実行の結果，LiDARクラウドはグリッド平面上に載ったために，図39の3-39から3-61までの赤ルートと一致するようになった。この章の求めたものである。

　この値が3.67というのは，４基準点の位置の3D平均のずれが3.67mなのである。およそ850mを時速5km余りで歩いて取得した結果である。これをどう考えるかであるが，CloudCompareの例でも類似の値が見える。地形学的な研究ではこの程度の誤差は許されると思う。ぼくが野外調査で測量する場合は，国土地理院の座標値は使えず，光波測距儀でのいわば基準点測量を実施するし，基準点密度はより大きいので，さらに問題はないと思われるのである。
　なお，以上のaligning過程では，実はLiDAR測量のハンドホールの蓋をそのまま，海抜高度に対応させてしまった。LiDAR測量結果では蓋面しか反映していないので，国土地理院の基準点の海抜高度から蓋面から真鍮鋲までの落差を差し引くべきであった。しかしこれをしたからと言って，RMS値3.67に反映するかどうかはわからない。

　図65は，修正アドバイスである。当方の他のページでもこのテーマは記したような気がする。上掲CloudCompare開発者のマニュアルのp. 23にはこの説明がある。平面直角座標系の数値が非常に大きいことでこのメッセージが現れた。地理座標系ではこのような大きな値になるのは珍しくないこともこのマニュアルには記述されている。石丸のような狭い場所で，平面直角座標値をそのまま使わなくても，数十万の値のうちで，下3桁ぐらいに搾っても問題はないとは言える。

　図66では，CloudCompareだけを選んでいる。

　align後に得られた後，保存を選ぶと図67のコンソールが現れる。ぼくからすると，このデータはGrass GISで使えるぐらいであるが，3D計算をするのはこのCloudCompareの方が簡便でエキスポートする必要性はない。point数は75万余りになっている。

　図68はASCIIポイントで表示した部分である。このように明らかにクラウドは切れてしまっているが，座標系の継続性が持続されていることに驚いている。

　図69では，変換済みのクラウドと４基準点を表示している。レファランス過程を経て生み出されたグリッド平面に載せられたクラウドは基準点枠のすぐそばに位置しているのである。

　図70にはグリッド平面のクラウドだけを表示している。左のペーン上段で選ばれているクラウドに対応しているのである。

おわりに

　以上，国土地理院の基準点を利用してLiDAR測量結果を研究に使えるようにするという目的は果たしたと思う。ここまで読み込んできた人が居て，さて，と思わないだろうか。断面測量ならば，ルート周辺の不要なクラウド部分を削除して，一定の幅をもったストリップを再現するところまで見てみたい，ということである。まあ，これは，今回，ゆっくりと歩いて３基準点を含めた連続性の確保されたクラウドで実行はできるのであるが，舗石や雨水口などは稀にあるが，まあアスファルトだけの道のそのストリップを作ったところで，面白くもないだろうと思い，止めにすることにした。

　つぎは，元々の目的物である大饗石のクラウドを見てみることにする。ああそうだ，その前に，年賀状をなんとかしないと。今後止めるかも，考えないと。ハードワークだけど。まずは，文案だなあ。それが決まったらFileMakerでの処理に過程が続く。12月20日火曜日はアイスバーンの可能性がないのならタニハへ行くことになるだろう。

以上，Dec. 18, 2022記。

はじめに

　ペーパーにするための具体的作業について，Webページ作成というよりも，悉皆ではなくて，節目に近い作業プロセスをここに記して行きます。議論の場ともしたいと思っています。今後の作業を思いつくまま，箇条書きで，次に示します。なお，現地の看板や役場のWebサイトでは，「犬の門蓋」と表記され，いぬのじょうふた，と読まれていますが，他の観光サイトでは，じょうぶた，とも表記されてます。鹿児島県のもともとの発音表記は，ローマ字で綴ると，いんぬじょうふた Innujofuta（外務省ヘボン式）となります。ですので，「犬の門蓋」も，いんぬじょうふた Innujofutaと読みたいと思います。

　Aug. 8, 2022追記： つまりこの投稿に三ヶ月振りにもどった。これから読み直す過程で理解しにくい部分を補足する。（補足： ）という形で明記。また放置して，本日はAug. 20, ああ，Oct. 13, 2022，なかなか戻れなかったもうNov. 6, 2022。

1. 　このページの内容であるが，前ページ　Cloudから抽出された連続プロファイルの利用2　まで進めてきた犬の門蓋南岸の旧汀線の復元です。
2. 　これが終わると，次に同種の作業として，沖永良部島の宇和美崎の旧汀線高度の復元です。
3. 　次には，大津勘ビーチロックの同様の作業ですが，リスト（補足： この箇条書きの番号）１，２の旧汀線復元との関連が重視されます。すでに得られたC14年代値と旧汀線高度との関連を示します。
   　大津勘ビーチロックは，新旧大きく２部層に分けることができますが，旧の方には目立ったサンゴ礫などもなく全層砂質になっています。新の方は現在のビーチ同様，サンゴ礫などが主体となっています。（補足：この認識は画期的だと思う）
   　この出現形態は，徳之島空港南方の岬部（次の図１の断面を取ったところで，高校生バイトと木庭が実施）の主ノッチ以下の構造と対応すると思います。（補足：以下，Higher 1, 2, 3は高いものから低いものへ） つまり，隆起サンゴ礁原はHigher 3に対応しており，（補足：より高位の）Higher 1 and 2は隆起サンゴ礁とは直接関係が無いということです。この時代のビーチの堆積物が，大津勘ビーチロックの砂質の旧部層に対応すると思うのです。
   　海進過程で造礁サンゴは海底に付着してゆきますが，海進が早くてサンゴ礁（補足：サンゴ礁とは海面まで達した礁原のこと）ができません。そして最高海水準（補足：Higher 1）の際にはサンゴ礁は形成されず，海退が始まってから，やっとサンゴ礁ができたのです。そういう流れが，この徳之島の研究から明らかになったと思います。それを訴えるための種々の本格的な作業がこれから始まります。
   　年代測定試料を徳之島の犬の門蓋南岸付近で採取し（補足：別所氏と），何とかクリーニングを続ければ，加速器用の試料とX線回折用の試料は採取できると思います。粗っぽくみて，４試料だけがこれに該当します。できればこのクリーニング作業を川口さんにお願いしたいと思っております。LED照明下での実体顕微鏡での作業です。ドラフトチャンバーはありませんが，掃除機で吸いながらのプロクソンでの作業になります。（補足：経験的に，粉塵はこれで完全に封じ込めることができると思います）
4. 　（補足：沖永良部島最北端の）空港北の津波堆積物とペデスタルを構成する隆起サンゴ礁地形をまとめます。空港の滑走路の延長にこの場があって，ドローン撮影は無理と別所氏によって判断されましたので，残念ながら詳細な画像情報はありませんが，何とか空中写真判読をして，津波堆積物の分布を捉える必要があります。（補足：残念ですが，撮影は低空で可能だったのでは？） これも川口さんなら可能かと思います。どうでしょうか。パソコン上で肉眼立体視をして地図化してゆくか，簡易実体鏡で判読などして，分類図を作成して頂ければと存じます。ぼくはパソコン上で実施し，二人の判読結果を付き合わせて，一つの分類図を作成したいと思っています。（補足：川口さん進んでいますか？）
   　拘るのであれば，その分類図を現地に持参して，津波石と礁原の関係を詳細に検討すれば良い成果が出ると思います。この方面の研究は一つのペーパーになると思います。現地では，別所氏も可能であれば，一緒に写真およびLiDARでの撮影をして，繋いで行けば，一つのcloudを得ることができると思いますが。（補足：もう難しいだろうなあ。ぼくのiPhoneの写真で可能かも知れない）
5. 　すでに実施した断面測量図なども併せて，ペーパーにしてゆくことになるかと思います。

いま，思いつくことを示しました。それでは，次の章へ。

　次の第１章は，Cloudから抽出された連続プロファイルの利用１　から移動した。研究内容を公開したくないからである。Mar. 28, 2022記。

１　海食崖のgapを読むための基準を提示する

追記Nov. 6, 2022:　図１と犬の門蓋南岸とは緑藻類と紅藻類の分布が異なるようであるが，フィールド写真やGoogle Earth写真で再度，比較する必要があるだろう。図１では，present MSL platformとpresent High Tide Platformには緑藻が分布しているようであるが，これも再度確認する必要がある。
図１は当初，2019年調査結果としていたが，2020年春の誤り。エクセルファイル名は，徳之島断面測量2020年春.xlsxである。川口さん，別所さんに，添付で送っていると思うのだけど。

　この断面図を解く詳細な思想は省略する。過去４年それぞれ春の大潮時に調査してきた。そろそろペーパーにしなければならない。この図１の左手は岬部の断面，右手は湾入部の断面である。岬部はすべて琉球石灰岩の石灰藻球岩で構成され，完新世隆起サンゴ礁は無い。湾入部の高位プラットフォームはほぼ隆起サンゴ礁で構成されている。このプラットフォームを図中ではwave-cut Raised Coral Reefとしている。過去の海水準としてはHigher 4 Levelとする。離水過程で，中等潮位プラットフォーム形成過程の影響下にあって，湾入部断面で見るように，11/1000（0.628゜）海方に傾いている。
　　Higher ３レベルについて：　もちろん湾入部の断面に見える隆起サンゴ礁はある時期の間，中等潮位プラットフォーム形成過程にあった。そして，1.41 m（湾断面の完新世後期サンゴ礁上限）〜1.65m（離水プラットフォーム上限）近く離水した。この隆起サンゴ礁は当時の潮位を現在の改正数をそのまま適用すると，山漁港の大潮升1.90m，中等潮位1.11mだから，（1.41 or 1.65）+ （0.79〜1.11）= （1.41 + 0.79）〜（1.65 + 1.11）= 2.20 〜 2.76 a.s.l.となる。で，図１の岬断面でのHigher 3レベルの陸方端の高度は2.38mであり，2.20 〜 2.76 a.s.l.の幅に入っている。つまり，Higher 3は，湾断面の隆起サンゴ礁を生成した旧海水準に当たっているのである。

　図１には緑色の線分が４本（１本は破線）ある。岬部分には，Higher 1, Higher 2 (broken), Higher 3，湾入部にはHigher 4 （wave-cut Raised Coral Reef）がある。岬部分のHigher 1 〜3はすべて，湾入部のwave-cut Raised Coral Reefの線分を機械的に平行移動したものである。図１の岬部断面の海方端には現在の中等潮位プラットフォームの一部が見える。いまだ面的広がりはない。中等潮位プラットフォームの陸側には，規模は小さいが高潮位プラットフォーム（図１のpresent high tide platform）が，（補足： 岬部と湾入部の）何れの断面にも見える。

　湾入部の断面のwave-cut Raised Coral Reefが隆起した後の時間の経過は，現在の中等潮位プラットフォームの幅から測ることが出来るはずであり，この幅が極めて小さいことからすると，現在の海水準に達してからの時間は長くは無いことが想像される。

以上，Mar. 18, 20, 2022記。

　Higher 1レベルについて：　岬部プロファイルの海寄りの高まりはランパートに相当する。 日本の岩石海岸でのプラネーション研究の代表的研究者であるTakahashi Tatsuroや豊島吉則が最も注目してきたものである。ランパートがかつての波食面由来であることを，この断面は示している。この断面の陸端には波食または溶食ノッチが見られる。これに隣接して配置しているのは同断面付近のノンプリズムによるノッチ断面図である。このノッチ断面とHigher 2レベル（破線）の交わる付近にはステップが見られる。そしてこの破線は，ランパート中央部付近のpointとも交わっている。このランパート中央部のpointは実はシリンダー状の凹所の高度を代表している。つまり，破線は明瞭なレベルを示しており，Higher ２は，Higher１に続く海退過程の一つの海水準を示しているのである。

　氷河性海水準上昇期の最高海水準は，Higher 1であり，その後の海退過程で，Higher 2のレベルが示す休止期があり，Higher 3に至って，サンゴ礁が略大潮の最低低潮位または大潮升の平均低潮位までほぼ面的に形成されたのである。ノンプリズムでのノッチに注目すると，Higher 1のレベルより高い部分はほぼ船首型を示している。このレベル時代のノッチは船首型を呈して，その海方には当時の中等潮位プラットフォームが形成されていたと考えて問題は無いであろう。ランパートの頂部はその当時の中等潮位プラットフォームと考えて良い。

　その後，Higher 2レベルまで海退がある。それに応じて，中等潮位プラットフォームが低下する。そして，さらにはHigher３レベルまで中等潮位プラットフォームが低下してきたのである。とはいえ，何故，残存しているのか。湾入部にはHigher１〜３が欠落し，wave-cut Raised Coral Reefが広く分布するのか。こういったことは以前から何となく感じてきたことである。海岸地形学の最も魅力的なテーマであると思う。海面下の基盤岩傾斜，陸域からのmass-wastingというより，水流運搬力との関連があると思う。（追補足：このロジック，今はもうわからない。サンゴ礁が岬部では発達せず，湾入部で広い理由を，説明しているのだと思う。）

　ルーフスロープでは石灰藻球岩の層理が明瞭に見えるが，フットスロープでは深いラピエが形成されて，層理が見えにくくなっている。言い換えると，スムーズなフットスロープ形成後に，ラピエのトップにそのスロープを残して，シリンダー状の深い立て孔が形成されている。図２の写真の手前部分は広いHigher３の離水プラットフォームであり，ここには深いラピエは展開していない。

　　このノッチの出現形態は，プラネーションを作り出す営力の大きなヒントになるが，この議論はここではしない。さし当たり，cloudから得たプロファイルを読む手がかりをここで示した。

２　前ページ　Cloudから抽出された連続プロファイルの利用2　に続いて

　前ページの「 ２　Point list pickingの有効性」，で得た情報をもとにして，犬の門蓋南岸の地形傾斜変換点の意味とその分布を捉えることになる。前ページで指摘したように，profiles上をクリックしてもpickingはできず，fbx上をpickingすることで座標情報を得ることができる。結果的に言えば，profilesから得られるものは多くは無く，結局のところ，profilesを生成しなくても，地形傾斜変換点を把握し，その座標値を得ることができるのである。
　ではあっても，2m間隔でのprofilesは傾斜変換点を捉える位置決めの目安になることは確かであって，そういう意味で不要なものではない。とは言っても，profilesの位置に規制されることなく，fbx-3D画像で傾斜変換点の定高性や連続性を観察して，pickingするのが最も適切と思われるのである。 図3は新たにピッキングしたものである。

　この結果をアスキー出力して，Excelで整頓したのが次の表1である。

以上，Mar. 28, 2022記。

　図１の考え方に基づいてピッキングした。表１には，旧汀線関係で３レベルが認識される。Higher 1で2件，aver. 4.36m，これは現在の出現形態はV-shaped notchであるが，当時は船首型ノッチであろう。その船首と言わば海面との交点がほぼ中等潮位にあったと思われる。海食面の最も卓越するレベルは海面と陸域の交点で最も海面位置の頻度の高い中等潮位と考えるからである。その根拠の明瞭性は未だ無いのかも知れないが（ぼくの学生時代より後に何らかの成果があったかも知れない：　川口さん，ネット検索など宜しく）。このV-shaped notchは，他のHigher 2 and 3と比べると，捉えやすい。そこでまずは，このNotchのみの分布を捉えて，一つのPicked points listをつくることにする。北西縁から始めて南東縁で終了したい。参考になるので，全profileを表示した方が良いだろう。picking位置の目安にもなる。

追記Nov. 6, 2022：　Point #8と Point #9の間，つまり，Raised Coral ReefとMSL platformとの間に，erosional RCRFがある筈かも知れない。元々Raised Coral Reefはなく，#7, #8がerosional RCRFの可能性もある。これより後に，記述されているかもしれない。

　次は，Low water platformにするか。この表現はネット検索したけど，みつからないので，Low-tide platformにする。潮位については，low waterというのが今は主流だと思うけど，プラットフォームについてはlow-tide platformの方がポピュラーのようだ。low-tide platformはGlossary of Geologyにもある。これは，solution platformとあり，これを引くと，次のよう。

“solution platform: An intertidal surface on carbonate rocks, nearly horizontal but not abraded, produced primarily by solution but with contributions by intertidal weathering and biological erosion and deposition (Bloom, 1978, p. 448). See also solution bench. Syn. low-tide plaform.”

とある。solution benchを引くと，次のようにある。

“solution bench: A low bench produced on limestone coasts by the action of fresh water (Wentworth, 1939). Presence of such benches on many desert coasts requires broadening of the definition. Preferred term: solution platform.”

とある。preferred termは，基本語、優先使用語，という意味であり，用語 “solution bench”は，用語 “solution platform”に吸収されて良いようである。後者の定義では，淡水の溶食が重視されている。潮間帯のベンチは海面より上の石灰岩が風化つまり溶食によって溶け去った結果である。そして，現成のベンチのレベルは略最低低潮位より上には，二つあり，一つは中等潮位プラットフォーム，もう一つは低潮位プラットフォームである。高潮位プラットフォームは，高位海水準に関連したもので，現在，ラピエが展開している。

　繰り返すが，Higher １，２，３，隆起サンゴ礁原，中等潮位プラットフォーム，低潮位プラットフォーム，と６レベルが認識される筈と考える。図１には，Higher １，２，３，隆起サンゴ礁原，高潮位プラットフォーム，中等潮位プラットフォーム，以上，６レベルが並んでいる。低潮位プラットフォームは遡上波を避けるために計測できなかったようである。一人でプリズムを移動しており，波しぶきもあって，落ち着いて，写真撮影なども出来なかった。
　図３と表１では，Higher １，２，３，隆起サンゴ礁原=高潮位プラットフォーム，中等潮位プラットフォーム，低潮位プラットフォーム，以上６レベルが認められる。

追記Nov. 6, 2022：　隆起サンゴ礁原=高潮位プラットフォーム，という表現は如何にも変だが，ドローン画像の観察から自然にそういう発想が生まれた物かも知れない。
　図57（修正後）では，MSLに揃って現在生成中のプラットフォームが分布しないことは注目すべきである。

　さて，point list pickingファイル作成の2番目は，中等潮位プラットフォームかと思われるが，まずは，V-shaped notchのpickingを実施しよう。

３　Higher 1, V-shaped notchの picking list

　実際にやってみて，profiles情報は大変役に立った。図４のDB Treeにあるように，fbxファイルのサブディレクトリに，Picked points listが作成される。レベル毎の別々のファイルにするために保存して，ツール内でASCIIファイルで保存して，それを呼び出して表示したのが図４編集画面である。右端にPoint #0から始まり，時計回りでPoint #17までが一望される。座標点の場所は，この図の左端から右端に及んでいる。pointの位置はマゼンダ色であるが，次に作成するレベルについては別の色表示が可能かどうか。

　図4の左ペーン内のディレクトリpicking_list_Higher1.txt，または，サブディレクトリpicking_list_Higher1 を選んで，Display > Display Settingsを選ぶと，Display optionsパネルが現れる。そのLabelsをクリックして開いた表示が，図５である。右下に “marker color” がある。これをクリックしてApply, OKすると反映されるが，残念ながら，他のファイルのpicking_listについても同じ色が反映されるので，個々のグループ分けには使えない。

4　mean sea level platform picking list

　さて，上記のように，別のpicking listであっても，pointの色を替えることができない。次の図６では，両レベルを一緒に表示して，その一部を示すので，限界を知るだろう。

以上，Mar. 29, 2022記。

追加 Apr. 1, 2022：　CloudCompareはmouseマシーンで立ち上げたまま，放置している。いま，見たら，図６のように，cloudファイルfbxで，このMSL platformのPicked point listが作成中になっているようだ。図６のDB Treeの最下段には，picking_list_MSLp.txtがあるので，この名でMSL platformのpickingデータをASCII保存して，これを呼び出して，図６の編集画面のように，表示しているらしい。
　Point #8で終わっているから，全９件である。図７に示したように，Point #3と#4の間にはプラットフォームは無いがどうも，この岬部だけに小さなNotchが分布しており，これがMSL platformに対応するらしい。

　図７の表示のうち，Point #3付近を観察しているのが図８である。

　図８の左下のPoint #0〜3は，MSL platformである。図８の右端には小さなNotchが続いている。で，Point #3とこの小さなNotchの間には，V-shaped notchがあって，より上位のPoint #5のV-shaped notchの規模と余り変わらない。このnotchをどう考えれば良いのか。上述の「Higher １，２，３，隆起サンゴ礁原，中等潮位プラットフォーム，低潮位プラットフォーム，と６レベルが認識される」，としたレベルで考えると，隆起サンゴ礁原（図１断面のHigher 4）かHigher 3になるが，このnotchは侵食地形なので，Higher 3になるのか？　それにしては低すぎるかも知れない。今のところ，ペンディングである。

　さて，図８右端の小さなnotchが手前のPoints #1〜3のMSLp相当だと考えて， MSLpのPoints #3と#4の間の岬部（図７のPoints # 3と$4のポイント欠落域）についてトレースして行くことにする。fbxのサブディレクトリであるPicked points listではこれまで#8となっているので，次の#は自動的に9と成るはずである。地理的には中間部にpointsを挿入することになる。

　Point #3からではなかなかpickingが難しく，#4から時計回りにピッキングすることにする。この岬部のprofilesは，#21〜61に該当し，全部表示して傾斜変換点を探す目安にする。

　クリックしたてのpickingは，ツールパネル左端の🌀マーク（例えば図９の画面右上のパネル）で削除できるが，それより前のものはこれが効かない。で，ところがDB TreeでのfbxのサブディレクトリのPicked points listで，削除したいものを選んでdeleteすると，編集画面のPoint #と連動する。図９では，#3に代わって，#32としたい。#3はMSLpとしては高すぎるのである。

　図10はDB Treeで#3を削除したところの図である。編集画面でも#3が消えている。

追記：元の#3がこれに近接するPoints #0〜#2に比べて高くて，右隣の#31から続いて，#32としたということだ。

　fbxでModelを選んで，Picking ツールを表示したところが，図10であるが。#3の削除での#の欠落を補うように，図11では，一つずれて，DB TreeでのPicked points listでは新たな#3が生まれ，編集画面のPoint #32が#31に変化している。元の#4以上が１減少したのである。

　Picking ツールで，フロッピーアイコン（例えば図11の画面右上のパネルの2番目のツール）をクリックして，picking_list_MSLp.txtファイルを上書き保存した。

　図12がMSL platformの陸縁座標値になる。このような表示だと使いにくい。このファイルを一度deleteして，再度呼び出せば，例えば図5のようになって，扱いやすい。

　図13は，MSL platformの出現形態を確認すべく，用意した。ここで注目したいのは，MSL platformの幅である。pickingした場所でみると左（西）寄りのPoint # 0, 1, 2, 31を含む左の部分では広くて，この図の右（東）寄りの岬部分にはこの面が存在しない。

　図13を改めて見ると，MSL platformは広く，ドローン撮影が捉えている。Higher 1のV-shaped notch画像は呆けているが。それゆえ，この部分について，MSL platform関連の情報を得たいと思う。左手にはMSL platformは，すぐ手前（南）の島様地形も見られる。傾斜変換点ではなくて，platform縁辺のrampart様の高まりの高度分布も得たいと思う。picking listの#はまたまた，不連続ではあるが，続けて行きたいと思う。つまり，#32から左手（時計回り）にMSL platformの傾斜変換点，そして，反時計回りにrampartトップを計測したいと思う。

以上，Apr. 1, 2022記。

　さて，図14のように，point #0の左手から時計回りに新たに，MSLpのpickingを開始した。陸繋島の部分付近の，#34 1.33m，#35 1.52m，#36 1.58mと高いけど，反時計回りで描いたランパート上は，#37〜#42は0.74〜0.91と余り高くない。まあ，沖永良部島でのSpratidal Platformと同様ですなあ。それで，MSLp関係はこのツールパネルのフロッピーアイコンを押して，上書き保存した。

５　low-tide platform picking list

　MSLp関係のpickingは終わったので，一度，CloudCompareを終了（または閉鎖）した方がよい。何か方法はあるかもしれないが，ピッキングを続けると，次から次とPicked points listにつみあげられて行くので，混乱を来す。もちろん，終了せずに，このリストから削除するのも可能ではあるが，精神衛生上，良くない。

　CloudCompareは，何か，Web閲覧と類似したところがある，沢山のファイルを開いても，なんら，重くならない。いいソフトだと思う。さて，また，fbxcloudファイルを開いて，さきほど上書き保存したpiking_list_MSLp.txt（Show labels in 2Dにチェックのこと）も開くが，ピッキングラベルがパノラマ状に表示されるので，一旦削除して，また開く必要がある。このようにして，次のステップの準備ができた。fbxクラウドを非表示にして，最も北寄りの場所をMSLpのラベル表示から想定して，ズームインなどする。

　low-tide platformの認定は，当然，地形ではあるが，紅藻類の分布はその海食崖のトップ近くまで分布している。湾入部の場合とかなり異なるのは注意すべきであろう。湾入部では，紅藻類の上限がlow-tide platformにあたるからである。low-tide plaformは図15では，左手（北側）の#0では-1.1mほどで，右手（南側）ではほぼMSLまで高くなってゆく。岬部では低くて，湾入部では高くなってゆく。左手ではサーフが押し寄せてわずかな場所で露出しているために，pickingの位置は限られている。ところが，右手ではプラットフォームが高いために，ほとんどサーフから免れているのである。all closed.

以上，Apr. 4, 2022記。

６　Rased coral reef

　本ページの第２章を確認したい。地形的に特徴的なものは，この隆起サンゴ礁原である。図３の付近は年代試料を採取した場所で，放射性炭素年代試料を採取し，何とか年代試料として適合するものが採取できたところである。それゆえ，この地をpicking開始場所とした。ここから時計回りにマーキングすることにする。

　さて，fbxクラウドと，あとはMSLpファイルを開く。そして，fbxのModelを選んで，Picked points listを作成する。ここで，気付いたことだけど，表で🌀アイコンをクリックすると消えてくれる。図16は図３から時計回りに北に進む岬部であるが，地形の傾斜変換点とともに，石灰岩の色も考慮している。

　　　

　図17は，図16のすぐ隣の#19までで，ここからは同定ができない。

　図17からちょっと北に行くと，図18のように，新たなRaised CRの面が見えるが，#23までが限界。

　ほぼ図3に該当する#0から右手つまり反時計回りに追加してゆくのであるが，point #25はPoritesだろう。

　図20の#26〜#28は怪しいが，他のレベル設定のために一応pickingした。　

　Raised Coral Reef Flatは高度に差が無いはずだが，内陸部では侵食されて面としては残っていない。図21では，他の地形との関連で隆起サンゴ礁原の出現形態の差が見えるであろう。

　さて，RCRは，原地性サンゴ礁石灰岩の上限に一致する筈であるが，いわゆる隆起サンゴ礁地形を面として見る際には，異なる視点が必要である。原地性サンゴ礁原面は，潮間帯の侵食面として出現する。言い換えると，空港南の調査での対応関係を取る必要性がある。

７　Erosional platform from Raised Coral Reef Flat

　これはこれまで言及してこなかった面である。前章の終わりで述べたように，現在の隆起サンゴ礁とされる面は多かれ少なかれ，潮間帯の侵食環境にさらされる。広い面の陸縁は中等潮位に一致するとぼくは今の所考えている。そこで，岬部にもこの面は小規模にあるだろうけど，現在の出現形態を見てもわかるように，岬部と湾部で同時に異なる高さで生じるために，ここでは，湾入部に限定して，一応，Erosional RCFとして，pickingファイルは，RCRとは別にすることにした。

　明確な地形をもった場所から始めた方が問題が生じないと考え，図22のPoint #28 of picking_list_Raised CRとPoint #7 of picking_list_MSLp付近から始めて，Point #0とした。

　#3まで実施して，#0より時計回りに，#4〜7まで実施した。図23に示す。

　図24には，これまで得たpicking結果５種のうち，Higher 1以外の4レベルを表示している。

　さて，ちょっと視点を替えて，旧汀線指示地形のうち，もっとも蓋然性が高い高位礁原高度picking_list_RasedCRを確認する。#0〜#28のうち，地形が明瞭なものでは，最小値は1.97m，最大値は2.37mである。平均は意味が無いのでここでは使わない。統計処理は後に実施したいとは思うが頻度分布図での最頻値が重要だろう。

　さて，旧汀線の長期の安定期があり，最も形成されるのは中等潮位プラットフォームであり，notchも同様，retreat pointがそれに該当すると考える。実験的な研究は，今のところ，みつからない。で，上記の高位礁原高度の最小値1.97m，最大値2.37mに，徳之島で唯一の潮汐港「山」について，略最低低潮位ー中等潮位=1.11m，または大潮升潮位1.90ー中等潮位1.11=0.79mを足して，最小値〜最大値を求めると，1.97+0.79=2.76m　〜　2.37+1.11=3.48mになる。で，2.76〜3.48mに，前述のHigher 1つまりV-shaped notchの高度を対照したい。

　V-shaped notchの最小値は3.30m，最大値は4.58mになり，3.30〜4.58mの高度幅があり，高度幅で重なる部分があり，V-shaped notchの方がより高いゾーンにある。これは言い換えると，サンゴ礁原が大潮升までは達せず，V-shaped notchのretreat point言い換えると，中等潮位プラットフォームが高潮位に近い位置にあったことを示す可能性がある。

　海進期には海岸は極端に言えば垂直崖，以前，木庭が沖永良部島と徳之島のモデルを作成したが，このモデルで言えば，傾斜3゜〜5゜ぐらいであったか（西村先生退官記念論文1980），急崖というよりも，緩傾斜と考えて良いだろう？　それにしてもサンゴ礁形成の基盤は深く，造礁サンゴが海面付近に礁原を作るのには多大の時間を要した筈である。以前，久米島のボーリングで得た年代測定での結果が役に立つかもしれない。高橋先生の古今書院のピンクの本に簡単にまとめられている。ちゃんと読む気がしなかったが。このボーリング作業現場で記載したのはぼくだったのであるが。

　とにかく，大潮升までサンゴ礁原が発達したことは間違いなく，困難なので，略最低低潮位が礁原トップであることは間違いない。そうすると，1.11mを採用することになる。かつ，残された礁原の高度で意味をなすのは，最大値または最大頻度値である。一応，最大値2.37mを使うと，2.37 + 1.11 = 3.48mが当時の中等潮位となる。V-shaped notchは，3.30〜4.58mの高度幅があって，このnotchは当時の中等潮位か，それより1mほど高くなる。

　V-shaped notchのretreat pointが形成されたのは，ある高位海水準の時代で，このnotchの海方には中等潮位プラットフォームは未だ形成されなかった。船首型だった。そのnotchのリトリートが海面低下過程で高くなってゆくのは，おかしい。おかしい，と考えるのがおかしい，と思う人は，反論してね。

　それでV-shaped notchとRaised CR flatの間に旧汀線候補を探すことになる。徳之島空港南断面と同じ方向性になったなあ。

　地形の全体の分布ではなく，実際に観察した図25付近を見てみる。図25には，picking＃が上，中，下の三段が見えるが，上段のは，この図の後背（北側）のV-shaped notchの#が透けて見えているだけ。

　中段の#9 (4.02m)と下段の#3,4 ((2.14+2.27)/2=2.21)の比高は1.82m，　　中段の#10,11 ((3.93+3.96)/2=3.95)と下段の#0,1 ((2.31+2.20)/2=2.26)比高は1.69m，であり，notchが高位礁原より，かなり高くなっている。やはり，このnotchと高位礁原を繋げるのは無理がある。

　では高位礁原に対応する旧汀線地形を，この間で探すことになる。

８　Teracelet between V-shaped notch and Raised coral reef flat

　さて，両レベルの間のterraceletを検知した。profile断面も参考にしている。この面の分布は必ずしも横に続かない。ここでは反時計回り#0〜5で，3.43〜3.57mの高度幅を示している。この付近では前述のように，下段#3,4の平均高度は2.21mであり，terracelet #0,1は (3.57+3.54)/2=3.56mで，3.56 – 2.21 = 1. 35m，もう一つの例で，下段#0,1の高度は2.26mであり，terracelet #3,4は (3.43+3.45)/2=3.44mで，3.44 – 2.26 = 1.18m，それゆえ，1.27mだから，略最低低潮位から中等潮位の高度差1.10mにほぼ対応していると言えるのである。

閑話休題：

　さらに，#0から時計回りに見ると，として，始めようとすると，ぼくはCloudCompareでよくやってしまうのだが，DB Tree内での，fbxファイル内のModelサブフォルダを過って，他のフォルダに移動してしまい，DB Treeで紛失してしまう。その紛失先を新たに保存してしまうとModel自体もその紛失先にコピーしてしまう。wifiマウスの操作ミスである。
　 作成中のPoint list pickingファイルは，fbxフォルダ内のサブフォルダModelの下位のフォルダに表示されて，編集が可能なのだが，この作業過程を保存しないと，このPoint list pickingファイルは失われる。もちろん，別名で保存しておけばPoint list pickingファイルは残る。残っている場合，そのサブフォルダをModelフォルダに移動すると，編集状態を復元することができるような形を取るが，CloudCompareは認知できない。と言うわけで，保存したpickingファイルを表示して，それを参考に考え直して，新たにModel内で作成することになる。保存するのは前のファイルに上書きすれば良いだろう。実は図26は修正版であり，この上の段落は，修正した結果に基づいて修正している。s

　さて，#0から時計回りに，このterraceletを探してみると，なかなか難しく，Higher 1との関係も気になることとなった。ここでは図３のHigher 2は分類していない。徳之島の他地域では，図３のHigher 3がHigher 2のような出現形態を示すからである。

以上，Apr. 8, 2022記。

９　全レベルの再評価

　さて，ラベルもpoint表示も，異なるカテゴリーの区別ができないので，まずは，ラベルだけでも変更できるかどうか。Low-tide platformの点数が少ないので，これを対照にテキストを変更してみたい。point数の少ないLow tide platformのpicking_listファイルであるpicking_list_LTp.txtファイルをテキストエディターで開いて，手作業で，Point#ナンバーについて，Point#LTナンバーとして，別名で保存picking_list_LTp_LT.txtとして保存して，CloudCompareで表示したのが次の図27である。

　こうしてみると，ラベル位置の入力値がそのまま表示されていることがわかるので，Point #LTナンバーの代わりに，LTナンバーとすれば良いようだ。Pointという表示から大文字と小文字も区別できることがわかる。さて，この作業を実際に表示して，この考えに問題がないことがわかった。

　さて，個々のレベルのラベルを次にまとめている。高位から低位に列挙する。
VN: Level 1, V-shaped notch
FT : Level 2, Footslope terracette
　V-shaped notchのfoot slope途中のちょっとした幅を持つ地形について，特に命名されていない（と思う）。terracetteは，Glossary of Geologyでは地すべりのちょっとした段を言うようである。Definition of ’terracette’ in British English (ˌtɛrəˈsɛt), https://www.collinsdictionary.com/jp/dictionary/english/terracette, にもあり，geography用語として，a naturally occurring terrace，とある。海岸の微地形でも使って良いのではないかと思う。これが，Raised coral reef flatを作った海面の中等潮位と考えている。
RR: Level 3, Raised coral reef flat
ER: Level 4, eroded Raised coral reef flat　RFが海退途中で中等潮位プラットフォーム形成過程を経た面と考える。犬の門蓋南岸の湾入部に広く分布する。徳之島空港南方の断面も同様である。通常，サンゴ礁海岸での隆起サンゴ礁面はこれにあたる。
　RFまたはERの陸側には小崖nipがある。見過ごすと，V-shaped notchが続くように見える。
GP: Level 5, green platform　緑藻が分布する潮間帯のプラットプラットにあたる。岬部ではspratidal Platform，湾入部ではintertidal platformの形で分布する。平衡に達するとmean sea level platformになると考えられるが，沖永良部島に比べて隆起速度が速いためか，MSLよりも高い傾向が生じている。
LT（RP, red platformに変更）: Level 6, low tide platform 　平均低潮面にほぼあたる筈であるが，岬部ではMSL付近に分布する傾向もある。

　以上，ぼくの頭の中にある考えを適当に書き下した。不正確なものである。とにかく，６ステップの地形変換点の名称をここに示した。この略号が不適当になる場合もあり，上からのレベル順に，Lv1, Lv2, 〜,Lv6とすれば混乱はないが，これでは地形的なイメージと直接つながらないので，覚えにくく，後に面倒になるかもしれないが，この意味付けした略号を使うことにする。

　テキストエディターでラベル名を追加して行くのは寂しいので，一応エクセル関数のconcatenateを使って作業することにする。このpicking過程でナンバーリングに必ずしも一貫性がなく，配置を変更することも可能ではあるが，混乱する可能性があり，一応，ナンバーリングは触らないことにしよう。mousePCからmacに，共有関係で6ファイルを移動して，エクセルで処理を実行する。

　データ>区切り位置，で，label, easting, northing, elevationを分ける。

９.1　LT: Level 6, low tide platform　（RP, red platformに変更）

　５　low-tide platform picking list，に記している。図27に分布図はあり，エクセルで処理した図などが図28と図29である。

　岬部分では略最低低潮位付近に位置し，湾入部では中等潮位に近づいている。略最低低潮位はサンゴ礁原の上限である。岬部分のpicked pointsの分布を図30に示している。図28には高度トレンドを赤矢印で示しているが，大きなLT2とLT3の間には大きな段差があり，図29の解釈の方が妥当であろう。つまり，岬部と湾入部では大きな落差があり，さらにそれぞれの中でもトレンドがあるということです。恐らく，海底地形との係わりだと思います。別所さん，川口さん，海底地形図を探して頂ければありがたく存じます。陸域の地形からおよその海底地形も想像はできますが。

　それにしても，岬部でLow tide platformが深部にあって，湾入部で高くなってMSL付近に到達している現象は全く想像できませんでした。

　

　このような結果は，思いもよらなかった。岬部分と湾入部で共に，大潮升の低潮位付近にあたると，勝手に想像していたのである。現成サンゴ礁の形成の観点では，岬部分ではバットレスゾーンの上限に対応するが，湾入部分では，Low tide platform陸端からすると，より深くて遠い位置にその上限が配置されているということになるかと思われる。図29で見ると，Low tide platform陸端から1m前後の小崖nipがあり，紅藻類が生育している。この上限が湾入部の上限とほぼ一致するのではないか，と想像したので，実際にCloudCompareで実行してみることにしたい。

　Top of red algae，upper limit of red algaeなのだが，略号はRAとしよう。色合いからすると，紅藻類と緑藻類のミックスのように見えるが，ミックス相の上限を捉えることにしよう。Low tide platform陸端のpicking地点#0〜#9に合わせて，pickingしよう。

　作業過程で紅藻類の上限よりも小崖のトップを捉える方が理にかなっているように感じた。で，Top of red algaeをやめて，top of nipとして略称は　TN（こちらの方はまだPoint #のまま，新規作成中）としよう。図31は岬部分，図32は湾部分の両ポイントの関係を示す。

　さて，両者の高度分布を確認したい。図33の上段の図はTNのもので，トレンドはほとんど無い。つまり，岬部でも湾入部でも分布高度に傾向は見られない。下段には，差（TN-LT）の分布を示している。岬部分では両落差にトレンドがあり，湾入部では差が無いという現象がある。納得できる傾向と言える。

　図34はGEで空中写真Jan2021を表示し，トーンカーブと彩度を触って，海底地形を見た。この再現は難しいかもしれない。右下隅のスケールは30m長さである。解像度をweb用に落としているために数字が読めない。

　なお，図35はPhotoshop処理前のものである。陸海域の認識のために，参考に掲載する。

以上，Apr. 10, 2022記。

　図34と図35に示したGEの写真から，海底地形とサンゴ礁地形との関係を捉えることができるので，Low tide platform高度分布について何らかの解釈が可能と思われる。川口さん，別所さん，アイデアがあれば。とにかく，Low tide platformの高度分布は興味深いと思われる。沖永良部島でも大津勘ビーチロックと宇和美崎の地形や，GE写真との関係がそれなりに捉えられるので，期待したいと思う。

　top of nipつまりTNと，LTの計算をしたエクセルファイルを，名前をつけて保存 > UTF-16 Unicode テキスト.txt，の形で保存すると，図などが自動で省略されて，図36の右上のようになる。この上段のTN0〜TN9の行だけを残して，mousPCに送ればCloudCompareで見ることができる。

　ところが，図37のように，csv形式に統一した方がベターと考えられる。

　エクセルで，別名保存する際に，csvファイル形式で出力する必要がある。この場合，ファイル名の拡張子は，csv，となり，アイコンはエクセル形式になっているので，マニュアルで，txtに変更すること。そしてCloudCompareで図38のように表示した。Point #3の場所には，L TN3のように見えるが，LT3が隠れている。DB Treeの配置で，下位ほど，表示が上位になることがわかる。

　あらためて，図38を見ると，LT以下の海面下の紅藻類が分布する面が，現在の礁原であることを理解することができる。その意味では，湾入部ではそのレベルはほぼ中等潮位までに達するのである。

　改めて，図34と図38を引き比べると，現成礁原とその海方のバットレスゾーンを見ることも可能で在る。GE掲載の空中写真は必ずしも国土地理院から提供されていない。ハレーションが無い立体写真が欲しい。図34と図35は2021年1月16日取得とあるが，ソースがわからない。川口さん，別所さん，調べて貰えますか。

追記　Apr. 15, 2022：　次節の９.2　GP: Level 5, green platform，を作成する上で，改めて，low tide platformという名称の問題性を解消する必要性を感じた。GPについては，中等潮位プラットフォームとぼくが読んできたもので，このうち，岬部では，spratidal platform，としてきた。これに疑問を持って仮称したのが，green platformである。植生から名付けることで現在の営力も理解できる。
　で，９.1　LT: Level 6, low tide platform，であるが，湾入部ではおよそ中等潮位に対応しており，low tideに対応する訳ではない。low tide時に干し出すという意味に過ぎない。９.2　GP: Level 5, green platform，も干し出すので，区別が付きにくい。では，どうするか，9.2同様，緑藻類 red algae が生息するプラットフォームがいいだろう。と言うわけで，９.1　LT: Level 6, low tide platform，はやめて，９.1　LT: Level 6, red platform，とする。この節のタイトルも変更し，picking_listの名称も変更だ。

９.2　GP: Level 5, green platform

　上掲を繰り返す。「GP: Level 5, green platform　緑藻が分布する潮間帯のプラットプラットにあたる。岬部ではspratidal Platform，湾入部ではintertidal platformの形で分布する。平衡に達するとmean sea level platformになると考えられるが，沖永良部島に比べて隆起速度が速いためか，MSLよりも高い傾向が生じている。」すでに作成したpiking_listは，4　mean sea level platform picking list　にあたり，ファイル名としては，picking_list_MSLp.txtである。この面が最も複雑であり，この面は旧汀線高度評価の鍵になっていると思うので，じっくりと取り組む必要がある。次の図は，picking_list_MSLp.txtをCloudCompareで表示した。

　さて，これは，岬部ではSpratidal platform，湾入部ではMean sea level platform，そして，前者ではrampartも含む。これらの対応関係がなんともわからない。picking順は必ずしも系統的にできなかったので，この図の配置に応じて，整理する必要がある。

　とはいえ，先ずは，picking pointsの高度分布をエクセルで観察した。高度分布から分類するのはこの研究の目的からすると適切でないと考え，それも配慮しつつも，ほぼ北から海岸線沿いのナンバーリングを意識しつつ，順序を変更した。

　図40のDB Treeを見てほしい。エクセルで整理してCloudCompareに取り込んだものが，5_picking_list_MSLp_GP.txtである。これは，この上の段のpicking_list_MSLp.txtの上位に載っている。例えば図40の左端下部付近に，GP02 #35，とあるが，これは，エクセルで新たに改名したGP02が，図39に見られるように，Point #35の上位に載っていて，GP02 #35，というように見えているのである。DB Treeの5_picking_list_MSLp_GP.txtでは，上位から，第１行目2D label: GP12，第２行目2D label: GP13，などとある。つまり，このようにして，ナンバーリングに問題ないか，確認した。

　picking_list_⋯⋯⋯⋯⋯.txt，は，ナンバーではなくて，テキストの行順を反映する。これは後のち，混乱が生じる可能性が’あるので，エクセルで新たなGPナンバーでソートした上で，CloudCompareに取り込んだ方がいいと思われ，変更することにした。

以上，Apr. 11, 2022記。

以上，Apr. 15, 2022記。

　タニハ関係で時間がなかった。図42からさらに南に下る。

　GP15とGP16-との関係をどう考えたら良いのか。GP15はSpratidal Platformの陸端である。GP16-は地形的には，一段高く配置されている。GP15は1.02m，GP16, 17はそれぞれ0.93，1.10mであり，高度分布に違いはないが，地形の連続性から言うと，異なっている。図43は図42の反時計回りの延長である。GP16の弓形notchはGP30まで続くが，GP31以降の弓形notchとは明らかに不連続である。そしてGP31以降の弓形ノッチは，GP16〜30の弓形ノッチを切っている。新旧関係になっているのである。

　それゆえ，GP16〜GP30の弓形ノッチは，GPではなくて，一段上位になっている。図44でのPoint #3〜#10はpicking_list_RaisedCRにあたっている。だから，GP16〜GP30の弓形ノッチは，GP31〜のレベルとPoint #3〜10のレベルの間に位置しており，これは，picking_list_ErosionalRCRに該当すると考えるのが妥当であろう。GPレベルから，GP16〜GP30の弓形ノッチを外し，picking_list_ErosionalRCRに参入させる必要がある。北寄り側にもpicking_list_ErosionalRCR候補があり，かなり増えることになる。GPレベルのナンバーリングは，GP31以降は15を差し引いて，GP16以降に変わる。

　GP31以降について，地形的連続性を確認したい。図44には，GP33〜GP38までが見える。右手のGP38とPoint#5,6の間には，明瞭な面があり，ここでもpicking_list_ErosionalRCRに入れるべきものであるが，カウントしていない。

　図45では，GP37までの傾斜変換点と，GP38の間では，gapがあるように見えるが，よく見ると，そうでもないか。

　図46では，GP37と38付近を拡大表示している。GP37と38の間の比高は0.04mであり，同高度と考えて良い。分ける必要性はないだろう。この後背のPoint#6〜3は，Raised coral reef としており，erosionalはやはり無いが，例えば，GP38とPoint #6の間には，明らかに傾斜変換点があり，これはerosionalとすべきだろう。こういった観点で，図45を再評価すべきだと考える。

　GP16〜GP33までは緑藻がクラウド画像では見ることができず，この点でもGPと同定するのは不適当と考える。

　これから湾入部に入ると，GPは低下してゆく。

　改めて，岬部と湾入部との境界部分の関係が気になる。図48で見られるように，連続性はよいようだ。

　図41で高度分布を見ると，erosional RCRとは別に，特に高いGPはGP01〜03付近と，GP36〜39付近となる。後者付近を図49に示す。GP34からGP39まで，いわば遡上面のようになっていることが影響しているだろう。

　以上から，　GPとしたポイントについては次のような作業が必要になる。エクセルとCloudCompare両方での作業。

１　GPとしたポイント群には，erosional RCRに該当するものがあり，それは，GP16〜30で，erosional RCRに入れ込む必要がある。
２　さらに，erosional RCRに当たるものが北西部図42と南西部図49付近にあって，これらもerosional RCRに入れる必要がある。
３　そして，RPの再ナンバーリングを施すことになる。その前後か，高度認定を確認し，最終的な形を求める必要がある。
４　以上を踏まえて，RPの高度分布を，改めて確認することになる。

　さて，エクセルで，ごちゃごちゃしたら，ミスる可能性があるので，GPを表示して，改めて観察をして，RNナンバーの近所にピッキングをし直した。この過程で，GP16〜37が3段のerosional CRF，にあたることが明らかになった。GPの陸端の設定はなかなか難しい。タイドプールの底をGPの陸端とするのはかなり単純ではあるが，南の方の湾入部では，ラピエの高さで隆起サンゴ礁の侵食面とGPを区別できるので基準が変わってしまった。そこで，図50に示したこのspratidal platformの方も何とか傾斜変換点を探したいと思い，Point_list_pickingツールだけで，この部分をやり直すことができるかどうか，試してみた。

　試してみたが，入力済みの行を，🌀ツールで，最新のものから削除は可能だが，挿入とか修正はできなかった。そこで，前回，Point #26で終了したので，図51のように，Point #9〜#15近辺に，新たにPoint #27〜#33をピッキングし，ラベル付きで，ver3として保存した。

　

　エクセルでPoints #10〜15に替えて#27〜33を上書きすればよいことになる。

以上，Apr. 18, 2022記。

　図52は新たなGPの分布である。この図52での岬部分には全く分布しないことがわかる。これまで，岬部としてきたのは中央の突出部だけでなく，西方のSpratidal platform部分も含めてきた。改めて，この図52を見ると，岬部といっても大きく二区分されることがわかる。図52は，大潮の低潮時の映像であるので，紅藻類プラットフォームが比較的広く干出しているが，中央の突出部とこの西方の部分では干出幅は狭くなっていて，広義の岬部と考えるのも問題無いと思われる。陸域の地形でも海岸後背地は岬部では高台になっていて，湾入部とは大きな違いがある。

　GP04〜GP20では，北西から南東に分布高度が増大している。GP1〜GP09はランパートにあたり，GP10〜GP16はGPの陸端にあたっている。両者とも南東方がより高い傾向を示していて，これは岬の突出部に近いほど高いと考えてよいのではないかと思う。
　突出部南東壁ではGP17〜GP20についてみると，より陸域に近い方が高く，遡上波との繋がりで説明できる。
　GP21〜27についてはほぼ1.0mほどを示し，湾入部の地形とよく対応していると考えることができるのである。

　過去四年余りの研究では，緑藻プラットフォームが岬部で高いと考えてきた。ところが，この結果では，そう単純ではないことがわかる。突出部南東壁と湾入部の境界付近を図53に示している。見かけ上，段差はないように見えるが。図52での高度分布を見ると，GP20と21では，0.5mほどの落差がある。そして，GP17はGP21〜27と同高度を示している。つまり，遡上波の影響を除くとGPの高度差は岬部と湾入部の間では認められないということになる。

　このロジックは簡単にスルーできるものではない。ここが正念場と感じている。図53のGP20と21の落差，そして，図54のこの付近を観察すると，明瞭な段差が見られる。GP20の遡上面が侵食されて，gP21の面が形成されている。GP20と21の後背の小崖nipを見ると，連続性がある。自宅に戻ってmouseマシーンでこの付近を拡大して観察したいと思う。
　さて，図55にGP20,21付近をディープに観察すると，GP19〜Point#0（1.59m）の弓形小崖，そしてGP20（1.45m）付近にも弓形小崖がある。さらに手前にもう一つがありそうである。どういう経緯でできるのか，わからない。

　で，これまでspratidal platformとして，いわば，潮間帯プラットフォームとして区別してきた件がどうなるのか，ということである。図52（併せて図56も参照）を見ると，湾入部のGPの幅は，岬域の西部に比べて2〜3倍ほどである。それだけ湾入部のGPの傾斜は緩やかになっているということである。

以上，Apr. 21, 2022記。

９.3　さて， red platform, green platform, erosional RCR platform

　図57はApr. 21に一応，描いてここに掲載していたが，本日，修正版に変更した。CloudCompareを使って，何カ所か，断面図を描くことは可能ではあるが，まだそれをしないで，モデルを考えた。断面図を描くと，プラットフォームの傾斜が出るので，より説得力が出るのであるが，かなりややこしいことになる。ややこしい過程を経て，図56のようなモデル図を提出できる筈である。

　この図57は，図29と53に基づいたものである。表現の変更と解釈をまとめて，次に図58に再掲する。

　改めて，測点の分布図を次の図58に示す。

　図58には，寄せ波breachに係わって，水色の矢印で示している。GP01は左端に隠れているが，GP01〜03は陸繋島上のランパートにあたり，最初のtopping high surfを作る。この海方にはred platformが無く，急激に深くなっていると思われる。それゆえ，寄せ波は最も高く，それに対応して，ランパートが最も高く分布しているのである。この場の後背にあたるGP04はかなり低い。そしてランパートの部分そして陸方端で低く，岬突出部の北側GP16，南側のGP17からGP20への遡上波，の係わりで寄せ波が高くなり，その結果がもう一つのtopping high surfを作っているのだろう。

　high surfの効果を除くと，headland域でもbay域でもおよそ海抜1mの高度に，GPが分布していると考えられるのである。それを，図57のモデル図で，green platformが，headland域でもbay域でもおよそ海抜1mの高度に分布する，ということになる。この結果は，沖永良部島で卒論時に発見したと思ったstorm benchの出現形態からすると，意外性があるのだ。図58の結果に誤りはないのだろう。沖永良部島ではどうなのか，気になるところである。第四紀中期以来，つまり，琉球層群の堆積時期以降は少なくとも，同じ変動域にあると考えられる（木庭，1980）が，完新世中期以降の変動速度は，沖永良部島に比べて徳之島が高くなっているので，沖永良部島はどうなのか，確認する必要があるのである。ぼくの老化した頭ではあるが，沖永良部島の湾入部でのGPの陸方端の分布高度はMSLに対応したと思う。つまり，徳之島のGPはMSLよりも１ｍほども高くなっているということになる。この点は極めて重要である。V-shaped notchからの旧汀線高度復元の際に根本的な差が生じるのである。未だ整理がつかないのであるが。

　このようなことであり，これまで考えて来た世界よりも，より興味深いと感じている。川口さん，別所さん，お考えください。

　次に，RPについて論じる。運動不足で頭がおかしい。明日はタニハだ。雨も上がったようなので，ちょっと散歩してこよう。日は回ってしまったが。

以上，Apr. 27, 2022記。

　図57での，緑藻プラットフォームGPと紅藻類プラットフォームRPは，現在の潮位に関連して形成中の平坦地形である。GPの陸端が，岬部と湾入部でほぼ同高度（1.0m a.s.l.）を示すことは驚嘆に値する。岬部では波が収束し湾入部では波が拡散することと，海岸線からすると，岬部では一般に急激に深くなり，湾入部では緩やかな傾斜をもっていることから考えると，うねりや風波の水位は岬部で高く，湾入部では低い筈である。なのに，何故，GPはほぼ同高度を示すのか。もちろん，これまで見てきたように，岬部では0.5mほどは高くなったり，遡上波が実現する場所では湾入部であっても，多少は高くなる。湾入部の海岸線付近でよく見られる小湾部でもこの現象は一般に見られるのであるが。

　図57の「GPの陸端が，岬部と湾入部でほぼ同高度を示す」現象を説明する物理的観点はみつからない。1.0m a.s.l.は中等潮位からすると略最低低潮位と対応する「略最高高潮位」にあたる。「略最高高潮位」という用語は無いのであるが。

　さて，紅藻類プラットフォームRPの陸方端の高度分布を図58の下段のグラフから見たい。岬部では略最低低潮位にあり，湾入部では中等潮位に収束する傾向がある。海藻の分布は，もちろん，潮位を反映したものであろう。岬部ではこのRP幅は小さく，その海方は急激に深くなる。そして，このRPは実はサンゴ礁のbuttress zoneに当たっている。サンゴ礁の最も活発名場所で平坦面を構成しているのである。隆起サンゴ礁面の原地形である。岬部ではほぼ最低低潮位がRPの上限である。そして，湾入部では中等潮位にまで上昇している。

　現成サンゴ礁がこの湾入部で中等潮位にまで達しているとは考えにくいが，地形としては連続性があるのである。造礁サンゴの外洋側で上限は略最低低潮位の筈であるから，この地形は徳之島の隆起と繋がりがあると考えざるを得ない。これまで述べてきた，隆起サンゴ礁面，そしてそれがプラネーションを受けて形成されたerosional raised coral reef flatの分布と繋がりがあると考えざるを得ないのである。

　で，これまでも描いてきたerosional raised coral reef flatの高度分布を示したいと思うのである。

９.4　erosional RCR platform の分布

　これは思っていたよりも簡単ではない。地形的な連続性に基づいてトレースしてゆくと，かなりの高度差になってしまう。図59には，３面が区別され，その高度分布を示すべく，picking listを使って表示している。
　最も低いのはPoint #38 = 1.79m，これはかつて作成したpicking_list_ErosionalRCR.txtの一部のPoint #2に近い場所である。図59には緑藻が陸域に侵入している場所で，Point #1ともあまり変わらない。この面はぼくも過去の研究者も隆起サンゴ礁面としてきたものであり，何となく納得できる視点ではある。
　Point #37 = 2.43m はこのすぐそばのPoint#28に近く，このPoint#28はraised coral reef flat陸縁にあたると考えていたもので， erosional RCRとするには，周辺地形からすると高くなってしまったという印象がある。実は地形の連続性からするとこのPoint #37が自然なのだが，高すぎるので，考え直さざるを得ない状況がある。Point #39 = 3.25 m, #40 = 3.21 mは，何らかの旧汀線地形であるが，これはV-shaped notchなどが指示する旧汀線と関連するものではないか，と思ったりする。一応北からのものを，4_picking_list_ErosionalRCR_fromN_temp.txtとして保存した。

以上，May 1, 2022記。

　というわけで，アプローチを北から実施してきたが，南から初めて見たいと思う。いわゆる「隆起サンゴ礁面」としてきた広々とした面は，この度の作業で，erosional RCRとなったが，このうち，「最も低いのはPoint #38 = 1.79m，これはかつて作成したpicking_list_ErosionalRCR.txtの一部のPoint #2に近い場所である」で，かつ「4_picking_list_ErosionalRCR_fromN_temp.txtとして保存した」ファイルの北縁の面の高度とほぼ一致しているので，この観点で実行したいと思う。

以上，May 2, 2022記。

　さて，いよいよ，実行する。picking_list_ErosionalRCR.txtだけCloudCompareで表示して，実行してゆく。

　当然ではあろうが，南から進めたからよりうまく行くものでもない。ただ，前述のように，いわゆるというか，中田さんや高橋達郎先生と歩いた記憶であっても，そしておそらく世界の研究でも，隆起サンゴ礁面としてきたのは，南に拡がる面（図60では突出部の右手）に対してであったであろう。で，この南から進めることで，ラピエからなる北の面から進めるよりも，いい結果が得られると思う。

　図60は北から識別した38点で，図61は南から識別した26点である。図60では西への突出部を含めて全域で識別され，図61では突出部にはなく，また，突出部の付け根付近では欠落している。図61を作成する過程で，旧汀線高度分布について，より理解が進んだ。erosional RCRの面は，（erosionalであるだけに？）遡上波の影響で現在でもなお，変形を受けている。そういう場所ではこの面は消失している。その場所は図61の突出部南（図の右手）の付け根付近の#9〜#10間と考えている。なお，図61の突出部の#14〜#15では，（隆起）サンゴ礁は形成されず（堆積場が無い），erosional RCRも存在しない。このように，南からの識別の方が，北からの識別よりも，より地形判読が容易と感じられた。

　エクセルでまとめた高度分布図を次に示す。北からは地形の連続性という観点を重視して作成したものであるが，高度分布の上下変動が余りに大きく，旧汀線高度の観点からすると不適当と言わざるを得ない。地形の連続性という観点は本来ならば適切とも思えるが，そのトレースがうまくはできていなかったことを示すようだ。Point #は図60に対応できている。図63では，Point #0〜#25をER1〜ER26に変更している。この図では，高度変動が極めて小さい。ER05は突出しているが，これは敢えて遡上斜面の上端を採取した結果である。ER26からER23にかけて高くなってゆくが，これは遡上斜面を意識して捉えたものである。図63の平均値ではないが，およそ1.8m a. MSLとなるだろう。配置から考えて，現在の緑藻プラットフォーム 1.0 m a. MSL（図56と図57上段）との比高 0.8 m がこの旧汀線になると考えて良いだろう。

以上，May 3, 2022記。

南からの識別過程（北からのものは省略する）のなかで理解しえたことを，次に示したいと思う。

　この図64には，「かつて作成したpicking_list_ErosionalRCR.txt」と，新たな「4_picking_list_ErosionalRCR_fromS_temp.txt」のPoint #3と#4が見えている。この場所には大きな灰色のブロックが見えていて，これは隆起サンゴ礁岩体になるだろう。この後背にはほぼ同高度に薄い茶褐色のラピエ面が続いており，隆起礁原レベルを示しているようである。Point #3は，図63のER04にあたり，海抜1.80mに位置する。この陸側にPoint #4あって，図63のER05で，海抜2.46mとなっている。#3から#4に遡上面が認められるのでいずれもerosional RCR面にあたるものである。旧汀線研究の方針からすると，ER04 = 1.80 m a.s.l.を採用することになる。こういった現象は他の場でも見られる。繰り返すが，旧汀線としてはER04 = 1.80 m a.s.l.を採用するのである。

以上，May 3, 2022記。

　図65では，前のピッキング（#4, 5）方針と同じで，「隆起サンゴ礁面」の平坦面の陸縁である。

　図66の#7=1.82m a.s.l.は，erosional RCR面の陸縁で，小規模のnotchが続いていて，極めて認識しやすい。上位のv-shaped notchに比べて，あまりに規模に大きな違いがあり，旧海水準の持続または引き継ぎの時間に大きな違いが感じられる。

　図67で，#6,7は以前の南からの評価。#24〜26はfrom Northのもので，#8, 9が現在進行形のfrom Southである。#8 = 1.80 m a.s.l. は#6のそば。#9=1.78m a.s.l.　段差に注目すると，#26なんか選びたいのだが，これはRCRに対応するものと思われる。高度1.8mを意識しつつ，erosional RCR面（遡上面ではなくて）の陸端を把握した。

　#14と#15の長い空白では，旧汀線を認識できない。この突出部南縁での地形は，波の遡上の形との関連があるようだ。
　図68の小規模のnotchのretreat pointが，旧汀線になっている。#15=1.98, #16=1.86, #17=1.81, #18=1.76, #19=1.89。GP15〜18はいわばnipである。極端に言えば，二段notchの場所である。

　図69について。#20 =1.82m より陸方は暗くて見えない。notchはまだ陸方に継続してゆくのであるが。#21=1.85m からまた観察が可能で，Point #22と#23はそれぞれ二カ所見えるが，一つはRCR面に対応させていたが，これはerosinal RCRとなる。#24=1.62m，#25=1.29mと低下するが，これは遡上面にあたることになる。

　以上の試行錯誤を通じて，4_picking_list_ErosionalRCR_fromS_temp.txtを採用したいと思う。tempを省略して，4_picking_list_ErosionalRCR_fromS_ver2.txt　としたい。これにはまずは編集したエクセルファイルをcsv保存して，拡張子をtxtに替えることである。図61と同様であるが，エクセルでの作業を通じて，Point #をER #に変更している。図63のエクセル表示と同じである。

９.5　Raised Coral Reef Flatの分布

　次に，隆起サンゴ礁原の復元を実施することになるが，他の原稿の締め切りが近づいていて，デスクワークはタニハの整理のブログ作成以外は，そちらに傾注することになる。方針を忘れそうなので，次に，確認したい。

０　この図70左ペーンに示した４個を使うことになる。隆起サンゴ礁面Level 3高はこれまでのLevels 6, 5, 4よりもはるかに，一定になるはずではあるが，そうはならないであろう，ことも生じる可能性はあるだろうとは思う。納得できる結果を期待したいところである。
１　 picking_list_RaiseCR.txt，と，4_picking_list_ErosionalRCR_fromS_ver2.txt，を表示して，造礁地形として確かと思われる地点を新たに，pickingしてゆく。そして，その，スクリーンショットを重ねて，高度分布も，確認する。
２　その情報に従って，南からか，新たにpickingしてゆくことになる。

以上，May 5, 2022記。

はじめに

　冗長をさけるために，一つのテーマを分割した。このページは次のページに続くものである。

Cloudから抽出された連続プロファイルの利用１　utilization of many vertical profiles extracted from a point cloud Part１

　上記ページ（Part 1）では，be氏によって撮影されたドローンの3Dスキャンデータから，CloudCompareを使って海食崖の断面図を作成した。そして，fbx 3D画像を観察しつつ，断面図の妥当性を評価した。

　このページでは，その結果から，海岸地形のうち，旧汀線に関連がある傾斜変換点を把握し，その高度変化を，海岸線の岬と湾の分布から捉えたいと思っている。

１　Profile #58の評価

　Part 1では，いわば適当に，#48から断面図評価を始めた。ここでは断面の評価と現地での観察記録のあるProfile #58 から始めたいと思う。
　作業してきたExractedProfiles.binファイルは終了して，最終的なExractedProfiles12.binを開いた。Microsoft Wordなどのアプリと異なり，開いているファイルと保存するファイルは異なる。開いているファイルはいわば作業ファイルで，保存する場合は，ファイル名を次から次とシリアルに名称を変えて行くのがいいと思われる。経験的に得たことである。ファイルを終了するのも特にそのメニューは用意されておらず，DB Treeから削除という形で終了することになる。そして新たに，ExractedProfiles12.binを開いたのである。

　この図１の上部の線分群はExtractedSections.binで，いわば平たい藁葺きの屋根のように見える。そして，Profile#58を選択しているので，黄色の直方体が断面を包んでいる。削除前のProfile域が残っている。で，次の図２のようにfbx 3D画像を表現したのが図２である。

　図２では，断面図が3D画像にピッタリと載っている。次の図３はprofile面の方向を知るために，回転した結果である。赤いprofile面が黄色の直方体の対角線に一致している。3D画像との関係を見ると，ほぼ海食崖線に対して垂直方向の断面であることがわかる。

　この地形の意味を知るには，地形変換点と潮位との関係を知る必要がある。地形変換点の座標値は記録してゆくべきである。その手法は次のページに説明した。
iPhone 12 Pro撮影の3Dスキャン画像の座標を捉える
　この説明の中の，４.2　Point list picking，が使える。
以上，Mar. 25, 2022記。

２　Point list pickingの有効性

　Point list picking機能は，ぼくのような3Dスキャン画像から3D位置情報を得たいものにとって，CloudCompareの大きな魅力の一つである。大変感謝している。profilesにはこの機能は通用しない。図４では，最上段のアイコン群の左から４番目の”Point list picking”ツールが使える体制になっている。それは，DB Treeで見られるように，fbxファイルのModelを選んでいるためである。

　で，このツールをクリックした結果が図５である。これまで作成したPointリストが作成されている。海食崖地形のキーとなる傾斜変換点を適当にピッキングした結果の一部が図５に見えている。

　DB Treeには，Picked points listが見えていて，これにラベルを付けて保存した上で，表計算ソフトを使用することで，種々の解析が可能になる。

　今後，この種の作業をして，全域の傾斜変換点の高度分布を求めて行く。今後の作業はペーパーの内容の一部を構成することになるので，共同研究者のnob氏とbe氏だけが閲覧できるページ Parts-3以降 を作成して行くつもりである。

　なお，picking listの保存は，次のようになる。左のペーンのDB Tree内のPicked points listを選んで保存しようとしても，図６のように，エラーメッセージが出る。

　図７に示した方法で，picking listの保存が可能になる。図の選択肢のうち，label name,x,y,zの形式をぼくは気にいっている。

　保存したテキストファイルを開いたのが，次の図８である。

おわりに

　このテーマについて一連のコンテンツを作成してきたが，地形学分野での今後の手法を提示するものであり，参考になれば幸いである。

以上，Mar. 26作成，Mar. 28修正，追加，2022記。

はじめに

　クラウドから地形断面図を作成 から続くページである。Extraction sectionsプロセスを経て作成した，sectionsそしてprofilesの利用法をこのページで考えたい。cloudファイルを呼び出すとやはり，作成したsectionsもprofilesも含まれていない。先のページで考えたように，それぞれのグループを保存する必要があったのである。

　図１のDB TreeでのExported.binは92kBでsectionsのファイルで，Extracted.binは2951kBでprofilesのファイルである。先のページで述べたように，CloudCompareでは，次のように記述されているが，
all section cloud(s) are stored in a default group named Extracted sections
all section profiles(s) are stored in a default group named Extracted profiles
名称のバグと言える。敢えて，ファイル名をエキスプローラーで変更してもいいか，やってみた。Exported.binをExtractedSections.binに，Extracted.binをExtractedProfiles.binに。全然問題が無いので，今後，同様に変更することにする。

　さて，図２のように，断面が多すぎて何も把握できない。

　profiles no. つまり，Section contour #の分布を見ると，どうも南からナンバーリングされているようで，DB Treeで，Section contour #31を選択した結果が図３である。黄色の直方体が見えている。他のプロファイルも選んで見るとかなり大きな直方体を示すものがあり，地形研究者としては違和感がある。つまり，point cloudでの詳細な3D値から断面図が作成されていることがわかるのである。先のページでは，「Sections thicknessは，セクション位置で利用する点群の幅であろうと考え，ここでは1.0mとした。その入力したものが次の図28である。セクション間隔は2.0mであるので，セクション位置の前後併せて1m幅の点群を使ってプロファイルを作成すると考えたのである」としているので，かなり平均的な地形からプロファイルの方向が決定されたはずではあるが。

　ここでの問題は，予想できたものであったと言える。Extract sectionsのオプションのtypeの選択の問題もあるだろう。

type：　図ではLowerが見えるが，他にUpperとBothがある。初期値としてはZ軸に平行な閉輪郭であり，その等高線の上方か，下方か，両方を取るか，ということになる。（全く未だ理解できない）　

さて，さて。

以上，Mar. 15, 2022記。

　図２の結果を漫然と見たり，何らかの統計処理をしても意味は無いことは，初めから理解していた。で，現地調査で得た認識こそ重要と考え，幾つかの断面測量について，かく漫然と見てきたが，結局，2019年春調査した断面が最も有効と考えた。それが次のものである。

１　海食崖のgapを読むための基準を提示する　省略

　ここで，旧汀線地形の記述していたが，省略する。図４，図５も削除した。他の公開しない共同研究者限定ページに移動した。

以上，Mar. 28, 2022記。

２　プロファイルの利用法を考える

　多量の断面をすべて生かすことはできない。何を基準に選べばいいのか。その基準の基礎を前章で示したのであるが，気になるのは，CloudCompareで得たプロファイルの意味を確認したい。図６のように，描いたシングルパスpolylines（白色表示している）沿いに発生させられたsectionsは，これに直交している。ラインはEdit/colors/Set unique，で塗色を設定できる。シングルパスを編集画面で左クリックすると，シングルパス全体を包む形で，黄色の選択枠が表示されるが，それを白色にしたのである。この黄色の下辺の枠外に出ている黄色の線分（赤線で囲んでいる）は#1-48のsectionである。

　図７は，#48断面を見ている。図７のDB Treeのように，Section contour#48を選択すると，黄色の直方体が表示されるので，移動と回転をして，黄色の直方体がおよそ長方形になるようにしている。プロファイルが何とか見えるように，Photoshopで色相を変更しているので図６などとはかなり違う色になっている。この図７ではプロファイルは黄色の線で描かれているように見えている。海食崖の最下部付近に白い縦線を描いている。これより右手が実際のプロファイルに合っていて，左手は奇妙な曲線を描いているが，これは波の飛沫の影響と考えることができる。
　クラウドから地形断面図を作成　で述べたように，Extract Sectionsのパネルで，typeをupperとlowerを含むbothとしたので，図７には比較的高い断面と低い断面が見られる。白い縦線の右手の海食崖の断面ではupper profileとlower profileがある。3D画像を見ると，upper profileが連続的であり，地形断面を反映しているように見えるので，ぼくらの研究では，upper profile を選んだ方が良いようである。ただ，そのために，upper profileだけを選択して，再度profileを作成する必要性は全く無いだろう。で，縦の白線より左手では極めて一部で地形を反映しているようであるが，ほとんどは飛沫を反映しているので，無視することになる。この海岸では，夏の静穏期を除いて飛沫が無い時期は極めて少ないものと考えている。

　プロファイル一つ一つについて，このような作業をして行くのは，徒労ではないが，かなりの労力が必要で効率も悪いことが予想できるので，断面をbinファイル以外に外部出力して個々の断面を評価し，不要な線を除去するのがいいだろう。

３　プロファイルファイルの出力について

　CloudCompareで，まずはExtractedProfiles.binを選んで，File/saveを実行するのであるが，これまで登録したCloudCompare entities (*.bin)のほかに，DXF geometry (*.dxf), SHP entity (*.shp), (Geo-) Mascaret profile (*.georef)（アプリは下記）, Salome Hydro poly lines (*.poly)（アプリは下記）, Sinusx curve (*.sx)がある。 断面図は平面座標系に載るので，3D操作の必要性はないが，ただ，CloudCompareではどのような構造のファイルを出力するかは今のところ，わからない。ぼくが，およそ知るファイル形式は，dxfとshpなので，いずれが無難ではある。dxfだとSurferだし，shpだとQGISである。何れが目的に合致したものであるか，次の章で，実験したいと思う。

open TELEMAC-MASCARET The mathematically superior suite of solvers

Salome Platform Documentation

以上，Mar. 20, 2022記。

４　まだまだCloudCompareでやることがある

　一晩，そして，タニハでのフジ地下茎除去作業の中，考えてみると，CloudCompareからexportしてしまうのはデメリットが多いと思った。dxf出力して，Surferだけでpoint削除などができるか，そして出来たとして，やはりdxfで出力すると考える。
　そのdxfを,次のフリーウェアで，csv/txtファイルに変換してもさて，どうするか。
DWG / DXF to XYZ (CSV/TXT) converter　guthrie DXF2XYZ 2.0 / CAD2Shap
3Dで，画像を見ながら編集できるか，と考えると，とにかく，CloudCompareから離れずに，完結するのが最良と考えられるのである。

３.1　fbx 3Dデータファイルをバックにプロファイルを見る

　txt 3Dデータファイルの3D画像は，fbxやobjと比べると鮮明度がかなり落ちる。そこで，eg. fbxを下地にプロファイル表示ができるかどうか。図８では，#1-48は赤色で染色され，ノッチ上にプロファイルが載っているのが明瞭に見える。

　図９は，図８の画像を非表示にしたもので，#1-48のプロファイルが明瞭に見える。

以上，Mar. 21, 2022記。

３.2　#1-48プロファイルでの不要プロファイル部分の削除

　#1-48だけを選んでおけば，不要なプロファイルの部分削除ができればありがたい。失敗するかも知れないので，前もって，File Explorerでダビングして，元のファイルを，ExtractedProfiles_old.binとした。mouse PCはスリープ状態にしていたがパワーキーを押しても立ち上がらず，結局終了してしまったので，#1-48redは保存されなかった。改めて，fbxとExtractedProfiles.binをopenしたのが次の図10である。#1-48を選んでいるので，黄色の矩形が入っている。

　そして図10scrnshotの後で，Edit>Colors>Set Uniqueで，redにした。ズームインするのにfbx画像の表示に時間がかかるのでチェックを外し，左端のset front viewのアイコンをクリックしたあと，図７のように見える位置まで，黄色線の直方体をプロファイルが見えるように，マニュアルで移動回転などをしたが，他の断面がかなり邪魔になる。赤い線の断面図と地形との関係がわかりにくいので，fbx画像を表示したのが図11である。

　他の緑色の線からなる隣接断面図が邪魔なので，周辺の断面の表示を消したのが次の図12である。この図12を観察すると，二段ノッチの下方が赤線には反映されていない。type upper profileはこの点で問題がある。lower profileはfbxが邪魔して見えていない。

　この図12からfbx画像を非表示にしたのが図13である。upperとlowerの両断面が見える。

　次のページに紹介したsegmentation toolで不要部分を削除する直前のものが図14である。

　図右上の左から５番目の五角形の回りが赤く塗色されているsegment outアイコンをクリックした結果が次の図15である。以上の説明だけでは納得できないと思うが，この詳細な観察から，最も適当な断面が得られたと考えられる。

　さて，当方の目的からすると，図15右上のツールバーの右から３番目の✅️アイコンはクリックしない方がいいようだ。segment out実行の後に，自動的に，図16が作成される。

　Profilesは，ポリゴンとポリラインからなっていて，図14のように多角形で範囲を選んでsegment outすると，ポロファイルの切った先がポリゴンを作るように繋がる。その結果，図16が生まれる。これは無視して，作業結果であるSection contour #48を採用することになる。ファイルに反映するためにはExtractedProfiles.binそのものを保存する。そうすれば，プロファイルの選択やカラーの選択も維持される。

　図17には#48Profilesをfbx画像上に見せている。DB Treeで，Section contour #48を選んでいるので，黄色の直方体が見えており，赤線の範囲を示していると言って良い。赤線は下のノッチやさらに礁原までは延長しているように見えないが，これはfbxと一緒に表示した故の問題点ではある。下のノッチの凹みは図15のように記録されている。

　この#48Profilesの作業では，#42〜47，#49〜54，つまり両側の6カ所，計12カ所を非表示にした。このようにすれば，全プロファイルについて，作業が可能と思われる。fbx画像を表示していると表示速度が低下するので，移動や回転作業では非表示の方がいい。断面の地形的意味を考える場合は，fbx画像を表示することになる。今後，このような作業を全プロファイルについて実施し，その結果を次の章に示したいと考えている。作業を経たprofilesは赤色にしてゆく。非表示のprofilesも一つ一つずらせて行けば良い。

以上，Mar. 22, 2022記。

５　全プロファイルをチェック

　いま，全profileのチェックを実施している。ドローンを飛ばした場所としては最も遠い場所の#1〜10ではRGB情報やケーブ的な暗がりの点群が捉えられていない。形も流れている。これは遠いからというよりも，ドローンの速度に由来するものであろう。操作上の結果的なミスに基づいているようだ。それゆえ，図18の右端の赤色断面は採用するが，海食崖の奥部分のグレイ色の部分は採用しないことにする。こういう判断ができるのも，profilesを景観画像をチェックできるからで，CloudCompareからprofileをexportするのは間違っていることがわかる。

　図19では，#10profileのうち，３カ所でsegment outしたツリーを削除する様子を示している。

　図20では，図19実行後，不要部削除後のprofileを示す。

　この章で示した現象以外は，ほぼ問題ない結果となった。一つ一つ，断面と3D画像との関係を見て，破棄すべきprofileと採用できるprofileをメモした。CloudCompareからprofileをexportしてしまうと，全く使い物にならないことが明らかになった。さて，次にどうするか。

以上，Mar. 23, 2022記。

おわりに

　だらだらと長くなるので，ここで一端，このページは終了する。次のページに続く。

Cloudから抽出された連続プロファイルの利用2

Mar. 25, 2022記。

はじめに

　iPhone 12 ProとMetascan Proを使って，フィールドで3Dスキャンする予定であるが，Extract sections，つまり連続的な断面図を得る必要がある。つまり，点群 point cloudでなければならない。Metascan ProのExportファイルの形式は，Metascan support によれば次のものである。

USDZ is an open standard, supported natively on iOS and macOS.
FBX is a closed format, created by Autodesk and widely supported by 3D software applications and game engines.
OBJ is a simple text-based format which is supported by almost all 3D software. Metascan stores the OBJ file and its JPEG textures in a ZIP file when exported.
glTF is an open standard format for sharing 3D data on the web. Metascan uses the .glb format to embed all data in a single file.
PLY is a simple format used for sharing point cloud data. Metascan stores the 3D position and color data in binary.
LAZ is a widely used format for sharing point cloud data that is georeferenced so can be imported into a GIS system such as QGIS for analysis.
When exporting multiple scans, files are stored in a single ZIP file. Contact us if you’d like to see additional formats supported.

　上の説明によれば，point cloudとして使用可能と思われるのは，obj, ply, lazであるが，lazは構造が複雑でpoint情報だけを抽出するのはぼくには難しい。それにCloudCompareで読み込んだ画像はボウボウとしている。plyは，be氏から得たフィールドワークでのplyファイルは出力の方法に拠るだろうが読めなかったが，Metascanのexportで得られたplyファイルはpoint cloudそのものであった。objファイルもpoint cloudの書き出しは簡単であった。つまり，Metascanのexportファイルのうち，plyとobjはExtract sectionsが可能なファイルであった。

　千里北公園でiPhone 12 Proで撮影したもののうち，山茶花主宰の下村非文の俳句碑文を次に。丘の上に来て 風は秋 雲は秋。これはobjファイルである。

　で，plyファイルは次のよう。pointサイズをdefaultの3倍に拡大しての表示である。Points数は40,404である。

　この石碑はMetascan Proの写真モードで2022年３月９日に撮影したものである。Metascanの写真モードでの撮影を一応，実験したものの一つである。LIDARについてはより高い信頼感があったのでLiDAR撮影には関心が薄かった。しかしながら，図２の点群の希薄さは写真モードも原因になっているのではないか，と考えて，本日May 12に，ヴィソラの北隣に位置する千里川右岸の「花咲か公園」のちっちゃな花壇に出かけた。前回に来た時は叔父さんが自転車を寄せて，三脚を立ててその前で空手かなんかのポーズを自撮りしてて，引き上げた。今日はお婆さんが近づいてきて，お握りを広げて花見を始めたので，諦め，コーナンでの買い物，メガネ屋での修理，スタバに入れず隣のタピオカドリンクを買って千里川を眺めたりした帰りに，やっと撮影することができた。その結果をこのページで述べたいと思う。

１　写真モード撮影での点群密度

　この章は次のページの続きとも言える。　Metascan写真画像測量モードの利用-2
　これまでの撮影経験の中では，最も丁寧に実施した。丁寧に撮影すればするほど，いい3Dスキャン結果が得られる。低い位置や高い位置から３回ほど回って撮影した。この図の手前の階段については意識して撮影した。照明タワーの一部が見えるが，これは撮影の際に邪魔だなあ，って意識で花壇を撮っているつもりであったが，しっかりと撮れている。最上部の照明部分は入っていない。意識して撮影しようと思わなかったからであろう。写真モードは，LiDARモードと違って，撮影したかどうかの表示は全く無いので，かなり計画的に撮影する必要があるのだろう。DB Tree では，verticlesにも表示の✓は入れているが表示に違いは見られない。

　この図３を把握してもらって，plyファイルを次に示す。point cloudはかなり希薄である。point数は，12,006点である。丁寧に撮影したからpoint数が増えるわけでも無いようだ。

　objファイルではpoint cloudが見えている。図３のDB Treeのobjファイルのサブフォルダを見ると，verticesが独立している。これを選んで保存すると，vertice.binというファイルができる。points数は，17,786となっている。

　以上から，points数は，plyファイルが12,006点，objから得たverticesでは17,786点となっており，後者は前者の1.48倍となっている。

２　LiDARモード撮影での点群密度

　iPhone 12 ProのLiDARは5mに限定されている。Metascanの指針では，0.5〜3.0mが適性距離だという。ほぼ，そのような意識の上で，撮影した。DB Treeを見ると，mesh群があって，最後にverticesが見える。図６では不要なゴミが見える。スキャンした際にこの点を多少意識して減らせるよう努力したが，不十分だったようである。もう一周すれば良かったと思う。花壇の上の花部分について，花壇内に入って，設置されていた石を踏んで，スキャンしたのであるが。

　次の図７には，plyファイルを示している。写真モードの図４とは絵作りで圧倒的な差が見られる。改めて，LiDARモードのパワーを感じた次第である。points数は532,061点。

　で，objファイルからvetices.binファイルを作成して，表示したのが図8である。写真モードの図５と比べて欲しい。

　LiDARモードでは，plyファイルの点数は532,061点，objファイルからのvertices点数は59, 617点となっている。つまり写真モードとは逆転し，plyがverticesの，8.9倍になっている。つまり，LiDARでは，plyファイルが圧倒的に点群数，つまり点密度が大きくなっている。

おわりに

　iPhone 12 ProとMetascan Proの組み合わせでは，LiDARモードでの撮影が，Extract sectionsでの分析には有効であることが改めて理解できた。そして，その結果のexportはplyファイル形式が適している。LiDARが及ばない対象に対しては，写真モードを使用することになるが，Extract sectionsでの分析には，objファイルから抽出したvertices.binファイルを使うことになるということだ。

以上，Mar. 12, 2022記。