[postgis-users] ST_Intersection error side location conflict
Sandro Santilli
strk at keybit.net
Fri Nov 30 02:16:42 PST 2012
On Fri, Nov 30, 2012 at 11:03:55AM +0100, Paolo Crosato wrote:
> Il 29/11/2012 18:10, Sandro Santilli ha scritto:
> >On Thu, Nov 29, 2012 at 05:56:42PM +0100, Paolo Crosato wrote:
> >>Hi,
> >>
> >>I tried all the suggestions.
> >>1) All geometries are closed, select count(*) from adminbndy4 where
> >>ST_IsClosed(geom)='f' gives 0
> >>2) Yes I will add the intersect clause to the composite query on the
> >>table, however for now I'm just trying to figure out why the example
> >>I posted gives an error.
> >>3) 4) All the geometries in the table are valid, select count(*)
> >>from adminbndy4 where ST_IsValid(geom)='f' returns 0. Anyway I tried
> >>the buffer trick on the example I posted, but the error is still
> >>there.
> >>
> >>Any other suggestion?
> >>I thought about rounding to the 4th decimal with ST_SnapToGrid to
> >>simplify things a bit, but It would be the very last option.
> >Tried upgrading GEOS to 3.3.6 ?
>
> Hi,
>
> I upgraded to 3.3.6, but the problem was still there. It turned out
> to be a very simple issue, I was building the mask rectangle
> clockwise rather than counterclockwise.
> Once I reordered the points, eveything worked well, and blazing fast too :)
For GEOS it shouldn't make any difference, so either you're hitting
a robustness issue which is fixed by any random scrambing of input
(for instance, the input may be triggering a snapping operation which is
known to be orientation dependent) or you found a very stupid bug
in GEOS (or PostGIS).
Could you try to reproduce the error with two simple geometries in inputs ?
--strk;
More information about the postgis-users
mailing list