アカウント名:
パスワード:
1. 速度を下げる。2. 本数を減らす。3. 停車時間を増やす。4. 運賃を上げる。5. 全席指定にする。6. 相互乗り入れをやめる。
これぐらいでいいかな? 簡単だね!!
千鳥停車を導入すれば良いでしょ。…と思ったら、既に都知事のブレーンが表明しているのか。
都知事公約「満員電車ゼロ」は、こう実現するhttp://toyokeizai.net/articles/-/130415 [toyokeizai.net]
# 「総2階建て」ばかり目立ってたので、てっきりアレな人かと思ってた。# 現実的な提案もしてたんだなぁ。
いや、あいかわらず微妙におかしい気がします。
青信号出る前にドア閉めて安全確認終わらせろって、それ、客から見たら発車時刻前に早発されるだけだから。客の視点に合わせるなら時刻表に掲示する時刻をその分早めることになって、実質的には何も変わらないでしょうに。
ドア閉め灯の話にしても、言ってることはわからんでもないけど、10㎜オーダーはドア検知で、それで検知できない部分は人の目でっていう現状を否定するわりには、対策は何らかのセンサーでとか言ってるだけで全然具体的じゃないですし。
千鳥停車は、ラッシュ時は都心に向かう人最優先で中間駅相互利用が多少
>青信号出る前にドア閉めて安全確認終わらせろ>客から見たら発車時刻前に早発されるだけ通過待ちの時などの話では?
>ドア閉め灯>対策は何らかのセンサーでとか言ってるだけで全然具体的じゃないドアの上に人感センサー、カメラ或いは距離カメラを置くだけで良いはずでしょう。簡単に解決できると思います。
>千鳥停車>新しい話ではありません新しい話ではなくとも、現状導入は少ないんだから…。
>車両性能の向上>まぁ金の問題いや、これが一番問題あると思います。乗り心地が悪くなったり、故障時の危険性が高まりそうな気がします。
>信号系の改良>現行システムで運用しながら工事していかないといけないこれはATACS [wikipedia.org]を導入すれば解決するはず。ただ、無線式はセキュリティの面で不安ですね。列車制御システムの無線化は世界的な動きですが、安全なのだろうか。
遅延が常態化するような路線はどちらかというと通過待ちより単純に閉塞の問題で青信号にならないので、あまり意味がないです。
ドアの上って具体的に何処でしょう。ドアの真上だとドアの自重でカウントできないんですが。というか、たとえば「誰かの鞄の紐がドアから飛び出してる」みたいなケースはセンサーでは解決できません。ルパン三世に出てくるような超高密度のレーザーセンサーでもつければ別ですが、そんなことしたらコストで破綻します。いや、コストをあえて無視したとしても、センサー機器のサイズだけ車両がでかくなって建築限界超えてぶっ壊れるか、その分内寸を小さくすることになって輸送力が下がるっていう本末転倒な自体を引き起こします。そして、「誰かの肩にかかってる鞄の紐がドアから飛び出してる」みたいな場合、そのまま出発して紐が電柱か何かに引っかかると、鞄を持ってる人の腕を内側でごっそり切断するリスクすらあります。あるいは扉を破壊して中の人ごと飛び出すとかね。どう転んでも大惨事です。ドアの上に人感センサーなんか載せた日にはドア閉まらなくてさらに遅延が加速するだけですね。あれ広範囲に測定しますから。嘘だと思ったらどこか適当な自動ドアのある設備で、ドアの直前に立ってドアが閉まる状況を作れるか試してごらんなさい。
ダイヤが煩雑化し、逆に回復運転の妨げになるからです。千鳥停車は実施駅における乗降時の混雑解消には一定の効果がありますが、ダイヤ遅延の対策にはなり得ません。遅延を減らすために千鳥停車を実施したら遅延の被害が拡大しましたとか馬鹿でしょう?
「消費電力が少なくて性能が向上した夢のモーターができました」みたいな非現実的な話に期待するなら兎も角、現実的に車両性能を引き上げようとするとモーター車の比率を引き上げることになるわけだが、首都圏だとむしろ電力容量の問題がのしかかる。車両の増備のコストよりそっちのほうが重大。変電所増やすとか発電所増やすとかそういうレベルで対策が必要になるわけで、それをやってはじめて「さあ車両のモーター比率上げようか」になるわけだ。色んな意味で現実的じゃないな。乗り心地に関しては多少のことでは悪化しないんじゃね?京急を超えるレベルでの急加速はじめたら流石に問題になるだろうけど:p
>信号系の改良>現行システムで運用しながら工事していかないといけないこれはATACSを導入すれば解決するはず。ただ、無線式はセキュリティの面で不安ですね。列車制御システムの無線化は世界的な動きですが、安全なのだろうか。
何適当なこと言ってるんだろう。馬鹿なの?死ぬの?
まず、ATACSは輸送密度は上げられても遅延回復には言うほど役に立ちません。というか混雑が問題になるような路線(田園都市線やメトロ東西線、JRだと中央線快速・埼京線あたりか)は既に密度的にかなり限界が近いし、中央線快速の23区出たあたりから外側は兎も角、それ以外は駅間がさほど長くないので、閉塞をなくして個別管理することによる恩恵を受けにくいです。(他方、中央線快速でATACSとか言い出すとE233以外に特急で使われるE351やE257、果ては成田エクスプレスのE259・果ては貨物のEH200やEF210までATACSに対応させなくてはならず、諸々のコストが大変なことになるわけで・・・というか積載重量に大幅な変化が出る貨物にATACSなんか無茶ぶりも甚だしい)
あとATACSの無線はきちんと暗号化されてますよ。少なくともそこらのWPA2な無線LANとかよりは強固に。むろん、キーが流出すればアウトだろうけど、そのレベルを懸念するなら「地上線の伝達装置に何かこっそり挟まれる」のも同等にリスクとして存在するので大差ないです。
総じて「わかってない人の妄言」で解決した気になっても、世の中には害悪でしかないですよっていう実例ですね。
>通過待ちより単純に閉塞の問題で青信号にならないので、あまり意味がない車間に余裕ができれば、意味はあるのでは?
>ドアの上って具体的に何処でしょうドアの上、車外スピーカーの横あたりとか。
>「誰かの鞄の紐がドアから飛び出してる」みたいなケースはセンサーでは解決できませんカメラ+画像認識じゃダメですかね?
>千鳥停車は[...]ダイヤ遅延の対策にはなり得ません車間に余裕が出来るので、遅延対策になると思います。
>ATACSは輸送密度は上げられても遅延回復には言うほど役に立ちません車間
特に遅延・ダイヤ乱れ時は先行列車が前の駅を出発するのが確定してからでないと出発できない。そうしないと駅間で長時間停車とかいうことになりかねず、急病人でも出ようものなら「上下線とめて救急隊を線路にいれて救護」みたいな事案になり、大幅に遅延が拡大するリスクを背負うから。だから駅間がさほどない首都圏の鉄道でこれ以上、車間距離を縮めるのが前提のダイヤを設定すると、それこそ遅延発生時にキャパシティオーバーが発生して遅延の解消ができなくなる。というか「一度遅延が発生したら運転本数を減らしつつ、
>車間距離を縮める車間距離を縮めるというよりも、車間距離を広げないという話です。
>そんな場所に設置したら電柱やら駅の設備やらにぶつかって速攻壊れる。側面に出っ張ったランプのある車両があるので、出来る路線はあるのでは?
>夜間でも雨天や雪の日でも動作して都会の駅なら夜でも明るいでしょうし、水滴はカメラにワイパー付ければ何とかなりませんかね?
>車体や窓ガラスの反射による映り込みは誤認しないPLフィルター入れるだけでしょ?
>千鳥停車>通過線と停車線が確保できてるなら兎も角、そうでなければ対策にならない停車していたはずの時間が減るので、そんなことは無いでしょ。
>ATACSの主な利点は管理性の向上であって遅延対策や密度向上は僅かに期待できる副次効果程度移動閉塞も立派な利点だと思いますが。
>暗号色々考えてみましたが、詳しい仕様が分からないので意見は保留で。
だから遅延発生時に備えて駅間より短い車両間隔のダイヤなんか組めないんだって何度も言ってるんだが。現状の閉塞で大半の路線はそれが達成できてる以上、それ以上詰めたら遅延発生時に回復ができなくなる。(或いは回復の狭間で「駅間で長時間停車」というリスクを負うことになり、そこでトラブルが発生したら遅延の回復どころではなくなる)
その程度の出っ張りに積めるカメラなんてたかが知れてる。民生品のス
>通過待ち>遅延発生時に備えて駅間より短い車両間隔のダイヤなんか組めない駅間よりも短くするとは言っていませんが…。駅間ギリギリにできるはずだ、という話ですよ。
>その程度の出っ張りに積めるカメラなんてたかが知れてるその程度のカメラでは足りませんか?
>都会でもホームの端はそこまで明るくない駅は多いそういえばそうですね。なら、車体にLEDライトを付ければ良いのでは?# そもそも目視はどこまで確認出来てるのだろう?
>走行中にもろ風圧受けるいや、当然カバーは必要ですよ。
>PLフィルターって偏向角度の調節しないと使い物にならんモーターで回せば良いでしょう。
>他の列車が支障になったり、他の列車の支障になったら本末転倒。どういうことを想定
既になってます。というかその程度の距離でいいのであれば固定の閉塞で対応できますし、できてます。
iPhoneで3~4mの距離からドア2~3cm幅の紐が挟まっているか、周囲の明るさや気象条件に左右されずに確実に判別できるソフト作ってみたら?それがどれだけ無理ゲーかわかると思うよ?
>都会でもホームの端はそこまで明るくない駅は多いそういえばそうですね。なら、車体にLEDラ
>既になってます。なってないから言っているのに。例えば閉塞中間駅で考えてみてください。
>iPhoneで3~4mの距離からドア2~3cm幅の紐が挟まっているか>周囲の明るさや気象条件に左右されずに確実に判別できるソフト作ってみたら?明るさは露光ブラケットで何とかなるでしょうし、気象条件も画像処理によって人間以上の精度にできるはずだと思います。
>そのライトの反射がディフューザーで拡散反射にすれば良いでしょ。いざとなったらドアに色を塗っても良い。
>モーターで回すだけで調節できると思ってるの?当然できるでしょう。3DCG用のテクスチャ撮影の時に使われる枯れた技術だったはず。>モーターで回転するPLフィルター
>千鳥停車>たとえば快速が急行を追い抜いたとして追い抜かない場所で考えてみてくださいな。そしたら、意味が分かりますでしょ?
>通信そのものの暗号化と、通信項目の暗号化の区別もついてない?
補足として、暗号の問題についてもう少し突っ込んで書いておきます。
本来、検証は 初期化ベクトル [wikipedia.org]によって行うべきですが、以下の資料の「合理性チェック」の所を見ると「車上制御装置のIDチェック」「通信電文にNo.1~No.255の連続番号を付加」「列車位置情報の合理性チェック」となっています。 https://www.ntsel.go.jp/forum/2012files/1107_1350.pdf [ntsel.go.jp] 誤記なら良いんですけどね。
そもそも、AT [mynavi.jp]
以下の資料の「合理性チェック」の所を見ると「車上制御装置のIDチェック」「通信電文にNo.1~No.255の連続番号を付加」「列車位置情報の合理性チェック」となっています。
それは何らかの理由でデータが不達になったことが確認するための番号を付与してるだけで、暗号化とはまったく別の話なんだが。
もうちょっと単純に「1」から「10」でのファイル名のファイルを(暗号化されてる)無線LAN経由で送受信することを考えてみろ。「3」のファイルが不達だったからロストしてますねー、というのが判る合理性チェックと、無線LANの暗号化(による盗聴や改竄リ
シーケンス毎にちゃんと異なる初期化ベクトルを使用しているなら、そんなものは無意味でしょうに。それとも何か見逃していますか?
見逃してるもなにも「電文に番号を振るのはアプリケーション層の問題であって、暗号化(初期ベクトル等含む)はトランスポート層の話題」なんだけど。まず通信技術について自身が無知だということを自覚しろ。そして勉強してこい。IT系専門学校の学生ですらそんな頓珍漢なことはあまり言わんぞ。
ダメだこりゃ。トランスポート層って、インターネットじゃないんだから…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
対策 (スコア:0)
1. 速度を下げる。
2. 本数を減らす。
3. 停車時間を増やす。
4. 運賃を上げる。
5. 全席指定にする。
6. 相互乗り入れをやめる。
これぐらいでいいかな? 簡単だね!!
Re: (スコア:0)
千鳥停車を導入すれば良いでしょ。
…と思ったら、既に都知事のブレーンが表明しているのか。
都知事公約「満員電車ゼロ」は、こう実現する
http://toyokeizai.net/articles/-/130415 [toyokeizai.net]
# 「総2階建て」ばかり目立ってたので、てっきりアレな人かと思ってた。
# 現実的な提案もしてたんだなぁ。
Re: (スコア:1)
いや、あいかわらず微妙におかしい気がします。
青信号出る前にドア閉めて安全確認終わらせろって、それ、客から見たら発車時刻前に早発されるだけだから。
客の視点に合わせるなら時刻表に掲示する時刻をその分早めることになって、実質的には何も変わらないでしょうに。
ドア閉め灯の話にしても、言ってることはわからんでもないけど、10㎜オーダーはドア検知で、それで検知できない部分は人の目でっていう現状を否定するわりには、対策は何らかのセンサーでとか言ってるだけで全然具体的じゃないですし。
千鳥停車は、ラッシュ時は都心に向かう人最優先で中間駅相互利用が多少
Re:対策 (スコア:0)
>青信号出る前にドア閉めて安全確認終わらせろ
>客から見たら発車時刻前に早発されるだけ
通過待ちの時などの話では?
>ドア閉め灯
>対策は何らかのセンサーでとか言ってるだけで全然具体的じゃない
ドアの上に人感センサー、カメラ或いは距離カメラを置くだけで良いはずでしょう。
簡単に解決できると思います。
>千鳥停車
>新しい話ではありません
新しい話ではなくとも、現状導入は少ないんだから…。
>車両性能の向上
>まぁ金の問題
いや、これが一番問題あると思います。
乗り心地が悪くなったり、故障時の危険性が高まりそうな気がします。
>信号系の改良
>現行システムで運用しながら工事していかないといけない
これはATACS [wikipedia.org]を導入すれば解決するはず。
ただ、無線式はセキュリティの面で不安ですね。列車制御システムの無線化は世界的な動きですが、安全なのだろうか。
Re:対策 (スコア:1)
遅延が常態化するような路線はどちらかというと通過待ちより単純に閉塞の問題で青信号にならないので、あまり意味がないです。
ドアの上って具体的に何処でしょう。ドアの真上だとドアの自重でカウントできないんですが。
というか、たとえば「誰かの鞄の紐がドアから飛び出してる」みたいなケースはセンサーでは解決できません。ルパン三世に出てくるような超高密度のレーザーセンサーでもつければ別ですが、そんなことしたらコストで破綻します。いや、コストをあえて無視したとしても、センサー機器のサイズだけ車両がでかくなって建築限界超えてぶっ壊れるか、その分内寸を小さくすることになって輸送力が下がるっていう本末転倒な自体を引き起こします。
そして、「誰かの肩にかかってる鞄の紐がドアから飛び出してる」みたいな場合、そのまま出発して紐が電柱か何かに引っかかると、鞄を持ってる人の腕を内側でごっそり切断するリスクすらあります。あるいは扉を破壊して中の人ごと飛び出すとかね。どう転んでも大惨事です。
ドアの上に人感センサーなんか載せた日にはドア閉まらなくてさらに遅延が加速するだけですね。あれ広範囲に測定しますから。嘘だと思ったらどこか適当な自動ドアのある設備で、ドアの直前に立ってドアが閉まる状況を作れるか試してごらんなさい。
ダイヤが煩雑化し、逆に回復運転の妨げになるからです。千鳥停車は実施駅における乗降時の混雑解消には一定の効果がありますが、ダイヤ遅延の対策にはなり得ません。
遅延を減らすために千鳥停車を実施したら遅延の被害が拡大しましたとか馬鹿でしょう?
「消費電力が少なくて性能が向上した夢のモーターができました」みたいな非現実的な話に期待するなら兎も角、現実的に車両性能を引き上げようとするとモーター車の比率を引き上げることになるわけだが、首都圏だとむしろ電力容量の問題がのしかかる。車両の増備のコストよりそっちのほうが重大。
変電所増やすとか発電所増やすとかそういうレベルで対策が必要になるわけで、それをやってはじめて「さあ車両のモーター比率上げようか」になるわけだ。色んな意味で現実的じゃないな。
乗り心地に関しては多少のことでは悪化しないんじゃね?京急を超えるレベルでの急加速はじめたら流石に問題になるだろうけど:p
何適当なこと言ってるんだろう。馬鹿なの?死ぬの?
まず、ATACSは輸送密度は上げられても遅延回復には言うほど役に立ちません。
というか混雑が問題になるような路線(田園都市線やメトロ東西線、JRだと中央線快速・埼京線あたりか)は既に密度的にかなり限界が近いし、中央線快速の23区出たあたりから外側は兎も角、それ以外は駅間がさほど長くないので、閉塞をなくして個別管理することによる恩恵を受けにくいです。
(他方、中央線快速でATACSとか言い出すとE233以外に特急で使われるE351やE257、果ては成田エクスプレスのE259・果ては貨物のEH200やEF210までATACSに対応させなくてはならず、諸々のコストが大変なことになるわけで・・・というか積載重量に大幅な変化が出る貨物にATACSなんか無茶ぶりも甚だしい)
あとATACSの無線はきちんと暗号化されてますよ。少なくともそこらのWPA2な無線LANとかよりは強固に。
むろん、キーが流出すればアウトだろうけど、そのレベルを懸念するなら「地上線の伝達装置に何かこっそり挟まれる」のも同等にリスクとして存在するので大差ないです。
総じて「わかってない人の妄言」で解決した気になっても、世の中には害悪でしかないですよっていう実例ですね。
Re: (スコア:0)
>通過待ちより単純に閉塞の問題で青信号にならないので、あまり意味がない
車間に余裕ができれば、意味はあるのでは?
>ドアの上って具体的に何処でしょう
ドアの上、車外スピーカーの横あたりとか。
>「誰かの鞄の紐がドアから飛び出してる」みたいなケースはセンサーでは解決できません
カメラ+画像認識じゃダメですかね?
>千鳥停車は[...]ダイヤ遅延の対策にはなり得ません
車間に余裕が出来るので、遅延対策になると思います。
>ATACSは輸送密度は上げられても遅延回復には言うほど役に立ちません
車間
Re: (スコア:0)
特に遅延・ダイヤ乱れ時は先行列車が前の駅を出発するのが確定してからでないと出発できない。
そうしないと駅間で長時間停車とかいうことになりかねず、急病人でも出ようものなら「上下線とめて救急隊を線路にいれて救護」みたいな事案になり、大幅に遅延が拡大するリスクを背負うから。
だから駅間がさほどない首都圏の鉄道でこれ以上、車間距離を縮めるのが前提のダイヤを設定すると、それこそ遅延発生時にキャパシティオーバーが発生して遅延の解消ができなくなる。というか「一度遅延が発生したら運転本数を減らしつつ、
Re: (スコア:0)
>車間距離を縮める
車間距離を縮めるというよりも、車間距離を広げないという話です。
>そんな場所に設置したら電柱やら駅の設備やらにぶつかって速攻壊れる。
側面に出っ張ったランプのある車両があるので、出来る路線はあるのでは?
>夜間でも雨天や雪の日でも動作して
都会の駅なら夜でも明るいでしょうし、
水滴はカメラにワイパー付ければ何とかなりませんかね?
>車体や窓ガラスの反射による映り込みは誤認しない
PLフィルター入れるだけでしょ?
>千鳥停車
>通過線と停車線が確保できてるなら兎も角、そうでなければ対策にならない
停車していたはずの時間が減るので、そんなことは無いでしょ。
>ATACSの主な利点は管理性の向上であって遅延対策や密度向上は僅かに期待できる副次効果程度
移動閉塞も立派な利点だと思いますが。
>暗号
色々考えてみましたが、詳しい仕様が分からないので意見は保留で。
Re: (スコア:0)
だから遅延発生時に備えて駅間より短い車両間隔のダイヤなんか組めないんだって何度も言ってるんだが。
現状の閉塞で大半の路線はそれが達成できてる以上、それ以上詰めたら遅延発生時に回復ができなくなる。
(或いは回復の狭間で「駅間で長時間停車」というリスクを負うことになり、そこでトラブルが発生したら遅延の回復どころではなくなる)
その程度の出っ張りに積めるカメラなんてたかが知れてる。民生品のス
Re: (スコア:0)
>通過待ち
>遅延発生時に備えて駅間より短い車両間隔のダイヤなんか組めない
駅間よりも短くするとは言っていませんが…。駅間ギリギリにできるはずだ、という話ですよ。
>その程度の出っ張りに積めるカメラなんてたかが知れてる
その程度のカメラでは足りませんか?
>都会でもホームの端はそこまで明るくない駅は多い
そういえばそうですね。なら、車体にLEDライトを付ければ良いのでは?
# そもそも目視はどこまで確認出来てるのだろう?
>走行中にもろ風圧受ける
いや、当然カバーは必要ですよ。
>PLフィルターって偏向角度の調節しないと使い物にならん
モーターで回せば良いでしょう。
>他の列車が支障になったり、他の列車の支障になったら本末転倒。
どういうことを想定
Re: (スコア:0)
既になってます。というかその程度の距離でいいのであれば固定の閉塞で対応できますし、できてます。
iPhoneで3~4mの距離からドア2~3cm幅の紐が挟まっているか、周囲の明るさや気象条件に左右されずに確実に判別できるソフト作ってみたら?
それがどれだけ無理ゲーかわかると思うよ?
Re: (スコア:0)
>既になってます。
なってないから言っているのに。例えば閉塞中間駅で考えてみてください。
>iPhoneで3~4mの距離からドア2~3cm幅の紐が挟まっているか
>周囲の明るさや気象条件に左右されずに確実に判別できるソフト作ってみたら?
明るさは露光ブラケットで何とかなるでしょうし、
気象条件も画像処理によって人間以上の精度にできるはずだと思います。
>そのライトの反射が
ディフューザーで拡散反射にすれば良いでしょ。
いざとなったらドアに色を塗っても良い。
>モーターで回すだけで調節できると思ってるの?
当然できるでしょう。
3DCG用のテクスチャ撮影の時に使われる枯れた技術だったはず。>モーターで回転するPLフィルター
>千鳥停車
>たとえば快速が急行を追い抜いたとして
追い抜かない場所で考えてみてくださいな。そしたら、意味が分かりますでしょ?
>通信そのものの暗号化と、通信項目の暗号化の区別もついてない
?
Re: (スコア:0)
補足として、暗号の問題についてもう少し突っ込んで書いておきます。
本来、検証は 初期化ベクトル [wikipedia.org]によって行うべきですが、
以下の資料の「合理性チェック」の所を見ると「車上制御装置のIDチェック」「通信電文にNo.1~No.255の連続番号を付加」「列車位置情報の合理性チェック」となっています。
https://www.ntsel.go.jp/forum/2012files/1107_1350.pdf [ntsel.go.jp]
誤記なら良いんですけどね。
そもそも、AT [mynavi.jp]
Re: (スコア:0)
それは何らかの理由でデータが不達になったことが確認するための番号を付与してるだけで、暗号化とはまったく別の話なんだが。
もうちょっと単純に「1」から「10」でのファイル名のファイルを(暗号化されてる)無線LAN経由で送受信することを考えてみろ。
「3」のファイルが不達だったからロストしてますねー、というのが判る合理性チェックと、無線LANの暗号化(による盗聴や改竄リ
Re: (スコア:0)
シーケンス毎にちゃんと異なる初期化ベクトルを使用しているなら、そんなものは無意味でしょうに。
それとも何か見逃していますか?
Re: (スコア:0)
見逃してるもなにも「電文に番号を振るのはアプリケーション層の問題であって、暗号化(初期ベクトル等含む)はトランスポート層の話題」なんだけど。
まず通信技術について自身が無知だということを自覚しろ。そして勉強してこい。IT系専門学校の学生ですらそんな頓珍漢なことはあまり言わんぞ。
Re: (スコア:0)
ダメだこりゃ。
トランスポート層って、インターネットじゃないんだから…。