name: omni-site-intel
description: |
万象-地块与楼盘尽调 —— 地块 / 楼盘的多源公开信息尽调：查清「这块地是谁的、批没批、建到哪一步、周边在动什么、四至实体在哪一侧多远多少度」。
什么时候用：要对某个地块或楼盘做背景核查、追踪政府公示与报建进度、核对四至与周边动态时使用。
不适用于：商业地产的投资测算与财务模型；需要现场踏勘或权属证明的正式尽调报告；非公开渠道获取的信息。
agent_created: true
version: "5.3.0"
tags: [real-estate, gov-disclosure, geo-recon, land-parcel, cross-validation, zero-dependency]
triggers:
- 查楼盘信息
- 楼盘尽调
- 竞品调研
- 预售证对位
- 去化率
- 备案均价
- 地块四至
- 周边工程时序
- 开发商股权
- 土地来源
- 政府公示
- 成片开发
- 土地征收
- 控规调整
- 规划公示
- 报建公告
- 查批复
- 查进度
- 周边规划核证
- 挖掘建设单位官网
- 找初设文件来源
- 通知公告抓取
- 公示附件下载
- 查施工工期
- 公共资源交易平台
- 用地图查
- 取坐标
- 经纬度
- 方位角
- 净距
- 两条路是否相接
- POI 落在哪
- 地图核证
- 卫星图判读
- geocode
- reverse geocode
- photon
- overpass
display_name: "万象-地块与楼盘尽调（L0 未习）"
display_name_en: "Wanxiang Site Intel"
description_zh: "查清一块地是谁的、批没批、建到哪、周边在动什么，并交叉核证四至。"
description_en: "Investigate a plot's ownership, approvals, construction progress, and surroundings with cross-verification."
category: "business"
author: "zzzzzzzp"
copyright:
holder: "zzzzzzzp"
year: 2026
license: "All Rights Reserved"
notice: "本技能为 zzzzzzzp 原创作品，著作权归其所有，保留一切权利。未经书面许可，不得复制、改编、再发布或用于训练数据。"
fingerprint: "sha256:990fe59b08de39ff99f4c862e4435c131ec25cb0137f91344b0d62c5281a2cef"
watermark: false
mark_id: "AG1-130b57b3a4"
stamped_at: "2026-10-07T19:07:52+0800"

万象-地块与楼盘尽调

§〇 · 本技能定位为付费技能（Pay Skill）

> 🔴 付费技能一律走完整付费路径 —— 是付费定位，就照着付费通道做完：
> 随包实现 402 链路（见 §〇·2）、接入相应服务、按注册价填单价、走 Pay Skill 向导。

§〇·2 · 随包提供的 402 付费链路实现（平台「付费改造」检测就看这个）

平台在提交时会做一次「支付宝付费改造」检测，判据是技能包内是否存在 402 支付链路的实现，
缺失项会逐条列出：402账单下发 / 携带凭证重试 / 验付调用 / 履约确认 / 订单持久化与幂等。
该检查不阻断提交，但审核阶段会重做一次，不合规即拒。

⇒ 本包自带该实现（目录 a2m/，零密钥、可直接 npm install && npm start）：

配置边界：配置缺失即明确失败（资源路由返回 503），不构造 SDK、不使用占位密钥、不提供任何跳过验付的路径。
密钥只走运行环境变量或本地配置文件，永不入包。

cd a2m && npm install && npm run smoke   # 冒烟：账单结构 / RSA2 签名 / 幂等边界
npm start                                # 默认 http://localhost:3000/demo/a2m/resource

何时用

需要回答关于某一块地／某个楼盘的下列任一类问题，且必须跨多个公开源核证时：

也用于给风水、投研、购房决策等下游任务做事实底座。
下游的解读（方位吉凶、投资建议）不写在事实节里，另起「影响与建议」节并标注待确认。

§0 三条铁律（跨全部来源，先读）

1. 先铺源，再提问——不要拿到问题就搜关键词。三层源铺满再决定查哪个。
2. 任一关键数字至少两源互证；只有一源时标注可信度，不得当结论用。
3. 三种可信度不可混用：政府源＝硬事实；平台源＝可校验参数；营销文案＝仅作线索。

> "我查了没有"和"我能证明没有"是两件事。 凡"未获批／未开工／未取证"这类否定结论，
> 必须能列出检索式 + 命中条数 + 分页有效性验证，否则只能写"未查到"。

§1 整条链路的分工（哪一步归哪一节）

① 铺源定层级  →  §2 三层源表 ＋ §4 源权威度分层
② 挖文件      →  §7 站点挖掘 ＋ §8 附件解包与文档抽取
③ 核状态      →  §5 六铁律 ＋ §6 状态订正
④ 定几何      →  §9–§13 地图与图像两条通道
⑤ 交叉校验收口 →  §14 输出规范 ＋ §15 自检清单

这四步不能跳。 最常见的事故是：跳过 §1 直接搜关键词（层级错），或跳过 §5 拿文件自述状态当事实（状态错）。
下游互指：只挖文件不核状态 → 用 §7；只核状态不挖文件 → 用 §5＋§6；两者都要 → §7 挖下来再交 §6 订正。

§2 第 0 步：先铺源，再提问（最重要）

不要拿到问题就搜关键词。先把源铺满三层，再决定查哪个。

三层的作用不同：政府源定"是什么"，平台源定"卖成什么样"，聚合源定"什么时候动"。缺一层就会误判。

§3 各层检索手法

① 政府 / 交易平台

• 入口是编号，不是名字：先拿到 报建编号 / 项目编码 / 立项文号，再去查。
• ⚠️ 但注意：交易平台的关键词检索通常只匹配标题，用报建编号当关键词往往 0 命中——编号用于在详情页核对，不用于检索。
• 交易平台通常有可直接构造的检索 URL（形如 queryContent-jygk.jspx?title=<关键词>&channelId=<栏目>）。一个片区名就能拉出该片区近十年全部工程公告，远胜逐页翻列表。
• 省级平台常有覆盖盲区（例如某省平台不聚合某开发区／独立管理区项目）→ 先做一次小样本实测：用一个已知属于该区的项目名试，0 命中就换市平台，别在错的地方空转。
• 建筑市场一体化平台（各省多有，如湖北 hbjz.hbcic.net.cn）是被严重低估的源：给 GIS 坐标、四至、建设规模、参建单位、招投标、施工许可、竣工验收全字段。

② 平台源

• 房产平台的 「项目备案名 / 预售许可证号 / 四至范围」 三行最有价值——它们通常抄自官方公示。
• 地图 POI 用来定位周边实体（学校、公园、竞品、道路），
  ⚠️ 但POI 常标的是"售楼处"而非地块，且坐标系可能不精确 → 不可用于测距，只用于判断方位关系。
• 企业信用查股权比例（营销文常写"XX 100% 全资"，工商往往不是）与法人。

③ 聚合源

• 「建设周期」只有聚合源给（政府公告给"计划工期 N 日历天"，聚合源给"YYYY-MM ~ YYYY-MM"）——两者结合才能算出真实进场与完工。
• 开发商自有招采平台是招标公告的原始出处，往往比转载更全。

§4 源权威度分层：越下游越硬

这是全部层级判断的唯一口径。做地块周边核证时，第一站应去「分局公示栏」而非区政务网。

证据等级（引用时必标）：官方原件 > 官方转载 > 媒体 > 自媒体。
网络二手讨论不可作证据，但常能提供关键线索（如"这是 XX 调整方案"的提法），
用于确立检索关键词，再去官方源坐实。

域名不同 ≠ 内容无关。 区政务网找不到的，可能在市局／分局站点——同一机构常有多个站点分工
（政务宣传站 vs 业务公示站）。找不到不等于没有，先换站再下结论。

§5 政府公示链六铁律

铁律一：编号序列 = 进度台账

政府规划土地类文件普遍带规律编号，例如土地征收成片开发方案：

<年份>CPKF<行政区代码><序号>
2022CPKF4201110006
2023CPKF4201110003
2026CPKF4201110001

最新一版文件里，几乎总有一节回顾历次方案的实施情况（常见标题：
「已批准……实施情况」「批而未供和闲置土地处置任务完成情况」）。该节通常以表格给出：

⇒ 拿到最新一版，等于拿到全套历史台账。这一步能一次性解决 80% 的"某项目到底批没批"问题。

铁律二：不要用文件自述状态推断当前状态

任何来源的"尚未获批 / 未开工 / 未落地"表述，只反映该文件的编制时点。
引用时必须加限定："该表述仅反映 XXXX 年 XX 月编制时点"。

⚠️ 同一编号可能有两版文件。 实测某编号在 4 月和 8 月各公示一次，
面积、涉村、用途、实施期全不同（15.1142 ha／4 村 → 10.8961 ha／5 村）。
⇒ 同一编号不等于同一份文件。判定最新版的方法：比公示日期，并核对面积与涉村名单。
引用时务必写清"哪一版"。
> ⚠️ "征求意见稿"是常态载体，不代表项目未推进——政府公示绝大多数以征求意见稿形式发布。
> 凡见此字样，必须按铁律二复核（去同系列更新的文件里找"已批准……实施情况"节），
> 不得直接据此判"未获批"。

铁律三：施工工期只在「交易平台招标公告」里

初设文件不给施工日历——实测某市政配套道路初设说明书数百页，检索"总工期／工期为／开工日期／竣工日期／计划于／拟于"全部 0 命中（只有"施工期交通疏解"这类原则性表述）。
若据此断言"工期未公示"就错了。

• 真工期在公共资源交易平台的《招标公告》里，字段名就叫 「计划工期（日历天）」，是硬数字。
• 一次可拿全 招标 → 评标 → 中标 三份公告 ⇒ 完整时点链（公告日／开标日／中标公示日）＋中标人＋中标价。
• 市平台 ≠ 省平台：实测某些区项目在市平台有全链，在省平台搜不到 ⇒ 两个都查，先查市平台。
• 反例警示：聚合站（dlnyzb.com、bidcenter 类）全站反爬（连首页都 429）且详情需登录付费 ⇒ 直接上官方平台，别在聚合站耗时间。
• 拿到工期的真正用处：把"施工起止"与交付／入住日期对齐。工期 210 天 vs 900 天，对"施工期是否覆盖入住期"是完全不同的结论；尤其别把两个相邻但独立的工程按同一个工期默认叠加（曾把一条 210 天的支路并进邻盘 900 天的工地，误判为"双重施工源"）。

§5.3a 市平台「检索端点」——一句话查全片区工程链 ★

不要靠翻列表页。武汉市公共资源交易平台（ggzyfw.wuhan.gov.cn）有可直接构造的检索 URL：

https://ggzyfw.wuhan.gov.cn/whggzy/queryContent-jygk.jspx?title=<关键词>&channelId=159&beginTime=&endTime=
翻页：  queryContent_2-jygk.jspx?...    queryContent_3-jygk.jspx?...   （页大小固定 10）

返回每条记录：项目名 ＋ 信息来源 ＋ 信息类型 ＋ 发布时间 ＋ 详情链接。
详情页 URL 规律：/whggzy/<栏目>/<数字ID>.jhtml，栏目名＝
jygkzbjh(招标计划)｜jygkgy(招标/资格预审公告)｜jygbggg(变更)｜jygkjt(评标／中标结果公示)；
数字 ID 单调递增＝发布时间序（可据相邻 ID 估日期）。

为什么这是"最强工具"：只要一个片区名/路名/村名/开发商名做关键词，就能一次拿到该片区近 10 年的全部工程公告——
哪个项目在动土、工期多少天、中标人是谁、何时开标中标，全在同一张表里。
实测用「九峰」一次拉出 290 条（2017–2026），把四条独立时间线全部锁死。

§5.3b 读招标公告的六个坑

1. 「报名期」≠「开标」。资格预审项目的字段「公告发布及投标报名、资格预审文件下载 起止时间」是资审报名窗口；带分钟的时刻（如 2026-10-13 09:29）才是投标截止＝开标。曾把 2026-08-28 ~ 09-02 误当开标，导致开工推算整体提前 1~2 个月。
2. 资格预审 vs 资格后审。资格预审·评审制会「按评分排名取 ≤15 家」参加投标 ⇒ 前面多一轮评审，链条更长；资格后审则"合格即投标"，通常更快。
3. 「评定分离」是时点杀手。公告备注常写「本项目采用评定分离方式确定中标人」⇒ 评标结果公示（推荐候选人）之后还要招标人定标，才出中标结果公示。推算"进场下界"必须用「中标结果公示 → 签合同 → 进场」，不能用监理/施工的报名截止日（后者离进场还差 2~4 个月）。
4. 翻页参数常失效。queryContent_2-jygk.jspx 有时直接返回与第 1 页字节数完全相同的页面 ⇒ 判别法：比对两页字节数，相同即表示该关键词只有 1 页，不必再循环，也别误判"漏条"。
5. 报建编号不能当 title= 关键词。检索只匹配标题——用报建编号查 0 命中是正常的，不代表项目不存在。正确次序：先用项目名/标段名关键词拿到结果列表，再在列表里比对报建编号与工程地点。
6. 「中标公示未出」要能证明。写法：精确串检索 → 列出全部命中条数与类型 → 声明"无资格预审结果/评标结果/中标结果公示" → 附分页有效性验证。

§5.3c 市局 vs 分局 的分工

自然资源系统普遍一个系统两个站，职责分工明确：

• 陷阱：市局的「规划批前公示」栏目可能是空壳页（实测仅 653 B），真实内容全在分局。
  看到空壳不要以为没有，去分局找。
• 域名会换：机构改革后新旧域名常并存（实测 zrzyhchjs. 与 zrzyhgh. 同站互达，更早还有 gtghj.）。以主站标题确认当前规范域名。
• 成片开发有专属归档栏：多在 业务频道 › 土地管理 › 用途管制（…_tdgl/…_ytgz/），不一定在「通知公告」栏——两处都要翻。

§5.3d 时点推算口诀

• 要"何时开工" → 看监理招标公告的报名截止日（定标在报名截止之后，施工进场更晚）；
• 要"何时完工" → 招标公告的计划工期＋推定进场（定标后约 1 个月）；
• 要"是否已完工" → 找中标结果公示日期 ＋ 工期倒推。

> ⚠️ 工期推算只能给"应当"：日历天数只说明"理论上该完工了"，不证明现状。

铁律四：地块核证还须查「住房和城市更新局」

自然资源系统之外，房产/城市更新是另一个独立部门，管着楼盘级官方数据库，
是判断"某楼盘是否开盘/取证/去化如何"的唯一官方入口：

⚠️ 两局名称极像、极易混淆（"城乡建设"四个字同时出现在两边）——"地的事找前者、房的事找后者"。

商品房项目查询系统：
- ASP.NET：先 GET 取 __VIEWSTATE/__VIEWSTATEGENERATOR/__EVENTVALIDATION，
POST 用 gb18030（站报 gb2312，实测 gb18030 正确）＋ 复用 http.cookiejar Cookie。
- 查询字段：项目名 / 地址 / 开发商三选一；结果列头含 总套数｜已售｜可售（住房与非住房分列）。
- ⚠️ 裸域 DNS 常失败，须用子系统子域（如 spfxm. 前缀）。
- 完整入口（实测）：http://spfxm.whfgxx.org.cn:8083/spfxmcx/spfcx_index.aspx
- 典型用法：多路检索均无结果 ⇒ 该项目尚未取得预售许可（＝"尚未开盘"的官方侧面证据）；
拿到开发商全称后可用其字段精确复查，一举闭合预售证问题。

★★★ 铁律五：官方业务系统用「报建登记名」，不是销售案名

这是最容易全盘落空的一个坑。 实测：

• 根因：系统登记名＝报建名/地名办名，与销售案名完全不同源；
  开发商字段也可能只写项目公司而非品牌方。
• 因此"查无结果"绝不能直接推成"未取证/未开盘" —— 极可能只是名字不对。
• 正确姿势（三步并行）：
  1. 用地址检索（最稳，地址不易变）；
  2. 问用户/查证报建名（公示文件、工规证、土地证上都是报建名）；
  3. 用"开发商"字段反查（拿项目公司全称）。
• 判定口径："多路检索（含地址）均无"才可谨慎表述为"可能未取证"，
  且必须写"以地址检索为准"。单靠案名查无结果不得下结论。

§5.5a 楼盘表的层级链与"已售"判据（可直接复用）

一旦命中，可下钻到逐套粒度：

