[mapserver-dev] GSoC UTFGrid Project

Francois Desjarlais fdesjarlais1 at gmail.com
Mon Jul 8 10:42:07 PDT 2013


Hi Daniel, hi Thomas,

I already made some of the changes Thomas suggested. I removed UTFGRID from
MS_LAYER_TYPES and the code in mapimageio.c. Any comments is welcome, they
help a lot in understanding how you want the code and functions to be/work.

Thanks

Francois


2013/7/8 Daniel Morissette <dmorissette at mapgears.com>

> 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<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<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<http://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>>
>>
>
> --
> 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<http://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130708/c3fba09c/attachment.html>


More information about the mapserver-dev mailing list