Files
frontend-miniapp/docs/QA/indoor-guide-professional-standard-gap-analysis-2026-06-30.md
lyf 8fed715235
Some checks failed
CI / verify (push) Has been cancelled
chore: sync latest project updates
2026-07-03 14:42:38 +08:00

30 KiB
Raw Blame History

室内导览楼层切换、点位展示与行业专业规范差异分析

日期2026-06-30
范围:深圳自然博物馆 frontend-miniapp H5 导览页
证据类型:源码审核 + deep-research 外部资料核验
说明:外部研究依据主要来自 OGC IMDF / IndoorGML、VA/WBDG 综合导视指南、Smithsonian 可访问展览设计指南、CMHR 博物馆 wayfinding 指南和博物馆移动导览案例。IMDF/IndoorGML 是数据模型标准,不直接规定 UI 视觉样式;本文将其作为室内导览数据与交互审计标尺。


1. 结论摘要

当前项目已经具备“移动 H5 室内 3D 位置预览”的基础能力:

  • 支持馆外/馆内入口切换。
  • 支持楼层按钮切换。
  • 支持建筑外观、单层、多层视图。
  • 支持 POI 标记、点击、聚焦与底部卡片。
  • 支持导览和讲解业务的部分联动。

但和行业内专业室内导览系统相比,当前实现仍有明显差距。核心差距不是单一 UI而是楼层上下文、POI 空间语义、坐标体系、数据 readiness 与导航能力边界尚未完整专业化。

最关键的问题包括:

  1. 楼层切换更像 3D 模型切换,不是完整 floor context 切换。
  2. POI 当前主要是单点渲染,缺少 display point / entrance point / route node / space geometry 的专业拆分。
  3. SGS 数据源下存在坐标轴语义进入 ThreeMap 后未完全归一化的风险,楼层切换后容易出现模型与点位错位。
  4. 楼层信息展示主要是 1F / 2F / B1 label缺少楼层内容、数据状态、目标楼层、路线途经楼层等专业状态表达。
  5. 当前能力应定义为“室内 3D 展示 + 位置预览”,不能定义为专业可导航室内导览。

2. 当前项目实现概览

2.1 导览页入口

首页导览页通过 GuideMapShell 组织导览地图、楼层控件、模式状态、POI 卡片和路线面板。

证据:

  • src/pages/index/index.vue:9 使用 GuideMapShell
  • src/pages/index/index.vue:23-30 传入 indoorModelSourceguideFloorsindoorViewindoorLayerModeactiveGuideFloor
  • src/pages/index/index.vue:48-53 监听 floor-changeindoor-view-changepoi-clickselection-clearauto-switch

当前页面结构说明:

index.vue
  └─ GuideMapShell
      ├─ ThreeMap / TencentMap
      ├─ 搜索入口
      ├─ 楼层切换控件
      ├─ 缩放/工具按钮
      ├─ POI 卡片
      └─ 路线/位置预览相关 UI

2.2 楼层切换现状

楼层控件位于 GuideMapShell

  • scroll-view 展示楼层列表。
  • floorItems 来自 props.floors 过滤后的室内楼层。
  • 点击楼层后调用 indoorRendererRef.value?.switchFloor?.(floorId)
  • 同时向父组件发送 indoorViewChangelayerModeChangefloorChange

证据:

  • src/components/navigation/GuideMapShell.vue:129-158:楼层列表渲染。
  • src/components/navigation/GuideMapShell.vue:526-535:楼层点击处理。

ThreeMap 的楼层加载逻辑包括:

  • 根据 floorId 查找楼层模型。
  • 加载 GLB。
  • 应用楼层可见性。
  • 加载当前楼层 POI。
  • 适配相机。

证据:

  • src/components/map/ThreeMap.vue:2612-2725loadFloor()
  • src/components/map/ThreeMap.vue:3768-3789handleFloorChange()

2.3 POI 展示现状

当前 POI 展示已经有初步的专业化方向:

  • 按视图模式区分 POI 显示密度:overviewmultifloor
  • 按相机距离做可见性分级:tightbalancedfull
  • 按 POI 类别和选中状态计算优先级。
  • 点击后设置选中态、聚焦相机、弹出底部卡片。

证据:

  • src/components/map/ThreeMap.vue:617-640getPoiDisplayMode()shouldShowPoiInCurrentMode()
  • src/components/map/ThreeMap.vue:667-718POI 距离可见性、数量限制、优先级计算。
  • src/components/map/ThreeMap.vue:3373-3451POI marker group 创建与加载。
  • src/pages/index/index.vue:65-106POI 底部卡片。

2.4 楼层信息展示现状

当前楼层信息主要表现为楼层按钮 label

<text class="floor-label">{{ floor.label }}</text>

证据:

  • src/components/navigation/GuideMapShell.vue:149-157

楼层排序和室内楼层判定由 guideFloor.ts 处理:

  • 支持 L1L-11FB1L1.5 等格式。
  • 可过滤 EXTERIOROUTDOOR、外立面、馆外等非室内楼层。
  • 可按语义楼层从高到低排序。

证据:

  • src/domain/guideFloor.ts:18-22
  • src/domain/guideFloor.ts:68-82
  • src/domain/guideFloor.ts:98-114

3. 当前项目与行业专业规范的差异

3.1 楼层切换差异

当前项目特点

当前楼层切换偏向“模型视图切换”:

点击楼层按钮
  -> ThreeMap.switchFloor(floorId)
  -> loadFloor(floorId)
  -> 加载/复用 GLB
  -> 加载该 floorId 的 POI
  -> fit camera

问题在于,专业室内地图的楼层切换不只是切换模型,而是切换完整 floor context。

行业专业规范

专业室内导览中的一次楼层切换,应同步更新以下上下文:

  1. 当前楼层 ID。
  2. 当前楼层 label/name/order/elevation。
  3. 当前楼层底图或 3D 模型。
  4. 当前楼层空间面/展厅区域。
  5. 当前楼层 POI。
  6. 当前楼层路径网络图层。
  7. 当前楼层垂直交通点。
  8. 当前用户定位状态。
  9. 当前目标点是否在本层。
  10. 当前路线是否途经本层。
  11. 当前楼层数据质量与可导航状态。

专业表述:

Floor Switch = Floor Context Switch
不是只换模型而是同步切换模型、空间、POI、路径、定位、状态和任务上下文。

当前差距

维度 当前项目 专业规范 风险
切换对象 主要是模型 + POI 完整 floor context 模型、POI、路径、定位上下文可能不同步
切换状态 activeGuideFloor 近似单状态 requested / loading / rendered / failed 分离 UI 可能显示已切换,但模型或 POI 仍未加载成功
模型匹配 依赖 floorIdlabel、节点名、fallback floor-model binding 明确 节点名不规范时误显示非本层构件
多楼层 有 multi 视觉展示 有跨层路线、垂直交通、换乘提示 只能看多层,不能证明可导航
失败处理 模型 loadError 模型、POI、空间面、路网分别诊断 用户不知道失败发生在哪一层

具体源码风险

GuideMapShell 点击楼层后立即 emit 父组件状态:

  • emit('indoorViewChange', 'floor')
  • emit('layerModeChange', 'single')
  • emit('floorChange', floor.label)

证据:src/components/navigation/GuideMapShell.vue:526-535

ThreeMap.switchFloor() 是异步加载模型。如果模型加载失败,父组件已经切换了楼层状态,可能出现:

UI 显示已切换到 2F
但 3D 场景仍停留在旧楼层或进入错误状态

专业做法应拆分:

requestedFloorId
loadingFloorId
renderedFloorId
failedFloorId

只有 ThreeMap 成功渲染目标楼层后,父级才更新“当前已渲染楼层”。


3.2 POI 展示差异

当前项目特点

当前 POI 主要以 GuideRenderPoi.positionGltf 作为渲染点,使用 sprite/label 展示。

证据:

  • src/domain/guideModel.ts:6-18GuideRenderPoi 只有 positionGltf,没有 display/entrance/route node 的拆分。
  • src/components/map/ThreeMap.vue:3384-3390POI marker 直接读取 [x, y, z] 并设置 sprite 坐标。

行业专业规范

专业室内导览中POI 通常不是“一个点”,而是一个空间对象。至少应拆分:

字段 用途
displayPoint 图标和标签展示点
anchorPoint 相机聚焦点
entrancePoint 用户可到达入口点
routeNodeId 路网节点,用于路径规划
geometry 房间、展厅、空间区域边界
floorId 稳定楼层 ID
sourceConfidence 坐标来源和可信度

