前ページの「 ２ Point list pickingの有効性」，で得た情報をもとにして，犬の門蓋南岸の地形傾斜変換点の意味とその分布を捉えることになる。前ページで指摘したように，profiles上をクリックしてもpickingはできず，fbx上をpickingすることで座標情報を得ることができる。結果的に言えば，profilesから得られるものは多くは無く，結局のところ，profilesを生成しなくても，地形傾斜変換点を把握し，その座標値を得ることができるのである。 ではあっても，2m間隔でのprofilesは傾斜変換点を捉える位置決めの目安になることは確かであって，そういう意味で不要なものではない。とは言っても，profilesの位置に規制されることなく，fbx-3D画像で傾斜変換点の定高性や連続性を観察して，pickingするのが最も適切と思われるのである。 図3は新たにピッキングしたものである。
追記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.”
CloudCompareは，何か，Web閲覧と類似したところがある，沢山のファイルを開いても，なんら，重くならない。いいソフトだと思う。さて，また，fbxcloudファイルを開いて，さきほど上書き保存したpiking_list_MSLp.txt（Show labels in 2Dにチェックのこと）も開くが，ピッキングラベルがパノラマ状に表示されるので，一旦削除して，また開く必要がある。このようにして，次のステップの準備ができた。fbxクラウドを非表示にして，最も北寄りの場所をMSLpのラベル表示から想定して，ズームインなどする。
さらに，#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
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は湾部分の両ポイントの関係を示す。
top of nipつまりTNと，LTの計算をしたエクセルファイルを，名前をつけて保存 > UTF-16 Unicode テキスト.txt，の形で保存すると，図などが自動で省略されて，図36の右上のようになる。この上段のTN0〜TN9の行だけを残して，mousPCに送ればCloudCompareで見ることができる。
図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からの旧汀線高度復元の際に根本的な差が生じるのである。未だ整理がつかないのであるが。
エクセルでまとめた高度分布図を次に示す。北からは地形の連続性という観点を重視して作成したものであるが，高度分布の上下変動が余りに大きく，旧汀線高度の観点からすると不適当と言わざるを得ない。地形の連続性という観点は本来ならば適切とも思えるが，そのトレースがうまくはできていなかったことを示すようだ。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 がこの旧汀線になると考えて良いだろう。
Point list picking機能は，ぼくのような3Dスキャン画像から3D位置情報を得たいものにとって，CloudCompareの大きな魅力の一つである。大変感謝している。profilesにはこの機能は通用しない。図４では，最上段のアイコン群の左から４番目の”Point list picking”ツールが使える体制になっている。それは，DB Treeで見られるように，fbxファイルのModelを選んでいるためである。
図１の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に。全然問題が無いので，今後，同様に変更することにする。
そして図10scrnshotの後で，Edit>Colors>Set Uniqueで，redにした。ズームインするのにfbx画像の表示に時間がかかるのでチェックを外し，左端のset front viewのアイコンをクリックしたあと，図７のように見える位置まで，黄色線の直方体をプロファイルが見えるように，マニュアルで移動回転などをしたが，他の断面がかなり邪魔になる。赤い線の断面図と地形との関係がわかりにくいので，fbx画像を表示したのが図11である。
年金生活者が初めて確定電子申告 a pensioner’s first electric income tax report
はじめに
追記 Mar. 17, 2023： 2022年の確定電子申告は締め切り日2023年３月15日に実施した。何となく，15日にやろうと思った。そしてこの日が締め切り日とわかった。何としても今日中にと，頑張った。前回のこのウェブページを参考にした。もちろん役だったのであるが，不安の中での作業であった。それで，2023年期間の確定申告をより負担無くやりたいと思い，このページを補強するべく，別途，次のポスティングを作成することにした。年金生活者の確定申告
Metascanの出力からテキストファイルを得る how to get a point cloud text file from an output from Metascan
はじめに
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.
この章は次のページの続きとも言える。 Metascan写真画像測量モードの利用-2 これまでの撮影経験の中では，最も丁寧に実施した。丁寧に撮影すればするほど，いい3Dスキャン結果が得られる。低い位置や高い位置から３回ほど回って撮影した。この図の手前の階段については意識して撮影した。照明タワーの一部が見えるが，これは撮影の際に邪魔だなあ，って意識で花壇を撮っているつもりであったが，しっかりと撮れている。最上部の照明部分は入っていない。意識して撮影しようと思わなかったからであろう。写真モードは，LiDARモードと違って，撮影したかどうかの表示は全く無いので，かなり計画的に撮影する必要があるのだろう。DB Tree では，verticlesにも表示の✓は入れているが表示に違いは見られない。
CloudCompare Wikiでは，対応ファイル形式についての言及がない。”Tools > Segmentation > Cross sections” に関する説明ではわざわざ，”Since version 2.6.2 this tool can be used on meshes” とある。CloudCompareがそもそも点群 point cloudに対応して作成されたアプリなので，わざわざmeshには対応していない，と示されないのである。 図１〜３で紹介しているmesh形式として代表的なFXB（542MB）や，更には点群とも回されてきたply（636MB）であっても，Extract Sectionsは対応しないのであるが，これらに比べてテキストファイル形式は容量11.22GBと圧倒的に重いのであるが，FXBと比べると，映像編集画面での操作ははるかに軽やかなのである。画面表示負荷が低いのであろう。図４はtxtファイルのインポート最初のページである。
このダイアログの終わりの”auto save and remove generatrix” についての次の説明が理解できない。一応，チェックを入れたままで実行する。 “A last option named ‘auto save and remove generatrix’ will tell CloudCompare to remove the selected polyline/path from the active polylines after having saved it to the main DB tree. This is useful as afterwards the ‘profile extraction’ method will use all active sections and it is generally not interesting to generate a profile along the main path. However, in case the orthogonal sections generation settings were not correct, the user can still undo this, import the path from the DB tree (see above) and restart the process.”
type： 図ではLowerが見えるが，他にUpperとBothがある。初期値としてはZ軸に平行な閉輪郭であり，その等高線の上方か，下方か，両方を取るか，ということになる。（全く未だ理解できない） max edge length： 現在のところ，理解できていない。次のような記述があり，Cross Sectionの参照が指示されているが。 max edge length: this is the main parameter of the ‘concave hull’ extraction algorithm. See the Cross Section tool documentation.
OKの後，マゼンタ色のsectionsが図26のように現れた。Orthogonal sections generatin中の，auto save⋯⋯⋯⋯⋯は”A last option named ‘auto save and remove generatrix’ will tell CloudCompare to remove the selected polyline/path from the active polylines after having saved it to the main DB tree.”の意であるが，sectionsを表示する際に，ポリライン（シングルパス）はDB treeに保存はするが，表示には邪魔と考えて表示しないようにする，というオプションに過ぎないことがわかる。
図10の5番目のフロッピーディスクのアイコンをクリックすると，保存したように見える。そしてアイコン８の✅️をクリックしても保存しているようであるが，エキスプローラーでcloudのファイルが入っているフォルダを見ても何もない。Wikiには次のような記述がある。 Notes: 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 cloud(s)は作成していないが，profile(s)は作成している。 a default group，というのは外部のファイル群ではないようだ。
