主场景区的配置契约

Type: grilling Status: resolved Labels: wayfinder:grilling Blocked by: None

进度：100%

已收口（2026-09-18，维护者「确认，同意收口」）。第 1–3 轮 Q1–Q9 全部落 ## Answer。下游：02（相机限位数值）与 07（视距雾气规格）随本票解除阻塞；实现票按地图约定接在 .scratch/cockpit-shell-panel-layout/issues/ 的 30 之后。

Question

以下保留本票启动时的问题与候选；当前有效结论以 ## Answer 为准。

「主场景区」（map.primaryArea）在配置里的字段形状、坐标口径与兜底来源是什么？

甲方已裁定（Q1=C）：用新配置字段显式给出，本部署取值＝甲方框定的沅陵县城范围。但下面三件事还没定死：

字段形状。map.primaryArea.bounds＝[west, south, east, north]（度）？还是中心＋半径、或 GeoJSON？仓库既有约定是四元数组（map.overlays[].bounds、Rectangle.fromDegrees(bounds[0..3])）。
坐标口径。甲方给的 [110.32874994141685, 28.491303899290685, 110.46577922666275, 28.3917230659234] 是 [W, N, E, S]（纬度降序）。归一化到仓库约定后是 [110.328749941417, 28.3917230659234, 110.465779226663, 28.4913038992907]。要不要在配置里就写归一化后的顺序，还是允许写 [W, N, E, S] 由代码翻？
兜底来源。甲方要求未配置时兜底＝「影像 bounds ∩ DEM 有效范围」（下称 B）收紧到 50%。已核实的数字：DEM layer.json（D:\GIS\GIS\yuanlingDEM）valid_bounds ＝ [110.000, 28.000, 111.000, 29.000]，与影像 bounds（map.overlays[0].bounds）求交后 B ≈ 97.8 × 111.3 km；按每边折半收紧 50% 后 ≈ 48.9 × 55.8 km，仍是框定范围的 ≈18.5 倍面积（含城区以外的山区森林）。另经 Cesium 1.145 运行时核对：Cesium 不读 DEM 的 valid_bounds（只读 layer.json 的 available 与 metadataAvailability）—— 也就是说「DEM 有效范围」在运行时无法从 Cesium API 取得；前端自行 fetch map.terrain.url 的 layer.json 则另说。那么兜底到底怎么算？

候选：

(a) 兜底＝硬编码一个保守常量（例如框定范围本身，或某个与沅陵无关的中性盒），不要试图在运行时推导 B。
(b) 兜底＝只取影像 bounds（map.overlays[0].bounds），再按比例收紧 50%（可运行时取得，无需读 DEM）。
(c) 兜底＝沿用 B∩收紧 50%，由部署侧在构建期写死进内置配置，不在运行时推导。
(d) 不设兜底：没配 primaryArea 就整段功能关闭（不锁、不雾），并在引擎浮标上如实报状态。

Answer

已确认决策：第 1 轮 Q1–Q4

维护者确认：Q1=A; Q2=A; Q3=A; Q4=(i)。下述编号对应本票访谈，不对应决策地图早期的 Q 编号。

字段形状（Q1=A）：map.primaryArea 本期只设 bounds，取四元数组 [west, south, east, north]，单位为度。无需另存几何中点，不增加中心＋半径、GeoJSON 或名称字段。此处的几何中点不改变 ADR 0008 中相机旋转中心的既有定义；相机契约合成仍由 03 裁决。
坐标顺序（Q2=A）：部署配置必须写好 [W, S, E, N]。甲方提供的 [W, N, E, S] 在准备配置时转换；运行时代码不自动翻转。校验要求 west < east、south < north；错误记入配置问题并进入 Q3 确认的关闭路径。
兜底责任（Q3=A）：采用“部署期计算候选值＋运行时未配置则关闭”。当部署需要根据数据覆盖准备候选值时，由部署侧离线计算 B = 影像 bounds ∩ DEM 有效范围，收紧后写入同一个 map.primaryArea.bounds 字段。运行时直接消费配置，不为此额外读取 DEM 元数据、不自行计算 B、不内置沅陵地理常量。未配置时关闭本 effort 中依赖主场景区的限位与自建雾气，并由引擎浮标如实提示；顺序非法也进入关闭路径，并保留配置错误原因。
收紧尺度（Q4=(i)）：东西跨度、南北跨度各保留 B 的 50%；经纬度矩形的面积比例约为原来的 25%，不是“面积保留 50%”。收紧围绕哪个中心，仍待下一轮确认。

