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 _______________________________________________ Users mailing list Users@openlayers.org http://openlayers.org/mailman/listinfo/users