ENH: expose all shapely functions as GeoSeries/GeometryArray methods

[martinfleis]

shapely now contains some functions which could be exposed as methods on GeoSeries/GeometryArray levels.

Probably incomplete list of candidates (updated Feb 13, 2023):

• buffer signature parity ENH: buffer signature parity with shapely #3116
• build_area ENH: add build_area #3202
• contains_properly ENH: add contains_properly predicate method #3105
• coverage_union API: how to expose coverage_union? #3117
• coverage_union_all ENH: include coverage_union_all in union_all and dissolve #3151
• dwithin ENH: add GeoSeries.dwithin #3153
• force_2d ENH: add force_2d and force_3d #3090
• force_3d ENH: add force_2d and force_3d #3090
• get_num_coordinates (ENH: expose relevant get_num_* functions as count_geometries and count_interior_rings #3154)
• get_num_geometries (ENH: expose relevant get_num_* functions as count_geometries and count_interior_rings #3154)
• get_num_interior_rings (ENH: expose relevant get_num_* functions as count_geometries and count_interior_rings #3154)
• get_precision ENH: set_precision and get_precision methods #3175
• get_geometry ENH: add get_geometry from shapely #3287
• intersection_all ENH: add intersection_all #3228
• is_closed ENH: explose is_closed on a base level #3092
• is_valid_reason ENH: add is_valid_reason method #3176
• line_merge ENH: add line_merge method #3214
• polygonize ENH: add GeoSeries.polygonize #2963
• polygonize_full ENH: add GeoSeries.polygonize #2963
• relate_pattern ENH: add relate_pattern method #3211
• set_precision ENH: set_precision and get_precision methods #3175
• shared_paths ENH: add shared_paths method #3215
• snap ENH: expose snap #3086
• symmetric_difference_all - see Questionable behaviour of symmetric_difference_all shapely/shapely#2027
• transform ENH: Expose transform #3075
• voronoi_polygons ENH: add voronoi_polygons method #3177
• oriented_envelope ENH: Added minimum_rotated_rectangle from shapely #2541
• concave_hull ENH: add concave_hull as GeoSeries method #2903
• count_coordinates ENH: Add count coordinates #3026
• delaunay_triangles ENH: add delaunay_triangles as GeoSeries method #2907
• extract_unique_points ENH: add extract_unique_points as a GeoSeries property #2915
• frechet_distance ENH: add frechet_distance method #2929
• hausdorff_distance ENH: add hausdorff distance method #2909
• is_ccw ENH: Add is_ccw from shapely #3027
• minimum_bounding_radius ENH: add minimum_bounding_radius as GeoSeries method #2827
• minimum_clearance ENH: add minimum_clearance to geopandas from shapely #2989
• minimum_rotated_rectangle ENH: Added minimum_rotated_rectangle from shapely #2541
• offset_curve ENH: add offset_curve as GeoSeries method #2902
• remove_repeated_points ENH: add remove_repeated_points as a GeoSeries method #2940
• reverse ENH: expose reverse #2988
• segmentize ENH: add segmentize as a GeoSeries method #2910
• shortest_line ENH: add shortest_line from shapely #2960
• destroy_prepared (don't expose)
• from_geojson (duplication)
• from_ragged_array (too low level)
• is_prepared (don't expose)
• node ENH: add node as a GeoSeries method #2925
• prepare (don't expose)
• set_coordinates (don't expose)
• to_geojson (duplication)
• to_ragged_array (too low level)
• contains_xy ENH: add contains_xy and intersects_xy methods #3114
• intersects_xy ENH: add contains_xy and intersects_xy methods #3114
• get_dimensions (ignore due to overlap with has_z)
• get_num_points (ignore due to overlap with count_coordinates)

From upcoming Shapely 2.1

• has_m
• get_m / .m

[Zeroto521]

About the API design problem.

Would these pygeos methods be GeoSeries/GeometryArray's methods or gather them into accessors (after #1952 is done)?

Use coordinate ops as the example:

• GeoSeries.count_coordinates(), this way would easily use.
• GeoSeries.coord.count_coordinates() ( or GeoSeries.coord.count()), this way has a hierarchical relationship for different methods.

[martinfleis]

I imagined methods. It is shorter and there's surely no overlap in naming as pygeos exposes all as top-level functions. And it is consistent with the existing methods.

Do you think that there are some significant benefits of preferring accessors?

[bitanb1999]

Hello @martinfleis, I believe for implementing the measurements such as Frechet, Hausdorff distance, and so on, we would have to consider the combinations of the different trajectories formed by the edges of the polygons of the GeoSeries elements or is straight-up between two shapely objects?

[martinfleis]

@bitanb1999 No, it is a distance between two geometries. See the pygeos API.

We need to turn this API:

pygeos.hausdorff_distance(a, b, densify=None, **kwargs)

To this API:

geopandas.GeoSeries.hausdorff_distance(b, densify=None)

It is just about exposing those functions as they are as GeoPandasBase methods, nothing else. In most of the cases, it should be very straightforward as we just need to mirror how other functions are exposed.

[bitanb1999]

@martinfleis Thank you for the clarification! That indeed seems pretty straightforward! Is this issue up for the GSoC 2022?

[martinfleis]

Is this issue up for the GSoC 2022?

Probably not, the small-size GSoC project is 175 hours. Implementing all listed above will be a matter of <10 hours. Have a look at GSoC project ideas here https://github.com/geopandas/geopandas/wiki/Google-Summer-of-Code-2022 to get a sense of scale. Or pick one of them directly :).

[bitanb1999]

Is this issue up for the GSoC 2022?

Probably not, the small-size GSoC project is 175 hours. Implementing all listed above will be a matter of <10 hours. Have a look at GSoC project ideas here https://github.com/geopandas/geopandas/wiki/Google-Summer-of-Code-2022 to get a sense of scale. Or pick one of them directly :).

Oh okay! Thank you!

[bitanb1999]

Is this issue up for the GSoC 2022?

Probably not, the small-size GSoC project is 175 hours. Implementing all listed above will be a matter of <10 hours. Have a look at GSoC project ideas here https://github.com/geopandas/geopandas/wiki/Google-Summer-of-Code-2022 to get a sense of scale. Or pick one of them directly :).

Another question: Is it possible to integrate GEE with GeoPandas for heavy research-based visualisations?

[martinfleis]

Is it possible to integrate GEE with GeoPandas for heavy research-based visualisations?

I think that geemap is your best shot at the moment https://geemap.org/notebooks/geopandas/. But we're out of topic here :).

[bitanb1999]

Is it possible to integrate GEE with GeoPandas for heavy research-based visualisations?

I think that geemap is your best shot at the moment https://geemap.org/notebooks/geopandas/. But we're out of topic here :).

Yes, the question was associated with the GSoC ideas. Thank you for answering!

[martinfleis]

@bitanb1999 If you want to have a chat about GSoC ideas, feel free to move it to out gitter https://gitter.im/geopandas/geopandas. Happy to have a discussion there!

[EwoutH]

Probably not, the small-size GSoC project is 175 hours. Implementing all listed above will be a matter of <10 hours.

Do you still think this estimate is accurate?

It would be very nice to have all those functions exposed, and if this could be a potential GSoC project, the time to start thinking about that is around now.

[martinfleis]

Do you still think this estimate is accurate?

No, given the number and variety of shapely functions not exposed, it will be significantly longer with proper tests and documentation. Some are easy but a lot is not and we'll need to figure out how to seamlessly implement them here.

We're usually doing GSoC under the NumFOCUS umbrella so there's a bit more time for us.

[bretttully]

I'm very keen to get the precision functions from shapely2/pygeos in. If someone can point me to the best place to put them, I am happy to have a go at a PR.

Ideally, I'd like to have an API like

gdf = gpd.GeoDataFrame(...)  # maybe an optional ctr param?
gdf.set_precision(...)  # with and without inplace

One thing I would really like is to be able to (de)serialize this via files like geoparquet, but I suspect that is asking way too much, or at least can be split into a distinct issue :-)

[martinfleis]

Historical reasons. GeoPandas API predates accessor API as far as I remember. It would make more sense if the original object was still a pandas.DataFrame with an extension array but we predate that possibility either. With the Geo* subclasses, it feels okay to expose all these directly.

[EwoutH]

I would love to be able to use GeoSeries.contains_xy() in the future!

[martinfleis]

@EwoutH feel free to come up with a PR for that. Otherwise I'll tackle it before 1.0 is out for sure.

[martinfleis]

get_dimensions has overlapping usage with has_z and is_empty. Not sure if it is worth implementing.

[martinfleis]

get_num_points, which returns a number of points in LineString and LinearRing only is also a candidate to ignore, given get_num_coordinates provides the same number for any geometry type.