[mapserver-dev] SVG symbols with modifiable parameters

Tamas Szekeres szekerest at gmail.com
Wed Sep 11 11:41:01 PDT 2019


Hi Seth,

Naming the styles would make sense in some use cases, but with this
approach we would address to use a complex symbol definition within
multiple styles. Why don't we separate that complex definition to multiple
SVG-s which would then be assigned to multiple styles, which is a common
mapserver-ish way to implement complex symbology for the layers.

Best regards,

Tamas


Seth G <sethg at geographika.co.uk> ezt írta (időpont: 2019. szept. 11., Sze,
14:16):

> From a purely Mapfile syntax point of view it would be nice to add in
> named styles (as per https://mapserver.org/mapfile/style.html#style - The
> final intent is to have named styles (*Not yet supported*) that will be
> re-usable through the mapfile).
>
> Then for SVG the following syntax could be used, with the name used to
> match an SVG parameter name:
>
> STYLE
>   SYMBOL 'some-svg-symbol'
>   NAME 'color1'
>   COLOR 255 0 0
> END
> STYLE
>   SYMBOL 'some-svg-symbol'
>   NAME 'color2'
>   COLOR 0 255 0
> END
>
>
>
> On Wed, Sep 11, 2019, at 7:01 AM, Lime, Steve D (MNIT) wrote:
>
> 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:
>
> STYLE
>   SYMBOL 'some-svg-symbol'
>   SIZE 10
>   OPTIONS
>     'color1' 'red'
>     'color2' 'green'
>   END
> END
>
>
> --Steve
>
> ------------------------------
>
> *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
>
> Hi,
>
> 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?
>
> http://blog.ch/2011/06/30/svg-symbols-in-qgis-with-modifiable-colors/
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.sourcepole.ch%2F2011%2F06%2F30%2Fsvg-symbols-in-qgis-with-modifiable-colors%2F&data=02%7C01%7Csteve.lime%40state.mn.us%7Cb40a05dc806743f8ca7608d731fca1ca%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1%7C637032833418334660&sdata=UXiBHDUUxJgYY%2BAdS4s51u6EltjBGhr6Ywha3z91Eio%3D&reserved=0>
>
>
> 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,
>
> Tamas
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20190911/d09f27e3/attachment.html>


More information about the mapserver-dev mailing list