面向场馆的AI寻路助手

作者 The Kaleidr Team · 发布于 2026年8月27日 · 19 分钟读完

AI寻路架构将目的地发现、路线计算和可选的室内定位功能分离,最终显示经过验证的地图导航。

AI寻路助手能够解读自然语言导航请求,从可信的场馆记录中解析目的地,并协调地图或路线引导,而无需将发现、路径规划和定位视为单一功能。访客可以询问应该使用哪个入口、如何到达B厅,或者最近的无障碍洗手间在哪里。语言模型可以将这些字段恢复为可检查的意图;场地系统、路径规划引擎以及任何定位基础设施仍然对几何形状、连通性、访问权限和实时位置具有权威性。

以下章节涵盖目的地解析、室内连通性、无障碍访问和访问过滤器、起点、共享寻路状态、Kaleidr 当前的公共适用性、测量和故障模式。相关阅读包括面向活动的 AI 场地地图如何构建地图感知型 AI 助手位置智能客户体验地图面向酒店的 AI 宾客礼宾服务用于 AI 地图工作流程的私有位置数据

AI寻路要点

  • **发现并非路径规划:**找到B厅并不等同于计算通往B厅的路径。
  • **路径规划并非定位:**在产品知道访客所在位置之前,可能已经存在有效的路径。
  • **平面图并非网络:**室内导航需要空间、门、走廊和楼层过渡之间的拓扑结构。
  • **无障碍和访问是硬性筛选条件:**楼梯、员工走廊和封闭边缘必须从图中移除,而不仅仅是降低评分。
  • **语言模型解读意图:**地理空间和场馆系统计算路径;主办方验证地图操作。

AI寻路架构在显示已验证的地图导航之前,将目的地发现、路径计算和可选的室内定位分开。

什么是AI寻路助手?

AI 寻路助手是一个面向用户的界面,它利用对话、地图上下文和可靠的位置数据,回答用户在复杂场所应该去哪里以及如何到达目的地。普通的搜索只能返回房间名称,静态海报可以展示建筑物的平面图,但两者都无法将起点、楼层、门票资格、无障碍设施、实时封闭情况以及当前显示的路线整合到一个可查看的状态中。会议厅、校园、医院、机场、度假村和购物中心每隔几分钟就会产生这种复杂的需求。这款实用的产品会在地图上清晰地显示目的地、路线和楼层,而不是让用户从标牌、PDF 文件和无法移动摄像头的聊天面板中自行构建这些信息。

Kaleidr 的空间 AI 页面将“导航”列为地图体验之一,并描述了符合用户出行方式的路线 (AI Map Chat for Customer Discovery)。该页面权威地介绍了 Kaleidr 自身面向户外和旅行的导航定位功能。室内逐向导航属于不同的范畴:它包含目的地信息、可路由的网络,以及(仅在实际部署时)定位系统。面向客户的位置信息仍然采用“发现→比较→行动”的流程。“发现”用于检索符合条件的目的地。“比较”使楼层、行程关系、无障碍设施和访问权限可查看。“行动”用于突出显示、楼层切换、在存在路由的情况下请求路线,或人员交接。

任务应该在堆栈之前编写。例如,场地访客可能需要离座位最近的入口。会议参与者可能需要从当前会场到下一个会场的路径。机场旅客可能需要靠近登机口的指定休息室。校园用户可能需要离教室最近的建筑入口。医院访客可能需要从公共入口获取图像。每个任务的候选对象、硬性约束、垂直过渡以及是否需要实时定位都会有所不同。如果从“室内AI导航”入手,就会忽略这些差异,并导致产品声称能够满足场地无法支持的需求。

为什么发现、路由和定位必须分开?

目的地发现回答了哪个地点是相关的。路由计算回答了符合条件的访客可以使用哪条连通路径。定位回答了访客当前的位置、楼层,以及(如果硬件支持)访客的朝向。这三个层可以相互协作,但彼此不可替代。例如,一张平面图可以显示204房间,但仍然缺少走廊连通性、开放的门、无障碍的过渡、通往目标楼层的电梯服务以及可靠的起点信息。诸如“十米后左转”之类的逐向导航指令需要路线和实时位置信息,且位置信息必须具有可用的精度和方向性。语言模型可以协调该请求。但语言模型无法提供缺失的拓扑结构或蓝点。

