该WebMapTiler似乎很慢，即使没有扇出。所以，我决定采用建议的方法@takashi。现在我已经得到了在FME这个工作和我能够生成砖的下一级（例如9）从以前的水平（例如10）如下：
- 使用PythonCaller计算下一级别瓦片x和y的索引位置和图像偏移量;
- 测试是否存在每个得到新的x和y索引4个源瓦片;
- 如果存在小于4个瓦片 - 空白图像被以0创建覆盖4块（即是1024×1024）用相同的X和Y瓦片索引;
- 所有现有的瓦片offet使用Offsetter（否则他们将彼此叠加）;
- 现有的砖和砖空白（参见图3）通过RasterMosaicker放，分组上的瓦片索引并指定“最大”重叠值。这确保了真正的原单瓦覆盖的任何空白瓷砖。
- 将得到的新的块被使用RasterResampler到所需的图像尺寸（512×512）重新采样。
- 数据集扇出用于创建TMS的目录结构（即
\ ）文件名设置为y索引。
这个过程需要几分钟的时间来运行，并将所得瓦水平已经在单张的被测试是很好的工作。
非常感谢@takashi的提示！
有趣的是在工作台的瓶颈不是参照。如果我删除/禁用WebMapTiler和引导来自RasterMosaicker的直接输出到作家得到一个单一的形象，这样就完成了分钟。我怀疑的问题是，在与扇出的表情，我认为这是导致FME持有大量栅格的内存组合WebMapTiler。
谢谢@takashi，这是非常有用的。我会看看我们是否能在小叶不同的分辨率与minNativeZoom和maxNativeZoom选项只是起到了瓷砖。
有趣的是它没有地理参考导致性能问题，因为工作台在分钟运行一次，如果我地理参考，然后用RasterMosiacker创建一个单一的形象。这绝对是WebMapTiler，我怀疑是与对作家的扇出，以获得正确的目录结构。它消耗了大量的内存，这表明它在写之前保持在内存中的瓷砖。
你好@ john_gis4busine我猜测，地理参考过程可能是瓶颈中的表现。
如果在缩放级别10中的每个源块的瓦片索引（X，Y）是已知的，就可以计算出瓦片索引为缩放级别9或8，将它们适当地移动而不地理参照，然后它们镶嵌通过新瓦片索引分组。
例如，你可以算出缩放级别9的与这些数学表达式tile索引。假设（XN，YN）表示缩放级别N.瓦指数
X9 = @floor（×10/2）= Y9 @floor（Y10 / 2）
接下来，抵消了Offsetter原来的512 * 512的图像。
X偏移：512 *（×10％2）Y偏移：-512 *（Y10％2）
然后，您可以镶嵌其中每个组（X9，Y9）的，并在必要时终于修改与RasterResampler分辨率。
请注意，在缩放级别9的新平铺图像应在缩放级别10的由4个原始图像。你将不得不增加供应缺少的部分，如果一个新的形象将不会与原始图像完全充满的过程。
顺便说一句，你还可以指定选项参数的minNativeZoom'，“maxNativeZoom”和“tileSize”到小叶瓷砖层宾语。根据不同的情况，它可能不是必要创建一个新的瓷砖数据集。
tileLayer = L.tileLayer（
，{minzoom:8，maxzoom:10，minnativezoom:10，maxnativezoom:10，tilesize:512}）；