| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Doc: add page for geoc conversion (fixes #1092)
|
|
|
|
easily run it locally
|
|
|
|
|
|
Those functions contain code specific of input != angular and output = angular
which to the best of my knowledge never happens in PROJ. Looking at that
code, I feel there are a number of errors in it, and anyway removing it shows
absolutely no change in the test suite, which shows it is unused. I've also
added exit(1) to verify that those code paths are never taken.
This was found while investigating the fix for
8cfc81380617ff4a17a06a97635f77c5e9ed7d5b
|
|
There is a regression in PROJ 5 regarding the handling of the +geoc flag,
specific to the case of +proj=longlat, and the inverse transformation,
which makes it a no-op:
echo "12 55 0 " | src/cct +proj=pipeline +step +proj=longlat +ellps=GRS80 +geoc +inv
12.0000000000 55.0000000000 0.0000 inf
With this fix, we now get:
echo "12 55 0 " | src/cct +proj=pipeline +step +proj=longlat +ellps=GRS80 +geoc +inv
12.0000000000 54.8189733083 0.0000 inf
The fix consists in making inv_prepare() do symetrically as fwd_finalize(), ie
skip a number of transforms when left and right units are angular,
and in inv_finalize() apply the (OUTPUT_UNITS==PJ_IO_UNITS_ANGULAR) processing
even if INPUT_UNITS == PJ_IO_UNITS_ANGULAR
|
|
|
|
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.
|
|
|
|
|
|
|
|
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
|
|
Declutter frontpage
|
|
|
