地下鉄御堂筋線千里中央駅から萱野南駅への延伸の遅れ期間の嘘と膨れあがった費用の謎 cheating the delay period and the strange expense for the extension of the Subway Midosuji Line from Senri-Chuo Station to Kayano Minami Station

1. 北大阪線北伸の餌に掛かる

 大阪府知事橋下さんが2010年2月に箕面市にやってきて箕面市議など関係者を前に演説をした。その演説に応えるべく,箕面市議会は,大阪国際空港の廃止を受け入れた。地下鉄御堂筋線(北大阪急行)延伸を受け入れて貰うために。
 箕面市の広報資料がネット上,(報道資料)「関西における空港の在り方と都市将来像について(決議)」について,にあり,その一部を次に転載する。

経過:―大阪府知事と箕面市議会との意見交換―

 箕面市議会は、今年2月22日(月曜日)にメイプルホールにて橋下知事と「空港問題に関する意見交換会」を実施しました。意見交換会は、一般市民、報道関係者など約470人の参加の下、箕面市議会議員(24人)と橋下知事が2時間余りにわたり、「空港問題と都市の将来像」をテーマに課題や将来展望など幅広く議論が行われました。

決議の概要:

  • 地域の交通手段としての空港利便性という小異を捨て、「関西圏・大阪圏全体の大きな活性化」という大同につき議論する。
  • 国及び大阪府に対して、「関西圏・大阪圏全体の大きな活性化」という観点から各空港の将来像を早期に決することを求める。
  • 各空港の将来像を決するうえで、次の三点の履行を求める。

1.関西国際空港を国際・国内一体のハブ拠点化するとともに、中長期的には大阪国際空港(伊丹空港)を廃港し、関西圏・大阪圏全体に活性化をもたらす未来のまちづくりを志向すること。
2.関西国際空港のハブ化にあたっては、高速鉄道網をはじめ北大阪地域から関西国際空港へのアクセス改善を、国及び大阪府の責任において実施すること。
3.大阪国際空港(伊丹空港)については、当分の間、近距離国際便(アジアシャトル便等)を導入するなど、フル活用を図ること。

図1 北大阪急行線南北線延伸線の路線図
(北大阪急行線延伸事業パンフレット「北摂くらす」)

 意味の無い文言が並ぶが,要するに,新御堂筋線の北伸の実現を期待するということである。橋下さnの餌に,もちろん,喜んで,掛かったのである。大阪空港なんて,箕面市とは実際関係ない。しかし,この延伸って誰が考えたのだろうか。徒歩でも簡単に移動できる距離をバスで問題無いのに,なんで地下鉄延伸なのか。税金の無駄遣いの最たるものの一つではないか。地下鉄御堂筋線のターミナル千里中央の再開発も長く掛かっている。街の魅力もなく,完成した部分もお粗末で,再開発で集客能力が増したようにも思えない。2本の高層マンションを作って,単なる住宅開発が進んでいるだけの印象だ。都市計画としては無能の極みだ。

 さらに延伸してどうなるのだろう。すぐに箕面山地にぶつかる。まあ,箕面グリーンロードと称してトンネルが箕面山地を突き抜けたが,突き抜けてもそこはトドロミで,農林村域だ。このトドロミに大阪府のキャンプ場ができたのだけど,ペイする利用客は居るのだろうか。単なる地域へのご褒美で,大阪府の重荷になってゆくのではないか。第二名神ができて,インターチェンジができた。まさか,このトンネルの地下に,地下鉄延伸を想定した空間が用意されているのだろうか。

2. 開通延期期間のごまかし

 開通は,たしか,2020年4月1日の筈であった。ぼくの退職日の翌日にあたる。
(報道資料)北大阪急行電鉄南北線延伸線(千里中央駅から箕面萱野駅)を「2023年度末(令和5年度末)に開業」します は,具体的な内容をもつ現在最新の記事であろう。先日,箕面市役所に行ったら,玄関ホールには,3月末日開通のカウントダウンの電光掲示板があった。趣味の悪い維新的な広報ドラマが大画面で流されている。

 この報道資料には市長の挨拶がある。
2019年(令和元年)5月7日 開業目標を2020年度から2023年度に見直し
とある。当時,3年延長と流布されていて,箕面市民は3年の延長かと受け取ったのである。

 何故,延期されたのか。その理由は,地下を掘ってみたら,センリニュータウン開発時の建設資材のゴミが残っていたという。その片付けに3年かかるという。ぼくは,この情報を自ら確かめた訳ではないが,周辺の人達はそう言っていた。そんなんで3年もかかるのお? おかしいやないか。(ある市民に聞いたことで,後述するが,この話はでたらめだった)
 見直しの話が出てから,ヴィソラ敷地内にある萱野南駅になる筈の場所で,新たに建設されていた鉄道を支える太い鉄筋コンクリートの柱が長い時間をかけて破壊されて行った。ぼく自身が,怪訝な気持ちで,連日観察したことである。設計ミスに由来するのか,地下ゴミのためではないだろう。本当の理由は藪の中だけど,責任を取ったものは居ないようだ。三年間の延長で,もちろん,何らかの工事をしているようで,遊び資産分,借り資金の金利も膨らんでいるだろう。不思議な世界だ。見直しを読んでも,何の反省も感じられない。すごい世界だと思う。箕面市長は自分の頭で考えたものなのだろうか。おそらく,箕面市議会で問題が議論されていたのだろうけど,そういう情報に触れていない。ぼくの無関心から来るものであるが。

3. 杜撰極まりない都市計画と土木設計

 箕面市の広報どおり,3年延長とぼくは考えていた。この1月だったか,ターミナル箕面萱野南駅の出入り口に大きな看板が出ていて,2023年度末(どうも来年の3月末)に開通とあった。非常に驚いてイオンの受付に聞きに行った。2023年度末って,これでは4年延長じゃないかと。不誠実な表現だと。イオンの新装開店は開通に合わせるためであったはずだ,という確認を迫ったが,それも回答してくれない。まあ,この場の人が応えられる訳は無い。
 そこの女性事務員に,御本人の理解を確かめたが,応えてくれない。へんなおっさんやと雰囲気もあったので,それまではよくそちらで買い物もしたが,会話の成り立たない場が嫌になって,もう行っていない。要するに,2020年4月1日開通の予定が2024年3月末になったのだから,3年度の延長だということらしいのである。サギだよー。「責任者出てこーい」,という漫才があったなあ。

 北大阪急行線延伸事業の開業目標を見直しました という箕面市の広報であるが,「本事業は、2016年度より用地買収及び工事に着手し、事業を進めて参りましたが、今般、設計及び工事工程の見直しなどが必要(図2)となったことから、開業目標は2020年度から2023年度となる見通しとなりました」,とあり,

開業目標を、2020年度から2023年度に変更します。(3年延期)
総事業費(650億円)に変更はありません。

