[postgis-users] ST_area returning wrong results (and stretched polygon in the screen)

Nicolas Ribot nicolas.ribot at gmail.com
Thu Jul 21 06:34:32 PDT 2011


On 21 July 2011 14:42, p valdes <p.valdes334 at gmail.com> wrote:
> Hi,
> I'm trying to calculate the area of a polygon, with strange results...
>
> First a description of the problem, the ugly details at the end of the post
>
> I have measured the perimeter of a pond. An irregular
> polygon vaguely 'chop shaped' without holes or spikes
> and closed (beginning and ending in the same point).
> For simplification purposes let's suppose that I was
> expecting something like the left shape...
> well, I'm obtaining instead this:
>
> expected    obtained
> -------            ---
> |      |           |  |
> |      |           |  |
> |      |__        |  |
> |          |       |  |
> -----------        |  |
>                   |  |
>                   |  |
>                   |  |_
>                   -----
>
> The right shape is "not right". The polygon is clearly
> stretched in the vertical North-South axis in the screen. The
> satellite google map support that the real shape of
> the pond is the first represented and I think the same...
>
> Well I could live with this, but there's two more nasty consequences.
>
> 1) If I take a point inside or related to the polygon
> in a separated map layer the point is drawn OUTSIDE
> and far away below the figure of the pond (note also that the
> pond is printed much more big than expect, because the relative distance
> between a and b is the same in both, and seems right). Graphically:
>
> expected     obtained
>
> --*a               ---
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |                |  |
> |  |_              |  |_
> -----*b           ------
>
>
>
>
>
>
>                      *a
>                      *b
>
> Maybe a problem of the map viewer software, yes but the second
> question is more serious:
>
> ST_distance calculates a distance between the "a" and "b" points of
> about 160 m for this rectangle. A max length of 160 m for this pond
> seems reasonable to me.
>
> but ST_area calculates an area for this polygon of almost 7 ha!, for a
> polygon that could fit in a rectangle of about 160x50 m!.
>  I'm obtaining a faked area about seven times BIGGER than real, uh-oh...
>
> Its clear to me that I'm doing a very obvious and stupid mistake. I
> greatly appreciated if you could take a look at the problem or suggest
> any possible source of the error
>
> Thanks in advance
>
> pvaldes.
>
>
>
> .....................................................................
> Details
> ..................
>
> The points were registered with a garmin GPS as coordinates in degrees
> (ie: 43.254 N -4.839 W)
>
> I'm using PostgreSQL 9.0.4
>          on i486-pc-linux-gnu, compiled by GCC gcc-4.6.real (Debian
> 4.6.0-6) 4.6.1 20110428 (prerelease), 32-bit
>          (obtained as Debian package from an official repository)
>
> postgis-1.5.3
>      (downloaded and compiled from the tarfile at postgis.refractions.net)
>
> This is the table
>
> CREATE TABLE mytable(
> ref serial PRIMARY KEY,
> name varchar(80),
> perimeter geography(POLYGON,4326)
> );
>
> The polygon with lat/lon coords was loaded with something like:
>
> INSERT INTO mytable (perimeter, name)
> VALUES (
> ST_GeogFromText(
> 'POLYGON((
> -5.3850 43.230,
> -5.3858 43.231,
> -5.3859 43.245,
>   ...
> -5.3850 43.230
> ))', 4326),'myname');
>
> And this is the very simple query returning strange results
>
> SELECT st_area(mytable.perimeter)::double precision AS square_meters
> FROM mytable
> WHERE name = 'myname';
>
> I use pgsql2shp for obtaining a shapefile that I'm loading with thuban


Hi,
st_area works with data units, degrees in your case.
So you are computing square degrees, which has no geographic meaning.
You should project your data to a metric system and then perform area
computation on the projected data.
North of Spain corresponds to UTM 30N (SRID 32630).

Nicolas



More information about the postgis-users mailing list