I now looked at some of the documentation of geographiclib and better
understand the current implementation for PostGIS.
Clearly, there is no special treatment for sphere based calculations
where flattening=0. There are two separate classes 'Geodesic' and
'GeodesicExact' in geographiclib, but both do full spheroid aware
calculations, the difference between the classes being that
'GeodesicExact' can handle larger values for flattening while still
keeping errors in check, at the cost of 2-3x slower processing,
according to the documentation. But that is a different distinction than
between simplified sphere versus complicated spheroid calculations as
suggested in the PostGIS Help text.
The PolygonAreaT class of geographiclib that I guess is used by PostGIS
for calculating geodesic areas also fully depends on the 'Geodesic' and
'GeodesicExact' classes, and thus follows the same distinction.
https://geographiclib.sourceforge.io/C++/doc/classGeographicLib_1_1Geodesic.html#details
https://geographiclib.sourceforge.io/C++/doc/classGeographicLib_1_1GeodesicExact.html#details
https://geographiclib.sourceforge.io/C++/doc/classGeographicLib_1_1PolygonAreaT.html#details
As Paul suggested, it would be interesting to see if indeed the current
implementation in PostGIS simply sets flattening to 0, and doesn't
feature a dedicated sphere based code section, as also indicated by the
timing results of the tests I did with PostGIS 3.4.3. The Help for
ST_Area (https://postgis.net/docs/ST_Area.html) is ambiguous, as the
"Enhanced: 2.2.0 - measurement on spheroid performed with GeographicLib
for improved accuracy and robustness." text suggests geographiclib may
only be used for the spheroid case, not sphere, but this may not
represent the true implementation as Paul suggests.
Marco
Op 1-10-2024 om 22:20 schreef Paul Ramsey:
On Oct 1, 2024, at 1:18 PM, Regina Obe <l...@pcorp.us> wrote:
This does not surprise me. I think Paul wrote that note 15 years ago and even
then I don't recall it making a significant difference and back then we weren't
even using geographylib and think we are now even for sphere.
We should probably take that not out of the docs.
Paul you have anything to say about the below? Does it make a difference maybe
if you have a narly multipolygon with 5,000,000 points?
No idea. But I bet if you trace the code you’ll find that area uses the
geographiclib code in both spherical and spheroidal mode, it just sets the
major and semi-major axes equal for the spherical mode. I haven’t confirmed
that, but my best guess.
P
-----Original Message-----
From: Marco Boeringa
Subject: Sphere based calculations for geography don't appear to be faster?
Hi,
After the PostGIS 3.4.3 release, that fixed an issue with sphere based
calculations for geography type, I decided to run a quick test to see if sphere
based calculations would give a performance benefit for my workflow. Due to
the existing bug, I had been using spheroid based calculations exclusively up to
now.
According to the Help (https://postgis.net/docs/ST_Area.html), the sphere
based calculations should be faster. However, looking at the timings listed
below, it appears there is no significant difference?
SQL used:
DROP MATERIALIZED VIEW IF EXISTS atest;
CREATE MATERIALIZED VIEW atest AS SELECT
ST_AREA(way::geography,true/false) FROM planet_osm_polygon
The test data was the Geofabrik Italy extract, and used the polygon table of an
osm2pgsql import containing +/- 19M records, containing polygons of varying
sizes up to country size. The tests were run on a local dedicated system with
plenty of IO and CPU.
Marco
*** SPHEROID ***:
Start time 2024-10-01 08:07:05.984
Finish time 2024-10-01 08:07:15.248
Start time 2024-10-01 08:08:13.881
Finish time 2024-10-01 08:08:24.362
Start time 2024-10-01 08:08:42.772
Finish time 2024-10-01 08:08:51.998
Start time 2024-10-01 08:09:16.137
Finish time 2024-10-01 08:09:26.484
*** SPHERE ***
Start time 2024-10-01 08:10:35.261
Finish time 2024-10-01 08:10:45.846
Start time 2024-10-01 08:11:05.856
Finish time 2024-10-01 08:11:16.110
Start time 2024-10-01 08:11:35.278
Finish time 2024-10-01 08:11:44.499
Start time 2024-10-01 08:12:18.769
Finish time 2024-10-01 08:12:29.020
