MS RFC 71:MapServer项目中mod geocache的集成¶
- 日期
2011／05／20
- 作者
托马斯堡
- 联系
t在Terriscope DOT FR的端口
- 状态
采用
- 版本
MAPServer 7
说明：此RFC建议集成 mod-geocache 在MapServer项目中。
1。概述¶
Mod-Geocache 是一种最新的磁贴缓存解决方案，它在WMS服务器前面以Apache模块或FastCGI可执行文件的形式运行。它可以连接到任何与WMS兼容的服务器，但是考虑到它的源代码语言和核心开发人员的根，将其与MapServer项目紧密集成、简化最终用户的配置以及通过更大的开发团队提供更高的质量保证是有意义的。
1.1对磁贴缓存解决方案的需求¶
Web映射的使用模式在过去几年中不断发展，并且越来越多地基于图像分片的预生成，而不是直接从源数据创建图像。
当前提供地图贴片的解决方案包括TileCache、MapProxy和GeoWebCache，这些解决方案成功地完成了任务，但不能与MapServer项目完美集成：
它们不运行本机代码，这会导致较小的性能开销，并且在高性能数据传播的环境中可能会带来不便。
它们不与代理服务器共享其配置，因此需要用户复制配置变量和元数据。
对于python服务器，它们需要一个额外的组件来运行（mod python、mod wsgi或fastcgi包装器），这在非主流平台上配置起来很麻烦。对于需要访问本机代码的请求（特别是与图像格式编码和解码相关的请求），gil也是多线程服务器的瓶颈。
NIH；）正如它可以用C语言写的那样，为什么不直接使用它呢？
1.2 mod geocache项目¶
mod geocache是最近的一个项目（2010年10月），根据Apache许可证分发。它是用纯C语言编写的，使用半面向对象的体系结构（大量使用结构继承和函数指针）。它主要以作为Apache模块运行为目标，在处理HTTP请求的进程内以本机代码运行非常快（在CGI进程创建或FastCGI IPC中没有开销）。
其功能列表包括：
服务WMS、WMT、TMS、VirtualEarth/Bing和谷歌地图请求
能够通过合并缓存中的数据块或将其转发到WMS源来响应未命名的WMS请求
响应WMS/WMTS GetFeatureInfo请求（转发到源服务）
KML超覆层生成
WMS后端提供的数据（计划的GDAL支持源）
实验性memcached缓存
可配置的元平铺，具有进程间/线程间锁定和同步，以避免在尚未播种平铺时使源WMS过载。
将多个图块合并为单个图像的动态图块合并
从后端到达时的图像后处理（重新压缩和量化）
解释并生成缓存控制头：最后一次修改，如果修改自，则过期
多线程种子设定实用程序
能够在存储的瓷砖上添加自定义水印
可以生成一个fastcgi可执行文件，用于Apache以外的其他Web服务器
可配置的空白磁贴符号链接以获得磁盘存储
可配置的错误报告：纯HTTP错误代码、文本消息或空（空白）图像
能够指定要转发到WMS后端的供应商参数或维度（并构建考虑这些参数的缓存）
基于规则的将非平铺请求代理到（一个）其他服务器，例如用于WFS、WFS-T等…
1.3集成概述¶
mod geocache将被修改为从提供的映射文件读取其配置，而不是像现在这样读取其自己的XML文件。当与mapserver和tinyows一起使用时，它将充当这些服务器的代理：如果传入请求对应于可以从缓存提供服务的soemting，则它将充当经典的tile服务器，否则它将把请求代理到mapserver或tinyows（或任何其他符合ogc的服务器）。
2。治理¶
2.1查找名称¶
“mod geocache”作为一个名称是一个糟糕的选择，应该在与mapserver集成期间进行更改。对于解决方案的命名，作者没有预先定义的概念，我们将非常感谢您的想法。
2.2释放周期¶
mod geocache是最近的一个项目，它正在以与mapserver发布周期不兼容的速度进行开发。因此，mod geocache的发布周期将首先与mapserver 1分离：mod geocache的发布将在mapserver发布的任何时候生成，但如果需要，也将以更快的速度生成。
2.3源代码位置¶
mod geocache代码将位于mapserver存储库的子目录中，例如trunk/mapserver/mod geocache
2.4 RFC和决策过程¶
在集成的早期步骤中，与MapServer盛行的基于RFC的决策相比，围绕与MapServer项目无关的mod geocache核心的开发将以轻松的方式进行。
所有对mod geocache核心的重要更改将在mapserver dev邮件列表上公布供讨论，但除非与实际的mapserver功能直接交互，否则不会进行RFC投票过程。
一旦集成的过渡阶段完成，mod geocache的开发将遵循传统的基于RFC的决策。
2.5许可证¶
mod geocache的apache许可证将切换到与mapserver相同的许可证。
2.6张票¶
mod geocache托管在谷歌代码上，并使用其集成的问题跟踪系统。创建mod geocache的专用组件后，将使用mapserver trac实例。
当前没有要转换到MapServer Trac的打开的Bug。打开的功能增强将手动迁移到MapServer Trac实例。
2.7 VSN导入¶
mod geocache主干将导入mapserver svn。
以前的提交历史将在旧的Google代码SVN上保留一段时间。
3作为配置文件的通用映射文件¶
3.1 libmapfile应用程序接口¶
libmapfile API将从mapserver源树中创建，并且需要对头文件和源文件进行一些重构。不应更改MapServer API本身，因为重构主要涉及将一些函数和声明移到单独的文件中。
3.2配置指令¶
必须将新的关键字和/或元数据添加到MapServer解析器中。配置关键字的确切语法和范围必须作为此RFC注释期间的一部分进行讨论。
由于配置指令相当广泛，因此必须在易于语法和与实际mapserver关键字相似性之间找到一个折衷方案。
3.3文件¶
mod geocache文档相当稀疏，基本上由注释配置文件组成。必须努力将文档添加到主MapServer Doc站点，并从Google代码托管迁移几个wiki页面。
第四章。代码审查¶
4.1代码起点¶
所有的C代码都是我和SteveWoodbridge从头开始编写的，所以不应该是真正的问题。基于libpng/libjpeg的图像IO功能受到了mapserver中相同功能的极大启发，可以在第二阶段合并在一起。
4.2代码质量¶
类似于mapserver。
4.3安全审计¶
没有对代码执行外部安全审核。作为一个可能接收不受信任数据的Apache模块运行，在编写代码时，安全性一直是一个问题，但我不是安全专家。
4.4外部依赖¶
libcurl（必需）
apr（必需）/apr util（可选）
libpng（必需）
libjpeg（必需）
PCRE（可选）
OGR（用于播种机，可选）
libcairo（可选，用于服务从缓存的tiles生成的getmap请求）
FastCGI（可选）
4.5构建系统¶
像mapserver这样的mod geocache使用autoconf（不使用automake）和makefiles来构建东西。
4.6知识产权和专利概述¶
专利审查留给来自专利制度不健全国家的用户作为练习；
5。投票历史¶
2011年8月19日，Steve L.、Steve W.、Tamas、Dan、Howard、Assefa、Thomas和Tom通过了+1。