推荐领域模型:

interface IndoorPoi {
  id: string
  name: string
  categoryId: string
  floorId: string

  displayPoint: [number, number, number]
  anchorPoint?: [number, number, number]
  entrancePoints?: Array<[number, number, number]>
  routeNodeIds?: string[]

  geometry?: Polygon | MultiPolygon
  unitId?: string
  spaceId?: string

  priority: number
  minZoom?: number
  maxZoom?: number
  labelPolicy: 'always' | 'selected' | 'adaptive' | 'hidden'
  sourceConfidence: 'verified' | 'backend' | 'model-derived' | 'fallback'
  dataStatus: 'ready' | 'partial' | 'unverified'
}

当前差距

维度 当前项目 专业规范 风险
POI 坐标 单个 positionGltf display / anchor / entrance / route node 分离 展厅中心点可能被误作路线终点
POI 区域 以点为主 点 + 面 + 入口 + 路网节点 展厅语义表达不足
坐标高度 直接使用 [x,y,z] 楼层绝对高程与本层贴地高度分离 切换楼层后 marker 和模型错位
可达性 有分类但不完整 入口、无障碍路线、垂直交通联动 不足以支持专业无障碍导览
展示策略 代码内硬编码优先级 可配置图层样式与任务态策略 扩展和调参困难

SGS 坐标风险

当前 SGS adapter 中 normalizePositionSource() 直接输出 [x, y, z]

证据:src/data/adapters/sgsSdkGuideAdapter.ts:124-130

ThreeMap 又直接把 y 用作 sprite 高度:

证据:src/components/map/ThreeMap.vue:3384-3390

但 SGS 坐标常见语义是:

x = GLB 水平 X
z = GLB 水平 Z
y = 高度或楼层绝对高程

专业渲染中POI 展示应使用:

renderX = source.x
renderZ = source.z
renderY = surfaceOffset 或 floor-local height

而不是直接把 SGS position.y 当作当前单层模型的局部高度。


3.3 楼层信息展示差异

当前项目特点

当前楼层信息主要是楼层按钮:

B2 / B1 / 1F / 2F / 3F ...

选中态主要依赖:

:class="{ active: activeFloorId === floor.id && layerMode !== 'multi' }"

证据:src/components/navigation/GuideMapShell.vue:149-154

行业专业规范

专业楼层信息不应只是 label而应包含

interface IndoorFloor {
  id: string
  code: string        // L1 / L2 / L-1
  label: string       // 1F / 2F / B1
  name?: string       // 一层大厅 / 二层展厅区
  level: number       // -1, 1, 2
  elevation?: number
  order: number
  isIndoor: boolean
  isNavigable: boolean
  isOpen: boolean
  modelStatus: 'ready' | 'missing' | 'loading' | 'error'
  poiStatus: 'ready' | 'empty' | 'partial' | 'error'
  routeStatus: 'ready' | 'not-ready' | 'partial'
}

专业楼层 UI 至少要区分:

状态 展示建议
当前显示楼层 高亮
用户所在楼层 “你在这”/定位点
目标所在楼层 目标标记
路线途经楼层 路线提示/小圆点
有搜索结果楼层 数量 badge
加载中楼层 spinner
数据缺失楼层 灰化/警告
不开放楼层 锁定/禁用

当前差距

维度 当前项目 专业规范
楼层 label 已实现 已实现
楼层名称 缺少 应显示“一层大厅 / 二层展厅区”等
楼层内容摘要 缺少 应显示主要展厅、服务设施数量
用户所在楼层 缺少 应和当前显示楼层区分
目标楼层 缺少 从搜索/讲解进入时应标注
路线途经楼层 部分 route 数据有,但 UI 未系统表达 应在楼层控件中明确标注
数据状态 缺少 应标注模型/POI/路网是否 ready

4. 行业内专业展示规范总结

4.1 楼层切换规范

专业室内导览的楼层切换应满足:

  1. 楼层 ID 稳定,不使用纯展示 label 作为主键。
  2. 楼层排序基于语义 level而不是字符串排序。
  3. 切换楼层时模型、空间面、POI、路线、定位状态同步更新。
  4. 切换过程有 loading/pending 状态。
  5. 切换失败保留旧楼层,并提示失败原因。
  6. 用户所在楼层、目标所在楼层、当前查看楼层应分开表达。
  7. 跨楼层路线时,应标记路线涉及楼层。
  8. 非开放、无数据、无路网楼层应禁用或显示状态。

