给城市数字化与三维团队：底座不是一次性模型，先把范围、分层和更新方式定下来。

城市底座和普通展示模型不一样。它要长期用，还会不断更新，一开始的结构没搭好，后面每加一片都要返工。

底座最怕两件事：范围反复变，编码各写各的。前者让模型拼不上，后者让平台挂不上数据。

下面按底盘范围、场景生成、结构组织和交付检查四段说明，末段讲三维场景能接住哪一环，哪些仍要测绘和平台团队完成。

把底盘、分层和编码先定下来，后面扩片和更新才有共同规则，不用每次重新商量。

1 城市底座先定哪三件事

1.1 底盘范围与基准

先定底盘覆盖哪些片区，边界按行政区、街区还是项目范围。三种口径混用，后面统计和拼接都会乱。

坐标系统和高程基准统一，写进项目说明。不同来源的数据直接拼，位置会差出一截。

底盘的精度目标按用途定。展示、比对和管理对细节要求不同，一开始就说清，别做到一半再改。片区之间的接边范围单独列，拼接时按同一基准。底盘的面积不需要精确到平方米，口径一致更重要。底盘范围变更要走确认，不能建模中途自行扩大。底盘的边界线要闭合，缺口会让面积统计出错。底盘范围外的邻近片区也留一圈，接边时不至于断开。

1.2 对象分层与用途

底座按建筑、道路、地形、水系、绿地和地下管线分层。图层结构决定后续能不能单独更新。

每类对象服务什么用途，提前说明。道路既要看走向又要看宽度，表达方式就不一样。

哪些对象必须精细、哪些可以简化，列成清单。全部精细，底座会重到无法日常使用。哪些对象要挂属性，提前和平台团队对一遍。地下管线是否纳入底座，按平台需求决定。用途变化时重新评估分层，别在原结构上硬加。对象清单和图层结构要能互相查，别各说各的。属性字段先定最小集合，后面再扩。

2 底座底盘怎么生成

2.1 地形水系与建筑

地形按可用资料搭，水系按岸线描。两者是底盘骨架，位置不对，建筑和道路都会跟着偏。

建筑轮廓按影像识别后人工检查。屋顶加建、连廊和临时棚容易被误判，重点片区要逐街核。

建筑高度按层数或测绘资料定，注明来源。两种来源混用，天际线和视线分析都会失真。地形来源不同时，先在接边处校核高程。建筑密度高的片区，识别结果逐栋核一遍。地形精度不足的片区，在说明里单独标注。影像时间不同的片区，建筑状态要注明日期。地形接边处的高差要平顺，突然断开会很显眼。

2.2 道路绿地与边界

道路按等级和宽度画，交叉口和桥隧单独标。只画中心线，看不出通行能力，也接不上交通数据。

绿地按乔木、灌木和草坪分区。全部铺成一片，遮挡关系和空间层次都出不来。

片区边界和接边位置标清楚。相邻片区拼进来时，道路和河道要能接上，不能各画各的。桥隧和立交按结构形式标，视距和限高由专业核。水系按常水位和汛期水位分别标，用途不同。道路交叉口的转向关系标出来，后面接交通数据用得上。道路和绿地的边界重叠时，先定归属再画。绿地里的水面单独成层，别和草坪混在一起。

3 底座怎么组织成可维护的结构

3.1 图层树与编码

图层树按片区、类型和版本组织，层级不要超过三层。太深了，平台侧不好用，维护也容易出错。

对象编码统一规则，比如片区代码加类型码加序号。编码不统一，后面挂数据和更新都对不上。

重点对象单独编码，方便单独替换。地标建筑和重要设施，不应混在普通建筑层里。编码里不要带日期，版本另设字段管理。图层颜色只做区分，不要当成正式制图标准。图层命名不用缩写，平台侧和业务部门都要看得懂。片区代码和行政代码对应，统计时能直接汇总。编码规则写成一页说明，新成员照着用。

3.2 更新与替换机制

明确哪些对象按季度更新、哪些按项目更新。全部实时更新不现实，频率要按用途定。

替换流程写清楚：新数据怎么进、旧对象怎么退、版本怎么记。没有流程，更新几次图层就乱了。

更新后的检查和回滚方式也要有。新版本出问题，能退回上一版，不至于影响使用。更新频率按对象类型分，建筑和管线不必同步。替换对象时保留原编码，避免平台数据断链。更新记录里写清数据来源和负责人。回滚版本至少保留一版，别只留最新。更新前备份旧版，替换失败还能恢复。

如果要把城市底盘的图层和更新规则先对齐，可以查看造形家官网的场景生成与编辑说明，先看范围与编码，再逐项检查交付。

4 底座交付前查什么

4.1 对象完整与命名

按清单核对建筑、道路、水系和绿地数量。数量对不上，先查是漏建还是重复。

命名规则逐层抽查。编码、片区名和类型要能对应，不能只看文件名叫得对。

重点对象逐个确认位置和高度。底座是参照物，重点对象偏了，后面所有分析都不可信。漏建最常出现在临时建筑和围墙，抽查时重点看。重复对象也要查，复制粘贴最容易留下重名。对象数量按图层统计，不要只报一个总数。重点对象的高度和层数对一遍，差得多的标出来。命名检查用脚本跑一遍，人工抽查容易漏。

4.2 坐标版本与说明

导出前核对坐标原点、单位和朝向。平台接入时，这三项最常出问题。

版本号和日期写进文件名与说明文档。多个片区并行时，版本混乱最难排查。

说明文档写清数据来源、精度限制和未覆盖部分。接收方知道哪些能用、哪些还要补。说明文档里附一张坐标系示意图，接入时少问。交付前在目标平台打开一次，位置和层级都要看。说明文档和场景文件放在同一目录，交接时不丢。版本号按日期加序号，避免同一天多版混淆。交付时附一份联系人清单，后续更新能找到人。说明文档更新后同步版本号，别只改正文。

5 三维底座能接哪几环

5.1 城市底盘场景生成

造形家官网展示了地图框选生成三维场地模型、AI 识别建筑轮廓高度和类型、生成地形水体和植被等能力，也支持图层化预览、编辑和管理。

城市底盘可以按片区框选，建筑、道路、地形、水体和绿地一起带入，底座不用从空白场景开始搭。

建筑类型、位置、旋转和高度可以调整，识别结果能人工修正。重点片区可以单独加密处理。

地形和水系分层显示，河道、坡地和低洼区更容易看清。底盘骨架在场景里能直接核对。

图层化预览和编辑让各类对象分开管理。按片区拼接时，接边位置的问题更容易发现。

几个片区可以分别生成，再拼成完整底盘。道路、河道和绿地的接边关系，放在一起看更清楚。底盘里的建筑、道路和水系共用一套坐标，扩片时直接接着摆。

测绘精度、平台性能和数据治理不在场景里判断。场景只解决底盘的生成与编辑，不替代测绘验收。

整理完可以导出通用 GLB，接到 ArcGIS、GISBox、Blender 或山海鲸可视化继续用。

5.2 导出与平台交接

导出前按平台要求核对格式、单位、坐标原点和图层结构。少一项，平台侧就要重新处理。

接入测试至少覆盖打开、定位和图层开关。只看截图，发现不了坐标和层级问题。交付的场景按片区和图层分开存放，后续替换只动一小块。

平台侧的数据绑定和功能开发不在造形家范围内。底座交付清楚，后续工作才有基础。

这类场景适合城市底盘搭建和分期扩展，造形家不承担测绘验收与平台运维。边界写进说明文档。

6 把城市底座搭成能长期维护的底图

6.1 底盘先定

底盘先定。范围、坐标和高程基准统一，后面拼接和统计才有共同基础。

6.2 类型分层

对象分层。建筑、道路、地形、水系和绿地各自成层，更新时不用整份重做。

6.3 编码统一

编码统一。片区、类型和序号按规则编，平台挂数据和替换对象才对得上。

6.4 交付前核

交付前查。数量、命名、位置和坐标逐项核，重点对象偏差要单独说明。

6.5 版本随替换

版本随更新。每次替换留编号和日期，出问题能回滚，也能追溯改了什么。

FAQ：常见问题

FAQ-1 没有全市测绘数据怎么起步？

可以先按重点片区做底盘，用影像和公开地形搭骨架，注明精度限制。后续扩片时沿用同一套坐标和编码，不要每个片区各定一套。

FAQ-2 底座能直接支撑平台吗？

可以作为三维底图接入，但平台还需要数据绑定、功能开发和性能优化。底座交付前先做接入测试，确认格式、坐标和图层结构可用。

FAQ-3 底座更新由谁负责？

通常在项目启动时约定。三维团队负责模型更新，平台团队负责数据接入，业务部门负责确认变化。责任不清，更新几次就会乱。

需要把底盘场景、图层清单和版本记录整理成一套，可以查看造形家官网的场景生成与编辑说明，按片区归档后再交给平台团队。

【内容与技术说明】
本文由造形家产品团队整理发布，内容由AI工具辅助生成并经团队人工核验。
因产品版本持续迭代，具体功能、参数与免费范围以造形家官方文档为准。
如有技术疑问或内容勘误，欢迎通过support@shapezo.com反馈。
最后核校：【2026-10-26】。