※ 引述《YiShenHsieh (汲汲营营)》之铭言： : 我想许多人等公车都很怕公车会过头不停 : 我这边有一个想法提供给各位参考 : 在公车上如果要下车要先按按钮 : 司机那边灯号就会亮起来 : 我想相同的道理 : 可以在每个站牌下设立一个按钮 : 只要按下去之後 : 下一班公车车上那边该站灯号会亮起 : 表示需要停车 : 待公车停车後 该站灯号就会消失 : 我觉得这种方式就可以让等待的人安心等待了 : 也可以不用再考验司机的眼力 : 尤其是下雨与夜间时候 : 推 cookie20125:其实这样真的不错，应该是有经费压力+怕恶作剧才不行 12/15 20:10 : 推 s88239:如果有两路以上能到 先来的是没按的，那已经按了的不就囧了 12/15 20:39 : 推 tntchn:手机APP公车停车系统 12/15 21:06 : → moriyaorange:这个比较适合用在班次少的路线上，但以目前最好的方 12/15 21:15 : → moriyaorange:式是以手机通讯的方式，类似於电话叫车 12/15 21:15 : → YiShenHsieh:对於s88239的问题 如果该按钮是可以设置取消的功能 12/15 23:07 : → YiShenHsieh:那应该就可以看到有更快到的路线时 可把原本设定取消 12/15 23:08 : 推 mackywei:用SmartPhone的Location Base系统，旅客到乘车站附近後， 12/15 23:09 : → mackywei:选取路线/目的站/目的地，再传给指定的公车。 12/15 23:10 : → mackywei:问题会在系统反应的时间跟乘客可能会挑车.... 12/15 23:11 先说，我不是大众运输相关科系 or 业者 只是就一个程式设计师 or（软体）系统分析的角度来看这个... 需求 首先，就是这个需求到底好不好呢？ 以我的观点，相当好，我每次等公车搭公车都会有这个念头 而且对司机 or 对乘客都是双赢 乘客不用苦苦当望夫石（虽然这年头已经好很多了） 司机在特定条件下也可以很理所当然的过站不停，加快行车速度 （当然，这有点遥远，後叙） 你说软体系统 or 软体技术有没有办法作到呢？ 太复杂的细节我们就跳过（反正也不是你写 or 我写，怕什麽 XD） 简单地说，如果 5284 这种公车动态资讯都已经 online 了 那麽剩下来的流程就是 1. 乘客 A 新增一个 request 给 server 2. server 根据公车动态资讯，将讯息传送给某公车 2.1 更好的作法是也送给某车站的显示系统 3. 某公车的某装置接收到讯息，alert 司机 理论上也没有问题，剩下来就是软硬体经费... blahblah 那我这篇就是彻底的废文了 [喂喂] 实际上，我可以这麽说： 拜托，有钱也不要浪费来搞这个好吗？ 原因在上头各位大大们的推文已经写了开头了 只是我缺 P 币，所以就来画蛇添足一下 [殴飞] 这个 idea 首要的天敌就是：同个路段有太多路线重叠。 以中永和为例，中正桥头→中兴二村 就有 214 / 262 / 249 / 670 / 304 可以选择 （很久没看到 242 / 248 / 227 就姑且跳过） 这样会造成什麽问题？ 很多... 第一个问题就是：我到底要通知哪一班公车？ a.软体设计成「通知哪一班公车」 那麽大多数人一定会统统都勾 b.按照 mackywei 的「起点跟终点」设计想法 a 的作法实在很愚蠢，而且会炸出更多问题 例如推文中的「取消」机制就会变得很复杂 因为： a.1 使用者忘记按取消 即使设计成只要一个按键「我已上车」就好 也还是会有一卡车的人忘记要按 就像现在语音报站做的很彻底 还是有人会顾着当低头族然後车们都要关了才大喊下车 ＝＝" a.2 214 / 262 / 304 几乎同时进站 要取消也来不及，结果可能不用进站却还是要来这麽一下 a.3 server / communication loading problem （我只是使用者，管你去死 [踢]） b 的想法看起来很 user friendly 的，但是 b.1 介面很难设计的很简单好用（谁知道你要去哪里？） 可能你都还没来得及设定完目的地 结果公车已经到了 b.2 系统认定的车子 311 来了，你嫌太绕 想要 262 / 249 这种两点一直线的车子 回归问题 a 或是 b.1 b.3 其实我真正的目的地是 http://goo.gl/maps/svcN6 5 路我也可以... 於是又回到 b.1 跟 a.1 或着中兴二村只是我的转乘点，还有其他目的地可选择... 我还不如盯着车子还比较快 b.4 server / communication loading problem、 server 程式很难写 （我只是使用者，管你去死 [踢]） 好，UI 设计的问题解决、 使用者的良好习惯也都养成（我个人对这点极度悲观）， 那麽，还会有什麽後续问题呢？ c. 热门路段（像公车专用道），这系统基本上没啥意义 原因类似 b.1 d. 热门时段冷门路线，车来了也未必上得去 还得重新再设定一次 结果只有冷门时段的冷门路线 那种半个小时、一个小时才发一班车，才能显现出价值 於是就会炸出一个更根本的问题： 这个系统建置、维护的成本 说不定都可以让冷门路线用 307 的方式营运 [误] 那些 UI 设计、a.3、b.4 的解法， 背後都是用 $$（或着新鲜的肝脏）堆出来的 赔钱生意没人作阿老板...... Orz 更不用说，对於乘客来说 建置这些系统，还不如一个倒数计时器来的实在？ 这些还只是我临时、嘴炮阶段的 defence 实际分析起来应该还有更多反对理由 Orz 当然，可能有很多盲点是我没有想到的 也欢迎大家诘谯...... (艹) -- 钱锺书： 说出来的话 http://www.psmonkey.org 比不上不说出来的话 Java 版 cookcomic 版 只影射着说不出来的话 and more...... --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.129.132.206