Q3 替代决策地图早先“未配置时由内置兜底自动得到 B 收紧 50%”的描述。部署期生成候选值不等于前端构建期写死源码，也不要求为修改区域重建应用；结果进入既有部署配置。

已确认决策：第 2 轮

数据越界条款（Q6=A）：契约不含「配置几何合法但超出影像/DEM 覆盖」的校验。配置即权威，越界属部署责任，运行时按配置生效。本部署实测：甲方框定范围 ⊂ DEM valid_bounds ⊂ 影像 bounds，无实际越界。

已确认决策：第 3 轮（Q5/Q7/Q8/Q9 收口）

Q5 收紧中心（最终口径）：＝「进入系统默认位置＝归位按钮位置」＝票 30 交付的 map.home 预设经纬度（相机路径由 .scratch/cockpit-shell-panel-layout/issues/03 相机控制契约锁定，该票已 resolved、维护者 2026-09-17 验收）。数值随部署配置 map.home.lon/lat 走；本机为 lon 110.39028164 / lat 28.4436787。维护者澄清：此处 T03 指外壳与面板布局（执行索引）的 #3 相机控制契约，不是本 effort 的 03 —— 引用目标已 resolved，无相互参照、无死锁，不需要加 Blocked by 边。
Q7=A（作用域）：中心只作用于部署期候选值公式，bounds 仍写死进配置；运行时不做以中心定位或边界跟随。「跟随中心变化」＝部署改 map.home.lon/lat 后重算候选值。本部署显式值不做重定位（其几何中点与 map.home 相差约 0.7 km，由 02/03 的限位口径自理）。
Q8=(a)（形状）：沿用矩形（长宽不等）；「方形」为笔误。不新增正方形口径。

据此，部署期候选值公式补全为：B ＝影像 bounds ∩ DEM layer.json 的 valid_bounds；候选值＝ B 围绕 map.home 经纬度、东西/南北各折半。用本机数据算得示例 ≈ [110.1402, 28.1936, 110.6404, 28.6938]（约 48.9 × 55.7 km，仍完整包含甲方框定范围）；部署时按实际数据重算，不内置该常量。

本部署的显式值

本部署仍采用甲方框定的沅陵县城范围，不用更大的 B 收紧结果替换它：

{
  "map": {
    "primaryArea": {
      "bounds": [110.328749941417, 28.3917230659234, 110.465779226663, 28.4913038992907]
    }
  }
}

以上是已确认的契约示例，尚未修改运行配置或实现代码。

目标、边界与取舍

目标：提供一个明确的主场景区配置，供后续限位、雾气与过渡票共同引用。

边界：本票确定区域配置与不可用时的处理；限位数值归 02，相机中心、home 预设及进出状态机合成归 03，雾气曲线归 07，过渡手段归 08。

取舍：四元数组沿用仓库现有矩形约定；写入时归一化、运行时拒绝反向顺序，使配置错误可见。部署期计算把数据覆盖责任放在部署侧，减少运行时依赖；相应代价是配置遗漏后不会自动恢复区域保护，必须通过明确状态提示发现并修正。

剩余风险：契约各条已全部确认；待维护者过目最终 Answer 全文并确认 resolved 收口。长期注意点：若本 effort 的 03 将来改动 home 的 lon/lat（当前冲突只涉及 range/pitch），需回本票更新 Q5 的中心口径。

Comments

2026-09-18 第 1 轮：fact-check 与 frontier 发出

事实核实（已改正题面）：

DEM layer.json 实测 valid_bounds ＝ [109.99967, 27.99977, 111.00011, 29.00022]（≈ [110, 28, 111, 29]）。影像 bounds ∩ 它 ≈ 97.8 × 111.3 km；原题面「B ＝ 48.9 × 55.8 km」实为每边折半收紧后的数字，已按实测改正。
Cesium 1.145 运行时（Build/CesiumUnminified/Cesium.js）只读 layer.json 的 available 与 metadataAvailability，valid_bounds 零引用 —— 「DEM 有效范围运行时从 Cesium API 拿不到」成立。原题面把该结论归给调研 05，实际 05 的产物未含此项，已改为直接溯源。
配置分层现状（services/cockpitConfig.js）：内置默认 → 构建期环境变量 → 运行时文件（gitignored、部署侧维护）→ 宿主注入。内置默认层里 terrain.url 为空、overlays 为空 —— mock/无配置部署没有影像也没有 DEM，B 在该世界无从谈起。
normalizeConfig 现状：overlays[].bounds 只校验「四个数字」，不校验顺序；主场景区若要防「纬度降序」抄错，需要新校验。

第 1 轮四问已发维护者：Q1 字段形状 / Q2 坐标口径（含顺序校验）/ Q3 兜底机制 / Q4「收紧 50%」语义。结论待答复后写进 ## Answer。

2026-09-18 第 2 轮：Q1–Q4 落盘，Q5–Q6 发出

维护者答复：Q1=A; Q2=A; Q3=A; Q4=(i)。已写入 ## Answer，并同步更新 map.md 第 1 条裁定（原「内置兜底自动得到 B 收紧 50%」已被 Q3=A 取代）。

补充事实（继承第 1 轮子代理简报并已复核）：

ADR 0008：旋转中心＝选中对象地表点 / 屏幕中心地面拾取点，不是场景或城市原点；主场景区的几何中点只用于部署期收紧计算，不触碰旋转中心。
cockpitConfig.js 单次加载、进程内缓存；主场景区沿用该生命周期，不新增热更新。
本部署数据覆盖关系（供 Q6 参照）：甲方框定范围 ⊂ DEM valid_bounds ⊂ 影像 bounds，当前无实际越界。
若按「B 几何中点、每边折半」收紧（Q5 候选 a），候选值 ≈ [110.250, 28.250, 110.750, 28.750]，仍完整包含甲方框定范围。

第 2 轮两问已发维护者：Q5 收紧中心、Q6 数据越界条款。结论待答复后并入 ## Answer。

2026-09-18 第 3 轮：Q5 记录待澄清、Q6 落盘、Q7–Q9 发出

维护者答复：Q5=以在地球视角点击进入系统后的默认位置与归位按钮进入的同位置（T03中完成）为中心点，方形边界区域跟随这个中心点变化；Q6=A。

核实事实：

T03 头部：Blocked by: 01,02，open —— 若 01 的结论依赖 T03 将锁定的进入默认位置，01↔03 出现相互参照，需按本轮 Q9 选收口方式。
「进入系统」与「归位按钮」同走票 30 的 home 预设（mapService.flyToHome / CockpitShell.vue 归位按钮）；本机 home 预设 lon 110.39028164 / lat 28.4436787 / pitch −55 / range 12000。
T03 的冲突 3 已写明：新限位下 home 的 range 12000 超标 5.8×，可能裁定改小 home 预设或豁免归位 —— 即 home 的最终值由 T03 锁定。
本 effort 收口状态（回应维护者「请确认」）：未收口。map.md Status: open、进度 38%；01 claimed、02/03/07/08 open、04/05/06 resolved。Q5 的 T03 耦合使 01 的 resolved 需先定 Q9 的收口方式。

第 3 轮三问已发维护者：Q7 作用域 / Q8 形状 / Q9 依赖收口方式。

2026-09-18 第 4 轮：Q7/Q8 落盘，Q9 经澄清消解

维护者答复：Q7=A; Q8=描述有误，选(a)沿用矩形; Q9=描述有误，T03 指外壳与面板布局（执行索引）的 #3 相机控制契约。