I noticed that the BNF grammar seems to have a typo in the entry for
reserved words, Between BEFORE and IN there's a line break but no |
The CQL parser also doesn't seem to handle attributes with spaces (when
quoted) and doesn't handle escaped double quotes
PR with fix for the reserved word issu
The problem manifests even without the BarnesSurface, I was just responding
to your comment that the attribute name was bad by pointing out that when I
encountered the problem, the attribute didn't even exist. I've checked with
saner data and get the same thing. The error occurs when parsing the EC
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
On 30 March 2015 at 18:04, Jim Hughes 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 q
Fair enough, just pointing out that intersecting attribute names with
keywords crosses a linestring. And that might not work after that.
Puns aside, I'm curious to see the fix when it comes. If you have a
failing unit test, I'm not above playing along over here.
Cheers,
Jim
On 03/30/2015
In this case "point' was the name of an attribute in the data - so not much
we could do about it.
--
Jody Garnett
On 30 March 2015 at 18:04, Jim Hughes wrote:
> The EBNF does reference key words/reserved words. That list includes wkt
> keywords like POINT, POLYGON and predicates like INTERSEC
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 l
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-
I've noticed that ECQL.toCQL doesn't escape WKT keywords. So
point 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 th