GeoJsonLayer tesselates polygon data incorrectly

[Gimir]

Description

I generated geojson data for drawing day/night layer on map (link in reproduce section), and when I pass the data to GeoJsonLayer it draws additional polygon or something. Here is what layer looks like in my case with deck.gl:

Flavors

• [ ] React
• [ ] Python/Jupyter notebook
• [ ] MapboxLayer
• [ ] GoogleMapsOverlay
• [ ] CartoLayer
• [ ] DeckLayer/DeckRenderer for ArcGIS

Expected Behavior

When I test data passed to GeoJsonLayer in geojson.io, it correctly draws given polygon.

Steps to Reproduce

Here is link to Sandbox Generating GeoJson data on line - 17 Creating GeoJsonLayer on line - 37

Here is Gist with full polygon data in Geojson.io (to see raw click on < > button)

Example layer GeoJson data:

{
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "properties": {},
            "geometry": {
                "type": "Polygon",
                "coordinates": [
                    [
                        [
                            -360,
                            90
                        ],
                        [
                            360,
                            90
                        ],
                        ...
                        [
                            -360,
                            90
                        ],
                    ]
               ]
          }
     }
  ]
}

Environment

• Framework version: 8.7.0
• Browser: Chrome latest
• OS: Mac os 11.3.1

Logs

No response

[ibgreen]

I have seen a similar issue, in the FlatgeobufLoader example in loaders.gl (see the spurious triangle in the very south).

To repro, go to https://loaders.gl/examples/geopkg and select the flatgeobuf file in the dropdown.

We haven't ruled out that it could be a problem in the flatgeobuf loader but it seems to follow a similar pattern (i.e. geometry close to the pole being incorrectly tessellated).

[Gimir]

@ibgreen yes, it seems to be same issue. I tried two layers (PolygonLayer, SolidPolygonLayer), both have this problem. Also I tried different coordinate systems (180 90, 360 90), same thing.

[kylebarron]

A couple quick observations:

• My hunch is that the error would be in the polygon triangulation, not the shaders themselves.
• The maximum latitude of web mercator is 85.05113, so rendering data with latitude values outside that band will never be seen. If I use Python's Shapely in a small script to intersect your geojson data with the box -180, -85.05113, 180, 85.05113, then triangulation and rendering works fine
• At least for the flatgeobuf example, I wouldn't be surprised if that issue was more with self-intersections in polygons than with handling polar data

[Gimir]

@kylebarron it works! Thank you man, I changed latitude to 85 and artifacts are gone.

[kylebarron]

Good to know, though I'd still consider this a bug.

[ibgreen]

Good to know, though I'd still consider this a bug.

Yes, or maybe two different bugs.

We use earcut for tesselation and it is advertised as offering very high performance with the down side being that it doesn't guarantee correctness: https://github.com/mapbox/earcut#the-algorithm.

If one or both of these issues relate to earcut . I suppose one option could be to also offer a slower, more robust tesselation algorithm.

[felixpalmer]

In PolygonTesselator, we already cut the polygon by Mercator bounds when wrapLongitude is set. Would a similar approach work here?

[kylebarron]

We could definitely try it. I haven't tried to render polar data in deck.gl myself, so I can't guarantee that will fix this error, but it might.

[Pessimistress]

@Gimir If you set wrapLongitude: true on the layer, it will be rendered correctly.

Web Mercator projection's latitude limit is around 85.0511 (source). 90 is projected to infinity and is usually the culprit of strange tesselation outcomes. In the shader, we clamp latitudes to 89.9 to avoid artifacts, but we don't do it on the CPU (Viewport.projectFlat). We should handle 90 gracefully since it is technically valid GeoJSON.

[Pessimistress]

Fixed in v8.7.4