推荐状态模型:

interface FloorViewState {
  requestedFloorId?: string
  loadingFloorId?: string
  renderedFloorId?: string
  userLocatedFloorId?: string
  targetFloorId?: string
  failedFloorId?: string
  routeFloorIds: string[]
}

4.2 POI 展示规范

专业 POI 展示应满足:

  1. 区分展示点、入口点、路线节点、空间几何。
  2. POI 必须绑定稳定 floorId
  3. POI 坐标必须声明坐标系、单位、轴向和变换。
  4. POI label 应按 zoom/camera distance/task state 自适应显示。
  5. POI 高密度区域必须做避让、聚合和优先级裁剪。
  6. 搜索命中、选中、路线起终点、换乘点应强制显示。
  7. 设施、展厅、展品、交通、无障碍、安全设施应有独立图层策略。
  8. 不同任务模式应有不同 POI 图层:浏览、找设施、路线、无障碍、讲解联动。

推荐 POI 点位拆分:

展厅中心点:用于标签展示
展厅入口点:用于路线终点
路网节点:用于路径计算
空间面:用于区域高亮
锚点:用于相机聚焦

4.3 楼层信息展示规范

专业楼层信息应包含:

  1. 楼层短 label1F2FB1
  2. 楼层名称:如 一层大厅二层展厅区
  3. 主要内容摘要:如 宇宙厅 / 服务台 / 卫生间
  4. 点位数量或搜索结果数量。
  5. 模型加载状态。
  6. POI 数据状态。
  7. 路线数据状态。
  8. 当前用户所在楼层。
  9. 当前目标所在楼层。
  10. 当前路线途经楼层。

移动端推荐形式:

楼层按钮2F
当前楼层 chip2F · 地球厅 / 演化厅 · 23 个点位
楼层详情面板:展示展厅、设施、数据状态、路线状态

4.4 3D 室内导览规范

专业 3D 室内导览应满足:

  1. 3D 模型只是底图/底座,业务语义来自数据层。
  2. 不应依赖模型节点名推断核心业务楼层语义。
  3. GLB 模型、POI、空间面、路线点必须共享或可转换到同一坐标系。
  4. 模型 translation/rotation/scale 必须被业务图层同步应用。
  5. 单层模型和全馆模型切换不能改变 POI 的真实语义坐标。
  6. 模型加载失败、POI 加载失败、路网加载失败应分别提示。
  7. 移动端应控制 GLB 体积、解码时间和 WebGL 资源释放。

4.5 导航能力规范

如果产品要宣称“室内导航”,至少需要:

  1. 可步行路网节点。
  2. 路网边和权重。
  3. 垂直交通连接:电梯、楼梯、扶梯。
  4. 跨楼层路线分段。
  5. POI 到可达入口/路网节点的映射。
  6. 无障碍路线约束。
  7. 一方通行/封闭/施工等约束。
  8. 路线可视化。
  9. 起终点和换乘点状态。
  10. 数据 readiness 与 smoke test。

当前项目在 route graph / nav data 未验证前,应继续使用:

位置预览 / 查看位置 / 查看三维位置

不应使用:

开始馆内导航 / 到达引导 / turn-by-turn / 精准导航

5. 当前项目优先改进建议

P1统一 SGS 坐标归一化

当前最优先问题是避免 SGS position.y 直接进入 ThreeMap marker 的 Y 坐标。

建议:

// SGS 渲染坐标:只用 x/z 做水平定位Y 使用本层贴地偏移
positionGltf = [source.x, 0, source.z]

如果需要保留原始高度:

rawPosition = [source.x, source.y, source.z]
heightMode = 'absolute-elevation'

不要让绝对高程直接控制单层模型里的 marker 高度。

P1楼层切换状态闭环

把当前单一 activeGuideFloor 拆成:

requestedFloorId
loadingFloorId
renderedFloorId
failedFloorId

流程:

点击楼层
  -> requested/loading
  -> ThreeMap 加载模型和 POI
  -> 成功后 emit renderedFloorChange
  -> 父组件更新 active/rendered floor
  -> 失败后保留旧楼层并提示

