huge memory cost and crash in buffer [JTS fails too]

[atubar]

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 }

[strk]

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 !

[strk]

See also #384 for another such case

[atubar]

So if the geometry is too big, how to solve the problem? and where can I find out the limit size of the geometry?

[strk]

I haven't checked your geometry yet. Anyway, if it's a multi-component try applying the buffer to each component in turn.

[atubar]

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?

[strk]

I cannot look at it shortly, sorry (unless you can buy me some time).

[atubar]

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?

[strk]

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.

[strk]

See also #502 for another case of this bug

[strk]

This is actually a duplicate of #344

[mdavis]

Geometry causing error for buffer distance = -8665