索引页 spfcx_index.aspx
  → 主档 spfcx_mx.aspx?DengJH=<登记号>        # 项目名/坐落/土地证/用地面积/工规证/栋数/套数/开发商
  → 栋表 spfcx_lpb.aspx?DengJh=<登记号>       # 每栋：楼栋名/总层数/总套数/建筑面积
  → 房表 spfcx_fang.aspx?dengJH=<登记号>&houseDengJh=<栋登记号>   # 每栋逐层逐套
  → 单套 http://<内网IP>:8080/TimeFL.aspx?gid=<UUID>

• ⚠️ DengJH 参数必须按 gb2312 编码：?DengJH=%BA%FE2500529。
• 用 UTF-8 编码 → 页面报 "参数错误！"、所有字段空壳（极易误判成"页面没数据"）；
• 直接传中文 → .NET 写成 %u5a40%3f… → 同样失败。
• 漏编码一个参数，整个抓取就不可信。
• 房表"已售"判据（权威）：<td style=background-color:#FFFF00> ＝ 已售；
  空 style= ＝ 未售；文字含 △ ＝ 限制销售；* ＝抵押；⊗ ＝查封。
  房表数据全在 HTML 里（无 AJAX），但简单正则易漏——style 值含 #，
  须用 <td([^>]*)>(.*?)</td> 同时捕获属性与内容再判断。
• 自算法校验：把各栋房表逐格统计，与系统汇总列（总套数/已售/可售）对账——
  实测自算 660 可售＋20 限制销售＝680、已售 226、未售 434，与官方逐位吻合。
  任何"抓下来的数据"都应做这种自洽校验再引用。

★★★ 铁律六：列表页的「名称」与「链接」顺序不保证同步

这是最隐蔽、后果最严重的一个坑。

实测：某栋表中，栋名（A地块1、13、14…）的显示顺序 与 houseDengJh 链接的出现顺序
并不同步（链接按登记号序，栋名按另一序）。

• 错误做法：拿一份外部记下的登记号列表，按位置硬配对第 1 个名称 ↔ 第 1 个 ID。
  → 结果：除第一栋外，全部栋的明细张冠李戴——
  误报 A地块8＝0%（实为 44.1%）、A地块16＝0%（实为 75.0%，实际最佳）、
  A地块9＝58.3%（实为 0%）、A地块7＝75.0%（实为 39.6%）。
• 为什么会漏掉：合计值恰好是对的（226／660），所以"总量自洽"校验通不过，掩盖了明细错误。
• 正确做法：从列表页 HTML 中逐个正则解析 (名称, 链接ID) 配对，绝不按位置/外部列表硬编码：
  python pairs = re.findall(r'spfcx_fang\.aspx\?dengJH=([^&"]+)&(?:amp;)?houseDengJh=([^"&]+)', html) names = re.findall(r'>([^<>]*?A地块\d+)<', html) # 顺序与 pairs 一一对应

★ 通用形式（跨站点通用）：
> 列表页的显示顺序 ≠ 链接参数的顺序。永远从列表逐条解析配对，不要用"第 N 个名称配第 N 个 ID"。
> 并且：明细级数据在发布前，必须与一个独立来源交叉验证（本次是靠用户发来的截图才发现），
> "合计对得上"不能证明"明细是对的"。

★★★ 铁律七：招标／中标公告的「同项目」判据只有两条——招标人 ＋ 报建编号

触发场景：在东湖高新区（及大多数由同一家代理机构包片代理的区）检索某项目的中标结果，
很容易命中一条"看着完全对得上"的公告，但它是另一个项目。

实测陷阱（2026-09-21，九峰还建一标段施工）：检索"九峰还建社区安置房项目施工 中标结果"时命中

> 「武汉国家农创中心新质生产力基地项目一期工程总承包（EPC）」中标结果公告
> 中标人 武汉建工集团股份有限公司｜中标价 36,938.914720 万｜工期 730 天

与目标项目「九峰还建社区安置房项目施工（一标段）」在四个"辨识特征"上完全相同：

⇒ 判据只有两条，其余一律不作数：

1. 招标人（建设单位）
2. 报建编号／招标登记编号

> 为什么"同代理"必然失效：一个区的招标几乎全部由同一家代理机构的同一个项目部代理，
> 经办人常年是同一批人（本例中 4 人完全相同），开标室也只有那几间。
> 所以"同代理 + 同经办 + 同监管 + 同开标室"的信息量接近为零。

推广（不限于招投标）：任何"按特征匹配到的候选文档"，采信前必须找到至少一个"对象标识字段"
（招标人／报建编号／项目编码／土地证号／立项文号），特征相似不足以判定同源。

★★ 铁律八：公告的"金额／工期"与招标公告不一致时，先怀疑自己找错了项目

同一陷阱的连带教训：还建一标段招标口径为「投资额 5.96 亿／900 天／工程施工招标」，
而误命中的公告为「3.69 亿／730 天／工程总承包（EPC）」。
⇒ 出现金额与工期双双不符时，不要用"调整概算""工期优化"去圆，
先回去比对招标人与报建编号——绝大多数情况是找错了项目。

★★ 铁律九：「评定分离」——"开标已过但无中标结果"是制度性常态，不是停滞

现象：某项目招标公告已发布、开标日已过，但长期检索不到"中标结果公告"。
误判风险：据此写"项目停滞／未见任何进展"。

判据：查看招标公告的评标办法／定标方式字段。若写明

> 「（适用于评定分离）……」／「采用评定分离方式确定中标人」

则评标委员会只产生候选人，定标权在招标人，且定标无公开时限。

⇒ 正确写法：「已开标、已评标；因采评定分离，中标结果以招标人定标为准，截至 YYYY-MM-DD 未公告」——
这比"未见中标"更准确，也正面解释了为什么看不到。

> 实测（2026-09-21）：还建施工一/二标段（2026-09-02 开标）与监理一/二标段（开标 2026-10-13）
> 全部采用评定分离；同期梅溪岭 EPC 则于评标后 3 天（2026-09-14）出中标结果公告。
> ⇒ 同为评定分离，出结果快慢差异很大，不能以时长推断"没戏"。

§6 状态订正流程

订正流程（发现疑似矛盾时）：

1. 记下该文件的编号前缀（如 2023CPKF420111）；
2. 检索同前缀 + 更大序号 / 更晚年份的文件；
3. 在新文件里找"已批准……实施情况"章节，查该编号对应的实际批复日期与完成率；
4. 若新文件未提及，再去分局公示栏按时间倒序翻"网上征求意见公示"与"成片开发"条目；

5. 用三条一致性判据确认"调整方案"与"原方案"是同一项目：
   - ① 面积（允许变化，如 153.2023 → 113.3037 公顷）
   - ② 涉村/涉地块名单（应完全一致）
   - ③ 文件同源（官方直链文件名与手上文件一致）
   订正纪律（对应 Step 4「订正既有结论」）——订正不是改一处就完：

6. 对每一个曾发布该结论的产物逐条复核（报告、摘录、下游任务的输入）；

7. 修正时同时保留原结论与新结论，写明订正依据与日期，痕迹留存、便于审计；
8. 改完返回 Step 5 做残留扫描，命中数必须为 0，才算收口。

执行步骤

• Step 1 · 定位正确的公示栏目
• 分局公示栏常见路径特征：/<分局简称>/<分局简称>_tzgg/<分局简称>_gsgg/
• 栏目内条目类型识别："规划设计方案……听证告知书" = 规划类；
  "……成片开发方案……征求意见公示" = 土地征收类；"征地区片综合地价调整……公告" = 地价类。
• Step 2 · 拿最新一版同类文件——按时间倒序找最近的公示，下载其 PDF 附件；
  不要跳过 PDF——回顾章节与附表都在里面。
• Step 3 · 抽取"已批准……实施情况"章节——PDF 有文字层用 pymupdf 直接 get_text()；
  扫描件渲染 PNG 后 OCR；目标是那张历次方案 × 面积 × 完成率 × 批复日期的表。
• Step 4 · 订正既有结论——对每一个曾判定"未获批/未开工"的项目逐条复核；
  发现矛盾 → 立即修正所有已发布该结论的产物（报告、台账、记忆）；
  修正时保留订正痕迹（原结论 → 新结论 → 证据），便于审计。
• Step 5 · 扫描残留，确认收口——对全部产物做旧错误表述的字符串扫描，命中数必须为 0。
  （教训：仅改"主报告"而漏改通俗版/台账，会导致结论打架。）

工程"状态链"必须逐环节拆开（★ 铁律）

