Add some simple case modification functions to the expression parser

[mapserver-bot]

Reporter: woodbri
Date: 2012/03/20 - 01:13
Trac URL: http://trac.osgeo.org/mapserver/ticket/4255
There is a need to be able to modify text strings being presented as labels. Some simple functions added to the expression parser would solve this problem.

initcap(string) - would force the first character to uppercase and the rest of the characters to lowere case for EACH word in the string.

upper(string) - would force all characters to uppercase

lower(string) - would force all characters to lowercase.

These functions should probably be UTF8 aware. Ideally they should be able to convert upper/lower case accented characters I believe there are functions in the [http://site.icu-project.org/ ICU] library that do this. Minimally, the functions should not damage UTF8 strings.

[mapserver-bot]

Author: dmorissette
Date: 2012/03/21 - 03:27
See also ticket #1634 about essentially the same thing.

[mapserver-bot]

Author: sdlime
Date: 2012/03/21 - 04:12
What library are we currently using for UTF8 strings elsewhere in the code? (consider me UTF8 illiterate) Note there's nothing in the expression handling (where these functions would be implemented) specific to UTF8 at all.

This addition would also aid simple string comparison in logical expressions...

Steve

[mapserver-bot]

Author: woodbri
Date: 2012/03/21 - 05:24
SteveL, I'm not sure we do much with UTF8 or Unicode. Thomas added some code in maptclutf.c to support mapcairo.c needs and we have some limited support for it in mapstring.c and a few other places where we need to support unicode or utf8.

I only mentioned libicu because I used it for another project where I needed to mess around with utf8 characters, otherwise, I'm pretty UTF8 illiterate too. It would probably be worth your time to spend 15 minutes on their web site. They also have a good example /usr/share/doc/libicu-dev/examples/case/ucase.c if you install the libicu-dev package on Debian.

I don't want to make this too complicated, my only concern is that as soon as we start doing case changes, we have to be aware of the encoding to do it correctly.

[tbonfort]

de-milestoning this one as I suspect it won't make it to 6.2

concerning libicu, it would be on my todo list to investigate using it or harfbuzz to replace the fribidi support we have (it isn't thread safe, and currently breaks seeding with mapcache. Wrapping the fribidi calls with a mutex is not an option as it is called far too often and will therefore be locking constantly)

[nandajavarma]

What is the status of this issue right now? If Harfbuzz integration is enabled, then it can solve this issue as well. #2591. I would like to work on this. And would like to know the feasibility of this idea.

[sdlime]

I don't believe anyone is actively working on it... Adding functions to the parser is easy, it's the string handling/encoding that complicates matters. nandajavarma I'm not sure on what you'd like to work on though.

[aperi2007]

Hi, is someone working on this issue ?

[aperi2007]

I try your implement, but having this error in the webserver when try to do a getcapabilities.

maplabel.c:277: msComputeTextPath: Assertion `ts->annotext && *ts->annotext' failed.

[tbonfort]

@aperi2007 please provide a testcase

[aperi2007]

I'm testing better.....

It seem happened only on a my huge mapfile. :/
only one , the others seem all right.

To use correctly the upper/lower/initcap is necessary to add an expression to the label section ?
actually I use the TEXT only inside the Label .

[tbonfort]

@aperi2007 can you provide backtrace from a debugger when the assertion fails please.

[aperi2007]

Hi,
perhapps the issue is related to a change I must do to have a successful compile.

I have install harfbuzz, but the cmake don't see it.
So I must to disable both harfbuzz and fribidi to have a successful compile.

perhaps this could be the issue ?

[tbonfort]

For the harfbuzz/cmake issue, try starting from a fresh build directory (i.e. rm -rf * in build/). For the failed assertion, that should not be related, and even if it was I would like to get a backtrace in order to fix it.

[aperi2007]

ok,
the issue assert seem not related to the upper/lower label.
It happened also using the ssource from the mapserver-trunk main repo.

I isolate the layer that trigger that assert:

 LAYER
    CONNECTION "/path-to-spatialite/spatialite-db-file.sqlite"
    CONNECTIONTYPE OGR
    DATA "vt_pae_lett_e"
    EXTENT 1561380.48766475 4875325.97247314 1632475.09465035 4921952.65645745
    METADATA
      "ows_title"   "lett_e_artut"
      "ows_enable_request" "*"  
      "ows_include_items" "all"  
      "gml_include_items" "all"
      "gml_geometries" "GEOMETRY"
      "gml_geometry_type" "multipolygon"
      "gml_types"   "none"
      "gml_PK_UID_type" "int"
      "wms_getfeatureinfo_formatlist" "OGRGML" 
    END
    TEMPLATE 'void'  
    NAME "lett_e_artut"
    PROJECTION
      "+init=epsg:3003 +towgs84=0,0,0,0,0,0,0"
    END
    STATUS OFF
    TILEITEM "location"
    TYPE POLYGON
    UNITS meters
    LABELCACHE on
    CLASS
      NAME 'area superiore a 10ha'
      EXPRESSION ( ([AREA] < 2000000000) AND ([AREA] > 10000000) )
      MAXSCALEDENOM 5000100
      MINSCALEDENOM 500100
      STYLE
         COLOR "#FFC0B666"
      END
      STYLE
         WIDTH 1.1
         OUTLINECOLOR "#FEFEFE"
         PATTERN 2 2 END
         ANTIALIAS false
      END
    END
    CLASS
      NAME 'area inferiore a 10ha'
      EXPRESSION ([AREA] < 10000000)
      MAXSCALEDENOM 5000100
      MINSCALEDENOM 500100
      STYLE
         GEOMTRANSFORM 'centroid'
         SYMBOL 'circlefill'
         SIZE 2
         COLOR "#FFC0B666"
         OUTLINECOLOR "#FFC0B6"
         ANTIALIAS false
      END
    END
    CLASS
      NAME ""
      MAXSCALEDENOM 500100
      MINSCALEDENOM 1
      STYLE
        COLOR "#FFC0B666"
      END # STYLE
      STYLE
         WIDTH 1.1
         OUTLINECOLOR 255 192 182
         PATTERN 2 2 END
         ANTIALIAS false
      END
      TEXT '[LOC]'
      LABEL
        COLOR 100 100 100
        OUTLINECOLOR 255 192 182
        OUTLINEWIDTH 1
        MAXSCALEDENOM 100000
        MINSCALEDENOM 1
        FONT "Calibri"
        TYPE truetype
        SIZE 9
        ANGLE 0
#        STYLE
#          GEOMTRANSFORM 'labelpnt'
#          COLOR 255 0 0
#          OFFSET 3 2
#        END # STYLE
        POSITION auto
        PRIORITY 10
        MAXOVERLAPANGLE 90.0
        BUFFER 1
        FORCE OFF
        PARTIALS OFF
        MINFEATURESIZE auto
      END
    END # CLASS
  END # LAYER

However I guess is better open a more specific ticket.

[tbonfort]

@aperi2007 no need for another ticket or testcase, I can reproduce with your layer definition

[tbonfort]

fixed in 53c58d8

[aperi2007]

@tbonfort the assertion fail is resolved. Thx.

I try also to apply your hint for harfbuzz problem. I remove old build and reclone all , but still the harfbuff is not found.
AFAIK cmake is searching the harfbuzz on a single path. But I see it has no a clear installed folder.
Instead it is copy under the usually /usr/local/bin; /usr/local/lib;/usr/local/include.
I try to add these to the CMAKE_PREFIX_PATH without any result.

[szekerest]

Documentation updated in MapServer/MapServer-documentation@9410665