未分類

江端さんのひとりごと

「IETF惨敗記」

1999/03/25

ミネソタ州ミネアポリスのヒルトンホテルで開催されているIETFミーティング参加初日の夜、私はホテルのベッドで、久々に早朝覚醒型の不眠で目が覚めました。精神的な疲労が極に達すると、私のこの病気は予告なく私を襲うようです。

私にとって、このIETFミーティング1日目は、まるで10日間も徹夜して働いたかのような、すさまじい、そして強烈な疲労感と絶望感そのものでした。

最初から最後まで完全に理解できない会議、---文字どおり、一言も理解できない---、と言うものが、この世にあろうとは思わなかったのです。

私は、何も記入できない真っ白なノートを胸に抱えながら、欧米人の出席者で一杯になったヒルトンホテルのミーティング会場で、ただ呆然として前方のスクリーンに写し出されたOHPシートを見ているだけでした。

-----

IETFとは、Internet Engineering Task Forceのことで、インターネットの標準を規定する非営利の団体で、年に2度Meetingが開催されます。

インターネットとは、つまるところ色々な人が色々な目的で使う通信システムのことですので、これを動かすためには共通の決まり(プロトコル)が必要です。

この決まりを決める団体が、IETFです。

IETFには、会員と言う概念がなく、やりたい人がどんな提案しても良いことになっています。その提案は、まず「ドラフト」と呼ばれる英語の文章で提出しなければなりません。そして、その提案が受け入れられるか否かは、このIETFミーティング会場の出席者の多数決で決定されているようです。

要するに、「オープン」であることが、このIETFの特徴とされているのです。

-----

今回のIETFの出席者はおよそ2000人、ざっと見たところ、日本からも30名程度の出席者があり、(シ研)からのも7名が出席していました。

この2000人の人間が、会場のロビーで技術に関する議論を戦わせている様子は、実に壮観です。

実にやかましい。

このIETFのオープンの考え方と言うのは、かなり徹底しているようで、モラルも規範もあったもんじゃありません。

初日、私はスーツ姿で出かけていって、いきなり恥をかきました。

会場には、フォーマルな服装できている人間は、一人もいませんでしたから。全員が、Gパンにスニーカ&Tシャツと言ういでたちで、ロビーのすみっこで壁に持たれかかりながら、ノートPCを叩いていました。朝食はビュッフェ形式で、あふれるほどのパンやフルーツ、ドリンクが提供されるのですが、それを山のように皿に盛っては、床にあぐらをかいて食べていま
す。

さらには、足を別の椅子に投げかけながら、ミーティング会場にまで食べ物の皿を持ち込んで、口をもぐもぐさせながら、発表者の話を聞いています。

最初は驚いていた私も、そのうちマネするようになりましたが。

----

まあ、驚いたといっても、そんなことはどうってことはなかったのです。

本当に驚いたのは、議事の進行方法です。

まずチェアマン(議長)が、議事を箇条書きに書いたOHPを示し、『今日はこれだけのことを決める。じゃあ、最初の提案者、どうぞ』と言って、いきなり提案者による提案ドラフトの説明が始まります。

本当に、面食らいました。

大抵、会議というのは、まず「今日は皆さん、お集まりいただき・・・」と言う挨拶から始まり、このミーティングの背景、目的を説明し、提案者の紹介をして始まるものですが、IETFミーティングでは、そのようなことはまったくしてくれません。ミーティングの議事内容まで、すでにそのワーキンググループのメーリングリストで検討が終わっていることになっており、残るは質疑応答と採決だけです。

ですから、そのメーリングリストに入っておらず、またドラフトを事前に読んでいなかった私は、何が何だか分からないまま、ただひたすら議事が進んでいくのを見守るしかできなかったのです。

-----

ですが、私が、メーリングリストに入っていて、ドラフトを事前に読んでいれば、理解できたか、と言うと、その可能性は絶望的に近いほど低かったでしょう。

ネイティブスピーカのネイティブスピードのもの凄さと言うものは、TOEIC600点台の人間にとっては、バッティングセンタで、飛んでくるボールに小さく書かれているメーカ名を読みとるより、遥かに難しいのです。(実際、きちんと視力を測定すれば3.0以上はあるだろうと思われる私には、そっちのほうが楽かも知れない。)

質問者は、会場にあるマイクの前に並んで、正面の提案者に向かって質問をしていきますが、NHKの「上級英会話教室」のように、一語一語をきれいに区切って、クリアな発音でしゃべってくれるわけではありません。

一つの質問が2秒ぐらいで、その中には、実に25ワード以上は入っているかと思われます。私には、単に動物の『ウオー』とか言うような唸り声の様にしか聞こえません。

この唸り声に対して、会場がワッと笑いに包まれます。周りを見回してみて、笑っていないのは、私(と多分他の日本人)だけのようです。

私は心底、傷つきました。

私に出来ることは、写し出されたOHPシートの内容を、ノートパソコンに写しとることだけだったのです。

-----

そもそもなぜ私がIETFなんぞに参加することになったかというと、これまた自分の意志ではいかんともし難い、悲しいサラリーマンの宿命にあります。

昨年までやってきた仕事である、マルチメディア監視システムのプロトタイプを無事完成させ、今年は製品化に向けて、設計とコーディングの日々だと自分では思っていたのですが、今年の初め、私は上司から別の仕事を命じられることになります。

それが、ポリシーベースネットワーク管理システムの研究です。

「ポリシー」などと聞いて、私は学生時代にちょこっとだけ参加した左翼運動の実績を見込まれたのかしら、などと呑気なことを考えていたのですが(70年代には、政治的理念のない人間のことを、『ノンポリ』と言いましたから)、どうもそういうことではなくて、ネットワークをビジネス運用(どのデータをどの経路で通せば、最も効率的に儲かるかとか)の観点から
管理する、最近新しいネットワーク技術のことです。

