| Age | Commit message (Collapse) | Author |
|
Need these to reduce the chance I'm screwing up something during this
rather intrusive code surgery
|
|
|
|
|
|
Correcting a blunder!
|
|
The brief version::
In an attempt to make proj.4 code slightly more secure and much easier
to read and maintain, I'm trying to eliminate a few unfortunate design
decisions from the early days of proj.4
The work will be *very* intrusive, especially in the PJ_xxx segment of
the code tree, but great care has been taken to design a process that
can be implemented stepwise and localized, one projection at a time,
then finalized with a relatively small and concentrated work package.
The (very) long version: See the comments in PJ_minimal.c
|
|
|
|
algorithm, and algorithm lineage.
|
|
|
|
Document a (the?) convention for PJ_VERSION for versions 4.10 and up.
|
|
|
|
Add support for MISR SOM projection
|
|
|
|
|
|
|
|
|
|
|
|
|
|
unnecessary assignment in Lambert Azimuthal Equal Area
|
|
adapt patch for #325 to fix static-only library building
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* upgrade geodesic.[ch3]
* add test suite geodtest.c and invoke via cmake's add_test
* increment version to 4.9.3 and library version to 11.0.0
|
|
|
|
This partially reverts https://github.com/OSGeo/proj.4/commit/338ea581
(#271) to solve issue with naptrans2008.gtx grid mentioned in
http://lists.maptools.org/pipermail/proj/2016-February/007327.html
|
|
|
|
|
|
On systems with long paths (e.g. iOS, which uses UUIDs for bundle
directories), the existing maximum path length of 128 resulted in path
truncation, and caused the grid shift file loading to fail.
This change increases the buffer size for the path to 1024 chars,
enabling the nadgrids file to be loaded on such systems.
|
|
|
|
|
|
This is to address PR #341 in which Visual C++ stops compile due to encountering a #warning.
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
nad/tv_out.dist
|
|
Add a test to check this. Output of an existing test changed in 7th
decimal place.
|
|
- New SCH coordinate system for radar imaging systems
|
|
|
|
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.
|