交通感知行程规划

交通感知行程规划结合了客户的出发地、目的地、时间限制、出行方式和当前出行状况，以及权威的路线规划或公共交通服务，使企业能够指导客户进行切实可行的出行。语言模型能够解读自然语言约束并解释可比较的选项。路线规划、交通状况和公共交通系统在几何形状、拥堵情况、时刻表、延误和服务警报方面仍然具有权威性。该地图保存共享的行程状态，因此返程路线规划和后续问题仍以相同的酒店、场所或车站为锚点。

以下章节将路线规划、交通和公共交通与空间人工智能区分开来，然后涵盖驾驶预计到达时间、实时服务状态、返程路线规划、沿途发现、Kaleidr 地图绘制和测量。相关阅读包括AI 寻路助手、酒店 AI 宾客礼宾服务 和AI 餐厅搜索和订位。已确定实施方案的团队可以直接跳至 Kaleidr 地图绘制部分；仍在确定数据边界的团队应从图层区分开始。

感知交通的行程要素

• 优先考虑路线规划、交通和公共交通： 路径、持续时间、拥堵情况、时刻表、行程更新和服务警报等信息保留在出行系统中。
• **空间人工智能第二层级：**语言模型解读意图、提取约束条件、比较各种可行方案并解释权衡取舍。
• **硬性约束优先于偏好：**到达截止时间、禁止驾车规则或必需的无障碍属性是资格条件，而非软性排名。
• **可见的行程状态：**起点、终点、交通方式、到达截止时间或出发时间以及返程锚点应显示为可检查字段。
• **衡量结果：**路线开始次数、返程路线使用情况和主持人操作比单独使用地图平移或聊天时长更有效。

空间人工智能解读行程；路线规划、交通和公共交通系统提供出行信息。

为什么交通感知行程规划是企业对企业空间人工智能领域的一个问题？

酒店、目的地平台、活动应用、旅游市场、校园、本地服务产品和出行应用已经拥有第一方上下文信息，例如已预订的房源、场地、车站或已批准的目的地列表。将这些地点绘制为标记不再是稀缺功能。产品问题在于，如何在实时路况和交通状况下，帮助客户选择切实可行的往返路线，而无需依赖语言模型来生成路线。

Kaleidr 目前将“交通”和“运输”列为空间人工智能产品故事，并将“本地交通和返程路线规划”列为客户旅程，该旅程为用户提供本地交通选择、分步路线和便捷的返程方式（面向企业的 AI 地图体验）。 用于客户发现的 AI 地图聊天 页面目前将旅行描述为将意图转化为行程、路线和目的地推荐，并将移动出行列为对话层可以支持的垂直领域之一。这些页面是 Kaleidr 自身定位的权威依据。这些页面并不能证明 Kaleidr 运营交通传感器网络或 GTFS Realtime 连接器，也没有声称每个主机都必须替换其路由提供商。

交通、公共交通、路线规划和空间 AI 有何区别？

路线规划回答了指定交通方式下连接起点和终点的路径。路线规划引擎可以从其拥有的网络中返回道路、步行或骑行的几何形状、距离、持续时间、备选方案和逐向转弯步骤。交通信息则添加了不断变化的路网状况，例如拥堵、当前速度、事故、延误和道路封闭（如果提供商支持这些字段）。交通感知路线可能与仅基于静态路网计算的路线有所不同。Transit 添加了已安排和实时的公共交通服务：行程、换乘、步行路段和当前服务状态。空间人工智能 (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}
}