P1POI 专业语义拆分

GuideRenderPoi.positionGltf 逐步升级为:

displayPoint
anchorPoint
entrancePoints
routeNodeIds
geometry

展厅类 POI 尤其需要:

  • space.geometry 用于区域高亮。
  • space.center 用于标签。
  • entrancePoints 用于路线。
  • routeNodeIds 用于导航。

P2楼层信息面板升级

建议当前楼层展示从单 label 升级为:

2F · 地球厅 / 演化厅 · 23 个点位

楼层按钮可增加:

  • 当前目标所在楼层标记。
  • 路线途经楼层标记。
  • 搜索结果数量。
  • 数据未就绪/加载失败状态。

P2POI 图层配置化

ThreeMap.vue 中硬编码的 POI 类别优先级迁到配置或 view model

interface PoiLayerStyle {
  categoryId: string
  icon: string
  color: string
  priority: number
  labelPolicy: 'always' | 'adaptive' | 'selected-only'
  routeRelevant: boolean
  accessibilityRelevant: boolean
}

P2空间面成为一等图层

博物馆展厅不应只显示一个点。建议将 spaces 转成专业图层:

  • 展厅区域 polygon/mesh highlight。
  • 展厅中心标签。
  • 展厅入口点。
  • 点击区域选中展厅。
  • 展厅卡片与讲解内容联动。

P3路线能力逐步专业化

后续如要升级为真正室内导航,需要完成:

  • route graph / nav data 接入。
  • 跨层连接。
  • POI entrance -> route node 映射。
  • 无障碍路线。
  • 路线分段楼层展示。
  • route readiness smoke test。

6. 建议实施顺序

优先级 事项 目标
P1 SGS 坐标归一化 解决楼层切换后 POI 与模型错位
P1 楼层切换状态拆分 防止 UI 楼层状态与实际渲染楼层不同步
P1 POI display/entrance/routeNode 拆分 建立专业导览数据基础
P1 继续限制导航话术 防止能力误导
P2 楼层信息展示升级 让用户理解每层内容和状态
P2 POI 图层配置化 支持搜索、设施、路线、无障碍等任务态
P2 空间面展厅图层 从“点位地图”升级到“空间地图”
P3 route graph / nav data 闭环 支持真正路线预览/导航
P3 移动端性能优化 控制 GLB、POI、标签和 WebGL 资源成本

8. deep-research 外部资料核验补充

本节为 2026-06-30 deep-research 工作流补充。研究问题:对比当前深圳自然博物馆 frontend-miniapp 导览页的楼层切换、点位展示、楼层信息展示,与室内导览/室内地图行业专业展示规范的差异,并总结行业专业规范。

8.1 研究限制

  • 外部结论主要基于博物馆/公共建筑无障碍指南、OGC IMDF/IndoorGML 标准和少量博物馆案例研究。
  • 这些资料适合作为专业规范与审计标尺,不等同于某一司法辖区对移动 H5 导览页的硬性法律要求。
  • IMDF/IndoorGML 是数据模型标准,不直接规定 UI 视觉样式;本文关于“楼层切换 UI 应如何呈现”的部分,是从专业数据模型和地图应用行为要求推导出的应用性结论。
  • 部分可访问性来源讨论实体展览空间、实体地图、导视牌或触觉/印刷材料;映射到 frontend-miniapp 时,应理解为同一 wayfinding 原则在移动端的对应实现。

8.2 外部核验后的高置信结论

8.2.1 专业室内导览首先把楼层/层级认知当作核心问题

专业室内导览不是简单楼层按钮切换。对于多楼层、多 level、局部区域才能上下转换的建筑楼层切换必须帮助用户理解

  • 我在哪一层。
  • 当前这一层有什么。
  • 目标在哪一层。
  • 如何去另一层。
  • 应通过哪个电梯、楼梯、坡道或换乘点。

外部依据British Museum 移动导览案例显示,复杂博物馆中的多楼层和多 level 会直接造成方向感问题用户难以理解自己在哪一层、如何换层以及如何阅读多层表示。VA/WBDG 指南要求每层目录识别该层公共目的地,说明楼层信息应服务于定位和决策,而不是只作为地图图层开关。

