Changes between Version 9 and Version 10 of RFC59-Draft
- Timestamp:
- Oct 25, 2010, 10:04:21 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RFC59-Draft
v9 v10 33 33 == Proposed Technical Changes == 34 34 35 This RFC proposes a number of technical changes. The core change, however, involved updating the way logical expressions work. Additional capitalize on thisto bring additional capabilities to MapServer.35 This RFC proposes a number of technical changes. The core change, however, involved updating the way logical expressions work. Additional features capitalize on this core change to bring additional capabilities to MapServer. 36 36 37 37 '''Core Parser Update''' … … 67 67 }}} 68 68 69 Some of these definitions hint at other features that will be detailed later. When we convert an expression string into a series of tokens we also store away the value associated with that token (if necessary). In many cases the token value is a lit teral (string or number), in other cases its a reference to a feature attribute. In the latter case we use the attributeBindingObj already in use by MapServer to encapsulate the information necessary to quickly access the correct data (typically an item index value).69 Some of these definitions hint at other features that will be detailed later. When we convert an expression string into a series of tokens we also store away the value associated with that token (if necessary). In many cases the token value is a literal (string or number), in other cases its a reference to a feature attribute. In the latter case we use the attributeBindingObj already in use by MapServer to encapsulate the information necessary to quickly access the correct data (typically an item index value). 70 70 71 71 We always have had to make expression data available to the parser (and lexer) via temporary global variables. That would continue to be the case here, although different data are shared in this context. One thing to note is that once an expression is tokenized we no longer have to rely on the flex-generated lexer so, in theory, it should be easier to implement a thread-safe parser should we choose to do so. … … 79 79 EXPRESSION (fromText('POINT(500000 5000000)') Intersects [shape]) 80 80 81 1) fromText('POINT(500000 5000000)') defines a shape literal 81 1) fromText('POINT(500000 5000000)') defines a shape literal (the WKT to shapeObj conversion is done only once) 82 82 2) [shape] is a shape binding 83 83 }}} … … 97 97 '''Context Sensitive Parsing ''' 98 98 99 We could have done this all along but this would be an opportune time to implement context sensitive parser use. Presently we expect the parser to produce a true or false result, but certainly aren't limited to that. For example, at the moment you can write: 99 We could have done this all along but this would be an opportune time to implement context sensitive parser use. Presently we expect the parser to produce a true or false result, but certainly aren't limited to that. The idea is to use the parser to compute values in other situations. Two places are working in the sandbox and are detailed below. 100 101 ''Class TEXT Parameter'' 102 103 Currently you can write: 100 104 101 105 {{{ … … 126 130 Then in the grammar we set a parse result type and set the result accordingly. One side effect is that we have to define a standard way to convert numbers to strings when in the string context and simply using "%g" as a format string for snprintf does wonders to output. 127 131 128 We can also extend the parser to output shapeObj's and I could see this manifesting itself via the GEOMTRANSFORM mechanism already in place. It would be relatively easy to add many of the GEOS supported operators to the grammar and expose them this way. Buffering would be an obvious candidate. 132 ''Style GEOMTRANSFORM Parameter'' 133 134 Within the sandbox I've implemented GEOMTRANSFORMs as expressions as opposed to the original implementation. The parser has also been extended to support the GEOS buffer operator. So you can write: 135 136 {{{ 137 STYLE 138 GEOMTRANSFORM (buffer([shape], -3)) 139 ... 140 END 141 }}} 142 143 This does executes a buffer on the geometry before rendering (see test.buffer.png attachment). Because of where the GEOMTRANSFORMATION processing occurs this processing happens '''after''' the feature is converted from map to image coordinates, but the effect is still valuable. In the future we might consider implementing a GEOMTRANSFORM at the layer level so that the transformation is available to all classes and/or styles (and consequently in query modes too). 129 144 130 145 == Expression Use Elsewhere == … … 136 151 == Query Impact == 137 152 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.)153 This is where things get interesting. I'm proposing adding a new query, msQueryByFilter() that would work off an expression string (this is working in the sandbox). 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. msQueryByFilter() works much like msQueryByAttributes(). The layer API has been extended to include a prototype, msLayerSupportsCommonFilters(), that allows the driver to say if it 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. 139 154 140 155 == Backwards Compatibility Issues == … … 145 160 146 161 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. 162 163 Logical operators: AND, OR, NOT[[BR]] 164 Comparison operators: =, '''=*''', !=, >, <, >=, <=, ~, '''~*''', in[[BR]] 165 Spatial comparison operators: '''intersects''', '''disjoint''', '''touches''', '''overlaps''', '''crosses''', '''within''', '''contains''', '''beyond''', '''dwithin'''[[BR]] 166 Functions: length, '''commify''', '''round''', '''tostring'''[[BR]] 167 Spatial functions: '''fromtext''', '''area''', '''distance''', '''buffer''' 147 168 148 169 == Security Issues ==
