StrokeWidth passed as a string breaks OpenLayers 6.3.1

[richard-thomas]

When SLDReader.Reader() extracts the object from the raw XML, number are all represented as strings. I have hit a problem where strokeWidth of "0.5" passed into OpenLayers 6.3.1 ol/Style/RegularShape.js causes the calculation in render() of size to fail as "+" is taken as string concatenation instead of floating point addition. Specifically the following line in RegularShape.prototype.render() where this.radius_ = 5.5 (not a string by this point) evaluates to NaN:

    var size = 2 * (this.radius_ + strokeWidth) + 1;

If I overwrite the strokeWidth value with a numeric version before calling the styler it works fine, i.e.:

featureTypeStyle.rules[0].pointsymbolizer.graphic.mark.stroke.styling.strokeWidth = 0.5;
vectorLayer.setStyle(SLDReader.createOlStyleFunction(featureTypeStyle

For more context, my QGIS SLD output has the following star symbology:

     <se:PointSymbolizer>
      <se:Graphic>
       <se:Mark>
        <se:WellKnownName>star</se:WellKnownName>
        <se:Fill>
         <se:SvgParameter name="fill">#2bc43d</se:SvgParameter>
        </se:Fill>
        <se:Stroke>
         <se:SvgParameter name="stroke">#232323</se:SvgParameter>
         <se:SvgParameter name="stroke-width">0.5</se:SvgParameter>
        </se:Stroke>
       </se:Mark>
       <se:Size>11</se:Size>
      </se:Graphic>
     </se:PointSymbolizer>

is converted to:

{
"name":"Single symbol",
"pointsymbolizer":{
   "graphic":{
      "mark":{
         "wellknownname":"star",
         "fill":{
            "styling":{"fill":"#2bc43d"}},
         "stroke":{
            "styling":{
               "stroke":"#232323",
               "strokeWidth":"0.5"}}},
   "size":"11"}}},
{

This is running in Windows 10 on Google Chrome Version 85.0.4183.83 using SLDReader 0.2.6 which has been processed by WebPack 4.44.0.

[ajkopinga]

Thanks for the detailed bug report. That's always nice to see as a dev.

This bug should be fixed in the (recently released) 0.2.7 version of SLDReader.
Could you check if upgrading to this version solves your problem?

[richard-thomas]

Yes that solves the problem... and thanks for the quick response.
I'm trying to generate a website from QGIS - automatically where possible from data & styles written by QGIS to a single GeoPackage, but with options for manual styling overrides where automation fails. I am currently also experimenting with GeoStyler and QGIS2Web. Currently SLDReader much more accurately recreates the styles (in OL3) than GeoStyler (using SLD or QML). QGIS2Web output is generally not in a usable form for me, but seems to get some of the renderings slightly better (perhaps due to bugs in QGIS SLD-writer?). Are you happy for me to raise issues on SLDReader for such things? The obvious one that comes to mind at the moment is label placement below the above discussed "star" point symbolizer where I need to adjust SLDReader output from the (value in the SLD: 4.95) to 13 which QGIS2Web seemed to get right (setting offsetY=13 in ol/style/Text):
featureTypeStyle.rules[1].textsymbolizer.labelplacement.pointplacement.displacement.displacementy = 13;

[ajkopinga]

If the SLD specifies a y-offset of 4.95, then I'm not sure why it should be converted to 13 in the resulting OL style object. Feel free to raise a new issue if you think SLDReader does something unexpected.