Support on-the-fly geometry clipping

[springmeyer]

We can support geometry clipping.

It can potentially be:

• pre rendering, a new VertexSource in ctrans.hpp
• work in floating point (geo) coordinates.
• clip both lines and polygons while maintaining topology (good enough for rendering)

This can enable:

1. Faster rendering times for maps with a density of complex, large, and/or multi-part features, particularly at >= z10.

2. Cool cartography effects - e.g. allowing label centroids to be sensitive to the clipped polygon region (Labeling polygons that are "majority outside of tile bbox" #25)

3. Infinite zooming - currently >= z18-20 maps that intersect with very large polygons can cause overflows in AGG (rendering overflow #1076, features unrendered at >= z11 when agg clipping not used #1075)

4. Complementing AGG's clip_box() functionality, which works in screen coords.

This ticket replaces #708, #876, #25, #1076, and #1075

details

It should be controllable by user (#1281), likely at the symbolizer level. For example, clipped geometries will likely not work well for labels along lines.

[artemp]

initial support for geometry clipping : https://github.com/mapnik/mapnik/tree/move_bind_logic_to_layer

[springmeyer]

@artemp - do you see a possible way to make clipping on/off per user control? This seems important in the case that we find clipping may not be desirable and also quite useful for testing.

[artemp]

@springmeyer - we can, but I'm hoping that 'clipping' will be always desirable. Also, we can make clip_box configurable.

[springmeyer]

@artemp - sounds good re: clipping always being desirable.

Another question: will this geo-coord clipping enable removing of ras/ren.clip_box and therefore also close #777?

[artemp]

@springmeyer I think we should leave ras.clip_box

[springmeyer]

@artemp - yes, leaving ras.clip_box sounds good. I did a test with agg::rasterizer_scanline_aa<agg::rasterizer_sl_no_clip> which basically appears to no-op the ras.clip_box. With processed_p/z0 it did not help speed things up ( I wondered about potential overhead of "double clipping"), and with osm streets render its removal lead to inf loop:

I have DEBUG_UNDEFINED = True in my config.py which I think is the reason this turns into a hang. Without that I bet it would just be some kind of overflow - not sure.

Anyway, I'm also now not seeing a major perf hit at z0 with clipping vs no-clip branch. So, I'm not sure what I was seeing before :)

[springmeyer]

landed in 514ec14

[strk]

we're considering pre-clipping vectors prior to get into mapnik (using queries or temporary tables in postgis). Can we opt-out of this to not incurr in the overhead ? (see issue #1093)

[springmeyer]

@strk - yes, I'm currently working on allowing disabling of clipping for text labels. I'll take a look at what it would take for polygons/lines.

However, first we'd need to ensure the perf issue you are seeing is due to clipping.

[woodpeck]

I'm seeing line pattern problems in 2.1 that weren't there in 2.0. Issue #777 addresses what I'm seeing but you seem to be of the opinion that it is fixed so I'm raising it here:

This is from a tile server with Mapnik 2.1.0+dev20120615.git.b12e73f. The magenta road in the middle straddles a meta tile boundary.

This is the same server with 2.0.1+dev20120518.git.92dd305-1:

Sorry for reporting against a 10-day old version, it's entirely possible that it was just a glitch that has been fixed in the mean time.

[artemp]

@woodpeck - thanks for reporting

[springmeyer]

@woodpeck a workaround for this problem was
pushed to master around 1o days ago,
so upgrading should fix it: #1215

[springmeyer]

Going to close this issue now - it scoped the main task of implementing support for clipping, which has now been in master for a while.

New issues to track sub tasks are: #1281 (ability to disable per symbolizer) and #1282 (make the clipping extent smarter).