tamakyi
6b665b6056
图片恢复：坐标来源全部合并，认不出时说清已查过哪些来源
真数据实测（扫描 40 个对象、只挂回 7 张）暴露了第一版的漏洞：
报错「数据集 #1 里没有编号 389 的地点」——来源能读出来，却不是上传那会儿的编号空间。
根因：srcPKCoords 是「第一个能读到的来源就返回」，而**换基线会覆盖 baselines/<id>.sqlite**，
当前那份未必是当年上传时用的编号；旧编号往往还躺在同一份底座的 .bak 留档里。
教训很直白：**「能读出数据」不等于「读对了那一版」**。
改了三处：
1. 来源全部读入合并（先读的优先）：库里 places → entity_raw 里 ZLOCATION 的整行留档
（站点上删掉的地点，places 没了、留档可能还在）→ baselines/<id>.sqlite 及其每一份 .bak-*。
读不动的文件跳过换下一个，不再「第一份成功就返回」。
2. 同一个编号保留多组候选坐标，逐个试到能在当前数据集里对上为止
（站点纠过偏、或不同来源算出的坐标不一样，只认第一组会白白认不出）。
3. 认不出要能排查：理由写明「已查来源 …」与试过的坐标；提示条按**数据集归并**上报
（「数据集 #1：31 张（编号 389、390…），已查来源 …」），不再刷「另有 31 张」；
完整清单（前 30 条）进服务端日志。
新增用例：当前底座缺编号、换基线留档里才有（正是用户遇到的形状）⇒ 必须救得回；
以及「真的认不出」时要带出已查来源。全量验收 PASS=332 FAIL=0 SKIP=0。
2026-10-01 00:11:04 +08:00
..
2026-09-24 20:37:16 +08:00
2026-09-18 13:05:49 +08:00
2026-09-18 13:05:49 +08:00
2026-09-30 23:31:17 +08:00
2026-09-18 13:05:49 +08:00
2026-09-24 20:37:16 +08:00
2026-09-18 13:05:49 +08:00
2026-09-24 22:48:22 +08:00
2026-09-30 16:18:52 +08:00
2026-09-30 23:31:17 +08:00
2026-09-24 20:37:16 +08:00
2026-09-30 17:35:59 +08:00
2026-09-18 13:05:49 +08:00
2026-09-30 16:18:52 +08:00
2026-09-24 20:37:16 +08:00
2026-10-01 00:11:04 +08:00