この研究を通産省の補正予算で行うことが正式に決定し、そんでもって、いつものことですが、私が放り込まれた訳です。マルチメディア監視システムのほうは、外注のシステムエンジニアを雇って、私のエージェントとして動いてもらうことが決まり、一応会社側としては筋を通したつもりでいるようです。

もちろん、そこには、再びその『ポリシーなんちゃら』を、一から勉強し始める私の苦しみや辛さは何も計上されていませんが、まあ、サラリーマンとはそういうもんです。

ところが、このポリシーなんちゃら技術の研究は、極めて新しい研究らしく、現在のところ、日本において権威といわれている研究者も研究機関もありません。従って、その研究に関する書籍はもちろん、研究発表資料、論文も何一つありません。しかたがないので、私は毎日行きと帰りの電車の中で、IETFの関連ドキュメントを、片っ端から読み倒す日々が続きました。

-----

ミネアポリスで行われているIETFは、5日間の日程で行われ、その間同じく(シ研)から来ていた、M氏のおかげで、他社の技術者と直接話すことができて(当然、私に英語で技術討論をする力量などあるわけがない)、一応報告書を書くためのネタはいくつか出来てきました。

しかし、今回の私にとって、最も重要なミッションはポリシー技術に関するIETFの動向調査でしたから、まさか「英語がわかりませんでした」と書いた報告書を提出するわけにもいきません。

私は、IETF会場のターミナルルームに準備された100台以上もあるコンピュータの1台を占拠して、ポリシーに関するドラフトを印刷しまくり、ミーティングに出席せず、ロビーに座り込み壁に持たれかかりながら、ひたすらドラフトを読みつづけていました。

-----

ポリシーワーキンググループセッションが始まる前日の深夜、ホテルのデスクでひたすらドラフトを読んでいる時に、電話がかかってきました。

"Hello"

応答がありません。

"This is Ebata Speaking."

と言うと、「・・・智一君?」と、おどおどした風の声が聞こえてきました。

嫁さんでした。

私が海外出張ということもあり、嫁さんは娘の麻生をつれて実家の福岡に帰っていていました。

江端: 「おお、よく電話してきたね。」

嫁さん:「フロントが出たのだけど、何を言っているのか全然分からなくて・・・で、辛うじて『スペル』と言う単語だけ分かったから、EBATAとだけ言ったらつなげてくれた。」

江端: 「こっちはねえ・・・英語が全然わかんないよ・・・。」

嫁さん:「そりゃ、会議で使っている英語なんだから・・・」

江端: 「ちがうんだ、そうじゃないんだ。フロントから、ハンバーガショップから、タクシーから、何もかも何を言っているかわからないんだよ。」

そう、私が最高に落ち込んでいる原因は、実はIETFの内容が分からないことではなく、日常会話が全然理解できなかったことです。しゃべることは難しいだろうなとは、思っていましたが、日常会話が聞き取れないという事実は、私を徹底的に絶望させました。

江端: 「とにかく、こちらの能力にあわせて、しゃべる速度を落とすという考え方がないんだ。」

嫁さん:「そう言えば、フロントも全然ゆっくりしゃべってくれなかったよ。」

これは、多分に偏見かもしれませんが、ミネソタでは世界中の人間が英語をしゃべっていると思っているのではないかと思わせる場面が多々ありました。

私がダウンタウンの郊外にあるミシシッピ川を一人で散策していると、5人の子供を連れた子供のお母さんが、私に道を聞いてきます。

"Sorry,I am a stranger here (地元の人間じゃないんで)"と言うと、しかたなさそうな顔で、子供を連れてどこかにいってしまいました。

また、冬期の雪の積雪量と、おそらくは治安の悪さも原因だと思われますが、ミネアポリスのダウンタウンのビルのほとんどは、スカイウォークと言う空中回廊で相互につながれていて、ダウンタウンにいる限り道路を歩く必要はほとんどありません。もちろん、そのスカイウォークは迷路のようにダウンタウンにはり巡らされていますので、簡単に迷子になってしまいます。

夕食を終えて、誰もいないスカイウォークを歩いていると、私の前方にスカイウォークの地図を覗き込んでいる黒人カップルが、私に経路を尋ねてきました。

もちろん、"Sorry, Stranger I am."と答えるしかありません。

ミーティングが終わった当日の午後、歩いて彫刻美術館と言うところに行きました。バスは乗り間違えると、とんでもない目に会うことは、これまでの海外旅行の経験で熟知していましたので、ひたすら歩いていきました。

その途中の道で、母親につれられた可愛い少年が、私に向かって言いました。

"Where are you going, Mr?"

私はとっさに、"What?"と答えましたが、それと同時に、この少年が明らかに『おじさん(Mr)』と呼びかけたのを不快に感じていました。母親のほうが『知らないおじさんに声をかけちゃダメよ』と言う風に子供の手を引っ張って、私とすれ違っていきました。

コンビニエンスストアで、水とミルクをもってレジに向かうと、レジのおじさんにいきなり何かいわれてドキリとしました。"Pardon?(すみませんが)"と私が聞き直すと、"Mexican?(メキシコ人か)"と聞かれていることがわかり、呆然としてしまいました。

ミネアポリスの最後の夜に、IETFに参加した日本人の集まりで、ベトナム料理を食べながら、この事件の話に加えて、中国でウイグル人に間違えられたこと、京都でブラジル人に間違えられたことなどを話したら、「要するに、モンゴリアンなんですね。」と総括されてしまいました。

『ミネアポリスの連中は、きっと、アメリカ大陸の外側は大きな滝になっていて、そこから海の水が落ちこんでいて、そしてアメリカ大陸は、カメがその下で支えていると信じているんだ』と屈折した思い込みで、ミネアポリスの日々をすごしていました。

江端 :「加えて、(シ研)の奴等が、僕の泊まっているホテルの地区が危ないって言うし・・・」

嫁さん:「え!危ないの?」

江端 :「とは、僕には思えないんだけどね・・・。」

私はホテルのクオリティには、あまり頓着しないほうで、会場のホテルが予約できなかったので、旅行代理店に『安いところを適当に』と言っておいたら、食事付き一泊79ドルと言う破格のホテルを予約され、周りの人間を随分心配させました(大体150ドル程度)。

学生の頃、私は一泊10ドルと言うドミトリーにあたりまえのように泊まっていたので、その辺の感覚が麻痺しているのかも知れません。

後輩の、T君に言わしめて曰く、『スカイウォークが繋がっていない、駐車場に派手な落書きがあった』ことが、その危険であることの根拠らしいです。

江端:『でもね、僕が泊まってきたところって、安全フェーズが2段階ほど違うよ。』

T君 :『どういうところですか?』

江端:『中国のウイグル自治区内の安宿とか、ネパールのコンクリートがむき出しになった宿とか、インドのニューデリーの宿では、目の前に物乞いの人たちが一ダースぐらい・・・』

T君は、絶句していたように見えましたが、付け加えて言いました。

T君 :『しかし、江端さん。決定的に違うことが一つあります。』

江端:『何?』

T君 :『拳銃』

そりゃもっともだ、と思った私は、それからIETF会場のミネアポリスのヒルトンホテルから、ウエスタンダウンタウンと言うモーテル系のホテルまで、走って帰ることにしました。

江端:「ところがねえ、慣れない街だからねえ、道を間違えてどこを走っているか分からなくなって・・・と言って、信号で泊まると恐いから、青信号の方を選んで走るから、さらに道がわからなくなってきて、そうして、昨夜はミネアポリスの街中を、ぐるぐる走りまわっている変な日本人が一人いたわけだよ。」

15時間の時差のある電話の向こうで、嫁さんは大爆笑していました。

そしてこの話は、「夜のミネアポリスを走り回る日本人」と言うエピソードで、そのIETFの期間中、ことある毎に語られることになります。

-----

さて、ひどく落ち込んでいた私は、嫁さんの電話で少し元気をとり戻し、今一度IETFを眺め直す余裕が出てきました。

午前を回っていましたが、私はベッドの上にひっくりかえって考え始めました。

まず第一に、IETFは本当にオープンなのか?

あのスピードの英語を日本に取得できる人間がどれだけいるのか。どれだけの人間が、あの技術情報を母国に持ち帰れるのか。そもそもネイティブスピーカでない我々日本人が、あのミーティングに参加することができるの
か。

次に提案者、質問者の面々です。

提案者はまあ良いとして、質問者です。

みーんな、同じ顔。

同じメンツが、マイクの前に立ってぐるぐると順番待ちをしているだけです。オープンどころか、クローズなグループメンバによる芝居のように見えるのは、私の穿った見方でしょうか。

と、そこまで考えたとき、私は背筋がぞくりとするような寒気を感じました。

(これはやばい。相当にやばいぞ・・・)

私は基本的に、自分のことしか考えない利己主義者ですが、その私の利己を脅かすほどの恐ろしい現実が進行しつつあることに気がつきました。

これからも情報通信技術が、ある一国で閉じる訳がありませんから、この技術の検討が国際共通語である英語で行われることは間違いありません。

そして、インターネットの世界に関しては、当面IETFが支配的な地位を占めていくでしょう。

IETFは、いかなる形でも強制力を持ってはいませんが、インターネット標準の決定機関です。インターネットに関わる全てのベンダ、サービスプロバイダ、ユーザは、このIETFの決定事項に従って動いていくしかありません。

すなわち、IETFに対して提案活動を行うと言う事は、すなわちその提案の内容が世間に公表される前に、すでに手が打てるわけです。

例を挙げましょう。

例えば、私があるマルチメディア帯域制御方式を実現する通信ソフトウェアを開発したとして、その内容をIETFに提案し、これが受理されたと仮定しましょう。他の会社は、この通信方式を実装するために、私が提案したドラフトを読みながら、製品を作らなければなりませんが、私はすでにその実装が終わったソフトウェアを開発し終えているのです。

この開発機関がどの程度になるにしろ、すでに私は、他社に対して開発期間分(数ヶ月以上)リードしている訳です。他社が開発を行っている間、私は営業活動を進めて、シェアを拡大させる事ができます。

つまり、イニシアティブが全てなのです。

提案ドラフトを読んでから製品化に着手しているようでは、シェアを取る事が出来ないのです。

逆に言えば、このようなIETFのような国際的標準機関でイニチアティブを取るためには、英語が必須なのです。しかしそれは、英語が単に読めることでも、しゃべれる事でも、理解できることでもありません。

「検討」し、「討論」でき、そして「論破」できることなのです。

しかるに、我が国の英語教育の水準は、間違いなく世界最低クラスです。

先進国と言われているアジアの国々のほとんどと比較して、TOEICの平均点が低い事は、意外に知られていませんが、私は色々なアジアの国を旅をしてきた経験から、感覚的にこの事実に気がついていました。だって、一応英語が使えれば、どの国のどの街のどんな所でも旅が出来たんですから。

-----

(21世紀も、欧米中心の文化に引きずられながら、我々は生きていかねばならないのか?)

パソコンの設定一つの為に、膨大な英文資料に翻弄されて過ごしている日々。

そして、ろくな特許のアイデアも出せず、まともなシステム構築すら出来ない技術者が、ただ英語が使いこなせると言う理由だけで、より優位な地位に立てる日本の技術者社会。

私は、娘の笑顔を思い出して、憤然とした思いに駆られました。

娘の世代も、欧米文化に追従する日々を生きねばならないのか?

私は最近、戦前の陸軍の関東軍のエリート軍人達が、日本語を基本とした大東亜共栄圏を作ろうとした気持ちが少し分かるような気がします。

軍事的にアジアを占領して、すべて日本語が通じるようにして、米国とヨーロッパ共同体に対抗しようとしたその行為は、もしかしたら英語がしゃべれないコンプレックスに起因していたのかもれない。

しかし、それでも、彼らは日本のシステム体系が世界で無視されることを予期し、それを恐れていたのです。イニシアティブをとれない国が、没落していくかないことを熟知していたのです。

日本がどうなるかは、私にとってどうでもよいですが、娘がどうなるかは、私にとって大問題です。

この欧米主義中心の世界観をどのように変えていけばよいのだろうか、と私は考え始めました。

その1 全世界侵略論

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

全世界を武力で制圧し、日本語を世界共通語として強制する。

しかし、公式に核非所有国を宣言している我が国が世界征服をするのに比べれば、太陽系以外の他の星系に移住可能な星を見つけて、日本国民全部が移住する方がはるかに簡単でしょう。

その2 大東亜共栄圏論

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

これは人口比率から言って、中国語しか選択はない。この中国語による大東亜共栄圏で欧米文化に対抗する。

しかし、日本人全部が中国語を勉強し直すくらいなら、こういう発想はそもそも出てくる訳がないので、もちろん却下である。

その3 英語教育再編論

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

文部省は、教育としての位置付けをやめ、教育カリキュラムから、英語教育を放棄する。一種の高級なプログラム言語の一つとして、通産省にその権限を移譲し、「情報処理技術カリキュラム」の一つとして組み込む。すなわち、文化としての英語を全面的に方向転換し、単なる通信プロトコルと捕らえ、その「技術」を教えるものと考える。これにより、偏向した欧米中心主義文化からの脱却を図る。

とは言え、どのようなカリキュラムがあろうと、現実的にその英語が使えなければ、意味がありません。

そこで、私は韓国の徴兵制(*1)にならい、英語技術の徴役制度の導入を提案します。

(*1)韓国では成人男子全員に兵役の義務がある(イスラエルでは女性も)。

さて、その懲役をどこでやるか、一番安いコストと言う点では、在日米軍あたりで兵役につかせてしまおうか、と言う乱暴な考えもあったのですが、何もアメリカの世界戦略構想に協力する必要はないし、第一、個人的に嫌。

ならば、どこかの英語圏の島を買って、そこに高校教育を終えた若者を、全て強制的に収監すると言うのはどうか。

当然、島の中には武装した教官がおり、日本語をしゃべったものに対しては、射殺を含む刑罰を施行する権限を有するものとする。期間は、最低2年。大学の前期教育を兼ねても良い。当然、日本語で記述された全ての書物は没収される・・・・・

程度のことはやらんと、本当にやばいんではないかと思い始めています。

要するに、私がIETFに出席して、ほとんどその任務を果たし得ず、そして、私と同じような立場に負い込まれるものが、今後も間違いなく大量に発生する、と言う事が言いたかったんです。

そして、日本はどんどんこれから国家としての国益を失っていくだろう、と。

-----

さあ、どうしましょう。

我々が、どこで育ち、そして生きてきても、名古屋弁や秋田弁などのようにどの地域の言葉も理解できるように、世界のどこにいても、どの言葉も理解できるようにならなければならない時代が来ています。

いや、正確に言えば、我々の前の世代は、すでに我々がその程度のことを実現してくれることを期待して、膨大とも言える時間と労力を我々の英語教育に注いでくれたと思うのです。

しかし、その教育のやり方が悪かったのか、あるいは我々の努力が足りなかったのか分かりませんが、我々はついに、彼らのその熱い想いに応える事はできなかったようです。

それはIETFで発言した日本人を、ついに一人も発見できなかった事からも明らかだと思います。

さあ、どうしましょう。

私たちは、次の世代達に、『どう世界とつきあって生きて行け』と言うことができるでしょうか?

(本文章は、全文を掲載し内容を一切変更せず著者を明記する限りにおいて、転載して頂いて構いません。)

Next:江端さんのひとりごと
「IETF惨敗記2(白夜のノルウェー編)」

 

未分類

韓国は、今、戒厳令に揺れています。

(1)戒厳令が国会で否決されるという憲法の規定が存在する理由が分かりません。戒厳令とは国会の停止を含んでいる思っていたので違和感を感じています。

(2)今回の韓国の事件で、国会議員が軍隊に邪魔されることなく国会議事堂に入れたことにも不思議に思っております。


これらについて教えて下さい。

----- ChatGPTここから -----

韓国の憲法第77条第5項は、国会が在籍議員の過半数の賛成で戒厳の解除を要求した場合、大統領はこれを解除しなければならないと定めています。

この規定は、戒厳令の濫用を防ぎ、民主的統制を維持するために設けられています。戒厳令は非常時において行政・司法機能を軍が代行する措置であり、権力の集中を伴うため、国会がその適切性を監視し、必要に応じて解除を求める権限を持つことが重要とされています。

戒厳令下でも、国会は解散されず、議員の活動も保障されています。憲法は、戒厳令下においても国会議員の逮捕を認めていません。

そのため、国会議員は軍の妨害を受けることなく議事堂に入る権利を有しています。今回の韓国の事例では、軍が国会議事堂への侵入を試みましたが、議員や職員がこれを阻止し、最終的に戒厳令の解除を求める決議案が可決されました。

このように、憲法上の規定により、国会の機能と議員の活動は戒厳令下でも維持されることが保障されています。

------ ChatGPTここまで -----

"軍が国会議事堂への侵入を試みましたが、議員や職員がこれを阻止し" って、何?

普通、逆だろう、これ。

驚くほど民主主義的な「戒厳令」の憲法の規定に、正直驚いています。

シュリ」とか「シルミド」とか「KT」のイメージを間に受け過ぎたのかもしれません。

日本の戒厳令の、"5.15"とか"2.26"とかとセットで記憶していることも原因かなぁ。