総事業費が変わらない,って,変じゃない? 2020年4月1日から現在まで,ずっと工事してるのにー。
 図2を観察すると,延伸理由の3点の何れもが,驚くべく杜撰な計画そして設計であったことがわかる。いずれも責任者が辞職すべき事件である。なお,図2では地図の3要素のすべてが脱落している。とにかく,最低,方位が必要なので,およその方位を緑の矢印で示した。方位が無いので,理解できなかったが,方位を付けることで,図2の情報がやっと頭に入るようになった。

 A図はルート図とインデックス図を兼ねている。ここには緑地枠内に,用地買収がかなりの困難に遭遇し,強制的な土地収用があったことが示されている。この計画は前掲の広報の市長の言のように,「『北大阪急行線の延伸』は、今から約55年前の1968年(昭和43年)に策定された最初の箕面市総合計画にその構想が書き起こされてから、半世紀にもわたり、市民誰もが待ち望んできた念願であります。」橋下のお陰?で,2015年にこの案が具体化に動きだしたとしても,箕面市は土地確保のために,早くから動く必要があった。箕面市の責任だ。

 B図とC図は,設計者が愚昧であった証拠だ。B図については,地下鉄の終端は地下水や土砂の急激な流入を防ぐために,設置されるべきダムである。C図については,都心から続く自動車専用道路の陸橋部分であり,道路の下部には強固な橋桁が設置されているのは当然である。わざわざ?,国道423号線の自動車専用道路に接触する形で地下鉄ルートを設置したこと自体,奇妙奇天烈といわざるを得ない。これも,あんぽんたんの設計者であっても,そしてチェックする能力が箕面市や北大阪急行に無くても,国民の税金で賄われる大工事が,何らかのまともなチェック機関を経るべきなのは当然である。箕面市には人材がいない。北大阪急行には人材が居ないにしても,大阪府や国のチェックは無かったのだろうか。決定を下したのは国ではないか。信じられない。箕面市というより,日本の国そのものの程度が低いといわざるを得ない。

図2 延期理由

 

4. おわりに

 このページを作成する当初は,工期が4年追加されたのに,年度で3年,という表現での詐欺行為を強調したかったのであるが,4年の追加工事に至った理由を知って,愕然とした。マスコミは行政の単なるスポークスマンになっていて,何ら問題にしなかったようだ。箕面市議会では何が議論されたのかは知らないが,4年の追加的の工事に係わる費用は膨大の筈なのに,費用は変わらない,と箕面市は言っている。それでは誰が負担したのだろう。これは議会で追及すべき問題であると思う。議会そのものの責任も重大だ。
 図2の特にC図の障害物の追加的工事は,2020年4月1日開通の見積額と比べて,かなりの増額になった筈だ。自動車専用道路の橋桁をただ削り込んで地下鉄のチューブを作る訳には行かず,削りつつ,並行して補強する工事も必要で,当初の見積額の2倍とは言わないが,1.5倍ぐらいにはなったのではないか。土地収用の費用も膨らんでいる筈だ。当初予算と変更無し,これはあり得ない。
 箕面市に住む無力な一老人として,素朴な疑問をここにつぶやいたところである。

以上,Nov.26, 27, 2023記。




宅配便者の手抜き negligence by a delivery man

 宅配便の方々には日頃,感謝している。わが家にも来られる郵便局の配達者の一人を近所で見掛けたりするが,その誠実さにはメルヘン的佇まいすら感じるのである。

 ただ,手抜きする人も居て,アマゾンから定期購入しているワインセットを玄関置きを前もって指定し,届く前のメールについてもこの玄関置きをだめ押しで指定してきたにもかかわらず,平然とフルタイムロッカーに入れる者が居る。ワインセットとトイレットペーパーを一緒に,玄関置きを無視して,フルタイムロッカーに入れたのである。配達連絡メール(Nov. 21, 2023)が届いて愕然とした。ヤマト運輸でないことは確かだと思っていた。

 三日後,そのフルタイムロッカーの管理会社から(自動)メール連絡がきた。早く引き出せと言う。配達業者はヤマト運輸だとある。これは意外で驚いた。昨晩,タニハから自宅に戻って,その勢いで,旅行用カバンに付属するキャリアを持って,フルタイムロッカーで,ワインセットとトイレットペーパーを引き出し,斜行エレベーターに入れ込もうとするができない。二つの段ボールはエレベーター内に転げ落ちて,何とかアスファルトの道や橋や斜面を通って,腰を屈めつつ,自宅に運び込んだ。この形を続けることはもうしたくない。

図1 重いワイン

 で,本日,ヤマト運輸に電話した。近所の事務所に繋がった。ここからだと今宮南のあの事務所だ。近所には二つの事務所があって,より近所の日頃使う事務所は,どうもヤマト運輸直営ではないらしい。
 荷物やメールに記載されていた荷物レーベルは,DAxxx xxx xxxxとなっている。これを伝えると,DAで始まる英数字はヤマト運輸のものではないという。
 幸い,アマゾンカスタマーセンターの電話番号0120 899 190を教えて頂いた。

 その番号で電話すると,中国に転送されたようだ。担当者の日本語理解力は高い。事情を伝えて,荷物レーベルDAxxx xxx xxxx,アマゾンでユーザーIDに使っているものではなく日頃の連絡用に使用しているメールアドレス,ハンドルネーム,名前,住所を伝えた。了解頂いた。そして,さきほど,アマゾンカスタマーサービスからメールが届いた。

「ご注文につきまして、玄関の配達設定ですが、商品がロッカーに配達されて申し訳ございません。今回の状況を把握して、配送サポートに報告いたします。今後の配達と商品の扱いには一生懸命がんばります!このたび、ご理解いただきありがとうございます。」

 これも中国からだと思う。理解されている。安心だ?

以上,Nov. 26, 2023記。

 

 




フィリプスソニケアー電動歯ブラシ an electric toothbrush of Philips sonicare

はじめに

 大阪に赴任して以来,先輩の方から紹介された歯医者さんお一人に,問題がある際に通ったが,その方の年齢は80歳を超えて,どうもまだ営業されているようだが,行く気になれず,ここ10年ほどか,歯医者に行っていなかった。すぐ玄関前ぐらいに新たに歯医者ができて1度行ったがどうも合わず,ぼくは次の一歩が出なかった。息子の奥さんの父親は歯医者さんなのだが,大阪の南の方で開業されていて,遠いことと歓迎されないように思えて,行かずじまいであった。
 毎年,箕面市から来る歯科検診案内を何とか利用したく,ネットで調べたら,よくいっていたジムの前にこの歯科医院があるようだ。写真には沢山の若いスタッフが写っていて,まあ,行ってみた。すごくいい印象で,1回目は,虫歯2本の治療,その翌週は2回目で,ステイン取り。皆若くて感じがいい。オーナーは一人だが,一つの大学関係の若いメンバーを集めているようだ。この場で開業して,20年だという。全然知らなかった。医者が一人で,いわば休み無く営業を続けることに,違和感があったので,この医院のように,歯医者が五名を超えるようなスタッフの豊富さには魅力を感じている。

 そういえば,歯医者に行った理由は,下顎右側の奥歯のブリッジと歯茎の間が大きくなって,食べ物の滓が残っていて,ツマヨウジを使うのであるが,取れないという問題があった。そういう理由でこの歯科医院に出かけたのだった。X線チェックの結果は問題がないというもので,進行させないために,電動の隙間滓除去のツールを使おうと思ったのである。なかなか良いのが無い。そこで思いついたのが,電動歯ブラシであった。ソニケアーは,音波で歯の根元まで洗うという。まあそれを信じてアマゾンで見て適当な価格のものを購入した。

 アプリと連動するようになっているが,ブルーツースの連動が悪い。使い勝手も慣れていないためのあって,良くない。そこで,サポートに電話して相談したが,解決しなかった。その際に,試用期間30日なので,問題があれば返却できると言われた。これが過りの始まりであった。三日ぐらいなら返却は可能かも知れないが二週間近くでアマゾンでチェックしてもそれは駄目だなあ。

