个人作品集
地形、周边环境、可达性三模块量化评分；YAML 可配置规则；Python 管线与 FastAPI 服务、B 端表单与 Agent Copilot 闭环。
用一句话说：把「这块地/这个营地作为露营地是否合适、好在哪里、短板在哪里」从主观感受，尽量变成可重复计算的分数字段，并保留「给人看的解释」这一层（叙述可由 LLM 根据分数与规则生成，需自行配置模型接口）。
为什么值得做成工程：露营选址同时涉及安全（坡度、排水）、体验（景观、安静程度 proxy）、经营（到城市与补给的时间）。单一地图目测很难在多候选地之间公平比较；把规则写进 YAML、把计算放进管线，才能版本化、对比实验、团队协作。
请在页脚填写你的姓名、邮箱与 GitHub 链接（占位符已标注）。
空间侧以 Shapefile + DEM 为主；地形统计与部分空间处理依赖 ArcGIS Pro / ArcPy（与 API 进程分离，避免把重型 GIS 绑在 Web 服务进程里）。
评分与路径侧以 Python（geopandas 等） 为主；规则配置为 YAML；对外服务为 FastAPI；浏览器侧为轻量静态页；对话式操作为自研 Agent（计划、缺参追问、确认后执行、状态轮询）。
下面各节先给结论式说明，需要时再点开灰色折叠块看指标名、接口名、仓库路径。若你只想看产品价值，读完「项目摘要」和「指标体系」即可；若你关心实现，请继续看「工程实现」与「数据与工具」。
把「分数」理解成多道选择题加权：每一维（例如坡度是否过陡）在规则表里对应档位与分值，再加权合成模块分与总分。地图与遥感数据只是用来客观量那些档位的输入。
关注「输入要准备什么」「输出能进什么报告」「谁能自助跑一遍」。B 端页支持上传地块与触发管线；Agent 适合用自然语言发起「跑全流程 + 解读误差」类任务（仍需后端与密钥环境）。
看模块边界：api/app.py 注册模块与路由；code/ 为可脚本化步骤；Evaluation_System/*.yaml 为单一事实来源的阈值与权重；docs/选址评估/ 为与规则对齐的说明文档。
在多个露营地或候选地块之间做比较时，常见痛点是：每人心中标准不同、现场踏勘成本高、难以把「离高速远不远」「坡陡不陡」「离水边太近是否风险」等说法对齐到同一套量纲。
本项目目标：给定统一的空间与配置输入，输出可复现的分项得分与总分，并可选生成文字解读（叙述层依赖 LLM，与量化层解耦）。
规则与文档：Evaluation_System/*.yaml（计分阈值与权重）、docs/选址评估/（指标体系与公式说明，和 YAML 对齐）。
运行结果：各模块评分 CSV、管线 JSON 摘要等，默认落在仓库 Result/ 下（体积大，作品集页不打包分发）。工程侧另有 FastAPI 与两个轻量 HTML 界面（对话 + B 端表单）。
若仓库已公开，建议把下列路径换成你的 GitHub「浏览」链接，方便访客直接点开 Markdown。
docs/选址评估/05_指标体系总览与宏观权重.mddocs/API_Contract_Draft.mdapi/README.md宏观权重（文档口径）：地形 0.40、周边环境 0.30、可达性 0.30。含义是：安全与场地本身（地形 + 周边自然风险/景观）略重于「好不好到达」，但三者都不可忽略——缺一块就很难支撑完整选址结论。
回答「营位好不好扎、雨水怎么走、有没有过陡坡、朝向是否舒适」等问题。输入主要来自 DEM 与营区几何，在 GIS 里做分区统计后，再进 YAML 打分。
与 ArcPy 衔接：地形表一般在桌面 GIS 流程里生成；API 机器需单独配置 ArcGIS Python 解释器路径，避免把整个 Pro 绑进 Web 进程。
高程维：核心区高程的均值、极差、类型多样性、主体海拔占比等，用来区分「是否在适宜海拔带、是否起伏过于剧烈」。
坡度维：平均坡度、最大坡度、高分位坡度（如 90% 分位）反映「大部分场地是否可活动 / 极端点是否危险」；坡度标准差与极差反映起伏是否杂乱（影响排水与工程）；另有综合规则刻画积水/排水风险。
坡向维：把坡向归类到东南西北等方位档，映射到舒适度与日照经验分值（具体映射见文档，不在此页重复数字）。
回答「离水体多远是否安全」「植被覆盖大致如何」「从营地往外看，山水林田的可见比例」——后一类用约 2 km 视域内的可见比例作「景观丰富度」的 proxy。
这些指标把「感觉风景好」拆成可比的几个比例，便于多地块横向对比，也便于在文档里写清为什么高分/低分。
回答「小车能不能方便进出」「上高速/进城区大概多久」「局部路网质量如何」。既看宏观衔接（如最近高速出口的路径距离），也看周边 3 km 道路等级与高程起伏，还看多方向到城市/区县的路径时间与拥堵占比等。
多方向批量路径通常依赖第三方路径规划 API；生产环境必须把密钥放在服务器环境变量中，作品集与公开仓库均不得展示。
完整阈值、公式与字段名以 docs/选址评估/06_07_08_*.md 与 Evaluation_System/ 为准。公开展示请勿粘贴 .env、密钥或完整内部业务表。
整体思路是：浏览器与 Agent 只负责编排与展示，真正重的计算（尤其 ArcPy）以子进程或脚本方式执行，结果写回磁盘上的标准目录（如 Result/），API 再读回 JSON/CSV 返回前端或 LLM。这样便于排错、加超时、换机器跑地形。
提供健康检查、创建一次「运行」、按阶段调用注册表里的模块脚本、拉取运行摘要与产物路径等。模块键包括地形、环境、可达性、误差分析、边界优化、飞书报告等（以 MODULE_REGISTRY 与 README 为准）。
对外还有一组 Agent 端点：先做「计划」——理解自然语言、对齐到内部任务、列出缺参；用户确认后再「执行」；长任务用「状态」接口轮询进度。
普通 REST 往往一次请求一次结果；这里管线可能跑很久（尤其地形），因此需要 run_id、日志尾部、失败时的可读 hints（例如本机未安装 ArcPy 时的提示）。Agent 层再把「该调哪个 run、缺哪些文件路径」从对话里收敛成结构化请求，降低误操作。
Agent Copilot（/chat-ui）：面向「用自然语言驱动管线 + 要解读」的使用方式，适合内部熟练用户或演示。
B 端选址评估（/b/site-assessment-ui）：面向「有 SHP、要一步步上传、触发管线、再生成叙述」的表单流；上传会落在会话目录，量化结果可粘贴 JSON 或由服务端管线生成后再走叙述接口。
对话入口适合探索式任务与多轮补参；表单入口适合固定审计流程、培训新人、以及「同一套字段每次都要填」的 B 端场景。二者背后可复用同一套 API 与结果目录约定。
正在检测是否与 MTG API 同源（GET /health）…
以下链接与当前站点同源，需已执行 python api/run_server.py。
未检测到同源 MTG API（GET /health 不可用）。静态托管下无法直接打开上述 UI；请在本地克隆仓库后安装依赖并启动服务，再访问本页于同源下的 /portfolio/。
pip install -r api/requirements.txt
python api/run_server.py详见 api/README.md 与 portfolio/README.md。
除「评分核心」外，仓库里还有一批围绕真实工作流的脚本：拉 POI、批路径、坐标统一、把结果推送到文档平台等。它们不是摆设，而是为了让「从公开数据到可跑输入」这段路也能重复跑。
用于 POI 检索、驾车路径批量请求、营地周边餐饮/设施距离分层等。适合作为「运营与配套」分析的输入，与核心选址 YAML 解耦；调用前必须在环境变量中配置平台密钥，且不得提交到 Git。
国内常见发布数据为 GCJ-02（国测偏转），与国际或本地 DEM/WGS 混用时需要统一。仓库提供 GCJ-02 与 WGS84 互转的小模块，供 CSV 与地图数据对齐，避免「看起来在同一位置、实际偏几百米」。
code/run_pipeline_gen2.py 一类入口把地形、环境、可达性、误差分析等步骤串成一次可复现运行；各步输入输出路径在文档与配置草案中有约定。误差与敏感性脚本用于回答「边界挪一点分变多少」「误差从哪来」——对科研或甲方汇报同样重要。
MTG_ARCGIS_PYTHON 指向 Pro 自带解释器；Web API 是否用普通 Python 启动（不要把 Pro 的 python 当 uvicorn 入口）。