[mapserver-dev] UTFGrid support

thomas bonfort thomas.bonfort at gmail.com
Sat Jul 27 01:10:05 PDT 2013


Hi Francois,
I've had a look at your progress and you seem to be advancing along
nicely, congratulations. Just a few quick remarks:

- you still have a reference to an aggFakeOutput. Can you confirm that
this is left-over code from the initial implementation and that it
will go away in the final implementation.
- I see you're going to start working on symbols. Unless/Until you
have nothing else to advance on, I would not bother going into the
details of each individual function (ellipse, vector, svg, etc...) and
instead create a single helper function that encodes the bbox and use
that for all symbol types. You can always come back in a later phase
to refine those if needed, but it at least immediately gives us a
working feature for all symbol types. Definitely do not work on
truetype symbols (c.f. next point).
- Don't spend too much time on anything related to text/truetype, as
the renderer vtable signatures for those will change entirely in
master. For the time being there is a *single* text rendering function
( https://github.com/tbonfort/mapserver/blob/rfc98-rebase/mapagg.cpp#L571
), that we'll probably have to extent to include a reference to a
shapeObj for marker symbols so that you can access the utfitem/id .

I've got a bot more time now to help out, don't hesitate to ping me.

cheers,
thomas

On 13 July 2013 11:15, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> Sorry, not much time to give details...
>
> On 11 July 2013 17:47, Francois Desjarlais <fdesjarlais1 at gmail.com> wrote:
>> Hi Thomas,
>>
>> I worked a lot in the UTFGrid renderer recently and I have a question about
>> AGG to ask you. First, you wrote to Daniel in your latest discussion about
>> UTFGrid that it was possible to use AGG with int32u instead of colors. But
>> going through AGG doc, I can't find any mention to it. Is changing the
>> rendering buffer type from colors chars to int32u really going to make it or
>> is there more thing to change like pixel_format and color_type? If so is it
>> possible to generate any color_type and pixel_format from template because
>> those already in place only use color chars.
>
> You'd have to change the whole chain of agg templating to use int32u
> and other relevant typedefs for a grid renderer. You should probably
> have a look at the mapnik grid renderer for inspiration. Once again
> the utfgrid renderer and the current mapserver agg renderer have very
> little in common aside from the fact that they are using agg
> primitives as a backend (and given that agg is so flexible due to it's
> usage of templates, that means not much in common at all).
>
>>
>> Also, in your recommandation mail you wrote:
>> "you should not be messing with map->cellsize, scale, width, height,etc...
>> inside mapdraw.c. Your utfRes adjustments should be private to the
>> utfrenderer."
>> But the image width, height and resolution are set outside the createImage
>> function in the mapdraw.c. The image variables are set directly from the map
>> such as image->resolution = map->resolution. If I try to set my own width,
>> height and res they get overwritten by those right outside the createImage
>> function. I know AGG don't set these inside its createImage but is it the
>> same with every renderer? If it isn't the same with every renderer, is it
>> possible to move that code inside AGG so image variables don't get
>> overwritten after they get out of createImage?
> c.f AGG_RENDERER(image) in which you can assign a structure that's
> private to your renderer. You would typically be storing the utfRes in
> there, to pass as a parameter to your path_adaptor so it applies the
> wanted scaling. (e.g. in mapagg.cpp, bool use_alpha is a private
> bookkeeping variable to indicate wether we should be exporting an
> alpha channel or not)
>
>>
>> Thanks!
>> Francois
>>
>> _______________________________________________
>> 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