[postgis-users] Odd st_buffer behaviour

[Stephen Woodbridge]

This is because lines shaped like say an Omega character, will create an 
island inside the character at a certain offset and this can not be 
represented as a simple polygon. Well maybe it can but the algorithm 
probably does not try to reduce them to their most simple features. 
While the lines may not intersect, the offset lines may intersect and it 
is a function of how these are dealt with.

-Steve

On 11/25/2013 12:49 PM, James David Smith wrote:
> Hi Remi/all,
>
> I realise I'm digressing slightly from the point, but this seems
> related. This seems strange to me:
>
> I check the geometry type of a table of what I think are linestrings (roads):
>
> ukroads=# SELECT COUNT(*), geometrytype(geom) FROM ukrds GROUP BY
> geometrytype(geom);
> 395356 | LINESTRING
>
> Great. They are all linestrings. Now I check that none of them are
> self-intersecting:
>
> ukroads=# SELECT COUNT(*), st_issimple(geom) FROM ukrds GROUP BY
> st_issimple(geom);
>   395356 | t
>
> Ok. That's fine. They are all ok.
>
> Now I check that they are all valid:
>
> ukroads=# SELECT COUNT(*), st_isvalid(geom) FROM ukrds GROUP BY
> st_isvalid(geom);
>   395356 | t
>
> So now I buffer them all by 1000 metres wanting to make a polygon out
> of each line:
>
> ukroads=# SELECT COUNT(a.*), geometrytype(a.the_geom) FROM (SELECT
> st_buffer(geom,1000) as the_geom FROM ukrds) AS a GROUP BY
> geometrytype(a.the_geom);
> 392255 | POLYGON
> 3101 | MULTIPOLYGON
>
> However I am returned with 3101 multipolygons (and the rest polygons).
> Why is that? Should they not all be polygons? Why do some of them
> become a multipolygon?
>
> Thanks
>
> James
>
> On 25 November 2013 17:25, Rémi Cura <remi.cura at gmail.com> wrote:
>> You could use the default ending (which is well defined),
>> then split the resulting with the line like endcap=flat (easy to build,
>> translate endpoint by radius and -radius in normal direction)
>>
>> I still fail to understand why you would need this kind of ending.
>>
>> Cheers,
>>
>> Rémi C
>>
>>
>> 2013/11/25 Rémi Cura <remi.cura at gmail.com>
>>>
>>> Does  offset curve gives the same result?
>>> (seems lile offsetting both side have same behavior)
>>>
>>> Maybe you can try several buffers with increasing size?
>>> (default appears wau before 1000)
>>>
>>> Also, can you try to simplify your line : each coordinates uses 15 digits,
>>> surely you don't need all of this !
>>> (simplifying to 8 digits doesn't help).
>>>
>>> It seems like a bad design in algorithm ?
>>>
>>> Cheers,
>>> Rémi-C
>>>
>>>
>>> 2013/11/25 James David Smith <james.david.smith at gmail.com>
>>>>
>>>> Hi there,
>>>>
>>>> Some code to illustrate my problem:
>>>>
>>>> 1) A linestring (SRID: 27700)
>>>>
>>>> LINESTRING(555936.152 200920.582000002,555938.312000002
>>>> 200908.102000002,555943.112000001 200883.142000001,555953.192000001
>>>> 200839.702,555964.471999999 200798.181999998,555974.312
>>>> 200764.342000002,555983.912 200744.182000002,555990.554
>>>> 200733.721000003,555993.512 200729.062000005,555995.778000002
>>>> 200726.756000001,556006.952000001 200715.382000001,556024.232
>>>> 200698.822000002,556036.597999999 200687.931,556050.392000001
>>>> 200675.782000002,556055.914 200671.265000002,556071.512
>>>> 200658.502000002,556094.915000001 200640.537000002,556095.451000001
>>>> 200640.152000001,556113.992000001 200628.742000001,556138.472000001
>>>> 200616.502000004,556159.112000002 200605.942000002,556180.232000001
>>>> 200589.862000002,556207.592 200568.022000002,556217.912000002
>>>> 200558.182,556228.472000001 200545.702,556240.472
>>>> 200527.702000003,556251.992000001 200509.221999999,556253.237000001
>>>> 200506.732000003,556258.952 200495.302000001,556268.000000001
>>>> 200478.000000002,556279.592 200458.582000002,556300
>>>> 200431.000000002,556351.000000002 200364,556349.253 200366.234000001)
>>>>
>>>> 2) Now I buffer it:
>>>>
>>>> SELECT ST_Buffer(
>>>>   ST_GeomFromText(
>>>>    'LINESTRING(555936.152 200920.582000002,555938.312000002
>>>> 200908.102000002,555943.112000001 200883.142000001,555953.192000001
>>>> 200839.702,555964.471999999 200798.181999998,555974.312
>>>> 200764.342000002,555983.912 200744.182000002,555990.554
>>>> 200733.721000003,555993.512 200729.062000005,555995.778000002
>>>> 200726.756000001,556006.952000001 200715.382000001,556024.232
>>>> 200698.822000002,556036.597999999 200687.931,556050.392000001
>>>> 200675.782000002,556055.914 200671.265000002,556071.512
>>>> 200658.502000002,556094.915000001 200640.537000002,556095.451000001
>>>> 200640.152000001,556113.992000001 200628.742000001,556138.472000001
>>>> 200616.502000004,556159.112000002 200605.942000002,556180.232000001
>>>> 200589.862000002,556207.592 200568.022000002,556217.912000002
>>>> 200558.182,556228.472000001 200545.702,556240.472
>>>> 200527.702000003,556251.992000001 200509.221999999,556253.237000001
>>>> 200506.732000003,556258.952 200495.302000001,556268.000000001
>>>> 200478.000000002,556279.592 200458.582000002,556300
>>>> 200431.000000002,556351.000000002 200364,556349.253
>>>> 200366.234000001)'), 1000, 'endcap=flat join=round');
>>>>
>>>> 3) The result is attached as a jpg (line thickness increased to aid
>>>> viewing).
>>>>
>>>> Any ideas please? This is related to an ongoing discussion I was
>>>> having with Remi a while ago. Basically I'm buffering loads of road
>>>> centrelines to create polygons. But when I do it, a small number end
>>>> up with really strange buffers like this attached example. I'm at a
>>>> loss as to why.
>>>>
>>>> Thanks
>>>>
>>>> James
>>>>
>>>> _______________________________________________
>>>> postgis-users mailing list
>>>> postgis-users at lists.osgeo.org
>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>>
>>>
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at lists.osgeo.org
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>