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

[Magnus Hagander]

On Thu, May 12, 2011 at 10:20, Sandro Santilli <strk at keybit.net> wrote:
> On Thu, May 12, 2011 at 09:53:38AM +0200, Magnus Hagander wrote:
>> On Tue, Mar 8, 2011 at 10:16, Magnus Hagander <magnus at hagander.net> wrote:
>> > On Mon, Feb 28, 2011 at 16:35, Mark Cave-Ayland
>> > <mark.cave-ayland at siriusit.co.uk> wrote:
>> >> On 28/02/11 15:18, Magnus Hagander wrote:
>
>> >>> 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:
> ....
>
>> > Since nobody appears to be too interested in producing a quick fix in
>> > geos, attached is a patch that puts in an *ugly* workaround in
>> > PostGIS, that simply rejects the infinite values higher up in the
>> > stack.
>
> Please see http://trac.osgeo.org/geos/ticket/357
> It was waiting for a testcase, as none helped reproducing
> with 3.3.0rc1 so far.
> I'll try with the data you give. It may need a second geometry to tango.

Well, you can pick any geometry you want as the second one, and it'll
lock up in PostGIS as well.

Like I said - we want the underlying fix, but I do beleive we want the
fix in PostGIS *as well*.

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