企业官网建设流程全解析

简介：这份PDF资料围绕倾斜摄影数据处理与发布全流程展开，面向测绘、GIS、三维建模及智慧城市相关从业者与学习者，帮助解决OSGB数据从拿到手到Web端展示的落地难题。资源包共1个PDF文件，大小约1.79MB，内容以图文步骤形式组织，便于按章节查阅。资料从倾斜摄影数据介绍切入，讲解CC软件生产的OSGB组织格式，解析s3c工程文件、Data根目录与metadata.xml中ENU坐标系及EPSG编码的读取方式；随后覆盖SuperMap iDesktop生成配置文件、加载浏览、倾斜入库与瓦片边长判断、s3m单文件大小控制，以及基于iServer和MongoDB瓦片的服务发布与Web浏览。目前已有773人学习，适合需要打通倾斜摄影数据入库、优化与发布链路的技术人员参考。

1. 倾斜摄影数据处理和发布流程：从一堆 OSGB 瓦片到能点开就看的服务

你拿到手的原始成果，大概率是一个几十 GB 的文件夹，里面全是 OSGB 瓦片、一个 metadata.xml，外加几张不知道干什么用的缩略图。甲方说「给我一个能在线看的链接」，而你的机器上只有 SuperMap iServer 和一个还没装好的 MongoDB。这就是倾斜摄影数据处理和发布流程最真实的起点：数据是死的，服务是活的，中间隔着格式转换、坐标系对齐、瓦片重建、数据库挂载四道坎。

这套流程解决的核心问题是：把无人机或大飞机采集的空三成果，变成浏览器里能流畅漫游的三维场景服务。适合谁？做测绘交付、智慧城市底座、三维 GIS 开发的一线人员。你不需要懂摄影测量平差，但必须清楚 OSGB 怎么进、服务怎么出。下面按我实际交付过的方式，把每一步拆开讲。

2. 先搞懂 OSGB 到底装了什么：数据组织与坐标系确认

2.1 OSGB 的目录结构不是随便摆的

OSGB 是 OpenSceneGraph 的二进制场景格式，倾斜摄影建模软件（ContextCapture、大疆智图、重建大师等）输出时，会按金字塔层级组织。典型结构长这样：

Data/ ├── metadata.xml ├── Production_1/ │ ├── Data/ │ │ ├── Tile_+000_+000/ │ │ │ ├── Tile_+000_+000.osgb │ │ │ ├── Tile_+000_+000_L20_00.osgb │ │ │ └── ... │ │ └── Tile_+001_+000/ │ └── ...

metadata.xml里藏着最关键的信息：SRS（空间参考系）、中心点坐标、瓦片划分规则。很多人翻车就翻在直接拿 OSGB 去发布，结果模型飘到海里去了——因为 OSGB 内部顶点坐标是局部坐标，必须靠 metadata 里的偏移量还原到真实地理坐标。

常见做法是先用文本编辑器打开 metadata.xml，确认三件事：SRS是不是 EPSG:4326 或你项目要求的投影坐标系；SRSOrigin的偏移值；瓦片命名规则里的层级数。这三项对不上，后面全白干。

2.2 坐标系不统一，后面全是玄学

倾斜摄影原始成果常见两种坐标系：WGS84 地理坐标（EPSG:4326）和项目地方投影坐标（如 CGCS2000 高斯投影）。SuperMap iServer 发布三维服务时，默认按数据自带 SRS 处理，但前端加载底图如果是 Web 墨卡托，就会出现模型和底图错位。

我一般会做一次显式转换：如果原始是 4326，而底图用 3857，就在数据处理阶段统一转成 3857 再生成缓存。转换工具用 SuperMap iDesktop 的「投影转换」功能，或者用 GDAL 命令行：

# 将 OSGB 的 metadata 坐标系从 4326 转为 3857（示意，实际需配套转换工具） gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857 # 输入经纬度，输出墨卡托坐标，用于校验偏移量

参数说明：-s_srs是源坐标系，-t_srs是目标坐标系。注意 OSGB 本身不能直接被 GDAL 转换，这里只是校验坐标偏移量，真正的转换要在建模软件或 iDesktop 里做。

提示：坐标系确认这一步，宁可多花半小时核对，也不要等发布完发现模型和底图差几百米再返工。

3. 用 SuperMap iDesktop 把 OSGB 接进来：配置、生成缓存、避坑

