はじめに

　共同研究者の一人beがドローンを飛ばして光波測距儀での測量についてはプリズムをボクが移動し，測点の記載を実施した。それはもう2020年春のことである。2018年と2019年にはkaさんと海岸地形の光波測距儀での測量などを実施した。両方のデータの整合性を取る必要があって，ドローン測量をここ１カ月以上に渡って，検討してきた。

　これはドローン測量のほぼファイナルな結果である。残念ながら期待した結果は得られていない。この結果に至るまでのやり取りなどや分析の詳細はプライベートページに掲載されている。まだ研究成果を発表するまでには時間が必要で，公開できない内容を多く含むためである。

ortho.tifの限界

　図１は，Agisoft Metashapeで作成されたオルソ写真と光波測距儀で求めた８点の位置のずれを示している。ビューワーはGoogle Earth (Pro)である。グーグルアースで表示されている画像はモザイク写真であり，写真画像で正確な位置を捉えることはできないので注意が必要である。

　画像とは関係なくグーグルアース画像での位置情報，繰り返すが画像とは関係のない，グーグルアース座標系での位置情報の精度は高い。グーグルアースプロの限界 の「GEProの位置精度」の章に示すように，地球面上の位置精度は1〜2mほどと言えるだろう。

　それゆえ，光波測距儀で得たgcp候補８点のうち採用した７点の位置は正しくグーグルアースにプロットされる。光波測距儀はノンプリズム対応のもので８点のうち２点はプリズムの設置が困難な場所であった。ドローン測量結果の位置決めはgcp７点を使用した。ドローン測量でえた空中写真で同地点で複数の写真にgcp位置を同定しており，ドローン測量結果はgcpとの対応が取られていて，グーグルアース上では，オルソ写真の画像上のgcp位置と一致する筈であった。ボクは当然一致すると考えていた。

　ところが，図１に示したように，gcp８点（図１の中央列のc点はドローン測量結果には使用されていないが球面位置情報は正しいので掲載した）のいずれも一致していない。図１では黄線分でズレを示しているが解像度が低くて見にくい。オルソ写真の位置と光波測距儀で決定した位置のズレを示している。参考データとしてGoogle画像で示されたスケールを使ってそのズレ値を例えば，e:1.3mなどと示している。Google画像での距離精度は低いがオルソ写真と光波測距儀での座標から得られた点のズレなので，精度はグーグルアースの精度ほど低くはないのであるが。

　で，図１の右端の画像はオルソ画像域全体のなかでの，ズレの傾向を示している。この画像の右下隅に方位ホウィールが見える。研究対象域は海岸線付近なので，gcpの点a,f, b,gに注目すると，1.85m±0.35ｍほど，北に変位している。

　これまで，種々の計算処理をしてきており，これ以上の対処は難しい。海岸地形の研究の観点からすると，このオルソ画像をいわばインデックスマップとして使わざるを得ないのである。このインデックスマップに，以前に測量したポイントの座標系を平行移動または回転などして行かざるを得ないのである。

今後の作業は思って

　このオルソ写真というか，ドローン測量結果が使えるかどうかは，別の観点から，評価する必要がある。この海岸で2018年または2019年に測量した結果，特に海抜高度が完全に一致しているかどうかである。球面位置はこのオルソに合わせるにしても，海抜高度に問題があれば，使えない。

　3DオブジェクトのPLYを使って，次に評価したいと思う。

以上，0:16，Dec. 24, 2023, to Christmas Eve。

グーグルアースから離脱か，Qgisか

　ズレ，1.0〜2.2mは，そういえば，グーグルアースの誤差範囲である。
参考：グーグルアースプロの限界。
　図１ではgcpとオルソのズレは同じではないので，オルソ全体のズレだけでなく，gcpの個々のズレもある。グーグルアースの限界に基づくものと考えれば，納得もゆく。

　今日，be氏に電話して，Qgisにプロットしてもらうことにした。ぼくはGrassGISであるが，Qgisのユーザーは多く，簡便であり，Qgisにシフトした方がいいと思う。ゲームなどでも利用される3DオブジェクトのFBXやUSDZなどにも対応しているかも知れない。その確認もお願いした。

　ぼくはCloudCompareで，海岸線付近の高度情報を調べることになる。

以上，Dec. 24, 2023記。

1. Google Earthとのつきあい方

　光波測距儀設置点をGEPro情報から捉える：後方交会法 では，後方交会法の限界を思い知った結果になった。ドローン測量の際に，公共基準点を捉えられなかったことが今なお，響いている。現地に再度行った方が，よほど人生を生かすことになるはずだが，だらだらと不完全なドローン測量結果を生かすべく，闘っている？
　ドローン測量と併せて光波測量を実施したが，光波測距儀の設置位置が数メートル規模で確定できない。gpsはこの精度では信頼できない。それではと，Google Earthを使おうとのめり込んだ。この限界については，グーグルアースプロの限界 にぼくが得た情報をまとめている。その結果，Google Earth上で何らかの作業をするのは，狭い範囲の測量情報を取り扱うのは，時間をドブに捨てるのと同じだと，遅ればせながら，わかった。GEが提供するプログラムがあるが，これは児童のお遊びツールとしてのみ，何とか価値があるかも知れない。

2. 平面上での作業を選択

　現在の悩みは，前述のように，もともとのドローン測量の周辺的な問題もあるが，Google Earthの画像と光波測距儀のgcpのズレを気にしてしまったことにある。Google Earthの画像が当方の使用目的には不適当であることがわかっても，ドローン測量から得られたortho.tifをGoogleアースに落とした際にほぼGoogle Earthの画像と一致していて，違和感を感じさせないということに意味があると，グーグルアースの画像がモザイク写真であっても，思っている。
　このページ作成の前に，前述の後方交会法のページで最後に掲載したGoogle Earthの画像から後方交会法で得たプッシュピンを削除し画像を図１に示す。赤いプッシュピン（電柱byKなどの個別名称）はGoogle Earth上で，現地調査時の現場写真やドローン測量で得られた空中写真に基づいて，手作業で落としたものである。これをここでは仮にGoogle Earth系A〜Fとする。
　茶色のプッシュピン（a-GE〜g-GE，-GEを付加しているのは光波測距儀の設置位置を現場写真なろからGE上に落としたことに由来する）は光波測距儀で得られたものである。これをここでは仮に光波系a〜fとする。

　今後の作業過程を次に。

ステップ1　光波系a〜f（計7点）とbase-GE（GE画像にプロットした光波測距儀の想定設置位置）（以上，計8点。平面直角座標系1の形）。Google Earth系A〜F（計7点）についてはkml出力して，経緯度（十進角）を平面直角座標系1に一括変換する。

Wikipedia由来か。次の情報を得て，今後は，十進角で表現したい。
「十進角（じゅうしんかく、英：Decimal degrees (DD) ）とは、角度の表現法の一つである。緯度と経度の地理座標を度分秒法が北緯a度b分c.d秒、東経e度f分g.h秒と表現するのに対して、十進角ではa.bcd度、経度e.fgh度といったように分秒の部分を小数、十進法で表す。」

ステップ2　この二つの系を一つの散布図にプロットして画像出力して，それをイラストレーターに配置する。この一連の作業の目的はGoogle Earthのモザイク写真との整合性を取ることなので，光波系a〜f（計7点）のみ，トレースしてベクトル化して，手作業？で回転および平行移動をする。

　なお，この回転と平行移動は現実的でなければならない。平行移動は最大2mほどだろうし，回転は数度以内であろう。光波測距儀では回転軸はコンパスで実行されるが，大山の自衛隊基地のレーダーの影響が考えられるので，数度の回転を要する可能性はある。

ステップ3　ステップ2の結果に基づいて，幾何学的な数値計算を実施する。

ステップ4　その結果に基づいて，光波測量の結果を回転および平行移動を実施する。

ステップ5　ステップ4で得られた結果を十進角に変換してKMLファイルを作成してGoogle Earthに取り込む。

ステップ6　Google Earth上で，ノータッチのGoogle Earth系A〜F（7点）と変換後の光波系a〜fとベース（8点）の整合性を一応，確認する。この作業を通じて，当然，みかけ状の改善は見られるはずである。

3. 計算作業

3.1 ステップ１

　Google Earthから出力したKMLをみると，図2のように，

経緯度値が2セット見られる。
<LookAt></LookAt>内に，128.5300162650217 27.35264129535775
<Point></Point>内に，128.5300076128268,27.35263507066106
KML リファレンス には，<LookAt></LookAt>について，次の説明がある。

Feature から派生する要素に関連付ける仮想カメラを定義します。LookAt 要素は、表示対象のオブジェクトに対する「カメラ」の位置を設定します。Google Earth では、ユーザーが [場所] パネルのアイテムや 3D ビューア内のアイコンをダブルクリックすると、「空を飛ぶように」視点が移動し、LookAt で指定した視点のビューに切り替わります。

というわけで，建物南西角の場所は，<Point></Point>内の経緯度を採用する必要がある。

　国土地理院の平面直角座標系への一括変換では，DMS形式の形に限定されるので，十進角からDMS形式にまずは変換しなければならない。経緯度座標系↔平面直角座標系　にその手法は掲載している。bl2xy.inのファイル内には小数点以下4桁であるが，10桁でも問題なく，計算される。bl2xy.outの平面直角座標系の座標値は小数点以下4桁までに限定される。

3.2 ステップ２

　エクセルでの光波系a〜f（計7点）とbase-GE（GE画像にプロットした光波測距儀の想定設置位置）（以上，計8点。平面直角座標系1の形），と，Google Earth系A〜F（計7点）の散布図を作成する。

　図3にエクセルで作成した両グループの散布図を作成し，左の修正対象の光波系a〜f（計7点）とbase-GE（計8点）の散布図を，右の固定とみなすGoogle Earth系A〜F（計7点）の散布図にコピペした。

