保津峡谷鵜ノ川口から峡谷右岸基盤岩露頭へのアプローチ Approach to the basement rock outcrops on the right bank at the upper end of the Hozugawa Gorge (Unokawa-guchi)

はじめに  保津峡谷口,または保津峡谷入り口についてのぼくの言及を,友人は地理学の谷口集落の連想からか,嵐山と誤解した。それを踏まえてこの投稿の英語タイトルを決定した。upper endが重要だ。日本語では地名があるので不要だろう。  防災や土木用語としては請田サイトが使われている。時刻水位月表検索 観測所記号 観測所名 水系名 河川名 306041286606300 請田(ウケタ) 淀川 桂川  しかし驚くほど情報がない。どこかに委託しているのか,サボっているのか。  亀岡の水害を調べ始めると,請田,という地名は使われているが,実質がないようだ。 以上,2026年2月16日。 1. アプローチの選択  請田神社から府道を使って保津峡谷に入ると,かつての山陰線(現トロッコ列車軌道)の上方には大きく切ったと思われる崖面が見える(図1にはその下部だけ)。この場が大山咋命(おほやまくひのみこと)の丹の海干拓のための主要な工事現場であったとぼくは当初考えていた。  「古代タニハ『丹の海』とその排水プラグを地形発達史から復元 Part 1」関西大学文学論集75-4は本日(2026年3月12日)刊行されたが,この報告では,大山咋命が見た丹の海の湖面の海抜高度が98mであったことを明らかにした。図1の付近は海抜80mだからおよそ落差20mの滝があったとぼくは考えていた。その滝を数十年またはそれ以上の年数をかけて,開削をすることで,湖底は侵食されていったと想像したのである。開削工事については,上記論文のPart 2として発表する予定である。 以上,2026年3月2日。2026年3月12日修正。  この観点ゆえに,図1に見える右岸の岩質を確認する必要があった。元の山陰線,現トロッコ列車軌道の上方にはコンクリートの大きな壁面が見え岩盤は隠されているので,河原で観察するしかない。 2. 右岸河原に辿り着くには  冬の渇水で鵜ノ川を渡ることができた。図のルートでまずは鵜ノ川の右岸へ。そして,図2に見える堰を図3のように伝って人工島にたどり着いた。高齢でバランスを崩す可能性が濃厚で,堰の途中で,キャラバンからウェットブーツに履き替えた。  図5には,軌道面から一段低いテラスから川への梯子が見えるので,鵜ノ川の流れが早い場合にはテラス面を使うルートもありうると思っている。図7は保津川の本流路でこれが保津川下りのルートを確保している。図1は請田神社からの眺望であるが,この人工島で分割されて,保津川下りの航路が確保されているのがよくわかる。 3. 岩石種は玄武岩か  保津川右岸河床に立つと,左岸の黒色岩石の露頭が見える(図8〜10)。なぜか,左岸では節理が目立つ。  アイフォーンのパノラマ機能で図11を撮影した。左手の河岸上方の朱色は請田神社の柵,中央手前にカーブして流れているのが保津川本流,右手のほぼ静水域は鵜ノ川河口からの水域。中央にはコンクリートで固めた人工島がみえる。  図12は,差別侵食で残った枕状熔岩だと思う。図13,14の正面に見えているマッシブな壁面はコンクリート壁である。最下部にへの字の洞穴が見えるがここには人が積み上げた河床礫がコンクリート壁が侵食された結果,露出している。気になって現場に行ってわかったことである。  図15,16は,コンリート壁のすぐ下流側のステレオ写真である。ベッディングに見える。この産状が下流に続くのを左岸から見ていたので,熔岩ではなく泥岩と考えざるを得ないと考えていた。近接して観察すると,右下がりの「層理面」に間違いなく,節理ではない。ぼくの貧弱な知識だと海洋底の玄武岩とは到底思えなかったのであるが,図12のような部分もあって,海洋底での噴出物の降下堆積物と考えざるを得なくなった。というか,玄武岩であることに安堵したのである。  図17,18は,図16の壁面の一部であるが,チャートも含まれているようである。  図19〜21では熔岩と火山礫・火山灰相が見える。  図19〜23は同じ場所で,図15からすると,200mほど下流のやはり右岸である。  請田神社前(図25)の河床には玄武岩が見えるが,少し上手では泥岩が見えているようだ。この上の府道の露頭では,泥岩にチャートが混入している。 おわりに  これから水位が上がると右岸に到達するのは腰まで水に浸かる必要が出てくるかもしれない。請田神社側つまり左岸は道路から簡単に草木の繁る斜面を降りると岩盤に辿り着くことができる。図25の水位観測点の下流側から降りるのが簡単のようだ。(調査日:Feb. 15, 2026) 以上,2026年3月10日。2026年3月12日修正。

