Sldfix 11863 #1975
Sldfix 11863 #1975
Conversation
| @@ -2218,7 +2218,7 @@ bool QgsExpression::NodeUnaryOperator::prepare( QgsExpression* parent, const Qgs | |||
|
|
|||
| QString QgsExpression::NodeUnaryOperator::dump() const | |||
| { | |||
| return QString( "%1 %2" ).arg( UnaryOperatorText[mOp] ).arg( mOperand->dump() ); | |||
| return QString( "%1%2" ).arg( UnaryOperatorText[mOp] ).arg( mOperand->dump() ); | |||
There was a problem hiding this comment.
This will also output NOT with no space which isn't correct. I was thinking about this and I'm not sure this needs to change even though I though it was wrong at the start.
There was a problem hiding this comment.
ok, happy to remove this, as it was only because you asked :-)
This reverts commit 6122a9f.
| } | ||
| else // not sure if this will ever happen | ||
| { | ||
| uoElem.appendChild( doc.createTextNode( "-" ) ); |
There was a problem hiding this comment.
In theory this may happen - e.g. with expression "-fldA + fldB = 0"
From a quick look into OGC Filter Encoding specs it seems to me that v1.1 defined arithmetic operators like [Add] and [Sub], the latest v2.0 does not mention them anymore. The expression "-X" could be handled the same way as "0-X" is handled - with [Sub] tag.
Or we could just return an error message stating it is not supported - better than just creating invalid filter...
There was a problem hiding this comment.
@wonder-sk I kept that line to not break historical use of it...
I'm fine with an error message, as I think (espcially in the ogc/sld context) this will never be used/happen.
Should I change it and add it to this PR then?
…eral operand See #1975 for discussion
|
@wonder-sk Martin ok, like this? Please pull, so it will be in 2.8.2 :-) |
Fixes #11863 (invalid SLD with negative values)
|
Thanks Martin |
|
thanks for patience :-) |
This fixes http://hub.qgis.org/issues/11863
in which non valid xml was generated due to the dual generation of literal layers.
not sure if this is the obvious solution, but it works for the example case which is in the issue.
I also found out that using a minus in a column name raises other problems. Not related to this one as there the minus is not seen as an unary operator.
6122a9f is a minimal dump fix.