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

[Paul Ramsey]

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
>