[postgis-devel] [PostGIS] #894: _ST_Expand for geography is broken

[PostGIS]

#894: _ST_Expand for geography is broken
---------------------+------------------------------------------------------
 Reporter:  robe     |       Owner:  pramsey      
     Type:  defect   |      Status:  new          
 Priority:  blocker  |   Milestone:  PostGIS 2.0.0
Component:  postgis  |     Version:  1.5.X        
 Keywords:           |  
---------------------+------------------------------------------------------

Old description:

> I think this may be related to #869.
>
> In trying to trace the cause of failure of ST_DWithin in 869, I
> discovered that
>
> _ST_Expand for any geography type for any distance always returns the
> same geography.  What was especially puzzling is that it is also broken
> in PostGIS 1.5.2 and yet the ST_DWithin in that works.
>
> _ST_DWithin by itself works fine and produces the correct answers in that
> regress for both 2.0 and 1.5.2 -- so the failing part is the _ST_Expand.
>
> My conclusion is that while PostGIS 1.5.2 is also broken, the cached box
> it produces must be right, but that when Paul enable the gserialized, it
> somehow probably made the cached box agree with the output geometry thus
> making the _ST_Expand ineffective in 2.0.
>
> I'm not sure how to see the cached box of a geography though?  Do we have
> a function for that?
>
> So here is the case:
>
> On PostGIS 1.5.2 and PostGIS 2.0
>
> {{{
>
> SELECT ST_AsText(_ST_EXPAND(ST_GeogFromText('LINESTRING(1 2, 3 4)'), 1000
> );
>
> -- result--
> LINESTRING(1 2,3 4)
> }}}
>
> However watch this:
>
> {{{
>
> SELECT _ST_EXPAND(ST_GeogFromText('LINESTRING(1 2, 3 4)'), 1000) &&
> ST_GeogFromText('POINT(3 3)');
> }}}
>
> On 1.5 the above returns true, but on our new 2.0 after Paul's changing
> the switch to make gserialized live, it now returns false.
>
> So PostGIS 2.0 is more or less more or less broken than 1.5. It's just
> that 1.5 is covering its tracks in ways we usually check.

New description:

 I think this may be related to #869.

 In trying to trace the cause of failure of ST_DWithin in 869, I discovered
 that

 _ST_Expand for any geography type for any distance always returns the same
 geography.  What was especially puzzling is that it is also broken in
 PostGIS 1.5.2 and yet the ST_DWithin in that works.

 _ST_DWithin by itself works fine and produces the correct answers in that
 regress for both 2.0 and 1.5.2 -- so the failing part is the _ST_Expand.

 My conclusion is that while PostGIS 1.5.2 is also broken, the cached box
 it produces must be right, but that when Paul enable the gserialized, it
 somehow probably made the cached box agree with the output geometry thus
 making the _ST_Expand ineffective in 2.0.

 I'm not sure how to see the cached box of a geography though?  Do we have
 a function for that?

 So here is the case:

 On PostGIS 1.5.2 and PostGIS 2.0

 {{{

 SELECT ST_AsText(_ST_EXPAND(ST_GeogFromText('LINESTRING(1 2, 3 4)'), 1000
 );

 -- result--
 LINESTRING(1 2,3 4)
 }}}

 However watch this:
 -- This returns true in both --
 {{{

 SELECT _ST_EXPAND('LINESTRING(1 2, 3 4)'::geography, 1000) && 'POINT(3
 3)'::geography);
 }}}

 --- This returns true in PostGIS 1.5 and false in PostGIS 2.0 --

 {{{
 SELECT 'POINT(-20 -10)'::geography && _ST_Expand(ST_GeogFromText('POINT(0
 0)'),3000000);

 }}}

 -- This works in both --

 {{{
 SELECT _ST_Expand('POINT(-20 -10)'::geography,3000000) &&
 ST_GeogFromText('POINT(0 0)');
 }}}

 So perhaps its expanding 0 0 that is at fault, but both are still
 producing erroneous geography output from _ST_Expand which doesn't agree
 with what is happening.

--

Comment(by robe):

 Oops I was incorrect in the second part of my assumptions. I guess it is
 the expansion of 0 0 that is problematic because if I switch the expand it
 works.  But notice the geography expand output is still wrong in both.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/894#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.