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

[Magnus Hagander]

With the disclaimer of not having looked at the code, I like (b). I
assume you mean that in the path of isvalid*, we pick up the same
check and return the proper thing. But we still keep the check you put
in with your patch, so that if we enter them some other way, or if the
test in isvalid* goes wrong for some reason, we'll still get the
exception.

I like the general idea of doing it deep down to make sure there's no
codepath being missed.

//Magnus

On Thu, May 26, 2011 at 17:12, Paul Ramsey <pramsey at opengeo.org> wrote:
> 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
>>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>



-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/