1. Philips sonicare

 購入して10日ほど。歯間が磨けていない。bluetoothを介してのiPhoneとの接続も悪い。明日,返却手続きをしたい。【2023年10月】電動歯ブラシのおすすめ人気ランキング30選【歯科医が選び方を解説!】|徹底比較 が一番,いいようだ。

追記 Nov. 27, 2023: フィリプスのキャンペーンをまともに読まずに勝手に1カ月の試用期間があると思っていた。アマゾンの購入履歴から返却手続きをしようとすると受け付けていない。おかしいと思ってフィリプスのサイトをみると,「対象店舗で対象製品を期間中にご購入いただき、磨き心地にご満足いただけなかった場合、ご購入日の翌日から30日以内に、製品とレシート及び必要事項をご記入済みの応募用紙をご送付いただければ、ご購入代金を全額返金いたします。」とある。アマゾンでは駄目だ。残念っ。

2. パナソニックのドルツ

 W音波で歯間用の繊細のブラシもあって期待したが。https://my-best.com/products/506441 には,振動音も大きく、全員から「頭に響く」「家族から音を指摘された」といったコメントが寄せられました。音が控えめで使いやすい商品もあるなか、こちらは使用する時間や場所に配慮が必要です,とある。モニター五人のうちの四人が下記の感想だ。

  1. 「音が大きく、頭に響く」(モニターA)
  2. 「家で使ってみたところ、家族から音の大きさを指摘された」(モニターB)
  3. 「まわりに響く音量」(モニターC)
  4. 「ノーマルモードでもかなりの音量。自分でも大きく感じるので、まわりにも結構聞こえそう」(モニターE)

追記 Nov. 27, 2023: 1.の追記で述べたように,ソニケアが返却できない。このドルツは有力候補だったが,頭に響く,というのは致命的で,購入リストから外したのである。替えブラシが,フィリプスとブラウンに比べてかなり廉価で,これも魅力と考えていた。

3. Braun’s Oral B i06

 上記の代用として,振動がなくて,歯垢が最も良く取れる機種がこれだ。

以上,Nov. 25, 2023記。

追記 Nov. 27, 2023: このブラウンを購入しようと思ったが,残念ながら,ソニケアが返却できず,さし当たり,諦めた。

4. フィリプス ソニケアー ダイアモンドクリーン HX9911/72を使って行こう

図1 本体,充電器,旅行ケース

図2 ソニッケアーって?

図3 機能

 何故か,フィリプスの全額返金キャンペーンの機種リストにこの機種は含まれない。購入後二週間を過ぎた。手での歯磨きはパソコンをしながら場合によっては1時間もやっていたのではないだろうか。食塩だけで磨いており,塩が喉を刺激するのだろう,吹き出すこともある。このソニケアーはソファーに座って,すぐに済んでしまう。

 歯磨きの時間がかなり短縮されるようになった。手磨きに比べての結果は多少,ソニケアーの方がいい。ただ,奥歯の間の食べ滓は取れない。ソニケアーの使用後,10分後ぐらいだろうか,食べ滓が何となく浮き出してくるように思う。
 アプリとの連動を諦めて,今は,全く使っていない。使っている時には2分間の限定で,次の2分間が出来なかったが,アプリ無しだと,自由に追加できる。今は,2分間 + 2分間,のペースだ。

 タニハに出かける際にも旅行用ケースに入れて持参する。ケースに本体は入るがブラシにプラスチックカバーを付けると,蓋が完全には閉まらず,カバンの中で,本体が転がる現象があったりする。なかなかリッチなケースなのだが,設計ミスだ。充電ケースはバカラではないが,なかなかオシャレなガラスコップで,本体を投げ込めば充電できる。

5. 互換ブラシの調達

 ブラシは3カ月に1回の交換という。同じブラシを使い続けることの違和感も少しある。使ったらすぐに水洗いするのであるが乾かない。本体にブラシを付けたまま洗って,オンにすると,ブルッとブラシから水が飛び出す。これは感動ものだった。

 で,この交換ブラシは高い。アマゾンで安くて1本880円。中国製から選ぶことになるが,口コミを見ると,絶望的になる。種々行ったり来たりして,諦めて,次のものを注文した。これだと1本230円。実際に使ってみてのことになる。あまり期待はしていないがささやかな抵抗といって良いのか。パナソニックだと1本500円ほどだ。これなら純正を使っても良いのだけど。
ブラシモ 互換ブラシ フィリップス ソニッケアー 電動歯ブラシ 替えブラシ 対応 ダイヤモンドクリーン プレミアムブラシヘッドミニ 8本入

図4

図5

図6

以上,Nov. 27, 2023記。

6. ブラシモが到着

 今日,ブラシモの互換ブラシが,タニハに行く前に,自宅前のポストに,届いた。タニハから帰って,食後,使ってみた。心配していたのはソニケアによる言わば拒否反応であったが,そういう現象は無いようだ。磨く強度にもモードにも表示の影響は無いように見える。ただ変更などはしていない。使ってみて,変に振動する場合があり,ソニケアの純正に比べて小さいためなのか,わからない。上掲図6の宣伝文句の3に,「万が一の不具合には,交換・返金対応」,とあるので,このブラシをさし当たり,使ってゆくつもりだ。ブラシサイズが半分近いので,今だ慣れていない。

図7 ソニケアー本体,ブラシ,ケース

図8 ケースがしっかりと閉まる

図9 ブラシモ到着

 ソニケアーに対する不満の一つは,本体とブラシを入れるとケースが閉まらないということだった。しかし図7の赤〇で示したブラシの本体装着部分が多少固くて入り難いためだった。強く押し込む必要があった。ガシッと填まった。その結果,図8のように,しっかりと閉まった。なかなかしっかりしていて,オシャレだ。高級感がある。図9は届いたばかりのブラシモ8本の一つを純正のもの(左手)と並べてみた。長さ1/2で体積は1/4に近い。ソニケアー本体にしっかりと填めることはできる。接続部には純正同様の構造が見られる。次回には,使用感が許容範囲かどうか,記述するつもりだ。

以上,Nov. 28, 2023記。




Gmail ユーザーにメール返信ができない Mail Delivery Subsystem from Google Mailer Daemon

Gmailユーザーへのメールはもう嫌

 Google Monopolyはいまや,USAでは常識。Gmailもその世界に入った。スマホユーザーに使い勝手がいいのか,急速に普及し,その段階で,他のメールアプリを駆逐するプロセスに入ったと言えるだろう。アップルやアマゾンなどのメジャーサイトを名のる怪しいメールがどんどん来るようになった。この状況もうまく利用しているようだ。
 アップルのiCloudもいいだろうが,しらんまに無料限界を超える可能性があるので,特別の場合にしか,ぼくは使っていない。レンタルサーバー(さくら)に付属するメール機能が中心だ。勤務先のメールは退職後も使用可能だが,勤務先の通信環境を担う富士通は自らの低いセキュリティ能力ゆえにMicrosoft Outlookに換えてしまった。ものすごく使いにくい。

 Gmailユーザーとのやり取りで,もう二進も三進も行かなくなった。相手はレンタルサーバーに問題があるというけど,Gmailは世界のIT関連企業のうち,日本のレンタルサーバー運営企業を信頼していないようだ。Gmailに取り込むつもりだ。Outlookはターゲットには今のところなっていない。というか,Gmailの基準をクリアしている。

 いま,自らの受信メールフォルダーのMail Delivery Subsystem Mailer-Daemonのメールを検索してみた。ぼくのフォルダーでは2011年からでトータルで30件ほどだが,その理由は,ぼくが関係していた研究所のメーラーの低いセキュリティによるもの(富士通),携帯からのメール @dokomo.ne.jp,ezweb.ne.jp, biglob, yahoo,ne.jp, softbank.ne.jp, 親族の一人の rejected due to local policy (mac.com) (時々受信される,もう送るのを止めた),であった。

 先月ぐらいからか,Gmailユーザーへの送信について,目に見えて,問題が出てきた。be氏の指摘もあって,昨夜から,原因を探ることにしたのである。
