[mapserver-dev] RFC 54: MapServer Rendering API

[Tamas Szekeres]

I would rather in favour of merging the trunk back to the sandbox first, and
do some testings in place (either by adding some stuff to the msautotest as
well).
Then if we get rid of the potential issues (build problems, memory
corruptions, segfaults)  we can safely add the stuff in the trunk
permanently.

Currently I find several issues either with the simplest mapfiles that
should somehow be fixed first. The opengl support didn't work for me at all,
it seems the implementation didn't follow the recent changes of the vtable
names caused compiler errors. It may also be required to install some
additional things that I'm currently not aware of.
I've fixed up the most alloying issues and the sandbox now compiles on
windows. I also advertised ready to use windows binary packages for the
users to be able to test with on the mapserver-users list.

Best regards,

Tamas





2009/4/19 Steve Lime <Steve.Lime at dnr.state.mn.us>

> My feeling is we should go with the merge now and work out any details
> where
> there are divergent paths (such as caching) later. We need this addition.
> Some
> of my comments were related to detail such as:
>
>  - how should renderer options be encoded in an output format (presumably
> not
> as a format option, perhaps a new renderer option (hash?))
>  -  what will the make-up of the more specific rendering objects such as
> line styles
> look like?
>  - 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.
>
> So, I'm +1 for the merge ASAP.
>
> Steve
>
> >>> thomas bonfort <thomas.bonfort at camptocamp.com> 04/17/09 10:49 AM >>>
> Hi devs,
>
> RFC 54 has just been committed to the docs site:
>
> http://mapserver.org/development/rfc/ms-rfc-54.html
>
> I've tried to be as complete as possible, but I'm quite sure I may
> have missed a couple (I hope minor) points.
>
> Most of the RFC is implemented in the graphics sandbox. It  would be
> great if some of you could try it on your local mapfiles to squeeze
> out as many bugs as possible (currently not activated/implemented are
> symbology on lines and polygons, and all the raster layer related code).
> To enable the plugin code, you need to configure with --with-cairo.
> The outputformat drivers are cairo/png , cairo/jpeg, cairo/svg and
> cairo/pdf.
>
> Ideally I'd like to merge the graphics branch into the trunk around
> the end of the month so we have more eyes on it before our september
> release target.
>
> Best regards,
>
> thomas
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20090419/df525d13/attachment.html