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

[Magnus Hagander]

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 :-)

//Magnus

On Wed, May 25, 2011 at 21:11, Paul Ramsey <pramsey at opengeo.org> wrote:
> Magnus,
> We've decided to go with Inf testing, but I've move the test lower
> down into the GEOS handling code so it applies to all GEOS operations,
> not just Intersects().
>
> http://trac.osgeo.org/postgis/ticket/987
>
> See if that still works for you, hopefully it should (just tested with
> your test geometry)
>
> P.
>
> On Mon, Feb 28, 2011 at 7:18 AM, Magnus Hagander <magnus at hagander.net> wrote:
>> Hi!
>>
>> Running the following query locks up postgis completely (in
>> geos::algorithm::RobustDeterminant):
>>
>> SELECT st_intersects(somegeometry,
>> '0103000020E61000000100000005000000737979F3DDCC2CC0F92154F9E7534540000000000000F07F000000000000F07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540'::geometry)
>>
>> I believe this is because there are infinite values in that geometry:
>>
>> # select ST_AsText('0103000020E61000000100000005000000737979F3DDCC2CC0F92154F9E7534540000000000000F07F000000000000F07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540'::geometry);
>>
>>  st_astext
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>>  POLYGON((-14.4001308522972 42.6555167828373,inf inf,-85.9726317957995
>> 82.0924680617579,42.5223944076352 43.6054577711015,-14.4001308522972
>> 42.6555167828373))
>> (1 row)
>>
>>
>> ISTM that this should either be rejected as an invalid geometry, or at
>> least not hang....
>>
>>
>> Now, this geometry actually comes back as the result of st_transform,
>> which suggests to me that there is *also* a bug in st_transform, which
>> should never output an invalid geometry. It is the result of:
>>
>> st_transform('0103000020CD0B0000010000000500000099E6673CA2FC2DC1AD7BF5ED45CC534199E6673CA2FC2DC1D7BDFAF6D28960415A06E670D7E94B41D7BDFAF6D28960415A06E670D7E94B41AD7BF5ED45CC534199E6673CA2FC2DC1AD7BF5ED45CC5341',
>> 4326)
>>
>> And that geometry is valid before it goes into st_transform, from what
>> I can tell:
>> # select st_astext('0103000020CD0B0000010000000500000099E6673CA2FC2DC1AD7BF5ED45CC534199E6673CA2FC2DC1D7BDFAF6D28960415A06E670D7E94B41D7BDFAF6D28960415A06E670D7E94B41AD7BF5ED45CC534199E6673CA2FC2DC1AD7BF5ED45CC5341'::geometry);
>>
>>        st_astext
>>
>> ----------------------------------------------------------------------------------------------------------------------------------
>> ------------------------------------------
>>  POLYGON((-982609.1179802 5189911.7181081,-982609.1179802
>> 8670871.7181081,3658670.8820198 8670871.7181081,3658670.8820198
>> 5189911.
>> 7181081,-982609.1179802 5189911.7181081))
>> (1 row)
>>
>>
>>
>> To me this looks like bugs "below" postgis - it's certainly below the
>> PostgreSQL level that I know well :-) Not sure if it can be worked
>> around/fixed at the postgis level or if it needs to be done in the
>> lower level libraries, but either way it shouldn't behave this way :-)
>>
>> --
>>  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
>>
>



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