[postgis-users] Odd st_buffer behaviour

[Rémi Cura]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20131125/6a79da15/attachment.html>