ST_Buffer returning multipolygon with linestring/polygon input

[mcastrog]

Hi, I got the standard North Carolina dataset ​http://grass.osgeo.org/sampledata/north_carolina/nc_shape.tar.gz and imported streams shape layer into postgresql through shp2psql shell command.
In the resulting table the geometry field contains only LINESTRING elements.

By running the following query:

SELECT
sub.gid, GeometryType(sub.buffer) AS buffer_GeometryType,
GeometryType(sub.the_geom) AS stream_GeometryType
FROM (
        SELECT gid, the_geom, st_buffer (the_geom, 100) AS buffer
        FROM streams
) AS sub
WHERE
GeometryType(sub.buffer)  <> 'POLYGON';

I get this output:

 gid  | buffer_geometrytype | stream_geometrytype 
------+---------------------+---------------------
  674 | MULTIPOLYGON        | LINESTRING
  810 | MULTIPOLYGON        | LINESTRING
  811 | MULTIPOLYGON        | LINESTRING
 1564 | MULTIPOLYGON        | LINESTRING
 1571 | MULTIPOLYGON        | LINESTRING
 1667 | MULTIPOLYGON        | LINESTRING
 2764 | MULTIPOLYGON        | LINESTRING
 2848 | MULTIPOLYGON        | LINESTRING
 5203 | MULTIPOLYGON        | LINESTRING
 5250 | MULTIPOLYGON        | LINESTRING
 8369 | MULTIPOLYGON        | LINESTRING

So, 11 out of 8554 records are MULTIPOLYGONs not POLYGONs as expected.

To be more accurate, I isolated the record having gid=674

SELECT gid, AsText(the_geom) 
FROM streams 
WHERE gid=674;

the related output is:

 674 | LINESTRING(640770.332537465 216785.425146015,640770.356311913 216785.560172686,640770.475488952 216786.226162019,640770.647396495 216787.800152365,640770.658978918 216789.268376902,640770.447752096 216792.399898366,640769.98018796 216795.624688816,640769.110287021 216798.527305023,640767.648768098 216801.891389348,640766.02448565 216804.805892778,640764.74005588 216807.134569434,640763.337363474 216809.560477487,640761.650901703 216812.246990061,640759.955600712 216815.327305019,640758.482499366 216817.868732504,640757.383693167 216819.548488661,640756.238862077 216821.226720821,640754.01503683 216824.434442434,640751.366929134 216828.435255234,640749.204368809 216832.450088865,640747.25516891 216836.227787618,640746.014020829 216838.801219168,640745.393751588 216840.360274284,640744.315976633 216842.854457673,640743.400050801 216844.65704848,640742.582575565 216846.277673322,640741.52491745 216848.478638524,640740.503835408 216850.705816576,640739.787553975 216852.270967708,640739.053289307 216853.851968469,640738.173025147 216855.546355058,640737.55488951 216856.568961104,640736.817272035 216857.822910812,640735.910795021 216859.35697228,640734.77510795 216861.236982439,640733.832969266 216862.938074642,640732.814325629 216865.039674844,640731.225095251 216869.012141189,640729.979984761 216871.879095724,640729.445974092 216873.02148841,640729.002794006 216873.679857725,640728.952197105 216873.745389857,640728.676962154 216874.089814544) 

All of you can see that the above record represents a regular LINESTRING geometry. Finally I exported the gid=674 stream and the related buffer, you can see large and small zoom at this links:

​https://docs.google.com/file/d/0B0MkYF-Ljs34c1owdkc1U0Q4OFk/edit ​https://docs.google.com/file/d/0B0MkYF-Ljs34MlNkTkJwc0dEbG8/edit

The behaviour is not regular, I suppose.

About postis version

SELECT postgis_full_version();

returns

POSTGIS="1.5.2" GEOS="3.2.2-CAPI-1.6.2" PROJ="Rel. 4.7.1, 23 September 2009" LIBXML="2.7.8" USE_STAT

Best wishes.
Marco

[robe]

Paul or Sandro can chime in on this, but I suspect this is not a bug and just that your linestrings are so short. Even a buffered linestring is not guaranteed to return a polygon if it is not simple or is really short because at that point the areas start intersecting with each other creating pockets which could conceivably turn into small polygons if two pockets are close enough.

The example linestring you have has length of ~99.18 which is smaller than your buffer.

SELECT ST_length('LINESTRING(640770.332537465 216785.425146015,640770.356311913 216785.560172686,640770.475488952 216786.226162019,640770.647396495 216787.800152365,640770.658978918 216789.268376902,640770.447752096 216792.399898366,640769.98018796 216795.624688816,640769.110287021 216798.527305023,640767.648768098 216801.891389348,640766.02448565 216804.805892778,640764.74005588 216807.134569434,640763.337363474 216809.560477487,640761.650901703 216812.246990061,640759.955600712 216815.327305019,640758.482499366 216817.868732504,640757.383693167 216819.548488661,640756.238862077 216821.226720821,640754.01503683 216824.434442434,640751.366929134 216828.435255234,640749.204368809 216832.450088865,640747.25516891 216836.227787618,640746.014020829 216838.801219168,640745.393751588 216840.360274284,640744.315976633 216842.854457673,640743.400050801 216844.65704848,640742.582575565 216846.277673322,640741.52491745 216848.478638524,640740.503835408 216850.705816576,640739.787553975 216852.270967708,640739.053289307 216853.851968469,640738.173025147 216855.546355058,640737.55488951 216856.568961104,640736.817272035 216857.822910812,640735.910795021 216859.35697228,640734.77510795 216861.236982439,640733.832969266 216862.938074642,640732.814325629 216865.039674844,640731.225095251 216869.012141189,640729.979984761 216871.879095724,640729.445974092 216873.02148841,640729.002794006 216873.679857725,640728.952197105 216873.745389857,640728.676962154 216874.089814544)'::geometry)

[robe]

nevermind what I said. I see Martin has confirmed this to be a robustness issue in GEOS and JTS.

​http://lists.osgeo.org/pipermail/postgis-users/2013-January/036342.html

[rnuske]

Reproduced bug with relatively simple polygon.

One of many polygons received from a colleague produces a multipolygon if buffered with buffer radii between 40.5 and 42.3. Other buffer radii or a different "start point" in the order of the vertices lead to the expected regular polygons without additional slivers or splinters

Query using simplified version of problematic polygon

SELECT ST_AsText(ST_Buffer(ST_GeomFromText('POLYGON((19.4994 56.0304, 19.2074 56.0271, 18.9318 56.0205, 18.8957 57.9268, 20.5001 57.9498, 20.0079 56.0369, 19.7389 56.0304, 19.4994 56.0304))'), 42.0));

results in

"MULTIPOLYGON(((19.7367211896429 14.0304,19.7705233164382 14.0307820103371,19.7389 14.0304,19.7367211896429 14.0304)),((19.9343358615234 14.0327608693757,11.7006495228381 14.6476772442749,3.74363996706844 16.8628724567734,-3.62598135388737 20.5924531953819,-10.1232010579226 25.6921813271142,-15.4967450996707 31.9648295183871,-19.5387965650002 39.1678088222387,-22.093032800601 47.0225505845648,-23.0606710500053 55.2252798327099,-23.0967710500053 57.1315798327099,-22.4407679720923 65.3629559687913,-20.1869395043865 73.3068939324235,-16.4224054354575 80.6563276776687,-11.2926805712663 87.127171204565,-4.99604998629464 92.4692996575579,2.22409551437942 96.4762176852911,10.0886674559795 98.9930413396766,18.2936676174523 99.9224849808449,19.8980676174523 99.9454849808449,28.4228349595372 99.1957727823327,36.6186842709601 96.7337044076271,44.1453589826341 92.6614943931604,50.6903837894731 87.1482034616806,55.9820372870512 80.4227198449549,59.8006326808134 72.7642568244779,61.9876382410949 64.4907609916044,62.4522588617096 55.9457124665125,61.175205483978 47.4838650743824,60.683005483978 45.5709650743824,58.0642841438528 38.2686241721232,54.1472040167705 31.5724784607419,49.0654030065054 25.7109784307067,42.9922554664985 20.8840992041937,36.1349572365661 17.2565180409666,28.7274568016185 14.9519960913458,21.022473738028 14.0491560723953,20.753473738028 14.0426560723953,19.9343358615234 14.0327608693757)),((19.9358193041834 14.0326500814315,19.9475017979551 14.0327821096145,19.9373172271422 14.0325382120551,19.9358193041834 14.0326500814315)))"

SELECT postgis_full_version();
"POSTGIS="2.0.3 r11128" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.8.0" LIBJSON="UNKNOWN" RASTER"