[mapserver-dev] GSoC UTFGrid Project

thomas bonfort thomas.bonfort at gmail.com
Mon Jul 8 11:50:33 PDT 2013

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.


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

More information about the mapserver-dev mailing list