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

[Thomas Bonfort]

On Sun, May 3, 2009 at 15:53, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> 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.
I'm not sure it's the best solution. In the long run, it probably
means modifying all the input drivers as we would have to stop using
shapeObjs as we do now for some other representation that also encodes
curves. I don't think the benefit is worth the effort given the little
existing data that uses this representation.

>
> 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
the problem I see here is that implementing half of the spec is
probably worse than not implementing it at all. I would hate as a user
to have created an svg symbology only to see only a part of it appear
on my maps.

> 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.
Unless we have funding this is too big of a task to leap into, as it's
solving a problem (I think) nobody has. If and when the time comes
where the need for these features arises, it wouldn't overwhelming to
create an svg parser to use them.

Until then it seems to me that what we want is to be able to specify a
scale independant advanced symbology, no more. Going for option 2
would probably be better in the long run, but a more pragmatic
approach is option 3.

regards,
Thomas (no strong feelings on this one, I'd gladly be contraticted)