SLD export does not account of attribute based symbology

[qgib]

Author Name: Andrea Aime (@aaime) Original Redmine Issue: 15430 Affected QGIS version: master Redmine category:symbology

---

Several of the styling properties can be linked to attributes or built using expressions. SLD has the same ability (since SLD 1.0 and onwards) but the SLD exporter ignores attribute/expression and falls back on static values instead

---

Related issue(s): #22172 (duplicates) Redmine related issue(s): 14170

---

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Hi,

I just noticed that when exporting rule based symbology to SLD where there is a rule where the filter is "ELSE" (to define a symbology class that must be applied when features do not match previous expressions) the "ELSE" is always stripped from the resulting SLD

<se:Rule>
          <se:Name></se:Name>
          <!--Parser Error: syntax error, unexpected ELSE - Expression was: ELSE-->
          <se:PolygonSymbolizer>
            <se:Fill>
              <se:SvgParameter name="fill">#9a5ceb</se:SvgParameter>
            </se:Fill>
            <se:Stroke>
              <se:SvgParameter name="stroke">#000001</se:SvgParameter>
              <se:SvgParameter name="stroke-width">1</se:SvgParameter>
              <se:SvgParameter name="stroke-linejoin">bevel</se:SvgParameter>
            </se:Stroke>
          </se:PolygonSymbolizer>
</se:Rule>

When re-used in QGIS the result is a rule with no filter "ELSE", so this symbology class will always be applied to all features.

Is the same issue described in this ticket?

I also noticed that in recent QGIS releases the tickness of polygons border lines is exported bigger than should be. At least up to QGIS 2.8.* this was working as expected.

[qgib]

Author Name: Andrea Aime (@aaime)

---

The use case above is for "", not linked to property based symbology as I defined it above (as in, having a single property, e.g., thickness, use directly an attribute).

About the thickness, it was too small before, and has been fixed, at least when you are exporting while the properties are defined in mm, since SLD only knows about pixels. If you have a case where the unit is pixels and it's not exported using the correct value please open a separate ticket (I do not monitor redmine btw, better discuss also on the list).

[qgib]

Author Name: Alessandro Pasotti (@elpaso)

---

This is a duplicate of #22172

---

• resolution was changed from to duplicate
• status_id was changed from Open to Closed

[qgib]

Author Name: Andrea Aime (@aaime)

---

I believe this report got misunderstood and wrongly closed.... this was was about symbols using attributes directly for widths, colors, shapes (e.g., fillColor = myFeatureAttribute), not about using filters to match them. The expression is in the symbolizer here, not in the filter.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• status_id was changed from Closed to Reopened
• resolution was changed from duplicate to

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• regression was configured as 0
• easy_fix was configured as 0

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Please check if this issue is still valid on QGIS 3.4.5 or 3.6.

---

• status_id was changed from Reopened to Feedback

[geraldo]

So right now none of the symbology expressions are exported, they are all ignored when exporting SLD. This is also true for pyqgis API calling saveSldStyle.

This makes it impossible to use for example scale based symbology with SLD as <MinScaleDenominator> and <MaxScaleDenominator> aren't used. Here a simple expression which I use:

CASE 
WHEN @map_scale < 1500 
THEN  8
WHEN @map_scale >= 1500 and  @map_scale < 3500 
THEN 6
ELSE 4
END

Probably worth to mention that there is this QEP proposing the overall quality of SLD in QGIS, which probably would be important to implement before adding new functionalities.

[gioman]

Probably worth to mention that there is this QEP proposing the overall quality of SLD in QGIS, which probably would be important to implement before adding new functionalities.

@geraldo QGIS development is driven by the necessity of its users, especially the ones that are willingly to commit resources to make happen such developments. Truth is that there was always some interest around SLD support in QGIS but evidently not from users/organizations willingly to commit.