Open Geospatial Consortium 的 IndoorGML 2.0 第 1 部分概念模型是当前室内导航网络的 OGC 概念模式。该标准对空间及其细分、几何和语义属性、连接类型以及逻辑和度量导航网络进行建模(OGC IndoorGML 2.0 Part 1 – Conceptual Model,OGC 22-045r5,发布于 2025 年 6 月 26 日)。生产产品无需序列化 IndoorGML。但产品必须遵循相同的区别:视觉几何并非导航图。OGC 于 2025 年 8 月 28 日发布的公告称 IndoorGML 2.0 第 2 部分编码即将发布 (OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard)。IndoorGML 1.1 仍然是已发布的面向编码的 IndoorGML 标准 (IndoorGML 1.1, OGC 19-011r4, 2020 年 11 月 5 日)。请引用第 1 部分作为概念性契约;在第 2 部分发布之前,请勿将 GML、JSON 或 SQL IndoorGML 2.0 编码视为已发布的实现标准。

室内地图数据格式 (IMDF) 是一个补充性的 OGC 社区标准,用于存储室内位置信息,以进行定向、导航和发现,其中包括机场、购物中心和火车站的建模说明(Indoor Mapping Data Format,OGC 20-094,版本 1.0.0,发布于 2021 年 2 月 18 日)。IndoorGML 2.0 第 1 部分本身描述了 IMDF 提供了一个综合模型,应用程序可以从中导出路径,而 IndoorGML 则旨在实现统一的空间图方法。对于 AI 寻路助手而言,其操作要点更为明确:在对话承诺导航之前,必须先存在结构化的室内数据。

室外寻路通常更简单,因为道路或行人网络、路径 API 和 GNSS 已经存在。助手可以对目的地进行地理编码,向服务提供商请求路线,并将结果绘制出来。室内和混合校园人流通常需要额外的基础设施:楼层状态、垂直过渡、访问控制边界,以及可能并非来自浏览器的起点。一条校园路径可能将室外路径 GNSS 连接到建筑物入口,然后再连接到室内路径。对话层可以解释这种过渡。路由引擎仍然拥有每个路径的所有权。

路由前如何进行目的地解析?

路由到原始字符串“B厅”是一个产品缺陷。应用程序应该在路由引擎运行之前解析出稳定的目的地标识符、建筑物和楼层。显示名称冲突:12号门和12号入口是不同类型的实体。房间、隔间和会话标识符在人类语言中也会冲突,原因与AI场地地图 将几何图形与事件叠加层分开的原因相同。建筑物、楼层、入口、房间、大门、亭子、洗手间、电梯、楼梯、停车区域和服务台等信息的录入记录,可在标签更改时保持搜索、地图、路线、无障碍设施和分析功能的同步。

{
  "destinationId": "hall_b",
  "buildingId": "expo_center",
  "floorId": "floor_1",
  "type": "hall"
}

资格认定应在同一步骤中进行。即使休息室与房间物理相连,仍可能因票级、安检区域或仅限工作人员进入等原因而被禁止进入。候选空间应在进行空间比较和解释之前通过授权和运行状态验证。受限多边形应在检索前进行过滤,以便语言模型无需“记住”哪些走廊是私有的。OWASP’s LLM01:2025 Prompt Injection 描述了用户或检索到的文本如何改变模型行为,包括对连接功能的影响。OWASP Top 10 for LLM Applications 2025 列出了 LLM06:2025 Excessive Agency:当系统被赋予过多的功能、权限或自主权时,意外或被篡改的模型输出可能导致的有害行为。寻路助手应建议目的地和允许的操作。主机应用程序应在模式、访问权限和网络状态验证之后执行摄像头移动、楼层切换或路线请求。

歧义是首要结果。“正门”、“北门”和“VIP 入口”都可以是有效的解析结果。该产品应该询问用户输入的候选地点,在地图上列出,或者要求用户点击,而不是通过字符串相似度进行猜测。即使对话失败,直接目的地搜索也必须有效。输入 Hall B 的访客不应该需要对话。确定性查找、筛选器、地图和复合问题的对话应该使用相同的标识符。

为什么室内路线规划需要连通性,而不是平面图?

地点查找会突出显示几何图形。室内路线规划基于连通图进行计算:从房间到走廊,再到门,再到楼梯或电梯,最后到达另一层。显示多边形和路线节点可以有意地分开。房间多边形可以连接到门口节点;走廊边代表行程;电梯和楼梯边代表楼层变更、无障碍设施和运行状态。带有装饰性折线的栅格平面图并非这样的图。场地地图指南 也明确区分了显示房间和提供逐向路径之间的区别。

