[OpenLayers-Users] Strange. Labels treated as numbers

[Christopher Schmidt]

On Wed, Sep 02, 2009 at 01:35:30PM +0200, Andreas Hocevar wrote:
> Christopher Schmidt wrote:
> > On Fri, Aug 28, 2009 at 08:52:11AM +0200, Arnd Wippermann wrote:
> >   
> >> Hi,
> >>
> >> I want to label features by the attribute name ( label:"${name}" ). The
> >> labels should be 06.01, 06.10, 06.080 etc.. But displayed as labels are
> >> this: 6.01, 6.1, 6.08.
> >>
> >> Looking at the code I get no idea, where the place that cause this
> >> behaviour. Can someone help.
> >>
> >> Here is an example of this behaviour:
> >> http://gis.ibbeck.de/ginfo/apps/OL27Client/OL28ClientGis.asp?WMC=./data/WMC/
> >> strange%20labels.wmc.xml
> >>
> >> The black and red labels comes from equal attributes. Only the point is
> >> changed with a comma.
> >>     
> >
> > Looks like the text is being treated as a number at some point.
> > Specifically:
> >
> > OpenLayers.Style.createLiteral = function(value, context, feature) {
> >     if (typeof value == "string" && value.indexOf("${") != -1) {
> >         value = OpenLayers.String.format(value, context, [feature]);
> >         value = (isNaN(value) || !value) ? value : parseFloat(value);
> >     }
> >     return value;
> > };
> >
> > Seems like that's slightly overzealous; not sure why we're parseFloating
> > the value? (This comes down, to an extent, to OpenLayers not having
> > strongly typed data parsing, so we don't know that something should or
> > shouldn't be a number.)
> >   
> 
> The reason is that there are some symbolizer properties that only work
> with numbers in IE (e.g. graphicWidth and graphicHeight).
> 
> > I'd be in favor of dropping the parseFloat entirely, but I'm not the one
> > who put it there :) (Okay, literally speaking, I *did* put it there,
> > with my commit in r5429, but I don't think I wrote that code myself.)
> >   
> 
> In a perfect world, this parseFloat would be done in the renderer, so
> this issue deserves a ticket (Arnd, would you be so kind and create one?).
> 
> > Andreas, can you explain why this is here? And is it possible we could
> > somehow make it optional? 
> >   
> 
> Why is it there? This code was written at a time where there were no
> text labels, so it was easiest to put it there.

actually, "graphicWidth and graphicHeight require numbers" is a perfectly
fine reason :) Thanks for the explanation, and suggestion for improvement.
 
Regards,
-- 
Christopher Schmidt
MetaCarta