Opened 18 years ago

Closed 12 years ago

#1634 closed enhancement (fixed)

Support for formatting (and converting) labels of attributes

Reported by: szekerest Owned by: sdlime
Priority: high Milestone:
Component: MapServer C Library Version: 4.6
Severity: minor Keywords:
Cc: jmckenna, aboudreault

Description (last modified by dmorissette)

Mapserver supports displaying labels based on attributes in different ways, that
is specifying labeitem or setting up the text attribute of the class. The latter
allow of labeling based on multiple attributes.

In many cases it would be useful to convert the type of the attribute (eg. from
float to integer) value and (or) to apply some formatting on numeric fields(eg.
number of digits or floating point representation) before drawing it.

In the current implementation mapserver reads attribute values as strings so
formatting takes place at the driver level. In order not to rewrite large amount
of code atof or atoi could be used before applying the formatting after
evaluating the users format specification given along with the field names.


Tamas

Change History (8)

comment:1 by sdlime, 18 years ago

Summary: Support for formatting (and converting) labels of attributes Support for formatting (and converting) labels of attributes
Actually RFC 9 is a step in the this direction. It looks at formating 
attributes for use in templates. Some of the ideas there could be applied to 
labeling. I would propose not writing much code at all but extending the 
expression handing to include a number of string functions such as:

  tolower, toupper, commify, substr, round

Some would obviously expect numeric strings (e.g round).

That way it all happens in the Bison code. (Format specifications from my 
perspective are dangerous.) This way you could write labeling functions like:

  TEXT ($ commify(round([cost], 2), '.'))

or something like that.

Steve

comment:2 by szekerest, 18 years ago

Steve,

I have an OGR layer having a field of type real but it contains always integers
(eg. street numbers). Currently theese items are labelled in ugly formats like

"        18.00000000000"

does this proposal allows me to label it as "18"

How soon may I expect RFC9 to be implemented?

Tamas  


comment:3 by sdlime, 18 years ago

The RFC 9 proposal only applies to output via query templates and yes it would 
allow you to output 18 instead of 18.00000000. The idea of adding string 
functions to the Bison grammar would allow similar functionality for labeling.

The template idea (e.g. RFC 9) is just about ready. I just need to write a 
commify function.

Steve

comment:4 by szekerest, 18 years ago

Query template applies to the CGI Mapserver as far as I know.

Will the labelling issue be handled together or a new RFC to be added?

Tamas

comment:5 by jmckenna, 14 years ago

Cc: jmckenna added

comment:6 by dmorissette, 12 years ago

Cc: aboudreault added
Description: modified (diff)

Bump.

The need for other operators such as toupper() and tolower() came up today. I believe Steve set the bases for this in RFC-64 with the addition of a toString() function.

comment:7 by dmorissette, 12 years ago

See also ticket #4255

comment:8 by sdlime, 12 years ago

Resolution: fixed
Status: newclosed

Actually I'm going to mark this one as fixed as part of the parser re-write for 6.0. I added numeric formatting support as part of that work. Ticket #4255 is more concise and can stand on its own.

Steve

Note: See TracTickets for help on using tickets.