この歌、いつ頃、流行ったかなぁ・・・私、学習塾で講師をやっていた時、子どもたちにこの歌を聞かせたことがあります。

今は、もう流せないのかなぁ？

最近のNHK大河ドラマには、興味深い挑戦が見られると思います。
I think recent NHK Taiga dramas present genuinely interesting challenges.

江戸時代のメディア王の話や、宮廷文学に乗せた恋愛話など、従来にない試みで楽しませてくれました（個人的には色恋ドラマにはあまり関心がありませんが）。
Stories about a media magnate of the Edo period, or romantic tales framed in court literature, have entertained us with approaches previously uncommon (although, personally, I am not particularly interested in romantic dramas).

日本史上の著名な権力者ではなく、それを取り巻く人物（黒田官兵衛、石田三成、明智光秀等）にクローズアップしたドラマなども面白いです。
It is also interesting to see dramas that focus not on the most famous power holders in Japanese history, but on the figures surrounding them (such as Kuroda Kanbei, Ishida Mitsunari, and Akechi Mitsuhide).

今後期待されるのは、松永久秀、三好義継、篠原長房、荒木村重、津田信澄あたりが題材になると面白いのでは、と思います。
Looking ahead, I think it would be interesting if figures such as Matsunaga Hisahide, Miyoshi Yoshitsugu, Shinohara Nagafusa, Araki Murashige, or Tsuda Nobuzumi were taken up as subjects.

明治維新後では、岩瀬忠震、川路聖謨、永井尚志などはどうでしょうか。ちょっとネームバリューと視聴率の面では難しそうですが。
For the period after the Meiji Restoration, how about Iwase Tadanari, Kawaji Toshiakira, or Nagai Naoyuki? Admittedly, their name recognition and potential ratings might be an issue.

そういう意味では、今年のNHKの大河ドラマ（豊臣秀長）には、少し期待しています。
In that sense, I have modest expectations for this year’s NHK Taiga drama (Toyotomi Hidenaga).

---

多分、現実的には、絶対に実施されないとは思うのですが――
Although I think that, realistically, this would almost certainly never be implemented—

GIS（Geographic Information Systems）を使った、ドラマとの同時進行
A system that runs in parallel with the drama using GIS (Geographic Information Systems)

が見たいなぁ、と思うのです。
is something I would really like to see.

簡単に言うと、地図上に戦場を再現して、ドラマに合わせて、軍隊の移動状況や主人公の立ち位置を変えていく、というものです。
Put simply, it would recreate battlefields on a map and change troop movements and the protagonist’s position in sync with the drama.

このようなシステムを、COP（Common Operational Picture：共通作戦状況図）といいます。
Such a system is called a COP (Common Operational Picture).

戦場・部隊配置・時間経過を、主にGIS上に統合表示し、指揮官や関係者が共通の状況認識を持つための仕組みです。戦場可視化(Battlefield Visualization)システムとも呼ばれます。
It is a mechanism that integrates and displays battlefields, troop deployments, and the passage of time—primarily in GIS—so that commanders and stakeholders can share everyday situational awareness. It is also referred to as a battlefield visualization system.

もちろん、このCOPを把握できるのは、当然、視聴者だけです――ドラマの登場人物が、このシステムを視聴していたら、ドラマになりませんから。
Of course, the only ones who can grasp this COP are the viewers—if the characters in the drama themselves could see it, there would be no drama.

川中島、関ヶ原、壇ノ浦――これらのフィールドでの状況が、ドラマと連動してWebサイトで見られたとしたら――これは、いわゆる「萌え」ではなく、純粋に「燃え」ますよ。
If the situations at Kawanakajima, Sekigahara, or Dan-no-ura could be viewed on a website in sync with the drama, this would not be “moe,” but something that genuinely fires you up.

川中島、関ヶ原、壇ノ浦が、現在の日本の何県の何市にあるか、ほとんどの日本人は知らないですよね。
Most Japanese people do not know which prefecture or city in present-day Japan Kawanakajima, Sekigahara, or Dan-no-ura are actually located in, do they?

この、大河ドラマ―COPリアルタイム連動放送が実現したら、地域活性政策として、半端ではない盛り上がり方をすると思います。「アニメの『聖地巡礼』」など目ではありません（と、私は思っていますが――そうでもないかな？）。
If this kind of real-time Taiga drama–COP linked broadcast were realized, I think it would generate an extraordinary level of excitement as a regional revitalization policy. It would far surpass so-called “anime pilgrimage” tourism (at least, that’s what I think—though perhaps not?).

私が、桶狭間合戦場の出身者であることは、何度もお話してきましたが、私、「大高城」も「沓掛城」も「鳴海砦」も、その場所を知らないのです（そもそも遺跡がちゃんとあるのかも怪しい）。
I have mentioned many times that I am from the area of the Battle of Okehazama. Yet, I do not actually know the locations of Odaka Castle, Kutsukake Castle, or Narumi Fort (and I am not even sure whether proper remains still exist).

桶狭間合戦の今川軍や織田軍が、私の元実家のあった場所で、行軍または戦闘していたと分かったら――そりゃ、燃えますよ。
If it turned out that the Imagawa or Oda forces at the Battle of Okehazama had marched or fought in the very place where my former family home stood—well, that would definitely fire me up.

---

そういう意味では、GISと言わないまでも、地図（または位置情報）というのは、過去と現在をタイムリープさせる超低コストの「タイムマシン」のような存在であり、そして、歴史と地理を連携させる有効な教材であると思うのです。
In that sense, even without explicitly calling it GIS, maps (or location information) function like an ultra-low-cost “time machine” that allows us to leap between the past and the present, and they are an effective educational tool that links history and geography.

なにより、「面白い」と思う――私は。
Above all, I find it interesting—that is what I think.

ただ、これを実現するには、「歴史学者」と「地理学者」の両方を兼ね備えた人物が必要でして、戦場可視化（Battlefield Visualization）にかなりのコスト、または、歴史＆地図オタクの存在が必要になると思います。
However, to realize this, one would need someone who combines the expertise of both a historian and a geographer, and it would require considerable cost for battlefield visualization—or the presence of a serious history-and-map enthusiast.

でまあ、「現実的には、絶対に実施されないとは思うのですが」と、先んじて逃げを打っておいた訳です。
So, by saying “realistically, it would almost certainly never be implemented,” I have already hedged my bets in advance.

---

この年末年始の休みは、毎日の歩行に、少しずつジョギングを加えながら、リハビリをしていたのですが、同時に、歩きながら、北朝鮮の資料を読み漁ってもいました。
During the year-end and New Year holidays, I was doing rehabilitation by gradually adding jogging to my daily walks. At the same time, I was voraciously reading materials on North Korea while walking.

私、今日、はじめて北朝鮮の地図をまじまじと見ました。そして、私が、これまで、北朝鮮を概念、または「点」として把握していたことに気がつきました。そして、この国の中に多くの人が生きていることを、漠然と感じることができました。
Today, for the first time, I closely examined a map of North Korea. I realized that until now I had perceived North Korea merely as a concept or a “point,” and I was able, albeit vaguely, to sense that many people actually live there.

地図を見てみると、その国の政治体制や国民の気質が見えてくる気がします――地政学というものではなくて、国を陸地で接している国々を見ると、それぞれの国が、早朝ラッシュ時の山手線に乗っている乗客のように見えてきて、なかなか示唆に富んでいて、面白いものです。
When you look at a map, you begin to feel that you can see a country’s political system and the temperament of its people—not in the sense of geopolitics, but rather as if the countries sharing land borders resemble passengers riding the Yamanote Line during the early-morning rush hour, which is quite thought-provoking and engaging.

もし「弔われていない戦死者の上に建つ土地」を事故物件と呼ぶのであれば、日本中の平野部は、ほぼ全滅です。

plans.xmlとoutput/output_plans.xml を記載します。変換の概要を教えて下さい。

以下のMATSimのplans.xmlの内容を説明して下さい。

MATSimにおける walk モードと軌跡・接触解析に関する検討メモ

OSM → MATSim 変換後の network.xml を読むための実務向け説明

Javaを使ったMATSim network.xml.gz 構築手順メモ（hirohakama）

現在の状況(11/30) 一通りの稼働を確認

(Step 1) 広袴のOSMファイルをダウンロード
G:\home\ebata\hirohakama\hiro_db\small-hirohakama.osm

(Step 2) OSM → network.xmlへの変更
G:\home\ebata\hirohakama\hiro_db
$ python osm_to_matsim_network.py
network.xmlが生成

(Step.3)
ebata@DESKTOP-1QS7OI7:~/matsim-example-project$ java -jar matsim-example-project-0.0.1-SNAPSHOT.jar

[config-test1.xml]

<?xml version="1.0" ?>
<!DOCTYPE config SYSTEM "http://www.matsim.org/files/dtd/config_v2.dtd">
<config>

	<module name="global">
		<param name="randomSeed" value="4711" />
		<param name="coordinateSystem" value="EPSG:6685" />
	</module>

	<module name="network">
		<param name="inputNetworkFile" value="network-test1.xml" />
	</module>

	<module name="plans">
		<param name="inputPlansFile" value="plans-test1.xml" />
	</module>

	<module name="controller">
		<param name="outputDirectory" value="./output" />
		<param name="lastIteration" value="0" />

		<!-- 追記：毎イテレーション events を出す -->
		<param name="writeEventsInterval" value="1" />

	</module>


	<module name="scoring">
		<parameterset type="activityParams" >
			<param name="activityType"            value="h" />
			<param name="typicalDuration" value="12:00:00" />
		</parameterset>
		<parameterset type="activityParams" >
			<param name="activityType"            value="w" />
			<param name="typicalDuration" value="08:00:00" />
		</parameterset>
	</module>

	<module name="routing">
	  <!-- 既に書いてある他の routing パラメータがあればそのまま残す -->
	  
	  <!-- ネットワーク整合性チェックを無効化 -->
	  <param name="networkRouteConsistencyCheck" value="disable" />
	</module>	
	
</config>

[network-test1.xml]

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE network SYSTEM "http://www.matsim.org/files/dtd/network_v1.dtd">

<network name="equil test network">
  <nodes>
    <node id="279332805" x="768875.871" y="1096994.329"/>
    <node id="279332812" x="768964.532" y="1097238.641"/>
    <node id="279332877" x="768972.629" y="1097302.450"/>
(中略)
    <node id="12893847140" x="768966.269" y="1097305.846"/>
    <node id="13206970768" x="768642.219" y="1096803.771"/>
    <node id="13206970769" x="768656.013" y="1096826.212"/>
  </nodes>

  <links capperiod="01:00:00">
    <link id="1239817547_0_bwd" from="12891801850" to="279332880" length="2.25" freespeed="13.89" capacity="900.00" permlanes="1" />
    <link id="1239817547_0_fwd" from="279332880" to="12891801850" length="2.25" freespeed="13.89" capacity="900.00" permlanes="1" />
    <link id="1239817547_1_bwd" from="1768138693" to="12891801850" length="62.84" freespeed="13.89" capacity="900.00" permlanes="1" />
