Opened 14 years ago
Last modified 13 years ago
#3481 reopened defect
Using STYLEITEM AUTO, loadExpression fails when the labe text contains a double quote
Reported by: | aboudreault | Owned by: | aboudreault |
---|---|---|---|
Priority: | normal | Milestone: | 6.0 release |
Component: | MapServer C Library | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: | dmorissette, assefa, sholl |
Description
Due to the ticket #185, the following text string returned from a ogr style text string fails is incorrectly displayed in a map:
ogr label text value: expand"ed map label value: "expand"ed"
If a string contains a double quote, the function msLoadExpressionString fails to parse the string.
Change History (23)
comment:1 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:3 by , 14 years ago
Cc: | added |
---|---|
Milestone: | → 6.0 release |
comment:4 by , 13 years ago
We noticed two new bugs related to this ticket. When a feature text read (ie. from MapInfo) is one of these cases, it will fail to load:
- HIGHWAY 7 <-- only HIGHWAY is displayed.
- "SOMETHING" <-- ""SOMETHING"" is displayed (2 double quotes)
The change was ok for MapServer 5.6 since the parser doesn't support quote escaping. Since the parser in MapServer 6.0 support it, the new solution is easy: we always pass the string quoted as we did before revision r10290, but we simply escape it before. So the double and single quotes are properly interpreted.
Fixed and committed in r11808.
comment:5 by , 13 years ago
I think this breaks an OGR layers where you can set on the layers; filter somthing like this:
LAYER CONNECTIONTYPE OGR .. FILTER "WHERE (ttt=1)" ... END
comment:6 by , 13 years ago
Cc: | added |
---|
follow-up: 9 comment:7 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
forgot to reopen last time. Stephan has also signaled similar problem.
comment:8 by , 13 years ago
Cc: | added |
---|
comment:9 by , 13 years ago
Alan,
di you had the time to fix this issue yet? Is there a chance having this into 6.0.1?
Best regards
Stephan
comment:10 by , 13 years ago
I'm going to check this today. Is the small example pasted by assefa ok to reproduce the issue?
comment:11 by , 13 years ago
6.0.1 is already release... but the last reported issue was only in trunk.
comment:12 by , 13 years ago
Yes, this should fail also. Qur filter always ended before the first occurance of a whitespace though.
Thanks for looking into this.
comment:13 by , 13 years ago
With the same FILTER (which works with a POSTGIS layer), I can't get it to work with mapserver r10000. So this ticket doesn't seem to be the cause. Will check deeper to see what broke a such filter.
comment:14 by , 13 years ago
MapServer 5.6 with that filter doesn't work neither. Am I missing something? How did you test that? What ms version did you use to get the expected result with? Here's my FILTER:
FILTER (name = 'Regina')
comment:15 by , 13 years ago
I tried this FILTER with the latest trunk and it works properly:
FILTER "WHERE (name='Regina')"
comment:18 by , 13 years ago
Attached is the test case:
http://127.0.0.1/cgi-bin/mapserv.exe?map=f:/msapps/tmp/bug3874/bug3841.map&SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=world_ogr&FILTER=<Filter><And><PropertyIsEqualTo><PropertyName>name</PropertyName><Literal>Ethiopia</Literal></PropertyIsEqualTo><BBOX><PropertyName>msGeometry</PropertyName><gml:Box><gml:coordinates>-90,-180 90,180</gml:coordinates></gml:Box></BBOX></And></Filter> layer is defined ... CONNECTIONTYPE OGR CONNECTION 'PG:host=127.0.0.1 port=5432 dbname=postgis user=xxxx password=xxx' DATA "world_ogr" ...
msLoadExpressionString should be called from filter encoding with an OGR type expression (WHERE ...). And that is failing. It was still a problem this moring with MS from svn.
Note that this is not an issue in 6.0.x, only in trunk.
comment:19 by , 13 years ago
comment:20 by , 13 years ago
The r11962 fixes the problem with the ogc filter that I reported earlier.
I also believe that r11808 have effects on all calls to msLoadExpressionString since that function now assumes that the input string should be quoted? (mapscript should also be affected).
I wish the fix for the original bug did not modify the loadExpressionString and impose a new double quote requirement for the function. Looking at r11808, I am not sure why that was necessary event after escaping the string in mapogr.
I am not sure if all the cases using loadExpressionString are covered by msautotest. mapogcfilter.c is covered. mapogcsld.c is parly covered (raster sld are not par of it for example). I am not at all sure about mapraster.c and maprasterquery.c. mapscript is not covered.
comment:21 by , 13 years ago
Replying to aboudreault:
Assefa, sholl, any idea of what I'm doing wrong?
Mhh, our Problem is slightly different than your. We are writing an expression through mapscript (Java) and the resulting expression in the written mapfile is truncated after the first blank line.
This is mapserver with r11973.
When manually adjust the expression-string in the resulting mapfile, ms is able to render the results though.
Should I open up another ticket for that issue?
Best
follow-up: 23 comment:22 by , 13 years ago
Yes, a new ticket for the Java issue would likely be better since it doesn't seem related. And perhaps include in the new ticket sample code or even better, a complete test case to reproduce since your description of the problem is not clear to me.
comment:23 by , 13 years ago
Replying to dmorissette:
Yes, a new ticket for the Java issue would likely be better since it doesn't seem related. And perhaps include in the new ticket sample code or even better, a complete test case to reproduce since your description of the problem is not clear to me.
I have added a small testcase into the new ticket #3983.
As a temporary fix, we reverted the change made in #185 when the first char of the string is an alpha character. (a-z, A-Z). The change in the previous ticket was to force the text to be interpreted as a string and not a regex/number. However, the lexer seems to fail when the string contains a double quote. With the isalpha hack, we keep the same behavior as before.. without the lexer bug with double quotes.
In MapServer 6.0, a useful enhancement would be the ability to escape double quotes inside a quoted string expression. A discussion should be started on the mapserver-dev mailing list.
Fixed and committed in r10290.