[mapserver-dev] GSoC UTFGrid Project

[thomas bonfort]

Daniel,
The code in mapagg.cpp is templated, and as you need to use a
specialized path_adaptor (to account for the utfres scaling), a
specialized rasterizer, a specialized renderer, etc... you only ending
up having a big if(antialiased) { actual code } else { new code } in
each function.
As for the "second class" I would not worry about that. As I said
adding more functionality inside the utf renderer will be easy if
needed. Imo there are a number of other issues outside of the agg utf
renderer that need to be tackled before worrying about these details.

--
thomas

On 8 July 2013 20:25, Daniel Morissette <dmorissette at mapgears.com> wrote:
> On 13-07-08 1:55 PM, thomas bonfort wrote:
>>
>>
>> A *very strong* +1 at writing your own agg code. There is going to be
>> so very little overlap between the rgba and int32 renderers that it's
>> not worth going into the pain of making mapagg.cpp do both.
>>
>
>
> I should feel better in light of such a strong position, but unfortunately,
> I fear that going down that road we're going to end up duplicating most of
> mapagg.cpp in maputfgrid.c. To avoid that duplication of code I sure wish
> there was a way to treat rendering using int32 ids just as a special case of
> rgba rendering (is encoding ids as rgba quadruplets really that bad an
> idea?).
>
> What I envision down the road for utfgrid is not a second class output
> driver that ignores most symbology options, but a fully featured driver that
> properly handles vector symbols and labels as real shapes with an outline
> (and not just square boxes), dash lines, line ends, etc.
>
> When we look at a map at small scale, ignoring those rendering details is
> not a problem, but I can already hear complaints that when people zoom in
> and the symbols or labels become larger, the huge invisible box around the
> point symbols/labels prevents the ids of the other underlying features from
> getting through, same with dash lines, line ends and other rendering
> details.
>
> Maybe I should not worry about full support and just keep it simple...
>
>
> --
> Daniel Morissette
> http://www.mapgears.com/
> Provider of Professional MapServer Support since 2000
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev