[mapserver-dev] RFC 54: MapServer Rendering API

[Thomas Bonfort]

On Mon, Apr 20, 2009 at 6:21 PM, Steve Lime <Steve.Lime at dnr.state.mn.us> wrote:

> Do you have a feel for how the raster code would have to be changed? Seems like it
> would have to be able to write to a GD buffer and rasterBufferObj. I guess that's why you
> reference time and/or $'s for that change.

Yes, the gd specific code would have to be kept. The raster code would
have to be modified to write to an arbitrary buffer with the obly
knowledge of the byte ordering, and pixel and row stride.


>>>  - how should renderer options be encoded in an output format (presumably
>> not
>>> as a format option, perhaps a new renderer option (hash?))
>> formatoptions aren't ideal, but these options would mostly be specific
>> to each renderer. What are you thinking of when talking of a hash ?
>
> I was thinking of this, in mapfile syntax:
>
> OUTPUTFORMAT
>  ...
>  RENDEREROPTIONS
>    'key' 'value'
>    ...
>  END
> END

Yes, that sounds reasonable. The current formatoptions could
internally be in there to (and decide if we keep backwards
compatibility on the formatoption keyword in the mapfile)

>
>>>  -  what will the make-up of the more specific rendering objects such as
>> line styles
>>> look like?
>> Not sure I understand your question here. What do you mean by "make-up" ?
>
> The RFC references objects like 'strokeStyleObj' and 'symbolStyleObj', what will
> those look like?

strokestyleobj contains color, width, pattern and caps/joins.
symbolstyleobj  contains scale and orientation, colors and outlinewidth.
labelstyleobj  contains the full path to the font, size, orientation,
color and outlinecolor (shadowcolor could be included too, or factored
out a level above)

>
>>>  - reference maps are still necessary but I think we could attack them by  turning a
>>> request for one into an internal mapfile and handing it off to the renderer.
>>
>> The scale, legend and overview will be needing some major refactoring
>> anyways, but this will be probably be done in a second phase once the
>> rest of the api has stabilized.
>
> The legend and scalebar will be hard since they have significant layout tasks
> associated with them.
It won't be trivial, but nothing too difficult I think.


thomas

-- 
www.camptocamp.com
+33 4 79 26 57 97