Changes between Version 7 and Version 8 of RFC59-Draft
- Timestamp:
- Aug 6, 2010, 10:35:28 AM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RFC59-Draft
v7 v8 100 100 101 101 {{{ 102 103 104 105 102 CLASS 103 ... 104 TEXT ([area] acres) 105 END 106 106 }}} 107 107 … … 109 109 110 110 {{{ 111 111 TEXT (commify(toString([area]*0.000247105381,"%.2f")) + ' ac') 112 112 }}} 113 113 … … 130 130 == Expression Use Elsewhere == 131 131 132 Currently the logical expression syntax is also used with REQUIRES/LABELREQUIRES and with rasters. In the REQUIRES/LABELREQUIRES case the code would remain mostly "as is" we'd still do the substitutions bases on layer status, then explicitly tokenize and parse. Since this done at most once per layer there's really no need to do anything more. 132 133 134 Rasters present more of a challenge. We'd need to handle them as a special case when tokenizing an expression by defining pixel bindings and then pass a pixel to the parser when evaluating the expression. This should be '''much, much''' faster than the current method where each pixel value is converted to a string representation (and then back to a number), especially given the number of pixels often evaluated. Some interesting drawing effects are also possible if you could expose a pixel location to the GEOS operators. For example, one could create a mask showing only pixels within a particular geometry. 135 136 == Query Impact == 137 138 This is where things get interesting. I'm proposing adding a new query, msQueryByFilter() that would work off an expression string. The expression string would still have to be accompanied by an extent parameter. Drivers like shapefiles still need to first apply a bounding box before applying a secondary filter. Other drivers could choose to combine the extent and expression string (more likely the tokens) if they so choose. This new function would work much like msQueryByAttributes(). I would extend the layer API to add a new function/variable that would determine whether a driver could process this common expression format natively somehow (e.g. via a FILTER and msLayerWhichShapes()/ msLayerNextShape()) or if the expression would need to be applied after msLayerNextShape() is called repeatedly. The shapefile and tiled shapefile drivers would work natively, as would any driver that uses msEvalExpression(). My hope is that the RDBMS drivers could somehow translate (via the tokens) an expression into their native SQL but if not, we would still be able to use those sources. (Note: Assefa is working to test the OGC filter => expression string path, results look promising.) 133 139 134 140 == Backwards Compatibility Issues == 135 141 142 Surprisingly few. The parser changes would all be transparent to the user. Truly handling TEXT expressions as expressions is a regression, albeit a positive one IMHO. I would also propose a few expression level changes especially around case-insensitive string and regex comparisons within logical expression. I think it makes more sense and is more user friendly to simply define case-insensitive operators (e.g. EQ and IEQ for straight string equality, and ~ and ~* for regex (modeled after Postgres). 143 144 The additional operators, functions and parsing contexts are new functionality. 145 146 A great deal of code would be made obsolete if this were pursued. Much of the OWS filter evaluation would be handled by the msQueryByFilter() function and numerous associated enums, defines, etc... could go away. 136 147 137 148 == Security Issues == 149 150 While the bulk of the work is in the bowels of MapServer any change of this magnitude could have unintended consequences. In this case I think the largest risks are buffer overflows associated with string operators in the parser and memory leaks. Care would need to be taken in developing a comprehensive set of test cases. 151 152 == Todo's == 153 154 1) The ''IN'' operator is in dire need of optimization.[[BR]] 155 2) All OGC filter operations need to be supported. Bounding box filters in particular have not been looked at.[[BR]] 156 3) Need ''LIKE'' operator code.[[BR]] 157 4) Need to finish msQueryByFilter() implementation.[[BR]] 158 5) How to handle projections?[[BR]]
