Buffer returns empty geometry though it should not be empty

[silke]

I observed a really strange behavior of the buffer function when using an inner buffer. The error occurs with the following geometry: POLYGON (( 513.4 343.1, 707.3 344.2, 707.0 394.9, 797.9 395.4, 799.2 341.8, 516.9 340.9, 516.7 262.3, 513.2 262.3, 513.4 343.1 )) Its WKB representation is 0103000000010000000900000033333333330B80409A9999999971754066666666661A8640333333333383754000000000001886406666666666AE78403333333333EF88406666666666B678409A99999999F98840CDCCCCCCCC5C7540333333333327804066666666664E75409A99999999258040CDCCCCCCCC6470409A99999999098040CDCCCCCCCC64704033333333330B80409A99999999717540

Using a buffer of -2 should lead to an inner buffer but leads to "GEOMETRYCOLLECTION EMPTY" resp. "POLYGON( EMPTY)" depending on the geos version.

Using the same buffer of -2 on a polygon with the same shape but shifted to the left by 100 and shifted down by 100, i.e.

POLYGON (( 413.4 243.1, 607.3 244.2, 607.0 294.9, 697.9 295.4, 699.2 241.8, 416.9 240.9, 416.7 162.3, 413.2 162.3, 413.4 243.1 ))

resp. 010300000001000000090000006666666666D679403333333333636E406666666666FA82406666666666866E400000000000F8824066666666666E72403333333333CF854066666666667672409A99999999D985409A99999999396E4066666666660E7A40CDCCCCCCCC1C6E4033333333330B7A409A999999994964403333333333D379409A999999994964406666666666D679403333333333636E40

leads to the expected buffer: POLYGON((609.172261037685 243.512992930268,609.26383338939 243.821372982058,609.29996498814 244.211834112356,609.011804031568 292.911035772954,695.948180429531 293.389233662932,697.151062564334 243.793477951075,609.172261037685 243.512992930268)) resp. 01030000000100000007000000DD1965CA600983408D5226706A706E403118AE541C0A83402AF8FDAF487A6E400A300B54660A8340DB175558C7866E405E4CB62C1808834035253F9A934E72405BFC9EDF95BF8540BECC134D3A567240B72B4A6035C98540EB3EDF2B64796E40DD1965CA600983408D5226706A706E40

I tested this on different geos versions among them 3.0.0rc4 and 3.0.0

Cf. the discussion on the geos-devel list as well:  http://lists.osgeo.org/pipermail/geos-devel/2008-January/003271.html

Also this bug might be related to the bug number #158

[silke]

Hello!

I have an update on this bug: I compiled geos with debug (GEOS_DEBUG defined) and created the buffer again. Surprisingly the bug does not persist with debug information so that now the correct POLYGON is returned. I created a small python script that returns an EMPTY polygon when called with a geos lib compiled without debug. Called with a geos lib compiled with debug it returns the correct polygon - bug also a lot of debug information, which I would like to avoid.

I attached the script as well as both output files.

I would be grateful for any new input.

[silke]

I have tried again to tackle this problem because it still persists even with the newer versions of geos (last version I took was r2182).

A colleague helped me to rewrite my example into c++. I attached it to this ticket as well.

I was now able to use valgrind on the program which does not show any errors at all. Also I tried to link dmalloc with this little program but then it somehow starts an infitive look. At least it does not stop even after a whole night running.

Some other findings which I had as well: In the case where the empty polygon is returned it does not even enter the buffer algorithm itself. It stops when it checks whether the polygon is useful for the buffering.

I am running out of ideas how to tackle this problem. So I would be very glad if anybody could give me a hint which tool could be used to hunt this problem down!

[strk]

Please try with r2504 or later, if the problem persist consider writing an XML testcase, see tests/xmltester/tests/bug244.xml for an example.

[silke]

Replying to strk:

Please try with r2504 or later, if the problem persist consider writing an XML testcase, see tests/xmltester/tests/bug244.xml for an example.

I testes it with the latest version from trunk (r2561) as well as with latest stable release (3.1.0). With 3.1.0 the problem still exists but in the trunk it seems to have gone away.

If anybody has an explanation how this problem has been solved I would be happy for explanation. As long as I do not observe the problem again I would be fine with closing this ticket.

Greetings,

Silke

[strk]

Try  http://trac.osgeo.org/geos/browser/branches/3.1 The fix might have been backported there already

[strk]

It's likely this one:  http://trac.osgeo.org/geos/changeset/2511

[strk]

I've tried your geostest.cpp with trunk and here are the results I get:

using GEOS 3.1.0

======= Polygon 1, original: POLYGON ((413.3999999999999773 243.0999999999999943, 607.2999999999999545 244.1999999999999886, 607.0000000000000000 294.8999999999999773, 697.8999999999999773 295.3999999999999773, 699.2000000000000455 241.8000000000000114, 416.8999999999999773 240.9000000000000057, 416.6999999999999886 162.3000000000000114, 413.1999999999999886 162.3000000000000114, 413.3999999999999773 243.0999999999999943))

======= Polygon 1, buffered: POLYGON ((609.1722610376851890 243.5129929302678704, 609.2638333893902427 243.8213729820575395, 609.2999649881396635 244.2118341123558309, 609.0118040315680901 292.9110357729544489, 695.9481804295313623 293.3892336629322699, 697.1510625643339836 243.7934779510754595, 609.1722610376851890 243.5129929302678704))

======= Polygon 2, original: POLYGON ((513.3999999999999773 343.1000000000000227, 707.2999999999999545 344.1999999999999886, 707.0000000000000000 394.8999999999999773, 797.8999999999999773 395.3999999999999773, 799.2000000000000455 341.8000000000000114, 516.8999999999999773 340.8999999999999773, 516.7000000000000455 262.3000000000000114, 513.2000000000000455 262.3000000000000114, 513.3999999999999773 343.1000000000000227))

======= Polygon 2, buffered: POLYGON ((709.1722610376851890 343.5129929302678988, 709.2638333893902427 343.8213729820575963, 709.2999649881396635 344.2118341123558594, 709.0118040315680901 392.9110357729544489, 795.9481804295313623 393.3892336629322699, 797.1510625643339836 343.7934779510754879, 709.1722610376851890 343.5129929302678988))

Sounds good to me

[strk]

For the record, I've committed an XML version of the testcase, automatically run.