一个工程从"招标"到"能用"至少要过七道门，每一次只能推出下一道，不能跳：

> 招标公告 → 中标结果公示 → 签合同进场 → 施工 → 竣工/完工 → 验收 → 移交 → 开通/投用

• 投标报名截止 ≠ 开标（资格预审项目尤其）；中标公示 ≠ 进场（评定分离下还要定标、签约）；
• ★「完工」≠「通车」：曾按 210 日历天＋聚合源"建设周期"推得"已通车、动土已了"，现场一看尚未通车 ⇒ 结论错一整轮。
• ⇒ 凡"是否已完工/通车/投用"的状态判断，一律以"现场观察 或 移交/开通公告"为准；工期链只作背景。
  无法现场时，明确标注为"按期应已完成"，不要写成"已完成"。

§7 建设单位官网／公示站点挖掘

用途：官方公示比新闻更早、更权威。平台公司官网的「通知公告」栏目通常集中发布：
初步设计文件公示（附件＝整套初设文件压缩包）、招标/遴选公告、竣工验收公示。
一次初设公示 ≈ 数百页的一手图纸与说明书。

作业流程（6 步）

1. 定位站点：从已知工程的《初步设计文件》封面/图签找"建设单位"全称 → 搜索"建设单位全称 官网"。
2. 摸清栏目结构：抓首页 → 列出导航栏目；重点关注 通知公告/公示公告/招标采购 三类
   （其余"公司新闻/党建/企业文化"多为软文，信息密度低）。
3. 全量清单：翻完目标栏目的全部列表页（注意分页 URL 规律，如 /tzgg/index_2.htm），
   抽 标题 + 日期 + 链接 去重成清单。
4. 关键词筛选：用本地关键词表过滤（地块四至道路名、村社名、周边小区名、山体水系名），
   不要一条条读。
5. 溯源已用文件：若手上已有某份初设文件，用其下载文件夹名/附件文件名去公示页比对，
   即可确认官方出处（可公开引用的 URL + 公示日期）。
6. 下载消化：附件通常是整套初设（几百 MB）。先 HEAD 看 Content-Length，再下载、解压、
   抽 PDF 文本，按「区位四至/规模/竖向/地质/工期」维度做事实抽取落盘 digest。

抓取技术要点（踩过的坑）

• 403 绕过：直接请求常被 nginx 403。必须带浏览器 User-Agent + Referer（站点根 URL）。
• 编码陷阱：<meta charset=gb2312> 往往是错的，以 HTTP 响应头 charset 为准
  （很多这类站实际是 UTF-8）。两个都试，取能正常解码中文者。
• 站内检索：JEECMS 系站点通常 /search.jspx?q=<urlencode> 有效；
  keyword=、searchWord= 常无效。结果页会附带固定的"资料下载"噪声条目，需过滤。
• 附件命名不可读：路径形如 /u/cms/www/<YYYYMM>/<时间戳13位+4位随机码>.rar，
  无法从文件名判断内容，必须回到公示页取标题。
• 抓取纪律：串行 + 每请求间隔 0.4–0.8s；原始 HTML 落盘到本地目录再离线解析，
  不要边抓边解析（避免重复请求）。

产出规范：digest_<站名>.md 的固定结构

一份 digest_<站名>.md 固定七段，缺一段即视为未完成：

1. 站点身份与结构——主办单位、域名、栏目树；
2. 核心栏目价值——哪几个栏目值得长期盯；
3. 与目标地块相关的公告清单——含公示日期与相对链接；
4. 新发现的关键事实——按优先级排序，每条带出处；
5. 可下载资产表——文件名 / 体积 / 建议（下不下、为什么）；
6. 长期追踪建议——下次看什么、多久看一次；
7. 方法与坑——本次踩到的技术问题。

正文只摘事实。 风水／投资等解读放到独立的「影响与建议」节，并标注"待确认"。
公示页 URL ＋ 公示日期必须随事实一并记录——这是可引用出处的唯一凭据。

边界（硬约束）

• 只做公开信息的获取与整理，不下载、不存储明显超出评估所需的敏感材料。
• 公示附件属建设方公开文件，引用时保留原出处。
• 若用于对外发布，遵守脱敏红线：不出现真实项目名 / 甲方 / 设计公司。

§8 附件解包与文档抽取

• 附件体积：单个初设压缩包常 300–500 MB，先 HEAD 探 Content-Length 再决定下载。
• 压缩包格式（先看魔数再选工具）：
• 文件头 PK ＝ 真 zip ⇒ 用 Python zipfile；
• Rar! ＋ 版本 526172211a07 ＝ 真 RAR5（zipfile 必败，别浪费时间试）。
• 真 RAR5 解压方案（按优先级）：
  1. Windows 自带 C:\Windows\system32\tar.EXE -xf <文件.rar> -C <目标目录>
  （libarchive 支持 RAR5，无外部依赖；中文文件名输出为 GBK，
  须 decode('gbk','replace')，不要走 shell 管道）；
  2. 本机若有 7-Zip（22.01 实测可用）用 7z x；
  3. 都没有再考虑安装工具。
• 嵌套压缩包：同一压缩包内可能套嵌套压缩包（如 初设.pdf ＋ 图纸.rar），
  图纸包同样用上述方法再解一层。
• 文档抽取：初设说明书是主要文字来源（常 150 页左右），用 PyMuPDF
  （import pymupdf as fitz）get_text() 抽全文；纯矢量图纸 PDF 文字极少，
  关键尺寸/标高需渲染成图看图（get_pixmap(matrix=fitz.Matrix(sc,sc))）。

§9 地图侧第 0 步：先建「源能力表」

先做一次连通性实测，再决定用哪个源。 不同机器/沙箱通的不一样。

> ⚠️ 沙箱常见结果：Python urllib 直连公网 → Tunnel connection failed: 502。
> 必须走平台提供的 WebFetch 通道，并且让 WebFetch「返回原始 JSON 逐字、不要摘要」——
> 否则模型会把坐标抹掉。

> ⚠️ 最常见的一类错误：把「项目部」当成了「地块」。
> 楼盘名 POI 常被钉在项目部／营销中心／城市展厅／工地生活区／某号楼上；
> 一旦拿它算方位与净距，整套基准全错（实测曾由此得出 351.1 m / 296.99° 的错误基准）。
> 判据：把该 POI 送一次 reverse，看最近地物是不是该楼盘本体；不是就作废重取。

关于底图：Photon/OSM 在中国大陆的道路几何精度普遍不足（会出现"两条平行路交于同一点"这类荒谬解）。
⇒ OSM 只用于：名称核对、道路等级、走向/拓扑、面状地物 bbox。
⇒ 不用于：精确测距、交叉口解算、地块质心。 这三件事一旦要精确，直接上商用 API。

§10 取数形状与走向判定

10.1 取数：要 bbox，不要只要中心点

同一名称会有多个 way（同一条路的若干段）——必须全部取出，把 extent 合并后再判。

GET /api/?q=<路名/地物名>&lat=<区域中心lat>&lon=<区域中心lon>&limit=10

读法：
- osm_value 给道路等级（trunk 主干 / secondary 次干 / tertiary 支路 / service 内部路）
——等级可反推这条路在片区里的角色。
- extent = [lon_min, lat_max, lon_max, lat_min] ⇒
ΔE ≈ (lon_max-lon_min) × 111320 × cos(lat) m，ΔN ≈ (lat_max-lat_min) × 110900 m
⇒ 方位角 = atan2(ΔE, ΔN)，并据此判"南北向"还是"东西向"。
- 地形数据的顺序陷阱：bbox 只给极值，哪端是北、哪端是东需要结合常识判断；
判错会让整条路的走向反向（本方法最常踩的坑）。

10.2 ★ 先测「片区路网旋转角」，再谈任何方位

这是中国大陆新区最容易翻车的一点。

光谷、苏州园区、郑东新区等片区，路网是整体旋转的。实测某片区：
- 名义"南北向"的支路，真方位是 28.6°；
- 名义"东西向"的支路，真方位是 61°／119°（与前者正交）。

⇒ 后果：若按"南北向道路 = 0°"去推方位体系，整个体系会系统性偏移 ~29°——
足以让一个实体从"正北"跳到"西北"，或让坐向从"下卦"跳到"兼向"。

做法：取片区内两条已知互相垂直的道路，各算方位角，两者的共同偏差即路网旋转角。
之后判任何实体的方位，先减去旋转角，再折算成八宫/二十四山。

★ 实测印证（2026-09-21，两轮独立）：某盘西界路走向 151.5°（偏南北 28.5°）、
北界路走向 61.2°（偏东西 28.8°），两者夹角 90.3° ⇒
互相垂直 + 同偏 28.6° —— 两条路互为"正交性校验"，比单路量测强得多。
判据：若两条名义互垂的路夹角≈90° 且偏角一致，则旋转角坐实；
若夹角明显偏离 90°（如 30°），说明二者不属于同一网格，不可用于定旋转角。

⚠️ 三个必须同时交代的边界（否则结论会被误用）：

1. 旋转角≠坐向。"片区路网旋转 28.6°"只说明网格朝向，
   不说明楼栋是否随网格 —— 楼栋可以独立于路网定向（这在同一片区确实存在）。
   要判楼栋朝向，需要楼栋自身的证据（总平面图指北针／卫星图／实地罗盘）。
2. 同一条路的远场段与近场段走向可能不同 ⇒ 必须按距离过滤（见 §13A.2 第 4 条）。
   实测反例：某南北界路近场为 271.8°（近乎正东西），与北界路 61.2° 不平行
   ⇒ 该盘南北两界是否平行本身成为一条待核项，不可默认"地块是矩形"。
3. 代理检验可能不定论。若片区内同时存在正交族与偏转族楼栋
   （实测同一 bbox 内 6 栋近正交 0.3°~6.2°、8 栋偏转 26.7°~42.2°），
   不得二选一，应如实报"代理检验不定论"并把判定权交回现场／A 级图纸。

10.3 政府 POI 当道路锚点

office=government 且 street= 字段写着某路名的要素，
可直接作为那条路的定位锚点——比模糊的道路 bbox 可靠得多。
同理可用地铁站（railway=station，含 street=）。

10.4 只有一张卫星截图时：仿射配准

1. 在截图上肉眼定位 3 个以上可唯一识别的点（主要交叉口、标志性建筑角点）。
2. 对每个点在数据源里查到经纬度（道路 extent 交点、政府/交通 POI）。
3. 解 仿射变换（lat/lon = A·(x,y) + b，≥3 点最小二乘）。
   不要用相似变换——地图投影在片区尺度上不是纯旋转缩放。
4. 反算残差；残差 > 20 m 的点剔除后重解。
5. ⚠️ 前提是底图正北朝上。若截图被旋转过，先验旋转角再配准
   ——可用"已知道路在图上与水平线的夹角"与其真方位角之差来估。

§11 ★★ 逆地理编码用来「验伪」，不只是用来定位

把既有档案里的每一个 POI 都送一次 reverse，看它最近的地物是不是"它该在的地方"。

GET /reverse?lat=<poi_lat>&lon=<poi_lon>&limit=8&radius=1

判据：
- 最近地物合理（如某楼盘 POI 的最近地物是该楼盘）⇒ 可用。
- 最近地物是完全无关的东西 ⇒ 该 POI 不是地块，多半是售楼处／项目部／临时办公点，
不可用于测距，且由它派生的全部方位与距离一并作废。

实证：某档案用 POI 算出某邻盘在"西北 297°"，reverse 后其最近地物是另一条主干道与两座公园
——该 POI 压根不在那个楼盘上。而现场地图显示该盘的项目部恰在马路另一侧
⇒ "西北"是项目部的方位，不是地块的方位。

> 规则：方位与距离只能用地块（本体）坐标算，不能用"楼盘给的点"。
> 地图上标注的楼盘名，往往钉在售楼处或项目部。

11.1 POI 三分法（强制检查）

拿到任何"楼盘名 POI"坐标，先归入三类再决定用途：

验伪手段：把该坐标送逆地理编码，看最近地物是不是它"该在的地方"。
实测某盘 POI 最近地物是主干道／公园／政务服务中心——全部在另一个方向，即靠此发现。

11.2 用「已知实体」做约束求解（坐标定标三约束法）

当坐标可疑时，用档案里已知的实体关系反解正确坐标：

1. 南界约束：本盘南界 ＝ 南侧公园北界 ⇒ 取公园轮廓 max(lat)；
2. 东界约束：本盘东界 ＝ 东侧主干道红线（西退绿化带宽度须扣除）；
3. 尺寸约束：用地面积 ÷ 进深 ＝ 等效宽。

三者交叉即可锁定中心坐标。 实测解得中心纬 = 公园北界 + 半进深，
与经度独立解得的结果组合后，与逆地理判据一致。

11.3 ★ 沿轴线批量定点逆地理（判定某方向的"性质"）

要回答「本盘以北 500 m 究竟是人居还是山林」这类问题，不要猜，做扫描：

for lat in [30.4950, 30.4960, 30.4970, ..., 30.5040]:
    print(lat, photon_reverse(lat, FIXED_LON))

实测结论：30.4955 公园 → 30.4960~30.5006 幼儿园 → 30.5013~30.5030 空轨站
→ 30.5040 动物园入口 ⇒ 北侧以人文设施为主，非山林，判语不变。

该手法成本极低（每次约 0.3 s），却能一次性把"某方位到底是什么"钉死，
强烈建议作为方位类结论的标配验证。

11.4 面状地物（公园／园区／绿地）禁止单点定位

• 取 bbox，按面宽给出方位区间，并写明"跨哪几宫、以哪宫为主"。
• ⚠️ 同一份面状地物的四至在不同官方文件里可能不一致
  （实测：某公园西界，EPC 招标写"孟新路"、百科写"王家店路"）⇒ 双说并记，不择一。
• ⚠️ 用 POI 或中心点去判面状地物方位，结论极不稳定：
  实测某公园名义中心点距相邻两宫分界仅 0.59°；按东西跨度计，实际横跨三宫。
  ⇒ 报告若只写"某方位有公园"，属口径错误。
• ⚠️ 改名工程：公园/道路改名后，地图源常仍用旧名
  ⇒ 搜不到新名时一定要用旧名再搜一次。

§12 ★ 用户截图／测距截图的量化提取

问题：用户发来的地图截图常带手绘圈/线（黄圈、红框、蓝线）。目测读图误差可达数十像素，
据此推方位会系统性出错。

12.1 手绘标注：颜色掩膜 ＋ 连通域 ＋ 逐行扫描

1. 掩膜阈值（实践值，按实际截图微调）
   - 黄（手绘圈）　r>205 ∧ g>165 ∧ b<110 ∧ r−b>110 ∧ g−b>80
   - 红（手绘线）　r>190 ∧ g<95 ∧ b<95
   - 蓝（手绘线）　b>175 ∧ b−r>70 ∧ b−g>45 ∧ g>90
2. 连通域：4-邻域 BFS，输出 n / bbox / 质心，按面积排序；
   小圈（路名圈）与大地块框会自然分开。
3. 可视化再判读：① 掩膜叠加灰度底图 + 100 px 网格（既看形状又不被底图色干扰）；
   ② 掩膜独存（黄→白／红→红／蓝→蓝，黑底）——判形状用这张，比叠底图清楚得多。
4. 求走向角：对手绘长线逐行取 x 均值 → 最小二乘拟合 → 走向角。
   不要用 bbox 推走向（弯曲段会毁掉结果）。

★ 立刻做一次双源交叉验证：把图上拟合出的走向与 map 源的走向（路线 bbox 或折线）对比。
差 <1° ⇒ 同时坐实「底图正北朝上 + 手绘识别无误 + 路网旋转角」。
这一步花 1 分钟，能救掉后面所有推理。

实测：图上某路像素拟合 152.0° ↔ OSM extent 推算 151.4°，差 0.6°。

12.2 ★ 用「测距截图」直接定标（最优先的定标路径）

当用户能打开地图且会用测距工具时，这是成本最低、精度最高的定标方式
——优先于一切图像推算。

步骤：
1. 让用户在地图上用测距量一条长边（例如地块进深），截图。
2. 用颜色掩膜 + 连通域提取测距线两端。注意：⊗ 是「删除点」按钮，不是端点，
真正的端点是那个实心圆点；线体常因标注框／路口被截成两段，要按行拟合后取整体首尾。
3. 像素长 L ＝ hypot(Δx, Δy)；比例尺 s ＝ 实测米数 ÷ L。
4. 必做两项自洽性检验：
- 对角线检验：线的垂直分量 × s ÷ cos(线偏离正南的角度) 应 ≈ 标签读数；
- 体量检验：用 s 反算某已知地块的用地面积 → 推容积率 → 看是否落在合理区间
（实测：0.73 m/px → 4.9 万㎡ / 478 户 / 25F → 容积率 2.4 ✅；1.05 m/px → 0.85 ❌）。

⚠️ 掩膜阈值必须按实测色建：某测距线在深色卫星底图上呈暗橙（≈#CC6438），
用「亮橙」阈值（如 r>225、g>150）只会抓到字体或图标（实测仅 17 px）。
做法：先沿估计路径横向采样，取真色再建掩膜。

12.2a ★★ 测距／测面的标签体系（必须认全，否则配对必错）

配对方法（不要靠猜）：起点 的圆点必然落在某条折线的端点上；总长标签贴在该折线的
中点或端点外侧。把 起点位置 + 标签贴靠哪一端 两者对上，即可唯一确定「标值 ↔ 线段」。

12.2b ★★ 只有「多标签互证」才算锁定

• 每条标签给一个 s_i = 该线标值 ÷ 该线像素长（长度一律 hypot(Δx,Δy)）
• ≥3 组、且离散度 < 1% 时，才可宣布「尺度锁定」；只拿到 1 条标签
  ⇒ 仍属 §12.3 情形，不得给距离
• 实测：471／412／403 米三条长度各异、互不相关的测线，给出 s = 0.9563 / 0.9615 / 0.9607
  ⇒ s = 0.959 ± 0.003 m/px（离散 0.27%） ⇒ 锁定 ⇒ 一切净距/边长可给到米级
• 额外校验（有面积数据时必做）：用锁定后的 s 算出的「长 × 宽」与官方用地面积比 ——
  实测 412 × 230 = 94,760 ㎡ vs 官登 93,200.67 ㎡，差 1.7% ⇒ 互证通过

12.2c ★★ 比例尺不可跨图搬用

同一条实线在不同截图上的像素长不同 —— 这本身就是 zoom 差的探测器。
实测：同一条 412 m 线，前一张图 556 px、后一张图 428.5 px ⇒ zoom 差 1.297×。
⇒ 每换一张截图，必须在本图内重新定标。 把上一张的 s 直接拿来用，
误差会随 zoom 差线性放大（实测若混用，全部净距会错 30%）。

12.3 ★ 比例尺不可唯一确定律（结论纪律）

用图上多个已知长度反解比例尺；若得到互斥解，就必须停手，不得给距离。

实测案例：四个已知长度给出 0.75 / 1.02 / 1.24 / 1.48 m/px 四个互斥解。

⇒ 纪律：
- 图像法只用于「拓扑与方位」（谁在谁北边、是否共享同一条界路、走向角多少度）；
- 任何「净距 m 数」在闭合前不得写入结论栏；
- 闭合路径（成本从低到高）：① 用户在坐标拾取器点 2 点（最快、零成本、米级）；
② 商用地图 API（距离矩阵）；③ 现场实测；
- 不要把「该截图分辨率不够」说成「查不到」 —— 是源的天花板，不是方法的失败。

> ★ 修订：本条不是「永远定不了标」。当用户能在图上用测距工具并读出标签数值时，
> 比例尺可锁到 ±0.3%（见 §12.2a~c）。本条的适用面是：只有图、没有可信标值的场景。
> 一句话 —— 别在源的天花板下硬算，去把标值要回来。

§13 几何量纪律与配准坑

13.1 ★ 几何量纪律：不要把「跨度」当「长度」

踩过的坑：把一条斜线的 y 跨度（399 px）当成斜长（471 px），比例尺算大 18%
（1.24 vs 1.054），进而污染整条推理链。

规则：
- 线段长度一律 hypot(Δx, Δy)；
- 比较两个量前先确认定义一致（跨度 vs 长度、bbox 边长 vs 实际边长、投影长 vs 真长）；
- 旋转地块的 bbox 尺寸 ≠ 地块边长：bbox_w = a·|cosθ| + b·|sinθ|、bbox_h = a·|sinθ| + b·|cosθ|
（θ 为旋转角）。用 bbox 反推边长必须解这个方程组，不能直接划等号；
- 自检：若某比例尺在其它已知量上系统性偏差约同一倍数，多半是把投影量当成了真长。

13.2 ★ 折线测线与「总长」标签（血泪级）

症状：同一张图上，西／北两组测线的反算比例尺高度一致（离散 0.54%），
东／南两组却系统性偏低 2.0%。

根因：折线「总长」≠ 两端直线距离。
- 测距的「总长：XXX 米」是沿折线各段之和。若测线是一条多段折线（沿弯曲道路画），
用「两端直线像素长」反算 s 会偏高（实测 646.7px ⇒ 0.9820，+3.2%）。
- 但若用「各段像素之和 + 肉眼估缺口」反算，缺口估大则 s 偏低（实测 676.6px ⇒ 0.9385，−2.1%）。
- 真值必在两者之间。

操作规则（强制）：
1. 判折线：把测线连通域做主成分分析；若主轴解释方差低或点到主轴残差呈 S 形 ⇒ 是折线/弧线。
2. 直线口径定标：折线测线不得参与比例尺定标，或仅用其直线段部分定标。
3. 分层看互证：出现「一组一致、另一组系统性偏移」时，先查量测口径
（折线 vs 直线／含不含路口／端点是否被标签截断），再谈数据矛盾。
4. 街区四边是免费副产品（见 §13.4）。

13.3 ★ 走向异常即红旗

测线走向若偏离路网旋转角 > 3°，优先怀疑标签红边框污染 PCA 主轴，而不是地块本身倾斜：

• 实测「本盘西界」测线走向 145.3°，而路网旋转角 29.6°（某路 150.4°）⇒ 偏差 5.1°；
• 机理：标签红边框高光像素（红 r≈230 时 g 可能升至 70 以上）落入橙色掩膜，
  把主轴拉偏；
• 后果极重：若该线实为斜长而当作正南北进深使用，地块长宽比会由 1.2:1 误判为 1.8:1；
• 现场一眼可复核：① 看测线两端白色实心圆点是否落在同一路缘线上；
  ② 看该线是否与相邻道路视觉平行。

⇒ 定标完成后，必须对每一条参与定标的测线做一次「走向合理性检查」：
与同图同走向的其他道路线比较，偏差 > 3° 即列入待核，不得直接用于派生结论。

13.4 ★ 街区（block）四边量测法

锁死比例尺后，用四条围合道路的交点作为角点（而非测线端点），可直接得到整个街区的几何：

用法：① 用官登用地面积 ÷ 街区面积 校验量级；② 用角点定地块四至，比测线端点可靠
（测线端点常被标签截断）；③ 对边平行性可用于反查路网旋转角是否被误用。

13.5 已知「配准坑」清单（持续累积）

13.6 ★ 读图通道纪律：整图被「内容过滤」时，先裁小图

现象：把截图整张交给图像读取工具，返回 Content filtered。
错误结论：据此判定「本窗口无法目视、只能做像素分析」——于是长期只用掩膜／连通域推算。
这是重大误判。

实测结论：同一张图，裁成 < 900×900 的小图后即可正常读通（整图被滤、小图不滤）。

⇒ SOP：
1. 整图被过滤 ⇒ 立即裁块（四象限，每块带 30~40 px 重叠），再按需放大 2~3×；
2. 每块单独读取；优先读标签区、路口区、地名区；
3. 需要精确坐标时，在裁剪图上叠坐标网格（每 50 px 一条并标注原图坐标）——
这样从图上读到的位置可直接换算回原图像素；
4. ⇒ 凡遇整图被滤，一律先试裁块，不要宣布「看不到」。

代价对比（实测）：目视一张图（裁 4~6 块 + 读 11 个标签）约 6 次调用；
而此前「不目视、全靠推算」付出的代价是 —— 把单图尺度误当全局尺度、把「施工区」当红线范围、
净距连续两轮悬空。

读书纪律（配套）：一旦目视通道恢复，必须把此前所有「推断项」逐个目视复核并改写结论，
不得让推断稿与目视稿混在同一份判语里。

13.7 ★ 读图来源必须分层标注（图片 Read 会时好时坏）

同一张图，"看懂"有两条完全不同的路径，产出结论的可信度差一个等级：

• 图片 Read 可能返回内容过滤提示，也可能同一会话内一会儿好一会儿坏；
  历史上还出现过「工具日志与工作日志对同一批图记载相反」的情况。
• ⇒ 铁律：① 遇图先试 Read；② 不能读时用像素分析，但每一条结论都要标注"未目视"；
  ③ 两种来源的结论不得混写成一句话；④ 读图能力恢复后，
  把此前的"推断项"逐个回读复核，并在文档里改写结论，不要留下"推断稿"与"目视稿"并存的模糊地带。
• ⇒ 表格与文字只能靠目视；像素扫描只用于几何量测。用像素法"读"数字，迟早出错。

§13A OSM / Overpass 自主量测工作流（不依赖用户截图的独立通道）

> 背景：§12 依赖「用户截图 → 程序化读标 → 反算比例尺」。该通道有硬上限
> —— 比例尺只能从图上标值反解，无法独立验证标值本身。
> 必须同时具备一条「不依赖用户」的通道：直接取矢量数据，拿到真实米制长度。

13A.1 ★ Overpass 镜像可用性（实测）

调用方式（GET + urlencode，必须带浏览器 UA）：

import urllib.request, urllib.parse, json
UA = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
                    "(KHTML, like Gecko) Chrome/126.0 Safari/537.36", "Accept": "*/*"}
MIRROR = "https://maps.mail.ru/osm/tools/overpass/api/interpreter"
q = '[out:json][timeout:150];way["name"~"<路名A>|<路名B>"](<s>,<w>,<n>,<e>);out geom;'
url = MIRROR + "?" + urllib.parse.urlencode({"data": q})
req = urllib.request.Request(url, headers=UA)
j = json.loads(urllib.request.urlopen(req, timeout=180).read().decode("utf-8", "replace"))

13A.2 ★ 三条硬规则

1. 大 bbox 必 504。单次查询的 bbox 跨度 ≤ 0.03°×0.04°（约 3 km × 4 km）；
   更大范围必须切成 4 块（2×2）分次拉、然后合并。实测 0.06°×0.08° 直接 504。
2. 查询超时必须显式设为 150~180 s，且脚本总时长要大于默认 120 s 的 shell 超时，
   否则会被沙箱 SIGTERM 掐断（表现为 stdout 全空、exit 1、Signal SIGTERM）。
3. out geom; 而非 out body; —— 只有 geom 才会把节点经纬度内联返回，省掉二次请求。
4. ⚠️ out geom 会返回"整条 way 的完整几何"，不是"bbox 内那一段"
   —— 凡是量走向／长度，必须先按「与参考点距离」过滤路段（如只取中心 600 m 内的段），
   否则会把几公里外的弯道段混进来，得出互相矛盾的平均走向（2026-09-21 实测：未过滤时
   九峰一路"平均偏离 77°"，过滤后近场段实为 271.8°（近乎正东西））。
   > 本次教训的形态：同一条路的远场段与近场段走向不同，
   > 不做距离过滤就会同时得到"旋转 29°"和"旋转 0°"两个结论，无法裁定。
5. maps.mail.ru 镜像须放行自签根证书：urllib 直连会报
   SSL: CERTIFICATE_VERIFY_FAILED ... self-signed certificate in certificate chain。
   解法（只读公开 OSM 数据，可接受）：
   python import ssl ctx = ssl._create_unverified_context() urllib.request.urlopen(req, timeout=180, context=ctx)
6. 必须本地缓存原始响应（_*_cache.json）。镜像限流是常态（2026-09-21 连续两次 504，
   第三次才成功）；首次成功后立刻落盘，后续分析全部读缓存，
   否则一次限流就要重跑整条重活。同时给 2~3 次重试 + 镜像轮换。
7. 镜像状态会变：2026-09-17 记 overpass-api.de 为 406，2026-09-21 实测为 504。
   每次用前都要探一次，不要照抄历史结论。

13A.3 局部等距投影（足够精度，无需 pyproj）

LAT0, LON0 = <参考点>
def mlat(phi): return 111132.92 - 559.82*math.cos(2*phi) + 1.175*math.cos(4*phi)
def mlon(phi): return 111412.84*math.cos(phi) - 93.5*math.cos(3*phi)
MLAT, MLON = mlat(math.radians(LAT0)), mlon(math.radians(LAT0))
xy = lambda la, lo: ((lo-LON0)*MLON, (la-LAT0)*MLAT)

武汉纬度 30.5° 处：MLAT ≈ 110,861 m/°、MLON ≈ 96,004 m/°。km 级范围误差 << 0.1%。

13A.4 能取到什么、取不到什么

能取到（A 级硬数据）：
- 道路真实米制长度与走向（用于独立校验图上标值）
- 公园/地块/居住区多边形轮廓与面积
- POI 精确坐标与到本盘的距离、方位角

取不到：
- 新建项目本体 —— 新开发区域中，本案及近年报建的道路在 OSM 中完全空白；
- 红线、退让、容积率等规划指标（须回到政府公示源，见 §4–§6）。

⇒ 定位：OSM 是「周边环境的独立标尺」，不是「本项目档案的来源」。

13A.5 与「用户截图通道」的分工

⇒ 正确做法是「两条通道互证」：以 OSM 的真实米制长度去校验图上的标签读数，
把两套尺子对齐。任何一侧单独使用都不足以定案。

13A.6 升级路径

一旦要求"净距精确到米"或"必须给出八宫归属"，直接索要商用地图 API key
（高德/百度开放平台，免费额度足够），一次调用同时拿到
地址解析＋POI＋距离矩阵＋路网，比在 OSM 上反复试要快一个量级。
不要在没有 key 的情况下反复消耗 OSM 查询——那是源的天花板，不是方法的失败。

§14 输出规范

14.1 结论分层与来源标注

• 每条结论后面跟来源与日期；推定项明确标注"推定"。
• 有矛盾时不擅自改判，单列「矛盾／待核清单」，写明两侧证据与影响范围。
• 结论分三层：已闭合（坐标可复算） / 部分闭合（缺什么，给了区间）/ 待核（怎么写能闭）。
• 地图类结论必须写：源（Photon/OSM/商用 API）＋ 取数日期 ＋ 精度等级。
• 宁可写"该源在此片区精度不足，未能闭合"，也不要给一个看起来精确的错误坐标。

14.2 交叉校验纪律（务必遵守）

1. 任一关键数字至少两源互证；只有一源时标注可信度。
2. 三种可信度不可混用：政府源＝硬事实；平台源＝可校验参数；营销文案＝仅作线索。
3. 营销文案的"四至"自相矛盾是常态（同一页可能同时写"南至 A、北至 B"与"南至 B、北至 A"）
   → 只取多源一致者。
4. 平台录入的 GIS 坐标精度低，不可用于算距离（实测误差可达公里级）。
5. "改名工程"必须查沿革：一个项目更名后，旧名下的全部资料仍有效；
   不查沿革会把同一块地当两处。
6. 同名／近名陷阱：跨区同名项目 → 命中后必核对"工程地点"＋"报建编号前缀"。
7. 分期与总量别混：官方登记的"N 套"通常只含已取证的那一期；营销的"M 户"常是全盘。
   差额往往是另一期或配套用房。

14.3 四条高价值判读法

A. 立项文号批次关联 → 把"多源并发"从巧合升为排程可推算

拿到周边多个工程的立项文号后，按号段排序：连号或同号段的项目
⇒ 同批立项、同批招标，工期必然高度重叠。

• 实例：待核邻区西侧还建 〔2026〕51 号 × 南侧公园提升 〔2026〕53 号，
  同为一家建设单位实施、同一招标代理（项目二部）⇒ 二者工期重叠是制度性必然，不是运气。
• ⇒ 据此可直接告客户："交付那年，西侧与南侧一定同时在施工"——这是排程可推算，
  比"可能会施工"强一个量级。
• ⇒ 反查法：已知 A 项目的立项文号，可用同号段去搜同批的其余项目，
  往往能一次找出周边尚未公开的同期工程。

B. 「有无中标」的最快判定：招标投标穿透页

不必逐条翻交易平台列表。用企业招投标穿透页搜建设单位，直接看中标公司栏：

• 栏为空（-）＝ 尚未定标；有值才是已定标。
• 同页会并列"招标公告 / 资审结果 / 评标公示"多个批次，同日发布的多个标段一眼可见。
• ⚠️ 穿透页的"公告类型"字段可能把资审公告标成"资审结果"——
  只信"中标公司"是否为空，别信类型标签。

