交通感知行程規劃

交通感知行程規劃結合了客戶的出發地、目的地、時間限制、行程方式和目前行程狀況，以及權威的路線規劃或公共交通服務，使企業能夠指導客戶進行切實可行的行程。語言模型能夠解讀自然語言限制並解釋可比較的選項。路線規劃、交通狀況和公共交通系統在幾何形狀、擁塞情況、時刻表、延誤和服務警報方面仍然具有權威性。地圖保存共享的行程狀態，因此回程路線規劃和後續問題仍以相同的飯店、場所或車站為錨點。

以下章節將路線規劃、交通和公共交通與空間人工智慧區分開來，然後涵蓋駕駛預計到達時間、即時服務狀態、返程路線規劃、沿途發現、Kaleidr 地圖繪製和測量。相關閱讀包括AI 尋路助理、飯店 AI 賓客禮賓服務 和AI 餐廳搜尋和訂位。已確定實施方案的團隊可以直接跳至 Kaleidr 地圖繪製部分；仍在確定資料邊界的團隊應從圖層區分開始。

感知交通的行程要素

• 優先考慮路線規劃、交通和公共交通： 路徑、持續時間、擁塞情況、時刻表、行程更新和服務警報等資訊保留在行程系統中。
• **空間人工智慧第二層級：**語言模型解讀意圖、提取限制條件、比較各種可行方案並解釋權衡取捨。
• **硬性約束優先於偏好：**到達截止時間、禁止駕駛規則或必需的無障礙屬性是資格條件，而非軟性排名。
• **可見的行程狀態：**起點、終點、交通方式、到達截止時間或出發時間以及返程錨點應顯示為可檢查欄位。
• **衡量結果：**路線開始次數、回程路線使用和主持人操作比單獨使用地圖平移或聊天時長更有效。

空間人工智慧解讀行程；路線規劃、交通和公共運輸系統提供行程資訊。

為什麼交通感知行程規劃是企業對企業空間人工智慧領域的問題？

飯店、目的地平台、活動應用、旅遊市場、校園、本地服務產品和行程應用程式已經擁有第一方上下文訊息，例如已預訂的房源、場地、車站或已批准的目的地列表。將這些地點繪製為標記不再是稀缺功能。產品問題在於，如何在即時路況和交通狀況下，幫助客戶選擇切實可行的往返路線，而無需依賴語言模型來產生路線。

Kaleidr 目前將「交通」和「運輸」列為空間人工智慧產品故事，並將「本地交通和返程路線規劃」列為客戶旅程，該旅程為使用者提供本地交通選擇、逐步路線和便捷的返程方式（面向企業的 AI 地圖體驗）。 用於客戶發現的 AI 地圖聊天 頁面目前將旅行描述為將意圖轉化為行程、路線和目的地推薦，並將移動行程列為對話層可以支援的垂直領域之一。這些頁面是 Kaleidr 自身定位的權威依據。這些頁面並不能證明 Kaleidr 營運交通感測器網路或 GTFS Realtime 連接器，也沒有聲稱每個主機都必須替換其路由提供者。

交通、大眾運輸、路線規劃和空間 AI 有何不同？

路線規劃回答了指定交通方式下連接起點和終點的路徑。路線規劃引擎可以從其擁有的網路中返回道路、步行或騎乘的幾何形狀、距離、持續時間、替代方案和逐向轉彎步驟。交通資訊則增加了不斷變化的路網狀況，例如擁塞、目前速度、事故、延誤和道路封閉（如果提供者支援這些欄位）。交通感知路線可能與僅基於靜態路網計算的路線有所不同。 大眾運輸新增了已安排和即時的公共交通服務：行程、轉乘、步行路段和目前服務狀態。空間人工智慧 (Spatial AI) 解讀客戶請求，提取約束條件，比較候選路線，並將選定的選項轉換為地圖操作。語言模型不應取代路線或交通管理機構。

Google 目前記錄了三種 Routes API 路線偏好：TRAFFIC_UNAWARE 用於利用路網和平均時間無關條件實作最快回應；TRAFFIC_AWARE 用於在延遲最佳化的情況下獲取目前交通資訊；TRAFFIC_AWARE_OPTIMAL 用於在較高延遲下進行更全面的即時交通搜尋 (Google, 2026)。該頁面是某生產環境路線提供者的流量合約的證據。該頁面並不能證明每個 Kaleidr 部署都使用 Google 路線，也不能描述 Kaleidr 流量。

GTFS Realtime 目前支援四種可共享相同資料來源的實體類型：行程更新、服務警報、車輛位置和行程修改 (GTFS, 2026)。因此，公車產品需要的不只是道路路徑圖。服務警報可以描述影響車站、線路或更廣泛網路的中斷情況，這與繪製移動車輛是不同的工作。

可靠的行程助理能夠將語言推理與路線計算和即時服務資料分開。

哪些系統應該擁有旅程資訊和即時行程狀態？

客戶意圖遠不止起點加終點。例如，一位客人可能會要求在晚上 7 點前到達某個場所，步行時間不超過十分鐘，避免駕車，並在活動結束後返回飯店。語言模型可以將這句話轉換成行程系統可以評估的結構化欄位：起點識別碼、終點識別碼、到達時間、允許的行程方式、最大步行時間以及返回錨點。任何範例中的結構都只是範例。關鍵在於，模糊的語言能夠轉換為可檢查的狀態，客戶無需重新開始對話即可進行修正。

硬性約束是二元的。例如，到達截止時間、禁止駕駛的規定、資料支援的情況下提供輪椅無障礙交通，或活動結束後回程服務仍運行的要求，都應在排名前篩選候選路線。軟性偏好，例如較少的轉乘次數、較少的步行或較短的行程時間，則用於對剩餘的有效路線進行排名。即使轉乘次數較少，錯過活動開始時間的路線也不應勝出。

精確的幾何圖形仍屬於空間引擎的範疇。生產系統應允許語言模型解釋意圖並選擇操作，而路線規劃和公車服務則負責計算路徑、持續時間、轉乘次數和即時狀態。 如何建構地圖感知型AI助理涵蓋了地圖操作的相同應用層驗證。

交通感知駕駛應如何利用目前路況？

駕駛品質會隨著目前路況、出發時間、事故以及服務提供者的交通偏好而改變。 Google 的目前值 Routes API 也區分了 duration（考慮交通感知模式下即時路況的預計到達時間）和 staticDuration（僅考慮歷史路況資訊的預計到達時間）(Google, 2026)。當服務提供者傳回這些值時，產品可以將它們作為客戶資訊顯示出來。解釋可以說明目前駕駛速度低於歷史基準值。分鐘數必須來自路線規劃系統。

「最快路線」並非兩個座標的靜態屬性。同一家飯店和同一地點，在上午 8:00、下午 3:00 和晚上 11:30 可能會產生不同的駕駛路線，因為交通狀況和道路封閉情況會發生變化。應將出發或到達時間儲存在行程對像中。當乘客等待、更改行程方式或延後出發時，應重新計算路線。不要要求語言模型在條件變化後修補幾何圖形。

交通可視化不應過度承諾精度。彩色路段、擁塞標記、預計到達時間差異和事件標註只有在服務提供者實際提供的粒度範圍內才是準確的。一條路線層級的「行駛速度低於正常水準」的描述，可能比人為地新增一個資料來源中並不包含的道路層級擁塞疊加層更為準確。

為什麼大眾運輸是一個服務狀態問題，而不是路徑問題？

公車路線規劃取決於服務，而不僅僅是地圖幾何形狀。行程可能會因航班延誤、取消或新增、跳過站點、車站關閉或繞行路線變更而變更。 GTFS Realtime 的存在正是為了傳達這些變化的情況 (GTFS, 2026)。當資料來源同時提供預定到達時間和即時預測到達時間時，產品助理應區分二者。

缺少即時資訊並不代表行程準點。 GTFS Realtime 行程更新指南指出，如果預定行程沒有更新資訊，消費者應認為該行程沒有即時資料，不應假定行程準點 (GTFS, 2026)。面向客戶的產品應說明預定出發時間已知但即時狀態不可用，而不是僅憑無即時資訊就報告「準點」。

服務警報與車輛位置同樣重要。即使目的地車站關閉或線路停駛，移動標記仍然可以反映糟糕的行程。車輛位置最佳實踐建議使用穩定的車輛識別碼和位置測量時間戳，並建議至少每 30 秒刷新一次資料，行程更新和車輛位置資料不應超過 90 秒 (GTFS, 2026)。將移動標記用作輔助資訊。行程是否符合資格仍取決於行程更新、停靠順序、警報以及所選行程是否仍服務於乘客的目的地。

多模式行程應明確列出各路段：步行至車站、搭乘火車、步行至活動地點。類似的選項應共用相同的列，例如預計到達時間、步行時間、轉乘次數和即時狀態。最快的選項並非總是首選。攜帶行李的乘客可能願意多花幾分鐘以避免轉乘。空間人工智慧很有用，因為可以用自然語言表達偏好，同時路線提供者仍然可以計算出有效的候選路線。

無障礙功能必須基於受支援的資料。只有當行程資料來源公開了相應的屬性時，無障礙交通請求才算是硬性約束。不要從網站名稱、地圖圖片或通用模式資訊推斷無障礙功能。如果可用資料無法驗證該需求，請明確說明。

為什麼返程路線規劃是一項獨立的客戶任務？

返程路線規劃不僅僅是第二次通用的 A 到 B 搜尋。產品已經知道業務錨點：預訂的飯店、會議場地、郵輪碼頭或校園大門。詢問「音樂會結束後我該如何返回？」的客人不應該需要重新進入飯店。 Kaleidr 目前在首頁將該任務命名為「本地交通和返程路線規劃」。保留包含出發地、目前目的地、下一個行程安排、預計返回時間和交通方式的共享行程對象，以便後續操作（例如返程途中用餐或半小時後出發）可以在同一行程中完成。

如果產品能夠在後續問題中保留顧客的主要出發點和行程上下文，返程路線規劃將更加實用。

到達時間和出發時間是不同的意圖。 「6:15離開飯店」是出發時間。 「7點前到達活動場所」需要反向推算行程時間，包括等待時間、轉乘、步行、交通狀況和服務時刻表。路線或交通系統應該進行時間計算。語言模型應該保留顧客指定的意圖。

共享地圖狀態確保對話和地圖始終處於同一規範行程中。選擇自駕路線時，應更新繪製的路線。詢問「搭乘大眾運輸工具如何？」時，應保持相同的起點和終點。詢問「如何返回？」時，應保持相同的起點和終點。應該立即解析返回錨點。第二個僅供助理使用的不可見路線集違反了這項約定。地圖是一種視圖。路線對像是結構化資料，產品不應根據視口中可見的任何內容重建它。

沿途發現與附近搜尋有何不同？

出遊和地點發現通常會在同一旅程中交會。客戶可能會要求在返回飯店的途中尋找晚餐地點、目前路線附近的藥局，或在車站前尋找咖啡店。相關的關係是候選地點相對於現有路線的位置，而不僅僅是靠近目前標記點的位置。兩家餐廳可能位於距離路徑直線距離相近的位置，但一家會增加 3 分鐘的行程時間，而另一家則會增加 14 分鐘。當路線提供者支援時，增加的行程時間或增加的距離比半徑更有用。 AI 餐廳搜尋和餐桌預訂 和 商店感知購物 AI 涵蓋了這些站點的目的地側；移動層提供繞行路線。

沿途搜尋仍需確認商家是否符合資格。營業時間、預訂政策和庫存資訊仍由其所屬系統管理。路線規劃引擎只能判斷該站點是否在剩餘行程預算之內。位置智慧客戶體驗涵蓋了面向客戶的位置產品的相同「發現 → 比較 → 行動」模式。

交通感知行程規劃與車隊最佳化、場館尋路有何不同？

「AI路線規劃」通常指的是物流：分配司機、安排數百個站點、減少車隊里程或規劃運力。車隊最佳化屬於不同的產品類別。本文中的交通感知行程規劃面向客戶：一位客戶、一次行程、目前空間環境和可信賴的行程資料。 Kaleidr 目前的公共定位更接近客戶行程層面，而非專用的車輛路線最佳化器。

場館尋路是第三種架構。 AI尋路助理專注於複雜場所內的目的地解析、場館幾何形狀、室內連通性、存取和定位。交通感知行程規劃則著重於城市尺度的起點和終點、道路交通、本地公共交通、出發或到達時間、返程以及路線感知的地點發現。兩者可以在場館入口處匯合。它們不應共享同一個未區分的堆疊。 AI活動場館地圖涵蓋了城市尺度行程結束後室內的交接。

Kaleidr如何對應到交通感知行程規劃？

Kaleidr的實作可以將對話空間圖層附加到主機已執行的地圖和行動堆疊上。 Kaleidr目前將聊天功能描述為一種產品，它可以附加到主機已渲染的地圖上，繪製已解析的地點，並在對話解析位置時調整相機畫面（聊天附加）。公共平台 API 目前記錄了一個路由控制端點 POST /chat/control/route，以及 places[]、profile 和 raw_query（端點）。此端點清單證實了目前公共開發者介面中存在面向路由的交互作用。但同樣的文件並未承諾提供原生運輸資訊來源、GTFS Realtime 資料攝取，或本文所述的所有多模式路由功能。

這些資料來源和路由服務應保持明確的部署相依性。 Kaleidr 可以提供對話式空間圖層和地圖感知協調，而部署則使用相應的權威交通、公共交通和路由資料來源。除非部署文件中明確記錄了具體的整合，否則請勿暗示 Kaleidr 本身就是交通帳本或公共運輸機構。

瀏覽器層和應用層的邊界仍然適用。可發布密鑰用於瀏覽器 SDK；伺服器憑證屬於應用層。 Kaleidr 文件目前記錄了這種劃分，並指出以 bearer 形式提供的可發布金鑰將被拒絕（Auth & scopes）。設備位置是單獨的權限。目前的 W3C 地理位置候選建議快照要求在與 Web 應用程式共用任何位置資料之前，必須獲得最終使用者的明確許可（W3C, 2026）。旅程產品仍應支援明確的起點，例如飯店、場所、地址、車站或選定的地圖點。當客戶要求從目前位置開始時，設備位置會有所幫助。如果產品已經具有更好的業務錨點，則不應要求設備位置。 用於 AI 地圖工作流程的私人位置資料 涵蓋了主機不公開的行動資料的授權。

Kaleidr 目前描述的是一個包含精選目的地和點擊查詢地點摘要的飯店模板；其初始版本為 Kaleidr Hospitality。在依賴特定生產工作流程之前，請在 定價與計畫 上確認目前計畫的額度。請將目前的開發者文件視為整合合約；行銷頁面描述的是用例，而非行程資訊清單。

哪些 B2B 產品需要此旅程層？

飯店住客可以詢問前往場館最方便的方式以及演出結束後如何返回。飯店本身就是客人的落腳點。系統可以在飯店資料支援的情況下，比較駕駛、大眾運輸、步行和已核准的接駁車，然後將飯店保留為回程點。飯店仍然是接駁車時間和賓客服務的權威來源。 飯店 AI 賓客禮賓服務涵蓋了飯店方圍繞旅程展開的對話。

活動參與者可以詢問從飯店出發，為了在9點前到達主題演講地點，是開車還是搭乘大眾運輸。本產品可比較考慮交通狀況的駕車預計到達時間與目前服務狀態的公共交通路線，然後將選定的目的地提供給場館導航系統。目的地平台可以詢問訪客是否可以在參觀博物館、附近用餐，並且還能在火車到達車站之前到達。本地服務產品可以詢問前往機場的途中是否有藥局，且不會增加超過指定分鐘數的行程。在每種情況下，模型都會解讀請求順序。底層系統會驗證每個步驟。

