[mapserver-dev] GSoC UTFGrid Project

[Daniel Morissette]

Hi Thomas,

Thank you for your comments on the code. FYI, this François first stab 
at getting some UTFGrid data out, and the next step was a full code 
review of what he did to adjust the direction, so your comments come at 
the right time.

Without having fully reviewed the code myself yet, I agree with most of 
your comments, except for the one about "creating a full-fledged 
outputformat with its own rendererVtable". François' outputformat does 
have its own vtable (at the bottom of maputfgrid.c), but it tries to 
wrap calls to mapagg.cpp vtable functions to rely on existing mapagg.cpp 
code instead of rewriting all rendering methods from scratch.

Are you suggesting that maputfgrid.c should be reimplementing all 
methods based on direct calls to AGG? Simple polygon fills are 
straightforward and could have been done easily without relying on 
mapagg.cpp, but when it comes to rendering more complex symbology 
(complex symbols, dash lines, etc.) I would have thought that reusing 
code from an existing renderer if possible would be a better approach. 
Or did I misunderstand what you meant? Are you suggesting that we should 
ignore complex symbology and just support solid fill, solid lines and 
simple point symbols?

Thanks

Daniel


On 13-07-06 5:50 AM, thomas bonfort wrote:
> Hi Francois, welcome to the team!
>
> Here are a few comments regarding the code you have published in your branch:
>
> - Why are you adding a UTFGRID entry to MS_LAYER_TYPES? Layer types
> should not need to be extended as utgfgrid is an outputformat that
> should apply to existing layers.
>
> - Using aggFakeOutput  inside your UTFGridRenderer does not seem like
> the way to go. I believe you should be creating a full-fledged
> outputformat with its own rendererVtable
>
> - why the WITH_AGG_ALIASED option to cmake? You'll need a specific agg
> renderer for utfgrid support (which you are correct will need to be
> aliased). The only cmake option I would see would be to eventually be
> able to disable utfgrid support completely (and given that there
> should be no dependencies, I'm not sure that is needed).
>
> - you must not export a "rasterbuffer" and add code to mapimageio.c
> for saving as json. Implement your own saving functions inside the
> utfgrid renderervtable. (c.f. the vector vtables in mapcairo.c), and
> publicize you do not support a rasterbuffer.
>
> - you should not be messing with map->cellsize, scale, width, height,
> etc... inside mapdraw.c. Your utfRes adjustments should be private to
> the utfrenderer.
>
> cheers,
> thomas
>
> On 5 July 2013 21:36, Francois Desjarlais <fdesjarlais1 at gmail.com> wrote:
>> Hi everybody!
>> Like Daniel said I'm François Desjarlais, 3rd year computer engineering
>> student. I just wanted to add a little something to what Daniel wrote.
>> Instead of mapbox example, you can look at my own example on
>> http://msgsoc.mapgears.com/projet_utfgrid/testhtmlmapserver.html. It's a bit
>> buggy right now but as summer will go on it will get better.
>>
>> Also, I have a question. Daniel told me that Steve Lime could answer:
>>
>> Steve,
>> What is UTFITEM function? I read the RFC-93 multiple times and I can't
>> figure what it does. It's doing the same thing as UTFDATA because datas are
>> linked with shapes. And if you don't need certain datas you just remove them
>> from UTFDATA instead of adding syntax with UTFITEM.
>>
>> Thanks!
>> Francois
>>
>>
>> _______________________________________________
>> 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
>


-- 
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000