Segmentation fault when intersecting certain geometries using Shapely #329
Comments
|
We are experiencing the same problem with shapely installed in conda environments both in macos and linux. Downgrading to geos 3.7.2 (which also brings shapely down from 1.7.1 to 1.6.4) also solves the problem for us. Let me know if you want more example geometries to test. |
|
Technically speaking the overlay operations (including intersection) don't work on I'm not sure why this isn't explicitly disallowed via an exception - this is what JTS does. (@strk do you know?) That said, I'm surprised that this case doesn't in fact work, since it gets as far as it does. In any case, the overlay code has been switched over to OverlayNG in GEOS 3.9, so this issue may disappear. Although the caution on not supporting GeometryCollections still stands. |
|
9 years ago. I'm embarrassed to say I have no recollection of why. There are some tickets around the issue with various clues. https://trac.osgeo.org/geos/ticket/298 I remain intrigued by the possibility of actually stubbing out the cases where reasonable results can be returned. (Intersects, for example) |
This issue is about overlay operations, don't forget. Predicates are another matter (and agreed, it would be nice to extend them to handle collections). For overlay operations the safest path is to disallow GeometryCollection inputs. Although overlay code can handle some kinds of collection correctly (and OverlayNG is able to handle a wider range of collection inputs which are technically invalid MultiPolygons). But there's no easy way to tell a priori which are safe to run. Collections which can be handled are homogeneous collections of line, points and non-overlapping polygons (since these are isomorphic to Multi geometries of that type). Handling hetergeneous collections might be possible via some chained operations, assuming a suitable semantic can be defined for each overlay operation (union and intersection are fairly obvious, the others might take some thought). For now really Shapely should prohibit running overlay ops on collection inputs, using its native error mechanism. But it would be nice to have a guard in GEOS as well (especially since I'm not sure this restriction is well-documented). |
|
I feel like union, intersection and difference are all doable using the chain of
|
|
Actually JTS has a hack to compute a form of I'm not sure about doing "pairwise apply" - that seems like it could potentially produce a lot of overlapping resultants. But I guess it depends on what sort of semantics are desired. To my mind the closer the semantics to "normal" overlay operations the better (i.e. the result should be non-overlapping and noded). One rationale is that this provides better chainability for overlay operations. I guess you could make the argument that if the client wanted "normal" semantics it should supply a Multi geometry in the first place. But I think that a lot of clients won't understand this fine distinction, and just use GeometryCollections because their data is sloppily defined. |
|
On 3.9 this test now works. |
|
I think this can be closed then? Please re-open if I'm mistaken. |
|
If I may, I would like to share how I solved this problem. I solved this problem as follows:
After that, I corrected them, as follows:
After that I performed a reindex on the table.
Hope this is helpful for someone with this kind of problem. |
Description
Not sure if this is necessarily a GEOS issue - might be just some Shapely -> GEOS interface issue. When using GEOS 3.7.3 the segfault is not happening. The issue was reported to Shapely back in March shapely/shapely#860
Environment
reproduced on Arch Linux and Ubuntu 20.04
Python 3.8
Shapely 1.7.0 (and also reproduced with 1.6.4.post2)
GEOS 3.8.0
GDAL 3.0.4
PROJ 6.3.1-1
Steps to reproduce
GDB backtrace:
The text was updated successfully, but these errors were encountered: