Opened 9 years ago
Closed 9 years ago
#749 closed defect (fixed)
GeometryPrecisionReducer not honouring target PM for empty geometry inputs
Reported by: | strk | Owned by: | |
---|---|---|---|
Priority: | blocker | Milestone: | 3.5.1 |
Component: | Default | Version: | 3.5.0 |
Severity: | Unassigned | Keywords: | |
Cc: | mbdavis |
Description
This needs more testing but I've added a GEOSGeom_getPrecision function to the C-API and in some cases it's not confirming that the corresponding GEOSGeom_setPrecision did what it advertise to do.
Adding debugging lines shows a possible bug in GeometryPrecisionReducer not properly setting the output model.
Change History (5)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Cc: | added |
---|
I'd note that the same issue exists in JTS, whereas the class is called CoordinateSequenceOperation there.
comment:3 by , 9 years ago
Alright I restricted the problem to EMPTY input. Generally speaking, if the input has no Coordinates, the GeometryEditor with CoordinateOperation visitor does _not_ change the GeometryFactory.
I'm tempted to call this a bug, for GeometryPrecisionReducer to not change the factory of an empty.
comment:4 by , 9 years ago
Note that the bug of GeometryEditor also affects GeometryFactory->createGeometry() in that it uses GeometryEditor to change factory of geometries.
comment:5 by , 9 years ago
Milestone: | 3.6.0 → 3.5.1 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Summary: | GeometryPrecisionReducer not honouring target PM → GeometryPrecisionReducer not honouring target PM for empty geometry inputs |
Version: | svn-trunk → 3.5.0 |
GeometryEditor fixed in 3.5 branch with r4110 (for 3.5.1) and in trunk with r4109 (for 3.6.0)
I think I've spotted the bug being in CoordinateOperation::edit ending with a geometr->clone() rather than using the new factory.