[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgis-users
Subject:    Re: [postgis-users] Geometries returning zero area with PostGIS 3.1.2.
From:       Paul Ramsey <pramsey () cleverelephant ! ca>
Date:       2021-07-12 20:31:14
Message-ID: 84E34968-BED4-4C9D-99C8-C446A8744E1A () cleverelephant ! ca
[Download RAW message or body]

Thanks for the easy-to-use example data.

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?

  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.

P

> On Jul 12, 2021, at 1:03 PM, Marco Boeringa <marco@boeringa.demon.nl> wrote:
> 
> Hi Paul,
> 
> Done:
> 
> https://trac.osgeo.org/postgis/ticket/4951
> 
> Note that I copied the WKT representation straight from DBeaver's display of it in \
> the table view. Seems to work fine though... I tested displaying the files in a \
> browser based WKT renderer, and it appeared OK. 
> Marco
> 
> Op 12-7-2021 om 21:46 schreef Paul Ramsey:
> > Marco,
> > Can you open a ticket and attach some WKT to said ticket? That way I can test it \
> > without having to learn how to extarct those relations from OSM myself. Thanks!
> > P
> > 
> > > On Jul 11, 2021, at 3:42 AM, Marco Boeringa <marco@boeringa.demon.nl> wrote:
> > > 
> > > Hi all,
> > > 
> > > 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/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. 
> > > Marco
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > postgis-users mailing list
> > > postgis-users@lists.osgeo.org
> > > https://lists.osgeo.org/mailman/listinfo/postgis-users
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-users mailing list
> postgis-users@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-users

_______________________________________________
postgis-users mailing list
postgis-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users


[prev in list] [next in list] [prev in thread] [next in thread]