ARTICLE · 1234263
村组合并要不要做成插件功能?
村组合并要不要做成插件功能?· 业 务 讨 论 | D I S C U S S I O N · 村组合并 要不要做成插件功能？ 乡镇撤并 · 行政村合并 · 村民小组合并你那边，遇到过吗？ 🌿 这篇不发版本，想和一线聊聊一件事 📢 征求意见 有个功能，我们一直在犹豫要不要做——乡镇、村、组三级合并的批量化处理。 做，是因为现场确实在遇到；犹豫，是因为它不像出图那样每个项目都要用。所以这次先把场景和两种做法摆出来，由你们来定。 SCENARIO 先看场景 延包之前，先遇上一轮区划调整 二轮延包周期长，中间撞上行政区划调整很常见。数据还是老底子，组织形式已经变了。 乡镇撤并 两个乡镇并成一个，两套延包数据要合到一起。行政区代码、乡级界线、汇总口径，全得跟着走。 行政村合并 「合村并居」之后，A 村并进 B 村。发包方改名，承包方归属重挂，村界要重新接边。 村民小组合并 组是最细的一级，也是动得最频繁的一级。组合并后，地块、承包方、合同里的组别都要重新对应。 CURRENT WAY 现在是怎么干的 能做，但做不快，也说不清 现在的通行做法是：属性库维护 + 编辑器里手工改。四件事绕不开： ❗ 属性一条条改 —— 行政区代码、名称、发包方名称，靠人工核对，漏一条就前后对不上。 ❗ 界线要重新处理 —— 村界、组界融合，碎面、悬挂点、悬挂线，得逐个清。 ❗ 归属跟着变 —— 承包方、合同、台账里的层级关系，要一层层重挂。 ❗ 过程没留痕 —— 改完只留下一个最终结果，谁改的、改了哪些，事后说不清。 💡 最容易被卡住的不是改数据，是汇交时代码和名称对不上被退回——重新核一遍，等于白干。 COMPARE 两种做法摆一起 ① 属性改写 现状：逐条改，改完靠人工抽查插件：选定合并范围，一次批量改写 ② 界线处理 现状：编辑器里手工融合、逐处清碎面插件：按合并关系自动融合，输出干净边界 ③ 归属调整 现状：逐户确认后再改，量大容易错插件：按空间关系归并，改完可核对 ④ 过程留痕 现状：只有结果，没有过程插件：合并动作记入调整台账，可追溯 差别不在能不能做，在做得有多放心 OUR VIEW 我们的判断 不急着做，先看三个条件 ① 频率 —— 一年碰不到一次的，通用工具够用，不值得单独做模块。 ② 规模 —— 一个县整片推进、涉及几十个村几百个组，手工改的风险已经超过开发成本。 ③ 交付要求 —— 汇交要核代码与名称一致性、归档要留痕的，手工做法最容易在这一步翻车。 三条里中了两条，我们认为就该做成插件。只遇到一次的话，建议还是手工处理——为偶发需求做模块，成本最后会摊到所有用户身上。 VOTE 你来定（参与投票） 🗳️ LAST WORDS 💬 写在最后 工具箱里已经有地块分割、地块合并、交换、转让这些"动地块"的功能，唯独"动组织"这一层还空着。 要不要补上，不该由我们拍板。你觉得需要，就留言说一声；觉得不需要，也欢迎说说你是怎么解决的——有时候一个好用的操作习惯，比一个模块更值钱。 智测二轮延包工具箱 · 持续迭代中
