アカウント名:
パスワード:
1. 速度を下げる。2. 本数を減らす。3. 停車時間を増やす。4. 運賃を上げる。5. 全席指定にする。6. 相互乗り入れをやめる。
これぐらいでいいかな? 簡単だね!!
千鳥停車を導入すれば良いでしょ。…と思ったら、既に都知事のブレーンが表明しているのか。
都知事公約「満員電車ゼロ」は、こう実現するhttp://toyokeizai.net/articles/-/130415 [toyokeizai.net]
# 「総2階建て」ばかり目立ってたので、てっきりアレな人かと思ってた。# 現実的な提案もしてたんだなぁ。
いや、あいかわらず微妙におかしい気がします。
青信号出る前にドア閉めて安全確認終わらせろって、それ、客から見たら発車時刻前に早発されるだけだから。客の視点に合わせるなら時刻表に掲示する時刻をその分早めることになって、実質的には何も変わらないでしょうに。
ドア閉め灯の話にしても、言ってることはわからんでもないけど、10㎜オーダーはドア検知で、それで検知できない部分は人の目でっていう現状を否定するわりには、対策は何らかのセンサーでとか言ってるだけで全然具体的じゃないですし。
千鳥停車は、ラッシュ時は都心に向かう人最優先で中間駅相互利用が多少
>青信号出る前にドア閉めて安全確認終わらせろ>客から見たら発車時刻前に早発されるだけ通過待ちの時などの話では?
>ドア閉め灯>対策は何らかのセンサーでとか言ってるだけで全然具体的じゃないドアの上に人感センサー、カメラ或いは距離カメラを置くだけで良いはずでしょう。簡単に解決できると思います。
>千鳥停車>新しい話ではありません新しい話ではなくとも、現状導入は少ないんだから…。
>車両性能の向上>まぁ金の問題いや、これが一番問題あると思います。乗り心地が
遅延が常態化するような路線はどちらかというと通過待ちより単純に閉塞の問題で青信号にならないので、あまり意味がないです。
ドアの上って具体的に何処でしょう。ドアの真上だとドアの自重でカウントできないんですが。というか、たとえ
>通過待ちより単純に閉塞の問題で青信号にならないので、あまり意味がない車間に余裕ができれば、意味はあるのでは?
>ドアの上って具体的に何処でしょうドアの上、車外スピーカーの横あたりとか。
>「誰かの鞄の紐がドアから飛び出してる」みたいなケースはセンサーでは解決できませんカメラ+画像認識じゃダメですかね?
>千鳥停車は[...]ダイヤ遅延の対策にはなり得ません車間に余裕が出来るので、遅延対策になると思います。
>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)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
対策 (スコア:0)
1. 速度を下げる。
2. 本数を減らす。
3. 停車時間を増やす。
4. 運賃を上げる。
5. 全席指定にする。
6. 相互乗り入れをやめる。
これぐらいでいいかな? 簡単だね!!
Re: (スコア:0)
千鳥停車を導入すれば良いでしょ。
…と思ったら、既に都知事のブレーンが表明しているのか。
都知事公約「満員電車ゼロ」は、こう実現する
http://toyokeizai.net/articles/-/130415 [toyokeizai.net]
# 「総2階建て」ばかり目立ってたので、てっきりアレな人かと思ってた。
# 現実的な提案もしてたんだなぁ。
Re: (スコア:1)
いや、あいかわらず微妙におかしい気がします。
青信号出る前にドア閉めて安全確認終わらせろって、それ、客から見たら発車時刻前に早発されるだけだから。
客の視点に合わせるなら時刻表に掲示する時刻をその分早めることになって、実質的には何も変わらないでしょうに。
ドア閉め灯の話にしても、言ってることはわからんでもないけど、10㎜オーダーはドア検知で、それで検知できない部分は人の目でっていう現状を否定するわりには、対策は何らかのセンサーでとか言ってるだけで全然具体的じゃないですし。
千鳥停車は、ラッシュ時は都心に向かう人最優先で中間駅相互利用が多少
Re: (スコア:0)
>青信号出る前にドア閉めて安全確認終わらせろ
>客から見たら発車時刻前に早発されるだけ
通過待ちの時などの話では?
>ドア閉め灯
>対策は何らかのセンサーでとか言ってるだけで全然具体的じゃない
ドアの上に人感センサー、カメラ或いは距離カメラを置くだけで良いはずでしょう。
簡単に解決できると思います。
>千鳥停車
>新しい話ではありません
新しい話ではなくとも、現状導入は少ないんだから…。
>車両性能の向上
>まぁ金の問題
いや、これが一番問題あると思います。
乗り心地が
Re: (スコア:1)
遅延が常態化するような路線はどちらかというと通過待ちより単純に閉塞の問題で青信号にならないので、あまり意味がないです。
ドアの上って具体的に何処でしょう。ドアの真上だとドアの自重でカウントできないんですが。
というか、たとえ
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)
ダメだこりゃ。
トランスポート層って、インターネットじゃないんだから…。