Manipulation and analysis of geometric objects

Related tags

Geolocation Shapely
Overview

Shapely

github-actions appveyor coveralls

Manipulation and analysis of geometric objects in the Cartesian plane.

https://c2.staticflickr.com/6/5560/31301790086_b3472ea4e9_c.jpg

Shapely is a BSD-licensed Python package for manipulation and analysis of planar geometric objects. It is based on the widely deployed GEOS (the engine of PostGIS) and JTS (from which GEOS is ported) libraries. Shapely is not concerned with data formats or coordinate systems, but can be readily integrated with packages that are. For more details, see:

Usage

Here is the canonical example of building an approximately circular patch by buffering a point.

>>> from shapely.geometry import Point
>>> patch = Point(0.0, 0.0).buffer(10.0)
>>> patch
<shapely.geometry.polygon.Polygon object at 0x...>
>>> patch.area
313.65484905459385

See the manual for more examples and guidance.

Requirements

Shapely 1.7 requires

  • Python 2.7, >=3.5
  • GEOS >=3.3

Installing Shapely

Shapely may be installed from a source distribution or one of several kinds of built distribution.

Built distributions

Built distributions are the only option for users who do not have or do not know how to use their platform's compiler and Python SDK, and a good option for users who would rather not bother.

Linux, OS X, and Windows users can get Shapely wheels with GEOS included from the Python Package Index with a recent version of pip (8+):

$ pip install shapely

Shapely is available via system package management tools like apt, yum, and Homebrew, and is also provided by popular Python distributions like Canopy and Anaconda. If you use the Conda package manager to install Shapely, be sure to use the conda-forge channel.

Windows users have another good installation options: the wheels published at https://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely. These can be installed using pip by specifying the entire URL.

Source distributions

If you want to build Shapely from source for compatibility with other modules that depend on GEOS (such as cartopy or osgeo.ogr) or want to use a different version of GEOS than the one included in the project wheels you should first install the GEOS library, Cython, and Numpy on your system (using apt, yum, brew, or other means) and then direct pip to ignore the binary wheels.

$ pip install shapely --no-binary shapely

If you've installed GEOS to a standard location, the geos-config program will be used to get compiler and linker options. If geos-config is not on your executable, it can be specified with a GEOS_CONFIG environment variable, e.g.:

$ GEOS_CONFIG=/path/to/geos-config pip install shapely

Integration

Shapely does not read or write data files, but it can serialize and deserialize using several well known formats and protocols. The shapely.wkb and shapely.wkt modules provide dumpers and loaders inspired by Python's pickle module.

>>> from shapely.wkt import dumps, loads
>>> dumps(loads('POINT (0 0)'))
'POINT (0.0000000000000000 0.0000000000000000)'

Shapely can also integrate with other Python GIS packages using GeoJSON-like dicts.

>>> import json
>>> from shapely.geometry import mapping, shape
>>> s = shape(json.loads('{"type": "Point", "coordinates": [0.0, 0.0]}'))
>>> s
<shapely.geometry.point.Point object at 0x...>
>>> print(json.dumps(mapping(s)))
{"type": "Point", "coordinates": [0.0, 0.0]}

Development and Testing

Dependencies for developing Shapely are listed in requirements-dev.txt. Cython and Numpy are not required for production installations, only for development. Use of a virtual environment is strongly recommended.

$ virtualenv .
$ source bin/activate
(env)$ pip install -r requirements-dev.txt
(env)$ pip install -e .

The project uses pytest to run Shapely's suite of unittests and doctests.

(env)$ python -m pytest

Support

Questions about using Shapely may be asked on the GIS StackExchange using the "shapely" tag.

Bugs may be reported at https://github.com/Toblerity/Shapely/issues.

