GeoJSON renders incorrectly with default Rhumb arc type

[ezze]

I'm using Cesium 1.60.0 and trying to load GeoJSON describing borders of Russia. I extracted this GeoJSON from shape files found on NaturalEarth (1:50m resolution, cultural). Unfortunately, Cesium does something wrong while rendering the GeoJSON. Seems like it draws polygon lines between points that should not be connected with each other.

I report this issue because this GeoJSON is displayed as expected with another software such as QGIS.

Sandcastle example

var viewer = new Cesium.Viewer('cesiumContainer');
viewer.dataSources.add(Cesium.GeoJsonDataSource.load('https://gist.githubusercontent.com/ezze/98a77f60cab8d24613f440599bece3a5/raw/9ac4498a1f0d3f3c80792a73a52672f1c847f43d/russia.json'));

Cesium doesn't display GeoJSON properly

QGIS displays GeoJSON as expected

geojson.io displays GeoJSON as expected

mapshaper.org displays GeoJSON as expected

Browser: Chromium Version 75.0.3770.142 (Official Build) Built on Ubuntu , running on Ubuntu 18.04 (64-bit)

Operating System: Kubuntu 18.04

[OmarShehata]

This may due to the same issue as #7864. Try this Sandcastle which sets the arc type back to what it used to be. Let me know if this looks correct.

[ezze]

@OmarShehata, thanks for your reply.

Here is my updated Sandcastle example like you propose:

var viewer = new Cesium.Viewer('cesiumContainer');
var dataSource = Cesium.GeoJsonDataSource.load('https://gist.githubusercontent.com/ezze/98a77f60cab8d24613f440599bece3a5/raw/9ac4498a1f0d3f3c80792a73a52672f1c847f43d/russia.json');
dataSource.then(function(data) {
    // Change the arcType to GEODESIC, which is what it was in CesiumJS 1.53.
    for (var i = 0; i < data.entities.values.length; i++) {
        var entity = data.entities.values[i];
        if (Cesium.defined(entity.polygon)) {
            entity.polygon.arcType = Cesium.ArcType.GEODESIC;
        }
    }
    viewer.dataSources.add(dataSource);
});

Everything works fine now.

Your workaround is fine for me at the moment. But will it be fixed?

[OmarShehata]

Glad to hear the work-around solves your issue. The reason this originally changed in #7492 (comment) was to be compliant with the GeoJSON spec:

This PR also changes the default behavior of GeoJSON data source to be to use Rhumb lines. This makes GeoJSON spec compliant (See below).

So I'm surprised that this actually produces the wrong result compared to all the other visualizers you cited. @shehzan10 do you know why this might be?

[OmarShehata]

Same issue came up again on the forum here: https://groups.google.com/d/msg/cesium-dev/MwWRudF0axw/S6hSHn-rBwAJ

[likangning93]

Glad to hear the work-around solves your issue. The reason this originally changed in #7492 (comment) was to be compliant with the GeoJSON spec:

This PR also changes the default behavior of GeoJSON data source to be to use Rhumb lines. This makes GeoJSON spec compliant (See below).

Just a reminder here that the use of rhumblines in GeoJSON is not spec compliant.
The portion of the spec referenced in that PR states that GeoJSON lines are defined as a direct interpolation of lat/long, while the spec itself confusingly says both that the interpolation should be direct interpolation of lat/long but prefaces that it should be the shortest path between two points in the coordinate reference system.

We use rhumblines to emulate the behavior seen at geojson.io, which goes with the interpretation that GeoJSON lines are shortest-paths in the CRS and uses a mercator base map. but uses a mercator base map instead of the geographic coordinate system defined in the spec.

[likangning93]

For anyone who wants to do some close reading, here's the relevant section of the spec linked at the PR referenced above: https://tools.ietf.org/html/rfc7946#section-3.1.1

   A line between two positions is a straight Cartesian line, the
   shortest line between those two points in the coordinate reference
   system (see Section 4).

   In other words, every point on a line that does not cross the
   antimeridian between a point (lon0, lat0) and (lon1, lat1) can be
   calculated as

   F(lon, lat) = (lon0 + (lon1 - lon0) * t, lat0 + (lat1 - lat0) * t)

   with t being a real number greater than or equal to 0 and smaller
   than or equal to 1.  Note that this line may markedly differ from the
   geodesic path along the curved surface of the reference ellipsoid.

   The same applies to the optional height element with the proviso that
   the direction of the height is as specified in the coordinate
   reference system.

   Note that, again, this does not mean that a surface with equal height
   follows, for example, the curvature of a body of water.  Nor is a
   surface of equal height perpendicular to a plumb line.

[cesium-concierge]

Congratulations on closing the issue! I found these Cesium forum links in the comments above:

https://groups.google.com/d/msg/cesium-dev/MwWRudF0axw/S6hSHn-rBwAJ

If this issue affects any of these threads, please post a comment like the following:

The issue at #8042 has just been closed and may resolve your issue. Look for the change in the next stable release of Cesium or get it now in the master branch on GitHub https://github.com/AnalyticalGraphicsInc/cesium.

[hpinkos]

This GeoJSOn still has some issues

110m-land.json.txt

[hpinkos]

Work started in https://github.com/AnalyticalGraphicsInc/cesium/tree/fix-rhumb-triangulation but needs an approach that will work at the north and south poles.

[OmarShehata]

Came up again here: #8812 (comment). In this case, the polygon fill seems to get stuck trying to be computed (you can tell the viewer thinks the data source is still being loaded because the timeline is stuck, unless you set viewer.allowDataSourcesToSuspendAnimation = false). Doing the geodesic fix above fixes it.

GeoJSON: countries.geo.txt

[hpinkos]

Also reported in #8789. See that issue for another example file

[1riggs]

I have run into a similar issue rendering a geojson containing large multipolygons. Here is a sandcastle example. For the sake of completeness here is a sandcastle example with the workaround.

I have verified the geometry is valid, and have tried the arc type workaround described above to no avail. Any insight the Cesium team could provide would be very much appreciated.

---

Update: I was able to get my data set rendering correctly. It turns out the issue was the southern most polygon wrapped from bounding box border to bounding box border. Splitting the offending polygon and converting all multipolygons to polygons in the geojson data set fixed the rendering issues.