　図3右の散布図では，固定側のマーカーを赤い十字マーカーとしている。右の散布図を基図に，イラストレーターでズレの傾向を示す。図3右の散布図を見て，意外とズレが小さいので，方針を修正した。
　エクセルの散布図をイラレにコピペすると文字化けする。MS ゴシック，Osaka，Times New Romanに変更すると回避できたという情報があるが，ぼくは全然だめ。Mac Sonoma 14.1での，Microsoft Excel 16.79.2 から，Adobe Illustrator 2023 へのコピペだ。ひょっとするとと，Adobe Caslon Pro (Regular)にしてみると，見事に文字化けしていない。
　ついでに言えば，以前のマックでは，エクセルからコピーした図表はすべて，自由に分割，削除ができた，そういうマッキントッシュがあった。今は，ユーザーの使い勝手無視の体制だ。アプリ間の連動性が悪い。マイクロソフトとアドビの間でのやり取りはないのだろうか。いずれもマックアプリメーカーとしては老舗なのに。

3.3 ステップ３

　図４の右図はイラストレーターで描いたものである。(base)を頂点として生まれる誤差三角形は細長く，北西部分はF(f)を，南東部分はG(g)の例を描いている。F(f)，A(a)では，グーグルアース画像に比べて，(2.998 + 2.559)/2 = 2.7785º，G(g)，B(b)では，(2.251 + 1.972)/2 = 2.1115º，となる。

　Google Earth系A〜F（計7点）は固定点である。光波系a〜f（計7点）とbase-GE（計8点）は修正が可能である。base-GEを移動すると，光波系a〜f（計7点）も計算式に従って，変わる。iterationの手法を使えば，北西部分と南東部分の各2点の誤差角度の平均値を揃えることは可能である。(base)を最大2mほどだろうか南方に移動すれば一致する筈である。

　このプログラムを作成することはできるが，また時間を費やしてしまう。このウェブページの作成の前に予想した通りになった。このページの作業は，モザイク写真で構成されるグーグルアース画像と合わせる作業である。固定点のGoogle Earth系A〜F（計7点）の座標値は，実はモザイク写真と対応しているものではない。ちょっとややこしいく，ぼく自身も吹き飛ばされそうになるが，この座標値はモザイク写真の歪んだ像にプロットしたものである。だから，結局，モザイク写真に振り回されていることになる。もういいんじゃないか，と思う。回転すら必要無いのではないか，と思ったりしてしまう。

　でも，それでは，なーんで，ここまでグーグルアース画像との対応を取る「努力」をしてきたのか，と思う。とにかく，(base)の南進作業はやめよう。図４で得られた，回転角をどう生かすかを考えよう。北西部分の２ペアの平均値，南東部分の２ペアの平均値，そしてまとめて４ペアの平均値，いずれかを採用しよう。図１と図４右図を睨んで，結局，まとめて４ペアの平均値，を採用するのが無難であろう。2.445ºだ。

　光波系a〜f（計7点）は，反時計回りに2.445º，歪んでいるのだから，時計回りに2.445º回転すれば良いことになる。

　さて，図４右図の光波系a〜f（計7点）の，c, d, e, の三点のズレの傾向を確認したい。青い矢印で感覚的にズレを表現しているが，まあ，トレンドとしては悪く無い。　

3.4 ステップ４

　表２は，光波測距儀のgcp読値を整理したものである。この場の磁気偏角は5º19′W。光波鏡筒軸をコンパスで磁北にゼロセットしてターゲットの方位角を求めて行く。例えば，a点の場合，HR読値: 325º9′50″。磁北は真北に対して5º19′西偏しているので，真北は時計回りに5º19′の位置にある。そこで真北からの水平角（表２の「補正済み真北からの角度」）は，325º9′50″ – 5º19′ = 319º50′50″ となっている。

　3.3スタップ３の結果を，表２に反映させる必要がある。HRは光波測距儀の読値だから触らない。rad列の計算式は，「補正済み真北からの角度」の数値を使っている。磁北の西偏を補正するために，「磁北からの読値」から西偏分差し引いたのであるが，これは「磁北からの読値」からすると反時計回りの処理をしたことになる。図４右図の(base)を中心とするして，光波系a〜f（計7点）をいわば，反時計回り↪️に余分に回転した結果と言えるので，5º19′ – 2.445º = 5.317º – 2.445º = 2º52′ に抑えれば良いということになる。2次元でさえ，回転を直感的に理解するのはぼくは苦手だ。

計算結果が次の表２だ。

　この結果を使って，図３を更新した結果が図５である。回転後の光波系a〜f（計7点）は，Google Earth系A〜F（計7点）へかなり接近した。北東隅の電柱トップも接近している。

　図５下段では，baseからの挟角が回転前からすると回転後は小さくなっている。

3.5 ステップ５

　ステップ４までで所期の目的は達成した。グーグルアースで表示する必要性は全くない。
　とはいえ，この結果に基づいてortho.tifが作成されるので，このオルソ画像上にgcpの正確なプッシュピンを表示する意味はある。2018, 19年の調査情報もグーグルアースのオルソ写真上に掲載したいと思う。
　

　回転後の光波系a〜f（計7点）の平面直角座標系から経緯度座標系への変換をこれから実施したい。出来たものが次のようだ。

　次は，表５の枠囲の数値からKMLファイルを作成することになる。

以上，Dec. 8, 2023記。

　表５の十進角の値を使って，kmlファイルを作成し，グーグルアースに落としたのが次の図６である。良い感じだ。2018, 2019年に川口さんと光波測量した際の光波測距儀の設置点も表示したのが図７である。

　回転後のポイントg-rotは，2018, 2019年に川口さんと光波測量した際の光波測距儀の設置点ls_5に一致するが，図７ではずれている。ortho.tifが手に入れば，2018,2019の座標系のls_5をg-rotに平行移動して，その後に必要ならば回転してortho.tif上に2018,2019の座標系を載せたいと思っている。

以上，0:10，Dec. 9, 2023記。

1. 国土地理院の座標系変換ツール

　地理院ホーム  > 位置の基準・測量情報  > 測量計算サイト には，座標系変換ツールが提供されている。特に多用するのは次の前２者であるが，後２者も有効である。
ツール１：平面直角座標への換算 (緯度、経度から平面直角座標へ換算)　
ツール２ : 緯度、経度への換算 (平面直角座標から緯度、経度へ換算)
ツール３：距離と方位角の計算　(緯度、経度から２点間の距離と方位角を求める)　
ツール４：距離と方向角の計算 (平面直角座標から２点間の距離と方向角を求める)

　前２者では，DMS（度分秒）表示とDEG（度10進）表示の相互換算が問題となる。国土地理院の計算サイトでは，DMS（度分秒）の入力が工夫されている。「平面直角座標への変換」ツールでは，次の入力例が示されている。
緯度 36° 6′13.58925″ →　 360613.58925
経度 140° 5′16.27815″ → 1400516.27815
DDD MM SS.sssss → DDDMMSS.sssss
　つまり，度の２〜３桁，分の２桁，秒の２桁+（秒十進）という形である。
　この手法を使うことで，DMS（度分秒）表示とDEG（度10進）表示の相互換算が簡便になるのである。相互換算は国土地理院のツールと他のアプリ，例えばGoogle Earth Proなどとの連携が可能になる。換算法を次の章に示す。
　なお，Google Earth Proのパス計算機能には，グーグルアースプロの限界 に示しているように，大きな限界がある。それに代わって，後二者のツールを使うことができる。

2. DMS（度分秒）表示とDEG（度10進）表示の相互換算

　ワールドウェアのMicrosoftアプリ「エクセルExel」の計算式をここでは確認したい。次のMicrosoftのサイトには，
How to convert degrees/minutes/seconds angles to or from decimal angles in Excel
が掲載されているが，結局，次の式で問題がないだろう。他のサイトで掲載されているものとも一致している。

2.1 DMS表示からDEG（度10進）表示へ換算

テキストを次に示す。=INT(A6/10^4)+INT(MOD(A6,10^4)/100)/60+MOD(A6,100)/60^2

2.2 DEG（度10進）表示からDMS表示へ換算

テキストを次に示す。図と少し異なるがこの方がエクセルが受け入れやすいようだ。MODを使っていない。
=VALUE(INT(A7)&TEXT(INT((A7-INT(A7))60),”00″)&TEXT(((A7-INT(A7))60-INT((A7-INT(A7))60))60,”00.000000000″))

以上，Dec. 2, 2023記。

パスpathの精度

　drone測量で，公共座標点がうまく取得出来ていない場合，drone測量結果を編集する際，グーグルアースプロを使う誘惑に駆られてしまった。２地点間の距離は，垂直成分を含むのかどうか，という点が最も気になったことであった。Google Earth Help > Community に情報があった。

Does the Google Earth path tool consider the elevation during the distance measurement?

ここでは，水平距離200mほどの丘の測量値とGoogle Earth Proのパス測定値との大きなズレなどについて，質問している。質問のタイトルだけではない。

さて，GEProの技術者の回答は次のようだ。

Alchemist251
Diamond Product Expert
May 13, 2021

HI Arun,
For some reason, your post just showed up in the Google Earth forum today, May 12.
The digital elevation model used for most of the earth is from the SRTM recorded in February 2020. It’s a general survey and not specifically accurate by any standard. It simply happens to be the only digital elevation data that covers most of the earth. In the US, elevation data points are 30 meters apart and everything in between is interpolated. In other areas, the points may be 90 meters apart. The Jet Propulsion Lab will only guarantee accuracy of the data points as +/- 16 meters 95 % of the time.

There’s no documentation of how the elevation profile works. Over the years, it has had various glaring errors. You can’t use it for the level of accuracy you’re looking for.

I know that doesn’t help but it’s the situation that exists.

　上記中の精度の記述で注目されるのは，赤字の部分だ。only guarantee accuracy of the data points as +/- 16 meters 95 % of the time　これには驚いたし，なるほどと納得された。

　さらに，他の技術者が回答している。

Alchemist251
Diamond Product Expert
May 14, 2021

Arun, the ruler path tool doesn’t consider elevation change. This is in line with how surveyors measure property. So, if a piece of property contains a cliff, you get the face of the cliff for free. That doesn’t help hikers much, I know.

　距離に垂直成分は含まないということである。光波測距儀を使った結果との比較をしてみようと思っていたが，まあ，技術的な意味はゼロであることがわかった。まあ，ゼロでも，ここに後に提示したいと思っている。

以上，Dec. 1, 2023記。

GEProで使用されている画像の使い方を考える

Help Center > Community: Explore the EarthHow images are collected は参考になった。衛星写真や空中写真はモザイク利用がなされており，シームレスに繋げられている，ということだ。このシームレスに繋ぐ技術って，当方は凄いなあ，と思っている。3Dオブジェクトは空中の撮影場所が変われば大きく倒れ込む。これをできるだけ防ぐ技術があるのだ。ちょっと気になって，スカイツリーを見たくなった。

