[mapserver-dev] GSoC UTFGrid Project

[thomas bonfort]

Daniel,

On 8 July 2013 19:24, Daniel Morissette <dmorissette at mapgears.com> wrote:
> 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.
Yes, I don't think you can cut on that. The existing agg renderer uses
an 8bit RGBA buffer whereas you'll be writing to a single band 32bit
one (to encode the ids). You might be tempted to hack the current one
so that ids are encoded as an rgba quadruplet (as both are 32bits
wide) but that's probably asking for failure in the long run (You'll
have to rewrite most of the code anyway as you need to turn off
antialiasing).
>
> 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?
I do not think you need more than that. There's no need to encode
complex symbology as all you need is the id of the underlying feature
when you rollover a pixel. Dashed lines might need to be treated, but
that's very low priority. I think a first iteration that does solid
polygon fills, solid lines, and a bounding-box for markers and labels
will already be a significant step forward. Once that is in place, we
can easily refine (e.g. rasterize the actual shape of a circle-marker
instead of just its bounding box).



>
> 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
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev