2

I've got a plot of land in Texas that is (WKT):

MULTIPOLYGON (((-98.12317899283 26.29444331481, 
-98.12355263136 26.29220720658, -98.1274736313 26.29279476234, 
-98.12691816383 26.29544258344, -98.12532028286 26.29498101405, 
-98.12321790601 26.29467334228, -98.12317899283 26.29444331481)))'

I'd like to calculate the area in sq m. We are storing the data as 4326 in PostgreSQL. We also need to calculate values for plots in CAN and BRA, so really it's safest to go with "anywhere in the western hemisphere".

Current code is

ST_Area(ST_Transform($1, 5070)) as area_sq_m

I'm prototyping so I'm setting $1 when I run the script using ST_GeomFromText with 4326 as the 2nd arg. This gives me 109458.48788528093 sq m.

Which SRID should I use for this calculation? What are the tradeoffs?

Improve this question
1
  • 2
    US CONUS Albers certainly wouldn't work for Texas, Canada and Brazil. The bad news is that this is an opinion-based Question. The good news is that studying up on projections would allow you to have a good opinion. Or you can just use a geodesic calculation in geography.
    – Vince
    Commented Sep 15, 2023 at 1:06

2 Answers 2

Reset to default
6

Cast to geography and use use ST_Area to calculate area with units m².

SELECT ST_Area('MULTIPOLYGON (((-98.12317899283 26.29444331481, 
  -98.12355263136 26.29220720658, -98.1274736313 26.29279476234, 
  -98.12691816383 26.29544258344, -98.12532028286 26.29498101405, 
  -98.12321790601 26.29467334228, -98.12317899283 26.29444331481)))'::geography);

109458.59346706979

This method works anywhere, does not need a projected CRS, and has a high accuracy.

Improve this answer
6
  • We have some existing code around that is deriving an SRID based on lat/long -- would that be more accurate than casting to geography?
    – jcollum
    Commented Sep 15, 2023 at 19:34
  • Areas based on projections tend to get distorted near the edges, so are not as good. Geodesic areas done by ST_Area with geography type don't have such distortions, and are accurate; more on the algo used in PostGIS here
    – Mike T
    Commented Sep 17, 2023 at 3:41
  • that's good info thanks
    – jcollum
    Commented Sep 18, 2023 at 15:12
  • The only other answer I have to this question says use local coord system and you're saying do not use local coord system, yes? So how do I determine which is right? Is there some sort of reference polygon I can drop into my calculation to verify?
    – jcollum
    Commented Sep 18, 2023 at 15:21
  • 1
    Both methods work fine. This method has high precision for an area on a curved surface, if that's your metric of "area". However, many folks operate on flat maps via local projections which you can also get a flat area. So it's a matter if you want a flat or curved area.
    – Mike T
    Commented Sep 18, 2023 at 21:02
2

For highest accuracy, you would want to transform to a local coordinate system. For Texas it seems to be broken down into 5 state plane zones(EPSGs:32137,32138,32139,32140,32141). But the easiest (slightly less accurate), is using UTM zones. Still Texas intersects 3 different zones (EPSGs: 26913, 26914 and 26915). Once you decide on the coordinates you want to use, I would build an other table in our database with polygons and the associated EPSG. This way you can join them by intersection and apply the right transformation to each item you need to measure.

Improve this answer
3
  • Did you see "We also need to calculate values for plots in CAN and BRA" ?
    – jcollum
    Commented Sep 15, 2023 at 15:28
  • Yes, the same applies there, canada has province based coordinate sustem which are used often by the forestery industry. Example: BC Albers in british columbia ( Espg:3005). But again easier to use UTM zones N 7-22 ( 26907,26908,26909,26910, etc)
    – B-C B.
    Commented Sep 16, 2023 at 21:30
  • Same goes for brazil but you’d want to use a southern emisphere utm sustem like Sad 96. Eg. Espg 5875
    – B-C B.
    Commented Sep 16, 2023 at 21:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.