Opened 13 years ago
Closed 12 years ago
#383 closed defect (duplicate)
huge memory cost and crash in buffer [JTS fails too]
Reported by: | atubar | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 3.4.0 |
Component: | Default | Version: | main |
Severity: | Unassigned | Keywords: | buffer jtsfail |
Cc: |
Description
we debug the source code, and find that this function cause huge memory cost, especially of the 'for' circulation.
void SegmentNodeList::addSplitEdges(std::vector<SegmentString*>& edgeList) {
testingOnly
#if GEOS_DEBUG
std::cerr<<FUNCTION<<" entered"<<std::endl; std::vector<SegmentString*> testingSplitEdges;
#endif
ensure that the list has entries for the first and last point of the edge addEndpoints(); addCollapsedNodes();
there should always be at least two entries in the list since the endpoints are nodes iterator it=begin(); SegmentNode *eiPrev=*it; assert(eiPrev); it++;
problem occurs here for(iterator itEnd=end(); it!=itEnd; ++it) { &&&&This circulation consumes lots of memory so as to run out of the memory,then the program collapse
SegmentNode *ei=*it; assert(ei);
if ( ! ei->compareTo(*eiPrev) ) continue;
SegmentString *newEdge=createSplitEdge(eiPrev, ei); edgeList.push_back(newEdge);
#if GEOS_DEBUG
testingSplitEdges.push_back(newEdge);
#endif
eiPrev = ei;
}
#if GEOS_DEBUG
std::cerr<<FUNCTION<<" finished, now checking correctness"<<std::endl; checkSplitEdgesCorrectness(testingSplitEdges);
#endif }
Attachments (2)
Change History (14)
follow-up: 4 comment:1 by , 13 years ago
by , 13 years ago
comment:3 by , 13 years ago
Summary: | error occur when buffer → huge memory cost and crash in buffer |
---|
comment:4 by , 13 years ago
So if the geometry is too big, how to solve the problem? and where can I find out the limit size of the geometry?
follow-up: 6 comment:5 by , 13 years ago
I haven't checked your geometry yet. Anyway, if it's a multi-component try applying the buffer to each component in turn.
comment:6 by , 13 years ago
I have attach a ticket, a shapefile with only a entity. when buffering, with the shapefile in the ticket and a distance of -8665. Can you have a test, and show us a solution?
follow-up: 8 comment:7 by , 13 years ago
I cannot look at it shortly, sorry (unless you can buy me some time).
comment:8 by , 13 years ago
We need to do buffer operation in our program. Often the single geometry is huge, and the shapefile is big and contain many geometry. So what's the best way that you can show us?
comment:9 by , 13 years ago
Keywords: | buffer added |
---|---|
Milestone: | 3.2.1 → GEOS Future |
Version: | 3.2.0 → svn-trunk |
this is an issue with the buffer algorithm itself (from JTS). A possible solution could be splitting the line in smaller portions, buffer each one in turn and then finally union them togheter.
It is still an issue with trunk and won't be changed in 3.2, so changing the milestone.
comment:10 by , 13 years ago
Milestone: | GEOS Future → 3.4.0 |
---|---|
Summary: | huge memory cost and crash in buffer → huge memory cost and crash in buffer [JTS fails too] |
comment:12 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
This is actually a duplicate of #344
by , 3 years ago
Attachment: | geos-383-shp.zip added |
---|
Geometry causing error for buffer distance = -8665
Print edgeList.size() as first thing on function enter. Also, check the callers. Finally attach your input as WKT or WKB. Chances are your input geometry is just too big...
Ah, don't forget to try with current development version !