[postgis-tickets] [PostGIS] #4951: Geometries returning zero area with PostGIS 3.1.2

PostGIS trac at osgeo.org
Mon Jul 12 13:29:30 PDT 2021


#4951: Geometries returning zero area with PostGIS 3.1.2
------------------------+---------------------------
  Reporter:  mboeringa  |      Owner:  pramsey
      Type:  defect     |     Status:  closed
  Priority:  medium     |  Milestone:  PostGIS 3.1.3
 Component:  postgis    |    Version:  3.1.x
Resolution:  invalid    |   Keywords:
------------------------+---------------------------
Changes (by pramsey):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 I strongly doubt (??) this is changed behaviour, because it's behaviour
 with a reason, and the reasons are this.

 First, note the answer I get when I do not add the convex hull function to
 the query.
 {{{
 select st_area(ST_Transform(geom, 4326)::geography) from osm;

       st_area
 --------------------
   4650984117506.695
  33615580446323.664
 }}}

 Correct answers. Also note that, if you look at these shapes, they are
 essentially just rectangles, but they have a lot of vertices along the
 edges. In geometry (planar) space, those extra vertices are redundant,
 they just define the existing straight line between the corners. However
 in geography space (spherical) those vertices are quite important, they
 define a path along the parallels which is both (a) defined in edges of <
 180 degrees and (b) not the same as the default edge path (a great
 circle).

 So what happens in that convex hull call?
 {{{
 opentopo=# select st_astext(st_convexhull(st_transform(geom, 4326))) from
 osm ;

                                 st_astext
 --------------------------------------------------------------------------
  POLYGON((-180 -85.0511287,-180 -60,180 -60,180 -85.05,-180 -85.0511287))
  POLYGON((-180 -85.0511287,-180 -60,180 -60,180 -85.05,-180 -85.0511287))
 }}}

 Urm. The big horizontal "straight line" is reduced to one edge, and it
 goes "from" (-180 -60) to (180 -60), which is, in spherical space, a zero-
 distance path. Hence the zero area result.

 This is behaviour right at the core of the geography type, so I'm more
 surprised that you'd *ever* get a difference answer, in any version of
 PostGIS, running the SQL example you've shown.

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4951#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.


More information about the postgis-tickets mailing list