Deck.gl: Rendering issue for polygons in MVTLayer

[VictorVelarde]

Description

It looks like there is some kind of rendering issue of polygons when using MVTLayer, with lines and polygon surface not rendered in the right position.

It might be related to the clipping, as using different bufferSize value changes the positioning (using bufferSize: 10 in this error image and the next codepen) or perhaps related to coordinates precision in high zoom levels, but honestly I'm not sure.

Repro Steps

https://codepen.io/VictorVelarde/pen/dyYwjej

Let us know if we can help somehow with the fixing

Environment (please complete the following information):

• Framework Version: deck.gl 8.1.7
• Browser Version: Chrome 81.0
• OS: Mac OS X 10.15.4

[Pessimistress]

There is either an issue in your tile generation, or the MVTLoader's parser.

The feature coordinates should be relative to the origin of the tile, not including the buffer. I.e. the positions inside the buffer may be negative.

For reference, the tiles from Mapbox's own service appear to be loaded correctly with the latest release.

[jesusbotella]

I am gonna take a look at the CodePen example and determine the cause

[VictorVelarde]

We checked the tile generation server side with another mapping lib, so then I guess the issue must be on the parser...

[kylebarron]

The parsing to local coordinates is extremely simple and doesn't look to have a bug:

export function transformToLocalCoordinates(line, feature) {
  // This function transforms local coordinates in a
  // [0 - bufferSize, this.extent + bufferSize] range to a
  // [0 - (bufferSize / this.extent), 1 + (bufferSize / this.extent)] range.
  // The resulting extent would be 1.

  for (let i = 0; i < line.length; i++) {
    const point = line[i];

    line[i] = [point.x / feature.extent, point.y / feature.extent];
  }
}

You should check that extent is correctly encoded

[jesusbotella]

I have been doing some research on this issue, and I have discovered some things worth mentioning (IMHO).

First of all, I checked the extent encoding and it is correctly encoded within the MVT tile, so the positions are divided in both indices by 2048 (the extent).

I have achieved some improvements in this regard by:

• Reducing the buffer around the tile. Now it looks better with just one pixel of buffer around, but there are still some issues.
• Implementing a clipping based on the Cohen-Sutherland algorithm and intersecting line points with the tile area to create points in the tile edge. (We had it in our previous library so it was worth trying)

With those changes, we improved a bit, as you can see in the screenshots (above is the original map, below the one implementing the changes):

As you can see, it is not perfect but there's some progress between the two. It's true that clipping with that algorithm helps.

Given those evidences, I think that there's a precision issue in the data encoded in the tiles, or something that makes line string data not as accurate as it should be. But that's just my guess.

What do you think?

[Pessimistress]

One way to test that hypothesis is to prepare two versions of the same data:

• GeoJSON in lnglat
• GeoJSON in Mercator pixels as normalized by mvt-loader

and see if they render to the same output.

So your tile extent is 2048, what is the rendered size in pixels? I do want to point out that the MVT encoding, by specification, quantizes coordinates for compression, so you will run into issues if you overzoom.

[andybak]

I'm not sure if this is the same issue or different. I'm seeing spikyness and wobbly edges but never the broken lines shown here.

Renders fine in Mapbox. Doesn't matter if the MVT source is PostGIS or the Mapbox API - same result.

Good (Mapbox tileset preview):

Bad (Deck.GL):

[jesusbotella]

This is now solved by #4699.

This is how the original example looks now with 8.2.0-beta.1:

I cannot close the issue but this error is not reproduced anymore.