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

[Stephen Woodbridge]

Thomas,

I just reread your original post and it took we a while to reconstruct 
my thinking on why I responded the way I did. My thoughts were probably 
for option 2 because I felt it would provide better quality rendering, 
but as you point out, it might (mostly likely?) is at a cost that is 
unrealistic. I do not feel strongly about this and I'm sure you have 
thought more about this problem than I have, so I am happy to go in any 
direction that you recommend.

Thanks,
   -Steve W

Thomas Bonfort wrote:
> 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)