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

Sun May 3 09:53:28 EDT 2009

Thomas,

Great summary. So it sounds like if we were not constrained by trying to 
size this to GSoC effort, that we would probably decide to go with 
option 2. Well I would be inclined to go that direction based on your 
analysis.

What would people think of pushing forward on option 2 as the overall 
mapserver plan and scoping the GSoC into a subset of that plan. I'm have 
no idea if this would be doable scope wise, but a natural subset might be:

a. implement an svg subset that maps to the existing render mapserver 
renderer API for GSoC
b. if time permits do a simple extension to the mapserver render API and 
svg parser
c. complete the project of extenting the mapserver render API and svg 
parser in subsequent, funded? efforts.

Regards,
   -Steve W

Thomas Bonfort wrote:
> 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
>>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev