carto-territory-planning

区域规划（区域均衡 + 位置分配）

构建 CARTO 工作流，以解决两个相关的空间优化问题：将区域划分为均衡的区域（例如销售区域、服务区），以及寻找可最大化覆盖范围或最小化成本的最优设施位置。

前提条件：加载 carto-create-workflow，了解开发流程、JSON 结构和验证方式。该指南涵盖两种访问路径——连接 MCP 服务时使用其工作流工具（create_workflow、validate_workflow、run_workflow），否则使用 carto workflows CLI。路由信号：carto-basics/references/access-paths.md。两个组件都要求连接上已安装 Territory Planning Extension Package。

---

区域均衡

将研究区域划分为在空间上连续、并按需求变量（例如工作量、人口、收入）保持均衡的区域。

流程

Source Data (points) -> Spatial Indexing -> Aggregate per Cell -> Territory Balancing -> Save

步骤 1：加载源数据

使用 native.gettablebyname。输入通常为点数据，其中包含一个或多个要用于均衡的数值指标。

成功标准：节点输出包含几何列和数值指标列的表。

步骤 2：转换为空间索引

使用 native.h3frompoint（或 native.quadbinfromgeopoint）将每个点分配到一个网格单元。

分辨率指导：分辨率越高，网格单元越小，区域划分越精细，但计算量也越大。城市级分析通常使用 H3 分辨率 8-9。

成功标准：输出包含空间索引列（例如 h3）。

步骤 3：按网格单元聚合

使用 native.groupby，按网格单元生成一行，并包含要均衡的指标：

• 分组依据：空间索引列（h3）
• 聚合方式：例如 geom,count,revenue,sum,population,avg

成功标准：每个网格单元对应一行，包含需求数值列，以及可选的相似性特征。

步骤 4：运行区域均衡

使用 native.territorybalancing，并设置：

输入	说明	示例
input_table	表输入（来自上一步）
index_column	H3 或 Quadbin 列	h3
demand_column	要在各区域间均衡的数值列	geom_count
similarity_feats	用于衡量区域内部相似性的可选数值列	["sentiment_avg", "popularity_avg"]
npartitions	要创建的区域数量	9
keep_input_columns	在输出中包含所有输入列	true

成功标准：输出包含所有输入行，并额外包含区域分配列。每个网格单元恰好分配到一个区域。

步骤 5：保存

使用 native.saveastable 持久化结果。空间索引列可直接在 CARTO Builder 中可视化，并按区域 ID 着色。

成功标准：经过验证的工作流可通过 create_workflow（MCP）或 carto workflows create（CLI）上传。

---

位置分配

寻找候选设施位置的最优子集，以最大化需求覆盖范围，或最小化总成本/距离。

流程

Demand Data (grid/points) -> Candidate Locations -> Location Allocation -> Save

步骤 1：加载需求数据

使用 native.gettablebyname 加载表示需求的网格或点数据集（例如每个 H3 网格单元的人口、客户位置）。

成功标准：表中包含空间索引列和需求数值列。

步骤 2：加载候选位置

使用第二个 native.gettablebyname 加载潜在设施位置（例如现有基础设施、候选地点）。

如果需要筛选候选项，可使用 native.wheresimplified 或 native.limit 缩小集合——候选项越少，计算速度越快。

成功标准：表中包含表示候选地点的空间索引列。

步骤 3：运行位置分配

根据目标选择相应的变体：

最大化覆盖率

使用 native.locallocallocation_maximizecoverage：

输入	说明	示例
demand	包含需求值的表
demand_index_column	需求表中的空间索引列	h3
demand_column	数值型需求变量	population
candidates	包含候选位置的表
candidates_index_column	候选位置表中的空间索引列	h3
nfacilities	要开设的设施数量	5
coverageradius	最大服务距离（地理类型的单位为米）	5000

成功：输出会指出要开设哪些设施，以及每个设施服务哪些需求单元，从而在半径范围内最大化总覆盖需求。

最小化总成本

使用 native.locallocallocation_minimizetotalcost。输入与最大化覆盖率相同，但不包含 coverageradius ——目标是总加权出行距离，而非半径范围内的覆盖率。

成功：输出会指出要开设哪些设施，并最小化需求与分配到的设施之间的总加权出行距离。

步骤 4：保存

使用 native.saveastable 保存结果。

成功：经过验证的工作流可通过 create_workflow（MCP）或 carto workflows create（CLI）上传。

---

注意事项

• 提供商的大小写规则和 SQL 方言。 此技能使用小写列名（h3、geom_count、population、sentiment_avg 等），遵循 BigQuery / Databricks / Postgres / Redshift 的惯例。在 Snowflake 中，未加引号的标识符会显示为大写——请将其写作 H3、GEOM_COUNT、POPULATION、SENTIMENT_AVG。有关大小写规则和 SQL 方言的对应形式，请参阅 carto-create-workflow/references/providers/<provider>.md。
• 需要扩展包：地域均衡和位置分配都要求在所用的特定连接上安装 Territory Planning Extension Package。此扩展包默认不可用，用户必须自行安装。如果缺少该扩展包，验证将失败。
• 候选位置较多时，位置分配的计算开销较大。按地理区域、容量或其他条件预筛选候选位置，以缩小候选集。数百个候选位置可能导致运行缓慢；数千个候选位置则可能超时。
• 覆盖半径的单位取决于空间参考系统——使用 geography 类型时，通常以米为单位。请确认单位符合预期。
• 地域均衡会在空间连续性与均衡性之间进行权衡。无法保证完全均衡——各地域的需求变量大致相等，但不会完全相等。
• 网格分辨率敏感性：输入网格的分辨率会显著影响结果。更精细的网格能提供更精准的边界，但会增加计算量。城市尺度分析可从 H3 分辨率 8 开始，再根据需要调整。
• 组件名称使用 native.territorybalancing（“territory balancing”中没有点分隔符）以及 native.locallocallocation_maximizecoverage / native.locallocallocation_minimizetotalcost（注意前缀中的 “local” 重复了两次）。
• 需求数据必须覆盖研究区域。需求网格中的空缺区域对优化器而言不可见。如需完整覆盖，请使用 polyfill + COALESCE(value, 0)。

---

参考模板

Academy 教程

• 区域平衡教程 —— 分步讲解米兰 POS 用例
• 位置分配教程 —— 使用位置分配管理电信网络
• AI Agent + 位置分配 —— 使用 AI Agent 和位置分配来确定应急响应中心的位置

---

常见变体

变体	方法
销售区域平衡	点 -> H3 -> 按网格聚合收入 -> 将收入作为需求进行区域平衡
服务区设计	使用人口数据创建网格 -> 进行区域平衡，创建人口均等的区域
仓库/配送中心选址	使用人口网格作为需求 + 现有仓库作为候选地点 -> 最小化总成本
应急响应中心选址	使用人口网格作为需求 + 候选地点 -> 通过响应时间半径最大化覆盖范围
零售网络扩张	使用客户密度网格作为需求 + 潜在门店位置 -> 最大化覆盖范围
区域平衡 + 位置分配组合	先运行位置分配以选出中心位置，再运行区域平衡，将区域分配给各个中心