Spurious polygon fills displayed that are not present in source tileset

[annapowellsmith]

mapbox-gl-js version: 0.52.0
browser: Chrome

Steps to Trigger Behavior

1. Upload this MBTiles file to Mapbox Studio - a polygon tileset with minzoom 10 and maxzoom 12
2. Use Mapbox GL JS to display the resulting tileset

Link to Demonstration

Demo can be found here (Mapbox GL JS code can be viewed in source)

Expected Behavior

Mapbox GL JS should accurately display the MBTiles file at zoom levels 10 and 11. For reference, this is how the MBTiles file displays in GIS desktop software (MapTiler Desktop): observe that the polygons shown in the city centre are mostly roads, at all zoom levels.

Actual Behavior

Mapbox GL JS displays spurious polygon fills at zoom levels 10 and 11, that are not present in the source MBTiles file. This can be observed in the demo above, or in this gif.

Note re the MBTiles file

Please note: although this MBTiles file was created with tippecanoe, and at first glance this might appear to be an issue with tippecanoe simplification, I believe this to be a bug in Mapbox GL JS, not tippecanoe. This is because the MBTiles file does not display these spurious fills in desktop GIS software. (In addition, I have observed the same issue after generating a non-simplified tileset from the same source data, using the --no-feature-limit --no-tile-size-limit --no-line-simplification --no-tiny-polygon-reduction options.)

However, for reference, the source GeoJSON file can be found here, and it was created using tippecanoe 1.32.9 on OSX with the command tippecanoe -f -z12 -Z10 --coalesce-smallest-as-needed --detect-shared-borders -o sheffield_demo.mbtiles diffs_jan18_sheffield.geojson

[mikelmaron]

@ericfischer do you think this is a tippecanoe or GL JS issue?

[e-n-f]

This looks like a GL JS issue to me (or possibly an issue with overzooming or feature-shaving in tile serving).

When I run Tippecanoe (1.32.9) myself I get an effectively identical tileset to the one provided, and both look fine to me in mbview. When I upload the tileset and view it in Studio, I see the artifacts described above, and also much worse artifacts in the overzoomed zoom level 13.

In the zoom level 10/11 case, it looks like holes in the polygons are being lost, so the entire area is filled, not just the portions that are supposed to be positive. I'm not so sure what is going on in zoom level 13, but whatever it is is different on different sides of tile boundaries, so I think it may include coordinate overflow, not just misinterpretation of polygon ring winding.

[e-n-f]

When I switch mbview to use the latest GL JS release v0.52.0 I still do not see the artifacts in mbview, which makes me more inclined to think this is a tile serving issue rather than a rendering issue.

[e-n-f]

It could be compositing in tile serving, since the tiles that Studio renders from are composites of the base map data and the user data, not the raw user data tiles.

[e-n-f]

But when I download the composite tile 11/1015/663, decode it, and retile it, it looks right in mbview, which points back to the theory that rendering is wrong rather than compositing being wrong.

[reyemtm]

This is a problem as well with plain GeoJSON. It happens at high and low zoom levels. I will have to limit zooming until I can find a solution. This example is using 0.52.0. If you follow that link, the square in the center is not really there. See more in the gif below. This behavior exists but manifests differently in 0.38.0 if that helps any - something was changed but whatever it was still did not fix this issue.

[flippmoke]

This reminds me of past issues in other rendering we have done where we have had a winding order reversal and it inverts the fill patterns.

[e-n-f]

Maybe there is arithmetic overflow somewhere within GL JS when it is trying to calculate the area of a ring to determine whether it is inner or outer, and the overflow is flipping the sign of complicated rings.

[annapowellsmith]

Following a conversation with the Mapbox support team, I think this may be related to the fact that the individual polygons in the source data are very large.

If I use ST_Subdivide on the source data to chop it into smaller polygons, before running it through tippecanoe and uploading to Mapbox Studio in exactly the same way, then the problem does not appear.

So I think perhaps GL JS is simplifying the large individual polygons, which is producing these surprising results.

I have seen tilesets where console warnings appear about excessive numbers of polygon vertices, but (as you can see in my demo) no such warnings were appearing for this tileset. It would be helpful if GL JS could have produced a console warning in this scenario too, to alert the user to the fact it is simplifying.

[reyemtm]

I spliced my example by a 0.2 mile grid and can confirm that splicing up the polygons does indeed help - it gets rid of the square artifact in my example when zoomed in past 18. This is not meant as a solution, more as helping to pinpoint the issue. There are still some filled-in artifacts (blue) and disappearing polygons (red) when zoomed out past 14. I can live with limiting zoom on these complex layers to 14+, but I do want to zoom past 17.

[reyemtm]

Setting the maxzoom options in my geojson source to less than 18 fixed my overzooming ghost square issue. With that and limiting minzoom to 14 will solve my problems for now. I can only do this due to a small geojson file that I can upload to the client.

Is there a way to set maxzoom when creating tiles in Mapbox Studio?

This whole issue should likely be closed and merged into #7023.

[annapowellsmith]

This whole issue should likely be closed and merged into #7023.

Possibly, though in my case I think simply throwing a warning about overly complex polygons (either in tippecanoe or in GL JS) would have been enough. So I would suggest doing that in order to close this issue.