2022/07,江端さんの技術メモ

ローカルネットワークにおける「オレオレ証明書」の作り方

"http: TLS handshake error from 192.168.0.22:59914: remote error: tls: unknown certificate"のエラーを、ようやく消せました

2023年1月9日追記
他のマシンで作った鍵は、動きません。"http: TLS handshake error from 127.0.0.1:51901: remote error: tls: unknown certificate"が出てきます→ 証明書の中にPCのホスト名称が記載されているようです。ですので、面倒ですが、別のマシンで動かす鍵は、別のマシンで再度作り直す必要があるようです。

2023年1月10日追記
クライアントとサーバを同じWindowBOXで実施している場合でも、"http: TLS handshake error"がでてきますので、下記の「5.4. Windowsの場合」を参考にして、「証明書のインストール」を実施して下さい。 

1. 目的

ローカルな実験環境で、Go言語で作ったサーバを動かし、Websocket用の鍵を作成し、TLS通信(https://)を実現します

2. 狙い

最近、ブラウザの"https"縛りがきつくて、ローカルのindex.htmlを叩くだけでは、画面が出てこなくなりました。特にスマホで顕著です。セキュリティ的には良いことなのかもしれませんが、研究用の開発をする人間(私)にとっては、『正直、面倒くさいなぁ』と思っています。

あくまでインターナルな環境での動作テストで使えれば足り、インターネットに出るつもりはありません。つまりIPアドレス、直接指定で実験できれば足りるのです(e.g. https://192.168.0.8:8080)

ところが問題があります。当然、インターネットに出ないことが必要なのです(というかインターネットに出たらアウト(始末書もの))。

  • 当然、公式の認証鍵はインターネットでの使用を前提としている上に、高価です。
  • Let's encrypt (https://letsencrypt.org/ja/) は、IPアドレスは使えないようです(ドメイン名のみ)。またクローズなローカルネットでは使えません。
  • ZeroSSL (https://zenn.dev/mattn/articles/b2c4c92c9116b1) は、インターネット上でオープンされているIPアドレスには使えますが、やはりクローズなローカルネットでは使えません。

という訳で、今回は、mkcert (https://qiita.com/k_kind/items/b87777efa3d29dcc4467) を使うことにしました。

このメモでは、mkcertを使って、インターネットに繋っていないローカルネットワークで、TLS通信を実現することを目的とするものです。

3. mkcertの入手方法と鍵の作りかた

https://github.com/FiloSottile/mkcert を覗いて、バイナリがダウンロードできそうことが分かりました。

もって、ここから、Windows10で使えそうなバイナリをダウンロードして下さい。

ダウンロードしたところから、直接叩いてみたら、最初に、

# mkcert -install

しろ、と言われます。

本当はmkcertにリネームした方が良いのでしょうが、面倒なので、そのまま

# mkcert-v1.4.1-windows-amd64.exe -install

を強行しました。

その後、"localhost","127.0.0.1","192.168.0.8"の3つのアドレスを追加することにしましたので、

# mkcert-v1.4.1-windows-amd64.exe localhost 127.0.0.1 192.168.0.8

としました。

この結果は以下の通りです。

>mkcert-v1.4.1-windows-amd64.exe localhost 127.0.0.1 192.168.0.8
Using the local CA at "C:\Users\ebata\AppData\Local\mkcert" 
Created a new certificate valid for the following names 
 - "localhost"
 - "127.0.0.1"
 - "192.168.0.8"

The certificate is at "./localhost+2.pem" and the key at "./localhost+2-key.pem" 

と入力すると、鍵が、カレントディレクトリにできるようです。

で、

  • "localhost+1-key.pem"を "key.pem"とリネームして、
  • "localhost+1.pem"を"cert.pem"とリネームして、

鍵を使うプログラム(main.go, server24.go)のあるディレクトリの全部に放り込んで下さい。

4. 鍵の使い方

4.1. Goプログラム(server24.go, main.go)の修正

4.1.1. http.ListenAndServeTLS()への置き換え

さらに、main.go, server24.goのhttp.ListenAndServe()を、以下のようなhttp.ListenAndServeTLS()に置き換えて下さい

    var addr = flag.String("addr", ":8080", "http service address")

    /*
        log.Fatal(http.ListenAndServe(*addr, nil)) // localhost:8080で起動をセット
    */

    var httpErr error
    if _, err := os.Stat("./cert.pem"); err == nil {
        fmt.Println("file ", "cert.crt found switching to https")
        if httpErr = http.ListenAndServeTLS(*addr, "./cert.pem", "./key.pem", nil); httpErr != nil {
            log.Fatal("The process exited with https error: ", httpErr.Error())
        }
    } else {
        httpErr = http.ListenAndServe(*addr, nil)
        if httpErr != nil {
            log.Fatal("The process exited with http error: ", httpErr.Error())
        }
    }

4.1.2. アドレスの修正

  • "localhost"の記載を、外向きのipアドレス(192.168.0.8)に書き換えて下さい。

4.2. index.htmlの修正

  • "localhost"の記載を、外向きのipアドレス(192.168.0.8)に書き換えて下さい。

5. スマホ側への鍵の設定方法

スマホ側は、当然に、"192.168.0.8"などというあやしげなサーバを信じる訳がないので、それを信じさせる処理を行う必要があります。

これをスマホに信じさせるには、ルート証明書の作成が必要となりますが、これはすでに出来ています。

5.1. ルート証明書の場所

# mkcert-v1.4.1-windows-amd64.exe -CAROOT

で、rootCA-key.pem rootCA.pem の場所が分かります。

("key.pem"、"cert.pem"は、使わないので注意して下さい(それに気がつかずにエラい目に遭いました))

C:\Users\ebata\Downloads>mkcert-v1.4.1-windows-amd64.exe -CAROOT
C:\Users\ebata\AppData\Local\mkcert

C:\Users\ebata\Downloads>cd C:\Users\ebata\AppData\Local\mkcert

C:\Users\ebata\AppData\Local\mkcert>ls
rootCA-key.pem  rootCA.pem

5.2. iPad/iPhoneの場合

  1. スマホにrootCA.pemをメールで送り込みます。ただし、iPad/iPhoneの場合、gmailメーラからではrootCA.pemを直接インストールできないので、safariから、gmail.comにログインして、メーラーを出して、そこからrootCA.pemを叩いて取り出して下さい。
  2. 次に、「設定」をクリックすると「プロファイルがダウンロード済み」というメッセージが出てくるので、そこをクリックして、「インストール」を押して下さい(ここでしつこく「パスコードの入力」を要求されますが、くじけずに何度でも入力して下さい)
    1.ダウンロードが出来たら、[設定]→ [プロファイルがダウンロード済み]を選択して下さい。

あとは、インストールボタンを押し続けて、インストールが完了して下さい。

5.2.1. ルート証明書を信頼する

  1. [設定] → [一般] → [情報] → [証明書信頼設定] → ルート証明書を全面的に信頼するの項目で、インストールした証明書をONにして下さい。

  1. [設定] → [プロファイル]でインストールしたプロファイルを選択するとルート証明書を確認できます。

5.3. Andoroidの場合

5.3.1. ルート証明書のインストール

  1. rootCA.pem を、rootCA.cerにリネームして、スマホにrootCA.cerをメールで送り込みます。
  2. メーラからrootCA.cerをクリックすれば、インストールされます(ことがあります)。

あるいは、

  1. ルート証明書ファイルを端末の内部ストレージまたはSDカードのルートディレクトリに配置します。
  2. ストレージからのインストールまたはSDカードからのインストールを選択します。
    • ストレージからインストールする場合:
      [設定]−[ユーザー設定]−[セキュリティ]−[認証情報ストレージ]−[ストレージからのインストール]
    • SDカードからインストールする場合:
      [設定]−[ユーザー設定]−[セキュリティ]−[認証情報ストレージ]−[SDカードからのインストール]
  3. 証明書に名称を設定し、[OK]ボタンをタップして、インストールが完了します。

最後に、

  1. 証明書がインストールされたか確認します。[設定]−[ユーザー設定]−[セキュリティ]−[認証情報ストレージ]−[信頼できる認証情報]の[ユーザー]タブで確認できます(ただし、私はこのメニューは確認できませんでした)

5.4. Windowsの場合

Windowsがスマホになることはないと思いますが、リモートの端末になることはあるので、記載しておきます。

  1. rootCA.pemを、rootCA.cerにリネームして、Windowsに送り込みます。
  2. rootCA.cerを右クリックして、「証明書のインストール」を選びます。
  3. 「証明書をすべて次のストアに配置する(P)」のラジオボタンをクリックし、「参照」ボタンをクリックします。
    1.「使用する証明書ストアを選択してください(C)」の画面で、「信頼されたルート証明機関」を選択します。

  1. 先ほどの画面に戻るので「次へ」ボタンを押下し、さらに「完了」ボタンを押下して下さい。正しくインポートされました。」と表示されればインストール成功です。

6. 結果

上記の処理を行うことで、iPhone,iPad,Android,WindowsBoxからのアクセスを行っても、サーバのコンソールから、

http: TLS handshake error from 192.168.0.22:59914: remote error: tls: unknown certificate
http: TLS handshake error from 192.168.0.22:59920: remote error: tls: unknown certificate
http: TLS handshake error from 192.168.0.22:59922: remote error: tls: unknown certificate

が出てこなくなり、ローカルネットでのセキュアなWebSocket通信が実現できる目処が立ちました。

以上

2023,江端さんの忘備録

先週の金曜日、小田急で人身事故があり、講義に遅刻しました。

Last Friday, I was late for a lecture due to a personal injury accident on the Odakyu train.

1時間近く余裕を持って出発したのですが、私を閉じ込めたままで電車が止ってしまっては、どうしようもありません。

I left with almost an hour to spare, but there was nothing I could do while the train stopped with me trapped inside.

私、鉄道の人身事故については、普通の人よりも理解していると自負しています。

I am proud to say that I understand personal injury on the railroad.

 

 

が、―― やっぱり、腹は立ちます。

But - I'm still angry

今でも、

Even now,

『人身事故の責任は、―― 生死を問わず ―― 人身事故を発生させた当事者にあるに決まっとろうが』

"The responsibility for any personal injury, dead or alive, lies with the person who caused it"

と思っており、鉄道会社は責任はないと思います ―― ちゃんと、国土交通省の「ホームドア設置」の指導に対応していれば、ですが。

I think no responsibility of train companies, if only they are properly compliant with the MLIT's guidance on the installation of platform doors.

-----

私は、人身事故発生後の運行の回復予測が「死ぬほど」難しいことを知っています。

I know that it is "deathly" difficult to predict the recovery of operations after a personal injury event.

ならば、リアルタイムの列車の位置情報を、CUI(コマンドベースインターフェース)で構わないので、公開して貰えればいいのに、と思っています。

Even so, I would like them to open real-time train location information published in a CUI (command-based interface) if possible.

GPS情報が無理なら、閉塞区間の情報か、駅待機情報で構いません。

If GPS information is not possible, closed section information or station standby information is acceptable.

鉄道会社に『Webで公開しろ』とか、『アプリを作れ』とか言いません ―― それは、民間(私を含む)に丸投げしてもらって結構です。

I will not tell the railroad companies to 'publish on the Web' or 'make an app' -- that can be left entirely to the private sector (including me).

データさえ公開して貰えれば、交通工学専攻の学生たちが、ほっといても、勝手にアプリを作り出しますよ。

As long as the data is made available to the public, traffic engineering students will create applications on their own, even if they are left alone.

それについては、賭けてもいいです。

You can bet on that.

そのアプリで、彼らが卒業論文を書ければ、Win-Winです。

If they can use that application to write their thesis, it's a win-win.

CUIであれ何であれ、そこにデータがあれば、何かを解析するように訓練されているんです、私たちは。

If there is data there, whether it is CUI or whatever, we are trained to parse something, we are trained to parse something.

-----

まあ、上記の話を纏めると、

Well, to summarize the above story,

『私(江端)のためだけに、人身事故発生後のリアルタイムの列車の位置情報を開示しろ』

'For my (Ebata's) sake alone, disclose the real-time location of the train after the personal injury accident'

と言っているように聞こえなくもありません。

It sounds as if I am saying that.

それでも、鉄道会社が、うかつにダイヤの回復予測時間を口にできないなら ――

Still, if a train company can't carelessly say a projected timetable recovery time--

人身事故発生から収束までのリアルタイムのデータ"だけ"開示して、あとは民間の会社(あるいは学生などに)丸投げして、責任回避を図ればよいのです。

They should only disclose "real-time" data from the time of the accident to the time the accident is resolved, and then throw the rest to private companies (or students, etc.) to avoid their responsibility.

2023,江端さんの忘備録

私は、『自分の名前(×ハンドル名)と出所(メールアドレス等)を明示しない人の意見は聞かない』ことにしています。

I will not 'listen to the opinions of those who do not specify their name (x handle name) and source (email address, etc.).

それ故、WebサイトもYouTubeも、コメント欄は、すべてOFF(書き込み不可)としています。

Hence, all comment sections, both on the website and on YouTube, are turned off (no writing).

-----

ところが、最近、Wordpressの管理画面(×ユーザ画面)に、こんなのが出てきて、うっとうしいことこの上もありません。

Recently, however, I have been seeing something like this on the WordPress admin (not user) screen, and it is beyond annoying.

スパムのようなものだろう、と思っていますが、このような画面が出てくるのかが分かりません。

I thought it must be some kind of spam, but I don't understand how this kind of screen comes up.

そもそも、私のページには、コメント欄がありません。

To begin with, my page does not have a comments section.

『どっかに、バックドアを仕込まれたかもしれない』と思うと、気持ち悪くなりました。

It made me sick to think, 'Somewhere, someone might have planted a back door'.

-----

で、ちょっと調べてみたら、「投稿の編集画面」にこんなのがありました。

So I did a little digging and found this in the "Edit Post" screen.

 

即、チェックを外しておきました。

I immediately unchecked the box.

油断大敵です。

It is a tricky business.

2023,江端さんの忘備録

今後、鉄道に置き換えわっていく公共交通がBRT(Bus Rapid Transit)です。

BRTs (Bus Rapid Transit) is a public transportation system that will replace railroads in the future.

途上国でも積極的に導入されているようです。

BRTs seem to be actively being introduced in developing countries.

鉄道を飛ばして、いきなりBRT導入がされているようです。

It seems that BRT is being introduced suddenly, skipping the railroads.

-----

会社の同僚に聞いた話なのですが「地元の鉄道が廃線になったけど、BRTの導入で逆に移動が快適になった」という話を聞きました。

I heard from a colleague at work that "the local railroad line was closed down, but the introduction of BRT has conversely made travel more comfortable.

バス以外に入ってこれない専用レーンで(あるいは、路線の上にアスファルトを引いて専用道路にする)バスだけを走らせる ―― それは、もう鉄道と同じです。

Running only buses in a dedicated lane that only buses can enter (or asphalt over the route to make it a dedicated road) -- it's already the same as a railroad.

なにしろ安い。

After all, they are cheap.

構築コストはもちろんですが、メンテコストが恐しく安いし、輸送効率の費用対効果がケタ違いに優れています。

The cost of construction, of course, but maintenance costs are horrendously low, and the cost-effectiveness of transportation efficiency is outstanding.

突出しているのは、人件費です。バス停には駅員は不要です。

What sticks out is the cost of labor. Bus stops do not need station staff.

鉄道を存続させたい人の心理には、鉄道ではなく「○○駅」という「名前」が重要だ、という話を聞いたことがあります。

I have heard that the "name" of "XX station" is important to the mind of those who want to keep the railroad alive, not the railroad.

ならば、BRTの停車場を「駅舎」にして、それを「駅」を称呼すればいい、と思います。

Then I think we should make the BRT stop a "station house" and call it a "station".

-----

『それでも鉄道が必要』というフレーズでググってみました。

I googled the phrase "still need a railroad."

ふむ、「コンテナ車両の有効性」が語られていますが、BRTの路線にコンテナを搭載したトラックを走らせれば足りるんじゃない?

Hmmm, "effectiveness of container vehicles" is mentioned, but wouldn't it be enough to run trucks with containers on BRT routes?

コンテナの移動については、車両ごとトラックに牽引させれば、一般道まで走れるという特典まで付いてきます。

About moving containers, they offers the privilege of having the entire vehicle towed by a truck, moreover , which can then be driven on public roads.

はっきりいって、大量の人間を一気に運ぶニーズのない場所では、電車よりBRTの方が、圧倒的に美味しいです。

Clearly, in places where there is no need to transport large numbers of people at once, BRT is far more palatable than trains.

観光地などでは、観光客の需要を満たす問題もあると思いますが、それは鉄道であっても同じ問題に直面するので、争点にはなりません。

In tourist areas, etc., there will be problems meeting the demand of tourists, but that is not a point of contention, since the same problems would be faced by railroads.

逆に、観光シーズンには、BRTの車両数を増やす、あるいは、例外的に一般バスを借り入れてダイヤに組み込むなど、鉄道よりも柔軟性の高い運用ができると思います。

Conversely, during the tourist season, the BRT could operate with greater flexibility than rail, such as increasing the number of BRT vehicles or, on an exceptional basis, borrowing regular buses and incorporating them into the timetable.

CO2排出については、程なく電気自動車の実用化でケリがつくでしょう。

CO2 emissions will soon be settled with the commercialization of electric vehicles.

-----

とは言え、私は、この分野については門外漢です。

I am, however, an amateur in this field.

私の見落していることが沢山あると思いますので、教えて頂ければ嬉しいです。

I am sure there are many things I am missing, and I would be happy to learn about them.

但し、『利権』とか『ブランド』とか『コネクション』とか『票田』とか、そういう話は不要です。

However, you don't need to talk about "interests," "brands," "connections," "vote banks," and the like.

純粋に、技術的、経済的な話に限定でお願いします。

Please limit our discussion to purely technical and economic matters.

2023,江端さんの忘備録

「数学を18歳まで必修にします」――イギリスのスナク首相が年頭の演説で新たな教育方針を示しました。

"Mathematics will be compulsory until the age of 18"--British Prime Minister Rishi Sunak laid out his new education policy in his New Year's address.

スナク首相は、『現在、16歳から19歳のうち半数しか数学を学んでいないとして「データがあらゆるところにあり、統計があらゆる仕事を支える世界」で数学は重要だ』と訴えました。

The Prime Minister Rishi Sunak stressed that "mathematics is important in 'a world where data is everywhere and statistics support every job', however 'only half of 16- to 19-year-olds are currently learning mathematics'.

私もそう思います。

I agree with him.

しかし、現在の日本の数学教育で、同じ施策を強行したら「若者の苦痛の時間が長くなるだけ」だろう、とも思っています。

However, I also believe that if the same measures are enforced in the current Japanese mathematics education, "it will only prolong the time of suffering for young people.

-----

今の数学教育に必要なことは、『一生使い倒せる、"おいしい道具"としての数学』だと思うのです。

江端:「うん。だから数学の授業で『投資セミナーの例題を使って、等比級数と指数関数を教えれば、一石二鳥だ』と、昔から、ずっと言い続けているんだけど ―― 文部科学省って、バカなの?」

I believe that what is needed in mathematics education today is "mathematics as a 'tasty tool' that can be used throughout one's life.

『一生使い倒せる、"おいしい道具"としての英語』に比べれば、数学ははるかに『使用頻度の高い道具』だと思います。

Compared to English, mathematics is a much more frequently used tool, I think.

2023,江端さんの忘備録

『今のパーソナルコンピュータ(PC)の性能は、20年前のスーパーコンピュータ(スパコン)の性能と同じである』

"The performance of a personal computer (PC) today is the same as that of a supercomputer 20 years ago"

という話を聞いて、ちょっと計算してみました。

After hearing the story, I did some calculations.

- 2000年以降、PCとスパコンの性能差は、ざっくり1万倍になる

(引用先を失念しました。どなたか教えて頂ければ、記載いたします)

- After 2000, the performance difference between PCs and supercomputers have been roughly 10,000 times

- ムーアの法則「18ヶ月で性能が倍になる」

- Moore's Law "doubles performance in 18 months."

から考えると、

Given that from the information,

2^(x/1.5)= 10000 を解けばいい。

Solve 2^(x/1.5) = 10000.

x = 19.93 年

x = 19.93 years

なるほど、『私たちは、みんな、20年前のスパコンを使っている』ことになる訳です。

I see, 'We are all using 20-year-old supercomputers'.

つまり、理屈上、2003年の段階で、スパコンで計算していた天気予報や地震予測計算は、自分の部屋でもできます。

In other words, in theory, as of 2003, weather forecasts and earthquake prediction calculations that were being calculated on supercomputers can be done in your own room.

私から見れば『20年間待ち続ければいい』のです。

From my point of view, 'I just have to wait for 20 years'.

逆に言えば、スパコンへの開発や投資コスト(約1300億円、保守コスト抜き)は、この『20年間の先行』にあると言うことです。

Conversely, the cost of development and investment in supercomputers (about 130 billion yen, not including maintenance costs) is in this '20-year leading'.

皆さんが、どう考えるのは分かりませんが、私は、概ね妥当なコストだと思います。

I don't know what you all think, but I think the cost is generally reasonable.

2023,江端さんの技術メモ

第3章: スコアリングの詳細
第4章: MATSimの設定について
第5章: 利用可能な機能とその使用方法
第6章: MATSimのデータコンテナ
第7章: MATSimの初期入力の生成
第8章: MATSim JOSMNetworkエディタ
第9章 シンガポールにおけるMap-to-MapMatchingエディタ
第10章 ネットワークエディターの貢献
第11章: QSim
第12章 信号と車線
第13章 駐車場
第14章:電気自動車
第15章: ロードプライシング
第16章:MATSimによる公共交通のモデル化
第17章:「ミニバス」の貢献度
第18章 バス路線図マッチングの半自動化ツール
第19章 新しい動的イベントベースの公共交通ルータ
第20章 マトリックスベースの白金ルータ
第21章 "マルチモーダル "への貢献
第22章 カーシェアリング
第23章 カーシェアリング ダイナミックトランスポートサービス
第24章 貨物輸送 貨物輸送
第25章 貨物輸送 ワゴンシム
第26章 旅日記から読み解く貨物連鎖
第27章: デスティネーション・イノベーション
第28章 共同意思決定
第29章 ソクネトゲン
第30章: 日帰りリプランニング
第31章: MATSimエージェントを賢くする信念・願望・意図
第32章: CaDyTS: 動的トラフィックシミュレーションのキャリブレーション
第33章 セノゾンビア
第34章: OTFVis: MATSimのオープンソースビジュアライザー
第35章: アクセシビリティ
第36章: 排出ガスモデリング
第37章: MATSimを用いたインタラクティブな解析と意思決定支援
第38章: 「解析」の貢献
第39章: MATSimにおけるマルチモデリング。PSim
第40章: その他の計算性能に関する経験
第41章 避難計画 統合的アプローチ
第42章 都市シミュレーション MATSim4都市シム
第43章 廃止されたモジュール
第44章:組織 開発プロセス、コード構造、そして
第45章: 自分自身の拡張機能を書き、貢献する方法
第46章 MATSimの歴史
第47章 エージェントベースのトラフィックアサインメント
第48章: モンテカルロエンジンとしてのMATSim
第49章: MATSimにおける選択モデル
第50章: 運動学的波動の待ち行列表現
第51章:MATSimによる便益・費用に関するミクロ経済学的解釈
第52章 シナリオの概要
第53章:ベルリンI: BVGシナリオ
第54章 ベルリンII CEMDAP-MATSim-Cadytsシナリオ
第55章:スイス
第56章:チューリッヒ
第57章: シンガポール
第58章: ミュンヘン
第59章 スーフォールズ
第60章:アリアガ
第61章: 保定 家庭用新型ユーティリティの実証実験ケーススタディ
第62章 バルセロナ
第63章:ベルギー 河川洪水の経済的影響を評価するための推計フレームワークにおけるMATSimの利用
第64章:ブリュッセル
第65章:カラカス
第66章 コトブス 交通信号シミュレーション
第67章 ダブリン ダブリン
第68章 ヨーロッパの航空・鉄道輸送
第69章:ハウテン州
第70章: ドイツ
第71章:ハンブルク・ヴィルヘルムスブルク
第72章: ジョインビル
第73章: ロンドン ロンドン
第74章: ネルソン・マンデラ・ベイ
第75章: ニューヨーク
第76回:パダン パダン
第77章:パダン パトナ
第78章: フィリピン フィリピンにおけるエージェントベースの交通シミュレーションモデル
第79章: ポズナン
第80章: キト首都圏
第81章:ロッテルダム ロッテルダム 公共交通機関のレベニュー・マネジメント
第82章:サマラ
第83章: サンフランシスコ・ベイエリア スマートベイ・プロジェクト-コネクテッド
第84章 サンティアゴ・デ・チリ
第85章 シアトル地域
第86章: ソウル
第87章 上海
第88章: ソチ
第89章: ストックホルム
第90章:タンパ(フロリダ州 都市内移動の高解像度シミュレーションとその結果
第91章:テルアビブ
第92章:東京 ハイパーパスを用いた車両移動のシミュレーションと移動時間の信頼性に与える影響
第93章: トロント
第94章:トロント トロンハイム
第95章:ヤラウォンガとモルワラ。オーストラリア・ビクトリア州における需要対応型交通システム
第96章:横浜 MATSimのレジリエントな都市設計への応用
第97章: 研究の方向性


Chapter 3: A Closer Look at Scoring
Chapter 4: More About Configuring MATSim
Chapter 5: Available Functionality and How to Use It
Chapter 6: MATSim Data Containers
Chapter 7: Generation of the Initial MATSim Input
Chapter 8: MATSim JOSMNetwork Editor
Chapter 9: Map-to-MapMatching Editors in Singapore
Chapter 10: The Network Editor Contribution
Chapter 11: QSim
Chapter 12: Traffic Signals and Lanes
Chapter 13: Parking
Chapter 14: Electric Vehicles
Chapter 15: Road Pricing
Chapter 16: Modeling Public Transport with MATSim
Chapter 17: The "Minibus" Contribution
Chapter 18: Semi-Automatic Tool for Bus Route Map Matching
Chapter 19: New Dynamic Events-Based Public Transport Router
Chapter 20: Matrix-Based pt router
Chapter 21: The "Multi-Modal" Contribution
Chapter 22: Car Sharing
Chapter 23: Dynamic Transport Services
Chapter 24: Freight Traffic
Chapter 25: WagonSim
Chapter 26: freight Chains From Travel Diaries
Chapter 27: Destination Innovation
Chapter 28: Joint Decisions
Chapter 29: Socnetgen
Chapter 30: Within-Day Replanning
Chapter 31: Making MATSim Agents Smarter with the Belief-Desire-Intention
Chapter 32: CaDyTS: Calibration of Dynamic Traffic Simulations
Chapter 33: Senozon Via
Chapter 34: OTFVis: MATSim's Open-Source Visualizer
Chapter 35: Accessibility
Chapter 36: Emission Modeling
Chapter 37: Interactive Analysis and Decision Support with MATSim
Chapter 38: The "Analysis" Contribution
Chapter 39: Multi-Modeling in MATSim: PSim
Chapter 40: Other Experiences with Computational Performance
Chapter 41: Evacuation Planning: An Integrated Approach
Chapter 42: MATSim4 Urban Sim
Chapter 43: DiscontinuedModules
Chapter 44: Organization: Development Process, Code Structure and
Chapter 45: How toWrite Your Own Extensions and Possibly Contribute
Chapter 46: Some History of MATSim
Chapter 47: Agent-Based Traffic Assignment
Chapter 48: MATSim as aMonte-Carlo Engine
Chapter 49: Choice Models in MATSim
Chapter 50: Queueing Representation of Kinematic Waves
Chapter 51: Microeconomic Interpretation of MATSim for Benefit-Cost
Chapter 52: Scenarios Overview
Chapter 53: Berlin I: BVG Scenario
Chapter 54: Berlin II: CEMDAP-MATSim-Cadyts Scenario
Chapter 55: Switzerland
Chapter 56: Zuurich
Chapter 57: Singapore
Chapter 58: Munich
Chapter 59: Sioux Falls
Chapter 60: Aliaga
Chapter 61: Baoding: A Case Study for Testing a New Household Utility
Chapter 62: Barcelona
Chapter 63: Belgium: The Use of MATSim within an Estimation Framework for Assessing Economic Impacts of River Floods
Chapter 64: Brussels
Chapter 65: Caracas
Chapter 66: Cottbus: Traffic Signal Simulation
Chapter 67: Dublin
Chapter 68: European Air - and Rail-Transport
Chapter 69: Gauteng
Chapter 70: Germany
Chapter 71: HamburgWilhelmsburg
Chapter 72: Joinville
Chapter 73: London
Chapter 74: NelsonMandela Bay
Chapter 75: New York City
Chapter 76: Padang
Chapter 77: Patna
Chapter 78: The Philippines: Agent-Based Transport SimulationModel for
Chapter 79: Poznan
Chapter 80: QuitoMetropolitan District
Chapter 81: Rotterdam: Revenue Management in Public Transportation with
Chapter 82: Samara
Chapter 83: San Francisco Bay Area: The SmartBay Project - Connected
Chapter 84: Santiago de Chile
Chapter 85: Seattle Region
Chapter 86: Seoul
Chapter 87: Shanghai
Chapter 88: Sochi
Chapter 89: Stockholm
Chapter 90: Tampa, Florida: High-Resolution Simulation of Urban Travel and
Chapter 91: Tel Aviv
Chapter 92: Tokyo: Simulating Hyperpath-Based Vehicle Navigations and its Impact on Travel Time Reliability
Chapter 93: Toronto
Chapter 94: Trondheim
Chapter 95: Yarrawonga andMulwala: Demand-Responsive Transportation in Regional Victoria, Australia
Chapter 96: Yokohama: MATSim Application for Resilient Urban Design
Chapter 97: Research Avenues

未分類

今年の年末年始の休暇の開始から今に至るまで、私は自信をもって「1時間もサボっていない」と断言できます。

From the start of this year's New Year's vacation to now, I can confidently say that I have not skipped an hour.

この正月に見たテレビ番組は、録画しておいた『芸能人格付けチェック! 2023お正月スペシャル』だけです。

The only TV program I watched this New Year's was the recorded "Celebrity Ratings Check! 2023 New Year's Special".

なのに、予定しているスケジュールが、2.5日も遅延しているのは、なぜでしょうか。

Why, then, is the planned schedule delayed by 2.5 days?

分かっています ―― 「事前の情報収集不足」と「自分の力量の過信」です。

I know -- "lack of information gathering in advance" and "overconfidence in one's own abilities".

今年も、この2つが私を窮地に追い込むのだろうなぁ、と思うと、今から気が重いです。

I am now feeling a bit overwhelmed, thinking that these two will probably put me in a tight spot this year as well.

2023,江端さんの技術メモ

MATSimに関する情報が、これほどまでに少ないとは知りませんでした ―― 特に、日本語の情報が絶無に近いです。

このドタバタ(失敗メモ)については、こちらに記載しています。

MATSimの調査(継続中)

本来なら、大晦日の日に完了しているはずのメモのリリースが今日(2023年1月3日)になってしまいました。

「MATSimのシミュレーションが動いているところまで確認する」のメモ


多くの交通システムの研究に携わる人が、MATSimを最初に触って動かすときの一助になれば、幸いです。

江端