多层场馆地图及其路径图用于展示室内导航依赖于空间、门、走廊、电梯和楼层之间的明确连接。

多层状态必须明确。起点和终点应包含建筑物和楼层标识符。用户界面应显示路径何时切换楼层,而不是将转换隐藏在一条二维线内。垂直边缘需要类型化的属性:楼梯、电梯、自动扶梯、坡道、无障碍设施、服务楼层以及开放或关闭状态。路径引擎使用这些属性。语言模型可以在引擎返回结构化步骤后解释这些属性。理想的流程是:路径引擎→结构化步骤→更清晰的措辞,而不是随意编造方向。即使指南针方向不可用,诸如“继续前往中央大厅,然后使用东侧电梯”之类的地标相对指示仍然可用。

临时关闭是运营记录,而不是地图装饰。自动扶梯故障、走廊堵塞、入口关闭、楼层限制或电梯故障都应标记为路径闭合,并强制重新计算路径。访客阅读的说明应反映当前路径版本。在实际场所中,使用对话式文字绘制的过时几何图形是一个安全问题,而非复制问题。重新路由属于引擎的职责:当起点改变或路径闭合时,之前的路径失效,系统会计算新的路径。要求语言模型修补坐标是错误的控制方式。

无障碍、访问规则和闭合如何筛选路径?

无障碍要求是路径规划的硬性约束。如果访客要求提供无障碍路径,则楼梯路径可能会被排除。完整的无障碍路径可能需要无台阶通行、正常运行的电梯、无障碍入口以及场所实际记录的门宽。将无障碍因素融入软性偏好权重中,仍然可能导致不无障碍的路径被排在首位。缺少无障碍数据并不意味着可以随意创建完全无障碍的路径。当系统仅识别出无障碍入口和电梯时,只能说明这些设施已在地图上显示,但并不代表完整的无障碍路径已获得认证。法律上的无障碍义务仍由合格的律师和场地运营方进行判断;本文主要介绍数据合同。

根据可达性、访问权限和当前运行状态筛选三条候选路径,直至只剩下有效路径。

物理连通性只是资格审查的一个维度。员工走廊、VIP通道、安保区域、售票区域和员工入口在图中可能显示为可通行,但对于该访客而言仍然禁止通行。路径资格取决于物理连通性、访问权限和运行状态。受限路径在应用访问控制之前绝不应到达通信层。安全的流程是:身份验证、确定访问权限、检索允许的空间、计算允许的路径,然后进行解释。计算跨越所有空间的路径并在之后隐藏受限步骤会泄露拓扑结构。地图 API 身份验证涵盖了将通信附加到主机地图的Kaleidr表面的可发布密钥与服务器密钥;场馆访问规则仍然存在于主机的身份和票务系统中。

紧急和安全路由至关重要。生成式导航助手不应基于通用模型知识自行创建疏散路径、应急程序或受限的安全指南。应使用场馆认可的应急内容、官方计划、现场工作人员以及运行警报。当相关记录具有权威性时,寻路产品可以显示已批准的急救或出口位置。高风险路线规划应由专门为此设计的运行系统负责。

寻路何时需要定位,何时不需要?

每条路线都需要一个起点。起点可以来自明确的地图选择、已知的地标(例如主入口)、上次指定的区域(“我在A厅”)、室外设备位置或室内定位基础设施。即使存在自动定位,也必须保留手动起点选项。置信度取决于数据。几米精度的定位报告可以支持走廊范围内的导航。而室内定位误差达数十米的报告则可能导致选择错误的走廊或楼层。产品应能够提示室内位置不确定,并要求访客选择当前区域。从错误源头出发的可靠路径规划比简短的澄清更糟糕。

W3C Geolocation 规范(一份日期为 2026 年 3 月 26 日的候选推荐快照)规定,只有在获得明确许可后才能访问设备位置,并且 API 不保证设备的实际位置。浏览器定位并非室内蓝点。Bluetooth 信标、Wi-Fi 定位、ultra-wideband 视觉定位和特定场所系统属于基础设施,而非语言模型功能。方向信息是“左转”指令的另一项必要条件。地图仍然可以显示正确的路线,即使没有方向信息。当方向信息不可用时,应使用地标或地图相对位置信息来代替指南针指示。