3.1 新建三维场景并加载 OSGB 图层

打开 SuperMap iDesktop，新建一个文件型数据源（.udbx），然后新建球面场景。在「图层管理器」右键「添加三维图层」→「OSGB 模型」，选择 metadata.xml 所在目录。iDesktop 会自动读取瓦片层级和偏移。

关键参数在「图层属性」里：

加载后如果模型显示为一片黑或者只有轮廓，多半是显卡驱动或 OSGB 纹理路径问题。先检查纹理图片是否和 osgb 在同一目录，再确认 iDesktop 的「场景」→「属性」里开启了纹理显示。

3.2 生成三维缓存：参数决定加载速度

OSGB 直接发布也能用，但瓦片数量大时前端加载会卡。标准做法是生成 S3M 缓存。在 iDesktop 里右键数据集或图层 →「生成三维缓存」，弹出参数面板：

缓存类型：S3M 瓦片边长：128 或 256（默认 128，模型精细选 256） 纹理压缩：WebP 或 DXT LOD 层级：根据原始 OSGB 层级自动，一般 0-18 线程数：CPU 核数的一半

瓦片边长 128 适合大多数场景，256 会减少瓦片数量但单块体积变大。纹理压缩选 WebP 能在画质和体积间取得平衡，DXT 兼容性更好但体积大。生成过程中如果卡在某个层级不动，检查磁盘剩余空间——S3M 缓存体积通常是原始 OSGB 的 1.2 到 1.5 倍。

生成完成后，在缓存目录下会看到.s3mb文件和config配置文件。这个 config 就是后面 iServer 发布时要指向的东西。

3.3 发布前必须检查的三个点

第一，缓存目录里不能有中文路径，iServer 在 Linux 下对中文路径支持不稳定。第二，确认config里的srs字段和场景坐标系一致。第三，如果原始 OSGB 有 LOD 层级缺失，生成的缓存会出现空洞，需要在 iDesktop 里先做「模型修补」再生成。

我踩过最深的坑是：OSGB 瓦片命名里带+号，在 Linux 下被 shell 当成特殊字符，导致 iServer 读取失败。解决办法是批量重命名，把+换成_，同时更新 metadata 里的引用。

4. iServer 发布三维服务：MongoDB 挂载与切片存储

4.1 为什么发布三维服务要挂 MongoDB

SuperMap iServer 发布 S3M 三维服务时，切片元数据和索引默认存在本地文件里。但生产环境通常要求多节点共享切片，或者切片数量超过百万级，本地文件系统扛不住。这时候就要用 MongoDB 存切片。

MongoDB 在这里的角色是「切片仓库」：每个瓦片的二进制数据存成一个文档，_id用瓦片行列号和层级拼成，查询时按_id范围扫描。常见做法是单独部署一个 MongoDB 实例，不和业务库混用。

安装 MongoDB 在 Linux 上最稳的方式是用官方 apt 源：

# 导入 MongoDB 公钥 wget -qO - https://www.mongodb.org/static/pgp/server-6.0.asc | sudo apt-key add - # 添加源（以 Ubuntu 20.04 为例） echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/6.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list # 安装 sudo apt-get update sudo apt-get install -y mongodb-org # 启动 sudo systemctl start mongod sudo systemctl enable mongod

参数说明：mongodb-org是元包，包含 server、shell、tools。安装后默认端口 27017，配置文件在/etc/mongod.conf。如果启动失败，先看/var/log/mongodb/mongod.log，八成是数据目录权限问题。

注意：MongoDB 默认没有认证，生产环境必须开启security.authorization: enabled并创建管理员用户。别等被扫了才后悔。

4.2 iServer 里配置 MongoDB 切片存储

登录 iServer 管理页面，进入「服务管理」→「三维服务」→「切片存储配置」。选择「MongoDB 存储」，填写：

保存后，iServer 会把后续生成的切片写入 MongoDB。已有本地切片可以通过「迁移」功能导入。迁移时注意：切片数量大时分批导入，每批不超过 50 万，否则 MongoDB 的 oplog 会爆。

4.3 发布 S3M 服务并验证

在 iServer 里「快速发布」→ 选择「三维服务」→ 数据来源选「S3M 缓存」→ 指向 iDesktop 生成的 config 文件。发布后得到服务地址，形如：

http://<iserver-ip>:8090/iserver/services/3D-CacheName/rest/realspace

