-
Notifications
You must be signed in to change notification settings - Fork 902
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
ENH: include coverage_union_all in union_all and dissolve #3151
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @martinfleis , this seems like a better way to expose coverage_union_all
from Shapely.
A few docstring suggestions...
geopandas/base.py
Outdated
Parameters | ||
---------- | ||
coverage : bool (default False) | ||
Whether to assume non-overlapping coverage and opt-in for the faster |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest using the same docstring as below
If True, will use the faster coverage union to merge geometries.
If False, the default slower but robust union will be used.
Change the keyword to |
Co-authored-by: Brendan Ward <bcward@astutespruce.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks martin, looks good to me! Good spot on changing to method=
instead of a boolean, that future proofs things nicely.
Co-authored-by: Matt Richards <45483497+m-richards@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
Co-authored-by: Joris Van den Bossche <jorisvandenbossche@gmail.com>
… into coverage_all
Xref #2010
I was surprised how faster this actually is. On geodatasets'
geoda.south
it goes from 121 ms to 4.43 ms. It will likely depend on the data but it is impressive nonetheless.The formulations in the docstring feel a bit sloppy so I'd appreciate some native speaker to check if it makes sense.