Geometries returning zero area with PostGIS 3.1.2

[mboeringa]

I am running into an issue with two of OpenStreetMap's polygon geomtries returning a zero area for the following PostGIS SQL clause:

ST_Area(ST_ConvexHull(ST_Transform(way,4326))::geography,true)

Note that the data was imported using osm2pgsql, with the data stored in WGS1984, not Web Mercator.

The two relations that cause the issue are:

​https://www.openstreetmap.org/relation/2186646

​https://www.openstreetmap.org/relation/3394113

One represents "Antarctica", the other the "Ross Dependency".

Note that both relations appear to be quite old (years), and I am therefor pretty sure I have processed the exact same geometries previously without issues with older versions of PostGIS after planet import. Note also that both geometries test as valid with "ST_Isvalid(way)" after import using osm2pgsql.

Has something changed in the latest PostGIS 3.1.2 that might explain this result, e.g. especially related to the "::geography" cast or the "ST_ConvexHull" statement?

Of course, in the way these geometries wrap the globe, they may represent a challenge, but as said, I am pretty sure I must have processed the same geometries without issues in previous releases of PostGIS.

[mboeringa]

Ross Dependency from OpenStreetMap as WKT file

[mboeringa]

Antarctica from OpenStreetMap as WKT file

[pramsey]

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.

[mboeringa]

Hi Paul,

Nice answer, although it is always a bit difficult to wrap my head around such a description and mentally visualize what happens. Putting the examples in the online WKT renderer, helped though.

So, due to the particular and a bit unfortunate peculiar nature of these polygons, combined with calculating the "convex hull", you end up with a dimensional collapse… so, yes, that explains zero area well.

I must admit that between active code development, and multiple long running import and process sessions on global planet data, it is difficult for me to 100% garantuee I processed these geometries before (e.g. I also recently tested Facebook's Daylight distribution, but Facebook may have dropped these geometries from their distribution, IRDK).

Nonetheless, if you have a possibility to easily test this in previous version, it might be worthwhile to test the result in at least one older version of PostGIS before closing the issue.