验证方法：用 iServer 自带的「三维场景预览」打开，如果模型正常显示且能旋转缩放，说明发布成功。再用浏览器开发者工具看 Network，确认.s3mb请求返回 200 且 Content-Type 是application/octet-stream。

如果预览空白，先看 iServer 日志logs/iserver.log，常见错误是「S3M 缓存版本不匹配」——iDesktop 和 iServer 版本差一个大版本就会这样，统一版本即可。

5. 避坑与排查：OSGB 转 S3M 和 MongoDB 挂载的 5 个血泪记录

5.1 现象：模型加载后位置偏移几百米

原因：metadata.xml 里的SRSOrigin偏移量在转换过程中丢失，或者 iDesktop 场景坐标系设成了地理坐标但数据是投影坐标。

解决：在 iDesktop 里重新加载 OSGB 时，手动指定坐标系，并在「图层属性」里核对偏移值。如果偏移量已知，可以在场景属性里手动填入。

5.2 现象：MongoDB 安装后启动失败，日志报 Permission denied

原因：/var/lib/mongodb和/var/log/mongodb目录属主不是mongodb用户，常见于手动解压安装或从其他机器拷贝数据目录。

解决：

sudo chown -R mongodb:mongodb /var/lib/mongodb sudo chown -R mongodb:mongodb /var/log/mongodb sudo systemctl restart mongod

5.3 现象：iServer 发布时提示「无法连接 MongoDB」

原因：MongoDB 开启了认证但 iServer 配置里没填用户名密码，或者填了但用户没有对应数据库的读写权限。

解决：在 MongoDB 里创建业务用户并授权：

use s3m_cache db.createUser({ user: "iserver", pwd: "your_password", roles: [{ role: "readWrite", db: "s3m_cache" }] })

然后在 iServer 配置里填同样的用户名密码。

5.4 现象：S3M 缓存生成到一半报磁盘空间不足

原因：S3M 缓存体积比原始 OSGB 大，且生成过程中会产生临时文件。很多人按原始数据大小预留空间，结果不够。

解决：预留至少原始 OSGB 体积的 2 倍空间。如果已经生成一半，可以清理临时目录后重新生成，iDesktop 支持断点续传。

5.5 现象：前端加载三维服务时瓦片请求 404

原因：iServer 的切片存储配置指向了 MongoDB，但实际切片还在本地文件里，没有迁移。

解决：在 iServer 管理页面执行「切片迁移」，或者重新生成缓存时直接指定 MongoDB 存储。迁移后核对 MongoDB 里的文档数量是否和本地文件数量一致。

6. 进阶：用 MongoDB 查询语句直接校验切片完整性

发布完成后，怎么确认切片真的全了？不用一个个点，直接查 MongoDB。

// 切换到切片数据库 use s3m_cache // 统计总瓦片数 db.tile_s3m.countDocuments() // 按层级统计，检查是否有层级缺失 db.tile_s3m.aggregate([ { $group: { _id: "$level", count: { $sum: 1 } } }, { $sort: { _id: 1 } } ]) // 查询某一层级某一范围的行列号，确认无空洞 db.tile_s3m.find({ level: 10, row: { $gte: 100, $lte: 200 }, col: { $gte: 100, $lte: 200 } }).count()

逻辑说明：countDocuments()给出总量，和 iDesktop 生成的瓦片总数对比。aggregate按level分组，正常情况层级应该是连续的，如果中间缺了某一层，说明生成时中断过。第三个查询用来抽查局部区域，如果数量明显少于理论值（行数×列数），说明有空洞。

参数说明：level、row、col是切片文档的字段名，不同 iServer 版本可能略有差异，先用db.tile_s3m.findOne()看一条文档结构再改查询条件。

我一般还会加一个校验：把 MongoDB 里的_id导出成列表，和 iDesktop 缓存目录下的文件名列表做 diff。如果两边完全一致，说明迁移无损。这个习惯帮我省过好几次返工——有一次迁移到 90% 时网络断了，diff 一下立刻定位到缺失的层级。

最后一个习惯：每次发布完，用手机 4G 网络打开服务地址，模拟真实弱网环境。如果 4G 下能流畅加载，局域网内肯定没问题。这个动作花不了两分钟，但能提前暴露瓦片过大、LOD 不合理的问题。希望帮到你。

本文还有配套的精品资源，点击获取