Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Make clipping default off for all symbolizers with custom placement #1569

springmeyer opened this Issue Nov 9, 2012 · 8 comments


None yet
3 participants

springmeyer commented Nov 9, 2012

As more users start using Mapnik >= 2.1, it is becoming clear that defaulting to clipping geometries that are used for text/shield/marker placement is causing more trouble than benefit. The value is greater performance by default, but user experience of having to learn that you may need to turn off clipping to avoid rendering oddities or artifacts is not great.


nvkelso commented Nov 13, 2012



nvkelso commented Nov 13, 2012

Backgrounder from Dane:

Short answer: Yeah, we should change it to be default off in Mapnik 2.2. I'm starting to acknowledge that the performance boost is not worth the user pain.

Longer: The performance hit from rendering geometries twice (or more) across tiles is significant, even for OSM data that is quite segmented. For data that is not highly segmented the impact is even more extreme. Take a long diagonal line that crosses Oregon, like a railroad. It would make sense to store it as a single line in the data for a variety of reasons. If this happened then its BBOX will intersect with every single tile in Oregon at every single zoom level. And then, if the geometry is not aggressively clipped it will be rendered in its entirety (even though none of its vertices actually occur in most tiles). This overhead will really add up as more features are encountered that are invisibly rendered but still pulled from the database, making rendering jobs that should take minutes actually take days, etc. The perf impact of this gets more extreme when you think about labeling. Because long geometries often will only get one label by default, then Mapnik users will use the spacing parameter to trigger multiple labels per line segment. This parameter invokes much more expensive algorithms. If the line were nicely pre-segmented (or the line is clipped on the fly) you can avoid these multiple hits of performance pain.

The drawback of course is that label position becomes much more volatile between tiles, especially in your case where you have intentionally crafted merged highway lines to achieve nice labeling.

What is interesting is that AJ has not once yet turned clipping off in the MapBox Streets styles. He may not be able to get away with this much longer, but my hunch is that we use large enough metatiles that it is rarer for labels to be volatile across tiles. And of course with large metatiles that may contain a massive amount of data, clipping the edges before rendering becomes even more important for performance.

(nvk) Instead, could you test if there is a Text or Shield symbolizer attached to a layer and only turn clipping on by default when neither is present? Is the performance that much better for always having it on?

Clipping currently is actually per symbolizer, so turning it off selectively is very easy. So, my thinking is that we move forward by disabling clipping by default on any symbolizers that do placement work vs just raw rendering of a line/polygon.


nvkelso commented Nov 13, 2012

Also, if you clipped to a more standard "meta" size that didn't change from tile to tile as much, this might also solve the problem.

Right now it's clipping to the meta tile, but the clip on that changes from this metatile to that metatile. If there were "standardized" meta clippers instead of moving clippers, performance might be gained while keeping the label position more constant?

Maybe use the parent tile bounds from (zoom - 3)? For a given 256x256 tile, if the metatile is 1,024, the clipper would be 2,048? Are base it on a modulus of the metatile to prior zoom's tile size so it adapts to different sized metatiles?


springmeyer commented Nov 13, 2012

Right, clipping is being done at the edge of a metatile + map-buffer-size + any symbolizer specific padding (we currently pad for lines in particular). It may be as simple as that text/shields will be clipped less if we add further padding. Or it may be that any level of clipping, and particularly when padding, creates more volatile placements across tiles. But this really depends on the text placement options. The idea of trying to enforce some kind of more consistent clipping grid across tiles is interesting, but I can't (right now) see how that could work.


strk commented Nov 15, 2012

Please also consider #481 as a way to put an end to this "defaults" war.
I think generally defaults should follow the old behavior (for backward compatibility)


strk commented Nov 15, 2012

If it wasn't clear, the above was a +1 to make this change in 2.1.1, together with all other backward compatibility fixes


springmeyer commented Nov 15, 2012

Thanks @strk, yes I am also +1 on thinking of this as restoring defaults.

@springmeyer springmeyer pushed a commit that referenced this issue Nov 29, 2012

Dane Springmeyer set clipping off by default for markers, shields, and text (point/bui…
…lding do not support clipping so do not need this modification) - refs #1569

springmeyer commented Feb 9, 2014

tracking finally changing the default to off now across the board at #2146

@springmeyer springmeyer closed this Feb 9, 2014

@springmeyer springmeyer added this to the Mapnik 3.x milestone Feb 9, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment