[mapserver-dev] Mapserver numeric formatting of labels
Tamas Szekeres
szekerest at gmail.com
Fri Dec 10 13:31:43 EST 2010
Steve,
Thanks for the update this was really helpful.
Best regards,
Tamas
2010/12/10 Lime, Steve D (DNR) <Steve.Lime at state.mn.us>
> The work for RFC 64 has support for this already. I’ll have to go back to
> my notes for more detail but I think this is correct:
>
>
>
> Case 1: using LABELITEM… In this instance you get the full representation
> of the of the number according to the DBF definitions. If you access a
> numeric column in string context in an logical expression you’ll also get
> this (e.g. ‘[numcol]’).
>
>
>
> Case 2: using TEXT expression with no transformation and numeric context
> (e.g. TEXT ([numcol])). This forces the number through the new expression
> handling. In this case we have to do a conversion from a number to a string
> and the default format I chose was “%g” which results in some relatively
> reasonable trimming.
>
>
>
> Case 3: using TEXT expression with transformations. I added several
> functions to the parser to help in this regard:
>
>
>
> Round(num, num) (e.g. round([numcol], 2))
>
> Tostring(num, format) (e.g. tostring([numcol], “%.2f”), note this
> truncates so you might want to round and then convert to string)
>
> Commify(string) (e.g. commify(‘[numcol]’), typically you’d do this after
> converting to a string so 20000.00 would become 20,000.00)
>
>
>
> It’s pretty flexible although there’s almost certainly room for
> improvement.
>
>
>
> Steve
>
>
>
> *From:* mapserver-dev-bounces at lists.osgeo.org [mailto:
> mapserver-dev-bounces at lists.osgeo.org] *On Behalf Of *Tamas Szekeres
> *Sent:* Friday, December 10, 2010 12:07 PM
> *To:* mapserver-dev at lists.osgeo.org
> *Subject:* [mapserver-dev] Mapserver numeric formatting of labels
>
>
>
> Hi All,
>
> Do we have any plans to support numeric formatting when rendering labels
> from layer attributes? As far as I remember we had such plans for 6.0, but
> I'm not sure whether anyone is working on that actually or not.
> Any idea for a reasonable approach would also be helpful.
>
>
> Best regards,
>
> Tamas
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20101210/2a92fa75/attachment.html
More information about the mapserver-dev
mailing list