保持AI與地圖之間的互動簡潔：設定起點和終點，顯示路線或替代方案，突出顯示某個站點，顯示服務提醒，顯示沿途地點，顯示返迴路線，或清除路線。主持人會驗證操作。不要讓模型發出任意地圖程式碼。路線選擇應始終由使用者控制。對話系統可以推薦出遊方式。使用者仍應該能夠選擇其他路線、出發時間或其他目的地。

如何維持即時行程資料的有效性和可衡量性？

交通和公共交通對時間非常敏感。每個即時欄位都需要一個「時效性」資訊。上文提到的 GTFS Realtime 最佳實務窗口是生產者方的「新鮮度」協議，而非 Kaleidr 服務等級協定 (SLA)。使用者介面可以顯示目前狀態、延遲狀態、僅限計劃狀態和重新驗證狀態，因此過時的旅行資料與最新結果的可靠性不同。在執行諸如“開始路線”或“立即出發”等關鍵操作之前，請刷新路線或交通狀態。如果道路封閉、列車取消、交通高峰或乘客更改目的地，則應使舊路線失效，向權威系統請求新路線，並使用可追溯到目前提供者結果的值來解釋差異。

即時行程資料應反映其新鮮度並轉化為客戶體驗，而不僅僅是用於地圖動態顯示。

地圖平移和聊天開啟次數是診斷指標。結果指標包括行程搜尋開始次數、返回選項次數、無路線率、行程方式變更次數、路線選擇次數、回程路線請求次數、沿途地點選擇次數和路線開始次數。品質指標包括刷新率、資料過期率、非即時狀態率、服務警報觸發率和路線失敗率。業務指標取決於主辦單位：活動到達率、景點選擇率、餐廳預訂率、飯店入住率或本地服務轉換率。返程路線與去程路線分開衡量。保留結構化的無路線原因，例如無公共交通服務、起點未解析或無障礙資料不可用，而不是僅顯示失敗標誌。 地圖互動和位置分析目前記錄地圖和地點互動；主辦系統仍然負責預訂和出席情況。同樣的衡量標準也適用於其他地圖產品：任務完成度高於原始互動量。

以下對比僅為範例，並非實際測量結果或機構資料。僅用於說明為何不同選項需要相同的欄位。實際產品應根據目前的路線規劃和交通回應填充這些列。

通用的「最佳路線」評分可能會掩蓋這些權衡取捨。如果某個選項勝出，請說明原因：例如，到達時間早於 7 點、總時長、中轉次數、步行距離低於既定偏好。不要捏造服務提供者未提供的可靠性評分。

B2B 試點計畫應該如何啟動？

首先從一項高價值任務入手，例如幫助飯店客人前往重要活動並返回。將路線規劃、交通和公共交通資訊保留在現有服務提供者處。將對話式地圖互動功能新增至現有地圖。將飯店定義為起點，將目的地限制在已批准的場所，記錄即時資料的更新情況以及在即時資料缺失時的備用方案，並衡量路線選擇以及後續的營運商操作。僅在首次行程成功後才擴展行程方式和城市。

對話式行程規劃並不能取代網路品質、代理商資料或執行規範。出遊時間仍為預估價。即時公共交通資訊的準確性取決於其背後的資料品質。將助理新增到現有地圖通常比替換渲染器更經濟，但營運商仍需要擁有授權、與旅遊服務提供者簽訂合約以及後續業務操作。

探索 Kaleidr Spatial AI，以在現有地圖上新增對話式行程搜尋功能。 探索 Kaleidr Enterprise，了解圍繞目前行動技術堆疊的 SDK、推理 API、分析和部署支援。在將本文中的任何範例視為交付合約之前，請務必確認目前的公開頁面。

常見問題解答

什麼是交通感知行程規劃？

交通感知行程規劃結合了客戶的出發地、目的地、時間、行程方式和目前行程狀況，以及權威的路線規劃或公共交通服務，然後利用空間人工智慧來解讀約束條件、比較有效選項，並保留地圖和返程上下文資訊。

交通感知行程規劃與一般路線規劃有何不同？

普通路線規劃計算兩點之間的路徑。交通感知行程規劃也會使用即時道路或交通狀態、飯店等業務錨點、到達或出發意圖，以及針對相同行程對象的後續問題。

語言模型是否應該產生路線？

不應該。路徑規劃引擎應保持對路線幾何形狀和持續時間的權威性。交通和公車系統應保持對擁擠、時刻表、延誤和警報的權威性。助理可以解釋這些結果。

這與車隊路線最佳化相同嗎？

不同。車隊最佳化通常會為多輛車分配和排序多個停靠點。本文重點關注面向客戶的行程，這些行程涉及少量起點、終點和上下文相關的停靠點。

什麼是回程路線規劃？

返程路線規劃會保留一個有意義的錨點，例如飯店、場館、車站或物業，以便使用者在造訪其他目的地後可以詢問如何返回。

空間人工智慧可以比較駕駛和公共交通嗎？

可以，前提是部署系統擁有兩種行程方式的權威路線規劃和公共交通資料。助理可以比較返程路線，但行程時間和車輛狀態資訊應來自行程系統。

什麼是 GTFS Realtime？

GTFS Realtime 是一種公共運輸資訊規範，用於提供目前行程更新、服務提醒、車輛位置和行程修改資訊。

若公車即時資料缺失，是否應視為準點？

否。 GTFS Realtime 指南指出，消費者不應僅因為沒有即時更新就假定已安排的行程準點。

路線助理可以使用目前路況資訊嗎？

可以，前提是路線提供者支援路況感知路線規劃。 Google Routes 目前將路況感知和路況感知最優偏好作為此類服務的範例。

Kaleidr 可以取代路線提供者嗎？

不建議這樣做。 Kaleidr 可以圍繞現有的地圖和行程解決方案，新增對話式空間人工智慧和地圖感知路線協調功能。請參考目前的開發者和企業文件以確認具體的整合方案。

Kaleidr 目前是否提供了原生 GTFS Realtime 資訊流連接器？

目前的公開開發者文件中沒有通用的 GTFS Realtime 連接器。除非特定的 Kaleidr 整合另有說明，否則應將交通資訊流的導入視為明確部署相依性。

Kaleidr 目前是否提供了交通資訊流 API？

目前的公開文件記錄了聊天和路線控制功能，但沒有公開通用的獨立交通資訊流 API。交通資料應與部署中使用的路線或行程資料來源保持關聯。

B2B 產品應如何衡量旅程智能？

衡量成功路線結果、路線選擇、模式切換、返程路線使用情況、路線刷新、無路線原因以及下游業務行為，例如預訂、參與、景點選擇或本地服務轉換。

參考文獻

1. Kaleidr. AI-Powered Map Experiences for Business. Accessed 8 September 2026. https://kaleidr.com/
2. Kaleidr. AI Map Chat for Customer Discovery. Accessed 8 September 2026. https://kaleidr.com/ai
3. Google. Set the level of traffic data. Routes API. Accessed 8 September 2026. https://developers.google.com/maps/documentation/routes/config_trade_offs
4. General Transit Feed Specification. Feed Entities. GTFS Realtime. Accessed 8 September 2026. https://gtfs.org/documentation/realtime/feed-entities/overview/
5. General Transit Feed Specification. Trip Updates. GTFS Realtime. Accessed 8 September 2026. https://gtfs.org/documentation/realtime/feed-entities/trip-updates/
6. General Transit Feed Specification. GTFS Realtime Best Practices. Accessed 8 September 2026. https://gtfs.org/documentation/realtime/realtime-best-practices/
7. W3C. Geolocation. W3C Candidate Recommendation Snapshot, 26 March 2026. https://www.w3.org/TR/2026/CR-geolocation-20260326/
8. Kaleidr. Chat attach. Developer documentation. Accessed 8 September 2026. https://docs.kaleidr.com/sdk/chat-attach
9. Kaleidr. Endpoints. Developer documentation. Accessed 8 September 2026. https://docs.kaleidr.com/platform-api/endpoints
10. Kaleidr. Auth & scopes. Developer documentation. Accessed 8 September 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
11. Kaleidr. Kaleidr Hospitality. Template. Accessed 8 September 2026. https://template.kaleidr.com/customize/?template=hospitality
12. Kaleidr. Map Engagement and Location Analytics. Accessed 8 September 2026. https://kaleidr.com/analytics
13. Kaleidr. Location Intelligence APIs and Map SDK. Accessed 8 September 2026. https://kaleidr.com/enterprise

