multilinestring buffer artifacts

[aperi2007]

Hi,

In postgis try-ing a Buffer with this:

select

1 as id,

ST_Buffer(ST_GeomFromText('MULTILINESTRING( (1676339.95971128 4847443.67952346, 1676340.19 4847443.54, 1676338.44 4847440.65, 1676335.37 4847442.52, 1676337.12 4847445.4, 1676339.95971128 4847443.67952346)

)'),1) as geom;

I experience a Bug . The buffer build a Polygon with a strange secondary polygon near a vertex.

The Geos used from Postgis 1.5.1 is Geos 3.2.0, so I try downloading the last Geos 3.2.2 compile and use it. But the bug is still here.

I work with windows , postgis 1.5.1.

[strk]

Confirmed on linux (both 32 and 64 bit), with GEOS trunk

The resulting polygon is invalid:

Holes are nested[1676339.44153305 4847442.8242508]

[strk]

JTS trunk works fine with this one, giving:

POLYGON ((1676334.370908338 4847442.47738721, 1676334.381771572 4847442.672985536, 1676334.430559768 4847442.86271278, 1676334.515400594 4847443.039287834, 1676336.265400594 4847445.919287834, 1676336.383019845 4847446.075914382, 1676336.528914198 4847446.206608688, 1676336.697486246 4847446.306356514, 1676336.882268526 4847446.371330916, 1676337.07617165 4847446.399039078, 1676337.2717563 4847446.388417942, 1676337.461518643 4847446.339875002, 1676337.638178226 4847446.255272662, 1676340.477889498 4847444.534796128, 1676340.477889507 4847444.534796122, 1676340.708178227 4847444.395272662, 1676340.865054944 4847444.277767458, 1676340.995997551 4847444.13191887, 1676341.095975523 4847443.963330074, 1676341.16114793 4847443.778477878, 1676341.189010992 4847443.584463894, 1676341.178494273 4847443.388741704, 1676341.130001801 4847443.19883052, 1676341.04539655 4847443.022026312, 1676339.29539655 4847440.132026312, 1676339.177687757 4847439.974857962, 1676339.031535752 4847439.843721232, 1676338.862575756 4847439.743672394, 1676338.6773224 4847439.678569058, 1676338.482918545 4847439.650921426, 1676338.286859869 4847439.661795518, 1676338.096705855 4847439.710772058, 1676337.91978832 4847439.795962644, 1676334.84978832 4847441.665962642, 1676334.693269131 4847441.783769514, 1676334.56272065 4847441.92983049, 1676334.463152898 4847442.098540236, 1676334.398386959 4847442.283424222, 1676334.370908338 4847442.47738721), 
(1676338.816753609 4847443.202781668, 1676337.455985112 4847444.027221212, 1676336.743325995 4847442.854387922, 1676338.10393518 4847442.025612946, 1676338.816753609 4847443.202781668))

[strk]

I've committed an XML test for this case in r3247 (thanks Andrea for the small dataset!)

http://trac.osgeo.org/geos/browser/trunk/tests/xmltester/tests/bug356.xml

[strk]

Interesting enough, like GEOS also JTS fails buffering this input with the original precision. Odd, as the input is a very simple rectangle with a side of 3.5 units (a linestring) being buffered with a distance of 1 unit. Full coordinates are in the order of 1E6 units.

The exception thrown (by both GEOS and JTS) when attempting the operation on the orginal input is:

TopologyException: assigned depths do not match [ (1676339.4415330526, 4847442.824250799, NaN) ]

[strk]

Also, like with GEOS, JTS has to make 3 precision reduction attempts before getting a valid answer:

recomputing with precision scale factor = 1.0E11
recomputing with precision scale factor = 1.0E10
recomputing with precision scale factor = 1.0E9

This is with GEOS:

recomputing with precision scale factor = 1e+11
recomputing with precision scale factor = 1e+10
recomputing with precision scale factor = 1e+09

[strk]

Seems to be a bug in the ScaledNoder. No unit testing for it, neither in GEOS nor in JTS...

[strk]

I take it back, ScaledNoder is all fine. Noding results do match.

[strk]

I've found that specifying a precisionModel with scale 1e+09 from the start (in the XML test) gives the expected result. So sounds like a bug in the precision reduction phase.

[strk]

r3252 fixes this.

Basically GEOS was using, for bufferFixedPrecision, a non-snaprounding noder (MCIndexNoder). Was a known disallignment between GEOS and JTS. Getting in sync (using MCIndexSnapRounder) fixes this bug w/out breaking anything else in our testsuite. Also, doesn't break the case which doesnt' work with JTS (TestBufferFailure.xml in JTS)