ST_Area NaN on some polygons

Description

In one of our African datasets, we need to calculate ST_Area on the sphere for all polygons. ST_Area is returning NaN for some, but not all, polygons. The affected polygons appear to be equator crossing but otherwise there is no obvious connection and not all equator crossing polygons are affected.

We're confirming the issue on running PostGIS instances as far back as 2.1.2, but chronologically this only surfaced recently for us -- at some point in the past year or two these calculations used to pass without any NaN.

The failing polygons vary depending on the exact system and PostGIS version and seem somewhat bizarre and random.

The results below come from 2 systems, my Mac laptop and a Linux server and are slightly different but both broken.

Change History (6)

Any reason you're calculating on the sphere in particular? (Not that it matters, the old version would be sphere only anyways, probably.) The results even when you don't get NaN are pretty bad, even back when using postgis 2.0, for example:

I'd expect changes from 2.1 to 2.2, as we changed to new spherical area code. I'm surprised to see changes from 2.0 to 2.1, but I see that also. Anyways, I'm not sure the answers are right, even when you get non-NaN answers. Will have to confirm that.

We were using the sphere for continuity with old published results. I just changed all the queries to use the spheroid and they seem to be running fine on 2.2.0 and within a small tolerance of our old sphere-based results, so that will get us out of short-term trouble. You're also correct that all the sphere based calculations are super crazy right now, and not just on the equator.

I applied the above change back to 2.1 (r14485, r14486, r14487). (If I'm not mistaken, the spheroid area routines changed in 2.2, but the sphere routines did not.)

This resolves the NaN issues, or at least any that I can find. I'm not sure about "all the sphere-based calculations are super-crazy" though. Maybe you can post some test polygons to a separate ticket, rfc2616?