Merge is geodesic routines from GeographicLib 1.48. Changes:

[cffk]

• http://geographiclib.sf.net -> http://geographiclib.sourceforge.io
• backport fixes for warnings messages from some compilers
• change default range for longitude and azimuth to (-180d, 180d]
  (instead of [-180d, 180d))

[cffk]

Error message from failing travis build (for osx) is "Sorry we experienced an error". Possibly this is just a transient problem?

[kbevers]

I just restarted the build and this time it came up with this error:

[ 65%] Building C object src/CMakeFiles/proj.dir/pj_apply_vgridshift.c.o
/Users/travis/build/OSGeo/proj.4/src/geodesic.c:218:7: error: implicit conversion turns floating-point number into integer: 'real' (aka 'double') to '_Bool' [-Werror,-Wfloat-conversion]
  if (x) { *sinx += (real)(0); *cosx += (real)(0); }
  ~~  ^
1 error generated.
make[2]: *** [src/CMakeFiles/proj.dir/geodesic.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [src/CMakeFiles/proj.dir/all] Error 2
make: *** [all] Error 2

I haven't tested it, but I am guessing that if (x != 0.0) solves the problem.

By the way, is there a particular reason why you are using real in favour of double?

[cffk]

Hmm... When did "if (x)" instead of "if (x != 0)" become an error? I
thought C would be as forgiving as C++ on this. Anyway I've made the
fix and checked it in.

I use real instead of double in geodesic.c to keep the code as close as
possible to the C++ version. (You will note that I also similarly
typedef int boolx.) And in the C++ version I certainly allow real to be
other types: float, long double, boost::multiprecision::float128, and
mpfr::mpreal. (And the high precision types are crucial for testing.)

Would it matter if "real" were replaced by "double"? No. I've had to
do this with the Java implementation. But if it's not causing any
problems, I'd prefer to leave it as "real".

[kbevers]

I use real instead of double in geodesic.c to keep the code as close as
possible to the C++ version. (You will note that I also similarly
typedef int boolx.) And in the C++ version I certainly allow real to be
other types: float, long double, boost::multiprecision::float128, and
mpfr::mpreal. (And the high precision types are crucial for testing.)

Would it matter if "real" were replaced by "double"? No. I've had to
do this with the Java implementation. But if it's not causing any
problems, I'd prefer to leave it as "real".

Please leave it in, I was just curious about why it was there in the first place.