I think it would be good to start planning a 1.8.0 release, so opening an issue to track this (@sgillies).

Remaining issues tagged with the milestone: https://github.com/Toblerity/Shapely/milestone/37

(there are a few older feature requests that haven't seen any movement on the milestone; those can probably be moved to a next milestone / removed from the milestone?)

Regarding the deprecations and changes in preparation of the Shapely 2.0 RFC:

• Deprecations are mostly done (tracked in https://github.com/Toblerity/Shapely/issues/932), we still need to decide on the STRtree (https://github.com/Toblerity/Shapely/pull/1064) and deprecation of __len__ (https://github.com/Toblerity/Shapely/pull/1075)
• A good overview of those deprecations was added in https://github.com/Toblerity/Shapely/pull/1180

Vectorized functions would be a big help to GeoPandas and other projects trying to organize Shapely geometry in arrays, and there seems to be a consensus that it's best to implement the vectorized GEOS functions within Shapely. (See https://github.com/geopandas/geopandas/issues/430#issuecomment-291083993.)

After taking a look through the code I think we could implement this without too much trouble by adding a version of topology.py that generates vectorized versions of the functions. At that point it would be easy to call the functions from the vectorized module, or add them to the BaseGeometry class, or call them in Geopandas (I think).

I just want to get some feedback to make sure I'm on the right track before I start this, and figure out where people should send the pull requests.

Expected behavior and actual behavior.

Shapley should look for libgeos_c in the new Homebrew path for M1 machines.

Here's the release notes for Homebrew's path change on Apple silicon.

# shapely/geos.py

alt_paths = [
    # The Framework build from Kyng Chaos
    "/Library/Frameworks/GEOS.framework/Versions/Current/GEOS",
    # macports
    "/opt/local/lib/libgeos_c.dylib",
    # homebrew
    "/usr/local/lib/libgeos_c.dylib",
    # homebrew apple silicon M1 <-- add this
    "/opt/homebrew/lib/libgeos_c.dylib", <-- add this
]

I'm happy to open a PR on this ~

Steps to reproduce the problem.

1. poetry install shapely
2. if on an M1 machine: run any script with shapely import

Operating system

Mac OS X 11.1

Shapely version and provenance

shapely 1.7.1, installed via poetry

We have a few but relevant fixes in the maint-1.8 branch:

• #1264
• #1224
• #1235

For which it might be worth doing a 1.8.1 release? (@mwtoews @sgillies)

Especially the cython update + removal of .c files is important to have shapely installable from source on newer pythons.

.. and use the pygeos functions for all the Geometry methods/properties.

This is a first step for integrating PyGEOS into Shapely (https://github.com/Toblerity/Shapely/issues/962):

• For now I still use PyGEOS as an external dependency (it will be merged into Shapely in a later step, I first wanted to ensure this essential part is working out)
• This makes all the Geometry classes (Point, LineString, Polygon, etc) subclasses of the pygeos.Geometry extension type.
• This also registers those subclasses to pygeos. This means that all pygeos functions will start to return the correct shapely subclass, and not the generic pygeos.Geometry
• For most of the methods and properties of the Geometry classes, I switched to using pygeos functions (eg geom_factory(self.impl['difference'](self, other)) to pygeos.difference(self, other)). For other functionality in most other modules (eg shapely.ops etc), this is still left as is and keeps using the ctypes interface (this can be cleaned up later in a separate PR)
• A large chunk of the diff is actually the re-implementation of the Point(), Linestring(..), Polygon(..) etc constructors, as those don't directly map to the pygeos functions to create geometries from coordinates (the shapely ones are more flexible / allow more variation in input types)
• All tests are passing locally (with pygeos master), but I xfailed a bunch of tests where there are small differences or where we still need to implement something in the pygeos code to support it. But so it can be seen explicitly in the diff which ones are not yet passing.

cc @caspervdw

Created the affine_matrix_builder class in affinity.py to allow affine matrices to be combined. Affine transforms can now be applied with geom_transformed = affine_matrix_builder(Point(1,1)).rotate(90,(0,0)).translate(20, 30).transform() It also automatically determines when to combine the affine matrices or when to apply the last transform and store the current transform.

Tests for the class have been added in test_affinity.py

Documentation has been updated for the class in manual.rst

Runtime of some affine transforms has decreased by 30%

This PR tries to consolidate the STRtree implementations of Shapely and PyGEOS.

For now, I did the following:

• Rename pygeos' query to query_items to follow the API discussion / refactoring from #1064, #1112. Compared to the current shapely version, this query_items now has the additional predicate and distance keywords.
• ~Rename pygeos' nearest method to nearest_bulk. I am not very of this new name, but so we have to discuss / decide how to otherwise resolve the inconsistency with shapely's current nearest which only accepts a single geometry as input and returns a single index (instead of 2D array).~ Rename pygeos' nearest to nearest_item and changed it to return a 1D instead of 2D array (see discussion below) to have it be compatible with the shapely version. Compared to the current shapely version of nearest_item, the new version is vectorized and can accept an array of geometries.
• Added pygeos' query_bulk and nearest_all as is, as those are strictly new features not clashing with existing shapely methods.

See also some of the discussion in https://github.com/pygeos/pygeos/issues/398

Note for reviewing: I actually removed shapely's strtree.py and updated the pygeos version (strtree_pygeos.py) with new things from shapely in a first commit, and then renamed that to strtree.py in a second commit. So if you want to see the changes coming from pygeos, check the diff of only the first commit, while in the overall diff git shows the changes compared to shapely's existing strtree.py.

I still need to merge the docstrings (and especially the example sections)

Now that #1066 is closed, here are a few follow-up tasks:

• [x] Create maint-1.8 maintenance branch, i.e. this is the last release series with ctypes support, which sometimes require patching
• [x] Review items for the 1.8 milestone and either close or move forward, depending on what makes sense
• [x] Move master -> main -- this is as good enough of a time as any; see #1148 for a bit of discussion
• [x] Consider moving repo from https://github.com/Toblerity/Shapely to https://github.com/shapely/shapely as vaguely discussed in #819. I'm neutral on this task, but it should be discussed more thoroughly before.
• [x] Add maint-1.8 version to https://readthedocs.org/projects/shapely/

After these have been cleared, there is plenty of work ahead with #962 and beyond.

Comments before action on any of these tasks is welcome here.

In context of the Shapely 2.0 RFC (https://github.com/shapely/shapely-rfc/pull/1/) we had some discussion about storing/returning integer indices instead of geometry objects, but didn't yet finalize the exact API how we want this to look like.

With this PR, I am testing one concrete option, and which can then also trigger some discussion about this, and if we agree on the API, I can also update the RFC text about that.

Generally, I think we can always store the indices in the GEOS tree, and then on the python level we can still return geometries or indices as we want (since we store the original geometries which are inserted into the GEOS tree).
Then specifically in this PR, I am keeping the existing query and nearest methods of the STRtree, but add a return_geometries keyword. Currently, I set it as default to True (to preserve existing behaviour). But then, we can also decide to raise a warning in Shapely 1.8 that this will switch to False, and have it set to False as default in Shapely 2.0 (so then by default return indices), as a way to have a deprecation cycle.

Some possible alternatives / discussion points (also based on aspects mentioned in the RFC discussion):

• If we are fine with a keyword, is return_geometries=True/False good? Other ideas?
• Keep a single class, but separate methods that return indices (eg query_index and query_geometries)
• Separate class with the behaviour to return indices

Personally, I think a keyword option in a single method is the cleanest and easiest to implement (but certainly open to the other options as well). It's also similar to rtree's idx.intersection(..., objects=False).

Whichever option we choose, I think it will be straightforward to add it to the pygeos-based implementation for Shapely 2.0.

This PR obviously still needs more tests.

Also closes #615 (this PR is based on @snorfalorpagus's comment there)

cc @sgillies @mwtoews @caspervdw @brendan-ward

I'm not 100% what the right solution is for shapely (which is why this issue is not a PR), but we needed to apply this patch to get Shapely to successfully build a conda package on OS X that uses the conda install of libgeos: https://github.com/TheClimateCorporation/conda-recipes/blob/cd57916a02a4f97b71ca5937ee98e1499f131c73/shapely/osx-geos.patch

It would be nice to get a fix for this in Shapely. Here is a discussion with more context for this fix: https://groups.google.com/a/continuum.io/d/msg/conda/kw2xC4wjI-Y/wDHMYeTZDeEJ

Note that in my version of the patch, I needed to change it look in sys.prefix before the other locations, because I had another, non-conda version of geos installed (installed via brew) which shapely was linking to instead.

CC @ilanschnell @pelson @rsignell-usgs

For 1.8.0, we had quite some discussion in https://github.com/shapely/shapely/pull/1064 (and in https://github.com/shapely/shapely/pull/1094 and https://github.com/shapely/shapely/pull/1112), about the exact API we wanted for STRtree. In the end we settled on adding query_items() and query_geoms methods (in addition to query) instead of adding a keyword (like return_geometries=True/False) in query(). https://github.com/shapely/shapely/pull/1112 also added the functionality to pass custom items to the the STRtree(.., items=..) constructor.

But in https://github.com/shapely/shapely/pull/1251, where I merged the pygeos functionality with this Shapely interface, we had again some discussion about this, indicating that it might not yet be fully resolved.

One of the discussion points is the usage of the term "items" (https://github.com/shapely/shapely/pull/1251#issuecomment-1051407542). While the method is called query_items(), I used "index" in the update of the docstring.

Return the index (or stored item) of all geometries in the tree with extents that intersect the envelope of the input geometry.

The returned items may be identified by an integer index (default) or arbitrary item values (optional) if those are provided when constructing the tree.

But this triggered some comments about it (eg https://github.com/shapely/shapely/pull/1251#discussion_r795242461 or https://github.com/shapely/shapely/pull/1251#discussion_r795242032). While I think we can certainly get agreement on how to understand the default behaviour, it might point to the fact that the API is not yet really ideal (also given the fact that we have a hard time to clearly / succinctly explain this in the documentation).

Some other issues with the current naming in the API:

• The default is to return integer indices (if the user only provided geometries to the STRtree constructor), but the method is actually called query_items() using "items".
  (I personally think that most people will never pass explicit items, but will rather use the indices)
• The query_bulk() method only returns integer indices, and never items (even if the user passed those in the constructor), creating some more inconsistency. And the same applies to nearest_all. (The reason for this is that this methods takes an array of query geometries as input, and so returns indices into both the tree and input geometries. Alternatively, we could require that you pass items as well to the query_bulk method, but this would further complicate this method)

So possible outcomes:

• Decide we are fine with how it is now, and maybe only tweak the docstring a bit further.
• Reconsider the ability to pass custom items, to avoid the dichotomy between "items" and "indices" (and it easy to mimic this as a user).
• Reconsider the full API (i.e. the different options mentioned in https://github.com/shapely/shapely/pull/1064#issue-785861351: a keyword, different methods, different classes)

cc @sgillies @caspervdw @brendan-ward @mwtoews

I have encountered a problem with folded polygons that despite the use of ``shapely.geometry.polygon.orient``` are not describe fully oriented counter-clockwise.

I have described the problem from the cartopy project but this issue is in fact related to shapely.

See: https://github.com/SciTools/cartopy/issues/2111 Initialy from: https://stackoverflow.com/questions/74710358/how-to-detect-inner-polygons-from-a-multipolygon-shapely-object

So my question is: How to force the orientation of a folded polygon to be oriented counter-clockwise ?

import cartopy.crs as ccrs
import matplotlib.pyplot as plt
import matplotlib.patches
import numpy as np

fig = plt.figure(figsize=(10,5))

map_proj = ccrs.Robinson(105)
ax = fig.add_subplot(1, 1, 1, projection=map_proj)

ax.set_global()
ax.gridlines()

transform = ccrs.Geodetic()

poly0 =  np.array([
    [-70,  10],
    [-60,  10],
    [-60,  20],
    [-70,  20],
    [-81,  20],
    [-80,  30],
    [-70,  30],
    [-70,  20],
    [-70,  10]
])
poly1 =  np.array([
    [-70,  10],
    [-60,  10],
    [-60,  20],
    [-70,  20],
    [-70,  30],
    [-80,  30],
    [-81,  20], 
    [-70,  20],
    [-70,  10]
])
polyCode = np.array([ 1, 2, 2, 2, 2, 2, 2, 2, 79])

# works with poly1 (filled correclty)
path =  matplotlib.path.Path(poly0, polyCode)

patch = matplotlib.patches.PathPatch(path, facecolor='red', edgecolor='black', transform=transform)
ax.add_patch(patch)

plt.show()

This PR stems from my use case to get a Matplotlib patch from a Shapely polygon, but manipulate it in my own GUI instead of directly plotting it.

This adds a new patch_from_polygon() function that is internally called by plot_polygon() but can also be used standalone to return a patch without plotting. In the process I also did some slight cleanup.

Hi,

This issue is to discuss how we can make Shapely support more sustainable, meaning that Issues/PRs will get more promptly support and also that companies/individuals that want some new feature would have easy way to fund it.

As far as I see Shapely was not funded or accept donations, and some dear people are maintaining the project as volunteers in their free time. This issue is NOT to complain about anyone - quite the opposite - By first acknowledge and saying thank you for the people who donated their time and effort for supporting this wonderful project. This issue is to discuss how we can make it even better.

A recent quote of @jorisvandenbossche https://github.com/shapely/shapely/issues/1668#issuecomment-1366884171: As you might have noticed the last two weeks, the feedback capacity and response time in the project in general is not that great .. Time from maintainers is limited, and I am myself also helping to maintain shapely as a volunteer in my free time. That means that contributions from others are very much appreciated! But that also means that it helps keeping PRs as focused as possible, making it easier to review them, increasing the chance you get a timely review and PRs get merged in a reasonable time (which will also help to ensure contributing to shapely is a rewarding experience also for you)

A side effect of this situation, is that some PRs (sometimes even trivial fixes/enhancements) are standing for weeks or sometimes even months without discussion or just not getting merged after the discussion was concluded positively. Sadly, this might lead to discouragement of future contributions by people who made efforts to improve Shapely and made PRs or even discourage new contributors from getting involved in the first place.

I would like to point out two solutions for a similar issues in GDAL and QGIS. Please feel free to propose other ideas.

GDAL - Numfocus (dated January-July 2021):

https://gdal.org/development/rfc/rfc80_numfocus_relationship.html https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html https://numfocus.org/sponsored-projects/affiliated-projects https://docs.google.com/document/d/1yhMWeI_LgEXPUkngqOitqcKfp7ov6WsS41v5ulz-kd0/edit https://docs.google.com/document/d/1bc5jdpCe1axdyBHxbJnun7e0DTyDoZI_eFYgJYnOhB8/edit https://lists.osgeo.org/pipermail/gdal-dev/2021-April/053886.html https://lists.osgeo.org/pipermail/gdal-dev/2021-January/053303.html

QGIS Commercial support/Grant/crowd-finding: https://www.qgis.org/en/site/forusers/commercial_support.html https://blog.qgis.org/2022/01/16/qgis-grants-7-call-for-grant-proposals-2022/ https://plugins.qgis.org/planet/tag/crowdfund/

Thanks again for the maintainers and other supporters who contribute to Shapely on their free time. Thanks, and happy new year!

From: https://github.com/shapely/shapely/pull/1231#discussion_r1059400963_

https://numpydoc.readthedocs.io/en/latest/format.html#parameters

Valid syntax:

copy : bool, default True
copy : bool, default=True
copy : bool, default: True

What is the preferred syntax for the Shapely project for default values in docstrings? (just for clarity so things can be consistent)

I used the shapely.ops.substring method in my project. There was no issue in shapely 1.8.4. Today I upgraded to shapely 2.0.0 and I'm getting an error from calling this:

shapely.ops.substring(trajectory, dist1, dist2)

where the trajectory is a LineString type (LINESTRING Z), it contains Z coordinates.

setting an array element with a sequence. The requested array has an inhomogeneous shape after 1 dimensions. The detected shape was (14,) + inhomogeneous part

It looks like only X, and Y of the start_point and end_point is used in the vertex_list for constructing the LineString

I'm using: Ubuntu 20.04 shapely 2.0.0