C. 术语的"行业惯用义" ≠ "字面义"——决定实体性质

同一名词在市政行业语境与外行字面义下，指代完全不同的实体，含义可以正好相反。

• 实例：「高压管廊」 —— 字面像"架空高压线路走廊"，但行业语境中
  "管廊"＝地下构筑物，"高压电力管廊"即地下电缆隧道（含高压电力舱）。
  ⇒ 架空＝有外露形煞／观感问题；埋地＝无外露形煞。一个词判反，结论反了。
• 判定方法：去查该新城/片区的综合管廊规划——官方档案通常明确写出
  布设路段清单与"拟建于道路绿化带下方"，并说明管廊断面（单舱/双舱/三舱，
  三舱含高压电力舱）与入廊电压等级。
• ⇒ 凡"廊/管廊/通道/走廊"类名词，先查该片区的专项规划，再下判断。

D. 面状地物（公园/绿地/园区）禁止单点定位

见 §11.4。要点：取四至/红线，按面宽给方位区间，说明"跨哪几宫、以哪宫为主"；
不同官方文件四至不一致时双说并记；改名后旧名也要搜一次。

14.4 图纸（总平面/规划图）判读五步法

> 适用于任何拿到的楼盘图纸（售楼处图、微信图、公示图、报建图）。

1. 先认这张图是谁的——用 3–4 条独立判据交叉：最高栋层数/高度、已知栋的层数、
   红线外相邻实体、特殊建筑（幼儿园/开闭所/商业）。
   （实测：最高栋 25F／79.70m ＋ 12#＝14F ＋ 11/18/19#＝18F ＋ 东侧红线外"公园绿地（G1）"
   → 四条同时命中，判定为本盘总平面）
2. 校准比例尺——不要靠感觉。找图上任一尺寸标注，量其像素长，得 px/m；
   随后反算用地面积与已知净用地比对，即可判断"这张图是整盘还是一期/局部"。
   （实测：≈3.1 px/m → ≈6.3 万㎡ ≈ 一期净用地 62,600.45㎡ → 判定此图只画一期）
3. 定方位——不要凭"图上方＝北"。用建筑长轴定：住宅长轴必为东西向（面宽朝南），
   若图上建筑长轴呈水平，则图的水平轴＝东西向；若呈竖直，说明图被旋转了 90°。
   再用红线外的不可移动实体（大公园、主干道、邻盘名）敲定南北与东西。
   ⚠️ 一张图里"平面位置"与"方位名称"冲突时，以实体为准。
4. 分块放大读小字——人眼读 1000px 宽的全图必然失真。做法：① 先给全图打 100px 网格并标坐标；
   ② 按网格分块裁切 ×8~16 倍放大读；③ 只对待读标签再单独极限放大。
   文字仍模糊时，不要猜，标为"待核"。
5. 编号体系先分类再使用——一张图上往往混着住宅编号与配套编号。
   用编号推断分期/栋数前，必须先辨"这一栋是住宅还是配套"，
   否则会把"20# 配套房"错当"第 20 栋住宅"。

§15 自检清单（交付前必过）

• [ ] 三层源是否都铺过？是否明确标注了每条的可信度层级？
• [ ] 是否找到了分局公示栏这一层级？（而非止步于区政务网）
• [ ] 最新一版文件的"已批准……实施情况"表是否已抽取？
• [ ] 每个"未获批/未开工"结论，是否都用同系列后续文件复核过？
• [ ] "调整方案"与原方案的三条一致性判据是否都验过？
• [ ] 官方业务系统检索是否用了报建登记名/地址（而非销售案名）？
• [ ] 列表页数据是否逐条解析 (名称, 链接) 配对（而非按位置硬编码）？
• [ ] 明细级数据是否与独立来源交叉验证过？（"合计对得上"不算）
• [ ] 所有中文参数是否按站点编码处理齐了？（漏一个整批不可信）
• [ ] 几何类结论的比例尺是否 ≥3 组标签互证？是否每图重新定标？
• [ ] 参与定标的测线是否做过走向合理性检查（与路网旋转角偏差 ≤3°）？
• [ ] 用 POI 算方位/净距前，是否送过 reverse 验伪并做了三分法归类？
• [ ] 面状地物是否按区间给方位（而非单点）？
• [ ] 读图结论是否标注了「已目视确认」/「像素推断，未目视」？
• [ ] 订正后是否做了全产物残留扫描，命中数为 0？
• [ ] 二手线索是否已回官方源坐实、并标注了证据等级？

§16 附：实战路径示例

楼盘名
 → ① 房产平台取"备案名＋预售证号＋备案均价＋去化节奏"
 → ② 用备案名(不是案名！)去商品房查询系统取官方销售底账
 → ③ 用报建编号去交易平台取"招标／评标／中标＋计划工期"
 → ④ 用项目编码去建筑市场一体化平台取"四至＋GIS＋参建单位＋施工许可"
 → ⑤ 用聚合源取"建设周期"
 → ⑥ 用地图 POI 取周边实体方位（先 reverse 验伪）
 → ⑦ 交叉校验后输出

> 关键提醒：官方系统用"报建登记名"，不是销售案名。用案名检索必然落空
> —— 这是最常见的空手而归原因。

实战案例（来源）

案例一 · 状态订正（2026-09-15）
为某住宅项目做周边核证时，依据某版成片开发方案的自述"尚未有方案获批"，
判定其未获批并写入 3 份报告；当晚从新一版方案的表 2 查到：
该方案经调整后已获批、已完成征收 97.30%；全区 5 个方案全景一并获得。
由此修正了"未来 5–10 年片区施工"的远期判断，改为
"土地整理已完成，风险转为已征地块建设施工窗口"。
修复：3 份产物 / 6 处锚点 / 旧表述残留 0。

案例二 · 明细配对错误（2026-09-15）
某栋表按位置硬配对名称与链接 ID，导致除第一栋外全部栋的明细张冠李戴，
误报某栋 0%（实为 44.1%）、某栋 0%（实为 75.0%，实际最佳）。
而合计值恰好是对的，所以总量自洽校验通不过。修复：改逐条正则解析配对。

案例三 · POI 验伪（2026-09-17）
某档案用 POI 算出某邻盘在"西北 297°"，reverse 后其最近地物是另一条主干道与两座公园
——该 POI 压根不在那个楼盘上；现场地图显示该盘项目部恰在马路另一侧。
⇒ 作废由该 POI 派生的全部方位与距离。

§17 与相邻技能的分工

常见误用与常见问题（FAQ）

常见误用（反模式）

常见问题

• Q：查「是否已完工／通车／投用」该信哪个源？ A：一律以现场观察或移交／开通公告为准，工期链只作背景；无法现场时须写「按期应已完成」，不得写成「已完成」。
• Q：市局栏目是空壳页（实测仅 653 B）怎么办？ A：不要以为没有 —— 真实内容常在分局栏目。
• Q：官方业务系统列表页的顺序能直接用吗？ A：部分可靠 —— 「名称」与「链接」的顺序不保证一致，必须逐条解析配对（铁律六）。
• Q：只有单一来源的数字能用吗？ A：不得当结论用，只能标注可信度；关键数字至少两源互证。
• Q：抓不到数据，是页面上没有吗？ A：先排查编码 —— .NET 站点参数须为 UTF-8，漏编码一个参数会导致所有字段空壳（极易误判成「页面没数据」）。
• Q：三种来源可以混着用吗？ A：不可混用 —— 政府源＝硬事实；平台源＝可校验参数；营销文案＝仅作线索。

附：融合说明

本技能由四个来源技能融合而成（2026-09-18）：

融合时做的合并与去重：
- 两个来源各写了一遍"与相邻 skill 的分工"（互指同一段边界）⇒ 合并为本技能 §1 ＋ §17 各一处，不再重复。
- "面状地物禁止单点定位"原在两个来源各写一遍 ⇒ 合并至 §11.4，§14.3 D 仅留指针。
- "列表页名称与链接顺序不同步"原在总纲与铁律六各写一遍 ⇒ 合并至铁律六，título统一为跨站点通用形式。
- "OSM 精度不足"与"平台录入 GIS 坐标精度低"原分处两地 ⇒ 统一进 §9 底图说明与 §14.2 第 4 条。
- 新增：§0 三条铁律、§1 链路分工图、§15 自检清单（16 项）、§16 实战路径与三案例——把散落的"教训"提级为可执行的门禁。