以上，13:08，Dec. 1, 2023記。

　予想していたけれども，GEProでのスカイツリーは，360度回転しても，この図１の写真が回転するだけだ。関東地方全域が入るように縮小表示しても画像のどの部分も変わらない。当然ながらオルソ画像ではなくて，モザイク写真だ。GEPro内からGoogle Map表示にすると，写真モードで同じ画像が表示されるが，地図モードにして表示したのが，図2である。スカイツリーの構造体は表示されず，東京スカイツリーという表示があるだけだ。この緯度と経度を見ると，35.71011, 139.81069とある。図１でタワートップの白い円盤の中央にプッシュピンをセットして，その経緯度を見ると，35º42′39.76″N, 139º48′38.48″Eとある。
　図２のDEG（度10進）値35.71011, 139.81069をDMS形式に換算すると，それぞれ，35º42′39.396″N, 139º48′38.484″Eとなり，緯度に多少の違いがある。何れが正しいのか，不明ではあるが，恐らく図２に係わるDEG（度10進）値が正しいのだろうと思う。図１の写真を使ってタワートップ中央にプッシュピンを配置する方法は，精度を求めるならば，不適当と言える。

GEProの位置精度

　さて，こうなると，Google Earth Proの測量利用への期待値は大きく下がって，使えるかも知れないのは，唯一，位置情報ということになる。図１から想定できるが，見える画像とプッシュピンで刺した地球上の位置は，厳密には合致しない。水平位置というタームは，厳密には不適当で，今後は空間解像度 spatial resolutionという表現にしたい。GEは，米軍の使用で始まるWGS84 ellipsoid parameters and UTM projection，が使用されている。

このテーマでの報告はかなりの数に上るだろう。そのうち，4件を簡潔にここで引用する。

１　David Potere (Princeton University, NJ, USA), 2008.　Horizontal Positional Accuracy of Google Earth’s High-
Resolution Imagery Archive. Sensors 2008, 8, 7973-7981; DOI: 10.3390/s8127973.

２　Nagi Zomrawi (Sudan University of Science and Technology, Sudan) et al., 2013. Positional Accuracy Testing of Google Earth. INTERNATIONAL JOURNAL OF MULTIDISCIPLINARY SCIENCES AND ENGINEERING, VOL. 4, NO. 6, JULY 2013, pp. 6-9.

３　Peter C. Nwilo (Department of Surveying and Geoinformatics, Faculty of Engineering, University of Lagos, Nigeria) et al., 2022: POSITIONAL ACCURACY ASSESSMENT OF HISTORICAL GOOGLE EARTH IMAGERY. published by Springer in Applied Geomatics, 2022. The final published version is available at: https://rdcu.be/cSgXZ, 36p.

４　Jing Guo (National Quality Inspection and Testing Center for Surveying and Mapping Products, Beijing, China) et al., 2021. HORIZONTAL ACCURACY ASSESSMENT OF GOOGLE EARTH DATA OVER TYPICAL REGIONS OF AUSTRALIA USING WORLDVIEW. The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLIII-B3-2021, pp. 763-768.

　３の文献はナイジェリアでのGoogle Earth（GE）とSRTM（the Shuttle Radar Topography Mission v3.0）の画像の2000〜2018年の比較をしたものである。この期間を４期に分けており，RMSEs (the root mean square errors)の評価をしている。水平精度hotizontal accuracyに注目すると，

In terms of the horizontal accuracy, the root mean square errors (RMSEs) are as follows – year 2000 (29.369m), year 2008
(28.391m), year 2012 (10.615m) and year 2018 (10.603m). The most recent GE imagery (year 2018) was the most accurate while year 2000 was the least accurate. This shows a continuous enhancement in the accuracy and reliability of satellite imagery data sources which form the source of Google Earth data.

とあり，GEの精度は年々，改善されていることがわかる。

　そのため，古い文献をみても現状を知ることはできないのである。１の文献では地域別の評価がなされており，Southeast and East Asiaが最も精度が低くなっていることはわかるのである。日本がGEにとってどう評価されているのかは不明で，Europe並の精度が提供されているかは不明である。２の文献はナイジェリアでの評価であるが，奇妙に高い精度を示していて，他の評価との間に大きな懸隔がある。

　結局，使用可能なのは，４の文献である。著者５人全員が，北京の研究所のスタッフで中国人であるが，オーストラリア大陸での評価をしている。要旨を次に示す。発行年次は2021年であるが内容は３の文献よりも２年ほど新しく，最新の内容を持った文献と言える。

ABSTRACT:　Since the release of Google Earth image data, it has been the most widely used remote sensing data worldwide, and its accuracy evaluation has also been the focus of historical research. However, the researchers found that Google Earth’s image accuracy assessment results have obvious regional characteristics. This article uses the Australian continent as the research area and WorldView-2 remote sensing images as reference data to study the accuracy evaluation results of Google Earth data. The research shows that the overall accuracy of the assessment area in Australia is better. The areas with the best overall accuracy appear in the western coastal areas, with an accuracy range of 0.7-1.4; the accuracy assessment results in the central desert area are also better, with the accuracy range 1.4-2.2, and the areas with the worst accuracy appear in the western mountains and hills of 14.5 and17.1.

　現在公開されているものとしては最も高い精度のWorld View – 2 (WV)と比較しており，結局，地形環境の違いが精度を決めているということになる（図１の23カ所のレーベルが欠落しており，論文の議論が理解しがたい点が多々有るが，リモートセンシングを使いこなしていない当方としては知識そのものには，興味は感じた次第）。起伏や植生が多い山岳地域よりも，砂漠や海岸での精度が高くなっている。日本の離島の海岸での精度をこれから推し量ることは無謀かも知れないが，空間解像度は，1〜2mほどの精度ではないかと考えられるのである。

　この４の文献は，他の３点の文献の流れと対照して，違和感はなく，信頼して良いものと思う。この１〜２ｍという情報は，グーグルアースを自らの測量の補助として使い得ると感じて，安堵したところである。画像そのものではなく，pushpinを刺した地点の地球上の位置精度の意味と考えてのことである。

以上，Dec. 2, 2023記。

　

はじめに

　drone測量の際に公共基準点を利用できない事態が生じた。drone測量の経験が不足していた結果であった。drone測量で得られた空中写真と現地情報とを繋ぐために，１点にのみ設置した光波測距儀から得られた７点のgcpについて，drone測量から得られた空中写真上で同定した。以上の結果だけでは地球座標系との関係が得られず，光波設置点を後方交会法で求めた。（Nov. 2023にはこのことを失念していて，光波測距儀設置点をiPhone 12 ProのGPS計測値としていた）。2020年の調査から帰ってearly April, 2020には，drone測量結果からDEMやortho.tif画像を得たのであるが，Nov., 2023に検証してみると，GEProの画像とかなり一致していないことがわかり，このページ作成時には，GPSの精度の問題と誤解していた。

　そこで，測量時の記憶と現場写真，さらには，GPSを使ったgcpとGEPro画像のズレを考慮して，GEPro上で光波測距儀設置point，今後，ベースと呼ぶが，これを，仮に設定した（図１のbase-gps，茶色のプッシュピン）。その結果かなり改善されたのであるが，数メートルのズレが生じている（図１の茶色のプッシュピンで，a-gps〜g-gpsの7点）。そこで，GEPro上で画像を観察して，手作業で７点のgcpをプロットした。これを使って，後方交会法でベースを求めることにしたのである。

　前段も誤解で，結局，April 2020年と同様，後方交会法を使うのであるが，GEProの画像上でのgcpの位置を再検証して，かなり確かな位置を得たのである。つまり，７個の赤いプッシュピンは，droneで撮影した空中写真や現場写真などをここ数日，見直して決定したファイナルな結果である。

　まあ，この文章も混乱しているが，とにかく，April 2020 時と同じ後方交会法を使うことになる。

1. GEProの画像上のgcp７点から３点を選定

　後方交会法，この調査に関して，はじめて使おうと思ったら，すでに調査直後にVisual Basicでエクセルに組み込んで，計算が完了している。このウェブページを作成すべく，過去の当方のウェブサイトを検索するなどして，エクセルに計算プロセスを組み込もうとしていたら，このmacより古いファイル群の中に当方が作成したものがあった。この検証もしたいと思う。

　図１のほぼ中央に民家があって，この敷地内にbase-GE（茶色のプッシュピン）がある。このベースから光波測距儀を使って得たgcpの位置を7個の茶色プッシュピンで示している。GEPro画像での赤いプッシュピンは（ほぼ）正しい位置であるが，茶色のプッシュピンはほぼ反時計回りに回転しているように見える。7点の回転角度を求めて，時計回りに回転補正もできるが，ただ，図１の北西隅に近いf-GEとa-GEではベースからの距離も多少縮める必要もある。

　base-pointの決定過程で，GEPro上の位置決めが多少粗かったので，改めて，GRPro画像上のより高い精度の位置同定を実行したので，これに見合うベースを求める努力をしてもいいのではと思う。その過程と以下に示す。

　後方交会法は3点以上で成立するが，当方がVisual Basicで作成したエクセルファイルがあるので，これを使いたいと思う。April 2020に，be氏から提供頂いたのは，図１の左上隅のb点（宇和美崎トップ），図１の北西隅のa点（ピナクルトップ），そして，民家（立方体2階建て）の鉄筋コンクリート（屋根？）上端南西隅のd点であった。最後のd点は，放射軸の長さが短いので，電柱byKのc点を選択したいと思う。April 2020と異なり，位置は再検証して，変更している。その違いも多少，取り上げるつもりである。

以上，Nov. 29, 30, 2023記。

2. 後方交会法の計算

　エクセルファイル 宇和美崎2020春back.xls に新たにスプレッドシートを追加して行こう。後方交会法で使用する3点は，a点ピナクルトップ，b点宇和美崎トップ，c点d電柱byKである。図２はGEからの読みを平面直角座標系に変換。2020年4月の3点のうちの共通点の平面直角座標系でのズレの距離を示している。

　http://motochan.sakura.ne.jp/public_html/KyozaiContents/85.htm　にVBAを使った計算手法などを示しているが，Googleブラウザーでは開かない。FireFoxやSafariが必要だ。将来，移転するつもりだが。

