| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The source and destination for strcpy must not overlap, and failure to
ensure that's true causes a crash on OS X. memmove does not have such a
restriction.
|
|
|
|
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.
|
|
|
|
It's generated by autoheader, which was mysteriously left out of
autogen.sh.
|
|
The former is deprecated and automake emits a warning about it.
|
|
These files are generated by automake.
|
|
|
|
Win32 pvalue issue ticket #273
|
|
|
|
|
|
|
|
Don't return values when doing inverse projections outside of the mollweide map
|
|
Signed-off-by: Martin Raspaud <martin.raspaud@smhi.se>
|
|
|
|
On FreeBSD 10, PTHREAD_MUTEX_RECURSIVE exists, but as an enum constant,
not a #define macro, so it cannot be detected using #ifdef.
|
|
|
|
|
|
Drop in the latest geodesic library from GeographicLib (version 1.44).
|
|
(#292)
|
|
http://geographiclib.sourceforge.net/1.44/C/index.html
The changes are:
- Improve accuracy of calculations by evaluating trigonometric
functions more carefully and replacing the series for the reduced
length with one with a smaller truncation error.
- The allowed ranges for longitudes and azimuths is now unlimited; it
used to be [-540d, 540d).
- Enforce the restriction of latitude to [-90d, 90d] by returning NaNs
if the latitude is outside this range.
- The inverse calculation sets s12 to zero for coincident points at
pole (instead of returning a tiny quantity).
This commit also includes a work-around for an inaccurate value for
pi/180 in dmstor.c (see the definitions of DEG_IN and DEG_OUT in
geod_interface.c).
|
|
In dmstor.c an inaccurate constant was used for pi/180. This meant that
90deg converted to radians and back to degrees gave a result which was
larger than 90deg. The constant has been replaced by DEG_TO_RAD
(defined in proj_api.h).
In rtodms.c, the trailing digits in CONV were wrong; the constant has
been truncated so that all the digits are corrent.
|
|
|
|
(autoconf build)
|
|
|
|
Remove setlocale() use in pj_init_ctx(), and replace uses of atof() &
strtod() by their locale safe variants pj_atof() and pj_strtod().
Proj versions from now advertize #define PJ_LOCALE_SAFE 1 in proj_api.h
and export pj_atof() & pj_strtod()
|
|
|
|
|
|
< 4.6 case
|
|
|
|
|
|
These variables are re-written immediately after.
|
|
Some of these should be false positives, but I re-wrote them anyway
because they were unclear.
|
|
|
|
|
|
|
|
PJ_aeqd.c uses geodesics for inverse and forward projection +
modification so that the geodesic structure is not global.
|
|
This warning indicates maybe we wanted to use assignment and added the
extra parentheses to silence that *other* warning about assignment in a
conditional. However, we really want a conditional, and the parentheses
are due to it being in a macro, so using a yoda conditional avoids the
ambiguity and silences the warning.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The problem is that the setup function doesn't initialise all of the
values that it needs for the ellipsoid, inverse, equatorial case.
In the forward and spherical inverse cases, the equatorial case
(|phi0| < 1e-10) is a simplification of the oblique case, and requires
fewer parameters. However, for the ellipsoid inverse case (e_inverse),
the oblique calculation is used, but the setup function doesn't
initialise all of the parameters.
|
|
relatively obscure problems. (1) The business of returning an unrolled
longitude with the solution to the direct problem was broken for
west-going geodesics. (2) For flattening > 1/100, a slight inaccurate
result was returned for a12 in the direct calculation.
git-svn-id: http://svn.osgeo.org/metacrs/proj/trunk@2656 4e78687f-474d-0410-85f9-8d5e500ac6b2
|
