パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

IC乗車券「PASMO」の運用開始」記事へのコメント

  • JRと私鉄をまたいだ場合の一部に設定されている
    乗り継ぎ割引運賃に対応してないってのがなぁ…

    http://job.yomiuri.co.jp/news/jo_ne_07013124.cfm [yomiuri.co.jp]

    武蔵中原から原宿まで行く場合、
    「武蔵中原 -(JR南武線)- 武蔵小杉 -(東急東横線)- 渋谷 -(JR山手線)- 原宿」
    という乗り継ぎ切符を買った場合は320円になりますが、
    PASMO/Suicaで通った場合はそれぞれの区間で料金が発生して
    武蔵中原 -(JR南武線)- 武蔵小杉 130円
    武蔵小杉 -(東急東横線)- 渋谷 190円
    渋谷 -(JR山手線)- 原宿 130円
    合計450円になってしまいます。
    (130円高くなってしまう)

    この場合は武蔵小杉でも渋谷でも改札を通っているので
    認識できるはずですが…。

    問題は改札入った時点で最短料金を取られるので
    改札を出る際に最短料金以下に清算できない
    (改札でお金を引くことはできても足すことはできない)
    ところなんでしょうけど。
    (上の例では渋谷-四谷間が0円にならなければならない)
    今後改善されるんでしょうかね?

    #「乗り継ぎ割引を廃止します」という解決方法はやめてください ;-(
    • 南武線からだと、登戸〜新宿間も同じ扱いがありますね(登戸近くの駅からのみ)。溝の口は確かなかった。

      > 「武蔵中原 -(JR南武線)- 武蔵小杉 -(東急東横線)- 渋谷 -(JR山手線)- 原宿」

      まあ、自販機では切符を売ってない山手線内の駅もかつてはありましたし :-)

      その区間の定期券も、磁気式だと1枚で買えましたがPASMO/Suicaだとどうなんでしょう?
      # 無理かな

      --
      かつてそういう定期券を利用していた ID
      親コメント
    • by Anonymous Coward on 2007年03月19日 12時42分 (#1128139)
      > この場合は武蔵小杉でも渋谷でも改札を通っているので
      > 認識できるはずですが…。

      Suicaの改札入出場記録は3スロットしかないので無理です。
      東急渋谷の改札を出た時点で「どこから乗車したか」が消えてしまいます。

      支払履歴を辿ればいけるかもしれませんが、そこまでやっていると1秒以内での改札が難しくなるでしょうね。
      親コメント
      • > Suicaの改札入出場記録は3スロットしかないので無理です。
        > 東急渋谷の改札を出た時点で「どこから乗車したか」が消えてしまいます。

        1スロット目: 入場記録「武蔵中原」
        2スロット目: 出場記録「武蔵小杉」
        3スロット目: 入場記録「武蔵小杉」

        が限度ということですね。

        もうちょっと拡張性を考えたシステムにしとけば良かったのに…。
        親コメント
      • 全く別のシステム屋ですが。
        >Suicaの改札入出場記録は3スロットしかないので無理です。
        東急渋谷の改札を出た時点で「どこから乗車したか」が消えてしまいます。

        履歴を辿らなくても、渋谷の改札出場時に2スロット目を運賃の整合の取れるダミーデータに書き換えればいいだけでは?(武蔵中原2みたいなデータを用意する)
        で、その場合は最後の清算時に例外運賃処理に飛ばすと。

        ①JR②-③私鉄④-⑤JR
        を私鉄ーJRに書き換えて処理
        実際に通ってないんで最大改札数で考えます。

        普通に④の改札で①がJRの場合、2スロット目を渋谷(2)または武蔵中原(2)とする。(渋谷で実際に降りることを考えると渋谷(2))でしょうね。

        で、この場合例外に飛ばす。または、データ上④-⑤経路間を短く設定しておく。で済む話では?

        この手の例外処理なんてよくある話。
        そんなに難しい話でもないし、時間のかかる処理でもないはずなのになんでやんないんだろ。
        親コメント
        • ダミーデータに書き換えたタイミングで
          何らかの事件に巻き込まれた場合、
          アリバイの立証が難しくなりませんか?
          • 切符って、そういうもの?
          • > ダミーデータに書き換えたタイミングで
            > 何らかの事件に巻き込まれた場合、
            > アリバイの立証が難しくなりませんか?

            書き換えられてもどっちみち経路としては同じでは?
            Suica/PASMOは書き換えできないようになってるんじゃないのかな。
            磁気じゃないから追加だけ。とか
            • felica、suicaの中身の仕様をよくは知らないんで想像ですが、書き換えは可能なはずです。
              でないと定期の期限書き換えなんか無理。
              追加しか出来なくて、履歴の後ろ3つを追っているとも思えない。
              その場合はいつかメモリオーバー起こしますから。
              必ずどこかで書き換えがされています。

              元々のコメントで履歴以外の入出場が3スロットと言ってますし。
              で、これは普通に考えるとキューの形で書きかえられてるはずです。
              (でないと3回改札通ると使えなくなる)

              ①駅1入場ー②駅2出場ー➂駅3入場
              次に駅4で出場時に
              ①駅2出場ー②駅3入場ー➂駅4出場
              と書き換えてるはずです。

              これを元コメの
              ①JR②-③私鉄④-⑤JR⑥
              に当てはめると、
              ②か➄に乗り換え対応改札を用意し、乗り換えフラグを建て、
              ➄で入場時に➂スロット全体を
              ①私鉄②ー➆JR(初乗りを引かないダミー)に書き換えればいい話です。

              また、SUICAの実態であるfelicaはフォルダ構造が可能で一枚で複数機能をもてますから、フォルダを新規に用意してスロットを見かけ上増やすことも技術的には可能なはずです。

              親コメント
      • とくダネ! [fujitv.co.jp]によれば、PASMOの方が割安になるケースもあるようです。 確か新宿-松戸が例示されていましたが、録画してなかったのでそれ以上の細かいことは覚え切れませんでした。 悪しからず。

        もしかしてタッチ&ゴーで処理しきれないのは、スロット問題が大きいのでしょうか? 通信遅延だけの問題なら、適度に圧縮した路線パターンデータを改札機のハッシュ表に網羅的にキャッシュしておけば、数百万通りくらいはカバーできそうに思えますけど。 あるいはそれ以上のパターン数が存在する?

        親コメント
    • >問題は改札入った時点で最短料金を取られるので
      >改札を出る際に最短料金以下に清算できない


      いえ、今回のPASMO・Suica相互利用開始と同時に、乗車時には引かず、下車時に全部引く方式に変更になってるはず(ソース忘れたです・・・)。
      ただ乗車時には最短料金残ってるかどうかのチェックはあり、そこで弾かれると改札が閉まります。

      親コメント
    • >問題は改札入った時点で最短料金を取られるので
      今回のシステム導入にあたって変更されたそうな [srad.jp]
      • 元コメントで言っているのは JR→他社線→JR のうち乗り継ぎ2回中2回全てで改札通過が発生している例で、JRの解説 [jreast.co.jp]のルール4に相当するものではないかと。
        確かに18日から色々と運賃計算の方法が変更されているんだけど、このあたりが解決されてないよ、ということが言いたいんだと思う。

        #割引運賃を適用させたいなら切符買う手間を惜しむな、といったところか。
        親コメント
    • 昔、パスネットが導入された時に、羽田空港~成田空港間の割引運賃が
      反映されてなくて割高になってしまっていた、という件を思い出すなぁ。
      この場合は起点と終点と経路が特定できるので、後に反映されるようになったけど。

      それでも5年くらい放置されていたけれどね(^^;

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

処理中...