Comments
  • 1.8.0 release

    1.8.0 release

    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
    opened by jorisvandenbossche 37
  • Vectorize all GEOS functions

    Vectorize all GEOS functions

    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.

    enhancement 
    opened by wmay 35
  • Add new Homebrew path for M1 to alt_paths for libgeos_c

    Add new Homebrew path for M1 to alt_paths for libgeos_c

    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

    bug 
    opened by YoungiiJC 31
  • RLS: Shapely 1.8.1 release

    RLS: Shapely 1.8.1 release

    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.

    release 
    opened by jorisvandenbossche 28
  • Refactor Geometry classes to subclass the C extension type

    Refactor Geometry classes to subclass the C extension type

    .. 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

    opened by jorisvandenbossche 25
  • Improving affine_transform functions from issue #439

    Improving affine_transform functions from issue #439

    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%

    opened by BebeSparkelSparkel 25
  • API: update STRtree interface (merge shapely/pygeos features)

    API: update STRtree interface (merge shapely/pygeos features)

    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)

    opened by jorisvandenbossche 22
  • Post 1.8 tasks

    Post 1.8 tasks

    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.

    opened by mwtoews 22
  • Store indices instead of geometries in STRtree + option to keep returning geometries

    Store indices instead of geometries in STRtree + option to keep returning geometries

    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

    opened by jorisvandenbossche 22
  • Shapely needs a patch to work with conda on OS X

    Shapely needs a patch to work with conda on OS X

    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

    opened by shoyer 21
  • Finalizing the STRtree interface

    Finalizing the STRtree interface

    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

    needs discussion shapely 2.0 
    opened by jorisvandenbossche 19
  • orient function should work on folded polygons

    orient function should work on folded polygons

    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()
    

    image

    opened by PBrockmann 3
  • ENH: Allow getting matplotlib patch from polygon without plotting

    ENH: Allow getting matplotlib patch from polygon without plotting

    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.

    opened by sea-bass 1
  • Sustainable Shapely support

    Sustainable Shapely support

    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!

    opened by idanmiara 0
  • DOC: Syntax for default parameters in docstrings

    DOC: Syntax for default parameters in docstrings

    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)

    opened by snowman2 1
  • BUG: shapely.ops.substring issue with LineString Z in shapely 2.0.0

    BUG: shapely.ops.substring issue with LineString Z in shapely 2.0.0

    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

    bug 
    opened by jfulem 3
Releases(2.0.0)
  • 2.0.0(Dec 12, 2022)

    Shapely version 2.0.0 is a major release featuring a complete refactor of the internals and new vectorized (element-wise) array operations providing considerable performance improvements.

    For a full changelog, see https://shapely.readthedocs.io/en/latest/release/2.x.html#version-2-0-0

    Relevant changes in behaviour compared to 2.0rc3:

    • Added temporary support for unpickling shapely<2.0 geometries.
    Source code(tar.gz)
    Source code(zip)
    shapely-2.0.0.tar.gz(268.09 KB)
  • 2.0rc1(Nov 26, 2022)

    Relevant changes in behaviour compared to 2.0b2:

    • The Point(..) constructor no longer accepts a sequence of coordinates consisting of more than one coordinate pair (previously, subsequent coordinates were ignored) (#1600).
    • Fix performance regression in the LineString() constructor when passing a numpy array of coordinates (#1602).

    Wheels for 2.0rc1 published on PyPI include GEOS 3.11.1.

    Source code(tar.gz)
    Source code(zip)
    shapely-2.0rc1.tar.gz(265.60 KB)
  • 2.0b2(Oct 29, 2022)

    Relevant changes in behaviour compared to 2.0b1:

    • Fix for compatibility with PyPy (#1577).
    • Fix to the Point() constructor to accept arrays of length 1 for the x and y coordinates (fix compatibility with Shapely 1.8).
    • Raise ValueError for non-finite distance in the buffer() and offset_curve() methods on the Geometry classes (consistent with Shapely 1.8).
    • Add __format__ specification for geometry types (#1556).
    Source code(tar.gz)
    Source code(zip)
    shapely-2.0b2.tar.gz(256.96 KB)
  • 2.0b1(Oct 17, 2022)

    Relevant changes in behaviour compared to 2.0a1:

    • Renamed the tolerance keyword to max_segment_length in the segmentize function.
    • Renamed the quadsegs keyword in the top-level buffer and offset_curve functions and the resolution keyword in the Geometry class buffer and offset_curve methods all to quad_segs.
    • Added use of GEOSGeom_getExtent to speed up bounds calculations for GEOS >= 3.11.
    • Restored the behaviour of unary_union to return an empty GeometryCollection for an empty or all-None sequence as input (and the same for intersection_all and symmetric_difference_all).
    • Fixed the Geometry objects to be weakref-able again (#1535).
    • The .type attribute is deprecated, use .geom_type instead (which already existed before as well) (#1492).

    Wheels for 2.0b1 published on PyPI include GEOS 3.11.0.

    Source code(tar.gz)
    Source code(zip)
    shapely-2.0b1.tar.gz(254.79 KB)
  • 1.8.5(Oct 12, 2022)

    Packaging

    Python 3.11 wheels have been added to the matrix for all platforms.

    Bug fixes

    • Assign _lgeos in the macos frozen app check, fixing a bug introduced in 1.8.2 (#1528).
    • An exception is now raised when nan is passed to buffer and parallel_offset, preventing segmentation faults (#1516)
    Source code(tar.gz)
    Source code(zip)
    Shapely-1.8.5.tar.gz(196.03 KB)
  • 1.8.4(Aug 17, 2022)

  • 1.8.3(Aug 17, 2022)

    Deprecations

    The STRtree class will be changed in 2.0.0 and will not be compatible with the class in versions 1.8.x. This change obsoletes the deprecation announcement in 1.8a3 (below).

    Packaging

    Wheels for 1.8.3 published on PyPI include GEOS 3.10.3.

    Bug fixes

    • The signature for GEOSMinimumClearance has been corrected, fixing an issue affecting aarch64-darwin (#1480)
    • Return and arg types have been corrected and made more strict for area, length, and distance properties.
    • A new c_geom_p type has been created to replace c_void_p when calling GEOS functions (#1479).
    • An incorrect polygon-line intersection (#1427) has been fixed in GEOS 3.10.3, which will be included in wheels published to PyPI.
    • GEOS buffer parameters are now destroyed, fixing a memory leak (#1440).
    Source code(tar.gz)
    Source code(zip)
    Shapely-1.8.3.tar.gz(195.33 KB)
  • 2.0a1(Aug 3, 2022)

    Shapely version 2.0 alpha 1 is the first of a major release featuring a complete refactor of the internals and new vectorized (element-wise) array operations providing considerable performance improvements. A full changelog is still underway, and will be included with forthcoming pre-releases for Shapely 2.0.

    Packaging

    Wheels for 2.0a1 published on PyPI include GEOS 3.10.3.

    Source code(tar.gz)
    Source code(zip)
    shapely-2.0a1.tar.gz(255.18 KB)
  • 1.8.2(May 3, 2022)

    Version 1.8.2 fixes 3 bugs, one of them a significant memory leak in shapely.ops.nearest_points. We have more built distributions in https://pypi.org/project/Shapely/1.8.2/#files than ever before. In a nutshell, Pythons 3.6-3.10 for older platforms, and Pythons 3.8-3.10 for newer platforms including arm64 linux. Only Pythons 3.9 and 3.10 are supported on arm64 macos. All these built distributions include GEOS 3.10.2.

    Source code(tar.gz)
    Source code(zip)
    Shapely-1.8.2.tar.gz(194.15 KB)
  • 1.8.0(Oct 25, 2021)

    Shapely 1.8.0 is a transitional version. There are a few bug fixes and new features, but it largely exists to warn about the upcoming changes in 2.0.0. See the new migration guide for more details on how to update your code from Shapely 1.8 to 2.0.

    Python version support

    Shapely 1.8.0 supports only Python versions >= 3.6. The release is compatible with GEOS versions 3.6-3.10.

    Deprecations

    The following functions and geometry attributes and methods will be removed in version 2.0.0.

    • ops.cascaded_union
    • BaseGeometry.empty
    • BaseGeometry.ctypes and __array_interface__
    • multi-part geometry __len__
    • setting custom attributes on geometry objects
    • BaseGeometry.almost_exact

    Deprecation warnings will be emitted in 1.8.0 when any of these features are used.

    The deprecated to_wkb and to_wkt methods of BaseGeometry have been removed.

    New features

    • The STRtree nearest* methods now take an optional argument that specifies exclusion of the input geometry from results (#1115).
    • A GeometryTypeError has been added to shapely.errors and is consistently raised instead of TypeError or ValueError as in version 1.7. For backwards compatibility, the new exception will derive from TypeError and Value error until version 2.0 (#1099).
    • The STRtree class constructor now takes an optional second argument, a sequence of objects to be stored in the tree. If not provided, the sequence indices of the geometries will be stored, as before (#1112).
    • The STRtree class has new query_geoms, query_items, nearest_geom, and nearest_item methods (#1112). The query and nearest methods remain as aliases for query_geoms and nearest_geom.
    • A normalize method has been added to geometry classes, exposing the GEOSNormalize algorithm (#1090).
    • STRtree instances have a new default capacity of 10 items per node (#1070).
    • The new shapely.ops.voronoi_diagram computes the Voronoi Diagram of a geometry or geometry collection (#833, #851).
    • shapely.validation.make_valid fixes invalid geometries (#883).

    Packaging

    The 1.8.0 wheels uploaded to PyPI include GEOS 3.9.1.

    Source code(tar.gz)
    Source code(zip)
gjf: A tool for fixing invalid GeoJSON objects

gjf: A tool for fixing invalid GeoJSON objects The goal of this tool is to make it as easy as possible to fix invalid GeoJSON objects through Python o

Yazeed Almuqwishi 91 Dec 6, 2022
Pandas Network Analysis: fast accessibility metrics and shortest paths, using contraction hierarchies :world_map:

Pandana Pandana is a Python library for network analysis that uses contraction hierarchies to calculate super-fast travel accessibility metrics and sh

Urban Data Science Toolkit 321 Jan 5, 2023
scalable analysis of images and time series

thunder scalable analysis of image and time series analysis in python Thunder is an ecosystem of tools for the analysis of image and time series data

thunder-project 813 Dec 29, 2022
leafmap - A Python package for geospatial analysis and interactive mapping in a Jupyter environment.

A Python package for geospatial analysis and interactive mapping with minimal coding in a Jupyter environment

Qiusheng Wu 1.4k Jan 2, 2023
PySAL: Python Spatial Analysis Library Meta-Package

Python Spatial Analysis Library PySAL, the Python spatial analysis library, is an open source cross-platform library for geospatial data science with

Python Spatial Analysis Library 1.1k Dec 18, 2022
peartree: A library for converting transit data into a directed graph for sketch network analysis.

peartree ?? ?? peartree is a library for converting GTFS feed schedules into a representative directed network graph. The tool uses Partridge to conve

Kuan Butts 183 Dec 29, 2022
Raster-based Spatial Analysis for Python

?? xarray-spatial: Raster-Based Spatial Analysis in Python ?? Fast, Accurate Python library for Raster Operations ⚡ Extensible with Numba ⏩ Scalable w

makepath 649 Jan 1, 2023
OSMnx: Python for street networks. Retrieve, model, analyze, and visualize street networks and other spatial data from OpenStreetMap.

OSMnx OSMnx is a Python package that lets you download geospatial data from OpenStreetMap and model, project, visualize, and analyze real-world street

Geoff Boeing 4k Jan 8, 2023
Read and write rasters in parallel using Rasterio and Dask

dask-rasterio dask-rasterio provides some methods for reading and writing rasters in parallel using Rasterio and Dask arrays. Usage Read a multiband r

Dymaxion Labs 85 Aug 30, 2022
Location field and widget for Django. It supports Google Maps, OpenStreetMap and Mapbox

django-location-field Let users pick locations using a map widget and store its latitude and longitude. Stable version: django-location-field==2.1.0 D

Caio Ariede 481 Dec 29, 2022
Deal with Bing Maps Tiles and Pixels / WGS 84 coordinates conversions, and generate grid Shapefiles

PyBingTiles This is a small toolkit in order to deal with Bing Tiles, used i.e. by Facebook for their Data for Good datasets. Install Clone this repos

Shoichi 1 Dec 8, 2021
A short term landscape evolution using a path sampling method to solve water and sediment flow continuity equations and model mass flows over complex topographies.

r.sim.terrain A short-term landscape evolution model that simulates topographic change for both steady state and dynamic flow regimes across a range o

Brendan Harmon 7 Oct 21, 2022
Using Global fishing watch's data to build a machine learning model that can identify illegal fishing and poaching activities through satellite and geo-location data.

Using Global fishing watch's data to build a machine learning model that can identify illegal fishing and poaching activities through satellite and geo-location data.

Ayush Mishra 3 May 6, 2022
This repository contains the scripts to derivate the ENU and ECEF coordinates from the longitude, latitude, and altitude values encoded in the NAD83 coordinates.

This repository contains the scripts to derivate the ENU and ECEF coordinates from the longitude, latitude, and altitude values encoded in the NAD83 coordinates.

Luigi Cruz 1 Feb 7, 2022
A Django application that provides country choices for use with forms, flag icons static files, and a country field for models.

Django Countries A Django application that provides country choices for use with forms, flag icons static files, and a country field for models. Insta

Chris Beaven 1.2k Jan 3, 2023
Python bindings and utilities for GeoJSON

geojson This Python library contains: Functions for encoding and decoding GeoJSON formatted data Classes for all GeoJSON Objects An implementation of

Jazzband 765 Jan 6, 2023
Python interface to PROJ (cartographic projections and coordinate transformations library)

pyproj Python interface to PROJ (cartographic projections and coordinate transformations library). Documentation Stable: http://pyproj4.github.io/pypr

null 832 Dec 31, 2022
Rasterio reads and writes geospatial raster datasets

Rasterio Rasterio reads and writes geospatial raster data. Geographic information systems use GeoTIFF and other formats to organize and store gridded,

Mapbox 1.9k Jan 7, 2023
Fiona reads and writes geographic data files

Fiona Fiona reads and writes geographic data files and thereby helps Python programmers integrate geographic information systems with other computer s

null 987 Jan 4, 2023