Skip to content

FIX: make hole multipolygon valid before removing from projected polygon #2521

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 26, 2025

Conversation

rcomer
Copy link
Member

@rcomer rcomer commented Apr 23, 2025

Rationale

When a polygon with multiple holes is projected, the projected holes may become so close that they can't form a valid MultiPolygon as they touch along a line. In this case, we can still create the holes one by one. Taking the first example from #2176 (comment), and adding coastlines for reference,

import cartopy.crs as ccrs
import cartopy.feature as cfeature
import matplotlib.pyplot as plt

crs_proj = ccrs.LambertAzimuthalEqualArea(central_latitude=-90)
fig, ax = plt.subplots(1, 1, subplot_kw={"projection": crs_proj})
ax.add_feature(cfeature.OCEAN)
ax.coastlines()
plt.show()

I now get
image

Setting the central latitude to -30 still results in a failure, but this is very sensitive to the exact number and the user will be able to work around it by setting central latitude to e.g. -29.9999:

image

Implications

Making the holes one by one is slow compared with using the MultiPolygon: I tried removing the try-except and always removing them in the loop. This benchmark took 18 times longer:

import matplotlib.pyplot as plt
import cartopy.crs as ccrs
import cartopy.feature as cfeature


def ocean_fig():
    fig = plt.figure()
    ax = fig.add_subplot(111, projection=ccrs.NorthPolarStereo())

    ax.add_feature(cfeature.OCEAN.with_scale('10m'))
    
    return fig


import timeit

setup = """
from __main__ import ocean_fig
fig = ocean_fig()
"""

print(timeit.timeit('fig.draw_without_rendering()', setup=setup, number=5))  

@rcomer
Copy link
Member Author

rcomer commented Apr 23, 2025

CI failures are in test_wfs_france so not my fault!

Copy link
Contributor

@greglucas greglucas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to change something that is broken for something that is slow and works :)

@@ -1251,7 +1251,14 @@ def _rings_to_multi_polygon(self, rings, is_ccw):
box = sgeom.box(x3, y3, x4, y4, ccw=is_ccw)

# Invert the polygons
polygon = box.difference(sgeom.MultiPolygon(interior_polys))
try:
polygon = box.difference(sgeom.MultiPolygon(interior_polys))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to call make_valid() before doing the box.difference() call here? Or would that be just as slow potentially...

Copy link
Member Author

@rcomer rcomer Apr 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually that seems to take no time at all. I ran my benchmark in the OP with and without make_valid and it doesn't consistently take longer with make_valid.

Let's do that 👍

@greglucas
Copy link
Contributor

CI failures are in test_wfs_france so not my fault!

I noticed that on main too. We should probably xfail that for now.

@rcomer rcomer changed the title FIX: remove too-close holes from projected polygon individually FIX: make hole multipolygon valid before removing from projected polygon Apr 26, 2025
@greglucas greglucas merged commit 7ec054e into SciTools:main Apr 26, 2025
23 checks passed
@QuLogic QuLogic added this to the Next Release milestone Apr 27, 2025
@rcomer rcomer deleted the bad-multipoly branch April 27, 2025 08:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants