Suicaに記録された駅名を正しく読み取るには日付データが必要 60
ストーリー by nagazou
都内に駅が増えるたびに大変なことに 部門より
都内に駅が増えるたびに大変なことに 部門より
六ミツさんのツイートによると、古いSuicaから2005年のデータを読み取ることに成功したが、その当時存在しないハズの高輪ゲートウェイの名称が出てきたことで驚いていたというツイートが話題になった。あおとさんなどの指摘によると、原因は高輪ゲートウェイ駅開業にあわせてJR東日本が駅順コードを割り振り直したためだそうだ。その詳細に関してはmuo-yaの記事に詳しい（六ミツさんのツイート、あおとさんのツイート、muo-ya）。
自動改札機を使用するシステムには、ICカード内に駅コードが記録されている。この駅コードは線区（路線）と駅順から構成され、JR東日本の東京駅は線区が0x01、駅順が0x01なので「001-001」が駅コードとして割り振られているそうだ（自動改札機の研究）。
山手線の東京-品川間駅順コードは、当初から空きコードが一つ用意されていたが、高輪ゲートウェイ駅に空きコードを割り当ててしまうと
浜松町(1-4) - 田町(1-6) - 高輪ゲートウェイ(1-5) - 品川(1-7)
というようになり、コード順と駅順が揃わなくなる問題が生じる。しかしJR東日本はこの順番が狂うことを避け、
浜松町(1-4) - 田町(1-5) - 高輪ゲートウェイ(1-6) - 品川(1-7)
という形で駅順コードの振り直しをおこなったとのこと。このような駅順コード振り直しがおこなわれたことで、冒頭のような古いSuicaデータを読み取ると、当時存在しない高輪ゲートウェイ駅が出てきてしまうと言う事態になったようだ。Suica ReaderなどのICカード履歴読み取りツールや各種経費精算ツールで、間違いなく読み込むためには日付をもとにした分岐処理が必要だとしている
初期構想では (スコア:1)
新駅は浜松町と田町の間に作る予定だったのか。
Re: (スコア:0)
10進で一桁目0と5が機械的に欠番になってるらしいよ。
Re: (スコア:0)
というわけでもないらしい。
https://ja.ysrl.org/atc/code.php?region=0&line=001 [ysrl.org]
Re: (スコア:0)
駅間距離的にそれはないでしょ
Re: (スコア:0)
しんばし、たまちの間にあるという幻の「したまち」駅用に取ってあったのではないか
Re: (スコア:0)
しんばしとたまちをミックスするなら
たまちん
サイバネ規格/サイバネコード (スコア:1)
無駄にカッコイイんだよね。名前が。
日本鉄道技術協会の特定部会の日本鉄道サイバネティクス協議会が定めた、ってだけなんだが。
https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E9%89%84%E9%81%93%E6%... [wikipedia.org]
※個人的には、ヤマト運輸の物流ターミナル「羽田クロノゲート」に並ぶと思ってる。
最初の言語がBASICだったので (スコア:0)
こういうときは10,20,30と番号ふってしまう癖がついてる。
Re: (スコア:0)
IDと順序は別で管理したらいいだけなんじゃないのん。
Re: (スコア:0)
それな。
Identityの略がIDなのに変化するってどういうことかと。
Re: (スコア:0)
IDではなくて駅順コードなのよ。
最初からその路線の中で物理的な駅の順に振ることになっていて、それを前提で運賃計算している。
改札機だと、データ読み取り→データ処理→データ書き込みまで数百ミリ秒で処理完了しないといけないので、IDと別に順序を管理するなんてことはやりたくないのよ。
駅数の少ない路線では予め飛び飛びで駅順コード振ってるけど、8ビットしかないので運悪く空きがないと今回のように振り直すことになる。
Re: (スコア:0)
昔のBASICにはRENUMなかったからなぁ
Re: (スコア:0)
APPLE BASICにも、N BASICにもRENUMはあったけど、シャープとか富士通とか非MSだとなかったんだろうか。
Re: (スコア:0)
PC-1251みたいなポケコンにはRENUMなかったんで、手動でやってしんどかった。
メモリ少ないんで行番号の桁数減らしたいけど、減らしすぎると仕様追加時に詰む。
Re:最初の言語がBASICだったので (スコア:1)
うろ覚えですが、N-BASICにもあったはず。
PC-6001のN60-BASICにはRENUMはなかった。
ラベルジャンプも無かったので、
N-BASICからの劣化っぷりに絶望した覚えがあります。
行番号のふり直しはかなり地獄。
Re: (スコア:0)
一桁で足ります？
Re: (スコア:0)
途中で桁数が変わることを避けるから1000開始の10飛ばしが基本じゃろ
設計したやつ新入社員か？
# 処理速度やメモリフットプリントの関係で桁数削ってたんならごめん。
Re: (スコア:0)
ワークエリアが多くて64KBの時代ならともかく、今どきすべてのプログラムが1000行以内に収まるか?
Re: (スコア:0)
10_要件定義
20_基本設計
30_詳細設計
...
うちの会社のファイルサーバはこんなんばっかだねw
Re: (スコア:0)
十の位だけ増やすのではないですが、大阪市営地下鉄は自社線の駅ナンバリングを1ではなく11からカウントしてましたね。延伸区間、相互乗り入れ区間は10, 09, ... みたいに。
高速道路だと枝番になってますね (スコア:0)
高速道路のICとかにも番号振ってありますけど，
IC増設したら枝番になってますね。
そりゃあ番号振りなおしたら看板全部作り直しだもんな
拡張性って大事だけどリソースの制約もあるから
設計難しいね
Re: (スコア:0)
1丁目1番1号第一ビル1階111号室1100区画
Re: (スコア:0)
絶対に必要であり続ける日付がバージョン番号の役割も兼ねてるので悪いやり方ではないよねコレ
Re: (スコア:0)
IDが一意に定まらなかったり、変動したりするのは、最悪の設計です。
Re: (スコア:0)
半角カタカナで電略をそのまま入れとくとか
Re: (スコア:0)
細かいこと考えずにint32で振ってくれて良いんですよ。
Re:高速道路だと枝番になってますね (スコア:1)
FAT/IPv4/x86「「「呼んだ？」」」
Re: (スコア:0)
ちょうど先日のストーリーで、住所の号に枝番があると東京電力などのアホな入力フォームが受け付けてくれないという話をしてたな
アメリカの場合は (スコア:0)
アメリカの場合は、州内の起点(その高速道路の起点か州境)からのマイルでの距離になってて、同じマイルに(つまり1マイル以内に)複数ある場合は後ろにA,B,C...ってつけてく方式になってる
なので、出口の標識で目的の出口までの距離がわかりやすいし、距離が短くなければ出口番号が被らない
(例えば目的の出口が「Exit 75A」で今通りすぎた出口が「Exit 10」であれば、65mphで走ってたらあと1時間くらいで目的地)
日本の高速道路もこの方式を採用すればいいのに
Re: (スコア:0)
キロポストの数字を，看板にでかく追加してやればOk?
Re: (スコア:0)
ナビに次のインターまでの距離と時間が出てるから
それをちらっと見ればOk.
Re: (スコア:0)
abと振った後にaとbの間に出来た場合はどうなるの？aa？
それともabcは位置関係ないのか。
おおざっぱすぎだわ。
そういや電車の駅も連番になってるよな、外人がわからんからって。
あれも降りなおすのだろうか。
Re:アメリカの場合は (スコア:1)
その場合、
・新設をc
・bをdに変更(以降bは欠番)
てのを思いついたがいかがだろうか。
Re: (スコア:0)
高輪ゲートウェイの駅番号に関してはあらかじめ空けてあったらしい。
https://trafficnews.jp/post/97548/2 [trafficnews.jp]
Re: (スコア:0)
その記事にあるけれど、
東京メトロや東武東上線ではひとつずつ番号を繰り下げ
JR四国では枝番号付きと、対応が分かれるみたいだね。
不連続にはしたくないようだ。
Re: (スコア:0)
知ってる限りABCの順になってるので、たぶんアルファベット部分は振りなおししてる？
出口番号は出口番号であってインターの番号じゃなく分岐に対してつけられるので、例えばジャンクションで南方面と北方面の分岐がそれぞれあったら順番に「42A」「42B」みたいに使われる
短距離に近接してインターがあるせいでABCが使われてる例もそれなりにあるけど、でも1600m以下の間隔で追加する事もそんなに頻繁には無いだろうから、振りなおしでもそんなには困らないのかも？
(ジャンクションの作り直し(アメリカでは結構ある)の場合は構造ごと変わるだろうからそれも振り直しの方が合理的そう)
振り直しの理由 (スコア:0)
振り直した理由は簡単で、この線区駅順コードはICにも使われてるけど、処理速度に限りがある磁気切符や磁気の定期券用でもあるから。
限られた記録ビットと記憶領域と処理速度で、通過可能か不可か判定するのに、逆順になる特例が増えると困る。
発行済の磁気定期券や回数券も高輪ゲートウェイ開業前後でズレたけど、
磁気内の世代ビットで田町か高輪ゲートウェイかは区別されて利用者は意識せず使い続けられるようになってた。
Re: (スコア:0)
処理は改札側が行うのに切符や定期券が磁気かどうかが関係あるの?
Re: (スコア:0)
磁気とICでは判定ロジックも判定CPUも別建てで出来てます。
磁気は切符購入時に券売機が事前に枝狩りしてくれるけど、古い奴はP54C位の世界。流石に今は滅んでるはず。
ICはICで所定の時間内に最安経路を求めないといけないのでとても大変だけど、PenM位の世界。
Re: (スコア:0)
総当たりでテーブルにしてあるのかと思ってたけどリアルタイムに経路探索してたんだ
Re: (スコア:0)
テーブルにしてもデカイだけだよ。
Re: (スコア:0)
複雑に絡み合った路線の通過可能かの判定に、連番を使うような実装のわけがなかろう。
Re: (スコア:0)
複雑だからこそ、枝刈りのために変な枝生やすなってなる。
連番を守らないなら、内部的に山手線の枝が増える事になる。
Re: (スコア:0)
生えるのは山手線ではなく、東海道線の誤りです。申し訳ない。
Re: (スコア:0)
枝もなにも、グラフ構造のデータで持って経路探索するだけじゃん。
路線が増える度に、プログラマが経路のプログラムを作り替えてるとでも思ってるのかw
そんなんじゃ振替輸送にも対応できない。
公開されているの? (スコア:0)
こういう読み取りアプリはたくさん公開しているけど、バージョンアップの情報って公開されているのかな？
1999年以前のシステムと2000年付近のシステムと情報をやり取りするには補足情報が必要 (スコア:0)
老人会たるコミュニティならば、xx年以前なら21世紀、そうでないなら20世紀などという条件分岐を認知するだろう。
想定していたロバスト性（柔軟性）を超えた事象が起きた時にラフなワークアラウンド（力技な迂回策）を採用することになるはずだ。
はたしてその一端を見つけたことはアレげになるのだろうか？(あるいは、それをアレげにできるほどに下々の作業を無視できるほどに現在のACは上級国民なのか)
Re: (スコア:0)
老人会エアプだから2000年問題と名前まで付けてアホみたいに大騒ぎしたの知らないのかな?
分岐処理・・・？ (スコア:0)
こういうのって日付に応じたデータ読んで処理するものだと思ったけど・・・
日付に応じたデータ読むのが分岐処理でいいんだよね。
分岐処理っていわれると1-6は日付によって田町か高輪か判断するみたいなイメージ持ってしまった。
そんな斜め上な解釈にまで連想してしまうのはいつもやらかしてくれる外注さんのせいだな。
JRの駅コード変換処理部はワシが作った (スコア:1)
日付と駅コードを持った変換用テーブルを持ってて、データ処理の最初の方で駅コードの変換掛けてたはず。
もう10数年前なので正確なことは忘れたけど、なんで今頃話題になったのか？
変換コード追加の切っ掛けは、高輪ゲートウェイ駅じゃなくて、空港近くの駅だった気がする。