Kevin,Hmm... does the Barnes Surface process create an ad hoc, intermediate feature type?
I think the issue may be here: https://github.com/geotools/geotools/blob/master/modules/library/cql/src/main/java/org/geotools/filter/text/commons/ExpressionToText.java#L215-221. PropertyNames are not escaped. I fiddled with cooking up filters with Literals rather than PropertyNames, and those were escaped by code above.
Cheers, Jim On 03/30/2015 09:16 PM, Kevin Smith wrote:
On 30 March 2015 at 18:04, Jim Hughes <[email protected] <mailto:[email protected]>> wrote:The EBNF does reference key words/reserved words. That list includes wkt keywords like POINT, POLYGON and predicates like INTERSECTS and DURING. A property name appears to get worked out as 'character string literal', and would need to be quoted. I think that would do the trick. Since the literal *point* is written sans qutoes, I'dguess that the preference for keyword identification is too high? If that's the case, something in the parser may need a little nudge.In general, I'd suggest that reserved words in a query language make poor attribute names.;)Yes but the CQL encoder should be able to deal with it when it happens. What's particularly strange is that the specific example that brought this to my attention, the query is actually wrong in that the attribute in question doesn't even exist. It was just being added to a raster symbolizer in a style using Barnes Surface for no apparent reason and when I converted it to CQL and then tried to parse the CQL, it broke.Cheers, Jim On 03/30/2015 07:55 PM, Jody Garnett wrote:So what is needed here ... list of reserved words that must be escaped when encoded? I think the square brackets are just to introduce precedence, isolating point won't help since it will start trying to treat it as geometry. For reference the grammar is here: http://old.geotools.org/ECQL-Parser-Design_110493908.html -- Jody Garnett On 30 March 2015 at 16:46, Kevin Smith <[email protected] <mailto:[email protected]>> wrote: I've noticed that ECQL.toCQL doesn't escape WKT keywords. So <PropertyName>point</PropertyName> is encoded to just point rather than "point" or [point]. When this is parsed in turn, it is interpreted as a WKT literal, although it's lacking the rest of the expression and so fails. The bracket notation also fails to resolve this when parsing, it still interprets [point] as being the start of a WKT literal rather than an attribute name. When double quoted ("point") it escapes against the WKT interpretation as expected. I may be missing something. When I looked up the formal CQL spec hidden in the CSW spec, i couldn't find any indication of either bracket or double quote escaping of property names. Were these added for ECQL?--Kevin Smith Software Engineer | Boundless <http://boundlessgeo.com/> [email protected] <mailto:[email protected]> +1-778-785-7459 <tel:%2B1-778-785-7459> @boundlessgeo <http://twitter.com/boundlessgeo/> <http://twitter.com/boundlessgeo/> http://boundlessgeo.com/ <http://boundlessgeo.com/> ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ GeoTools-Devel mailing list [email protected] <mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now.http://goparallel.sourceforge.net/ _______________________________________________ GeoTools-Devel mailing list [email protected] <mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/geotools-devel------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ GeoTools-Devel mailing list [email protected] <mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Kevin Smith Software Engineer | Boundless <http://boundlessgeo.com/> [email protected] <mailto:[email protected]> +1-778-785-7459 @boundlessgeo <http://twitter.com/boundlessgeo/> <http://twitter.com/boundlessgeo/> http://boundlessgeo.com/ <http://boundlessgeo.com/>
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
