Re-raising the issue below:

Using integer degrees angle input only is completely unacceptable and irrelevant as an excuse of not handling floating point error:

1. JS trigo functions use radians and not angles as input, so the input is already a floating point number
2. At some point there will be a trigo or inverse trigo function invoked (in fact also a square root), and trigo functions are transcendental, so the result will introduce floating point errors. This is how I get the [0.00000000000001, 89.99999999999999]
3. There are already 2 solutions that rounds numbers willy nilly to work around this issue, while some solutions do not. So essentially the same logic will cause different result to be returned just from the difference of the exact expression used for the calculations, which some are approved and some are rejected. This is, obviously, unacceptable (unless the kata is specifically testing for operations, which this kata isn't)

Also, "opinion-based issue" my ass, please wake up and actually address the content of the issues, and learn how to deal with numbers properly. This is a rookie mistake, and calling it "opinion" is a massive insult to everyone involved in the beta process.

a list of those 26 groups location

There's no reason for arrays to be this big.