Start GIMP instead of Adobe Photoshop

はじめに  awesome Adobe applications to sharewares で示したように,Adobe Photoshopから離れて,GIMPを使用したい。  GIMP使用当初はPhotoshopに比べてステップ数が多いと感じたのであるが慣れてきて,かつてGIMP使用を断念した時よりはよほど肩が軽くなった。Photoshopから拒絶されたので致し方ない。 1. ダウンロード  https://www.gimp.org/downloads/ に,GIMP, Current Stable Version The current stable release of GIMP is 3.0.2 (2025-03-23), のダウンロードサイトがある。Donationを以前したことがある。使えるようになったら改めてしたいと思う。  ver. 2.1を削除してこのver. 3.0をインストールしたのであるが,ツールボックス表示のタイミングがうるさくなくなったという印象を持つが,戸惑うことがあり,Perplexityにお世話になった。 2. 最近は何をしていたのか  Adobe Photoshopで最近何をしてきたのかを考える。今後,必要に応じて追加してゆく。 2.1 スクリーンショットや写真からWeb用コンテンツを作成  現在の最頻度の作業は,macやWindowsでの作業をスクリーンショットで貯めて,それらを軽くしてWebページへ掲載してきた。フィールドなどで撮影した写真も同様の利用をする。iPhoneで撮影した写真は,mac写真アプリに並べてコメントを付し,jpgで出力してそれらをスクリーンショットとほぼ同様の作業をしてきた。  スクリーンショットはフィールド写真と比べるとかなり軽量で多少処理過程に違いはある。総じてPhotoshopでの作業は次のようであった。 1  必要な部分を切り取る場合がある。 2 写真の場合はスライダーを使って彩度を高くする。 3 ランドスケープの場合は,解像度300dpi,縦1200dpi,横1600dpi。   ポートレート の場合は,解像度300dpi,縦1600dpi,横1200dpi。 4 容量を軽くする。Web用だとスクリーンショットの場合最大100 kbyteほど,写真だと500kbytesほどにしてきた。  さて,Perplexityでの質問文を考えてみる。  スクリーンショット: GIMPでの作業過程を教えてください。スクリーンショットの一部を切り取って,その形がランドスケープの場合は,解像度300dpi,横1600dpiに揃えたい。そしてファイル容量100kbytesほどのjpgで出力したい。  写真: GIMPでの作業過程を教えてください。iPhoneで撮影した写真の彩度を高めて,その形がランドスケープの場合は,解像度300dpi,横1600dpiに揃えたい。そしてファイル容量500kbytesほどのjpgで出力したい。 3. スクリーンショットをWebページ掲載画像ファイルjpgに変換する手順  では,スクリーンショットの場合を聞いてみた。回答は簡潔でそのままでは実行できない。以下に。 作業手順 3.1 スクリーンショットの切り抜き  1.1 GIMPで,メニューのファイル […]

続国土地理院の基準点成果の利用 a sequel to using control point survey results made by the Geospatial Information Authority of Japan or GSI

はじめに  国土地理院の基準点成果の利用 は,2022年秋に作成したものである。これを元に,文学論集Vol. 74, No. 4に投稿すべく記述してみて,2年間のブランクもあって,一つの章を追加する必要性を感じ(2年前に残したことであった),それをここにまとめることにした。制限ページ数に近く,ここで書き込んだもののダイジェストを文学論集Vol. 74, No. 4の第Ⅹ章にしたいと思った。 0. 「Ⅹ LiDARルート測量とライダーROI測量を繋ぐ」(コピペ) 2024年秋現在,筆者の利用の観点からすると,最も優れた3D LiDAR ScannerアプリはScaniverse[i] (v.4.0.2) である。Polycam[ii]と,これまで述べてきたMetascanは,マニュアルを読む限り,パワフルなアプリという印象を受けてきたが,1セッションのLiDAR測量継続時間はいずれも10分間に限られる。Polycam Pro [for iOS v.3.5.18 (225)]の説明書には10分間の限界は書かれていないが,10分を超えると,「前のエリアに戻って再開する」と「最初からやり直す」の二択を迫られる。戻っても再開されない。Scaniverseには,この制限に関連する情報は記されていないが,幸い経験的にこのような限界はないように思う。 さて,ここでは本章タイトルを実行する。許されたページ数は残りわずかなので,これまでのような順を追った説明は省く。これまで,基準点4カ所を通るLiDARルート測量結果を平面直角座標系に載せる手法を示してきたが,ROIのライダー測量結果を平面直角座標系に載せる手法は示していない。しかし,賢明な読者はこれから述べる内容をすでに見抜いておられるのではないかと想像している。 本報告の目的は,ROIのLiDAR測量結果を平面直角座標系に載せる手法を示すことにある。測量ルートの選定は当然,ROIを通過するかその近接地にすることになる。ルート測量の途中でROIのLiDAR測量を実施することも可能かも知れない。ただ,ROIでは丹念にLiDAR測量を実施するので通常,ルート測量とは別にしたいと考えるだろう。 そこでルート測量の際に,ROI付近に一時的な二次的基準点を4カ所設置すれば良いと考えられる。ルート測量して,引き続きまたは翌日にでもROIのLiDAR測量を実施することもできる。なんらかの理由で繰り返しLiDAR測量したい場合にもこの4カ所の二次的基準点を繰り返し使うことができるのである。 [i] Scaniverseは,Niantic(ナイアンティック)https://nianticlabs.com/products?hl=ja による開発中のアプリ。NianticはGoogle社内のスタートアップ企業でGoogle EarthもGoogle mapも開発している。現在Googleから独立したらしい。かつては有料だったが無料化されて,先進的なGaussian Splatting機能が付加されてもなお,無料のままだ。 [ii] https://poly.cam Polycam Proを2024年10月に月契約($26.99)してみた。 1. Oct. 26, 2024実験  曇りの日で雨が降りそうな天気であった。自分の影が映らなくて良いと感じた。Splattingに期待もしていた。Polycam (Pro)が,LiDAR測量の10分間限定を超えるのではないか,という期待があった。先に結果を言えば,PolycamもScaniverseもSplattingはルート測量には適さないということである。LiDAR測量こそ,ルート測量に適していることが判明した。諦めがついた。図1を参照してほしい。  後述するが,DOIに当たるのが,打越池南縁の歩道である。DOIを公共の基準点とつなぐ目的でルートを設定している。 南西部の基準点3-61から出発し,打越池南縁のDOIに階段②から入って③の阪急バス停「青松苑」から出て,⑤の交差点を通過して,④の基準点3-42に到達して交差点⑤に戻り,⑥の基準点3-40に北進する。そして,⑦の基準点3-41,②を通過して,①の基準点3-61に戻っている。 文学論集図51に登録済み。  階段②からバス停③の間がDOIという設定であるが,そのルートのGoogle map (2024年) 画像を図A下部に示している。画像右下隅に見えるスケールの長さは10mである。③と④の間の300mほどの距離の間に,レーベル L-1〜-4を設置しているのである。  図B,Cは打越池南縁プロムナードのステレオ写真である。ベンチの向こう先端の左手のレンガとアスファルト境界付近の地面にLabel-1を置いていた。左右両方の金網塀には葛が絡まっている。 Label 1〜4を図D〜Gに示す。Label 1は階段に近く,Label 4はバス停に近い。 以上,2024年10月24日記 2 Polycam社そのものの社会的信頼度は低い […]

3D Gaussian Splatting

はじめに  いやー,驚いた。ChatGPT ver. 4の契約をするかどうか,ネットサーフィンしていたら,このgaussian splattingテクノロジー情報をみつけた。ぼくのiPhoneのScaniverse 3D map scan アプリにもすでにgaussian splattingが実装されている。このgaussian splattingの技術が実用化したのは昨年(2023年)夏とま新しい。原理を理解するのは今のぼくには難しい。これまでのフォトグラメトリなら簡単な幾何学に過ぎないが別世界の技術だ。解析速度もより速く,解像度もより高い。LiDAR測量に拘ってきたが,通常の写真や動画の方がより有効な気配だ。 メモ: SfM (Structure from Motion)またはフォトグラメトリ(Photogrammetry)とは、被写体をさまざまなアングルから撮影し、そのデジタル画像を解析、統合して立体的な3DCGモデルを作成する手法。  ぼくが最も信頼する3D scan soft, Scaniverseにまずは眼が向いたが,最強だが有料のpolycamが劇的に使い易くなったようだ。他にLuma AIもある。全部,iPhone11以降に対応している。以下,ぼくの知りたい情報をピックアップしつつ,学びたいと思う。そして,実際に試した結果もここに報告したい。 以上,2024/04/12。 1. Niantic Lab Niantic (ナイアンティック)って知らなかった。Google社内のスタートアップ企業で,Googleから独立したらしい。そして,3D ScanningソフトScaniverseを吸収したようだ。かつては有料だったが無料化されて,先進的なGaussian Splatting機能が付加されてもなお,無料のままだ。ぼくのiPhone 12 Proのアプリは,Apr. 1, 2024にもアップデートされていたNianticはGoogle EarthもGoogle mapも開発したGoogle内のティームだったようだ。 2. Scaniverse Scaniverseが3D Gaussian Splattingをサポート 〜 スマホからフォトリアルな3Dシーンを迅速に作成 〜 2024.3.20 を参照して欲しい。LiDARではなく,ムーヴィーか,シーンを重ねて撮影した写真で,Gaussian Splattingが可能だ。次のアドバイスがある。 メッシュ生成とスプラット生成をどのように使い分けるべきですか? スプラットが適している場合:照明と反射を備えたフォトリアリスティックな結果を求める場合背景を含む全体のシーンをキャプチャしたい場合 メッシュが適している場合:スキャン結果を他の3Dソフトウェアやゲームエンジンで使用したい場合背景のない独立した3Dモデルを求める場合正確な測定が必要な場合明確に定義された被写体がないシーンをモデル化したい場合(例えば、建物内のすべての部屋を含むスキャンなど)  写真の3D合成は,他のアプリでは,有料で,企業のサーバーにアクセスする必要があるが,このScaniverseでは,iPhone内で実行することができる。しかも無料だ。まだ,完成形ではないと,アプリ開発者が考えて,ユーザーの意見などを吸収して行こうとしている。 Scaniverseでスプラットをサポートしている端末を教えてください。 Gaussian Splattingは現在iOSでのみ利用可能です(iPhone 11以降、比較的新しいiPad[*])。Android版の開発中ですので、お待ちください! [*] iPad: 第9世代および第10世代、iPad […]

光波測量によるネットワークをdroneマップに投影する方法 how to match distance-measured points from different setting bases with a drone-measured map

1. 課題  フィールドワークでの測量に問題が生じた。2020年測量のdrone3Dマップと,2018年の光波測距儀を使って得られたネットワークが対応しない。droneマップは光波測距儀で得られたgcpとの対応関係が取られている。そのgcpを使ってdroneマップをコントロールしているので問題はない。この場所には自衛隊のレーダーサイトがあって,コンパスが正常に作動していない危惧があり実際に西偏角度が想定されるものと異なっている。  光波測距儀の設置点は14カ所で個々の設置点で幾つか測点があって,前視と後視で,位置関係を一応把握したのであるが,手抜きしてGPS計測値を光波測距儀の地球座標値として使用した。これが今抱える問題の元凶だ。そこで,2018年の測量時の測点の現場写真からdrone3Dマップと対応できる測点を利用して,ls_1〜_14の光波測距儀の設置点を求めたいと思う。 2. ls_2の設置点を求める  ls_2の放射星形区で3Dマップ上での2カ所を現場写真から特定できた。その一つは,図1のls2_20であり,もう一つは図2のls2_11である。後者は光波ネットワークとも一致している。それを図3に示す。  ls2_20の方は,図2に示すようにかなりズレている。図1の現場写真ではa-rotの下に見えるが,図2では3mほど内陸にずれ込んでいる。  求めたいのは図1の,赤字で「かわぐち」としたls_2の設置点の3Dマップ上の座標値である。 3. ls_2の3Dマップ上の座標値を求める 3.1 計算法  当初,3D空間での三角形平面を想定して計算すべきと考えた。しかしながら,熟考するとその必要性が無いことが明らかになった。光波測距儀の構造は台座を水平にして,光波測距儀が装着されている。コンパスで磁北をゼロ度として,台座上を時計回りに回転して,光波測距儀をターゲットに向けて,直線距離を求める。その測距儀の水平角と垂直角を記録する。これだけだ。今,問題なのは3Dマップでのls_2設置点を決定することであり,2D空間に過ぎない。  連立方程式は簡単にできる。文字表現の簡略化したい。現在の設置点をO’点として,3Dマップに載せうる設置点をO点(Xo, Yo)とする。ls_2放射星形区の2点のうちの1点について,現在の位置をA’点として,3Dマップに載せうる設置点をA点(Xa, Ya)とする。他の1点については,現在の位置をB’点として,3Dマップに載せうる設置点をB点(Xb, Yb)とする。  光波測量の結果から,次式が成り立つ。赤字表現しているのが未知数である。他の数値はすでに得られた計測値または3Dマップから読み取りできる。|OA|=|OA’|=√((Xa-Xo)^2+(Ya-Yo)^2) ⋯⋯⋯⋯⋯式(1)|OB|=|OB’|=√((Xb-Xo)^2+(Yb-Yo)^2) ⋯⋯⋯⋯⋯式(2) 上記の計算式が成り立つ理由は次のようである。光波測量の結果に基づいて位置ベクトルを3Dマップにプロットするのであるが,ls_2の設置点が決まらないだけであって,その測定結果のうち,水平距離,垂直距離,さらには視準線の間の挟角は変わらない。  式(1), (2)の連立方程式から,(Xo, Yo)の解が2個現れる。A点を中心として半径|OA|の円と,B点を中心として半径|OB|の円との交点は2点形成されるからである。3Dマップを見ている作者からするといずれが正解かは自明ではある。  式(1),(2) は何れも円の方程式である。両円は交わって,その二つの交点を通る直線が成立する。その観点で整理したいと思う。式(2)と(3)はそれぞれ,次のように整理できる。(Xo– Xa)^2+(Yo– Ya)^2 = |OA|^2 ⋯⋯⋯⋯⋯式(3)(Xo– Xb)^2+(Yo– Yb)^2 = |OB|^2 ⋯⋯⋯⋯⋯式(4)  二つの交点を通る直線の式は,式(3) – 式(4),で次のように,得ることができる。2(Xa-Xb)Xo + 2(Ya-Yb)Yo +〔(|OA|^2 – |OB|^2) – (Xa^2 -Xb^2) – (Ya^2 – Yb^2)〕= 0⋯⋯式(5)  両円の交点の計算は,式(3)と式(4)の何れかの円と式(5)の直線との交点を求めれば良い。ここでは,式(3)の円と式(5)の直線の交点を求めることにする。 式(3)の,中心座標(Xa, Ya),半径 |OA|の円,と,式(5)の直線の交点をM, Nとして,交点を表現したいのであるが,かなり複雑になるので,式(5)を簡潔化して次に表現する。 e=2(Xa-Xb), f=2(Ya-Yb), g=〔(|OA|^2 […]

CloudCompareでCloud layersを handling cloud layers in CloudCompare

1. このページ作成の意味  もともとの関心はGISソフトでの3Dクラウドとgcpの重ね表示の可能性を探ることであった。ここに至る経緯は次のページに示している。  このページの作成過程で,gisソフトでは実現しないことがわかった。MeshLabに期待したが,これも重い3Dファイルを受け付けない点で問題があった。結局,CloudCompareに頼らざるを得なかった。CloudCompareではMeshLabでどうにもならないものでも何とか作業ができるのである。  で,問題はレイヤー構造で使用出来るかであるが,Danielの情報で,使えることがわかったのである。ただ,図1のように,Plugins: Cloud layers,は灰色になっている。  Help > About Plugins,で開いた画面が図2である。Cloud layersを選択するが,これ以上進めない。Referencesとして,サードパーティのWiggins Tech website が見えるが,ここをクリックするとこの注記が消えてしまう。 2. Plugins: Cloud layersのインストールに向けて  図3を参照して欲しい。なにか不可解なのだが,CloudCompareのサイトではなくて,3ds-scan.de で公開されている。ぼくがインストールしているのは,図1の v 2.12.4 (Kyiv)なので,2.12.0はより古いバージョンだ。  キーウで現在活動する企業(サードパーティ)のようだ。  このサードパーティのリンクをCloudCompareを使用しているWindowsで立ち上げた。ドイツ語が表示される。言語を換える選択肢があり,日本語に替えた。その画面が図3のものである。このサイトは2016年11月から始まっている。図3の「Cloud Layers」プラグインをクリックするとmp4のムーヴィーが始まるがCCもなく,音声も出ない。  図3の表示のすぐ下には,ダウンロードリンクがある。CloudCompareのミラーサイトの認証を受けているようだが,ヴァージョンが2.12.0のままだ。更新されていない。CloudCompareはフリーだけどサポートが要るというメッセージが色つきになっている。  次の情報がある。ただし,当方の Editメニューでは,’Edit > Cloud > Create single point cloud‘しか有効でない。Edit > Scalar fields についても下に示された選択肢はすべて灰色になっているのである。 Here are the new menu entries:  このWebサイトに入ると,ぼくはすごく怪しい印象を持った。どこにもプラグインのダウンロードのリンクはなく,ただ,コンタクトせよという。しかも種々のページを見ていると,bluetoothに繋げようとする。  Danielさんが,フォーラムで,Maybe you can use the new ‘qCloudLayers’ plugin?Another way, […]

QgisとGrassGISの何れが3Dメッシュと点群ファイルを生かすことができるか which is better Qgis or GrassGIS for the display and analization of 3D mesh and cloud data ?

1. 期待していること  GrassGISをかつては使ってきたがご無沙汰している。Qgisは1回だけ使って精度面で問題を多く感じてアプリも削除した。Qgisは大衆化が著しく,悪貨が良貨を駆逐する,勢いである。日本の行政はGrassGISを飛び越して,専らQGIS派である。行政のコンテンツがQgisを意識したものになっている。  さて,3Dメッシュまたは点群ファイルへの対応はどうだろうか。もちろん,GrassGISではこのアプリ公開以来,早くから米軍やNASAのLiDARデータの処理が実行されてきたのであるが,ぼくはこのコンテンツには触れなかった。  いま,求めるのは,3Dモデルの3D表示能力はもちろんである。CloudCompareはその点では問題はない。しかし,CloudCompareでは,3Dモデルに,他のベクトルデータをオーバーレイすることができない。これはかなり不便なことである。それで,GISソフトに期待してのこのページ作成である。  繰り返すと,3Dモデル表示が自在で,他のベクトルデータをオーバーレイできるか。この観点で,両アプリを調べたいと思う。   2. GrassGISではどうか 2.1 ケース1  まずは次の回答を紹介する。 Import Point-Cloud to Grass-GisData Processing – Discussion and Q&A MichaelL Feb ’20 Got it. I know Lidartools (which LAStools is dependent on) was not ported for QGIS 3 so that what I was getting at. 10M points isn’t all that big so if […]

ドローン測量の限界の一例 an example of the limitation of drone measurements

はじめに  共同研究者の一人beがドローンを飛ばして光波測距儀での測量についてはプリズムをボクが移動し,測点の記載を実施した。それはもう2020年春のことである。2018年と2019年にはkaさんと海岸地形の光波測距儀での測量などを実施した。両方のデータの整合性を取る必要があって,ドローン測量をここ1カ月以上に渡って,検討してきた。  これはドローン測量のほぼファイナルな結果である。残念ながら期待した結果は得られていない。この結果に至るまでのやり取りなどや分析の詳細はプライベートページに掲載されている。まだ研究成果を発表するまでには時間が必要で,公開できない内容を多く含むためである。 ortho.tifの限界  図1は,Agisoft Metashapeで作成されたオルソ写真と光波測距儀で求めた8点の位置のずれを示している。ビューワーはGoogle Earth (Pro)である。グーグルアースで表示されている画像はモザイク写真であり,写真画像で正確な位置を捉えることはできないので注意が必要である。  画像とは関係なくグーグルアース画像での位置情報,繰り返すが画像とは関係のない,グーグルアース座標系での位置情報の精度は高い。グーグルアースプロの限界 の「GEProの位置精度」の章に示すように,地球面上の位置精度は1〜2mほどと言えるだろう。  それゆえ,光波測距儀で得たgcp候補8点のうち採用した7点の位置は正しくグーグルアースにプロットされる。光波測距儀はノンプリズム対応のもので8点のうち2点はプリズムの設置が困難な場所であった。ドローン測量結果の位置決めはgcp7点を使用した。ドローン測量でえた空中写真で同地点で複数の写真にgcp位置を同定しており,ドローン測量結果はgcpとの対応が取られていて,グーグルアース上では,オルソ写真の画像上のgcp位置と一致する筈であった。ボクは当然一致すると考えていた。  ところが,図1に示したように,gcp8点(図1の中央列のc点はドローン測量結果には使用されていないが球面位置情報は正しいので掲載した)のいずれも一致していない。図1では黄線分でズレを示しているが解像度が低くて見にくい。オルソ写真の位置と光波測距儀で決定した位置のズレを示している。参考データとしてGoogle画像で示されたスケールを使ってそのズレ値を例えば,e:1.3mなどと示している。Google画像での距離精度は低いがオルソ写真と光波測距儀での座標から得られた点のズレなので,精度はグーグルアースの精度ほど低くはないのであるが。  で,図1の右端の画像はオルソ画像域全体のなかでの,ズレの傾向を示している。この画像の右下隅に方位ホウィールが見える。研究対象域は海岸線付近なので,gcpの点a,f, b,gに注目すると,1.85m±0.35mほど,北に変位している。  これまで,種々の計算処理をしてきており,これ以上の対処は難しい。海岸地形の研究の観点からすると,このオルソ画像をいわばインデックスマップとして使わざるを得ないのである。このインデックスマップに,以前に測量したポイントの座標系を平行移動または回転などして行かざるを得ないのである。 今後の作業は思って  このオルソ写真というか,ドローン測量結果が使えるかどうかは,別の観点から,評価する必要がある。この海岸で2018年または2019年に測量した結果,特に海抜高度が完全に一致しているかどうかである。球面位置はこのオルソに合わせるにしても,海抜高度に問題があれば,使えない。  3DオブジェクトのPLYを使って,次に評価したいと思う。 以上,0:16,Dec. 24, 2023, to Christmas Eve。 グーグルアースから離脱か,Qgisか  ズレ,1.0〜2.2mは,そういえば,グーグルアースの誤差範囲である。参考:グーグルアースプロの限界。 図1ではgcpとオルソのズレは同じではないので,オルソ全体のズレだけでなく,gcpの個々のズレもある。グーグルアースの限界に基づくものと考えれば,納得もゆく。  今日,be氏に電話して,Qgisにプロットしてもらうことにした。ぼくはGrassGISであるが,Qgisのユーザーは多く,簡便であり,Qgisにシフトした方がいいと思う。ゲームなどでも利用される3DオブジェクトのFBXやUSDZなどにも対応しているかも知れない。その確認もお願いした。  ぼくはCloudCompareで,海岸線付近の高度情報を調べることになる。 以上,Dec. 24, 2023記。