许多场所无需持续的室内跟踪即可提供有效的寻路功能。访客选择一个地标,引擎返回路线,地图上保留静态步数,访客手动前进。会议场所、校园、度假村和博物馆通常更需要这种模式,而不是一个实时显示的蓝点。这种模式还能降低隐私和基础设施成本。寻路功能可以创建详细的移动历史记录:当前室内位置、路线、重复目的地、工作场所、医疗部门或活动参与情况。NIST Privacy Framework (NIST.CSWP.01162020,2020 年 1 月 16 日) 将隐私视为企业风险管理:明确收集哪些数据、收集原因以及收集时长。优先使用临时的起点、终点和路线上下文,而不是持久的移动轨迹。用于 AI 地图工作流的私有位置数据 涵盖相同的主机所有边界。

对话式寻路如何与地图共享状态?

当目的地或路线已显示在地图上时,对话功能才真正发挥作用。后续操作,例如询问当前路径上的洗手间、请求避开楼梯或从选定的起点前往更近的入口,都依赖于共享状态,而不是第二个非官方的结果列表。地图、列表、说明和聊天信息应读取同一条寻路记录:起点、目的地、当前楼层、路线标识符、路线版本、无障碍模式以及定位系统启用时的位置置信度。选择目的地即可显示路线。更改无障碍模式可能会使当前版本失效并请求重新计算。助手结果应显示在访客已使用的同一张地图上。

共享寻路状态同步对话请求、路线数据、楼层上下文、场所信息和已验证的地图操作。

{
  "routeId": "route_north_to_hall_b",
  "originId": "entrance_north",
  "destinationId": "hall_b",
  "mode": "accessible",
  "activeFloorId": "floor_1",
  "routeVersion": 4
}

语义操作应保持简洁:设置起点、聚焦目的地、显示路线、切换楼层、高亮显示过渡区域、打开目的地记录、清除路线、请求重新规划路线。在渲染器适配器运行之前,主机将根据当前标识符、访问权限和网络版本验证每个有效负载。任意地图 JavaScript 并非控制契约。这些操作的权限属于应用程序和基础设施,而非语言模型。地图感知助手指南 涵盖了共享地图状态和该切换的已验证操作。

运行更新应同时对网络和路线进行版本控制。例如,电梯关闭可能会导致网络版本 18 上的路线版本 4 失效,并需要使用版本 5。版本控制使得过时的导航信息可以进行调试。应用路线前的验证应确认起点、终点、权限、路线新鲜度、关闭情况和出行方式仍然匹配。在实时场所中,寻路状态会快速变化。室内离线或连接较弱也是正常现象。在适当情况下,缓存场所几何形状、标签、最后一层以及最后一条有效路线。如果对话层出现故障,则必须保留直接地点查找功能。空间分析仪表盘 KPI 属于产品衡量范畴,而非将聊天量作为衡量成功的标准。

Kaleidr 如何融入现有的寻路堆栈?

Kaleidr 当前的开发者文档将聊天功能定位为附加到主机已运行地图上的对话层。Quickstart 展示了如何将聊天功能集成到正在运行的 Mapbox、MapLibre、Google Maps 或 Leaflet 实例上。Chat attach 将控制塔描述为基于聊天的导航、地点摘要以及在主机地图上标记地点的功能。可发布的键值对浏览器具有源锁定;服务器键值不会显示在页面上 (Auth & Scopes)。代码片段应使用明显的占位符,而不是实际运行的键值。

const handle = Kaleidr.mount("#chat", {
  product: "chat",
  publishableKey: "YOUR_PUBLISHABLE_KEY",
  map: myMap,
});

这些平台支持自然语言目的地发现、地图感知对话、地点答案、实时标记和摄像头更新。主机仍然拥有渲染器、场地数据、路线引擎、室内拓扑、定位和访问控制。Kaleidr 的公开文档描述了 AI 地图聊天、已发布地图、设计的底图和地图编辑。这些文档目前没有记录专用的室内定位引擎或专门的逐向室内导航产品。因此,正确的架构是在 Kaleidr 上实现对话式和地图感知交互,而专门的室内路线规划或定位功能则保留在场地或导航系统中,以便在部署需要时使用。Location Intelligence APIs and Map SDK 是目前用于推理 API、排名系统、分析和部署支持的商业平台。排名和室内路线规划仍然是不同的产品;不要根据营销宣传来构建虚构的室内导航路线。

混合型场所仍然符合这种划分。室外路段可以使用路线规划提供商。室内场景可以使用场地地图。正如场地地图文章所述,活动叠加层可以在不重建墙体的情况下更改展位和会议区域。医院和机场的请求通常首先在目的地识别和访问权限方面失败,而不是在路径绘制方面失败:“成像”和“我可能在42号登机口附近使用的休息室”首先是资格问题,然后才是几何问题。语言模型可以解释请求。授权的业务数据和地理空间服务仍然提供事实依据。

团队应该如何衡量人工智能寻路助手?

衡量的是寻路效果,而非聊天量。目的地解析率、无结果率、路线成功率、楼层错误修正率、重新规划路线率、访问拒绝率、返回路线所需时间、目的地确认率和路线放弃率,这些指标描述了访客是否真正到达了目的地。如果存在定位功能,则需添加偏离路线事件、位置置信度失败和楼层检测失败。将发现与导航区分开来:已解析的目的地但路线失败与查找失败是不同的缺陷。诸如“目的地已解析”、“路线请求”、“路线失败”、“楼层已更改”和“重新规划路线”之类的编辑事件名称属于产品分析,而非已记录的自动事件Kaleidr Analytics。

评估应包括歧义、跨楼层路径、闭合路径、访问受限、缺少无障碍数据以及低连接性回退。测试地图、列表和语音或书面步骤是否显示相同的路线版本。延迟应按阶段进行归因;将延迟归咎于“AI”的团队通常会发现,路线规划或起点解析才是主要原因。任务完成情况比交互次数更为重要。一位访客无需交谈即可通过搜索找到 B 厅,这就算成功。而一次冗长的对话最终却导致他走到了错误的楼层,则不算成功。

寻路产品应避免哪些故障模式?

反复出现的故障是将三个系统合并成一个生成的段落。楼层平面图被当作路由图。语言模型被当作定位系统。楼层信息消失。无障碍设施变成了优先级权重。受限区域泄露。逐向导航文字出现时没有方向指示。对话成为强制性要求。移动历史记录默认保留。以下每一行都是一个产品缺陷及其具体的修正方案。

错误 结果 更佳方案
将地图图像视为导航网络 路线不可信 建立连通性模型
将语言模型视为定位系统 起点变得不可靠 使用明确的起点
忽略楼层 错误的楼层引导 在共享状态下跟踪楼层
让模型生成路线 不安全或过时的路径 使用路线引擎
将可访问性视为优先级 不可访问的路线也可能优先 使用硬性约束
忽略临时封闭区域 过时的路线 更新边的状态并重新计算
穿越限制区域的路线 访问泄漏 路线规划前过滤图
承诺提供逐向导航,但不提供方向信息 误导性指示 使用地标或地图相关的措辞
强制对话 聊天失败时基本导航失效 保持确定性搜索
默认保持移动状态 隐私风险 保留临时路线上下文

移动寻路需要大的目标、清晰易读的步骤,以及在模型或耗时的路线超时时仍然可用的地图。缓存基础几何信息。以可控的方式降低信息丰富度。即使对话不可用,也要保留通过文本搜索获得的路径以进行高亮显示。

构建对话式导航体验

可靠的架构包括意图识别、目的地解析、授权路由、路线计算、路线解释以及已验证的地图操作。室内定位是一个可选的后续层,仅当场所运行合适的系统时才添加。Kaleidr 可以将对话式空间 AI 附加到主机已运行的地图上,而场所拓扑结构和专用路由器在需要真正室内导航时仍然具有权威性。

探索 Kaleidr Enterprise,了解当前的 API、SDK 接口和部署支持。在确定集成路径之前,请查看 Kaleidr 开发者文档中的连接模式和密钥类型。

常见问题解答

什么是 AI 导航助手?

AI 导航助手可以理解自然语言导航问题,从可信记录中解析目标目的地,并协调地图或路线引导。路由和定位仍然是独立的系统。

AI 导航与室内导航相同吗?

否。对话可以解读导航请求。室内导航也需要结构化的路由网络,并且可能需要室内定位。

平面图图像可以用于逐向导航吗?

不能单独使用。可靠的路由需要空间、门、走廊、楼梯、电梯和其他过渡区域之间的连通性。

什么是 IndoorGML?

IndoorGML 是室内空间和导航数据的 OGC 标准。IndoorGML 2.0 第 1 部分是当前空间、连通性和导航网络的概念模型 (OGC 22-045r5)。OGC 描述了 IndoorGML 2.0 的编码方案,预计于 2025 年 8 月发布;IndoorGML 1.1 仍然是已发布的面向编码的版本。

什么是 IMDF?

室内地图数据格式 (IMDF) 是用于定向、导航和发现的室内位置存档的 OGC 社区标准 (OGC 20-094,版本 1.0.0)。

Kaleidr 目前是否提供室内定位?

Kaleidr 目前的公开文档描述了空间人工智能、地图聊天、自定义地图、发布和现有地图集成。文档中并未提及专用的室内定位系统,因此除非宿主程序集成了室内定位功能,否则应将室内定位视为一项独立的部署功能。

Kaleidr 能否与室内地图配合使用?

Kaleidr 可以将对话式人工智能附加到兼容的现有地图实现中。宿主应用程序仍然负责地图数据、路线网络和任何室内定位。

无障碍导航应如何运作?

无障碍需求应使用经过验证的场所数据编码为硬性路线约束。助手不应根据不完整的信息创建无障碍路线。

人工智能地图助手能否为访客重新规划路线?

助手可以请求或解释新的路线。权威的路线引擎应使用当前的网络状况和访问规则重新计算路线。

导航功能是否应该持续追踪用户的位置?

仅当产品需要且用户已收到适当通知或同意时才需要。许多导航任务无需持续追踪用户位置,只需选择起点或地标即可。

参考资料

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

@misc{kaleidr_auth_scopes_2026_08_27,
  title  = {Auth \& Scopes},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}

@misc{kaleidr_chat_attach_2026_08_27,
  title  = {Chat attach},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/sdk/chat-attach}
}

@misc{kaleidr_docs_intro_2026_08_27,
  title  = {Introduction},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/}
}

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

@misc{kaleidr_quickstart_wayfinding_2026_08_27,
  title  = {Quickstart},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 27 August 2026},
  url    = {https://docs.kaleidr.com/quickstart}
}

@techreport{nist_privacy_framework_2020,
  title       = {NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0},
  author      = {{National Institute of Standards and Technology}},
  number      = {NIST.CSWP.01162020},
  institution = {National Institute of Standards and Technology},
  year        = {2020},
  month       = jan,
  url         = {https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf}
}

@techreport{ogc_indoorgml_1_1,
  title       = {IndoorGML 1.1},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 19-011r4},
  institution = {Open Geospatial Consortium},
  year        = {2020},
  month       = nov,
  url         = {https://docs.ogc.org/is/19-011r4/19-011r4.html}
}

@techreport{ogc_imdf_1_0_0,
  title       = {Indoor Mapping Data Format},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 20-094},
  institution = {Open Geospatial Consortium},
  year        = {2021},
  month       = feb,
  note        = {OGC Community Standard, version 1.0.0},
  url         = {https://docs.ogc.org/cs/20-094/index.html}
}

@techreport{ogc_indoorgml_2_0_part1,
  title       = {OGC IndoorGML 2.0 Part 1 – Conceptual Model},
  author      = {{Open Geospatial Consortium}},
  number      = {OGC 22-045r5},
  institution = {Open Geospatial Consortium},
  year        = {2025},
  month       = jun,
  url         = {https://docs.ogc.org/is/22-045r5/22-045r5.html}
}

@misc{ogc_indoorgml_2_0_announcement_2025_08_28,
  title  = {OGC Publishes IndoorGML 2.0 Part 1 Conceptual Model Standard},
  author = {{Open Geospatial Consortium}},
  year   = {2025},
  month  = aug,
  note   = {Accessed 27 August 2026},
  url    = {https://www.ogc.org/announcement/ogc-publishes-indoorgml-2-0-part-1-conceptual-model-standard/}
}

@misc{owasp_llm01_prompt_injection_2025,
  title  = {LLM01:2025 Prompt Injection},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 27 August 2026},
  url    = {https://genai.owasp.org/llmrisk/llm01-prompt-injection/}
}

@misc{owasp_llm_top10_2025,
  title  = {OWASP Top 10 for LLM Applications 2025},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 27 August 2026},
  url    = {https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf}
}

@misc{w3c_geolocation_2026_03_26,
  title  = {Geolocation},
  author = {{W3C}},
  note   = {W3C Candidate Recommendation Snapshot, 26 March 2026; accessed 27 August 2026},
  url    = {https://www.w3.org/TR/geolocation/}
}