Get rid of the remaining hard coded pi constants

[Kurt Schwehr]

find . -type f -name \*c | xargs grep '3\.14'
./frmts/gtiff/libgeotiff/geo_normalize.c:#  define M_PI 3.14159265358979323846
./frmts/gtiff/libtiff/tif_luv.c:#define M_PI		3.14159265358979323846
./frmts/hdf4/hdf-eos/EHapi.c:#define RADIANS_TO_DEGREES 180. / 3.14159265358979324
./frmts/hdf4/hdf-eos/EHapi.c:#define DEGREES_TO_RADIANS 3.14159265358979324 / 180.
./frmts/hdf4/hdf-eos/gctp_wrap.c:#define PI (3.141592653589793238)
./frmts/pcraster/libcsf/angle.c:# define M_PI        ((double)3.14159265358979323846)
./frmts/pcraster/libcsf/create2.c:# define M_PI        ((double)3.14159265358979323846)
./frmts/grib/degrib18/degrib/myerror.c:      "<testing>", "<05><3.1415><D><20>",
./frmts/grib/degrib18/degrib/myerror.c:   reallocSprintf (&ptr, "<%02d><%.4f><%D><%ld>", 5, 3.1415, 20, 24);

and

find . -type f -name \*.py | xargs grep '3\.141'
./gdal/swig/python/samples/crs2crs2grid.py:    adjustment = adjustment * (3.14159265358979323846 / 180.0)
./autotest/ogr/ogr_gpkg.py:        feat.SetField('fld_real', 3.14159/(i+1) )
./autotest/ogr/ogr_gpkg.py:       feat.GetField(2) != 3.14159  or feat.GetField(3) != '2014/05/17' or \

[Kurt Schwehr]

The libtiff/tif_luv.c case looks okay, but are there really useful environment these days that do not have M_PI that would want to build libtiff?

#ifndef M_PI
#define M_PI            3.14159265358979323846
#endif

[Raeburn]

I would like to work on this defect, could you please assign it to me? Thank you :)

[Raeburn]

Hello goatbar, If we're to remove the M_PI definitions, how about we also remove M_LN2 as that too is defined in math.h?

[Kurt Schwehr]

Sure. I suggest doing only one of those per change so that we know that all platforms tested have M_LN2.

[Raeburn]

It seems that M_PI definition is not really a part of math.h, and not defining M_PI in visual studio is likely to break the compilation... ​http://stackoverflow.com/questions/26065359/m-pi-flagged-as-undeclared-identifier

[Jeff McKenna]

As a GDAL package maintainer on Windows (for ms4w.com / MapServer), please keep in mind that older Visual Studio compilers should also be supported. (the use of defining this constant is done in many software projects, I actually don't see the problem with it, as in "if it ain't broken don't fix it").

[Raeburn]

I see. So what do you suggest, should we close this ticket, because now I don't see any compelling reason to remove the hard coded constants...

[Kurt Schwehr]

I'm closing this ticket as invalid.