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 aboudreault, 14 years ago

Resolution: fixed
Status: newclosed

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.

comment:2 by aboudreault, 14 years ago

Correction: I've replaced isalpha by isalnum in r10291.

comment:3 by dmorissette, 14 years ago

Cc: dmorissette added
Milestone: 6.0 release

comment:4 by aboudreault, 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 assefa, 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 assefa, 13 years ago

Cc: assefa added

comment:7 by assefa, 13 years ago

Resolution: fixed
Status: closedreopened

forgot to reopen last time. Stephan has also signaled similar problem.

comment:8 by sholl, 13 years ago

Cc: sholl added

in reply to:  7 comment:9 by sholl, 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 aboudreault, 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 aboudreault, 13 years ago

6.0.1 is already release... but the last reported issue was only in trunk.

comment:12 by sholl, 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 aboudreault, 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 aboudreault, 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 aboudreault, 13 years ago

I tried this FILTER with the latest trunk and it works properly:

FILTER "WHERE (name='Regina')"

comment:16 by aboudreault, 13 years ago

FILTER "WHERE (gid=457)" # also works

comment:17 by aboudreault, 13 years ago

Assefa, sholl, any idea of what I'm doing wrong?

comment:18 by assefa, 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 aboudreault, 13 years ago

Fixed in r11962. Assefa, please test and confirm. Also, do you think the r11808 could affect other msLoadExpressionString call? Is there a good number of tests in msautotest for that?

comment:20 by assefa, 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.

in reply to:  17 comment:21 by sholl, 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

comment:22 by dmorissette, 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.

in reply to:  22 comment:23 by sholl, 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.

Note: See TracTickets for help on using tickets.