Opened 5 years ago

Closed 4 years ago

#4598 closed defect (wontfix)

spurious results of ST_Centroid on invalid polygons of type geography

Reported by: fadi Owned by: pramsey
Priority: medium Milestone: PostGIS 2.5.5
Component: postgis Version: 3.0.x
Keywords: Cc: grasslandtom

Description

The following query:

WITH geogs (geog) AS (VALUES
    ('POLYGON((0 0, 0 1, 1 1, 1 0, 0 0))'::geography),
    ('POLYGON((0 0, 1 1, 1 1, 0 0))'::geography),
    ('POLYGON((0 0, 1 1, 1 0, 0 1, 0 0))'))
SELECT
    pg_typeof(geog),
    ST_IsValidReason(geog::geometry),
    ST_AsText(ST_Centroid(geog)),
    ST_AsText(ST_Centroid(geog::geometry)),
FROM geogs;

will output :

pg_typeof st_isvalidreason st_astext st_astext
geography Valid Geometry POINT(0.499999916440062 0.500006427946943) POINT(0.5 0.5)
geography Too few points in geometry component[0 0] POINT(-nan nan) POINT(0.5 0.5)
geography Self-intersection[0.5 0.5] POINT(0.5 0.333342264894616) POINT(0.5 0.5)

(3 rows)

  • The first one seems okay, assuming the numbers are due to numerical not very

precise calculation, although I would have expected the centroid some where between 0 and 0.5 in terms of latitude (the polygon is thicker at the bottom)

  • Second and third do not look right.
    $ select postgis_full_version();
    

POSTGIS="3.0.0 r17983" [EXTENSION] PGSQL="120" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.2, 08 September 2015" GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3" LIBJSON="0.11.99" LIBPROTOBUF="1.2.1" WAGYU="0.4.3 (Internal)" RASTER

Change History (4)

in reply to:  description comment:1 by grasslandtom, 5 years ago

Replying to fadi:

  • The first one seems okay, assuming the numbers are due to numerical not very

precise calculation, although I would have expected the centroid some where between 0 and 0.5 in terms of latitude (the polygon is thicker at the bottom)

  • Second and third do not look right.

Taking into account the comment regarding the first one (i.e. "thicker at the bottom") the third one might well be ok (did not verify that in any way).

For the "Too few points in geometry" case, it seems inconsistent that ST_Centroid(geography) returns POINT(-nan nan) while ST_Centroid(geometry) nevertheless computes a "correct" result. It could be expected that in both cases the output is the same as for the linestring that would be the correct representation of the given "polygon" (which is already the case for ST_Centroid(geometry)):

select st_astext(st_centroid('linestring(0 0, 1 1)')), st_astext(st_centroid('linestring(0 0, 1 1)'::geography));
-[ RECORD 1 ]-----------------------------------------
st_astext | POINT(0.5 0.5)
st_astext | POINT(0.499961919922622 0.500019038226107)

comment:2 by grasslandtom, 5 years ago

Cc: grasslandtom added

comment:3 by pramsey, 5 years ago

Milestone: PostGIS 2.5.4PostGIS 2.5.5

comment:4 by robe, 4 years ago

Resolution: wontfix
Status: newclosed

I'm going to dismiss this as a won't fix. The first one looks right

WITH geogs (geog) AS (VALUES
    ('POLYGON((0 0, 0 1, 1 1, 1 0, 0 0))'::geography),
    ('POLYGON((0 0, 1 1, 1 1, 0 0))'::geography),
    ('POLYGON((0 0, 1 1, 1 0, 0 1, 0 0))'))
SELECT
    pg_typeof(geog),
    ST_IsValidReason(geog::geometry),
    ST_AsText(ST_Centroid(geog)),
    ST_AsText(ST_Centroid(geog::geometry)),
	ST_AsText(ST_Transform(ST_Centroid(ST_Transform(geog::Geometry,_ST_BestSRID(Geog))),4326) )
FROM geogs;

I get this:

POINT(0.499934819426203 0.500006912686044)

which isn't too far off from the geography answer. As to handling invalid polygons I'm not convinced it's worth thinking about.

Note: See TracTickets for help on using tickets.