Skip to content
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

Add GEOSVoronoiDiagram to shapely #881

Merged
merged 20 commits into from
Apr 7, 2020
Merged

Conversation

tomplex
Copy link
Contributor

@tomplex tomplex commented Mar 31, 2020

Per #833.

I thought it made sense to keep Delauney / Voronoi close together in the code since they're similar in use and right next to each other in the CAPI, but if you disagree I'm happy to move it to wherever.

I couldn't nail down for sure exactly when VoronoiDiagram was added to the CAPI. This entry was the best I could find indicating release version, so I went with 3.5.0.

@coveralls
Copy link

coveralls commented Mar 31, 2020

Coverage Status

Coverage increased (+0.1%) to 81.477% when pulling 2efb189 on tomplex:voronoi-diagram into 808fd46 on Toblerity:master.

@tomplex tomplex changed the title WIP: Add GEOSVoronoiDiagram to shapely Add GEOSVoronoiDiagram to shapely Mar 31, 2020


@requires_geos_35
def test_from_polygon_without_enough_tolerance():
Copy link
Contributor Author

@tomplex tomplex Mar 31, 2020

Choose a reason for hiding this comment

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

This test and the ones below it drive some un-intuitive behavior with regards to the tolerance argument. The first case is when we specify a tolerance to the function which is, I guess, "not enough"? I'm not necessarily sure how the tolerance value is associated with snapping (I need to look at the source C code more) but the C API returns a null geometry, which throws an error in the geom_factory function.

The case below is perhaps more interesting: if we specify a tolerance and we don't have any floating point coordinates, then we also get a null geometry back.

Either way, I added some code to catch the generic error about creating geometry from null values and raise an error which is generally more descriptive, but I wonder if it's worth calling this behavior out specifically in an error? Or is it overkill? Either way I also added some info to the docstrings & docs.


def voronoi_diagram(geom, envelope=None, tolerance=0.0, edges=False):
"""
Constructs a Voronoi Diagram [1] from the given geometry.
Copy link
Contributor

Choose a reason for hiding this comment

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

Most of this is over my head but it looks really nice. I think you need a underscore after the references in numpydocs if we want it to build with hyperlinks eventually. Like this: [1]_. And you'll also want to add a .. before each reference down in the References section.

See point number 14 here: https://numpydoc.readthedocs.io/en/latest/format.html

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll defer to @sgillies on this, I'm happy to add the extra formatting if the docstrings will be built into documentation, but if they're mostly used for inline help (like help(voronoi_diagram)) then the extra formatting might not be helpful. Either way thanks for the suggestion! =)

shapely/ops.py Outdated Show resolved Hide resolved
shapely/ops.py Outdated Show resolved Hide resolved
shapely/ops.py Outdated Show resolved Hide resolved
@jorisvandenbossche
Copy link
Member

The current return value is a list of geometries. Could it also be considered to return the actual GeometryCollection (as it is returned by GEOS)? The user could then still get the list by doing result.geoms themselves.

I assume that for users that pass a single geometry, the current API returning a list is easier (and also more consisitent with the existing triangulate, which is a good reason of course ..). But returning a geometry collection would make it easier to have it compatible with the PyGEOS version.

@tomplex
Copy link
Contributor Author

tomplex commented Apr 1, 2020

@jorisvandenbossche, though I personally agree that a GeometryCollection feels like a better option since that's what being returned natively by GEOS, I think one of the best parts of Shapely is the consistency and therefore intuitiveness of the API, so I went with a list of geometries. I'd be happy to discuss more if you feel strongly, especially because it seems like there will be a closer union of Shapely and PyGeos in the future, so it makes sense to take consistency between the two libraries into account.

@sgillies sgillies modified the milestones: Shapely 3001, 1.8 Apr 2, 2020
@tomplex
Copy link
Contributor Author

tomplex commented Apr 6, 2020

@sgillies should I rebase this onto master?

@sgillies
Copy link
Contributor

sgillies commented Apr 6, 2020

@tomplex yes, please.

Returning a GeometryCollection would be more efficient and I'm in favor 👍

@tomplex tomplex changed the base branch from maint-1.7 to master April 7, 2020 02:32
Copy link
Contributor

@sgillies sgillies left a comment

Choose a reason for hiding this comment

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

@tomplex thank you!

@sgillies sgillies merged commit da5b611 into shapely:master Apr 7, 2020
BuonOmo added a commit to BuonOmo/geos that referenced this pull request Oct 14, 2022
**change**

the getDiagramEdges now only returns a MultiLineString, whether there is
one or many lines. Which reduces to two the number of possible kind of
geometries given by `GEOSVoronoiDiagram`

**reason**

I've been working on adding `voronoi_diagram` to RGeo. And looking at
the [Shapely PR for voronoi diagram][1] and [mine in RGeo][2], it seems
like the `GEOSVoronoiDiagram` CAPI method causes confusion by returning
three possible kind of geometries:

- `GeometryCollection` (when `onlyEdges` is false)
- `MultiLineString` (`onlyEdges` is true and there are at least two lines)
- `LineString` (`onlyEdges` is true and there is only one line)

The parameter `onlyEdges` changes the outcome, which is ok to reason
about. However, the fact that we could have either a LineString or a
MultiLineString is way harder to work around in my opinion.

[1]: shapely/shapely#881 (comment)
[2]: rgeo/rgeo#334 (comment)
BuonOmo added a commit to BuonOmo/geos that referenced this pull request Oct 17, 2022
**change**

the getDiagramEdges now only returns a GeometryCollection, whether there
is one or many lines. So `GEOSVoronoiDiagram` now can only return a
GeometryCollection itself.

**reason**

I've been working on adding `voronoi_diagram` to RGeo. And looking at
the [Shapely PR for voronoi diagram][1] and [mine in RGeo][2], it seems
like the `GEOSVoronoiDiagram` CAPI method causes confusion by returning
three possible kind of geometries:

- `GeometryCollection` (when `onlyEdges` is false)
- `MultiLineString` (`onlyEdges` is true and there are at least two lines)
- `LineString` (`onlyEdges` is true and there is only one line)

The fact that we could have either a LineString or a MultiLineString is
quite confusing. And wrapping the whole result in a GeometryCollection
is actually [not a significant overhead][3]. Hence the choice of always
returning a GeometryCollection.

[1]: shapely/shapely#881 (comment)
[2]: rgeo/rgeo#334 (comment)
[3]: libgeos#702 (comment)
BuonOmo added a commit to BuonOmo/geos that referenced this pull request Oct 17, 2022
**change**

the getDiagramEdges now only returns a GeometryCollection, whether there
is one or many lines. So `GEOSVoronoiDiagram` now can only return a
GeometryCollection itself.

**reason**

I've been working on adding `voronoi_diagram` to RGeo. And looking at
the [Shapely PR for voronoi diagram][1] and [mine in RGeo][2], it seems
like the `GEOSVoronoiDiagram` CAPI method causes confusion by returning
three possible kind of geometries:

- `GeometryCollection` (when `onlyEdges` is false)
- `MultiLineString` (`onlyEdges` is true and there are at least two lines)
- `LineString` (`onlyEdges` is true and there is only one line)

The fact that we could have either a LineString or a MultiLineString is
quite confusing. And wrapping the whole result in a GeometryCollection
is actually [not a significant overhead][3]. Hence the choice of always
returning a GeometryCollection.

[1]: shapely/shapely#881 (comment)
[2]: rgeo/rgeo#334 (comment)
[3]: libgeos#702 (comment)
BuonOmo added a commit to BuonOmo/geos that referenced this pull request Nov 10, 2022
**change**

the getDiagramEdges now only returns a GeometryCollection, whether there
is one or many lines. So `GEOSVoronoiDiagram` now can only return a
GeometryCollection itself.

**reason**

I've been working on adding `voronoi_diagram` to RGeo. And looking at
the [Shapely PR for voronoi diagram][1] and [mine in RGeo][2], it seems
like the `GEOSVoronoiDiagram` CAPI method causes confusion by returning
three possible kind of geometries:

- `GeometryCollection` (when `onlyEdges` is false)
- `MultiLineString` (`onlyEdges` is true and there are at least two lines)
- `LineString` (`onlyEdges` is true and there is only one line)

The fact that we could have either a LineString or a MultiLineString is
quite confusing. And wrapping the whole result in a GeometryCollection
is actually [not a significant overhead][3]. Hence the choice of always
returning a GeometryCollection.

[1]: shapely/shapely#881 (comment)
[2]: rgeo/rgeo#334 (comment)
[3]: libgeos#702 (comment)
BuonOmo added a commit to BuonOmo/geos that referenced this pull request Nov 10, 2022
Improve consistency of GEOSVoronoiDiagram
**change**

the getDiagramEdges now only returns a MultiLineString, whether there is
one or many lines. Which reduces to two the number of possible kind of
geometries given by `GEOSVoronoiDiagram`

**reason**

I've been working on adding `voronoi_diagram` to RGeo. And looking at
the [Shapely PR for voronoi diagram][1] and [mine in RGeo][2], it seems
like the `GEOSVoronoiDiagram` CAPI method causes confusion by returning
three possible kind of geometries:

- `GeometryCollection` (when `onlyEdges` is false)
- `MultiLineString` (`onlyEdges` is true and there are at least two lines)
- `LineString` (`onlyEdges` is true and there is only one line)

The parameter `onlyEdges` changes the outcome, which is ok to reason
about. However, the fact that we could have either a LineString or a
MultiLineString is way harder to work around in my opinion.

[1]: shapely/shapely#881 (comment)
[2]: rgeo/rgeo#334 (comment)
BuonOmo added a commit to BuonOmo/geos that referenced this pull request Nov 10, 2022
Improve consistency of GEOSVoronoiDiagram
**change**

the getDiagramEdges now only returns a MultiLineString, whether there is
one or many lines. Which reduces to two the number of possible kind of
geometries given by `GEOSVoronoiDiagram`

**reason**

I've been working on adding `voronoi_diagram` to RGeo. And looking at
the [Shapely PR for voronoi diagram][1] and [mine in RGeo][2], it seems
like the `GEOSVoronoiDiagram` CAPI method causes confusion by returning
three possible kind of geometries:

- `GeometryCollection` (when `onlyEdges` is false)
- `MultiLineString` (`onlyEdges` is true and there are at least two lines)
- `LineString` (`onlyEdges` is true and there is only one line)

The parameter `onlyEdges` changes the outcome, which is ok to reason
about. However, the fact that we could have either a LineString or a
MultiLineString is way harder to work around in my opinion.

[1]: shapely/shapely#881 (comment)
[2]: rgeo/rgeo#334 (comment)
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.

None yet

5 participants