Gmailユーザーに,ぼくもGmailを使って,21:54, Nov. 18に送付すると,他者に21:57, Nov.18に届く。3分ほどだ。
Sakuraから自分のSakura20:32, Nov. 18に送ると,20:33に届く。1分ほどだ。ソフトバンクの5Gはこの頃特に遅くなった。
Sakuraから自分のGmailに20:34, Nov. 18に送ると,届いたのは04:15, Nov. 19。8時間弱だ。

 もう,GmailユーザーにはGmailで送るしかない。Gmailユーザーには当方のGmail宛てに送ってもらうしかない。もちろん,ぼくもGmailユーザーにはGmailを使うしか無い。

レンタルサーバー「さくら」の言い分

 Gmailにメールが転送されない 2023/10/20•ナレッジ に説明がある。要するに,上記の赤字の対処にシフトせよということだ。
 ただ,Gmail(ブラウザ版)の設定をしたい にある手法も紹介されている。これは,Gmailに,サクラや他のメールアカウントを登録するものであり,Webメールが嫌いなぼくには意味のない対策である。

 これからは,3カ所のメールチェックが必要になる。ああ,めんどうくさーいよー。
macのmailアプリで,サクラのメール,iCloudのメール,ヤフーのメールを,
Google Chromeで,Gmailを,
そして,MicrosoftのOutlookを見る必要性がある。

以上,Nov. 19, 2023記。

macアプリメールでgmailを送受信

 macのメールでGmailアカウントを追加することで,gmailの送受信が可能になった。gmailのメール構造がぼくには何とも使いにくくて,イライラしての所作である。

 Gmail設定方法(Macメール 編)を参考に実施した。すでにgmailユーザーであれば,4.【メニュー(歯車アイコン)】⇒【すべての設定を表示】を選択します,から実行する。Googleから何度も鬱陶しいセキュリティ対策の手続きがある。

 アップルサポートの Macの「メール」でメールボックスを読み込む/書き出す でも可能かも知れない。トライしていない。

以上,19:58更新,2024/04/21。

 




名入り色プッシュピン情報の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>

以上,Nov. 15, 2023記。

2. 複数の名前入り位置情報は

 複数の名前入り位置情報を登録するには,https://developers.google.com/kml/documentation/kmlreference?hl=ja#folder を使うことになるだろう。このリンクにはサンプルが表示されている。ぼくが必要なものだけ残して,次に示す。

<?xml version=”1.0″ encoding=”UTF-8″?>
<kml xmlns=”http://www.opengis.net/kml/2.2″>
<Folder>
<name>Folder.kml</name> <open>1</open>
<Placemark>
<name>Folder object 1 (Placemark)</name>
<Point>
<coordinates>-122.377588,37.830266,0</coordinates>
</Point>
</Placemark>
</Folder>
</kml>

 この記述のうち,<open>1</open>の1の指定によって,KMLファイルを選択した時に,フォルダーが開いて表示される。いま,ぼくの目的を達成する記述を次に示す。行間は実際には禁忌である。

<?xml version=”1.0″ encoding=”UTF-8″?>
<kml xmlns=”http://www.opengis.net/kml/2.2″>
<Folder>
<name>gc7points.kml</name> <open>1</open>

<Placemark>
<name>gcp_a</name>
<Point>
<coordinates>経度a,緯度a</coordinates>
</Point>
</Placemark>

<Placemark>
<name>gcp_b</name>
<Point>
<coordinates>経度b,緯度b</coordinates>
</Point>
</Placemark>

⋯⋯⋯⋯⋯

<Placemark>
<name>gcp_g</name>
<Point>
<coordinates>経度g,緯度g</coordinates>
</Point>
</Placemark>

</Folder>
</kml>

 目印はデフォルトの黄色になるので,他の表示と競合するので,水色に変えたいし。

3. プッシュピンの色を変更したい

Google Earth/Maps Icons にサンプルアイコンのリストが見える。このリンク先は,http:,なのであるが,リンクは見ることができる。Googleがセキュリティの観点から,http:,を廃棄したのにもかかわらずである。興味深い方針だと思う。http://maps.google.com/mapfiles/kml/pushpin/ltblu-pushpin.png アイコンは色々あるが,プッシュピンの針先が正確な位置が表示できるので,プッシュピンから離れられない。

 全pointsに対して同じプッシュピンを使うとなると,<Document>と</Document>で囲んで,その冒頭に<IconStyle>と</IconStyle>で囲んだブロックを配置するのだろう。少し実験したが,結局,Google Earth Proで,左ペーンの場所のタイトルを選んで,右クリック / コピー,して,エディターにペーストして学ぶところはあったが,不要なものも付加されている。
 種々,その後,学んで?,最低限の形を得ることができたので,次に示す。なお,このWebページへのコピペは,preformattedを選択しないと,出来ない。特に個々のプッシュピンに対する色指定の部分をオレンジ色に塗っている。なお,次のスクリプトには行間が入っているが,実行ファイルには入れてはならない。

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">

<Document>
	<name>UwamizakiDroneBase7gcp.kml</name>
	<open>1</open>
	 <Style id="whtpin">
             <IconStyle>
                 <Icon>
                     <href>http://maps.google.com/mapfiles/kml/pushpin/wht-pushpin.png</href>
                 </Icon>
             </IconStyle>
         </Style>
	<Folder>
		<name>UwamizakiDroneBase7gcp</name>
		<open>1</open>
		<Placemark>
			<name>base-GE</name>
			<styleUrl>#whtpin</styleUrl>
			<Point>
				<coordinates>128.529927781,27.352555558,0</coordinates>
			</Point>
		</Placemark>
		<Placemark>
			<name>a-rot</name>
			<styleUrl>#whtpin</styleUrl>
			<Point>
				<coordinates>128.529317242,27.353249608,0</coordinates>
			</Point>
		</Placemark>
		<Placemark>
			<name>b-rot</name>
			<styleUrl>#whtpin</styleUrl>
			<Point>
				<coordinates>128.529897150,27.351787300,0</coordinates>
			</Point>
		</Placemark>
		<Placemark>
			<name>c-rot</name>
			<styleUrl>#whtpin</styleUrl>
			<Point>
				<coordinates>128.530017250,27.353252369,0</coordinates>
			</Point>
		</Placemark>

                         ⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯
		
		<Placemark>
			<name>g-rot</name>
			<styleUrl>#whtpin</styleUrl>
			<Point>
				<coordinates>128.529735058,27.351815917,0</coordinates>
			</Point>
		</Placemark>
	</Folder>
</Document>
</kml>

  なお,他の色(白色も含む)の例を次にリストする。

http://maps.google.com/mapfiles/kml/pushpin/blue-pushpin.png
http://maps.google.com/mapfiles/kml/pushpin/grn-pushpin.png
http://maps.google.com/mapfiles/kml/pushpin/ltblu-pushpin.png
http://maps.google.com/mapfiles/kml/pushpin/pink-pushpin.png
http://maps.google.com/mapfiles/kml/pushpin/purple-pushpin.png
http://maps.google.com/mapfiles/kml/pushpin/red-pushpin.png
http://maps.google.com/mapfiles/kml/pushpin/wht-pushpin.png
http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png

以上, Nov.21,2023記, Dec.8, 2023修正。

4. Google特有の色指定 αBGR

 https://howtosfdc.cloud/salesforce/change-shape-color-kml-salesforce-maps/ このページがこのテーマでは直接的な情報である。すぐ上のKMLでは,<color>ff336699</color>,Brownとなるのであるが。

  • Red – ff0000ff
  • Yellow – ff00ffff
  • Blue – ffff0000
  • Green – ff00ff00
  • Purple – ff800080
  • Orange – ff0080ff
  • Brown – ff336699
  • Pink – ffff00ff

 この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%。

 アルファを除くRGBの配列の例として,HTML COLOR CODES
Get HTML color codes, Hex color codes, RGB and HSL values with our color picker, color chart and HTML color names. Let’s go!
 が参考になるかも知れない。もちろん,RGBをBGRに変更して使用しなければならない。

以上,Nov. 21, 2023記。




can’t go back to non-Facetime

今日,be氏の提案で,AppleのFacetimeで研究の打ち合わせをした。Apple機器同志でWi-Fiを介してのアプリ利用なので,LINEのように,コマーシャルに邪魔されることもない。

この環境はJobsによって2010年初夏に発表されたものなんだなあ。図表も目の前に提示できるのもありがたい。ぼくは今日はiPhoneでFaceTimeでやりとりしつつ,macでファイルを一緒にみながら,検討することができた。

iPhone や iPad で FaceTime を使う には利用の可能性が見える。

iPhoneとAndroidでFaceTimeができる!やり方や注意点は? では,アンドロイドとの対応も可能のようだ。「異なるOS間でのFaceTimeは便利なものの、FaceTimeアプリからリンクを生成する必要があるため、発信者は必ずiOSユーザーである必要があります。」,と,「iPhone側の電話番号がアンドロイドユーザー側に表示される」が,これぐらいなら,問題ない。kaさんも一緒にできるね。

以上,Nov. 12, 2023記。




ジム用海パン swim shorts in the gym

サーフパンツ(日本語)で泳ぐとお腹から水が入ってしまう。それがクリアできたのは,図1のRusty製のものであった。ヴィソラのスポーツデポでやっと2020年に出会えた。品番 Rus 910405 BLK L,国際スタンダード。胴回り84-94cmだった。やっとオーケー。4500円税抜き。今はもう販売されていないようだ。予備のものを含めてカルキでかなり傷んだ。この凄いのは胴回りに幅廣のゴム入り?のストリップが付け足されていて,これ効果で水が入らない,優れもの。腰回りがすごく心地よかった。

アマゾンサイト内で,ブランド名”Rusty”を使って,検索するのであるが,明示なく,Rustyから,外されている。Rusty本体のウェブサイトにも無い。仕方無く,図2の,[NARANNBU] ナランブ メンズ 水着 サーフパンツ オシャレ 通気 速乾 メッシュインナー 海パン 水陸両用 大きサイズ M_4L をあまり期待せずに注文した。[NARANNBU] メンズ 水着 サーフパンツ オシャレ 海パン 海水パンツ メッシュインナー 通気速乾 UVカット ボードショーツ 02ネイビー L 実際サイズLに相当 販売: Narannbu-JP商標登録第-6218030号。日本のメーカーなので,サイズ情報が詳細で親切である。廉価だ。

この,Narannbu,到着したのであるが,残念ながら図1のような腰回りのゴム入り部分は全くない。Rustyに比べると薄くてかなり軽い。もう,あまり泳がなくなったから,まあ,いいか。ゴム入り構造があるかどうかは,画像や説明ではわからない。Rusty2着はさきほど,ゴミ箱に捨てた。気にいってもメーカーがモデル廃棄してしまう。そういう時代ではある。人気が無かったのだろうなあ。

図1 Rusty 品番 Rus 910405 BLK L

図2 [NARANNBU] メンズ 水着 サーフパンツ L

以上,Nov. 8, 2023記。




macがUSBメモリーを受け付けない:一人相撲 Sonoma refusing a USB memory: several days’ one sided rivalry

ことの発端

 大容量20GBほどのファイルをmacからWindowsマシーンに移動するのに,USBメモリーを使うべくUSBメモリーをアダプター経由でmacに接続しようとしたら,次のようなメッセージが。

 重い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メモリーに対してのものではないが。

 HDD/SSD/USBメモリーのフォーマット,のI-O DATAのページを見ると,「Windows/macOSでデータを共有する場合
Windowsを使って、『exFAT形式』でフォーマットしてください。※ macOSでは通常NTFS形式のHDD/SSDにデータを保存することはできません。」とあるのを見つける。

 当該USBメモリーは,NTFSフォーマット形式,なので,exFAT形式でフォーマットしたらどうなるかと,Windowsマシーンの80GB余りのファイル群が入っているが,Windowsマシーンにあるものなので,Windows環境でフォーマットしたいのですが? 【USBメモリー】,に従って(全く読んでないけど)実行した。初期化の前に,このUSBメモリーのプロパティをみると,全般ではファイルシステム: NTFS,ハードウェアではSAMSUNG, VendorCo Disc,となっている。
 当然ではあろうが,macによる読み書きができるようになった。感謝だなあ。
 初期化のあと,初期化前のzipファイルと更新した履歴テキストをコピーした。なお,NTFSフォーマットした経緯を次のページに記している。Windows 10 DocumentsのUSBメモリーへのバックアップ

以上,Oct. 27, 2023記。

 




Windows 10 DocumentsのUSBメモリーへのバックアップ backup of Windows 10 Documents into USB memory

はじめに

 macのタイムマシーン6TBは使用しているが,mouse製Windows 10ではバックアップを取っていない。ここ数年,3Dデータの処理やキンドル版発行のために,100GBほどの書類が溜まってきた。これが壊れると,研究がストップする。
 締め切り原稿を出して,急にこの件が気になって,256GBのUSBメモリーにバックアップすることにした。ところが,バックアップに余りに時間を要してしまって,結局,失敗が2回続いた。

メーカー: ‎Aeuln,対応OS: ‎mac_os, windows_me, Windows_xp, windows_2000, windows_vista, windows_7,その他 機能: ‎ポータブル,耐水性,防水,接続方式 :‎USB,サイズ: ‎256GB,梱包サイズ: ‎9.2 x 4.5 x 2.2 cm; 50 g, 製造元リファレンス: AEULN-856692, ASIN B09YCL4BY3, Amazon.co.jp での取り扱い開始日: 2022/1/4

1 昨日〜今日までの問題

 C:\Users\moto\Documentsの中の一つのフォルダー88GBのUSBへのバックアップに対して,所用時間17時間が出てきて驚いたのであるが,実際は,図2, 3のような質問が途中に出てきて,これに応えないとバックアップが進行しないので,つきっきりでも無い限り,完了しえない。そして,ファイルやフォルダーについて,何故かプロパティをコピーできなくても良いか,ってな質問が出て,コピーしないで次に進むことに,違和感もある。

図1 経過例

図2 確認画面例1

図3 確認画面2

「対処法」プロパティを含めずにこのファイルをコピーしますか?に良い情報があった。チャイナ系のサイトのように思う。プロパティを含めない,のは,まずいらしい。「このエラー「プロパティを含めずにこのファイルをコピーしますか?」は、ファイルシステムに起因している可能性があります。コピー先のディスクやパーティションがFATの場合、プロパティ付きでコピーや転送ができないファイルがあります。これは、NTFSファイルシステムはADSやファイル暗号化情報に関わるプロパティを保存できるのに対し、FATドライブでは保存できないためです。そして、「プロパティを含めずにこのファイルをコピーしますか?」というエラーが発生します。」とある。

2 USBメモリーのNTFS初期化,バックアップフォルダーの圧縮

 Windows10で,249GB-USBを選択して,フォーマットを選ぶと,ファイルシステム(F)として,exFAT(既定)になっていた。これはmacとWindows両方に対応しているが,FATの一つなので,この問題を生じていると考えられるので,NTFSで初期化を実施した(図4)。

 なお,Microsoftの情報 FAT、HPFS、NTFS ファイル システムの概要,も参照した。さらに,前述の,「対処法」プロパティを含めずにこのファイルをコピーしますか? では,エラー回避のために,ファイルを圧縮してコピーするとこの種の問題は生じないということで,フリーウェアの7-Zipを使って(右クリックで表示される),zipファイルを作成することにした。合計サイズ85GB298MB(図5)。パネル表示によれば,50分ほどかかるようだ。

図4 USBメモリーのNTFS初期化

図5 moto > win_moto_documentsフォルダーの7-Zipによるzip圧縮

図6 7-Zipで圧縮中

 15:06スタート。16:14には残り,2h30m。20:12終了。全4時間だった。元フォルダーは85.298GBだったが,27.564GBまで,つまり32%まで圧縮できた。出来上がったzipファイルをUSBメモリーにコピーした。コピーに要した時間を計測していないがプロパティーで見ると,20:14にスタート,20:49に終了。35分間。

3 WindowsマシーンとUSBメモリー

 Windowsマシーン内のwin_moto_documtnsフォルダーを7-Zipで圧縮して,USBメモリーにコピーした。両方に,同じメモ帳ファイルを置いた。ここにこれからコピーの履歴を記録してゆくことになる。

図7 Windowsマシーンのwin_moto_documtnsフォルダー

図8 USBメモリーのwin_moto_documtns.zip

おわりに

 図7には,win_moto_documents内のフォルダーが見られる。新たなファイルはそれぞれのフォルダーに収納する必要がある。そして履歴は共通のメモ帳に記録する必要がある。

以上,Sep. 30, 2023記。

追記

 馬鹿馬鹿だ。まだ一月経ってない作業なのに,この作業を完全に忘れていた。NTFSフォーマットでは,macが読めない。USBメモリーのケースに,Windows Openって,書いているし,レーベルにもWindows用,って書いている。また,exFATに戻して,再コピーした。バックアップ用の追加ファイルは,zip化してゆけば,exFATでもコピーができる。

以上,Oct. 27, 2023記。




Meshmixerで底抜け解消そして  closing up a big gap in the 3D mesh using Meshmixer, and

はじめに

 やっと,大饗石の底抜けを解消することができた。Autodesk Meshmixerはオープンソースである。ありがたい。一昨晩,寝る前の恒例のTV録画鑑賞に入る前に,出会ったのである。Meshmixerというぐらいだから,点群よりもメッシュに対応している。ぼくのイメージでは,これを使えばIllustratorのように穴の周辺のネットを引っ張ってブリッジをどんどん架けて,その隙間は一気に埋められるというような印象があって,実際にやろうとしたが全然そうはならない。
 とはいえ,3Dスキャンで得たオブジェクトのデコボコを滑らかにすると行ったことは手作業でできる。CloudCompareやMeshLabでは到底できないことである。iPhoneLiDARで作成した3Dスキャンオブジェクトのネットが綻びているのは普通のことで,この解消はCloudCompareではできず,MeshLabの役目ではあった。MeshLabでコマンドを実行するにしても,パラメータの役割が説明を読んでも理解できず,無力感が襲うのであるが,Meshmixerを使っていて,そういう感覚は全く生まれず,実行プロセスが目の前に見えて,何とも頼もしい。これを無料で提供しているAutodesk恐るべしである。このアプリの目的は,3Dプリンター用のファイルを作成することにあるが,残り少ない人生,この分野には到底入れない。

1 Autodesk Meshmixer

Meshmixer 3.5 is now available ! https://meshmixer.com/download.html

Japanese Installer Windows 3.5,System Requirements Meshmixer 3.5 Microsoft Windows 7 or later 4GB system RAM Release April 17, 2018.

Wikipedia:  スカルプトモデラー。 Sculptor modeler,いわば彫像や塑像を作るソフトだろうか。メッシュの合成、メッシュの伸長・回転、メッシュ選択のスムース化などの機能を持つ。3Dプリンタ向けに、床面上への複数オブジェクトの詰め込み (Layout/Packing Tool)、効率的な支柱構造を自動的に追加する機能が追加されている。開発終了。

————————————————
Autodesk Meshmixer UI解説 -2つの3DデータをMIXする-

Autodesk Meshmixerは無料で公開されているスカルプ系の3Dモデリングソフト。簡単な操作で加工ブラシを使用して、粘土を扱うようにモデル表面を変形することができ,3Dスキャンデータの修復や3Dオブジェクトデータの合成,3Dプリンターのデータ作成を気軽に行うことが可能。
ここでは、UIの解説と、2つの3DデータをMIXする方法を解説する,とある。

2 3D底抜け解消が実現

当方の,C:/Users/moto/Documents/win_moto_documents/win_3d_scan/大饗石metascan_LiDAR/大饗石from_iPhone/onlyOoaeishi_closeHole.mlp というMeshLabファイルを使う。

 左のメニューアイコンで実行する。上のメニューからでも可能。図1は大饗石objをインポートしたところで,次にメッシュの綻びをチェックすべく,解析 > 検証を選択直後の様子が図2である。大饗石の底抜けの部分には赤い縁取りが見られるが,銀色の表面の部分の穴がチェックされているようだ。図3は「すべて自動修復」ボタンを押した後の画面である。結構の時間がかかったように思う。

図1 大饗石のobjファイルをimportした

図2 解析 > 検証

図3 「すべて自動修復」の実行後 

 図4では,解析 > ソリッド作成,を実行しているところである。かなりの時間を要した。図5は完了した際の画面で,ソリッド作成のパネルが現れて,細かなパラメータの設定ができる。ぼくはこの結果に満足して,下の「適用」のボタンをクリックして,図6の表示を得た。とにかく,永らく切望していた大饗石オブジェクトの頑丈な底ができている。ソリッドの意味がわからない。蓋ができても中味は空っぽだ。

図4 解析 > ソリッド作成

図5 ソリッド作成直後

図6 適用,の直後

 図7は,インポートしたオブジェクトだ。パネルでその選択をしている。図8はソリッド化されたオブジェクトだ。このオブジェクトを選んだ状態で,エキスポートした。図9では,Mesh_step3_obj_mixer2.objとした。この前に,Mesh_step3_obj_mixer2.mixで全体を保存している。

図7 Mesh_step3.obj 表示

図8 Mesh_step3.obj(ソリッド)表示

図9 エキスポート: Mesh_step3_obj_mixer2.obj

以上,0:20,Sep. 23, 2023記。

3 体積をCloudCompareで求めるーMeshmixerで穴埋め,平坦化

 CloudCompareに取り込んで,Edit > Mesh > Measure volume,を実行。V= 37.7436,
mesh has hole。またこのメッセージだ。図10ではwireframe表示して観察したが,穴は見えないなあ。面積も求めた(図11)。

図10 CloudCompareで体積を求めたが

図11 面積も

 図12は,Meshmixerで,解析 > 検証 > すべて自動修復,の実行後。この前に,沢山の穴の表示があったが,撮影を忘れた。ソリッド化を実行した後,改めて,解析 > 検証 > すべて自動修復,を実行する必要があった,ということらしい。今後はそうしたい。

図12 自動修復後

図13 ブラシで北壁をフラット化(途中)

図14 ブラシで北壁をフラット化済

 図13, 14は,スカルプトsculpt(動詞しかないが) > ボリューム選択 > フラット化 flatten,を北壁について実行してゆく過程を示している。繰り返すとどんどんフラット化がすすむ。元々のオブジェクトはフラット化後の雰囲気に似ていたが,作業過程を進めて行く過程でボコボコになったので,この種の作業そのものが体積計算の正確度を下げるものでは無いと感じている。
 他の面のフラット化も記録?のために,鬱陶しいだろうが以下に示す。

図15 南面のフラット化実行前

図16 南面のフラット化実行後

図17 頂面のフラット化実行前

図18 頂面のフラット化実行後

図19 東面のフラット化実行前

図20 東面のフラット化実行後

図21 西面のフラット化実行前

図22 西面のフラット化実行後

図23 底面のフラット化実行前

図24 底面のフラット化実行後

図25 西北西付近のフラット化実行前

図26 西北西付近のフラット化実行後

 以上の作業がholeを埋める効果があるとは思えないが,外から見て穴のように見える部分がほぼ無くなって,実体に近くなっていると感じている。
 もう一度,解析 > 検証 > すべて自動修復。穴なし。終了。
 名前を付けて保存。Mesh_step3_obj_mixer3.mix,エキスポート
Mesh_step3_obj_mixer3.obj だ。

4 体積をCloudCompareで求めるー警告メッセージから回避できた

 Mesh_step3_obj_mixer3.obj をCloudCompareで開いて,図27のDB Treeに見られるようにメッシュを選択して,Edit > Mesh > Measure volume,実行。計算結果は,V=37.6635。警告メッセージが無くなった。成功だ。Edit > Mesh > Measure surface,実行,S=69.7372。図27最下部のコンソールに見える。

図27 objファイルから体積と面積が正しく求められた

 点群verticesをPLYで保存する前が図28である。

図28 objファイルのverticesを選択して

5 OBJファイルの点群verticesから2.5D volume 計算

 上記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で,切り口は見えない。まだ事態が掴めない。

図32 segment out 実行

図 33 confirm segmentation

図34 left side view

 図35で見ると,segmentedは欲しいcloudの筈なのだが不要な方がそうなっている。図36, 37はremainingのトップからとボタムから見たcloudだ。

図35 segmentedのtop view

図36 remaining のtop view

図37 remainingのbottom view

 図38のfront viewを見ると,オブジェクトが図35のcloud抜きなので,完全に分離されている。もしこのtopとbottomを使う場合,点群remainingに,上下の点群が一つの点群エンティティーになっているので,分割する必要があるが,それはできないっ,とその時は思ったのである。
 意味ないのだけど,remainingとsegmentedの両cloudを選択して,mergeしようとしているのが図39である。図40にはmergeの結果が見える。赤い点群はsegmentedのcloudである。まあ,全くの失敗なのでdeleted。お試しだ。

図38 remainingは完全に2分割されている

図39 Mergeを実行する直前

図40 mergeの結果

 練習2だ。図41はtop view。図42はsegment in。図43で見ると,remainingだけ表示しているが,不連続で断裂してる。回転などして3D構造を見ると,手前の壁だけでなく,奥の壁も削除されているようにも。bottom viewでみて,連続性を考慮して,もう一度トライしてみよう。deleted。

図41 top view

図42 segment in

図43 confirm, remainingを表示

 また読み込んだ。どうも試行錯誤で,なんかわかったような。図44のようにbottom viewにして,図45のように,適当にsegmentした。そして,segment out(図46)。

図44 bottom view

図45 適当にsegmentする

図46 segment out

 図47のようにポリゴンで選んで,segment outしたら,選んだ範囲以外のcloudが残る形だ。そういえば,そうだよなあ。この結果をキャンセル(ツールの✖️)。

図47 底面も頂面も削除されている

図48 見える範囲で適当に縁辺だけ

図49 segment out どうも奥も切れている

 図50は開始前,図51ではsegment out。図52はconfirm前。

図50  開始前

図51 segment out

図52 confirm前

 図53, 54, 55。試行錯誤。ceilとgroundになる点群の分割を考えている。少しずつ,segment outを繰り返している。

図53 confirm前

図54 confirm前 

図55 こんなものかなあ

 図56で,複数回のsegment outに対して,confirm segmentation実行した。図57は,segmentedだけを表示。図58ではremainingだけを表示した。これがsetment outの結果でsegmented outされた「残り」であって,感覚的には,削除を繰り返してきた点群がいわばメモリー内でマージされていたのである。

図56 confirm segmentation実行

図57 segmentedの表示

図58 remainingの表示

 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のように,パネルが消えてシーンには高度頻度分布図が配置されている。

図63 Grid step 0.10(10cm)など

図64 Export grid as a cloudを選択

図65 パネルが消えて高度頻度分布図がシーンに配置されているのが見える

 図66に示した結果が最適値である。grid step 0.200,Volume 32.441, Matching cells: 82.4%。gridが粗いのでもちろん警告は出ていない

図66 最適値

6 OBJファイルの体積計算結果にもう少し拘ってみたい

 以上から,メッシュオブジェクトと点群オブジェクトの体積計算値をその限界精度から考えると,メッシュオブジェクトの計算,Edit > Mesh > Measure volume,の結果,V=37.6635を採用するのが,妥当ということになる。点群オブジェクトの計算過程を見ると粗雑になっている。とはいえ,両値は,かけ離れていないし,点群の値はメッシュの計算結果をサポートしているとも考えられる。
 体積計算にもう少し拘りたいと思う。一つは,点群密度の向上であり,もう一つは手作業での四面体分割法での計算である。

以上,0:35,Sep. 24, 2023記。

 ぼくにとっては,このウェブページを書いた当日に寝ながら,考えて,新たな修正原稿をこの月曜日の事務スタッフ出勤前に,Google Driveにアップロードするのが,ベストだと考えた。Meshmixerによるソリッド化の成果を生かすことにした。

 で,このウェブページが完結できていないので,いま,その後片付けをしたいと思う。すでに述べてきたことであるが,点群のメッシュ化,さらに点群への変換を実行する。その手法は,すでに述べてきたことであるが,

点群PLYのエンティティーを選択して,
 ① Edit > Normals > Compute(デフォルト値)を実行すると,Octreeがこの下位に作成される。
 ② 同エンティティーを選択して,Edit > Mesh > Delaunay2.5D(best fitting plane)を実行。この直後にnormalsに関するメッセージが出るが触らずにYes。その結果,対象エンティティの下位でOctreeと同階層に隙間の無いMeshエンティティー(メッシュアイコンが付加されている)が作成される。
 ③ このメッシュエンティティーを選択して,Edit > Mesh > Sample PointsでデフォルトでOK。デフォルトで百万点にしていたので作成されるエンティティーも1,000,000点になる。
 このプロセスを実行する前の筆者が使った点群PLYは2万点であったから,Points数は50倍になっている。なおこのエンティティーは元の点群PLYと同じ階層に生成される。

図67では点群cloud 50,312 pointsである。

図67 Mesh_step3_obj_mixer3.CCvertices-Cloud segmented

図68は②実行後で,Octreeとともに,meshエンティティーが形成されている。

図68 ②の実行後

図69は,③の実行後で,Mesh_step3_obj_mixer3.CCvertices-Cloud segmented.mesh.sampled を表示。点群cloudのpoint数は,百万点になった。

図69 ③の実行後

図70はボタムのremaining対応を表示している。①〜③実行済みで,これも,point数を百万点にしている。

図70 ボタムのremaining top view

図71のように,両cloudを選択している。

図71 両cloudを選択。

Tools > Volume > Compute 2.5D volume,を実行した。自動で,Ground: remaining 底
Ceil: segmented 地上部,Grid step 0.005 5mmだった。警告なし。計算結果は,Volume 31.825,Surface 17.921,Matching cells 81.6。

図72 step: 0.005

Grid step を0.02にしてみよう。Volume 31.865,Surface 18.050,Matching cells 81.7。

図72 step: 0.02

Grid step 0.005 5mmだ。Height difference raster (0.005)北壁のポイント密度が少ない。

図73 パネル表示を外した

 以上の結果を踏まえて,文学論集Vol. 73-3の原稿に反映している。以下,それを次に。

7 フィールド科学のためのアップルLiDAR測量 Part 2 Ⅴ.4 Meshmixerで大饗石の底抜けを解消して体積を求める

 文学論集Vol. 73, No. 3(発行は2023年末ぐらいか)

 Meshmixer 3.5 is now available ![i] からこのアプリをダウンロードできる。筆者が用意していた大饗石オブジェクトだけのMeshLabファイルからobjファイルを抽出してMeshmixerにインポートした。メッシュの綻びをチェックすべく,解析 > 検証,を選んだ。かなりの綻びがシーンに表示される。「すべて自動修復」ボタンを押した。実行にかなりの時間を要した。MeshLabでこの種の作業を実施してきたファイルであったが,Meshmixerからすると今だ綻びがあるようだ。Meshmixerは,ビジュアルに簡便に,この種の作業が実施できる。これは驚きであった。

 その上で,解析 > ソリッド作成,を実行した。これも時間を要したが,図33(a)のように見事に底抜けが解消した。しかもMeshLabでのポアッソン再建の如く異様に膨らむこともなく,しっかりとした薄皮一枚で底抜けが解消されたのである。


[i] https://meshmixer.com/download.html

図33 Meshmixerによるソリッド化とフラット化

 Meshmixerは,編集過程などでの3Dオブジェクトの変形を修復する機能を持っている。ここではブラシのフラット化ツールをつかって修正した結果を図33(b),(c)に示している。(b)は(a)の新たに付加された底面をフラット化ツールを使って滑らかにしたbottom viewの結果である。(c)は大饗石地上部の東壁および周辺をフラット化したもので,これはフラット化前の(a)右手突出部に対応している。

 なお,このような作業を経たファイルはCloudCompareで開く前に,Meshmixerで,解析 > 検証 > すべて自動修復,を改めて実行しなければならない。

Ⅴ.4.a 大饗石objファイルのメッシュ体積計算

 このobjファイルをCloudCompareで開いて,Edit > Mesh > Measure volume及び > Measure surfaceを実行すると,図34(a)のように,V = 37.6635(警告メッセージなし),S = 69.7372を得ることができた。

Ⅴ.4.b 大饗石objファイルの点群verticesから2.5D volume計算

 objメッシュファイルには点群verticesが含まれており,これを使うと点群対応の2.5D volume計算が可能になる。2.5D volume計算は,Ceil(シール,天井面)にあたる点群とGround(底面)にあたる点群の間の3D空間を垂直方向の小さな立方体で構成される正四角柱で分割して,CeilとGroundの間の立方体を数える手法である。

図34 CloudCompareでメッシュ体積面積計算と点群体積計算の準備

 この手法では,objファイルの点群verticesを,3D構造を考慮して,Ceil点群とGround点群に分割する必要があるが,で示した分割ツールを使って,Ceil点群とGround点群として,それぞれsegmented点群とremaining点群を割り当てることになるのである。図34(b)では分割できた両点群を選んで表示しているので,シーンには⋯⋯segmented⋯⋯と⋯⋯remaining⋯⋯の名称が見える。白っぽく広い面は底面の部分であって,Ground点群に対応している。

図35 点群2.5D volume計算

 Ceil点群とGround点群それぞれを構成する点数は,この大饗石の例ではそれぞれ5万点,2万点ほどなので,Ⅲ.4 計算結果の比較,で述べた「点群ファイルPLYからメッシュに変換しさらに点群に変換したエンティティー」(脚注[i]に説明)の手法で,それぞれ百万点ほどに増やして,図34(b)のようにCceilとGgroundの両点群を選択して,Tools >Volume > Compute 2.5D volumeを実行した。実行結果を図35に示している。正四角柱の断面は正方形であるがその一辺をCloudCompareではGridのstepといい,図35のものはstep=0.005mとしている。図35(a)は計算結果のパネルを示していて,この結果の数値がみえるように切り取って拡大している。Volume: 31.825㎥,Surface: 17.921㎡,Matching cells: 81.6%を示している。なお,Compute 2.5D volumeが算出するSurfaceは,前述のようにオブジェクトの(Z軸に垂直な)平面図の面積を示しているようだ。このパネル下部のOKボタンを押すと,パネル表示が消えて,図35(b)が現れる。点群密度は,反射光量を反映して北壁は南壁に比べるとかなり低い。大饗石の標高分布別に赤色と緑色の間で段彩(原図はカラー)されており,最下部付近の緑色の点群の塊はGround cloudに相当するものである。

 なお,上述のように点群の点数を増やさない場合,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法に限定されるので,もちろん,使用価値はある。


[i] 点群PLYのエンティティーを選択して,① Edit > Normals > Compute(デフォルト値)を実行すると,Octreeがこの下位に作成される。② 同エンティティーを選択して,Edit > Mesh > Delaunay2.5D(best fitting plane)を実行。この直後にnormalsに関するメッセージが出るが触らずにYes。その結果,対象エンティティの下位でOctreeと同階層に隙間の無いMeshエンティティー(メッシュアイコンが付加されている)が作成される。③ このメッシュエンティティーを選択して,Edit > Mesh > Sample PointsでデフォルトでOK。デフォルトで百万点にしていたので作成されるエンティティーも1,000,000点になる。このプロセスを実行する前の筆者が使った点群PLYは2万点であったから,Points数は50倍になっている。なおこのエンティティーは元の点群PLYと同じ階層に生成される。


図36 Surfaceを構成するセルマップ

 なお,図35(a)のSurface値:17.921の算出法について確認したい。step値は図35(a)では0.005で図で表現しにくいので,step: 0.200として図36に示す。ここでは,V:32.441,S:19.840, Matching cells: 82.4%になる。CeilとGroundの両cloudで算出する場合,Surfaceの計算式にMatching cells(%)値は関与しない。

以上,Sep. 29, 2023記