对当前项目的含义:

  • 当前 floor-switcher 只展示楼层 label不能充分支撑复杂博物馆场景下的楼层认知。
  • 应补充楼层内容摘要、用户所在楼层、目标楼层、路线途经楼层和可达性提示。

8.2.2 专业楼层切换应由结构化 Level 数据驱动

OGC IMDF 将楼层建模为 Level Feature,核心要求包括:

  • 稳定 id
  • feature_type = level
  • polygonal geometry。
  • venue-declared name
  • short_name
  • 数字 ordinal

其中 ordinal 表示真实楼层堆叠位置,应与 UI 显示 label 分离。例如 B11FL1 是展示和命名问题,而 ordinal 是排序、跨层关系和空间推理问题。

对当前项目的含义:

  • guideFloor.ts 已经有楼层 label/code 解析和排序,这是正确方向。
  • 但当前领域模型仍缺少 IMDF 式 Level geometry、ordinal、display point、楼层范围和数据状态的完整表达。
  • 后续不应只依赖 floor.label 或模型节点名推断楼层语义。

8.2.3 专业 floor switcher 不应有任意初始状态

IMDF Level geometry 规则要求 venue organization 考虑:

  • 无楼层选择时默认显示哪些楼层。
  • 用户选择单体建筑时默认显示哪层。
  • 复杂结构中 physical parity 与 ordinal parity 不一致时如何处理。

对当前项目的含义:

  • 当前页面传入 indoor-initial-view="overview",同时存在 activeGuideFloor 默认值;这应被明确为产品策略,而不是偶然状态。
  • 应定义:初次进入馆内时显示全馆、用户主动选楼层后显示单层、从搜索/讲解定位进入时显示目标楼层。
  • 需要区分 requestedFloorIdrenderedFloorIdtargetFloorIduserLocatedFloorId

8.2.4 POI/amenity 必须 floor-aware且要避免跨楼层重叠混淆

IMDF Amenity 规则定义 correlation_id,用于不同 Level 上同一服务设施的关联。其目标之一是:当多个楼层垂直重叠存在同类设施,而用户未选楼层时,地图不应混杂或重复展示。

对当前项目的含义:

  • POI 展示必须严格绑定当前渲染楼层。
  • 多层/全馆模式下,不应无差别显示所有楼层 POI。
  • 同一垂直位置的电梯、楼梯、卫生间等跨层设施需要关联关系,而不是多个互不相关的点。
  • 当前代码已有按楼层加载 POI 的方向,但 POI 专业语义仍需从单 positionGltf 升级为 floor-aware amenity/space 模型。

8.2.5 点位和地图可读性依赖清晰视觉层级与可区分符号系统

British Museum 案例中,地图改版通过颜色和样式区分图标、按钮和地图区域,以降低用户对缩放、滚动、选择对象和地图定向的困难。

对当前项目的含义:

  • 当前 ThreeMap 已经有 POI 类别颜色、优先级、距离过滤和 label 策略,是正确方向。
  • 但专业系统还应有配置化图层、碰撞避让、聚合、色盲友好、非颜色唯一编码、搜索/路线/无障碍任务态强制显示策略。

8.2.6 楼层信息展示应组合地图、文本/语音锚点和附近地标

British Museum Museum Navigator 使用 floor、level、room number、方位和附近 landmark 组织位置描述并结合音频说明、地标图片和高亮路线。COSIT、Met 和 V&A 相关证据也支持在多楼层空间中使用房间号、楼层、地标和可识别转折点辅助定位。

对当前项目的含义:

  • 楼层按钮仅显示 1F / 2F / B1 不足。
  • 楼层信息应显示主要展厅、服务设施、附近地标、空间区域名称和换层节点。
  • POI 卡片也应包含“所在楼层 + 附近地标 + 如何到达/查看位置”的组合描述。

8.2.7 专业室内导览是 integrated wayfinding system

CMHR 指南将 wayfinding 描述为包含 signs、maps、spoken directions、technology、mobile application、website、tactile indicators、lighting 和 amenity communication 的冗余线索系统。VA/WBDG integrated wayfinding 要求所有工具使用一致目的地名称、命名逻辑、视觉语言和同一套 canonical map 信息。