@misc{kaleidr_home_traffic_journey_2026_09_08,
  title  = {AI-Powered Map Experiences for Business},
  author = {{Kaleidr}},
  note   = {Accessed 8 September 2026},
  url    = {https://kaleidr.com/}
}

@misc{kaleidr_ai_traffic_journey_2026_09_08,
  title  = {AI Map Chat for Customer Discovery},
  author = {{Kaleidr}},
  note   = {Accessed 8 September 2026},
  url    = {https://kaleidr.com/ai}
}

@misc{google_routes_traffic_2026_09_08,
  title  = {Set the level of traffic data},
  author = {{Google}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/routes/config_trade_offs}
}

@misc{gtfs_rt_overview_2026_09_08,
  title  = {Feed Entities},
  author = {{General Transit Feed Specification}},
  year   = {2026},
  note   = {GTFS Realtime; accessed 8 September 2026},
  url    = {https://gtfs.org/documentation/realtime/feed-entities/overview/}
}

@misc{gtfs_rt_trip_updates_2026_09_08,
  title  = {Trip Updates},
  author = {{General Transit Feed Specification}},
  year   = {2026},
  note   = {GTFS Realtime; accessed 8 September 2026},
  url    = {https://gtfs.org/documentation/realtime/feed-entities/trip-updates/}
}

@misc{gtfs_rt_best_practices_2026_09_08,
  title  = {GTFS Realtime Best Practices},
  author = {{General Transit Feed Specification}},
  year   = {2026},
  note   = {Accessed 8 September 2026},
  url    = {https://gtfs.org/documentation/realtime/realtime-best-practices/}
}

@misc{w3c_geolocation_cr_2026_09_08,
  title  = {Geolocation},
  author = {{W3C}},
  year   = {2026},
  month  = mar,
  note   = {W3C Candidate Recommendation Snapshot, 26 March 2026},
  url    = {https://www.w3.org/TR/2026/CR-geolocation-20260326/}
}

@misc{kaleidr_chat_attach_traffic_journey_2026_09_08,
  title  = {Chat attach},
  author = {{Kaleidr}},
  note   = {Developer documentation; accessed 8 September 2026},
  url    = {https://docs.kaleidr.com/sdk/chat-attach}
}

@misc{kaleidr_endpoints_traffic_journey_2026_09_08,
  title  = {Endpoints},
  author = {{Kaleidr}},
  note   = {Developer documentation; accessed 8 September 2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

@misc{kaleidr_auth_scopes_traffic_journey_2026_09_08,
  title  = {Auth \& scopes},
  author = {{Kaleidr}},
  note   = {Developer documentation; accessed 8 September 2026},
  url    = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}

@misc{kaleidr_hospitality_template_2026_09_08,
  title  = {Kaleidr Hospitality},
  author = {{Kaleidr}},
  note   = {Template; accessed 8 September 2026},
  url    = {https://template.kaleidr.com/customize/?template=hospitality}
}

@misc{kaleidr_analytics_traffic_journey_2026_09_08,
  title  = {Map Engagement and Location Analytics},
  author = {{Kaleidr}},
  note   = {Accessed 8 September 2026},
  url    = {https://kaleidr.com/analytics}
}

@misc{kaleidr_enterprise_traffic_journey_2026_09_08,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  note   = {Accessed 8 September 2026},
  url    = {https://kaleidr.com/enterprise}
}