Fix label clipping across tile boundaries

[lucaswoj]

Presently, if a source has any of the following properties set to true, labels may be clipped at tile boundaries:

• text-allow-overlap
• icon-allow-overlap
• text-ignore-placement
• icon-ignore-placement

This behaviour is intended to avoid double-drawing labels on tile boundaries when the feature is in one tile and in an adjacent tile's buffer. This behaviour can also cause a label to be clipped when the feature is not in the adjacent tile's buffer (because the buffer is too small).

The relevant code is in draw_symbol

I don't have any specific solutions in mind yet.

cc @ansis @yhahn @noemiwalzebuck @mourner

[mourner]

Could we still do label collision for those symbols but only with tile boundaries in the collision tree?

[lucaswoj]

Very good idea @mourner 😄. That approach would be a nice follow-up to #2703.

[pathmapper]

What are the drawbacks having double-drawed labels? Is there a big impact on the rendering performance? Depending on the drawbacks a double-drawed label (if perfectly drawed one upon the other) might be preferable compared to a clipped one.

[ChrisLoer]

This behaviour can also cause a label to be clipped when the feature is not in the adjacent tile's buffer (because the buffer is too small).

The clipping can also happen whenever labels placed with symbol-placement: line get placed at a boundary in one tile but due to symbol-spacing logic don't get placed with the exact same anchor in another tile. This behavior shows up in our current symbol spacing tests (look for the discontinuous line across the bottom).

What are the drawbacks having double-drawed labels?

The main drawback I'm aware of is that it messes with the ordering of labels that are allowed to overlap. Whatever gets drawn last will be shown "on top" of whatever was drawn earlier. Each tile has an internally consistent ordering of overlapping labels based on the y-position of their anchor (see issue #470).

Consider two tiles A, B and a symbol S. S's anchor is in B, but it overlaps into A. If we draw tile B after tile A, then S will be drawn on top of all the other symbols drawn in A. That might contradict the ordering that A would otherwise have.

I'm considering changes here as part of the global collision detection changes in PR #5150, but the sorting problem is still a sticking point. One potential solution would be something like:

• Each tile only includes symbols whose anchors are within its boundaries
• Symbol buckets from multiple tiles are combined into one buffer and globally sorted before being drawn

That approach would (1) preserve sort order, (2) avoid tile-clipping problems because symbol draw calls would no longer be tile-based, and (3) cut down on the number of GL draw calls (a potential performance win). On the other hand, continually merging "global" symbol buckets on every tile change would add complexity/cost...

[ChrisLoer]

Double-drawing symbols can also make unclipped labels "bolder" than they should be. Here's an example from our test suite showing a (non-overlapping, and thus un-clipped) label:

Here's the results of the test only drawing each label once even though the label shows up in both tiles (the boxes show tile boundaries, so you can see why both labels span multiple tiles). Note that the label text looks a little bit thinner:

[mrdrprofuroboros]

Is there any workaround for this issue? I'm using mapbox 0.40.1 and generate tiles myself with node-mapnik. And everything works fine until I enable icon-ignore-placement or icon-allow-overlap for layer. This causes cropping icons as shown - tried to enlarge buffer-size both on generated vtiles and layers, nothing helped. Any ideas?

[ChrisLoer]

@mrdrprofuroboros If you're using symbol-placement: point and the icons near boundaries are present in both tiles, the clipping shouldn't be happening. So even though you've tried increasing the buffer size when you generate the tiles (how are you generating them?), the symbols might not actually be making it in to both tiles.

As an alternative to that workaround, you might try running against the code in #5150 to see if that helps with your problem. We use a different approach to symbol sorting that should mostly address this issue. Although that PR hasn't landed yet, we hope to merge it into our next release.

[mrdrprofuroboros]

@ChrisLoer The point is that icons seem to present on both tiles as expected - when I zoom in and out some of them change their place from one tile to another

I am currently generating tiles from geojson like that
vtile = new mapnik.VectorTile(@z, @x, @y)
vtile.addGeoJSON(JSON.stringify(geojson), "myTileName")

[mrdrprofuroboros]

@ChrisLoer #5150 Solved the problem! Can't wait to see it the release! Thank you

[ChrisLoer]

This is fixed with #5150. There is one caveat: we don't guarantee symbol sort order at tile boundaries (normally higher-y-coordinate icons display in front of lower icons, but at a tile boundary it is now possible for that order to be reversed.

[mrdrprofuroboros]

I'm pity to report this but though #5150 is merged in new 0.41.0 release, the bug with cropping still exists =( I was eager to try new heatmaps, but had to stay on the pure #5150, to keep my icons display properly.

[pathmapper]

@mrdrprofuroboros #5150 is not part of v0.41.0, I think it will be part of v0.42.0.

Maybe you were referencing to #5105 :-)

[mrdrprofuroboros]

@pathmapper oh, yep, that's true =) sorry for bothering. Btw, v0.42.0 works like a charm! thank a lot for your work