[postgis-users] Odd st_buffer behaviour

[Rémi Cura]

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