Opened 13 years ago

Last modified 13 years ago

#894 closed defect

_ST_Expand for geography is broken — at Initial Version

Reported by: robe Owned by: pramsey
Priority: blocker Milestone: PostGIS 2.0.0
Component: postgis Version: 1.5.X
Keywords: Cc:

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.

Change History (0)

Note: See TracTickets for help on using tickets.