(中略)
    <link id="761529596_5_bwd" from="12891801828" to="12891801827" length="1.72" freespeed="10.00" capacity="1000.00" permlanes="1" />
    <link id="761529596_5_fwd" from="12891801827" to="12891801828" length="1.72" freespeed="10.00" capacity="1000.00" permlanes="1" />
  </links>
</network>

[plans-test1.xml]

<?xml version="1.0" ?>
<!DOCTYPE plans SYSTEM "http://www.matsim.org/files/dtd/plans_v4.dtd">
<plans xml:lang="de-CH">
<person id="1">
  <plan>
    <act type="h" link="153188623_0_fwd" end_time="06:00" />
    <leg mode="car">
      <route> </route>
    </leg>

    <act type="w" link="165222823_3_fwd" dur="00:00:10" />
    <leg mode="car">
      <route> </route>
    </leg>
    <act type="w" link="165257680_2_fwd" dur="00:00:05" />

    <leg mode="car">
      <!-- ここは書かない（MATSim に任せる） -->
    </leg>

    <act type="h" link="257057591_26_fwd" />
  </plan>
</person>
</plans>

(Step.4)

ebata@DESKTOP-1QS7OI7:~/matsim-example-project/scenarios/equil2$ python matsim_events_to_geo_csv.py
CSV exported: output/agents_positions_geo.csv

(Step.5)

ここからは、QGISで動画表示をするところは、前回の方式とおなじ

======
現在の状況(11/24)

WSL(Ubuntu)起動→
ebata@DESKTOP-1QS7OI7:~/matsim-example-project$ java -jar matsim-example-project-0.0.1-SNAPSHOT.jar

これが通ると

ebata@DESKTOP-1QS7OI7:~/matsim-example-project/scenarios/equil2/output$ pwd
/home/ebata/matsim-example-project/scenarios/equil2/output が書換えられるので注意

必要なファイルは3つ

<?xml version="1.0" ?>
<!DOCTYPE config SYSTEM "http://www.matsim.org/files/dtd/config_v2.dtd">
<config>

	<module name="global">
		<param name="randomSeed" value="4711" />
		<param name="coordinateSystem" value="EPSG:6685" />
	</module>

	<module name="network">
		<param name="inputNetworkFile" value="network.xml" />
	</module>

	<module name="plans">
		<param name="inputPlansFile" value="plans100.xml" />
	</module>

	<module name="controller">
		<param name="outputDirectory" value="./output" />
		<param name="lastIteration" value="10" />

		<!-- 追記：毎イテレーション events を出す -->
		<param name="writeEventsInterval" value="1" />

	</module>

	<module name="scoring">
		<param name="lateArrival" value="-18" />
		<param name="performing" value="+6" />
		<parameterset type="activityParams" >
			<param name="activityType"            value="h" />
			<param name="typicalDuration" value="12:00:00" />
		</parameterset>
		<parameterset type="activityParams" >
			<param name="activityType"            value="w" />
			<param name="typicalDuration" value="08:00:00" />
			<param name="openingTime"     value="07:00:00" />
			<param name="closingTime"     value="18:00:00" />
		</parameterset>
	</module>
	
	<module name="replanning">
		<parameterset type="strategysettings" >
			<param name="strategyName" value="BestScore" />
			<param name="weight" value="0.9" />
		</parameterset>
		<parameterset type="strategysettings" >
			<param name="strategyName" value="ReRoute" />
			<param name="weight" value="0.1" />
		</parameterset>
	</module>
</config>

上記のconfig.xmlの概要は以下の通り。

config.xml の概要

本設定ファイルは、MATSim シミュレーションを実行するための基本パラメータを定義したものであり、全体として「ネットワーク」「プラン」「コントローラ」「スコアリング」「リプランニング（経路再探索）」の各モジュール設定から構成されている。

1. global モジュール

• シミュレーションの乱数シード（4711）を指定して再現性を確保している。

• 使用する座標系として EPSG:6685（日本の平面直角座標系 9系などに相当）を明示している。

2. network モジュール

• 交通ネットワークとして network.xml を読み込む設定である。

• 道路・リンク・ノード等の空間構造を定義する基礎データである。

3. plans モジュール

• エージェントの活動計画ファイルとして plans100.xml を指定している。

• 各エージェントの1日の行動（自宅→職場など）を読み込む役割を持つ。

4. controller モジュール

• 出力ディレクトリを ./output とし、最終イテレーションは 10 としている。

• 各イテレーションでイベントファイル（events.xml.gz）を出力するため、writeEventsInterval=1 を設定している。

5. scoring モジュール

• スコア計算に関するパラメータを定義している。

  • 遅刻のペナルティ（lateArrival = −18）

  • 活動継続の効用（performing = +6）

• 活動タイプ h（home） および w（work） の典型滞在時間・開閉時間などを定義し、日常行動モデルの評価基準を与えている。

6. replanning モジュール

• プラン選択と経路再探索に関する戦略設定を行っている。

  • BestScore（重み 0.9）

  • ReRoute（重み 0.1）

• これにより、シミュレーション内でエージェントがプランを修正し、より良い経路や活動を選択する過程を再現する。

総括

本 config.xml は、標準的な MATSim 実行構成を踏襲しながら、日本の座標系（EPSG:6685）を用いたネットワーク・プランデータを読み込み、10 イテレーションのシミュレーションを行う設定となっている。スコアリングおよび再計画戦略も基本設定が施されており、小規模テストから実用的な解析まで広く利用可能な構成である。

[network.xml]

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE network SYSTEM "http://www.matsim.org/files/dtd/network_v1.dtd">

<network name="equil test network">
  <nodes>
	<node id="1"  x="774558.033" y="1108851.844"/>
	<node id="2"  x="779558.033" y="1108851.844"/>
	<node id="3"  x="793693.033" y="1114776.844"/>
	<node id="4"  x="792060.033" y="1113182.844"/>
	<node id="5"  x="790729.033" y="1112066.844"/>
	<node id="6"  x="789860.033" y="1110562.844"/>
	<node id="7"  x="789558.033" y="1108851.844"/>
	<node id="8"  x="789860.033" y="1107140.844"/>
	<node id="9"  x="790729.033" y="1105636.844"/>
	<node id="10" x="792060.033" y="1104520.844"/>
	<node id="11" x="793693.033" y="1102926.844"/>
	<node id="12" x="794558.033" y="1108851.844"/>
	<node id="13" x="799558.033" y="1108851.844"/>
	<node id="14" x="799558.033" y="1098851.844"/>
	<node id="15" x="774558.033" y="1098851.844"/>
  </nodes>

   <links capperiod="01:00:00">
      <link id="1" from="1" to="2" length="10000.00" capacity="36000" freespeed="27.78" permlanes="1"  />
      <link id="2" from="2" to="3" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="3" from="2" to="4" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="4" from="2" to="5" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="5" from="2" to="6" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="6" from="2" to="7" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="7" from="2" to="8" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="8" from="2" to="9" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="9" from="2" to="10" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="10" from="2" to="11" length="10000.00" capacity="3600" freespeed="27.78" permlanes="1"  />
      <link id="11" from="3" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="12" from="4" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="13" from="5" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="14" from="6" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="15" from="7" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="16" from="8" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="17" from="9" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="18" from="10" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="19" from="11" to="12" length="5000.00" capacity="1000" freespeed="27.78" permlanes="1"  />
      <link id="20" from="12" to="13" length="10000.00" capacity="36000" freespeed="27.78" permlanes="1"  />
      <link id="21" from="13" to="14" length="10000.00" capacity="36000" freespeed="27.78" permlanes="1"  />
      <link id="22" from="14" to="15" length="35000.00" capacity="36000" freespeed="27.78" permlanes="1"  />
      <link id="23" from="15" to="1" length="10000.00" capacity="36000" freespeed="27.78" permlanes="1"  />
   </links>
</network>

network.xml の概要

本 network.xml は、MATSim の「equil（equilibrium）」テストで用いられる代表的な小規模ネットワークの構造を記述したものであり、ノード 15 点とリンク 23 本から構成される。全体として、中央ノード「2」を中心とした放射状構造と、外周を囲うリング構造をあわせ持つネットワークである。

1. ノード構成（nodes）

• ノード数は 15。

• 座標はメートル単位の **平面直角座標（UTM ではない独自座標）**に近い配置。

• ノード 1 → 2 → 3 → 12 → 13 → 14 → 15 → 1 と接続する大きな「外周ループ（リング）」が形成されている。

■ 中央に位置するノード

• ノード 2
  → このノードから計 10 本のリンクが放射状に伸びており、ネットワークの「ハブ」として機能する。

■ 外周ノード

• 1, 2, 3, 12, 13, 14, 15
  → 大きな四角形〜多角形を構成する外周ノード。

■ 放射状ノード

• 3〜11（2 を中心とした扇状配置）

• これらのノードはすべてノード 12 に接続され、中央から外周へ向かう“枝”のような構造を形成。

2. リンク構成（links）

総リンク数は 23 本。時間帯は capperiod="01:00:00"（1時間あたり容量）。

(1) ハブ（ノード 2）から放射状に伸びるリンク（リンクID 2〜10）

• from="2" → to="3〜11"

• 長さ：10,000 m

• 容量：3,600 veh/h

• 自由速度：27.78 m/s（= 約 100 km/h）

• 構造：中央ノードから各方向へ伸びる 9 本の支線

(2) 放射状ノードからノード 12 への接続（リンクID 11〜19）

• 各ノード 3〜11 → ノード 12 へ接続

• 長さ：5,000 m

• 容量：1,000 veh/h（細い道路）

• 放射状ネットワークの外周に向かう“枝”の集約点がノード 12

(3) 外周ループ（リンクID 1, 20〜23）

• 1 → 2

• 12 → 13

• 13 → 14

• 14 → 15

• 15 → 1

• 長さ：10,000〜35,000 m

• 容量：36,000 veh/h（高速道路レベル）

• ネットワーク外周を広く囲むリング道路

3. ネットワーク構造の特徴

• 中央ハブ（ノード2）
  → 多方向に交通が流れる主要結節点。
  → エージェントが多く集まるため、MATSim チュートリアルで典型的に渋滞が再現される部分。

• 外周大容量リンク
  → 大容量（36,000 veh/h）で構成され、混雑しづらい。
  → “外環状道路”として機能。

• 中間のノード 12 が集約点
  → 放射状ノード群の出口に相当。
  → ハブ（2）と外周（13）を結ぶ重要な中継ノード。

• 典型的なテストネットワーク
  → シンプルであるが、渋滞・ルート選択・再探索の動きを明確に確認できる構造。
  → MATSim の初学者用・論文やサンプルコードで用いられる標準モデル。

総括

この network.xml は、MATSim の代表的な「equil」ネットワークをベースとしたもので、中心に交通が集中するハブ構造と、大容量リング道路、放射状道路からなるシンプルかつ典型的なテスト用ネットワークである。渋滞発生や再経路探索のような動態変化を観察するのに適した構成となっている。

[plans100.xml]

<?xml version="1.0" ?>
<!DOCTYPE plans SYSTEM "http://www.matsim.org/files/dtd/plans_v4.dtd">
<plans xml:lang="de-CH">
<person id="1">
	<plan>
		<act type="h" x="-25000" y="0" link="1" end_time="06:00" />
		<leg mode="car">
			<route>2 7 12</route>
		</leg>
		<act type="w" x="10000" y="0" link="20" dur="00:10" />
		<leg mode="car">
			<route> </route>
		</leg>
		<act type="w" x="10000" y="0" link="20" dur="03:30" />
		<leg mode="car">
			<route>13 14 15 1</route>
		</leg>
		<act type="h" x="-25000" y="0" link="1" />
	</plan>
</person>

</plans>

この概要は以下の通り。

plans100.xml の概要

この plans100.xml は、MATSim に投入する **エージェントの活動計画（1日の行動スケジュール）**を定義したファイルである。
現状では person は1名のみ（id="1"）であり、その人物が 自宅(h)→職場(w)→職場(w)→自宅(h) と移動しながら活動する1日の行動列が記述されている。

1. person と plan の構成

• <person id="1">
  → エージェント1名を定義。

• <plan>
  → そのエージェントの1日の行動計画を時系列に並べる。
  act（活動）と leg（移動）の交互列が基本。

2. 行動列の中身（act / leg）

(1) 自宅活動 h

• type="h" は home（自宅）。

• link="1" 上に存在する活動地点。

• end_time="06:00" なので、06:00 に出発する設定。

(2) 車移動（自宅→職場）

• mode="car" により車移動。

• route は通過リンク列で、
  リンク 2 → 7 → 12 を通る経路を明示している。

(3) 職場活動 w（短い滞在）

• type="w" は work（職場）。

• link="20" 上で活動。

• dur="00:10" なので 10分だけ職場に滞在。

(4) 車移動（職場→職場）

• 車移動だが route が空白。

• これは 経路をMATSim側に再計算させる意図で置かれていると解釈できる。

(5) 職場活動 w（長い滞在）

• 同じ link="20" の職場で、
  3時間30分滞在する設定。

(6) 車移動（職場→自宅）

• リンク 13 → 14 → 15 → 1 を通って帰宅する経路が明示されている。

• ネットワークの外周ループ側を通る帰路と対応する。

(7) 自宅活動 h（帰宅後）

• 最終活動は自宅(h)。

• end_time や dur がないため、**その時点で計画終了（終日滞在）**の意味。

3. この plans.xml の特徴と用途

• person が1名だけの 最小構成テスト用 plans。

• 経路が一部手動指定、一部自動再探索（空 route）という混合設定。

• equil ネットワーク上で
  時間指定付きの通勤行動と、再経路探索の挙動を確認するための計画になっている。

総括

plans100.xml は、エージェント1名の1日行動（06:00 出発の通勤、職場での短時間/長時間滞在、外周経路で帰宅）を記述したテスト用 plans である。経路指定を明示する部分と MATSim に任せる部分が共存しており、ルート選択やリプランニングの動作確認に適した構成となっている。

さて、3つのファイルで

ebata@DESKTOP-1QS7OI7:~/matsim-example-project/scenarios/equil2/output$ ls
ITERS                      modestats.png              output_households.xml.gz  pkm_modestats.csv
logfile.log                modestats_stackedbar.png   output_legs.csv.gz        pkm_modestats.png
logfileWarningsErrors.log  modules.dot                output_links.csv.gz       scorestats.csv
modeChoiceCoverage10x.png  output_activities.csv.gz   output_network.xml.gz     scorestats.png
modeChoiceCoverage10x.txt  output_allVehicles.xml.gz  output_persons.csv.gz     stopwatch.csv
modeChoiceCoverage1x.png   output_config.xml          output_plans.xml.gz       stopwatch.png
modeChoiceCoverage1x.txt   output_config_reduced.xml  output_trips.csv.gz       tmp
modeChoiceCoverage5x.png   output_counts.xml.gz       output_vehicles.xml.gz    traveldistancestats.csv
modeChoiceCoverage5x.txt   output_events.xml.gz       ph_modestats.csv          traveldistancestatslegs.png
modestats.csv              output_facilities.xml.gz   ph_modestats.png          traveldistancestatstrips.png
ebata@DESKTOP-1QS7OI7:~/matsim-example-project/scenarios/equil2/output$

ができている。

ここにcsvファイル作成用のPythonプログラム(matsim_events_to_csv.py)を書き込む。

[matsim_events_to_csv.py]

import gzip
import xml.etree.ElementTree as ET
import csv
import math

EVENTS_FILE = "output_events.xml.gz"
NETWORK_FILE = "output_network.xml.gz"
OUT_CSV = "agents_positions.csv"
STEP_SEC = 1.0  # 1秒刻み


def load_network(network_file):
    nodes = {}
    links = {}

    with gzip.open(network_file, 'rb') as f:
        tree = ET.parse(f)
        root = tree.getroot()

        for node in root.find("nodes"):
            nid = node.attrib["id"]
            x = float(node.attrib["x"])
            y = float(node.attrib["y"])
            nodes[nid] = (x, y)

        for link in root.find("links"):
            lid = link.attrib["id"]
            fnode = link.attrib["from"]
            tnode = link.attrib["to"]
            length = float(link.attrib.get("length", "0"))
            freespeed = float(link.attrib.get("freespeed", "0"))
            links[lid] = (fnode, tnode, length, freespeed)

    return nodes, links


def interpolate_points(t0, t1, x0, y0, x1, y1, step=1.0):
    dt = t1 - t0
    if dt <= 0:
        return [(t0, x0, y0), (t1, x1, y1)]

    n_steps = int(math.floor(dt / step))
    pts = []

    for i in range(n_steps + 1):
        t = t0 + i * step
        if t > t1:
            break
        r = (t - t0) / dt
        x = x0 + r * (x1 - x0)
        y = y0 + r * (y1 - y0)
        pts.append((t, x, y))

    if not pts or pts[-1][0] < t1:
        pts.append((t1, x1, y1))

    return pts


def process_events(events_file, nodes, links, out_csv):
    # vehicle -> person 対応
    vehicle_to_person = {}

    # vehicleごとの entered 状態
    # in_progress[vehicle] = (link_id, enter_time)
    in_progress = {}

    with gzip.open(events_file, 'rb') as f, open(out_csv, "w", newline="", encoding="utf-8") as csvfile:
        writer = csv.writer(csvfile)
        writer.writerow(["time", "person", "x", "y", "link", "event_type"])

        for ev, elem in ET.iterparse(f, events=("end",)):
            if elem.tag != "event":
                continue

            a = elem.attrib
            etype = a.get("type", "")
            time = float(a.get("time", "0"))

            # 1) vehicle -> person 対応を作る
            if etype == "PersonEntersVehicle":
                person = a.get("person")
                vehicle = a.get("vehicle")
                if person and vehicle:
                    vehicle_to_person[vehicle] = person
                elem.clear()
                continue

            # 2) entered/left link は vehicle 単位で処理
            if etype in ("entered link", "left link"):
                vehicle = a.get("vehicle")
                link_id = a.get("link")
                if vehicle is None or link_id is None:
                    elem.clear()
                    continue
                if link_id not in links:
                    elem.clear()
                    continue
                if vehicle not in vehicle_to_person:
                    # person がまだ紐付いていない車両は無視
                    elem.clear()
                    continue

                fnode, tnode, length, freespeed = links[link_id]
                if fnode not in nodes or tnode not in nodes:
                    elem.clear()
                    continue

                if etype == "entered link":
                    in_progress[vehicle] = (link_id, time)

                elif etype == "left link":
                    if vehicle not in in_progress:
                        elem.clear()
                        continue

                    entered_link_id, t_enter = in_progress[vehicle]
                    if entered_link_id != link_id:
                        # 不整合対策：状態を更新してスキップ
                        in_progress[vehicle] = (link_id, time)
                        elem.clear()
                        continue

                    t_left = time
                    actual_dt = t_left - t_enter

                    expected_dt = length / freespeed if freespeed > 0 and length > 0 else None
                    if actual_dt <= 0:
                        if expected_dt is not None and expected_dt > 0:
                            actual_dt = expected_dt
                            t_left = t_enter + actual_dt
                        else:
                            actual_dt = 0

                    x0, y0 = nodes[fnode]
                    x1, y1 = nodes[tnode]

                    pts = interpolate_points(t_enter, t_left, x0, y0, x1, y1, step=STEP_SEC)

                    person = vehicle_to_person[vehicle]
                    for t, x, y in pts:
                        writer.writerow([t, person, x, y, link_id, "move"])

                    in_progress.pop(vehicle, None)

            elem.clear()


def main():
    nodes, links = load_network(NETWORK_FILE)
    process_events(EVENTS_FILE, nodes, links, OUT_CSV)
    print(f"CSV exported: {OUT_CSV}")


if __name__ == "__main__":
    main()

$ebata@DESKTOP-1QS7OI7:~/matsim-example-project/scenarios/equil2/output$ python matsim_events_to_csv.py
CSV exported: agents_positions.csv

このagents_positions.csvが、エージェントの軌跡となるが、面倒なので、時間と座標を出すプログラムを作成

[matsim_events_to_geo_csv.py]

import gzip
import xml.etree.ElementTree as ET
import csv
import math
from datetime import datetime, timedelta, timezone

try:
    from pyproj import Transformer
except ImportError as e:
    raise SystemExit(
        "pyproj が必要です。pip install pyproj を実行してください。"
    )

EVENTS_FILE = "output_events.xml.gz"
NETWORK_FILE = "output_network.xml.gz"
OUT_CSV = "agents_positions_geo.csv"
STEP_SEC = 1.0  # 1秒刻み

# シミュレーション開始日時（必要に応じて変更）
# 例: 日本時間で 2025-11-24 00:00:00 開始
SIM_START = datetime(2025, 11, 24, 0, 0, 0, tzinfo=timezone(timedelta(hours=9)))

# 座標変換: EPSG:6685 -> EPSG:4326 (lon, lat)
TRANSFORMER = Transformer.from_crs("EPSG:6685", "EPSG:4326", always_xy=True)


def load_network(network_file):
    nodes = {}
    links = {}

    with gzip.open(network_file, 'rb') as f:
        tree = ET.parse(f)
        root = tree.getroot()

        for node in root.find("nodes"):
            nid = node.attrib["id"]
            x = float(node.attrib["x"])
            y = float(node.attrib["y"])
            nodes[nid] = (x, y)

        for link in root.find("links"):
            lid = link.attrib["id"]
            fnode = link.attrib["from"]
            tnode = link.attrib["to"]
            length = float(link.attrib.get("length", "0"))
            freespeed = float(link.attrib.get("freespeed", "0"))
            links[lid] = (fnode, tnode, length, freespeed)

    return nodes, links


def interpolate_points(t0, t1, x0, y0, x1, y1, step=1.0):
    dt = t1 - t0
    if dt <= 0:
        return [(t0, x0, y0), (t1, x1, y1)]

    n_steps = int(math.floor(dt / step))
    pts = []

    for i in range(n_steps + 1):
        t = t0 + i * step
        if t > t1:
            break
        r = (t - t0) / dt
        x = x0 + r * (x1 - x0)
        y = y0 + r * (y1 - y0)
        pts.append((t, x, y))

    if not pts or pts[-1][0] < t1:
        pts.append((t1, x1, y1))

    return pts

def sec_to_datetime_str(sec):
    dt = SIM_START + timedelta(seconds=sec)
    # QGISで扱いやすい形式 → 2025-11-24 06:00:01
    return dt.strftime('%Y-%m-%d %H:%M:%S')

def xy_to_lonlat(x, y):
    lon, lat = TRANSFORMER.transform(x, y)
    return lon, lat


def process_events(events_file, nodes, links, out_csv):
    vehicle_to_person = {}
    in_progress = {}

    with gzip.open(events_file, 'rb') as f, open(out_csv, "w", newline="", encoding="utf-8") as csvfile:
        writer = csv.writer(csvfile)
        writer.writerow(["datetime", "time_sec", "person", "lat", "lon", "link", "event_type"])

        for ev, elem in ET.iterparse(f, events=("end",)):
            if elem.tag != "event":
                continue

            a = elem.attrib
            etype = a.get("type", "")
            time_sec = float(a.get("time", "0"))

            # vehicle -> person 対応付け
            if etype == "PersonEntersVehicle":
                person = a.get("person")
                vehicle = a.get("vehicle")
                if person and vehicle:
                    vehicle_to_person[vehicle] = person
                elem.clear()
                continue

            if etype in ("entered link", "left link"):
                vehicle = a.get("vehicle")
                link_id = a.get("link")
                if vehicle is None or link_id is None:
                    elem.clear()
                    continue
                if link_id not in links:
                    elem.clear()
                    continue
                if vehicle not in vehicle_to_person:
                    elem.clear()
                    continue

                fnode, tnode, length, freespeed = links[link_id]
                if fnode not in nodes or tnode not in nodes:
                    elem.clear()
                    continue

                if etype == "entered link":
                    in_progress[vehicle] = (link_id, time_sec)

                elif etype == "left link":
                    if vehicle not in in_progress:
                        elem.clear()
                        continue

                    entered_link_id, t_enter = in_progress[vehicle]
                    if entered_link_id != link_id:
                        in_progress[vehicle] = (link_id, time_sec)
                        elem.clear()
                        continue

                    t_left = time_sec
                    actual_dt = t_left - t_enter

                    expected_dt = length / freespeed if freespeed > 0 and length > 0 else None
                    if actual_dt <= 0:
                        if expected_dt is not None and expected_dt > 0:
                            actual_dt = expected_dt
                            t_left = t_enter + actual_dt
                        else:
                            actual_dt = 0

                    x0, y0 = nodes[fnode]
                    x1, y1 = nodes[tnode]

                    pts = interpolate_points(t_enter, t_left, x0, y0, x1, y1, step=STEP_SEC)

                    person = vehicle_to_person[vehicle]
                    for t, x, y in pts:
                        lon, lat = xy_to_lonlat(x, y)
                        dt_str = sec_to_datetime_str(t)
                        writer.writerow([dt_str, t, person, lat, lon, link_id, "move"])

                    in_progress.pop(vehicle, None)

            elem.clear()


def main():
    nodes, links = load_network(NETWORK_FILE)
    process_events(EVENTS_FILE, nodes, links, OUT_CSV)
    print(f"CSV exported: {OUT_CSV}")


if __name__ == "__main__":
    main()

QGISで動画表示する
レイヤ→属性テーブルを開く

これでdtというエントリーができる。
これで「プロパティ」→「時系列」で、

を投入する
これで
「プロジェクト」→「プロパティ」→「時系列」→「レイヤから計算」→「適用」

これもセットしないと出てこない

時系列コントロールを表示するには4つ設定しないと出てこない。
(1)そのレイヤ→"属性テーブル"によるdtのセット
(2)そのレイヤ→"プロパティ"によるセット
(3)メニューの"プロジェクト"→"プロパティ"→"時系列"によるセット
(4)メニューの"ビュー"→"パネル"→"時系列コントローラ"のチェック

こんな感じの動画がでます。

======

まず失敗から。

MATSim Docker image(https://github.com/maptic/matsim-docker)で動かせない。3日間くらいの時間を費やした結果、断念

-----

(1)WSLのUbuntuを起動

(2)matsim-example-project(https://github.com/matsim-org/matsim-example-project)にあるコンテンツをダウンロード

cd ~
git clone https://github.com/matsim-org/matsim-example-project.git

(3)ビルド

cd ~/matsim-example-project$

./mvnw clean package

(3-1) どの java が呼ばれているか確認

which -a java
readlink -f "$(which java)"
echo "$JAVA_HOME"
which -a で複数出たら、一番上が今使われている java です。

JAVA_HOME が 17 を指していれば、PATH 先頭に $JAVA_HOME/bin が来て 17 が優先されます。

~/.bashrc や ~/.profile に JAVA_HOME=/usr/lib/jvm/java-17... の行が残っていると、それが勝ちます。

(3-2) 一時的に 21 へ切り替え（すぐ試せます）

export JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64
export PATH="$JAVA_HOME/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
hash -r # シェルのコマンドキャッシュをクリア
java -version
→ ここで openjdk version "21..." になれば OK。

(3-3) 恒久設定（ログイン時に毎回 21 になるように）

~/.bashrc または ~/.profile の中の 古い JAVA_HOME/PATH 行をコメントアウトし、下を追記：

# Java 21 を既定にする
export JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64
export PATH="$JAVA_HOME/bin:$PATH"

保存後、反映：

exec $SHELL -l
java -version

(4)MATSim起動

cd ~/matsim-example-project$

java -jar matsim-example-project-0.0.1-SNAPSHOT.jar

(4)テスト起動

「Choose」を押す → リポジトリ内の
scenarios/equil/config.xml を選択。

ちなみに、Output Directoryのは、自動的に、
/home/ebata/matsim-example-project/scenarios/equil/output
が入っていた。

「Start MATSim」のボタンを押下

2～3分後に、こんな感じになった

コンソール画面も、こんな感じになって、入力できない状況

ただ、この段階で、データはできているので、コンソールをCtrl-Cで落しても良い。

で、ここから図示したかったのですが、すったもんだしたあげく失敗したので、via-appを使うようにしました。

で、WSLのUbuntuで、以下からダンロードします。

https://simunto.com/via/download

で、

$CPU=$(dpkg --print-architecture)
$wget https://www.simunto.com/data/via/release/debian/simunto-via-app_25.1.0_${CPU}.deb
$sudo apt install ./simunto-via-app_25.1.0_${CPU}.deb

を実施すると、

$via-app

で、viaが起動します。

ebata@DESKTOP-1QS7OI7:~/matsim-example-project$ export DISPLAY=:0
ebata@DESKTOP-1QS7OI7:~/matsim-example-project$ export LIBGL_ALWAYS_INDIRECT=1

ebata@DESKTOP-1QS7OI7:~/via-app

も必要かもしれない。

"output_network.xml.gz"を選択

同じ様に、

"output_events.xml.gz"

を選択する。

上図のように、"Load Data"ボタンを押して下さい。

上図のようにタイムラインが表示され、08:00から数分間のみ、自動車が表示されます。右側のインジケータを若干右に移動させると、移動の様子(といっても表われて消えているだけの様子)が見えます。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE config SYSTEM "http://www.matsim.org/files/dtd/config_v2.dtd">
<config>
  <module name="controller">
    <param name="firstIteration" value="0"/>
    <param name="lastIteration"  value="0"/>
    <param name="overwriteFiles" value="overwriteExistingFiles"/>
    <param name="outputDirectory" value="output/simple1"/>
  </module>

  <module name="network">
    <param name="inputNetworkFile" value="network.xml"/>
  </module>

  <module name="plans">
    <param name="inputPlansFile" value="plans.xml"/>
  </module>

  <module name="qsim">
    <param name="startTime" value="00:00:00"/>
    <param name="endTime"   value="24:00:00"/>
  </module>

  <!-- 旧 strategy → replanning に修正済み -->
  <module name="replanning">
    <param name="maxAgentPlanMemorySize" value="1"/>
  </module>

  <!-- scoring に h / w を定義 -->
  <module name="scoring">
    <parameterset type="activityParams">
      <param name="activityType" value="h"/>
      <param name="typicalDuration" value="12:00:00"/>
    </parameterset>
    <parameterset type="activityParams">
      <param name="activityType" value="w"/>
      <param name="typicalDuration" value="08:00:00"/>
      <param name="openingTime" value="07:00:00"/>
      <param name="closingTime" value="18:00:00"/>
    </parameterset>
  </module>
</config>

この `config.xml` は、MATSim（Multi-Agent Transport Simulation）の実行設定を記述したファイルです。内容をセクションごとに整理すると次のようになります。

---

### 1. `<module name="controller">`

シミュレーション全体の制御に関する設定。

* `firstIteration=0`
最初のイテレーション番号を 0 に設定。
* `lastIteration=0`
最後のイテレーションも 0 にしているので、学習や繰り返しは行わず、初期の状態のみを実行する（ワンショットのシミュレーション）。
* `overwriteFiles=overwriteExistingFiles`
出力ディレクトリに既存のファイルがあっても上書きする設定。
* `outputDirectory=output/simple1`
シミュレーション結果の出力先フォルダ。

---

### 2. `<module name="network">`

利用する交通ネットワークデータの指定。

* `inputNetworkFile=network.xml`
道路やリンク構造が記載されたネットワーク定義ファイル。

---

### 3. `<module name="plans">`

エージェント（個人）の行動計画データの指定。

* `inputPlansFile=plans.xml`
各エージェントの出発地・目的地・活動スケジュールを記載したプランファイル。

---

### 4. `<module name="qsim">`

シミュレーション実行時間の設定。

* `startTime=00:00:00`
シミュレーション開始時刻を午前 0 時に設定。
* `endTime=24:00:00`
シミュレーション終了時刻を 24 時に設定（丸一日分を対象にする）。

---

### 5. `<module name="replanning">`

プラン修正（replanning）の設定。
※旧名称 `strategy` が `replanning` に変更されたもの。

* `maxAgentPlanMemorySize=1`
各エージェントが保持できるプランの数を 1 に制限（つまり再計画はせず、最初のプランをそのまま利用）。

---

### 6. `<module name="scoring">`

エージェントが行動を評価するためのスコアリング設定。ここでは活動（activity）のパラメータを定義している。

* `activityType=h`
「h」（home、自宅滞在）活動を 12 時間の典型的持続時間で設定。
* `activityType=w`
「w」（work、仕事）活動を 8 時間の典型的持続時間で設定。
また、開店時間を 7:00、閉店時間を 18:00 とすることで、仕事に従事できる時間帯の制約を表現。

---

### 総合説明

この設定ファイルは、**1日分の単発シミュレーション**を対象とし、ネットワークとプランデータを与え、再計画を行わずに実行するシンプルなケースを記述している。活動は「自宅（h）」と「仕事（w）」の2種類のみで、典型的な1日の行動（12時間の在宅と8時間の勤務）を再現する構成になっている。

---

?? 要するに、この `config.xml` は \*\*「network.xml」と「plans.xml」を入力として、エージェントが自宅と仕事の往復を行う1日シミュレーションを出力/simple1 に結果保存する」\*\*ための設定ファイルです。

[config.xml]

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE network SYSTEM "http://www.matsim.org/files/dtd/network_v2.dtd">
<network name="tiny-net">
  <nodes>
    <node id="1" x="0.0"    y="0.0"/>
    <node id="2" x="1000.0" y="0.0"/>
  </nodes>

  <links>
    <!-- 1km、自由速度15m/s ≒ 54km/h、容量 1000veh/h、1車線 -->
    <link id="1_2" from="1" to="2" length="1000.0" freespeed="15.0"
          capacity="1000.0" permlanes="1" modes="car"/>
    <link id="2_1" from="2" to="1" length="1000.0" freespeed="15.0"
          capacity="1000.0" permlanes="1" modes="car"/>
  </links>
</network>

この `network.xml` は、MATSim で利用する交通ネットワークを記述したファイルで、最小限の「2ノード・2リンク」からなる非常にシンプルなネットワークを定義しています。内容を整理すると以下の通りです。

---

### 1. `<network name="tiny-net">`

ネットワーク全体の名前として `"tiny-net"` を定義。小規模なテスト用ネットワークであることを示す。

---

### 2. `<nodes>`

ノード（交差点や地点）を定義。ここでは2つのノードがある。

* `<node id="1" x="0.0" y="0.0"/>`
座標 (0,0) にあるノード。IDは `1`。
* `<node id="2" x="1000.0" y="0.0"/>`
座標 (1000,0) にあるノード。IDは `2`。
→ ノード間は直線で 1000m（=1km）離れている。

---

### 3. `<links>`

ノード間を結ぶリンク（道路）を定義。2本のリンクが双方向に設定されている。

* `<link id="1_2" from="1" to="2" ... />`
ノード1からノード2へ向かうリンク。

* 長さ：`1000.0` m （1km）
* 自由速度：`15.0` m/s ≒ 54 km/h
* 容量：`1000.0` 台/時 （1時間あたりの通過可能車両数）
* 車線数：`1`
* 利用可能モード：`car` のみ
* `<link id="2_1" from="2" to="1" ... />`
ノード2からノード1へ戻るリンク。条件は上記と同じ。

---

### まとめ

このファイルは、**1kmの直線道路を2ノードで表現し、車が双方向に走行できるようにした最小限の道路ネットワーク**を定義している。速度や容量も現実的な数値（片側1車線、時速54km、1000台/時）で設定されており、テストや学習用のシミュレーションに適したネットワーク構成になっている。

?? 要するに「**ノード1とノード2を結ぶ片側1車線の道路（往復2車線）だけのシンプルネットワーク**」です。

[plans.xml]

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plans SYSTEM "http://www.matsim.org/files/dtd/plans_v4.dtd">
<plans>
  <person id="1">
    <plan selected="yes">
      <act type="h" link="1_2" x="0.0" y="0.0" end_time="08:00:00"/>
      <leg mode="car"/>
      <act type="w" link="2_1" x="1000.0" y="0.0" end_time="17:00:00"/>
      <leg mode="car"/>
      <act type="h" link="1_2" x="0.0" y="0.0"/>
    </plan>
  </person>
</plans>

この `plans.xml` は、MATSim におけるエージェント（人物）の行動計画を記述したファイルです。内容を整理すると以下のようになります。

---

### 1. `<plans>` ルート要素

計画ファイル全体を示すルート。内部に個々の人物（`<person>`）とその行動計画（`<plan>`）を記述。

---

### 2. `<person id="1">`

ID が `1` の人物を定義。ここでは 1 人だけ。

---

### 3. `<plan selected="yes">`

この人物の計画（行動スケジュール）を記述。

* `selected="yes"` → このプランが実行対象として選択されている。

---

### 4. 行動と移動の流れ

計画は **行動（`<act>`）と移動（`<leg>`）が交互に記述**される。ここでは1日の典型的な「自宅→仕事→自宅」往復を表現している。

#### (1) 自宅での行動

```xml
<act type="h" link="1_2" x="0.0" y="0.0" end_time="08:00:00"/>
```

* `type="h"`：自宅（home）活動。
* `link="1_2"`：ノード1→2のリンク上に自宅があると仮定。
* 座標 `(0.0, 0.0)`（ノード1の位置に対応）。
* `end_time="08:00:00"` → 午前8時まで自宅に滞在し、その後移動を開始。

#### (2) 通勤移動

```xml
<leg mode="car"/>
```

* `mode="car"` → 自動車で移動する。
* 出発地点は自宅（link="1\_2"）、目的地は次の `<act>` で指定。

#### (3) 仕事での行動

```xml
<act type="w" link="2_1" x="1000.0" y="0.0" end_time="17:00:00"/>
```

* `type="w"`：仕事（work）活動。
* `link="2_1"`：ノード2→1のリンク上に職場があると仮定。
* 座標 `(1000.0, 0.0)`（ノード2の位置に対応）。
* `end_time="17:00:00"` → 午後5時まで仕事をして、その後帰宅移動。

#### (4) 帰宅移動

```xml
<leg mode="car"/>
```

* 仕事先から自動車で自宅へ戻る。

#### (5) 自宅での行動（帰宅後）

```xml
<act type="h" link="1_2" x="0.0" y="0.0"/>
```

* 再び自宅（link="1\_2"）で活動。
* 終了時刻は未設定なので、そのまま夜間～翌日まで滞在。

---

### まとめ

この `plans.xml` は、**1人の人物（id=1）が「午前8時に自宅を出発 → 車で職場へ通勤 → 午後5時まで勤務 → 車で帰宅 → 以降は自宅で滞在」する一日の行動計画**を記述している。

ネットワーク（`network.xml`）と組み合わせると、ノード1（自宅）とノード2（職場）の間を往復する最小限の通勤シナリオが再現できる構成になっている。

---

kno

以下のMATSimのplans.xmlの内容を説明して下さい。

<?xml version="1.0" ?>
<!DOCTYPE plans SYSTEM "http://www.matsim.org/files/dtd/plans_v4.dtd">
<plans xml:lang="de-CH">
  <person id="1">
	<plan>
      <act type="h" link="1" end_time="06:00" />
      <leg mode="car">
      </leg>
  
      <act type="w" link="10" dur="00:00:10" />
      <leg mode="walk">
      </leg>
	  
      <act type="w" link="11" dur="00:00:05" />
	  
      <leg mode="car">
		<!-- ここは書かない（MATSim に任せる） -->
      </leg>
	  
      <act type="h" link="11" />
	</plan>
  </person>

  <person id="2">
	<plan>
      <act type="h" link="10" end_time="06:00" />
      <leg mode="car">
		<route> </route>
      </leg>
	  
      <act type="w" link="11" dur="00:00:10" />
	  
      <leg mode="walk">
		<route> </route>
      </leg>
	  
      <act type="w" link="100" dur="00:00:05" />
	  
      <leg mode="car">
		<!-- ここは書かない（MATSim に任せる） -->
      </leg>
	  
      <act type="h" link="11" />
	</plan>
  </person>


</plans>

以下は、提示された MATSim の plans.xml の内容を、構造・意味・挙動の3点から整理して説明する。

1. ファイル全体の位置づけ

<!DOCTYPE plans SYSTEM "http://www.matsim.org/files/dtd/plans_v4.dtd">
<plans xml:lang="de-CH">

<person id="X">
  <plan>
    <act ... />
    <leg mode="..." />
    <act ... />
    ...
  </plan>
</person>

• person
  → エージェント（個人）

• plan
  → その人の1日の行動シーケンス

• act（activity）
  → 滞在行動（自宅、職場など）

• leg
  → 活動間の移動

• act と leg は必ず交互に出現する

3. person id="1" の行動計画

(1) 最初の自宅活動

<act type="h" link="1" end_time="06:00" />

• type="h"
  → home（自宅）

• link="1"
  → network.xml の link id=1 上で活動

• end_time="06:00"
  → 06:00 に出発

(2) 自宅 → 職場（車）

<leg mode="car">
</leg>

• 移動手段：car

• <route> が書かれていない
  → MATSim が network.xml と travel time を使って経路を自動生成

(3) 職場活動①

<act type="w" link="10" dur="00:00:10" />

• type="w"：work（職場）

• link="10"

• dur="00:00:10"
  → 10秒だけ滞在

• end_time ではなく dur が指定されている点に注意
  → 開始時刻＋滞在時間で終了時刻が決まる

(4) 徒歩移動

<leg mode="walk">
</leg>

• 徒歩移動

• 経路は MATSim が内部で処理
  （多くの場合、距離÷歩行速度の単純計算）

(5) 職場活動②（短時間）

<act type="w" link="11" dur="00:00:05" />

• 別リンク（11）での職場活動

• 滞在時間は 5秒

(6) 再び車移動（経路指定なし）

<leg mode="car">
  <!-- ここは書かない（MATSim に任せる） -->
</leg>

• 車移動

• 経路は再計算対象

• replanning が有効なら、反復ごとに経路が変わりうる

(7) 帰宅

<act type="h" link="11" />

• 自宅活動（終了時刻なし）

• シミュレーション終了まで滞在

4. person id="2" の行動計画の特徴

person 2 は、person 1 と似ているが、route タグが明示的に存在する点が重要。

(1) 車移動（空の route）

<leg mode="car">
  <route> </route>
</leg>

• <route> タグは存在するが中身は空

• この場合：

  • 初期状態では意味のある経路情報はない

  • MATSim は 初回の routing で上書きする

• 実質的には <route> を書かない場合とほぼ同等

(2) 徒歩移動（空 route）

<leg mode="walk">
  <route> </route>
</leg>

• 徒歩でも route を書けるが、

  • 多くのケースで MATSim は 詳細なリンク列を保持しない

  • travel time は内部計算

(3) 行動リンクの違い

<act type="w" link="100" dur="00:00:05" />

• person 1 とは異なるリンク構成

• network 上での空間的な差異を与えている

5. この plans.xml が意味する「本質」

(1) これは OD を完全に固定した計画ではない

• 出発時刻・滞在時間・モードは指定されている

• しかし：

  • 経路（link 列）は未確定

  • travel time はシミュレーション中に決定

(2) walk leg の扱い

• 多くの場合：

  • network を厳密に辿らない

  • link ベースの距離計算 or 直線近似

• そのため：

  • 正確な歩行経路ログは events.xml に残らないことが多い

(3) RCM / 共時空間解析への影響

• act の link と time は明示されている
  → 滞在の共時性は評価可能

• leg（特に walk）の詳細な軌跡は失われやすい
  → 移動中の「出会い」解析には不向き

6. まとめ（要点）

• この plans.xml は
  「行動の骨格だけを与え、移動の詳細は MATSim に委ねる」 設計

• route を書かない／空にするのは一般的

• 車移動はネットワークに基づくが
  徒歩移動は簡略化される

• 接触機会を「活動滞在ベース」で評価する用途向き

• 移動中の微細な接触解析には構造的制約がある

<attribute name="type" class="java.lang.String">residential</attribute> <attribute name="type" class="java.lang.String">primary</attribute> <attribute name="type" class="java.lang.String">tertiary</attribute> のアトリビュートの種類について説明をお願いします。
また、 <link id="203" from="1806698497" to="1806698523" length="159.5139984301562" freespeed="11.11111111111111" capacity="1000.0" permlanes="1.0" oneway="1" modes="car"> の各パラメータについても説明をお願いします。

以下、OSM → MATSim 変換後の network.xml を読むための実務向け説明として整理します。
定義論ではなく、「MATSim で何に使われ、どう効くか」を軸に書きます。

1. <attribute name="type"> とは何か

<attribute name="type" class="java.lang.String">residential</attribute>
<attribute name="type" class="java.lang.String">primary</attribute>
<attribute name="type" class="java.lang.String">tertiary</attribute>

結論

これは OSM の highway=* タグを、そのまま MATSim の link attribute として持ち込んだものです。

MATSim 標準の OsmNetworkReader は、

• OSM の highway タグ

• → MATSim link の attribute type

として保存します。

2. 各 type の意味（OSM 的・交通工学的）

以下は OSM の公式定義＋実務的な解釈です。

2.1 residential

• 住宅地内道路

• 生活道路

• 低速・低容量

• 交差点密度が高い

OSM 的には：

people live here

MATSim 的には：

• freespeed が低め

• capacity も控えめ

• 渋滞のボトルネックになりやすい

2.2 tertiary

• 地区幹線道路

• 住宅地と幹線をつなぐ役割

• 生活道路よりは速いが、主要幹線ではない

OSM 的には：

connects neighbourhoods

MATSim 的には：

• 中程度の freespeed

• 通過交通と生活交通が混在

2.3 primary

• 主要幹線道路

• 都市間・都市内の主要動脈

• 信号・交差点はあるが、通過交通向き

OSM 的には：

major roads between towns or important parts of a city

MATSim 的には：

• freespeed が高い

• capacity も高い

• 交通流を支配するリンクになりやすい

2.4 重要なポイント（研究用途的に）

• この type は MATSim の挙動に直接は使われない

• しかし：

  • 後処理

  • 可視化

  • フィルタリング

  • 分析（例：primary だけ抽出）

で 極めて重要

「MATSim が計算に使う値」ではなく
「人間が意味づけするための属性」

という位置づけです。

3. <link ...> 各パラメータの意味

対象：

<link id="203"
      from="1806698497"
      to="1806698523"
      length="159.5139984301562"
      freespeed="11.11111111111111"
      capacity="1000.0"
      permlanes="1.0"
      oneway="1"
      modes="car">

3.1 id="203"

• MATSim が内部的に振った link ID

• OSM の way ID ではない

• 識別子としてのみ使用

3.2 from, to

from="1806698497"
to="1806698523"

• MATSim network の node ID

• 今回は OSM node ID と一致

• 有向リンク（from → to）

3.3 length="159.51"

• リンク長 [m]

• CRS 変換後の座標距離から計算

• MATSim の移動時間・距離計算の基礎

重要：

• 現実の道路長と完全一致するとは限らない

• 曲線道路は直線近似されている

3.4 freespeed="11.11111111111111"

• 自由流速度 [m/s]

• 11.11 m/s ≒ 40 km/h

計算：

11.111... × 3.6 = 40 km/h

modes="car,bus"
modes="walk,bike"

4. MATSim 的に「効くパラメータ」「効かないパラメータ」

計算に直接効く

• length

• freespeed

• capacity

• permlanes

• modes

計算に直接は効かない（が超重要）

• attribute type（primary / residential など）

5. 全体の理解（重要）

この1本の link は、MATSim 的には：

「from node 1806698497 から to node 1806698523 へ
長さ約160m、自由流40km/h、容量1000veh/h、
車1車線の一方通行道路（住宅・幹線種別あり）」

という 完全に交通工学的な抽象道路です。

OSM の複雑な現実を、

• node

• directed link

• 数値パラメータ

に落とし込んだものが MATSim network です。

6. 次に自然な関心点

ここまで理解できたら、次は自然に：

• type ごとの freespeed / capacity の妥当性

• residential が速すぎないか？

• primary が遅すぎないか？

• bus を入れたらどう変わるか？

という **「モデルの現実性」**の話に進めます。

次はどこを見ますか？

• パラメータ調整？

• network の可視化？

• bus / pt network の追加？

network.xmlでは、全部、oneway="1"になっていますが、これで正しいのでしょうか？

結論から言います。

はい、現状の oneway="1" が並んでいるのは「異常ではない」が、
そのまま受け入れてよいかは「目的次第」です。

これは MATSim + OSM 変換で 非常によくある・意図された挙動です。
以下、理由と「何が起きているのか」を段階的に説明します。

1. まず重要な前提（誤解しやすい点）

❌ 誤解

OSM の道路は双方向が多い
→ network.xml も oneway="0" が多いはず

✅ 実際

MATSim の network は「有向リンク」が基本
→ 双方向道路でも「片方向リンク × 2本」で表現する

2. MATSim における「oneway」の意味

<link ... oneway="1" />

この oneway="1" は、

「この link オブジェクトは一方向リンクである」

という意味であり、

「この道路が現実世界で一方通行である」

という意味ではありません。

ここが最大の混乱ポイントです。

3. 双方向道路はどう表現されているか

OSM 側（例：residential, oneway 指定なし）

highway=residential
(oneway タグなし = 双方向)

MATSim 側では…

2本の link に分解されます

<link id="203" from="A" to="B" oneway="1" />
<link id="204" from="B" to="A" oneway="1" />

つまり：

👉 だから「全部 oneway=1」に見える

4. では「oneway=0」はいつ出るのか？

MATSim network では、実は：

• oneway="0" は ほぼ使われません

• 双方向性は link の本数で表現します

oneway="0" が出るケースは：

• 古い network

• 手書き network

• 特殊なカスタム実装

OSM → OsmNetworkReader → network.xml
という正統ルートでは、基本的に すべて oneway="1" になります。

5. OSM の oneway=yes はどう反映されているか

OSM が一方通行の場合

highway=primary
oneway=yes

MATSim では：

<link from="A" to="B" oneway="1" />

逆向きリンクは作られません

👉 結果として：

• 双方向道路：link が2本

• 一方通行道路：link が1本

どちらも oneway="1"

6. 正しいか？という問いへの答え

技術的に正しいか？

✅ 正しい

• MATSim の設計通り

• OsmNetworkReader の標準挙動

• 世界中の MATSim network がこうなっている

交通モデルとして正しいか？

✅ 目的次第で正しい

• 経路探索：問題なし

• 混雑生成：問題なし

• 方向制約：正しく表現されている

研究・説明的に誤解を招かないか？

⚠️ 説明は必要

論文・資料では必ずこう書くべきです：

「MATSim network は有向リンクで構成されており、
双方向道路は2本の一方向リンクとして表現されている」

7. 確認したい場合のチェック方法

(1) 同じ node ペアの逆向き link があるか

zgrep 'from="1806698497" to="1806698523"' output_network.xml.gz
zgrep 'from="1806698523" to="1806698497"' output_network.xml.gz

• 両方あれば → 双方向道路

• 片方だけ → 一方通行道路

8. まとめ（重要）

• oneway="1" が並ぶのは 正常

• MATSim は 有向リンク前提

• 双方向性は link の本数で表現

• OSM の oneway 情報は 逆向き link の有無に反映

• network.xml を見て不安になるのは 誰もが通る道

これはむしろ、

「network.xml をちゃんと読めている証拠」

です。

次に気になるのはたいてい：

• 「residential が速すぎないか？」

• 「capacity は現実的か？」

• 「bus を入れたらどうなるか？」

どれに進みますか？

network.xmlには、modes="car" になっています。エージェントで歩行をさせたい場合はどうすれば良いですか？

結論から言います。

いまの modes="car" の network.xml のままでは、歩行エージェントは動けません。
歩行をさせるには、network 側と設定（plans / config）の両方を整える必要があります。

以下、「何をどう変えるか」を 実務手順として説明します。

1. なぜ歩行できないのか（前提）

いまの network.xml では、各リンクが例えばこうなっています。

<link ... modes="car" />

MATSim の原則は：

エージェントは、自分の legMode が含まれるリンクしか通れない

つまり：

👉 歩行をさせるには、link に walk を含める必要がある

2. 方法は大きく3つある（重要）

方法A（最も正統・おすすめ）

network 作成時に walk を含める

あなたの Osm2NetworkCli は CLI で --modes を受け取れる構成です。

実行例

java -jar target/matsim-osm2network-1.0.0.jar \
  --osm hirohakama.osm \
  --out output_network.xml.gz \
  --toCRS EPSG:6685 \
  --modes car,walk

すると network.xml は：

<link ... modes="car,walk" />

になります。

✅ 車も歩行も同じ network を共有
✅ 最も MATSim 的
✅ 将来 bike / bus を足しやすい

方法B（歩行専用 network を作る）

--modes walk

• 歩行だけの network

• 車と完全に分離

これは：

• 歩行分析専用

• 車両流と干渉させたくない場合

に使います。

方法C（後処理で network.xml を書き換える）※非推奨

modes="car" → modes="car,walk"

を一括置換する方法。

❌ 再現性が低い
❌ 論文・研究向きでない
❌ 将来の自分が困る

3. network を直しただけでは「まだ足りない」

ここが重要ポイントです。

3.1 エージェント（plans.xml）側

歩行 leg はこうなっている必要があります。

<leg mode="walk">

3.2 config.xml 側（必須）

(1) qsim に walk を許可

<module name="qsim">
  <param name="mainModes" value="car,walk" />
</module>

(2) routing の設定

<module name="planscalcroute">
  <param name="networkModes" value="car,walk" />
</module>

(3) walk の速度（重要）

<module name="planscalcroute.walk">
  <param name="teleportedModeSpeed" value="1.34" />
</module>

※ 1.34 m/s ≒ 4.8 km/h（標準的歩行速度）

4. 歩行を「network 上で歩かせる」か「テレポート」にするか

MATSim では歩行に 2通りあります。

A. network walk（物理的にリンクを歩く）

• 渋滞・交差点を考慮

• 車と空間を共有

• 計算コスト高

👉 研究用途・都市スケール分析向き

B. teleported walk（距離÷速度）

• network を使わない

• 最短距離直線 or 軽量計算

• 計算コスト低

👉 大量人口・簡易分析向き

今の network を使うなら、あなたは A を選ぶ立場です。

5. 実務的なおすすめ手順（あなた向け）

① network を作り直す（最重要）

--modes car,walk

② config.xml に walk を追加

• qsim

• planscalcroute

• planscalcroute.walk

③ plans.xml に <leg mode="walk"> を入れる

6. まとめ（要点）

• modes="car" の network では歩行不可

• network 作成時に walk を含めるのが正道

• network / config / plans の3点セットが必要

• 歩行は MATSim では「特別扱い」されがちなので注意

• あなたの network 生成ツールは すでに walk 対応可能

Javaを使ったMATSim network.xml.gz 構築手順メモ（hirohakama）

1. 目的

OpenStreetMap から取得した OSM ファイルを入力として、
MATSim で利用可能な network.xml.gz を安定的・再現可能に生成する。

対象は以下。

• 入力：hirohakama.osm

• 出力：output_network.xml.gz

• 座標系：EPSG:6685（日本測地系・平面直角座標）

• 利用モード：car

2. なぜ Python プログラムではなく、MATSim 公式 API を使うのか

2.1 当初の疑問

• OSM → network 変換は Python でも書ける

• 実際、Python 版の変換スクリプトもすでに作成済み

• それでも MATSim の有効性を示すなら、公式ツールを使うべきではないか？ という疑問が生じた

2.2 結論

network.xml は「MATSim の内部仕様そのもの」であり、
MATSim 自身が生成した network.xml を使うことに意味がある

理由：

1. リンク属性（freespeed / capacity / lanes / allowedModes）の解釈が MATSim と完全一致

2. 将来 MATSim のバージョンが変わっても、
   network.xml の生成ロジックが MATSim 側で追従される

3. 論文・研究・再現性の観点で

   「MATSim 標準の OsmNetworkReader を用いて生成した network を使用した」
   と明記できる

結論として、

Python は補助・可視化・後処理に使う
network.xml の生成は MATSim に任せる

という役割分担にした。

3. 現在のディレクトリ構成（WSL）

/home/ebata/matsim-example-project/hirohakama/
├── hirohakama.osm
├── pom.xml
├── target/
│   ├── matsim-osm2network-1.0.0.jar
│   └── original-matsim-osm2network-1.0.0.jar
└── src/
    └── main/
        └── java/
            └── net/
                └── kobore/
                    └── matsim/
                        └── Osm2NetworkCli.java

補足（Windows から見たパス）

\\wsl$\Ubuntu\home\ebata\matsim-example-project\hirohakama\

4. 各ファイルの役割

4.1 hirohakama.osm

• OpenStreetMap からダウンロードした生の地図データ

• XML 形式

• 今後、エリアを変えればこのファイルだけ差し替える

4.2 Osm2NetworkCli.java

パス：

src/main/java/net/kobore/matsim/Osm2NetworkCli.java

役割：

• MATSim の OsmNetworkReader をラップした CLI（コマンドラインツール）

• 以下を担当：

  • OSM 読み込み

  • 利用 highway の限定

  • モード指定（car 等）

  • CRS 変換（EPSG:4326 → EPSG:6685）

  • network.xml.gz の出力

このファイルは：

• 今後 network の作り方を変えたくなった時に編集する

• 普段は直接触らない

• しかし 残しておく必要がある（再ビルド用）

4.3 pom.xml

役割：

• Maven のビルド定義

• 以下を明示的に設定している：

  • Java 17

  • MATSim 15.0

  • GeoTools EPSG 辞書（gt-epsg-hsql）

  • OSGeo リポジトリ

  • Shade Plugin（fat jar 作成）

  • 署名ファイル除外（Invalid signature file digest 対策）

  • Main class 指定

この pom.xml によって「java -jar で動く単一 JAR」が作られる

4.4 target/matsim-osm2network-1.0.0.jar

役割：

• 実行ファイル

• network.xml.gz を作るだけなら これだけあれば良い

• Java ソースを触らない限り、再ビルド不要

5. ビルド手順（必要な場合のみ）

Java ソースを変更した場合のみ実行。

cd /home/ebata/matsim-example-project/hirohakama
mvn -q -DskipTests clean package

成功すると：

target/matsim-osm2network-1.0.0.jar

が生成される。

6. network.xml.gz の生成手順（通常作業）

cd /home/ebata/matsim-example-project/hirohakama

java -jar target/matsim-osm2network-1.0.0.jar \
  --osm hirohakama.osm \
  --out output_network.xml.gz \
  --toCRS EPSG:6685 \
  --modes car

実行ログ例

[INFO] OSM      : hirohakama.osm
[INFO] OUT      : output_network.xml.gz
[INFO] toCRS    : EPSG:6685
[INFO] modes    : [car]
[INFO] highways : [motorway, motorway_link, trunk, ...]

成功すると、同ディレクトリに

output_network.xml.gz

が生成される。

7. 深いディレクトリ構造についての補足メモ

src/main/java/net/kobore/matsim/

という深さは、

• Maven の規約

• Java の package とディレクトリの 1 対 1 対応

• クラス名衝突防止（世界規模）

という Java の設計思想そのもの。

個人研究・小規模用途としては冗長だが、

• MATSim

• GeoTools

• Java エコシステム

と共存する以上、受け入れるのが最短ルート。

8. 今後の使い方方針（整理）

• OSM を変える
  → hirohakama.osm を差し替える

• network 条件を変える
  → Osm2NetworkCli.java を編集 → mvn package

• 普段の作業
  → jar を実行するだけ

9. まとめ（判断の記録）

• Python 版は「自分で制御できる」利点がある

• しかし MATSim network の正当性・再現性・説明責任を考え、

  • network 生成は MATSim API に委ねた

• この Java プログラムは
  「network.xml を作るためだけの専用工具」

• 一度作ってしまえば、運用は極めて単純

高齢者によるアクセルとブレーキの踏み間違いによる事故が後を断ちません。
Accidents caused by elderly drivers mistakenly pressing the accelerator instead of the brake continue unabated.

国内では、以下のような重大事故が実際に発生しています。
In Japan, the following serious accidents have actually occurred.

(1) 2019年4月19日、東京都豊島区池袋で、高齢ドライバーがアクセルとブレーキを踏み間違え、横断歩道に突入し、母子2人が死亡、複数人が重軽傷を負う事故が発生しました（池袋暴走事故）。
(1) On April 19, 2019, in Ikebukuro, Toshima Ward, Tokyo, an elderly driver mistakenly pressed the accelerator instead of the brake and crashed into a crosswalk, killing a mother and her child and injuring several others (the Ikebukuro runaway car accident).

(2) 2019年6月22日午後0時40分ごろ、福岡県北九州市八幡西区で、高齢男性が運転する車がスーパーマーケットの駐車場でアクセルを踏み続け、歩行者をはねる事故が発生しました。
(2) Around 12:40 p.m. on June 22, 2019, in Yahatanishi Ward, Kitakyushu City, Fukuoka Prefecture, a car driven by an older man continued accelerating in a supermarket parking lot and struck a pedestrian.

(3) 2021年11月25日午後2時30分ごろ、神奈川県横浜市戸塚区で、高齢ドライバーの車が国道沿いの歩道に突入し、バス停で待っていた歩行者が巻き込まれ、複数人が死傷する事故が起きました。
(3) Around 2:30 p.m. on November 25, 2021, in Totsuka Ward, Yokohama City, Kanagawa Prefecture, a car driven by an older adult veered onto a sidewalk along a national highway, hitting pedestrians waiting at a bus stop and causing multiple deaths and injuries.

(4) 2025年12月10日午後3時ごろ、福岡県宗像市で、高齢ドライバーがアクセルとブレーキを踏み間違え、スーパーマーケットの出入口に車が突っ込み、買い物客が負傷しました。
(4) Around 3:00 p.m. on December 10, 2025, in Munakata City, Fukuoka Prefecture, an elderly driver mistakenly pressed the accelerator instead of the brake, crashing into the entrance of a supermarket and injuring shoppers.

当然のことながら、海外でも同種の事故は発生しています。
Naturally, similar accidents have occurred overseas as well.

(5) 2003年7月16日、米国カリフォルニア州サンタモニカで、高齢ドライバー（86歳）の車がファーマーズマーケットの歩道に突入し、10人が死亡、60人以上が負傷しました（サンタモニカ・ファーマーズマーケット事故）。
(5) On July 16, 2003, in Santa Monica, California, USA, a car driven by an elderly driver (86 years old) crashed into a sidewalk at a farmers’ market, killing 10 people and injuring more than 60 (the Santa Monica Farmers Market crash).

これらの事故は低速域・日常空間で発生することが多く、被害者が歩行者である点に共通性があります。
These accidents often occur at low speeds in everyday spaces, and they share the common feature that the victims are pedestrians.

このような事故について『決定的な対策が打てない理由』については、こちらに記載しています。
The reasons why "decisive countermeasures cannot be implemented" for such accidents are described here.

(↑ Click on the column)

---

私が不思議に思っているのは、『このような事故は、現在の技術で簡単に止められるのではないか』ということなのです。
What I find puzzling is this: aren’t accidents like these easily preventable with current technology?

最近の自動車のブレーキやアクセルは、Webに表示されるスライダ(ボリューム)のように扱われています。ブレーキやアクセルにかかる負荷を信号に変えて、自動車のコンピュータ(ECU：Electronic Control Unit（電子制御ユニット）)に伝えられているだけです。
In modern cars, the brake and accelerator are treated much like sliders (volume controls) displayed on a web interface. The force applied to the brake or accelerator is converted into a signal and sent to the car’s computer (ECU: Electronic Control Unit).

もう少し正確に書きましょう。
Let me describe this a bit more precisely.

(1)アクセルペダルは、機械的にスロットルを直接引いておらず、踏み込み量をセンサで検出する入力装置に過ぎません。ECU が信号を解釈し電子制御スロットルを動かすという ドライブ・バイ・ワイヤ（Drive-by-Wire）方式を採用しています。
(1) The accelerator pedal does not mechanically pull the throttle directly; it is merely an input device that detects how far it is pressed via sensors. The ECU interprets the signal and moves the electronically controlled throttle, using a drive-by-wire system.

一方、
On the other hand,

(2)ブレーキは、ブレーキペダル → 油圧 → ブレーキという 機械系が依然として残っていますが、同時にABS、ESC、自動ブレーキ（AEB）などが ECUにより強制介入します。
(2) The braking system still retains a mechanical structure?brake pedal → hydraulic pressure → brakes?but at the same time, systems such as ABS, ESC, and automatic emergency braking (AEB) forcibly intervene under ECU control.

ペダル操作は電気信号として ECU（Electronic Control Unit）に送られ、実際の加速や減速はコンピュータが制御しているのです。
Pedal operations are sent to the ECU, which controls electrical signals and actual acceleration and deceleration.

つまり、ドライバーが踏んでいるのは「力」ではなく「意思」であり、その意思をどう反映させるかの最終判断は車両側に委ねられている ーー つまり、ブレーキやアクセルは、原則として「入力デバイス」であって、実際は、その駆動部の信号が処理されているだけなのです。
In other words, what the driver is applying is not "force" but "intent," and the final decision on how that intent is reflected is left to the vehicle, meaning that the brake and accelerator are, in principle, merely "input devices," and only the signals to the drive system are actually being processed.

最近、すっかり安くなったドライブレコーダと連携すれば、「人混み、店舗、歩道に対して、強いアクセルの信号を検知すれば、それをキャンセルする制御をすることなどは、造作もない」と思うのです。
By linking with dashboard cameras, which have become quite inexpensive recently, it would be trivial to implement control logic that cancels strong accelerator signals when people, shops, or sidewalks are detected.

少なくとも、私のような組み込み系も取り扱うエンジニアにとって、『ECUのプログラムを書き換える』というのは、十分に可能ではあります。実際にアフターマーケットや不正改造で行われています。当然、私程度の技術力でも可能です。
At least for an engineer like me who also works with embedded systems, "rewriting ECU programs" is entirely feasible. It is already done in the aftermarket and through illegal modifications. Naturally, it is possible even with my level of technical skill.

ただし「違法」です。
However, it is "illegal."

そりゃ違法に決まっています。こんなことが、合法であれば、
Of course, it is illegal. If such things were legal,

- 速度リミッターを解除した車や、
- cars with speed limiters removed, or

- 衝突回避機能を意図的に無効化した車や、
- cars with collision avoidance functions intentionally disabled, or

- アクセル入力と実際の駆動出力を乖離させた車
- cars where accelerator input is decoupled from actual drive output

を作るなど、造作もないことです。
Creating such vehicles would be trivial.

悪意で、他人の車のECUにハッキングすれば、簡単に大事故を誘発することも可能でしょう。
With malicious intent, hacking another person’s car ECU could easily trigger a significant accident.

---

しかし、私は、すでに上記の事故を起こし得る当事者となる年齢に至っております。
However, I have already reached an age at which I could become a party responsible for such accidents myself.

合法的に、販売店ディーラーで、ECUのプログラム書き換えをやってくれるのであれば、10万円単位の金を払ってでもお願いしたいです。人を殺傷するコストに比べれば、ゴミのようなコストと言えましょう。
If a dealer were to rewrite the ECU program legally, I would gladly pay tens of thousands of yen. Compared to the cost of killing or injuring someone, it is negligible.

-----

さて、ここから本論です。
Now, here is the main argument.

では、なぜ「この程度の改造ができないのか？」
So why is it impossible to make modifications of this level?

理由は、技術の問題ではありません。責任の問題です。
The reason is not a technical problem. It is a problem of responsibility.

もしディーラーが ECU を書き換え、「人混みでは強制的に加速しない車」を販売したとします。その結果、誤検知で車が止まり、後続車に追突され、事故が起きた場合――その責任は誰が負うのでしょうか。
If a dealer rewrote the ECU and sold a car that does not accelerate forcefully in crowded areas, and as a result, a false detection caused the vehicle to stop and be rear-ended, leading to an accident, who would bear responsibility?

運転者か。ディーラーか。自動車メーカーか。それとも ECU のソフトを書いた技術者か。
The driver? The dealer? The automaker? Or the engineer who wrote the ECU software?

現在の制度では、この問いに明確な答えを出せません。だから、自動車は「最後は人が操作する」という建前を崩せないのです。
Under the current system, there is no clear answer to this question. That is why the premise that "in the end, humans operate cars" cannot be abandoned.

技術的には車は止められます。しかし、止めた結果として起きた事故の責任を、誰も引き受けられない。
Technically, cars can be stopped. However, no one can be held responsible for accidents caused by blocking them.

---

この「責任を引き受けられないために改造できない」という構造は、主に以下の法令によって支えられています。
This structure," modifications cannot be made because responsibility cannot be assumed," is supported mainly by the following laws.

(1) 道路運送車両法および保安基準
(1) Road Transport Vehicle Act and safety standards

自動車は型式指定を受けた状態でのみ公道走行が認められており、ECU を含む制御系のプログラムを書き換えることは、原則として「構造等変更」に該当します。販売店やディーラーがこれを行えば、保安基準違反となり、車両の公道使用は認められません。
Vehicles are allowed on public roads only in their type-approved configuration, and rewriting control programs, including the ECU, generally constitutes a "structural modification." If dealers perform such changes, it violates safety standards, and the vehicle cannot legally be used on public roads.

(2) 製造物責任法(PL法)
(2) Product Liability Act (PL Act)

もしディーラーやメーカーが ECU を改変した車を提供し、その制御によって事故が起きた場合、「欠陥のある製品を提供した」として、メーカーや改変主体が無過失責任を問われる可能性があります。
If a dealer or manufacturer provides a vehicle with a modified ECU and an accident occurs due to that control, the manufacturer or modifier may be held strictly liable for providing a defective product.

このため、販売側は「人の操作に最終責任がある」構造を手放せません。
For this reason, sellers cannot let go of the structure in which final responsibility lies with human operation.

(3) 道路交通法
(3) Road Traffic Act

現行制度では、運転行為の主体はあくまで「人」であり、事故の第一次的責任も運転者に帰属します。車両側が運転判断を上書きする設計を前提にしていないため、強制的な加速キャンセルや停止を常時組み込むことは、制度上、想定されていません。
Under the current system, driving is strictly a human activity, and primary responsibility for accidents lies with the driver. Since vehicle designs do not assume overriding human driving decisions, constant forced acceleration cancellation or stopping is not envisioned institutionally.

これが、この程度の改造ができない理由です。
This is why modifications of this level cannot be implemented.

---

言い換えれば、私たちは「人が誤操作で事故を起こすリスク」よりも、「機械が判断して事故を起こす責任問題」を、まだ社会として受け入れられていないのです。
In other words, as a society, we have not yet accepted responsibility when machines make decisions and cause accidents, even though we take greater risks from human error.

技術はすでにあります。
The technology already exists.

足りないのは、プログラムではなく、覚悟と制度なのです。
What is lacking is not programming, but resolve and institutions.

---

現行の法令のままであれば、基本的に、このような事故はこれからも発生しつづけ、多くの人が死傷することになります。
If current laws remain unchanged, accidents like these will continue to occur, and many people will be killed or injured.

これを回避する手段は、私から見れば『チョロイと言えるほど簡単』なのにそれができません。
From my perspective, the means to avoid this are "so easy they are trivial," yet they cannot be implemented.

まあ、他人のことはどうでもいいです。
Well, other people’s matters don’t really concern me.

取り敢えず、嫁さんと私の為に、違法上等で、確信犯的にECUのハッキングをやってやろうか、と(不穏なことを)考え始めています。
For now, for the sake of my wife and myself, I have even started thinking "dangerously" about deliberately hacking an ECU, legality be damned.

というか、
Or rather,

――私なら本当にやりかねない
"I might really do it."

地元のお巡りさんは、私の家の巡回を頻繁に行った方が良いです。
The local police would do well to patrol around my house frequently.

もし私が、機材やパソコンを、私の自宅の自動車のガレージに展開しながら、車の下に潜っているのを見つけたら、即座に職務質問、任意同行を求めることを、強くお勧めします。
If they find me spreading equipment and computers in my home garage while crawling under my car, I strongly recommend that they immediately conduct a stop-and-question and request voluntary accompaniment.

―― N-BOXには「改造したい」という気持ちが湧いてこない

\\wsl$\Ubuntu\home\ebata\matsim-example-project\scenarios\equil2

output/output_events.xml.gzと、output/output_network.xml.gzを生成したら、
$ go run matsim_events_to_geo_csv.go
で、agent_positions_geo.csv ができたら、999.9_merged_type1.csvにリネームして、

go run server22-1.go → http://localhost:8080
で、
go run pm_proxy_single_socket.go
でエージェントが歩き出す

(続きは明日)

インパール作戦とは、1944年（昭和19年）に日本陸軍がビルマ（現ミャンマー）から英領インドのインパール方面へ侵攻した作戦です。

目的は、英印軍の拠点であるインパールを攻略し、英軍の戦力を分断・弱体化させること、あわせてインド独立運動への影響を期待する点にありました。

主力は第15軍（司令官：牟田口廉也中将）で、険しい山岳地帯と未整備の補給路を越えて進攻したのでうが、補給の破綻、英軍の反攻、モンスーンの到来により壊滅的損害を被り、作戦は失敗に終わりました。

戦後の研究において、このインパール作戦と、それを指揮した牟田口中将は、今なお、批判され続けています。

主な批判点は、以下の通りです。

(1)補給計画の欠如
食糧・弾薬・医療物資の補給が現実的に成り立たず、「現地調達」への過度な依存が兵の大量餓死・病死を招いた。

(2)非現実的な作戦立案
地形・気候（雨季）・敵戦力の分析が甘く、成功可能性の低い作戦を強行した点が批判されている。

(3)上層部の独断と精神主義
現場の反対意見や中止進言が無視され、「精神力で克服できる」とする非合理な判断が続いた。

(4)指揮統制の混乱
作戦途中でも方針が一貫せず、撤退判断が遅れ、被害を拡大させた。

(5)兵士の生命軽視
戦略的成果に比して犠牲が極端に大きく、日本軍史上でも最悪級の失敗例として位置づけられている。

このインパール作成は、ミッドウェイ開戦より、酷い扱いを受けています。で、その理由が

―― 牟田口廉也中将は、戦後においてもインパール作戦の根本的な誤りを認めず、一定の正当化を続けた

という点が挙げられます。

ただ、私は、このことに対して、理非を論じたい訳ではありません。

当時の日本陸軍全体が「精神主義」「上意下達」「兵站軽視」だったのは事実でしたし、その場(戦場)にいなかった私が、軽々しく「戦争責任を内面化できなかった指揮官」と評することはできません。

ーー と、ここまでが前置きです。

-----

私が、このインパール作成のことを覚えているのは、

―― 雨が降りしきり、道行く先には腐敗が進む死体の山

―― 死んでるのは兵士や軍属ばかり

―― 将校と下士官は死んでいない

という内容のメモと、

『小休止後、立ち上がらない兵士が、その場で死んでいた』

という内容を覚えていたからです。

言うまでもないことですが、「小休止が兵士を殺した」というのは、当然ながら「ミスリーディングのロジック」です。

これは、インパール作戦の酷さを語る一節であれば良いのです。

『"部下"のほとんどが餓死している真っ最中にあって、"上司"には食事が与えられ、食べることができる』

-----

昨日から、私がPCとバトルを繰り返しているのは、『PCに小休止を与えないことによる、カーネルパニックを避ける処理』です。

「Windows + Radeon iGPU が“完全アイドル”に入る瞬間を作らない」ことで、負荷が高い時ではなく、何もしていない時に起きるカーネルパニックを回避する方法を、ChatGPTと相談しながら進めています。

不安定な省電力復帰を「起こさせない」ための保険として、"GPU keep-alive 常駐"という処理を組み込んでいます。

つまり、『PCに小休止を与えない』ことで、PCの連続稼働率を上げる作戦です。

-----

で、まあ、このようなPCのセッティングを行っている私(江端)は、牟田口廉也中将みたいなのかな ーー などと思ったりしています。

MINISFORUM HM90 / Windows 11 放置中フリーズ対策・検証メモ