[mapserver-dev] SVG symbols with modifiable parameters

Lime, Steve D (MNIT) steve.lime at state.mn.us
Tue Sep 10 22:01:13 PDT 2019

Hi Tamas: I think something like this would be super useful. Currently MapServer does not load (directly) or parse the SVG. It's relying on svg-cairo or rsvg for that. So to support parameters one would need to parse and then process the XML looking for parameters. To avoid doing this for every file I'd thinking adding something to a symbolObj to trigger the extra processing might be a possibility. Any chance svg-cairo or rsvg support this (where you'd pass a key/value store along with the filename)?

I was wondering how you'd store the colors, etc... within the mapfile. I don't think that it makes sense to bind it to a styleObj as is. Not enough flexibility for symbols with multiple colors or whatever, plus I'd assume you'd want the flexibility to use SVG files that already define parameter names. So, I'd think we would need to use a hash within the styleObj to hold the configuration parameters something like:

  SYMBOL 'some-svg-symbol'
  SIZE 10
    'color1' 'red'
    'color2' 'green'


From: mapserver-dev <mapserver-dev-bounces at lists.osgeo.org> on behalf of Tamas Szekeres <szekerest at gmail.com>
Sent: Thursday, September 5, 2019 7:28 AM
To: mapserver-dev at lists.osgeo.org <mapserver-dev at lists.osgeo.org>
Subject: [mapserver-dev] SVG symbols with modifiable parameters


I have a requirement to be able to modify some parameters of the SVG symbols according to the parameters of the corresponding style in the mapfile configuration. This would provide significant help to avoid maintaining large number of SVG definitions with the same shape, but different colors or line widths. Or one could also replace the truetype symbols with the SVG variants if needed.

Would that be reasonable to implement something like this?


I think we could easily modify the SVG definition in msPreloadSVGSymbol, where the symbol definition would be loaded and modified in a local buffer before passing that to the renderer.

Best regards,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20190911/85aa3003/attachment.html>

More information about the mapserver-dev mailing list