[postgis-users] Odd st_buffer behaviour
Rémi Cura
remi.cura at gmail.com
Tue Nov 26 00:03:28 PST 2013
Also in your small code snippet you did't ensure that all your line where
simple linestring (and not multilinestring).
Just to be sure :
SELECT COUNT(*) FROM ukrds WHERE ST_IsSimple(geom)=FALSE
Cheers,
Rémi
2013/11/25 James David Smith <james.david.smith at gmail.com>
> Steve,
>
> Thanks, you are of course right. I hadn't thought of that. Makes sense.
>
> James
>
> On 25 November 2013 17:58, Stephen Woodbridge <woodbri at swoodbridge.com>
> wrote:
> > 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
> >>
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20131126/b1c8c7b3/attachment.html>
More information about the postgis-users
mailing list