Add merge overlaps function

[lisawink]

Have added a function merge_overlaps in overlap.py which merges any overlapping polygons sharing an overlap area larger than 'overlap_limit'. Overlapping polygons smaller than 'merge_limit' are always merged, no matter the overlap area. Tests are included in test_overlap.py and examples in overlaps.ipynb

[codecov]

Codecov Report

Attention: Patch coverage is 96.96970% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 73.49%. Comparing base (3202732) to head (a4fc4ad).
Report is 1 commits behind head on main.

Files	Patch %	Lines
geoplanar/overlap.py	96.96%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #50      +/-   ##
==========================================
+ Coverage   70.04%   73.49%   +3.44%     
==========================================
  Files           6        6              
  Lines         217      249      +32     
==========================================
+ Hits          152      183      +31     
- Misses         65       66       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sjsrey]

Thanks for this, @lisawink

This looks good to me and would add nicely to the package.

The one test is failing with an older version of geopandas. @martinfleis, I'm wondering if we want to consider dropping support/adding a min dep for geopandas, or should we add a skip test if we want to keep testing everything else on the older version?

[martinfleis]

I am not sure if that last example in the notebook is desired behaviour. It seems weird to see those two large polygons merged together.

[lisawink]

I agree it is weird, but because the polygons are merged in order, when the smaller polygon is merged to one of the bigger polygons, this now overlaps with the other big polygon, and so it is all merged together. Any other solution would require trimming, which could be done first with trim_overlaps, and then with merge_overlaps or merge_touching. I think it really depends on the use-case.

[martinfleis]

That's probably fair.

[sjsrey]

I had the same initial reaction as @martinfleis, but then, thinking through the logic, I agree with @lisawink that the results make sense.

This brings up a more general question of how the sequence of operations may result in different outcomes - I think this is a really interesting problem. I think the role of the package would be to handle individual operations correctly and provide the user with the ability to combine them in sequences that make sense for different use cases.

[martinfleis]

This brings up a more general question of how the sequence of operations may result in different outcomes - I think this is a really interesting problem. I think the role of the package would be to handle individual operations correctly and provide the user with the ability to combine them in sequences that make sense for different use cases.

Fully agree. In our case of building footprints, @lisawink spent some time figuring out the correct order of operations and it does indeed make a difference. But that will be case specific, so I would not impose any sequence within geoplanar.