Home | Products | Issue Tracker | FAQ | Download | |
Last Updated: | 2011-05-04 |
---|
Table of Contents
本部分阐述了从MapServer 5.6.x版本(或更早版本)迁移到6.0版本必须要修改的一些设置,同时也会介绍一些新特性的信息。
6.0版本扩展了一些表达式解析能力。这既增强了其功能性,同时又引进了一些不便:
逻辑表达式
文本分类表达式在6.0版本中可以使用了。这使得可以对数字进行更好的格式化,但同时亦表明属性数据和字符之间需要使用字符串操作符进行连接。
另外,您现在可以控制小数点的位置、小数点后的位数。
详情请参见 http://mapserver.org/development/rfc/ms-rfc-64.html 和 http://trac.osgeo.org/mapserver/ticket/3736 。
随着控制标注绘制风格需求的增加,很明显单纯无止境地扩展labelObj已经很不现实了。在6.0版本中,我们引进了标注样式的概念,即一个labelObj对象中的labelObj对象。样式可以用来给标注添加标志或者边框元素,形成一种类似于kinda的注记图层。这样做的一个好处是一步即好。也就是说你可以绘制复杂的路径并同时遮蔽起来。是不是很酷?并且,你可以绑定支持的属性值到styleObj对象的属性
这样导致的一个结果是,参数BACKGROUNDCOLOR、BACKGROUNDSHADOWCOLOR和BACKGROUNDSHADOWSIZE被删除了。要在6.0版本中绘制一个标注框,你需要:
LABEL
...
STYLE # a shadow
GEOMTRANSFORM 'labelpoly'
COLOR 222 222 222
OFFSET 2 2
END
STYLE # bbox
GEOMTRANSFORM 'labelpoly'
COLOR 255 255 255
OUTLINECOLOR 0 0 0
END
END
从长远来看,这变得更加灵活了,尽管有一点繁琐。
MS RFC 60: Labeling enhancement: ability to skip ANGLE FOLLOW labels with too much character overlap 引进了一个新的关键字MAXOVERLAPANGLE在重叠的字符标注上过滤出ANGLE FOLLOW。该选项在6.0版本中默认启用,MAXOVERLAPANGLE的默认值为22.5度。
正如 MS RFC 60: Labeling enhancement: ability to skip ANGLE FOLLOW labels with too much character overlap 中显示的,可以通过设置MAXOVERLAPANGLE为0来回归到6.0以前版本的风格,从而使用maxoverlapangle = 0.4*MS_PI(180度的40%即为72度)。
MapServer 6.0的渲染后端已经经过了重构,使得用户可以使用所有渲染驱动(GD、AGG、PDF、SVG等)的特性。
所有的线样式现在必须在图层的STYLE中指定。
以下的参数或关键字从SYMBOL移到了STYLE:
PATTERN POSITION GAP LINECAP LINEJOIN LINEJOINMAXSIZE
SYMBOL和STYLE参数或关键字在5.0版本中被重命名为PATTERN。
SYMBOL和TYPE型的绘图线已经被移除。
由于LINECAP三角形不AGG或Cairo所支持,因此不再可用。对直线使用填充的矢量三角形标志并设置开始和结束为GEOTRANSFORM型,然后设置ANGLE为AUTO,可以获得与之类似的三角形端点效果。这种方法只对直线起作用,对破折号不起作用。
运行时替代如今 必须 在替代之前进行有效性验证(过去的版本中为可选)。这可以在图层中或网络VALIDATION块中通过图层的元数据标记来设置。详情参见#3522号票(ticket)。
所有的地图查询相关模式(例如NQUERYNMAP、ITENQUERYNMAP等)已经被废弃,代之的是使用“qformat”参数。该参数使用输出格式名称或者mime/type作为值,并且可以来处理一系列的查询结果。例如:
...&mode=nquerymap&... would become ...&mode=nquery&qformat=png24&...
OGC网络服务现在默认被关闭。若你想要像在MapServer的5.6及之前版本中的那样启动它们,可以在 ::WEB块中添加以下的元数据:
"ows_enable_request" "*"
记住只有“wcs_*”和“ows_*”前缀的元数据块才作用在OGC的WCS服务中,这样可以避免困扰。在之前的版本中使用“wms_*”前缀的元数据入口来表达,而在新版本中已经被废弃。
现在可以在字符串和逻辑表达式中对单引号和双引号进行转义,例如:
NAME "RO\"AD" # 在限定字符串双引号中的双引号
NAME 'RO\'AD' # 在限定字符串单引号中的单引号
FILTER ('[CTY_NAME]' = 'Ita\'sca') # 包含单引号的逻辑表达式
注意:转义符号(反斜杠符)只在后面紧跟着 “,’ 和 的时候才起作用。
Windows的用户们请注意:如果你们的由双引号或单引号限定的路径字符串以反斜杠 结尾,你需要对最后一个反斜杠转义。
SHAPEPATH "C:\ms4w\shapefiles\"
# 应该改为 。。。
SHAPEPATH "C:\ms4w\shapefiles\\"
要求PHP 5.2.0或以上版本。
PHP地图脚本现在使用异常机制来报告错误,所有的错误都可以被捕捉到。
可以像其它php对象一样设置地图对象的属性,亦即如 myObj->myProperty = 10。
注意:set/setProperty方法依然可用。
所有的对象构造方法会在构建失败时抛出异常。
对象可以使用php的“new”操作符创建,亦即如: $myShape = ms_newShapeObj(MS_SHAPE_LINE); // or $myShape = new shapeObj(MS_SHAPE_LINE);
可复制的对象在复制时需要使用PHP的clone关键字,没有其他的复制方法。
已经被移除的类的属性包括:
已经被移除的类的方法包括:
referenceMapObj添加了新的属性:marker,markername,markersize,maxboxsize,minboxsize
shapeFileObj在被销毁时可以自动关闭或写入保存。(在脚本的最后或者显式地使用一个unset()方法)
layerObj->clearProcessing()方法现在返回一个空值(void)。
mapObj->queryByIndex():addToQuery参数的默认行为,之前不能正常使用,现在可以了。
返回值为MS_SUCCESS/MS_FAILURE的方法有:
失败时返回空值(NULL)的方法:
返回一个空数组的方法:
图层的查询结果处理机制已经重新生效了,在5.4和5.6版本中引进的一些问题也得以解决。resultsGetShape和getFeatures方法已被移除。如今你得使用重新设计的getShape方法来操作图层上的图元。该方法将一个resultObj对象作参数,并返回一个shapeObj对象。典型用法(以Perl为例):
$layer->queryByRect($map, $map->{extent}); # layer is still open
for($i=0; $i<$layer->getNumResults(); $i++) {
$shape = $layer->getShape($layer->getResult($i));
print "$i: ". $shape->getValue(1) ."\n";
}
$layer->close();
resultObj对象是对管理结果集数据的封装。
请使用新的resultObj对象来单独地操作查询的图元:
$layer->open(); $shape = $layer->getShape(new mapscript::resultObj(1)); $layer->close();
详情参见http://mapserver.org/development/rfc/ms-rfc-65.html。
当读取mapfile文件设置OUTPUTFORMAT参数时,若出现问题会弹出一个错误窗口,而之前这些问题是在后台被慢慢修复的。比如,JPEG格式使用RGBA色彩模式时会触发一个错误,之前遇到此类状况会自动转换为RGB色彩模式。
默认的输出文件格式和MIME类型经过了全新的组织。
本部分阐述了MapServer从 5.4.x 版本(或更早版本)向 5.6 版本迁移(亦即后向兼容性)所要注意的变化,同时也会介绍一些新特性的信息。
在 RFC-52 中,MapServer 对查询的执行过程进行了改进,现在是执行单条语句而不是之前的两条。对 CGI 程序来说,这个改进不可见;但是 MapScript 的脚本必须将 layer.getShape() 方法修改为 layer.resultsGetShape()。
参见: http://mapserver.org/development/rfc/ms-rfc-52.html
(注意:5.6.0-beta1中的新 resultsGetShape() 方法暂时还不能用于 PHP MapScript)
The axis order in previous versions of the WFS specifications was to always use easting (x or lon ) and northing (y or lat). WFS 1.1 specifies that, depending on the particular SRS, the x axis may or may not be oriented West-to-East, and the y axis may or may not be oriented South-to-North. The WFS portrayal operation shall account for axis order. This affects some of the EPSG codes that were commonly used such as ESPG:4326. The current implementation makes sure that coordinates returned to the server for the GetFeature request reflect the inverse axis orders for EPSG codes between 4000 and 5000.
RFC 36 added support for templated outptformats, but this new feature was not available for WMS GetFeatureInfo ouptut (see ticket #3024). In MapServer 5.6 this has been resolved by implementing lookup of output formats for query templates by mime-type. However this caused a conflict for the text/html mime-type between the actual text/html query templates and the preconfigured imagemap outputformat which also used the text/html mime-type.
In order to resolve this conflict, the mime-type of the imagemap outputformat has been changed to “text/html; driver=imagemap”. This is unlikely to cause much side-effects to existing applications, but the change is documented here just in case.
This section documents the changes that must be made to MapServer applications when migrating from version 5.2. (or earlier versions) to 5.4 (i.e. backwards incompatibilities), as well as information on some of the new features.
Due to some potential security vulnerabilities that were uncovered in previous versions of MapServer, RFC-56 introduced a number of changes to tighten access control on mapfiles and templates and limit the risk of leaking arbitrary file contents. These changes were introduced in version 5.4.0, and were also backported to v5.2.2 and 4.10.4.
The new requirements are as follows:
See also: http://mapserver.org/development/rfc/ms-rfc-56.html
This section documents the changes that must be made to MapServer applications when migrating from version 4.10.x (or earlier versions) to 5.x (i.e. backwards incompatibilities), as well as information on some of the new features.
Attribute Bindings: In an effort to stem the tide of keyword overload and add functionality MapServer 5.0 supports a new method of binding feature attributes to STYLE and LABEL properties. In the past keywords like ANGLEITEM or LABELSIZEITEM were used, now you denote the attribute in the context of the property being bound. For example, to bind an attribute to a label size you’d do:
LABEL
...
SIZE [mySizeItem]
END
The []’s denote a binding (as with logical expressions). The following keywords are no longer supported and their presence will throw an error:
The following properties can accept bindings:
Colors may be given as a hex value (e.g. #FFFFFF) or an RGB triplet (e.g. 255 255 255).
Layer Transparency: The values for the TRANSPARENCY parameter have always been backwards and in an effort to resolve that the parameter has been renamed OPACITY. TRANSPARENCY is still recognized by the mapfile parser but is depricated and should be avoided.
Scale Parameters: MapServer’s handling of scale has long been a source for confusion. The values use in a layer MINSCALE are really the denominators from a representative fraction (e.g. 1:24000). To help clarify this all scale parameters are now end with DENOM. So MINSCALE => MINSCALEDENOM, SYMBOLSCALE => SYMBOLSCALEDENOM, and so on. The mapfile parser still recognizes the older keywords but they are depricated and should be avoided.
Symbol Style: STYLEs are used within a symbol definition to store dash patterns for line symbolization. However, there is potential confusion with the style object that is used within class definitions. To resolve that confusion the symbol STYLE parameter has been renamed PATTERN. The symbol file parser will still recognize the STYLE keyword but it is depricated and should be avoided.
Prior to MapsServer 5.0, if a pixmap symbol was used in style on a Line Layer, the symbol was used as a brush to draw the line. In MapServer 5.0, it is possible to draw the pixmap symbol along the line (Note that this was available using a true type symbol). To achieve this, the user needs to use the parameter GAP with it’s pixmap symbol definition in the symbol file. The GAP represents the distance between the symbols. If the GAP is not given, the pixmap symbol will be used as a brush.
see the AGG rendering specifics for the changes relating to the addition of the Antigrain Geometry rendering engine.
Previous versions of the MapServer CGI program allowed certain parameters to be changed via a URL using a cumbersome syntax such as map_layer_0_class_0_color=255+0+0 which changes the color in one classObj. Not only was this cumbersome for users but also from a code maintenance perspective since we had to maintain seperate loaders for URL-based config and file-based config. RFC-31 attempts to streamline both by migrating to a single object loading function that can be used with strings (either in MapScript or via URL) or with files.
So, in the past you have to change parameters one-at-a-time. Now you can pass chunks of mapfiles (with security restrictions) to the CGI interface. The map_object notation is still necessary to identify which object you want to modify but you can change multiple properties at one time. Note that you can use either a ‘_’ or a ‘.’ to seperate identifiers.
Example 1, changing a scalebar object:
...&map.scalebar=UNITS+MILES+COLOR+121+121+121+SIZE+300+2&...
Example 2, changing a presentation style:
...&map.layer[lakes].class[0].style[0]=SYMBOL+crosshatch+COLOR+151+51+151+SIZE+15&...
Example 3, creating a new feature
...&map_layer[3]=FEATURE+POINTS+500000+1000000+END+TEXT+'A+test+point'+END&...
The variable identifies an object uniquely (by name or index in the case of layerObj’s and classObj’s). The value is a snippet of a mapfile. You cannot create new objects other than inline features at this point.
Attribute queries (qstring) done via the mapserv CGI could theoretically be used for SQL injection.
No exploit has been reported, but in order to mitigate the risk, a new validation pattern mechanism has been added in 5.0.
In the case of qstring attribute queries, the qstring_validation_pattern layer-level metadata is required for qstring queries to work. The metadata value is a regular expression that the qstring value must match otherwise mapserv produces a fatal error. A fatal error is also produced if qstring is used but qstring_validation_pattern is not provided.
Note that similar validation pattern mechanism has been available for %variable% substitutions since version 4.10, but in this case it is optional. The pattern for %myvar% is provided via a metadata called myvar_validation_pattern.
Layer Transparency: The layerObj transparency parameter is now called opacity. Scripts setting that value in code must be updated.
Symbol Style: the symbolObj style parameter is now called pattern. MapScript does not allow direct modification of that parameter. In Swig-based languages the symbolObj method setStyle is now called setPattern. In PHP/MapScript, the methods setStyle and getStyle are now called setPattern and getPattern.
A new msGetVersionInt() function returning the current MapServer version in integer format has been added to facilitate version checks in the future. Given version x.y.z, it returns (x*0x10000 + y*0x100 + z). For instance, for v5.0.0 it will return 0x050000 (note the hexadecimal notation).
Layer Transparency: The layerObj transparency parameter is now called opacity. The old “transparency” name is deprecated and will be removed in a future release. Scripts getting/setting that value in code must be updated.
All occurences of scale, minscale, maxscale, etc... parameters have been deprecated and renamed with a “denom” suffix (e.g. minscale becomes minscaledenom, etc.). The deprecated parameters will be removed in a future release. Scripts getting/setting them must be updated.
SymbolObj style has been renamed pattern. The old “stylelength” parameter and setStyle() and getStyleArray() methods have been deprecated and “patternlength”, setPattern() and getPatternArray() should be used instead. They will be removed in a future release.
layer.getShape(int tileindex, int shapeindex)) has been deprecated and renamed to layer.getFeature(int shapeindex [, int tileindex = -1]) to match the SWIG MapScript equivalent. Note that the order of the arguments is reversed since tileindex is optional in getFeature().
class.getExpression() and layer.getFilter() have been deprecated and renamed to class.getExpressionString() and layer.getFilterString() to match what we have in SWIG MapScript. The String suffix in the function name also more clearly indicates that the return value is not an object but a string representation of it.
A new ms_GetVersionInt() function returning the current MapServer version in integer format has been added to facilitate version checks in the future. Given version x.y.z, it returns (x*0x10000 + y*0x100 + z). For instance, for v5.0.0 it will return 0x050000 (note the hexadecimal notation).
Required Parameters for GetMap and GetFeatureInfo: previously, MapServer did not check for the following parameters when responding to an OGC:WMS GetMap or GetFeatureInfo request:
- SRS
- FORMAT
- WIDTH
- HEIGHT
- STYLES or SLD / SLD_BODY
- BBOX
That is, a GetMap request would process without error if these were not passed by the WMS client.
A compliant OGC:WMS 1.1.0 and 1.1.1 REQUIRES these parameters. This may affect OGC:WMS client requests who were not passing these values. Ticket 1088 fully documents this issue. In addition to WMS compliance, this was also decided that by adding this constraint, if an OGC client request (as described earlier) breaks something, people should fix their client anyway since if they change WMS vendor, they will have problems as well.
“sos_describesensor_url” “http://example.org/sml/%procedure%.xml“
This change has been made to clarify and unify the meaning of procedure within SOS Server’s context of a DescribeSensor request.
MapServer’s main include file has been renamed from “map.h” to “mapserver.h”.
A new mapserver-config script has been created with the following options:
Usage: mapserver-config [OPTIONS]
Options:
[--libs]
[--dep-libs]
[--cflags]
[--defines]
[--includes]
[--version]
The shared and static link libraries for MapSserver have been renamed libmapserver.x.y.so and libmapserver.a respectively.
The –enable-coverage configure option has been renamed to –enable-gcov since the former name led users to think it might be related to enabling support for WCS or Arc/Info coverages:
--enable-gcov Enable source code coverage testing using gcov
Some features present in MapServer are likely to be removed in a future release. Features might be headed for deprecation because:
- they have been replaced by a superior or more capable solution
- they have stopped being maintained
Users of these features should be prepared for these upcoming changes and start adapting their mapfiles in consequence. If you have strong and motivated objections as to the removal of one or more of these features please open a discussion in the usual Mapserver communication channels.
Cartoline symbols: these were a hack to overcome GD weaknesses, and their functionality is now supported by the AGG renderer. They have become poorly supported in current MapServer versions. Keywords allowing for setting the style of line joins and caps will be moved to the STYLE block.
RGB/RGBA output with GD: support for RGB and RGBA image types will likely not be maintained anymore. PC256 will continue to be supported with GD, while RGB and RGBA will liekly only be supported with AGG