[postgis-users] Strange ST_Area problem
I've got some building outlines that I'm pretty sure I've worked with before. They are all srid 4326 (lat/lon), converted from a SHP file. ST_Area returns extremely small numbers for any of the buildings. It's almost like it's looking at the data like they are absolute numbers instead of lat/lon. Thoughts? As an example: select st_npoints(the_geom), st_srid(the_geom), st_summary(the_geom), st_area(st_transform(the_geom,4326)) from buildings; st_npoints | st_srid |st_summary| st_area +-+--+-- 5 |4326 | | 9.7305773438805e-09 : MultiPolygon[BS] with 1 elements : Polygon[] with 1 rings :ring 0 has 5 points : 5 |4326 | | 1.1065881433403e-08 : MultiPolygon[BS] with 1 elements : Polygon[] with 1 rings :ring 0 has 5 points : -- Eric Ladner ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Strange ST_Area problem
st_area returns in the same units as the input data. So data in 4326 is degrees and you numbers are in degrees squared. If you want the number in meters or feet then project then into an appropriate UTM or equal area projection. -Steve On 3/24/2012 11:48 AM, Eric Ladner wrote: I've got some building outlines that I'm pretty sure I've worked with before. They are all srid 4326 (lat/lon), converted from a SHP file. ST_Area returns extremely small numbers for any of the buildings. It's almost like it's looking at the data like they are absolute numbers instead of lat/lon. Thoughts? As an example: select st_npoints(the_geom), st_srid(the_geom), st_summary(the_geom), st_area(st_transform(the_geom,4326)) from buildings; st_npoints | st_srid |st_summary| st_area +-+--+-- 5 |4326 | | 9.7305773438805e-09 : MultiPolygon[BS] with 1 elements : Polygon[] with 1 rings :ring 0 has 5 points : 5 |4326 | | 1.1065881433403e-08 : MultiPolygon[BS] with 1 elements : Polygon[] with 1 rings :ring 0 has 5 points : ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Strange ST_Area problem
On Sat, Mar 24, 2012 at 11:06 AM, Stephen Woodbridge wrote: > st_area returns in the same units as the input data. So data in 4326 is > degrees and you numbers are in degrees squared. If you want the number in > meters or feet then project then into an appropriate UTM or equal area > projection. Ah.. that makes sense. Would EPSG:32230 be appropriate? (WGS 72, UTM zone 30N) I'm dealing with things roughly in the 30.0 to 31.0N range. > - Steve Thanks! -- Eric Ladner ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Strange ST_Area problem
On 25 March 2012 12:19, Eric Ladner wrote: > Would EPSG:32230 be appropriate? (WGS 72, UTM > zone 30N) I'm dealing with things roughly in the 30.0 to 31.0N range. EPSG:32630 is a better projected reference, since it shares the same spheroid, WGS 84, as EPSG:4326 (rather than mixing in the older WGS 72). http://spatialreference.org/ref/epsg/32630/ You should also check out converting your geometry types into geography types, which automagically calculates ST_Area (and ST_Length, and others) using tangible units of metres. http://postgis.refractions.net/docs/ch04.html#PostGIS_Geography -Mike ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