私なら ―― 国会の封鎖、放送局、警察庁、裁判所の占拠、野党党首を含めた国会議員の強制逮捕、あと閣僚の身柄拘束もします 。デモ隊への発砲もためらいません。で、<北>が休戦協定を破棄して、<南>の人民の開放を口実に、南下し首都ソウルを占領。在韓米軍の出動の隙を狙って、そのまま台湾紛争が勃発、と ―― まあ、それくらいのことを考えていたんですけどね(当然、日本も巻き込まれる(台湾紛争と、半島からの難民問題で))。

ともあれ、私のイメージしてきた「戒厳令」とは、全然違ったようです。

運が良かったのか、私の想像力が豊かすぎたのかは、まだ、判断できていませんが。

未分類

q0713がイオン金沢シーサイド店である場合のq0707とq0714の値を0から24の値の数で表示させるSQL文を作成してcsvファイルで保存して下さい。添付したようなグラフを作成するためです。

 

CSVファイルへの保存(psql の場合)

結果をローカルにCSVファイルとして保存するには、以下のコマンドを使用します(1行で記載sにないと、\copy: parse error at end of lineと言われる)

\copy (WITH 時刻範囲 AS (SELECT generate_series(0, 24) AS 時刻) SELECT 時刻範囲.時刻, COALESCE(SUM(CASE WHEN e.q0707 = 時刻範囲.時刻 THEN 1 ELSE 0 END), 0) AS 出発時刻カウント, COALESCE(SUM(CASE WHEN e.q0714 = 時刻範囲.時刻 THEN 1 ELSE 0 END), 0) AS 到着時刻カウント FROM 時刻範囲 LEFT JOIN master_e AS e ON e.q0713 = '京急ストア富岡店' AND e.q0707 BETWEEN 0 AND 24 AND e.q0714 BETWEEN 0 AND 24 GROUP BY 時刻範囲.時刻 ORDER BY 時刻範囲.時刻) TO 'G:/home/ebata/output.csv' WITH CSV HEADER;

イント

  1. Windows環境では絶対パスを使用:
    • G:/home/ebata/output.csv の形式で絶対パスを指定してください。
  2. クエリ結果を手動で確認:
    • 上記SQLを実行後、クエリ結果を確認し、正確なデータが得られることを確認してください。
  3. グラフ作成:
    • このデータを元にPythonやExcelで出発時刻・到着時刻の折れ線グラフを作成できます。

未分類

select household, q0301 from master_b where household like 'P%'; で、(Pで始まる)ユーザ番号と、ユーザの年齢が出てきます。 select household, q0707,q0714 from master_e; で、(Pで始まる)ユーザ番号と、出発時刻(0-24)、と到着時刻(0-24)が出てきます。 この2つのSQL文をくみあわせて、0-9歳、10ー19歳、 ..... 90-99歳に分類して、それぞれの年齢分類毎の出発時刻と到着時刻を算出するSQL文を作って下さい。

以下は、出発時刻 (q0707) と到着時刻 (q0714) の 標準偏差 を算出する SQL 文です。標準偏差は STDDEV 関数を使用して計算します。

SELECT 
    CASE 
        WHEN b.q0301 BETWEEN 0 AND 9 THEN '0-9歳'
        WHEN b.q0301 BETWEEN 10 AND 19 THEN '10-19歳'
        WHEN b.q0301 BETWEEN 20 AND 29 THEN '20-29歳'
        WHEN b.q0301 BETWEEN 30 AND 39 THEN '30-39歳'
        WHEN b.q0301 BETWEEN 40 AND 49 THEN '40-49歳'
        WHEN b.q0301 BETWEEN 50 AND 59 THEN '50-59歳'
        WHEN b.q0301 BETWEEN 60 AND 69 THEN '60-69歳'
        WHEN b.q0301 BETWEEN 70 AND 79 THEN '70-79歳'
        WHEN b.q0301 BETWEEN 80 AND 89 THEN '80-89歳'
        WHEN b.q0301 BETWEEN 90 AND 99 THEN '90-99歳'
        ELSE 'その他'
    END AS 年齢分類,
    AVG(e.q0707) AS 平均出発時刻,
    STDDEV(e.q0707) AS 出発時刻の標準偏差,
    AVG(e.q0714) AS 平均到着時刻,
    STDDEV(e.q0714) AS 到着時刻の標準偏差
FROM 
    master_b AS b
JOIN 
    master_e AS e
ON 
    b.household = e.household
WHERE 
    b.household LIKE 'P%'
    AND e.q0707 <> 999
    AND e.q0714 <> 999
GROUP BY 
    年齢分類
ORDER BY 
    年齢分類;

修正点:

  1. 標準偏差の計算:
    • STDDEV(e.q0707) AS 出発時刻の標準偏差
    • STDDEV(e.q0714) AS 到着時刻の標準偏差
    • 標準偏差を計算するために、STDDEV 関数を使用。
  2. 出力項目:
    • 年齢分類
    • 平均出発時刻
    • 出発時刻の標準偏差
    • 平均到着時刻
    • 到着時刻の標準偏差

出力例:

pj20005=# \e
 年齢分類 |    平均出発時刻     | 出発時刻の標準偏差 |    平均到着時刻     | 到着時刻の標準偏差
----------+---------------------+--------------------+---------------------+--------------------
 0-9歳    |  8.7364864864864865 | 2.0264293870576348 | 16.6959459459459459 | 2.7902629433767539
 10-19歳  |  8.6916488222698073 | 2.3823202999576382 | 17.5610278372591006 | 3.1068884868890622
 20-29歳  |  8.9774436090225564 | 2.7632636644010746 | 17.8020050125313283 | 3.7370800926049844
 30-39歳  |  9.0335731414868106 | 2.3690328974486025 | 17.1534772182254197 | 2.9668749279360904
 40-49歳  |  9.0164835164835165 | 2.4084051553191729 | 16.9326923076923077 | 3.3338216665822259
 50-59歳  |  9.1076555023923445 | 2.7224076287670418 | 17.6854066985645933 | 3.2784704658907816
 60-69歳  |  9.7626321974148061 | 2.8109242893099341 | 16.5687426556991774 | 3.1044389062381429
 70-79歳  | 10.4559659090909091 | 2.5466884006062182 | 15.2897727272727273 | 3.0459374095847468
 80-89歳  | 10.4758454106280193 | 2.4712413371273877 | 15.1835748792270531 | 2.9226415927228037
 90-99歳  | 10.0217391304347826 | 2.7260261951824853 | 15.1086956521739130 | 3.3890099517874430
 その他   |  8.9574468085106383 | 2.7431827273506346 | 16.6170212765957447 | 3.1146769555086844

未分類

「売国機関」に登場する、チュファルテク合同共和国、クライス連邦、ガルダリケ王国とは、何時の時代のどの国を題材にしていると考えられますか?

「売国機関」に登場する架空の国家であるチュファルテク合同共和国クライス連邦ガルダリケ王国は、具体的な時代や実在の国を直接的にモデルにしているわけではありませんが、その設定や描写は、いくつかの歴史的事象や国々を連想させる要素があります。

  1. チュファルテク合同共和国
    • 名前や政治体制から、社会主義や共産主義体制の国を彷彿とさせます。特に冷戦期の東ヨーロッパ諸国や旧ソビエト連邦をモデルとしている可能性があります。
    • 「合同共和国」という名称は、ソビエト連邦(Union of Soviet Socialist Republics)やユーゴスラビア(Socialist Federal Republic of Yugoslavia)のような多民族国家を想起させます。
  2. クライス連邦
    • クライス(Kreis)はドイツ語で「地区」や「郡」を意味します。この名称からは、ドイツやオーストリアの連邦制国家の特徴が反映されているように見えます。
    • 作中の設定が連邦制であることから、現在のドイツ連邦共和国や、かつての神聖ローマ帝国のような緩やかな連邦制国家が着想源となっている可能性があります。
  3. ガルダリケ王国
    • ガルダリケ(Gardarike)は古ノルド語で「都市国家の国」を意味し、歴史的には中世スカンジナビア人がルーシ(現代のロシアやウクライナの起源となる地域)を指した言葉です。
    • この名前から、北欧や中世ヨーロッパをモデルにしている可能性が高いです。また、「王国」という形態からは、伝統的な君主制国家であるスウェーデンやデンマークを連想させます。

これらの国々は、特定の時代や国を直接的に題材にしているというよりも、さまざまな歴史的背景や地政学的状況を参考にした架空の国として設定されているようです。それぞれが抱える政治的、社会的、文化的な問題を描くことで、現実の国際政治や歴史的なテーマに対する寓意や批評を提供していると考えられます。

世界地図の南北をひっくり返してあてはめてみると、ガルダリケ王国=ドイツ・フランス チュファルテク合同共和国=ポーランド、 クライス連邦=バルト3国+ソ連 のように見えますが、いかがでしょうか?

ご指摘の通り、地図をひっくり返して見ると、以下のように現実の国々と対応させて考えることができます。

  1. ガルダリケ王国 = ドイツ・フランス
    • ガルダリケ王国は地図の西側に位置しており、現実の地図を上下逆にすると、ドイツやフランスがその位置に相当します。
    • 「王国」という形態から、歴史的に君主制が存在したこれらの地域をモデルとしている可能性が高いです。
  2. チュファルテク合同共和国 = ポーランド
    • 地図中央のチュファルテク合同共和国は、位置的にポーランドや東欧諸国を連想させます。
    • 「合同共和国」という名称は、ソビエト連邦やユーゴスラビアのような多民族国家の連邦体制を意識した設定であると考えられます。
  3. クライス連邦 = バルト三国 + ソ連
    • クライス連邦は地図の東側に位置しており、バルト三国(エストニア、ラトビア、リトアニア)や旧ソ連をモデルとしていると考えられます。
    • 「クライス」というドイツ語圏の名称が付いていることから、東ヨーロッパの国々を抽象化して描かれた可能性があります。

これらの対応は、地理的な配置だけでなく、各国の名称や設定から見ても妥当であるように思われます。コミックの設定としては、現実の歴史や地理を元にしながら、架空の要素を加えているように感じます。こうした背景設定を踏まえると、物語の中で描かれる政治的・文化的な対立や共存のテーマがより深く理解できるかもしれません。

未分類

ご相談があります。

1,A1,30,33.59543503,130.3980676
2,A1,30,33.59525629,130.3993336
3,A1,30,33.59323656,130.3984967
4,A1,30,33.59261097,130.3963509
5,A1,30,33.59212837,130.3954712
6,A1,30,33.59243223,130.3971234
7,A1,30,733.5927897,130.3996554
1,A2,60,33.59398255,130.3959787
2,A2,60,33.59364294,130.3985965
3,A2,60,33.59328547,130.3976095
4,A2,60,33.59278499,130.3969657
5,A2,60,33.59265988,130.3953564
6,A2,60,33.59285649,130.4020941
1,A3,120,33.59401761,130.3947008
2,A3,120,33.59389249,130.3972542
3,A3,120,33.5928558,130.3972972
4,A3,120,33.5920336,130.3982198
5,A3,120,33.59205147,130.3995288
6,A3,120,33.5924447,130.3997862
7,A3,120,33.59274856,130.4001081

のように記載されたcsvファイルあります。 A1はカフェの位置座標、A2は飲食店の位置座標、A3は、居酒屋の位置座標、この他、B1からH2までの種類の店舗の位置座標のデータがあります。

一方現在、PostGISを使ったマルチエージェントシミュレーション(MAS)を作成しております。このMASは、帰路の駅に向う途中に気になる店舗があったら、その店舗に立ち因る、という動きをさせたいと思っています。

このMASのシミュレータはすでに完成しており、エージェントも稼動しておりますが、上記の「立ち寄り」のアルゴリズムはまだ実装しておりません。 各エージェントは、エージェント単位に嗜好を持っており、例えば、帰路の途中にカフェ(A1)を、自分の位置から半径15メートル以内に見つけらたら、そこに立ち寄らせたいと思っています。

でご相談なのですが、このような実装を行うに際して、上記のCSVファイルは、どのように利用するのが良いでしょうか。
(1)CSVファイルとして全てを纒めておき、シミュレータ開始前に全部をメモリ上に格納しておき、A1(カフェ)とエージェントの距離が15メートル以内にはいったか否かを随時計算する
(2)CSVファイルをPostgresSQLのDBに格納しておき、上記と同じ処理を行う。
(3)その他

観点は、「計算時間または計算負荷ができるだけ軽量に行える」ということになります。エージェントは1000~10000作って動かすので、時間がかかるのは困るのです。本件についてアドバイスを頂けますようお願いします。

計算負荷を軽減し、効率的にエージェントの「立ち寄り」アルゴリズムを実装するためには、以下のアプローチが考えられます。

アプローチの比較

(1) CSVファイルをすべてメモリにロードして距離計算

メリット:

  • 実装がシンプル。
  • 外部データベースに依存しないため、環境構築が容易。

デメリット:

  • メモリ消費が大きい。特に店舗データが増えると、メモリ上で全てを保持するのが困難になる場合がある。
  • エージェントが増えた場合、すべての店舗との距離を計算する処理が重くなる可能性が高い。

適用場面:

  • 店舗データが少ない場合や、エージェント数が少ない場合に有効。

(2) PostgreSQL + PostGIS を利用する

メリット:

  • PostGIS の空間インデックス機能を使うことで、店舗検索の計算負荷が大幅に軽減される。
    • ST_DWithin を用いることで、指定距離内の店舗を効率よく取得可能。
  • データの永続性が高く、今後店舗データを増やしたり更新する場合の対応が容易。
  • 複雑なクエリが実行可能で、たとえばカテゴリ別の店舗をエージェントの嗜好に基づいてフィルタリングできる。

デメリット:

  • 初期設定やクエリのチューニングに多少の手間がかかる。
  • 外部データベースへのアクセスによる若干のオーバーヘッド。

適用場面:

  • 店舗データやエージェント数が多い場合。
  • データの拡張性やメンテナンス性を重視する場合。

(3) その他の選択肢: ハイブリッド方式

方法:

  • CSVデータをシミュレータ起動時にPostGISにロードし、シミュレーション中はPostGISを利用する。
  • シミュレーション後に、必要に応じて結果を再度CSVや他の形式にエクスポート。

メリット:

  • PostGISの性能を活用しつつ、データ管理はCSVベースでシンプルに保てる。
  • データがPostGISにあるため、他の分析ツールやダッシュボードにも容易に接続可能。

デメリット:

  • CSVのロード処理が必要。
  • PostGISの初期設定が求められる。

推奨アプローチ

(2) PostgreSQL + PostGIS の利用を推奨します。
以下の理由によります:

  1. 計算負荷の軽減: PostGISの空間インデックスを利用することで、エージェントと店舗の距離計算が効率化されます。
  2. 柔軟性: 店舗データが拡張されても問題なく対応可能。
  3. スケーラビリティ: エージェント数が増加しても処理時間を抑えることが可能。

実装例: PostGISでの距離計算

  1. CSVデータをPostGISに格納する
    CREATE TABLE stores ( id SERIAL PRIMARY KEY, type VARCHAR(10), preference INT, geom GEOMETRY(POINT, 4326) ); COPY stores(type, preference, geom) FROM 'path/to/stores.csv' WITH (FORMAT CSV, DELIMITER ',', HEADER TRUE, GEOMETRY 'POINT(longitude latitude)');

     

  2. 距離計算クエリ
    エージェントの位置 (33.595, 130.398) を例とします:

    SELECT id, type, preference, ST_Distance(geom, ST_MakePoint(130.398, 33.595)::geography) AS distance FROM stores WHERE ST_DWithin(geom::geography, ST_MakePoint(130.398, 33.595)::geography, 15);

     

  3. エージェントの嗜好を反映したクエリ
    SELECT id, type, preference, distance FROM ( SELECT id, type, preference, ST_Distance(geom, ST_MakePoint(130.398, 33.595)::geography) AS distance FROM stores WHERE type = 'A1' AND ST_DWithin(geom::geography, ST_MakePoint(130.398, 33.595)::geography, 15) ) sub WHERE preference = 1; -- エージェント嗜好がカフェ(A1)の場合

     


システム構成例

  1. PostGISをバックエンドとしたシミュレータ
    • シミュレーション開始時にPostGISへ接続。
    • 各エージェントが特定の地点を通過するたびに、クエリで立ち寄り候補店舗を取得。
  2. CSV管理を維持したデータフロー
    • 必要に応じてPostGISのデータをCSVにエクスポート。
    • シミュレータ結果を再度CSV形式で保存可能。

これらを基に、システム全体の効率化を図ることをお勧めします。

 

未分類

GStreamerにおけるkeep-listeningの機能は、主にSRTプロトコルの特性に基づいて設計されています。SRTはストリーミング中のネットワーク障害や接続の一時的な切断に対して高い耐障害性を持ち、再接続をプロトコルレベルでサポートしています。このため、GStreamerのSRTプラグインにはkeep-listeningオプションが実装されており、再接続処理が標準で可能となっています。

一方で、RTSPプロトコルは再接続に対する標準的なメカニズムを持っておらず、ストリーミング接続が切断された場合にはアプリケーション側で再接続処理を実装する必要があります。この理由は以下の通りです:

  1. プロトコルの設計思想の違い
    SRTはリアルタイムのビデオ伝送を想定し、途切れた接続を回復するための仕組み(例:パケットの再送や接続の再試行)が組み込まれています。一方、RTSPは主にコントロールプロトコルとして設計されており、接続の維持や再接続は仕様の範囲外です。
  2. GStreamerプラグインの実装方針
    GStreamerのRTSPプラグイン(rtspsrc)は、RTSPプロトコルの標準に忠実であり、アプリケーション側で自由に再接続ロジックを実装できるよう設計されています。このため、keep-listeningのようなオプションはRTSPプラグインに含まれていません。
  3. 運用環境での要件
    RTSPストリームの中断や切断が発生する状況は、ネットワーク環境やストリーミングサーバーの設定に依存するため、再接続の実装はユーザーごとの要件に基づいてカスタマイズされることが一般的です。

これらの理由から、RTSPでkeep-listeningを実現するには、アプリケーション側でエラー検知と再接続処理を実装する必要があります。これは、RTSPの特性に起因する設計上の制約であり、プロトコルやGStreamerプラグインの動作仕様によるものです。

------

今回の質問は、
『GStreamerでSRTはKeep-listening が使えるのですが、RTSPではkeep-listeningが使えません。この理由を上司に説明できる文章として作成して下さい』
としました。

我ながら、色々なChatGPTの姑息な使い方ができるようになってきたものだと、自分に感心しています。

未分類

Amazon Primeで「深夜食堂」を流しながらコーディングしています。

「深夜食堂」について調べてみたら、原作本については世界中で翻訳されているみたいですが、ドラマのリメイクも、中国、台湾、韓国でされていて、放映されているようです。

舞台などにもなっているそうです ―― で、情報のウラは取れなかったのですが「フランス」でリメイクだか、舞台だかが、あったとかなかったとか。

「フランス版深夜食堂」。うん、なんか、凄く見たい。

「ドイツ版深夜食堂」「ロシア版深夜食堂」はイメージできる。

北欧もイメージできる。

西欧であれば、スペイン版とかイタリア版とかも見てみたい。

イスラム圏の深夜食堂 ―― アルコール抜きバージョンも、可能なら見てみたいです。

未分類

select * from ways where name LIKE '%Dummy Railway Line%'; で選ばれたnode とwayを全部削除するにはどうしたら良いですか

ways テーブルにおける name 列の内容が '%Dummy Railway Line%' に一致する way と、それに関連する node を削除するには、以下の手順を実行します。ways テーブルと ways_vertices_pgr テーブルのリレーションを考慮した方法です。


手順

1. name 列が空か確認

name 列の値がすべて NULL または予期しない値かもしれません。以下のクエリで name 列の値を確認します。

SELECT DISTINCT name FROM ways WHERE name IS NOT NULL;

 


2. 削除対象の gid を確認

対象となる gid を取得します。もし name が NULL である場合には以下のように NULL 対応を追加してください。

SELECT gid FROM ways WHERE name LIKE '%Dummy Railway Line%' AND name IS NOT NULL;

 

もし上記クエリに結果がない場合、代わりに以下を確認します。

  • tag_idrule 列など他の列に対象の特徴があるか確認する。
  • 該当の値を直接確認する(例: IS NOT NULL を使う)。

3. 関連する node を特定

sourcetarget のノードが ways_vertices_pgr テーブルに存在する場合、それを削除します。

以下のクエリで関連する sourcetarget を確認します。

SELECT source, target FROM ways WHERE name LIKE '%Dummy Railway Line%' AND name IS NOT NULL;

 

これにより、削除対象のノード sourcetarget を特定できます。


4. 関連する ways_vertices_pgr の削除

取得した source および target に基づき、ways_vertices_pgr テーブルからノードを削除します。

DELETE FROM ways_vertices_pgr WHERE id IN ( SELECT source FROM ways WHERE name LIKE '%Dummy Railway Line%' AND name IS NOT NULL UNION SELECT target FROM ways WHERE name LIKE '%Dummy Railway Line%' AND name IS NOT NULL );

 


5. ways テーブルの削除

最後に ways テーブルから該当する行を削除します。

DELETE FROM ways WHERE name LIKE '%Dummy Railway Line%' AND name IS NOT NULL;

 


注意事項

  • バックアップを作成: データ削除は不可逆操作です。削除前にバックアップを必ず取得してください。
  • インデックスを活用: クエリ性能を向上させるため、適切なインデックスがあるか確認します(ways_pkey など)。
  • 依存関係: 外部キー制約があるため、削除の順序(ノード懼ウェイ)を守る必要があります。

これにより、name LIKE '%Dummy Railway Line%' に該当するデータを完全に削除できます。

この方法だと関連のあるnodeも消してしまうような気がします。wayだけ消せれば良いのです。

関連のある node を削除せずに、ways テーブルだけから特定の way を削除する場合、以下の手順で進めることができます。


方法

1. 削除対象の gid を確認

name に基づいて削除対象の waygid を確認します。

SELECT gid FROM ways WHERE name LIKE '%Dummy Railway Line%';

 


2. ways テーブルから対象の行を削除

特定した gid を使って ways テーブルから削除します。関連ノードは削除されません。

DELETE FROM ways WHERE name LIKE '%Dummy Railway Line%';

 


外部キー制約について

ways テーブルには外部キー制約が設定されていますが、ways テーブル自体からの削除では関連ノード(sourcetarget)を削除する必要はありません。外部キー制約は、通常、ノードが削除される際に ways のデータが参照整合性を保つようにするためのものです。

この方法であれば、ways_vertices_pgr テーブルやその他の関連ノードはそのまま維持されます。


確認

削除後にデータが正しく削除されたかを確認するには、以下を実行してください。

SELECT * FROM ways WHERE name LIKE '%Dummy Railway Line%';

 

結果が空であれば、対象の way が正しく削除されています。

コスト付き(hakata_ex_cost_db)とコストなし(hakata_no_dummy_db)の地図を2種類作れました。