1

I am a complete newbie using GIS, and particularly using postgresql-postgis.

I have a table with administrative boundaries where limits are multipolygons defined in utm (EPSG:23030).

I want to calculate both centroids and also minimum-bounding-circle centre and radius, for each row of the table.

To my surprise, the coordinates I got are different if I transform them before/after calculating the centroid:

postgis=# SELECT gid, name, ST_AsText(ST_Transform(ST_Centroid(the_geom),4326)) as centr1_trans2, ST_AsText(ST_Centroid(ST_Transform(the_geom,4326))) as trans1_centr2 from adminboundaries_23030 where name='Madrid';

 gid  |  name  |              centr1_trans2               |              trans1_centr2
------+--------+------------------------------------------+-----------------------------------------
 5642 | Madrid | POINT(-3.6962798422859 40.4655298819556) | POINT(-3.6963536465966 40.465587716731)
(1 row)

If I do it the other way round (conversion from a table with latlon 4326 to utm 23030), these are my results. 6-8 m of difference:

postgis=# SELECT gid, name, ST_AsText(ST_Transform(ST_Centroid(the_geom),23030)) as centr1_trans2, ST_AsText(ST_Centroid(ST_Transform(the_geom,23030))) as trans1_centr2 from admboundaries_4326 where name='Madrid';

 gid  |  name  |              centr1_trans2               |              trans1_centr2
------+--------+------------------------------------------+------------------------------------------
 5642 | Madrid | POINT(441074.289262773 4479875.27865048) | POINT(441080.495696979 4479868.80970194)
(1 row)

I know this is not a huge difference, but is there any easy explanation for it?

Which one would be the most correct way of calculate the centroids before displaying them in a web map?

  • 1
    The centroid algorithm doesn't change, but the coordinates do, so yes, it should be expected that the results would be slightly different. Deprojecting a single centroid should be significantly faster than deprojecting an entire polygon, then calculating a centroid. Correctness is in the eye of the beholder, especially when ST_Centroid doesn't even guarantee that the resulting point will be within the parent geometry. – Vince Mar 11 '18 at 21:04
  • @Vince thanks for your answer. I understand what you mean about correctness. I also got your point about calculation speed. Both opinions quite valuable for me to make a decission. Regarding what should be expected, I do not understand: shouldn't the results be almost identical if the original coordinates have a big accuracy? (as far as original coordinates are not somehow rounded or loose accuracy during the calculations). Both coordinate systems do represent the same polygon. Is ST_Centroid() intended to be used only with either metric or geographical coordinates? – abu Mar 12 '18 at 11:52
  • Projection will change the character of a geometry, including rotation, shape, and aspect ratio. The Cartesian center of mass will not be constant under such circumstances. I've given up on ST_Centroid and only use ST_PointOnSurface, since my polygons invariably have holes and concave shapes that result in centroids outside the geometry. – Vince Mar 12 '18 at 12:18
  • If non-interior centroids are of no concern, I'd say use a geographical CRS and geography type/cast for spatial analysis if possible. that way, your centroids should have the highest accuracy, even if the projected points might be off for reasons stated by @Vince. as for the precision of your coordinates...after 10 decimal places it slowly turns into fiction anyways... – ThingumaBob Mar 12 '18 at 21:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.