[postgis-users] Infinite loop in st_intersects - because of incorrect data out of st_transform?

[Paul Ramsey]

OK then either
(a) we test for Inf boxes at the head of each GEOS function we care
about protecting (and not IsValid* functions)
(b) we put a pre-test in the IsValid* functions to check for Inf boxes
Preferences?
P.

On Thu, May 26, 2011 at 7:21 AM, Magnus Hagander <magnus at hagander.net> wrote:
> On Thu, May 26, 2011 at 16:20, Sandro Santilli <strk at keybit.net> wrote:
>> On Thu, May 26, 2011 at 04:16:59PM +0200, Magnus Hagander wrote:
>>> On Thu, May 26, 2011 at 16:15, Sandro Santilli <strk at keybit.net> wrote:
>>> > On Thu, May 26, 2011 at 04:09:27PM +0200, Magnus Hagander wrote:
>>> >> Hi!
>>> >>
>>> >> Yup, it does appear to solve the problem for at least my limited test
>>> >> case. I now get:
>>> >> ERROR:  Infinite coordinate value found in geometry.
>>> >> CONTEXT:  SQL function "st_intersects" statement 1
>>> >>
>>> >> as expected.
>>> >>
>>> >> Glad to see you found a better place :-)
>>> >
>>> > Could you please also try ST_IsValid, ST_IsValidReason and
>>> > ST_IsValidDetail against the table containing the offensive
>>> > geometry ?
>>>
>>> It's not actually in a table, the offensive geometry was generated by
>>> the app as the other side. Tha tmakes it even easier to check - both
>>> cases return:
>>>
>>> ERROR:  Infinite coordinate value found in geometry.
>>
>> My point is that ST_IsValid and friends should return validity information,
>> not throw an exception. By throwing an exception you don't get any other
>> result, so can't check the validity of multiple geometries at once.
>
> In that case, the patch is wrong, because it does return an exception.
>
>
> --
>  Magnus Hagander
>  Me: http://www.hagander.net/
>  Work: http://www.redpill-linpro.com/
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>