对当前项目的含义:

  • frontend-miniapp 不应自成一套命名体系。
  • 展厅名、楼层名、设施名、房间号、讲解内容应与现场实体导视、后台 SGS 数据和讲解内容库一致。
  • 当前项目需要明确 canonical nomenclature即“哪一套命名为准”。

8.2.8 专业导览应在决策点反复确认方向和楼层上下文

VA/WBDG 指南要求访客在导航过程中获得 frequent intervals 的 reinforcement and guidance并强调 decision points、floor directories、you-are-here 和室内导航能力。CMHR 指南也指出 You-Are-Here maps 应布置在电梯、坡道等方向决策点附近。

移动端对应规范:

  • 到达电梯/楼梯/坡道/入口/服务台/转折点时UI 应强化当前楼层和下一步。
  • 跨楼层路线应明确“当前楼层路径”和“目标楼层路径”。
  • 即使没有实时定位,也应在位置预览中表达“目标在 2F建议从某电梯/楼梯上楼”。

当前项目由于 route graph/nav data readiness 尚未闭环,目前不应承诺此类真实导航,只能在数据可用时逐步增加。

8.2.9 可访问楼层图和平面图是专业展览/博物馆导览的重要组成

Smithsonian Accessible Exhibition Design 要求提供 accessible floorplan 帮助访客 wayfinding并建议在展览入口、信息台或中心位置提供它还要求 circulation route 清楚定义、易跟随,并在 level changes、unexpected turns 或 obstacles 等处清晰表达路线。

对移动端的映射:

  • 楼层图应可被理解,不只是 3D 模型。
  • 路线、无障碍路线、电梯/坡道、台阶规避等应被明确表达。
  • 若 route graph 未就绪,则 UI 应清楚显示“位置预览可用,路线导航未开放”。

8.2.10 专业室内导览需要导航网络/连通性模型支撑

OGC IndoorGML 1.1 的范围是 indoor navigation network models 的表示与交换,强调为室内导航应用建立通用 schema并建模室内空间拓扑和语义关系。

这不意味着本项目必须采用 IndoorGML但说明专业室内导航能力应由以下数据支撑

  • 可步行路网节点。
  • 边和权重。
  • 垂直连接。
  • 空间拓扑。
  • POI 到可达入口或路网节点的映射。
  • 跨楼层路径分段。

当前项目若只有 GLB 和散点 POI应继续定位为“位置预览”。

8.3 外部研究映射到当前项目的专项差距

专业规范 当前项目状态 差距
结构化 Level/ordinal 数据 guideFloor.ts label/code 解析,但缺少完整 Level geometry/ordinal/display point 楼层模型、POI、路线和 UI 状态还未统一到专业 Level 模型
floor-aware POI 有按 floorId 加载 POI POI 仍以单 positionGltf 为主,缺少 amenity correlation、entrance、route node、geometry
楼层目录/内容摘要 楼层按钮只显示 label 缺少每层目的地、主要展厅、服务设施和状态说明
决策点强化 暂无完整路线/决策点 UI 电梯、楼梯、坡道、入口、转折点未形成导览状态机
integrated wayfinding miniapp 内部已有导览/讲解联动雏形 仍需与现场导视、SGS 后台、讲解内容库统一命名和空间关系
可访问 floorplan 当前是 3D 展示 + POI 预览 缺少无障碍路线、可访问入口、坡道/电梯优先等表达
导航网络 route graph/nav data readiness 未验证 不能宣称专业室内导航

8.4 deep-research 推荐追问

后续专项审计建议回答以下问题:

  1. 当前 frontend-miniapp 的楼层切换是否已经有真实 Level 数据模型支撑,还是仅使用 UI 标签/静态图层状态?
  2. 深圳自然博物馆现场实体导视、房间/展厅编号、楼层命名、服务设施名称与 miniapp 中的 POI 命名是否一致?如果不一致,应以哪一套 canonical nomenclature 为准?
  3. 当前导览页是否支持无障碍路径语义,例如电梯、坡道、无障碍卫生间、台阶规避、跨楼层可达路线?这些信息是否来自可维护的数据源?
  4. SGS Map SDK 或上游 sgs-frontend-map 场景设置是否提供 route graph/nav_data、level ordinal、POI level binding、vertical connector 等字段如果没有miniapp 应补充适配层还是推动上游数据治理?

8.5 外部来源