アカウント名:
パスワード:
ＥＴＣにしたって、オーストラリアなんかでは、ダッシュボードにシールのようなものを貼るだけ。それに引き替え日本では、どれだけ大がかりなシステムなのか？民間にやらせれば、スイカみたいな分散型のシステムだって開発できるのに。住民基本台帳カードだって・・・まだ普及していないのに マイナンバーを打ち出していったいいくつの番号を作れば気が済むんだ
民間にやらせたらSuicaみたいなエリア越え乗車が出来ない分断された糞システムが出来たじゃないかあれこそ国が音頭取ってやるべきだった
それは国とか民間とかは関係ないと思う。
各エリアごとで分割しないと、組み合わせ爆発が起こって、料金改定が不可能なくらいにコスト高になるから。
全国一律にする方が糞システム。言わせんなよ、恥ずかしい。
http://www.shopbiz.jp/nf/news/112667.html [shopbiz.jp]「スイカは２００１年の発行以来、西日本旅客鉄道（ＪＲ西日本）の「ＩＣＯＣＡ（イコカ）」などＪＲ各社のＩＣ乗車券のほか、首都圏の私鉄・バスが加盟するＩＣ乗券「ＰＡＳＭＯ（パスモ）」と相互乗り入れをしている。運賃変更をした場合、私鉄とＪＲ間などを乗り継いで正しく運賃計算されるか確かめる必要がある。その数はスイカとパスモの連携だけでも約１２億３千万通りと膨大な作業が必要となる。」
みどりの窓口でJR全線のきっぷが買えるのに作業量が膨大って言われてもな…。12億通りってコの業界にとって膨大なの？
ICカード化に伴う車内改札の廃止で乗車経路が特定できなくなったという事情はありそう。後払い制っていうのも効いてそうだし。
通過の時に瞬時にできる必要はある。ただ金銭についてサーバとの通信は後で非同期でいいはず。
ようはローカルのスイカリーダーおよびそのバックエンドとのやりとりの完結の中で、ということ。
# だったよな...
PaSoRiやRELETやNFC対応スマホで読める通り、カード内にも金銭情報があります。ですので、タッチした瞬間に金銭情報も瞬時に算出出来ないと駄目ですよね。
サーバーの通信が非同期でよいのは、パフォーマンスと耐障害性ですかね。通信回線が一時的に不通になっただけで改札が通過不可になったら困りますから。
12億通りって軽く言ってますが、対応駅を増やせば指数関数的に組み合わせ爆発するので簡単に数桁増えます。後払い制で金券ってのが正にガンですね。タッチした瞬間に最短・最安ルートを探して、カード書き換えもしないといけない。それに、JR全線で済まず、JR-私鉄A-私鉄Bみたいなケースも有り得てしまう。運賃自体も制度が複雑で、会社によって異なりますし、割引制度が有ったりすることも。JRに関係ない遠くの私鉄の新駅やら移動やらで運賃改定で大量に有る全改札機の改修が発生する点もポイントです。
おそらく定期券なら少しはマシでしょう。磁気切符は予め「乗れる場所」と「降りれる場所」と「経由」が予め確定済みで定期券とほぼ同様です。
他の理由としては・そもそもIC化されてないエリアがまだまだ結構あるので会社を跨ぐ前にエリア外になってる。・途中下車(長距離磁気切符は途中で降りて駅の外の宿に泊まった後続きを移動とか出来るようになってる)をどうするのか。・不正対策でカードとサーバー上で入札と出札がペアになってないといけない。（PASMOエリアで降りたら、Suicaサーバーへ情報が行ってるし、その逆も同じ。情報が来なければ不正乗車や盗難等と区別が付かず、止めるしかない）
でも増税に合わせて1円単位の運賃制度を導入したいみたいな話じゃなかったっけ？どうも元記事の記述と合わないんだよねえ。
ごめん、どの辺が合わないのかがよくわからない。1円単位にしても組み合わせが増えるわけじゃないよ？
そこで量子コンピュータですよ！
てか、その１２億通りを全パターン試験が必要なの？そもそもSuicaやPasmoを使わなくてもその組み合わせはあるわけで、そこは人力でも１２億通りの確認は必要な気がする。
ある程度はサボれるケースもあるかもしれないけど運賃って営業キロベースですから発駅が変わるとすべて変わるし、乗り換えもあるし、全組み合わせ想定が必要では。1円単位運賃で既に2倍ですけど、現状の12億から100億オーバーとかになっちゃうと検証フローが限界超えちゃうよね的な話。経由が選べ過ぎてしまうのが原因なので、乗り換え禁止って方法なら比較的安く実現できるかもね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
とにかく大がかりなシステムが大好き (スコア:1)
ＥＴＣにしたって、オーストラリアなんかでは、ダッシュボードにシールのようなものを貼るだけ。
それに引き替え日本では、どれだけ大がかりなシステムなのか？
民間にやらせれば、スイカみたいな分散型のシステムだって開発できるのに。
住民基本台帳カードだって・・・まだ普及していないのに マイナンバーを打ち出して
いったいいくつの番号を作れば気が済むんだ
Re: (スコア:0)
民間にやらせたらSuicaみたいなエリア越え乗車が出来ない分断された糞システムが出来たじゃないか
あれこそ国が音頭取ってやるべきだった
Re: (スコア:4, 興味深い)
それは国とか民間とかは関係ないと思う。
各エリアごとで分割しないと、組み合わせ爆発が起こって、
料金改定が不可能なくらいにコスト高になるから。
全国一律にする方が糞システム。言わせんなよ、恥ずかしい。
http://www.shopbiz.jp/nf/news/112667.html [shopbiz.jp]
「スイカは２００１年の発行以来、西日本旅客鉄道（ＪＲ西日本）の「ＩＣＯＣＡ（イコカ）」など
ＪＲ各社のＩＣ乗車券のほか、首都圏の私鉄・バスが加盟するＩＣ乗券「ＰＡＳＭＯ（パスモ）」と
相互乗り入れをしている。運賃変更をした場合、私鉄とＪＲ間などを乗り継いで正しく運賃計算
されるか確かめる必要がある。
その数はスイカとパスモの連携だけでも約１２億３千万通りと膨大な作業が必要となる。」
Re:とにかく大がかりなシステムが大好き (スコア:0)
みどりの窓口でJR全線のきっぷが買えるのに作業量が膨大って言われてもな…。
12億通りってコの業界にとって膨大なの？
ICカード化に伴う車内改札の廃止で乗車経路が特定できなくなったという事情はありそう。
後払い制っていうのも効いてそうだし。
Re:とにかく大がかりなシステムが大好き (スコア:1)
通過の時に瞬時にできる必要はある。ただ金銭についてサーバとの通信は後で非同期でいいはず。
ようはローカルのスイカリーダーおよびそのバックエンドとのやりとりの完結の中で、ということ。
# だったよな...
M-FalconSky (暑いか寒い)
Re: (スコア:0)
PaSoRiやRELETやNFC対応スマホで読める通り、カード内にも金銭情報があります。
ですので、タッチした瞬間に金銭情報も瞬時に算出出来ないと駄目ですよね。
サーバーの通信が非同期でよいのは、パフォーマンスと耐障害性ですかね。
通信回線が一時的に不通になっただけで改札が通過不可になったら困りますから。
Re:とにかく大がかりなシステムが大好き (スコア:1)
12億通りって軽く言ってますが、対応駅を増やせば指数関数的に組み合わせ爆発するので簡単に数桁増えます。
後払い制で金券ってのが正にガンですね。
タッチした瞬間に最短・最安ルートを探して、カード書き換えもしないといけない。
それに、JR全線で済まず、JR-私鉄A-私鉄Bみたいなケースも有り得てしまう。
運賃自体も制度が複雑で、会社によって異なりますし、割引制度が有ったりすることも。
JRに関係ない遠くの私鉄の新駅やら移動やらで運賃改定で大量に有る全改札機の改修が発生する点もポイントです。
おそらく定期券なら少しはマシでしょう。
磁気切符は予め「乗れる場所」と「降りれる場所」と「経由」が予め確定済みで定期券とほぼ同様です。
他の理由としては
・そもそもIC化されてないエリアがまだまだ結構あるので会社を跨ぐ前にエリア外になってる。
・途中下車(長距離磁気切符は途中で降りて駅の外の宿に泊まった後続きを移動とか出来るようになってる)をどうするのか。
・不正対策でカードとサーバー上で入札と出札がペアになってないといけない。
（PASMOエリアで降りたら、Suicaサーバーへ情報が行ってるし、その逆も同じ。
情報が来なければ不正乗車や盗難等と区別が付かず、止めるしかない）
Re: (スコア:0)
でも増税に合わせて1円単位の運賃制度を導入したいみたいな話じゃなかったっけ？
どうも元記事の記述と合わないんだよねえ。
Re: (スコア:0)
ごめん、どの辺が合わないのかがよくわからない。
1円単位にしても組み合わせが増えるわけじゃないよ？
Re: (スコア:0)
そこで量子コンピュータですよ！
Re:とにかく大がかりなシステムが大好き (スコア:1)
てか、その１２億通りを全パターン試験が必要なの？
そもそもSuicaやPasmoを使わなくてもその組み合わせはあるわけで、そこは人力でも１２億通りの確認は必要な気がする。
Re: (スコア:0)
ある程度はサボれるケースもあるかもしれないけど運賃って営業キロベースですから発駅が変わるとすべて変わるし、乗り換えもあるし、全組み合わせ想定が必要では。
1円単位運賃で既に2倍ですけど、現状の12億から100億オーバーとかになっちゃうと検証フローが限界超えちゃうよね的な話。
経由が選べ過ぎてしまうのが原因なので、乗り換え禁止って方法なら比較的安く実現できるかもね。