Overlapping polygons at tile edges, using jawg.io tiles

[westnordost]

TANGRAM VERSION: 0.20.1 ENVIRONMENT: Firefox 77.0.1, Windows 10

TO REPRODUCE THE ISSUE, FOLLOW THESE STEPS:

• Go to https://play.tangram.city/?#15.2500/51.8805/10.4567
• In Tangram Play, open https://raw.githubusercontent.com/ENT8R/streetcomplete-mapstyle/jawg/streetcomplete-light-style.yaml
• The style uses jawg.io as tile source. Add api_key: Zv2Mm3fkkjfqjWQ7bZ8xradVnzJv8ZlRBqtSYkZoNuBRhcpB5n8l58aU6YYGvfYB to the globals. (This is a temporary token that will be revoked when this bug is closed). The map should render (almost fine) now

RESULT:

EXPECTED RESULT:

The same, but without the overlapping polygons at the tile edges. I figured that as tiles can not overlap, it can't be a problem of the tiles. They also render fine with mapbox, as shown here: https://www.jawg.io/en/maps/#13.66/51.87577/10.46222

STYLE USED

This should be the relevant section of the used stylesheet (in land.yaml):

layers:
    hillshade:
        data: { source: jawg , layer: hillshade }
        highlights:
            filter: { highlight: true }
            draw:
                hillshade-light-style:
                    order: 100
                    color: '#040404'
        shadows:
            filter: { shadow: true }
            draw:
                hillshade-shadow-style:
                    order: 100
                    color: '#f9f9f9'

styles:
    hillshade-light-style:
        base: polygons
        blend: add
    hillshade-shadow-style:
        base: polygons
        blend: multiply

[bdon]

Is this a regression in the latest Tangram - did this work properly in the past? Is it possible that this problem only appeared when using the blend:add or blend:multiply blend modes in the style?

I figured that as tiles can not overlap, it can't be a problem of the tiles.

I haven't used that tile service specifically, but most tile services do intentionally overlap, repeating some data in a buffer area in order to help with labeling and stroking across tile edges, for example a 4096x4096 tile has data from -100 to 4196. Most renderers then clip the actual displayed tile to 0,0,4096,4096. Is it possible Tangram is designed with different assumptions for the overlapping buffer? I haven't looked closely at the code yet.

[bdon]

https://github.com/tangrams/tangram/issues/469

[westnordost]

Is this a regression in the latest Tangram - did this work properly in the past?

I don't know

[bcamper]

Hi, yes, sorry to let this one slip through the cracks. @bdon is correct, this is a known issue with blending and buffered tiles specifically, as noted in #469. While Tangram is meant for use with any tile source, most core features were initially developed with the Tilezen schema in mind, and those tiles are not buffered. Since that linked issue was written, we did add some use of stencil buffer for blending in #704. That PR addresses a different but related issue; the stencil approach used there could possibly be adapted/extended to solve this issue, however it would cause problems with 3d extruded geometry (to my knowledge, other renderers that use buffered tiles such as Mapbox GL use a separate rendering pass for extruded geometry specifically; I'm not sure it's possible to arrange rendering order in Tangram in a way that would work for all these blending cases while also honoring the blend_order parameter). So it remains an open issue but this is a good reminder :)