倾斜摄影OSGB转3DTiles报错Code:134？内存与并发排查

2026年10月14日 20:32

报错说的是现象，不是病因，先按固定顺序找那道可观察的信号

先给结论。OSGB 转 3DTiles 时蹦出 Code:134 或类似的中断，绝大多数不是格式本身有问题，而是任务跑到某个阶段时资源不够了：内存被耗尽、磁盘写不进、并发放得太高，或者输入数据在某一块本身就有缺口。这类报错指向的是现象，不是病因。省时间的做法是照一个固定顺序往下排查，每一步找一个可观察的信号，命中即停。本文给出一份这样的顺序，并说清楚什么时候该停止重试。

1 先看清楚报错说的是什么

134 这个数字本身信息量有限，它多半是进程被系统或运行环境强制结束之后留下的退出码，而不是某条业务逻辑明确抛出的错误。换句话说，它更像一句"这里出事了"，而不是"这里因为什么出事了"。把注意力全放在数字上，容易走进死胡同。

真正有用的是同一份数据配合的三个信息：中断发生在整体进度的哪个位置、中断那一刻机器的资源占用是什么样、换一个更小的输入范围能不能复现。这三条凑在一起，才能把"随机事件"和"确定性缺陷"分开。前者多半是资源与环境，后者多半在数据里。

一个可以先用起来的判断：如果同一份、同一范围的数据连续两次都在相近位置中断，问题大概率是确定性的，改配置没用，得回头查数据或资源上限；如果两次中断位置不同，那更像是资源抖动或外部干扰，值得从运行环境这一侧找。

2 第一顺序：内存与并发

这一类是最常见的成因，也是优先排查的。典型表现是任务能顺利跑一阵，进度条走过一段之后才中断，而不是一上来就退出。

1）内存峰值被顶满：处理到后段时占用持续爬升，机器开始换页，随后进程被结束

2）并发设置偏高：同时展开的线程或子任务过多，瞬时占用抬高，反而拖慢甚至压垮任务

3）同时跑了别的重负载程序：浏览器、三维软件、同步盘都会来分内存

4）输入范围一次给得太大：单个任务要吃掉的数据量超出机器上限

观察信号很直接：在失败前盯一下任务管理器的内存曲线。如果它是缓慢爬升然后在某一刻触顶，问题基本锁定在内存或并发。对应的动作是先把并发调低、关掉无关重负载程序，再用更小的输入范围试一次。注意方向，降并发通常比加内存更快见效，也更可控。

3 第二顺序：磁盘空间与权限

资源类问题里，磁盘这一项经常被忽略，因为提示常常被读成"文件不存在"，实际却是"写不进去"。

1）输出分区写满：大范围数据的中间产物与成品叠加，把盘写爆

2）临时目录空间不足：系统临时空间不足，中间文件无法落盘

3）输出目录没有写权限：目录属主或权限设置限制写入

4）目标盘是网络盘或移动盘：网络抖动、断连会让写入在关键时刻中断

判断方法：先看输出分区和系统临时目录还剩多少空间，再看输出目录能不能正常新建文件。如果换到一个本机、空间充足、全英文短路径的目录做小规模试切能过，问题就锁定在空间或权限，而不是模型本身。

4 第三顺序：路径、命名与输入完整性

前面两类都排除了，再来查这一层。它属于确定性缺陷，改资源没用，得回到数据或路径上修。

1）路径含中文、空格或过深层级：部分环节对路径字符敏感

2）文件名含特殊符号或过长：读取阶段偶发失败

3）OSGB 目录结构不完整：Data 目录有缺层或缺块，读到缺口就中断

4）贴图缺失或损坏：几何在、贴图打不开，处理到纹理阶段报错

5）坐标信息缺失或异常：原点为空、坐标系未定义，或平移值明显越界

这一步的关键是"最小复现"：拿一小块结构完整的数据试切，能过说明是范围或路径问题；同一小块也失败，就要逐层检查输入目录的完整性。涉及数据本身的缺口，反复重跑没有意义，必须先补数据再切。

5 末位确认：版本与已知问题

前三层都干净了，再看工具侧。这一步放在最后，是因为它命中率不高，但排查成本最低。

