MetaWriters status in master

[springmeyer]

The recent refactoring of the compositing branch, which implemented vertex_converters lead to the removal of the writers from the AGG rendering code. @artemp did not see a clean/viable way to keep them coupled with the AGG code, and feels they should be in their own renderer.

@herm - what is your long term thinking on MetaWriters? Are you keen to continue maintaining them, and their development? Are you aware of current users depending on their functionality?

My feeling is that we need to restore their functionality before 2.1 release. @artemp's judgement will be final word on this, but we should discuss here to flesh out a plan.

[springmeyer]

bump @herm, @artemp

[herm]

I don''t think creating a new renderer for metawriters is a good idea. One would loose many of the benefits metawriters currently have:

• It is guaranteed that their output always matches the output from the rendering run. The data in the database could change between the run of the graphical renderer and the metawriter renderer otherwise. Also different renderers currently render different output images because they don't share the rendering logic. Instead it is copy&pasted between renderers often resulting in differences. This could be fixed but would require a large redesign of mapnik's rendering code.
• There is almost no performace cost when metawriters are enable because data is already fetched from the database and processed. This work is duplicated with metawriters being a separate rendering process
• Currently one can easily add metawriter so an existing stylesheet but one would have to write a new one to only include feature with metawriters to make them work with the new design. This again introduces the problem of getting out of sync with the main stylesheet.

[artemp]

@herm - I hear what you're saying!

My issues with current implementation :

• muddles logically independent concepts together
• too intrusive at source (implementation) level
• there is no way to disable metawriters completely
• LineSymbolizer need to output outline polygons to be useful

Some of these can be solved by re-using data querying and processing logic between rendering backends - see #1254

[springmeyer]

I feel strongly that for the upcoming release we should disable metawriters completely to avoid confusion over the broken support. We can re-enable in a new form when #1254 lands, but until then it would be best for users to stick with Mapnik 2.0.2 if they wish to use metawriter functionality.

[artemp]

On 15 August 2012 01:25, Dane Springmeyer notifications@github.com wrote:

I feel strongly that for the upcoming release we should disable
metawriters completely to avoid confusion over the broken support. We can
re-enable in a new form when #1254https://github.com/mapnik/mapnik/issues/1254lands, but until then it would be best for users to stick with Mapnik 2.0.2
if they wish to use metawriter functionality.

Agree! Done in aecf053

Artem

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1240#issuecomment-7744805.

[herm]

aecf053#commitcomment-1746171

[herm]

@artemp: Could you please comment on what the plan is for re-enabling or removing metawriter support?

[artemp]

@herm - current plan is to re-implement 'feature_style_processor' to work with multiple rendering backends. So user will be able to construct 'multi' renderers (data fetched only once !!) :

## pseudo code
r = mapnik.Renderer('agg','cairo','metawriter') 
r.apply()

I also would like to revisit vertex_converters and reduce code duplication in current backends.

To summarise, yes, metawriter will make its way back into core and 'yes' it'll become separate backend.
I'd love to discuss implementation details and how to maintain flexibility and efficiency.

@springmeyer @herm - how about brainstorming this one over skype ?

[der-stefan]

I hope that the great metawriters by @herm will find back to future Mapnik, since those are a perfect way to achieve a raster+vector map. I am a bit surprised that no significant OSM map makes use of it yet. Instead, some make use of a sledge hammer method by calling the Overpass API.