アカウント名:
パスワード:
大版の時刻表でもなかなか順を追えるような説明がないので、例えば東京近郊区間で運賃を求める方法をまとめておきます。最初に求まった運賃が解です。
旅客に直接操作させる自券機ならば着駅だけで引ける表で十分でしょうが、それでもその表を作成するのには運賃の求め方が分からないといけませんよね。また、職員が窓口でたたく印発や精算機などの場合は発着駅や経路、計算方法(乗越運賃を打切と発駅のどちらで計算するかは乗車券に依る)が設計時には分からないため、この表だけでは不十分です。
最近登場した、ストアードフェアカードと普通乗車券や定期券などの組合せが可能な自改では精算機と同じ問題が出ます。この場合、ストアードフェアカードの発駅または着駅から、普通乗車券および定期券内のどの駅までをストアードフェアカードで精算すれば良いかを求めなければなりません。実際にこの組合せをやってみると分かりますが、処理が終了するまでにワンテンポ遅れがあります。
Suica定期券はストアードフェアカードと定期券の組み合わせにすぎないため、やはり同じ問題があります。悪いことに、タッチの時間はICカードリーダでは全く制御できません。したがって精算処理に時間要求が生じ、磁気券の自改よりもさらに問題が難しくなります。
なお、印発 [sphere.ne.jp]は印刷発行機の略で、職員が旅客向けに切符を発行するための機械です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
根本的原因は解明されてるんですか? (スコア:1, すばらしい洞察)
それ以前に、複雑怪奇なJRの運賃規定は問題じゃないの?
JR側からの要求仕様が運賃規定を網羅できていないのでは
ないかと思えて仕方が無いんですけど・・・・・・
その度に「プログラムミス」で片付けられるんじゃぁ現場の
プログラマも立場ないよなー、とか思ってみたり。
複雑怪奇? (スコア:1, 参考になる)
制度にイチャモン付けて鬱憤晴らしするのはやめたら?
たとえばイオカードに合わせて東京近郊区間の拡大をしたりしてるわけで、
首都圏に閉じた範囲でそんな「複雑怪奇」な制度ってありますか?
旅規69条も70条も157条も関係ないし。
運賃の正しい求め方 (スコア:2, 参考になる)
大版の時刻表でもなかなか順を追えるような説明がないので、例えば東京近郊区間で運賃を求める方法をまとめておきます。最初に求まった運賃が解です。
Re:運賃の正しい求め方 (スコア:0)
テーブルを持ってるだけだと思いますが…
Re:運賃の正しい求め方 (スコア:1)
旅客に直接操作させる自券機ならば着駅だけで引ける表で十分でしょうが、それでもその表を作成するのには運賃の求め方が分からないといけませんよね。また、職員が窓口でたたく印発や精算機などの場合は発着駅や経路、計算方法(乗越運賃を打切と発駅のどちらで計算するかは乗車券に依る)が設計時には分からないため、この表だけでは不十分です。
Re:運賃の正しい求め方 (スコア:1)
> それでもその表を作成するのには運賃の求め方が分からないといけませんよね。
そりゃそうだけど、券売機&改札機の設計をする場合には、
「駅に応じたテーブルを入れる」というだけで十分では…
表の作成はJRに任せればよいわけだし。
#つか、動的に計算するとしたら、全
Re:運賃の正しい求め方 (スコア:1)
最近登場した、ストアードフェアカードと普通乗車券や定期券などの組合せが可能な自改では精算機と同じ問題が出ます。この場合、ストアードフェアカードの発駅または着駅から、普通乗車券および定期券内のどの駅までをストアードフェアカードで精算すれば良いかを求めなければなりません。実際にこの組合せをやってみると分かりますが、処理が終了するまでにワンテンポ遅れがあります。
Suica定期券はストアードフェアカードと定期券の組み合わせにすぎないため、やはり同じ問題があります。悪いことに、タッチの時間はICカードリーダでは全く制御できません。したがって精算処理に時間要求が生じ、磁気券の自改よりもさらに問題が難しくなります。
なお、印発 [sphere.ne.jp]は印刷発行機の略で、職員が旅客向けに切符を発行するための機械です。