1）先确认用的是不是最新版本：已知问题往往在后续版本里被修掉

2）核对版本号与运行环境：系统版本、是否虚拟机、显卡驱动是否满足要求

3）检索是否已有同类讨论：同一种中断，别人可能已经踩过并且有了结论

4）区分你的现象与讨论帖里的现象：条件不同，结论未必通用

这里要提醒一句，社区里已经存在不少关于转换中断的讨论帖，先检索再提问，常常能把方向提前定下来。站内可以先从 在文档社区检索同类报错讨论 入手，把版本号、报错码和中断阶段一起作为关键词，命中率会高很多。

6 停下重试的判断：什么时候该放弃

排查的意义之一，是知道什么时候不该继续。下面这几种情况，值得直接停下来。

1）同一范围稳定复现、位置一致：确定性缺陷，重跑无用，先修数据或调上限

2）输入目录存在缺块或贴图损坏：属于数据问题，必须回到生产环节

3）降并发、腾空间、换短路径之后仍在同一位置中断：需要升级硬件或拆分任务

4）报错信息与已知问题吻合且已有修复版本：直接换版本，别在旧版本上耗

5）数据涉密、敏感或未公开：不得为排查把原始数据上传到任何公共渠道

反过来，只有确认为外部中断，比如系统休眠、他人抢占、网络存储抖动、会话过期，才适合直接重跑。把重试当成第一反应，往往只是把一次失败重复一遍。想先确认每一步在界面上的落点，可以参考 倾斜模型切片图文教程，对照着走一遍再动手排查。

7 求助时该带上的现场信息

真到自己定位不了，把下面这些信息一并提供，比单说一句跑失败了有效得多。

1）完整报错文字与报错码，以及发生的大致阶段

2）数据规模：目录层级、大致文件数量、最大单文件体积

3）失败前那一刻的内存与磁盘占用

4）输出路径的写法，以及所在磁盘的类型

5）工具版本号与运行环境（系统版本、是否虚拟机）

6）是否可稳定复现，以及最小复现所用的数据范围

需要说明的是，本文的顺序不能保证解决所有中断，成因有时是叠加的，比如数据缺口与内存不足同时存在。若按顺序仍无法定位，或数据本身涉密、敏感，请勿把原始数据发到公共渠道，只提供不含敏感信息的报错与规模描述即可。规范层面的细节由 OGC 3D Tiles 标准页 定义，理解它能帮你判断输出结构是否正常，但它不解释运行环境这一侧的中断。

常见问题（FAQ）

FAQ-1 报错码一样，是不是就不用查了，直接按网上的方案改？

不建议。同一个报错码往往对应多种成因，网上的方案多半只覆盖其中一种。稳妥做法是先确认你的现象与前人描述是否在同一条件下：中断阶段、数据规模、版本、资源占用是否接近。条件不同，结论未必通用。先用自己的数据把范围缩小，再决定采信哪一条。

FAQ-2 降了并发还是中断，是不是必须换机器？

先看是内存还是磁盘顶到上限。内存问题除了降并发，还可以拆小输入范围分段处理；磁盘问题则是腾空间或换分区。只有在拆小范围、腾出空间后仍在相近位置失败，才需要考虑更高配置或更大内存的机器。判断前先记录失败前的资源曲线，避免盲目加硬件。

FAQ-3 数据涉密，出问题能把原始数据发给官方看吗？

不可以。涉密、敏感或未公开的测绘成果不得进入公网，也不应上传到任何公共渠道。正确做法是自行完成本文的顺序排查，只把不含敏感信息的报错文字、规模描述、资源曲线和版本环境提供出来；确需协助时，按所在单位的成果管理规定走内部流程，用脱敏样例复现。

FAQ-4 社区里已经有人问过同样的问题，还有必要再确认版本吗？

有必要，但顺序可以调。先检索讨论能帮你快速锁定方向，再去确认版本是不是最新、已知问题是否已在后续版本修复。检索与换版本两步都很便宜，通常放在排查的前面。若讨论帖的结论与你的现象不符，再回到本文的内存、磁盘、路径、数据四层顺序逐层排除。

排查到最后如果仍不确定，可以 下载 GISBox 用最新版本复测，用一小块数据把链路先跑通，再回到大范围任务。

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