| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
added usage example
|
|
typo error in example - unitconvert.rst
|
|
|
|
bug in example - changed +t_in=gpsweek to +t_in=gps_week
|
|
Fixes for webmerc projection (fixes #1078)
|
|
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...
|
|
|
|
Doc: add page for geoc conversion (fixes #1092)
|
|
|
|
easily run it locally
|
|
|
|
|
|
Implement the Equal Earth projection (closes #1085)
|
|
|
|
|
|
|
|
Assorted fixes: Makefile, tests, gie enhancement, Travis-CI simplification
|
|
|
|
useless step
|
|
DHDN_ETRS89 autoconf test
|
|
|
|
(we should have a way to state that some grids must be present) (refs #872)
|
|
optimization issue with gcc 8.2 (fixes #1084)
|
|
Fix wrong behaviour of torad_coord() with gcc 8.1 -O2 (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]
|
|
pj_strerrno(): Change check of err value to avoid undefined behavior.
|
|
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
|
|
Various minor fixes
|
|
|
|
|
|
Add projection parameters to all projection doc pages
|
|
|
|
|
|
|
|
Add test coordinates for webmerc
|
|
|
|
Fix #1074. Fix unit conversion factors for geod.
|
|
vgridshift: add a +multiplier={value}
|
|
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
|
|
Closes #981
|
|
|
|
This was left out when documented the various proj_create_*
functions. Added proj_context_errno description as well
since it was undocumented and is needed when creating PJs
for a specific context.
|
|
|