　図３には新たな光波測距儀のベースが求められているが，2020年４月に比べて，northingで北に1.8m，西に0.1mしか変わらなかった。経験的に言うと，現場写真などでGE画像上で求めたベースよりも北寄りになっていて，改善されていないことがわかるが，一応，再計算してみたいと思う。意味がないと思いつつ。

　この原因は，後方交会法の限界というよりも，GE上での実GCPの同定の際に，GEのモザイク画像の歪みが大きいと思う。グーグルアースプロの限界 参照。

3. GCP７点の再計算

　後方交会法で求めた光波測距儀位置（宇和美崎ベース）を使ってGCPの再計算を実施した。

　

4. GE表示のために平面直角座標系を経緯度座標系に一括変換

　図５の結果を使ってkmlファイルを作成することになる。

5. KMLファイルを作成してGEに載せる

　残念っ。新たに満を持しての後方交会法で求めたベースからgcp７点をプロットしたのが図6だ。GEProから想定したベースよりもかなり離れてしまった。やっぱり回転かいなあ。

以上，Dec. 2, 2023記。

　3D点群や3DメッシュはCloudCompareなどで3D表示できるが，フィールドワークでの測量地点でのレーベル情報などをこの上に取り込んで表示することはできない。そこでGoogle Earth Proに期待して，このページを作成した。

1. Metashape が提供するKMZファイルについて

　ドローン写真測量の結果は，KMZファイルとして出力が可能のようである。uwamizaki.kmzを共同研究者から頂いてGoogle Earth Proにインポートしようとした。

　拡張子kmz（1.12GB）を，zipに変更して，それを解凍した（3.55GB)。GEで，uwamizaki.kmzをimportしようとしたが，これでは，解凍フォルダ中のkmlでも，解凍前のkmzいずれも選択できない。図１のように，ファイル名:”model.dae”エラー　ファイルを読み取れませんでした，。左ペーン最下部の保留の中に，Agisoft Metashapeのリンクが見える。これをクリックすると，図２などが現れる。どうも，Agisoftのプラグインが必要のようなので，当方はこれ以上，触れない。

　なお，KMZファイルについては，https://developers.google.com/kml?hl=ja　に次の記述がある。

doc.kml ファイルが 10 KB よりも大きい場合や、doc.kml ファイルから他のファイル（画像、サウンド ファイル、モデル、テクスチャ）を参照している場合は、KMZ ファイルを作成する必要があります。

1.appendix

　ファイル名:”model.dae”エラー　ファイルを読み取れませんでした，については，Googleが提供する次のページが参考になる。KML（Keyhole Markup Language）のモデルが参考になる。このページを紹介する。

　「KML では、3D モデル（建物、橋、記念碑、彫像など）を COLLADA 交換ファイル形式でインポートできます」，とあり，この「COLLADA 交換ファイル形式」が，model.daeになるようだ。　

「当該ページではサンプルモデルとして，Macky Buildingであり，この完全なテクスチャード モデルを含む KMZ アーカイブには、次のファイルが含まれています。

• doc.kml – 上記の KML ファイル。COLLADA（.dae）モデルをインポートし、Google Earth に配置します。このファイルは KMZ（ZIP）ファイルのルート ディレクトリに配置します。
• files/ ディレクトリ – モデルのジオメトリ、テクスチャ、マテリアルを定義する COLLADA ファイルが格納されています。Macky Building の例では、COLLADA ファイル（CU Macky.dae）と、建物のテクスチャに使用する JPEG の画像ファイル（CU-Macky-BrickwallnoCulling.jpg、CU-Macky–Center-StairsnoCulling.jpg、CU_Macky-EastdetaildoornoCulling.jpg など）が多数このディレクトリに格納されています。」

　この引用文の，「COLLADA ファイル（CU Macky.dae）」が，model.daeの一例になっている。

　AIの回答では，model.dae」エラーには、次のようなもの，を示している。

• 「Document is empty」
• 「Error parsing XML in daeLIBXMLPlugin::read」
• 「The document “model.dae” could not be opened」
• 「Unable to download model」

　このうち，be氏の処理に問題が無いばあい，「The document “model.dae” could not be opened」，の可能性が高いだろう。macのram memoryは16GBなので，winの64GBでトライするのは無駄では無いだろう。

2. Metashapeが提供するgeotiffはどうだろうか

　Google Earth（パソコン用）に地理情報システム（GIS）データを読み込む を参考しても。期待満満だったが，全然だめだめ。

