香港有不少交通和天氣資料來源。問題不是完全沒有資料，而是資料分散在不同網站、App、群組、地圖和通知中。對一般市民來說，慢慢查找還可以；對正在開工的司機來說，每次切換 App 都是成本。G63M 的核心工作，是把常用訊號整理成一個適合手機掃讀的流程。
公開交通消息
交通消息可以反映交通意外（事故）、封路、塞車（擠塞）、道路工程和特別交通安排，反映即時馬路情況。這些資訊通常文字較長，並且按時間更新。司機真正需要的是方向、地區、影響程度和是否仍然新鮮，而不是把整段公告逐字讀完。
| 來源 | 主要內容 | 更新頻率 / 性質 | G63M 點用 |
|---|---|---|---|
| 運輸署特別交通消息 | 交通意外、封路、道路工程、臨時交通安排 | 官方即時或按事件更新 | 抽出地區、方向、影響路段，避免長公告阻住掃讀。 |
| 運輸署行車速度 / CCTV / 交通快拍 | 主要幹道速度、路面影像、擠塞線索 | 官方公開，接近即時或定期刷新 | 配合交通消息判斷「公告仍有效定已散」。 |
| 運輸署交通通告 | 預早公布工程、活動、封路、交通改道 | 官方公告，按安排發布 | 分開「即時路面」和「政策/預告」，避免司機把下星期通告當成現在事故。 |
| 香港天文台 | 雨區、雷暴、酷熱、熱帶氣旋、能見度 | 官方天氣訊號，按天氣變化更新 | 影響雨天接單和需求指數，但會同路況一齊看。 |
| 香港國際機場 | 航班抵港、機場狀態 | 官方航班資料，按航班狀態更新 | 重建未來一小時機場需求，而不是只看一班機。 |
| data.gov.hk | 停車場、咪錶、部分交通及設施資料、隧道收費資料入口 | 公開資料集，各資料集有自己的更新節奏 | 把分散 JSON/XML/API 轉成司機畫面可讀的狀態。 |
| 易通行 / 香港出行易 | 隧道不停車繳費、過海隧道時段收費顯示 | 官方/授權系統，按收費點和時段顯示 | 用於過海成本判斷；實際收費以官方顯示為準。 |
天氣資料
香港天氣對道路需求影響很直接。雨、雷暴、酷熱、強風和能見度都可能改變乘客行為和道路速度。天氣資料本身是公開的，但司機需要的是它對接單和轉區的影響，而不只是天氣描述。
機場及泊車資訊
機場司機會留意航班抵港、泊車、道路和市區需求。單看航班資料容易誤判，因為乘客下機、過關、取行李和到達上車點需要時間。G63M 將機場相關資訊放在同一頁，方便司機用營運角度閱讀。
司機社群訊號
部分路面提示來自司機社群。這類訊號通常快，但格式不統一，也需要時間、地點和可信度判斷。G63M 的做法是把訊號整理、去重、保留時間和位置，避免舊消息長時間誤導司機。
G63M 點清理、去重、定位
原始交通文字不是直接丟上地圖。G63M 會先把同一事件的重複公告合併，例如同一條北大嶼山公路臨時安排不應出現三張卡；再把「往九龍方向」「近隧道口」「介乎 A 至 B」拆成司機看得懂的方向和路段。地名定位亦要保守：遇到「迴旋處」或交界名稱，若精確 geocode 失敗，會改用主幹道路段作 fallback；遇到「以下路段」這種列表開頭，則不應硬插一支錯 pin。
另一個例子是天氣 advisory。運輸署特別交通消息有時會出現「天雨路滑」之類一般提醒，文字裏有「路」字，但它不是一條叫「天雨路」的道路。G63M 會過濾這類提醒，避免地圖出現假地點。這些清理動作看似細，但對開車的人很重要：錯 pin、舊消息、重複卡，比沒有資料更容易誤導。
Worked example：同一事故點樣變成可用決策
假設 17:20 運輸署消息寫「因交通意外，觀塘繞道往油塘方向近麗港城慢線封閉，龍尾至啟業」。原文對一般讀者已足夠，但司機要的是決策：你在九龍灣準備接一張去藍田的單，原本估 12 分鐘；如果龍尾至啟業，代表上橋前已開始慢，實際可能多 10–15 分鐘。若該單預計收入 HK$85，而附近有一張去牛頭角、約 8 分鐘的 HK$55 短單，規則是先避開事故方向，做短單等路面恢復；除非藍田單有明顯加乘或乘客距離非常近，否則不值得入事故隊尾。
為甚麼要整合
- 減少切換 App 和重複閱讀。
- 把長文字轉成地區、時間和狀態。
- 讓司機用同一個畫面比較交通、天氣、機場和需求指數。
- 保留原始資訊的參考性，同時避免把預測當成保證。
G63M 不是要取代所有官方或第三方資料來源，而是做司機開工時的整合層。當資料被整理成可掃讀、可比較、可按地區理解的格式，司機才更容易把資訊轉化成實際行動。