Sphere based calculations for geography don't appear to be faster?

[Marco Boeringa]

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 <lr at 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