MS RFC 97：动态创建更高缩放级别的平铺

日期

2013／04／15

作者

托马斯堡

联系方式

thomas.bonfort@gmail.com

状态

采用

版本

MAPCACHE 1.2

1。概述

在平铺栅格数据时，原始数据的本机分辨率通常比标准GoogleMapsCompatible或WGS84网格的较高缩放级别的分辨率低一些/远一些。要求以高分辨率提供低分辨率数据的用户目前被迫使用以下方法之一：

  • 在其tileset中设置一个<grid maxzoom=“15”>attribute，这意味着高于最大配置的缩放级别的所有缩放级别都被视为不可用。然后只能通过WMS调用获得用于更高缩放级别的升幅图块或图像，图块请求将失败。

  • 不设置maxzoom参数，因此在所有缩放级别缓存所有图块，这在mapcache实例上的存储和最初在将图像拆分为图块之前请求图像时在原始WMS服务器上设置的负载方面效率低下。

此RFC建议为给定的tileset和给定的网格添加“最大缓存级别”的概念。在实践中，高于配置的最大缓存级别的图块仍透明地可供最终用户使用，或在垂直合并多个图块时使用，但它们是从最大缓存级别动态上标的，而不是缓存在mapcache实例上（从源WMS服务请求一次后）。

2。建议的解决方案

为了可用于所有平铺操作，请 mapcache_tileset_tile_get 函数将检测超过最大缓存级别的调用，并返回到负责处理此特殊情况的新函数。此“超过最大缓存缩放”方案将提供两种配置：

  • 通过以下方式从较低的缩放级别重建请求的平铺：

    • 确定最大缓存的一个或四个磁贴，使请求的磁贴的范围感兴趣。

    • 调用 mapcache_tileset_tile_get 再一次，这次（x，y，z）调整为z=max缓存级别（以避免无限递归）。

    • 解码下部缩放级别图块的图像数据。

    • 将解码后的图像数据升迁到最终的图块中。

    • 向上缩放的图像数据不会立即编码，因为此功能的一个常见使用案例是覆盖多个平铺集时（即，将发生对原始像素数据的访问）。

  • 将请求的tile代理到源WMS服务器，从而完全绕过mapcache的缓存机制（这在最初不会实现）：

    • 构造图块的范围，最终说明元缓冲区（但不是元图块大小）。

    • 发送到源WMS。

    • 如果使用元缓冲区或请求的图块是多个图块集的垂直组合，则最终解码数据。

对于tileset引用的每个网格，在配置文件中激活此功能：

<tileset>
  <!-- ... -->
  <grid max-cached-zoom="12" out-of-zoom-strategy="reassemble">WGS84</grid>
  <grid max-cached-zoom="12" out-of-zoom-strategy="proxy">g</grid> <!-- not implemented -->
  <!-- ... -->
</tileset>

三。实施细节

将添加两个新函数，并通过向上缩放较低级别的图块或直接查询源WMS来生成图块的图像。他们将从 mapcache_tileset_tile_get() 当在配置文件中请求这样的行为时。

3.1受影响的文件

  • mapcache.h

  • configuration_xml.c

  • tileset.c

  • mapcache_seed.c

3.2向后兼容性问题

不需要，新功能

3.3性能影响

当向上缩放图块时，每个图块请求将意味着至少一个图像解压缩和一个图像压缩，以及对图像数据进行双线性重采样。因此，服务向上采样的切片将比直接从缓存服务它们慢几个数量级。

应该可以为希望以降低输出质量为代价获得更好性能的用户停用双线性重采样。如果需要的话，这可以在后面的阶段解决。

3.4条警告

  • 双线性重采样在pixman内部失败，无法达到极端的重采样比例（即，当请求的图块在最大缓存缩放图块中仅跨越几个像素时）。参见https://bugs.freedesktop.org/show_bug.cgi？ID=46277对于这些情况，我们切换到最近的邻居重新采样，即将切片设置为统一的颜色。

  • 双线性重采样将在最大缓存缩放图块的边缘产生轻微可见的伪影。这是因为需要相邻切片的数据来生成无缝的升级版本。

5.错误ID

6。投票历史

托马斯布、斯蒂芬、米克斯、汤克、杰夫姆、丹尼尔、佩里恩和史蒂文