[mapserver-dev] RFC 54: MapServer Rendering API

Thomas Bonfort thomas.bonfort at camptocamp.com
Mon Apr 20 05:13:33 EDT 2009


Steve,

I'd also favor a rapid merge, to cut down on the branch maintainance
and get more testers to iron out bugs.
However before going that way I was hoping for some feedback on the
sanity of the proposed approach, and more specifically:
* does the API seem usable from the OpenGL implementation point of view ?
* is the raster layer handling ok, and will we manage to get some time
and/or funding to implement the change  ?

As for the instability of the current code, we worked things out with
Tamas yesterday and begun arriving to some reasonable results
(embedded legends and scalebars were wrecking havock in the internal
structures). This in any case should not be a major show stopper, as
the new code is isolated from the current mapserver API and should not
be activated unless explicitely activated in configure, and selected
from a mapfile outputformat.

>
>  - 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 ?

>  -  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" ?

>  - 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.

Best regards,

thomas

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


More information about the mapserver-dev mailing list