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

> 日期：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` 传入 `indoorModelSource`、`guideFloors`、`indoorView`、`indoorLayerMode`、`activeGuideFloor`。
- `src/pages/index/index.vue:48-53` 监听 `floor-change`、`indoor-view-change`、`poi-click`、`selection-clear`、`auto-switch`。

当前页面结构说明：

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

### 2.2 楼层切换现状

楼层控件位于 `GuideMapShell`：

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

证据：

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

`ThreeMap` 的楼层加载逻辑包括：

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

证据：

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

### 2.3 POI 展示现状

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

- 按视图模式区分 POI 显示密度：`overview`、`multi`、`floor`。
- 按相机距离做可见性分级：`tight`、`balanced`、`full`。
- 按 POI 类别和选中状态计算优先级。
- 点击后设置选中态、聚焦相机、弹出底部卡片。

证据：

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

### 2.4 楼层信息展示现状

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

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

证据：

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

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

- 支持 `L1`、`L-1`、`1F`、`B1`、`L1.5` 等格式。
- 可过滤 `EXTERIOR`、`OUTDOOR`、外立面、馆外等非室内楼层。
- 可按语义楼层从高到低排序。

证据：

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

---

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

## 3.1 楼层切换差异

### 当前项目特点

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

```text
点击楼层按钮
  -> 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. 当前楼层数据质量与可导航状态。

专业表述：

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

### 当前差距

| 维度 | 当前项目 | 专业规范 | 风险 |
|---|---|---|---|
| 切换对象 | 主要是模型 + POI | 完整 floor context | 模型、POI、路径、定位上下文可能不同步 |
| 切换状态 | `activeGuideFloor` 近似单状态 | requested / loading / rendered / failed 分离 | UI 可能显示已切换，但模型或 POI 仍未加载成功 |
| 模型匹配 | 依赖 `floorId`、`label`、节点名、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()` 是异步加载模型。如果模型加载失败，父组件已经切换了楼层状态，可能出现：

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

专业做法应拆分：

```ts
requestedFloorId
loadingFloorId
renderedFloorId
failedFloorId
```

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

---

## 3.2 POI 展示差异

### 当前项目特点

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

证据：

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

### 行业专业规范

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

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

推荐领域模型：

```ts
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 坐标常见语义是：

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

专业渲染中，POI 展示应使用：

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

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

---

## 3.3 楼层信息展示差异

### 当前项目特点

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

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

选中态主要依赖：

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

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

### 行业专业规范

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

```ts
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. 非开放、无数据、无路网楼层应禁用或显示状态。

推荐状态模型：

```ts
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 点位拆分：

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

## 4.3 楼层信息展示规范

专业楼层信息应包含：

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

移动端推荐形式：

```text
楼层按钮：2F
当前楼层 chip：2F · 地球厅 / 演化厅 · 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 未验证前，应继续使用：

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

不应使用：

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

---

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

## P1：统一 SGS 坐标归一化

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

建议：

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

如果需要保留原始高度：

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

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

## P1：楼层切换状态闭环

把当前单一 `activeGuideFloor` 拆成：

```ts
requestedFloorId
loadingFloorId
renderedFloorId
failedFloorId
```

流程：

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

## P1：POI 专业语义拆分

将 `GuideRenderPoi.positionGltf` 逐步升级为：

```ts
displayPoint
anchorPoint
entrancePoints
routeNodeIds
geometry
```

展厅类 POI 尤其需要：

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

## P2：楼层信息面板升级

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

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

楼层按钮可增加：

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

## P2：POI 图层配置化

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

```ts
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 分离。例如 `B1`、`1F`、`L1` 是展示和命名问题，而 `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` 默认值；这应被明确为产品策略，而不是偶然状态。
- 应定义：初次进入馆内时显示全馆、用户主动选楼层后显示单层、从搜索/讲解定位进入时显示目标楼层。
- 需要区分 `requestedFloorId`、`renderedFloorId`、`targetFloorId` 和 `userLocatedFloorId`。

#### 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 外部来源

- OGC Indoor Mapping Data Format (IMDF): https://www.ogc.org/standards/indoor-mapping-data-format/
- OGC IMDF Level: https://docs.ogc.org/cs/20-094/Level/index.html
- OGC IMDF Reference: https://docs.ogc.org/cs/20-094/Reference/index.html
- OGC IMDF Amenity: https://docs.ogc.org/cs/20-094/Amenity/index.html
- OGC IndoorGML 1.1: https://docs.ogc.org/is/19-011r4/19-011r4.html
- VA/WBDG Integrated Wayfinding: https://www.wbdg.org/FFC/VA/VASIGN/wayfinding_new_chapter2.pdf
- Smithsonian Accessible Exhibition Design: https://affiliations.si.edu/wp-content/uploads/PDFs/Accessible-Exhibition-Design.pdf
- ADA Museum Access guide: https://archive.ada.gov/business/museum_access.htm
- CMHR Wayfinding: https://id.humanrights.ca/visitor-supports/wayfinding/
- British Museum mobile wayfinding case: https://www.museumsandtheweb.com/mw2011/papers/mobile_devices_for_orientation_and_way_finding
- COSIT museum orientation reference: https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.COSIT.2017.18
- V&A digital map: https://www.vam.ac.uk/features/digitalmap/where-am-i
- Metropolitan Museum map design case: https://www.100archive.com/projects/metropolitan-museum-of-art-map-design