| Age | Commit message (Collapse) | Author |
|---|
|
We are relying more and more on C99 math functions. On C89 systems where
those functions are not available our own custom versions of those
functions are used instead. So far these has been spread across the code
base. This commit gathers them in the same file and introduces the
proj_math.h header. The build system checks for C99 math functions. If
not found the proj_math.h header make sure that C99 functions are
defined as their pj_ equivalent.
Ideally proj_math.h is included instead of math.h. This removes the need
for any checks against HAVE_C99_MATH in the code making it easier to
read.
For this commit the functions hypot, log1p and asinh has been taken care
of.
|
|
It is not necessary to read +lat_0 with pj_param in projection setup. It
is read by default in pj_init().
|
|
* Avoid using angle brackets for PROJ headers.
Switching from #include <proj.h> to #include "proj.h",
and correspondingly for projects.h and proj_api.h,
reduces the risk of accidentally picking up a system
installed older version of the header while building
a new version of PROJ.
* Also handle geodesic.h
|
|
* Removed remaining traces of the builtin selftest system. Moved all functionality to test/gie
* Updated Appveyor and Travis build scripts
* Another appveyor script update
|
|
* Ensure C89 compliance and enable more warnings
According to the contributing guidelines, the library is developed
strictly in ANSI C 89. However, this is not enforced.
Additionally, we enable more warnings: apart from -Wall and -Wextra we
enable a warning that makes sure all enumeration values are covered in
a switch statement.
When compiling with Clang, we also turn on the warnings -Wc99-extensions
and -Wc11-extensions.
* Enable all warnings that are used on Travis
This makes it easier to notice problems before pushing.
|
|
Enumerations have the following advantages over #define:
- they clearly connect a variable and the allowed constants,
- the meaning of code is not obfuscated by integer values,
- they are visible to the compiler, which can warn about (possibly)
incorrect usage.
There should be no functional change.
|
|
All projections starting with "a". Replace with stubs returning 10000.
The two PJ_apply_?gridhift.c files have not been touched
|
|
In most cases memory deallocation is completely removed from the
code since it can be handled by the default destructor. In a few
special cases a local destructor overrides the default destructor
and makes sure that locally allocated memored is cleaned up correctly.
Move all deallocation from pj_free to pj_default_destructor
Rename pj_latlong.c to fit with the conventional format PJ_latlong.c - freeup was missed here due to wrong naming
Clean up pj_init to avoid double deallocation; Also resolve #576 by adding z_0 and t_0 options in pj_init, while cleaning
Add a prototype for dealloc_params
Added missing errno.h include in pj_ctx.c
Temporarily removing ob_tran from testvarious, to be sure that is where the trouble is
Make PJ_ob_tran.c use proper initialization for the chained projection
proj=ob_tran: make it clear, that we disallow ellipsoidal projections, and, for improved backwards compatibility, turns off default settings, which could inject unwanted ellipsoid definitions
... then also remove the ellipsoid definition from the testvarious test case - which is probably buggy anyway
Work around cs2cs spherical init bug in testvarious; Forbid defs for ob_tran in pj_init
|
|
Expanded *_ERROR* macros with calls to proj_errno_set() and proper
returns when necessary. Defined a bunch of new PJD_ERR_ constants in
projects.h that corresponds to the error numbers in pj_strerrno.c. A few
unknown error numbers were replaced by existing ones in pj_strerrno.c.
|
|
|
|
conversions
|
|
unused variable
|
|
+a replaced with +R
|
|
|
|
facto standard M_PI and its ilk. Change names that are widely used in the project to be in the M_ namespace, so HALFPI becomes M_HALFPI. HALFPI is #defined as M_PI_2 (the defacto standard name). #defines _USE_MATH_DEFINES for MS Visual Studio (I didn't personally test this part, but Appveyor will not build otherwise).
|
|
|
|
I'm making this pull request soon after the release of 4.9.2. It will
cause the results that people get out of proj.4 to change very slightly.
If there are problems, we'll get a chance to iron them out well before
the next release.
The important change is to use DEG_TO_RAD for degree to radian
conversions in dmstor.c instead of the slightly inaccurate number used
earlier.
This necessitates a change to geod_interface.c (which previously had to
work aroung the previous bad behavior). PJ_aeqd.c now does conversions
in a compatible manner.
In src/proj_api.h, DEG_TO_RAD and RAD_TO_DEG are both given to 17
significant figures (this is just a cosmetic change).
I've "fixed" the testvarious tests so that they still pass (on my system
at least). Everyone should be suitably skeptical of my fixes.
(1) Minor changes to "Test bug 244" and only ask for nanometer (instead
of picometer) accuracy on positions.
(2) 2 lon_wrap tests now return 0dE instead of 360dE (now it's tight?)
(3) The results for the forward healpix projection of (-180, +90) and
(-180, -90) are now different. I have put the new values into
tv_out.dist. I'm fairly confident that the new values are OK, since
this projection has various cuts which meet at the poles. It would be
good if someone who knows about this projection can verify this.
|
|
|
|
|
|
PJ_aeqd.c uses geodesics for inverse and forward projection +
modification so that the geodesic structure is not global.
|
|
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@2520 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@1856 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@1504 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@1048 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@906 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
|
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@776 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