　三択のうちは，一番期待していたスーパーオーバーレイを選択した(図３）。ファインダーのどこに分割kmzファイルを保存するのかが，現れる（図４）。保存先のフォルダーを指定すると，「イメージデータをインポートしています」のメッセージ。

　図５のように，表示されたが真っ黒。密度がありすぎるのではとどんどんズームインしたが図６のように真っ黒のまま。

　ファインダーで保存先のファイル数を見ると，5069項目もある。⋯⋯⋯⋯⋯-root.kml（527B）以外は，kmzファイルで729B〜7kBまでのサイズがある。トータル計20.8MBと，意外と少ない。図５のLibraryのファイル群も使用されるのであろう。ズームレベルに応じて拡大縮小される準備，と期待していたのであるが。全く駄目。

　次に，縮尺モードを選んだ。図７の保存過程では，元データとリンク先Library内のパスが見えて，図８では，標高タブで海抜を指定している。現れたのは図９のように，海上に黒い枠が。

　最後の，切り取りモードを選択した。ウィンドウの中心を選べというので，それに従うと，クリックした場所に黒い影が。GE Proの歪んだDEMに黒い帯が載っただけ。執拗に，縮尺モードで，標高を，地面に固定，にすると，GE Proの歪んだDEMに黒い帯が載っただけ。

　もう，GeotiffのDEMを諦めて，Ortho画像の表示を見てみた。図13で無事載ったのであるが，歪んだGEのDEMに載っただけで，意味無しだなあ。

　GE Proでは，Metashape出力ファイルは，使えない。

以上，Nov. 3, 2023記。

　orthoしか使えない結果から，使える，という方向性に替えて，次のページを作成した。

保護中: 3 Comparative checking btw a 3D model and the electro-optical distance measured net

以上，Nov. 5, 2023記。

3. GE Proでの表示の限界を知る

　Metashapeの限界とGoogle Earth Proの限界の観点からこの章を作成したいと思う。Google Earth（パソコン用）に地理情報システム（GIS）データを読み込む の情報は最新，簡潔，で問題はないが，demについては記述されていない。

3.1 dem.tifをGE Proでimportはできなーい

　How to Overlay the GeoTIFF file on Google Earh では，衛星から取得されたgeotiffファイルをGE Proにimportすると，その範囲が白い区画になってしまうというものである。本ページでは黒い区画になるという違いはあるが。その問の応えに，

First thing to check is that your GeoTiff images are 3-band RGB images, which is the only type of GeoTiff that Google Earth can import & display. 

とあり，GEでは，3-band RGBイメージしか，取り込めないということであった。ファイルがそれに対応しない場合，GISソフトで，RGBイメージだけ抽出せよという。demはGE Proでは取り込めないということである。

　上記質問では，次のページが紹介されている。Importing GeoTIFFs to Google Earth Pro as Super Overlays では，海底の深度図であるが，demではない，RGB画像に過ぎないので，表示できただけだ。

　Import dem with google earth ap,i Dec 20, 2011　では，

It would also be theoretically possible to generate a COLLADA model of　the terrain from your DEM and import as a KML , but that couild　get pretty involved.

とあるが，説明は無い。

Topic: Export model or DEM to Google Earth (Read 5049 times)，December 10, 2016　は，MetaShapeのページである。質問者は，前のバージョンの PhotoScanではできたけど，今の2016年のバージョンでは出来なくなった。でもPDFでできた，という。回答者は，GE ProはRGB画像だけに対応しているとか何とか言っている。議論がかみ合っていない。質問者はDEMがわかっていないようだなあ。

3.2 GISでしか

　結局，GrassGISやQGISでDEM上に，point shapeを載せるぐらいに過ぎない。コンターでは海岸地形を表現できないから，orthoとpoint shapeをGE Proで表示して使うしかないなあ。

以上，Nov. 5, 2023記。

　この種の一般的な認識を適宜書き込んで行く。

1. CloudCompareと世界測地系の表現

　世界測地系では，(x, y, z) = (northing, easting, altitude)であるが，CloudCompareでは，(X, Y, Z) = (easting, northing, altitude)であった。確かめた結果である。

　図１の赤〇は適当に配置している。マウスの手がスクリーンショット（今後SS）に撮影されていない。だが，最下段右にはその座標値が見える。

　CloudCompareの座標系は，基礎数学でなじみのあるCartesian coordinate system直交座標系に対応しているのである。

　なお，気になるところがあって，図3のPoint 2のZ値が，0.899945 mとなっていて，中等潮位から1m近く高くなっている。ドローンデータの整理で使用したCP control points情報を確認する必要がある。
　連絡掲示板 > 2 Trials and tribulations on 3D contents 1.3 個別的な確認：沖永良部島大津勘ビーチロック海岸，の方で議論する。

以上，Oct. 27, 2023記。

　共同研究で，ドローン撮影して頂いた，地形ファイルの取り扱い過程を，このページに記す。分析過程については研究連絡ページで論じる。

1. macでファイル受信

　ドローンで3D写真測量を実施。撮影者からファイルをMicrosoft365のOneDrive経由で送付頂いた。PLYとOBJである。いずれも類似の3D faceファイルであり，点群との関連性も高い。OBJの欠点を改善したのがPLYだそうだが，OBJの肌理などの面再現能力は高いと感じている。PLYはOBJのように画像ファイルは含まれていず，軽い点が魅力と考えている。こういった感想は使用してきた経験からのものである。
　図１の右端のファイル情報を見ると，OBJのダウンロードには，２時間16分を要している（OneDriveでは14.5GB，ダウンロードの結果では15.6GB）。図２の右端のファイル情報では，PLYのダウンロードは40分で終わっている（OneDriveでは4.31GB，ダウンロードの結果では4.63GB）。容量からすると，所用時間に差はほとんど無いか。

　OBJファイルのダウンロードは２回失敗した。当方のmacの設定故らしい。macを放置して戻って来た時に画面が暗い場合，escキーを叩くが，ダウンロードフォルダーには影も形も無くなっている。原因はディスプレイの設定である。赤枠で示した場所には，「電源アダプター接続時に使用していない場合はディスプレイをオフにする」，を，デフォルトで，「する」，となっていた。ディスプレイの電源を落とす，という選択である。これが悪さをしていたようだ。「しない」に設定すると，macから離れていても，スクリーンセーバーが持続的に稼動しており，ディスプレイは強制的にオフにはならない。
　だから，こういう大容量のファイルのダウンロードの際は，「しない」を選択するが，赤枠の注意書きにもあるように，通常は，具体的時間を選択した方がいいようだ。例えば，30分とかである。

以上，Oct. 23, 2023記。

2. macからWindowsマシーンへ3Dファイルを移動しようとしたが

　さて，USBメモリーを使って，ファイルコピーしようとしたが，macが受け付けてくれない。メッセージを見ると，このUSBメモリーは，I-O DATA製らしい，初めて知った。I-O DATAのサイトからこの対処法を知ったが，macのセキュリティを下げるというものであった。このUSBメモリーを使うために，セキュリティを下げるのはまずいと思った。
　それで日頃使用しているmacとmouseWindowsマシーンと？？？？するのが適切と考えたのである。

2.1 NTFS-3G for mac I-O DATA Could not mout

　「NTFS-3Gは、WindowsのNTFSというファイルシステムの読み書きをサポートしたオープンソースのクロスプラットフォーム実装である。NTFS-3GはFUSEファイルシステムインタフェースを使っているため、様々なオペレーティングシステム (OS) 上で修正することなく動作可能である。動作が報告されているOSとしては、Linux、macOS、FreeBSD、NetBSD、Solaris、BeOS、Haiku がある。」（ウィキペディア）

　macは，セキュリティ向上のために，これに対応しなくなったということになる。上記対応リストにWindowsが含まれないのは，実際使えていることからすると，理解できないが。

　図４は，USBメモリーをmacに差し込んだ際の拒否メッセージ，である。検索して，I-O DATAのサポート情報に出会った。
【NTFS-3G for Mac I-O DATA】インストールしてドライブを接続するとエラーが出てマウントされない，である。この一部のスクリーンショットを図５に示す。macそのもののセキュリティを下げなさい，ということだ。これは受け入れ難い。他の選択肢があるのではと考えた。

2.2 サーバー接続でmacとPCのファイル移動

　経験的にmacとWindowsマシーンの接続が可能になったので，ここに誌しておく。過去の両者の接続または共有関係は，一つのフォルダーについてであった。ぼくの場合は，Mac_Win_Shared，というフォルダーを利用してきた。mac内のParallels Desktop内のWindowsとの共有フォルダーであった。macもWindowsも使用環境が改善されて，現在の便利な環境が生まれていると思う。

2.2.1 Drop Box経由

Windowsとmacの両方がDropboxを採用しており，その結果が，Dropbox経由の共有フォルダー環境を生み出したものと思われる。

●　ウィンドウズ側での設定：　
デスクトップに共有フォルダーMac_Win_Sharedを用意。フォルダー上で右クリックして，プロパティを選択する。

全般タブでは，Mac_Win_Shared，が，C:\Users\moto\Dropbox\PC\Desktop，に配置されることになっている。

共有タブでは，リストが３個用意されている。ネットワークのファイルとフォルダーの共有，では，ネットワークパスは，\MYCOMPUTER\Mac_Win_Shared，となっていて，共有ボタンをクリックすると，共有する相手を選んでください，とあり，右手のプルダウンのリストにEveryoneが見える。そして，右手の，追加ボタンを押すると，リストにEveryoneが表示される。この右手の，アクセス許可のレベルのプルダウンのリストで，読み取り/書き込み，を選択して，共有ボタンをクリックする。
ユーザーのフォルダーは共有されています，というメッセージが見えるのを確認して，終了ボタンを押す。
共有タブの，詳細な共有ボタンをクリック。このフォルダーを共有する，に✓が入っている。
アクセス許可のボタンを押すと，グループ名またはユーザー名として，Everyoneがあり，このままに。
アクセス許可の内容については，デフォルトでは，読み取り，にだけ，許可，が✓されているが，フルコントロール，変更にも，許可の✓をいれて，OK。

カスタマイズタブで，フォルダーアイコン，から，アイコンの変更を押す。二人上半身を選ぶ。

この作業は不要かも知れないが，やってしまっている。この手法の問題点は，Dropboxを経由することである。というか，Dropboxにファイルが保存されてしまう。大容量のファイルを両機とやり取りするには，問題が多すぎる。駄目だな。

●　macの方では，Finderのメニューバーで，移動 >サーバへ接続，すると，サーバへ接続パネル，が表示される。ぼくはすでに設定しているので，Smb://mycomputer，が出ているから，下方の「接続」ボタンを押すことになる。最初の時にはユーザー名やパスワードの入力が必要になる。

2.2.2 mac ファインダー > サーバーへ接続：　Dropbox回避してファイルやフォルダーのコピー

　ここから述べる過程で，Dropbox経由から回避できる。macのファインダーのメーンメニューの，移動 > サーバーへ接続，を選択すると，図６の，サーバーへ接続，パネルが現れる。パネルで選択されているのは，すでに登録されている，smb: mycomputer，である。SMB（Server Message Block）はファイル共有などの際に使用するファイルサーバー機能で主にWindowsで使用されている通信プロトコルである。具体的にはぼくのmouseWindowsマシーンにあたる。よく使うサーバーのリストのトップに見える，下段のブラウズボタンを選ぶと，ウィンドウズ内の特定のフォルダーを選択することができる。ブラウザーで選択した場合，Dropboxから回避できるのである。Mac_Win_Sharedフォルダーは，上記の過程を経て作成したもので，Dropboxを経由する。
　図6に見えるmacのデスクトップには，三つのドライブアイコンが見える。Mac_Win_Shared，win_moto_documents，そして，Usersである。後の二つはこのようにブラウズして作成したものである。Usersの場合，この下位のどこのフォルダともアクセスできるので，他の二つのドライブアイコンは不要ではある。図７では三つのドライブ名が灰色になっており，選択されていることがわかる。図８の場合は，Usersを選択した際に見えるウィンドウズ内の３フォルダーである。mac内のフォルダーやファイルのように扱うことが可能である。

2.2.3 大容量のファイルのコピー

　大容量のファイルを，macとWindowsマシーンの間で，やり取りする，試行をして，失敗した。USBメモリーを使うのにmacのセキュリティを下げる必要があって，一時的に下げて戻す，とやれば早いのであるが，そういうプロセスを取るのが嫌で，macのサーバーへの接続を使った。しかし，これには限界があるということを知った。文字が何とか読めるように，スクリーンショット（略号：SS）画像１枚毎にアップロードした。
　図9では，macの，サーバーへの接続，を実行して，macにWindowsの中味を表示して，20.23GBほどのuwamisaki.objとuwamaizaki.plyが入ったフォルダーをコピー開始している。

　20:24スタートして，21:26にPLY 3.49GBのコピーが完了している。所用時間は6時間表示のまま。図10にはWindows画面で確認した。どうも，ぼくがこのパスに移動したようだなあ。

　22:29にダウンロードフォルダーを確認したのが図11である。uwamisaki.objが1.31GBになっており，未確認というファイルが見える。ダウンロードが完了するとこのファイル名が，uwamisaki.objに変わるという印象なのだが，OBJファイルのサイズはズーと変化がなかった。

　22:42に，macで，エラーコード100060が発生。ぼくが何かを触ったのかはわからない。このコードナンバーは，ファイル移動の際に生じるようだ。理由はアクセス権の問題のようだ。電源容量の情報もあるがこれは直接的な理由ではない。

　22:45のウィンドウズの画面が図13だ。コピー作業がmacでは切断できないので，Windowsを終了することにした。

　それでも，macの方でサーバー接続の解除ができない。ヒエー。

2.2.4 macからの移動を諦めてWindowsマシーンでダウンロード

　もうコピーは諦めて，Microsoftからのダウンロードすることに。Windowsマシーンで，Google Chromeに登録しているoutlookを開いて，Microsoftのダウンロードサイトから，ダウンロードを開始した。Google Chromeの最上部のリボン右端の縦に…が並ぶ部分をクリックすると，「ダウンロード」が見えるのでこれを選ぶと，図14のように，ダウンロードタブが表示される。これで，ダウンロードの現状を見ることができる。図14ではPLYのダウンロードの様子である。

　ブラウザでダウンロード状況をみたのが図15。パスを見ると，Dropboxを経由しているようだ。

　次にOBJをダウンロード開始。図16のリストの上から二番目にPLYが見え，「フォルダを開く」とある。これをクリックするとWindowsマシーンのダウンロードフォルダーを見ることができる。

　図17に見えるように，Dropboxを経由している。ダウンロードが何故か急激に進んで終了。13.16GBしかない。

　ダウンロードしたファイルをwin_3d_scanのパスに移動した。PLYは4.52GB, OBJは13.16GBだ。トータルで17.68GBしか無い。

　図19にはDropboxの中味が見える。軽いファイル３個のみ。

　これまで使ってきたSSは，編集したものである。macとWindowsでのものである。Windowsのものは，PC > ピクチャ > スクリーンショット，に保存されるが，これをmacにコピーするのに，Mac_Win_Shared，フォルダーに保存したいと思った。図20は全スクリーンショットを選んだところである。図20の後，Windowsのデスクトップに共有用に作成したMac_Win_Sharedフォルダーに移動した。

　その結果，mac上では，図21のmacデスクトップ右端のMac_Win_Sharedドライブ，を開いたのがデスクトップ左手のウィンドウであって，右下のウィンドウはmacのデスクトップの常置しているWindows_schreenshotsフォルダーを開いているところである。左手のWindowsのスクリーンショット全体を，右下のWindows_schreenshotsフォルダーに移動（＝コピー）することになる。

　共有を解除するべく，図22のように，macデスクトップ上の三つのドライブを選んだ。

　図23のように３ドライブのうち，win_moto_documentsドライブが取り出せない。Windowsでダウンロードフォルダーからwin_moto_documentsにPLYとOBJを移動したのであるが，OBJのダウンロードが完了していなかったことに由来するのだと思われる。

　macでファインダーのリスタートなどして，何とか，図24の強制的な取り出しまで，辿り着いた。

　OBJがダウンロード中に改変されたりして，完了できなかった。Zipファイルで送ってもらうか，OBJの代わりにFBXを選ぶかだろうと思う。

　Windowsマシーンで分析などを実施するが，研究連絡ページでpassword protectedへ。

以上，Oct. 25, 2023記。

はじめに

　タニハの厨房をぼくは使用した経験はない。父の死後，隅田さんと山崎さんが通われるようになって，厨房のほぼ全面改装をした。その後は山崎さんが使われたのであるが，姉の買いそろえてきたものは恐らくさわらず，隅田さんと山崎さんなりの利用があった。新規のシステム？キッチンの収納などには擬似アルミ紙が貼られ，コンロ周辺には擬似アルミ紙が貼られている。
　システム？キッチン台もぼくがポリタンクなどを置いているだけのスペースだった。ドラフトのフードや手許用照明は油汚れで薄汚い。窓ガラスなどは４０年ほどは掃除もされていない。
　厨房と周辺の片付け，でぼくの過去の対処を示している。2022年夏〜年末にかけてかなりの時間をかけて対処したようだ。もう始めた頃に近くなってきた。システム？キッチンについては，収納部の鍋釜類をゴミに出したぐらいであった。
　で，それなりに片付けたのであるが，全く利用していない。今回の実験室への利用転換方針は，昨晩遅く，いいように感じ始めた。川口さんと実験しなければならない，６月２日から，そして他の用件もあって，ギリギリでこの作業に入る気持ちになったのである。川口さんの体調の問題が無ければ，６月２日から実験室としての利用開始だ。昨晩始めたが，明日も行かないとまずい。寝る場所の掃除などをしないといけない。
　年代測定のための前処理関係の道具を準備して，昨日運び込んで，姉が使っていたスティール棚をセットして，道具類をここに収納した。今思えば，まだ自宅に残っていて，これから運び出しの準備もしないといけない。他のハードな用件もある。疲れるなあ。

１　主に実験道具一式の棚への整理とシステム?キッチン磨き　May 26, 2023

　さて，長く続く懸案は風呂そばのシロアリ被害である。図１のように，廊下には穴が空いている。ここに実験道具を収納するスティール本棚を設置したいと考えた。掃除機を取りに東の二部屋に行き，図２のように蜂の死骸の山が粉末化しているのをみつけた。今年初めには無かったもので，相変わらず天井裏で営巣して，飛び立った一部が出れなくなって死骸となっている。この天井裏の穴を見つけないとこの状態は繰り返される。困ったなあ。業者さんにも来て貰ってミツバチの大きな巣を二つ撤去してもらったが，穴が見つからなかった。ぼくがやって見つかるのか？　見つかったら網を張ることになるが。図３のようにシロアリ害の上に自宅のぼくの書斎にあったシーリングファンのフィン４本をセットして，図３の右隅にみえる厚いゴム板を載せた。このゴム板は室内での縄跳び用で，奥さんが使用を許さなかったから一度も使っていない。やっと役に立った。

　図４にはシステム？キッチン全景を示す。掃除完了後のものだ。右端のコンロ台には，実験で使う200℃までの恒温ホットプレートを設置した。この上にはレンジフードがあるがかなり汚い。フレームカバー外して，油用洗剤で洗って再設置した。まあ綺麗なものではない。手許照明も汚くて，壊れたらもう少し良いものに替えたいとは思っている。木枠のガラス戸と網も汚くて完全に外して洗ったり張り替えたりする必要がある。この左上のパイプは隣接の茶室用のエアコンのものだ。
　

　図４のコンロ台の右手と奥手には，汚い剥がした跡がある。山崎さんが貼っていたものでかなり汚くて，ぼくが剥がした跡だ。昨晩，タニハから帰宅後，アマゾンで調べて，図５, ６の製品を注文した。この種の製品は凄く多い。山崎さんはDIYで恐らくこの種のものを購入して貼ったのであろう。耐熱を謳うがガスコンロで調理をする場所では役に立たないと思う。
　下記を購入したあとで，この種のものが軟質のPVC（ポリ塩化ビニル　polyvinyl chloride, 通称 PVC）であることを知った。こんなに有害！ポリ塩化ビニル（PVC）を避けた方が良い理由，では，「塩ビに大量に使用される添加剤は、ポリマー（プラスチック）と化学的に結合しているわけではないため、プラスチックから浸出する場合があります（Patrick 2005, Lithner et al. 2012）。たとえば合皮やビニールなどのやわらかい軟質塩ビからは大量に使われるフタル酸エステルが溶出することがあります（Patrick 2005, Lithner et al. 2012）。一番身近な例では、消しゴムを思い出してください。消しゴムって定規など他のプラスチックとくっついているときがありますよね？あれは消しゴムから可塑剤のフタル酸が溶出したからです。」などとある。
　まあ，今回の用途ではぼくに実害は無いが，この商品の使用用途で，キッチントップ，棚，引き出しなどに敷いて使ったりしているが，こういう用途は不適切であろう。図４の汚い壁面のサイズは，高さ40cm幅100cmである。汚いタイル壁面であるが，ステンレスのように磨き粉やサンドペーパーを使うことはできないので，手許にある種々の洗剤とタワシで取れるかどうか，チェックしてみよう。
　取れないようなら，２８日には届くこの製品を使うことになる。汚いしかも溝境界もあるタイル面なので，この製品を接着面から剥がさずにそのまま使いたいと思う。トライアンドエラーの作業が必要だが，接着面を出して，表面に貼れるかどうか。できるなら，段ボール紙を壁に貼り付けるのにセロテープを使うような要領で可能である。貼り付けることができないのであれば，上端と左端と右端の幅数センチメートルを裏紙を剥がして，部分的にタイルに貼ることも考えられる。さて，どうなるか。

図7, 8, 9：　サンドペーパーと磨き粉でサビはほぼ取れた。シンク使用後には固く絞ったタオルで水滴を拭く手間をかければサビは出ないであろう。シンク台には，底をセットした洗い籠に以外，何も置かないことが重要だ。

図10, 11, 12：　図11, 12はシンク左手を示す。図12はコンロ台を置く前だ。

以上，May 27, 2023記。

２　厨房の仕上げと他室の受け入れ準備　May 28, 2023

図17, 18：　床の拭き掃除，卓上の片付けなどを実施した。実験台になるが，養生用のシーツもあるので，それをセットなどしたいと思っている。シンク下の収納スペースのヤカンなども一部処分した。

図19, 20：　廊下の整理と拭き掃除。天井灯の点灯ヒモが頭に当たってきたが，ヒモを短くして，解決できた。先にヒモを切り取ったためにプラスチックの取っ手の小さな穴に入れるのに苦労した。取っ手を上方に移動してから切ればよかった。

図21, 22：　来客用寝室として使用すべく片付けとほとんど床だけの掃除だった。壁面，窓枠などの掃除もした方がいいのだが。余裕がない。

図23, 24：　居間のコタツを長く放置していた。掛け布団に弁当の寿司用の醤油をこぼしたので，クリーニングに出す必要がある。

図25, 26, 27：　準備完了。居間は食事やデスクワークをする場所になる。西之間は父のかつての寝室でここに始めて泊まることになる。

以上，May 29, 2023記。

３　川口さんと実験４日目　Jun. 5, 2023

　川口さんがかなり疲れてきた。昨日は，始めて風呂に行った。溪山閣の日帰り利用。ライン登録の日は半額の500円。川口さんはスマートフォンを忘れて1000円。なかなかいいRadium温泉であった。ぼくは第二駐車場の３０回以上の通いでついに背骨が曲がりヘルニアになった？　整形外科の診断ではそうだ。歩けないぐらい痛いことも６月３日にはあった。今日Jun. 5は少し遠出して園部に行ったが，丹後先生からお聞きした城下町の雰囲気はほぼ崩壊していた。旧都市の崩壊の時代だ。道路だけはやたらに作られている。無駄金だ。農業構造改善事業で意味無い沢山の幅拾い直線道路が作られた文化破壊現象と類似している。過去から培われてきた文化が崩壊している。

　図28には，年代測定のための化石前処理ツール群を置いている。掃除機で粉塵を吸う。シンクそばのまな板には小さな万力を設置。これも試料を潰すツールの一つだ。実体顕微鏡，照明装置，バランス，なども見える。

図30の２本のルーターrouterのうち，左はProxxon，右はMinimoのもの。いずれにもダイアモンドのビットをセットしている。Minimoでは高速で細かな部位のクリーニングをして，Proxxonではまとめて除去する。ビット交換が不要なので，この２本体制の利便性が高い。前者のビット使う際に先っぽだけ使うとすぐに使い物にならなくなる。側面にダイアモンドがちりばめられているので，側面を主に使うようにしないといけない。

　いずれも，コレットチャックの径は2.35mmである。プロクソン(PROXXON) ダイヤモンドビット2本 【矢型1.6mm 軸径2.35mm】 No.28215 を今回のために，新たに注文した。シャフト径:φ2.35mm。先端:ダイヤモンド電着，シャフト:鉄。先端形状:矢型。メーカー品番:No.28215。この同じものをすでに持っていたようだ。

　Minimoのマニュアルや付属部品を紛失しており，このルーターを使うことができず，本日，メーカーに電話して，マニュアルの一部をメールで送付頂いた。
　ミニター株式会社　https://www.minitor.co.jp/

大阪営業所	TEL.06-6531-5300担当地域：近畿・東海・中四国・九州沖縄エリア

　Minimoの「ハンドピース」は，モーターKM11とヘッドH011からなる。ビットの抜き刺しの方法がわからなかったが，サポートからメールして頂いた取扱説明書_H011.pdfの下記の部分を読んで明らかになった。

　川口さんとJun. 3に烟河前の湯ノ花平にあるTamTamに出かけた（図32）。土曜日であったこともあるだろうが大人気だ。初めて，こんな店が近所にあるのを知った。図33は玄関前で粗クリーニング中。

図34, 35：　満月Jun. 3, 2023の下で。祈念撮影した。二人とも爺さんになったなあ。川口さんが着ているシャツは学生時代のまま。

以上，Jun. 5, 2023記。

４　冷凍冷蔵庫とオーブントースター到着　Jun. 2, 2023

　川口さんとの宿泊を想像して，３日前にアマゾンに冷蔵冷凍庫を注文した。町で購入した弁当が腐らないように冷蔵庫が必要だった。冷凍庫はパンを冷凍するためだ。夏には，「アイスノン」を冷凍するのにも必要だ。２日前には，パンを焼くためにオーブントースターが必要と考えて，アマゾンに注文した。川口さんを亀岡駅に迎えに行く途中，タニハの前を通ったが，届いていなくて，川口さんとタニハに到着した際には，２個とも届いていた。アマゾンに感謝。冷蔵庫から出してすぐに弁当を食べる場合には電子レンジが必要だが，食べる前に多少早く冷蔵庫から出せば何とか食べることができる。冬には弁当丸ごと暖めることができる電子レンジがあれば便利だと思うが，鬱陶しい。

冷蔵冷凍庫：　アイリスプラザ 冷蔵庫 87L 一人暮らし 2ドア 両開き対応 小型 幅47.5cm ブラック PRC-B092D-B
アイリスプラザに，リサイクル回収サービス　というのがあるが，安い訳では無い。説明書に添付されているようだが。ダークウッドが欲しかったが６月２日到着に間に合わず，唯一この黒だけが間に合うという状況であった。
アマゾンで買ったが，アイリスプラザの方が2万円余り，安い。今後は，アイリス製品はアイリスプラザで購入した方が良さそうだ。取扱説明書。

●商品サイズ（cm）幅約47.5×奥行約50.2×高さ約85.8　●商品質量　約24.5kg　●定格内容積　87L（冷蔵室61L／冷凍室26L）（※1）　●定格電圧　AC100V　●定格周波数　50/60Hz　●定格消費電力　電動機：46W　電熱装置：4W　●年間消費電力量　202kWh/年（※2）　●電源コード長さ　約1.8m　●付属品　製氷皿、霜取り用ヘラ、卵トレー、清掃棒　●冷凍室の性能（JIS C 9607の規定による）　記号：フォースター　冷凍負荷温度（食品温度）：－18℃以下　冷凍食品の貯蔵期間の目安（※）：約3か月　※食品の種類、店頭での保存状態、冷蔵庫の使用条件などによって異なります。　●カラー　ホワイト PRC-B092D-W　ブラック PRC-B092D-B　シルバー PRC-B092D-S　ダークウッド PRC-B092D-M　（※1）定格内容量は、日本工業規格（JIS C 9801：2015）にもとづき、食品収納スペースと冷気循環スペースを含んでいます。　（※2）年間消費電力量は、日本工業規格（JIS C 9801：2015）にもとづき表示しています。実際の消費電力は、使用条件によって変動します。

オーブントースター：　アイリスオーヤマ トースター オーブントースター 4枚焼き 温度調整無段階機能付き シャンパンゴールド POT-412FM-N　「遠赤ヒーター，オーブントースター」とある。この遠赤ヒーターの特質が気にいった。取扱説明書。これはアマゾンの方が安かった。ピザなども丸まる焼ける。弁当を暖めるのも，アルミフォーイールをトレイに敷いて具材などを並べたら問題無いだろう。

　川口さんの来訪を契機に，この冷凍冷蔵庫とオーブントースターを購入したが，今後，タニハにぼく一人で泊まり込みで利用すれば，無駄遣いにはならない筈だ。

以上，Jun. 7, 2023記。

５　第１回一人実験　Jun. , 2023

　今後，実験作業を記録してゆく。

はじめに

　最近，標題の二つのアプリの名を知った。期待できるような気がしている。vGISは日本では知られていないようだが，アップルストアで購入することはできる。本日，下記の2件のテーマでこのアプリを使ってみた。

身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量で求める
　２ 神武天皇遙拝所碑のスケール実測3D　３ LiDARおよび写真測量で得られたイメージの限界

国土地理院の基準点成果の利用

　その結果をここに示したいと思う。

１　入手過程とその費用

１.1　Polycam 3D Scan
　日本語の幾つかのサイトの情報はアップデートされていない。https://poly.cam/pricing が正しい。アップルストアからぼくがダウンロードしたものは，年間12000円の選択肢しかない。3日間は無料だがこれを過ぎると自動で１年契約になる。使用頻度を考えると受け入れられない。今日May 25, 2023の午後３時頃から試用はじめたので，May 28の正午ぐらいにはキャンセルしないといけない。28日も丸一日タニハに居るから，結局27日にはキャンセルする必要がある。
　上記サイトでは，Polycam Proの年間費用は$80だから，換算レートは$1 = 150円だから受け入れられない。直接，上記サイトから申請した方が良い。

　月単位で考えると，$15だから，15 x 138/$ = 2070円だ。調査の際に，月単位で利用するのがいい。
　Academic（アカデミックメールアドレス）で申請すると，$80/2 x 150円/$ = 6000円だからこの選択もあるが，今回の試用の結果を評価して，他と比べて断然いい場合は，この選択もある。
　

１.2　vGIS Scan
　これは日本では認知されていない。vGIS Pricingで見ると，vGIS ARは，$1,250 USD per user annuallyだ。しかし，アップルストアからダウンロードできるvGIS scanには課金内容が見えない。クラウドの出力の際に請求があるかも知れない。まだ実行していない。ぼくの使用法からすると，vGIS ARは不要だ。ファイル出力の際に請求がきたら使用しないだろう。額によるが。

以上，May 25, 2023記。

２　ファイル出力までの情報

２.1　vGIS Scan

図2〜5：　vGIS Scan のルート図作成過程でのiPhone 12 Proのスクリーンショット。

　vGIS Scanのホーム画面はあまりにサッパリしている。アップルの写真アプリのように，とにかく，撮影画面から始まる。石丸二丁目交叉点の三等基準点3-61から始めてこれまでのアプリのように3-39で止めようと思ったがどんどん行けそうなので山麓線の3-42まで延長して，そばのちっちゃなカフェでイチジクパンとともに日本的なコーヒーを飲んだ。

　改めて今，vGIS Scanを開くと，Scansに２ファイルあって，
このルート図は最初のもので，May 25, 2023 14:35, 5803mb 488k Verts 2834 Images
とある。…を選ぶと，図４が現れる。下端のShareをタップすると，図５が現れる。

iPhone-LiDAR + Scaniverse or Metascanから書き出された点群とメッシュを比較 で，「3Dファイルのうち，汎用性の高いものは，メッシュではOBJ，点群ではPLYであるが，ターゲットの表現力は圧倒的に，メッシュのOBJである。点群の分析ツールとしてCloudCompareが優れていて，できればメッシュではなくて，点群ファイルが欲しいところである。」と述べたように，OBJ, Point Cloudが欲しい。ただ，KMZもあって，Google Earthでどのように表示されるのか興味深く，この３ファイルをダウンロードすることにした。
　自宅のWi-Fi環境下，AirDropでOBJをダウンロードしようとしたが失敗した。Google Drive 15MBは問題なく遅くも無く，ダウンロードできた。
　Point Cloudを選ぶと，XYZ color以下９種のファイル形式が見える。PLY with color 0-255を選んだ。トップのタブを見過ごしていた。Low Density, Medium Density, High Densityがある。Medium Densityがデフォールトのようであるが何と，3D Asset 1.81GB，もある。これも結構時間を要した。ここではHigh Densityにしてみよう。そして，Zip Files, Z axis up，のオプションもある。High Densityにすると，vGIS Scanは強制終了する。有料契約をしていないからのようだ。これが実現したとして1.81GBを遙かに超えるのか。経験的にあり得ないのだが。Medium Densityでいいとしてファイルが大き過ぎるので，Zip Filesの選択をしよう。Z axis upも選んだ。これは問題無く実行されている。Zip Archive 314.8MBと軽くなった。Google Driveにアップロードした。Untitled_Scan_20_27_46.zipというファイル名である。
　KMZでダウンロードしようとすると，図８のメッセージが出る。あまりに重くて表示などに困りそうだ。図７は点群ファイル群だ。ぼくが使うのはPLYファイル。図7の赤枠には，ぼくのiPhone 12 Proに現在インストールしている４種のアプリを示している。

２.2　Polycam 3D Scan

　さて，PolycamもvGIS同様，ルートと神武天皇遙拝所碑をスキャンした。図10のように，操作プロセスとしては，vGISよりもわかりやすいように思う。下端の「処理」を一応タップしたが測定後にすでに処理しているようで，上書きするかというようなメッセージが出る。「クロップ」もみたが特にこの例では必要ないようだ。上段のアップロードアイコンをクリックすると，Upload to Polywebとあって，このサイトへのアップロードのようでこれも必要ない。どうもはっきりしないので，…に○のアイコンをタップすると，図11のような表示が出てくる。
　命名して，ぼくの場合，exportがしたいようだ。ここに clear raw data 4.08GBとあるので，これは実行した方がよさそうだと思ったがどうもやばいので放置。exportを選ぶと，図12のようなファイル形式が現れる。ぼくはOBJだが，好きなFBXもリストにある。ポイントクラウドの方としてPLYを選ぶことになる。OBJはAirDropで成功した。zipで15.9MBだ。PLYのzipは，18.4MBでAirDropで問題が無かった。このサイズはすごく常識的だ。
　さて，vGIS Scanに比べて，余りにオプションが少ない。図12の上端右端に⇅みたいなアイコンがある。これを選択した結果が図13だ。
　POINT CLOUDについては，Point densityはMediumになっている。これをHighにした。Up axisはZ axis upのままに。
　MESHについては，up axisがY axis upになっているが，これもZ axis upにした。CloudCompareでの作業についての設定を忘れてしまった。で，もう一度，exportしてみよう。
そしてAirDropでエキスポートした。もちろんOBJのzipサイズは一致している。AirDropによるPLYの送信に時間がかかって結局失敗。Google Driveでトライ。PLYの zipサイズは51MB余となっている。

図10に見えるルート図は，図４よりも長い。そしてクローズドするように歩いたが，閉じていない。こういう限界があるということだ。vGIS ScanとScaniverseでも同じルートで実施してみよう。持続をサポートしているかはわからない。

　神武天皇遙拝所碑，もスキャンした。OBJをAirDropで転送した。656kBだ。PLYはAirDropで何故か早かった。2.8MBだ。この小オブジェクトのスキャン結果には驚いた。
　他のアプリでは周辺の建物や地面などを捉えるが，図14にはそういう兆候が全くない。ぼくが捉えたいものを察知しているようだ。身近な直方体の体積をiPhone 12 Pro+ LiDAR写真測量の図8には神武天皇遙拝所碑のサイズを示しているが，直方体部分の面の幅14.5mm（図15），高さ144.5mm（図16）に近い値となっている。指で適当にポイントした場所の問題があり，おそらくはほぼ正しく長さを示しているようだ。
　図14ほどの復元は他のアプリでも近い結果が出る。トップの四角錐は余りに小さくてどうしてもトップのトンガリを捉えることができない。これはアップルのLiDARの限界を示すものだ。

　このアプリはぼくの使用頻度としては余りに高額なので年間購入はできないが，月単位の契約をしたいとは思うが，ルートマップ作成機能の精度をチェックする必要がある。後述する。

以上，May 28, 2023記。

３　室内照明下でのスキャン

３.1　vGIS Scan

　夜間，部屋の照明を消して，スキャンを始めた。赤く画面が表示され，部屋のソファがワイアーフレームで描かれた。喜びの声を上げたがその後，画面全体が赤く染まったままになった。何らかのブレーキが働いた感じであった。iPhone 12 Proのデバイスそのもののポテンシャルは暗がりでLiDARスキャンできるのであるが，何らかのブレーキがセットされている。アプリによるものではなく，アップルデバイスの設計に基づくブレーキであろう。おそらくUSAの軍事的技術に係わるものと思わざるを得ない。ソニーなどもUSAの規制が働いているので，中国製のデバイスこそ期待できる可能性もある。
　残念ながら，部屋の一方の明かりだけを点灯して，スキャンを実行した。

図17〜19：　vGIS SCANによる夜間の照明下でのスキャン結果である。坐る場所が異常に膨らんでいる。床も捲れ上がっている。使えないなあ。

図20〜22：　図17〜19は，textureモードでの表示である。vGIS SCANの他のモードについても一応，表した。同じ3Dスキャンファイルなので改善される訳ではない。textureモードが構造の認識の点でも最も使えるもののようであるが，とにかく，vGIS Scanは，室内屋外を問わず，小空間のLiDAR測量には不適であることがわかる。なお，元のソファは次のPolycam 3D ScanのLiDAR測量結果からイメージできるであろう。

３.2　Polycam 3D Scan
　図23, 24,25： vGIS Scanと比べると優れているが，ぼくが一番気にいっている無料のScaniverseと同程度である。　

4　Polycam 3D Scan登録から離脱しアプリも削除

　新たな２種のLiDARアプリを見てきたが，vGIS Scanは小規模のオブジェクト把握には全く使い物にならない，ことがわかった。ルート調査の不適合性は未だ検証していないのでわからない。
　ルート調査で閉曲線域をスキャンして閉じることができるか，試したいと思う。Polycam 3D Scanアプリでは最も距離を稼いだのであるが，閉じることができなかった。とはいえ，3D情報の精度を確かめたいとは思っている。
　現在のLiDARアプリの性能のぼくの認識では，無料のScaniverseがトップであり，調査使用時には月2000円程度を出すことに問題はない。Polycamは$15/月だから，円/$=140でも，2100円となり，費用的には問題ないが，一時的にしろScanverseが無料なので，わざわざPolycamを購入する必要性がない。

　そこで，時間切れになる前にと，昨日の午前中に，Polycam Proのアプリそのものを削除した。アップルストアから現在登録すると，円/$=150なので，日々変動するレートの享受が可能なPolycamサイトで購入することになる。
　Scaniverseでルート調査をして閉局線を作りうるか試していないので，Polycamで測量した同じルートでスキャンして，いずれの精度が高いか，試してみたいと思っている。PolycamがScaniverseを上回るのであれば，広域の測量にはPolycamを使う選択肢もある。vGIS Scanの結果も見て，vGISがScaniverseよりも広域に強く，Polyscan Proと同程度ならば，Polyscan Proを使う理由が無くなる。

　登録を抜け出すには，ホーム画面でmenuを選び，最下部にスクロールして（図26），Manage pro subscriptionを選択すると，図27が現れる。ここで，サブスクリプションをキャンセルする，を選ぶと，登録から離脱できる。図28は図27で，すべてのプランを表示，を選択すると現れる。月2200円だと，2200円/$15 = 147となって，$1 = 147円となっており，年間契約よりは円高となっている。

図29, 30, 31：　図26の, Delete Polycam Account，を選ぶと，図29が現れ，Continueすると，Polycamのサーバー内のコンテンツを削除することになるが良いかというようなアラートが現れる。それに了解して図30が見えるが，もちろん，ログインではなくて，終了する。デスクトップのPolycamアプリも図31のように念のため削除しておく。

　ルート調査のまとめは，後に示したいと思う。

以上，May 29, 2023記。

　閉ループのLiDAR図をScaniverseとvGISで作成したいと思った。それで，Jun. 12にはScaniverseで，Jun. 13にはvGISでループ測量を実施した。

５　Scaniverseでループ測量　Jun. 12, 2023

　上記の課題をこなすべく，昨日Jun. 12にはScaniverseを，本日Jun. 13にはvGISの可能性を探った。

　Scaniverse で，RANGE: 2.5M，RANGE: 5.0Mを使って，スキャンした。5mレンジの方が進行先がより遠くスキャンできるので，普段の徒歩速度でとほぼ変わらない形で可能ではある。図33は当方の住所に近い交叉点であり，三等基準点3-61にあたる。図32の南西隅にあたる。図34はScaniverseの映像の三等基準点3-61が見える画面ショットである。図35はここから北東の方に進んだ三等基準点3-40付近である。スキャン開始から数百メートルでは図34のようにアスファルトが判別できるが，それ以降は図35のようにかなり画素サイズが大きくなって，マンホールそのものもわからなくなる。図35では地面の焦げ茶色の大きなタイルのように見えている。このScaniverseを使う場合，個々の三等基準点で画像のスクリーンショットを撮影する必要がある。

　

　つまり，Scaniverseは，この程度の範囲であっても，iPhone 12 Proのコンパス機能，さらにはもちろんGPSも，使われていないのである。距離数百メートルであれば，視覚的には気付きにくいが，全長2.5kmほどのルートでは大きく変形してしまう。
　このループ測量は，iPhone 12 Pro + LiDARが，地球上の何らかの測量上の基準点から，未知点の(X, Y, Z)を求めうるかどうか，を把握するためのものである。
　Scaniverseは不合格ということになる。

６　vGISでループ測量　Jun. 13, 2023

　vGISはオブジェクトのスキャンには適さないが，当方のフィールドでの基準点移動測量に有効かどうか，確認した。3等基準点はこのルートに⒎カ所である。全ルートでテキスチャーははっきりと捉えられていた。図32の3-61から反時計回りにループを辿った。
　テキスチャーが明瞭ではあるが，個々の基準点で，iPhone 12 Proの画面のスクリーンショットを記録した。iPhone 12 Proの裏側のレンズに近い場所を爪を立てて２回タップすると画面キャプチャーができる。図37は人差し指を立てていたために指までがキャプチャーされた。人差し指と中指の２本でタップするのが賢明だ。

　結果は，大いに期待できた。iPhone 12 Pro画面の最下部のレコードボタンを押して，測量は終了すると，図44のような，メニューが表示される。ほぼ2分間でProcessingができるということで，ゴール地点で，実行した。図44を見ると，最下段に，Process Later のボタンもあって，測量が全部終わって，帰宅してからでも，問題はないと思う。この時点で，バッテリー残量は68%であった。出発時にはほぼ100%であったから，30%ほどを消費したことになる。バッテリー充電器は持参していた。もちろん，デフォルトの図44HDのまま，Startボタンを押した。

　図45はSCANリストである。タイトル名の変更のコマンドがみつからない。図46は図45の最新のスキャンの全画像を示している。残念ながら，かなりの部分が消失している。記録されているのは，上と下の２本。図32の南西隅から反時計回りにスキャンしたので，上の１本，いわばほぼ後半だけが切れていない。下の線で上方に溝状に飛び出した部分があるが，これは郵便物投函のために郵便ポストに寄った時の記録である。

　図46最下段のボタンShareをタップすると，図47が現れる。ぼくは，USDZ，OBJを，Google Driveにアップロードした。そして，Point Cloudを選ぶと，図48が現れる。このうち，PLYを選んで，同ドライブにアップロードした。OBJは22MB，PLYは412MBである。いずれもzipファイルなので元ファイルはさらに大きくなる。

　

　iPhone 12 Proからアップロードすることになるが，図49はPLYファイルの場合である。Google Driveを選んだ。図50はそのDriveアップロード中であるが当方Wi-Fiがソフトバンクのためにかなり遅い。契約変更後，どんどん，Wi-Fi速度が遅くなっている。ソフトバンクから離脱したいのだが面倒で。

　このように，vGISについての作業の詳細を示してきたが，図46のような結果なので，この労力は意味がほぼ無いのであるが，期待してきただけに，役に立たないという記録も必要だと思う。

　図51の右図は，図46である。このscan図をIllustratorでトレースして，図32の地図に合うように拡大，回転を施した。その結果が図52である。青色の線でvGISが捉えたscan図を地図に載せている。図51の右図のscan結果はそのまま拡大そして回転しただけでは図52の結果を得ることはできなかった。図51右図のscan結果の上と下をグルーピングしたままでは，図52の結果は得られなかった。上と下のscan結果を独立して，拡大，回転する必要があった。とはいえ，下の溝のように伸びる道路と上の道路は，図52の地図のものと同様の関係にあった。

　vGISはiPhone 12 Proのcompass機能，gps機能を利用している筈であるが，それでも，上と下のscan結果の整合性が得られなかった。つまり，vGISは，既知の基準点から移動するためのツールとして利用するのは不適当ということである。

　結局，vGISはオブジェクトにも測量基準点の移動にも使用することができないことが明らかとなったのである。

おわりに

　結局，ぼくの現在の認識では，基準点移動に有効なアプリは，図10の結果を得たPolycamだけ。オブジェクトについては，ScaniverseかPolycamだけということだ。CloudCompareを使ったより詳細な検討は別途示したいと思う。

以上，Jun. 15, 2023記。