Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Amit-Gore opened this issue Jul 12, 2018 · 8 comments
Open
Labels

Comments

@Amit-Gore
Copy link

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
Copy link
Contributor

jfirebaugh commented Jul 12, 2018

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
Copy link
Author

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
Copy link
Contributor

e-n-f commented Jul 13, 2018

@jfirebaugh This was also reported in Tippecanoe as mapbox/tippecanoe#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
Copy link
Contributor

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

@mourner mourner closed this as completed Jul 24, 2018
@Amit-Gore
Copy link
Author

Amit-Gore commented Oct 12, 2018

@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 mourner reopened this Oct 17, 2018
@mourner
Copy link
Member

mourner commented Oct 17, 2018

@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.

@mourner mourner changed the title Custom vector tiles does not match with tiles made from geojson source in mapbox High-precision vector tiles are downsampled to 8192 extent for rendering Oct 17, 2018
@MattFerraro
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants