青竹雑記帖(6代目)

テキスト処理をメインとしたIT解説をします。

西鉄電車データベース・運用関係資料出力システム実装中

ご無沙汰しております。7月後半に発生した多忙状態を無事倒し、そこから1週間かけて状態異常を回復しました。

状態異常回復期間中に、西鉄電車の時刻表データベースシステムの製作を大いに進めました。これは、私が作成する西鉄電車の車両運用関係諸資料(車両運用表・車両運用図表【箱ダイヤ】・列車編成両数表)および全列車一覧形式の時刻表を一括生成することを企図して構築したものです。これは次の機能を持ちます。現在、昨年の試作システムからの移植、および新規実装部分の構築を進めています。

  • 車両運用表の出力(昨年の試作システムから移植実施予定)
  • 列車編成両数表の出力(出力実装完了、LaTeXソースコード生成部移植実施予定)
  • 車両運用図表用グラフの出力(昨年の試作システムから移植実施予定)
  • 全列車一覧形式の時刻表出力(LaTeXソースコード生成に成功)
  • 車両運用情報入りの駅別時刻表生成(実装完了)

私が西鉄電車の車両運用を本格的に追い始めて早十年、各種運用資料を作るようになってから八年が経ちました。当初は運用調査成果をもとにすべて手作業で打ち込んでいましたが、列車が1日数百本走る路線の全列車を入力するのは非常に大変で、作成後の自分の手での校正により数十箇所の誤植を訂正しつつもさらに誤植が残るありさまでした。悪い時には総誤植数が百箇所近くに達していたこともあり、これではもし後世に残ったとして混乱が生じるもとになります。そこで、私は資料生成の自動化を始めました。

自動化として、車両系統(出庫から入庫まで、どの列車に流れるかの情報)と車両形式・編成両数の情報を一体化しました。この情報をもとに、各列車の列車番号から車両系統を求め、一覧表に同じことを何回も入力する手間を省くようにしました。また逆に、車両系統から各列車を求め、運用表にその情報を並べるようにしました。この手法の利点は「ミス発生箇所の集中化による発見可能性の向上」です。たとえば、車両系統に対する車両形式の入力を間違えたとします。その情報は、列車編成両数表において複数行の誤りとして表示されるため検出しやすくなります。また、検出された車両系統の情報を修正し、資料を再生成すればすべての誤りが修正できます。また、どれかひとつで誤りを発見した場合、必ず同じ列車・車両系統において別の資料も誤りがあることになるため、誤りの検出効率が上がります。各資料てんでばらばらの場所に誤りがあるより、同じ列車・車両系統に関係ある部分すべてに出現してくれた方が、逆説的ではありますが一気に誤りを直せて、資料の品質が向上します。

この自動化システムは、昨年夏に試作して実際に動かし、2021年3月13日ダイヤ改正における資料生成に多大なる貢献を果たしました。誤り箇所の発生を大きく減らし、かつ迅速に情報をまとめることができました。また、今まで構想しながらも煩雑さのため見送っていた車両運用図表(箱ダイヤ)の生成も実現しました。

ただ、試作システムには少々問題がありました。それはデータ入力に一手間かかっていたことです。公式発売のダイヤグラムから列車を1本ずつ取り出して自作システム規定の形式でデータベースシステムに打ち込んでいましたが、最初の設計で無駄に細かくしすぎたため、この情報をテーブルAに入力し、そのIDに関連する情報をテーブルBとテーブルCに入力……といったように、手続きが面倒で間違いやすいものになっていました。実際、前回より誤りが大きく減ったとはいえ、近所の有識者の方による校閲でまだ10~20箇所の誤りが検出されました。

また、これは個人的な話ですが、データを可能な限りテキストデータとして保持したいという思いがありました。試作システムのデータベースは世に広く定着しているSQLite3を用いていました。このデータベースはSQLにより情報を自在に集約して取り出せること、外部キー制約などを利用してデータの関連性の規則を保つことができること、最適化された保存形式により高速にデータ集約が可能なことという利点があります。しかし、遠い将来情報が取り出せなくなる可能性がテキストデータよりも高くなります。広く使われているオープンソースソフトウェアは比較的開発保守が継続されやすいのですが、将来の行方がどうなるかは誰にも分かりません。

テキストデータであればファイルの形式に起因する読み取り不能状態を避けやすくなります。テキストデータからの集約演算はUNIXコマンド群や各種スクリプト言語によるプログラミングにより達成できますし、大変であればいつでもその時流行っているデータベースシステムに取り込んで、SQLを用いて集約ができます。最近ではテキストデータに対してSQLを発行できる面白いツールが公開されていますので、これを使うことも有力な選択肢です。

github.com

これらを踏まえ、私はシステムVer.2.0を製作しました。

システムとしてはプログラムディレクトリが43.78KB(シェルスクリプト14個・AWKスクリプト1個・Rubyスクリプト4個・テキスト形式メタデータファイル5個)、データディレクトリが1.7MB(2021年3月13日改正全ダイヤ分)となりました。このサイズは小規模であると言って良いと思います。スクリプトファイル数は少々多いかもしれません。

現在、このシステムを2021年3月13日ダイヤ改正データに対して適用し、出力状態の確認を進めています。完成した後、来たる2022年8月28日ダイヤ改正データを収集・打ち込みをして適用し、各種運用資料の迅速生成を目指します。