mapbox / mapbox-gl-js

Interactive, thoroughly customizable maps in the browser, powered by vector tiles and WebGL
https://docs.mapbox.com/mapbox-gl-js/
Other
11.2k stars 2.22k forks source link

High-precision vector tiles are downsampled to 8192 extent for rendering #6957

Open Amit-Gore opened 6 years ago

Amit-Gore commented 6 years ago

I am trying to switch my current map-based application from geojson type source to vector tile source. As a proof of concept, I did a small experiment to visually compare the features drawn from geojson source vs vector source. Features drawn from vector source are geometrically different than that of geojson.

Especially polygon geometries have a skew effect like shown below where features with black boundary are drawn from geojson source and blue one are from vector tile source

image

image

As per the discussion here, it is confirmed that the tiles being generated are up to the expectations but mapbox gl-js is somehow trying to modify it. How do I get the tiles rendered(blue colored layer) so that they match exactly with the tiles generated from geojson source(black colored layer)

jfirebaugh commented 6 years ago

What are you using to generate vector tiles, and with what configuration? From the screenshots, it looks like the tiles have either an insufficiently high maximum zoom level, or a low extent value, so coordinates are being quantized to an integer grid that's too coarse.

Amit-Gore commented 6 years ago

I am using tippecanoe for generating these tiles with configurations like tippecanoe --maximum-zoom=14 --detect-longitude-wraparound --no-tiny-polygon-reduction --no-tile-size-limit --no-line-simplification

On mbview I can see these tiles being rendered with exactly the way I want. If I use this tile source on mapbox gl js , they are getting rendered the way I've shown above.

Can you suggest any configuration changes for tippecanoe command to get it worked ?

e-n-f commented 6 years ago

@jfirebaugh This was also reported in Tippecanoe as https://github.com/mapbox/tippecanoe/issues/595. As far as I can tell the tiles are fine, so I think something else in the rendering pipeline is downsampling the tile resolution.

jfirebaugh commented 6 years ago

@Amit-Gore Could you put together a self-contained example on jsbin.com that demonstrates the issue?

Amit-Gore commented 6 years ago

@jfirebaugh please refer the following self-contained example https://jsfiddle.net/amit_gore/wpduvroy/6/ Something is downsampling the tile resolution if you can see the round shaped geometry and the skewness. The red colored shapes are from the geojson source whereas the green one is from vector source

mourner commented 6 years ago

@Amit-Gore I traced the issue down to the fact that we downscale high-extent tiles to 8196 — here's an explanation in the comment. I'm not sure if there's a solution that would allow us to support higher-precision tiles while not degrading performance. Perhaps @ansis can chime in on that.

MattFerraro commented 5 years ago

I ran into this because I'm implementing a vector tile server. My intention was to store the vectors in pre-baked tiles at a max zoom level of say 10, then in my mapbox style I would set the max zoom of the source to 10, and the interpolation would have kept the features accurate even at high zoom levels like 20. Of course the discretization noise with a 4096 default tile resolution means that the features move around noticeably from their true locations. I tried to solve this by encoding my pbfs with much larger extents. I saw a visible improvement going from 4096 to 8192, but then no further improvement even with extents like 4096 * 128. The explanation linked by @mourner indicates that there is no quick solution to this.

I understand the need to normalize, but it would be super nice to be able to configure that 8192 extent in the client so that in hyper-zoom use cases like this, tile servers don't have to keep around higher resolution tiles.

stackrusty commented 3 months ago

After #5073, would it make sense to bump this to 16384 and get one more bit of precision?