[其他]
我發電郵查詢GTFS-RT實時資訊所獲之回覆
[複製鏈接]
|
本帖最後由 s3n370 於 2025-3-21 13:49 編輯
kay 發表於 2025-3-21 13:11
說服呢個字眼未夠好
應該係用story telling
同意
樓主其實進步佐唔少，劈頭已經想解決問題搵出路。
有D似政府話烏爸非法之後搵保險、搵的士合作嘅影子。
起碼唔係之前咁怨呢樣怨果樣，亦都好努力解答質疑。
呢D絕對值得肯定。
雖然以香港嘅環境，我對樓主嘅方案有幾大益處有保留。
不過我好希望我係錯嘅~
回番樓主，若說用番citymapper咁用schedule配對，
再map real time data會miss out佐一D real time可行嘅行程。
其實擴大起始配對嘅範圍，即係系統可能一開始會rule out佐太長轉乘等候時間，
只要將等候時間個range擴闊會唔會幫到手？
反正幾落後嘅route planner點都會分析同出多個方案架啦
（我估樓主無乜可能無諗過，只係呢個方向可能有問題？）
|
|
|
|
|
|
|
|
|
呢套產品喺芬蘭已經行之有效，喺其它歐美國家（包括挪威、丹麥、瑞典等）亦都廣泛採用，之前亦都有公司試圖喺非洲落後地區以 crowd source 方式做 data gathering 不過可惜失敗收場，唯獨是係亞洲嗰邊唔多見有 application 。
英國嘅問題係啲系統比較舊，好多都係 pre-date 現時標準，但係同樣嘅資料可以用其它方式搵到，所以將啲系統現代化，接入國際標準就已經可以將芬蘭質素嘅體驗帶到入去。既然香港本身先進過英國，根本當初一開始唔應該有呢啲問題。
至於話關於等車時間加 schedule 方面， OpenTripPlanner 嘅 algorithm 係以每轉一次車為一個 iteration 方式，首先由起點站出發，按時間順序睇下首先上最快到站嘅路線，睇下一程車可以去到邊；然後再由呢啲可達車站睇下轉另一條路線，睇下一程可以去到邊，如此類推。
而點解話用 schedule data 會 miss 咗某啲唔理想，但 real time 變得理想嘅方法呢？因為個系統係以時間表運作，佢唔會假設條線每班車嘅行車時間都一樣（所以佢會 filter 咗同一條線入面嘅 overtaken journey ），例如由A站去B站，12:00出發：
如果個站有1號線，12:05分開車，一程過，12:35分到B站，咁當然即刻搵到；搵晒一程過嘅方法之後，如果有條特快3X線，12:08分開，12:10分到去轉車站，咁都會搵埋，但係如果下班車由轉車站開去B站嘅4X線要13:00先開，個 algorithm 已經停咗唔會搵到，因為你已經有個更好選擇，就係一程過，12:35到B站。
如果個 algorithm 套用咗 real time data ，知道原本12:07分喺轉車站開（所以本應送車尾），12:17分到目的地嘅4X線延誤到12:15轉車站開，12:25分到目的地，咁佢就會識搵出來，因為免轉車嘅最優解係12:35到達，但個時間未到12:35，所以會繼續搵落去，從而搵到更好選擇；如此類推，搵晒轉一次，之後到轉兩次，轉三次，如此類推等等，直到無更優解為止。佢唔會關心嗰兩條特快線嘅「車程」真係好快（除非你改個 optimisation criteria 要求等車時間嘅 cost 係 0，但呢個當然不切實際，因為咁佢會叫你由朝等到晚搭一日一班嘅繁忙時間直達車）
|
|
|
進智公交
|
|
|
|
|
|
本帖最後由 miklcct 於 2025-3-22 01:54 編輯
咁 open source development 的確係 mutual benefit ，因為唔同交通營辦商都有同樣嘅 business need ，所以大家一齊合作做一件合乎國際標準嘅產品就對大家都有利。
舉例 ， OpenTripPlanner 嘅開發主要係由芬蘭 HSL 、 挪威 Entur ，以及向交通營辦商提供服務嘅專家 Leonard 等等出資，每間公司都有自己 technical team 去開發自己需要嘅功能，同時亦都可以採用其它公司開發咗，對自己有用嘅功能，互惠互利。
我成篇文章都係以 mutual benefit 為出發點，唔能夠偏頗任何單一營辦商。
|
|
|
進智公交
|
|
|
|
|
|
miklcct 發表於 2025-3-21 17:47
呢套產品喺芬蘭已經行之有效，喺其它歐美國家（包括挪威、丹麥、瑞典等）亦都廣泛採用，之前亦都有公司試 ...
未用過OpenTripPlanner
據你所述，佢唔會剩係出最佳方案，而係會俾幾個你揀。咁係咪唔會即時篩走佐D無咁好嘅方案呢？
我所講嘅正正係改篩選嘅criteria。
舉個例，搵其他trip planner search荃灣去油麻地，正路最快嘅係紅線直達，
而明顯地响太子/旺角轉綠線好有機會係次快同第三快。
正路出多個suggestion時除佐最快嘅紅線，
之後就會彈屯馬轉紅線/30X等慢好多明顯唔同路嘅方法。
唔熟可以點篩走D紅線轉綠線都快但係廢嘅方法，
個人嘅gut feeling係可以响篩選criteria著手？ |
|
|
|
|
|
|
|
|
KE7066 發表於 2025-3-21 18:54
又睇返之前 GTFS 隻 post
https://www.hkitalk.net/HKiTalk2/forum.php?mod=redirect&goto=findpost&ptid ...
外地一樣有呢個dilemma
不過呢D trip planner有助增加公交使用率做大個餅
更多嘅係考慮公共交通如基建，計埋social benefits落去
呢兩點响香港嘅效應就細好多 |
|
|
|
|
|
|
|
|
或者咁講有無其他solution
唔知係咪因為睇完樓主篇野
我有日見到個AD話有隻APP可以用AI去預估班車到站時間間距
開過黎睇雖然係爛野
但似乎有其他野可以入手
大家都知一班車幾點到站係有隨機性
咪收集一段時間既資料
再去睇佢分布大概邊個range會出現機會最多(頭尾個10%唔計)
真係做得好可以連平日/周五六日
晴天雨天都可以再調整
但應該無論點tune都好難好可靠
其實巴士公司預定班次
唔同時間出既野都可以唔一樣
巴士公司都係BASE ON行車記錄去計ETA
真係要做到好精準其實就應該睇行車記錄
|
|
|
合理行為不容無理干涉,後果自負
|
|
|
|
|
|
其實以香港公共交通的普及程度，班次的頻密度和以及不同組乘客用交通App的習慣，是否有需要投資去做一個水晶球級別的Journey Planner啦？至少對於各大交通公司而言，做大個餅不是首要考慮（因為公共交通使用比例已經是世界上數數二最高的城市），做大自己嗰餅也許是考慮之一，但更著重的是成本效益和運作效率，這不是Jornery Planner可以直接提供到的好處。
唔知大家知唔知，Google Map是需要搵第三方供應商協助才可以做到香港的journey planner，直至近幾年才傾到一間公司直接提供編定班次數據，實時數據還是傾唔到，連早幾年如日方中的Google都做唔到嘅野，看來以後都比較難有去做到。
現時已經是AI的年代，Journey Planner是否仍然沿用10幾年來的編定班次為主，實時資訊為輔的方式，答案未必是否定的，因為重點是如何在N咁多個可行組合中找出最好的答案，當中實時班次只是其中一個考慮元素，其他元素還包括價錢，轉乘優惠，步行距離，無障礙設施，個人習慣，地理限制等等，而且答案可以因人和因use case而變。AI與以前的Joruney planner相比，最大的好處是可以同時處理更多的數據，條件與可能性，突破以往journey planner無法處理的限制。
不過AI是要訓練的，所以Journey planner的演算法如何有效率和準確地去找尋路線，以及如何定義好的結果供AI作判斷，仍然是問題核心。
至於如何將journey planner做到具商業上的可能性，其實是有不少切入點的。希望樓主明白，mutual benefit只是最起碼的出發點，而不是足以令商業機構有興趣的切入點。 |
|
|
8!
|
|
|
|
|
|
本帖最後由 miklcct 於 2025-3-22 23:40 編輯
如果用我上面描述嘅方式，30X呢個結果會搵到（因為轉乘次數屬於最優），但係唔會出到嗰啲例如屯馬轉紅線等等，無論用任何 criteria 都非最優解嘅方法（假設由荃灣站出發）。
不過如果 real time data 話紅線荔景以北收檔，咁就會可能會出到為最快方案。
個 algorithm 係搵最佳方案，但係何謂最佳係有一定彈性，包括時間／轉乘次數／用戶喜好計算之公式等等，任一為最優解都會提供。例如你少少唔鍾意搭地鐵，你可以喺條公式將地鐵嘅時間值乘1.3；好唔想搭地鐵，可以乘4，咁個系統就會偏好其它交通，但如果地鐵有明顯優勢（例如尖沙咀去金鐘）仍然會推薦你搭。
OpenTripPlanner 喺個 algorithm 搵到結果之後可以調節再作篩選（例如佢任何情況下都會嘗試直接步行去目的地，但係會唔會輸出呢個結果就視乎同使用公交嘅結果比較），不過呢個已經係後話。
|
|
|
進智公交
|
|
|
|
|
|
咁你同城巴單deal有咩進展
另外唔見你講九巴
九巴係咪肯同你合作？
講大九巴先係最大個間
|
|
|
合理行為不容無理干涉,後果自負
|
|
|
|
|
|
|
Advertisement
Advertisement
Advertisement
Advertisement
Advertisement
|
樓主
