Charles Karney

> I'd be willing to accept a change from `HUGE_VAL` to `NaN` if it came as part of a larger effort that completely rewires error handling in PROJ. Perhaps something...

All the credit for the hardware and software belongs to John Kulp. I was a heavy user of the graphics capabilities in this group of MIT graduate students working under...

This should be "easy" to implement. `geopy/distance.py` is already pulling in `geographiclib.geodesic` and all the functionality is there. A regular user or maintainer for `geopy` should do this (i.e., not...

OK, I'll take a look. The intention is that PROJ's geodesic calculations (C code) should mirror very accurately what you get from GeographicLib (C++ code).

The "exact" area of the 44-sided training_single polygon is -0.126347391348170 m^2 if the coordinates in the KML file are treated as exact decimal numbers. This calculation is performed by the...

> How about the polygon from the QGIS issue [qgis/QGIS#40888](https://github.com/qgis/QGIS/issues/40888)? For that the difference in area between current QGIS and GeographicLib was 0.654%. > > ``` > POLYGON (( >...

One possible source of confusion is that the [online planimeter tool](https://geographiclib.sourceforge.io/cgi-bin/Planimeter) is compiled to use `long double` so you get 11 bits more accuracy compared to the Planimeter tool you...

> I'm always unsure about center or corner of the pixel. This data is "pixel is point". I.e., the data give the heights at the corners of the cells (at...

I've just given Dennis's paper a quick read. I don't have much to contribute here. There should be some acknowledgement that if a conformal projection on the reference ellipsoid is...

I'm -1 on this too (sorry!). It's awkwardly jimmying an obsolete counting system (no zero, no negative numbers, no fractions) into a modern application. I fear it would also invite...