Mollweide projection incorrect ?

[PBrockmann]

I have encountered a problem when drawing polygons from a icosahedral grid with a Mollweide projection only.

The same with a Robinson projection.

What do I miss ?

I have prepared a notebook with OPeNDAP access to the netcdf file that shows the problem.
https://thredds-su.ipsl.fr/thredds/fileServer/ipsl_thredds/brocksce/gridsCF/cartopy_bug_projection.html
https://thredds-su.ipsl.fr/thredds/fileServer/ipsl_thredds/brocksce/gridsCF/cartopy_bug_projection.ipynb

Tested with cartopy 0.20.2

[greglucas]

There are a lot of open issues relating to Molleweide: https://github.com/SciTools/cartopy/search?q=Mollweide&type=issues
Some of them indicate polygons are getting flipped inside out during the transformation and having issues near the poles. One thought to narrow it down is to try limiting some of your domain and see if that helps at all. Or set alpha=0.5 on the collection to see if you can see through the polygons and see if many are just being covered up by a few.

[PBrockmann]

Thanks for your interest.
Indeed alpha=0.5 shows that polygons are drawn correctly...

Some cells should be not correctly drawn.

[PBrockmann]

Investigating... I have isolated the polygon that causes the problem. Used add_geometries() to be simpler.

import matplotlib
import matplotlib.pyplot as plt
import cartopy
import cartopy.crs as ccrs
from shapely.geometry.polygon import Polygon

fig = plt.figure(figsize=(20,10))                      
ax1 = plt.subplot(111, projection=ccrs.Mollweide(central_longitude=0))

#==================================
coords = [
(-31, -83),
(-61, -86),
(-180.0, -89.5), 
#(-180.0, -90),
(61, -86)
]
poly = Polygon(coords)

ax1.add_geometries([poly], crs=ccrs.PlateCarree(), facecolor='r', edgecolor='b', alpha=0.2)

ax1.coastlines()
ax1.gridlines()

#==================================
plt.show()

Changed with the vertex (-180.0, -89.5) with (-180.0, -90) gives

So why is there this overlap when I use (-180.0, -89.5) ?

[greglucas]

It looks like this may be the same issues as #1333 and there does appear to be a PR to fix that: #1334 although I haven't looked at it.

[stephenworsley]

I suspect this may be fixed by OSGeo/PROJ#3082.