search

visgl / deck.gl

WebGL2 powered visualization framework
https://deck.gl
MIT License
12.08k stars 2.08k forks source link

MVT rendering artifacts #5220

Closed thomasgwatson closed 3 years ago

thomasgwatson commented 3 years ago

Hey folks,

Trying to chase down where some rendering artifacts might be emerging.

Any hints on how to debug would be appreciated (I had a look at prior tickets but didn't find any that seemed relevant).

Challenge:

I wonder if there is a discrepancy between the schema of MVT used by the MVT service we are using, and how deck.gl is expecting the MVT to look like.

At times it looks like the glitching features are just displaced; that they have the wrong cartesian coordinates for the tile zoom level being used. And that once the zoom is changed, the new tile arrives and the features are re-rendered, the glitching features 'snap' back into place

Some pics that demonstrate this:

low-zoom, you can see the 'confetti' effect where some features are displaced Screen Shot 2020-12-03 at 14 37 41L

Zoom in, different features seem displaced

Screen Shot 2020-12-03 at 10 45 21

After a few moments of processing (perhaps the higher zoom tile loads)

Screen Shot 2020-12-03 at 10 45 26

Little video of what it can show up as: https://youtu.be/czyEF3xow9U

neokore commented 3 years ago

Hi @thomasgwatson! I'm trying to reproduce your bug, but I can't. Can you share with us an example where this bug happens? Looking at the video and screenshots, looks like it could be caused by a geometry optimization bug, but I'm not sure if it could be caused by the MVT data or the renderer, so it would be nice to have an example to work with. Thanks!

thomasgwatson commented 3 years ago

@neokore I cross-posted this to the Data Hub team (the providers of the MVTs) and they think it is an issue on their side.

They shared: "I think this is due to the mvt served from datahub. Current, when requesting mvt the coordinates are "adjusted" to 512 pixelsize with no extend. So, the data is not "detailed" enough be used on higher zoom levels then the requested. "overzooming" is the term here. This is not adjustable by the user but clearly should"

I'll work with them to resolve, guessing we can close this issue. Thanks for your follow up, very appreciated

0xflumedev commented 2 years ago

Hi @neokore @thomasgwatson I am experiencing similar over at https://github.com/visgl/deck.gl/issues/6966 but not with polylines.