我發電郵查詢GTFS-RT實時資訊所獲之回覆

jpoon 發表於 2025-3-20 05:20
諗起條友話形點I上唔到B1嘅笑話
就算可以車駁車，都唔代表可以上到車
更何況路況嘅嘢話唔埋，突然有交通意 ...

講就好好，不過包裝欠奉，連要做咩出嚟都係搖擺不定

預測嘅嘢，統計學我唔識，過往呢度要講基本上都係得個拗字

但係轉邊條線嘅預測，本身係咪無做呢？

miklcct 發表於 2025-3-19 23:14
咁如果我企喺柴灣嗰陣，個電腦程式預測到我架788出到中環之後3分鐘會有5X，我咪會出到去轉；反之，如果個 ...

有 788 嘅地方根本第一程除咗 788/789 都無咩其他合理選項

呢啲用人腦都知應該要離開咗柴灣先諗下一步嘅問題
poor example

KE7066 發表於 2025-3-20 15:18
有 788 嘅地方根本第一程除咗 788/789 都無咩其他合理選項

呢啲用人腦都知應該要離開咗柴灣先諗下一步嘅 ...

小西灣個情況係極端
基本上上得788轉車幾乎係去邊度都唔會輸

衰D講, 下一程幾時有車, 去到轉車站之前先諗

根本就唔會走去預先夾

1181174166 發表於 2025-3-20 00:34
「出到中環之後3分鐘會有5X」，停多支燈或者揸慢少少已經企咗喺度，結果就係臨落車再睇有無車
再者，城巴 ...

GTFSRT 標準支持預測誤差（例如如果誤差3分鐘，個程式可以避免追1分鐘到嘅車；誤差係0分鐘嘅話，個程式可以教我追車），亦都支持載客量（可以警告我部車頂咗閘，會飛站）。

咁我目的當然係接入埋其它營辦商嘅資料，目的係叫我夾到5X或者18X時間就搭，否則如果下架有排等，用其它營辦商嘅服務會快啲，就用其它營辦商嘅服務啦。

miklcct 發表於 2025-3-20 17:53
GTFSRT 標準支持預測誤差（例如如果誤差3分鐘，個程式可以避免追1分鐘到嘅車；誤差係0分鐘嘅話，個程式可 ...

問題係：預測
根本即時係未有數
最重要係整合係對營運商一道雙面刃，自身唔一定最快
依然答唔到對巴士公司利益

1181174166 發表於 2025-3-20 18:02
問題係：預測
根本即時係未有數
最重要係整合係對營運商一道雙面刃，自身唔一定最快

咁，如上文描述過，自身當然唔一定最快，但整合晒全個地區所有營辦商嘅資料，以整體利益（所有營辦商利益總和）計算，一定係有利。人哋芬蘭 Digitransit 平台就已經做到呢點。最緊要係俾到乘客選擇，喺唔同營辦商之間作一個公平比較，例如A方法最快，B方法最密，C方法最穩定，一目了然。

Google Maps 原生用 GTFS ／ GTFS-RT 格式，但係今時今日都喺香港出唔到任何實時資料，已經知道個問題喺邊啦。

miklcct 發表於 2025-3-20 18:18
咁，如上文描述過，自身當然唔一定最快，但整合晒全個地區所有營辦商嘅資料，以整體利益（所有營辦商利益 ...

有利係對個客啫
對公司都係無說服力，吸唔到一回事，突顯人哋仲快先死
A唔一定
B人力成本貴
C香港咁多車手

miklcct 發表於 2025-3-14 13:41
咁而家香港有無 journey planner 可以整合全部交通模式同營辦商嘅 real time information ，再用機器計算 ...

（唔係做IT純粹亂咁估）
搵先搵schedule配對再搵real time data去map，
係咪會快過直接搵real time data配對呢？

因為先搵schedule配對，要搵黎做配對班次嘅range會窄好多。
而搵real time先唔好講點predict先，搵黎做配對嘅班次要多好多，處理就會慢佐。

講到點predict，架車開頭慢之後跑快D追時間，或者前快後慢去跟番timetable。
咁我得前段嘅data，點predict到後段嘅trend係一致地快/慢丫，
定係會人為地調整呢？

個人試過唔好話轉車，剩係睇住real time data落樓下等車都可能出事。
試過有日臨放工，見平時搭班車頭段遲佐近半個鐘，諗住响公司做多陣野先行出去巴士站。
我响架車嘅scheduled arrival time再check，都係遲緊27-28分鐘。
15分鐘後再check，再追多3分鐘，咁我咪即時走人，
反正車站响公司門口嘅對面馬路，正常情況下唔駛5分鐘就出到車站，點都唔會miss掛
點知車長喪跑到一個點，係我一出到去就見住架車啱啱落完客走人...

而更重要嘅係，trip planner响唔識路嘅人手上，
佢哋對時間嘅sensitivity未必咁大。

而對於識路但係想睇邊一邊快嘅用者，正路都知邊D位要預鬆D。
公共交通準到every minute counts已經唔易。
要trip planner做到呢點及無縫接駁，似乎係不可能嘅任務。

s3n370 發表於 2025-3-20 18:28
（唔係做IT純粹亂咁估）
搵先搵schedule配對再搵real time data去map，
係咪會快過直接搵real time data配 ...

首先，我懷疑 Citymapper 係先用 schedule plan journey ，然後 overlay 個 real time data 落去，我見過佢一開始出118分鐘然後一 load real time data 跳到全程87分鐘，因為某啲 connection 追到。

至於 OpenTripPlanner 呢，就係直接用 real time data 改個 timetable ，再用來 plan journey 。

prediction 呢樣嘢唔係 journey planner 嘅範疇，而係 data producer 嘅責任。 GTFS 標準有一個概念叫定時點（ timing point ），咁可以知道架車會唔會喺度等時間，定係會越來越快／慢；至於確實點樣預測，呢樣就係可以用來賺錢嘅範疇，舉例唔，而家已經有產品會自動話你知巴士改道，唔使經人手干預（佢嘅方法係連續3班車有同一個方式偏離路線就當係臨時改道），然後自動直出 GTFS-RT 俾所有 app 知道，無論你用邊隻 app 都可以得到同樣資訊。

至於 real time 點樣 match schedule ？ 好簡單，對字軌。部車嘅機（AVL）入面當然有字軌，咁直接配對就得；如果條線唔係行時間表，而係行班距（唔跟時間表運作），咁就另一回事。

你話跟 real time 等車出事，呢個亦都係 GTFS-RT 支持嘅範疇；如果個資料話係15分鐘有車，預期誤差係正負5分鐘，咁你差唔多到10分鐘嗰陣就可以睇部車有無跑快／慢到；如果某條線埋轉車站嘅誤差係3分鐘，另一條嘅誤差係5分鐘，咁個程式可以提供幾個選項：安全選項係避免叫人轉8分鐘以內嘅車（咁如果第二條線係半個鐘一班，就可能會叫你轉另一條唔同嘅路線）；一般選項就可能係留5分鐘（取兩者較高誤差）；趕時間模式就直接無視呢個數。尤其係當你嘅路程有好多個唔同選項，時間都差唔多嘅話，你可以經大隧、獅隧、青沙轉車都得嘅話，咁呢啲資料同選項就好重要。

Del