[postgis-users] ERROR: ptarray_area_spheroid: cannot handle ptarray that crosses equator

Sarah Berke skberke at uchicago.edu
Sun Jul 24 14:27:32 PDT 2011


I've figured out a little more detail about my ST_Area problem, perhaps this
might help someone give me some advice for troubleshooting. To provide a
little more background, I've generated several thousand polygons using
ST_ConvexHull from collections of points (I've tried both
ST_ConvexHull(ST_Collect(points)) and ST_ConvexHull(ST_Union(points)) ) and
when I try to calcuate their areas I get this error:

ERROR:  ptarray_area_spheroid: cannot handle ptarray that crosses equator
CONTEXT:  SQL function "st_area" statement 1


The problem seems to be that ST_Area cannot handle some polygons with
internal crosses (i.e. bowtie-shaped) that share a border with the equator,
even though it can handle them elsewhere. For example:

SELECT ST_AREA(ST_GEOGFROMTEXT('POLYGON((15 -5, 15 5, 16 0, 16 -5, 15
-5))')) ;
works just fine--this is just a simple polygon that crosses the equator. By
the same token, a simple polygon that borders the equator works:

SELECT ST_AREA(ST_GEOGFROMTEXT('POLYGON((15 -5, 15 0, 16 0, 16 -5, 15
-5))')) ;

Switching the 2nd and 3rd coordinates, however, makes a bowtie-shaped
polygon which is valid, but it shares a border with the equator and ST_Area
cannot take it:

SELECT ST_AREA(ST_GEOGFROMTEXT('POLYGON((15 -5, 16 0, 15 0, 16 -5, 15
-5))')) ;

ERROR:  ptarray_area_spheroid: cannot handle ptarray that crosses equator
CONTEXT:  SQL function "st_area" statement 1

The same kind of formation works fine, however, if it does not share a
border with the equator :

SELECT ST_AREA(ST_GEOGFROMTEXT('POLYGON((15 -5, 16 1, 15 0, 16 -5, 15
-5))')) ;
SELECT ST_AREA(ST_GEOGFROMTEXT('POLYGON((15 -4, 16 1, 15 1, 16 -4, 15
-4))')) ;


Again, here are my system details:
PostgreSQL 8.4.8 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real
(Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64-bit
POSTGIS="1.5.2" GEOS="3.3.0-CAPI-1.7.0" PROJ="Rel. 4.7.1, 23 September
2009" LIBXML="2.7.6" USE_STATS

I assume that one or more of the polygons I made with ConvexHull is a
bowtie-shape sharing a border with the equator, but why would ST_ConvexHull
generate a shape like that? How can I avoid this problem? Short of visually
examining the map of every one of these several thousand polygons, how do I
even figure out which one is the culprit? Is there a better way to go from
points or multipoints to polygons?

Any insight would be really great! Thanks!

_________________________________
Sarah K Berke
Postdoctoral Scholar
Department of the Geophysical Sciences
University of Chicago
5734 S. Ellis Ave
Chicago, IL 60637


Date: Fri, 22 Jul 2011 14:39:52 -0500
> From: Sarah Berke <skberke at uchicago.edu>
> Subject: [postgis-users] ERROR: ptarray_area_spheroid: cannot handle
>        ptarraythat crosses equator
> To: postgis-users at postgis.refractions.net
> Message-ID:
>        <CAJUPZDEPTyKHb4LoG1szea0mSpRGikpFHM70Fh_AtBBuxSoYJA at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello,
>
> I found a short thread on this subject from February 2011--I am now having
> the same problem that Marcello had, and I wonder if anyone has found a fix
> or workaround for this problem? Using the same example code that Marcello
> provided:
>
> SELECT 161109 polygon ,ST_AREA(ST_GEOGFROMTEXT('POLYGON((15.8327132977611
> 0.25,16 0.25,16 0,15.8566682147637 0,15.8566112518311
> 0.00356000009924173,15.8485898971558 0.124770000576973,15.8327132977611
> 0.25))')) gsareageo;
>
> I get
>
> ERROR:  ptarray_area_spheroid: cannot handle ptarray that crosses equator
> CONTEXT:  SQL function "st_area" statement 1
>
> I am using:
>
> PostgreSQL 8.4.8 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real
> (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64-bit
> POSTGIS="1.5.2" GEOS="3.3.0-CAPI-1.7.0" PROJ="Rel. 4.7.1, 23 September
> 2009" LIBXML="2.7.6" USE_STATS
>
> >From the earlier thread, it sounds as if this version of postgis should
> run
> the code just fine? I saw that Marcello was able to work around the problem
> by changing 0 lats to being very near-0; but this of course affected the
> calculated areas. Can anyone guess why this is a problem, or has anyone
> figured out a better solution?
>
> Thanks very much!
> _________________________________
> Sarah K Berke
> Postdoctoral Scholar
> Department of the Geophysical Sciences
> University of Chicago
> 5734 S. Ellis Ave
> Chicago, IL 60637
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://postgis.refractions.net/pipermail/postgis-users/attachments/20110722/ec2f1ed8/attachment.html
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20110724/1b42c9a4/attachment.html>


More information about the postgis-users mailing list