#960 closed defect (fixed)
Exception when creating geometry buffer
Reported by: | allenkim0129 | Owned by: | |
---|---|---|---|
Priority: | blocker | Milestone: | |
Component: | Default | Version: | 3.6.2 |
Severity: | Unassigned | Keywords: | Buffer, TopologyException |
Cc: |
Description
Issue:
I am getting the following exception from GEOS:
TopologyException: assigned depths do not match at 3.3333333333333357 36.666666666666664
Steps to re-produce:
//1. Create GEOS Geometry std::string wkt = "MULTILINESTRING ((10 10, 20 20, 10 40), (40 40, 30 30, 40 20, 30 10))"; geos::io::WKTReader wkt_reader; geos::geom::Geometry* geom = wkt_reader.read(wkt); //2. BufferParameters geos::operation::buffer::BufferParameters param; param.setEndCapStyle(geos::operation::buffer::BufferParameters::CAP_FLAT); param.setQuadrantSegments(6); geos::operation::buffer::BufferBuilder builder(param); //3. Create Buffer double dist = 40; geos::geom::Geometry* geom_buffer = builder.buffer(geom, dist);
Attachments (2)
Change History (8)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
I have attached my test main.cpp and CMakeList.txt
So far, what I have discovered is that the error is thrown from DirectedEdge::setDepth() function.
void DirectedEdge::setDepth(int position, int newDepth) { if (depth[position]!=-999) { if (depth[position]!=newDepth) throw util::TopologyException("assigned depths do not match", getCoordinate()); //Assert.isTrue(depth[position] == depthVal, "assigned depths do not match at " + getCoordinate()); } depth[position]=newDepth; }
depth[position] is 2, but newDepth is 3
follow-up: 4 comment:3 by , 4 years ago
Martin can the usability range be computed to avoid such occurrences ?
comment:4 by , 4 years ago
Replying to strk:
Martin can the usability range be computed to avoid such occurrences ?
Maybe. It might be that if the length of the end segments is less than the buffer distance then there may be visual artifacts present. That would certainly include this case. It's an overly aggressive heuristic though, since it would prevent running lots of cases which would not show artifacts.
A more sophisticated heuristic would be to check if the end cap line intersected any of the side offset lines.
But if what you are suggesting is throwing an error such as "Unable to compute buffer for given buffer distance", then this could just be emitted as the error when a TopologyException occurs.
comment:6 by , 4 years ago
A test with current master shows there's no exception. Test was added to testsuite, closing this ticket.
You should note that buffering with CAP_FLAT produces a very poor buffer outline when the buffer distance is large relative to the geometry (as in this case). In fact, this should probably not be used at all in this case.