Vissarion Fisikopoulos

First of all I agree that it would be useful for Boost.Geometry to have an accurate solution for as many as possible implemented algorithms. Having a more accurate version of...

There are some accuracy data for Andoyer method (and other methods) here: https://github.com/vissarion/geometry/wiki/Accuracy-and-performance-of-geographic-algorithms

I also agree and like the design proposal in general. Thanks @awulkiew ! I have some comments regarding the user perspective. For naming I think we should use the same...

>There is also another thing, i.e. distinction between spherical_equatorial and spherical_polar. In most cases spherical_polar is not supported (my guess is that nobody uses it) and in rare cases where...

@vschoech is this still present in 1.79.0 (rescaling is removed). Sorry I cannot reproduce your issue because of the `tc::geo::polygon` type.

This is still present in 1.79.0. side note: for `double` instead of `int` the result is correct.

You need to include the stategies for centroid. Including the following should work ```#include ``` However, AFAIU, this should not be needed to use the centroid algorithm.

@fsimonis sorry for overlooking here. Indeed there is no consistent way for citing boost.geometry. The simplest way I see is using github-zenodo interaction and create a DOI, see https://guides.github.com/activities/citable-code @barendgehrels...

I agree with @mloskot

>My point was that this would be the workaround. The custom strategy that we'd have to implement would probably do something similar, i.e. similar math would have to be done...