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

[Marco Boeringa]

Greg, given the current situation you are right it would be wise to 
adjust the Help docs for e.g. ST_Area() etc. and remove the statement 
that sphere based calculations are faster.

Out of curiosity, I also posted an issue on the upstream GeographicLib 
GitHub repo though, underlying PostGIS's implementation for geography 
data type. One of the developers confirmed that with flattening=0 
(sphere case), there is no special optimized code path in 
GeographicsLib. This confirms Paul's and Regina's statements (although 
those were more related to PostGIS itself) that there is no special 
treatment for the simpler sphere case.

The developer of GeographicLib did give some interesting suggestions 
though, especially the remark about the conversion of data to authalic 
latitudes, and using that as input for a possible faster sphere based 
implementation, to give a reliable approximation of spheroidal areas. See:

https://github.com/geographiclib/geographiclib/issues/31#issuecomment-2395549269

Marco

Op 2-10-2024 om 13:59 schreef Greg Troxel:
> Marco Boeringa<marco at boeringa.demon.nl> writes:
>
>> I am not suggesting geographiclib is a bad choice. It may well be the
>> fastest and most efficient implementation out there for doing geodesic
>> calculations. It is just that the current PostGIS Help documentation
>> clearly suggests that switching to sphere based calculations can
>> improve performance at the obvious cost of some less accuracy. And of
>> course it would be interesting to know if a true sphere based
>> implementation could be faster, but maybe nobody bothered to implement
>> one as it can be a special case of spheroidal, IDK?
> In that case, the thing to fix might be the docs.