Bug report #21686

SVG Point symbols missing in GetLegendGraphics Responses

Added by Andreas Neumann almost 2 years ago. Updated almost 2 years ago.

Assignee:Alessandro Pasotti
Category:QGIS Server
Affected QGIS version:3.6.1 Regression?:Yes
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:invalid
Crashes QGIS or corrupts data:No Copied to github as #:29502


In QGIS Server 3.6 (most likel also in mater, but not tested), GetLegendGraphics response images do not correctly display our SVG symbols in the GetLegendGraphics image.

Simple shape symbols (e.g. the red circle for category 'Bahnhof' are correctly displayed, but, SVG symbols not.

In the GetMap request, the SVG symbols are correctly rendered.

URL to QGIS 3.6 based WMS service: https://services.geo.zg.ch/ows/TestSVGSymbols

I don't know exactly if this is a general QGIS server 3.x problem or specific to our Docker/NGINX configuration?

GetLegendGraphicsProblem.png - GetLegendGraphics-Screenshot showing that SVG symbols are missing (22.6 KB) Andreas Neumann, 2019-03-28 11:31 AM

TestSVGSymbols.qgs - Project File (32.2 KB) Andreas Neumann, 2019-03-28 11:32 AM

haltestellen_1700.backup - Postgis DB-Dump (12.2 KB) Andreas Neumann, 2019-03-28 11:37 AM


#1 Updated by Andreas Neumann almost 2 years ago

  • Subject changed from Point symbols missing in GetLegendGraphics Request to SVG Point symbols missing in GetLegendGraphics Responses

#2 Updated by Alessandro Pasotti almost 2 years ago

  • Assignee set to Alessandro Pasotti
  • Status changed from Open to Feedback

I'm not really sure about how to fix this, and even if that's a bug: the issue is triggered by the symbol renderer which has a data-defined property on symbol size wth an expression that is based on @map_scale property.

But, in case of a getlegendgraphic request, there is no map and there is no map_scale so the expression evaluation obviously fails, in other words, the getlegendgraphic request does not have all the information required to calculate the map_scale and to determine the symbol size.

I'm not sure about the best approach here. I could try to fake the request and inject a map_scale into the context based on server full extent and an arbitrary map size that makes sense on the web (1024x768?).

Another option would be to ignore the data-defined property in case the context does not contain the information required to compute the expression successfully (but this would mean messing up with core routines of symbol drawing and I don't really recommend it, I'd rather prefer a server-only patch to handle this case).

I'll try the server approach first.

#3 Updated by Alessandro Pasotti almost 2 years ago

  • Resolution set to invalid
  • Status changed from Feedback to Rejected

Ok, after some more thoughts and an enlightning talk with Nyall, I decided that this is not a bug.

The behavior of expression evaluation is designed to not raise an exception when a variable is undefined but evaluate it to NULL instead.

This means that in the attached test case, the last rule (ELSE) is triggered and it returns a 0 as the symbol size.

The solution is to add an extra case to the expression:

WHEN @map_scale <= 2000 THEN 9
WHEN @map_scale > 2000 AND @map_scale <= 5000 THEN 8
WHEN @map_scale > 5000 AND @map_scale <= 10000 THEN 7.5
WHEN @map_scale > 10000 AND @map_scale <= 20000 THEN 6.5
WHEN @map_scale > 20000 AND @map_scale <= 100000 THEN 6
WHEN @map_scale > 100000 AND @map_scale <= 200001 THEN 5.5
WHEN @map_scale IS NULL THEN 8

#4 Updated by Andreas Neumann almost 2 years ago

Hi Alessandro,

Just tested.

Yes - introducing the ELSE rule with a non-zero size value fixes the issue.

Thanks for investigating!


Also available in: Atom PDF