MS RFC 70:MapServer项目中Tinyows的集成

日期

2011/04/14

作者

奥利维尔库廷

联系

Oslandia.com网站的Olivier Dot Courtin

状态

采用

版本

地图服务器6.2

描述:此RFC建议在MapServer保护伞下进行Tinyows集成。

1。概述

Tinyows通常与MapServer结合使用,以提供WFS-T功能。

这里的想法是通过两个应用程序的单个映射文件配置文件为最终用户提供一个更集成的解决方案。

并将Tinyows放在MapServer项目的保护伞下,再次增加其使用量。

2。建议的解决方案

2.1保持循环释放独立

mapserver和tinyows循环版本保持独立。

2.2向量网

在SVN上,Tinyows位置应为:

svn.osgeo.org/mapserver/trunk/tinyows svn.osgeo.org/mapserver/branches/tinyows-1.0 svn.osgeo.org/mapserver/tags/tinyows-1.0.0

2.3作为配置文件的通用映射文件

目标是能够为最终用户提供一个配置文件,所以是一个文本映射文件。

Tinyows主干已经能够通过专用的mapfile lexer处理mapfile来检索所有的配置文件。

这个想法,在不久的将来,是带来一个libmapfile API,从而允许其他应用程序使用mapfile作为一个配置文件的方式。

它将简化这种解析器的维护,并避免具有不同行为的可能性。

此libmapfile api超出了此RFC的范围。

2.4透视图:打包构建系统

我们可以从这个RFC(以及相关的mod_geocache集成)中想象,提供一个具有单个配置/生成/生成安装的元包,同时管理mapserver、tinyows和mod_geocache的构建。

这些元包构建系统也超出了这个RFC的范围。

三。解决方案详细信息

3命名

Tinyows将被称为:mapserver Tinyows(保留以前的已知名称,并为其提供mapserver前缀)

3.1文件

将tinyows-trac-wiki文档移动到rst语法。

还需要增强文档以提供更多示例和全面的用户手册,或者至少类似于常见问题解答的内容。

当地的英国作家,还有那些还不熟悉这个项目的人,都非常感谢他们在这方面的帮助。

3.2许可证

Tinyows已经使用了MIT许可证,就像MapServer一样。版权所有人(芭芭拉·菲利波特和奥利维尔·科廷)应保存在现有的Tinyows文件中。

3.3张票

Tinyows使用Trac,但由于只有很少的票还处于打开状态,所以一种有效的方法就是在MapServerOne中重新创建它们。

应该意味着mapserver-trac中的一个新组件,称为:tinyows。

3.4开发人员和PSC

Olivier Courtin应该进入MapServer PSC并拥有对MapServer主干的提交访问权,并且将(至少在一段时间内)保持Tinyows开发方面的领先地位。

其他Tinyows开发人员已经参与了MapServer项目(Assefa、Alan)。

一个目标是让更多的MapServer开发人员准备好查看代码并提交补丁。

MapServer PSC将成为MapServer Tinyows模块的最终决策自动化。

3.5 VSN导入

Tinyows中继和1.0(即将到来)分支应导入到MapServer SVN中。

以前的提交历史将在旧的Tinyows SVN上保留一段时间。

3.6规范惯例

我们必须在整个代码中调用astyle,使其与mapserver兼容:astyle--style=kr--unpad=paren--indent=spaces=2

3.7重定向

tinyows.org域可以重定向到即将到来的mapserver tinyows文档页面。(http://www.mapserver.org/tinyows/

邮件列表:应该停止tinyows dev和tinyows用户,并且应该对相关的mapserver用户进行新闻讨论。

3.8项目成熟度

如果我们与MapServer相比,Tinyows是一个更年轻的项目,有一个非常小的开发团队。因此,这意味着至少在一段时间内,项目的决策和管理部分必须保持轻量级。

因此,RFC必须只用于大的和主要的变更,所有其他常见的事情,都应该“仅”使用简单的trac票据,例如:

  • 纠正/改进OGC标准的遵从性和互操作性

  • 错误和安全修复

  • 次要特征增强

  • 小代码重构

  • 单元测试策略

4。Tinyows代码检查

4.1代码起点

所有C代码都是由Tinyows开发人员从头开始编写的,因此不应该是真正的问题。

对于来自OGC的XSD模式和OGC引用的单元测试:官方的OGC许可证描述如下:https://www.ogc.org/ogc/document它允许公开传播,但不允许修改它。

4.2代码质量

所有代码在通用类Unix平台上编译时没有任何警告,带有标志:-ansi-pedantic-wall

所有的OGC引用单元测试都经过了验证(没有错误,没有内存泄漏),但是它并没有覆盖所有的代码分支。

像CUnit这样的一些单元测试将来可能会有所帮助。

4.3安全审计

从未对代码执行任何外部安全审计。主要的固有风险是SQL注入。

一些检查已经用像sqlmap这样的自动化工具完成,但是需要改进以适应一些WFS-T和FE特殊的用例。

(在带有sqlmap的Tinyows主干上未发现安全漏洞)

4.4 OGC WFS-T合规性

实施WFS 1.0.0、WFS 1.1.0、FE 1.0.0和FE 1.1.0。基本和事务配置文件,SF-0。(未实现XLink或锁定配置文件)

OGC上的Tinyows中继引用单元测试:
  • WFS-T 1.1.0(R4):559'通过'/0'失败'

  • WFS-T 1.0.0(r3):398'通过'/0'失败'

4.5外部依赖

  • libxml2>=2.6.20(和libxml2中继以避免GML XSD模式)

  • PostgreSQL>=8.1.0

  • Postgis>=1.5.0

  • FastCGI是可选的(但推荐)

4.6 Mapfile 概念尚未解决

Tinyows中还没有出现一些映射文件概念:
  • 只处理PostGIS连接类型

  • Tinyows不会假装现在支持mapfile中所有可用的WFS参数。

  • 但另一方面,您应该能够从mapfile配置Tinyows的每个部分。

  • 层中的每个连接字符串值必须相同。

  • 未分析映射文件投影内容,因此请使用显式WFS_SRS

  • 未分析映射文件层/筛选器。

  • 默认值是极小的,即使是两个应用程序共享的公共属性。

  • tinyows不使用mapfile中的数据元素,因此必须在每个层中使用tinyows_表(如果需要,还必须使用tinyows_模式)。

  • 如果在一个层上dump未设置为true,则这些层的读写访问都将关闭。

4.7构建系统

Tinyows使用mapserver autoconf和makefile来构建东西。

4.8路线图和愿景

总体目标是使应用程序成为WFS-T可用的更快的替代方案,尽可能地符合下一个OGC和激励标准,当然,还具有健壮性。

主要的未来工作区是(他们将意味着未来的RFC,就在这里通知他们):
  • 添加新的导出格式(shapefile,kml…)

  • Apache模块支持

  • 更详尽的单元测试策略(不仅是OGC策略)

  • Tinyows和MS的行为和配置指令更加一致。

  • Oracle空间支持

  • 应用程序架构支持

  • WFS 2.0和激励合规性

5。投票历史

2011年8月19日,Steve L.、Steve W.、Tamas、Dan、Howard、Assefa、Thomas和Tom通过了+1。