Output handling (was Status of AGG support?)

[Steve Lime]

I do think we'll need to do something with output handling in post 5.0 releases, it
is a bit untenable. Part of the issue is that we have many ways to output information:

via OUTPUTFORMAT, that is, renderers that draw features, use mapserver styles and
place labels, e.g. GD, AGG, GDAL, PDF, SWF, SVG, Imagemap. Very flexible, uses [shpxy...]
tag but requires knowledge of a format. Also 1 layer can have 1 template, which sucks.

via TEMPLATEs, adhoc text-based formats that are produced as the result of queries,
mapserver styles are not uses, label points are not computed, e.g. HTML, imagemaps,
KML, SVG, GML, GeoRSS, XML...

via GML from WMS/WFS, configurable text-based format that is the result of queries, no
styling and no label placement. Sort of sits there on it's own.

Ideally these could somehow merge. For example, might be nice to be able to serialize
MapServer styles/symbols as SLD or SVG styles for use in templates. Or allow template
defs in OUTPUTFORMATS. Also need OUTPUTFORMATS that are used solely for query
presentation (a draw is really just post query processing).

Anyway, there are lot's of opportunities here. We need to make formats like KML, and 
GeoRSS easier to produce.

Steve

>>> Tamas Szekeres <szekerest at GMAIL.COM> 07/03/07 3:42 PM >>>
OT: I wish we ever had a common interface how the various renderers
are connected to mapserver. The number of the elseif-s are increasing
forcefully when a new renderer is added. One or 2 more renderers in
the future will make the project pretty unfollowable.

Would it make sense to isolate the common simple tasks related to the
renderings in mapserver? We could possibly set up a vtable with these
functions and call the various kind of the renderers based on this
vtable. In addition the renderers should use a common repository of
the private data (like the layerinfo of the providers) to keep the
structures as simple as possible.

We should also consider the renderers to be pluggable so as to provide
the 3rd party or platform dependent renderers (like Windows GDI) come
into the picture easily.

Best regards,

Tamas



2007/7/3, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> Hi Tom: AGG support is in the codebase for 5.0. I still owe an RFC to explain what was
> done although the addition of AGG doesn't affect any other portions of MapServer. It's
> a big user feature though. I recently got a big time sink off my plate and will work that up
> ASAP.
>
> The support is relatively complete. The guys from DM Solutions can probably comment
> further as they've been using it the most. The AGG vs. GD images DM has supplied are
> very nice. The quality difference is noticeable with roads in particular.
>
> The only missing capability that I am aware of has to do with PIXMAP symbols that contain
> an alpha channel. There is a fundamental difference in how AGG and GD handle alpha
> blending (GD is flat out backwards).  We use GD to manage the pixel buffer that AGG is
> rendering into so that becomes a problem. I'll go into options in the RFC.
>
> Anyway, other than that the support seems to be working nicely is worth trying.
>
> Steve
>
> >>> On 7/1/2007 at 10:08 PM, in message
> <7b5b710d0707012008i59c41e8bq8e0ef4d8022f40f8 at mail.gmail.com>, Tom Beard
> <tom at PROJECTX.CO.NZ> wrote:
> > Hi there,
> >
> > This is my first time posting here, and I hope this is the right forum to
> > ask this question.
> >
> > I was wondering what the status of AGG support was for the 5.0 release. On
> > searching the archives, the most recent reference I could find was the
> > minutes from the May 22 IRC meeting that said that there would be an RFC
> > freeze on June 15, and that an RFC for AGG was "forthcoming". Did AGG
> > support make it into that freeze? Is it listed somewhere online?
> >
> > I'd also be interested to know if there is a version currently in Subversion
> > that includes AGG sub-pixel rendering and that works well enough to have a
> > go at compiling on Windows.
> >
> > Regards,
> >             Tom Beard
>