Curious Visual Anomaly With GeoJSON on Android/Mobile

Hello

I am revisiting CesiumJS and doing some blog posting / outreach to a data science / geovis community in the Clojure programming language (really ClojureScript using js stuff through native js interop).

It have a very simple baby visualization here that loads the default Cesium viewer, with an optional topojson layer for the US states projected. I copied the examples from the sandcastle geojson demo and built around them, and I verified I’m using the same topojson file. Bottom line, the visual renders fine in on desktop browsers for me (tested in firefox, edge, chrome) across Windows and Linux. So we should see this:

For kicks I went to check it out on mobile to see how the performance and layout looked, I am greeted with a really weird rendering of the GeoJSON layer like this:

This is on Android; I get similar results in Chrome and Brave (both are chromium derivatives though), and firefox. So this is the same file, which renders correctly on desktop (and has for years for me at least). When I visit the sandcastle reference demo on mobile, the GeoJSON renders correctly. It feels like maybe something with the data or the initialization of datasource that is irritating the mobile side in my visual (maybe problems with the topojson file?)

Has anyone seen this artifact before on mobile?
If so, is there a known cause or work around?

The only change to the default invocation for loading is modifying the styling, so something equivalent to this:

const viewer = new Cesium.Viewer(‘cesiumContainer’);
viewer.dataSources.add(Cesium.GeoJsonDataSource.load(‘../../SampleData/ne_10m_us_states.topojson’, {
stroke: Cesium.Color.BLACK,
fill: Cesium.Color.DARKGRAY.withAlpha(0.7),
strokeWidth: 20
//markerSymbol: ‘?’ //this shows up in the docs, but I never had it set, and neither does sandcastle.
}));

Hi @joinr, that does look strange.

What happens if you set strokeWidth to 1?

While the WebGL lineWidth method accepts large values, most desktop WebGL implementations only support a maximum value of 1. There could be 1 of 2 things happening here:

  1. Some mobile devices might behave strangely with large lineWidths, but we haven’t noticed it because most WebGL programmers don’t try values larger than 1.
  2. CesiumJS could have an bug with large lineWidths, which we haven’t noticed since the machines we are using for testing don’t support the large values.

@jjhembd Looks like item 1 was the answer in question. I am guessing there are values (as in the reference docs) where strokeWidth is > 1 (e.g. 3) and nobody notices it, or they don’t break whatever hidden threshold exists.

It looks like that fixed it. I might play around and see if there’s an empirical threshold that causes things to degenerate.

Thanks for your insight.

1 Like