#1047 closed defect (fixed)
GEOS Panics on GeometryCollection with 1 MultiPolygon object
Reported by: | otan | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Default | Version: | 3.8.0 |
Severity: | Unassigned | Keywords: | |
Cc: |
Description
Tested on v3.8.1.
The following code will seg fault:
#include <geos_c.h> #include <string> using namespace std; void geos_message_handler(const char *fmt, ...) {} void geos_error_handler(const char *fmt, ...) {} int main() { string aEWKB = "01020000000200000000000000000000000000000000000000000000000000F03F0000000000000000"; string bEWKB = "0107000000010000000106000000010000000103000000010000000500000008690b3a70a9c347540a11d15993eec7e04b9e4d8fd2cb4702907c2929abe847d02aef5652e3cec72c1b57867da3dd47bbf47698d501eac7ccc0d287b380d44708690b3a70a9c347540a11d15993eec7"; initGEOS(&geos_message_handler, &geos_error_handler); auto wkbReader = GEOSWKBReader_create(); auto geomA = GEOSWKBReader_read(wkbReader, reinterpret_cast<const unsigned char*>(aEWKB.data()), aEWKB.length()); auto geomB = GEOSWKBReader_read(wkbReader, reinterpret_cast<const unsigned char*>(bEWKB.data()), bEWKB.length()); GEOSIntersects(geomA, geomB); return 0; }
Seems like geometryN does not work and returns NULL:
_ZN4geos9algorithm6locate24SimplePointInAreaLocator20locatePointInPolygonERKNS_4geom10CoordinateEPKNS3_7PolygonE /Users/otan/go/src/github.com/cockroachdb/cockroach/lib/libgeos.dylib:0 pc=0x14218db3 _ZN4geos9geomgraph11EdgeEndStar11getLocationEiRKNS_4geom10CoordinateEPNSt3__16vectorIPNS0_13GeometryGraphENS6_9allocatorIS9_EEEE /Users/otan/go/src/github.com/cockroachdb/cockroach/lib/libgeos.dylib:0 pc=0x1423fce8 _ZN4geos9geomgraph11EdgeEndStar16computeLabellingEPNSt3__16vectorIPNS0_13GeometryGraphENS2_9allocatorIS5_EEEE /Users/otan/go/src/github.com/cockroachdb/cockroach/lib/libgeos.dylib:0 pc=0x1423f936 _ZN4geos9operation6relate14RelateComputer9computeIMEv /Users/otan/go/src/github.com/cockroachdb/cockroach/lib/libgeos.dylib:0 pc=0x142a95a3 _ZN4geos9operation6relate8RelateOp6relateEPKNS_4geom8GeometryES6_ /Users/otan/go/src/github.com/cockroachdb/cockroach/lib/libgeos.dylib:0 pc=0x142ab1f2 _ZNK4geos4geom8Geometry10intersectsEPKS1_ /Users/otan/go/src/github.com/cockroachdb/cockroach/lib/libgeos.dylib:0 pc=0x14220773 GEOSIntersects_r
Change History (7)
comment:2 by , 4 years ago
As background, the reason general GCs aren't supported for predicstes in general is because of the difficulty of computing some of the more specific predicates over inputs containing overlapping polygons.
The intersects
predicate could be computed correctly, in theory. But this will require a different code path to the other predicates.
comment:3 by , 4 years ago
See PostGIS 4749 for a proposal to allow predicates to handle GeometryCollections. Most or all of this logic could be implemented in GEOS.
comment:5 by , 3 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I merged PR https://github.com/libgeos/geos/pull/334 in master (3.9.0) but needs to be backported to all affected branches still
In JTS at least, spatial predicates do not support GEOMETRYCOLLECTIONs as inputs. So this is a case of erroneous input. But should not be allowed to cause a segfault, for sure.
The simple fix is to just use the JTS approach of disallowing GEOMETRYCOLLECTION inputs to predicates.
It would also be possible to "unwrap" GC inputs containing a single element (and do this recursively...). It's not clear that that's really much of a benefit, however. And it might just be confusing, since GCs of size > 1 should still be disallowed.