地下鉄御堂筋線千里中央駅から萱野南駅への延伸の遅れ期間の嘘と膨れあがった費用の謎 cheating the delay period and the strange expense for the extension of the Subway Midosuji Line from Senri-Chuo Station to Kayano Minami Station
Gmail ユーザーにメール返信ができない Mail Delivery Subsystem from Google Mailer Daemon
Gmailユーザーへのメールはもう嫌
Google Monopolyはいまや,USAでは常識。Gmailもその世界に入った。スマホユーザーに使い勝手がいいのか,急速に普及し,その段階で,他のメールアプリを駆逐するプロセスに入ったと言えるだろう。アップルやアマゾンなどのメジャーサイトを名のる怪しいメールがどんどん来るようになった。この状況もうまく利用しているようだ。 アップルのiCloudもいいだろうが,しらんまに無料限界を超える可能性があるので,特別の場合にしか,ぼくは使っていない。レンタルサーバー(さくら)に付属するメール機能が中心だ。勤務先のメールは退職後も使用可能だが,勤務先の通信環境を担う富士通は自らの低いセキュリティ能力ゆえにMicrosoft Outlookに換えてしまった。ものすごく使いにくい。
名入り色プッシュピン情報のKMLファイルを作る making a KML file containing named coloured pushpins
1. まずは一つだけエディターで
Google Developers.com のKMLの説明を参照した。地上でのトータルステーションを使った測量結果の確認のために,KMLファイルを作る必要性がある。過去に自分が作ったKMLの構造を理解できなくなっている。ネット上にはcsvをkmlに変換するサイトがあったりするが,確か,全部エディターで作成した記憶がある。そこで,Google Developers のレクチャーを参照した。ぼくが今,作成したいKMLの基礎情報だけを整理することにした。
GDcomには,図1について,「この例の目印は Google の Building 41 を指していますが、これは Google Earth が開発された場所です。」とある。GDcomにあるKMLの記述をエディターにコピペしてsimple placemark.txtとして保存して,拡張子txtをkmlに書き換えて,Google Earth Proの保存フォルダーにドラッグアンドドロップした。そのGEProで得られた表示が図1である。左のペーン最下部の保留フォルダーにこのファイルが見える。画面中央の赤枠で囲んだのが,simple placemarkで,Google Earthが開発された場所。目印は黄色で,指示しない場合,デフォルトが黄色のプッシュピンだ。図1のGEProの画面の右手のmacのデスクトップのsimple placemark.kmlファイルを赤枠で囲っている。
図1 simple placemark
図2 Pushpinを左クリックして情報を見る
<?xml version=”1.0″ encoding=”UTF-8″?> <kml xmlns=”http://www.opengis.net/kml/2.2″> <Placemark> <name>Simple placemark</name> <description>Attached to the ground. Intelligently places itself at the height of the underlying terrain.</description> <Point> <coordinates>-122.0822035425683,37.42228990140251,0</coordinates> </Point> </Placemark> </kml>
この8桁は通常?とは異なる。Google Maps KML: 8-Digit Hex Code の質問と回答で見られるように,通常の光の三原色比記述順序RGBとは逆になっている。BGRなのである。上記のRedは,不透明度100% + blue 0 % + green 0 % + red 100%になっている。一般的には,Redは,ffff0000,つまり,不透明度100% + red 100% + green 0 % + blue 0 %と表現されるのであるが。
通常,8桁の英数字はそれぞれ16進数で表現され,αrgbの配列をなす。α(アルファ)は,opacity(不透明度)である。ff-33-66-99のffは16進数で,15×16 + 15 = 255になる。不透明度は0〜255,つまり256(2^8)段階に分かれる。その最大値がffになる。RGBも同様だ。ffで不透明度は最大100%である。不透明度50%は,hex (adecimal) numeralでどう表現するか。256段階の半分,つまり128だ。128/16=8で余りゼロだから,80となる。透明はもちろん00だ。例えばGreenは,ff00ff00で,opacity 100%, red 0%, green 100%, blue 0%。
サーフパンツ(日本語)で泳ぐとお腹から水が入ってしまう。それがクリアできたのは,図1のRusty製のものであった。ヴィソラのスポーツデポでやっと2020年に出会えた。品番 Rus 910405 BLK L,国際スタンダード。胴回り84-94cmだった。やっとオーケー。4500円税抜き。今はもう販売されていないようだ。予備のものを含めてカルキでかなり傷んだ。この凄いのは胴回りに幅廣のゴム入り?のストリップが付け足されていて,これ効果で水が入らない,優れもの。腰回りがすごく心地よかった。
重い3Dファイルの移動とダウンロードの,2.1 NTFS-3G for mac I-O DATA Could not mout,にその顛末を示している。 この情報では,macOS14のセキュリティの向上で,macのセキュリティを下げる必要があるということになる。そんなこと,いちいち,できない,と考えて,現在の状況に対応したUSBドライブを購入しようとネット検索したが,みつからない。この検索を3日間ほど,思い出した時には,何度もトライしたのである。
困った挙げ句に
今日はアップルケアに電話しようとしたが,サードパーティーの問題だと言われそうなので,アイオーデータ機器,今はI-O DATAか,このサイトで調べた。macOS 14 Sonoma 対応情報 を見ると,「「NTFS-3G for Mac I-O DATA」「Sync with for mac」は非対応です。(2023年10月19日追記)」などと在ったりする。USBメモリーに対してのものではないが。
上記PLYファイルをCloudCompareで開いてcloudを選択し,bottom view(図29)。点群対象のcompute 2.5D volume分析のために,上下に点群を分割したい。外周の一番の出っ張りをトレースしてsegmentationを実施したいと考えた。segmentationはsegment in or outを実行をしないとオブジェクトの移動などができないので,1回で分割しなければならない,と呆けで決めつけてしまった。それで,図30のように,set bottomにしてその縁辺で切り取るしか,方法はない,と考えたのである。 図31には,ポリゴンの選択を完了した様子(緑色細線の閉曲線)が見える。
図29 PLYファイルを開いてcloudを選択
図30 set bottomでsegmentationのトライ
図31 ポリゴンツールによる選択完了
図32はsegment outを実行したところで,図31のポリゴンツールで閉曲線を作成した筈であるが,囲んだ範囲の外側が図32のcloudとなったのである。図33ではconfirmした結果で,DB Treeのremainingとsegmentedの両方が選択されている。図34はこのオブジェクトのleft side viewで,切り口は見えない。まだ事態が掴めない。
toolでの点群体積計算で,Ceilがsegmentedで,groundがremainingに対応することになるだろう。図60では両cloudを選んで,Tools > Volume > 2.5Dvolumeを実行することになる。図61を見ると,groundに対応するcloudはremainingで,ceilに対応するcloudはsegmentedになっているので,いい感じだ。ただ,At least one of the cloud is sparse! You should fill the empty cells… という警告が出ている。 step: 0.03(3 cm)。図62との違いはEmpty Cellsをleave emptyにしているかinterpolateにしているかの違いで体積値が変わる。
図60 両cloudを選んで
図61 UpdateでVolume 25.879
図62 UpdateでVolume 21.376
Calculated volume in 2.5 d changes with grid step size bug? を参照のこと。それで,図63では,両点群のEmpty cells: interpolate,Grid step 0.10(10cm)にした。かなり粗いグリッドだが,Volume 32.205,Surface 18.750,Matching cells: 81.9%,となった。警告が出なくなった。図64のように,Export grid as a cloudのボタンをクリックすると,シーンにカラーによる高度頻度分布図がHeight deiffernce raster(0.1)として出力されている。図64のパネルの最下部でOKを押すと,図65のように,パネルが消えてシーンには高度頻度分布図が配置されている。
7 フィールド科学のためのアップルLiDAR測量 Part 2 Ⅴ.4 Meshmixerで大饗石の底抜けを解消して体積を求める
文学論集Vol. 73, No. 3(発行は2023年末ぐらいか)
Meshmixer 3.5 is now available ![i] からこのアプリをダウンロードできる。筆者が用意していた大饗石オブジェクトだけのMeshLabファイルからobjファイルを抽出してMeshmixerにインポートした。メッシュの綻びをチェックすべく,解析 > 検証,を選んだ。かなりの綻びがシーンに表示される。「すべて自動修復」ボタンを押した。実行にかなりの時間を要した。MeshLabでこの種の作業を実施してきたファイルであったるが,Meshmixerからすると今だ綻びがあるようだ。Meshmixerは,ビジュアルに簡便に,この種の作業が実施できる。これは驚きであった。
なお,上述のように点群の点数を増やさない場合,step: 0.1より小さくすると,赤字でAt least one of the cloud is sparse! You should fill the empty cells..という警告が現れる。Ⅴ.4.aのメッシュの体積は前述のように37.6635㎥であった。点群の体積は31.825㎥である。メッシュの体積は,図34(a)のメッシュ拡大図に見えるようにメッシュエンティティーは三角面triangle facesからなり,適当な原点から三角面それぞれの頂点に側稜が伸びて,オブジェクトは三角錐で埋められる。それぞれの三角錐の体積の総和がメッシュファイルの体積となる。前述のように2.5D volume法はこのメッシュ法に比べると粗雑になっているので,メッシュ法の体積V = 37.6635㎥を採用することになる。土木工事などで工事の前後の土量の移動などの場合は,適用が2.5D volume法に限定されるので,もちろん,使用価値はある。