Opened 8 years ago

Closed 8 years ago

#451 closed defect (fixed)

ST_Area(geography,false) returns wrong result for objects crossing dateline

Reported by: pramsey Owned by: pramsey
Priority: high Milestone: PostGIS 1.5.1
Component: postgis Version: 1.5.X
Keywords: Cc:

Description

The st_area(geography, false) variant runs the area calculation on the sphere rather than the spheroid. It returns a wrong answer when crossing the dateline.

Here is the right answer, away from the dateline.

postgis20=# select st_area(g::geography,false)/1000000, st_area(transform(geometry(g), 4326)), astext(geometry(g)) from (select 'POLYGON((9.5 2, 9.5 1, 8.5 1, 8.5 2, 9.5 2))'::geography) as foo(g);
    ?column?     | st_area |                  astext                  
-----------------+---------+------------------------------------------
 12360.265021368 |       1 | POLYGON((9.5 2,9.5 1,8.5 1,8.5 2,9.5 2))
(1 row)

Here is the answer we get

postgis20=# select st_area(g::geography,false)/1000000, st_area(transform(geometry(g), 4326)), astext(geometry(g)) from (select 'POLYGON((179.5 2, 179.5 1, -179.5 1, -179.5 2, 179.5 2))'::geography) as foo(g);
     ?column?     | st_area |                        astext                        
------------------+---------+------------------------------------------------------
 21896.2627343197 |     359 | POLYGON((179.5 2,179.5 1,-179.5 1,-179.5 2,179.5 2))
(1 row)

Change History (2)

comment:1 Changed 8 years ago by pramsey

This problem was originally noted in spheroid area (#450) and was fixed. The sphere problem remains.

comment:2 Changed 8 years ago by pramsey

Resolution: fixed
Status: newclosed

False alarm, I just had a mistake in my test case. Did find potential future corner case and patched it. Branch 1.5 at r5344 and trunk at r5345

Note: See TracTickets for help on using tickets.