| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is intended to supersed https://github.com/OSGeo/proj.4/pull/1080
with a number of differences.
What is kept from #1080 is not forcing the ellipsoid_params to be the one
of a sphere. This is not required for correct coordinate computation and
avoid lying on the various distorsion parameters.
For better interoperability with EPSG, we also no longer force the
lam0 parameter to 0, because
https://www.epsg-registry.org/export.htm?gml=urn:ogc:def:method:EPSG::1024
has a provision for it, even if in practice they will always be zero
phi0 should always be zero and is not used by the formulas.
Another difference with the #1080 approach is that we do not force the
WGS84 ellipsoid. Perhaps someone will use webmerc for another planet,
even if that is a crazy idea...
|
|
Implement the Equal Earth projection (closes #1085)
|
|
DHDN_ETRS89 autoconf test
|
|
optimization issue with gcc 8.2 (fixes #1084)
|
|
torad_coord() of gie.c has this sequence:
```
if( cond )
axis = l->param + strlen ("axis=");
n = strlen (axis);
```
When the if branch is evaluated, n is always zero
even if on inspection axis is non empty
The reason is that the struct ARG_list which is the
type of l use a variable-length array for the param member
struct ARG_list {
paralist *next;
char used;
char param[1];
};
But this is not a proper way of declaring it, and
gcc 8 has apparently optimizations to detect that l->param + 5
points out of the array, hence it optimizes strlen() to 0.
Reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914
According to https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html,
the proper way of declaring such arrays is to use [0]
|
|
src/pj_strerrno.c:96:20: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
#0 in pj_strerrno proj/src/pj_strerrno.c:96:20
#1 in (anonymous namespace)::ProjErrnoStringTest_ProjErrnos_Test::TestBody() test/unit/proj_errno_string_test.cpp:47:5
ASAN UndefinedBehaviorSanitizer: signed-integer-overflow
Issue revealed by proj_errno_string_test.cpp add in
https://github.com/OSGeo/proj.4/commit/b87b59106879188ffc684a41a9de638ac5fd02bf
|
|
|
|
|
|
|
|
Fix #1074. Fix unit conversion factors for geod.
|
|
Bletch, pj_init also decodes the to_meters field of pj_unit, but only
handles plain numbers or 1/nnn, but not 1./nnn or mmm/nnn. (So the
original code would have not decoded the us-in entry properly.)
Probably pj_init should be changed to use the factor field instead.
Alternatively pj_init should look for a "/" anywhere in the field and
decode the numerator and denominator as separate doubles. This would
be needed if ratios are ever to be entered directly by the user (this
is the strategy used by GeographicLib). And then, of course, the
functionality should be provided by a separate utility function.
|
|
|
|
Previously, unit conversion using atof(unit_list[i].to_meter) which
gives the wrong answer with, e.g., "1/10". Now it directly uses
unit_list[i].factor (e.g., 0.1).
Also fix all the conversion factors for the US Surveyor units so that
they are the closest doubles. E.g., the conversion factors for US
feet are
factor rel error
old 0.304800609601219 6e-16
12/39.37 1e-16
now 1200/3937.0 5e-17
Maybe someone should check the Indian units (but it's possible that
India and Pakistan have different standards).
|
|
As mentionned in #1071, it is often unclear how the offset of a vertical grid
is applied.
|
|
Helmert: consider that xyzt.t == HUGE_VAL means t_epoch
|
|
|
|
Currently when doing
echo "2 49 0" | src/cct +proj=pipeline +ellps=GRS80 +step +proj=cart +step +proj=helmert +x=10 +y=3 +z=1
we get as a result:
-nan -nan -nan inf
This is due to cct initializing the xyzt.t to HUGE_VAL
|
|
Courtesy of Michael Stumpf <mi12st34@gmail.com>
|
|
Make +proj=geocent and +proj=cart take into account +to_meter (relates to #1053)
|
|
|
|
|
|
that it supports numeric factors (refs #1053)
|
|
|
|
PJD_ERR_NON_CONV_INV_MERI_DIST (#993)
|
|
When there are no arguments, we set PJD_ERR_NO_ARGS, just like the old
API does in that case.
On allocation failure we set ENOMEM as usual.
|
|
use-of-uninitialized-value third_party/proj4/proj/src/pj_fileapi.c:pj_ctx_fgets
Found with autofuzz msan
|
|
|
|
|
|
Refines #1034
|
|
builds only (CMake integration to be done)
|
|
The previous commits were added way to prematurely. The code was not
properly tested and it turned out to do more bad than good. This commit
hopefully fixes that. And this time it is backed up by tests!
DMS style coordinates should now be fully functional in gie. Finger
crossed.
|
|
|
|
Make gie read dms style coordinates
|
|
proj_strtod doesn't read values like 123d45'678W so we need a bit
of help from proj_dmstor. proj_strtod effectively ignores what
comes after "d", so we use that fact that when dms is larger than
d the value was stated in "dms" form.
This could be avoided if proj_dmstor used the same proj_strtod()
as gie, but that is not the case (yet). When we remove projects.h
from the public API we can change that.
|
|
|
|
|
|
|
|
|
|
Observed a buffer overflow in append_args with autofuzz with the strcpy in append_args.
I think the +2 is required to account for both a nul char and the space.
|
|
Ensure that operations are less than MAX_OPERATION long.
|
|
Add test framework, C++11 compilation mode and warning fixes
|
|
gie T.fout output cleanup
|
|
(detected by gcc 8.1)
|
|
Fixes consist in:
- no use of comma operator for multi statement purpose
- avoid confusing comma in for loops first and third clauses
- avoid implicit long to int casts by storing to long, or explicit bound checking before cast
|
|
Buffer overflow found with autofuzz.
|
|
|
|
|
|
- printf -> fprintf in more places
- puts -> fprintf
- Move list_err_codes to after where T.fout is set
This makes fuzzing easier by allowing more of the output to be sent to
/dev/null. Found with autofuzz.
|
|
|
