[mapserver-dev] [Support for reading SVG symbols-MapServer-GSoC]Kiran Anjaneya Varma

Thomas Bonfort thomas.bonfort at camptocamp.com
Sun May 3 06:07:33 EDT 2009


Hi all,

I think we have three path that we could follow for incorporating SVG reading:

* add SVG as a native format that should be rendered by each renderer.
In this case, each renderer must include the logic to parse an svg
file, and then use its own rendering primitives to add shapes to its
generated image. This approach is very flexible, as each renderer can
decide if it wants to rasterize the svg symbol, or transform it into
vector primitives, or even dump the svg directly in the case of an svg
renderer. It has the downside that each renderer should carry its own
svg parser, and all svg rendering primitives.

* use a higher level svg parser, that transforms the input svg into
mapserver primitives. Unless we only support a subset of the SVG
specification (which I think is a bad idea), we would have to extend
mapserver's rendering api to support more than lines, polygons and
ellipses as it is now. (cubic and quadratic beziers, gradients,
filling rules come to mind, there are probably others)

* use an out-of-the-box svg to pixmap rasterizer, and create scaled
and rotated pixmaps at a higher level before passing them over to
mapserver's low level renderers. We would have to leverage a pixmap
cache to do this, so as not to repeat the svg parsing and rasterizing
steps. A pixmap would be put in cache for each (scale,rotation)
couple, or maybe only for each scale and rotate the created pixmap.
libsvg-cairo could be an idea to explore without adding in too many
dependencies.

a couple of thoughts:
 - Options 1 and 2 oblige us to implement our own svg parsing, which
isn't an easy task if we want to support the full svg spec.
- I wouldn't go for option 1, as it would be hell to maintain, let
alone implement.
- Option 2 would be nice, as it would open up support for more
symbology. (I'm think gradients, or postgis curves). I'm not sure the
scope isn't too far fetched for a soc project though.
- Option 3 is the easiest and least prone to failure imho.

best regards,

thomas

www.camptocamp.com
+33 4 79 26 57 97



On Fri, Apr 24, 2009 at 21:38, Daniel Morissette
<dmorissette at mapgears.com> wrote:
> Hi Kiran,
>
> Congratulations and welcome to the project. I meant to write an introduction
> email but have been too busy this week, so I'm glad you just did it.
>
> I think the first step for the project will be to define exactly what we
> mean by SVG symbol support. In your proposal you mentioned that you'd expect
> the SVG symbol to be included in the output and rendered by the browser, but
> as I think I wrote in one comment, MapServer is mostly about generating
> images, so things can't work as you expected for the image output formats
> (GIF/PNG/JPEG) which account for most usages.
>
> Instead, we'll need to find a way to efficiently parse and render the SVG
> symbol definition in a similar way to what is currently done for symbols of
> type vector in MapServer. We'll probably also need to define a subset of SVG
> that we allow for symbol definitions since we can't support the whole spec.
>
> This will require some discussion on this -dev list with the other
> developers to pick the best approach... and in the meantime, to feed this
> discussion, you could start by the following:
>
> 1- Have a look at the way vector symbols are handled in mapsymbol.c...
> browsing the source without a specific objejctive may be a bit of a rough
> start though, so perhaps just getting familiar with the use of vector
> symbols in a map would already be a good start.
>
> 2- Research and evaluate options for a non-intrusive open source library
> that can be used to parse a SVG symbol definition and render it in a
> MapServer image. By non-intrusive, I mean that the library should have a
> friendly open source license, be light-weight and ideally it should not add
> any no new dependency to the MapServer build process other than itself.
>
> 3- I wonder if Cairo or any of the new rendering stuff in the graphics
> branch could help with SVG symbols. I guess this is more a question for
> Thomas.
>
> Finally, I guess I need to do my homework as well if I want to guide you
> properly.
>
> Note to all other developers: all inputs and contributions welcome to make
> this a project a success.
>
> Daniel
>
>
>
> kiran varma wrote:
>>
>>  Hi all
>>           I am A Kiran Anjaneya Varma 3rd year undergraduate ,my
>> proposal[Support for reading SVG symbols-MapServer] has been accepted as
>> part of GSoC  2009
>>         My mentor is Mr.Daniel Morissette
>>         Thank you  for accepting me as part of your reputed MapServer
>> project,I am very keen in working on this project .
>>         So what is my next step for having a good start on the project, I
>> would also like to know about some of the sources and suggestions through
>> which i can get a good flexibility on my project before coding day(May 23)
>>
>>
>> looking forward to work successfully with u throughout this wonderful
>> summer
>>
>> Thanks regards
>> A Kiran Anjaneya Varma
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
> --
> Daniel Morissette
> http://www.mapgears.com/
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>


More information about the mapserver-dev mailing list