[geos-devel] Bug in buffer function?

Wed Feb 6 09:47:45 EST 2008

Hello,

Not too much help, I know, but things do look amiss! The following WKB
also fails with buffer(-2). It is almost identical to the second WKB
in your post (and which produces a valid buffer), differing only at
around the 15th decimal place (didn't check exactly!):

010300000001000000090000006666666666D679403433333333636E406666666666FA82406666666666866E400000000000F8824066666666666E72403333333333CF854066666666667672409A99999999D985409A99999999396E4066666666660E7A40CCCCCCCCCC1C6E4034333333330B7A409A999999994964403433333333D379409A999999994964406666666666D679403433333333636E40

Homme.

On Wed, Feb 06, 2008 at 01:50:46PM +0100, Silke Reimer wrote:
> 
> Hallo again,
> 
> I know that usually it is not really helpful to submit a request twice but in 
> this case I give it a try by formulating the request slightly different: Can 
> anybody please try just to through the below mentioned polygons into the 
> corresponding geos function and confirm the behavior? All I want to know is, 
> whether this is really a bug or whether I just oversee something. 
> 
> (If I get no answer to this email I will just add this example to the bug 
> tracker.)
> 
> Thanks,
> 
> 	Silke
> 
> See here again the original post:
> 
> On Friday 25 January 2008, Silke Reimer wrote:
> > Hallo!
> >
> > 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
> > 0103000000010000000900000033333333330B80409A9999999971754066666666661A86403
> >33333333383754000000000001886406666666666AE78403333333333EF88406666666666B67
> >8409A99999999F98840CDCCCCCCCC5C7540333333333327804066666666664E75409A9999999
> >9258040CDCCCCCCCC6470409A99999999098040CDCCCCCCCC64704033333333330B80409A999
> >99999717540
> >
> > 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.
> > 010300000001000000090000006666666666D679403333333333636E406666666666FA82406
> >666666666866E400000000000F8824066666666666E72403333333333CF85406666666666767
> >2409A99999999D985409A99999999396E4066666666660E7A40CDCCCCCCCC1C6E40333333333
> >30B7A409A999999994964403333333333D379409A999999994964406666666666D6794033333
> >33333636E40
> >
> > 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.
> > 01030000000100000007000000DD1965CA600983408D5226706A706E403118AE541C0A83402
> >AF8FDAF487A6E400A300B54660A8340DB175558C7866E405E4CB62C1808834035253F9A934E7
> >2405BFC9EDF95BF8540BECC134D3A567240B72B4A6035C98540EB3EDF2B64796E40DD1965CA6
> >00983408D5226706A706E40
> >
> > I tested this on different geos versions among them
> > 3.0.0rc4 and 3.0.0
> >
> > I would say that this is a bug but it would be nice if somebody could
> > confirm this - and perhaps you even have an idea how to solve this? I did
> > not find any entry in the bug tracker but maybe I just missed it. In this
> > case I would be glad for a hint.
> >
> > Many greetings,
> >
> > 	Silke
> 
> 
> 
> -- 
> phone: +49 3381 8904318		 fax:   +49 3381 8904101
> 
> RapidEye AG
> Molkenmarkt 30
> 14776 Brandenburg an der Havel
> Germany
> 
> Head Office/Sitz der Gesellschaft: Brandenburg an der Havel
> Management Board/Vorstand: Wolfgang G. Biedermann
> Chairman of Supervisory Board/Vorsitzender des Aufsichtsrates: Axel Schmalz
> Commercial Register/Handelsregister Potsdam HRB 17 796
> Tax Number/Steuernummer: 048/100/00053
> VAT-Ident-Number/Ust.-ID: DE 199331235
> 
> *************************************************************************
> Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
> E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
> Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie
> die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
> 
> The information in this e-mail is intended for the named recipients
> only. It may contain privileged and confidential information. If you
> have received this communication in error, any use, copying or
> dissemination of its contents is strictly prohibited. Please erase all
> copies of the message along with any included attachments and notify
> RapidEye AG or the sender immediately by telephone at the number
> indicated on this page.
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
> 

-- 
Homme Zwaagstra
GeoData Institute
University of Southampton